Solved: Why we need to use auto rp listener or pim sparse-dense mode?

diya isleem · ‎07-25-2015

Hi All,

By definition, Auto rp Listener or pim sparse-dense mode used to solve chicken-egg problem the occurred in auto rp multicast network in which PIM routers need a multicast group to learn about the RPs. therefore I don't expect any PIM router except "RP and mapping agent" to learn about the RP without using any of these features?

But in a test LAB, i surprised that all my routers were able to learn the address of the RP without those features, the RP address was shown when I hit show ip pim rp mapping, it also shows the exact groups that RP mapped to!!

The only difference I noticed without using these commands is that when I join any router to a group the, the traffic will not reach the group receiver although the RP address is propagated through the network

so, What exactly does "auto rp listener" or "pim sparse-dense mode" do?

Peter Paluch · ‎07-25-2015

Steve,

You are welcome.

but are we missing an obvious point here, in that any router configured for IP multicast routing joins the multicast group 224.0.1.40.

I do not think this is relevant at this point. Joining a group is different from joining a multicast tree - when you join a group, you become a receiver yourself, whileas joining a tree means you become a member of the path through which a multicast is distributed. You have stated very correctly that every AutoRP-enabled router joins the 224.0.1.40 to learn the group-to-RP mappings - that, however, has no impact on how this learned information is propagated further.

In this environment, R2 is the RP (in fact, it is the RP-candidate and RP mapping agent) and it tells it to R1 and R3 simply because they happen to be its directly connected neighbors. They did not send any IGMP nor PIM Join for this particular group. They thus know who the RP is, but because they're running sparse-mode only, and R4 has not explicitly joined the 224.0.1.40 group (remember, no IGMP nor PIM Joins for this group), R4 does not get these mapping messages and does not learn about R2.

Does this make sense?

Best regards,
Peter

View solution in original post

Peter Paluch · ‎07-25-2015

Hi,

Would you mind posting a diagram of your network topology along with the configurations of the respective devices? It would help us narrow down the possible causes.

In general, sparse-dense-mode causes multicast for any group whose RP is unknown to be flooded using dense mode rules. For groups whose RP is known, multicast will be delivered using sparse mode rules.

The ip pim autorp-listener allows the specific AutoRP traffic (destined to 224.0.1.39 and 224.0.1.40) to be flooded using dense mode rules across interfaces configured for strict sparse mode. This command has no meaning if using sparse-dense-mode - with this mode, the AutoRP traffic can always be flooded using dense mode rules.

Best regards,
Peter

diya isleem · ‎07-25-2015

Thank you Peter,

you can try with any topology,

first, I thought this only happens for RP's directly connected routers, but it proves me wrong, it happens in all routers,

I also tried using ios 12 and 15,

here also one thing that might help, check the differences in the mroute table before and after ip pim autorp listener

before:

(*, 224.0.1.39), 00:13:36/stopped, RP 0.0.0.0, flags: DP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(2.2.2.2, 224.0.1.39), 00:01:01/00:01:58, flags: PT
Incoming interface: FastEthernet0/0, RPF nbr 172.16.12.2
Outgoing interface list: Null

(*, 224.0.1.40), 00:15:22/stopped, RP 0.0.0.0, flags: DPL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(2.2.2.2, 224.0.1.40), 00:12:37/00:02:59, flags: PLT
Incoming interface: FastEthernet0/0, RPF nbr 172.16.12.2
Outgoing interface list: Null

after:

(*, 224.0.1.39), 00:02:56/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:02:56/00:00:00

(2.2.2.2, 224.0.1.39), 00:02:56/00:00:03, flags: PT
Incoming interface: FastEthernet0/0, RPF nbr 172.16.12.2
Outgoing interface list: Null

(*, 224.0.1.40), 00:03:09/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:03:09/00:00:00

(2.2.2.2, 224.0.1.40), 00:03:01/00:02:58, flags: PLT
Incoming interface: FastEthernet0/0, RPF nbr 172.16.12.2
Outgoing interface list: Null

Peter Paluch · ‎07-25-2015

Hello,

These outputs do not prove that the information about the RP has been properly advertised across the network - quite the contrary. Note that in each of the (*,G) entries in your multicast routing table outputs, the heading says "RP 0.0.0.0", saying that the RP is in fact unknown.

Is there any other output that makes you believe that your routers know who the RP is?

Best regards,
Peter

diya isleem · ‎07-25-2015

Yup, check the following outputs, I'll re-check mroute tables

R1#show ip pim rp mapp
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 2.2.2.2 (?), v2v1
Info source: 2.2.2.2 (?), elected via Auto-RP
Uptime: 00:05:24, expires: 00:02:31

R3# show ip pim rp mapp
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 2.2.2.2 (?), v2v1
Info source: 2.2.2.2 (?), elected via Auto-RP
Uptime: 00:08:54, expires: 00:02:07

Peter Paluch · ‎07-25-2015

Hi,

I wouldn't be too concerned about routers directly connected to R2. In this case, R2 is a source of a multicast traffic, and it simply floods it over all its interfaces. The setting of sparse or dense mode has no relation to this process as it affects only multicast routing, not the origination of multicast itself.

How about R4?

Best regards,
Peter

diya isleem · ‎07-25-2015

R4, doesn't show for now, this actually surprised me and opsite of the previous lab, I'll recheck it, note that it is the receiver,

Check here R5:

Steve Fuller · ‎07-25-2015

Hi,

Forgive me for chiming in, but are we missing an obvious point here, in that any router configured for IP multicast routing joins the multicast group 224.0.1.40.

If we also have ip pim autorp-listener configured then the Mapping Agent advertisement of the selected RP to the 224.0.1.40 group is going to be received by all routers.

Isn't this how the routers in this envornment know who the RP is?

Regards

Peter Paluch · ‎07-25-2015

Steve,

You are welcome.

but are we missing an obvious point here, in that any router configured for IP multicast routing joins the multicast group 224.0.1.40.

I do not think this is relevant at this point. Joining a group is different from joining a multicast tree - when you join a group, you become a receiver yourself, whileas joining a tree means you become a member of the path through which a multicast is distributed. You have stated very correctly that every AutoRP-enabled router joins the 224.0.1.40 to learn the group-to-RP mappings - that, however, has no impact on how this learned information is propagated further.

In this environment, R2 is the RP (in fact, it is the RP-candidate and RP mapping agent) and it tells it to R1 and R3 simply because they happen to be its directly connected neighbors. They did not send any IGMP nor PIM Join for this particular group. They thus know who the RP is, but because they're running sparse-mode only, and R4 has not explicitly joined the 224.0.1.40 group (remember, no IGMP nor PIM Joins for this group), R4 does not get these mapping messages and does not learn about R2.

Does this make sense?

Best regards,
Peter

Steve Fuller · ‎07-25-2015

As I understand it the simple act of configuring the ip multicast-routing command means that a router joins the 224.0.1.40 group.

This means it will both receive traffic destined to the group, but will also form part of the tree for that group.

If ip pim autorp-listener is configured then we see the Fa0/0 in the OIL, and so traffic to the group will be forwarded on that interface. The device downstream of Fa0/0 will then receive traffic for that group.

From the OP

therefore I don't expect any PIM router except "RP and mapping agent" to learn about the RP without using any of these features?

This was my point. Any router configured with ip multicast-routing will receive the MA advertisement as it has joined the group, assuming ip pim autorp-listener of course.

Regards

Peter Paluch · ‎07-25-2015

Hi Steve,

As I understand it the simple act of configuring the ip multicast-routing command means that a router joins the 224.0.1.40 group.

That is a part of what happens but it it not all. First and foremost, it allows multicast to be forwarded in the first place. Without ip multicast-routing, the show ip mroute says this in the header:

Router# show ip mroute
IP Multicast Forwarding is not enabled.
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
[ ... cut ... ]

Older IOSes did not produce this line in the show ip mroute output - instead, they warned you as soon as you configured an interface with PIM but forgot to activate the multicast routing itself:

R1(config-if)# ip pim sparse-mode
 WARNING: "ip multicast-routing" is not configured,
        IP Multicast packets will not be forwarded
R1(config-if)#

The fact that a router joins the AutoRP RP-discovery group 224.0.1.40 is just a byproduct of starting the multicast routing as for quite some time, Cisco IOSes did not allow the AutoRP to be deactivated. However, recent IOSes support the no ip pim autorp global command that deactivates AutoRP altogether, so the ip multicast-routing becomes truly only about multicast forwarding.

Furthermore, a router does not join the AutoRP groups 224.0.1.39 and .40 explicitly - meaning it does not send IGMP Joins or PIM Joins. It only accepts and processes these messages once they have arrived, but it does not explicitly signal its neighbors it wants to receive them. It therefore relies on the dense-mode flooding of AutoRP traffic, and with ip pim sparse-mode without ip pim autorp listener, this does not occur. That is why R4 does not learn about the RP.

Best regards,
Peter

Steve Fuller · ‎07-26-2015

Thanks Peter. Yet another excellent posting and explanation.

Regards

diya isleem · ‎07-25-2015

Hi Peter,

After checking it seems you are right, only routers connected to the RP knows about it "R1&R3", and if they joined to to any multicast group, they even will receive traffic destined to that group.

Thank you for you support

diya isleem · ‎07-25-2015

Here are configs,

R1:

ip multicast-routing

interface Loopback1
ip address 1.1.1.1 255.255.255.255
ip ospf 1 area 0
!

interface GigabitEthernet0/0
ip address 172.16.12.1 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
duplex full

R2

ip multicast-routing

interface Loopback2
ip address 2.2.2.2 255.255.255.255
ip pim sparse-mode
ip ospf 1 area 0
!

interface GigabitEthernet0/0
ip address 172.16.12.2 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
duplex full
speed 1000
media-type gbic
negotiation auto
!
interface GigabitEthernet1/0
ip address 172.16.23.2 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
negotiation auto

ip pim send-rp-announce Loopback2 scope 100
ip pim send-rp-discovery Loopback2 scope 100

R3

ip multicast-routing
interface GigabitEthernet0/0
ip address 172.16.23.3 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
duplex full
speed 1000
media-type gbic
negotiation auto
!
interface GigabitEthernet1/0
ip address 172.16.34.3 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
negotiation auto

R4

ip multicast-routing
interface Loopback4
ip address 4.4.4.4 255.255.255.255
ip pim sparse-mode
ip igmp join-group 224.4.4.4
ip ospf 1 area 0

interface GigabitEthernet0/0
ip address 172.16.34.4 255.255.255.0
ip pim sparse-mode
ip igmp join-group 224.43.43.43
ip ospf 1 area 0
duplex full
speed 1000
media-type gbic
negotiation auto