MSDP RPF Rules

Routing & Switching
1

Hello, everyone.

I did not find a lesson for MSDP so I am creating a new topic if you don’t mind.

This protocol has been very simple so far until I ran into all of the RPF rules that it uses to prevent loops, that part makes my head spin.

Let’s start with Rule 1..

Rule 1: Applied when the sending MSDP peer is also an interior MBGP peer.

obrázok
obrázok1150×655 108 KB

The lines highlight the peerings. Since we have both BGP and MSDP…

R4 is the only RP here. The reason why it’s the RP is because I want it to generate SA messages, the other routers aren’t RPs, they are there just to forward and process them.

The rule seems to state this:

When the sending MSDP peer is also an internal MBGP peer, MSDP checks the BGP MRIB for the best path to the RP that originated the SA mes

If the MRIB contains a best path, the MSDP peer uses that information to RPF check the originating RP of the SA. If there is no best path in the MRIB, the unicast RIB is checked for a proper RPF path. If no path is found in either table, the RPF check fails. The IP address of the sending MSDP peer must be same as the BGP neighbor address (not the next hop) in order to pass the RPF check.

In the example above, when the source starts transmitting, R4 generates an SA and sends it to R2 and R3.

R2 and R3 will send the SA to R1. Both of these MSDP peers are internal and run iBGP.

So if I understand this right, R1 will check its BGP table (I only have the unicast RIB for simplicity), find the best path towards the originator of the SA (R4) and compare whether the sending MSDP peer’s IP matches the one in the BGP table for the best route towards R4?

So in simple terms, R1 receives the SA. It checks the unicast RIB

obrázok
obrázok848×126 5.65 KB

It realizes that the path via R2 is the best path. It then compares the IP address of the MSDP peer who sent this SA (R2 and R3) with the BGP neighbor address, which has to be 2.2.2.2 in this case.

Since the best path is via R2, it only accepts SAs from peers that have 2.2.2.2 as their IP because this matches the BGP neighbor address.

obrázok

obrázok

Is my understanding correct here?

I’ve purposely changed the MSDP peering later for R1-R2 to be over the physical interface IP instead. So on R1, the BGP peering is via 2.2.2.2 while the MSDP peering is via 192.168.21.2.

Since the MSDP peer’s IP from R2 does not match the BGP neighbor address, neither the SAs from R2 or R3 are accepted

obrázok

obrázok

Thank you for the confirmation,

David

2

Hello David

Indeed your analysis is completely correct, and you showed it excellently in a practical topology. Let me just help out by desribing the process a little more generically. First of all, the rules that you’re talking about are defined in, RFC 3618 . These are a strictly ordered, deterministic set of five rules for selecting the RPF peer N for a given SA originated by RP R. The first matching rule wins. The rule your situation is matching is rule 3, as described in the RFC:

(iii). The Peer-RPF route for R is learned through a distance-vector
or path-vector routing protocol (e.g., BGP, RIP, DVMRP) and N
is the neighbor that advertised the Peer-RPF route for R
(e.g., N is the iBGP advertiser of the route for R), or N is
the IGP next hop for R if the route for R is learned via a
link-state protocol (e.g., OSPF or IS-IS.

So when applied to your topology, the logic on R1 is:

  1. Receive an SA from an MSDP peer. Extract the RP address from the SA (R4 = 4.4.4.4).
  2. Look up 4.4.4.4 in the MRIB (unicast RIB in your case).
  3. Find the best route and identify which BGP neighbor advertised that route (i.e., the iBGP peer that sent the UPDATE containing 4.4.4.4/32).
  4. Compare that BGP neighbor’s IP address against the IP address of the MSDP peer that just sent the SA.
  5. If they match → SA is accepted. If not → SA is dropped.

Now why does it do this? Ultimately, MSDP SA forwarding must be congruent (that is, in agreement, or aligned) with the BGP topology. The BGP routing table doesn’t just provide reachability, but it defines the authoritative direction from which MSDP control-plane information about a given RP must be accepted. Make sense?

I hope this has been helpful!

Laz

3

Hello Laz!

Great response, thank you!

To nail this down, I would like to know, have you seen MSDP being used in the real world? I understand the idea behind it but what are the chances that

  1. We will actually run multicast
  2. And even if we do, would we ever run it between ASes?
  3. And even if we did, would we not just use SSM?

It feels like a lot of work, implementing MSDP and especially understanding how it works. Most of it is quite simple but the RPF rules are not, and are a bit confusing at first.

The RPF rules are also barely covered anywhere, I had to search the official RFC to even find them.

And speaking about these rules, there’s also the ip msdp rpf rfc3618command which is a compliance feature. Apparently, it relaxes some of the RPF rules. In short:

  • You can use an IGP for the RPF checks
  • You can have MSDP peerings over a transit AS
  • You can have your RRs not run MSDP

My question is, RFC 3618 was the one that defined the “strict” RPF rules, or not? I originally thought that RFC 3618 relaxed these rules, since the ip msdp rpf rfc3618 compliance command does just that.

And the final question is, what is the significance of the first point - You can use an IGP for the RPF checks?

We won’t be running an IGP between ASes. The only case scenario where this could be useful is if we are running MSDP internally for a feature like anycast RP.. but those RPs are, again, usually in a mesh group which disables RPF altogether.

This RPF part has me a little confused.

Thank you
David

4

Hello David

Let me address your RFC 3618 issue first, since that’s the foundation for understanding the rest. RFC 3618 actually defined the relaxed RPF rules, not the strict ones. The original MSDP behavior (which predates RFC 3618) had much stricter RPF requirements. RFC 3618 came along and essentially said, “Let’s make this more practical for real deployments by loosening these constraints.” So when you don’t enable the ip msdp rpf rfc3618 command, you’re running in that older, stricter mode by default on many implementations.

To be honest, no I haven’t seen MSDP deployed outside of a lab topology. The truth is that MSDP is more of a legacy/service provider/large enterprise mutlicast technology rather than a mainstream feature.

  • Will we actually run multicast? Yes, it is used extensively.
  • Would we run it between ASes? Much less likely. Exchanging multicast sources between independent ASes is quite rare, and comes with a lot of policy, filtering, security, and operational complexity.
  • Would we use SSM instead? For new designs, SSM is generally preferred, unless we specifically need Any-Source Multicast (ASM) with PIM-SM across separate multicast domains, which is what MSDP was designed for. MSDP exists because ASM is the problem.

You are correct, and this is precisely what RFC 4611 which describes MSDP deployment scenarios also documents. The IGP RPF option (Rule iii) is specifically for intra-domain deployments without BGP. RFC 4611 spells this out:

“This new capability will allow for enterprise customers, who are not running BGP and who don’t want to run mesh groups, to use their existing IGP to satisfy the MSDP peer-RPF rules.”
— RFC 4611, Section 3.2

And the existing workarounds (that make this IGP option relevant primarily in edge cases) are confirmed:

“MSDP can be deployed without BGP, however, and as a result, there are some special cases where the requirement to perform a peer-RPF check on the BGP path information is suspended. These cases are: There is only a single MSDP peer connection. A default peer (default MSDP route) is configured. The originating RP is directly connected. A mesh group is used. An implementation is used that allows for an MSDP peer-RPF check using an IGP.”
— RFC 4611, Section 2.3

I hope this has been helpful!

Laz

5

Hello Laz.

Thank you very much! That’s all I needed.

Best regards,

David

1 Like