Multicast Anycast RP Configuration on Cisco IOS

Lessons Discussion
63

Hello Sir,
Does msdp interface must use loopback interface? can I use 192.168.23.0/24 interface to msdp source interface?

64

Hello Eric

You can use the IP address of a physical interface to act as the MSDP source interface if you like. The feature will work correctly if you do so. However, while it’s not strictly required to use a loopback interface for MSDP, it’s highly recommended. The reason is that loopback interfaces are virtual and always up, unlike physical interfaces that can go down due to various reasons such as link failures, hardware issues, etc. Using a loopback interface for MSDP increases reliability.

So it is best practice to use a loopback interface, however, it will still work if you use physical interface.

I hope this has been helpful!

Laz

65

Hello,
How does MSDP works to build (S,G) all the way between the Anycast RPs?If we dont use MSDP,how is this achieved?
Thanks

66

Hello Kai

Take a look at this NetworkLessons note on how MSDP operates when used with Anycast RPs.

Similarly, you can take a look at this note that describes how Auto-RP and BSR can also be used as an alternative.

I hope this has been helpful!

Laz

67

@ReneMolenaar, great work.

If we expand this topology a little bit, and we have a site (Site B for example) that is connected through an ISP. Would I be able to do the same and build an MSDP mesh where Site A has Anycast RP of 1.1.1.1 and Site B has Anycast RP of 2.2.2.2?

68

Hi all,
I’m facing a concept idea about MSDP.

Let’s say i have 2 PIN domains with two RPs inside them

immagine
immagine1557×628 31.5 KB

Is in this case the best practice to full-mesh the msdp peering between all of them ?

In other words:

  • RP1 has as MSDP peer RP2,RP3 and RP4
  • RP2 has as MSDP peer RP1,RP3 and RP4
  • RP3 has as MSDP peer RP1,RP2 and RP4
  • RP4 has as MSDP peer RP1,RP2 and RP3

or is it better to keep let’s say “single homed” connections ?

In other words:

  • RP1 has as MSDP peer RP2 and RP3
  • RP2 has as MSDP peer RP1 and RP4
  • RP3 has as MSDP peer RP1 and RP4
  • RP4 has as MSDP peer RP1 and RP3

What is the downside using the the first one or the second scenario ?

Thanks in advance.

Wish you a great day.

Aronne

69

Hello Ahmed

Yes, the setup you describe is definitely doable, and it is a logical way to configure multicast, Anycast RP and MSDP in a multi-site environment. This of course depends upon the requirements of your topology.

Since Anycast RP allows the use of the same RP address by multiple in different locations, each serving a different group of multicast receivers, the RP closest to the multicast source can is used. In your case, Site A and Site B can have their own Anycast RP addresses (1.1.1.1 and 2.2.2.2 respectively). You just need to ensure that the ISP supports multicast routing and allows multicast traffic.

You would also need to configure MSDP between the Anycast RPs to share the active source information. This way, if a multicast source becomes active in Site A, the Anycast RP in Site B would learn about it through MSDP, and vice versa.

I hope this has been helpful!

Laz

70

Hello Aronne

In the arrangement that you are describing, you have intra-domain MSDP peerings and inter-domain MSDP peerings.

The intra-domain peerings are those between RPs in the same domain. Since you have only two RPs in each domain, you simply have one peering between them. This MSDP peering of course is mandatory in order for Anycast RP to function correctly.

Inter-domain MSDP peerings are those between RPs in different PIM domains. Now the question here is, for the topology you shared, should there be a full mesh peering or a partial mesh peering? What are the benefits of each choice?

Between different PIM domains, technically, only one MSDP peering per domain is necessary. This is because RP1 and RP2 already share the same SA database within Domain 1 through their internal peering, and RP3 and RP4 do the same within Domain 2. Adding the “R1 → R4” and “R2 → R3” peerings does not provide additional value but unnecessarily increases control-plane overhead.

The best practice is to use a partial-mesh peering between PIM domains. With the partial mesh that you describe, even if one of the routers fails, you still have a second inter-domain peering that maintains the synchronization between domains.

Using a partial mesh between domains strikes a balance between redundancy, scalability, and simplicity. It ensures that multicast sources and receivers are fully visible across domains without unnecessary overhead. Does that make sense?

I hope this has been helpful!

Laz

71

Hi Laz,
many thanks for your feedback, all clear and helpful so far.

Since peering for anycast in the same domain is already active, you suggest to create “only” interdomain MSDP peering between R1 and R3. Also peering between R2 and R4 is needed to maintain redundancy in case of failure of R1 or R3, isn’t it ?

Thanks a lot for your support and tips.

Wish you a great day!

Aronne

72

Hello Aronne

Ah, I see the confusion. My suggestion was that this:

does not provide additional value compared to this:

In the second scenario, you do have multiple inter-domain peerings for redundancy, but you don’t need those extra “R1 → R4” and “R2 → R3” peerings for the reasons I explained in the previous post. I’ve rewritten my post to make that clearer.

I hope this has been helpful!

Laz

73

Hi Laz,
Many thanks for the explanation.
I got It now.

Wish you a great day.
Aronne

1 Like
74

Hi,

The first output from the lesson shows Fa0/1 in the OIL (see below) , but shouldn’t it be Fa0/0 because that’s where the IGMP join is?

Of course R3 will be the closest RP for R4 so you’ll find a (*,G) entry for 239.1.1.1:

R3#show ip mroute 239.1.1.1
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

(*, 239.1.1.1), 00:06:35/00:02:08, RP 23.23.23.23, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/1, Forward/Sparse, 00:06:35/00:02:08

Also, just to let you know, I copied the configs from the lesson and they resulted in an OSPF duplicate ID (because the highest loopback IPs are the same,) so I had to use the router-id OSPF command.

Another issue I ran into was that R4 would not respond to multicast pings (from R1) unless I enabled multicast-routing on it (missing from the config). But I didn’t have to add ip pim sparse-mode to its Gi0/0 interface to make it work (which is in the configs).

Thanks,

Sam

75

Hello Sam

Yes, you are correct, that should indeed be Fa0/0 based on the diagram. I will let Rene know.

You’re right, the OSPF router ID would be the same and there would be a conflict for OSPF.

Yes, that is indeed true. Multicast routing must be enabled on a router if you want a router to act as a multicast receiver. However, it doesn’t need to participate in PIM, and indeed it shouldn’t if it is acting as a client.

Thanks for pointing these out, it shows you are gaining a deeper understanding of multicast and how it works!

I hope this has been helpful!

Laz

1 Like
76

Hi Laz,

it’s me again with the same scenario from the 8th Jan.

Just a little question about it again.

Is it possible to face a Multicast loop or MSDPs SA loop using this kind of topology ?
We’re running static routing between these 2 PIM Domains.

Thank you for a feedback

Best Regards

Aronne

77

Hello Aronne

Nice to hear from you again! The short answer is no, if everything is configured correctly, there is no danger of getting a multicast loop or an MSDP SA loop. Let me explain in a bit more detail.

MSDP has a built-in loop prevention mechanism: Every MSDP Source Active (SA) message is accepted only from the RPF peer toward the originating RP address. Copies of the same SA received from any other peer are dropped, so an SA can’t circle the network forever. Secondly, PIM itself is RPF-based. RPF, or reverse path forwarding, is a mechanism that is used by multicast to prevent multicast loops where non-RPF interfaces don’t forward traffic. So multicast data can’t loop either.

Actually, in such a topology where you’re using PIM and MSDP, it’s very hard to create a multicast forwarding loop because of these loop prevention mechanisms that are active in multicast PIM and MSDP. The worst thing you can do is create conditions that are less efficient, such as:

  • If you misconfigure static routes, and the route for the RP points in the “wrong direction,” you may have two peers that think the other is the RPF neighbor. This causes SA bouncing or flapping. This is not a loop, but it is inefficient.
  • If you have ECMP towards the RP, you may get SA flapping between peers, making the network look unstable.
  • If you have multiple active RPs for the same group without proper anycast, different domains think different RPs are authoritative for the same group. This results in duplication of traffic.

Although these conditions do not result in loops, they can result in duplicate packets and duplicate SAs resulting in route flapping, if the routing to the RPs and sources is inconsistent.

I hope this has been helpful!

Laz

78

Hi Laz,

Awesome explanation. Thank you very much. Always clear.

Wish you a great day.

Best regards

Aronne

1 Like
79

Hi all,

In the scenario described by Rene the originator-id is the unique loopback address on both routers. What happens if both RP Routers uses the Anycast Loopback address (in this case the 23.23.23.23) ? In some documents is described that the originator-id should be that one used for anycast. What do you think about ?

80

Hello Aronne

That’s an excellent question. Let me get right into it.

The originator-ID is a value that is used by MSDP for loop prevention. By definition, it must be unique. If anycast is being used, and the IP addresses of the loopbacks of the RPs are the same, they cannot and should not be used as the originator-IDs. Otherwise, MSDP will break.

Rene had to manually configure the originator-IDs so that the use of 23.23.23.23 on both routers would be avoided.

If that is indeed found in documentation, it would be incorrect, since that would cause MSDP to fail. I’d be interested to see this documentation. Can you share it?

I hope this has been helpful!

Laz

81

Hi Laz

thank you very much for your explanation. I’ve chatted with AI “Gemini” about this question and i’ve read it there. I can paste you a small extract of the chat.

---

## The Core Problem: MSDP RP-RPF Check Failure

The primary issue is not what the $\text{mroute}$ shows, but what happens when the MSDP-speaking RPs (A1, A2, A3) receive the SA message containing the incorrect originator ID:

  1. SA Received: The Site A RP (e.g., A1) receives an SA message from Site B: $(\text{Source } S, \text{ Group } G, \text{ RP Address } 123.1.1.1)$.

  2. RP Policy Check: The RP (A1) checks its local configuration. It sees the receiver interest is for $\text{RP } 100.100.100.100$.

  3. The Failure Point: Since the RP address in the SA message ($\mathbf{123.1.1.1}$) does not match the expected Anycast RP IP ($\mathbf{100.100.100.100}$) and $\mathbf{123.1.1.1}$ is likely not known as a valid RP for the domain, the MSDP speaker will likely drop the SA message because it fails the consistency checks necessary for Anycast RP.

  4. No $\text{(*, G)}$ to $\text{(S, G)}$ Conversion: Because the SA is dropped or ignored, the Site A RP never learns about the remote source $S$ via MSDP. Consequently, the RP cannot send the necessary PIM $\text{(S, G)}$ Join toward the source, and the receivers in Site A will never receive the multicast traffic from the external source $S$.

In short, the $\text{mroute}$ shows the static configuration is fine ($\text{RP 100.100.100.100}$), but the MSDP Source Discovery mechanism (which relies on the RP address in the SA matching the expected Anycast RP IP) breaks, leading to a functional failure where remote sources are not discovered.

---

Anyway, i prefer your explanation instead of that one of a Computer :wink: .

82

Just another question if it’s possible. I have Site A with 3 Routers running Anycast RP using MSDP peering and the same on Site B. Site A and Site B have 2 different pim domain. i would like to create a MSDP peering between Site A and site B between A1<>B1. Do you suggest to have one MSDP mesh group for the “internal Anycast” peering and another one between A1 and B1 or do you suggest to insert the Peer B1 into the “internal mesh group” of Site A and do the same on site B? Hope that my question is clear.

Thanks in advance for a feedback.

Wish you a great evening.

Aronne