IP 멀티캐스트 문제 해결 가이드
목차
소개
이 문서에서는 IP 멀티캐스트를 위한 일반적인 문제 및 솔루션에 대해 설명합니다.
사전 요구 사항
요구 사항
이 문서에 대한 특정 요건이 없습니다.
사용되는 구성 요소
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
배경 정보
멀티캐스트 라우팅을 트러블슈팅할 때 기본 관심사는 소스 주소입니다.멀티캐스트에는 RPF(Reverse Path Forwarding) 확인 개념이 있습니다.멀티캐스트 패킷이 인터페이스에 도착하면 RPF 프로세스는 멀티캐스트 패킷의 소스에 도달하기 위해 유니캐스트 라우팅에서 사용하는 발신 인터페이스인지 확인합니다.이 RPF 확인 프로세스는 루프를 방지합니다.패킷의 소스가 RPF 검사를 통과하지 않는 한 멀티캐스트 라우팅은 패킷을 전달하지 않습니다.패킷이 이 RPF 검사를 통과하면 멀티캐스트 라우팅은 목적지 주소에만 따라 패킷을 전달합니다.
유니캐스트 라우팅과 마찬가지로 멀티캐스트 라우팅에는 PIM-DM(Protocol Independent Multicast Dense Mode), PIM-SM(PIM Sparse Mode), DVMRP(Distance Vector Multicast Routing Protocol), MBGP(Multicast Border Gateway Protocol), MSDP(Multicast Source Discovery Protocol)와 같은 몇 가지 프로토콜이 있습니다. 이 문서의 사례 연구를 통해 다양한 문제를 해결하는 과정을 안내합니다.문제를 신속하게 파악하고 해결하는 방법을 배우기 위해 어떤 명령이 사용되는지 확인할 수 있습니다.여기에 나열된 사례 연구는 프로토콜에 걸쳐 일반적입니다(언급된 경우 제외).
RPF 실패로 인해 라우터가 멀티캐스트 패킷을 호스트에 전달하지 않음
이 섹션에서는 IP 멀티캐스트 RPF 장애의 일반적인 문제에 대한 해결책을 제공합니다.이 네트워크 다이어그램은 예로 사용됩니다.
이 그림에서 멀티캐스트 패킷은 IP 주소가 1.1.1.1인 서버에서 라우터 75a의 E0/0에 도착하여 그룹 224.1.1.1으로 전송됩니다. 이를 (S,G) 또는 (1.1.1.1, 224.1.1.1)이라고 합니다.
문제 진단
라우터 75a에 직접 연결된 호스트는 멀티캐스트 피드를 수신하지만, 라우터 72a에 직접 연결된 호스트는 멀티캐스트 피드를 수신하지 않습니다.먼저 show ip mroute 224.1.1.1 명령을 입력하여 라우터 75a의 상황을 확인합니다.이 명령은 그룹 주소 224.1.1.1에 대한 멀티캐스트 경로(mroute)를 검사합니다.
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:01:23/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:01:23/00:00:00
(1.1.1.1, 224.1.1.1), 00:01:23/00:03:00, flags: TA
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00
라우터는 PIM Dense 모드(D 플래그 때문에 덴스 모드임을 알 수 있음)를 실행하므로 *,G 항목을 무시하고 S,G 항목에 집중합니다.이 항목은 멀티캐스트 패킷이 주소가 1.1.1.1(주소가 224.1.1.1인 멀티캐스트 그룹으로 전송)인 서버에서 소싱되었음을 나타냅니다. 패킷은 Ethernet0/0 인터페이스로 들어오고 Ethernet0/1 인터페이스로 전달됩니다.완벽한 시나리오입니다.
라우터 72a가 업스트림 라우터(75a)를 PIM 인접 디바이스로 표시하는지 확인하려면 show ip pim neighbor 명령을 입력합니다.
ip22-72a#show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires Ver Mode 2.1.1.1 Ethernet3/1 2d00h 00:01:15 v2
show ip pim neighbor 명령 출력에서 PIM 인접 디바이스가 정상적으로 보입니다.
라우터 72a에 정상 경로가 있는지 확인하려면 show ip mroute 명령을 입력합니다.
ip22-72a#show ip mroute 224.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, 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 - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:10:42/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3/1, Forward/Dense, 00:10:42/00:00:00
Ethernet3/2, Forward/Dense, 00:10:42/00:00:00
(1.1.1.1, 224.1.1.1), 00:01:10/00:02:48, flags:
Incoming interface: Ethernet2/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3/1, Forward/Dense, 00:01:10/00:00:00
Ethernet3/2, Forward/Dense, 00:00:16/00:00:00
ip22-72a#
show ip mroute 224.1.1.1 명령에서 수신 인터페이스는 Ethernet2/0이고 Etheret3/1은 예상됨을 확인할 수 있습니다.
이 그룹에 대한 멀티캐스트 트래픽이 라우터 72a에 도착하는지 여부와 그 다음에 어떤 일이 발생하는지 확인하려면 show ip mroute 224.1.1.1 count 명령을 입력합니다.
ip22-72a#show ip mroute 224.1.1.1 count
IP Multicast Statistics
3 routes using 2032 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: 0, Packets received: 471
Source: 1.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0
ip22-72a#
Other(기타) 카운트에서 RPF 실패로 인해 트래픽이 삭제되는 것을 확인할 수 있습니다.총 471개 삭제(RPF 실패 - 471...)
RPF 오류가 있는지 확인하려면 show ip rpf <source> 명령을 입력합니다.
ip22-72a#show ip rpf 1.1.1.1 RPF information for ? (1.1.1.1) RPF interface: Ethernet2/0 RPF neighbor: ? (0.0.0.0) RPF route/mask: 1.1.1.1/32 RPF type: unicast (static) RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-72a#
Cisco IOS®는 이러한 방식으로 RPF 인터페이스를 계산합니다.RPF 정보의 가능한 소스는 유니캐스트 라우팅 테이블, MBGP 라우팅 테이블, DVMRP 라우팅 테이블 및 고정 경로 테이블입니다.RPF 인터페이스를 계산할 때 RPF 계산의 기반이 되는 정보의 소스를 정확하게 확인하기 위해 주로 관리 거리가 사용됩니다.특정 규칙은 다음과 같습니다.
-
소스 IP 주소에서 일치하는 RPF 데이터의 모든 선행 소스가 검색됩니다.공유 트리를 사용하면 소스 주소 대신 RP 주소가 사용됩니다.
-
일치하는 경로가 두 개 이상 발견되면 관리 거리가 가장 낮은 경로가 사용됩니다.
-
관리 거리가 동일한 경우 이 기본 설정 순서가 사용됩니다.
-
고정 경로
-
DVMRP 경로
-
MBGP 경로
-
유니캐스트 경로
-
-
동일한 경로 테이블 내에서 경로에 대한 여러 항목이 발생하는 경우 가장 긴 일치 경로가 사용됩니다.
show ip rpf 1.1.1.1 명령 출력은 RPF 인터페이스가 E2/0이지만 수신 인터페이스는 E3/1이어야 합니다.
RPF 인터페이스가 예상과 다른 이유를 보려면 show ip route 1.1.1.1 명령을 입력합니다.
ip22-72a#show ip route 1.1.1.1 Routing entry for 1.1.1.1/32 Known via "static", distance 1, metric 0 (connected) Routing Descriptor Blocks: * directly connected, via Ethernet2/0 Route metric is 0, traffic share count is 1
이 show ip route 1.1.1.1 명령 출력에서 static/32 경로가 있으므로 잘못된 인터페이스를 RPF 인터페이스로 선택할 수 있습니다.
몇 가지 추가 debug 명령을 입력합니다.
ip22-72a#debug ip mpacket 224.1.1.1 *Jan 14 09:45:32.972: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface *Jan 14 09:45:33.020: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface *Jan 14 09:45:33.072: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface *Jan 14 09:45:33.120: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface
패킷은 E3/1에서 수신되며 정확합니다.그러나 유니캐스트 라우팅 테이블에서 RPF 확인에 사용하는 인터페이스가 아니므로 삭제됩니다.
가능한 수정
이 요구 사항을 충족하기 위해 유니캐스트 라우팅 테이블을 변경하거나, 유니캐스트 라우팅 테이블 상태에 관계없이 특정 인터페이스를 RPF로 멀티캐스트를 강제 수행하기 위해 고정 경로를 추가할 수 있습니다.고정 경로 추가:
ip22-72a(config)#ip mroute 1.1.1.1 255.255.255.255 2.1.1.1
이 고정 경로 상태는 RPF의 주소 1.1.1.1에 도달하려면 외부 인터페이스 E3/1인 다음 홉으로 2.1.1.1을 사용하라고 나타냅니다.
ip22-72a#show ip rpf 1.1.1.1 RPF information for ? (1.1.1.1) RPF interface: Ethernet3/1 RPF neighbor: ? (2.1.1.1) RPF route/mask: 1.1.1.1/32 RPF type: static mroute RPF recursion count: 0 Doing distance-preferred lookups across tables
show ip mroute 및 debug ip mpacket의 출력이 양호하고, show ip mroute count에서 전송된 패킷 수가 증가하고, HostA가 패킷을 수신합니다.
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
(1.1.1.1, 224.1.1.1), 00:00:48/00:02:59, flags: CTA
Incoming interface: Ethernet3/1, RPF nbr 2.1.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: 1.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: 1.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=1.1.1.1 (Ethernet3/1)
d=224.1.1.1 (Ethernet3/2) len 60, mforward
*Jan 14 10:18:29.999: IP: s=1.1.1.1 (Ethernet3/1)
d=224.1.1.1 (Ethernet3/2) len 60, mforward
*Jan 14 10:18:30.051: IP: s=1.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로 설정합니다. 이 네트워크 다이어그램을 예로 들어 보겠습니다..
문제 진단
이전 그림에서 라우터 A는 소스에서 라우터 B의 직접 연결된 수신기로 패킷을 전달하지 않습니다.멀티캐스트 라우팅 상태를 보려면 라우터 A에서 show ip mroute 명령의 출력을 확인합니다.
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" 외에 "1.1.1.1, 224.1.1.1"도 표시되어야 합니다.
show ip rpf 명령을 입력하여 RPF 문제인지 확인합니다.
ROUTERA#show ip rpf 1.1.1.1 RPF information for ? (1.1.1.1) RPF interface: Ethernet0/0 RPF neighbor: ? (0.0.0.0) - directly connected RPF route/mask: 1.1.1.0/24 RPF type: unicast (connected) RPF recursion count: 0 Doing distance-preferred lookups across tables
출력에서 RPF 문제가 아님을 확인할 수 있습니다.RPF 체크는 E0/0을 올바르게 표시하여 소스의 IP 주소에 연결합니다.
show ip pim interface 명령을 사용하여 인터페이스에 PIM이 구성되어 있는지 확인합니다.
ROUTERA#show ip pim interface
Address Interface Version/Mode Nbr Query DR
Count Intvl
1.1.1.2 Ethernet0/0 v2/Sparse-Dense 0 30 1.1.1.2
2.1.1.1 Ethernet0/1 v2/Sparse-Dense 2 30 2.1.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 2.1.1.2 224.1.1.1 Ethernet1/2 00:30:02 00:02:45 3.1.1.2
224.1.1.1은 E1/2에 가입했습니다. 괜찮습니다.
PIM 덴스 모드는 플러딩 및 정리 프로토콜이므로 조인이 없지만 접지가 있습니다.라우터 B가 라우터 A에서 플러드를 수신하지 않았기 때문에, 이식편을 어디로 보내야 하는지 알 수 없습니다.
스니퍼 캡처에 대한 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 잘못된 hop 카운트가 표시됩니다.이 명령을 입력할 때마다 잘못된 홉의 수가 증가합니다.이는 발신자가 TTL=1을 사용하여 패킷을 전송하며, 라우터 A가 0으로 감소합니다.그러면 잘못된 hop count 필드가 증가합니다.
가능한 수정
문제를 해결하려면 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
(1.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
(1.1.1.1, 224.1.1.1), 00:17:46/00:02:59, flags: CTA
Incoming interface: Ethernet1/1, RPF nbr 2.1.1.1
Outgoing interface list:
Ethernet1/2, Forward/Sparse-Dense, 00:17:46/00:00:00
라우터가 라우터의 TTL 임계값으로 인해 멀티캐스트 패킷을 전달하지 않음
이 섹션에서는 IP 멀티캐스트 트래픽이 수신기에 도달하지 않도록 TTL 임계값이 너무 낮게 설정된 일반적인 문제에 대한 해결책을 제공합니다.이 네트워크 다이어그램은 예로 사용됩니다.
문제 진단
이전 그림에서 수신자는 소스에서 멀티캐스트 패킷을 수신하지 않습니다.소스와 라우터 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
(1.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
출력에 Router 75a가 Ethernet0/1로 패킷을 전달하는 것이 나와 있습니다. 라우터 75a가 패킷을 전달하도록 하려면 이 소스 및 멀티캐스트 그룹에 대해서만 디버그를 설정합니다.
ip22-75a#configure terminal Enter configuration commands, one per line. End with CNTL/Z. ip22-75a(config)#access-list 101 permit udp host 1.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=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied
디버그 메시지는 TTL 임계값에 도달했으므로 라우터 75a가 멀티캐스트 패킷을 전달하지 않음을 나타냅니다.원인을 찾을 수 있는지 확인하려면 라우터 컨피그레이션을 확인하십시오.이 출력에는 가해자가 표시됩니다.
interface Ethernet0/1 ip address 2.1.1.1 255.255.255.0 ip pim sparse-dense-mode ip multicast ttl-threshold 15
라우터에 TTL 임계값이 15이지만 TTL 15보다 큰 어떤 것도 전송되지 않는다는 의미는 아닙니다.사실, 그 반대는 사실이다.애플리케이션은 TTL 15로 전송됩니다. Router 75a에 도달하면 멀티캐스트 패킷의 TTL이 15보다 작습니다.
ip multicast ttl-threshold <value> 명령은 TTL이 지정된 임계값보다 낮은 패킷이 전달되지 않음을 의미합니다. 이 경우 15입니다.이 명령은 일반적으로 내부 멀티캐스트 트래픽이 인트라넷에서 빠져나가는 것을 방지하기 위한 테두리를 제공하기 위해 사용됩니다.
가능한 수정
이 명령의 no 형식으로 기본 TTL 임계값 0으로 되돌리는 ip multicast ttl-threshold <value> 명령을 제거하거나 트래픽이 전달될 수 있도록 TTL 임계값을 낮춥니다.
여러 개의 동일 비용 경로로 인해 원치 않는 RPF 동작 발생
이 섹션에서는 멀티캐스트 소스에 대한 동일한 비용 경로가 원하지 않는 RPF 동작을 일으킬 수 있는 방법을 보여줍니다.또한 이러한 동작을 피하기 위해 IP 멀티캐스트를 구성하는 방법에 대해서도 설명합니다.이 네트워크 다이어그램은 예로 사용됩니다.
문제 진단
그림에서 라우터 75b는 소스(1.1.1.1)에 대한 세 가지 동일 비용 경로를 가지고 있으며, RPF 링크로 첫 번째 선택을 원하지 않는 링크를 선택합니다.
소스에 대한 여러 개의 동일 비용 경로가 있는 경우 IP 멀티캐스트는 IP 주소가 가장 높은 PIM(Protocol Independent Multicast) 인접 디바이스가 있는 인터페이스를 수신 인터페이스로 선택한 다음 다른 링크의 PIM 인접 디바이스로 정리기를 전송합니다.
가능한 수정
인터페이스 IP 멀티캐스트가 수신 인터페이스로 선택하는 인터페이스를 변경하려면 다음 중 하나를 수행합니다.
-
멀티캐스트가 트래버스할 인터페이스에 PIM만 구성하면 멀티캐스트 이중화가 손실됩니다.
-
기본 멀티캐스트 링크로 설정하려는 링크에 가장 높은 IP 주소가 있도록 서브넷을 변경합니다.
-
기본 멀티캐스트 인터페이스를 가리키는 고정 멀티캐스트 경로(mroute)를 생성합니다. 즉, 멀티캐스트 이중화를 잃게 됩니다.
예를 들어 고정 경로가 생성됩니다.
고정 경로를 설치하기 전에 이 출력에서 라우팅 테이블에 소스 주소 1.1.1.1에 대한 세 가지 동일 비용 경로가 있음을 확인할 수 있습니다. RPF 정보는 RPF 인터페이스가 E1/3임을 나타냅니다.
ip22-75b#show ip route 1.1.1.1
Routing entry for 1.1.1.0/24
Known via "ospf 1", distance 110, metric 20, type intra area
Redistributing via ospf 1
Last update from 3.1.1.1 on Ethernet1/2, 00:26:21 ago
Routing Descriptor Blocks:
* 4.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3
Route metric is 20, traffic share count is 1
2.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1
Route metric is 20, traffic share count is 1
3.1.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 1.1.1.1
RPF information for ? (1.1.1.1)
RPF interface: Ethernet1/3
RPF neighbor: ? (4.1.1.1)
RPF route/mask: 1.1.1.0/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
(1.1.1.1, 224.1.1.1), 01:30:35/00:02:59, flags: CT
Incoming interface: Ethernet1/3, RPF nbr 4.1.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
고정 경로를 구성한 후 이 출력에 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 2.1.1.1
ip22-75b(config)#end
ip22-75b#show ip rpf 1.1.1.1
RPF information for ? (1.1.1.1)
RPF interface: Ethernet1/1
RPF neighbor: ? (2.1.1.1)
RPF route/mask: 1.1.1.1/0
RPF type: static mroute
RPF recursion count: 0
Doing distance-preferred lookups across tables
ip22-75b#show ip route 1.1.1.1
Routing entry for 1.1.1.0/24
Known via "ospf 1", distance 110, metric 20, type intra area
Redistributing via ospf 1
Last update from 3.1.1.1 on Ethernet1/2, 00:26:21 ago
Routing Descriptor Blocks:
* 4.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3
Route metric is 20, traffic share count is 1
2.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1
Route metric is 20, traffic share count is 1
3.1.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
(1.1.1.1, 224.1.1.1), 01:31:30/00:02:59, flags: CT
Incoming interface: Ethernet1/1, RPF nbr 2.1.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 멀티캐스트를 구성하는 방법에 대한 일반적인 문제에 대해 설명합니다.이 네트워크 다이어그램은 예로 사용됩니다.
그림에서 라우터 75b는 3개의 동일 비용 경로(1.1.1.1)을 소스로 되돌립니다. 세 링크 모두에서 멀티캐스트 트래픽을 로드 밸런싱하고자 합니다.
가능한 수정
Multiple Equal Cost Paths Result in Unwanted RPF Behavior(다중 동일 비용 경로 결과 원치 않는 RPF 동작) 섹션에서 보듯이 PIM(Protocol Independent Multicast)은 RPF 확인을 위해 하나의 인터페이스만 선택하고 나머지는 정리합니다.즉, 로드 밸런싱이 발생하지 않습니다.로드 밸런싱을 수행하려면 이중화 링크에서 PIM을 제거하고 라우터 75a와 라우터 75b 간에 터널을 생성해야 합니다.그런 다음 링크 레벨에서 로드 밸런싱을 수행하고 IP가 터널을 통해 실행됩니다.
터널의 컨피그레이션입니다.
| 라우터 75a |
|---|
interface Tunnel0 ip address 6.1.1.1 255.255.255.0 ip pim sparse-dense-mode tunnel source Ethernet0/0 tunnel destination 5.1.1.1 ! interface Ethernet0/0 ip address 1.1.1.2 255.255.255.0 ip pim sparse-dense-mode ! interface Ethernet0/1 ip address 2.1.1.1 255.255.255.0 ! interface Ethernet0/2 ip address 3.1.1.1 255.255.255.0 ! interface Ethernet0/3 ip address 4.1.1.1 255.255.255.0 |
| 라우터 75b |
|---|
interface Tunnel0 ip address 6.1.1.2 255.255.255.0 ip pim sparse-dense-mode tunnel source Ethernet1/4 tunnel destination 1.1.1.2 ! interface Ethernet1/1 ip address 2.1.1.2 255.255.255.0 ! interface Ethernet1/2 ip address 3.1.1.2 255.255.255.0 ! interface Ethernet1/3 ip address 4.1.1.2 255.255.255.0 ! interface Ethernet1/4 ip address 5.1.1.1 255.255.255.0 ip pim sparse-dense-mode ! ip mroute 0.0.0.0 0.0.0.0 Tunnel0 |
터널을 구성한 후 그룹에 대한 멀티캐스트 경로(mroute)를 보려면 show ip 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
(1.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
(1.1.1.1, 224.1.1.1), 00:22:53/00:02:59, flags: CT
Incoming interface: Tunnel0, RPF nbr 6.1.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 1.1.6.2 for invalid RP 1.1.5.4 00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) Join from 1.1.6.2 for invalid RP 1.1.5.4
Cisco IOS Software System Error Messages는 이 오류의 원인을 설명합니다.다운스트림 PIM 라우터가 공유 트리에 대한 조인 메시지를 전송했으며, 이 라우터는 수락하지 않습니다.이 동작은 이 라우터가 특정 RP에 대한 다운스트림 라우터만 조인할 수 있음을 나타냅니다.
어떤 종류의 필터링이 진행되고 있다고 의심됩니다.라우터의 컨피그레이션을 확인해야 합니다.
interface Ethernet0/0 ip address 1.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 Commands에서 이 문서에서는 "지정된 RP로 향하는 Joins 또는 Prunes를 수락하도록 라우터를 구성하고 특정 그룹 목록에 대해 ip pim accept-rp 전역 컨피그레이션 명령을 사용하도록 구성합니다.해당 검사를 제거하려면 이 명령의 no 형식을 사용합니다."
ip pim accept-rp 명령을 제거하면 메시지가 사라집니다.문제를 일으키는 명령을 찾았지만 컨피그레이션에 해당 명령을 유지하려면 어떻게 해야 합니까?잘못된 RP 주소를 허용할 수 있습니다.올바른 RP 주소를 보려면 show ip pim 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 1.1.5.4 (?), v2v1
Info source: 1.1.5.4 (?), via Auto-RP
Uptime: 01:00:48, expires: 00:02:07
출력에 따르면 1.1.5.4은 Auto-RP 또는 그 밖의 방법으로 학습된 유일한 RP입니다.그러나 이 라우터는 그룹 224.0.0.0/4에 대한 RP일 뿐입니다. 따라서 컨피그레이션의 pim accept-rp 문이 잘못되었습니다.
가능한 수정
이 솔루션은 ip pim accept-rp 문의 IP 주소를 다음과 같이 수정하는 것입니다.
다음 명령문 변경:
ip pim accept-rp 10.2.2.2 8
다음으로:
ip pim accept-rp 1.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 2.1.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 1.1.1.1 (?), v2v1
Info source: 1.1.1.1 (?), elected via Auto-RP
Uptime: 00:21:26, expires: 00:02:24
router2#
224.1.1.1의 RP는 1.1.1.1입니다.
router2의 인터페이스 중 하나인지 확인합니다.
router2#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0/0 1.1.1.2 YES NVRAM up up Ethernet1/0 2.1.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 1.1.1.1 (?), v2v1
Info source: 1.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: 2.1.1.1 (?)
router3#
보시다시피 router3은 정적으로 RP 정보를 구성했으며 router2를 가리킵니다. 이는 올바르지 않습니다.이렇게 하면 router3에서 RP-Join을 router2로 전송하는 이유를 설명합니다.
가능한 수정
라우터2를 그룹 224.1.1.1의 RP로 만들거나 라우터3의 컨피그레이션을 변경하여 올바른 RP 주소를 참조합니다.
router3#show run | i rp ip pim rp-address 2.1.1.1 override router3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router3(config)#no ip pim rp-address 2.1.1.1 override router3(config)#exit router3#
router3의 컨피그레이션이 수정되면 router3은 올바른 RP 주소를 참조하고 오류 메시지가 나타나지 않습니다.
router3#show ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 1.1.1.1 (?), v2v1
Info source: 1.1.1.1 (?), elected via Auto-RP
Uptime: 00:30:45, expires: 00:02:02
router3#
CGMP는 멀티캐스트 패킷의 플러드를 방지하지 않음
이 섹션에서는 특정 서브넷의 모든 라우터에서 CGMP(Cisco Group Management Protocol)가 활성화되지 않은 경우 멀티캐스트 패킷의 불필요한 플러딩이 발생하는 방법과 이 문제를 방지하는 방법에 대해 설명합니다.이 네트워크 다이어그램은 예로 사용됩니다.
문제 진단
그림에서 Catalyst 5000 스위치 A의 고정 CAM 테이블에는 올바른 포트가 채워져 있지 않습니다.CGMP 구성 라우터는 CGMP 패킷을 전송하지 않습니다.
CGMP는 스위치 A에서 set cgmp enable 명령과 라우터 75a의 E0/2 인터페이스에서 ip cgmp 명령을 사용하여 올바르게 구성됩니다.그러나 show multicast group 명령이 실행되면 스위치 A에서 멀티캐스트 그룹이 표시되지 않습니다.
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- Total Number of Entries = 0
이 명령의 출력에는 CGMP 구성 라우터가 있는 각 포트(포트 2/3)와 관련된 수신기가 있는 각 포트(포트 2/6)가 표시되어야 합니다. 0이 나열되므로 모든 포트가 필요 없이 멀티캐스트 트래픽으로 넘쳐난다고 가정할 수 있습니다.
관찰
라우터 75a에 PIM(Protocol Independent Multicast) 인접 디바이스가 있는지 확인합니다.
ip22-75a#show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires Ver Mode 2.1.1.1 Ethernet0/2 00:07:41 00:01:34 v2
출력은 라우터 75a가 스위치 A를 통해 라우터 75b를 유효한 PIM 인접 디바이스로 볼 수 있음을 보여줍니다.
이제 라우터에서 올바른 멀티캐스트 경로(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), 00:14:55/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/2, Forward/Sparse-Dense, 00:14:55/00:00:00
(1.1.1.1, 224.1.1.1), 00:14:56/00:02:59, flags: CTA
Incoming interface: Ethernet0/1, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/2, Forward/Sparse-Dense, 00:14:56/00:00:00
출력은 라우터 75a가 멀티캐스트 패킷을 E0/2에서 스위치 A로 전달하는 것을 보여줍니다.이 출력은 Router 75b가 멀티캐스트 패킷을 가져와서 올바르게 전달하는 것을 보여줍니다.
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), 00:17:57/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/3, Forward/Sparse-Dense, 00:17:57/00:00:00
Ethernet1/4, Forward/Sparse-Dense, 00:17:57/00:00:00
(1.1.1.1, 224.1.1.1), 00:00:35/00:02:59, flags: CTA
Incoming interface: Ethernet1/3, RPF nbr 2.1.1.2
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 00:00:35/00:00:00
스위치 A의 관점에서 보면 포트 2/3에서 라우터 75a가 해제되는 것을 알 수 있습니다.
Console> (enable) show multicast router CGMP enabled IGMP disabled IGMP fastleave disabled Port Vlan --------- ---------------- 2/3 6 Total Number of Entries = 1
지금까지 본 모든 것이 괜찮은 것 같아요라우터 75a에서 몇 가지 debug 명령을 입력하여 확인할 수 있는 사항을 확인합니다.
ip22-75a#debug ip cgmp CGMP debugging is on *Feb 8 12:45:22.206: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:45:22.206: GDA 0000.0000.0000, USA 00d0.ff2f.a002 *Feb 8 12:46:22.234: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:46:22.234: GDA 0000.0000.0000, USA 00d0.ff2f.a002 *Feb 8 12:47:22.262: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:47:22.262: GDA 0000.0000.0000, USA 00d0.ff2f.a002
출력에서 0000.0000.0000은 모든 그룹 주소이며 라우터가 CGMP 가입/탈퇴 메시지를 보낼 때 사용되므로 스위치가 라우터 포트를 채울 수 있습니다.GDA는 MAC(Media Access Control) 레벨 형식의 Group Destination Address를, USA는 Unicast Source Address를 의미합니다.이 CGMP 메시지가 생성된 IGMP 보고서를 생성한 호스트의 주소입니다.이 경우 라우터 75a 인터페이스 E0/2의 MAC 주소입니다. 라우터 75a의 E0/2에 대한 MAC 주소는 다음과 같이 show interface 명령과 함께 볼 수 있습니다.
ip22-75a#show interface e0/2 Ethernet0/2 is up, line protocol is up Hardware is cxBus Ethernet, address is 00d0.ff2f.a002 (bia 00d0.ff2f.a002)
또한 debug ip igmp 명령이 켜져 있을 때 이를 주기적으로 볼 수 있습니다.
*Feb 8 12:51:41.854: IGMP: Received v2 Report from 2.1.1.3 (Ethernet0/2) for 224.1.1.1
그러나 이후에 Router 75a에서 해당하는 CGMP 패킷이 표시되지 않습니다.즉, Router 75a는 IGMP 보고서를 수신하지만 스위치 A가 어떤 포트를 차단할지 알 수 있도록 필요한 CGMP 패킷을 생성하지 않습니다.이는 IGMP 쿼리 발생기인 경우 라우터 75a에서 예상되는 것입니다.라우터 75a의 이 출력은 예상 동작이 발생하지 않는 이유를 알려줍니다.
ip22-75a#show ip igmp interface e0/2 Ethernet0/2 is up, line protocol is up Internet address is 2.1.1.2/24 IGMP is enabled on interface Current IGMP version is 2 CGMP is enabled IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 3 joins, 1 leaves Multicast routing is enabled on interface Multicast TTL threshold is 0 Multicast designated router (DR) is 2.1.1.2 (this system) IGMP querying router is 2.1.1.1 No multicast groups joined
동일한 서브넷에 두 개의 라우터가 있고 CGMP에 대해 두 라우터를 모두 구성할 경우 CGMP 패킷은 하나만 전송됩니다.CGMP 패킷을 전송하는 라우터는 IGMP 쿼리 라우터입니다.이는 IGMP 지원 라우터의 가장 낮은 유니캐스트 IP 주소를 가진 라우터를 의미합니다.
이 경우 라우터 75a와 라우터 75b 모두 IGMP가 활성화되었지만(라우터 75b가 IGMP 쿼리 라우터가 됨), 라우터 75a만 CGMP가 활성화되었습니다.라우터 75a는 IGMP 쿼리 라우터가 아니므로 CGMP 패킷이 전송되지 않습니다.
가능한 수정
문제를 해결하려면 IGMP 쿼리 라우터에서 CGMP를 구성해야 합니다.이 경우 라우터 75b.먼저, 라우터 75b에서 debug 명령을 설정합니다.
ip22-75b#conf t Enter configuration commands, one per line. End with CNTL/Z. ip22-75b(config)#int e 1/3 ip22-75b(config-if)#ip cgmp ip22-75b(config-if)#end ip22-75b#debug ip cgmp ip22-75b#debug ip igmp *Feb 8 12:58:42.422: IGMP: Received v2 Report from 2.1.1.3 (Ethernet1/3) for 224.1.1.1 *Feb 8 12:58:42.422: CGMP: Received IGMP Report on Ethernet1/3 *Feb 8 12:58:42.422: from 2.1.1.3 for 224.1.1.1 *Feb 8 12:58:42.422: CGMP: Sending Join on Ethernet1/3 *Feb 8 12:58:42.422: GDA 0100.5e01.0101, USA 0030.b655.a859
라우터 75b는 그룹 224.1.1.1에 대해 2.1.1.3에서 IGMP 보고서를 수신합니다. 그런 다음 MAC에 해당하는 CGMP Join을 스위치 A에 전송하고 2.1.1.3 관심 호스트의 MAC 주소(미국)와 224.1.1.1을 사용합니다.Switch A는 호스트가 어떤 포트를 사용하는지 파악하므로 해당 포트를 열린 상태로 표시하고 다른 포트를 차단합니다.
이제 Switch A에서 작업을 수행해야 합니다.
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 6 01-00-5e-01-01-01 2/3-4,2/6 Total Number of Entries = 2
이게 훨씬 나아요224.1.1.1(01-00-5e-01-01-01-01) 패킷은 필요에 따라 스위치 A의 포트 2/3, 2/4 및 2/6에서만 전송됩니다.다른 모든 포트에 대한 플러딩이 중지되었습니다.총 항목 수가 2로 올바르게 나열됩니다. MAC 주소 01-00-5e-00-01-28은 CGMP 자체 조인에 사용되는 멀티캐스트 주소 224.0.1.40에서 매핑됩니다.
CGMP는 소스/수신기 배치로 인해 멀티캐스트 패킷의 플러딩을 방지하지 않습니다.
이 섹션에서는 올바른 호스트 대신 모든 포트로 트래픽을 플러딩하는 Catalyst 스위치의 일반적인 문제에 대한 해결책을 제공합니다.이 네트워크 다이어그램은 예로 사용됩니다.
문제 진단
그림에서 라우터 75a, 75b 및 Catalyst 5000(스위치 A)은 멀티캐스트 및 CGMP(Cisco Group Management Protocol)에 맞게 올바르게 구성되었습니다. 호스트가 멀티캐스트 트래픽을 가져옵니다.그러나 스위치 A의 다른 모든 호스트도 마찬가지입니다. 스위치 A는 모든 포트에서 트래픽을 플러딩하므로 CGMP가 작동하지 않습니다.
스위치 A에서 show multicast group 명령의 출력은 다음과 같습니다.
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 Total Number of Entries = 1
출력에서 유일한 그룹이 224.0.1.40이라는 것을 확인할 수 있습니다. 이는 라우터가 auto-RP 그룹에 대해 CGMP 자체 조인을 전송할 때 사용됩니다.왜 다른 그룹이 없는 거죠?
가능한 수정
솔루션을 이해하려면 특정 조건에서 CGMP가 어떻게 동작하는지 이해해야 합니다.CGMP 지원 라우터는 CGMP 조인을 스위치에 전송하여 특정 멀티캐스트 그룹에 관심이 있는 호스트의 스위치에 알립니다.이 스위치는 CAM 테이블에서 이러한 호스트의 MAC 주소를 조회한 다음, 관심 있는 호스트가 있는 포트에서 멀티캐스트 패킷을 전달하고 다른 모든 포트가 멀티캐스트 패킷을 전달하지 못하도록 차단합니다.
라우터가 CGMP가 활성화된 동일한 인터페이스(라우터)에 있는 소스에서 멀티캐스트 패킷을 수신하는 경우 CGMP가 활성화된 인터페이스를 CGMP로 직접 조인합니다.
예를 들어, 소스가 라우터 75a 및 75b와 동일한 서브넷(VLAN)인 2.1.1.0/24에 있는 경우 CGMP는 완벽하게 작동합니다.소스에서 패킷이 표시되면 라우터가 CGMP 셀프 조인을 스위치에 전송하고, 그러면 라우터가 어떤 포트에 있는지 동적으로 확인하고 다른 모든 포트에서 멀티캐스트 패킷을 전달하는 것을 차단할 수 있습니다.
라우터가 CGMP가 활성화된 동일한 인터페이스(라우터)의 호스트에서 IGMP 보고서를 수신하는 경우 CGMP 지원 인터페이스를 전송합니다.
또 다른 예는 이 동일한 VLAN에 관심 있는 호스트가 있는 경우입니다.이 경우 CGMP 지원 라우터가 특정 멀티캐스트 그룹에 관심이 있는 호스트에서 IGMP(Internet Group Management Protocol) 보고서를 수신하면 라우터는 CGMP 조인을 보냅니다.조인은 가입하려는 호스트의 MAC(Media Access Control) 주소와 가입하려는 그룹을 나타냅니다.그런 다음 Catalyst 5000은 CAM 테이블에서 호스트의 MAC 주소를 확인하고, 연결된 포트를 멀티캐스트 그룹 목록에 추가하고, 기타 모든 관심 없는 포트를 차단합니다.
소스 및 관심 있는 호스트가 CGMP 지원 서브넷(VLAN) 이외의 서브넷에 있는 경우에도 마찬가지입니다. 소스에서 오는 멀티캐스트 패킷은 CGMP 셀프 조인을 스위치에 전송하도록 라우터를 트리거하지 않습니다.따라서 패킷이 스위치에 도달하고 VLAN 내의 모든 곳에 플러딩됩니다.이 시나리오는 스위치의 포트에서 나오는 VLAN의 호스트가 IGMP 조인을 전송할 때까지 계속됩니다.IGMP 보고서를 수신하는 경우에만 라우터가 CGMP 패킷을 전송하며, 그러면 스위치가 적절한 호스트 포트를 포워딩으로 추가하고 다른 모든 포트는 차단됩니다(라우터 포트 제외).
따라서 CGMP가 이 트랜짓 유형 토폴로지에서 작동하려면 이 네트워크 다이어그램에서와 같이 라우터 75a 및 75b와 동일한 VLAN에 호스트를 추가할 수 있습니다.
또는 이 예에서와 같이 라우터 75a 및 75b와 동일한 서브넷에서 소스를 이동합니다.
소스를 동일한 서브넷으로 이동한 다음 스위치 A의 출력을 확인합니다.
Console> (enable) show multicast router CGMP enabled IGMP disabled IGMP fastleave disabled Port Vlan --------- ---------------- 2/3 6 2/4 6 Total Number of Entries = 2 '*' - Configured Console> (enable) Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 6 01-00-5e-01-01-01 2/3-4 Total Number of Entries = 2
현재 224.1.1.1(01-00-5e-01-01-01-01-01)은 라우터 포트 2/3 및 2/4에만 플러딩되며 스위치 A의 모든 포트에는 플러딩되지 않습니다.
CGMP는 특정 그룹 주소에 대한 멀티캐스트 패킷의 플러딩을 방지하지 않습니다.
이 섹션에서는 일부 멀티캐스트 IP 주소로 인해 CGMP(Cisco Group Management Protocol)가 LAN(Local Area Network)의 모든 포트에서 멀티캐스트 트래픽을 플러딩하는 이유를 설명합니다. 멀티캐스트 그룹 주소 225.0.0.1을 사용하면 CGMP가 작동하지 않습니다.멀티캐스트 스트림을 플러딩하여 모든 스위치 포트를 사용하고 대역폭을 낭비합니다.그러나 주소를 225.1.1.1 CGMP로 변경하면 문제가 없습니다.라우팅 프로토콜에 대해 등록된 주소가 아니므로 225.0.0.1을 사용하는 데 문제가 있습니까?
가능한 수정
먼저 레이어 3 멀티캐스트 주소가 레이어 2 멀티캐스트 주소에 매핑되는 방식을 이해하는 것이 중요합니다.모든 IP 멀티캐스트 프레임은 24비트 접두사 0x0100.5e로 시작하는 IEEE MAC 레이어 주소를 사용합니다.레이어 3을 레이어 2 주소에 매핑하면 레이어 3 멀티캐스트 주소의 하위 23비트가 IEEE MAC 주소의 하위 23비트로 매핑됩니다.
또 다른 중요한 사실은 IP 멀티캐스트 주소에 대해 28비트의 고유한 주소 공간이 있다는 것입니다(32비트에서 110 클래스 D 접두사를 포함하는 첫 번째 4비트를 뺀 값). IEEE MAC 주소에는 23비트만 연결되어 있으므로 5비트의 중복이 남아 있습니다.즉, 여러 레이어 3 멀티캐스트 주소가 동일한 레이어 2 멀티캐스트 주소에 매핑될 수 있습니다.
예를 들면 다음과 같습니다.
224.0.0.1 = 1110 0000.0000 0000.0000 0000.0000 0001 in binary low order 23 bits = 000 0000.0000 0000.0000 0001 hex equivalent = 0 0 0 0 0 1 result of mapping = 0x0100.5e00.0001 224.128.0.1 = 1110 0000.1000 0000.0000 0000.0000 0001 in binary low order 23 bits = 000 0000.0000 0000.0000 0001 hex equivalent = 0 0 0 0 0 1 result of mapping = 0x0100.5e00.0001
이 예에서는 동일한 레이어 2 멀티캐스트 주소에 224.0.0.1 및 224.128.0.1 맵을 모두 매핑합니다.
레이어 3에서 레이어 2 멀티캐스트 주소가 어떻게 매핑되는지 알고 있으므로 이 문제에 대한 특정 솔루션으로 진행합니다.
Switch A는 멀티캐스트 패킷을 224.0.0.x로 플러딩합니다. 해당 주소는 링크-로컬이며 링크-로컬 주소가 LAN(Local Area Network)의 모든 디바이스에 연결되도록 하려는 경우. 또한 Catalyst 스위치는 224.0.0.x(예: 224.0.0.1 및 225.0.0.1은 모두 0100.5e00.0001에 매핑)로 모호한 MAC 레벨의 다른 멀티캐스트 주소로 멀티캐스트 패킷을 플러딩합니다. CGMP가 활성화되었는지 여부에 관계없이 스위치는 이러한 링크 로컬 주소로 향하는 멀티캐스트 패킷을 플러딩합니다.
따라서 멀티캐스트 애플리케이션은 16진수로 xx가 00~FF일 수 있는 레이어 2 멀티캐스트 주소 0100.5e00.00xx에 매핑되는 클래스 D 주소를 사용하지 않아야 합니다.이는 다음 클래스 D 주소로 구성됩니다.
224.0.0.x (x = 0 to 255) 225.0.0.x . 239.0.0.x 224.128.0.x (x = 0 to 255) 225.128.0.x . 239.128.0.x
중복 멀티캐스트 패킷 스트림을 수신함
원인 1
두 라우터가 덴스 모드에서 구성된 경우 중복 멀티캐스트 패킷이 수신됩니다.고밀도 모드에서는 디바이스가 정기적으로 스트림을 플러딩합니다.플러딩 후 증기가 필요하지 않은 인터페이스를 잘라냅니다.또한 두 라우터는 어설션 프로세스를 통해 전달자가 누구인지 결정합니다.타이머가 종료될 때마다 이 프로세스가 완료될 때까지 두 라우터는 스트림을 전달합니다.그러면 애플리케이션이 중복 멀티캐스트 스트림을 수신하게 됩니다.
가능한 수정 1
멀티캐스트 라우팅을 위해 구성된 라우터 중 하나와 업스트림의 RP가 되도록 다른 라우터를 구성하는 경우 이 문제를 해결할 수 있습니다.스트림이 라우터로 유입되기 전에 스트림을 스파스 모드로 변환하려면 이 스트림을 구성합니다.이렇게 하면 중복 패킷이 애플리케이션에 도달하는 것을 방지할 수 있습니다.중복 패킷이 최종 호스트에 도달하지 않도록 하는 것은 네트워크 책임의 일부가 아닙니다.중복 패킷을 처리하고 불필요한 데이터를 무시하는 것은 애플리케이션의 책임입니다.
원인 2
이 문제는 이그레스(egress) 멀티캐스트 복제 모드로 구성되고 모든 라인 카드[OIR]의 제거 및 재삽입으로 트리거될 수 있는 Cisco Catalyst 6500 스위치에서 발생할 수 있습니다.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
이를 해결하려면 인그레스 복제 모드로 변경합니다.이그레스(egress) 복제 모드에서 인그레스(ingress) 복제 모드로 변경하는 동안 바로가기가 제거되고 다시 설치되기 때문에 트래픽이 중단될 수 있습니다.
mls ip multicast replication-mode ingress
Cisco IOS 소프트웨어를 Cisco 버그 ID CSCeg28814(등록된 고객만 해당)의 영향을 받지 않는 릴리스로 업그레이드하여 문제를 영구적으로 해결합니다.
원인 3
이 문제는 엔드 호스트 또는 서버에서 RSS(Receive Side Scaling) 설정이 비활성화된 경우에도 발생할 수 있습니다.
가능한 수정 3
RSS 설정을 사용하면 여러 CPU에서 데이터를 보다 빠르게 전송할 수 있습니다.엔드-호스트 또는 서버에서 RSS 설정을 활성화합니다.자세한 내용은 Microsoft 문서 RSS를 통한 확장 가능 네트워킹 
을 참조하십시오.
멀티캐스트 패킷이 삭제되는 이유
원인 1
멀티캐스트 트래픽이 흐르면 인터페이스에서 과도한 플러시와 입력 패킷 삭제를 볼 수 있습니다.show interface 명령으로 플러시를 확인할 수 있습니다.
Switch#show interface gi 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 gi 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 join-group <group-name> 명령 대신 ip igmp static-group <group-name> 명령을 사용할 수 있습니다.
관련 정보
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
1.0 |
02-Dec-2013 |
최초 릴리스 |
피드백