MSDP RPF Check (IOS-XE)
Load msdp.rpf.tshoot.init.cfg
#IOS-XE (R1-R10 only)
config replace flash:msdp.rpf.tshoot.init.cfg
Anycast RP is pre-configured in the core.
Anycast RP = 150.1.255.255/32
Anycast RPs = R4, R7, R8
The three RPs are already in a full MSDP peering mesh.
Currently R9 cannot ping 239.1.1.1, which R10 is subscribed to. Explain the issue and fix it with a single command on R8.
Answer
#R8
ip msdp rpf rfc3618Explanation
First we must understand the default Cisco MSDP RPF rules on IOS-XE.
The RPF check is skipped if:
Sending MSDP peer is the originating RP
Sending MSDP peer is in a mesh group
Sending MSDP peer is the default-peer
None of these checks pass. R8 is peering with R7 over Lo0, but R7’s origiantor ID is Lo2, so the sending peer is not the originating RP.
Next, the following three rules are used:
The sending MSDP peer is an iBGP peer, and the peer advertised the route to the originating RP
The sending MSDP peer is an eBGP peer, which is in the closest AS on the best path to the originating RP
The sending MSDP peer is not a BGP peer, but the route to the MSDP peer is in the closest AS for the route to the originating RP
Rule 1 is not satisfied because the route to the originating RP (160.1.7.7) is via iBGP, but the MSDP peer (150.1.7.7) is not an iBGP peer. The route to 160.1.7.7 is known via the RR (R1).
Rule 2 is not satisfied because we are not running eBGP.
Rule 3 is also not satisfied because the route to the originating RP is via iBGP (160.1.7.7) with AS path “”, but the route to the MSDP peer (150.1.7.7) is via IGP.
The result is that the SA messages are denied due to the RPF check on R8:
Solution 1 - RFC3618
The given solution is to use the command ip msdp rpf rfc3618. This enables RFC3618 rules instead of the old Cisco rules. It should be noted that RFC3618 is the default and only setting on IOS-XR.
As a refresher, these are the RFC3618 RPF rules:
MSDP peer = Originating RP
MSDP peer = BGP nexthop to the originating RP
MSDP peer = BGP peer which advertised the route towards the originating RP
MSDP peer resides in the closet AS towards the originating RP
MSDP peer RPF was statically configured (as with default-peer)
RFC3618 rule 2 now satifies the RPF check. (The MSDP peer is the BGP nexthop for the route to the originating RP).
The BGP route for 160.1.7.7 is via 150.1.7.7, which is itself the MSDP peer. The route to the originating RP is via the MSDP peer as the nexthop. The old Cisco rules required the advertising router (R1, the RR) to be the MSDP peer. (Rule 1).
Now R8 will accept the SA message from R7 and the traffic works:
Solution 2 - Mesh Group
Another solution is to put R7, R4, and R8 in a mesh group. This is the more reasonable solution. An SA received from a mesh group peer has the RPF check disabled.
#R7
ip msdp mesh-group GROUP1 150.1.4.4
ip msdp mesh-group GROUP1 150.1.8.8
#R4
ip msdp mesh-group GROUP1 150.1.7.7
ip msdp mesh-group GROUP1 150.1.8.8
#R8
ip msdp mesh-group GROUP1 150.1.4.4
ip msdp mesh-group GROUP1 150.1.7.7Technically, to satisfy the lab requirements, you could simply configure R8 with a single mesh-group statement that puts R7 in the mesh group. This is a single command that solves the problem, which is technically a valid solution.
Solution 3 - MSDP peer with RR
The original intent of the Cisco MSDP RPF check rules was that the MSDP peering would follow the BGP peering. If we peer the RPs with only the RR instead of with each other, the RPF check passes.
#R7
no ip msdp peer 150.1.4.4 connect-source Loopback0
no ip msdp peer 150.1.8.8 connect-source Loopback0
ip msdp peer 150.1.1.1 connect-source Loopback0
#R4
no ip msdp peer 150.1.7.7 connect-source Loopback0
no ip msdp peer 150.1.8.8 connect-source Loopback0
ip msdp peer 150.1.1.1 connect-source Loopback0
#R8
no ip msdp peer 150.1.4.4 connect-source Loopback0
no ip msdp peer 150.1.7.7 connect-source Loopback0
ip msdp peer 150.1.1.1 connect-source Loopback0
#R1
ip msdp peer 150.1.4.4 connect-source Loopback0
ip msdp peer 150.1.7.7 connect-source Loopback0
ip msdp peer 150.1.8.8 connect-source Loopback0The SA from R7 is reflected by R1 to R8, and traffic works:
Above, R1 is R8’s default peer. We can prove the RPF check is actually working because the MSDP topology follows the iBGP topology, by forming a second peering between R7 and R8 again. Now R8 no longer has a default peer.
#R7
ip msdp peer 150.1.8.8 connect-source Loopback0
#R8
ip msdp peer 150.1.7.7 connect-source Loopback0
Above, the RPF check for the SA from R1 succeeds, because the MSDP peer is an iBGP peer, and the route to the originating RP is via the iBGP peer. The RPF check for the SA from R7 still fails as usual.
What about using the IGP?
What happens if the route to the originating RP is via the IGP and not BGP? I’ve reverted back to the initial config, advertised the Lo2 into OSPF on R7, and deleted BGP on R8.
#R7
router ospf 1
network 160.1.7.7 0.0.0.0 area 0
#R8
no router bgp 100The RPF check still fails:
The RPF check is dependent on a BGP route towards the originating RP.
Let’s update to the new RPF rules:
#R8
ip msdp rpf rfc3618Still the RPF check fails:
However, an old interdomain multicast video says the OSPF RID can be used for the RPF check. Let’s change R7’s RID to 150.1.7.7. Now the OSPF route for 160.1.7.7 should be known from OSPF RID 150.1.7.7 which matches the MSDP peering address.
#R7
router ospf 1
router-id 150.1.7.7
If we turn on ip msdp rpf rfc3618, the RPF check now passes:
This IGP rule appears to not be documented very well. Perhaps it is an alternative to rule 2 - instead of the route to the originator being via the MSDP peer which is also the BGP originator of the route, now the MSDP peer is the IGP originator of the route.
Both the old and new MSDP RPF rules are still heavily reliant on the originating RP having a BGP route. However, remember that if the MSDP peer is the originating RP itself, then the check will pass unconditionally.
Last updated