Troubleshooting PIM
Troubleshooting IGMP Joins
As discussed in Chapter 12, “Understanding Protocol Independent Multicast (PIM),” IGMP joins are a line of communication between the multicast receiver (host) and the router. IGMP joins are used by the multicast receiver to inform the multicast router that hosts on the local segment are interested in certain multicast groups; this allows the router to forward multicast packet to the segment. This section discusses issues with IGMP joins. Refer to Figure 13-1 for the troubleshooting flowchart on IGMP join issues.
Refer to Figure 13-2 for network setup of IGMP join problem.
In Figure 13-2, the multicast host is interested in joining multicast group 225.1.1.1. The multicast host sends the IGMP joins to the multicast address 224.0.0.2, which is the all routers multicast address. The problem is that Router A is not seeing the IGMP joins. To see which multicast groups are joined to the routers through IGMP, use the command show ip igmp group. Example 13-1 shows the show ip igmp group command output for Router A.
Example 13-1 show ip igmp group Command Output for Router A
RTR_A# show ip igmp group IGMP Connected Group MembershipGroup Address Interface Uptime Expires Last Reporter RTR_A#
The output in Example 13-1 shows that Router A is not seeing the IGMP joins from the multicast host. If Router A is not seeing the IGMP joins from the multicast host, the next logical step in troubleshooting is to question whether the multicast host is sending out IGMP joins and what the router did with the IGMP join packet. To see the IGMP transaction on a router, use the debug ip igmp command, as demonstrated in Example 13-2 for Router A.
Example 13-2 debug ip igmp Command Output on Router A
RTR_A# debug ip igmp IGMP: Received v2 Report from 150.150.2.2 (Ethernet0) for 225.1.1.1 IGMP: Group 225.1.1.1 access denied on Ethernet0
The debug output shows that the router is receiving the IGMP joins from the host, but they are rejected by the router. Example 13-3 shows Router A’s configuration.
Example 13-3 Router A Configuration
RTR A# show run ip multicast-routin interface ethernet 0 ip address 150.150.2.1 255.255.255.0 ip pim dense-mode ip igmp access-group 1 access-list 1 deny 224.0.0.0 3.255.255.255 access-list 1 permit any
The configuration in Example 13-3 reveals the reason why the 225.1.1.1 IGMP join is getting rejected—there is an access-group statement configured for IGMP on interface Ethernet 0. The access group is tied to access-list 1, which denies any group joins for the range of 224.0.0.0 to 227.255.255.255. The network administrator wants to deny only groups from 224.0.0.0 to 224.255.255.255, and this is a misconfiguration on the router.
Solution to IGMP Join Problem
The solution for this IGMP join problem is to change access-list 1 to match that shown in Example 13-4.
Example 13-4 Alteration of the Router A Configuration to Permit Joining the Multicast Group of 225.1.1.1
RTR_A# access-list 1 deny 224.0.0.0 0.255.255.255 access-list 1 permit any
With this new configuration, the router no longer will reject the IGMP join for the 225.1.1.1 group. Example 13-5 shows the debug on Router A and the output from the show ip igmp group command after the changes have been made.
Example 13-5 debug ip igmp and show ip igmp group Command Output on Router A
RTR_A# debug ip igmp IGMP: Received v2 Report from 150.150.2.2 (Ethernet0) for 225.1.1.1 RTR_A# show ip igmp group Group Address Interface Uptime Expires Last Reporter 225.1.1.1 Ethernet0 00:00:40 00:02:18 150.150.2.2
Now Router A shows the 225.1.1.1 group as joined in Ethernet 0 with the IP address of 150.150.2.2 as the IGMP reporter.
Troubleshooting PIM Dense Mode
Multicast dense mode operation is very simple—it uses the flood and prune mechanism to form a multicast forwarding tree. Because of the simplicity in operation, troubleshooting PIM dense mode is also very simple. Most of the PIM dense mode problem is related to Reverse-Path Forwarding (RPF) check failure and Time to Live (TTL) value problems. Figure 13-3 shows the troubleshooting flowchart for multicast dense mode.
The case study that follows demonstrates a typical PIM RPF check problem. Figure 13-4 shows the network setup for such a case study.
shows the pertinent configuration on the routers depicted in Figure 13-4.
Example 13-6 Multicast Router Configuration
Multicast Source# interface ethernet 0 ip address 172.16.1.1 255.255.255.0 _____________________________________________________________________________________ RTR_A# ip multicast-routin interface ethernet 0 ip address 172.16.1.2 255.255.255.0 ip pim dense mode interface serial 0 ip address 172.16.3.1 255.255.255.0 interface serial 1 ip address 172.16.2.1 255.255.255.0 ip pim dense mode router eigrp network 172.16.0.0 _____________________________________________________________________________________ RTR_B# ip multicast-routing ip multicast-routing interface ethernet 0 ip address 172.16.5.1 255.255.255.0 ip pim dense mode interface serial 0 ip address 172.16.3.2 255.255.255.0 interface serial 1 ip address 172.16.4.1 255.255.255.0 ip pim dense mode router eigrp 1 network 172.16.0.0 _____________________________________________________________________________________ RTR_C# ip multicast-routing interface serial 0 ip address 172.16.2.2 255.255.255.0 ip pim dense mode interface serial 1 ip address 172.16.4.2 255.255.255.0 ip pim dense mode router eigrp 1 network 172.16.0.0 _____________________________________________________________________________________ Multicast Receiver# ip address 172.16.5.2 255.255.255.0
The problem present in the case study is that the multicast server is sending a multicast stream to the group 225.1.1.1, but the multicast receiver is not getting the packet. When a problem like this is first presented, the first thing to do is to make sure that the TTL of the multicast stream from the server is more than 1 and that the TTL value is more than the total number of hops in the network. The TTL value is set on the multicast application in the server when sending the stream. To check the TTL value of the packet, a sniffer is needed to capture the multicast packet and to look inside the packet to determine the TTL value. In this case study, the TTL value of the multicast server is set to 15 hops. The next step in troubleshooting is to look at the multicast routing table. Example 13-7 shows the pertinent output of the show ip mroute command on Router A .
Example 13-7 show ip mroute Command Output for Router A
RTR_A# show ip mroute 225.1.1.1 IP Multicast Routing Table (*,225.1.1.1), Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet 0, Forward/Dense Serial 1, Forward/Dense (172.16.1.1/32, 225.1.1.1), Incoming interface: Ethernet 0, RPF nbr 0.0.0.0 Outgoing interface list: Serial 1, Forward/Dense
From the multicast routing table for Router A in Example 13-7, you can see that Router A has received the multicast stream from Ethernet 0 and is forwarding it to the and Serial 1 interface. The show ip mroute count command verifies that Router A is indeed forwarding the multicast stream, as demonstrated in Example 13-8.
Example 13-8 show ip mroute Command Output
RTR_A# show ip mroute 225.1.1.1 count Forwarding Counts: Pkt Count/Pkts per seconds/Avg Pkt Size/Kilobits per second Other Counts: Total/RPF failed/Other drops(OIF-null, rate-limit, etc) Group: 225.1.1.1, Source count: 1, Group pkt count: 29543 Source: 172.16.1.1/32, forwarding: 29543/195/1043/203, other: 0/0/0
As the output in Example 13-8 reveals, Router A is pumping a total of 29,543 packets, at 195 packets per second. show ip mroute count is an important show command because it confirms that a router is passing multicast packets and also reveals whether any multicast packet drops are occurring because of RPF failures. From the show command output in Examples 13-7 and 13-8, Router A looks fine. The next step is to go to the next hop, which is Router B. Example 13-9 shows the output from the show ip mroute 225.1.1.1 command on Router B.
Example 13-9 show ip mroute 225.1.1.1 Command Output for Router B
RTR_B# show ip mroute 225.1.1.1 IP Multicast Routing Table (*,225.1.1.1), Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet 0, Forward/Dense, Serial 0, Forward/Dense, Serial 1, Forward/Dense (172.16.1.1/32, 225.1.1.1), Incoming interface: Serial 1, RPF nbr 172.16.3. Outgoing interface list: Ethernet 0, Forward/Dense
The output in Example 13-9 reveals that Router B’s outgoing interface is Ethernet 0, which is in the forwarding state; however, the multicast receiver is not getting any multicast packets. The receiver has sent the IGMP joins to Router B, and Router B acknowledges it, as shown in Example 13-10.
Example 13-10 Router B’s Confirmation of IGMP Joins
RTR_B# show ip igmp group Group Address Interface Uptime Expires Last Reporter 225.1.1.1 Ethernet0 00:00:40 00:02:18 172.16.5.2
The next step is to see whether Router B is sending the multicast packet by executing the show ip mroute 225.1.1.1 count command, as demonstrated in Example 13-11.
Example 13-11 show ip mroute 225.1.1.1 Command Output on Router B
RTR_B# show ip mroute 225.1.1.1 count Forwarding Counts: Pkt Count/Pkts per seconds/Avg Pkt Size/Kilobits per second Other Counts: Total/RPF failed/Other drops(OIF-null, rate-limit, etc) Group: 225.1.1.1, Source count: 1, Group pkt count: 29543 Source: 172.16.1.1/32, forwarding: 29543/0/0/0, other: 29543/29543/0
Notice that Router B is not forwarding any packets on its Ethernet 0 interface. Router B still puts Ethernet 0 as in forwarding state because there is an active receiver on Ethernet 0. The RPF failed counter has been incrementing constantly. It appears that Router B is not for-warding packets to Ethernet 0 because of RPF check failure problems. RPF check failure means that the unicast routing path is not congruous with the multicast path. To verify, the routing table on Router B to the source network of 172.16.1.0/24 looks like Example 13-12.
Example 13-12 show ip route Command Output for Router B
RTR_B# show ip route 172.16.1.0 255.255.255.0 Routing entry for 172.16.1.0/24 Known via "EIGRP 1", distance 90, metric 2195456, type internal Redistributing via eigrp 1 Last update from 172.16.3.1 on Serial 0, 00:10:30 ago Routing Descriptor Blocks: * 172.16.3.1, from 172.16.3.1, 00:10:30 ago, via Serial 0 Route metric is 2195456, traffic share count is 1 Total delay is 21000 microseconds, minimum bandwidth is 1544 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1
The unicast routing table on Router B shows that it is using Serial 0 as the next hop to reach network 172.16.1.0/24; however, the multicast path points to Serial 1 based on the output of show ip mroute 225.1.1.1 on Router B. Notice that the RPF neighbor is listed as 172.16.3.1, its unicast path. Such discrepancies cause the RPF check to fail, and the router simply drops the packet.
Solution to PIM Dense Mode Problem
Looking at the configuration, Router A and Router B’s Serial 0 interfaces are not enabled for dense mode; however, this is the customer’s requirement. The customer doesn’t want multicast streams to congest the WAN link between Router A and Router B, and the customer also wants the multicast stream to flow in the direction of Router A, Router C, and then Router B. To fix the RPF problem and preserve the customer’s requirement, you need to configure a static multicast route on Router B so that the RPF check uses the static multicast route instead of the unicast routing table. Example 13-13 show the static multicast route configuration for Router B.
Example 13-13 Static Multicast Route Configuration for Router B
RTR_B# ip mroute 172.16.1.0 255.255.255.0 172.16.4.2
With this static multicast route in place, the RPF check in Router B succeeds and the multicast packet is forwarded to multicast receiver instead of being dropped. Example 13-14 shows the output from show ip mroute 225.1.1.1 and show ip mroute 225.1.1.1 count on Router B after the configuration change.
Example 13-14 show ip mroute Command Output on Router B
RTR_B# show ip mroute 225.1.1.1 IP Multicast Routing Table (*,225.1.1.1), Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet 0, Forward/Dense, Serial 0, Forward/Dense, Serial 1, Forward/Dense (172.16.1.1/32, 225.1.1.1), Incoming interface: Serial 1, RPF nbr 172.16.4.2 Outgoing interface list: Ethernet 0, Forward/Dense RTR_B# show ip mroute 225.1.1.1 count Forwarding Counts: Pkt Count/Pkts per seconds/Avg Pkt Size/Kilobits per second Other Counts: Total/RPF failed/Other drops(OIF-null, rate-limit, etc) Group: 225.1.1.1, Source count: 1, Group pkt count: 26721 Source: 172.16.1.1/32, forwarding: 26721/254/1253/318, other: 0/0/0
The output in Example 13-14 reveals that Router B is forwarding multicast packets on Ethernet 0 and that the multicast receiver now is receiving the multicast stream.
Troubleshooting PIM Sparse Mode
PIM sparse mode operates differently than dense mode and is more complex. The trouble-shooting steps are similar to the dense mode case. Figure 13-5 shows the troubleshooting flowchart for the PIM sparse mode problem.
The case study that follows examines troubleshooting a PIM sparse mode problem in which the leaf router sends joins to the RP. Figure 13-6 illustrates the network diagram of this case study.
From Figure 13-6, you can see that Router A and Router B form the connection from the multicast server to the receiver. Router C is connected to Network X, which is not directly connected to the multicast server’s network. The multicast server sends the multicast stream over multicast group 225.0.0.1. Example 13-15 shows the configuration for the routers in Figure 13-6. The sparse-dense mode configuration on the routers allows the router to run in sparse mode if the RP is present. If RP is not available, the routers will run in dense mode.
Example 13-15 Router Multicast Configuration
Multicast Source# interface ethernet 0 ip address 172.16.1.1 255.255.255.0 ___________________________________________________________________________________ RTR_A# ip multicast-routin interface ethernet 0 ip address 172.16.1.2 255.255.255.0 ip pim sparse-dense mode interface serial 0 ip address 172.16.2.1 255.255.255. ip pim sparse-dense mode router eigrp 1 network 172.16.0.0 ip pim send-rp-announce ethernet 0 scope 16 ip pim send-rp-discovery scope 16 _____________________________________________________________________________________ RTR_B# ip multicast-routing interface ethernet 0 ip address 172.16.3.1 255.255.255.0 ip pim sparse-dense mode interface serial 0 ip address 172.16.2.2 255.255.255.0 ip pim sparse-dense mode router eigrp 1 network 172.16.0.0 _____________________________________________________________________________________ RTR_C# ip multicast-routing interface ethernet 0 ip address 172.16.3.3 255.255.255.0 ip pim sparse-dense mode interface serial 1 ip address 172.16.4.1 255.255.255.0 ip pim sparse-dense mode router eigrp 1 network 172.16.0.0 _____________________________________________________________________________________ Multicast Receiver# interface ethernet 0 ip address 172.16.3.2 255.255.255.0
As the configurations in Example 13-15 show, Router A is the rendezvous point (RP) for all the multicast groups, and it announces its Ethernet 0 address as the RP address. The other routers discover the RP through the auto-rp mechanism. The auto-RP mechanism eliminates the need to manually configure the RP information in every router in the network. The auto-RP mechanism uses IP multicast to distribute the RP information to all routers in the network. The PIM routers discover the RP information through the multicast address of 224.0.1.40. In this case study, the problem arises when the receiver attempts to send the PIM IGMP join to the 224.0.0.2 multicast address. Router B and Router C both receive the IGMP join, but Router B is not sending the PIM sparse mode joins to the RP. Therefore, no forwarding tree is formed, and the multicast stream is not forwarded from the server to the receiver. Checking with the multicast server setup, the multicast stream has a TTL value of 15. If Router B is not sending the PIM sparse mode joins to the RP, the next step is to find out whether Router B is receiving multicast traffic from Router A. To do this, you need to look at only the multicast routing table of Router A, displayed in Example 13-16.
Example 13-16 show ip mroute Command Output from Router A
RTR_A# show ip mroute 225.1.1.1 IP Multicast Routing Table (*,225.1.1.1), Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet 0, Forward/Sparse-Dense, Serial 0, Forward/Sparse-Dense, (172.16.1.1/32, 225.1.1.1), Incoming interface: Ethernet 0, RPF nbr 0.0.0.0 Outgoing interface list: Null
Looking at the (S,G) entry, the output shows that the Router A’s outgoing interface list is null for group 225.1.1.1, indicating that no downstream routers are interested in receiving packets for this group. As the show ip igmp group command output for Router B in Example 13-17 reveals, however, there is a receiver 172.16.3.2 that already has joined group 225.1.1.1 through IGMP.
Example 13-17 show ip igmp group Command Output for Router B
RTR_B# show ip igmp group Group Address Interface Uptime Expires Last Reporter 225.1.1.1 Ethernet0 00:00:40 00:02:18 172.16.3.2
The next step is to find out whether there are any other neighbors in Router B’s Ethernet and which router is the designated router (DR) of this segment. It is important to determine the DR because the DR is the router that is responsible for sending PIM joins to the RP. To find out which router is the DR, look at the output generated from the show ip pim neighbor command, as demonstrated in Example 13-18 for Router B.
Example 13-18 show ip pim neighbor Command Output on Router B
RTR_B# show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires 172.16.3.3 Ethernet 0 00:50:23 00:01:30 (DR)
As the output in Example 13-18 reveals, Router B’s Ethernet segment has another neighbor in it with the address of 172.16.3.3 (Router C), and the neighbor is the DR of the segment. The next step is to check whether Router C has the RP information, as determined from the show ip pim rp command in Example 13-19.
Example 13-19 show ip pim rp Command Output on Router C
RTR_C# show ip pim rp Group: 225.1.1.1, RP:172.16.1.2, uptime 01:34:12, expires never
As this output confirms, Router C has RP information for group 225.1.1.1. The next step is to determine whether Router C has a route to the RP. Example 13-20 shows the results from checking Router C’s routing table for the RP address of 172.16.1.2.
Example 13-20 show ip route Command Output on Router C
RTR_C# show IP route 172.16.1.2 Routing entry for 172.16.1.0/24 Known via "EIGRP 1", distance 90, metric 2221056, type internal Redistributing via eigrp 1 Last update from 172.16.3.1 on Ethernet 0, 00:17:30 ago Routing Descriptor Blocks: *172.16.3.1,from 172.16.3.1, 00:17:30 ago, via Ethernet 0 Route metric is 2221056, traffic share count is 1 Total delay is 22000 microseconds, minimum bandwidth is 1544 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 2
Notice that the routing table shows that the route is from the Ethernet 0 interface, which is the interface that heard the IGMP joins. Because of this, Router C will not send a join to the RP.
Solution to PIM Sparse Mode Problem
The problem in the preceding case study is that Router C doesn’t have any other way of getting to the RP except through the interface that receives the IGMP joins. One solution is to make Router B the DR for the segment. To do this, Router B must have a higher IP address than all the routers in the segment. Changing Router B’s Ethernet address to 172.16.3.254 will ensure that Router B is the DR for the segment and will send PIM joins to the RP.