Troubleshooting PIM Sparse Mode

‚  < ‚  Free Open Study ‚  > ‚  

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.

Figure 13-5. Flowchart for Troubleshooting PIM Sparse Mode Problems

graphics/13fig05.gif

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.

Figure 13-6. Network Diagram for Case Study on PIM Sparse Mode Problem

graphics/13fig06.gif

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-routing   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.0   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.

‚  < ‚  Free Open Study ‚  > ‚  


Troubleshooting IP Routing Protocols
Troubleshooting IP Routing Protocols (CCIE Professional Development Series)
ISBN: 1587050196
EAN: 2147483647
Year: 2002
Pages: 260

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net