It first helps to have an understanding of the messages that are used in MSDP. There are 5 message types in the MSDP specification.

  1. Source Active
  2. Source Active Request
  3. Source Active Response
  4. Keepalive
  5. Reserved

Remember from earlier, when a PIM DR registers a source with its RP, the RP sends a Source Active (SA) message to all its MSDP peers. Each MSDP peer that receives the SA floods the SA to all its own peers downstream from the originator.

When an RP receives an SA, it checks to see whether there are any members of the SA’s group in its domain by checking to see whether there are interfaces on the group’s (*, G) outgoing interface list. If there are no group members, the RP does nothing. If there are group members, the RP sends an (S, G) join toward the source. As a result, a branch of the source tree is constructed across AS boundaries to the RP (a Rendezvous Point Tree or RPT). As multicast packets arrive at the RP, they are forwarded down its own shared tree to the group members in the RP’s domain. The members’ DRs then have the option of joining the RPT to the source using standard PIM-SM procedures.

The originating RP continues to send periodic SAs for the (S, G) every 60 seconds for as long as the source sends packets to the group. When an RP receives an SA, it has the option to cache the message. Suppose, for example, that an RP receives an SA for (172.16.5.4, 228.1.2.3) from originating RP 10.5.4.3. The RP consults its mroute table and finds no active members for group 228.1.2.3, so it passes the SA message to its peers downstream of 10.5.4.3 without caching the message. If a host in the domain then sends a join to the RP for group 228.1.2.3, the RP adds the interface toward the host to the outgoing interface list of its (*, 224.1.2.3) entry. Because the previous SA was not cached, however, the RP has no knowledge of the source. Therefore, the RP must wait until the next SA message is received before it can initiate a join to the source.

If, however, the RP is caching SAs, the router has an entry for (172.16.5.4, 228.1.2.3) and can join the source tree as soon as a host requests a join. The trade-off here is that in exchange for reducing the join latency, memory is consumed caching SA messages that may or may not be needed. If the RP belongs to a large MSDP mesh, and there are large numbers of SAs, the memory consumption can be significant.

By default, Cisco IOS Software does not cache SAs. You can enable caching with the command ip msdp cache-sa-state. To help alleviate possible memory stress, you can link the command to an extended access list that specifies what (S, G) pairs to cache.

If an RP has an MSDP peer that is caching SAs, you can reduce the join latency at the RP without turning on caching by using SA Request and SA Response messages. When a host requests a join to a particular group, the RP sends an SA Request message to its caching peer(s). If a peer has cached source information for the group in question, it sends the information to the requesting RP with an SA Response message. The requesting RP uses the information in the SA Response but does not forward the message to any other peers. If a noncaching RP receives an SA Request, it sends an error message back to the requestor.

To enable a Cisco router to send SA Request messages, use the ip msdp sa-request command to specify the IP address or name of a caching peer. You can use the command multiple times to specify multiple caching peers.

Now, back to SA filtering.

There are several available options for filtering at an MSDP router to control and scope MSDP activity:

  • control the local sources that are allowed to register with the RP (done at the RP level, not MSDP)
  • control the SA messages the RP sends to and receives from its MSDP peers
  • control the SA Request messages the RP sends to and receives from its peers

If we enable caching on a particular msdp router, we can specify an optional access-list to limit caching to specific source / group pairs.

R1(config)# access-list 101 permit ip 10.254.0.0 0.0.255.255 224.0.0.0 31.255.255.255
R1(config)# ip msdp cache-sa-state list 101

Let’s say we wanted to limit the SA requests that we sent a caching peer. We can accomplish that with the command ip msdp filter-sa-request as below.

R1(config)# access-list 1 permit 229.50.0.0 0.0.255.255
R1(config)# ip msdp sa-request 192.168.254.1
R1(config)# ip msdp filter-sa-request 192.168.254.1 list 1

R1 will only request SA caching from the MSDP peer 192.168.254.1 for groups in the range of 229.50.0.0 through 229.50.255.255.

Our next filtering technique is used if you want to limit the multicast groups for which an MSDP router will announce SAs. This would be used to limit the scope of groups to the local domain.

R1(config)# access-list 102 permit ip 192.168.224.0 0.0.0.255 224.0.0.0 31.255.255.255
R1(config)# ip msdp redistribute list 102

This applies only to locally originated SAs.

To expand filtering to all SA messages, whether locally originated or not, you use the ip msdp sa-filter out command.

R1(config)# access-list 101 permit ip 10.254.0.0 0.0.255.255 224.0.0.0 31.255.255.255
R1(config)# ip msdp sa-filter out 192.168.1.9 list 101
R1(config)# exit

This would limit SA advertisement to sources in the 10.254.0.0/16 network.

You can also limit the SA messages that are accepted from other peers. The command is ip msdp sa-filter in <Peer> list <ext-acl>.

Finally, the TTL values of the MSDP messages are regulated with the ip msdp ttl-threshold <Peer> <hops> command.