이걸 망가뜨리면 어떻게 될까?

이 시리즈의 첫 여덟 편은 모델을 제대로 만드는 일에 관한 것이었습니다. 네트워크의 일부가 되지 않으면서 네트워크를 발견하고, 포워딩을 홉 단위로 재현하고, 추측하기를 거부하고, 제 도구가 허구를 그려 왔다는 사실을 어렵게 알아내는 일 말입니다.

그 모두가 준비 과정입니다. 그저 정확하기만 한 네트워크 모델은 아주 비싼 사진입니다. 그 수고를 들이는 이유는, 실제 네트워크에는 던질 수 없는 질문을 모델에는 던질 수 있게 하기 위해서입니다.

이걸 망가뜨리면 어떻게 될까?

이 질문이 유지보수 창을 결정합니다. 새벽 3시에 카드를 뽑아도 버틸 수 있는지를 누군가는 말해야 하고, 보통은 머릿속 모델과 지난번 장애의 기억으로 답합니다. 이제부터 나오는 이야기가 흥미로운 이유는 Osprey에 시뮬레이터가 있어서가 아닙니다. 장애가 실제로 일어나기 전에 그 장애를 두고 추론할 수 있게 되기 때문입니다.

---

바꿀 수 있는 일곱 가지

Osprey의 시뮬레이션 모드는 라이브 모델을 가져와 복제하고, 변형을 적용하고, 다시 계산합니다. 바꿀 수 있게 허용된 목록은 짧고, 그 짧음은 의도된 것입니다.

변형	하는 일
link_failure	링크를 내립니다
node_failure	라우터를 내립니다
cost_change	링크의 메트릭을 바꿉니다. 정방향과 역방향이 각각 독립적입니다
hypothetical_link	존재하지 않는 링크를 코스트와 속도와 함께 추가합니다
hypothetical_node	존재하지 않는 라우터를 추가합니다
srlg	공유 위험 그룹을 내립니다. 한 번의 조작으로 상관된 링크 N개가 함께
peer_failure	BGP 세션을 끊습니다

그 밖의 것은 전부 unknown mutation type으로 거부됩니다. 영역 재구성 변형도, 재분배 변형도, 연쇄 장애 변형도 없습니다. 어느 것도 데이터를 지어내지 않고는 구현할 수 없었기 때문입니다. 이 이야기는 뒤에서 다시 하겠습니다.

---

케이블 하나, 그리고 네트워크가 그것에 대해 하는 일

랩의 실제 사례입니다. nrt1-cr1 ↔ sea1-cr1은 AS 200의 태평양 횡단 백본 링크이고, OSPFv2 기준 코스트는 10이며, Osprey가 이 테넌트의 OSPF 인스턴스 두 개에 걸쳐 보유한 링크 275개 중 하나입니다. 오른쪽 클릭해서 Simulate Failure를 골랐습니다.

맨 위 세 숫자를 읽어 보십시오. 도달 불가가 된 것은 없음. 경로 56개 변경. 새로운 단일 장애점은 없음. 전체 평가는 서버 쪽에서 57밀리초가 걸렸습니다.

이제 Failed Links 헤더를 보십시오. 사람들이 놓치는 일이 여기서 벌어집니다. 2 links입니다. 저는 케이블 하나를 클릭했는데 Osprey는 링크 두 개를 내렸습니다. 그 케이블이 OSPFv2와 OSPFv3을 서로 독립적인 두 프로토콜 인스턴스로, 서로 독립적인 두 코스트와 함께 나르기 때문입니다. 선을 죽이면 양쪽에서 죽습니다. 케이블 하나당 엣지 하나를 모델링하는 도구는 그 두 목숨 중 어느 쪽을 끝낼지 정해야 합니다.

흥미로운 것은 그 56개의 내역입니다.

• 15개 증가: 경로가 비싸졌습니다. sea1-cr1 → nrt1-cr1은 코스트 1에서 코스트 11로 가고, 직결 링크가 세 홉짜리 경로로 바뀝니다.
• 41개 우회: 경로의 홉이 바뀌었고 코스트는 전혀 움직이지 않았습니다.

두 번째 숫자가 오래 들여다볼 만한 것입니다. 마흔두 개의 출발지/목적지 쌍이 네트워크 안에서 다른 길로 갔고, 그 대가로 아무것도 치르지 않았습니다. 등가 코스트 대안이 이미 거기 있었기 때문입니다. 이중화를 형용사가 아니라 측정값으로 표현하면 이렇게 보입니다. “우리는 다중 경로를 갖고 있습니다”는 주장입니다. “영향을 받은 56쌍 중 41쌍이 동일 코스트로 우회한다”는 숫자이고, 정비 시간을 새벽 3시로 잡아야 하는지를 알려 주는 것은 그 숫자입니다.

여기서 라우터에 타이핑된 것은 하나도 없습니다. 랩이 링크를 잃지도 않았습니다. 저는 모델에게 물었습니다.

---

화면 맨 위의 거부

이제 첫 번째 스크린샷의 호박색 배너를 보십시오. 그것은 하나의 고백이고, 제가 패널의 나머지를 믿는 이유입니다.

simulated paths are shown as an SPF projection (source-rooted least-cost tree) so before and after stay comparable; the live path panel shows the hop-by-hop forwarding chain, which can differ where an intermediate router’s own routing table disagrees with the source’s view

세 번째 글은 출발지를 뿌리로 하는 통로가 IP 포워딩의 잘못된 모델이라는 논증이었고, 측정이 그것을 뒷받침했습니다. 영역 간 라우터 쌍 2,839개 중 360개에서, 통로가 어떤 패킷도 타지 않을 홉을 담고 있었습니다. 저는 그 엔진을 각 라우터 자신의 라우팅 테이블을 따라가는 것으로 바꾸고, 4,032쌍 전부에 대해 검증했습니다.

그러고 나서 시뮬레이션에서는 의도적으로 그것을 쓰지 않습니다.

이유는 코드에 있고, 이 제품에서 제가 가장 자랑스러워하는 문장입니다.

// The panel shows the hop-by-hop forwarding chain (path_chain.go): every
// router's OWN routing table, read from the per-area LSDBs. A what-if topology
// has no such tables. The Type-3 summaries the surviving ABRs would
// re-originate after the mutation are exactly the thing that cannot be
// synthesised, and inventing them would make the simulation's numbers agree with
// nothing. So both simulation sides stay on the source-rooted SPF projection,
// consistently with each other, and say so. A labelled projection is honest; a
// baseline that disagrees with the baseline is not.

각 라우터 자신의 테이블을 따라가려면 변경 이후 각 라우터의 테이블이 어떻게 될지를 알아야 합니다. OSPF에서 그것은 살아남은 ABR들이 다시 생성할 Type-3 summary-LSA에 달려 있습니다. 장애가 아직 일어나지 않았으므로 그 LSA는 존재하지 않습니다. 저는 그것을 추측할 수 있습니다. 정확하게 추측할 수는 없습니다. 그리고 추측한 summary 위에 세운 홉 바이 홉 체인은 검증된 엔진의 권위를 전부 두르고 검증은 하나도 없는 물건이 됩니다.

그래서 비교의 양쪽 모두 분명히 라벨이 붙은 투영에 머무릅니다. “이전” 그림은 “이후” 그림과 계속 맞물리도록 일부러 정밀도를 낮춰 둔 것입니다. “경로 56개 변경”이 사실은 “진짜 변경 36개 더하기, 양쪽이 다른 엔진을 쓴 탓에 생긴 허상 20개”라면 그것은 diff가 아닙니다. 숫자가 붙은 잡음입니다.

---

EIGRP: 천장은 프로토콜이 아니라 제 데이터입니다

EIGRP 테넌트에서 무언가를 망가뜨리면 Osprey는 투영하는 대신 멈춥니다.

the simulated change affects the observed EIGRP chain (forward and reverse). Osprey cannot predict DUAL re-convergence: the topology tables it reads carry the DUAL distances, not the metric components (bandwidth, delay) a recomputation needs. After a real event the live view shows the new chain.

EIGRP에는 다시 계산할 근거가 될 링크 상태 데이터베이스가 없습니다. Osprey가 가진 것은 CISCO-EIGRP-MIB에서 읽은 각 라우터 자신의 토폴로지 테이블이고, 그 열두 개 열이 담고 있는 것은 DUAL의 거리(feasible distance, computed distance, reported distance)이지, 그 거리들이 만들어진 구성 요소가 아닙니다.

변경 이후 DUAL을 다시 계산하려면 최소 대역폭, 총 지연, 신뢰도, 부하, MTU, 홉 수가 필요합니다. 그것들은 장비에는 존재합니다. e-ams1-cr1에서 show ip eigrp topology 10.64.0.0/15로 확인했습니다. 그저 Osprey가 읽는 MIB 테이블에 없을 뿐입니다.

그 구분은 일부러 코드 주석에 적어 두었습니다.

// Scoped to what Osprey READS, deliberately not to what SNMP can carry: … A future
// CLI enricher could lift part of this ceiling, so the sentence must not read as a
// permanent property of the protocol.

*“이 프로토콜은 시뮬레이션할 수 없다”*와 “지금은 그 입력을 수집하지 않는다” 사이에는 실질적인 차이가 있고, 둘을 흐리는 제품은 다시 물어볼 필요 없다고 조용히 말하는 셈입니다. 이것은 데이터 수집의 천장이고, 들어 올릴 수 있습니다. 제가 들어 올리면 이 메시지는 사라집니다.

그 아래에는 더 작고 더 날카로운 규칙이 하나 있습니다. 변형이 순수한 제거(링크나 노드 장애)이고, 제거된 대상이 관측된 체인 위에 없음을 증명할 수 있다면, Osprey는 실제 체인을 계속 보여 주고 그 이유를 말합니다. “observed live EIGRP chain: the simulated failure does not touch it (EIGRP re-convergence itself is not modelled)”. 어딘가 다른 곳에서 용량을 없앤다고 해서, 그것을 쓰지 않던 디스턴스 벡터 경로가 좋아지는 일은 결코 없습니다. 그러나 코스트 변경이나 새 링크는 어디에서든 경로를 끌어올 수 있으므로, 그런 것들은 항상 “건드림”으로 셉니다. 이 엔진은 거부해야 할 때 정확히 거부하는 것이지, 뭉뚱그려 거부하지 않습니다.

---

변형 목록에 없는 것들, 그리고 그 이유

일곱 가지 변형은 입력을 지어내지 않고 구현할 수 있었던 것들입니다. 빠진 것들은 명시된 이유로 빠져 있습니다.

• 영역 재구성. ABR을 옮기거나 영역 경계를 다시 긋는 일은 애초에 어떤 summary-LSA가 존재하는지를 바꿉니다. 그것은 토폴로지의 변형이 아니라 다른 토폴로지입니다.
• 재분배 변경. 이것들은 Osprey가 전혀 볼 수 없는 route-map과 prefix-list에 달려 있습니다. 읽을 수 없는 정책을 모델링하는 셈이 됩니다.
• 연쇄 장애. 두 번째 장애를 예측하려면 큐와 TCP 동역학이 필요한데, 토폴로지 도구가 그것을 모델링한다고 주장할 자격은 없습니다. 위험을 표시할 것. 연쇄를 예측하지 말 것.

이들 각각은 시연에서 근사하게 보였을 것입니다. 각각이 뒤에 아무것도 없는 숫자였을 것입니다.

---

핵심

시뮬레이션은 토폴로지 제품이 모델링에 들인 노력을 회수하거나 밑천을 드러내는 자리입니다. 데이터 모델에서 질러 간 지름길은 전부 여기서 자신만만한 오답으로 나타납니다. what-if에는 대조할 기준 진실이 없기 때문입니다. 장애는 아직 일어나지 않았으므로 아무것도 당신을 반박할 수 없습니다. 바로 그래서 이것이 가장 조심할 가치가 있는 기능입니다.

정직한 버전은 스크린샷 한 장당 덜 인상적이고 새벽 3시에는 훨씬 더 쓸모 있습니다. 바꿀 수 있는 일곱 가지, 나오는 네 개의 숫자, 그리고 그것들을 어느 엔진이 만들었는지 설명하는 배너.

---

다음 글: 링크 하나가 죽었다. 그런데 네트워크의 어느 부분이 실제로 그것에 의존하고 있었을까? 영향 반경.