MSDP is an inter-domain multicast solution that addresses the interconnection of PIM-SM domains. It discovers multicast source information in other PIM-SM domains.

In the basic PIM-SM mode, a multicast source registers only with the RP in the local PIM-SM domain, and the multicast source information in each domain is isolated. As a result, both of the following occur:

· The RP obtains the source information only within the local domain.

· A multicast distribution tree is built only within the local domain to deliver multicast data locally.

MSDP enables the RPs of different PIM-SM domains to share their multicast source information. The local RP can then join the SPT rooted at the multicast source across the PIM-SM domains. This allows multicast data to be transmitted among different domains.

With MSDP peer relationships established between appropriate routers in the network, the RPs of different PIM-SM domains are interconnected with one another. These MSDP peers exchange source active (SA) messages, so that the multicast source information is shared among these domains.

MSDP is applicable only if the intra-domain multicast protocol is PIM-SM. MSDP takes effect only for the ASM model.

For more information about the concepts of DR, BSR, C-BSR, RP, C-RP, SPT, and RPT mentioned in this document, see "Configuring PIM."

How MSDP works

MSDP peers

One or more pairs of MSDP peers in the network form an MSDP interconnection map. In the map, the RPs of different PIM-SM domains interconnect in a series. An SA message from an RP is relayed to all other RPs by these MSDP peers.

Figure 1 MSDP peer locations in the network

As shown in Figure 1, an MSDP peer can be created on any PIM-SM router. MSDP peers created on PIM-SM routers that assume different roles function differently.

· MSDP peers created on RPs:

¡ Source-side MSDP peer—MSDP peer closest to the multicast source, such as RP 1. The source-side RP creates and sends SA messages to its remote MSDP peer to notify the MSDP peer of the locally registered multicast source information.

A source-side MSDP peer must be created on the source-side RP. Otherwise, it cannot advertise the multicast source information out of the PIM-SM domain.

¡ Receiver-side MSDP peer—MSDP peer closest to the receivers, typically the receiver-side RP, such as RP 3. After receiving an SA message, the receiver-side MSDP peer resolves the multicast source information carried in the message. Then, it joins the SPT rooted at the multicast source across the PIM-SM domains. When multicast data from the multicast source arrives, the receiver-side MSDP peer forwards the data to the receivers along the RPT.

¡ Intermediate MSDP peer—MSDP peer with multiple remote MSDP peers, such as RP 2. An intermediate MSDP peer forwards SA messages received from one remote MSDP peer to other remote MSDP peers. The intermediate MSDP peer acts as a relay for forwarding multicast source information.

· MSDP peers created on common PIM-SM routers (other than RPs):

Router A and Router B are MSDP peers on common multicast routers. Such MSDP peers just forward received SA messages.

In a PIM-SM network using the BSR mechanism, the RP is dynamically elected from C-RPs. A PIM-SM network typically has multiple C-RPs to ensure network robustness. Because the RP election result is unpredictable, MSDP peering relationships must be built among all C-RPs to always keep the winning C-RP on the MSDP interconnection map. Losing C-RPs assume the role of common PIM-SM routers on this map.

Inter-domain multicast delivery through MSDP

As shown in Figure 2, an active source (Source) exists in the domain PIM-SM 1, and RP 1 has learned the existence of Source through multicast source registration. RPs in PIM-SM 2 and PIM-SM 3 also seek the location of Source so that multicast traffic from Source can be sent to their receivers. MSDP peering relationships must be established between RP 1 and RP 3 and between RP 3 and RP 2.

Figure 2 Inter-domain multicast delivery through MSDP

The process of implementing PIM-SM inter-domain multicast delivery by leveraging MSDP peers is as follows:

1. The multicast source in PIM-SM 1 sends the first multicast packet to multicast group G. When DR 1 receives this multicast packet, it encapsulates the multicast data within a register message and sends the register message to RP 1. Then, RP 1 obtains information about the multicast source.

2. As the source-side RP, RP 1 creates SA messages and periodically sends them to its MSDP peer.

An SA message contains the addresses of the multicast source (S), the multicast group (G), and the RP that has created this SA message (RP 1).

3. On MSDP peers, each SA message undergoes an RPF check and multicast policy-based filtering. Only SA messages that have arrived along the correct path and passed the filtering are received and forwarded. This avoids delivery loops of SA messages. In addition, the MSDP mesh group mechanism can avoid SA message flooding between MSDP peers.

NOTE:

An MSDP mesh group refers to a group of MSDP peers that establish MSDP peering relationships with each other and share the same group name.

4. SA messages are forwarded from one MSDP peer to another. Finally, information about the multicast source traverses all PIM-SM domains with MSDP peers (PIM-SM 2 and PIM-SM 3, in this example).

5. After receiving the SA message, RP 2 in PIM-SM 2 examines whether any receivers for the multicast group exist in the domain.

¡ If a receiver exists in the domain, the RPT for the multicast group G is maintained between RP 2 and the receivers. RP 2 creates an (S, G) entry and sends an (S, G) join message. The join message travels hop by hop toward the multicast source, and the SPT is established across the PIM-SM domains.

The subsequent multicast data flows to RP 2 along the SPT, and from RP 2 to the receiver-side DR along the RPT. After receiving the multicast data, the receiver-side DR determines whether to initiate an RPT-to-SPT switchover process based on its configuration.

¡ If no receivers exist in the domain, RP 2 neither creates an (S, G) entry nor sends a join message toward the multicast source.

In inter-domain multicasting using MSDP, once an RP gets information about a multicast source in another PIM-SM domain, it no longer relies on RPs in other PIM-SM domains. The receivers can override the RPs in other domains and directly join the multicast SPT rooted at the source.

Anycast RP through MSDP

PIM-SM requires only one active RP to serve each multicast group. If the active RP fails, the multicast traffic might be interrupted. The Anycast RP mechanism enables redundancy backup between two or more RPs by configuring multiple RPs with the same IP address for one multicast group. A multicast source registers with the closest RP or a receiver joins the closest RP to implement source information synchronization.

Anycast RP has the following benefits:

· Optimal RP path—A multicast source registers with the closest RP to build an optimal SPT. A receiver joins the closest RP to build an optimal RPT.

· Redundancy backup among RPs—When an RP fails, the RP-related multicast sources and receiver-side DRs will register with or join their closest available RPs. This achieves redundancy backup among RPs.

Anycast RP can be implemented through MSDP. In this method, you can configure multiple RPs with the same IP address for one multicast group and establish MSDP peering relationships between the RPs.

As shown in Figure 3, within a PIM-SM domain, a multicast source sends multicast data to multicast group G, and the receiver joins the multicast group.

To implement Anycast RP:

1. Configure the same IP address (known as Anycast RP address, typically a private address) to an interface on Router A and Router B.

¡ An Anycast RP address is usually configured on a logical interface, such as a loopback interface.

¡ Make sure the Anycast RP address is a host address (with the subnet mask 255.255.255.255).

2. Configure these interfaces as C-RPs.

3. Establish an MSDP peering relationship between Router A and Router B. An MSDP peer address must be different from the Anycast RP address.

Figure 3 Intra-domain Anycast RP through MSDP

The operating process of Anycast RP through MSDP is as follows:

1. After receiving the multicast data from Source, the source-side DR registers with the closest RP (RP 1).

2. After receiving the IGMP report message from the receiver, the receiver-side DR sends a join message toward the closest RP (RP 2). Therefore, an RPT rooted at this RP is established.

3. The RPs share the registered multicast source information through SA messages. After obtaining the multicast source information, RP 2 sends an (S, G) source-specific join message toward the source to create an SPT.

4. When the multicast data reaches RP 2 along the SPT, the RP forwards the data along the RPT to the receiver. After receiving the multicast data, the receiver-side DR determines whether to initiate an RPT-to-SPT switchover process based on its configuration.

MSDP support for VPNs

Interfaces on the multicast routers in a VPN can set up MSDP peering relationships with each other. By exchanging SA messages between MSDP peers, multicast data can be transmitted in a VPN across different PIM-SM domains.

To support MSDP for VPNs, a multicast router that runs MSDP maintains an independent set of MSDP mechanism for each VPN that it supports. These mechanisms include SA message cache, peering connection, timers, sending cache, and cache for exchanging PIM messages.

One VPN is isolated from another, and MSDP and PIM-SM messages can be exchanged only within the same VPN.

Protocols and standards

· RFC 3618, Multicast Source Discovery Protocol (MSDP)

· RFC 3446, Anycast Rendezvous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)

MSDP configuration task list

Tasks at a glance
Configuring basic MSDP features: · (Required.) Enabling MSDP · (Required.) Creating an MSDP peering connection · (Optional.) Configuring a static RPF peer
Configuring an MSDP peering connection: · (Optional.) Configuring a description for an MSDP peer · (Optional.) Configuring an MSDP mesh group · (Optional.) Controlling MSDP peering connections
Configuring SA message-related parameters: · (Optional.) Configuring SA message contents · (Optional.) Configuring SA request messages · (Optional.) Configuring SA message policies · (Optional.) Configuring the SA cache mechanism

Tasks at a glance

Configuring basic MSDP features:

· (Required.) Enabling MSDP

· (Required.) Creating an MSDP peering connection

· (Optional.) Configuring a static RPF peer

Configuring an MSDP peering connection:

· (Optional.) Configuring a description for an MSDP peer

· (Optional.) Configuring an MSDP mesh group

· (Optional.) Controlling MSDP peering connections

Configuring SA message-related parameters:

· (Optional.) Configuring SA message contents

· (Optional.) Configuring SA request messages

· (Optional.) Configuring SA message policies

· (Optional.) Configuring the SA cache mechanism

Configuring basic MSDP features

All the configuration tasks in this section should be performed on RPs in PIM-SM domains, and each of these RPs acts as an MSDP peer.

Configuration prerequisites

Before you configure basic MSDP features, complete the following tasks:

· Configure a unicast routing protocol so that all devices in the domain can interoperate at the network layer.

· Configure PIM-SM to enable intra-domain multicast.

Enabling MSDP

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable IP multicast routing and enter MRIB view.	multicast routing [ vpn-instance vpn-instance-name ]	By default, IP multicast routing is disabled.
3. Return to system view.	quit	N/A
4. Enable MSDP and enter MSDP view.	msdp [ vpn-instance vpn-instance-name ]	By default, MSDP is disabled.

Creating an MSDP peering connection

An MSDP peering relationship is identified by an address pair (the addresses of the local MSDP peer and the remote MSDP peer). To create an MSDP peering connection, you must perform the creation operation on both devices that are a pair of MSDP peers.

If an MSDP peer and a BGP peer share the same interface, configure the same IP address for the MSDP peer and the BGP peer as a best practice.

To create an MSDP peering connection:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MSDP view.	msdp [ vpn-instance vpn-instance-name ]	N/A
3. Create an MSDP peering connection.	peer peer-address connect-interface interface-type interface-number	By default, MSDP peering connections are not created.

Configuring a static RPF peer

Configuring static RPF peers can avoid RPF check for SA messages.

If only one MSDP peer is configured on a router, this MSDP peer acts as a static RPF peer.

To configure a static RPF peer:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MSDP view.	msdp [ vpn-instance vpn-instance-name ]	N/A
3. Configure a static RPF peer.	static-rpf-peer peer-address [ rp-policy ip-prefix-name ]	By default, static RPF peers are not configured.

Configuring an MSDP peering connection

This section describes how to configure an MSDP peering connection.

Configuration prerequisites

Before you configure an MSDP peering connection, complete the following tasks:

· Configure a unicast routing protocol so that all devices in the domain can interoperate at the network layer.

· Configure basic MSDP features.

Configuring a description for an MSDP peer

MSDP peer descriptions help administrators easily distinguish between different MSDP peers and better manage them.

To configure a description for an MSDP peer:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MSDP view.	msdp [ vpn-instance vpn-instance-name ]	N/A
3. Configure a description for an MSDP peer.	peer peer-address description text	By default, no description for an MSDP peer exists.

Configuring an MSDP mesh group

An AS might contain multiple MSDP peers. You can use the MSDP mesh group mechanism to avoid SA message flooding among these MSDP peers and to optimize the multicast traffic.

In an MSDP mesh group, member MSDP peers forward SA messages that passed the RPF check from outside the mesh group to the other members in the mesh group. If a mesh group member receives an SA message from another member, it neither performs an RPF check on the message nor forwards the message to the other members.

This mechanism not only avoids SA message flooding but also simplifies the RPF check mechanism because you do not need to run BGP between these MSDP peers.

To organize multiple MSDP peers in a mesh group, assign these MSDP peers to the same mesh group. Before doing this, make sure the routers are interconnected with one another.

To configure an MSDP mesh group:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MSDP view.	msdp [ vpn-instance vpn-instance-name ]	N/A
3. Configure an MSDP mesh group..	peer peer-address mesh-group name	By default, an MSDP peer does not belong to any mesh group. If you assign an MSDP peer to multiple mesh groups, the most recent configuration takes effect.

Controlling MSDP peering connections

MSDP peers are interconnected over TCP (port number 639). You can tear down or re-establish MSDP peering connections to control SA message exchange between the MSDP peers. When the connection between two MSDP peers is torn down, SA messages are no longer delivered between them. The MSDP peers will not attempt to re-establish the connection. The configuration information, however, remains unchanged.

A TCP connection is required when one of the following conditions exists:

· A new MSDP peer is created.

· A previously deactivated MSDP peering connection is reactivated.

· A previously failed MSDP peer attempts to resume operation.

You can adjust the interval between MSDP peering connection attempts.

To enhance MSDP security, configure a password for MD5 authentication used by both MSDP peers to establish a TCP connection. If the MD5 authentication fails, the TCP connection cannot be established.

IMPORTANT:

The MSDP peers involved in MD5 authentication must be configured with the same authentication method and password. Otherwise, the authentication fails and the TCP connection cannot be established.

To control MSDP peering connections:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MSDP view.	msdp [ vpn-instance vpn-instance-name ]	N/A
3. Tear down an MSDP peering connection.	shutdown peer-address	By default, an MSDP peering connection is active.
4. Configure the interval between MSDP peering connection attempts.	timer retry interval	The default setting is 30 seconds.
5. Configure MD5 authentication for both MSDP peers to establish a TCP connection.	peer peer-address password { cipher \| simple } password	By default, MD5 authentication is not performed before a TCP connection is established.

Configuring SA message-related parameters

This section describes how to configure SA message-related parameters.

Configuration prerequisites

Before you configure SA message delivery, complete the following tasks:

· Configure a unicast routing protocol so that all devices in the domain can interoperate at the network layer.

· Configure basic MSDP features.

Configuring SA message contents

Some multicast sources send multicast data at an interval longer than the aging time of (S, G) entries. In this case, the source-side DR must encapsulate multicast data packet-by-packet in register messages and send them to the source-side RP. The source-side RP transmits the (S, G) information to the remote RP through SA messages. Then, the remote RP sends join messages to the source-side DR and builds an SPT. Because the (S, G) entries have timed out, remote receivers can never receive the multicast data from the multicast source.

To avoid this problem, you can configure the source-side RP to encapsulate multicast data in SA messages. As a result, the source-side RP can forward the multicast data in SA messages to its remote MSDP peers. After receiving the SA messages, the remote RP decapsulates the SA messages and forwards the multicast data to the receivers in the local domain along the RPT.

The MSDP peers deliver SA messages to one another. After receiving an SA message, a router performs an RPF check on the message. If the router finds that the remote RP address is the same as the local RP address, it discards the SA message.

However, in the Anycast RP application, you must configure the same IP address for the RPs in the same PIM-SM domain and configure these RPs as MSDP peers. To make sure SA messages can pass the RPF check, you must assign SA messages a logical RP address that is different than the actual RP address. A logical RP address is the address of a logical interface on the router where the RP resides.

To configure the SA message contents:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MSDP view.	msdp [ vpn-instance vpn-instance-name ]	N/A
3. Enable multicast data encapsulation in SA messages.	encap-data-enable	By default, an SA message contains only (S, G) entries, but not the multicast data.
4. Configure the interface address as the RP address in SA messages.	originating-rp interface-type interface-number	By default, PIM RP address is the RP address in SA messages.

Configuring SA request messages

By default, after receiving a new join message, a router does not automatically send an SA request message to any MSDP peer. Instead, it waits for the next SA message from its MSDP peer. This will cause the receiver to delay obtaining multicast source information.

An SA request policy enables the switch to filter SA request messages by using an ACL that specifies the multicast groups. This reduces the join latency.

IMPORTANT:

Before you enable the router to send SA requests, make sure you disable the SA message cache mechanism.

To configure SA request transmission and filtering:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MSDP view.	msdp [ vpn-instance vpn-instance-name ]	N/A
3. Enable the device to send SA request messages.	peer peer-address request-sa-enable	By default, after receiving a new join message, a device does not send an SA request message to any MSDP peer. Instead, it waits for the next SA message from its MSDP peer.
4. Configure an SA request policy.	peer peer-address sa-request-policy [ acl acl-number ]	By default, no SA request policy exists.

Configuring SA message policies

To control the propagation of multicast source information, you can configure the following policies:

· SA creation policy—Limits the multicast source information advertised in SA messages. This policy enables the router to advertise (S, G) entries by using an ACL that specifies the multicast sources and groups.

· SA incoming or outgoing policy—Limits the receipt or forwarding of SA messages. This policy enables the router to receive or forward SA messages by using an ACL that specifies the multicast sources and groups.

By default, multicast data packets are encapsulated in SA messages and forwarded to MSDP peers only if the TTL values in the packets are larger than zero. You can set the lower TTL threshold for multicast data packets encapsulated in SA messages that are sent to an MSDP peer. Then, only multicast data packets whose TTL values are larger than or equal to the configured value are encapsulated in SA messages. Only SA messages whose TTL values are larger than or equal to the configured value are forwarded to the specified MSDP peer. This controls the multicast data packet encapsulation and limits the propagation range of the SA messages.

To configure SA message policies:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MSDP view.	msdp [ vpn-instance vpn-instance-name ]	N/A
3. Configure an SA creation policy.	import-source [ acl acl-number ]	By default, no SA creation policy exists.
4. Configure an SA incoming or outgoing policy.	peer peer-address sa-policy { export \| import } [ acl acl-number ]	By default, no SA incoming or outgoing policy exists.
5. Set the lower TTL threshold for multicast data packets encapsulated in SA messages.	peer peer-address minimum-ttl ttl-value	The default setting is 0.

Configuring the SA cache mechanism

The SA cache mechanism enables the router to locally cache (S, G) entries contained in SA messages. It reduces the time for obtaining multicast source information, but increases memory occupation.

With the SA message cache mechanism enabled, when the router receives a new (*, G) join message, it searches its SA message cache first.

· If no matching (S, G) entry is found, the router waits for the SA message that its MSDP peer sends in the next cycle.

· If a matching (S, G) entry is found in the cache, the router joins the SPT rooted at S.

To protect the router against DoS attacks, you can set a limit on the number of (S, G) entries that the router can cache.

To configure the SA message cache mechanism:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MSDP view.	msdp [ vpn-instance vpn-instance-name ]	N/A
3. Enable the SA message cache mechanism.	cache-sa-enable	By default, the SA message cache mechanism is enabled. The device caches the (S, G) entries contained in the received SA messages.
4. Configure the maximum number of (S, G) entries learned from the specified MSDP peer that the router can cache.	peer peer-address sa-cache-maximum sa-limit	The default setting is 4294967295.

Displaying and maintaining MSDP

Execute display commands in any view and reset commands in user view.

Task	Command
Display brief information about MSDP peers.	display msdp [ vpn-instance vpn-instance-name ] brief [ state { connect \| disabled \| established \| listen \| shutdown } ]
Display detailed status of MSDP peers.	display msdp [ vpn-instance vpn-instance-name ] peer-status [ peer-address ]
Display (S, G) entries in the SA message cache.	display msdp [ vpn-instance vpn-instance-name ] sa-cache [ group-address \| source-address \| as-number ] *
Display the number of (S, G) entries in the SA message cache.	display msdp [ vpn-instance vpn-instance-name ] sa-count [ as-number ]
Reset the TCP connection with an MSDP peer and clear statistics for the MSDP peer.	reset msdp [ vpn-instance vpn-instance-name ] peer [ peer-address ]
Clear (S, G) entries in the SA message cache.	reset msdp [ vpn-instance vpn-instance-name ] sa-cache [ group-address ]
Clear statistics for an MSDP peer without resetting the TCP connection with the MSDP peer.	reset msdp [ vpn-instance vpn-instance-name ] statistics [ peer-address ]

MSDP configuration examples

This section provides examples of configuring MSDP on switches.

PIM-SM inter-domain multicast configuration

Network requirements

As shown in Figure 4, OSPF runs within AS 100 and AS 200 and BGP runs between them. Each PIM-SM domain has at least one multicast source or receiver.

Set up MSDP peering relationships between the RPs in the PIM-SM domains to share multicast source information among the PIM-SM domains.

Figure 4 Network diagram

Table 1 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
Switch A	Vlan-int103	10.110.1.2/24	Switch D	Vlan-int104	10.110.4.2/24
Switch A	Vlan-int100	10.110.2.1/24	Switch D	Vlan-int300	10.110.5.1/24
Switch A	Vlan-int200	10.110.3.1/24	Switch E	Vlan-int105	10.110.6.1/24
Switch B	Vlan-int103	10.110.1.1/24	Switch E	Vlan-int102	192.168.3.2/24
Switch B	Vlan-int101	192.168.1.1/24	Switch E	Loop0	3.3.3.3/32
Switch B	Loop0	1.1.1.1/32	Switch F	Vlan-int105	10.110.6.2/24
Switch C	Vlan-int104	10.110.4.1/24	Switch F	Vlan-int400	10.110.7.1/24
Switch C	Vlan-int102	192.168.3.1/24	Source 1	—	10.110.2.100/24
Switch C	Vlan-int101	192.168.1.2/24	Source 2	—	10.110.5.100/24
Switch C	Loop0	2.2.2.2/32

Configuration procedure

1. Assign an IP address and subnet mask to each interface according to Figure 4. (Details not shown.)

2. Configure OSPF on all the switches in the ASs. (Details not shown.)

3. Enable IP multicast routing, enable PIM-SM on each interface, and configure a PIM-SM domain border:

# On Switch A, enable IP multicast routing.

<SwitchA> system-view

[SwitchA] multicast routing

[SwitchA-mrib] quit

# Enable PIM-SM on VLAN-interface 103 and VLAN-interface 100.

[SwitchA] interface vlan-interface 103

[SwitchA-Vlan-interface103] pim sm

[SwitchA-Vlan-interface103] quit

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] pim sm

[SwitchA-Vlan-interface100] quit

# Enable IGMP on the receiver-side interface (VLAN-interface 200).

[SwitchA] interface vlan-interface 200

[SwitchA-Vlan-interface200] igmp enable

[SwitchA-Vlan-interface200] quit

# Enable IP multicast routing and PIM-SM on Switch B, Switch C, Switch D, Switch E, and Switch F in the same way Switch A is configured. (Details not shown.)

# Configure a PIM domain border on Switch B.

[SwitchB] interface vlan-interface 101

[SwitchB-Vlan-interface101] pim bsr-boundary

[SwitchB-Vlan-interface101] quit

# Configure a PIM domain border on Switch C and Switch E in the same way Switch B is configured. (Details not shown.)

4. Configure C-BSRs and C-RPs:

# Configure Loopback 0 as a C-BSR and a C-RP on Switch B.

[SwitchB] pim

[SwitchB-pim] c-bsr 1.1.1.1

[SwitchB-pim] c-rp 1.1.1.1

[SwitchB-pim] quit

# Configure C-BSRs and C-RPs on Switch C and Switch E in the same way Switch B is configured. (Details not shown.)

5. Configure BGP for mutual route redistribution between BGP and OSPF:

# On Switch B, configure an EBGP peer, and redistribute OSPF routes.

[SwitchB] bgp 100

[SwitchB-bgp] router-id 1.1.1.1

[SwitchB-bgp] peer 192.168.1.2 as-number 200

[SwitchB-bgp] address-family ipv4 unicast

[SwitchB-bgp-ipv4] import-route ospf 1

[SwitchB-bgp-ipv4] peer 192.168.1.2 enable

[SwitchB-bgp-ipv4] quit

# On Switch C, configure an EBGP peer, and redistribute OSPF routes.

[SwitchC] bgp 200

[SwitchC-bgp] router-id 2.2.2.2

[SwitchC-bgp] peer 192.168.1.1 as-number 100

[SwitchC-bgp] address-family ipv4 unicast

[SwitchC-bgp-ipv4] import-route ospf 1

[SwitchC-bgp-ipv4] peer 192.168.1.1 enable

[SwitchC-bgp-ipv4] quit

# Redistribute BGP routes into OSPF on Switch B.

[SwitchB] ospf 1

[SwitchB-ospf-1] import-route bgp

[SwitchB-ospf-1] quit

# Redistribute BGP routes into OSPF on Switch C.

[SwitchB] ospf 1

[SwitchB-ospf-1] import-route bgp

[SwitchB-ospf-1] quit

6. Configure MSDP peers:

# Configure an MSDP peer on Switch B.

[SwitchB] msdp

[SwitchB-msdp] peer 192.168.1.2 connect-interface vlan-interface 101

[SwitchB-msdp] quit

# Configure an MSDP peer on Switch C.

[SwitchC] msdp

[SwitchC-msdp] peer 192.168.1.1 connect-interface vlan-interface 101

[SwitchC-msdp] peer 192.168.3.2 connect-interface vlan-interface 102

[SwitchC-msdp] quit

# Configure MSDP peers on Switch E.

[SwitchE] msdp

[SwitchE-msdp] peer 192.168.3.1 connect-interface vlan-interface 102

[SwitchE-msdp] quit

Verifying the configuration

# Display information about BGP peer groups on Switch B.

[SwitchB] display bgp peer ipv4

BGP local router ID: 1.1.1.1

Local AS number: 100

Total number of peers: 1 Peers in established state: 1

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

192.168.1.2 200 24 21 0 6 00:20:07 Established

# Display information about BGP peer groups on Switch C.

[SwitchC] display bgp peer ipv4

BGP local router ID: 2.2.2.2

Local AS number: 1

Total number of peers: 1 Peers in established state: 1

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

192.168.1.1 100 18 16 0 1 00:20:07 Established

# Display the BGP routing table on Switch C.

[SwitchC] display bgp routing-table ipv4

Total number of routes: 5

BGP local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

Network NextHop MED LocPrf PrefVal Path/Ogn

* > 1.1.1.1/32 192.168.1.1 0 0 100?

* >i 2.2.2.2/32 0.0.0.0 0 0 ?

* > 192.168.1.0 0.0.0.0 0 0 ?

* > 192.168.1.1/32 0.0.0.0 0 0 ?

* > 192.168.1.2/32 0.0.0.0 0 0 ?

When Source 1 in PIM-SM 1 and Source 2 in PIM-SM 2 send multicast information, receivers in PIM-SM 1 and PIM-SM 3 can receive the multicast data.

# Display brief information about MSDP peer groups on Switch B.

[SwitchB] display msdp brief

Configured Established Listen Connect Shutdown Disabled

1 1 0 0 0 0

Peer address State Up/Down time AS SA count Reset count

192.168.1.2 Established 00:12:57 200 13 0

# Display brief information about MSDP peer groups on Switch C.

[SwitchC] display msdp brief

Configured Established Listen Connect Shutdown Disabled

1 1 0 0 0 0

Peer address State Up/Down time AS SA count Reset count

192.168.3.2 Established 01:43:57 ? 8 0

192.168.1.1 Established 01:43:57 ? 13 0

# Display brief information about MSDP peer groups on Switch E.

[SwitchE] display msdp brief

Configured Established Listen Connect Shutdown Disabled

1 1 0 0 0 0

Peer address State Up/Down time AS SA count Reset count

192.168.3.1 Established 01:07:57 200 8 0

# Display detailed MSDP peer information on Switch B.

[SwitchB] display msdp peer-status

MSDP Peer 192.168.1.2; AS 200

Description:

Information about connection status:

State: Established

Up/down time: 00:15:47

Resets: 0

Connection interface: Vlan-interface101 (192.168.1.1)

Received/sent messages: 16/16

Discarded input messages: 0

Discarded output messages: 0

Elapsed time since last connection or counters clear: 00:17:40

Mesh group peer joined: momo

Last disconnect reason: Hold timer expired with truncated message

Truncated packet: 5 bytes in buffer, type: 1, length: 20, without packet time: 75s

Information about (Source, Group)-based SA filtering policy:

Import policy: None

Export policy: None

Information about SA-Requests:

Policy to accept SA-Requests: None

Sending SA-Requests status: Disable

Minimum TTL to forward SA with encapsulated data: 0

SAs learned from this peer: 0, SA cache maximum for the peer: 4294967295

Input queue size: 0, Output queue size: 0

Counters for MSDP messages:

RPF check failure: 0

Incoming/outgoing SA: 0/0

Incoming/outgoing SA-Request: 0/0

Incoming/outgoing SA-Response: 0/0

Incoming/outgoing Keepalive: 867/867

Incoming/outgoing Notification: 0/0

Incoming/outgoing Traceroutes in progress: 0/0

Incoming/outgoing Traceroute reply: 0/0

Incoming/outgoing Unknown: 0/0

Incoming/outgoing data packet: 0/0

Anycast RP configuration

Network requirements

As shown in Figure 5, OSPF runs within the domain to provide unicast routes.

Configure the Anycast RP application so that the receiver-side DRs and the source-side DRs can initiate a join process to their respective RPs that are topologically closest to them.

The router ID of Switch B is 1.1.1.1, and the router ID of Switch D is 2.2.2.2. Set up an MSDP peering relationship between Switch B and Switch D.

Figure 5 Network diagram

Table 2 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
Source 1	—	10.110.5.100/24	Switch C	Vlan-int101	192.168.1.2/24
Source 2	—	10.110.6.100/24	Switch C	Vlan-int102	192.168.2.2/24
Switch A	Vlan-int300	10.110.5.1/24	Switch D	Vlan-int200	10.110.3.1/24
Switch A	Vlan-int103	10.110.2.2/24	Switch D	Vlan-int104	10.110.4.1/24
Switch B	Vlan-int100	10.110.1.1/24	Switch D	Vlan-int102	192.168.2.1/24
Switch B	Vlan-int103	10.110.2.1/24	Switch D	Loop0	2.2.2.2/32
Switch B	Vlan-int101	192.168.1.1/24	Switch D	Loop10	4.4.4.4/32
Switch B	Loop0	1.1.1.1/32	Switch D	Loop20	10.1.1.1/32
Switch B	Loop10	3.3.3.3/32	Switch E	Vlan-int400	10.110.6.1/24
Switch B	Loop20	10.1.1.1/32	Switch E	Vlan-int104	10.110.4.2/24

Configuration procedure

1. Assign an IP address and subnet mask to each interface according to Figure 5. (Details not shown.)

2. Configure OSPF on the switches in the PIM-SM domain. (Details not shown.)

3. Enable IP multicast routing, IGMP, and PIM-SM:

# On Switch B, enable IP multicast routing.

<SwitchB> system-view

[SwitchB] multicast routing

[SwitchB-mrib] quit

# Enable IGMP on the receiver-side interface (VLAN-interface 100).

[SwitchB] interface vlan-interface 100

[SwitchB-Vlan-interface100] igmp enable

[SwitchB-Vlan-interface100] quit

# Enable PIM-SM on the other interfaces.

[SwitchB] interface vlan-interface 103

[SwitchB-Vlan-interface103] pim sm

[SwitchB-Vlan-interface103] quit

[SwitchB] interface Vlan-interface 101

[SwitchB-Vlan-interface101] pim sm

[SwitchB-Vlan-interface101] quit

[SwitchB] interface loopback 0

[SwitchB-LoopBack0] pim sm

[SwitchB-LoopBack0] quit

[SwitchB] interface loopback 10

[SwitchB-LoopBack10] pim sm

[SwitchB-LoopBack10] quit

[SwitchB] interface loopback 20

[SwitchB-LoopBack20] pim sm

[SwitchB-LoopBack20] quit

# Enable IP multicast routing, IGMP, and PIM-SM on Switch A, Switch C, Switch D, and Switch E in the same way Switch B is configured. (Details not shown.)

4. Configure C-BSRs and C-RPs:

# Configure Loopback 10 as a C-BSR and Loopback 20 as a C-RP on Switch B.

[SwitchB] pim

[SwitchB-pim] c-bsr 3.3.3.3

[SwitchB-pim] c-rp 10.1.1.1

[SwitchB-pim] quit

# Configure a C-BSR and a C-RP on Switch D in the same way Switch B is configured. (Details not shown.)

5. Configure MSDP peers:

# Configure an MSDP peer on Loopback 0 of Switch B.

[SwitchB] msdp

[SwitchB-msdp] originating-rp loopback 0

[SwitchB-msdp] peer 2.2.2.2 connect-interface loopback 0

[SwitchB-msdp] quit

# Configure an MSDP peer on Loopback 0 of Switch D.

[SwitchD] msdp

[SwitchD-msdp] originating-rp loopback 0

[SwitchD-msdp] peer 1.1.1.1 connect-interface loopback 0

[SwitchD-msdp] quit

Verifying the configuration

1. Verify that the MSDP peer configurations are correct.

# Display brief information about MSDP peers on Switch B.

[SwitchB] display msdp brief

Configured Established Listen Connect Shutdown Disabled

1 1 0 0 0 0

Peer address State Up/Down time AS SA count Reset count

2.2.2.2 Established 00:10:57 ? 0 0

# Display brief information about MSDP peers on Switch D.

[SwitchD] display msdp brief

Configured Established Listen Connect Shutdown Disabled

1 1 0 0 0 0

Peer address State Up/Down time AS SA count Reset count

1.1.1.1 Established 00:10:57 ? 0 0

2. Verify that Switch B acts as the RP for Source 1 and Host A.

# Send an IGMP report from Host A to join multicast group 225.1.1.1. (Details not shown.)

# Send multicast data from Source 1 to the multicast group. (Details not shown.)

# Display the PIM routing table on Switch B.

[SwitchB] display pim routing-table

Total 1 (*, G) entry; 1 (S, G) entry

(*, 225.1.1.1)

RP: 10.1.1.1 (local)

Protocol: pim-sm, Flag: WC

UpTime: 00:15:04

Upstream interface: Register

Upstream neighbor: NULL

RPF prime neighbor: NULL

Downstream interface(s) information:

Total number of downstreams: 1

1: Vlan-interface100

Protocol: igmp, UpTime: 00:15:04, Expires: -

(10.110.5.100, 225.1.1.1)

RP: 10.1.1.1 (local)

Protocol: pim-sm, Flag: SPT 2MSDP ACT

UpTime: 00:46:28

Upstream interface: Vlan-interface103

Upstream neighbor: 10.110.2.2

RPF prime neighbor: 10.110.2.2

Downstream interface(s) information:

Total number of downstreams: 1

1: Vlan-interface100

Protocol: pim-sm, UpTime: - , Expires: -

# Display the PIM routing table on Switch D.

[SwitchD] display pim routing-table

No information is output on Switch D.

3. Verify that Switch D acts as the RP for Source 2 and Host B.

# Send an IGMP leave message and an IGMP report to multicast group 225.1.1.1 from Host A and Host B, respectively. (Details not shown.)

# Send multicast data from Source 2 to the multicast group. (Details not shown.)

# Display the PIM routing table on Switch B.

[SwitchB] display pim routing-table

No information is output on Switch B.

# Display the PIM routing table on Switch D.

[SwitchD] display pim routing-table

Total 1 (*, G) entry; 1 (S, G) entry

(*, 225.1.1.1)

RP: 10.1.1.1 (local)

Protocol: pim-sm, Flag: WC

UpTime: 00:12:07

Upstream interface: Register

Upstream neighbor: NULL

RPF prime neighbor: NULL

Downstream interface(s) information:

Total number of downstreams: 1

1: Vlan-interface200

Protocol: igmp, UpTime: 00:12:07, Expires: -

(10.110.6.100, 225.1.1.1)

RP: 10.1.1.1 (local)

Protocol: pim-sm, Flag: SPT 2MSDP ACT

UpTime: 00:40:22

Upstream interface: Vlan-interface104

Upstream neighbor: 10.110.4.2

RPF prime neighbor: 10.110.4.2

Downstream interface(s) information:

Total number of downstreams: 1

1: Vlan-interface200

Protocol: pim-sm, UpTime: - , Expires: -

SA message filtering configuration

Network requirements

As shown in Figure 6, OSPF runs within and among the PIM-SM domains to provide unicast routing.

Set up an MSDP peering relationship between Switch A and Switch C and between Switch C and Switch D.

Source 1 sends multicast data to multicast groups 225.1.1.0/30 and 226.1.1.0/30, and Source 2 sends multicast data to multicast group 227.1.1.0/30.

Configure SA message policies to meet the following requirements:

· Host A and Host B receive the multicast data only addressed to multicast groups 225.1.1.0/30 and 226.1.1.0/30.

· Host C receives the multicast data only addressed to multicast groups 226.1.1.0/30 and 227.1.1.0/30.

Figure 6 Network diagram

Table 3 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
Source 1	—	10.110.3.100/24	Switch C	Vlan-int300	10.110.4.1/24
Source 2	—	10.110.6.100/24	Switch C	Vlan-int104	10.110.5.1/24
Switch A	Vlan-int100	10.110.1.1/24	Switch C	Vlan-int101	192.168.1.2/24
Switch A	Vlan-int102	10.110.2.1/24	Switch C	Vlan-int103	192.168.2.2/24
Switch A	Vlan-int101	192.168.1.1/24	Switch C	Loop0	2.2.2.2/32
Switch A	Loop0	1.1.1.1/32	Switch D	Vlan-int400	10.110.6.1/24
Switch B	Vlan-int200	10.110.3.1/24	Switch D	Vlan-int500	10.110.7.1/24
Switch B	Vlan-int102	10.110.2.2/24	Switch D	Vlan-int104	10.110.5.2/24
Switch B	Vlan-int103	192.168.2.1/24	Switch D	Loop0	3.3.3.3/32

Configuration procedure

1. Assign an IP address and subnet mask to each interface according to Figure 6. (Details not shown.)

2. Configure OSPF on the switches in the PIM-SM domains. (Details not shown.)

3. Enable IP multicast routing, IGMP, and PIM-SM, and configure a PIM domain border:

# On Switch A, enable IP multicast routing.

<SwitchA> system-view

[SwitchA] multicast routing

[SwitchA-mrib] quit

# Enable IGMP on the receiver-side interface (VLAN-interface 100).

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] igmp enable

[SwitchA-Vlan-interface100] quit

# Enable PIM-SM on the other interfaces.

[SwitchA] interface vlan-interface 101

[SwitchA-Vlan-interface101] pim sm

[SwitchA-Vlan-interface101] quit

[SwitchA] interface vlan-interface 102

[SwitchA-Vlan-interface102] pim sm

[SwitchA-Vlan-interface102] quit

[SwitchA] interface loopback 0

[SwitchA-LoopBack0] pim sm

[SwitchA-LoopBack0] quit

# Enable IP multicast routing, IGMP, and PIM-SM on Switch B, Switch C, and Switch D in the same way Switch A is configured. (Details not shown.)

# Configure a PIM domain border on Switch C.

[SwitchC] interface vlan-interface 101

[SwitchC-Vlan-interface101] pim bsr-boundary

[SwitchC-Vlan-interface101] quit

[SwitchC] interface vlan-interface 103

[SwitchC-Vlan-interface103] pim bsr-boundary

[SwitchC-Vlan-interface103] quit

[SwitchC] interface vlan-interface 104

[SwitchC-Vlan-interface104] pim bsr-boundary

[SwitchC-Vlan-interface104] quit

# Configure PIM domain borders on Switch A, Switch B, and Switch D in the same way Switch C is configured. (Details not shown.)

4. Configure C-BSRs and C-RPs:

# Configure Loopback 0 as a C-BSR and a C-RP on Switch A.

[SwitchA] pim

[SwitchA-pim] c-bsr 1.1.1.1

[SwitchA-pim] c-rp 1.1.1.1

[SwitchA-pim] quit

# Configure C-BSRs and C-RPs on Switch C and Switch D in the same way Switch A is configured. (Details not shown.)

5. Configure MSDP peers:

# Configure an MSDP peer on Switch A.

[SwitchA] msdp

[SwitchA-msdp] peer 192.168.1.2 connect-interface vlan-interface 101

[SwitchA-msdp] quit

# Configure MSDP peers on Switch C.

[SwitchC] msdp

[SwitchC-msdp] peer 192.168.1.1 connect-interface vlan-interface 101

[SwitchC-msdp] peer 10.110.5.2 connect-interface vlan-interface 104

[SwitchC-msdp] quit

# Configure an MSDP peer on Switch D.

[SwitchD] msdp

[SwitchD-msdp] peer 10.110.5.1 connect-interface vlan-interface 104

[SwitchD-msdp] quit

6. Configure SA message policies:

# Configure an SA accepting and forwarding policy on Switch C so that Switch C will not forward SA messages for (Source 1, 225.1.1.0/30) to Switch D.

[SwitchC] acl number 3001

[SwitchC-acl-adv-3001] rule deny ip source 10.110.3.100 0 destination 225.1.1.0 0.0.0.3

[SwitchC-acl-adv-3001] rule permit ip source any destination any

[SwitchC-acl-adv-3001] quit

[SwitchC] msdp

[SwitchC-msdp] peer 10.110.5.2 sa-policy export acl 3001

[SwitchC-msdp] quit

# Configure an SA creation policy on Switch D so that Switch D will not create SA messages for Source 2.

[SwitchD] acl number 2001

[SwitchD-acl-basic-2001] rule deny source 10.110.6.100 0

[SwitchD-acl-basic-2001] quit

[SwitchD] msdp

[SwitchD-msdp] import-source acl 2001

[SwitchD-msdp] quit

Verifying the configuration

# Display the (S, G) entries in the SA message cache on Switch C.

[SwitchC] display msdp sa-cache

MSDP Total Source-Active Cache - 8 entries

Matched 8 entries

Source Group Origin RP Pro AS Uptime Expires

10.110.3.100 225.1.1.0 1.1.1.1 ? ? 02:03:30 00:05:31

10.110.3.100 225.1.1.1 1.1.1.1 ? ? 02:03:30 00:05:31

10.110.3.100 225.1.1.2 1.1.1.1 ? ? 02:03:30 00:05:31

10.110.3.100 225.1.1.3 1.1.1.1 ? ? 02:03:30 00:05:31

10.110.3.100 226.1.1.0 1.1.1.1 ? ? 02:03:30 00:05:31

10.110.3.100 226.1.1.1 1.1.1.1 ? ? 02:03:30 00:05:31

10.110.3.100 226.1.1.2 1.1.1.1 ? ? 02:03:30 00:05:31

10.110.3.100 226.1.1.3 1.1.1.1 ? ? 02:03:30 00:05:31

# Display the (S, G) entries in the SA message cache on Switch D.

[SwitchD] display msdp sa-cache

MSDP Total Source-Active Cache - 4 entries

Matched 4 entries

Source Group Origin RP Pro AS Uptime Expires

10.110.3.100 226.1.1.0 1.1.1.1 ? ? 00:32:53 00:05:07

10.110.3.100 226.1.1.1 1.1.1.1 ? ? 00:32:53 00:05:07

10.110.3.100 226.1.1.2 1.1.1.1 ? ? 00:32:53 00:05:07

10.110.3.100 226.1.1.3 1.1.1.1 ? ? 00:32:53 00:05:07

Troubleshooting MSDP

This section describes common MSDP problems and how to troubleshoot them.

MSDP peers stay in disabled state

Symptom

The configured MSDP peers stay in disabled state.

Solution

To resolve the problem:

1. Use the display ip routing-table command to verify that the unicast route between the routers is reachable.

2. Verify that a unicast route is available between the two routers that will become MSDP peers to each other.

3. Use the display current-configuration command to verify that the local interface address and the MSDP peer address of the remote router are the same.

4. If the problem persists, contact H3C Support.

No SA entries exist in the router's SA message cache

Symptom

MSDP fails to send (S, G) entries through SA messages.

Solution

To resolve the problem:

1. Use the display ip routing-table command to verify that the unicast route between the routers is reachable.

2. Verify that a unicast route is available between the two routers that will become MSDP peers to each other.

3. Verify the configuration of the import-source command and its acl-number argument, and make sure the ACL rule filters appropriate (S, G) entries.

4. If the problem persists, contact H3C Support.

No exchange of locally registered (S, G) entries between RPs

Symptom

RPs fail to exchange their locally registered (S, G) entries with one another in the Anycast RP application.

Solution

To resolve the problem:

1. Use the display ip routing-table command to verify that the unicast route between the routers is reachable.

2. Verify that a unicast route is available between the two routers that will establish an MSDP peering relationship.

3. Verify the configuration of the originating-rp command. In the Anycast RP application environment, use the originating-rp command to configure the RP address in the SA messages, which must be the local interface address.

4. Verify that the C-BSR address is different from the Anycast RP address.

5. If the problem persists, contact H3C Support.

06-IP Multicast Configuration Guide

Overview

MSDP peers

Inter-domain multicast delivery through MSDP

Anycast RP through MSDP

MSDP support for VPNs

MSDP configuration task list

Configuring basic MSDP features

Enabling MSDP

Creating an MSDP peering connection

Configuring a static RPF peer

Configuring an MSDP peering connection

Configuring a description for an MSDP peer

Configuring an MSDP mesh group

Controlling MSDP peering connections

Configuring SA message-related parameters

Configuring SA message contents

Configuring SA request messages

Configuring SA message policies

Configuring the SA cache mechanism

Displaying and maintaining MSDP

MSDP configuration examples

Network requirements

Configuration procedure

Verifying the configuration

Anycast RP configuration

Network requirements

Configuration procedure

Verifying the configuration

Network requirements

Configuration procedure

Verifying the configuration

Symptom

Solution

Symptom

Solution

Symptom

Solution

Cloud & AI

InterConnect

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Resources

Partner Business Management

Company Information

News & Events

Contact Us