McDewey

Multi-vendor documentation library · semantic search · MCP endpoint at /mcp

Page 11

↗ View in doc context
page
11
source
ip/multicast/multicast-guide/multicast-guide.md
chunk_id
ip::multicast::multicast-guide::multicast-guide::10

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 has been joined on E1/2, which is fine. PIM dense mode is a flood and prune protocol, so there are no joins, but there are grafts. Since Router B has not received a flood from Router A, it does not know where to send a graft. You can check to see if it is a TTL issue with the sniffer capture and also seen with show ip traffic command:

<#root> 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

The output shows 63744 bad hop counts. Each time you type this command, the bad hop count increases. This is a strong indication that the sender sends packets with a TTL=1, which Router A decrements to zero. This results in an increase of the bad hop count field. Possible Fixes In order to solve the issue, you need to increase the TTL. This is done at the application level on the Sender. For more information, refer to your multicast application instruction manual. Once this is done, Router A looks like this:

<#root> 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