Sunday, October 27, 2013

[mini] Static RP Address Blocks auto-RP Dense Flows

My first 40 posts were written while I was attempting to improve my understanding of a number of topics.  At this point in my studying, I've moved on to practicing interoperability of features, so I haven't written any new posts in some time.  My first posts were between five and twenty page topic deep-dives.  Now that I've moved on to review & practice, I'm planning on starting a new series of posts, which I will label with [mini] in front of the subject.  These will cover any small problems that really got me stuck while doing practice labs. Same quality as my old posts, but much smaller scope.

Today, I got stuck on a multicast problem.

I have EIGRP running on every interface, and pim sparse-dense mode on every interface.
Every IP address has reachability to every other IP address.  The last octet IP on every segment is the router number.  Every router has a loopback of Y.Y.Y.Y where Y is the router number.

I was working a lab for auto-RP. In an equivalence for the simpler scenario above, R1 was the mapping agent and R2 was the RP candidate.  Then R3 would join, and R1 would send a ping towards and expect a reply.

The setup was as follows (remember, PIM sparse-dense and routing are already setup)

ip pim send-rp-discovery Loopback0 scope 10 interval 2

ip pim send-rp-announce Loopback0 scope 10 interval 2

interface FastEthernet0/0
 ip igmp join-group

And be damned if I could get the join on R3 to work.  I discovered pretty quickly that R3 wasn't learning the dynamic RP address:

R3#sh ip pim rp mapping
PIM Group-to-RP Mappings


"Well there's your problem!"

After a lot of digging, I finally noticed some odd output on R2:

R2#sh ip mroute | b 224
(*,, 00:15:00/stopped, RP, flags: SJCL
  Incoming interface: Null, RPF nbr
  Outgoing interface list:
    FastEthernet0/0, Forward/Sparse-Dense, 00:15:00/00:01:58

(,, 00:14:47/00:02:57, flags: PLJTX
  Incoming interface: FastEthernet0/0, RPF nbr
  Outgoing interface list: Null

It's pretty evident that (The mapping agent group) isn't going to reach R3, as the OIL lists "Null", and R3 isn't going to learn the RP address, and therefore isn't going to be able to join the group.  Let's look closer on that output:

R2#sh ip mroute | i 224
(*,, 00:21:47/stopped, RP, flags: SJCL
(,, 00:21:34/00:02:59, flags: PLJTX

What's up with those flags?

S=Sparse, P=Pruned ... wait a minute! is supposed to be dense mode forwarded.
Just to verify that, look at R1:

R1#sh ip mroute | i 224
(*,, 00:36:03/stopped, RP, flags: DCL
(,, 00:29:21/00:02:58, flags: LT


What the heck is R2 up to?
Turns out I didn't remove some debugging config I'd put in earlier, which as a whole is really nothing new on these type of tasks, but this one struck me as odd:

ip pim rp-address

In fact, let's take it out and see what happens:

R2(config)#no ip pim rp-address
R2#sh ip mroute | b 224
(*,, 00:00:18/stopped, RP, flags: DCL
  Incoming interface: Null, RPF nbr
  Outgoing interface list:
    FastEthernet0/1, Forward/Sparse-Dense, 00:00:18/00:00:00
    FastEthernet0/0, Forward/Sparse-Dense, 00:00:18/00:00:00

(,, 00:00:16/00:02:58, flags: LT
  Incoming interface: FastEthernet0/0, RPF nbr
  Outgoing interface list:
    FastEthernet0/1, Forward/Sparse-Dense, 00:00:16/00:00:00

I can't imagine why this behavior is there, but if you have ip pim rp-address Y.Y.Y.Y configured, the RP will automatically assume auto-RP groups originated by other routers are sparse mode instead of dense, which effectively breaks auto-RP.  That makes no sense to me, and it took me almost two hours to go pull this line of config out.  I also can't find any documentation on why this behavior happens.

In a nutshell: Configuring a static RP address on an auto-RP device will stop the device in question from sending auto-RP dense groups to downstream neighbors.


Jeff Kronlage

1 comment:

  1. Jeff I am a big fan... thanks for posting all this awesome stuff...

    I was testing your scenario... I was able to replicate your problem. and I wanted to see going into sparse mode...
    very interesting... I have been studying multicast really hard for last few month... knowing even running SSM (in sparse mode) Cisco router keep in Dense mode (infact as soon as you enable pim it does that)

    Another solution:
    ip pim autorp listener (on R2)
    changed *, back to Dense mode and R3 was able to get RP info.

    Thanks again for all your great posts