핵심 인사이트 (3줄 요약)

  1. 본질: 원래 라우터는 패킷의 "목적지 IP(어디로 갈래?)"만 보고 길을 찾지만, PBR(정책 기반 라우팅)은 목적지뿐만 아니라 "출발지 IP(누가 보냈니?)", "포트 번호(웹이냐 FTP냐?)" 등 관리자가 원하는 다양한 조건을 걸어 패킷의 방향을 강제로 꺾어버리는 갑질 라우팅이다.
  2. 라우팅 테이블(RIB) 무시: PBR이 라우터 포트에 적용되면, 라우터는 자신이 똑똑하게 계산해 둔 라우팅 테이블(OSPF/BGP)을 무시하고, 관리자가 Route Map(경로 지도)으로 지시한 룰을 1순위로 복종하여 패킷을 던진다.
  3. 주요 활용 (로드 밸런싱과 보안): "사장님(특정 IP)이 쓰는 트래픽은 빵빵한 전용선(1번 길)으로 보내고, 직원들이 쓰는 트래픽은 싸구려 ADSL선(2번 길)으로 몰아내라!"처럼 극도로 정밀한 사내 트래픽 통제(Traffic Engineering)를 할 때 쓰인다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

  • 개념: 표준 라우팅 프로토콜이 결정한 최적 경로(Destination-based)를 무시하고, 관리자가 정의한 정책(Route Map)에 따라 트래픽의 포워딩 경로를 임의로 조작하는 기술.

  • 필요성: 서울 본사에서 부산 지사로 가는 길이 2개 있다 (1번 광랜, 2번 일반선). OSPF를 돌리면 무조건 1번 광랜만 탄다. 근데 사장님이 지시했다. "야, 임원진 PC 10대가 보내는 데이터만 1번 광랜 태우고, 나머지 1000명 일반 직원이 보내는 건 다 2번 일반선으로 몰아!" OSPF(목적지 기반 라우팅)로는 이 지시를 절대 구현할 수 없다(부산이라는 목적지는 같으니까). 결국 패킷의 **'출발지(Source)'**나 **'어플리케이션 종류'**를 뜯어보고 길을 갈라치는 깡패 같은 룰이 필요했다.

  • 💡 비유: 일반 라우팅이 **"지하철 노선도"**라면, PBR은 클럽 앞의 **"기도(가드) 아저씨"**입니다.

    • 지하철: 승객이 부자든 거지든(출발지 무관) "강남역(목적지)" 간다고 하면 똑같은 2호선 열차에 태웁니다.
    • PBR 가드: 클럽(목적지)에 들어가려는 사람들을 붙잡고, **"어? 너 VIP(특정 출발지 IP)네? 넌 하이패스 정문으로 가! 어? 넌 일반인이네? 저쪽 좁은 뒷문으로 돌아가!"**라며 사람의 신분을 보고 강제로 길을 꺾어버립니다.

📢 섹션 요약 비유: PBR은 공정한 법(라우팅 테이블) 위에 군림하는 **"관리자의 독재(사면권)"**입니다. 내비게이션이 아무리 빠른 길을 알려줘도, 조수석에 앉은 회장님이 "저쪽 골목으로 들어가!" 하면 운전사(라우터)는 찍소리 못하고 핸들을 꺾어야 합니다.

Ⅱ. Route Map 구조와 PBR의 동작 방식 (Deep Dive)

1. Route Map (루트 맵)의 뼈대: Match & Set

PBR을 구현하려면 시스코 장비 기준 **route-map**이라는 프로그래밍 함수 같은 구조체를 짜야 한다. 루트 맵은 철저하게 "If ~ Then" 구조로 되어 있다.

  • match (If 조건문): "누구를 잡아낼 것인가?"
    • 예: match ip address 10 (ACL 10번에 적힌 사장님 IP 192.168.1.99를 잡아라!)
    • 예: match length 1000 1500 (패킷 크기가 1000바이트 이상인 무거운 놈만 잡아라!)
  • set (Then 실행문): "잡아낸 놈을 어떻게 요리할 것인가?"
    • 예: set ip next-hop 10.1.1.1 (원래 길 무시하고 10.1.1.1 라우터 쪽으로 냅다 던져버려라!)

2. 패킷 처리 시퀀스 (PBR vs 일반 라우팅)

포트로 패킷이 들어올 때 라우터의 뇌구조는 다음과 같다.

  1. 이 포트에 PBR(정책)이 걸려 있나 확인.
  2. 걸려있네? 패킷을 뜯어서 match 조건에 맞는지 본다.
  3. 조건에 맞으면(예: 사장님 IP) ──▶ 라우팅 테이블 무시하고, set 명령에 따라 강제로 1번 길로 날려버림!
  4. 조건에 안 맞으면(예: 일반 직원) ──▶ PBR 룰을 통과하여, 비로소 일반 라우팅 테이블(OSPF 등)을 보고 2번 길로 정상 배달됨.
 ┌─────────────────────────────────────────────────────────────┐
 │                PBR (Policy-Based Routing) 트래픽 갈라치기 도식    │
 ├─────────────────────────────────────────────────────────────┤
 │                                                             │
 │   [ 사장님 PC (192.168.1.99) ] ────┐                          │
 │                                  ▼ [라우터]                     │
 │   [ 직원들 PC (192.168.1.x)  ] ────┤ 1) PBR 검사              │
 │                                    │ - 99번 IP인가? (Match)   │
 │                                    │ - Yes ──▶ 광랜으로 쏴! (Set)│
 │                                    │ - No  ──▶ 라우팅테이블 봐!  │
 │                                    │                        │
 │   * 라우터의 행동:                      ▼                        │
 │     사장님 패킷 ════════════════════▶ [ 광랜 (비싼 전용선) ]      │
 │     직원들 패킷 ────────────────────▶ [ 일반망 (ADSL선) ]       │
 │                                                             │
 │   ▶ "목적지가 같아도 출발지 신분에 따라 다른 길로 던지는 마법!"         │
 └─────────────────────────────────────────────────────────────┘

3. PBR의 치명적 단점 (CPU 갉아먹기)

PBR은 마약과 같다. 쓰면 좋지만 남발하면 라우터가 죽는다. 하드웨어(FIB)가 기계적으로 처리하던 걸, CPU가 일일이 "이거 사장님 IP 맞나? 크기는 맞나?" 하고 match 구문을 검사(소프트웨어 처리)해야 하므로 트래픽 병목과 딜레마(CPU 100%)를 유발한다. 따라서 꼭 필요한 구간에 최소한으로만 걸어두는 것이 실무의 정석이다.

📢 섹션 요약 비유: Route Map 설정(match와 set)은 컨베이어 벨트 위의 **"불량품 선별기"**입니다. 벨트 위를 지나가는 수만 개의 택배(패킷) 중, "빨간색 스티커가 붙은 박스(match 조건)"만 귀신같이 탁 쳐서 "VIP 배송 트럭(set 조건)"으로 튕겨내는 무자비한 분류 시스템입니다.