[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 239.0.0.1, and R1 would send a ping towards 239.0.0.1 and expect a reply.

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

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

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

R3:
interface FastEthernet0/0
 ip igmp join-group 239.0.0.1

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

R3#

"Well there's your problem!"

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

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

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

It's pretty evident that 224.0.1.40 (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 224.0.1.40 | i 224
(*, 224.0.1.40), 00:21:47/stopped, RP 2.2.2.2, flags: SJCL
(1.1.1.1, 224.0.1.40), 00:21:34/00:02:59, flags: PLJTX

What's up with those flags?

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

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

D=Dense

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:

R2:
ip pim rp-address 2.2.2.2

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

R2(config)#no ip pim rp-address 2.2.2.2
R2(config)#exit
R2#sh ip mroute 224.0.1.40 | b 224
(*, 224.0.1.40), 00:00:18/stopped, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  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

(1.1.1.1, 224.0.1.40), 00:00:16/00:02:58, flags: LT
  Incoming interface: FastEthernet0/0, RPF nbr 192.168.12.1
  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.

Cheers,

Jeff Kronlage