NX-OS를 사용하는 Nexus 9000에서 멀티캐스트 Auto-RP 문제 해결

소개

이 문서에서는 Auto-RP가 NX-OS를 사용하는 Cisco Nexus 9000에서 작동하는 방식과 멀티캐스트 작업을 검증하고 문제를 해결하는 방법에 대해 설명합니다.

사전 요구 사항

요구 사항

• IP 멀티캐스트에 대한 기본 지식
• IGMP 및 PIM 스파스 모드에 대한 기본 지식
• Cisco Nexus 9000 및 NX-OS CLI 사용 경험
• 유니캐스트 라우팅 및 RPF 개념 이해

사용되는 구성 요소

• Cisco Nexus 9000 Series Switch
• Cisco NX-OS Software
• PIM 스파스 모드
• 고정 RP 및 Auto-RP

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

멀티캐스트 개요

멀티캐스트는 소스에서 여러 수신자에게 단일 트래픽 스트림을 전송하는 일대다 통신 모델입니다. 각 대상에 대해 별도의 사본을 생성하는 대신, 전달 경로가 분기되는 위치에서만 트래픽을 복제합니다. 따라서 멀티캐스트가 브로드캐스트 또는 반복 유니캐스트 전송보다 더 효율적입니다. IPv4에서 멀티캐스트 트래픽은 224.0.0.0/4 범위의 목적지 주소를 사용합니다.

PIM Sparse Mode는 NX-OS를 실행하는 Cisco Nexus 스위치에서 지원되는 멀티캐스트 라우팅 모델입니다. 수신기 관심이 명시적으로 학습된 경우에만 트래픽을 전달합니다. Any-Source Multicast 설계에서 수신자는 처음에 Rendezvous Point를 향해 공유 트리에 참여하며, 소스는 해당 RP에 등록합니다. 트래픽이 흐르기 시작하면 마지막 홉 라우터가 공유 트리에서 출발지를 향해 최단 경로 트리로 이동할 수 있습니다.

정확한 트러블슈팅은 컨트롤 플레인 이벤트, 라우팅 엔트리 및 전달 결정을 나타내는 방법을 이해하는 데 달려 있으므로 멀티캐스트에 사용되는 용어를 정의하는 것이 중요합니다. 용어 지우기는 명령 출력을 정확하게 해석하고, 공유 트리와 소스 트리 동작을 구분하며, 엔드 투 엔드 포워딩 프로세스에서 각 멀티캐스트 구성 요소의 역할을 식별하는 데 도움이 됩니다.

용어	정의
멀티캐스트 그룹 주소	멀티캐스트 그룹을 식별하는 데 사용되는 224.0.0.0/4 범위의 IPv4 목적지 주소.
Source address	멀티캐스트 그룹에 트래픽을 전송하는 발신자의 유니캐스트 IP 주소입니다.
M루트	그룹 또는 소스 그룹 조합에 대한 멀티캐스트 트래픽이 처리되는 방법을 정의하는 멀티캐스트 라우팅 항목입니다.
IIF	들어오는 인터페이스. 멀티캐스트 트래픽이 도착할 것으로 예상되는 인터페이스.
OIF	발송 인터페이스. 멀티캐스트 트래픽을 수신기 또는 다운스트림 네이버로 전달하는 데 사용되는 인터페이스.
석유	발송 인터페이스 목록 멀티캐스트 라우팅 엔트리와 연결된 발신 인터페이스 집합입니다.
RPF	역방향 경로 전달입니다. 멀티캐스트 트래픽이 소스 또는 RP를 향하는 유니캐스트 경로를 기반으로 올바른 인터페이스에 도착했는지 확인하는 확인.
MDT	멀티캐스트 배포 트리입니다. 소스에서 모든 수신자에게 멀티캐스트 트래픽을 전달하는 논리적 트리입니다.
RPT	RP 트리(공유 트리라고도 함) RP에 수신기를 연결하며 (*,G)로 표시됩니다.
SPT	소스 트리라고도 하는 최단 경로 트리 수신자를 소스에 직접 연결하고 (S,G)로 나타냅니다.
FHR	첫 번째 홉 라우터. 소스에 직접 연결되어 있으며 RP와의 소스 등록을 담당하는 멀티캐스트 라우터입니다.
LHR	마지막 홉 라우터. 멀티캐스트 라우터는 수신자에 직접 연결되며 IGMP를 통해 수신기 관심을 학습한 후 멀티캐스트 상태를 생성합니다.
RP	랑데부 포인트 ASM 및 PIM Sparse Mode에서 소스 및 수신기를 초기에 연결하는 데 사용되는 논리적 회의 지점입니다.
ASM	Any-Source 멀티캐스트 수신자가 사전에 소스를 지정하지 않고 그룹에 가입하는 멀티캐스트 모델입니다.

멀티캐스트 트러블슈팅은 지정된 목적지 그룹을 사용하는 제어 프로토콜과 네트워크에서 트래픽이 어떤 기능을 수행하는지를 신속하게 식별하는 데 따라 결정되므로 잘 알려진 예약 멀티캐스트 주소를 이해하는 것이 중요합니다. 이러한 주소를 통해 정상적인 프로토콜 운영과 비정상적인 동작을 구분할 수 있으며 IGMP, PIM 및 Auto-RP 교환을 더 쉽게 검증할 수 있습니다. Auto-RP의 경우 특히 인식할 수 있는 가장 중요한 그룹은 RP-Announce의 경우 224.0.1.39, RP-Discovery의 경우 224.0.1.40입니다. 라우터에서 동적 RP 매핑을 학습할 수 있는 정보를 전달하기 때문입니다.

멀티캐스트 주소	목적
224.0.0.1	로컬 서브넷의 모든 호스트
224.0.0.2	로컬 서브넷의 모든 라우터
224.0.0.13	모든 PIM 라우터
224.0.0.22	IGMPv3 메시지
224.0.1.39	Auto-RP에서 사용하는 Cisco RP-Announce 메시지
224.0.1.40	Auto-RP에서 사용하는 Cisco RP-Discovery 메시지

PIM 스파스 모드의 Auto-RP 작업(컨트롤 플레인 워크플로)

Auto-RP는 Protocol Independent Multicast Sparse Mode에서 멀티캐스트 도메인 전체에 RP(Rendezvous Point) 정보를 동적으로 검색하고 배포하는 데 사용하는 Cisco 메커니즘입니다. 멀티캐스트 기반 컨트롤 플레인 메시지를 사용하여 RP-to-group 매핑을 광고, 선택 및 학습함으로써 고정 RP 컨피그레이션이 필요하지 않습니다. 주요 구성 요소는 특정 그룹 범위에 대한 RP 서비스를 제공하는 Candidate RP와 후보를 수집하고 그룹당 활성 RP를 결정하는 Mapping Agent입니다.

이 프로세스는 각 후보 RP가 IP 주소, 우선순위 및 지원되는 멀티캐스트 그룹 범위를 포함하여 RP-Announce 메시지를 224.0.1.39로 주기적으로 전송할 때 시작됩니다. 이러한 메시지는 NX-OS의 Auto-RP 리스너를 사용하여 네트워크 전체에서 플러딩되므로, 네트워크가 스파스 모드에서 완전히 작동하기 전에도 모든 매핑 에이전트가 메시지를 수신할 수 있습니다.

매핑 에이전트는 이러한 알림을 듣고, 후보 RP 데이터베이스를 구축하고, 그룹당 결정적 선택 프로세스(일반적으로 우선순위가 가장 높고, IP 주소가 가장 높음)를 수행합니다. 최상의 RP를 선택하면 매핑 에이전트가 RP-Discovery 메시지를 생성하여 224.0.1.40으로 전송하여 도메인의 모든 라우터에 최종 RP-그룹 매핑을 알립니다.

모든 PIM 라우터는 RP-Discovery 메시지를 수신하고 로컬 RP 테이블에 매핑을 설치합니다. 이 정보를 통해, 마지막 홉 라우터(수신기에 연결됨)는 PIM Join 메시지를 선택한 RP로 전송하여 RPT(공유 트리)를 구축하는 반면, 첫 번째 홉 라우터(소스에 연결됨)는 PIM 레지스터 메시지의 멀티캐스트 트래픽을 캡슐화하여 활성 소스에 대해 RP에 알립니다.

트래픽이 RP를 통과하므로 라우터는 선택적으로 소스를 향해 직접 추가 PIM Join/Prune 신호를 사용하여 RPT(Shared Tree)에서 SPT(Shortest-Path Tree)로 전환할 수 있습니다. 이 프로세스 전반에 걸쳐 Auto-RP는 주기적인 제어 메시지를 통해 지속적으로 매핑을 새로 고쳐 복원력과 토폴로지 또는 RP 변경에 대한 자동 적응을 보장합니다.

PIM 스파스 모드의 Auto-RP 작업(컨트롤 플레인 워크플로)

Auto-RP 제한 사항 및 운영 제약 조건

• Auto-RP는 IPv4 멀티캐스트에서만 작동하며 IPv6(PIM6)에서는 지원되지 않으므로 IPv6 구축에는 다른 RP 검색 메커니즘이 필요합니다.
• Auto-RP는 동일한 PIM 도메인 내에서 BSR과 공존할 수 없습니다. 컨트롤 플레인 충돌을 방지하기 위해 RP 검색 메커니즘을 하나만 구성할 수 있기 때문입니다.
• Auto-RP 메시지는 NX-OS 디바이스에서 기본적으로 처리되거나 전달되지 않으므로 적절한 작동을 위해서는 명시적 컨피그레이션이 필요합니다.
• Auto-RP 제어 메시지의 전파는 Auto-RP 리스너를 활성화하는 것에 따라 달라집니다. 그렇지 않으면 RP 매핑 정보가 모든 라우터에 도달하지 않습니다.
• RP 알림 간격의 최소 임계값은 15초이며, 이는 RP 업데이트를 알릴 수 있는 속도를 제한하며 컨버전스 시간에 영향을 줍니다.
• 경로 맵을 통한 자동 RP 메시지 필터링은 작업에 영향을 줄 수 있습니다. 잘못된 정책이 RP-그룹 매핑을 차단할 수 있기 때문입니다.
• Auto-RP는 VRF 컨텍스트에서 기본적으로 비활성화되므로 다중 VRF 구축에서 명시적으로 활성화해야 합니다.

• ECMP 기반 다중 경로 전달은 기본적으로 활성화되어 있으며, 이를 통해 멀티캐스트 트래픽에서 로드 밸런싱에 동일 비용 경로를 사용할 수 있습니다.

• IPsec AH-MD5를 사용하는 PIM 네이버 인증이 지원됩니다.

• PIM 스누핑을 사용할 수 없습니다.

Auto-RP 사용의 이점

Auto-RP는 PIM Sparse Mode 멀티캐스트 환경에 대해 동적 RP 검색 및 중앙 집중식 RP 매핑 배포를 제공합니다. 모든 멀티캐스트 라우터에서 고정 RP 컨피그레이션이 필요하지 않으며, 운영 복잡성을 줄이고 멀티캐스트 확장성을 향상합니다. Auto-RP는 또한 여러 RP-Candidate를 지원하여 자동 RP 장애 조치 및 이중화를 지원합니다. 이 메커니즘은 일관된 멀티캐스트 포워딩 동작을 유지하고 네트워크 확장을 간소화하며 멀티캐스트 라우터가 도메인 전체에서 RP 정보를 자동으로 학습할 수 있도록 합니다.

Auto-RP 매핑 에이전트 및 RP 선택 프로세스

Auto-RP의 선택 프로세스는 결정적이며 주로 IP 주소를 기반으로 합니다. 다른 프로토콜(예: PIMv2 BSR)과 달리 Auto-RP는 구성 가능한 "우선순위" 값을 사용하지 않습니다. 대신 IP 주소 계층 구조를 사용하여 충돌을 해결합니다.

매핑 에이전트(MA) 선택

Auto-RP에서는 이중화를 위해 여러 매핑 에이전트가 동일한 네트워크 내에서 공존할 수 있습니다. 한 명이 꺼지고 다른 한 명이 켜지는 공식적인 선거 절차가 없습니다. 모두 기술적으로 활성 상태입니다. 그러나 네트워크의 스위치에서 신뢰할 정보를 결정해야 합니다.

• 선택 기준: 가장 높은 IP 주소.
• 프로세스:
  1. 모든 매핑 에이전트는 RP-Discovery 메시지를 멀티캐스트 그룹 224.0.1.40으로 전송합니다.
  2. 클라이언트 스위치에서 이러한 메시지를 수신합니다.
  3. 스위치에서 서로 다른 두 매핑 에이전트에서 충돌하는 정보가 포함된 검색 메시지를 수신하는 경우, 스위치는 소스 IP 주소가 가장 높은 매핑 에이전트의 정보를 수락합니다.
  4. Nexus 동작: IP 주소가 더 낮은 매핑 에이전트는 일반적으로 네트워크에서 중복 제어 트래픽을 방지하기 위해 IP 주소가 더 높은 다른 MA를 탐지할 때 "수동" 또는 "억제" 상태가 됩니다.

RP(랑데부 지점) 선택

이 프로세스는 매핑 에이전트가 후보로부터 모든 RP-Announce 메시지(그룹 224.0.1.39로 전송됨)를 수신한 후 수행합니다.

매핑 에이전트가 동일한 멀티캐스트 그룹에 대한 여러 후보를 수신할 때 다음 순서대로 규칙을 적용합니다.

규칙 A: 가장 긴 접두사 일치(가장 구체적인 마스크)

후보들이 중첩된 범위들을 발표하면, MA는 가장 작은 범위(가장 긴 서브넷 마스크)를 발표한 RP에 그룹을 할당한다.

• 예:
  • 후보 A는 224.0.0.0/4 (the의 전체 멀티캐스트 범위를 알려줍니다.
  • 후보 B는 224.10.20.0/24을 발표한다.
  • 결과: 그룹 224.10.20.5의 경우, 그 범위가 더 구체적이기 때문에 후보 B가 승리한다.

규칙 B: 최고 IP 주소(타이 브레이커)

둘 이상의 후보가 정확히 동일한 그룹 범위를 발표하는 경우 매핑 에이전트는 하나만 선택해야 합니다.

• 기준: IP 주소가 가장 높은 후보가 승리합니다.
• 예:
  • 후보자 1: 224.10.20.0/24 범위의 10.2.0.1.
  • 후보자 2: 224.10.20.0/24 범위의 경우 10.2.0.4입니다.
  • 결과: 매핑 에이전트는 해당 범위에 대한 공식 RP로 10.2.0.4를 선택하고 이는 해당 검색 메시지에서 광고됩니다.

레이어 2 고려 사항: 멀티캐스트 MAC 및 스누핑

이 문서에서는 PIM을 사용하는 레이어 3 멀티캐스트를 중점적으로 다루지만, 레이어 2 동작은 문제 해결 및 전반적인 설계에 중요한 역할을 합니다. 레이어 2에서 디바이스는 네트워크 인터페이스에 할당된 48비트 식별자인 MAC 주소를 사용하여 통신하며, 멀티캐스트 트래픽은 유니캐스트 및 브로드캐스트 트래픽과 구별하기 위해 특정 MAC 주소 지정 방식이 필요합니다.

IPv4 멀티캐스트 MAC 주소는 예약된 접두사 `01:00:5E`를 사용하여 레이어 3 멀티캐스트 그룹 주소에서 파생됩니다. 그러나 IP 멀티캐스트 주소의 23비트만 MAC 주소에 매핑됩니다. 그러면 32:1 중복이 생성됩니다. 즉, 최대 32개의 서로 다른 멀티캐스트 IP 그룹이 동일한 MAC 주소에 매핑될 수 있습니다. 따라서 지정된 멀티캐스트 MAC 주소를 수신하는 호스트는 여러 멀티캐스트 그룹에 대한 트래픽을 수신할 수 있습니다(단 하나에만 관심이 있는 경우에도). 예: 224.1.1.1, 225.1.1.1, 226.1.1.1, 227.1.1.1, 228.1.1.1 이상

이러한 중복은 네트워크 효율성 및 문제 해결에 직접적인 영향을 미칩니다. MAC 주소만을 기반으로 하는 레이어 2 포워딩 결정은 중첩되는 멀티캐스트 그룹을 구분할 수 없으므로 스위치에서 불필요한 트래픽을 호스트로 전달할 수 있습니다. 그런 다음 이러한 호스트는 IP/IGMP(Higher-Layer Filtering)에 의존하여 원치 않는 패킷을 버림으로써 CPU 및 버퍼 리소스를 소비해야 합니다.

Cisco Nexus NX-OS에서는 이러한 제한이 IGMP 스누핑의 동작으로 완화됩니다. 기본적으로 IGMP 스누핑은 MAC 전용 전달이 아닌 IP 기반 조회를 수행하므로 여러 멀티캐스트 그룹이 동일한 MAC 주소를 공유하는 경우에도 스위치에서 보다 정확한 전달 결정을 내릴 수 있습니다. 따라서 레이어 2 효율성이 크게 향상되고 불필요한 트래픽 전달이 줄어듭니다.

Auto-RP 컨피그레이션

이 섹션에서는 간단한 구현을 참조로 하여 Auto-RP 컨피그레이션에 대한 자세한 설명을 제공합니다. 이 설정에서는 멀티캐스트 소스가 vPC를 통해 2개의 Nexus 스위치에 연결되어 트래픽을 수신자에게 전달합니다. 이 설계에서, N9K-1 및 N9K-2 모두는 RP 후보들 및 맵핑 에이전트들로서 동시에 기능한다.

멀티캐스트 트래픽 흐름

첫 번째 홉 라우터

동일한 구성에 FHR-2가 있습니다.

FHR-1# show running-config pim
feature pim
ip pim auto-rp forward listen

interface Vlan1
  ip pim sparse-mode

interface Ethernet1/1
  ip pim sparse-mode

interface Ethernet1/3
  ip pim sparse-mode

명령을 사용합니다	목적/설명
기능 pim	스위치에서 PIM(Protocol Independent Multicast) 프로세스를 활성화합니다.
ip pim auto-rp forward listen	Auto-RP 리스너를 활성화합니다. 이렇게 하면 스위치에서 아직 RP의 ID를 모르는 경우에도 Auto-RP 제어 메시지(224.0.1.39 및 224.0.1.40)를 수신하고 전달할 수 있습니다.
ip pim sparse-mode	특정 인터페이스에서 PIM Sparse Mode를 활성화합니다. 이 모드에서는 멀티캐스트 트래픽이 PIM 참여 메시지를 통해 명시적으로 요청한 세그먼트에만 전달됩니다.

에이전트 및 RP 후보 매핑

N9K-1# show running-config pim
feature pim

ip pim auto-rp rp-candidate loopback0 group-list 224.10.20.0/24 interval 15
ip pim auto-rp mapping-agent loopback1

interface loopback0
  ip pim sparse-mode

interface loopback1
  ip pim sparse-mode

interface Ethernet1/3
  ip pim sparse-mode

interface Ethernet1/4
  ip pim sparse-mode

interface Ethernet1/49
  ip pim sparse-mode

이 테이블은 N9K-1에 대한 PIM 컨피그레이션의 세부 기술 분석을 제공합니다. 이 컨피그레이션은 N9K-2에 복제됩니다. 두 스위치 모두 멀티캐스트 도메인에 대한 RP 후보 및 매핑 에이전트 역할을 하는 이중 역할로 구성됩니다.

명령을 사용합니다	자세한 기술 설명
기능 pim	기능 활성화: Nexus 스위치에서 PIM(Protocol Independent Multicast) 엔진을 전역적으로 활성화합니다.
ip pim auto-rp rp-candidate loopback0 group-list 224.10.20.0/24 interval 15	RP 후보자 역할: 이 스위치를 RP(Rendezvous Point)로 "volunteer"로 구성합니다. 출처: 루프백0의 IP 주소를 사용합니다. 범위: 멀티캐스트 그룹 범위 224.10.20.0/24을 처리할 수 있습니다. 간격: 15초마다 매핑 에이전트에 "Announce(알림)" 메시지를 보냅니다. 보류 타이머는 이 값의 3배입니다.
ip pim auto-rp mapping-agent loopback1	매핑 에이전트 역할: 스위치를 Auto-RP 프로세스의 "관리자"로 구성합니다. 기능: 모든 RP 후보를 듣고 충돌을 해결하며(가장 높은 IP 주소를 타이 브레이커로 사용) 네트워크의 나머지 부분에 "검색" 메시지를 브로드캐스트하여 활성 RP가 누구인지를 알려줍니다.
인터페이스 루프백0/루프백1	논리적 인터페이스: PIM은 RP 후보 및 매핑 에이전트 역할의 소스 IP로 사용되므로 이러한 인터페이스에서 활성화됩니다. 모든 PIM 라우터에서 유니캐스트 라우팅 테이블을 통해 연결할 수 있어야 합니다.
인터페이스 Ethernet1/3, 1/4, 1/49	물리적 포워딩: 물리적 포트에서 PIM Sparse Mode를 활성화합니다. 그러면 스위치가 다른 라우터와 PIM 네이버 인접성을 형성하고 이러한 특정 링크를 통해 멀티캐스트 트래픽을 전달할 수 있습니다.
ip pim sparse-mode	작동 모드: 위의 모든 인터페이스에 적용됩니다. 멀티캐스트 트래픽이 PIM 조인 메시지를 통해 명시적으로 요청한 수신자에게만 전송되도록 하여 불필요한 네트워크 플러딩을 방지합니다.

IPv4 연결성을 위한 라우팅 컨피그레이션

• 이 토폴로지에서는 모든 Nexus 스위치가 영역 0(0.0.0.0) 내에서 운영되는 UNDERLAY라는 단일 OSPF 프로세스에 참여하여 네트워크 전체에 완전한 라우팅 연결성을 제공합니다.
• LHR에서 OSPF는 멀티캐스트 수신기의 게이트웨이 역할을 하는 VLAN 2와 포인트-투-포인트로 구성된 업링크 인터페이스 Ethernet1/49 및 Ethernet1/50에서 활성화됩니다. 이를 통해 DR/BDR 선택 없이 업스트림 N9K 스위치로의 효율적인 인접성 형성이 보장됩니다.
• FHR 계층(FHR-1 및 FHR-2)은 동일한 구성을 공유한다. OSPF는 멀티캐스트 소스의 게이트웨이 역할을 하는 VLAN 1과 어그리게이션 레이어를 향하는 라우티드 업링크(Ethernet1/1 및 Ethernet1/3)에서 활성화됩니다. 이러한 링크는 포인트-투-포인트로 구성되어 컨버전스 및 인접성 동작을 최적화합니다.
• 마찬가지로 N9K-1과 N9K-2는 OSPF에 Loopback0 및 Loopback1 광고를 추가하여 동일한 OSPF 컨피그레이션을 갖습니다.
  • 이러한 루프백은 나중에 PIM RP 후보자 및 매핑 에이전트 역할에 사용되므로 매우 중요합니다.

PIM Neighbors and OSPF 영역 0

N9K-1 — OSPF 컨피그레이션

N9K-1(config)# show running-config ospf
feature ospf

router ospf UNDERLAY
  router-id 10.2.0.1

interface loopback0
  ip router ospf UNDERLAY area 0.0.0.0

interface loopback1
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/3
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/4
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/49
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

FHR-1 - OSPF 컨피그레이션

FHR-1(config)# show running-config ospf
feature ospf

router ospf UNDERLAY

interface Vlan1
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/1
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/3
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

LHR — OSPF 컨피그레이션

LHR(config)# show running-config ospf
feature ospf

router ospf UNDERLAY

interface Vlan2
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/49
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/50
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

작동 상태 확인 및 Auto-RP 문제 해결

1단계: 기본 IP 연결성 확인(유니캐스트 언더레이 검증)

멀티캐스트 동작을 분석하기 전에 유니캐스트 언더레이(OSPF Area 0)가 완전히 작동하는지 검증하는 것이 중요합니다. PIM 및 Auto-RP와 같은 멀티캐스트 컨트롤 플레인 프로토콜은 올바르게 작동하는 유니캐스트 도달 능력에 따라 달라집니다.

첫 번째 검증 단계는 소스와 수신자(또는 가장 가까운 레이어 3 게이트웨이)가 FHR 및 LHR에 연결할 수 있습니다.

토폴로지에서

• 멀티캐스트 소스에 가장 가까운 FHR-1 / FHR-2 →(10.150.1.37 - VLAN 1)

• LHR → 멀티캐스트 수신기에 가장 가까운 거리(192.168.2.37 - VLAN 2)

검증 방식

1. 다음 기간 동안 ICMP 연결 가능성 테스트를 수행합니다.

• FHR ↔ LHR

• FHR ↔ 수신기 서브넷(VLAN 2 게이트웨이)

• LHR ↔ 소스 서브넷(VLAN 1 게이트웨이)

2. 라우팅 테이블에서 소스 및 수신기 연결 상태를 확인합니다. vPC 구축의 경우 두 Nexus 피어 간에 일관성을 보장합니다. 수신기에는 ECMP 경로가 있지만 소스는 레이어 2를 통해 연결할 수 있습니다.

FHR-1 - 소스로 경로 지정

FHR-1# show ip route 10.150.1.37

10.150.1.37/32, ubest/mbest: 1/0, attached
    *via 10.150.1.37, Vlan1, [250/0], 06:57:19, am

FHR-1 - 수신자에 대한 경로

FHR-1# show ip route 192.168.2.37

192.168.2.0/24, ubest/mbest: 2/0
    *via 10.4.0.6, Eth1/3, [110/45], 04:11:08, ospf-UNDERLAY, intra
    *via 10.4.0.10, Eth1/1, [110/45], 04:11:08, ospf-UNDERLAY, intra

FHR-2 - 소스로 경로 지정

FHR-2# show ip route 10.150.1.37

10.150.1.37/32, ubest/mbest: 1/0, attached
    *via 10.150.1.37, Vlan1, [250/0], 07:03:45, am

FHR-2 - 수신자에 대한 경로

FHR-2# show ip route 192.168.2.37

192.168.2.0/24, ubest/mbest: 2/0
    *via 10.4.0.13, Eth1/3, [110/45], 04:16:16, ospf-UNDERLAY, intra
    *via 10.4.0.18, Eth1/4, [110/45], 04:16:16, ospf-UNDERLAY, intra

LHR — 소스로 경로 지정

LHR(config)# show ip route 10.150.1.37

10.150.1.0/24, ubest/mbest: 2/0
    *via 10.4.0.22, Eth1/49, [110/45], 04:14:52, ospf-UNDERLAY, intra
    *via 10.4.0.26, Eth1/50, [110/45], 04:14:52, ospf-UNDERLAY, intra

LHR — 수신자에 대한 경로

LHR(config)# show ip route 192.168.2.37

192.168.2.37/32, ubest/mbest: 1/0, attached
    *via 192.168.2.37, Vlan2, [250/0], 06:47:21, am

중요 고려 사항

• 이 테스트가 실패했다는 것은 언더레이 문제를 강력히 나타냅니다.

• 다음 이유 때문에 멀티캐스트가 유니캐스트 연결 없이는 제대로 작동할 수 없습니다.

  • PIM 네이버는 유니캐스트 라우팅을 사용합니다

  • RP(루프백) 주소에 연결할 수 있어야 합니다.

  • RPF(Reverse Path Forwarding) 확인은 라우팅 테이블에 따라 다릅니다

• Ping을 정상적으로 수행한다고 해서 멀티캐스트가 제대로 작동할 수 있는 것은 아닙니다.

  • 멀티캐스트가 차단된 동안 ICMP를 허용할 수 있음

  • PIM 또는 Auto-RP는 여전히 잘못 구성될 수 있음

2단계: 멀티캐스트 역할 및 엔드 투 엔드 토폴로지 식별

다음 단계는 멀티캐스트 트래픽 전달과 관련된 각 디바이스의 역할을 명확하게 식별하는 것입니다. 멀티캐스트 트러블슈팅은 토폴로지 전체에서 트래픽 흐름과 예상되는 동작을 이해하는 데 전적으로 의존하므로 이 단계는 필수 단계입니다.

최소한 다음 요소를 식별해야 합니다.

• 멀티캐스트 소스(s): 10.150.1.37(VLAN 1)

• 멀티캐스트 그룹(G): 224.10.20.10

• 수신자: 192.168.2.37(VLAN 2)

• FHR(첫 번째 홉 라우터): FHR-1 / FHR-2(소스와 가장 가까운 곳)

• LHR(Last Hop Router): LHR(수신자와 가장 가까운 위치)

또한 컨트롤 플레인 역할을 식별해야 합니다.

• RP 후보자: N9K-1 및 N9K-2(루프백0)

• 매핑 에이전트: N9K-1 및 N9K-2(루프백1)

토폴로지 및 컨트롤 플레인 인식

멀티캐스트 트러블슈팅을 진행하려면 자세한 네트워크 토폴로지가 필요합니다. 여기에는 다음 항목이 포함됩니다.

• 물리적 연결(디바이스 간에 사용되는 인터페이스)

• 논리적 토폴로지(VLAN, 라우팅된 링크, vPC 관계)

• 사용 중인 라우팅 프로토콜(이 설계에서는 OSPF 영역 0)

• 라우팅 도메인 경계(단일 IGP와 OSPF, EIGRP, BGP와 같은 혼합 프로토콜)

• RP 및 매핑 에이전트 역할에 사용되는 루프백 인터페이스

• PIM 지원 인터페이스 및 네이버 관계

분명히 이해해야 할 것은

• Source → FHR → RP → LHR → Receiver의 정확한 경로

• 어떤 장치가 다음 작업을 담당합니까?

  • FHR(PIM 레지스터) 전송

  • 빌딩 (*,G) 또는 (S,G) 트리 (LHR)

  • RP 정보 광고(매핑 에이전트)

• 라우팅(OSPF)을 통해 다음과 같은 연결 기능을 보장하는 방법:

  • 소스 서브넷

  • 수신기 서브넷

  • RP 루프백 주소

  • 에이전트 루프백 주소 매핑

3단계: 디바이스 역할에 따라 Auto-RP 컨피그레이션 검증

다음 단계는 멀티캐스트 토폴로지에서의 역할에 따라 각 디바이스에서 Auto-RP가 올바르게 구성되었는지 확인하는 것입니다. 여기에는 다음을 확인하는 것이 포함됩니다.

• RP 후보(N9K-1 / N9K-2)는 자신의 Loopback0을 멀티캐스트 그룹 범위에 대한 RP로 광고하도록 적절히 구성됩니다.

• 매핑 에이전트(N9K-1 / N9K-2)는 RP-Announce 메시지를 수집하고 루프백1을 사용하여 RP-Discovery 메시지를 생성하도록 구성됩니다.

• FHR 및 LHR은 모든 관련 인터페이스에서 PIM Sparse Mode가 활성화되어 Auto-RP에 참여하고 RP 매핑을 수신합니다.

PIM sparse-mode에 대해 필요한 모든 인터페이스(루프백 및 라우티드 링크 포함)가 활성화되어 있고 RP-Announce(224.0.1.39) 및 RP-Discovery(224.0.1.40) 메시지의 교환을 방해하는 누락된 컨피그레이션이 없는지 확인해야 합니다.

4단계: 모든 RP 후보자 및 모든 매핑 에이전트의 작동 확인

4.1단계 PIM 네이버 인접성 확인

첫 번째 검증 단계는 모든 예상 PIM 인접 디바이스가 멀티캐스트 토폴로지 전체에서 올바르게 설정되었는지 확인하는 것입니다.

N9K-1 — PIM 인접 디바이스 확인

N9K-1# show ip pim neighbor

PIM Neighbor Status for VRF "default"
Neighbor        Interface            Uptime    Expires   DR       Bidir-  BFD    ECMP Redirect
                                                         Priority Capable State     Capable
10.4.0.5        Ethernet1/3          23:19:45  00:01:20  1        yes     n/a     no
10.4.0.14       Ethernet1/4          23:19:45  00:01:38  1        yes     n/a     no
10.4.0.21       Ethernet1/49         23:19:45  00:01:38  1        yes     n/a     no

N9K-2 - PIM 인접 디바이스 확인

N9K-2# show ip pim neighbor

PIM Neighbor Status for VRF "default"
Neighbor        Interface            Uptime    Expires   DR       Bidir-  BFD    ECMP Redirect
                                                         Priority Capable State     Capable
10.4.0.9        Ethernet1/3          23:21:18  00:01:29  1        yes     n/a     no
10.4.0.17       Ethernet1/4          23:21:18  00:01:23  1        yes     n/a     no
10.4.0.25       Ethernet1/49         23:21:18  00:01:44  1        yes     n/a     no

검증 지점

• 모든 라우티드 인터페이스에 예상되는 모든 네이버가 표시되는지 확인합니다.
• 네이버 가동 시간이 안정적이고 지속적으로 증가하는지 확인합니다.
• Expires 타이머가 주기적으로 새로 고쳐지는지 확인합니다.
• 예기치 않은 인접성 플랩이 발생하지 않는지 확인합니다.
• 올바른 DR(Designated Router) 선택을 확인합니다.
• 멀티캐스트 인터페이스가 PIM 인접성을 형성하는지 확인합니다.

이 토폴로지에서는

• N9K-1은 3개의 PIM 인접 디바이스를 설정합니다.
• N9K-2는 또한 3개의 PIM 인접 디바이스를 설정합니다.
• 모든 인접성은 23시간 이상 안정적으로 유지되며 이는 안정적인 멀티캐스트 컨트롤 플레인 작업을 나타냅니다.

---

4.2단계 PIM 지원 인터페이스 확인

다음 단계는 Auto-RP에 참여하는 모든 인터페이스가 PIM에 대해 활성화되었는지 확인하는 것입니다.

이 검증은 특히 다음에 중요합니다.

• RP 후보 루프백
• 에이전트 루프백 매핑

N9K-1 — PIM 인터페이스 확인

N9K-1# show ip pim interface brief

PIM Interface Status for VRF "default"
Interface            IP Address      PIM DR Address  Neighbor  Border
                                                     Count     Interface
Ethernet1/3          10.4.0.6        10.4.0.6        1         no
Ethernet1/4          10.4.0.13       10.4.0.14       1         no
Ethernet1/49         10.4.0.22       10.4.0.22       1         no
loopback0            10.2.0.1        10.2.0.1        0         no
loopback1            10.2.1.5        10.2.1.5        0         no

N9K-2 — PIM 인터페이스 확인

N9K-2# show ip pim interface brief

PIM Interface Status for VRF "default"
Interface            IP Address      PIM DR Address  Neighbor  Border
                                                     Count     Interface
Ethernet1/3          10.4.0.10       10.4.0.10       1         no
Ethernet1/4          10.4.0.18       10.4.0.18       1         no
Ethernet1/49         10.4.0.26       10.4.0.26       1         no
loopback0            10.2.0.4        10.2.0.4        0         no
loopback1            10.2.1.4        10.2.1.4        0         no

검증 지점:

• 모든 라우티드 멀티캐스트 인터페이스가 출력에 나타나는지 확인합니다.
• RP-Candidate 루프백이 PIM을 활성화했는지 확인합니다.
• 매핑 에이전트 루프백이 PIM을 활성화했는지 확인합니다.
• 트랜짓 인터페이스에서 네이버 카운트가 올바른지 확인합니다.
• 루프백 인터페이스에 Neighbor Count = 0이 올바르게 표시되는지 확인하십시오.

루프백 역할 할당:

디바이스	기능	루프백
N9K-1	RP 후보	10.2.0.1
N9K-1	매핑 에이전트	10.2.1.5
N9K-2	RP 후보	10.2.0.4
N9K-2	매핑 에이전트	10.2.1.4

루프백은 PIM 네이버를 형성하지 않는 경우에도 활성 PIM 인터페이스로 올바르게 표시됩니다. 루프백 인터페이스는 멀티캐스트 인접성을 직접 설정하지 않으므로 이 동작이 예상됩니다.

이러한 루프백이 있으면 다음을 확인할 수 있습니다.

• PIM은 Auto-RP 제어 메시지를 올바르게 소싱할 수 있습니다.
• RP 광고를 성공적으로 시작할 수 있습니다.
• 매핑 에이전트 기능이 제대로 작동할 수 있습니다.

---

4.3단계 show ip pim rp 분석

이 명령은 다음을 확인합니다.

• RP 검색
• Auto-RP 광고
• 매핑 에이전트 작업
• Group-to-RP 매핑

N9K-1 - RP 정보

N9K-1# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5*, next Discovery message in: 00:00:39
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.1*, (0),
 uptime: 22:18:44   priority: 255,
 RP-source: 10.2.0.1 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:00:37 (A)

RP: 10.2.0.4, (0),
 uptime: 23:00:32   priority: 255,
 RP-source: 10.2.0.4 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:00:44 (A)

Line-by-Line 설명

BSR 사용 안 함

BSR disabled

이를 통해 다음을 확인할 수 있습니다.

• BSR(Bootstrap Router)은 사용되지 않습니다.
• 멀티캐스트 도메인은 Auto-RP에만 의존합니다.

이 토폴로지에서는 이러한 동작이 필요합니다.

자동 RP RPA: 10.2.1.5*

Auto-RP RPA: 10.2.1.5*

• 10.2.1.5는 N9K-1의 루프백1에 해당합니다.
• *는 로컬 스위치 자체가 활성 매핑 에이전트임을 나타냅니다.

이는 다음을 의미합니다.

• N9K-1은 RP-Discovery 메시지를 시작합니다.
• N9K-1은 RP-Candidates에서 RP 공지를 수집합니다.
• N9K-1은 RP 매핑 정보를 멀티캐스트 도메인에 배포합니다.

다음 검색 메시지

next Discovery message in: 00:00:39

• 타이머가 계속 새로 고쳐지는지 확인합니다.
• 검색 메시지가 주기적으로 전송되는지 확인합니다.

이 타이머가 갑자기 멈추거나 만료되면 Auto-RP 광고가 올바르게 전파될 수 없습니다.

정책 필드

BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

• 적용된 필터링 정책이 없습니다.
• 모든 RP 공지 및 검색 광고가 허용됩니다.

첫 번째 RP 엔트리

RP: 10.2.0.1*, (0),

• RP 주소 = 10.2.0.1
• *는 이 RP가 N9K-1에 로컬임을 나타냅니다.
• 10.2.0.1은 N9K-1의 루프백0에 해당합니다.

이렇게 하면 N9K-1이 RP-Candidate로 구성되었음을 확인할 수 있습니다.

가동 시간 및 우선 순위

uptime: 22:18:44   priority: 255,

• 안정적인 가동 시간은 안정적인 RP 광고 작업을 나타냅니다.
• 우선순위 255가 기본 최고 우선순위입니다.

RP 소스

RP-source: 10.2.0.1 (A),

• RP 광고는 RP 자체에서 직접 시작되었습니다.
• (A)는 Auto-RP에서 학습한 정보를 나타냅니다.

그룹 범위

224.10.20.0/24

• 올바른 멀티캐스트 범위가 알려졌는지 확인합니다.
• 그룹 범위가 컨피그레이션과 일치하는지 확인합니다.

두 번째 RP 항목

RP: 10.2.0.4, (0),

• 토폴로지에 다른 RP가 있습니다.
• 10.2.0.4는 N9K-2의 루프백0에 해당합니다.
• 이 RP가 N9K-1에서 원격이므로 *가 나타나지 않습니다.

N9K-2 - RP 정보

N9K-2# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 22:19:10, expires: 00:02:28

RP: 10.2.0.4*, (0),
 uptime: 23:14:14   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:28 (A)

N9K-2의 주요 차이점

Auto-RP RPA: 10.2.1.5

• N9K-2가 매핑 에이전트가 아니므로 *가 나타나지 않습니다.
• N9K-2는 N9K-1로부터 매핑 에이전트 정보를 원격으로 학습합니다.

중요한 RP 차이

RP-source: 10.2.1.5 (A),

• N9K-2는 매핑 에이전트에서 RP 정보를 학습합니다.
• 매핑 에이전트는 10.2.1.5입니다.

이를 통해 다음을 확인할 수 있습니다.

• Auto-RP 검색 메시지가 올바르게 작동하고 있습니다.
• 매핑 에이전트 알림이 멀티캐스트 도메인을 통해 성공적으로 전파됩니다.

4.4단계 Auto-RP 선택 프로세스 및 RP 선택 검증

Auto-RP는 두 가지 다른 멀티캐스트 컨트롤 플레인 기능을 사용합니다.

• RP 후보
• 매핑 에이전트

PIM Sparse Mode 환경에서 멀티캐스트 작업을 검증할 때는 이러한 함수가 상호 작용하는 방식을 이해하는 것이 중요합니다.

이 토폴로지에서는

• N9K-1 및 N9K-2는 RP 후보로 작동합니다.
• N9K-1은 활성 매핑 에이전트로 작동합니다.

RP 후보 작업

RP-Candidate는 자신을 하나 이상의 멀티캐스트 그룹 범위에 대해 유효한 Rendezvous Point로 광고합니다.

각 RP-Candidate는 주기적으로 Auto-RP Announce 메시지를 다음 주소로 전송합니다.

• 224.0.1.39 — Auto-RP Announce 그룹
  
  

이러한 발표에는 다음이 포함됩니다.

• RP 주소
• 그룹 범위
• 우선순위
• Holdtime

이 토폴로지에서는

• N9K-1의 10.2.0.1은 자신을 RP로 광고합니다.
• N9K-2의 10.2.0.4는 자신을 RP로 광고합니다.

N9K-1 — RP 후보 정보

N9K-1# show ip pim rp
<snip>
RP: 10.2.0.1*, (0),
 uptime: 23:11:22 priority: 255,
 RP-source: 10.2.0.1 (A),
 group ranges:
 224.10.20.0/24 , expires: 00:00:38 (A)

RP: 10.2.0.4, (0),
 uptime: 23:53:09 priority: 255,
 RP-source: 10.2.0.4 (A),
 group ranges:
 224.10.20.0/24 , expires: 00:00:43 (A)

N9K-2 — RP 후보 정보

N9K-2# show ip pim rp
<snip>
RP: 10.2.0.4*, (0),
 uptime: 1d00h priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24 , expires: 00:02:52 (A)

두 디바이스 모두 동일한 멀티캐스트 그룹 범위를 알립니다.

• 224.10.20.0/24

두 RP 후보 모두 다음을 사용합니다.

• 우선 순위 255

이는 Auto-RP가 RP 선택 시 우선 순위 및 RP 주소를 사용하기 때문에 중요합니다.

활성 매핑 에이전트 식별

매핑 에이전트는 다음 논리로 시작하는 멀티캐스트 그룹에 대한 활성 RP를 선택합니다.

1. 가장 높은 RP 우선 순위가 이깁니다.
2. 우선순위가 같으면 가장 높은 RP IP 주소가 성공합니다.

이 토폴로지에서는

• N9K-1 RP 주소 = 10.2.0.1
• N9K-2 RP 주소 = 10.2.0.4
• 두 RP 후보 모두 우선순위 255를 사용합니다.

두 RP 후보 모두 우선순위가 동일하기 때문입니다.

• 가장 높은 RP IP 주소가 선택한 RP가 됩니다.

따라서

• 10.2.0.4는 224.10.20.0/24에 대한 활성 RP가 됩니다.

선택한 RP 검증

N9K-2 - 선택한 RP

N9K-2# show ip pim rp
<snip>
RP: 10.2.0.4*, (0),
 uptime: 23:14:14   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24

N9K-1이 여전히 두 RP 엔트리를 표시하는 이유

N9K-1:

N9K-1# show ip pim rp
<snip>
RP: 10.2.0.1*, (0),
RP: 10.2.0.4, (0),

이 동작은 다음과 같은 이유 때문에 발생합니다.

• N9K-1은 매핑 에이전트로 작동합니다.
• 매핑 에이전트는 모든 RP-Candidate에 대한 가시성을 유지합니다.
• 출력은 최종 RP 선택이 분배되기 전에 모든 학습된 RP 공지를 표시한다.

5단계: RP 후보 및 매핑 에이전트에 대한 연결성 확인

PIM Sparse Mode 도메인에 참여하는 모든 멀티캐스트 라우터는 안정적인 IP 연결 상태를 유지해야 다음을 수행할 수 있습니다.

• 모든 RP 후보
• 모든 매핑 에이전트

PIM Sparse Mode는 다음과 같은 유니캐스트 라우팅을 사용하기 때문에 이러한 검증이 중요합니다.

• RP(Rendezvous Point)에 연결
• RPT(Shared Multicast Tree) 구축
• FHR(First Hop Router)에서 PIM 레지스터 메시지 전달
• Auto-RP 검색 광고 수신
• RPF(Reverse Path Forwarding) 검증 수행

RP 또는 매핑 에이전트에 대한 연결이 실패할 경우:

• 멀티캐스트 소스가 성공적으로 등록되지 않을 수 있습니다.
• 수신자는 멀티캐스트 그룹에 참가하지 못할 수 있습니다.
• Auto-RP 광고를 올바르게 전파할 수 없습니다.
• RPF 오류가 발생할 수 있습니다.
• 멀티캐스트 트래픽 포워딩이 불안정해지거나 간헐적으로 변할 수 있습니다.

---

안정적인 라우팅 엔트리 확인

라우팅 테이블은 다음에 대한 안정적인 유니캐스트 경로를 포함해야 합니다.

• 모든 RP 루프백
• 모든 매핑 에이전트 루프백
• 모든 멀티캐스트 트랜짓 인터페이스

경로는 경로 플래핑 또는 과도한 리컨버전스 이벤트 없이 지속적으로 설치된 상태를 유지해야 합니다.

확인:

• 올바른 next-hop 선택
• 올바른 발송 인터페이스
• 안정적인 경로 가동 시간
• 예상 라우팅 프로토콜 원본
• 멀티캐스트 도메인 전체에서 일관된 유니캐스트 연결

---

FHR-1 — RP 후보 10.2.0.1에 대한 경로

FHR-1# show ip route 10.2.0.1

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.1/32, ubest/mbest: 1/0
    *via 10.4.0.6, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-1 — RP 후보 10.2.0.4로 경로 지정

FHR-1# show ip route 10.2.0.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.4/32, ubest/mbest: 1/0
    *via 10.4.0.10, Eth1/1, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-1 — 매핑 에이전트 10.2.1.5에 대한 경로

FHR-1# show ip route 10.2.1.5

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.5/32, ubest/mbest: 1/0
    *via 10.4.0.6, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-1 — 매핑 에이전트 10.2.1.4에 대한 경로

FHR-1# show ip route 10.2.1.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.4/32, ubest/mbest: 1/0
    *via 10.4.0.10, Eth1/1, [110/5], 1d02h, ospf-UNDERLAY, intra

---

FHR-2 — RP 후보 10.2.0.1에 대한 경로

FHR-2# show ip route 10.2.0.1

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.1/32, ubest/mbest: 1/0
    *via 10.4.0.13, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-2 — RP 후보 10.2.0.4로 경로 지정

FHR-2# show ip route 10.2.0.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.4/32, ubest/mbest: 1/0
    *via 10.4.0.18, Eth1/4, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-2 — 매핑 에이전트 10.2.1.5에 대한 경로

FHR-2# show ip route 10.2.1.5

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.5/32, ubest/mbest: 1/0
    *via 10.4.0.13, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-2 — 매핑 에이전트 10.2.1.4에 대한 경로

FHR-2# show ip route 10.2.1.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.4/32, ubest/mbest: 1/0
    *via 10.4.0.18, Eth1/4, [110/5], 1d02h, ospf-UNDERLAY, intra

---

LHR — RP 후보 10.2.0.1에 대한 경로

LHR# show ip route 10.2.0.1

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.1/32, ubest/mbest: 1/0
    *via 10.4.0.22, Eth1/49, [110/2], 1d02h, ospf-UNDERLAY, intra

LHR — RP 후보 10.2.0.4에 대한 경로

LHR# show ip route 10.2.0.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.4/32, ubest/mbest: 1/0
    *via 10.4.0.26, Eth1/50, [110/2], 1d02h, ospf-UNDERLAY, intra

LHR — 매핑 에이전트 10.2.1.5에 대한 경로

LHR# show ip route 10.2.1.5

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.5/32, ubest/mbest: 1/0
    *via 10.4.0.22, Eth1/49, [110/2], 1d02h, ospf-UNDERLAY, intra

LHR — 매핑 에이전트 10.2.1.4에 대한 경로

LHR# show ip route 10.2.1.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.4/32, ubest/mbest: 1/0
    *via 10.4.0.26, Eth1/50, [110/2], 1d02h, ospf-UNDERLAY, intra

---

PIM 인터페이스에서 Ping 연결성 확인

라우팅 테이블을 검증한 후 다음에 대한 엔드 투 엔드 IP 연결성을 확인합니다.

• 모든 RP 후보
• 모든 매핑 에이전트

ping의 출처는 다음과 같습니다.

• PIM 지원 인터페이스
• 멀티캐스트 라우팅에 참여하는 루프백 인터페이스

멀티캐스트 라우터는 다음 과정에서 이러한 소스 주소를 사용하므로 이러한 검증이 중요합니다.

• PIM 네이버 설정
• RPF 계산
• PIM 레지스터 캡슐화
• Auto-RP 통신

Ping 검증 요약

디바이스	소스 IP	대상	기능	결과
FHR-1	10.4.0.5	10.2.0.1	RP 후보	성공
FHR-1	10.4.0.5	10.2.0.4	RP 후보	성공
FHR-1	10.4.0.5	10.2.1.5	매핑 에이전트	성공
FHR-1	10.4.0.5	10.2.1.4	매핑 에이전트	성공
FHR-2	10.4.0.9	10.2.0.1	RP 후보	성공
FHR-2	10.4.0.9	10.2.0.4	RP 후보	성공
FHR-2	10.4.0.9	10.2.1.5	매핑 에이전트	성공
FHR-2	10.4.0.9	10.2.1.4	매핑 에이전트	성공
LHR	10.4.0.5	10.2.0.1	RP 후보	성공
LHR	10.4.0.5	10.2.0.4	RP 후보	성공
LHR	10.4.0.5	10.2.1.5	매핑 에이전트	성공
LHR	10.4.0.5	10.2.1.4	매핑 에이전트	성공

FHR 및 LHR에서 운영 상태 및 멀티캐스트 트래픽 포워딩 확인

다음 검증 단계에서는 다음을 확인합니다.

• FHR과 LHR이 예상 RP를 학습했습니다.
• 멀티캐스트 라우팅 테이블에 예상 멀티캐스트 상태가 포함되어 있습니다.
• 멀티캐스트 트래픽 전송이 시작되기 전에 멀티캐스트 컨트롤 플레인이 올바르게 작동합니다.
• PIM Sparse Mode는 필요한 공유 트리 상태를 작성합니다.

---

1단계 FHR 및 LHR에서 RP 학습 확인

멀티캐스트 전달 상태를 검증하기 전에 모든 멀티캐스트 라우터가 검증 중에 멀티캐스트 그룹에 대한 예상 RP를 학습했는지 확인합니다.

이 단계는 다음과 같은 이유로 중요합니다.

• FHR은 PIM 레지스터 메시지를 보낼 위치를 알아야 합니다.
• LHR은 공유 트리를 구축할 때 사용할 RP를 알고 있어야 합니다.
• 멀티캐스트 도메인은 일관된 RP 매핑을 유지해야 합니다.

이 토폴로지에서는

• 선택한 RP는 10.2.0.4입니다.
• 매핑 에이전트는 10.2.1.5입니다.
• 멀티캐스트 그룹 범위는 224.10.20.0/24입니다.

---

FHR-1 — 학습된 RP 확인

FHR-1# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:30
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.4, (0),
 uptime: 1d03h   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:30 (A)

FHR-2 — 학습된 RP 확인

FHR-2# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:15
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.4, (0),
 uptime: 1d03h   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:15 (A)

LHR — 학습된 RP 확인

LHR# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:07
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.4, (0),
 uptime: 1d03h   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:07 (A)

---

RP 학습 분석

출력에서 확인할 수 있는 사항은 다음과 같습니다.

• 모든 멀티캐스트 라우터가 동일한 RP를 일관되게 학습했습니다.
• 선택한 RP는 10.2.0.4입니다.
• RP 매핑은 Auto-RP를 통해 학습되었습니다.
• RP 정보를 배포하는 매핑 에이전트는 10.2.1.5입니다.
• RP 매핑은 1일 이상 안정적으로 유지됩니다.
• 검색 만료 타이머가 올바르게 새로 고쳐집니다.

이 동작은 다음과 같은 이유 때문에 발생합니다.

• Auto-RP 선택 과정에서 10.2.0.4가 활성 RP로 선택되었습니다.
• 10.2.1.5는 매핑 에이전트로 작동합니다.
• 모든 멀티캐스트 라우터가 성공적으로 Auto-RP 검색 알림을 수신합니다.

이 단계에서 멀티캐스트 컨트롤 플레인이 올바르게 작동하며 모든 라우터는 224.10.20.0/24에 대해 일관된 RP 매핑을 갖습니다

---

2단계 활성 멀티캐스트 트래픽 전에 멀티캐스트 라우팅 상태 확인

다음 단계는 멀티캐스트 트래픽 전송이 시작되기 전에 멀티캐스트 라우팅 테이블을 검증하는 것입니다.

이 시나리오에서:

• 멀티캐스트 수신자가 이미 멀티캐스트 그룹에 가입했습니다.
• 활성 멀티캐스트 소스 트래픽이 아직 흐르지 않습니다.

이 상태는 다음을 검증하기 때문에 중요합니다.

• IGMP 멤버십 작업
• PIM 공유 트리 생성
• 초기(*,G) 멀티캐스트 상태
• 수신기 이자 전파

FHR-1 — 멀티캐스트 라우팅 테이블

FHR-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 23:07:34, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

FHR-2 - 멀티캐스트 라우팅 테이블

FHR-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 23:07:37, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

---

FHR 멀티캐스트 상태 분석

FHR에는 아직 다음 항목이 포함되어 있지 않습니다.

• 224.10.20.10의 경우 (*,G) 상태
• 멀티캐스트 소스의 (S,G) 상태

이 동작은 다음과 같은 이유 때문에 발생합니다.

• 아직 활성 상태인 멀티캐스트 소스 트래픽이 없습니다.
• PIM 등록 메시지가 생성되지 않았습니다.
• FHR이 멀티캐스트 전달을 시작하지 않았습니다.

멀티캐스트 항목은 다음과 같습니다.

• 232.0.0.0/8

이는 기본 SSM 범위에 해당하며 시스템에서 자동으로 설치합니다.

이 값은 다음과 같습니다.

• 수신 인터페이스: Null
• RPF 네이버: 0.0.0.0
• 발송 인터페이스 수: 0

이 항목은 활성 멀티캐스트 전달을 나타내지 않습니다.

---

LHR — 멀티캐스트 라우팅 테이블

LHR# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 23:07:39, igmp ip pim
  Incoming interface: Ethernet1/50, RPF nbr: 10.4.0.26
  Outgoing interface list: (count: 1)
    Vlan2, uptime: 23:07:39, igmp

(*, 232.0.0.0/8), uptime: 23:07:39, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

LHR 멀티캐스트 상태 분석

FHR과 달리 LHR에는 다음에 대한 활성(*,G) 항목이 포함되어 있습니다.

• 224.10.20.10

이 동작은 다음과 같은 이유 때문에 발생합니다.

• 멀티캐스트 수신자가 이미 그룹에 가입했습니다.
• VLAN2에서 IGMP 멤버십 정보를 학습했습니다.
• LHR이 RP를 향한 공유 트리 조인을 시작했습니다.

멀티캐스트 라우팅 테이블은 다음을 확인합니다.

• IIF(Incoming Interface)는 Ethernet1/50입니다.
• RPF 인접 디바이스는 10.4.0.26입니다.
• OIL(Outgoing Interface List)에는 Vlan2가 포함되어 있습니다.

이는 다음을 나타냅니다.

• LHR은 RP를 향해 공유 트리를 올바르게 구축했습니다.
• 멀티캐스트 수신기 정보가 업스트림으로 전파되었습니다.
• PIM 가입 메시지가 올바르게 전송되었습니다.

이 단계에서는 다음을 수행합니다.

• 아직 활성 상태인 멀티캐스트 소스 트래픽이 없습니다.
• (S,G) 상태가 아직 없습니다.
• 공유 트리 상태만 존재합니다.

---

N9K-1 — 매핑 에이전트 멀티캐스트 라우팅 테이블

N9K-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 1d03h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

매핑 에이전트 멀티캐스트 상태 분석

N9K-1은 매핑 에이전트로만 작동하며 224.10.20.10에 대한 멀티캐스트 전달에는 참여하지 않습니다

따라서 (*,G) 항목과 (S,G) 항목이 없을 것으로 예상됩니다.

매핑 에이전트는 RP 매핑 정보만 배포하며, 멀티캐스트 트래픽이 디바이스를 직접 통과하지 않는 한 멀티캐스트 데이터 전달에 반드시 참여할 필요는 없습니다.

---

N9K-2 — RP 멀티캐스트 라우팅 테이블

N9K-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 1d01h, pim ip
  Incoming interface: loopback0, RPF nbr: 10.2.0.4
  Outgoing interface list: (count: 1)
    Ethernet1/49, uptime: 1d01h, pim

(*, 232.0.0.0/8), uptime: 1d03h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

RP 멀티캐스트 상태 분석

N9K-2는 다음에 대한 활성 RP로 작동합니다.

• 224.10.20.0/24

따라서 RP에는 224.10.20.10에 대한 공유 트리(*,G) 상태가 포함됩니다

이 값은 다음과 같습니다.

• 수신 인터페이스 = 루프백0
• RPF 인접 디바이스 = 10.2.0.4
• 발송 인터페이스 = Ethernet1/49

이는 다음을 나타냅니다.

• RP에서 공유 트리 상태를 설치했습니다.
• RP가 다운스트림 라우터에서 PIM Join 메시지를 받았습니다.
• 수신자에 대한 공유 멀티캐스트 트리가 올바르게 작성되었습니다.

이 단계에서는 다음을 수행합니다.

• RP에는 공유 트리 상태만 포함됩니다.
• 아직 활성 상태인 멀티캐스트 소스 트래픽이 없습니다.
• (S,G) 항목이 아직 없습니다.

---

3단계 활성 멀티캐스트 트래픽으로 멀티캐스트 라우팅 상태 확인

멀티캐스트 트래픽 전송이 시작되면 멀티캐스트 라우팅 테이블이 공유 트리 상태에서 활성 소스별 포워딩 상태로 전환됩니다.

이 시나리오에서:

• 멀티캐스트 소스는 10.150.1.37입니다.
• 멀티캐스트 그룹은 224.10.20.10입니다.
• 활성 RP는 N9K-2에서 10.2.0.4입니다.
• 멀티캐스트 소스는 vPC 포트 채널 78을 통해 연결됩니다.

---

중요 vPC 멀티캐스트 고려 사항

멀티캐스트 소스는 FHR-1 및 FHR-2에 의해 형성된 vPC 도메인을 통해 연결됩니다.

소스가 vPC 멤버 포트 채널을 통해 연결되므로

• 트래픽 해싱은 멀티캐스트 패킷을 Nexus 스위치로 전달할 수 있습니다.
• 두 FHR 모두 동일한 멀티캐스트 컨피그레이션이 필요합니다.
• 두 FHR 모두 일관된 유니캐스트 라우팅 정보가 필요합니다.
• 두 FHR은 동일한 RP 매핑을 유지해야 합니다.
• 두 FHR 모두 안정적인 PIM 인접성을 유지해야 합니다.

이 시나리오에서는 다음을 수행합니다.

• 멀티캐스트 흐름이 FHR-2로 해쉬됩니다.
• FHR-2는 멀티캐스트 소스에 대한 활성 전달 FHR이 됩니다.

FHR-1 — 멀티캐스트 라우팅 테이블

FHR-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:03:58, ip pim
  Incoming interface: Vlan1, RPF nbr: 10.150.1.37
  Outgoing interface list: (count: 0)

(*, 232.0.0.0/8), uptime: 1d00h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

FHR-1 - vPC 역할

FHR-1# show vpc role

vPC Role status
----------------------------------------------------
vPC role                        : primary <<<
Dual Active Detection Status    : 0
vPC system-mac                  : 00:23:04:ee:be:01
vPC system-priority             : 32667
vPC local system-mac            : 00:6b:f1:84:02:97
vPC local role-priority         : 32667
vPC local config role-priority  : 32667
vPC peer system-mac             : 6c:b2:ae:ee:5a:97
vPC peer role-priority          : 32667
vPC peer config role-priority   : 32667

FHR-1 멀티캐스트 상태 분석

FHR-1에는 다음에 대한 활성(S,G) 항목이 포함되어 있습니다.

• 출처 = 10.150.1.37
• 그룹 = 224.10.20.10

멀티캐스트 라우팅 엔트리는 다음을 확인합니다.

• 소스는 Vlan1에서 학습되었습니다.
• RPF 인접 디바이스는 직접 연결된 멀티캐스트 소스입니다.
• OIL에 발신 인터페이스가 없습니다.

멀티캐스트 플로우가 아웃바운드 포워딩을 위해 FHR-1로 해시되지 않았기 때문에 이러한 동작이 예상됩니다.

그 결과

• FHR-1은 로컬 소스 상태만 설치합니다.
• FHR-1은 PIM을 통해 멀티캐스트 트래픽을 업스트림으로 전달하지 않습니다.

FHR-2 - 멀티캐스트 라우팅 테이블

FHR-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:16:35, ip pim
  Incoming interface: Vlan1, RPF nbr: 10.150.1.37
  Outgoing interface list: (count: 1)
    Ethernet1/3, uptime: 00:16:35, pim

(*, 232.0.0.0/8), uptime: 1d00h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

FHR-2 - vPC 역할

FHR-2# show vpc role

vPC Role status
----------------------------------------------------
vPC role                        : secondary <<<
Dual Active Detection Status    : 0
vPC system-mac                  : 00:23:04:ee:be:01
vPC system-priority             : 32667
vPC local system-mac            : 6c:b2:ae:ee:5a:97
vPC local role-priority         : 32667
vPC local config role-priority  : 32667
vPC peer system-mac             : 00:6b:f1:84:02:97
vPC peer role-priority          : 32667
vPC peer config role-priority   : 32667

FHR-2 멀티캐스트 상태 분석

FHR-1과 달리 FHR-2에는 다음이 포함됩니다.

• 활성 발신 인터페이스 목록
• 활성 PIM 전달 경로

이는 다음을 나타냅니다.

• FHR-2는 멀티캐스트 플로우에 대한 운영 포워딩 FHR이 되었습니다.
• 멀티캐스트 패킷이 vPC 멤버 포트 채널을 통해 FHR-2로 해시되었습니다.
• FHR-2는 멀티캐스트 트래픽을 PIM 레지스터 메시지로 캡슐화했습니다.
• FHR-2는 RP를 향해 멀티캐스트 트래픽을 업스트림으로 전달했습니다.

ECMP 및 멀티캐스트 포워딩 동작

발신 인터페이스 Ethernet1/3은 유니캐스트 라우팅 테이블을 수신기 192.168.2.37에 일치시킵니다

FHR-2 - 멀티캐스트 수신자에 대한 경로

FHR-2# show ip route 192.168.2.37

IP Route Table for VRF "default"

'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.168.2.0/24, ubest/mbest: 2/0
    *via 10.4.0.13, Eth1/3, [110/45], 1d02h, ospf-UNDERLAY, intra
    *via 10.4.0.18, Eth1/4, [110/45], 1d02h, ospf-UNDERLAY, intra

FHR-2는 멀티캐스트 수신기 서브넷을 향하는 2개의 동일 비용 경로를 포함합니다.

• 10.4.0.13~Ethernet1/3
• 10.4.0.18~Ethernet1/4

이를 통해 다음을 확인할 수 있습니다.

• ECMP 라우팅은 멀티캐스트 전송 토폴로지에서 활성 상태입니다.
• 수신기 네트워크에 유효한 여러 유니캐스트 포워딩 경로가 있습니다.
• PIM은 멀티캐스트 전달 결정을 위해 MRIB 선택 RPF 경로를 사용할 수 있습니다.
• 병렬 ECMP 경로 간의 패킷 중복은 발생하지 않습니다.

동일 비용 경로가 2개 있지만 멀티캐스트 전달은 각 멀티캐스트 흐름에 대해 단일 RPF 경로를 사용합니다.

이 토폴로지에서는 멀티캐스트 플로우에서 다음을 사용합니다.

• 10.4.0.13으로 향하는 이더넷1/3

이 동작은 이전에 관찰된 멀티캐스트 라우팅 테이블과 일치합니다.

(10.150.1.37/32, 224.10.20.10/32)
  Outgoing interface list:
    Ethernet1/3

---

vPC 운영 기본 및 보조 동작

vPC 운영 역할은 다음에 대해 멀티캐스트 전달 동작에 다른 영향을 미칩니다.

• PIM 트래픽
• IGMP 처리

이 토폴로지에서는

• FHR-1은 운영 중인 vPC입니다.
• FHR-2는 운영 중인 vPC 보조 서버입니다.

두 Nexus 스위치 모두 다음을 수행할 수 있습니다.

• PIM 컨트롤 플레인 트래픽 처리
• 멀티캐스트 라우팅 상태 구축
• PIM을 통해 멀티캐스트 트래픽 전달

그러나:

• 작동 중인 vPC 기본만 액세스 레이어를 향해 IGMP 수신기 트래픽을 처리합니다.

이러한 구분은 다음과 같은 이유로 중요합니다.

• 라우팅된 네트워크로 향하는 PIM 포워딩은 두 피어 모두에서 활성 상태로 유지됩니다.
• 레이어 2 수신기 세그먼트로 향하는 IGMP 포워딩은 운영 프라이머리(operational primary)에서 중앙 집중식으로 유지됩니다.

따라서

• 소스에서 라우팅된 멀티캐스트 도메인으로 향하는 멀티캐스트 트래픽은 vPC 피어 중 하나를 통해 나갈 수 있습니다.
• IGMP 수신기로의 멀티캐스트 트래픽은 운영 기본 동작에 의존합니다.

---

LHR — 멀티캐스트 라우팅 테이블

LHR# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 1d00h, igmp ip pim
  Incoming interface: Ethernet1/50, RPF nbr: 10.4.0.26
  Outgoing interface list: (count: 1)
    Vlan2, uptime: 1d00h, igmp

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:31, ip mrib pim
  Incoming interface: Ethernet1/49, RPF nbr: 10.4.0.22
  Outgoing interface list: (count: 1)
    Vlan2, uptime: 00:06:31, mrib

(*, 232.0.0.0/8), uptime: 1d00h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

LHR 멀티캐스트 상태 분석

이제 LHR에는 다음 두 가지 사항이 모두 포함됩니다.

• (*,G) 공유 트리 상태
• (S,G) 소스 트리 상태

이를 통해 다음을 확인할 수 있습니다.

• 멀티캐스트 수신자가 연결되었습니다.
• 멀티캐스트 소스가 활성화되었습니다.
• LHR이 공유 트리 전달에서 소스 트리 전달로 전환되었습니다.

(S,G) 항목은 다음을 확인합니다.

• 멀티캐스트 소스 경로를 학습했습니다.
• RPF 인접 디바이스는 10.4.0.22입니다.
• 멀티캐스트 트래픽이 Ethernet1/49를 통해 도착합니다.
• 멀티캐스트 트래픽은 Vlan2 수신기로 전달됩니다.

이 동작이 성공적으로 확인됩니다.

• PIM 전달
• RPF 검증
• 소스 트리 구성
• 멀티캐스트 트래픽 전달

---

N9K-1 — 전송 멀티캐스트 라우팅 테이블

N9K-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:42, pim ip
  Incoming interface: Ethernet1/4, RPF nbr: 10.4.0.14
  Outgoing interface list: (count: 1)
    Ethernet1/49, uptime: 00:06:42, pim

(*, 232.0.0.0/8), uptime: 1d04h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

N9K-1 수송 상태 분석

N9K-1은 활성 멀티캐스트 흐름을 위한 트랜짓 멀티캐스트 라우터로 작동합니다.

멀티캐스트 라우팅 엔트리는 다음을 확인합니다.

• 멀티캐스트 트래픽은 Ethernet1/4에서 전달됩니다.
• 멀티캐스트 트래픽은 Ethernet1/49로 전달됩니다.
• LHR로 향하는 멀티캐스트 전달 경로가 작동 중입니다.

확인 결과:

• PIM 네이버 작업
• RPF 검증
• 트랜짓 네트워크를 통한 멀티캐스트 포워딩

---

N9K-2 — RP 멀티캐스트 라우팅 테이블

N9K-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 1d02h, pim ip
  Incoming interface: loopback0, RPF nbr: 10.2.0.4
  Outgoing interface list: (count: 1)
    Ethernet1/49, uptime: 1d02h, pim

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:50, ip pim mrib
  Incoming interface: Ethernet1/4, RPF nbr: 10.4.0.17, internal
  Outgoing interface list: (count: 0)

(*, 232.0.0.0/8), uptime: 1d04h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

RP 멀티캐스트 상태 분석

N9K-2는 멀티캐스트 그룹에 대한 활성 RP로 작동합니다.

RP에는 다음 두 가지가 모두 포함됩니다.

• (*,G) 공유 트리 상태
• (S,G) 소스 트리 상태

다음과 같은 이유로 (S,G) 항목에 발신 인터페이스가 없을 것으로 예상됩니다.

• RP는 수신기를 이미 최단 경로 트리로 전환했습니다.
• 활성 멀티캐스트 전달에는 공유 트리 전달 경로가 더 이상 필요하지 않습니다.

RCA 및 상태 진단에 필요한 최소 멀티캐스트 정보

명령 목록은 NX-OS를 실행하는 Cisco Nexus 9000 Series 스위치에서 적절한 RCA(Root Cause Analysis) 또는 멀티캐스트 상태 진단을 수행하는 데 필요한 최소 권장 멀티캐스트 데이터 수집을 제공합니다. 이러한 출력은 멀티캐스트 컨트롤 플레인 상태, MRIB 프로그래밍, 포워딩 정보, vPC 작동 상태 및 하드웨어 포워딩 세부사항을 캡처합니다. 그러나 장애 시나리오에 따라 추가 정보가 필요할 수 있습니다. 예를 들어, 멀티캐스트 패킷 손실, 간헐적 트래픽 삭제, 패킷 복제 문제, 하드웨어 포워딩 불일치 또는 비순차적 멀티캐스트 포워딩을 수행하려면 Ethanalyzer, SPAN 또는 하드웨어 레벨 캡처를 사용하여 Nexus 스위치에서 직접 패킷 캡처를 수행해야 하는 경우가 많습니다. 마찬가지로, 영구적인 로그 생성 없이 일시적인 RPF 불일치, ECMP 포워딩 변경, ASIC 프로그래밍 실패 또는 IGMP 억제 이벤트가 발생할 수 있습니다.

따라서 show tech 출력과 패킷 캡처 및 포워딩 검증을 결합하면 진단 정확도와 RCA 품질이 크게 향상됩니다. 이 정보는 멀티캐스트 트러블슈팅을 위한 강력한 운영 기준을 제공하지만, RCA가 항상 이러한 출력에서 배타적으로 식별될 수 있다고 보장하지는 않습니다. 특정 멀티캐스트 장애의 경우 정확한 근본 원인을 파악하기 위해 추가 트러블슈팅, 라이브 트래픽 분석, 하드웨어 레벨 검증, 토폴로지 상관관계 또는 확장 패킷 캡처가 필요합니다.

최소 멀티캐스트 데이터 수집 명령

N9K-1# show tech-support multicast >> bootflash:$(SWITCHNAME)-sh-tech-multicast.txt

N9K-1# show tech-support details >> bootflash:$(SWITCHNAME)-sh-tech-det.txt

N9K-1# show tech-support vpc >> bootflash:$(SWITCHNAME)-sh-tech-vpc.txt

N9K-1# show tech-support forwarding multicast >> bootflash:$(SWITCHNAME)-sh-tech-fwd-multicast.txt

N9K-1# show tech-support forwarding l3 multicast detail vdc-all >> bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-multicast.txt

N9K-1# show tech-support forwarding l3 unicast detail vdc-all >> bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-unicast-det.txt

내보내기를 위한 TAR 아카이브 생성

show tech 파일을 생성한 후 내보내기 및 분석을 위해 단일 TAR 아카이브로 통합합니다. 이 명령은 한 줄입니다.

N9K-1# tar create bootflash:$(SWITCHNAME)-multicast-logs
bootflash:$(SWITCHNAME)-sh-tech-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-det.txt
bootflash:$(SWITCHNAME)-sh-tech-vpc.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-unicast-det.txt

단일 TAR 아카이브를 내보내면 다음과 같은 작업이 간소화됩니다.

• TAC 케이스 업로드
• RCA 워크플로
• 중앙 집중식 로그 분석
• 멀티캐스트 전달 상관관계
• 기록 장애 보존

개정 이력

개정	게시 날짜	의견
1.0	13-May-2026	최초 릴리스