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 장애의 일반적인 문제에 대한 해결책을 제공합니다. 이 네트워크 다이어그램은 예시입니다.
멀티캐스트 RPF 실패의 네트워크 다이어그램 예
이 그림에서 멀티캐스트 패킷은 IP 주소가 10.1.1.1인 서버에서 라우터 75a의 E0/0으로 들어와 그룹 10.224.1.1로 전송됩니다. 이를 (S,G) 또는 (10.1.1.1, 10.224.1.1)이라고 합니다.
문제 진단
라우터 75a에 직접 연결된 호스트는 멀티캐스트 피드를 수신하지만 라우터 72a에 직접 연결된 호스트는 수신하지 않습니다. 먼저 show ip mroute 224.1.1.1 명령을 사용하여 라우터 75a에서 활동을 확인합니다. 이 명령은 그룹 주소 10.224.1.1에 대한 멀티캐스트 경로(mroute)를 검사합니다.
75a#show ip mroute 10.224.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
(*, 10.224.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
(10.1.1.1, 10.224.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 고밀도 모드(D 플래그를 통해 고밀도 모드임을 알 수 있음)를 실행하므로 *, G 항목을 무시하고 S, G 항목에 중점을 둡니다. 이 엔트리는 멀티캐스트 패킷이 주소가 10.1.1.1인 서버에서 소싱되며, 이를 10.224.1.1의 멀티캐스트 그룹으로 전송합니다. 패킷은 Ethernet0/0 인터페이스로 들어오고 Ethernet0/1 인터페이스 외부로 전달됩니다. 이는 완벽한 시나리오입니다.
다음을 입력합니다. show ip pim neighbor 라우터(72a)가 업스트림 라우터(75a)를 PIM 네이버로 표시하는지 확인하기 위한 명령:
ip22-72a#show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires Ver Mode 10.2.1.1 Ethernet3/1 2d00h 00:01:15 v2
에서 show ip pim neighbor 명령 출력, PIM 네이버십이 정상인 것 같습니다.
다음을 입력합니다. show ip mroute 라우터 72a에 좋은 mroute가 있는지 확인하기 위한 명령:
ip22-72a#show ip mroute 10.224.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
(*, 10.224.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
(10.1.1.1, 10.224.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#
Firepower Management Center의 show ip mroute 10.224.1.1 명령을 실행하여 들어오는 인터페이스는 Ethernet2/0이지만 Ethernet3/1이 필요합니다.
다음을 입력합니다. show ip mroute 10.224.1.1 count 이 그룹에 대한 멀티캐스트 트래픽이 라우터 72a에 도착하는지 확인하고 다음에 무슨 일이 발생하는지 확인하기 위한 명령:
ip22-72a#show ip mroute 10.224.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: 10.224.1.1, Source count: 1, Packets forwarded: 0, Packets received: 471
Source: 10.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0
ip22-72a#
Other 카운트에서 RPF 실패로 인해 트래픽이 삭제됨을 확인할 수 있습니다. RPF 실패로 인해 총 471개가 삭제됩니다. 471개...
다음을 입력합니다. show ip rpf 명령을 사용하여 RPF 오류가 있는지 확인합니다.
ip22-72a#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet2/0 RPF neighbor: ? (0.0.0.0) RPF route/mask: 10.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 라우팅 테이블, 고정 Mroute 테이블입니다. RPF 인터페이스를 계산할 때는 주로 AD(Administrative Distance)를 사용하여 RPF 계산에 사용되는 정보의 소스를 정확하게 결정합니다. 구체적인 규칙은 다음과 같습니다.
-
RPF 데이터의 모든 이전 소스가 소스 IP 주소에서 일치하는지 검색됩니다. 공유 트리를 사용하는 경우 소스 주소 대신 RP 주소가 사용됩니다.
-
일치 경로가 두 개 이상 있는 경우 관리 거리가 가장 낮은 경로가 사용됩니다.
-
AD(Administrative Distance)가 같으면 다음의 환경설정 순서가 사용됩니다.
-
고정 mroute
-
DVMRP 라우트
-
MBGP 라우트
-
유니캐스트 라우트
-
-
하나의 라우트에 대한 여러 항목이 동일한 라우트 테이블 내에서 발생하는 경우 가장 긴 일치 경로가 사용됩니다.
이 show ip mroute 224.1.1.1 명령 출력에서는 RPF 인터페이스가 E2/0임을 표시하지만, 수신 인터페이스는 E3/1이어야 합니다.
다음을 입력합니다. show ip mroute 224.1.1.1 명령을 실행하여 RPF 인터페이스가 예상과 다른 이유를 확인합니다.
ip22-72a#show ip route 10.1.1.1 Routing entry for 10.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 10.1.1.1 명령 출력에서 고정 /32 경로가 있음을 알 수 있습니다. 이 경우 잘못된 인터페이스가 RPF 인터페이스로 선택됩니다.
몇 가지 추가적인 디버그 명령을 입력합니다.
ip22-72a#debug ip mpacket 10.224.1.1 *Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface *Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface *Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface *Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface
패킷이 올바른 E3/1에 들어옵니다. 그러나 이는 유니캐스트 라우팅 테이블이 RPF 확인에 사용하는 인터페이스가 아니므로 삭제됩니다.
가능한 해결 방안
이 요구 사항을 충족하기 위해 유니캐스트 라우팅 테이블을 변경할 수도 있고, 유니캐스트 라우팅 테이블의 상태에 관계없이 멀티캐스트를 특정 인터페이스에 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 좋아 보입니다. 전송된 패킷의 수는 show ip mroute count HostA가 패킷을 수신합니다.
ip22-72a#show ip mroute 10.224.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
(*, 10.224.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, 10.224.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 10.224.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: 10.224.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 10.224.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: 10.224.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 10.224.1.1
*Jan 14 10:18:29.951: IP: s=10.1.1.1 (Ethernet3/1)
d=10.224.1.1 (Ethernet3/2) len 60, mforward
*Jan 14 10:18:29.999: IP: s=10.1.1.1 (Ethernet3/1)
d=10.224.1.1 (Ethernet3/2) len 60, mforward
*Jan 14 10:18:30.051: IP: s=10.1.1.1 (Ethernet3/1)
d=10.224.1.1 (Ethernet3/2) len 60, mforward
소스의 TTL 설정으로 인해 라우터가 멀티캐스트 패킷을 호스트로 전달하지 않음
이 섹션에서는 TTL(Time To Live) 값이 0으로 감소되어 전달되지 않는 IP 멀티캐스트 패킷의 일반적인 문제에 대한 해결책을 소개합니다. 이는 멀티캐스트 애플리케이션이 많기 때문에 흔히 발생하는 문제입니다. 이러한 멀티캐스트 애플리케이션은 주로 LAN 사용을 위해 설계되었으므로 TTL을 낮은 값 또는 심지어 1로 설정합니다. 이 네트워크 다이어그램을 예로 들어 보십시오.
주로 LAN 사용을 위해 설계된 멀티캐스트 애플리케이션 예
문제 진단
이전 그림에서 라우터 A는 소스(S)에서 직접 연결된 라우터 B로 패킷을 전달하지 않습니다. Cisco에서 제공하는 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
(*, 10.224.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 그룹에 조인하므로 출력에서 10.224.0.40을 무시할 수 있습니다. 그러나 10.224.1.1에 대해 나열된 소스는 없습니다. "*, 10.224.1.1" 외에도 "10.1.1.1, 10.224.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
수신자가 그룹 10.224.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 10.224.1.1 Ethernet1/2 00:30:02 00:02:45 10.3.1.2
E1/2에 10.224.1.1이 결합되었습니다.
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개의 잘못된 홉 수가 표시됩니다. 이 명령을 입력할 때마다 불량 홉 수가 증가합니다. 이는 발신자가 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
(*, 10.224.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, 10.224.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
(*, 10.224.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, 10.224.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 10.224.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
(*, 10.224.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, 10.224.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 10.224.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=10.224.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.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
command는 TTL이 지정된 임계값보다 낮은 모든 패킷(이 경우 15)이 전달되지 않음을 의미합니다. 이 명령은 일반적으로 내부 멀티캐스트 트래픽이 인트라넷에서 드리프트하는 것을 방지하기 위한 경계를 제공하기 위해 사용됩니다.
가능한 해결 방안
다음 중 하나를 ip multicast ttl-threshold
이 명령의 no 형식이 포함된 명령이며, 기본 TTL 임계값인 0으로 되돌려지거나 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 10.224.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
(*, 10.224.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, 10.224.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 10.224.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
(*, 10.224.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, 10.224.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 멀티캐스트 구성
이 그림에서 라우터 75b는 소스에 대한 3개의 동일 비용 경로(10.1.1.1)를 가지고 있습니다. 세 링크 모두에서 멀티캐스트 트래픽을 로드 밸런싱하려고 합니다.
가능한 해결 방안
여러 동일 비용 경로로 인한 원치 않는 RPF 동작 섹션에서 살펴본 것처럼, PIM(Protocol Independent Multicast)은 RPF 확인을 위한 인터페이스 하나만을 선택하고 나머지 인터페이스는 정리합니다. 따라서 로드 밸런싱이 발생하지 않습니다. 로드 밸런싱을 수행하려면 이중화된 링크에서 PIM을 제거하고 라우터 75a와 라우터 75b 사이에 터널을 생성해야 합니다. 그런 다음 링크 수준에서 로드 밸런싱을 수행하면 IP가 터널을 통해 실행됩니다.
터널의 구성은 다음과 같습니다.
| 라우터 75a |
|---|
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 |
| 라우터 75b |
|---|
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 10.224.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
(*, 10.224.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, 10.224.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 10.224.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
(*, 10.224.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, 10.224.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 (*, 10.224.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 10.224.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
What is the accept-rp 수행할 수 있는 구성 명령문입니까? IP Multicast Routing 명령에서 "지정된 RP 및 특정 그룹 목록을 대상으로 하는 조인 또는 프룬을 허용하도록 라우터를 구성하려면 ip pim accept-rp 전역 환경 설정 명령입니다. 확인을 제거하려면 이 명령의 no 형식을 사용합니다."
를 제거할 때 ip pim accept-rp 메시지가 사라집니다. 문제의 원인이 되는 명령이 발견되었지만 구성에서 해당 명령을 실행하려면 어떻게 해야 합니까? 잘못된 RP 주소를 허용할 수 있습니다. 다음을 입력합니다. show ip pim rp mapping 명령을 사용하여 올바른 RP 주소를 확인합니다.
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가 그룹 10.224.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#
10.224.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를 그룹 10.224.1.1의 RP로 지정하거나 라우터3에서 올바른 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#
CGMP가 멀티캐스트 패킷의 플러드를 방지하지 않음
이 섹션에서는 CGMP(Cisco Group Management Protocol)가 특정 서브넷의 모든 라우터에서 활성화되지 않은 경우 멀티캐스트 패킷의 원치 않는 플러딩이 발생할 수 있는 방법과 이러한 문제를 방지할 수 있는 방법을 설명합니다. 이 네트워크 다이어그램은 예시입니다.
CGMP(Cisco Group Management Protocol)가 활성화되지 않음
문제 진단
그림에서 Catalyst 5000 스위치 A의 고정 CAM 테이블에는 올바른 포트가 표시되어 있지 않습니다. CGMP 구성 라우터는 CGMP 패킷을 전송하지 않습니다.
CGMP는 set cgmp enable 명령 및 ip cgmp 라우터 75a의 E0/2 인터페이스에서 명령을 실행합니다. 그러나 다음 경우에는 스위치 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] ---- ------------------ ----- ------------------------------------------- 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 10.2.1.1 Ethernet0/2 00:07:41 00:01:34 v2
출력은 라우터 75a가 스위치 A를 통해 라우터 75b를 유효한 인접 PIM으로 볼 수 있음을 보여줍니다.
이제 라우터에서 올바른 멀티캐스트 경로(mroute) 정보를 수신하는지 확인합니다.
ip22-75a#show ip mroute 10.224.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
(*, 10.224.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
(10.1.1.1, 10.224.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로 전달하는 것을 보여줍니다. 이 출력은 라우터 75b가 멀티캐스트 패킷을 수신하여 올바르게 전달하는 것을 보여줍니다.
ip22-75b#show ip mroute 10.224.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
(*, 10.224.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
(10.1.1.1, 10.224.1.1), 00:00:35/00:02:59, flags: CTA
Incoming interface: Ethernet1/3, RPF nbr 10.2.1.2
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 00:00:35/00:00:00
스위치 A의 관점에서 보면 라우터 75a가 포트 2/3에서 벗어난 것을 볼 수 있습니다.
Console> (enable) show multicast router CGMP enabled IGMP disabled IGMP fastleave disabled Port Vlan --------- ---------------- 2/3 6 Total Number of Entries = 1
지금까지 모든 것이 정상으로 보입니다. 일부 입력 debug 라우터 75a의 명령을 사용하여 확인할 수 있는 내용을 확인합니다.
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 Join/Leave 메시지를 보낼 때 사용됩니다. 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 10.2.1.3 (Ethernet0/2) for 10.224.1.1
그러나 이후 라우터 75a에서 해당 CGMP 패킷이 표시되지 않습니다. 이는 라우터 75a가 IGMP 보고서를 수신하지만 스위치 A가 어떤 포트를 차단할지 파악하는 데 필요한 CGMP 패킷을 생성하지 않음을 의미합니다. 이는 라우터 75a가 IGMP 쿼리 발송기인 경우 예상되는 상황입니다. 라우터 75a의 이러한 출력은 예상되는 동작이 발생하지 않는 이유를 알려줍니다.
ip22-75a#show ip igmp interface e0/2 Ethernet0/2 is up, line protocol is up Internet address is 10.2.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 10.2.1.2 (this system) IGMP querying router is 10.2.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입니다. 먼저 전원을 켭니다. debug 라우터 75b의 명령:
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 10.2.1.3 (Ethernet1/3) for 10.224.1.1 *Feb 8 12:58:42.422: CGMP: Received IGMP Report on Ethernet1/3 *Feb 8 12:58:42.422: from 10.2.1.3 for 10.224.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는 10.2.1.3에서 그룹 10.224.1.1에 대한 IGMP 보고서를 받습니다. 그런 다음 10.2.1.3 관련 호스트의 MAC 주소(미국)를 사용하여 10.224.1.1에 해당하는 MAC에 대해 스위치 A로 CGMP 조인을 보냅니다. 스위치 A는 호스트가 켜져 있는 포트를 확인하므로 해당 포트를 열린 포트로 표시하고 다른 포트는 차단합니다.
이제 스위치 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
훨씬 더 좋습니다. 10.224.1.1(01-00-5e-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 스위치의 일반적인 문제에 대한 해결책을 제공합니다. 이 네트워크 다이어그램은 예시입니다.
모든 포트에 트래픽을 플러딩하는 Catalyst 스위치
문제 진단
그림에서 라우터 75a 및 75b와 Catalyst 5000(스위치 A)은 멀티캐스트 및 CGMP(Cisco Group Management Protocol)에 대해 올바르게 구성되어 있습니다. 호스트가 멀티캐스트 트래픽을 가져옵니다. 그러나 스위치 A의 다른 모든 호스트도 마찬가지입니다. 스위치 A는 모든 포트에서 트래픽을 플러딩하므로 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] ---- ------------------ ----- ------------------------------------------- 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) 10.2.1.0/24에 있는 경우 CGMP는 완벽하게 작동합니다. 라우터가 소스에서 패킷을 식별하면 CGMP 셀프 조인을 스위치로 전송합니다. 그러면 라우터가 어떤 포트에 있는지 동적으로 파악하고 다른 모든 포트에서 멀티캐스트 패킷 전달을 차단할 수 있습니다.
라우터가 CGMP를 활성화한 것과 동일한 인터페이스의 호스트에서 IGMP 보고서를 수신하는 경우, 라우터는 CGMP 기반 인터페이스를 통해 CGMP 조인을 전송합니다.
또 다른 예는 동일한 VLAN에 관련 호스트가 있는 경우입니다. 이 경우 CGMP 기반 라우터가 특정 멀티캐스트 그룹에 관련된 호스트로부터 IGMP(Internet Group Management Protocol) 보고서를 수신하면 라우터는 CGMP 조인을 전송합니다. 조인은 가입하려는 호스트의 MAC(Media Access Control) 주소와 가입하려는 그룹을 나타냅니다. 그런 다음 Catalyst 5000은 CAM 테이블에서 호스트 MAC 주소를 확인하고, 연결된 포트를 멀티캐스트 그룹 목록에 추가하고, 관심이 없는 다른 모든 포트를 차단합니다.
소스 및 관련 호스트가 CGMP 기반 서브넷이 아닌 서브넷에 있는 경우에도 마찬가지입니다. 소스에서 오는 멀티캐스트 패킷은 라우터가 CGMP 셀프 조인을 스위치로 전송하도록 트리거하지 않습니다. 따라서 패킷이 스위치에 도달하여 VLAN 내의 모든 위치에 플러딩됩니다. 이 시나리오는 스위치의 포트에서 나오는 VLAN의 호스트가 IGMP 조인을 전송할 때까지 계속됩니다. IGMP 보고서를 수신하는 경우에만 라우터가 CGMP 패킷을 전송합니다. 그러면 스위치가 적절한 호스트 포트를 전달로 추가하고 다른 모든 포트가 차단됩니다(라우터 포트 제외).
CGMP가 이러한 전송 유형 토폴로지에서 작동하려면 이 네트워크 다이어그램에서처럼 라우터 75a 및 75b와 동일한 VLAN에 호스트를 추가할 수 있습니다.
라우터 75a 및 75b와 동일한 VLAN에 호스트 추가
또는 이 예에서와 같이 라우터 75a 및 75b와 동일한 서브넷에서 소스를 이동합니다.
라우터 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
CGMP가 특정 그룹 주소에 대한 멀티캐스트 패킷의 플러딩을 방지하지 않음
이 섹션에서는 일부 멀티캐스트 IP 주소로 인해 CGMP(Cisco Group Management Protocol)가 LAN(Local Area Network)의 모든 포트에서 멀티캐스트 트래픽을 플러딩하는 이유를 설명합니다. 멀티캐스트 그룹 주소 10.225.0.1을 사용하면 CGMP가 작동하지 않습니다. 모든 스위치 포트에서 멀티캐스트 스트림을 플러딩하고 대역폭을 낭비합니다. 그러나 주소를 10.225.1.1로 변경하면 CGMP가 정상적으로 작동합니다. 10.225.0.1은 라우팅 프로토콜의 등록 주소가 아니므로 사용할 수 있습니까?
가능한 해결 방안
먼저 레이어 3 멀티캐스트 주소가 레이어 2 멀티캐스트 주소에 매핑되는 방식을 이해해야 합니다. 모든 IP 멀티캐스트 프레임은 24비트 접두사 0x0100.5e로 시작하는 IEEE MAC 레이어 주소를 사용합니다. 레이어 3을 레이어 2 주소에 매핑하면 레이어 3 멀티캐스트 주소의 하위 23비트가 IEEE MAC 주소의 하위 23비트에 매핑됩니다.
또 다른 중요한 사실은 IP 멀티캐스트 주소를 위한 28비트의 고유한 주소 공간(32비트에서 1110 클래스 D 접두사를 포함하는 첫 4비트를 뺀 값)이 있다는 것입니다. IEEE MAC 주소에는 23비트만 연결되어 있으므로 5비트 중복이 유지됩니다. 즉, 여러 레이어 3 멀티캐스트 주소가 동일한 레이어 2 멀티캐스트 주소에 매핑될 수 있습니다.
예를 들면 다음과 같습니다.
10.244.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 10.244.128.0 = 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
이 예시에서 10.244.0.1과 10.244.128.0은 모두 동일한 레이어 2 멀티캐스트 주소에 매핑됩니다.
레이어 3에서 레이어 2로 멀티캐스트 주소가 매핑되는 방식을 알아보았습니다. 이번에는 이 문제에 대한 구체적인 해결책을 알아보겠습니다.
스위치 A는 멀티캐스트 패킷을 주소 224.0.0.x로 플러딩합니다. 이러한 주소는 링크-로컬이며 LAN(Local Area Network)의 모든 디바이스에 링크-로컬 주소를 가져오게 하려는 것입니다. 또한 Catalyst 스위치는 MAC 레벨이 224.0.0.x로 모호한 다른 멀티캐스트 주소(예: 10.244.0.1 및 10.225.0.1 모두 0100.5e00.0001에 매핑)로 멀티캐스트 패킷을 플러딩합니다. 스위치는 CGMP의 활성화 여부에 관계없이 이러한 링크 로컬 주소로 향하는 멀티캐스트 패킷을 플러딩합니다.
따라서 멀티캐스트 애플리케이션은 레이어 2 멀티캐스트 주소 0100.5e00.00xx에 매핑되는 클래스 D 주소를 사용하지 않아야 합니다. 여기서 xx는 16진수로 00부터 FF까지 가능합니다. 이는 다음 클래스 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) 멀티캐스트 복제 모드에 구성된 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
멀티캐스트 트래픽이 흐르면 인터페이스에서 과도한 플러시 및 입력 패킷 삭제를 확인할 수 있습니다. Firepower Threat Defense에서 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
Cisco Collaboration Architecture를 ip igmp join-group
명령을 실행하면 스위칭이 수행됩니다. 멀티캐스트 패킷이 인터페이스에서 프로세스 전환되는 경우, 해당 그룹에 대한 모든 패킷의 프로세스를 전환해야 하므로 CPU 사용량이 증가합니다. Firepower Threat Defense에서 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
Firepower Threat Defense ip igmp static-group
명령 대신 ip igmp join-group
명령을 실행합니다.
관련 정보
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
2.0 |
26-May-2023 |
재인증 |
1.0 |
02-Dec-2013 |
최초 릴리스 |
피드백