BGP 경로가 두 개 보일 때 “AS_PATH가 짧은 쪽이 무조건 이긴다”는 설명은 실무에서 자주 틀립니다. 운영자가 먼저 답해야 할 질문은 어떤 속성이 먼저 비교되며, MED는 언제 비교 가능한가입니다.

FRRouting 10.7.0에서 동일한 203.0.113.0/24를 두 eBGP 이웃이 광고하게 한 뒤 LOCAL_PREF, AS_PATH, ORIGIN, MED를 한 단계씩 바꿨습니다. 숫자를 외우는 대신 상위 조건을 같게 만들어야 다음 조건이 효력을 갖는다는 사실을 확인했습니다.

best path는 정렬이 아니라 단계별 탈락이다

FRR의 BGP best path 문서는 여러 조건을 순서대로 비교합니다. 구현별 확장인 weight와 로컬 생성 여부 등을 제외하고 이번 실험이 다룬 핵심 순서는 높은 LOCAL_PREF, 짧은 AS_PATH, 좋은 ORIGIN(IGP가 incomplete보다 우선), 낮은 MED였습니다.

이 순서는 점수를 더하는 방식이 아닙니다. LOCAL_PREF가 다른 두 경로는 그 단계에서 승패가 나므로 뒤의 MED가 아무리 낮아도 결과를 뒤집지 못합니다. 다음 속성을 시험하려면 앞선 속성을 같게 해야 합니다.

RFC 4271은 LOCAL_PREF를 AS 내부에서 선호도를 알리는 well-known discretionary 속성으로, MED를 다른 AS에 여러 진입점 중 선호도를 전달하는 optional non-transitive 속성으로 정의합니다. 둘 다 숫자지만 적용 범위와 전달 성격이 다릅니다.

동일 조건의 두 광고를 준비했다

선택 라우터 AS65010에 192.0.2.21과 192.0.2.22 두 이웃을 연결했습니다. 두 이웃은 같은 사설 AS65100을 사용하고 동일 프리픽스를 광고했습니다. 같은 neighboring AS로 만든 이유는 FRR 기본값에서 MED 비교 경계를 흐리지 않기 위해서입니다.

첫 이웃의 inbound route-map은 LOCAL_PREF 200, 둘째는 100으로 설정했습니다. 광고 측 MED는 각각 50과 200이었습니다.

route-map LP-A permit 10
 set local-preference 200
route-map LP-B permit 10
 set local-preference 100
router bgp 65010
 neighbor 192.0.2.21 remote-as 65100
 neighbor 192.0.2.22 remote-as 65100
 address-family ipv4 unicast
  neighbor 192.0.2.21 route-map LP-A in
  neighbor 192.0.2.22 route-map LP-B in
 exit-address-family

다음 명령으로 매 단계의 두 후보를 조회했습니다.

docker exec ulw-bgp-best vtysh -c "show bgp ipv4 unicast 203.0.113.0/24 json"

controlled boundary 1: LOCAL_PREF가 아래 조건을 눌렀다

초기 결과에서 192.0.2.21 경로는 LOCAL_PREF 200, MED 50이고 best였습니다. 192.0.2.22는 LOCAL_PREF 100, MED 200이었습니다. 이 경우 두 속성이 모두 첫 경로를 가리키므로, 우선순위만 검증하기에는 부족합니다.

그래서 경계를 더 명확히 하기 위해 뒤 단계마다 앞 조건을 같게 만들었습니다. LOCAL_PREF를 둘 다 100으로 바꾸고, 이후 AS_PATH와 ORIGIN을 조작했습니다. 설정 변경 뒤에는 실제로 clear bgp * soft in 또는 soft out을 실행해 정책을 재평가했습니다.

2단계: AS_PATH가 MED보다 먼저였다

첫 이웃의 outbound route-map에 ASN 65100을 두 번 prepend했습니다. 수신 결과는 첫 경로 65100 65100 65100, 둘째 경로 65100이었습니다. 첫 경로의 MED는 여전히 더 낮은 50이었지만, best는 192.0.2.22로 바뀌었습니다.

이는 낮은 MED가 긴 AS_PATH를 보상하지 못한다는 직접 관찰입니다. AS prepend는 외부 유입 방향을 유도할 때 쓰지만 상대 AS의 LOCAL_PREF 정책이 더 앞서면 기대한 효과가 없을 수 있습니다. “두 번 prepend하면 반드시 백업 회선이 된다”는 보장은 없습니다.

3단계: ORIGIN은 IGP가 incomplete보다 앞섰다

prepend를 제거해 AS_PATH 길이를 같게 만들었습니다. 첫 경로에는 set origin incomplete, 둘째에는 set origin igp를 적용했습니다. 결과는 192.0.2.22의 IGP 경로가 best였고, MED 50인 첫 경로는 incomplete 때문에 탈락했습니다.

ORIGIN은 IGP 라우팅 프로토콜의 metric과 같은 뜻이 아닙니다. BGP 경로가 어떤 방식으로 유입됐는지를 나타내는 BGP 속성입니다. 운영 중 redistribution이나 정책이 ORIGIN을 바꾸면 AS_PATH가 같은 경로의 선택이 달라질 수 있습니다.

4단계: 앞 조건이 같을 때 MED가 작동했다

마지막으로 두 경로의 LOCAL_PREF를 100, AS_PATH를 65100, ORIGIN을 IGP로 맞췄습니다. MED만 첫 이웃 50, 둘째 200으로 남겼습니다. best는 192.0.2.21로 돌아왔습니다.

중요한 경계는 기본 MED 비교는 일반적으로 같은 neighboring AS에서 온 경로를 대상으로 한다는 점입니다. 서로 다른 upstream 사이의 MED를 일괄 비교하려면 FRR의 bgp always-compare-med 같은 별도 동작을 검토해야 하지만, 이번 실험에서는 켜지 않았습니다. 설정 하나를 추가하기 전에 여러 경로의 비교 순서와 route flap 영향을 함께 평가해야 합니다.

운영에서 흔한 실패

첫째, LOCAL_PREF를 고객·피어·트랜짓에 일관되게 부여하지 않으면 외부의 AS prepend보다 내부 정책이 예상치 못한 출구를 고릅니다. 둘째, MED를 서로 다른 AS 사이의 절대 비용으로 해석하면 기본 비교 대상이 아닌 값을 보고 결론을 냅니다. 셋째, best 한 줄만 보고 대체 후보가 왜 탈락했는지 놓칩니다.

경로 변경 전후에는 모든 후보의 peer, next hop, LOCAL_PREF, AS_PATH, ORIGIN, MED와 selection reason을 함께 저장해야 합니다. 한 속성만 캡처하면 다음 장애에서 같은 판단을 재현할 수 없습니다.

도입 전 점검표

  • 네트워크 전체의 LOCAL_PREF 등급과 의미가 문서화됐는가
  • AS prepend 전에 상대방 LOCAL_PREF가 우선할 수 있음을 고려했는가
  • ORIGIN을 변경하는 redistribution·route-map이 있는가
  • MED를 같은 neighboring AS 경로끼리 비교하는지 확인했는가
  • always-compare-med 같은 전역 옵션의 영향 범위를 검토했는가
  • best뿐 아니라 모든 후보와 선택 이유를 모니터링하는가

결론

직접 바꿔 본 결과 LOCAL_PREF 200 경로가 먼저 선택됐고, LOCAL_PREF를 같게 하자 짧은 AS_PATH가 낮은 MED를 이겼습니다. AS_PATH까지 같게 하자 IGP ORIGIN이 incomplete를 이겼으며, 앞 조건을 모두 같게 만든 뒤에야 MED 50이 MED 200을 이겼습니다.

따라서 BGP 경로 선택은 “짧은 AS_PATH” 한 문장으로 운영할 수 없습니다. 상위 속성을 의도적으로 통제하고, MED 비교 범위를 확인하며, 변경마다 전체 후보를 증거로 남겨야 예측 가능한 정책이 됩니다.