Basic Interdomain Multicast w/ MSDP

Load inter-as.multicast.msdp.init.cfg

#IOS-XE
config replace flash:inter-as.multicast.msdp.init.cfg
 
#IOS-XR
configure
load bootflash:inter-as.multicast.msdp.init.cfg
commit replace
y

Configure a partial mesh of MSDP peerings between all RPs. Do not peer CSR9 and XRv2. All MSDP peerings must use the loopbacks.

Use the password CCIE123 for all peering sessions, and set the keepalive/hold timer values to 10/25 seconds. (By default this is 30/75 seconds).

Join the group 226.1.2.3 on CSR3 and ping this from CSR2.

Answer

#CSR10
ip msdp peer 7.0.0.11 connect-source lo0
ip msdp peer 8.0.0.12 connect-source lo0
ip msdp peer 11.0.0.9 connect-source lo0
!
ip msdp password peer 7.0.0.11 CCIE123
ip msdp password peer 8.0.0.12 CCIE123
ip msdp password peer 11.0.0.9 CCIE123
!
ip msdp keepalive 7.0.0.11 10 25
ip msdp keepalive 8.0.0.12 10 25
ip msdp keepalive 11.0.0.9 10 25

#CSR9
ip msdp peer 7.0.0.11 connect-source lo0
ip msdp peer 9.0.0.10 connect-source lo0
!
ip msdp password peer 7.0.0.11 CCIE123
ip msdp password peer 9.0.0.10 CCIE123
!
ip msdp keepalive 7.0.0.11 10 25
ip msdp keepalive 9.0.0.10 10 25

#XR1
router msdp
 peer 9.0.0.10
  password encrypted 0130252D7E5A545C
  connect-source Loopback0
  keepalive 10 25
 !
 peer 11.0.0.9
  password encrypted 0130252D7E5A545C
  connect-source Loopback0
  keepalive 10 25
 !
 peer 8.0.0.12
  password encrypted 0130252D7E5A545C
  connect-source Loopback0
  keepalive 10 25

#XR2
router msdp
 peer 9.0.0.10
  password encrypted 0130252D7E5A545C
  connect-source Loopback0
  keepalive 10 25
 !
 peer 7.0.0.11
  password encrypted 0130252D7E5A545C
  connect-source Loopback0
  keepalive 10 25

#CSR3
int gi2.538
 ip igmp join-group 236.1.2.3

Explanation

MSDP allows RPs in separate domains to share active sources with one another. In intra-domain multicast, the FHR registers the source with the RP. However, when there are multiple RPs, every other RP besides the one the FHR registers with will be unaware of the active source. All of these RPs will be unable to “bring together” the source and interested receivers.

In MSDP, peers are defined in a similar fashion to BGP. The connect-source is the TCP source address. The originator-id (not used in this lab) is the originating RP address used when sourcing SA messages. This is important in an Anycast RP setup. (Unless there is only one default MSDP peer, an RFC check is done against the originator ID. If the receiving RP sees that its own Anycast RP address is in the origiantor ID, the SA message fails the RPF check. For this reason, you should manually set the originator-id to the unique loopback on each Anycast RP).

An MSDP peer will reflect an SA message to all other peers. In a way this works like eBGP. In order to prevent an SA message from looping endlessly, an RPF check is used. An SA message is only accepted if the RPF check succeeds. This is a complicated process which is described in later labs. In this lab, the RPF check that XR2 does for R10’s SA is successful because R10 is itself the originator of the SA.

Once a remote RP learns of an active source via an SA from an MSDP peer, and the RP has matching (*, G) state, the RP can pull in the traffic by joining a (S, G) tree to the source, just as it would in response to a PIM Register. This allows multicast to work between two different domains. As long as the remote AS has an RPF-valid path back to the source (which requires PIM to be enabled on the inter-AS links), traffic should work.

We have a few options when using MSDP. We can set a TCP password (similar to BGP), adjust the keepalive timers, and perform SA filtering. This lab tests your understanding of the MSDP password and timers. The timers do not need to match for MSDP to work. But if the hold time on one side is less than the keepalive on the other side, the MSDP peering will flap continuously. Also note that the TCP password can be set after the session is already up, and it won’t affect the peering session. It will only take effect once the session is restarted. (BGP works the same way).

MSDP is sometimes called a “napkin” protocol. It seems to have been developed a little hap-hazardly. The TCP session is opened and established with apparently no data at all. There is no negotiation or “open” message like with BGP. A simple three-way handshake and keepalives keep the session up. When a new source goes active, an SA is sent within the TCP session. The SA simply contains the encapsulated data, the Source, Group, and originating RP address.

Verification

On each router, you can use show ip msdp sum to view a summary of MSDP peers.

Currently, only CSR8 and XR2 have state for (*, 236.1.2.3) because R3 has joined this ASM group. CSR8 is the LHR and XR2 is the RP for the domain. The distribution tree is currently constrained to that domain. XR2 will need to be notified of new senders to distribute the traffic to R3.

On CSR2, ping this group (236.1.2.3). R5 will register the source with the RP, R10. R10 will send a SA message to all MSDP peers with the multicast data encapsulated in the SA message. An example of an SA message is shown below. The SA message is sent to R9, but the original multicast packet is encapsulated inside. The SA message simply has the RP address (set using the originator-ID command), and one or more S, G blocks. The S prefix length must always be 32.

Somewhat like eBGP, MSDP peers will propagate SAs to all other MSDP peers. For example, R9 forwards this SA message onto its other peer, XR1 (shown below). The SA message is reflected exactly as it is received. The RP address does not change. Because there’s no notion of an AS Path in MSDP, some other mechanism must be used for loop prevention. What is used is a complex set of RPF check rules, which we will detail later.

On R10 we can see the SA that has been originated to each peer using show ip msdp peer advertised-SAs.

Notice above that each entry is under the “from mroute table” section, not the “from SA cache” section. If an SA message is reflected to another MSDP peer, it will appear in the “from SA cache” section instead. For example, we can see that CSR9 reflected this SA message to XR1 from its SA cache, not from its mroute table.

We can see the SAs accepted from a peer using show ip msdp peer accepted-SAs

We can also see the entirety of the SA cache using show ip msdp sa-cache. It is important that each RP caches SA messages even if the RP does not have matching (*, G) state. This reduces the join latency if a receiver in the local domain joins this group later.

As a side note, MSDP has a mechanism to query other peers for SA messages. If a router does not want to cache SA state, it can instead rely on another router which is caching SAs, and upon receiving a new (*, G) join, it can ask the MSDP peer if it has any cached SAs for that group. However, IOS-XE does not appear to let us disable the default command ip msdp cache-sa-state, so this mechanism is not relevant to us. It seems IOS-XR allows us to filter which SAs we cache, but not query another router for SAs.

Back to our topology. Remember that to start, XR2 is the only router with (*, G) state. Upon learning of the source, XR2 joins the (S, G). Because PIM is running on the inter-AS links, and XR2 has a route to CSR2, the (S, G) forms successfully. On XR2, we see an E flag on the (S, G) entry, which indicates that the source is external (learned via MSDP):

On R10 we see an A flag on the (S, G) entry, because it is advertised via MSDP:

We can see on CSR6 that the (S, G) has an outgoing interface of the link to XR2, because XR2 has joined the (S, G) tree upon learning of the source.

On CSR8 we should see that the hardware forwarding count for this entry is increasing if we keep sending packets from CSR2. (CSR3 is not running ip multicast-routing, so it does not respond to the pings).

Let’s briefly explore the MRIB states when the roles are reversed: XR2 is advertising a source and R10 has joined the (S, G) tree. We’ll join a group from R2 and ping this from R3.

#R2
int Gi2.525
 ip igmp join-group 236.100.1.1

#R3
ping 236.100.1.1

R10 shows an M flag because the entry was created via an MSDP entry. The RPF check is done using MBGP.

XR2 does not appear to show anything indicating that it is advertising the mapping via MSDP. All we see is an L flag for “domain-local scope”:

Summary

MSDP is the key ingredient to achieving interdomain ASM. It is important that each domain has full control over its own RP. ASM relies on PIM Registers which allow the RP to learn of the active sources, and then pair the source traffic with the RPT multicast distribution tree. For this to work for interdomain ASM, each RP must announce active sources to all other RPs in other domains. This is the role of MSDP.

Interdomain ASM also requires PIM on all interdomain links. This allows PIM Joins to work, which build the interdomain (S, G) tree. PIM also requires the RPF check on the source to succeed as usual. Using BGP ipv4/multicast and ipv6/multicast, we can create a separate multicast topology from the unicast topology. The BGP ipv4/multicast or ipv6/multicast routes are preferred for the RPF check, and a PIM Join will be sent out the corresponding interface to the BGP route’s nexthop.

It’s interesting to realize that PIM has no notion of internal or external neighborships. PIM simply forms adjacencies on links on which it is enabled. The definition of PIM domains for ASM can then be thought as “where the RP information stops.” By bounding the propagation of the RP, for example by using BSR with ip pim bsr-border, you define the ASM domain. MSDP is run between the RPs in each domain simply to alert remote RPs of active senders.