네트워크 인프라 이해하기 · 제5부 · 사내망을 지사·클라우드·인터넷과 연결하기

OSPF 경로를 다른 프로토콜로 넘기면 왜 다시 돌아올까

서로 다른 라우팅 도메인 사이에서 경로 의미를 번역하고 되먹임을 차단하는 법

OSPF와 다른 라우팅 프로토콜 사이에서 Route를 넘기면 원래 Metric과 출처 정보가 그대로 보존되지 않습니다. 경계 라우터는 허용할 Prefix와 새 Metric을 정하고 Route Tag를 남겨 같은 경로가 원래 도메인으로 되돌아오는 것을 막아야 합니다. 이 글에서는 한 Prefix를 양쪽 경계로 따라가며 Loop가 생기는 지점과 정책·검증 순서를 설명합니다.

서로 다른 라우팅 프로토콜 사이에서 Route를 넘기면 원래 의미가 그대로 남을까↑

OSPF의 Cost와 LSA Type, BGP의 AS_PATH와 LOCAL_PREF는 서로 같은 단위가 아닙니다. 경계 라우터가 OSPF Route를 다른 프로토콜에 재분배하면 원래 계산 과정 전체가 넘어가는 것이 아니라, 선택된 Prefix와 Next-Hop 정보를 바탕으로 대상 프로토콜의 새 Route를 생성합니다.

어떤 Route Source를 대상으로 삼는지, RIB에 설치된 경로만 보는지, Connected와 Static을 별도로 포함해야 하는지는 구현과 명령에 따라 다릅니다. 따라서 “redistribute ospf” 한 줄이 정확히 어떤 Prefix 집합을 의미하는지 먼저 확인해야 합니다.

경계 라우터의 RIB에 10.20.30.0/24가 OSPF Route로 선택되어 있어도 대상 프로토콜로 넘길 때 OSPF의 토폴로지와 Cost 경로 전체가 전달되지는 않습니다. 경계는 그 Prefix를 자신이 새로 Origin한 외부 Route처럼 만들고 대상 프로토콜의 Attribute를 붙입니다. 수신 라우터는 원래 OSPF 내부 경로였다는 맥락을 기본적으로 알 수 없습니다.

어떤 Route가 Redistribution 후보인지도 플랫폼마다 주의가 필요합니다. 프로토콜 데이터베이스에 있지만 RIB에서 선택되지 않은 Route, Connected 인터페이스, Static Default와 Summary가 자동 포함되는지 명령 의미가 다릅니다. 따라서 Source 프로토콜 이름 하나로 범위를 추측하지 않고 Route Map·정책에서 허용 Prefix와 원래 RIB Source를 명시합니다. 정책 적용 전 후보 목록을 출력해 예상보다 넓은 Route Set이 넘어가지 않는지 검증해야 합니다.

따라서 “OSPF를 BGP로 연결했다”는 표현만으로는 범위가 부족합니다. 어느 VRF의 어떤 Route Source와 Prefix를, 어느 경계에서, 어떤 Attribute·Metric으로 내보내는지 명시해야 합니다. Connected나 Static이 함께 포함되는지와 Default Route 생성 조건도 Route Map과 실제 광고 결과에서 확인합니다.

이 절의 근거 IETF RFC 2328 · IETF RFC 4271 · Cisco Routing Protocol Redistribution

다른 프로토콜로 들어간 Route가 비교되려면 새 Metric과 Route Type이 필요하다↑

경계를 건넌 Route에는 대상 프로토콜이 비교할 수 있는 Metric이 필요합니다. OSPF로 외부 경로를 넣을 때는 External Type과 External Metric을 정하고, 다른 IGP는 자체 Composite Metric이나 홉 Count를 요구할 수 있습니다.

기본 Seed Metric이 무한대처럼 취급되어 경로가 광고되지 않는 구현도 있고, 지나치게 낮은 값 때문에 외부 경로가 내부 경로처럼 선호되는 구성도 생깁니다. Metric 숫자만 맞출 것이 아니라 장애 때 어느 경로가 이겨야 하는지 의도를 먼저 정한 뒤 대상 프로토콜의 의미로 표현해야 합니다.

OSPF에 외부 Route를 넣을 때 E1은 외부 Metric과 ASBR까지의 내부 Cost(Forwarding Address가 0이 아니면 해당 주소까지의 Cost)를 함께 고려하고, E2는 일반적으로 외부 Metric을 주된 값으로 사용합니다. 어느 유형이 맞는지는 여러 Exit 사이에서 내부 경로 비용을 반영해야 하는지에 달려 있습니다. 다른 프로토콜의 Metric 의미는 또 다르므로 Source Cost 20을 숫자 그대로 복사해도 같은 선호도를 나타내지 않습니다.

Seed Metric을 모든 Prefix에 하나로 주면 출처와 품질이 다른 WAN·Static Route가 같은 외부 비용으로 보일 수 있습니다. Prefix Group과 Entry Point에 따라 Metric·Type을 분류하고, 장애 때 어느 경계가 승자가 되어야 하는지 계산합니다. 기본값이 무엇인지 장비 문서에서 확인하고 설정에 명시하는 편이 안전합니다. 값 변경은 대상 도메인 전체의 선택 경로를 바꿀 수 있으므로 대표 Prefix뿐 아니라 전체 수용 Route 수를 검토합니다.

OSPF External Route의 E1은 외부 Metric에 ASBR까지의 내부 Cost(Forwarding Address가 0이 아니면 해당 주소까지의 Cost)를 더하고, E2는 일반적으로 외부 Metric을 중심으로 비교하는 등 Route Type도 경로 선택에 영향을 줍니다. 세부 Tie-Break는 구현과 토폴로지에 따라 확인해야 합니다. 설계에서는 대상 도메인 안에서 어느 경계를 선호할지 의도부터 정하고 Metric·Type을 그 의도에 맞춰 부여합니다.

이 절의 근거 IETF RFC 2328 · Cisco Routing Protocol Redistribution

두 경계에서 서로 Route를 넘기면 같은 Prefix가 원래 도메인으로 되돌아올 수 있다↑

Boundary A가 OSPF Prefix를 프로토콜 X에 넣고 Boundary B가 프로토콜 X Route를 OSPF에 넣는다고 해 보겠습니다. B는 그 Route가 원래 OSPF에서 왔다는 사실을 별도로 식별하지 못하면 새로운 OSPF External Route로 다시 광고할 수 있습니다.

원래 내부 경로가 장애로 사라지는 순간 되돌아온 외부 경로가 살아남으면 트래픽이 잘못된 경계로 향하거나 Loop가 만들어질 수 있습니다. 정상 상태의 라우팅 테이블만 보고 발견하기 어려운 이유입니다. 링크와 Route를 일부러 철회하는 장애 Test가 필요합니다.

OSPF 도메인의 10.20.30.0/24가 Boundary A에서 EIGRP로 넘어가고 Boundary B에서 다시 OSPF External로 들어오면 원본과 되돌아온 복사본이 공존합니다. 원본 OSPF 링크가 정상일 때는 내부 Route가 이겨 문제를 숨길 수 있습니다. 원본이 철회되는 순간 External 복사본이 남아 B를 향하고, EIGRP 쪽에서는 다시 A를 향하면 전달 Loop가 드러납니다.

이 문제는 프로토콜의 Neighbor가 모두 연결된 상태로 보이는 화면에서도 존재합니다. 그래서 양방향 재분배를 검증할 때는 한 경계만 차단하는 시험, 원본 Prefix만 철회하는 시험과 두 경계 복구 순서를 모두 확인해야 합니다. TTL Exceeded, 반복되는 Next Hop과 Route Age가 단서가 됩니다. 가장 단순한 해결은 한 프로토콜을 중심으로 정해 재분배 방향을 줄이는 것이며, 불가피하면 원본 식별과 입력 차단 정책을 모든 경계에 일관되게 둡니다.

이 문제는 단순히 Administrative Distance 하나를 바꾸는 것으로 모든 실패 상태에서 해결되지 않습니다. 어느 Prefix가 어느 도메인에서 기원했는지 표시하고, 같은 출처가 원래 경계로 재진입하지 못하게 명시적으로 필터링해야 합니다. 두 경계가 동시에 정상일 때뿐 아니라 한 경계·한 프로토콜·원본 Prefix가 각각 사라지는 경우를 시뮬레이션합니다.

이 절의 근거 IETF RFC 2328 · IETF RFC 4271 · Cisco Routing Protocol Redistribution

Default Route와 Summary 한 줄이 예상보다 훨씬 넓은 트래픽을 움직인다↑

Default Route Redistribution은 모든 미지의 목적지를 경계로 끌어옵니다. 기본 경로가 존재한다는 조건, Always 광고 여부, 원래 Next Hop의 상태를 구분하지 않으면 외부 연결이 끊겼는데도 내부 라우터가 계속 경계로 보낼 수 있습니다.

Summary Route는 경로 수와 변화 전파를 줄이지만 일부 하위 Prefix가 사라져도 Summary가 남을 수 있습니다. Null Route로 Loop를 막는 설계, 이중 경계의 우선순위, 더 구체적인 경로의 광고 조건을 함께 검토해야 합니다. Redistribution은 연결성 기능인 동시에 장애 범위를 결정하는 정책입니다.

경계가 실제 인터넷 Reachability와 무관하게 Default를 항상 광고하면 상위 회선이 끊겨도 내부 라우터는 모든 미지 목적지를 그 경계로 보냅니다. Default Origin 조건을 Track이나 RIB 존재와 연결하더라도 그 조건이 보호하려는 원격 범위를 대표하는지 확인해야 합니다. 이중 경계에서는 Metric과 정책으로 Primary·백업을 정하고 두 Default가 동시에 철회될 때 내부 동작도 설계합니다.

Summary 10.20.0.0/16 아래에 실제로 10.20.30.0/24만 있어도 /16을 광고하면 나머지 목적지 트래픽이 경계로 들어올 수 있습니다. 경계에 Null Route를 두면 Loop는 막지만 해당 트래픽은 폐기됩니다. Child Prefix 일부가 다른 경계로 이동할 때 더 구체적인 Route가 Summary보다 우선하는지 확인합니다. Default와 Summary는 Route 수를 줄이는 도구이면서 실패 시 트래픽을 어디에서 버릴지 결정하는 정책입니다.

Default를 항상 생성할지 특정 상류 Route·Track이 있을 때만 생성할지 정하고, Summary에는 집약 장비의 Discard Route와 부분 장애 동작을 검토합니다. 더 구체적인 예외 Prefix가 다른 경계에서 들어오면 Longest Prefix Match가 Default 선호도보다 먼저 적용됩니다. 정상·부분·전체 장애마다 실제 FIB 결과를 목적지 샘플로 확인합니다.

이 절의 근거 IETF RFC 2328 · IETF RFC 4271

용어사전↑