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.

Figure 13-3. Flowchart for Troubleshooting Multicast Dense Mode Problem

The case study that follows demonstrates a typical PIM RPF check problem. Figure 13-4 shows the network setup for such a case study.

Figure 13-4. Network Diagram for Case Study on PIM RPF Check Problem

Example 13-6 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-routing   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 1   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.1   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.