IGP 세 개, 지도 하나

라우터 192대, 통신사 3곳, 라우팅 프로토콜 3종이 단일 화면에서 어떻게 보이는가

2026년 8월 10일 Michel Wijnberg

저에게는 랩이 하나 있습니다. 도면도 아니고 시뮬레이터도 아닙니다. 실제 프로토콜 스택이 도는 진짜 라우터 192대이며, 저에게 제대로 반박할 수 있는 상대를 두고 Osprey를 만들기 위해 매일 이 랩을 씁니다.

이 랩은 일부러 까다롭게 만들었습니다. 서로 아무것도 공유하지 않는 통신사 세 곳이 들어 있습니다.

테넌트	ASN	IGP	형태
Harrier-Broadband	200	OSPFv2 와 OSPFv3	프로토콜마다 영역 15개, 같은 회선 위에서 듀얼 스택
Kestrel-Dynamics	100	EIGRP, IPv4 + IPv6	평면 구조. EIGRP에는 영역이 없기 때문입니다
Merlin-Carrier	300	IS-IS, 멀티 AF	level-2 백본 아래에 level-1 영역 17개

프로토콜 세 종, 주소 설계 세 벌, ASN 세 개, 자격 증명 세 세트. 공유되는 IGP는 어디에도 없습니다. 토폴로지 도구에 들이밀 수 있는 거의 최악의 사례이고, 바로 그래서 이 랩을 만들었습니다.

Osprey 대시보드: 테넌트 네트워크 3개, 장비 192대, 링크 441개, 영역 50개

아래에 나오는 것은 모두 이 글을 쓰면서 실시간으로 찍은 그 랩의 스크린샷입니다. 연출한 것은 하나도 없습니다.

그림보다 계층이 먼저인 이유

대부분의 토폴로지 도구는 캔버스에서 출발해 구조를 나중에 덧붙입니다. 그 방식은 같은 물리 라우터가 서로 다른 두 답에 동시에, 그것도 정당하게 속하기 전까지는 잘 굴러갑니다. 통신사 네트워크에서는 그런 일이 일상입니다.

Osprey는 순서를 뒤집었습니다. 모든 객체는 명시적인 계층에 매달립니다.

Network → Autonomous System → Routing Domain → Protocol Instance → Area → Device

이 사슬은 장식이 아닙니다. “어느 OSPF 프로세스인지, 어느 VRF 안인지, 어느 AS 아래인지, 어느 테넌트에 속하는지”를 추측 없이 답할 수 있게 해 주는 것이 바로 이 사슬이며, 한 장비가 어떤 인스턴스에서는 ABR이고 다른 인스턴스에서는 평범한 내부 라우터일 수 있는데도 모델이 스스로 꼬이지 않는 이유이기도 합니다.

계층 사이드바: OSPF 1과 OSPFv3 1이 나란히, 각각 자기 영역 15개를 거느린 모습

사이드바가 무엇을 보여 주는지 눈여겨보십시오. OSPF 1과 **OSPFv3 1 (v6)**은 서로 다른 프로토콜 인스턴스이며, 각각 자기 영역 15개, 자기 LSDB, 자기 SPF를 가집니다. 둘은 같은 물리 링크 위를 흐릅니다. 그럼에도 하나의 낙관적인 “IGP” 추상으로 합쳐지지 않았습니다. 실제로 같은 것이 아니기 때문입니다. RFC 5340은 OSPFv3에 고유한 LSDB와 고유한 토폴로지를 부여하며, 그렇지 않은 척하면 둘이 어긋나는 순간 틀린 답이 나옵니다.

Harrier-Broadband: OSPF, 영역 15개, 듀얼 스택

영역별로 색을 입힌 AS 200입니다.

Harrier-Broadband: 라우터 64대, 링크 151개, 영역 30개, OSPF 영역별 색상

라우터 64대, 링크 151개, 영역 30개(OSPFv2에 15개, OSPFv3에 15개). 가운데 파란 덩어리가 영역 0.0.0.0, 즉 백본입니다. 거기에 매달린 색색의 덩어리는 모두 자기 ABR을 거쳐 백본에 닿는 비백본 영역입니다.

이 정도 규모에서는 그림이 아직 읽힙니다. 다섯 배 규모라면 읽히지 않습니다. 그래서 같은 토폴로지를 영역 단위로 접을 수 있게 했습니다.

영역 클라우드 개요: 백본을 둘러싼 15개 영역이 구름으로 표시되고 링크 묶음 개수가 함께 표시됨

구름 하나가 영역 하나이고, 선 하나는 영역 간 인접의 묶음이며 그 위에 개수(4×, 8×, 2×)가 붙습니다. “영역 19.5.1.0은 백본에 얼마나 부실하게 붙어 있는가”에 답할 때 제가 실제로 쓰는 뷰가 이것입니다. 여기서의 답은 “링크 네 개로”이고, 이는 바로 옆에 있는 링크 두 개짜리 영역들과는 위험 프로필이 아주 다릅니다.

Merlin-Carrier: IS-IS, 그리고 주소 패밀리는 정말로 중요합니다

AS 300은 IS-IS로 돕니다. 물리적 형태는 같고, 프로토콜 모델은 완전히 다릅니다.

Merlin-Carrier: IS-IS 아래 라우터 64대, level-1 영역 17개와 level-2 백본

IS-IS는 많은 도구가 소리 없이 무너지는 지점입니다. IS-IS는 “말만 바꾼 OSPF”가 아니기 때문입니다. IS-IS LSDB 하나가 CLNS, IPv4, IPv6의 도달성을 동시에 실어 나를 수 있고, 올바른 최단 경로는 주소 패밀리마다 달라집니다.

그래서 Osprey는 주소 패밀리별로 계산하고, 지금 보고 있는 것이 어느 쪽인지 알려 줍니다.

주소 패밀리 선택기를 CLNS로 둔 IS-IS 경로. System ID와 서킷이 표시됨

홉 표를 보십시오. 주소 패밀리가 CLNS이기 때문에 각 홉은 System ID(0100.6600.8003)와 서킷으로 식별됩니다. IPv4 주소가 아닙니다. CLNS 경로에서 IPv4 주소는 아무 의미가 없기 때문입니다. 선택기를 IPv4나 IPv6으로 바꾸면 같은 경로가 그 패밀리가 실제로 쓰는 주소 체계로 다시 그려집니다.

(저 스크린샷은 IS-IS에서의 홉 바이 홉 모델링에 대한 고백이기도 합니다. 그것은 뒤에 나올 글의 주제이며, 여기에 묻어 두고 넘어갈 생각은 없습니다.)

Kestrel-Dynamics: 링크 상태 데이터베이스가 아예 없는 EIGRP

그리고 AS 100이 있습니다.

Kestrel-Dynamics: EIGRP 아래 라우터 64대. EIGRP에는 영역이 없어 색은 하나

색 하나. “영역” 둘. 렌더링 버그가 아닙니다. EIGRP가 자기 자신에 대해 정직한 것입니다.

EIGRP는 디스턴스 벡터 프로토콜이라 이어 붙일 링크 상태 데이터베이스도 없고 색을 입힐 영역 개념도 없습니다. 항목 두 개는 그저 IPv4와 IPv6 인스턴스입니다. EIGRP는 자체 Hello 프로토콜로 네이버 인접을 분명히 맺지만, 그 뒤에 훑을 링크 상태 데이터베이스도, 돌릴 SPF도 없습니다. 네이버끼리 주고받는 것은 거리 벡터이지 동기화된 지도가 아닙니다. 그래서 Osprey는 CISCO-EIGRP-MIB에서 읽기 전용으로 읽어 들이고, 각 라우터가 자기 네이버에 대해 보고하는 내용으로 인접 그래프를 재구성합니다. 이 랩에서는 살아 있는 네이버 관계 580개입니다.

이 차이는 경로 계산까지 그대로 이어지고, 눈에도 보입니다.

저 경로에는 “총 코스트”가 없고, 애초에 있을 수도 없었습니다. EIGRP의 복합 메트릭은 홉 하나가 아니라 경로 전체를 기술하므로, 홉별 코스트를 더하면 아무 의미도 없는 숫자가 나옵니다. 대신 얻는 것은 각 라우터가 목적지까지 스스로 계산한 현재 거리가 사슬을 따라 줄어드는 모습입니다. 712704 → 710144 → 658944 → … → 128256. 라우터에 한 대씩 들어가 읽었을 때 나오는 값 그대로입니다. (DUAL의 Feasible Distance는 이와 미묘하게 다른 값입니다. 해당 경로가 마지막으로 passive 상태가 된 이후의 최솟값, 즉 실현 가능성 임계값입니다. 홉 표는 둘을 구분해서 다루며, 한쪽을 다른 쪽으로 이름 붙이지 않습니다.)

프로토콜 세 종, 진짜로 서로 다른 모델 세 개, 올바른 답 세 개. 셋이 같은 것인 척하는 추상이 아닙니다.

그림 아래: LSDB 그 자체

캔버스는 표현일 뿐입니다. 그 밑에 있는 모델은 링크 상태 데이터베이스이고, Osprey는 그것을 계속 열람할 수 있게 유지합니다.

LSDB 브라우저: 재구성된 LSA 13,382건을 LSA 타입별로 분류

LSA 13,382건을 타입별로 분류했습니다. Router (1), Network (2), Summary (3), ASBR (4), External (5), NSSA (7). ABR과 ASBR 플래그는 명명 규칙이 아니라 LSA 자체에서 끌어냈습니다.

제목 아래 줄을 주의 깊게 읽어 보십시오.

13382 LSAs reconstructed (LSAge, SeqNo, Checksum not available)

이 LSA들은 프로토콜 인접을 통해 수신한 것이 아니라 SNMP 워크에서 재구성한 것입니다. OSPF MIB를 SNMP로 워크하면 LSA의 내용은 얻지만 실시간 헤더 필드는 얻지 못합니다. 그래서 Osprey는 내용을 보여 주면서, 데이터처럼 보이는 0의 열 세 개를 그리는 대신 세 필드가 없다고 그대로 밝힙니다.

작은 일입니다. 동시에 설계 철학 전체가 한 줄에 담긴 것이기도 하고, 그 화면에 있는 나머지 13,382개의 숫자를 제가 믿는 이유이기도 합니다.

핵심

지도는 제품이 아닙니다. 모델이 제품입니다.

프로토콜도, 주소 설계도, ASN도 공유하지 않는 통신사 세 곳이 어느 하나도 최소 공통분모로 납작해지지 않은 채 한 도구 안에 함께 있습니다. OSPF는 자기 영역과 두 개의 LSDB를, IS-IS는 자기 레벨과 주소 패밀리를, EIGRP는 자기 DUAL 거리와 링크 상태 데이터베이스가 아예 없다는 사실을 그대로 유지합니다.

정말로 다른 곳에서는 제품도 다르게 굽니다. 알 수 없는 것은 알 수 없다고 말합니다.

Osprey는 수동적입니다. 라우터에 에이전트를 넣지 않고, 경로를 주입하지 않으며, 패킷을 포워딩하지 않습니다. 그것이 실제로 어떻게 동작하고 무엇을 대가로 치르는지는 다음 글에서 다룹니다.