AFI와 SAFI: 서비스 이름보다 먼저 쌍을 읽어라

세션이 올라오고 경로가 나타나는 것을 보면서도 잘못된 서비스를 읽고 있을 수 있다. 각 알림 앞의 숫자 쌍, 즉 주소 패밀리 식별자와 다음 주소 패밀리 식별자가 어느 파서가 페이로드를 읽고 어느 테이블이 결과를 보관하는지를 결정한다. 쌍을 잘못 잡으면 임포트 정책, 라우트 타깃 일치, 넥스트 홉 조회가 모두 아무도 알리지 않은 구조를 상대로 돌아간다. 아래의 여정은 그 쌍에서 시작해 전달 결과에서 끝난다.

경로가 어느 테이블에 속하는지는 두 숫자가 정한다

쌍은 두 번 나타난다. 다중 프로토콜 기능 안에서 발화자가 패밀리를 알리는 자리와, 그 패밀리가 나르는 모든 NLRI 앞이다. 그래서 이것은 출발 상자의 설정이 아니라 경로의 속성이다. 벤더는 이를 Address family VPNv4 Unicast 같은 이름으로 인쇄하며, 숫자는 그대로인 채 표현만 릴리스마다 옮겨 다닌다.

네 가지 인코딩이 거의 모든 기업 사례를 덮는다. MPLS 레이블이 붙은 VPN-IPv4에는 1과 128, IPv6 동등물에는 2와 128, BGP로 신호되는 VPLS에는 25와 65, EVPN에는 25와 70이다. 첫 번째 오류는 모든 Layer 2 서비스가 25와 65 뒤에 있다고 가정하는 것인데, 이것이 EVPN을 가린다. 두 번째는 두 IP 패밀리를 더 긴 주소를 가진 하나의 패밀리로 취급하는 것이다. 둘은 따로 협상되며 서로 다른 피어에서 받아들여질 수 있다. 세 번째는 한쪽만 아는 릴리스에서 템플릿을 복사할 때 나타난다. 레지스트리를 조회하면 서비스 이름에 기댄 추측보다 세 가지 모두 빨리 정리된다.

네 행을 IANA 레지스트리의 예로 보라, 레지스트리 자체가 아니다. 낯익은 무엇과도 맞지 않는 숫자가 나오면, 그 주위에 정책을 세우기 전에 먼저 찾아보라.

AFI 25는 서로 무관한 두 NLRI 형식을 나른다

두 Layer 2 패밀리 모두 AFI 25 아래에 있고, 유사성은 거기서 끝난다. RFC 4761 section 3.2.2의 VPLS NLRI는 길이, 라우트 구분자, VE ID, VE 블록 오프셋, VE 블록 크기, 레이블 기반을 나르며, 이것들이 함께 pseudowire 종단점과 그 레이블을 지칭한다. EVPN은 AFI 25를 유지한 채 SAFI 70으로 옮겨가고, 페이로드는 경로 유형이 된다. 이더넷 자동 발견, MAC/IP 알림, 포괄적 멀티캐스트, 이더넷 세그먼트, IP 프리픽스다. 따라서 같은 바이트 오프셋이 두 패밀리에서 다른 뜻을 가진다. 한쪽을 위해 쓴 파서가 다른 쪽을 불평 없이 읽고 엉터리를 낸다. 쌍은 해석이 틀렸다는 유일한 경고다.

한 패밀리에서 VE 블록 오프셋을 뜻하는 필드는 다른 쪽에 대응물이 없고, MAC/IP 알림 경로는 EVPN에만 있다. 속성을 양쪽에 적용되는 것처럼 인용하는 것이 캡처 검토를 어긋나게 하는 길이다.

누군가 캡처나 벤더 표를 건네면 그 속성이 어느 패밀리에 속하는지 물어라. 그다음 수신 구현이 그 패밀리를 지원하는지 확인하라. 데이터시트의 서비스 이름이 아니다. 두 플랫폼이 모두 VPLS 지원을 주장하면서 서로 다른 신호 패밀리를 구현할 수 있다. 쌍은 그것들을 갈라놓고, 제품 라벨은 그렇지 못하다.

세션 자체의 주소 패밀리는 별개의 질문이다

VPN-IPv6는 TCP 연결이 IPv4 위에서 도는 세션을 통해 일상적으로 알려진다. 이것은 지원되는 설계이지 결함이 아니다. 따라서 세션 요약만 읽어서는 피어가 어떤 VPN 패밀리를 교환하는지 알 수 없다.

NLRI 패밀리, 전송 패밀리, 전달 패밀리는 세 가지 독립적인 결정이다. 라우터는 피어와 IPv4로 말하고, VPN-IPv6 도달 가능성을 받아들이고, 다음 홉이 의도하지 않은 경로로 도달 가능한 IPv6 주소인 경로를 설치할 수 있다. 계층마다 각자의 확인이 필요하다. 알림은 맞아 보이는데 IPv6 목적지에 닿지 못한다고 보고하는 사이트는 대개 패밀리 협상이 아니라 넥스트 홉 해석을 잃은 것이다.

세션의 주소 패밀리를 따로 시험하고, 그다음 그것이 나르는 패밀리를, 그다음 코어가 전달할 수 있는 것을 시험하라. 셋을 분리해 두면 올바른 알림을 IPv6가 끝에서 끝까지 동작한다는 증거로 읽는 흔한 오진을 막는다. 알림은 한 피어가 다른 피어에게 프리픽스를 알렸다는 것만 증명한다.

협상됨, 수신됨, 임포트됨, 설치됨

기대하는 경로 하나에 대해 네 상태가 순서대로 성립해야 하고 각각 관측 가능하다. 패밀리가 그 피어와 협상되어 있어야 하고, 경로가 도착해야 하고, 라우트 타깃이 의도한 문맥으로 임포트해야 하고, 경로가 설치되도록 넥스트 홉이 해석되어야 한다. 첫 상태를 건너뛰면 나머지 셋은 답할 수 없게 된다. 협상되지 않은 패밀리는 살펴볼 경로를 만들지 않기 때문이다. Cisco 스타일 플랫폼에서는 패밀리 요약과 피어별 기능이 별도 명령이다.

show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address family

협상은 피어별로 인쇄되는 기능 교환에 나타나고, 패밀리가 하나도 나열되지 않은 확립된 세션은 요청한 것을 아무것도 나르지 않는다. 임포트는 확장 커뮤니티로 실린 라우트 타깃이 결정하므로, 올바른 쌍이라도 타깃을 잘못 입력하면 테이블은 비어 있다. 그다음 설치는 수신 문맥에서 넥스트 홉이 해석되는지에 달려 있고, 모든 알림이 완벽해 보이는 동안에도 실패할 수 있다.

데이터 플레인은 마지막에 확인하라. 테이블의 경로는 주장이지 배달이 아니다. 같은 네 상태가 모든 패밀리에 적용되며, 바뀌는 것은 명령과 테이블 이름뿐이다.

패밀리 쌍이 결코 증명하지 않는 것

쌍을 바르게 읽는 것은 뒤따르는 라우팅 정보를 어떻게 해석할지 알려 주며, 그것이 주장의 전부다. 도달 가능성, 정책, 데이터 플레인의 건전성에 대해서는 아무것도 말하지 않는다. 둘을 혼동하면 아무도 검증하지 않은 네트워크에 대해 자신만만한 진술이 나온다. 라우트 타깃 불일치와 끊긴 넥스트 홉은 쌍만 보고는 똑같이 보인다. 쌍은 읽기 지침이며 결코 판결이 아니다.

에스컬레이션할 때 쌍, 라우트 타깃, 해석된 넥스트 홉을 같은 메모에 담아라. 그러면 다음 엔지니어는 서비스 이름을 다시 해석하는 대신 독립적인 세 가지를 시험할 수 있다. 협상이 없으면 즉시 보이고, 타깃이 틀리면 임포트가 눈에 띄게 빠져 있으며, 넥스트 홉이 해석되지 않으면 경로는 있지만 쓸 수 없다.