VPN을 통한 PIM-SM: BSR, RP 매핑, RPF 경로 점검

터널은 살아 있고 유니캐스트 핑도 통과하는데 수신기는 여전히 검은 화면을 보여 줍니다. PIM-SM 배포에서 이 증상은 거의 항상 네 개의 제어 경로 중 하나가 끊어졌다는 뜻이며, 데이터 경로 자체가 문제였던 적은 없습니다. 아래 목록을 순서대로 진행하되, 이후의 모든 단계가 앞 단계에 의존하므로 실패하는 첫 단계에서 멈추십시오. 저는 이 다섯 가지 점검을 초안 파일에 보관해 두었다가 멀티캐스트 문의가 들어오면 터미널에 붙여 넣으며, 이렇게 하면 진단이 추측으로 흐르지 않습니다.

터널이 아니라 수신기부터 시작하십시오

그룹을 한 번도 요청하지 않은 수신기는 어떤 라우터에도 상태를 만들지 않으므로, 다른 무엇을 살펴보기 전에 수신기 쪽 세그먼트에 가입이 존재하는지 확인하십시오. Cisco 계열 플랫폼에서는 마지막 홉 라우터에서 show ip igmp groups 를 실행하면 가입된 그룹이 그것을 들은 인터페이스 옆에 표시됩니다. 그 출력에 그룹이 없으면 터널은 주의를 흩트리는 대상이며, 요청은 액세스 스위치, 호스트 소켓, 또는 querier가 없는 VLAN에서 죽었습니다.

제가 본 대부분의 누락된 가입은 두 가지 평범한 원인으로 설명됩니다: 호스트와 라우터 사이의 IGMP 버전 불일치, 그리고 라우팅을 하지 않는 스위치에서 이루어진 querier 선출입니다. 세 번째는 더 미묘한데, 그룹에 가입은 했지만 호스트에 네트워크 카드가 두 개 있고 애플리케이션이 잘못된 카드에 묶여 있어 잘못된 VLAN에 있는 경우입니다. IPv6 수신기는 MLD에서 같은 문제를 겪으며, 거기서는 show ipv6 mld groups 이 같은 질문에 답합니다. 이 중 어느 것도 터널을 건드려서 고쳐지지 않으며, 바로 그 때문에 순서가 중요합니다.

가입이 보이면 수신기 쪽 인터페이스와 랑데부 지점으로 향하는 인터페이스 양쪽에서 PIM이 켜져 있는지 확인하십시오. IGMP 가입은 있지만 상위 인터페이스에 PIM이 없는 라우터는 그룹을 로컬 테이블에 담아 두고 어디로도 아무것도 보내지 않습니다.

BSR 집합이 반대편까지 도달하는가?

Bootstrap Router 메시지는 하나의 PIM 도메인 안에서 홉 단위로 이동하며, 터널을 건널 때 끊기는 방향이 바로 그쪽입니다. 후보 RP는 자신의 광고를 유니캐스트로 선출된 BSR에 보내므로 RP에서 BSR까지의 구간은 동작하는 터널에서 대개 그대로 유지됩니다. 반대 방향의 Bootstrap 메시지 홍수는 모든 중간 인터페이스에 PIM이 켜져 있는지, 그리고 경계에서 메시지를 막는 것이 없는지에 달려 있습니다. RFC 5059 는 그 배포와 이를 줄일 수 있는 관리 범위 경계를 정의합니다.

ip pim bsr-border 문장, 프로토콜 103을 필터링하는 ACL, 또는 멀티캐스트를 실을 수 없는 정책 기반 IPsec 터널은 각각 홍수를 끊으면서 유니캐스트는 그대로 둡니다. 실제로는 도달 가능성 문제인데도 장애가 RP 문제처럼 보이게 만드는 것이 바로 이 조합이며, 그래서 저는 RP 설정보다 BSR 상태를 먼저 읽습니다.

반대편 라우터에서 show ip pim bsr-router 은 선출된 BSR과 학습한 RP 집합을 보여 주며, 출력이 비어 있으면 반대편은 자기 도메인에 갇혀 있고 어떤 RP 설정으로도 둘을 맞출 수 없습니다. 터널 양쪽에서 show ip pim rp mapping 의 그룹 범위와 RP 주소를 비교하십시오. 로컬에만 존재하는 매핑은 잘못된 지점에서 끝나는 공유 트리를 만들고, 수신기는 영원히 기다립니다.

터널 양쪽에서 RP 매핑을 일치시키십시오

정적 RP, BSR, anycast-RP는 같은 질문에 대한 세 가지 답이며, 이것들을 터널 너머로 섞는 것은 결코 수렴하지 않는 도메인을 만드는 확실한 방법입니다. 헤드 엔드가 BSR을 쓰고 지사가 다른 주소를 가리키는 정적 ip pim rp-address 를 쓰면, 지사는 수신기의 존재를 모르는 RP를 향해 공유 트리를 만듭니다. 매핑은 그룹 범위와 주소 모두에서 일치해야 하는데, 더 구체적인 범위가 더 넓은 범위를 이기기 때문입니다.

anycast-RP는 두 사이트가 하나의 RP 주소를 공유할 수 있도록 존재하며, «같은 RP»의 의미를 바꾸기 때문에 여기서 언급할 가치가 있습니다. 하나의 주소를 광고하는 두 RP는 설계상 일관되지만, 같은 범위에 서로 다른 주소를 광고하는 두 RP는 각 사이트가 단독으로 아무리 건강해 보여도 그렇지 않습니다.

232.0.0.0/8 내부의 소스별 멀티캐스트에서는 RP를 절대 조회하지 않으므로 빈 RP 매핑이 자동으로 결함은 아닙니다. 한 번도 필요하지 않았던 RP를 쫓기 전에 애플리케이션이 어떤 서비스 모델을 쓰는지 정하십시오.

소스를 향한 RPF 조회를 읽으십시오

PIM은 유니캐스트 경로를 뒤집어 트리를 만들므로 중요한 점검은 소스로 돌아가는 경로, 공유 트리의 경우 RP로 돌아가는 경로입니다. 라우터가 상위로 보지 않는 인터페이스로 도착한 가입은 버려지고, 그 이유는 터널 장애가 아니라 RPF 실패로 기록됩니다. 터널을 통한 기본 경로와 WAN을 통한 더 구체적인 경로를 가진 지사 라우터에서는 소스에 터널로만 도달할 수 있는데도 RPF 인터페이스가 쉽게 WAN이 될 수 있습니다. 이것이 가입이 조용히 버려지는 가장 흔한 단일 이유입니다.

show ip rpf 192.0.2.10 은 선택된 인터페이스, 다음 홉, 그 결정을 낳은 경로를 보여 주며 보통 그것만으로 불일치를 볼 수 있습니다. ip mroute 192.0.2.0 255.255.255.0 tunnel0 같은 정적 멀티캐스트 경로는 해당 프리픽스에 대한 유니캐스트 조회를 덮어쓰며, 멀티캐스트 토폴로지가 유니캐스트 토폴로지와 실제로 다를 때는 정당한 수정입니다. 이것을 문서화해야 할 설정으로 다루고, 장애 때 적용한 뒤 잊히는 패치로 다루지 마십시오.

핑이 아니라 명령으로 가입을 확인하십시오

핑은 이미 알고 있던 대로 유니캐스트가 동작함을 증명합니다. 종단 간 확인은 가입, 매핑, 이웃, 트리를 그 순서로 보여 주는 일련의 단계이며, 각 명령은 서로 다른 질문에 답합니다.

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

실제 들어오는 인터페이스와 비어 있지 않은 나가는 목록을 가진 (S,G) 항목이 채워져 있으면 제어 평면이 할 일을 마친 것입니다. 들어오는 인터페이스가 Null 로 표시되는 항목, 또는 계속 올라가는 RPF failed 라벨의 카운터는 터널이 아니라 이전 절을 가리킵니다.

다섯 명령이 모두 올바르게 보이는데도 수신기가 아무것도 보지 못한다면, 남은 용의자는 유니캐스트 라우팅 프로토콜은 허용하지만 PIM, IGMP, 또는 그룹 트래픽 자체는 허용하지 않는 암호화 ACL이나 방화벽 규칙, 즉 터널 자체의 정책입니다. 정책 기반 IPsec 터널에서는 멀티캐스트가 아예 실리지 않으므로, 답은 또 하나의 필터 예외가 아니라 GRE 또는 VTI 설계입니다. 무엇이든 바꾸기 전에 다섯 점검 중 무엇이 실패했는지 적고, 그 계층만 바꾸십시오.