OSPF에서 10Gbps와 100Gbps link가 같은 cost로 보인다면 protocol 오류일까요? 대개는 reference bandwidth나 explicit interface cost가 현재 회선 속도를 구분하지 못하도록 설정된 결과입니다. OSPF는 단순 hop 수가 아니라 경로를 구성하는 outbound interface cost의 합으로 SPF를 계산하고, 최저 누적 cost가 정확히 같은 경로는 ECMP 후보가 될 수 있습니다.

이번에는 FRRouting 10.7.0 라우터 네 대를 diamond로 연결해 R1에서 R4 loopback까지 두 경로를 만들었습니다. reference bandwidth 설정, 명시적 cost, ECMP 설치, 한쪽 cost 변경과 복구를 실제 RIB에서 확인했습니다.

reference bandwidth는 단위의 기준이다

FRRouting 10.7 OSPFv2 문서는 auto-cost reference-bandwidth와 ip ospf cost를 제공합니다. 자동 cost는 reference bandwidth를 interface bandwidth로 나눈 값을 기반으로 하며 정수 범위와 최솟값의 영향을 받습니다.

예를 들어 reference가 100Mbps인 오래된 기준이면 1Gbps와 10Gbps가 모두 최소 cost 1로 뭉칠 수 있습니다. 더 빠른 link를 구분하려면 network 전체에서 충분히 큰 reference를 일관되게 설정하거나, 설계 의도에 따라 interface cost를 명시해야 합니다.

중요한 점은 reference가 실제 대역폭을 측정하는 telemetry가 아니라 계산 기준이라는 사실입니다. 잘못 보고된 interface bandwidth, tunnel, shared medium, oversubscription은 자동 공식만으로 반영되지 않습니다.

두 개의 누적 cost 20 경로를 만들었다

실험 경로는 다음과 같습니다.

R1--10--R2--10--R4
 |                  loopback 10.254.4.4/32
 +---10--R3--10----+

네 라우터 모두 auto-cost reference-bandwidth 10000을 설정했고, 실험의 결정성을 위해 각 transit interface에 ip ospf cost 10을 명시했습니다. 실제 설정과 interface 출력도 확인했습니다.

docker exec ulw-ospf-c-r1 vtysh -c 'show running-config'   | grep 'auto-cost reference-bandwidth'
docker exec ulw-ospf-c-r1 vtysh -c 'show ip ospf interface eth0'   | grep -E 'Internet Address|Cost:'
docker exec ulw-ospf-c-r1 vtysh -c 'show ip ospf interface eth1'   | grep -E 'Internet Address|Cost:'

출력은 reference 10000, eth0 cost 10, eth1 cost 10을 보였습니다. explicit cost를 썼으므로 이 실험의 경로 선택은 Docker가 보고한 가상 interface 속도에 의존하지 않습니다.

동일 cost에서 두 next hop이 설치됐다

R1에서 R4 loopback 경로를 조회했습니다.

docker exec ulw-ospf-c-r1 vtysh -c 'show ip route 10.254.4.4/32'

두 경로의 누적 cost가 각각 20이어서 RIB에 두 next hop이 함께 나타났습니다.

Routing entry for 10.254.4.4/32
  Known via "ospf", distance 110, metric 20, best
  * 10.90.12.12, via eth0, weight 1
  * 10.90.13.13, via eth1, weight 1

이 결과는 control plane이 equal-cost 경로 둘을 설치했다는 증거입니다. 개별 flow가 정확히 절반씩 분배된다는 뜻은 아닙니다. 실제 forwarding 분배는 kernel이나 ASIC의 hash field, flow 수, resilient hashing 지원과 platform ECMP 한도에 달려 있습니다.

한쪽 첫 hop을 50으로 올렸다

R1-R3 방향 interface만 cost 50으로 바꾸는 controlled boundary를 만들었습니다.

docker exec ulw-ospf-c-r1 vtysh   -c 'configure terminal'   -c 'interface eth1'   -c 'ip ospf cost 50'   -c 'end'

interface 출력은 Cost: 50으로 바뀌었고, 같은 목적지의 결과는 다음 하나만 남았습니다.

Known via "ospf", distance 110, metric 20, best
* 10.90.12.12, via eth0, weight 1

R1-R3-R4 경로의 누적 cost가 60으로 증가했기 때문에 cost 20인 R1-R2-R4만 선택됐습니다. 다시 eth1을 10으로 복원하자 두 next hop이 즉시 RIB에 돌아왔습니다. topology와 목적지는 그대로 두고 cost만 바꿔 ECMP의 성립 조건을 분리한 결과입니다.

운영에서 흔한 경계

reference bandwidth를 바꿀 때 한 라우터만 수정하면 같은 link를 서로 다른 metric으로 표현할 수 있습니다. OSPF adjacency는 유지될 수 있지만 각 출발점의 SPF 선택이 예상과 달라져 비대칭 경로나 우회 경로가 생깁니다. 따라서 reference 변경은 routing domain 전체의 coordinated change여야 합니다.

명시적 cost도 문서화가 필요합니다. 나중에 회선을 증속해도 explicit cost는 자동으로 바뀌지 않습니다. 반대로 자동 cost만 믿으면 tunnel과 shared uplink의 실제 가용 용량을 과대평가할 수 있습니다.

점검할 항목은 다음과 같습니다.

  • 모든 라우터의 reference bandwidth 값이 같은가
  • 자동 cost와 explicit ip ospf cost 중 무엇이 최종값을 결정하는가
  • 양방향 interface cost가 의도한 대칭성을 갖는가
  • end-to-end 누적 cost를 각 출발 라우터에서 계산했는가
  • ECMP next hop 수가 FRR RIB와 kernel FIB에서 모두 같은가
  • flow hash 편향과 platform ECMP 한도를 별도로 측정했는가
  • link 증속 뒤 cost 정책을 함께 갱신하는가
  • cost 변경 시 예상 우회 경로의 용량이 충분한가

확인 범위와 결론

이번 실험은 네 Docker router의 control-plane RIB에 한정했습니다. 실제 packet을 여러 flow로 보내 분배율, packet reordering, failure convergence 시간을 측정하지 않았습니다. interface cost는 모두 합성 설정입니다.

직접 확인한 결과, 누적 cost 20인 두 경로는 FRR RIB에 ECMP next hop 두 개로 설치됐습니다. R1의 한 interface만 cost 50으로 올리자 더 싼 경로 하나만 남았고, 10으로 복원하자 ECMP가 돌아왔습니다.

결론은 단순합니다. reference bandwidth는 cost의 공통 눈금을 만들고, SPF는 누적 cost를 비교하며, ECMP는 그 최저값이 같은 경로 사이에서만 성립합니다. 속도 표기보다 실제 interface cost와 최종 FIB를 확인해야 합니다.