제로 풋프린트
Osprey가 네트워크의 일부가 되지 않으면서 네트워크를 보는 방법
Michel Wijnberg
세상의 모든 모니터링 제품이 “에이전트리스”를 표방합니다. 그중 대부분이 뜻하는 바는
SSH로 들어가 show 출력을 화면 스크래핑한다는 것인데, 그것은 도둑이 손님인 것과 같은
의미에서만 에이전트리스입니다.
Osprey는 다른 길을 택했고, 저는 그 점을 정확히 말하고 싶습니다. 마케팅 문구가 온전히 사실은 아닌 부분까지 포함해서 말입니다.
Osprey가 데이터를 얻는 방법은 세 가지입니다. 셋 다 들여다보는 운영자에게는 보입니다(이 제품은 스텔스 제품이 아닙니다). 그러나 그중 Osprey를 라우팅 프로토콜 자신의 데이터베이스 안에 집어넣는 것은 하나뿐이고, 따져 볼 가치가 있는 것도 그 하나입니다.
1. GRE 레코더: 트래픽을 절대 실어 나를 수 없는 진짜 인접
가장 흥미로운 방법입니다. Osprey는 GRE 터널 위에서 진짜 IGP 인접을 맺을 수 있습니다. 진짜 Hello, 진짜 DBD 교환, 진짜 플러딩이 오가는 실제 OSPFv2, OSPFv3, IS-IS 네이버 관계입니다. 라우터가 LSDB를 배우는 방식 그대로, 즉 남이 알려 주는 방식으로 LSDB를 배웁니다.
이것은 MIB를 워크하는 것보다 엄밀히 낫습니다. 프로토콜이 실제로 배포하는 그대로의 데이터베이스를 시퀀스 번호, 에이지, 체크섬이 온전한 채로 얻고, 변경은 다음 폴링 주기가 아니라 플러딩되는 그 순간에 보이기 때문입니다.
동시에 이것은 라우터들이 네이버를 실제로 본다는 뜻이기도 합니다. 분명히 말씀드리면, Osprey는 LSDB에 나타납니다. 나타날 수밖에 없습니다. RFC 2328 §12.4.1은 영역 안의 모든 라우터가 Type 1 Router-LSA를 생성하도록 요구하며, 인접을 맺으면서 Router-LSA를 생성하지 않는 라우터는 고장 난 라우터입니다.
그러므로 질문은 “보이지 않을 수 있는가”가 아니라(그럴 수 없습니다) “포워딩에 영향을 줄 수 없는 상태가 될 수 있는가”입니다. 여기에는 진짜 답이 있습니다.
// originateRouterLSA creates and installs our Router-LSA in the LSDB.
// RFC 2328 Section 12.4.1 requires every router to originate a Type 1 LSA.
// We use cost 65535 (maximum) so no router will ever route traffic through
// Osprey. Only the P2P link is advertised. NO stub network for the tunnel
// inner subnet. Advertising the tunnel subnet (even at max cost) causes SPF
// on other routers to install a route for the tunnel prefix, which can
// disrupt the GRE outer path and kill the adjacency.여기에는 의도된 결정이 두 개 들어 있고, 두 번째 결정은 랩을 한 번 죽여 보고 나서야 제대로 배웠습니다.
최대 메트릭. 레코더는 자기 유일한 점대점 링크를 코스트 65535로 광고하는데, 이것은 두 보장 가운데 약한 쪽입니다. 메트릭은 경로를 매력 없게 만들 뿐이고, 매력 없는 경로도 그것 하나뿐이면 결국 선택됩니다. 진짜 보장은 형태에 있습니다. 레코더는 인접이 정확히 하나뿐이라 그래프에서 잎 노드이고, 잎을 통과하는 경로란 어떤 SPF도 찾아낼 수 없습니다. 게다가 자기 프리픽스를 하나도 광고하지 않으니 그쪽으로 향해 라우팅할 대상도 없습니다. 최대 메트릭은 이미 트랜짓을 실어 나를 수 없는 구조 위에 덧댄 이중 안전장치입니다.
스텁 네트워크 광고 없음. 레코더는 P2P 링크만 광고하고 그 외에는 아무것도 광고하지 않습니다. 특히 터널의 내부 서브넷을 스텁 네트워크로 광고하지 않습니다. 이 부분이 미묘합니다. 만약 광고한다면 영역 안의 모든 라우터가 터널 프리픽스로 향하는 경로를 설치합니다. 그 경로는 GRE 터널 자신이 타고 있는 언더레이 경로를 덮어쓸 수 있고, 그러면 외부 전송이 깨지고, 인접이 죽고, 레코더가 떨어집니다. 아름답도록 자업자득인 플랩입니다. 도달 가능한 무엇도 광고하지 않으면 이 부류의 문제가 통째로 사라지고, 그러면서도 RFC 2328은 그대로 만족합니다.
IS-IS 버전은 더 엄격합니다
IS-IS에는 바로 이런 목적을 위한 전용 메커니즘이 있어서, IS-IS 레코더는 그것을 씁니다. 스스로 생성하는 LSP가 다음과 같은 단단한 불변식들을 지고 있습니다.
| 불변식 | 이유 |
|---|---|
| OL 비트 = 1 | 오버로드 비트. ISO 10589은 다른 모든 라우터가 오버로드 상태의 라우터를 비트랜짓으로 취급하도록 의무화합니다. 메트릭 잔재주가 아니라 일차 보장입니다. |
| ATT 비트 = 0000 | L1 디폴트 경로를 절대 끌어당기지 않습니다. L1 전용 라우터가 디폴트를 Osprey로 향하게 해서는 안 됩니다. |
| P 비트 = 0 | 파티션 복구 없음. |
| TLV 22 메트릭 = 0xFFFFFF | 최대 와이드 메트릭. OL 비트와 함께 가는 이중 안전장치입니다. |
| TLV 128 / 130 / 135 / 236 없음 | IP 도달성 TLV들입니다. 하나라도 내보내면 경로를 주입하게 됩니다. |
| TLV 134 없음 | TE Router ID 없음. 내보내면 Osprey가 트래픽 엔지니어링 데이터베이스에 끼어듭니다. |
| TLV 222 / 242 없음 | 멀티토폴로지 없음, 라우터 케이퍼빌리티 및 세그먼트 라우팅 없음. |
저 표는 설정 목록이 아니라 코드가 할 수 없는 일의 목록으로 읽어 주십시오. 오버로드 비트를 끄는 설정 옵션은 존재하지 않고, IP 도달성 TLV를 조립하는 코드 경로도 존재하지 않습니다. 프리픽스를 절대 광고하지 않음을 보장하는 가장 안전한 방법은 광고 기능을 아예 구현하지 않는 것이기 때문입니다.
그러니까 보이고, 참여하며, 구조적으로 패킷 하나 끌어당길 수 없습니다. 이것은 “보이지 않는다”보다 훨씬 강한 주장이며, “보이지 않는다”와 달리 사실입니다.
2. SNMP: 지루한 방식으로 얻는 LSDB, 그리고 LSDB가 담지 않는 모든 것
모든 장비가 인접을 내주지는 않고, 애초에 링크 상태 데이터베이스에 없는 것들도 있습니다. 그래서 Osprey는 폴링도 합니다.
이 랩에는 타깃이 192개이고 전부 초록색이며, 300초 주기로 폴링하고, 마지막 폴링은 초 단위로 표시됩니다.
자격 증명 열에는 ***가 보입니다. 그 가림이 어디에서 일어나는지는 정확히 말할 가치가
있습니다. 브라우저가 아니라 API 핸들러 안입니다. 자격 증명은 AES-256-GCM으로 암호화되어
저장되고, 모든 읽기 경로는 직렬화 전에 응답을 마스크에 통과시킵니다. 프런트엔드는 애초에
커뮤니티 문자열이나 v3 auth/priv 비밀번호를 받지 않으므로 “표시” 버튼이 없고, 서버를 고치지
않는 한 있을 수도 없습니다.
클라이언트에서 가리는 것은 연출입니다. 핸들러에서 가리는 것은 통제입니다.
여기서 SNMP는 네 가지 일을 합니다.
- LSDB 재구성. 레코더가 붙어 있지 않은 곳에서 씁니다(이전 글의 LSA 13,382건이 이렇게 나왔고, 빠진 헤더 필드는 정직하게 명시했습니다)
- 인터페이스 카운터. 트래픽, 오류, 사용률용입니다
- EIGRP. 합류할 데이터베이스가 아예 없어 전부
CISCO-EIGRP-MIB에서 읽습니다 - L2 네이버. LLDP와 CDP를 통해 얻습니다
마지막 항목은 들리는 것보다 중요합니다.
L2 인접 303개, 고유 원격 장비 66대. AS 간 BGP 세션이 실제로 어느 물리 포트를 지나가는지를
“이 두 라우터 사이의 어떤 링크”라고 얼버무리지 않고 말할 수 있게 해 주는 것이 바로 이
계층입니다. 그런 AS 간 링크 하나가 표 안에 그대로 보입니다. ams1-gw1 Et1/1에서
e-ams1-gw1로 가는 CDP 항목, 그것이 AS 200 ↔ AS 100 경계입니다.
3. BMP: 라우터가 말하게 두기
BGP에서는 선호하는 길이 묻는 것이 아니라 듣는 것입니다.
BMP(RFC 7854)는 라우터가 자기 Adj-RIB-In, 즉 피어들이 자기에게 광고해 온 경로들을 평범한 TCP
세션으로 모니터링 스테이션에 밀어 보내는 프로토콜입니다. 폴링 루프도 없고, show ip bgp
파싱도 없으며, 세션 자체를 넘어서는 질의 부하를 컨트롤 플레인에 주지도 않습니다. 무엇을 언제
보낼지는 라우터가 정합니다.
여기서는 피어 57개에 걸쳐 378개 세션이 있지만, 전부 같은 경로로 들어온 것은 아니며 그 구분은 뭉개지지 않고 기록됩니다.
이 랩에서 여섯 대의 라우터가 BMP 익스포터이고(ams1-gw1, jfk1-gw1, e-ams1-gw1,
e-sin1-gw1, i-jfk1-gw1, i-sin1-gw1), 이들이 24개 세션을 차지합니다. 랩 안의 모든
eBGP 세션이 여기 포함됩니다. 나머지 354개는 BMP를 아예 내보내지 않는 라우터에서 BGP4-MIB를
SNMP로 워크해 얻은 것입니다.
데이터에 이르는 두 경로 모두 정당하고 둘 다 가질 가치가 있습니다. 다만 똑같이 좋지는 않습니다. BMP 피드는 피어가 광고한 모든 경로를, 라우터가 본 그대로의 Peer Up과 Peer Down과 함께 실어 옵니다. SNMP 워크는 폴링 시점의 세션 표를 줄 뿐, 폴링 사이의 일은 아무것도 주지 않습니다. 여기서 어느 RIB가 문제인가 하면, RFC 7854가 관측하는 것은 Adj-RIB-In, 즉 이 라우터가 무엇을 고르기 전에 도착한 것입니다. 라우터가 스스로 선택한 표인 Loc-RIB는 나중에 나온 별개의 확장(RFC 9069)이고 이 익스포터들은 그것을 보내지 않습니다. 따라서 그 후보들에 대한 베스트 패스 선택은 Osprey의 계산이며, 그렇게 표시됩니다.
그래서 모든 행이 어디에서 왔는지 기록하는 source 열을 달고 있고, 그 값은 스택 위쪽에서 하중을
받습니다. Osprey가 나중에 AS를 가로지르는 경로를 이어 붙이면서 도메인 간 홉을 정당화해야 할 때,
eBGP 세션은 출처를 달고(bmp-peer냐 snmp-peer냐) 근거로 계산되지, 결코 익명의 사실로 쓰이지
않습니다. 같은 표이되 등급이 매겨진 표입니다.
두 주소 패밀리는 익스포터당 하나의 BMP 세션에 함께 실려 옵니다. IPv4와 IPv6 행이 같은 보고 라우터를 공유하는 이유가 그것입니다.
저 표에서 흥미로운 것은 eBGP 행들입니다. 세 테넌트 사이의 이음매이기 때문입니다.
| 출발 | AS | 도착 | AS |
|---|---|---|---|
e-ams1-gw1 | 100 | ams1-gw1 | 200 |
i-sin1-gw1 | 300 | e-sin1-gw1 | 100 |
i-jfk1-gw1 | 300 | jfk1-gw1 | 200 |
삼각형입니다. 암스테르담에서 AS 200 ↔ AS 100, 싱가포르에서 AS 100 ↔ AS 300, 뉴욕에서 AS 200 ↔ AS 300. 세션 여섯 개, 두 패밀리를 합쳐 열두 행. 도메인을 가로지르는 경로 이어 붙이기를 애초에 가능하게 만드는 것이 이 삼각형이고, 그것이 세 번째 글의 주제입니다.
Osprey가 구조적으로 할 수 없는 일
어떤 제약은 기능이 아니라 제약으로 말해 두는 편이 낫습니다. 나머지를 믿을 수 있게 만드는 것이 바로 그 제약들이기 때문입니다.
- 경로 주입 없음. 레코더는 최대 코스트 P2P 링크 하나만을 기술하는 Router-LSA를 정확히 하나 생성하고, 그 외에는 아무것도 하지 않습니다. 프리픽스를 광고하는 코드 경로 자체가 없습니다.
- 패킷 포워딩 없음. Osprey는 데이터 플레인에 없습니다. 포워딩 테이블도 FIB도 없고, 잘못 프로그래밍할 대상 자체가 없습니다.
- 설정 쓰기 없음. UI의 SSH 터미널은 터미널입니다. 키를 두드리는 것은 사용자이고, 세션은 감사를 위해 기록되며, Osprey 자신이 설정 명령을 내리는 일은 없습니다.
- 단방향 데이터 흐름. 수집기와 BMP가 데이터를 받아 NATS에 발행하고, 엔진이 PostgreSQL에 영속화하며, API가 프런트엔드에 제공합니다. 상류로 되돌아 호출하는 서비스는 없습니다. 사람이 터미널에 타이핑하는 것 말고는 웹 UI에서 라우터로 가는 경로가 존재하지 않습니다.
정직한 요약
Osprey는 중요한 의미에서 수동적입니다. 트래픽을 끌어당길 수 없고, 경로를 주입할 수 없으며,
패킷을 포워딩할 수 없습니다. 하지만 보이지 않는 것은 아닙니다. 예상보다 한 줄 더 나온
show ip ospf neighbor에서 알아차리게 하느니, 제가 먼저 말씀드리는 편이 낫습니다.
어떤 벤더가 자기네 도구는 당신의 IGP에 합류하면서도 아무도 알아챌 수 없다고 말한다면, 그 Router-LSA가 어떻게 생겼는지 물어보십시오.
다음 글: 당신의 경로 도구가 아마도 당신에게 거짓말을 하고 있는 이유와, 그것을 증명하는 4,032쌍 측정: 홉 바이 홉의 진실.