MSDP Default Peer
Last updated
Last updated
Load inter-as.multicast.msdp.default.peer.init.cfg
AS11 and AS8 have turned into dual-homed stub ASs. Each AS receives a default route from both upstreams (AS9 and AS7).
Configure MSDP on CSR9 so that XR1 is the default peer for all received SAs.
If the peering with XR1 goes down, CSR9 should accept all SAs from CSR10.
Configure MSDP on XR2 so that CSR10 is the default peer.
MSDP default peer is a feature which allows you to always accept SAs from a single peer. When the default peer feature is used, SAs from other MSDP peers are not accept. The default peer feature is implicitly activated when you only have a single MSDP peer on the router.
On IOS-XE, we can configure multiple default peers with prefix-lists. The prefix-lists match the sources for which the particular MSDP peer should be treated as the default. (I was not able to get this feature to work).
IOS-XE also allows you to define multiple default peers. The first one defined is used, which is a bit sloppy. If that peer fails, the next default peer in the list is used as the default peer.
On IOS-XR, you can simply define one single default peer. You cannot define multiple for failover, nor can you associate the default peer with a prefix-list.
Default peers are generally used when a router is not running BGP with the MSDP peers or the MSDP peers are not reachable via a BGP route. The MSDP RPF checks depend on BGP, so when BGP is not running, you might run into a scenario where all SA messages are denied. Using the default peer on one MSDP peer can allow SA messages to be accepted. Note that if your router only has one MSDP peer, then you don’t need to explicitly configure this feature, as all SAs from that MSDP peer will be unconditionally accepted. The default peer feature is implicitly activated for that one peer.
Turn on debug ip msdp peer on CSR9. When CSR3 sends traffic, the SA sourced from XR2 is reflected by both XR1 and CSR10. Because the XR1 peer was defined first, we should only accept the SA from XR1.
Strangely, it seems to show that for the SA from CSR10, it used the default peer but the RPF check failed. I’m assuming it means that CSR10 is also a default peer, but it was configured second, so it is not “actively” a default peer, therefore the RPF check fails. Or perhaps it means that it is using the default peer check in general now, so since XR1 is the default peer, the RPF check from R10 fails.
We can see that only the SA from XR1 was accepted:
If we check show ip msdp sum we see an astrik next to both peers, indicating they are both configured as default peer.
If we break the MSDP peering with XR1, CSR10 is the only peer left, and becomes the default peer. We can break the session by configuring a bad password.
When we source traffic from CSR3 again, we should see that the SA from CSR10 is now accepted, because it is taking over the defaul peer role.
We now have two SAs accepted from CSR10. (This is the SA for the previous group, 233.3.3.3, which was refreshed by XR2, and the new traffic for group 233.3.3.4).
Let’s bring XR1 back up on CSR9 and demonstrate a different feature, which is using a prefix-list on the default peer. The prefix list defines which sources to use the MSDP peer as the default peer. We’ll add another source IP on CSR3 to demonstrate this.
I also removed BGP on CSR9, replacing routing with static routes. When we source multicast traffic from 8.3.8.3, CSR9 should use XR1 as the default peer. However, CSR9 rejects both SAs. It seems this feature does not work correctly.
Default peer also doesn’t appear to work correctly on XR2 (at first glance). When CSR4 sends traffic, XR2 shows the associated SA as being from XR1, when CSR10 is the default peer.
The IOS-XR docs say this: “A default peer configuration accepts all MSDP Source-Active (SA) messages, as a last Reverse Path Forwarding (RPF) rule, when all other MSDP RPF rules fail.”
Perhaps the check from XR1 passes before using the default peer. I’ll remove BGP on XR2 to try to get all RPF rules to fail.
Now I only see CSR10’s SA in the cache:
We can use XR’s “show msdp rpf” command to tell us which RPF rule is used for 11.0.0.9.
We see that the rule number is 5, which is the last rule. This rule is used for static RPF checks for a neighbor. So now the MSDP default peer feature appears to be working correctly.
For completeness, I bring BGP back up on XR2. Now the RPF check shows rule 4, because we have a single 0/0 route learned via BGP from the same AS. To XR2, the RP is known as residing in AS7, and the best path to AS7 is also via AS7. Each MSDP peer is know as being reachable in AS7, so all RPF checks always succeed. This is why we had to break BGP to get the default peer to take effect.
On IOS-XR, the default peer configuration just adds a last resort rule as rule #5.
