Information Technology Reference
In-Depth Information
Like multicast, the actual configuration of MSDP is deceptively simple. The configuration
is simple, but the actual layout of the MSDP peering sessions is where the difficulty lies.
The rule of thumb for MSDP peering session design is to mirror the BGP topology. This
ensures proper SA propagation. The configuration of an MSDP peer is as follows:
ip msdp peer
{
remote-address
} [
connect-source
local-interface
] [
remote-as
AS
]
remote-address
is the remote peering address, and connect-source is the local peering
address. This is analogous to BGP, with the neighbor address and update-source configura-
tion settings. The
remote-as
value is optional, because MSDP can automatically derive that
value based on the BGP peering information.
If only a single MSDP peering is used, a default peer can be configured. Using a default
peer removes the need to perform peer-RPF checking, because there is no possibility of SA
loops. The configuration of a default peer is
ip msdp default-peer
remote-address
If multiple default peers are defined in the configuration, they are used for redundancy. The
first one in the configuration is used. If it is unable to establish, the second one in the con-
figuration is used. Multiple default peers are not all concurrently established. Only one is
active.
Multicast NLRI in MP-BGP
The deployment of interdomain multicast is not pervasive, meaning that not all domains
have deployed multicast. The lack of pervasiveness in multicast deployment results in non-
congruent unicast and multicast topologies from an AS perspective. This lack of congruency
can create scenarios in which an MDT attempts to form across a unicast-only domain. If
the best path to a remote source is through a unicast domain, the MDT attempts to form in
that direction using the normal RPF mechanisms. However, an MDT cannot form across a
network that does not have multicast enabled, thereby breaking the interdomain multicast
functionality.
The solution is to enable BGP through the MP-BGP extensions to carry separate NLRI
specifically for use in performing RPF functions. This allows different path selection for
the same prefix in the unicast RIB (uRIB) and the multicast RIB (mRIB), which maintains
consistent unicast forwarding and allows interdomain multicast to function correctly. The
mRIB is never used for unicast forward, but the uRIB can be used for multicast RPF check-
ing. When performing the multicast RPF check, the mRIB is checked first. If there is no
entry, the uRIB is checked. The multicast NLRI is carried in MP-BGP using an address
family identifier (AFI) of 1, which indicates IPv4, and a subsequent address family identi-
fier (SAFI) of 2, which indicates multicast NLRI.
