데이터베이스가 없는 프로토콜
서로 다른 세 종류의 없음: 합류할 데이터베이스가 없는 것, 아무도 구현하지 않는 데이터베이스, 그리고 답은 있지만 입력은 없는 테이블
Michel Wijnberg
앞의 두 글은 링크 스테이트 프로토콜에 조심스럽게 합류하는 이야기였습니다. 경로가 되지 않으면서 들어가고, 유령을 남기지 않으면서 나오는 것. 둘 다 합류할 무언가가 있다고 전제합니다.
이 글은 그것이 없는 경우들에 관한 이야기이고, 그것들이 다 같은 경우는 아닙니다. 셋이 있고, 셋은 정말로 다른 방식으로 어긋납니다.
하나: 데이터베이스가 없다
EIGRP는 진보된 거리 벡터 프로토콜입니다. 이웃끼리 도달성과 거리 정보를 교환하며, 공유되는 링크 스테이트 데이터베이스를 유지하지 않습니다. 모든 라우터가 들고 있는 동기화된 사본이 없으니, 무엇과 동기화할 대상 자체가 없습니다. 앞의 두 글에 나온 “합류한다”는 수는 여기에 존재하지 않습니다. 합류할 그것이 애초에 지어진 적이 없기 때문입니다.
존재하는 것은 각 라우터 자신의 시야입니다. 자기 이웃들, 그리고 자기가 계산한 거리를 단 목적지들의
토폴로지 테이블. 그것을 SNMP로, CISCO-EIGRP-MIB에서, 라우터 한 대씩 읽어 오고, 인접 그래프는
각 라우터가 자기 이웃에 대해 말한 것들로부터 다시 조립됩니다.
읽는 게 아니라 조립하는 것입니다. 네트워크의 누구도 그 그림을 들고 있지 않습니다. 모두에게 물어 답을 합쳐야 비로소 존재하고, 이는 LSDB를 읽는 것과는 다른 인식론적 위치이며, 결과로 나온 그래프가 똑같아 보이더라도 정직하게 말해 둘 가치가 있습니다.
자기가 누구인지 말하지 않으려는 이웃
그리고 구체적인 문제가 하나 있는데, 꽤 괜찮은 문제입니다.
EIGRP 이웃 항목은 이웃의 주소를 줍니다. IPv6에서 그 주소는 링크 로컬이고, 링크 로컬 주소는 링크 위의 인터페이스를 식별합니다. 장비를 식별하지 않습니다. 네트워크 정반대 끝에 있는 두 라우터가 아무 충돌 없이 같은 링크 로컬 주소를 지닐 수 있습니다. 범위가 링크이기 때문입니다.
그러니 이웃 테이블은 저쪽에 뭔가 있다고는 말하면서 그게 무엇인지는 말하기를 거부합니다.
해결은 완전히 다른 계층에서 옵니다. 그 장비에 대해 이미 발견해 둔 LLDP와 CDP 인접을 인터페이스로 색인한 것입니다. EIGRP 이웃의 인터페이스를 같은 인터페이스의 L2 이웃과 맞춰 보면, 반대쪽 끝에 어떤 장비가 있는지 알게 됩니다.
즉 Osprey에서 EIGRP 간선은 그 밑을 보면 서로 독립적인 두 관측이 일치한 것입니다. 라우팅 프로토콜이 인접이 존재한다고 말하고, 링크 계층이 반대편에 누가 있는지 말하는 것. L2 데이터가 없으면 그 이웃은 미해결로 남습니다. 주소 체계로 추측하지 않고, 이름으로 추론하지 않고, 서브넷으로 맞추지도 않습니다. 장비에 귀속시킬 수 없는 간선은 간선이 되지 못합니다.
둘: 테이블에 답은 있지만 입력이 없다
EIGRP 토폴로지 테이블이 두 번째 종류의 없음이 사는 곳이고, 제품에 거부를 만들어 낸 것이 바로 이것입니다.
이 테이블에는 접근 가능한 열이 열두 개 있습니다. 그것들이 함께 DUAL의 거리들을 나릅니다. 실행 가능 거리, 현재 계산 거리, 후계자가 보고한 거리, 그리고 후계자 개수와 넥스트홉 상태. 그것으로 각 라우터가 지금 무엇을 믿고 있는지를 보여 주기에는 충분하고, 이 블로그의 첫 글이 보여 주는 것이 정확히 그것입니다. 각 라우터 자신의 숫자가 사슬을 따라 줄어드는 모습 말입니다.
새로운 무언가를 계산하기에는 충분하지 않습니다.
가상의 변경 이후에 메트릭을 다시 계산하려면, 보고된 거리들이 파생되어 나온 구성 요소들과 그 뒤의
인터페이스 상태가 필요합니다. 그것들은 라우터에 있습니다. e-ams1-cr1에
show ip eigrp topology 10.64.0.0/15를 물으면 그 프리픽스에 대해 최소 대역폭, 총 지연, 신뢰도,
부하, MTU, 홉 수를 출력합니다. 그래서 저는 그것들이 존재한다는 사실을 추론이 아니라 알고 있습니다.
그것들은 지금 읽고 있는 MIB 테이블에 없습니다. 열두 열은 DUAL이 결정한 것을 나릅니다. 라우터는 DUAL이 그것을 결정하는 데 쓴 재료를 가지고 있으면서, 여기에는 공개하지 않습니다.
그래서 Osprey는 거부합니다. EIGRP 도메인에서 장애를 시뮬레이션해 달라고 하면 새 사슬을 투영하기를 사양하고, 그 이유를 말합니다. DUAL 재수렴을 예측할 수 없다, 읽고 있는 테이블이 거리들을 나를 뿐 재계산에 필요한 메트릭 구성 요소를 나르지 않기 때문이다, 라고.
그 거부에 관해 거부 자체보다 더 중요한 것이 둘 있습니다.
그것은 프로토콜이 아니라 우리가 읽는 것에 한정되어 있습니다. 메시지는 이것이 데이터 수집의 천장이지 EIGRP의 성질이 아니라고 말하도록 쓰였습니다. 다른 데서 구성 요소를 읽어 오는 보강기가 훗날 생기면 그 천장은 걷힐 것이기 때문입니다. “EIGRP는 시뮬레이션할 수 없다”고 말하는 제품은 다시는 묻지 말라고 조용히 이르는 것이고, 그것은 “지금은 입력을 수집하지 않는다”와는 다른, 훨씬 나쁜 진술입니다.
그것은 언제 발동하는지에 대해 정확합니다. 시뮬레이션하는 변경이 순수한 제거이고, 제거되는 대상이 관측된 사슬 위에 없음을 증명할 수 있다면, 실제 사슬은 그대로 보여 주면서 이 장애가 그것을 건드리지 않는다는 주석을 답니다. 다른 곳의 용량을 걷어 낸다고 해서, 그것을 쓰지 않던 거리 벡터 경로가 좋아질 수는 없습니다. 하지만 비용 변경이나 새 링크는 어디서든 경로를 끌어당길 수 있으므로 그런 것들은 언제나 “건드린다”로 셉니다. 엔진은 거부해야 하는 곳에서 거부하지, 일률적으로 거부하지 않습니다. 그 차이가 거부의 가치 전부입니다.
셋: 데이터베이스는 표준 안에만 있고 다른 어디에도 없다
세 번째 종류의 없음이 가장 답답합니다. 그것이 누구의 버그도 아니기 때문입니다.
IS-IS에는 표준 MIB가 있습니다. RFC 4444, .1.3.6.1.2.1.138입니다. Osprey의 SNMP 탐지는 그 트리를
먼저 찔러 보고, 그다음에야 .1.3.6.1.4.1.9.10.118의 Cisco 트리로 물러납니다. 두 OID 집합은
기준 상대적인 열 배치를 공유하고, MIB가 실제로 다른 곳, 즉 서킷 열 하나가 밀리는 지점에서만
다릅니다. 인접 열들은 동일합니다. 설계는 의도적으로 벤더 중립적입니다.
그 표준 경로는 실제 하드웨어에 대해 한 번도 입증된 적이 없습니다.
단위 테스트가 없다는 뜻이 아닙니다. 테스트는 있습니다. 우리가 닿을 수 있는 모든 장비가 Cisco
트리만 구현하기 때문입니다. 랩 라우터에 표준 .138 트리를 물으면 No Such Object가 돌아옵니다.
벤더 중립 코드 경로는 픽스처에 의해서만 실행되고 그 밖의 무엇으로도 실행되지 않으며, 저는 이 문장을
누군가 발견하게 두기보다 제가 쓰는 쪽을 택하겠습니다.
그다음 Arista가 그것을 교훈적인 방식으로 더 나쁘게 만들었습니다. 서비스 팟의 vEOS-lab 4.29.2F를
찔러 보면, 표준 .138 트리가 No Such Object를 돌려주고 Cisco .9.10.118 트리도 마찬가지
입니다. 둘 다 없습니다. 이 장비는 IS-IS를 아주 잘 구사하는데, 그것에 대해 물어볼 SNMP 트리가 아예
없는 것입니다.
같은 에이전트가 OSPF-MIB를 아무 문제 없이 제공하고, LLDP-MIB도 제공하며, OSPF가 설정되면 OSPF 트리를 동적으로 등록합니다. 그러므로 그 노드들에 대한 정직한 답은 “IS-IS 탐지가 실패했다”가 아니고, 빈 토폴로지는 더더욱 아닙니다. 이 장비에는 이 질문을 할 수 없다입니다. 그래서 팟의 리프들은 대신 OSPF로 탐지됩니다.
이것을 시장에 대한 주장으로 바꾸지는 않겠습니다. 벤더 둘은 조사가 아니니까요. 제가 말할 수 있는 것은 한정적이고 그래도 유용합니다. 우리가 테스트할 수 있었던 모든 장비에서 표준 MIB는 구현되어 있지 않았고, Cisco 엔터프라이즈 MIB만이 그 데이터를 노출하는 유일한 트리였습니다. 우리가 닿을 수 있는 그 무엇도 구현하지 않는 표준은, 그 위에 약속을 지을 수 있는 표준이 아닙니다.
이 메뉴가 이 글의 정직한 요약입니다. 네 개의 보고서가 여기서 열리지 않는 이유는 존재하지 않는 데이터베이스를 읽기 때문이고, 회색으로 비활성화된 항목은 빈 표를 여는 대신 각자의 이유를 툴팁으로 내놓습니다. EIGRP는 대신 자기 항목을 갖습니다. 답할 수 있는 것이 다른 질문이기 때문입니다.
세 종류의 없음
나란히 놓아 봅시다. 이 셋을 똑같이 취급하는 제품은 적어도 둘에 대해서는 거짓말을 하고 있기 때문입니다.
| 무엇이 없는가 | 유혹 | 대신 무엇을 하는가 |
|---|---|---|
| 합류할 데이터베이스가 없음 | 토폴로지 출처를 지어냄 | 각 라우터 자신의 시야에서 재구성하고, 그렇게 표시함 |
| 답이 아니라 입력이 없음 | 기본 대역폭과 지연을 가정함 | 시뮬레이션을 거부하고, 천장이 우리 쪽임을 밝힘 |
| MIB 자체가 없음 | 빈 토폴로지를 돌려줌 | 이 장비에는 물을 수 없다고 말하고, 제공되는 트리를 씀 |
가운데 열을 읽어 보십시오. 그 하나하나가, 데이터가 진짜로 있었을 때 나오는 화면과 정확히 똑같이 생긴 화면을 만들어 냅니다. 빈틈을 메우는 일의 문제가 바로 그것입니다. 출력에는 자기 어느 부분이 관측된 것인지 당신에게 알려 줄 방법이 없습니다.
요점
이 시리즈의 첫 두 글은 남의 프로토콜 안에서 조심스러운 손님이 되는 이야기였습니다. 이 글은 아예 들여보내 주지 않는 방들에 관한 이야기입니다.
거기서 좋은 손님이 된다는 것은 다른 뜻입니다. 들어갈 길을 찾는 게 아니라, 어느 문이 잠겨 있었는지를 정확히 말하는 것입니다. 미해결 EIGRP 간선, 사양하는 시뮬레이션, 물을 수 없는 장비. 세 개의 거부, 각각 자기 원인을 이름 붙이고, 어느 것도 답인 척 차려입지 않았습니다.
다음이자 이 시리즈의 마지막: 물어봐 주기를 기다리는 대신 스스로 찾아오는 유일한 출처, 그리고 그것이 당신이 믿어도 되는 것을 바꾸는 두 가지 방식. 폴링 말고 푸시.