Information Technology Reference
In-Depth Information
Example 11-17
MSDP Debug for the Failed SA RPF Check
*Mar 3 10:22:44.847: MSDP(0): 10.1.0.3: Received 20-byte msg 15 from peer
*Mar 3 10:22:44.847: MSDP(0): 10.1.0.3: SA TLV, len: 20, ec: 1, RP: 10.1.0.1
*Mar 3 10:22:44.847: MSDP(0): 10.1.0.3: Peer RPF check failed for 10.1.0.1,
EMBGP route/peer in AS 5/0
Mesh Groups
In complex deployments, especially when RP Anycast is used, there might be a significant
number of MSDP peering sessions in a single domain. The use of Anycast RP is covered in
the case study. MSDP mesh groups optimize SA flooding within a domain. Figure 11-25
shows MSDP mesh groups in action. Configuration examples are provided in the case
study.
Figure 11-25
MSDP SA Flooding with Mesh Groups
R1
BGP Session
R2
MSDP Session
R4
SA Advertisment
R3
R5
The concept of mesh groups is built on the assumption that all peers in the mesh group are
fully meshed. This means that when a router receives an SA from a mesh group peer, it can
assume that the sending MSDP peer also sent the SA to all other peers in that mesh group.
It then floods the SA to any other MSDP peers that are not part of the mesh group on which
the SA was received. The RPF check is not performed on SA messages received from a
mesh group peer.
It is possible to have multiple mesh groups on a router. It is also possible to form mesh
group loops that will result in a routing information loop. MSDP SA messages are not RPF-
checked when they are received from an MSDP mesh group peer. An MSDP mesh group
