IP 멀티캐스트 문제 해결 가이드

몇 가지 추가적인 디버그 명령을 입력합니다.

ip22-72a#debug ip mpacket 224.1.1.1 
*Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface

패킷이 올바른 E3/1에 들어옵니다. 그러나 이는 유니캐스트 라우팅 테이블이 RPF 확인에 사용하는 인터페이스가 아니므로 삭제됩니다.

참고: 디버깅 패킷은 위험합니다. 패킷 디버깅은 멀티캐스트 패킷의 프로세스 전환을 트리거하며, 이 때 CPU가 많이 사용됩니다. 또한 패킷 디버깅으로 인해 콘솔 포트에 대한 출력이 느려져 라우터가 완전히 중단될 수 있는 막대한 출력이 생성될 수 있습니다. 패킷을 디버깅하기 전에 콘솔에 대한 로깅 출력을 비활성화하고 메모리 버퍼에 대한 로깅을 활성화하려면 특별한 주의가 필요합니다. 이를 위해 no logging console과 logging buffered debugging을 구성합니다. 디버그 결과는 show logging 명령으로 확인할 수 있습니다.

가능한 해결 방안

이 요구 사항을 충족하기 위해 유니캐스트 라우팅 테이블을 변경할 수도 있고, 유니캐스트 라우팅 테이블의 상태에 관계없이 멀티캐스트를 특정 인터페이스에 RPF로 강제 전송하도록 고정 mroute를 추가할 수도 있습니다. 고정 mroute 추가:

ip22-72a(config)#ip mroute 10.1.1.1 255.255.255.255 10.2.1.1

이 고정 경로는 RPF용 주소 10.1.1.1에 도달하려면 인터페이스 E3/1을 벗어난 다음 홉으로 10.2.1.1을 사용하도록 지정합니다.

ip22-72a#show ip rpf 10.1.1.1 
RPF information for ? (10.1.1.1) 
  RPF interface: Ethernet3/1 
  RPF neighbor: ? (10.2.1.1) 
  RPF route/mask: 10.1.1.1/32 
  RPF type: static mroute 
  RPF recursion count: 0 
  Doing distance-preferred lookups across tables 

의 출력show ip mroute 이debug ip mpacket 양호하고, 의 전송 패킷 수가 증가하고, HostA가show ip mroute count 패킷을 수신합니다.

ip22-72a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3/1, Forward/Sparse-Dense, 00:01:15/00:00:00 Ethernet3/2, Forward/Sparse-Dense, 00:00:58/00:00:00 (10.1.1.1, 224.1.1.1), 00:00:48/00:02:59, flags: CTA Incoming interface: Ethernet3/1, RPF nbr 10.2.1.1, Mroute Outgoing interface list: Ethernet3/2, Forward/Sparse-Dense, 00:00:48/00:00:00 ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2378 bytes of memory 2 groups, 0.50 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.1.1.1, Source count: 1, Packets forwarded: 1019, Packets received: 1019 Source: 10.1.1.1/32, Forwarding: 1019/1/100/0, Other: 1019/0/0 ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2378 bytes of memory 2 groups, 0.50 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.1.1.1, Source count: 1, Packets forwarded: 1026, Packets received: 1026 Source: 10.1.1.1/32, Forwarding: 1026/1/100/0, Other: 1026/0/0 ip22-72a# ip22-72a#debug ip mpacket 224.1.1.1 *Jan 14 10:18:29.951: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:29.999: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:30.051: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward

소스의 TTL 설정으로 인해 라우터가 멀티캐스트 패킷을 호스트로 전달하지 않음

이 섹션에서는 TTL(Time To Live) 값이 0으로 감소되어 전달되지 않는 IP 멀티캐스트 패킷의 일반적인 문제에 대한 해결책을 소개합니다. 이는 멀티캐스트 애플리케이션이 많기 때문에 흔히 발생하는 문제입니다. 이러한 멀티캐스트 애플리케이션은 주로 LAN 사용을 위해 설계되었으므로 TTL을 낮은 값 또는 심지어 1로 설정합니다. 이 네트워크 다이어그램을 예로 들어 보십시오. 

주로 LAN 사용을 위해 설계된 멀티캐스트 애플리케이션 예

문제 진단

이전 그림에서 라우터 A는 소스(S)에서 직접 연결된 라우터 B로 패킷을 전달하지 않습니다. 멀티캐스트 라우팅 상태  show ip mroute  를 보려면 라우터 A에서 명령의 출력을 확인합니다.

ROUTERA#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 00:00:01/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:00:01/00:00:00 (*, 224.1.1.1), 00:00:02/00:02:57, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:00:02/00:00:00 

모든 라우터가 이 Auto-RP Discovery 그룹에 조인하므로 출력에서 224.0.1.40을 무시할 수 있습니다. 그러나 224.1.1.1에 대해 나열된 소스는 없습니다. "*, 224.1.1.1" 외에도 "10.1.1.1, 224.1.1.1"을 볼 수 없습니다.

RPF 문제인지 확인하려면 show ip rpf 명령을 입력합니다.

ROUTERA#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet0/0 RPF neighbor: ? (0.0.0.0) - directly connected RPF route/mask: 10.1.1.1/24 RPF type: unicast (connected) RPF recursion count: 0 Doing distance-preferred lookups across tables 

출력에서 RPF 문제가 아닙니다. RPF 검사에서 E0/0을 올바르게 지정하여 소스 IP 주소로 이동합니다.

PIM이 인터페이스에서 다음 명령을 사용하여 구성되었는지 show ip pim interface 확인합니다.

ROUTERA#show ip pim interface Address Interface Version/Mode Nbr Query DR Count Intvl 10.1.1.2 Ethernet0/0 v2/Sparse-Dense 0 30 10.1.1.2 10.2.1.1 Ethernet0/1 v2/Sparse-Dense 2 30 10.2.1.2 

출력이 양호해 보이므로 문제가 되지 않습니다. 라우터가 다음 명령을 사용하여 활성 트래픽을 인식하는지show ip mroute active 확인합니다.

ROUTERA#show ip mroute active Active IP Multicast Sources - sending >= 4 kbps 

출력에 따르면 라우터가 활성 트래픽을 인식하지 않습니다.

ROUTERA#debug ip mpacket IP multicast packets debugging is on 

수신자가 그룹 224.1.1.1에 대한 IGMP(Internet Group Management Protocol) 보고서(조인)를 전송하지 않을 수 있습니다. show ip igmp group  다음 명령을 사용하여 확인할 수 있습니다.

ROUTERB#show ip igmp group IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 224.0.1.40 Ethernet1/1 00:34:34 never 10.2.1.2 224.1.1.1 Ethernet1/2 00:30:02 00:02:45 10.3.1.2 

224.1.1.1은 정상적으로 E1/2에서 조인되었습니다.

PIM 고밀도 모드는 플러드 및 프루닝 프로토콜이므로 조인은 없지만 그래프트는 있습니다. 라우터 B가 라우터 A에서 플러드를 수신하지 않았으므로 그래프트를 전송할 위치를 알 수 없습니다.

sniffer 캡처와 함께 TTL 문제인지 그리고 다음 명령에서도 확인되는지 확인할 수 show ip traffic  있습니다.

ROUTERA#show ip traffic IP statistics: Rcvd: 248756 total, 1185 local destination 0 format errors, 0 checksum errors, 63744 bad hop count 0 unknown protocol, 0 not a gateway 0 security failures, 0 bad options, 0 with options 

출력에 63744개의 잘못된 홉 수가 표시됩니다. 이 명령을 입력할 때마다 불량 홉 수가 증가합니다. 이는 발신자가 TTL = 1인 패킷을 전송하며 라우터 A가 0으로 감소하는 것을 나타냅니다. 이로 인해 잘못된 홉 수 필드가 증가합니다.

가능한 해결 방안

이 문제를 해결하려면 TTL을 늘려야 합니다. 이는 발신자의 애플리케이션 레벨에서 수행됩니다. 자세한 내용은 멀티캐스트 애플리케이션 사용 설명서를 참조하십시오.

이 작업이 완료되면 라우터 A는 다음과 같이 표시됩니다.

ROUTERA#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:16:32/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 01:16:32/00:00:00 (*, 224.1.1.1), 00:28:42/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:28:42/00:00:00 (10.1.1.1, 224.1.1.1), 00:19:24/00:02:59, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:19:24/00:00:00 

이것은 보려는 출력의 종류입니다.

라우터 B에는 다음이 표시됩니다.

ROUTERB#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:23:57/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/1, Forward/Sparse-Dense, 01:23:57/00:00:00 (*, 224.1.1.1), 01:19:26/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/1, Forward/Sparse-Dense, 01:19:26/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:19:26/00:00:00 (10.1.1.1, 224.1.1.1), 00:17:46/00:02:59, flags: CTA Incoming interface: Ethernet1/1, RPF nbr 10.2.1.1 Outgoing interface list: Ethernet1/2, Forward/Sparse-Dense, 00:17:46/00:00:00

라우터가 라우터의 TTL 임계값으로 인해 멀티캐스트 패킷을 전달하지 않음

이 섹션에서는 TTL 임계값이 너무 낮게 설정되어 IP 멀티캐스트 트래픽이 수신기에 도달하지 않는 일반적인 문제에 대한 해결책을 소개합니다. 이 네트워크 다이어그램은 예시입니다.

TTL 임계값이 너무 낮아 IP 멀티캐스트 트래픽이 수신자에게 도달하지 않음

문제 진단

이전 그림에서 수신기는 소스에서 멀티캐스트 패킷을 수신하지 않습니다. 소스와 라우터 75a 사이에 여러 라우터가 있을 수 있습니다. 라우터 75a가 수신기에 직접 연결되어 있으므로 먼저 라우터 75a를 살펴봅니다.

ip22-75a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:32:05/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:08:17/00:00:00 (10.1.1.1, 224.1.1.1), 00:01:02/00:01:57, flags: CTA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:01:02/00:00:00 

출력은 라우터(75a)가 패킷을 Ethernet0/1로 포워딩하는 것을 보여줍니다. 라우터 75a가 패킷을 전달하는지 확실히 확인하려면 이 소스 및 멀티캐스트 debug 그룹만 켜십시오.

ip22-75a#configure terminal Enter configuration commands, one per line. End with CNTL/Z. ip22-75a(config)#access-list 101 permit udp host 10.1.1.1 host 224.1.1.1 ip22-75a(config)#end ip22-75a#debug ip mpacket 101 IP multicast packets debugging is on for access list 101 ip22-75a# *Jan 17 09:04:08.714: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied

메시지는 debug TTL 임계값에 도달했기 때문에 라우터 75a가 멀티캐스트 패킷을 전달하지 않음을 나타냅니다. 라우터 구성을 확인하여 이유를 찾을 수 있는지 확인합니다. 다음 출력은 원인을 보여줍니다.

interface Ethernet0/1 ip address 10.2.1.1 255.255.255.0 ip pim sparse-dense-mode ip multicast ttl-threshold 15 

라우터의 TTL 임계값은 15이지만, 그렇다고 해서 TTL이 15보다 큰 항목이 전송되지 않는 것은 아닙니다. 실제로는 그 반대입니다. 애플리케이션은 TTL 15로 전송됩니다. 라우터 75a에 도달할 때까지 멀티캐스트 패킷의 TTL은 15보다 작습니다.

이 ip multicast ttl-threshold <value> 명령은 TTL이 지정된 임계값보다 낮은 모든 패킷(이 경우 15)이 전달되지 않음을 의미합니다. 이 명령은 일반적으로 내부 멀티캐스트 트래픽이 인트라넷에서 드리프트하는 것을 방지하기 위한 경계를 제공하기 위해 사용됩니다.

가능한 해결 방안

기본 TTL 임계값 ip multicast ttl-threshold <value>0으로 되돌려지는 이 명령의 no 형식으로 명령을 제거하거나, 트래픽이 통과할 수 있도록 TTL 임계값을 낮추십시오.

여러 동일 비용 경로로 인해 원치 않는 RPF 동작 발생

이 섹션에서는 멀티캐스트 소스에 대한 동일 비용 경로로 인해 원치 않는 RPF 동작이 발생하는 원인을 설명합니다. 또한 이러한 동작을 방지하기 위해 IP 멀티캐스트를 구성하는 방법도 설명합니다. 이 네트워크 다이어그램은 예시입니다.

멀티캐스트 소스에 대한 동일 비용 경로로 인해 원치 않는 RPF 동작 발생

문제 진단

그림에서 라우터 75b는 소스에 대한 3개의 동일 비용 경로(10.1.1.1)를 가지며, 첫 번째 선택 항목으로 삼지 않으려는 링크를 RPF 링크로 선택합니다.

소스에 대한 동일 비용 경로가 여러 개인 경우 IP 멀티캐스트는 IP 주소가 가장 높은 인접 PIM(Protocol Independent Multicast)이 있는 인터페이스를 수신 인터페이스로 선택한 다음 다른 링크의 인접 PIM에 프루닝을 전송합니다.

가능한 해결 방안

IP 멀티캐스트가 수신 인터페이스로 선택하는 인터페이스를 변경하려면 다음 중 하나를 수행하십시오.

• 멀티캐스트가 통과할 인터페이스에만 PIM을 구성해야 하므로 멀티캐스트 리던던시(redundancy)가 손실됩니다.

• 가장 높은 IP 주소가 기본 멀티캐스트 링크가 될 링크에 있도록 서브넷을 변경합니다.

• 기본 멀티캐스트 인터페이스를 가리키는 고정 멀티캐스트 경로(mroute)를 만듭니다. 그러면 멀티캐스트 리던던시(redundancy)가 사라집니다.

예를 들어 고정 mroute가 생성됩니다.

고정 mroute를 설치하기 전에 이 출력에서 라우팅 테이블에 소스 주소 10.1.1.1에 대한 3개의 동일한 비용 경로가 있음을 확인할 수 있습니다. RPF 정보는 RPF 인터페이스가 E1/3임을 나타냅니다.

ip22-75b#show ip route 10.1.1.1 Routing entry for 10.1.1.1/24 Known via "ospf 1", distance 110, metric 20, type intra area Redistributing via ospf 1 Last update from 10.3.1.1 on Ethernet1/2, 00:26:21 ago Routing Descriptor Blocks: * 10.4.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 Route metric is 20, traffic share count is 1 10.2.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 Route metric is 20, traffic share count is 1 10.3.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 Route metric is 20, traffic share count is 1 ip22-75b#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet1/3 RPF neighbor: ? (10.4.1.1) RPF route/mask: 10.1.1.1/24 RPF type: unicast (ospf 1) RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 01:30:34/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:30:34/00:00:00 Ethernet1/1, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/3, Forward/Sparse-Dense, 00:24:22/00:00:00 (10.1.1.1, 224.1.1.1), 01:30:35/00:02:59, flags: CT Incoming interface: Ethernet1/3, RPF nbr 10.4.1.1 Outgoing interface list: Ethernet1/1, Prune/Sparse-Dense, 01:30:35/00:02:32 Ethernet1/4, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/2, Prune/Sparse-Dense, 00:24:22/00:02:42 

고정 mroute를 구성한 후에는 이 출력에서 RPF 인터페이스가 E1/1로 변경된 것을 확인할 수 있습니다.

ip22-75b#configure terminal Enter configuration commands, one per line. End with CNTL/Z. ip22-75b(config)#ip mroute 0.0.0.0 0.0.0.0 10.2.1.1 ip22-75b(config)#end ip22-75b#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet1/1 RPF neighbor: ? (10.2.1.1) RPF route/mask: 10.1.1.1/0 RPF type: static mroute RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-75b#show ip route 10.1.1.1 Routing entry for 10.1.1.1/24 Known via "ospf 1", distance 110, metric 20, type intra area Redistributing via ospf 1 Last update from 10.3.1.1 on Ethernet1/2, 00:26:21 ago Routing Descriptor Blocks: * 10.4.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 Route metric is 20, traffic share count is 1 10.2.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 Route metric is 20, traffic share count is 1 10.3.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 Route metric is 20, traffic share count is 1 ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 01:31:29/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:31:29/00:00:00 Ethernet1/1, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/3, Forward/Sparse-Dense, 00:25:17/00:00:00 (10.1.1.1, 224.1.1.1), 01:31:30/00:02:59, flags: CT Incoming interface: Ethernet1/1, RPF nbr 10.2.1.1, Mroute Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/2, Prune/Sparse-Dense, 00:25:17/00:01:47 Ethernet1/3, Prune/Sparse-Dense, 00:00:31/00:02:28

IP 멀티캐스트가 사용 가능한 모든 동일 비용 경로에 로드 밸런싱되지 않는 이유는 무엇입니까?

이 섹션에서는 사용 가능한 모든 동일 비용 경로에서 로드 밸런싱을 수행하기 위해 IP 멀티캐스트를 구성하는 방식의 일반적인 문제에 대한 해결책을 제공합니다. 이 네트워크 다이어그램은 예시입니다.

참고: 스플릿 IP 멀티캐스트 트래픽을 터널을 통해 동일 비용 경로를 통해 로드하기 전에 패킷별로 CEF 로드 밸런싱을 구성하십시오. 그렇지 않으면 GRE 패킷을 패킷별로 로드 밸런싱할 수 없습니다. 멀티캐스트 환경에서 공유를 로드하는 다른 방법은 ECMP를 통한 IP 멀티캐스트 트래픽 로드 분할을 참조하십시오.

사용 가능한 모든 동일 비용 경로에서 로드 밸런싱을 수행하도록 IP 멀티캐스트 구성

이 그림에서 라우터 75b는 소스에 대한 3개의 동일 비용 경로(10.1.1.1)를 가지고 있습니다. 세 링크 모두에서 멀티캐스트 트래픽을 로드 밸런싱하려고 합니다.

가능한 해결 방안

여러 동일 비용 경로로 인한 원치 않는 RPF 동작 섹션에서 살펴본 것처럼, PIM(Protocol Independent Multicast)은 RPF 확인을 위한 인터페이스 하나만을 선택하고 나머지 인터페이스는 정리합니다. 따라서 로드 밸런싱이 발생하지 않습니다. 로드 밸런싱을 수행하려면 이중화된 링크에서 PIM을 제거하고 라우터 75a와 라우터 75b 사이에 터널을 생성해야 합니다. 그런 다음 링크 수준에서 로드 밸런싱을 수행하면 IP가 터널을 통해 실행됩니다.

터널의 구성은 다음과 같습니다.

interface Tunnel0 
 ip address 10.6.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
 tunnel source Ethernet0/0 
 tunnel destination 10.5.1.1 
! 
interface Ethernet0/0 
 ip address 10.1.1.2 255.255.255.0 
 ip pim sparse-dense-mode 
! 
interface Ethernet0/1 
 ip address 10.2.1.1 255.255.255.0 
! 
interface Ethernet0/2 
 ip address 10.3.1.1 255.255.255.0 
! 
interface Ethernet0/3 
 ip address 10.4.1.1 255.255.255.0

interface Tunnel0 
 ip address 10.6.1.2 255.255.255.0 
 ip pim sparse-dense-mode 
 tunnel source Ethernet1/4 
 tunnel destination 10.1.1.2 
! 
interface Ethernet1/1 
 ip address 10.2.1.2 255.255.255.0 
! 
interface Ethernet1/2 
 ip address 10.3.1.2 255.255.255.0 
! 
interface Ethernet1/3 
 ip address 10.4.1.2 255.255.255.0 
! 
interface Ethernet1/4 
 ip address 10.5.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
! 
ip mroute 0.0.0.0 0.0.0.0 Tunnel0

터널을 구성한 다음 그룹에 대한show ip mroute 멀티캐스트 경로(mroute)를 보려면 명령을 입력합니다.

ip22-75a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 02:40:31/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00 (10.1.1.1, 224.1.1.1), 02:40:32/00:03:29, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00 ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 02:42:20/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:22:53/00:00:00 Ethernet1/4, Forward/Sparse-Dense, 02:42:20/00:00:00 (10.1.1.1, 224.1.1.1), 00:22:53/00:02:59, flags: CT Incoming interface: Tunnel0, RPF nbr 10.6.1.1, Mroute Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 00:22:53/00:00:00 

멀티캐스트 데이터가 3개 링크에서 동일하게 로드 밸런싱되는지 확인하려면 라우터 75a의 인터페이스 데이터를 확인합니다.

수신 인터페이스는 9000비트/초입니다.

ip22-75a#show interface e0/0 . . 5 minute input rate 9000 bits/sec, 20 packets/sec 

3개의 발신 인터페이스에는 각각 3000비트/초가 표시됩니다.

ip22-75a#show interface e0/1 . . 5 minute output rate 3000 bits/sec, 7 packets/sec ip22-75a#show interface e0/2 . . 5 minute output rate 3000 bits/sec, 7 packets/sec ip22-75a#show interface e0/3 . . 5 minute output rate 3000 bits/sec, 7 packets/sec

라우터에서 IP 멀티캐스트 "INVALID_RP_JOIN" 오류 메시지를 수신할 때

이 섹션에서는 IP 멀티캐스트 "INVALID_RP_JOIN" 오류 메시지의 일반적인 문제에 대한 해결책을 제공합니다.

문제 진단 - 1부

이 오류 메시지는 RP(Rendezvous Point)에서 수신됩니다.

00:55:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 

Cisco IOS Software System Error Messages 문서에서는 이 오류의 원인을 설명합니다. 다운스트림 PIM 라우터가 공유 트리에 대한 조인 메시지를 보냈는데, 이 라우터는 이를 수락하지 않습니다. 이 동작은 이 라우터가 특정 RP에 조인하는 다운스트림 라우터만 허용함을 나타냅니다.

필터링 중인 것으로 의심됩니다. 라우터의 구성을 살펴보아야 합니다.

interface Ethernet0/0 ip address 10.1.5.4 255.255.255.0 ip pim sparse-dense-mode ! ip pim accept-rp 10.2.2.2 8 ip pim send-rp-announce Ethernet0/0 scope 15 ip pim send-rp-discovery scope 15 ! access-list 8 permit 224.0.0.0 0.255.255.255 

컨피그레이션의 accept-rp  명령문은 무엇을 달성해야 합니까? IP Multicast Routing 명령에서는 "지정된 RP 및 특정 그룹 목록에 대해 조인 또는 프룬을 허용하도록 라우터를 구성하려면 global configuration 명령을ip pim accept-rp 사용합니다. 확인을 제거하려면 이 명령의 no 형식을 사용합니다."

명령을 제거하면 ip pim accept-rp 메시지가 사라집니다. 문제의 원인이 되는 명령이 발견되었지만 구성에서 해당 명령을 실행하려면 어떻게 해야 합니까? 잘못된 RP 주소를 허용할 수 있습니다. 올바른 RP show ip pim rp mapping  주소를 보려면 다음 명령을 입력합니다.

ip22-75a#show ip pim rp mapping PIM Group-to-RP Mappings This system is an RP (Auto-RP) This system is an RP-mapping agent Group(s) 224.0.0.0/4 RP 10.1.5.4 (?), v2v1 Info source: 10.1.5.4 (?), via Auto-RP Uptime: 01:00:48, expires: 00:02:07

출력을 기준으로, 10.1.5.4는 Auto-RP 또는 기타 방법으로 학습된 유일한 RP입니다. 그러나 이 라우터는 그룹 224.0.0.0/4에 대한 RP일 뿐입니다. 따라서 컨피그레이션의 pim accept-rp 명령문이 잘못되었습니다.

가능한 해결 방안

해결 방법은 명령문의 IP 주소를 다음ip pim accept-rp과 같이 수정하는 것입니다.

변경 전 명령문:

ip pim accept-rp 10.2.2.2 8

변경 후 명령문:

ip pim accept-rp 10.1.5.4 8

또한 auto-rp 캐시에 있는 내용을 수락하도록 명령문을 변경하고 액세스 목록(이 예시에서는 8)이 필요한 멀티캐스트 그룹 범위를 허용하도록 할 수 있습니다. 예:

ip pim accept-rp auto-rp access-list 8 permit 224.0.0.0 0.255.255.255

문제 진단 - 2부

이 오류 메시지는 router2에 표시됩니다.

router2# *Aug 12 15:18:17.891: %PIM-6-INVALID_RP_JOIN: Received (*, 224.0.1.40) Join from 0.0.0.0 for invalid RP 10.2.1.1

router2가 그룹 224.1.1.1의 RP인지 확인합니다.

router2#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.1.1.1 (?), v2v1 Info source: 10.1.1.1 (?), elected via Auto-RP Uptime: 00:21:26, expires: 00:02:24 router2#

224.1.1.1의 RP는 10.1.1.1입니다.

이것이 router2의 인터페이스 중 하나인지 확인합니다.

router2#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0/0 10.1.1.2 YES NVRAM up up Ethernet1/0 10.2.1.1 YES NVRAM up up Ethernet2/0 unassigned YES NVRAM administratively down down router2#

router2는 RP가 아니므로 이 RP-Join 패킷을 수신하지 않아야 합니다. 다운스트림 라우터가 Join(조인)을 router2로 보낸 이유를 확인하며, 반드시 그래서는 안 됩니다.

router3#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.1.1.1 (?), v2v1 Info source: 10.1.1.1 (?), elected via Auto-RP Uptime: 00:24:30, expires: 00:02:16 Group(s): 224.0.0.0/4, Static-Override RP: 10.2.1.1 (?) router3#

보시다시피 router3는 RP 정보를 고정으로 구성했으며 router2를 가리키는데, 이는 올바르지 않습니다. 이 때문에 router3가 RP-Join을 router2로 전송하는 것입니다.

가능한 해결 방안

router2를 그룹 224.1.1.1의 RP로 설정하거나, router3에서 올바른 RP 주소를 참조하도록 구성을 변경합니다.

router3#show run | i rp ip pim rp-address 10.2.1.1 override router3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router3(config)#no ip pim rp-address 10.2.1.1 override router3(config)#exit router3#

라우터3의 컨피그레이션이 수정된 후 라우터3은 올바른 RP 주소를 참조하며 오류 메시지가 중지됩니다.

router3#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.1.1.1 (?), v2v1 Info source: 10.1.1.1 (?), elected via Auto-RP Uptime: 00:30:45, expires: 00:02:02 router3#

중복된 멀티캐스트 패킷 스트림 수신

원인 1

중복된 멀티캐스트 패킷은 두 개의 라우터가 고밀도 모드로 구성된 경우 수신됩니다. 고밀도 모드에서는 디바이스가 주기적으로 스트림을 플러딩합니다. 플러딩 후 스트림이 필요하지 않은 인터페이스에서 제거됩니다. 또한 두 라우터는 어설션 프로세스를 거쳐 전달자를 결정합니다. 타이머가 울릴 때마다 이 프로세스가 실행되고 이 프로세스가 완료될 때까지 두 라우터가 모두 스트림을 전달합니다. 이로 인해 애플리케이션이 중복되는 멀티캐스트 스트림을 수신하게 됩니다.

가능한 해결 방안 1

이 문제는 멀티캐스트 라우팅용으로 구성된 라우터 중 하나가 있고 다른 라우터를 업스트림의 RP로 구성하려는 경우 해결할 수 있습니다. 스트림이 라우터로 들어가기 전에 스트림을 저밀도 모드로 변환하도록 구성합니다. 이렇게 하면 중복 패킷이 애플리케이션에 도달하는 것을 방지할 수 있습니다. 중복 패킷이 엔드 호스트에 도달하지 않도록 하는 것은 네트워크 책임이 아닙니다. 중복 패킷을 처리하고 불필요한 데이터를 무시하는 것은 애플리케이션의 책임입니다.

원인 2

이 문제는 이그레스(egress) 멀티캐스트 복제 모드에 구성된 Cisco Catalyst 6500 스위치에서 발생할 수 있으며 모든 라인 카드를 제거하고 다시 삽입하여 트리거할 수 있습니다[OIR]. OIR 후에는 FPOE(Fabric Port Of Exit)가 잘못 프로그래밍되어 패킷이 잘못된 패브릭 종료 채널로 전송되어 잘못된 라인 카드로 전송될 수 있습니다. 그 결과 패브릭으로 루프백되고 올바른 라인 카드에서 종료될 때 여러 번 복제됩니다.

C6509#show mls ip multicast capability Current mode of replication is Egress Auto replication mode detection is ON Slot Multicast replication capability 1 Egress 2 Egress 3 Egress 4 Egress 5 Egress 6 Egress 7 Egress

가능한 해결 방안 2

이를 해결하려면 인그레스 복제 모드로 변경합니다. 이그레스를 인그레스 복제 모드로 변경하는 동안 바로 가기가 제거되고 다시 설치되므로 트래픽이 중단될 수 있습니다.

mls ip multicast replication-mode ingress 

Cisco IOS 소프트웨어를 Cisco 버그 ID CSCeg28814의 영향을 받지 않는 릴리스로 업그레이드하여 영구적으로 문제를 해결하십시오.

참고: 등록된 Cisco 사용자만 내부 Cisco 툴 및 버그 정보에 액세스할 수 있습니다.

원인 3

이 문제는 엔드 호스트 또는 서버에서 RSS(Receive Side Scaling) 설정이 비활성화된 경우에도 발생할 수 있습니다.

가능한 해결 방안 3

RSS 설정을 사용하면 여러 CPU에서 데이터를 더 빠르게 전송할 수 있습니다. 엔드 호스트 또는 서버에서 RSS 설정을 활성화합니다.

멀티캐스트 패킷이 삭제되는 이유

원인 1

멀티캐스트 트래픽이 흐르면 인터페이스에서 과도한 플러시 및 입력 패킷 삭제를 확인할 수 있습니다. 명령을 사용하여 플러시를 확인할 수 show interface 있습니다.

Switch#show interface gigabitethernet 1/0 !--- Output suppressed MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is SX input flow-control is off, output flow-control is on Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 2/75/0/13370328 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 195000 bits/sec, 85 packets/sec 30 second output rate 1000 bits/sec, 1 packets/sec L2 Switched: ucast: 53056 pkt, 4728434 bytes - mcast: 235759386 pkt, 66914376970 bytes L3 in Switched: ucast: 8714263 pkt, 1815426423 bytes - mcast: 1081138213 pkt,
 438000092206 bytes mcast L3 out Switched: ucast: 4939256 pkt, 790351689 bytes mcast: 0 pkt, 0 bytes 1326976857 packets input, 506833655045 bytes, 0 no buffer Received 1318209538 broadcasts, 0 runts, 0 giants, 1 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 input packets with dribble condition detected 31643944 packets output, 3124494549 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out

가능한 해결 방안 1

과도한 플러시가 발생하는 인터페이스에 대해 SPT 값을 무한대로 설정할 수 있습니다.

다음을 구성합니다.

Switch(config-if)#ip pim spt-threshold infinity 

원인 2

어떤 인터페이스에서 이 ip igmp join-group <group-name>명령을 사용하면 스위칭이 처리됩니다. 멀티캐스트 패킷이 인터페이스에서 프로세스 전환되는 경우, 해당 그룹에 대한 모든 패킷의 프로세스를 전환해야 하므로 CPU 사용량이 증가합니다. 명령을 실행하고 show buffers input-interface 비정상적인 크기를 확인할 수 있습니다.

Switch#show buffers input-interface gigabitethernet 1/0 Header DataArea Pool Rcnt Size Link Enc Flags Input Output 437C6EAC 8096AE4 Middl 1 434 7 1 280 Gi1/1 None 437C74B4 8097864 Middl 1 298 7 1 280 Gi1/1 None 437C98E4 809C964 Middl 1 434 7 1 280 Gi1/1 None 437CAAFC 809F1E4 Middl 1 349 7 1 280 Gi1/1 None 437CAE00 809F8A4 Middl 1 519 7 1 280 Gi1/1 None !--- Output suppressed 

가능한 해결 방안 2

명령 대신 명령을ip igmp static-group <group-name> 사용할 수 ip igmp join-group <group-name> 있습니다.

참고: 이전 문제로 인해 CPU 사용량이 90% 정도 높게 나타날 수 있습니다. 가능한 해결 방안으로 CPU를 해결하면 CPU가 정상적인 상태로 돌아옵니다.

관련 정보

• CLI 도구를 사용하여 멀티캐스트 네트워크 트러블슈팅
• 멀티캐스트 빠른 시작 설정 가이드

• ECMP 멀티캐스트 로드 분할 활성화 

• IP 멀티캐스트 기술 지원
• IP 라우팅 프로토콜 지원
• Cisco 기술 지원 및 다운로드