네트워크 인프라 이해하기 · 제3부 · 다른 네트워크와 인터넷으로는 어떻게 나갈까

링크가 끊기면 OSPF는 새 경로를 어떻게 찾아낼까

Hello에서 LSDB 동기화·LSA 플러딩·SPF 재계산까지 이어지는 Link-State 수렴

OSPF 라우터는 이웃을 맺고 Link-State 정보를 교환해 같은 Area의 LSDB가 같은 정보를 갖도록 동기화합니다. 각 라우터는 이 연결 정보를 바탕으로 자신을 출발점으로 SPF를 계산하고, 결과를 RIB와 FIB에 반영합니다. 이 글에서는 Hello부터 Neighbor 상태, LSA 동기화, Area 경계와 장애 진단까지 Route가 만들어지는 순서대로 설명합니다.

OSPF Hello를 서로 받아도 어떤 조건이 맞아야 Neighbor가 될 수 있을까↑

OSPF가 활성화된 인터페이스는 Hello 패킷을 보내고 라우터 ID, Area, Timer 등 Neighbor 형성에 필요한 정보를 교환합니다. 중요한 Parameter가 맞지 않으면 서로의 패킷을 보더라도 정상 Neighbor가 되지 못합니다.

Neighbor를 발견했다고 모든 상대와 반드시 Full Adjacency를 만드는 것은 아닙니다. Broadcast 네트워크에서는 DR과 BDR을 중심으로 데이터베이스를 동기화해 불필요한 Adjacency 수를 줄입니다. 따라서 2-Way 상태가 항상 장애인 것은 아니며 네트워크 Type과 상대 역할을 함께 봐야 합니다.

두 라우터가 Hello를 서로 받아 Neighbor 목록에 올리려면 Area ID, 네트워크 Mask나 네트워크 Type, Hello·Dead Interval, 인증과 Stub 관련 Option 등 필요한 조건이 맞아야 합니다. 불일치 항목은 플랫폼 Log에 드러나기도 하지만 패킷 캡처의 Hello Field를 양쪽에서 비교하면 더 직접적입니다. 라우터 ID는 OSPF 도메인에서 고유해야 하며 중복되면 Neighbor와 LSA 식별이 꼬일 수 있습니다.

Broadcast 네트워크에서 DROther끼리는 서로를 2-Way로 발견해도 Full Adjacency까지 가지 않는 것이 정상입니다. 두 장비가 모두 DR·BDR이 아닌데 2-Way라고 “멈췄다”고 판단하면 불필요한 조치를 하게 됩니다. 반면 Point-to-Point 링크에서는 Full 상태가 기대될 수 있습니다. Neighbor 상태는 네트워크 Type과 상대 역할이라는 문맥 속에서 읽어야 하며, 인터페이스별 기대 상태를 설계 문서에 남겨 두는 편이 좋습니다.

Broadcast 네트워크에서는 DR/BDR 선출 때문에 모든 라우터 쌍이 Full 상태가 될 필요가 없고 일부는 2-Way 상태가 정상입니다. Point-to-Point와 NBMA는 기대 관계가 다릅니다. 따라서 상태 이름만 보고 장애라 판단하지 말고 인터페이스 네트워크 Type, 기대 Neighbor 역할과 양쪽 Hello 내용을 함께 비교합니다.

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

링크 하나가 끊겼다는 사실은 LSA를 통해 Area 전체에 어떻게 퍼질까↑

라우터와 네트워크의 연결 상태, Prefix, 외부 경로 같은 정보는 목적에 맞는 LSA로 표현됩니다. LSA에는 생성 주체와 Link-State ID, Sequence Number, Age 등이 있어 라우터가 더 새로운 정보를 구분할 수 있습니다.

새 LSA를 받은 라우터는 이웃과 인터페이스의 상태, DR·BDR 역할에 따라 필요한 곳으로 다시 플러딩합니다. 보낸 이웃에게 같은 내용을 되돌리는 것과 수신 인터페이스 전체를 제외하는 것은 다릅니다. 공유 네트워크의 DR은 같은 인터페이스의 다른 이웃에게 다시 전달할 수 있으므로, 캡처에서는 수신 이웃과 인터페이스, DR·BDR 역할을 함께 확인해야 합니다.

라우터가 링크 Down 상태를 감지하면 자신이 생성한 관련 LSA를 더 새로운 Sequence로 갱신해 Adjacency로 플러딩합니다. 이웃은 기존 LSDB Entry와 비교해 새 정보일 때 저장하고 다른 이웃에게 전달합니다. Acknowledgment와 재전송은 손실이 있어도 플러딩 신뢰성을 높입니다. Distance-Vector 방식은 목적지까지의 거리와 경로 정보를 이웃에게 광고하고, 이웃은 이를 바탕으로 자신의 Route를 계산합니다. OSPF는 이웃이 계산한 경로를 그대로 받는 대신, 각 라우터가 경로를 계산할 수 있도록 링크 상태 정보를 배포합니다.

LSA의 플러딩 Scope는 Type과 Area 경계에 따라 다릅니다. 모든 LSA가 AS 전체에 동일하게 퍼지는 것은 아니며 ABR·ASBR이 다른 형태의 정보를 생성할 수 있습니다. Age와 Sequence는 오래된 사실이 새 사실을 덮지 않게 합니다. 장애 때 라우팅 테이블만 비교하지 말고 문제 링크를 나타내는 LSA의 Advertising 라우터, Sequence와 Age를 각 LSDB에서 비교하면 정보 생성·플러딩 단계의 차이를 찾을 수 있습니다.

LSA에는 Type, Link-State ID, Advertising 라우터, Sequence, Age와 Checksum이 있어 같은 항목의 신구를 판별합니다. 모든 LSA가 모든 Area와 외부로 무제한 전파되는 것은 아니며 Type과 Area 종류에 따라 범위가 다릅니다. 장애 시에는 Prefix만 검색하지 말고 어느 LSA를 누가 생성했으며 현재 라우터 LSDB에서 어떤 Sequence·Age로 보이는지 비교합니다.

이 절의 근거 IETF RFC 2328

같은 LSDB를 받은 라우터마다 자신을 출발점으로 새 경로를 계산한다↑

LSDB가 바뀌면 라우터는 자신을 Root로 Shortest Path First 계산을 수행합니다. 링크 Cost를 더해 목적지까지의 최단 트리를 만들고, 그 결과에서 Next Hop과 출력 인터페이스를 도출합니다. 계산 결과가 라우팅 정책과 설치 조건을 통과하면 RIB에 들어가고 FIB에 반영됩니다.

LSA를 받은 시각, SPF Scheduling, CPU 부하, FIB Programming 시간 때문에 Control Plane Convergence와 실제 패킷 전달 전환 사이에는 간격이 생길 수 있습니다. 장애 감지 시간만 줄인다고 End-to-End 중단 시간이 같은 비율로 줄어드는 것은 아닙니다.

같은 LSDB를 가진 라우터라도 자신을 트리의 Root로 두므로 각 목적지의 Next Hop은 위치에 따라 다릅니다. 라우터 A는 링크 Cost 합이 20인 경로를, 라우터 B는 같은 목적지까지 다른 이웃을 선택할 수 있습니다. SPF 결과는 Prefix를 Route 후보로 만들고, 다른 프로토콜 Route와 RIB 선택을 거쳐 FIB에 설치됩니다. LSDB 동일성이 모든 라우터의 라우팅 테이블 한 줄까지 같다는 뜻은 아닙니다.

링크 변화가 퍼지는 동안 라우터마다 LSA 수신·SPF 실행·FIB Programming 시각이 조금씩 다르면 짧은 Microloop나 Blackhole이 생길 수 있습니다. SPF Throttle, LSA Pacing과 Fast Reroute 같은 기능은 이 시간을 조절하지만 기본값과 효과는 구현별입니다. Convergence를 측정할 때 Neighbor 상실 시각 하나만 보지 말고 새 LSA 생성, 원격 수신, SPF 완료, FIB 변경과 End-to-End 패킷 복구를 나눠야 합니다.

LSDB에 Prefix가 있다는 사실은 RIB 설치를 보장하지 않습니다. 더 선호하는 Static/Connected Route가 있거나, 재귀 Next Hop이 해석되지 않거나, 다른 OSPF Path가 선택될 수 있습니다. SPF 실행 시각과 결과, RIB 경쟁 Route, FIB와 Adjacency를 이어 보아 토폴로지 인식과 실제 전달의 차이를 확인합니다. 동일 비용 경로가 몇 개까지 설치되는지도 설정값과 대조합니다.

이 절의 근거 IETF RFC 2328

용어사전↑