OSPF와 BGP (Adjacency, Route Filtering, Redistribute)

OSPF와 BGP 내부망

OSPF Adjacency가 맺히지 않는다는 에러를 처음 마주했을 때, 저는 솔직히 ping이 멀쩡하게 되는 상황에서 무엇이 문제인지 한참을 헤맸습니다. 그 경험이 OSPF와 BGP 두 프로토콜을 진지하게 파고드는 계기가 되었습니다. 내부망을 책임지는 OSPF와 인터넷 경계를 담당하는 BGP, 이 둘을 함께 이해하지 않으면 실무 네트워크 구조는 절반밖에 안 보입니다.

Adjacency가 안 맺힌다면, 먼저 이것부터 확인하세요

엔터프라이즈 네트워크에서 OSPF를 운영하다 보면 가장 자주 마주치는 증상이 Adjacency 실패입니다. Adjacency란 OSPF 라우터끼리 서로를 이웃으로 인식하고 링크 상태 정보를 교환하는 관계를 말합니다. 쉽게 말해 두 라우터가 "우리 연결됐어, 경로 정보 나눠보자"라고 합의한 상태가 만들어지지 않으면, 아무리 물리적으로 연결돼 있어도 OSPF는 작동하지 않습니다.

제가 직접 겪어보니 원인은 크게 세 가지로 좁혀지는 경우가 많았습니다. 첫 번째는 Hello Interval과 Dead Interval 불일치입니다. OSPF는 Hello 패킷을 일정 간격으로 주고받으며 이웃 관계를 유지합니다. 양쪽 라우터의 Hello Interval이 다르면 Adjacency는 절대 성립하지 않습니다. 두 번째는 MTU 미스매치입니다. MTU(Maximum Transmission Unit)란 한 번에 전송할 수 있는 최대 패킷 크기를 의미합니다. MTU가 맞지 않으면 ping은 정상인데 OSPF DBD(Database Description) 패킷이 잘려나가면서 Adjacency가 ExStart/Exchange 단계에서 멈춥니다. 처음에 이 증상을 보면 귀신이 곡할 노릇입니다. 세 번째는 Area ID 오설정입니다. OSPF는 Area 구조로 네트워크를 계층화합니다. Area 0은 Backbone Area로, 모든 Area는 반드시 Area 0을 통해 연결되어야 합니다. Area ID가 한쪽만 틀려도 Adjacency는 형성되지 않습니다.

제 경험상 이 중에서도 MTU 문제가 가장 찾기 어려웠습니다. ping이 되니까 L3 연결은 문제없다고 판단하고, OSPF 설정 쪽만 반복해서 들여다보다가 시간을 많이 잃었습니다. ping의 기본 패킷 크기가 64바이트 수준이기 때문에 MTU 미스매치 상황에서도 정상 응답을 받을 수 있습니다. 반면 OSPF DBD 패킷은 훨씬 크기 때문에 같은 환경에서 잘려나갑니다. 이 차이를 몰랐을 때는 "ping 됩니다"라는 말이 전혀 다른 의미를 가질 수 있다는 걸 인식하지 못했습니다.

이제는 OSPF Adjacency 문제가 생기면 가장 먼저 MTU 이슈인지 아닌지 확인하고, Hello/Dead Interval 차이를 점검하고, Area ID를 순서대로 좁혀나갑니다. 문제를 빠르게 좁혀나가는 순서가 결국 장애 대응의 속도를 결정합니다.

OSPF가 IGP(Interior Gateway Protocol), 즉 단일 자율 시스템(AS) 내부에서 경로를 학습하는 프로토콜이라는 점도 이 맥락에서 중요합니다. IGP란 하나의 조직이나 사업자가 관리하는 네트워크 영역 안에서만 동작하는 라우팅 프로토콜을 말합니다. OSPF가 Dijkstra의 SPF(Shortest Path First) 알고리즘으로 최단 경로를 계산하는 방식 덕분에 수렴 속도가 빠르다는 점은 잘 알려져 있지만, 그 속도를 제대로 살리려면 Adjacency가 안정적으로 유지되어야 한다는 전제가 있습니다.

Route Filtering 없이 BGP 피어링하면 생기는 일

솔직히 이건 예상 밖이었습니다. 신규 ISP와 BGP 피어링을 처음 맺으면서 Route Filtering 없이 full routing table을 그대로 수신했을 때, 라우터가 말 그대로 숨이 막혀가는 것을 눈앞에서 지켜봤습니다. BGP 테이블에 80만 개가 넘는 경로가 올라오면서 메모리가 치솟고 CPU가 100%에 달하는 상황이 순식간에 펼쳐졌습니다.

BGP(Border Gateway Protocol)는 AS(Autonomous System) 간 인터넷 라우팅을 담당하는 EGP(Exterior Gateway Protocol)입니다. EGP란 서로 다른 조직이나 사업자가 운영하는 네트워크 간의 경로를 교환하는 프로토콜로, BGP는 현재 인터넷 전체의 라우팅 구조를 떠받치는 유일한 표준입니다. BGP-4 버전이 RFC 4271로 정의되어 있으며, AS_PATH 속성을 활용해 라우팅 루프를 방지하는 구조로 설계되어 있습니다.

이 사건에서 가장 크게 반성한 부분은, 피어링 설정 자체에 집중하느라 "이 설정이 실제로 어떤 규모의 데이터를 끌어들이는가"를 전혀 고려하지 않았다는 점입니다. BGP full routing table이 얼마나 거대한지를 숫자로는 알고 있었는데, 실제로 그게 라우터에 어떤 충격을 주는지는 막상 눈앞에서 보기 전까지 실감하지 못했습니다. 이론과 실감 사이의 간극이 이만큼 클 수 있다는 걸 그날 배웠습니다.

그 사건 이후로 저는 BGP 피어링 설정에서 반드시 Route Filtering을 먼저 구성하는 것을 원칙으로 삼았습니다. prefix-list로 수신할 경로 범위를 제한하고, route-map으로 정책을 적용한 뒤 피어링을 활성화하는 순서를 지키는 것입니다. 필요에 따라서는 full routing table 대신 default route만 수신하도록 설정하는 것이 훨씬 안전하고 운용 효율도 높습니다.

여기서 한 가지 더 짚고 싶은 것이 iBGP와 OSPF를 연동하는 Redistribute 설정입니다. Redistribute란 서로 다른 라우팅 프로토콜 간에 경로 정보를 재분배하는 기능을 말합니다. OSPF 경로를 BGP로, BGP 경로를 다시 OSPF로 넘기는 양방향 Redistribute를 잘못 설정하면 라우팅 루프가 발생합니다. 제가 직접 이 루프를 경험했는데, Route Tag와 Distribute-list를 조합해 필터링 로직을 설계하기 전까지 네트워크가 불안정하게 흔들렸습니다. 이 구조는 한 번 꼬이면 추적하기가 매우 까다롭습니다.

Redistribute 문제가 까다로운 이유는 증상과 원인 사이의 거리가 멀기 때문입니다. 특정 경로가 갑자기 사라지거나 예상과 다른 경로를 타는 증상이 나타나는데, 그 원인이 두 프로토콜 사이의 경로 재분배 루프라는 걸 연결하기까지 시간이 걸립니다. 이 문제를 빠르게 잡으려면 평소에 어떤 경로가 어느 프로토콜로 학습됐는지를 파악하는 습관이 있어야 합니다. 장애 상황에서 처음으로 라우팅 테이블 구조를 파악하려 하면 이미 늦습니다.

일반적으로 OSPF와 BGP를 별개로 공부하는 경우가 많은데, 실제로 써보니 두 프로토콜은 계층적으로 맞물려 동작합니다. OSPF가 내부 경로를 학습하고, BGP가 그 경로를 외부에 광고하는 구조입니다. 그리고 BGP는 단순한 기술 프로토콜이 아닙니다. 어떤 경로를 수용하고 광고할지는 기업 간 계약과 정책이 반영된 결정입니다. BGP 하이재킹이 반복되는 이유도 이 신뢰 구조의 허점에서 비롯된다고 보는 시각이 있으며, RIPE NCC 역시 이 문제를 라우팅 보안의 핵심 과제로 다루고 있습니다.

OSPF Adjacency 문제든 BGP Route Filtering 실수든, 결국 두 프로토콜을 동시에 이해하고 있어야 원인을 제대로 추적할 수 있습니다. 피어링 설정 전 Route Filtering 구성, Redistribute 시 루프 방지 로직 설계, Adjacency 장애 시 MTU 우선 확인, 이 세 가지는 실무에서 반복적으로 마주치는 지점입니다. 이론으로만 알고 있으면 막상 장애 상황에서 손이 잘 움직이지 않습니다. 직접 랩 환경에서 일부러 오설정을 만들어보고 복구해보는 과정이 가장 빠른 학습이라고 생각합니다. 그리고 그게 귀찮게 느껴진다면, 실제 장애 상황에서 훨씬 더 많은 시간을 쓰게 된다는 걸 미리 알아두시기 바랍니다.

---

출처

• RFC 2328 — OSPF Version 2 — https://datatracker.ietf.org/doc/html/rfc2328
• RFC 4271 — BGP-4 — https://datatracker.ietf.org/doc/html/rfc4271
• Cisco — OSPF Design Guide — https://www.cisco.com/c/en/us/support/docs/ip/ospf/
• Cisco — BGP Best Practices — https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/
• AWS Direct Connect BGP Configuration — https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html
• CCNP ENCOR Official Cert Guide (Cisco Press)