Wednesday, February 25, 2009

PIM NBMA, DR and RPF issues

Below is the topology. RIP is running everywhere, PIM-SM on all interfaces and everyone has R4 at 192.168.100.4 as the static RP.


R1 has the following config on its LAN interface:
interface Ethernet0/0
ip address 192.168.0.1 255.255.255.0
ip pim sparse-mode
ip igmp join-group 239.0.0.1
Let's ping from R6:
R6#ping 239.0.0.1 re 5  

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:
.....
R6#
Hmmm....what gives? Let's look at R4:
R4#sho ip pim neighbor
PIM Neighbor Table
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
192.168.34.3 Ethernet0/0 03:29:50/00:01:39 v2 1 / S
192.168.100.2 Serial0/0 02:25:22/00:01:38 v2 1 / S
192.168.100.5 Serial0/0 02:25:22/00:01:39 v2 1 / DR S
192.168.100.1 Serial0/0 02:25:22/00:01:38 v2 1 / S

R4#sho ip mroute 239.0.0.1 | be \(
(*, 239.0.0.1), 00:24:31/00:02:33, RP 192.168.100.4, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/0, 192.168.100.2, Forward/Sparse, 00:24:31/00:02:33

(192.168.56.6, 239.0.0.1), 00:02:03/00:02:45, flags: T
Incoming interface: Serial0/0, RPF nbr 192.168.100.5
Outgoing interface list:
Serial0/0, 192.168.100.2, Forward/Sparse, 00:02:03/00:00:57

R4#
Well, it looks R2 is showing up in the OIL, but why isn't R1? It is a PIM neighbor afterall. The reason is because R2 has won the DR election and has the right to forward traffic. So it is the neighbor that sends PIM joins to R4. R1 receives the traffic, but it comes in on its LAN interface and thus fails the RPF check.

R1#debug ip mpacket
IP multicast packets debugging is on
03:40:21: IP(0): s=192.168.56.6 (Ethernet0/0) d=239.0.0.1 id=197, ttl=251, prot=1, len=114(100), not RPF interface
03:40:23: IP(0): s=192.168.56.6 (Ethernet0/0) d=239.0.0.1 id=198, ttl=251, prot=1, len=114(100), not RPF interface


It is important to remember we have at least two ways to resolve this:

1) Make R1 the DR

R1(config)#int e0/0
R1(config-if)#ip pim dr-priority 3000

R6#ping 239.0.0.1 re 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:

Reply to request 0 from 192.168.100.1, 60 ms
R6#

R1(config-if)#^Z
03:41:47: IP(0): s=192.168.56.6 (Serial0/0) d=239.0.0.1 (Ethernet0/0) id=207, ttl=252, prot=1, len=100(100), mforward


2) Static mroute to R2 for 192.168.56.6

R1(config)#int e0/0
R1(config-if)#no ip pim dr-priority 3000
R1(config-if)#exit
R1(config)#ip mroute 192.168.56.0 255.255.255.0 192.168.0.2

Make sure to clear mroutes otherwise previous state may mislead you :)

R4#clear ip mroute *

R6#ping 239.0.0.1 re 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:

Reply to request 0 from 192.168.100.1, 56 ms
R6#


This is one of those labs where I had no idea where I was going and I ended up with a nice troubleshooting scenario. If multicast is one your weaknesses than I highly recommend digging in and making something happen. Debug ip mpacket works best with "no ip mroute-cache" on your interfaces. In this scenario, I started troubleshooting on R5, then worked my way around to resolve the issue :)

6 comments:

  1. Hi there,

    So it is possible for the RP to have the Incoming and Outgoing Interface list on the same interface e.g. R4 has the OIL & IIL as Serial0/0.

    Why won't R1 receive on the Serial interface which points to the RP?

    Thanks.

    ReplyDelete
  2. think he said it in the post.. R2 won the DR selection so only R2 send (*,g) to RP. R1 dose nothing since it is not DR for segment 192.168.0.0/24

    ReplyDelete
  3. hi this is mark, taking ccie training in india. it's a very useful blog for aspirants like me.

    ReplyDelete
  4. why not to make R4 for DR, than it would be responsible for sending traffic to all clients

    ReplyDelete
  5. Hi! This is also an article, not to mention the whole blog, I find very useful for me who seems to be finding my way out from the dark. I am also new in this field and I am browsing for some posts that would make me understand it better.


    Hewlett from Amortisseur voiture

    ReplyDelete
  6. Wooah!! Its good that I've found this one.
    I am using the packet tracer and it seems like nothing happens with my configurations. Thanks, this works for me.

    Irene
    Kindly visit my blog, please cliquez ici.

    ReplyDelete

Note: Only a member of this blog may post a comment.