MSDP is used to implement PIM-SM inter-domain multicast and anycast Rendezvous Point (RP) in a PIM-SM domain. You can control connections between MSDP peers, adjust Source Active (SA) message parameters, and configure authentication for MSDP peers and filtering policies for SA messages to enhance MSDP security. The system supports multi-instance MSDP.
When a multicast network is divided into multiple PIM-SM domains, MSDP is used to connect RPs in each domain to share the multicast source information. In this manner, hosts in a domain can receive multicast data sent by multicast sources in other domains.
You can configure MSDP peers in an autonomous system (AS) domain, inter-AS MSDP peers, and static Reverse Path Forwarding (RPF) peers.
After anycast RP is applied to a PIM-SM domain, the multicast source registers with the nearest RP and receivers send Join messages to the nearest RP. This reduces the burden of a single RP, implements RP backup, and optimizes the forwarding path.
You can use a loopback interface as an interface of C-RP or static RP and specify the logical RP address for an SA message.
In the FW, you can set up and tear down an MSDP session, and configure the period for retrying to send TCP connection requests to the remote MSDP peers.
By default, SA-Cache is enabled on FWs. Therefore, FWs can locally store the (S, G) information carried in SA messages. When required to receive the multicast data, the FWs can obtain the (S, G) information from the SA-Cache.
You can set the maximum number of cached (S, G) entries, which can effectively prevent the Denial of Service (DoS) attack.
You can disable SA-Cache on a FW. After the SA-Cache on a FW is disabled, the FW does not locally store the (S, G) information carried in SA messages. When the FW needs to receive multicast data, it needs to wait for the SA message to be sent by its MSDP peer in the next period. This causes a delay for receivers to obtain multicast source information.
Certain FWs cannot be enabled with SA Cache or the capacity of SA Cache on these FWs is too small. When these FWs need to receive multicast data, they cannot immediately obtain the valid (S, G) information but need to wait for the SA message to be sent by their MSDP peers in the next period.
If SA Cache is enabled on the remote MSDP peer and the capacity of the SA Cache is large, you can configure "sending SA request messages" on the local FW to reduce the period during which receivers obtain multicast source information.
At the same time, you can also configure the filtering rules for receiving SA request messages on the remote MSDP peers.
When the interval for a certain multicast source to send multicast data is longer than the timeout period of an (S, G) entry, the source DR can only encapsulate burst multicast data in Register messages and send them to the source RP. The source RP uses SA messages to transmit (S, G) information to the remote RP. Then, the remote RP will send an (S, G) Join message to the multicast source to create a shortest path tree (SPT). Because of the timeout of the (S, G) entry, the remote user cannot receive the multicast data sent by multicast source S.
The FW supports the transmission of burst multicast data. You can enable the function of encapsulating a multicast data packet in an SA message on the source RP. The source RP can then encapsulate multicast data in an SA message and send the message out. Once the SA message is received, the remote RP decapsulates the message, and then forwards multicast data to hosts in the domain along the rendezvous point tree (RPT).
Setting the TTL threshold can limit the transmission scope of a multicast data packet contained in an SA message. After receiving an SA message containing a multicast data packet, an MSDP peer checks the TTL value in the IP header of the multicast packet. If the TTL value is equal to or smaller than the threshold, the MSDP peer does not forward the SA message to the specific remote peers. If the TTL value is greater than the threshold, the MSDP peer reduces the TTL value in the IP header of the multicast packet by 1, and then encapsulates the multicast packet in an SA message and sends the message out.
By default, MSDP devices receive all SA messages that pass the Reverse Path Forwarding (RPF) check and forward them to all MSDP peers.
To control the transmission of SA messages between MSDP peers, you can configure filtering rules by using the following methods:
Setting rules for filtering SA messages based on multicast sources on the source RP
The source RP filters active multicast sources that register with the local FW, and then determines whether to send (S, G) entries based on the rules.
Setting rules for filtering SA messages received from remote MSDP peers
When an SA message sent by a remote MSDP peer reaches the local FW, the FW determines whether to receive the message based on the rules.
Setting rules for filtering SA messages forwarded to remote MSDP peers
Before forwarding an SA message to a remote MSDP peer, the local FW determines whether to forward it based on the rules.
MSDP peer relationships can be set up between interfaces on multicast FWs that belong to the same instance (including the public instance and VPN instance). MSDP peers exchange SA message with each other. The inter-domain VPN multicast is implemented.
Multicast FWs on which multi-instance is applied maintain a set of MSDP mechanisms for each instance. Multicast FWs also guarantee the information separation among different instances; therefore, only MSDP and PIM-SM that belong to the same instance can interact.
Configuring MSDP Message-digest algorithm 5 (MD5) or Key-Chain authentication can improve the security of TCP connections set up between MSDP peers. Note that the MSDP peers must be configured with the same authentication password; otherwise, the TCP connection cannot be set up between MSDP peers and MSDP messages cannot be transmitted.