이 페이지의 내용
IGMP 구성
그룹 구성원 프로토콜 이해
호스트와 라우팅 디바이스 간에 사용되는 멀티캐스트 프로토콜과 멀티캐스트 라우팅 디바이스 자체 간에는 큰 차이가 있습니다. 특정 서브네트워크의 호스트는 특정 멀티캐스트 그룹에서 패킷을 수신하는 데 관심이 있는지 여부만 라우팅 디바이스에 알려야 합니다. 소스 호스트는 라우팅 디바이스에 특정 멀티캐스트 그룹에 대한 트래픽 소스라는 사실만 알려야 합니다. 즉, 호스트에서 배포 트리에 대한 자세한 지식이 필요하지 않습니다. 라우팅 디바이스에 멀티캐스트 그룹 참여를 알리는 데는 그룹 멤버십 프로토콜만 필요합니다. 반면, 인접한 라우팅 디바이스 간에 멀티캐스트 라우팅 프로토콜은 소스에서 리프까지 네트워크 토폴로지 및 분산 트리에 대한 상세한 감각을 구축하므로 루프를 피해야 합니다. 따라서 멀티캐스트 네트워크의 호스트-라우터 부분과 라우터-라우터 부분에 서로 다른 멀티캐스트 프로토콜이 사용됩니다.
멀티캐스트 그룹 멤버십 프로토콜을 사용하면 라우팅 디바이스가 직접 연결된 서브넷(일반적으로 LAN)의 호스트가 특정 멀티캐스트 그룹으로부터 트래픽을 수신하기를 원할 때를 감지할 수 있습니다. LAN에 있는 두 개 이상의 호스트가 해당 멀티캐스트 그룹에 대한 트래픽을 수신하기를 원하더라도, 라우팅 디바이스는 LAN의 고유한 브로드캐스트 특성으로 인해 해당 멀티캐스트 그룹에 대한 각 패킷의 사본 하나만 해당 인터페이스에서 전송합니다. 멀티캐스트 그룹 멤버십 프로토콜이 라우팅 디바이스에 서브넷에 관심 있는 호스트가 없음을 알리면 패킷은 보류되고 해당 리프는 배포 트리에서 정리됩니다.
IGMP(Internet Group Management Protocol) 및 MLD(Multicast Listener Discovery) 프로토콜은 표준 IP 멀티캐스트 그룹 구성원 프로토콜입니다. IGMP 및 MLD에는 호스트 및 라우팅 디바이스에서 지원하는 여러 버전이 있습니다.
IGMPv1 - RFC 1112에 정의된 원래 프로토콜입니다. 명시적 참가 메시지가 라우팅 디바이스로 전송되지만, 호스트가 그룹을 떠나는 시점을 결정하는 데 타임아웃이 사용됩니다. 이 프로세스는 라우팅 디바이스, 특히 오래되거나 더 작은 라우팅 디바이스의 처리 주기를 낭비합니다.
IGMPv2 - RFC 2236에 정의되어 있습니다. 다른 기능 중에서도 IGMPv2는 조인 메시지에 명시적 leave 메시지를 추가하여 라우팅 디바이스가 LAN에 관심 있는 리스너가 없을 때 그룹을 보다 쉽게 판별할 수 있도록 합니다.
IGMPv3 - RFC 3376에 정의되어 있습니다. 다른 기능 중에서도 IGMPv3는 멀티캐스트 그룹 또는 SSM(Source-Specific Multicast )을 위한 단일 콘텐츠 소스에 대한 지원을 최적화합니다.
MLDv1 - RFC 2710에 정의되어 있습니다. MLDv1은 IGMPv2와 유사합니다.
MLDv2 - RFC 3810에 정의되어 있습니다. MLDv2는 IGMPv3와 유사합니다.
다양한 버전의 IGMP 및 MLD는 이전 버전과 호환됩니다. 라우팅 디바이스는 LAN 인터페이스에서 여러 버전의 IGMP 및 MLD를 실행하는 것이 일반적입니다. 이전 버전과의 호환성은 LAN에서 실행되는 모든 버전 중 가장 기본적인 버전으로 되돌려 놓음으로써 달성됩니다. 예를 들어, 하나의 호스트가 IGMPv1을 실행 중인 경우 IGMPv2를 실행하는 LAN에 연결된 모든 라우팅 디바이스는 IGMPv1 작동으로 다시 드롭백되어 IGMPv2의 이점을 효과적으로 제거할 수 있습니다. 여러 IGMP 버전을 실행하면 IGMPv1 및 IGMPv2 호스트 모두 라우팅 디바이스에서 해당 버전에 대한 피어를 찾을 수 있습니다.
MX 시리즈 플랫폼에서 IGMPv2 및 IGMPv3는 설치 시 Junos OS 릴리스에 따라 동일한 인터페이스에서 함께 구성할 수도 있고 구성할 수도 없습니다. 두 가지를 함께 구성하면 멀티캐스트 트래픽 포워딩에서 예기치 않은 동작이 발생할 수 있습니다.
또한보십시오
IGMP 이해
IGMP(Internet Group Management Protocol)는 멀티캐스트 그룹에서 호스트 및 라우팅 디바이스의 멤버십을 관리합니다. IP 호스트는 IGMP를 사용하여 멀티캐스트 그룹 멤버십을 바로 인접한 멀티캐스트 라우팅 디바이스에 보고합니다. 멀티캐스트 라우팅 디바이스는 IGMP를 사용하여 연결된 물리적 네트워크 각각에 대해 구성원이 있는 그룹을 학습합니다.
IGMP는 여러 관련 멀티캐스트 프로토콜(예: DVMRP[Distance Vector Multicast Routing Protocol] 및 PIMv1[Protocol Independent Multicast version 1])에 대한 전송으로도 사용됩니다.
라우팅 디바이스는 다운스트림 그룹 멤버가 있는 이웃 라우팅 디바이스로부터 명시적 가입 및 정리 메시지를 수신합니다. PIM이 사용 중인 멀티캐스트 프로토콜인 경우 IGMP는 다음과 같이 프로세스를 시작합니다.
멀티캐스트 그룹 G에 가입하기 위해 호스트는 IGMP를 통해 구성원 정보를 전달합니다.
그런 다음 라우팅 디바이스는 멀티캐스트 그룹 G로 주소가 지정된 데이터 패킷을 명시적 참가 메시지가 수신된 인터페이스로만 전달합니다.
DR(Designated Router)은 활성 멤버가 있는 각 그룹의 그룹별 RP(Rendezvous Point)를 향해 주기적인 가입 및 정리 메시지를 보냅니다. 하나 이상의 라우팅 디바이스가 자동으로 또는 정적으로 RP로 지정되며, 모든 라우팅 디바이스는 RP를 통해 명시적으로 참가해야 합니다.
RP로 향하는 경로를 따라 각 라우팅 디바이스는 그룹에 대한 와일드카드(애니 소스) 상태를 구축하고 RP를 향해 가입 및 정리 메시지를 보냅니다.
경로 항목이라는 용어는 배포 트리를 나타내기 위해 라우팅 디바이스에서 유지되는 상태를 나타내는 데 사용됩니다.
경로 항목에는 다음과 같은 필드가 포함될 수 있습니다.
소스 주소
그룹 주소
패킷이 수락되는 수신 인터페이스
패킷이 전송되는 발신 인터페이스 목록
타이머
플래그 비트
와일드카드 경로 항목의 수신 인터페이스는 RP를 가리킵니다.
발신 인터페이스는 RP를 향해 참가 및 정리 메시지를 보낸 이웃 다운스트림 라우팅 디바이스와 그룹 G에 멤버십을 요청한 직접 연결된 호스트를 가리킵니다.
이 상태는 모든 그룹 멤버에 도달하는 공유된 RP 중심 배포 트리를 만듭니다.
IGMP는 여러 관련 멀티캐스트 프로토콜(예: DVMRP[Distance Vector Multicast Routing Protocol] 및 PIMv1[Protocol Independent Multicast version 1])에 대한 전송으로도 사용됩니다.
Junos OS 릴리스 15.2부터 PIMv1은 지원되지 않습니다.
IGMP는 IP의 필수적인 부분이며 IP 멀티캐스트 트래픽을 수신해야 하는 모든 라우팅 디바이스 및 호스트에서 활성화되어야 합니다.
연결된 각 네트워크에 대해 멀티캐스트 라우팅 디바이스는 쿼리 발생기 또는 비 쿼리 발생기가 될 수 있습니다. 쿼리 발생기 라우팅 디바이스는 그룹 회원 정보를 요청하기 위해 정기적으로 일반 질의 메시지를 보냅니다. 멀티캐스트 그룹의 구성원인 네트워크의 호스트는 보고서 메시지를 보냅니다. 호스트가 그룹을 탈퇴하면 그룹 탈퇴 메시지를 보냅니다.
IGMP 버전 3(IGMPv3)은 포함 및 제외 목록을 지원합니다. 포함 목록을 사용하면 멀티캐스트 그룹에 보낼 수 있는 소스를 지정할 수 있습니다. 이러한 유형의 멀티캐스트 그룹을 SSM(Source-Specific Multicast) 그룹이라고 하며, 멀티캐스트 주소는 232/8입니다.
IGMPv3는 소스 필터링을 지원합니다. 예를 들어, 라우팅 디바이스는 트래픽을 수락하거나 거부하는 특정 라우팅 디바이스를 지정할 수 있습니다. IGMPv3를 사용하면 멀티캐스트 라우팅 디바이스가 이웃 라우팅 디바이스에 관심을 갖는 소스를 학습할 수 있습니다.
제외 모드는 포함 목록과 반대로 작동합니다. 나열된 소스를 제외한 모든 소스를 SSM 그룹으로 전송할 수 있습니다.
IGMPv3는 프로토콜의 버전 1 및 2와 상호 운용됩니다. 그러나 이전 IGMP 호스트 및 라우팅 디바이스와의 호환성을 유지하려면 IGMPv3 라우팅 디바이스가 프로토콜 버전 1과 2도 구현해야 합니다. IGMPv3는 mode가 허용되고, 새 소스를 허용하고, 이전 소스를 차단하는 멤버십 보고서 레코드 유형을 지원합니다.
또한보십시오
IGMP 구성
시작하기 전에:
라우터가 멀티캐스트 소스에 직접 연결되어 있는지 확인합니다. 수신자는 이러한 소스를 찾을 수 있어야 합니다.
라우터가 멀티캐스트 그룹 수신기에 직접 연결되어 있는지 확인합니다. 수신기가 있는 경우 IGMP가 필요합니다.
멀티캐스트를 구성하여 스파스, 고밀도 또는 스파스 고밀도 모드를 사용할지 여부를 결정합니다. 각 모드에는 서로 다른 구성 고려 사항이 있습니다.
Sparse 또는 Sparse-Dense 모드를 사용하는 경우 RP의 주소를 결정합니다.
정적 구성, BSR 또는 auto-RP 방법으로 RP를 배치할지 여부를 결정합니다.
스파스(Sparse), 고밀도(Dense) 또는 스파스-고밀도(Sparse-Dense) 모드에서 PIM을 구성할 때 자체 RPF 라우팅 테이블을 사용하도록 멀티캐스트를 구성할지 여부를 결정합니다.
멀티캐스트 세션 알림을 수신하도록 SAP 및 SDP 프로토콜을 구성합니다. 세션 공지 프로토콜 구성을 참조하십시오.
IGMP(Internet Group Management Protocol)를 구성하려면 문을 포함합니다.igmp
igmp { accounting; interface interface-name { disable; (accounting | no-accounting); group-policy [ policy-names ]; immediate-leave; oif-map map-name; promiscuous-mode; ssm-map ssm-map-name; static { group multicast-group-address { exclude; group-count number; group-increment increment; source ip-address { source-count number; source-increment increment; } } } version version; } query-interval seconds; query-last-member-interval seconds; query-response-interval seconds; robust-count number; traceoptions { file filename <files number> <size size> <world-readable | no-world-readable>; flag flag <flag-modifier> <disable>; } }
다음 계층 수준에서 이 문을 포함할 수 있습니다.
[edit protocols][edit logical-systems logical-system-name protocols]
기본적으로 IGMP는 PIM(Protocol Independent Multicast)을 구성하는 모든 인터페이스와 DVMRP(Distance Vector Multicast Routing Protocol)를 구성하는 모든 브로드캐스트 인터페이스에서 활성화됩니다.
PIM을 구성하지 않고 인터페이스에서 IGMP를 구성할 수 있습니다. PIM은 일반적으로 IGMP 다운스트림 인터페이스에는 필요하지 않습니다. 따라서 라우터의 모든 IGMP 다운스트림(IGMP 전용) 인터페이스를 나타내기 위해 하나의 "의사 PIM 인터페이스"만 생성됩니다. 이렇게 하면 소비되는 라우터 리소스(예: 메모리)의 양이 줄어듭니다. 업스트림 IGMP 인터페이스에서 PIM을 구성하여 멀티캐스트 라우팅을 활성화하고, 멀티캐스트 데이터 패킷에 대한 역방향 경로 포워딩을 수행하고, 업스트림 인터페이스에 대한 멀티캐스트 포워딩 테이블을 채우고, 양방향 PIM 및 PIM 스파스 모드의 경우 IGMP 그룹 멤버십을 멀티캐스트 라우팅 도메인에 배포해야 합니다.
IGMP 활성화
IGMP(Internet Group Management Protocol)는 서브넷에서 그룹을 설정, 유지 및 제거하여 멀티캐스트 그룹을 관리합니다. 멀티캐스트 라우팅 디바이스는 IGMP를 사용하여 연결된 물리적 네트워크 각각에 구성원이 있는 그룹을 학습합니다. 라우터가 IPv4 멀티캐스트 패킷을 수신하려면 IGMP를 활성화해야 합니다. 멀티캐스트는 IPv6 네트워크에서 다르게 처리되므로 IGMP는 IPv4 네트워크에만 필요합니다. IGMP는 PIM을 구성하는 모든 IPv4 인터페이스와 DVMRP를 구성할 때 모든 IPv4 브로드캐스트 인터페이스에서 자동으로 활성화됩니다.
인터페이스에서 PIM 및 DVMRP가 구성되지 않았거나 인터페이스에서 IGMP가 명시적으로 비활성화되어 IGMP가 인터페이스에서 실행되고 있지 않은 경우 IGMP를 명시적으로 활성화할 수 있습니다.
IGMP를 명시적으로 활성화하려면:
또한보십시오
IGMP 호스트 쿼리 메시지 간격 수정
IGMP의 목적은 전체 서브넷의 그룹 구성원을 사용하여 라우터를 최신 상태로 유지하는 것입니다. 라우터는 모든 구성원이 누구인지 알 필요가 없으며 구성원이 존재하는지만 알 수 있습니다. 각 호스트는 어떤 멀티캐스트 그룹이 가입되어 있는지 추적합니다. 각 링크에서 하나의 라우터가 쿼리 발생기로 선출됩니다. IGMP 쿼리 발생기 라우터는 연결된 각 네트워크에 정기적으로 일반 호스트 쿼리 메시지를 보내 회원 정보를 요청합니다. 메시지는 모든 시스템 멀티캐스트 그룹 주소인 224.0.0.1로 전송됩니다.
쿼리 간격, 응답 간격 및 견고성 변수는 모두 그룹 구성원 제한시간을 계산하는 데 사용되는 변수라는 점에서 서로 관련되어 있습니다. 그룹 멤버십 시간 제한은 멀티캐스트 라우터가 서브넷에 호스트 그룹의 구성원이 더 이상 존재하지 않는다고 판단하기 전에 경과해야 하는 시간(초)입니다. 그룹 멤버십 시간 제한은 (견고성 변수 x 쿼리 간격) + (쿼리 응답 간격)으로 계산됩니다. 그룹 멤버십 타임아웃이 만료되기 전에 특정 그룹에 대한 보고서가 수신되지 않으면 라우팅 디바이스는 해당 그룹에 대해 원격으로 시작된 멀티캐스트 패킷을 연결된 네트워크로 전달하는 것을 중단합니다.
기본적으로 호스트 쿼리 메시지는 125초마다 전송됩니다. 이 간격을 변경하여 서브넷에서 전송되는 IGMP 메시지 수를 변경할 수 있습니다.
쿼리 간격을 수정하려면:
또한보십시오
IGMP 쿼리 응답 간격 수정
쿼리 응답 간격은 쿼리 발생기 라우터가 호스트 쿼리 메시지를 보내는 시점과 호스트로부터 응답을 수신하는 시점 사이에 경과할 수 있는 최대 시간입니다. 이 간격을 구성하면 서브넷에서 IGMP 메시지의 버스트 피크를 조정할 수 있습니다. 트래픽 버스트를 줄이기 위해 더 큰 간격을 설정합니다. 버스트 트래픽(Bursty traffic)은 고르지 않은 데이터 전송 패턴을 말하며, 때로는 매우 높은 데이터 전송 속도인 반면, 다른 경우에는 매우 낮은 데이터 전송 속도를 나타냅니다.
쿼리 응답 간격, 호스트-쿼리 간격 및 견고성 변수는 모두 그룹 멤버십 시간 제한을 계산하는 데 사용되는 변수라는 점에서 서로 관련되어 있습니다. 그룹 멤버십 시간 제한은 멀티캐스트 라우터가 서브넷에 호스트 그룹의 구성원이 더 이상 존재하지 않는다고 판단하기 전에 경과해야 하는 시간(초)입니다. 그룹 멤버십 시간 제한은 (견고성 변수 x 쿼리 간격) + (쿼리 응답 간격)으로 계산됩니다. 그룹 멤버십 타임아웃이 만료되기 전에 특정 그룹에 대한 보고서가 수신되지 않으면 라우팅 디바이스는 해당 그룹에 대해 원격으로 발생한 멀티캐스트 패킷을 연결된 네트워크로 전달하는 것을 중단합니다.
기본 쿼리 응답 간격은 10초입니다. 소수점 오른쪽으로 최대 한 자리까지 1초 미만의 간격을 구성할 수 있습니다. 구성 가능한 범위는 0.1에서 0.9까지이며, 그 다음 1초 간격으로 1에서 999,999까지입니다.
쿼리 응답 간격을 수정하려면:
또한보십시오
IGMP에 대한 Immediate-Leave 호스트 제거 지정
즉시 휴가 설정은 IGMP 멤버십의 휴가 대기 시간을 최소화하는 데 유용합니다. 이 설정이 활성화되면 마지막 호스트가 멀티캐스트 그룹을 떠난 직후 라우팅 디바이스가 멀티캐스트 그룹을 떠납니다.
immediate-leave 설정은 호스트 추적을 활성화하며, 이는 디바이스가 참가 메시지를 보내는 호스트를 추적한다는 것을 의미합니다. 이를 통해 IGMP는 마지막 호스트가 멀티캐스트 그룹에 대한 탈퇴 메시지를 보내는 시기를 결정할 수 있습니다.
즉시 나가기 설정이 활성화되면 디바이스는 IGMP 그룹별 쿼리를 인터페이스에 먼저 보내지 않고 포워딩 테이블 항목에서 인터페이스를 제거합니다. IGMP leave 메시지에 지정된 멀티캐스트 그룹의 멀티캐스트 트리에서 인터페이스가 정리됩니다. 즉시 나가기 설정은 여러 멀티캐스트 그룹이 동시에 사용되는 경우에도 스위치된 네트워크의 호스트에 대한 최적의 대역폭 관리를 보장합니다.
즉시 휴가가 비활성화되고 한 호스트가 그룹 탈퇴 메시지를 보내면, 라우팅 디바이스는 먼저 그룹 쿼리를 보내 다른 수신자가 응답하는지 확인합니다. 응답하는 수신기가 없는 경우, 라우팅 디바이스는 멀티캐스트 그룹에서 인터페이스의 모든 호스트를 제거합니다. 즉시 휴가는 IGMP 버전 2 및 IGMP 버전 3 모두에 대해 기본적으로 비활성화되어 있습니다.
즉시 탈퇴를 활성화하면 IGMPv2 및 MLDv1에 대해 호스트 추적이 활성화되지만, 인터페이스에 하나의 호스트가 있는 경우에만 이러한 버전에서 즉시 탈퇴를 사용하십시오. 그 이유는 IGMPv2 및 MLDv1이 인터페이스에서 하나의 호스트만 멤버십 쿼리에 대한 응답으로 그룹 가입 보고서를 보내는 보고서 억제 메커니즘을 사용하기 때문입니다. 관심있는 다른 호스트는 보고서를 표시하지 않습니다. 이 메커니즘의 목적은 동일한 그룹에 대한 보고서의 홍수를 방지하는 것입니다. 그러나 라우터는 관심 있는 호스트 한 명에 대해서만 알고 다른 호스트에 대해서는 알지 못하기 때문에 호스트 추적에도 방해가 됩니다.
인터페이스에서 즉시 나가기를 활성화하려면:
또한보십시오
IGMP 인터페이스 수준에서 원치 않는 IGMP 보고서 필터링
특정 멀티캐스트 그룹에 가입할 수 있는 서브넷을 제한해야 한다고 가정해 보겠습니다. group-policy 명령문을 사용하면 인터페이스 수준에서 원치 않는 IGMP 보고서를 필터링할 수 있습니다. IGMP 버전 2(IGMPv2) 또는 버전 3(IGMPv3)을 실행하는 라우터에서 이 문이 활성화되면 라우터가 IGMP 보고서를 수신한 후 라우터는 그룹을 지정된 그룹 정책과 비교하여 해당 정책에 구성된 작업을 수행합니다(예: 정책이 정의된 주소 또는 네트워크와 일치하는 경우 보고서 거부).
그룹 주소와 일치하도록 정책의 route-filter 명령문을 사용하여 IGMP 그룹 주소(IGMPv2의 경우)만 일치하도록 정책을 정의합니다. 정책의 route-filter 문을 사용하여 그룹 주소와 일치시키고 정책의 source-address-filter 문을 소스 주소와 일치시켜 IGMP(소스, 그룹) 주소(IGMPv3의 경우)와 일치하도록 정책을 정의합니다.
MX 시리즈 플랫폼에서 IGMPv2 및 IGMPv3는 설치 시 Junos OS 릴리스에 따라 동일한 인터페이스에서 함께 구성할 수도 있고 구성할 수도 없습니다. 두 가지를 함께 구성하면 멀티캐스트 트래픽 포워딩에서 예기치 않은 동작이 발생할 수 있습니다.
원치 않는 IGMP 보고서 필터링 방법:
또한보십시오
원격 서브네트워크에서 IGMP 메시지 수락
기본적으로 IGMP 인터페이스는 동일한 서브넷의 IGMP 메시지만 수락합니다. promiscuous-mode 명령문을 포함하면 라우팅 디바이스가 간접적으로 연결된 서브넷에서 IGMP 메시지를 수락할 수 있습니다.
/32 루프백 주소를 기부자 주소로 사용하는 번호가 지정되지 않은 이더넷 인터페이스에서 IGMP를 사용하도록 설정하는 경우 이 인터페이스에서 수신된 IGMP 패킷을 수락하도록 IGMP 무차별 모드를 구성해야 합니다.
promiscuous-mode를 활성화하면 이더넷 세그먼트의 모든 라우터를 promiscuous mode 문으로 구성해야 합니다. 그렇지 않으면 가장 낮은 IPv4 주소로 구성된 인터페이스만 이 이더넷 세그먼트에 대한 IGMP의 쿼리 발생기 역할을 합니다.
인터페이스에서 IGMP 무차별 모드를 활성화하려면:
또한보십시오
IGMP 마지막 멤버 쿼리 간격 수정
마지막 멤버 쿼리 간격은 그룹 탈퇴 메시지에 대한 응답으로 전송된 메시지를 포함하여 그룹별 쿼리 메시지 간의 최대 시간입니다. 이 간격을 구성하여 라우팅 디바이스가 그룹의 마지막 멤버의 손실을 감지하는 데 걸리는 시간을 변경할 수 있습니다.
쿼리 발생기 역할을 하는 라우팅 디바이스가 호스트로부터 그룹 탈퇴 메시지를 수신하면, 라우팅 디바이스는 남은 그룹에 여러 그룹별 쿼리를 보냅니다. 쿼리 발송기는 특정 간격으로 특정 수의 쿼리를 보냅니다. 전송된 쿼리 수를 마지막 멤버 쿼리 수라고 합니다. 쿼리가 전송되는 간격을 마지막 멤버 쿼리 간격이라고 합니다. 두 설정 모두 구성 가능하므로 휴가 대기 시간을 조정할 수 있습니다. IGMP leave latency는 멀티캐스트 그룹을 떠나라는 요청과 멀티캐스트 그룹에 대한 마지막 데이터 바이트 수신 사이의 시간입니다.
마지막 구성원 쿼리 수 x(회) 마지막 구성원 쿼리 간격 = (같음) 라우팅 디바이스가 그룹의 마지막 구성원이 그룹을 떠났다고 판단하고 그룹 트래픽 포워딩을 중지하는 데 걸리는 시간입니다.
기본 마지막 멤버 쿼리 간격은 1초입니다. 소수점 오른쪽으로 최대 한 자리까지 1초 미만의 간격을 구성할 수 있습니다. 구성 가능한 범위는 0.1에서 0.9까지이며, 그 다음 1초 간격으로 1에서 999,999까지입니다.
이 간격을 수정하려면 다음을 수행합니다.
견고성 변수를 구성하여 마지막 멤버 쿼리 수를 구성할 수 있습니다. 둘은 항상 동일합니다.
또한보십시오
IGMP 견고성 변수 수정
IGMP 견고성 변수를 미세 조정하여 서브넷에서 예상되는 패킷 손실을 허용합니다. 강력한 수는 IGMPv2 및 IGMPv3에 대한 특정 IGMP 메시지 간격을 자동으로 변경합니다. 강력한 수를 늘리면 더 많은 패킷 손실이 허용되지만 서브네트워크의 이탈 대기 시간이 늘어납니다.
쿼리 라우터가 IGMPv2를 실행하는 공유 네트워크에서 IGMP leave 메시지를 받으면 IGMP 그룹 쿼리 메시지를 지정된 횟수만큼 보내야 합니다. 전송되는 IGMP 그룹 쿼리 메시지의 수는 강력한 수에 따라 결정됩니다.
견고성 변수의 값은 다음 IGMP 메시지 간격을 계산하는 데에도 사용됩니다.
그룹 구성원 간격 - 멀티캐스트 라우터가 네트워크에 그룹의 구성원이 더 이상 없다고 판단하기 전에 경과해야 하는 시간입니다. 이 간격은 (견고성 변수 x 쿼리 간격) + (1 x 쿼리-응답 간격)으로 계산됩니다.
Other querier present interval(기타 쿼리 발생기 존재 간격) - 멀티캐스트 라우터가 쿼리 발생기인 다른 멀티캐스트 라우터가 더 이상 없다고 판단하기까지 경과해야 하는 시간을 계산하는 데 강력한 카운트가 사용됩니다. 이 간격은 (견고성 변수 x 쿼리 간격) + (0.5 x 쿼리 응답 간격)으로 계산됩니다.
Last-member query count—라우터가 그룹의 로컬 멤버가 없다고 가정하기 전에 전송된 그룹별 쿼리 수입니다. 쿼리 수는 견고성 변수의 값과 같습니다.
IGMPv3에서 인터페이스 상태가 변경되면 시스템은 해당 인터페이스에서 상태 변경 보고서를 즉시 전송합니다. 하나 이상의 멀티캐스트 라우터에서 상태 변경 보고서가 누락될 경우 재전송됩니다. 재전송되는 횟수는 강력한 카운트에서 1을 뺀 값입니다. IGMPv3에서 강력한 수는 그룹 멤버십 간격, 이전 버전 쿼리 발생기 간격 및 기타 쿼리 발생기 존재 간격을 결정하는 요소이기도 합니다.
기본적으로 견고성 변수는 2로 설정됩니다. 서브넷에서 패킷이 손실될 것으로 예상되는 경우 이 값을 늘릴 수 있습니다.
숫자는 2에서 10 사이일 수 있습니다.
견고성 변수의 값을 변경하려면,
또한보십시오
최대 IGMP 메시지 속도 제한
이 섹션에서는 라우터에서 1초에 전송되는 최대 IGMP 패킷 수에 대한 제한을 변경하는 방법에 대해 설명합니다.
초당 전송되는 IGMP 패킷의 최대 수를 늘리는 것은 IGMP에 참여하는 많은 수의 인터페이스가 있는 라우터에서 유용할 수 있습니다.
라우터가 1초에 전송할 수 있는 최대 IGMP 패킷 수에 대한 제한을 변경하려면 명령문을 포함하고 maximum-transmit-rate 전송할 초당 최대 패킷 수를 지정합니다.
또한보십시오
IGMP 버전 변경
기본적으로 라우팅 디바이스는 IGMPv2를 실행합니다. 서로 다른 버전의 IGMP를 실행하는 라우팅 디바이스는 서브넷의 호스트가 지원하는 IGMP의 가장 낮은 공통 버전을 결정하고 해당 버전에서 작동합니다.
SSM(Source-Specific Multicast) 기능을 활성화하려면 호스트와 호스트의 직접 연결된 라우팅 디바이스에서 버전 3을 구성해야 합니다. 정적으로 구성된 멀티캐스트 그룹에 소스 주소가 지정된 경우 버전을 IGMPv3으로 설정해야 합니다.
정적 멀티캐스트 그룹이 정의된 소스 주소로 구성되고 IGMP 버전이 버전 2로 구성된 경우, 소스는 무시되고 그룹만 추가됩니다. 이 경우 조인은 IGMPv2 그룹 조인으로 처리됩니다.
개별 인터페이스 계층 수준에서 IGMP 버전 설정을 구성하면 명령문이 재정의됩니다interface all. 즉, 새 인터페이스는 문으로 interface all 지정한 버전 번호를 상속하지 않습니다. 기본적으로 이 새 인터페이스는 version 2. 새 인터페이스를 추가할 때 을version number(를) 명시적으로 지정해야 합니다. 예를 들어, 로 interface all지정한 version 3 경우 새 인터페이스에 대한 문을 구성해야 version 3 합니다. 또한 계층 수준에서 멀티캐스트 그룹에 [edit interface interface-name static group multicast-group-address] 대한 인터페이스를 구성하는 경우, 다른 그룹 매개 변수와 함께 를 version number 지정해야 합니다. 그렇지 않으면 인터페이스가 기본값 version 2으로 활성화됩니다.
IGMP 버전 1(IGMPv1)을 사용하도록 라우팅 디바이스를 이미 구성한 다음 IGMPv2를 사용하도록 구성한 경우, 라우팅 디바이스는 최대 6분 동안 IGMPv1을 계속 사용한 다음 IGMPv2를 사용합니다.
SSM 기능을 위해 IGMPv3으로 변경하려면:
MX 시리즈 플랫폼에서 IGMPv2 및 IGMPv3는 설치 시 Junos OS 릴리스에 따라 동일한 인터페이스에서 함께 구성할 수도 있고 구성할 수도 없습니다. 두 가지를 함께 구성하면 멀티캐스트 트래픽 포워딩에서 예기치 않은 동작이 발생할 수 있습니다.
또한보십시오
IGMP 정적 그룹 멤버십 활성화
IGMP 정적 그룹 멤버십을 생성하여 수신자 호스트 없이 멀티캐스트 전달을 테스트할 수 있습니다. IGMP 정적 그룹 멤버십을 활성화하면 데이터가 인터페이스로 전달되고 해당 인터페이스는 다운스트림 호스트로부터 멤버십 보고서를 수신하지 않습니다. 정적 IGMP 그룹 멤버십을 활성화하는 라우터는 서브넷에 대한 DR(Designated Router)이어야 합니다. 그렇지 않으면 트래픽이 다운스트림으로 흐르지 않습니다.
IGMP 정적 그룹 멤버십을 활성화할 때 all 옵션이 IGMP 인터페이스로 지정된 경우 group-count, group-increment, source-count 및 source-increment 문을 사용하여 여러 그룹을 구성할 수 없습니다.
CoS(Class-of-Service) 조정은 IGMP 정적 그룹 멤버십으로 지원되지 않습니다.
이 예에서는 정적 그룹 233.252.0.1을 생성합니다.
라우팅 디바이스를 랑데부 포인트(RP)에 연결하는 포인트-투-포인트 링크에서 정적 IGMP 그룹 엔트리를 구성할 때, 정적 IGMP 그룹 엔트리는 RP를 향한 조인 메시지를 생성하지 않습니다.
멀티캐스트 트래픽을 수신할 인터페이스에서 멀티캐스트 포워딩을 테스트하기 위해 IGMP 정적 그룹 멤버십을 생성할 때 여러 정적 그룹이 자동으로 생성되도록 지정할 수 있습니다. 이 기능은 각 수신기를 별도로 구성할 필요 없이 여러 수신기에 대한 포워딩을 테스트하려는 경우에 유용합니다.
이 예제에서는 세 개의 그룹을 만듭니다.
DR에서 문을 포함하고
group-count생성할 그룹 수를 지정하여 생성할 정적 그룹의 수를 구성합니다.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 group-count 3
구성을 커밋한 후 명령을 사용하여
show configuration protocol igmpIGMP 프로토콜 구성을 확인합니다.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { static { group 233.252.0.1 { group-count 3; } } }구성을 커밋한 후 소스가 트래픽을 전송한 후 명령을 사용하여
show igmp group정적 그룹 233.252.0.1, 233.252.0.2 및 233.252.0.3이 생성되었는지 확인합니다.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.2 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.3 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
멀티캐스트 트래픽을 수신할 인터페이스에서 멀티캐스트 포워딩을 테스트하기 위해 IGMP 정적 그룹 멤버십을 생성할 때 생성된 각 그룹에 대해 그룹 주소가 자동으로 증가하도록 구성할 수도 있습니다. 이는 각 수신기를 개별적으로 구성할 필요 없이 여러 수신기에 대한 전달을 테스트하려는 경우와 그룹 주소가 순차적이지 않도록 하려는 경우에 유용합니다.
이 예에서는 세 개의 그룹을 만들고 각 그룹에 대해 2씩 그룹 주소를 늘립니다.
DR에서 문을 포함하고
group-increment각 그룹에 대해 주소가 증가해야 하는 수를 지정하여 그룹 주소 증분을 구성합니다. 증분은 IPv4 주소와 유사하게 점으로 분리된 10진수 표기법으로 지정됩니다.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 group-count 3 group-increment 0.0.0.2
구성을 커밋한 후 명령을 사용하여
show configuration protocol igmpIGMP 프로토콜 구성을 확인합니다.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { group-increment 0.0.0.2; group-count 3; } } }구성을 커밋한 후 소스가 트래픽을 전송한 후 명령을 사용하여
show igmp group정적 그룹 233.252.0.1, 233.252.0.3 및 233.252.0.5가 생성되었는지 확인합니다.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.3 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.5 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
멀티캐스트 트래픽을 수신할 인터페이스에서 멀티캐스트 포워딩을 테스트하기 위해 IGMP 정적 그룹 멤버십을 생성하고 네트워크가 SSM(Source-Specific Multicast) 모드에서 작동하는 경우 멀티캐스트 소스 주소가 허용되도록 지정할 수도 있습니다. 이는 특정 멀티캐스트 소스에서 멀티캐스트 수신기로의 포워딩을 테스트하려는 경우에 유용합니다.
SSM 범위에서 그룹 주소를 지정하는 경우 소스도 지정해야 합니다.
정적으로 구성된 멀티캐스트 그룹에 소스 주소가 지정된 경우 인터페이스의 IGMP 버전을 IGMPv3으로 설정해야 합니다. IGMPv2가 기본값입니다.
이 예에서는 그룹 233.252.0.1을 생성하고 IP 주소 10.0.0.2를 유일한 소스로 수락합니다.
DR에서 문을 포함하고
source소스 호스트의 IPv4 주소를 지정하여 소스 주소를 구성합니다.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 source 10.0.0.2
구성을 커밋한 후 명령을 사용하여
show configuration protocol igmpIGMP 프로토콜 구성을 확인합니다.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { source 10.0.0.2; } } }구성을 커밋하고 소스가 트래픽을 전송한 후 명령을 사용하여
show igmp group정적 그룹 233.252.0.1이 생성되었고 소스 10.0.0.2가 수락되었는지 확인합니다.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
멀티캐스트 트래픽을 수신할 인터페이스에서 멀티캐스트 포워딩을 테스트하기 위해 IGMP 정적 그룹 멤버십을 생성할 때 여러 멀티캐스트 소스가 자동으로 수락되도록 지정할 수 있습니다. 이는 둘 이상의 지정된 멀티캐스트 소스에서 멀티캐스트 수신기로의 전달을 테스트하려는 경우에 유용합니다.
이 예에서는 그룹 233.252.0.1을 생성하고 주소 10.0.0.2, 10.0.0.3 및 10.0.0.4를 소스로 수락합니다.
DR에서 명령문을 포함하고
source-count수락할 소스 수를 지정하여 수락할 멀티캐스트 소스 주소의 수를 구성합니다.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 source 10.0.0.2 source-count 3
구성을 커밋한 후 명령을 사용하여
show configuration protocol igmpIGMP 프로토콜 구성을 확인합니다.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { source 10.0.0.2 { source-count 3; } } } }구성을 커밋하고 소스가 트래픽을 전송한 후 명령을 사용하여
show igmp group정적 그룹 233.252.0.1이 생성되었고 소스 10.0.0.2, 10.0.0.3 및 10.0.0.4가 수락되었는지 확인합니다.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.3 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.4 Last reported by: Local Timeout: 0 Type: Static
멀티캐스트 트래픽을 수신할 인터페이스에서 정적 그룹을 구성하고 여러 멀티캐스트 소스가 자동으로 수락되도록 지정하는 경우, 허용된 각 소스에 대해 주소가 증가할 수도 있습니다. 이는 각 수신기를 별도로 구성할 필요 없이 여러 수신기에 대한 전달을 테스트하고 소스 주소를 순차적으로 사용하지 않으려는 경우에 유용합니다.
이 예에서는 그룹 233.252.0.1을 생성하고 주소 10.0.0.2, 10.0.0.4 및 10.0.0.6을 소스로 수락합니다.
명령문을 포함하고
source-increment각 소스에 대해 주소가 증가해야 하는 수를 지정하여 멀티캐스트 소스 주소 증분을 구성합니다. 증분은 IPv4 주소와 유사하게 점으로 분리된 10진수 표기법으로 지정됩니다.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 source 10.0.0.2 source-count 3 source-increment 0.0.0.2
구성을 커밋한 후 명령을 사용하여
show configuration protocol igmpIGMP 프로토콜 구성을 확인합니다.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { source 10.0.0.2 { source-count 3; source-increment 0.0.0.2; } } } }구성을 커밋한 후 소스가 트래픽을 전송한 후 명령을 사용하여
show igmp group정적 그룹 233.252.0.1이 생성되었고 소스 10.0.0.2, 10.0.0.4 및 10.0.0.6이 수락되었는지 확인합니다.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.4 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.6 Last reported by: Local Timeout: 0 Type: Static
멀티캐스트 트래픽을 수신할 인터페이스에서 정적 그룹을 구성하고 네트워크가 SSM(Source-Specific Multicast) 모드에서 작동하는 경우 특정 멀티캐스트 소스 주소를 제외하도록 지정할 수 있습니다.
기본적으로 정적 그룹에 구성된 멀티캐스트 소스 주소는 포함 모드에서 작동합니다. 포함 모드에서는 그룹의 멀티캐스트 트래픽이 구성된 소스 주소에서 허용됩니다. 또한 정적 그룹이 제외 모드에서 작동하도록 구성할 수도 있습니다. 제외 모드에서는 그룹의 멀티캐스트 트래픽이 구성된 소스 주소 이외의 모든 주소에서 허용됩니다.
정적으로 구성된 멀티캐스트 그룹에 소스 주소가 지정된 경우 인터페이스의 IGMP 버전을 IGMPv3으로 설정해야 합니다. IGMPv2가 기본값입니다.
이 예에서는 주소 10.0.0.2를 그룹 233.252.0.1의 소스로 제외합니다.
DR에서 문을 포함하고
exclude제외할 IPv4 소스 주소를 지정하여 제외 모드에서 작동하도록 멀티캐스트 정적 그룹을 구성합니다.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 exclude source 10.0.0.2
구성을 커밋한 후 명령을 사용하여
show configuration protocol igmpIGMP 프로토콜 구성을 확인합니다.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { exclude; source 10.0.0.2; } } }구성을 커밋하고 소스가 트래픽을 전송한 후 명령을 사용하여
show igmp group detail정적 그룹 233.252.0.1이 생성되었고 정적 그룹이 제외 모드에서 작동 중인지 확인합니다.user@host> show igmp group detail Interface: fe-0/1/2 Group: 233.252.0.1 Group mode: Exclude Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
또한보십시오
IGMP 참가 및 탈퇴 이벤트 기록
네트워크에서 IGMP 튜닝이 필요한지 여부를 결정하기 위해 IGMP 참가 및 탈퇴 이벤트를 기록하도록 라우팅 디바이스를 구성할 수 있습니다. 라우팅 디바이스 또는 개별 인터페이스에 대한 이벤트를 전역적으로 기록할 수 있습니다.
표 1 에는 기록 가능한 IGMP 이벤트가 설명되어 있습니다.
ERRMSG 태그 |
정의 |
|---|---|
RPD_IGMP_JOIN |
IGMP 참가 이벤트를 기록합니다. |
RPD_IGMP_LEAVE |
IGMP leave 이벤트를 기록합니다. |
RPD_IGMP_ACCOUNTING_ON |
IGMP 인터페이스에서 IGMP 어카운팅이 활성화될 때 기록합니다. |
RPD_IGMP_ACCOUNTING_OFF |
IGMP 인터페이스에서 IGMP 어카운팅이 비활성화된 경우 기록합니다. |
RPD_IGMP_MEMBERSHIP_TIMEOUT |
IGMP 멤버십 시간 초과 이벤트를 기록합니다. |
IGMP 계정 활성화:
또한보십시오
논리적 인터페이스에서 IGMP 멀티캐스트 그룹 조인 수 제한
group-limit 명령문을 사용하면 논리적 인터페이스에 대한 IGMP 멀티캐스트 그룹 조인 수를 제한할 수 있습니다. IGMP 버전 2(IGMPv2) 또는 버전 3(IGMPv3)을 실행하는 라우터에서 이 문이 활성화되면 그룹 보고서 수신 시 제한이 적용됩니다. 그룹 제한에 도달하면 후속 참가 요청이 거부됩니다.
IGMP 멀티캐스트 그룹에 대한 제한을 구성할 때 다음 사항에 유의하십시오.
각 임의 소스 그룹(*,G)은 한도에 대해 하나의 그룹으로 계산됩니다.
각 소스별 그룹(S,G)은 한도에 대해 하나의 그룹으로 계산됩니다.
IGMPv3 제외 모드의 그룹은 제한에 포함됩니다.
여러 소스별 그룹은 동일한 그룹에 대한 그룹일지라도 그룹 제한에 개별적으로 계산됩니다. 예를 들어, (S1, G1) 및 (S2, G1)은 구성된 제한에 대해 두 그룹으로 계산됩니다.
임의의 소스 그룹과 소스별 그룹의 조합은 동일한 그룹에 대한 것이더라도 그룹 제한에 개별적으로 계산됩니다. 예를 들어, (*, G1) 및 (S, G1)은 구성된 제한에 대해 두 그룹으로 계산됩니다.
네트워크에 이미 존재하는 것보다 낮은 네트워크에서 그룹 제한을 구성하고 커밋하면 구성에서 모든 그룹이 제거됩니다. 그런 다음 그룹은 네트워크 재가입을 요청해야 합니다(새로 구성된 그룹 제한까지).
동적 프로필을 사용하여 IGMP 논리적 인터페이스에서 멀티캐스트 그룹을 동적으로 제한할 수 있습니다.
Junos OS 릴리스 12.2부터 논리적 인터페이스에서 수신된 IGMP 멀티캐스트 그룹 조인에 대한 시스템 로그 경고 임계값을 선택적으로 구성할 수 있습니다. 문제 해결을 위해 시스템 로그 메시지를 검토하고 인터페이스에서 과도한 양의 IGMP 멀티캐스트 그룹 가입이 수신되었는지 감지하는 것이 도움이 됩니다. 이러한 로그 메시지는 구성된 그룹 제한을 초과했을 때, 구성된 임계값을 초과했을 때, 그룹 수가 구성된 임계값 아래로 떨어질 때를 전달합니다.
명령 group-threshold 문을 사용하면 경고 메시지가 기록되는 임계값을 구성할 수 있습니다. 범위는 1%에서 100%까지입니다. 경고 임계값은 그룹 제한의 비율이므로 경고 임계값을 group-limit 구성하려면 문을 구성해야 합니다. 예를 들어, 그룹 수가 구성된 경고 임계값을 초과하지만 구성된 그룹 제한 미만으로 유지되면 멀티캐스트 그룹이 계속 수락되고 디바이스는 경고 메시지를 기록합니다. 또한 디바이스는 그룹 수가 구성된 경고 임계값 아래로 떨어진 후 경고 메시지를 기록합니다. 문을 구성하여 로그 메시지 사이의 시간(초)을 추가로 지정할 수 있습니다 log-interval . 범위는 6초에서 32,767초까지입니다.
구성된 임계값 이후에 추가된 모든 항목과 구성된 제한 이후에 거부된 모든 항목으로 인해 경고 메시지가 기록되기 때문에 로그 메시지 제한을 고려할 수 있습니다. 로그 간격을 구성하면 IGMP 멀티캐스트 그룹 조인에 대해 생성되는 시스템 로그 경고 메시지의 양을 조절할 수 있습니다.
ACX 시리즈 라우터에서 멀티캐스트 경로의 최대 수는 1024개입니다.
IGMP 논리적 인터페이스에서 멀티캐스트 그룹 가입을 제한하려면:
구성을 확인하려면 명령을 사용합니다 show protocols igmp . 구성된 그룹 제한 및 선택적 경고 임계값 및 로그 메시지 간 간격을 포함하여 인터페이스에서 IGMP의 show igmp interface 작동을 확인하려면 명령을 사용합니다.
또한보십시오
IGMP 프로토콜 트래픽 추적
추적 작업은 보내고 받은 다양한 유형의 라우팅 프로토콜 패킷 및 라우팅 정책 작업과 같은 라우팅 프로토콜 작업에 대한 자세한 메시지를 기록합니다. 특정 추적 플래그를 포함하여 기록할 추적 작업을 지정할 수 있습니다. 다음 표에서는 포함할 수 있는 플래그에 대해 설명합니다.
기 |
묘사 |
|---|---|
모두 |
모든 작업을 추적합니다. |
클라이언트 알림 |
추적 알림. |
일반 |
일반적인 흐름을 추적합니다. |
그룹 |
그룹 작업을 추적합니다. |
호스트 알림 |
호스트 알림을 추적합니다. |
떠나다 |
그룹 메시지를 남깁니다(IGMPv2에만 해당). |
엠트레이스 |
추적 mtrace 패킷. |
보통 |
정상적인 이벤트를 추적합니다. |
패킷을 |
모든 IGMP 패킷을 추적합니다. |
정책 |
정책 처리를 추적합니다. |
쿼리 |
일반 및 그룹별 쿼리를 포함하여 IGMP 멤버십 쿼리 메시지를 추적합니다. |
보고서 |
멤버 자격 보고서 메시지를 추적합니다. |
경로 |
라우팅 정보를 추적합니다. |
상태 |
상태 전환을 추적합니다. |
과업 |
작업 처리를 추적합니다. |
타이머 |
타이머 처리를 추적합니다. |
다음 예에서는 모든 라우팅 프로토콜 패킷에 대해 추적을 사용할 수 있습니다. 그런 다음 특정 유형의 IGMP 패킷에만 초점을 맞추도록 추적 범위를 좁힙니다. IGMP에 대한 추적 작업을 구성하려면 다음을 수행합니다.
또한보십시오
IGMP 비활성화
인터페이스에서 IGMP를 비활성화하려면 문을 포함합니다.disable
disable;
다음 계층 수준에서 이 문을 포함할 수 있습니다.
[edit protocols igmp interface interface-name][edit logical-systems logical-system-name protocols igmp interface interface-name]메모:ACX 시리즈 라우터는 계층 수준을 지원하지
[edit logical-systems logical-system-name protocols]않습니다.
또한보십시오
IGMP 및 NSR(Nonstop Active Routing)
NSR(Nonstop Active Routing) 구성에는 라우팅 엔진 페일오버 중에 라우팅이 중단되지 않도록 정보를 공유하는 두 개의 라우팅 엔진이 포함됩니다. 이러한 NSR 구성에는 PIM과 관련된 IGMP의 수동 지원이 포함됩니다. 기본 라우팅 엔진은 IGMP를 사용하여 PIM 멀티캐스트 상태를 확인하며, 이 IGMP 파생 정보는 백업 라우팅 엔진에 복제됩니다. 새로운 기본 라우팅 엔진의 IGMP(페일오버 후)는 IGMP 작업을 통해 상태 정보를 빠르게 재학습합니다. 그 동안 새로운 기본 라우팅 엔진은 이전 기본 라우팅 엔진의 복제 프로세스에서 수신한 IGMP 파생 PIM 상태를 유지합니다. 이 상태 정보는 새로운 기본 라우팅 엔진에서 IGMP에 의해 새로 고쳐지지 않는 한 시간 초과됩니다. 추가 IGMP 구성은 필요하지 않습니다.
또한보십시오
변경 내역 테이블
기능 지원은 사용 중인 플랫폼 및 릴리스에 따라 결정됩니다. 기능 탐색기 를 사용하여 플랫폼에서 기능이 지원되는지 확인합니다.