Multicast PIM Auto RP

Hi rene, I am looking at aprod config and have a doubt

on one of Access Layer switch I see :-

  1. under some VLANs “ip pim passive” and “ip cgmp” —> what do you make out of this config ?

  2. under some interfaces : “ip pim sparse-dense mode” and under global “ip pim autorp listener”

why someone would configure both “ip pim sparse-dense mode” and “ip pim autorp listener” ?

Thanks in adv

Hi rene, I am looking at a prod config and have a doubt

on one of Access Layer switch I see :-

  1. under some VLANs “ip pim passive” and “ip cgmp” —> what do you make out of this config ?

  2. under some interfaces : “ip pim sparse-dense mode” and under global “ip pim autorp listener”

why someone would configure both “ip pim sparse-dense mode” and “ip pim autorp listener” ?

Thanks in adv

@Hans redundancy is no problem but you should configure multiple RPs AND multiple mapping agents. Otherwise a single mapping agent is your single point of failure.

@Abhishek CGMP is pretty old so it’s possible that this command is not even needed in your network. It’s used for within your L2 domain:

https://networklessons.com/cisco/ccie-routing-switching/cisco-group-management-protocol-cgmp/

The ip pim passive command means that the switch/router won’t send any PIM messages on its interface, it will also not accept any PIM messages from other devices. It forces your switch/router to become the DR. If you need PIM and you are the only PIM-enabled device, you can use this. Otherwise you should disable it.

Adding ip pim autorp listener only makes sense if you use sparse mode, not dense or sparse-dense mode.

Awesome Thanks Rene !

How come R3/R4 are mapping agents chosen in ethernet segment? What makes them mapping agent? Without PIM being configured or statically configured ??

Hello Parajuli

Although Rene doesn’t go into details in the lesson, a router is configured as a mapping agent using the following command:

ip pim send-rp-discovery

You can find out more about this command at this Cisco Command Reference Documentation (search for ip pim send-rp-discovery.

It is possible to configure two or more mapping agents within a network. Each will function independently. Engineers often misunderstand how multiple mapping agents interact and often believe that there is more complexity to such a configuration than there really is. Receiving mapping data from two or more mapping agents is not a problem because both transmit identical mapping information, so there are never any conflicts.

Conversely, the command ip pim send-rp-announce configures a router as an RP.

I hope this has been helpful!

Laz

1 Like

If R3 has to be statically configured as MP beforehand, may be R4 can be done as well!
Regardless, in this topo, why is R4 not announcing itself as RP then?
Or this is for brevity; only for clarifying the technology?

Hello Deep

Routers will only play the role of a RP or an MA if they are statically configured as such. Specifically, to configure a router as a candidate RP and thus to have it announce itself as such, the following command must be present:

ip pim send-rp-announce

To configure a router as an MA the following command must be present:

ip pim send-rp-discovery

The above are configured on R1 and R2 respectively. R4 is not configured to announce itself as an RP so it will not do so. R4 does however recieve the information from the mapping agent because of the following command that is found on R3

ip pim autorp listener

This command allows the multicast traffic that reaches R3 to be flooded with dense mode, thus it will flood those packets to R4.

I hope this has been helpful!

Laz

Between Auto-RP and BSR, which one provides better fault tolerance? Both can have backup RP IPs.

Hello Chris

It really depends on what you want. A good explanation is given in this Cisco Community post:

The link to the white paper in the post is out of date. The following is the whitepaper related to this issue:

I hope this has been helpful!

Laz

It seems Cisco officially recommend to use sparse-dense mode rather than auto-rp listener, and dummy rp’s for the groups which don’t exist.

Which frankly makes little sense to me, as listener requires way less config!

1 Like

Hi All,

when I run a show ip pim rp to find out where the RP is on a network i get the following response:

(*, 239.0.78.141), 1w3s/00:02:54, RP 0.0.0.0

This entry is repeated for all multicast groups that transit the L3 switch. My question is, what does the 0.0.0.0 output mean? Is it saying this L3 device is the RP?

thanks

Mike

Hello Michael

A response of (*, 239.0.78.141), 1w3s/00:02:54, RP 0.0.0.0 tells us that an RP has not been defined. Either enable auto RP or manually define the RP in order to have that information added.

I hope this has been helpful!

Laz

Thanks Laz that makes sense, many thanks.

1 Like

A post was merged into an existing topic: VRF Lite Configuration on Cisco IOS

Dear Rene,

In the configuration example, R3 is getting the rp mappings before we configure the ip pim autorp listener command. That means R3 know the RP address. So R3 should be able to serve if R4 wants to join a feed which is coming from R1 (as RP). But it is not until we configure ip pim autorp listener command on R3. Why is that?

Hello Roshan

If R4 is a host that wants to participate in a multicast group, then yes you are right, it can receive all the necessary information for such a case. However, we don’t want R4 to function as a multicast participant, but as a multicast router that will allow hosts on networks connected to it to participate in multicast. In this case, R4 will not “know” anything because it is behind R3 and is not receiving any RP mapping packets. This is because we are using PIM sparse mode which means that it would only be forwarded when requested by a downstream router.

The solution is to use the ip pim autorp listener which ensures that traffic sent to 224.0.1.39 gets flooded with dense mode. Once enabled, packets will be flooded to R4.

I hope this has been helpful!

Laz

Thank you Laz,
I think I have come across a bug or something. Or may be I had to clear the mroute chache at that time. It worked after some how anyway. Tx

1 Like

Hi Rene and team,
I tried to replicate a similar lab to the one in this lesson, but I’m getting some unexpected results.

Here’s the topology:

All RTR# devices have their interfaces configured with ip pim sparse-mode, and all RTR# devices have ip multicast-routing enabled. Also, OSPF is enabled on all RTR# interfaces in area 0. RTR# devices are OSPF neighbors on their directly connected interfaces.

RTR3’s loopback0 interface (3.3.3.3) is configured to be the RP: RTR3 is also the configured mapping agent and an RP candidate:

interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip pim sparse-mode
!

ip pim rp-address 3.3.3.3
ip pim send-rp-announce Loopback0 scope 16
ip pim send-rp-discovery Loopback0 scope 16

I did a show ip pim rp mapping on RTR1 and expected to see it empty (because all interfaces are configured to be in sparse mode). RTR2 is getting the RP discovery messages sent to 224.0.1.40 from RTR3 since it’s directly connected to RTR3, but RTR1 is some how still learning the RP to be 3.3.3.3 from R2. I did a debug ip pim auto-rp on RTR1 to confirm this.

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

Group(s) 224.0.0.0/4
RP 3.3.3.3 (?), v2v1
Info source: 3.3.3.3 (?), elected via Auto-RP
Uptime: 00:17:49, expires: 00:01:58
RTR1#

 

RTR1#
*Feb 14 16:03:41.565: Auto-RP(0): Received RP-discovery packet of length 48, from 3.3.3.3, RP_cnt 1, ht 181
*Feb 14 16:03:41.565: (0): pim_add_prm:: 224.0.0.0/240.0.0.0, rp=3.3.3.3, repl = 1, ver =3, is_neg =0, bidir = 0, crp = 0
*Feb 14 16:03:41.565: Auto-RP(0): Update
*Feb 14 16:03:41.565: prm_rp->bidir_mode = 0 vs bidir = 0 (224.0.0.0/4, RP:3.3.3.3), PIMv2 v1
RTR1#

RTR2’s show ip mroute shows that it is sending the auto-RP discovery messages over an SPT tree to RTR1 via its Ethernet0/1 interface. I’m not sure why that is, though.

RTR2#show ip mroute

<output omitted>

(3.3.3.3, 224.0.1.40), 00:21:35/00:02:12, flags: LT
Incoming interface: Ethernet0/2, RPF nbr 192.168.2.2
Outgoing interface list:
**Ethernet0/1**, Forward/Sparse, 00:21:35/00:02:31

Meanwhile at the other end of the topology, RTR4 does not appear to be forwarding the RP-discovery messages it receives on Et0/3 over to RTR5 on its Et0/0 interface:

RTR4#show ip mroute

<output omitted>

(3.3.3.3, 224.0.1.40), 00:49:08/00:02:25, flags: PLT
Incoming interface: Ethernet0/3, RPF nbr 192.168.3.1
**Outgoing interface list: Null**

RTR5 doesn’t seem to know about the RP:

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

RTR5#

Hello Sam

This is an interesting question that you bring up, and it is not readily clear as to why you see this behaviour. After spending some time with Rene labbing this up, the reason for this behaviour has been made clear, and we have all learned something in the process!

It is true that if you have R3 become the mapping agent as in your topology, it will send out its RP mapping advertisements to the 224.0.1.40 address, which means these advertisements should only reach R2 and R4 since we’re using sparse mode. However, you will find that if R2 is the DR for the link between R2 and R1, then it too will forward the mapping advertisement to R1. R2 will operate in dense mode for the 224.0.1.40 group. If it is not a DR for that link, then it will not forward it.

You can see this clearly in the following Cisco documentation:


Specifically it states:

All the PIM routers join the multicast group 224.0.1.40 when the first PIM-enabled interface comes up. This interface is seen in the outgoing interface list for this group if it is the Designated Router (DR) on that PIM Segment.

For your specific topology, R2 is indeed the DR for the R1-R2 segment since I assume it has the higher IP address, so it will forward the mapping messages. Conversely, R5 is probably the DR for the R4-R5 segment since R5 probably has the higher IP address, so R4 will not forward the advertisement. Try to change the DR priorities on the R4-R5 segment and see if that will cause the behaviour to change.

In any case, it’s not a good idea to simply depend on this behaviour of the forwarding of mapping advertisements by the DR. This is why two solutions have been provided to allow the RP to be learned by all multicast routers in the topology: PIM Sparse-Dense mode and PIM Auto-RP listener.

I hope this has been helpful!

Laz