Sparse-Dense Not Clear

[turbo_engine26]

Hello,

I am having a difficulty to fully understand the benefit of Sparse-Dense mode.

It said that if the C-RPs must be directly connected to the mapping agent and the mapping agent must be directly connected to other routers then sparse mode is good to go. In opposite concept, if the C-RPs are not directly connected to MA and MA is no directly connected to other routers then Sparse-Dense mode must be configured. This is because routers should join groups 224.0.1.39 and 40 in order to know the RP and they can't join these groups if there is no RP in the first place.

My confusion started when it said "directly connected". I think even if C-RPs are directly connected to MA and MA is directly connected to other routers, these routers should still have to join the mentioned groups and they can't do that without an RP. In other words, sparse-dense also must be configured if all mentioned are directly connected. So where is the benefit of sparse-dense mode if all mentioned are not directly connected? ....

Hope i explained it well.

Please see attached topology and part of Sparse-Dense cast study.

Notice the statement "A slight cheat was used in the examples of the preceding case study". This statement indeed means that the author intentionally provided the routers in the previous case study as directly connected to make the discussion of Sparse-Dense clear in the current case study.

Appreciate your valuable response.

HTH

AM

[Peter Paluch · Accepted solution]

Hello,

My confusion started when it said "directly connected". I think even if  C-RPs are directly connected to MA and MA is directly connected to other  routers, these routers should still have to join the mentioned groups  and they can't do that without an RP. In other words, sparse-dense also  must be configured if all mentioned are directly connected. So where is  the benefit of sparse-dense mode if all mentioned are not directly  connected? ....

You have to keep in mind that C-RPs are originating their advertisements themselves, i.e. they are sources of those multicast packets addressed to 224.0.1.39. They do not need to wait for any join, just as no ordinary multicast sources wait for any joins. They simply send the multicast packets through all multicast-enabled interfaces. Hence, without any joins, the C-RP advertisements can be sent, and of course, they will be accepted by directly-connected MAs.

For a MA, the situation is very, very similar. It is originating the mapping advertisements itself so it does not wait for any joins. If all remaining routers are directly connected to a MA, they will receive the mapping advertisements without asking for them - but surely accepting them on 224.0.1.40.

So, yes, having C-RPs directly connected to a MA, and in turn, having the MA directly connected to remaining multicast routers would allow you to run pure Sparse mode and yet have the AutoRP working, but I doubt it is an intended mode of operation.

Please feel welcome to ask further!

Best regards,

Peter

[turbo_engine26]

Hey, thanks for the reply

You have to keep in mind that C-RPs are originating their advertisements themselves, i.e. they are sources of those multicast packets addressed to 224.0.1.39. They do not need to wait for any join, just as no ordinary multicast sources wait for any joins. They simply send the multicast packets through all multicast-enabled interfaces. Hence, without any joins, the C-RP advertisements can be sent, and of course, they will be accepted by directly-connected MAs.

Of course, I understand that C-RPs and MAs do not need to join any groups as they are the sources of the messages ... I absolutely understand that ... My doubt was about the directly connected thing with other non-RPs/non-MAs routers. As i understood from you, if the routers are directly connected to MAs then they will just accept the messages without the need of those routers to join those messages' groups. Therefore, if the routers are not directly connected to MAs, then sparse-dense need to be configured in that case, RIGHT? ...

but I doubt it is an intended mode of operation.

Why you doubt it? ... Sorry i didn't get this one.

HTH

AM

[Peter Paluch · Accepted solution]

Hello

As i understood from you, if the routers are directly connected to MAs  then they will just accept the messages without those router joining  those messages' groups.

Ah, I see the point. Well, we have to clarify what means "joining" the AutoRP groups. Routers that support AutoRP do not necessarily send any PIM Join messages for these groups (after all, there is no RP to send these Joins towards to). However, internally, these routers always join the group 224.0.1.40. You can see it on any router supporting the AutoRP in the mroute table:

R1(config)#do show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode
R1(config)#int lo0
R1(config-if)#ip pim sparse-dense-mode
R1(config-if)#
*Mar  1 00:01:20.799: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 10.255.255.1 on interface Loopb
R1(config-if)#do show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 00:00:09/00:02:51, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse-Dense, 00:00:09/00:00:00

Note that before enabling the multicast routing on Lo0, there was no entry in the mroute table. Immediately after starting the multicast routing on the Lo0 interface, the 224.0.1.40 group was immediately joined automatically by the router (see the 'L' flag). A PIM Join was not sent anywhere but the group is joined.

If I configured this router as a MA then another group would be automatically joined - the 224.0.1.39:

R1(config)#do show ip mroute 224.0.1.39
Group 224.0.1.39 not found
R1(config)#ip pim send-rp-discovery lo0 scope 255 
R1(config)#do show ip mroute 224.0.1.39           
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.39), 00:00:04/00:02:55, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse-Dense, 00:00:04/00:00:00
R1(config)#

So to sum it up: routers do join these groups but they do it internally, not visibly via PIM Join messages - at least until a RP is known for these groups. In fact, I have not verified whether a PIM Join would be sent out for these groups if the RP for these groups was known in advance (via static configuration, for example). Perhaps somebody else can fill me here.

but I doubt it is an intended mode of operation.
Why you doubt it? ... Sorry i didn't get this one.

We are speaking about the apparent requirement to have all C-RPs directly connected to the MA, and all other multicast routers directly connected to the MA as well, all using SM only. The network would be limited to this particular topology which would be strongly contraining. A dynamic protocol should not impose such strong limitations. In addition, the sparse-dense mode was designed in particular to allow you to overcome this topological limitation. Alternatively, you could use the ip pim auto-rp listener command that allows flooding the AutoRP messages over interfaces in SM, and run PIM-SM only. In any case, both sparse-dense and this AutoRP listener have been designed to overcome the chicken-and-egg problem in AutoRP. Precisely because of these additional mechanisms that are available, I do not believe that having all routers physically connected to a MA and running pure PIM-SM is the intended mode of AutoRP operation.

Best regards,

Peter

[turbo_engine26]

God bless you my friend for that detailed explanation, i got the point easily.

Honestly, if exchanging emails was not against the forum's rule, i would have asked you to take your email in case if i have trouble understanding certain concept. It's very hard to find a patient person these days to clear candidates' doubts by delivering such detailed discussion. I really thank you for that.

In any case, both sparse-dense and this AutoRP listener have been designed to overcome the chicken-and-egg problem in AutoRP. Precisely because of these additional mechanisms that are available, I do not believe that having all routers physically connected to a MA and running pure PIM-SM is the intended mode of AutoRP operation.

Although the AutoRP listener mechanism wasn't mentioned in the book, i am going to stick with the sparse-dense-mode for now. Also, the book described this mode generally as the best practice of configuring PIM routers.

Thx again

HTH

AM

[Peter Paluch]

Hello my friend,

You are heartily welcome. As for my e-mail address, it is publicly visible here on CSC but I have noticed that I am faster at answering posts here on CSC than on e-mail Anyway, me and other friends and experts are around CSC constantly, so you are guaranteed to get a good response most of the time here.

Although the AutoRP listener mechanism wasn't mentioned in the book, i  am going to stick with the sparse-dense-mode for now. Also, the book  described this mode generally as the best practice of configuring PIM  routers.

I would personally disagree with the book, although it is a matter of best practice, not necessarily a principial issue. It's just that the AutoRP is by itself a proprietary mechanism, and the open and widely supported BSR (BootStrap Router) concept is a part of PIM-SM without ever needing to revert to dense-mode operation. So at the first point, I would choose BSR instead of AutoRP. In addition, if I was forced to run AutoRP, I would rather use the AutoRP Listener instead of sparse-dense-mode - it seems to me to be better controlled. It essentially allows dense-mode fallback only for AutoRP groups, instead of the entire multicast range as with sparse-dense-mode.

Best regards,

Peter