ip pim autorp listener should be named ip pim autorp forwarder

There is a fair amount of confusion about what exactly ip pim autorp listener actually does, or on which router to configure it. This probably stems from the fact that it has the word ‘listener’ in the command when it really doesn’t configure the router to listen for anything. Let’s take the following diagram into consideration for this post:

I’ve configured OSPF on all interfaces, including loopbacks, and configured ip pim sparse-mode on all interfaces

Auto-RP uses the multicast addresses of 224.0.1.39 and 224.0.1.40
224.0.1.39 is the AUTO-RP-ANNOUNCE group and is used by the mapping agent (send-rp-discovery) router to listen for routers sending candidate announcements. i.e. Candidate RPs send multicast traffic TO 224.0.1.39 and the mapping agent joins this group to RECEIVE that traffic
224.0.1.40 is the AUTO-RP-DISCOVERY group and is sent from the mapping agent out so that other multicast routers can get information on which address is the rendezvous point. i.e. The mapping agent sends traffic to this group, and all multicast routers join this group so that they can receive this traffic

The problem is that routers are running sparse-mode. How can they join a group if they don’t know the location of the RP? A classic chicken and egg scenario.

Let’s start off with a basic config. We’ll check the mroute table along the way as well as check what auto-rp packets are getting sent by which routers via wireshark. On R1 I’ve enabled ip pim on it’s interfaces and enabled ip multicast-routing. Nothing else. Let’s take a look at the mroute table:

R1#sh ip mroute | beg \(
(*, 224.0.1.40), 00:03:25/00:02:25, RP 0.0.0.0, flags: DPL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

This router is already listening to the 224.0.1.40 group. The group that contains messages from the mapping agent to let it know where the RP is. So the router is already ‘listening’ The flags are DPL and mean Dense/Pruned/Local. Checking wireshark, there is no traffic destined to 224.0.1.39 or .40 as expected.

On R1, let’s configure the router to it considers itself a candidate RP:

R1(config)#ip pim send-rp-announce lo0 scope 10 interval 5

I’m also going to debug any auto-rp messages via the other routers:

R2#debug ip pim auto-rp
PIM Auto-RP debugging is on

Wireshark shows me that R1 is sending an auto-rp packet every 5 seconds. Source is 1.1.1.1 and destination is 224.0.1.39 which is expected. 224.0.1.39 is the group that the mapping agent will join to receive these announcements.

So wireshark is showing that R2 receives these packets. Wireshark also shows that R2 does not forward these packets in a dense-mode fashion (I’m not going to paste an empty wireshark capture)

Now I’m going to enable ip pim autorp listener on R2. This will cause R2 to flood the two autorp groups in a dense mode fashion. This means R3 will receive those frames, but not forward them onto R4:

R2(config)#ip pim autorp listener

Straight away on gi2/0 of R2 I see the following packet getting sent:

This now means that R3 is receiving packets destined to 224.0.1.39, but R4 still isn’t. But let’s use this to our advantage. Let’s make R3 the mapping agent. This will cause it to consider R1 to be the RP and it will flood those frames out it’s directly connected interfaces.

R3(config)#ip pim send-rp-discovery lo0 scope 10 interval 5

R3 already received the packets destined to 224.0.1.39 via R2. This allows it to make an informed decision and maps R1 to be the RP for 224.0.0.0/4 – It then sends messages out to 224.0.1.40 which all routers are already listening for

My debug auto-rp shows the following on R1, R2, and R4:

*Jan 14 13:27:29.531: Auto-RP(0): Received RP-discovery packet of length 48, from 3.3.3.3, RP_cnt 1, ht 16
*Jan 14 13:27:29.531: Auto-RP(0): Update (224.0.0.0/4, RP:1.1.1.1), PIMv2 v1

Even R4 knows about the RP and can now join groups:

R4#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 1.1.1.1 (?), v2v1
    Info source: 3.3.3.3 (?), elected via Auto-RP
         Uptime: 00:04:16, expires: 00:00:15

However R5 has no mappings whatsoever. This is because while R4 is receiving packets destined to 224.0.1.40, it’s not forwarding them. So let’s configure autorp listener on R4:

R4(config)#ip pim autorp listener

Straight away on R5:

*Jan 14 13:32:18.511: Auto-RP(0): Received RP-discovery packet of length 48, from 3.3.3.3, RP_cnt 1, ht 16
*Jan 14 13:32:18.511: Auto-RP(0): Added with (224.0.0.0/4, RP:1.1.1.1), PIMv2 v1

Wireshark confirms that autorp packets are now being sent out R4’s gi2/0 interface

So here I have five routers running auto-rp in sparse mode. I’ve only configured autorp listener on two routers – R2 and R4

Conclusions

  • Autorp listener doesn’t cause the router to listen for anything, rather it causes the router to dense flood groups 224.0.1.39 and 224.0.1.40 when it receives them
  • This means that routers at the end of the path, or certain routers running as the candidate RP or MA do not actually need to be configured with autorp listener
  • I mentioned certain routers, as if your topology has multiple candidate RPs or MAs then each would would need to ensure that dense flood packets from OTHER RPs or MAs are forwarded
  • Think of autorp listener as a autorp forwarder command as that’s essentially what the command does
  • Use BSR if you can. It’s an open protocol (unlike autorp, even though Junos DOES support autorp) and RPs and MAs are lean’t on a hop by hop basis through PIMv2

© 2009-2020 Darren O'Connor All Rights Reserved -- Copyright notice by Blog Copyright