Table of Contents

Chapter 1 MSDP Configuration. 1-1

1.1 MSTP Overview. 1-1

1.1.1 Introduction to MSDP. 1-1

1.1.2 How MSDP Works. 1-2

1.1.3 MSDP Related Protocols and Standards. 1-8

1.2 MSDP Configuration Task List 1-8

1.3 Configuring Basic Functions of MSDP. 1-9

1.3.1 Configuration Prerequisites. 1-9

1.3.2 Enabling MSDP. 1-10

1.3.3 Creating an MSDP Peer Connection. 1-10

1.3.4 Configuring a Static RPF Peer 1-10

1.4 Configuring an MSDP Peer Connection. 1-11

1.4.1 Configuration Prerequisites. 1-11

1.4.2 Configuring MSDP Peer Description. 1-12

1.4.3 Configuring an MSDP Mesh Group. 1-12

1.4.4 Configuring MSDP Peer Connection Control 1-13

1.5 Configuring SA Messages Related Parameters. 1-14

1.5.1 Configuration Prerequisites. 1-14

1.5.2 Configuring SA Message Content 1-14

1.5.3 Configuring SA Request Messages. 1-15

1.5.4 Configuring an SA Message Filtering Rule. 1-16

1.5.5 Configuring SA Message Cache. 1-17

1.6 Displaying and Maintaining MSDP. 1-18

1.7 MSDP Configuration Examples. 1-18

1.7.1 Example of Configuration Leveraging BGP Routes. 1-18

1.7.2 Example of Anycast RP Application Configuration. 1-24

1.7.3 Static RPF Peer Configuration Example. 1-28

1.8 Troubleshooting MSDP. 1-32

1.8.1 MSDP Peers Stay in Down State. 1-32

1.8.2 No SA Entries in the Device’s SA Cache. 1-33

1.8.3 Inter-RP Communication Faults in Anycast RP Application. 1-33

 

Chapter 1  MSDP Configuration

When configuring MSDP, go to these sections for information you are interested in:

l           MSTP Overview

l           Configuring Basic Functions of MSDP

l           Configuring an MSDP Peer Connection

l           Configuring SA Messages Related Parameters

l           Displaying and Maintaining MSDP

l           MSDP Configuration Examples

l           Troubleshooting MSDP

 

 

1.1  MSTP Overview

1.1.1  Introduction to MSDP

Multicast source discovery protocol (MSDP) is an inter-domain multicast solution developed to address the interconnection of protocol independent multicast sparse mode (PIM-SM) domains. It is used to discover 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 of a domain is isolated from that of another domain. As a result, the RP is aware of the source information only within the local domain and a multicast distribution tree is built only within the local domain to deliver multicast data from a local multicast source to local receivers. If there is a mechanism that allows RPs of different PIM-SM domains to share their multicast source information, the local RP will be able to join multicast sources in other domains and multicast data can be transmitted among different domains.

MSDP achieves this objective. By establishing MSDP peer relationships among RPs of different PIM-SM domains, source active (SA) messages can be forwarded among domains and the multicast source information can be shared.

 

 

1.1.2  How MSDP Works

I. MSDP peers

As shown in Figure 1-1, an active multicast source (Source) exists in the domain PIM-SM 1, and RP 1 has learned the existence of Source through multicast source registration. If receiver hosts in PIM-SM 2 and PIM-SM 3 also wish to receive multicast data from Source, the RPs in these domains can learn the location of Source by establishing MSDP peering relationships. MSDP peering relationships can be established among RPs of different or the same PIM-SM domain, between RPs and multicast routers, or even between multicast routers.

With one or more pairs of MSDP peers configured in the network, an MSDP interconnection map is formed, where the RPs of different PIM-SM domains are interconnected in series. Relayed by these MSDP peers, an SA message sent by an RP can be delivered to RPs in other domains.

Figure 1-1 Where MSDP peers are in the network

The blue lines in Figure 1-1 interconnect MSDP peers. MSDP peers created on PIM-SM routers that assume different roles function differently.

1)         MSDP peers on RPs

l           Source-side MSDP peer: the MSDP peer nearest to the multicast source (Source), typically the source-side RP, like RP 1 in Figure 1-1. The source-side RP creates SA messages and sends the messages to its remote MSDP peer to notify the MSDP peer of the locally registered multicast source information. A source-side MSDP must be created on the source-side RP; otherwise it will not be able to advertise the multicast source information out of the PIM-SM domain.

l           Receiver-side MSDP peer: the MSDP peer nearest to the receivers, typically the source-side RP, like RP 3 in Figure 1-1. Upon receiving an SA message, the receiver-side MSDP peer resolves the multicast source information carried in the message and joins the SPT rooted at the source across the PIM-SM domain. When multicast data from the multicast source arrives, the receiver-side MSDP peer forwards the data to the receivers along the RPT.

l           Intermediate MSDP peer: an MSDP peer with multicast remote MSDP peers, like RP 2 in Figure 1-1. An intermediate MSDP peer forwards SA messages received from one remote MSDP peer to other remote MSDP peers, functioning as a relay of multicast source information.

2)         MSDP peers created on common multicast routers (other than RPs)

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

 

 

II. Implementing inter-domain multicast delivery by leveraging MSDP peers

As shown in Figure 1-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. If RPs in PIM-SM 2 and PIM-SM 3 also wish to know the specific location of Source so that receiver hosts can receive multicast traffic originated from it, MSDP peering relationships should be established between RP 1 and RP 3 and between RP 3 and RP 2 respectively.

Figure 1-2 MSDP peering relationships

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

1)         When the multicast source in PIM-SM 1 sends the first multicast packet to multicast group G, DR 1 encapsulates the multicast data within a register message and sends the register message to RP 1. Then, RP 1 gets aware of the information related to the multicast source.

2)         As the source-side RP, RP 1 creates SA messages and periodically sends the SA messages to its MSDP peer. An SA message contains the source address (S), the multicast group address (G), and the address of the RP which has created this SA message (namely RP 1).

3)         On MSDP peers, each SA message is subject to a reverse path forwarding (RPF) check and multicast policy–based filtering, so that 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, you can configure MSDP peers into an MSDP mesh group so as to avoid flooding of SA messages between MSDP peers.

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

5)         Upon receiving the SA message create by RP 1, RP 2 in PIM-SM 2 checks whether there are any receivers for the multicast group in the domain.

l           If so, 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 hop by hop towards DR 1 at the multicast source side, so that it can directly join the SPT rooted at the source over other PIM-SM domains. Then, the multicast data can flow along the SPT to RP 2 and is forwarded by RP 2 to the receivers along the RPT. Upon receiving the multicast traffic, the DR at the receiver side (DR 2) decides whether to initiate an RPT-to-SPT switchover process.

l           If no receivers for the group exist in the domain, RP 2 does dot create an (S, G) entry and does join the SPT rooted at the source.

 

 

III. RPF check rules for SA messages

As shown in Figure 1-3, there are five autonomous systems in the network, AS 1 through AS 5, with IGP enabled on routers within each AS and BGP as the interoperation protocol among different ASs. Each AS contains at least one PIM-SM domain and each PIM-SM domain contains one ore more RPs. MSDP peering relationships have been established among different RPs. RP 3, RP 4 and RP 5 are in an MSDP mesh group. On RP 7, RP 6 is configured as its static RPF peer.

 

 

Figure 1-3 Diagram for RPF check for SA messages

As illustrated in Figure 1-3, these MSDP peers dispose of SA messages according to the following RPF check rules:

1)         When RP 2 receives an SA message from RP 1

Because the source-side RP address carried in the SA message is the same as the MSDP peer address, which means that the MSDP peer where the SA is from is the RP that has created the SA message, RP 2 accepts the SA message and forwards it to its other MSDP peer (RP 3).

2)         When RP 3 receives the SA message from RP 2

Because the SA message is from an MSDP peer (RP 2) in the same AS, and the MSDP peer is the next hop on the optimal path to the source-side RP, RP 3 accepts the message and forwards it to other peers (RP 4 and RP 5).

3)         When RP 4 and RP 5 receive the SA message from RP 3

Because the SA message is from an MSDP peer (RP 3) in the same mesh group, RP 4 and RP 5 both accept the SA message, but they do not forward the message to other members in the mesh group; instead, they forward it to other MSDP peers (RP 6 in this example) out of the mesh group.

4)         When RP 6 receives the SA messages from RP 4 and RP 5 (suppose RP 5 has a higher IP address)

Although RP 4 and RP 5 are in the same SA (AS 3) and both are MSDP peers of RP 6, because RP 5 has a higher IP address, RP 6 accepts only the SA message from RP 5.

5)         When RP 7 receives the SA message from RP 6

Because the SA message is from a static RPF peer (RP 6), RP 7 accepts the SA message and forwards it to other peer (RP 8).

6)         When RP 8 receives the SA message from RP 7

A BGP route exists between two MSDP peers in different ASs. Because the SA message is from an MSDP peer (RP 7) in a different AS, and the MSDP peer is the next hop on the BGP route to the source-side RP, RP 8 accepts the message and forwards it to its other peer (RP 9).

7)         When RP 9 receives the SA message from RP 8

Because RP 9 has only one MSDP peer, RP 9 accepts the SA message.

SA messages from other paths than described above will not be accepted nor forwarded by MSDP peers.

IV. Implementing intra-domain Anycast RP by leveraging MSDP peers

Anycast RP refers to such an application that enables load balancing and redundancy backup between two or more RPs within a PIM-SM domain by configuring the same IP address for, and establishing MSDP peering relationships between, these RPs.

As shown in Figure 1-4, within the same PIM-SM domain, a multicast source sends multicast data to multicast group G, and Receiver is a member of the multicast group. To implement Anycast RP, configure the same IP address (known as anycast RP address, typically a private address) on Router A and Router B, configure these interfaces as C-RPs, and establish an MSDP peering relationship between Router A and Router B.

 

 

Figure 1-4 Typical network diagram of Anycast RP

The work process of Anycast RP is as follows:

1)         The multicast source registers with the nearest RP. In this example, Source registers with RP 1, with its multicast data encapsulated in the register message. When the register message arrives at RP 1, RP 1 decapsulates the message.

2)         Receivers send join messages to the nearest RP to join in the RPT rooted as this RP. In this example, Receiver joins the RPT rooted at RP 2.

3)         RPs share the registered multicast information by means of SA messages. In this example, RP 1 creates an SA message and sends it to RP 2, with the multicast data from Source encapsulated in the SA message. When the SA message reaches RP 2, RP 2 decapsulates the message.

4)         Receivers receive the multicast data along the RPT and directly join the SPT rooted at the multicast source. In this example, RP 2 forwards the multicast data down the RPT. When Receiver receives the multicast data from Source, it directly joins the SPT rooted at Source.

The significance of Anycast RP is as follows:

l           Optimal RP path: A multicast source registers with the nearest RP so that an SPT with the optimal path is built; a receiver joins the nearest RP so that an RPT with the optimal path is built.

l           Load balancing between RPs: Each RP just needs to maintain part of the source/group information within the PIM-SM domain and forward part of the multicast data, thus achieving load balancing between different RPs.

l           Redundancy backup between RPs: When an RP fails, the multicast source previously registered on it or the receivers previous joined it will register with or join another nearest RP, thus achieving redundancy backup between RPs.

 

 

1.1.3  MSDP Related Protocols and Standards

MSDP is documented in the following specifications:

l           RFC 3618: Multicast Source Discovery Protocol (MSDP)

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

1.2  MSDP Configuration Task List

Complete these tasks to configure MSDP:

Task		Remarks
Configuring Basic Functions of MSDP	Enabling MSDP	Required
	Creating an MSDP Peer Connection	Required
	Configuring a Static RPF Peer	Optional
Configuring an MSDP Peer Connection	Configuring MSDP Peer Description	Optional
	Configuring an MSDP Mesh Group	Optional
	Configuring MSDP Peer Connection Control	Optional
Configuring SA Messages Related Parameters	Configuring SA Message Content	Optional
	Configuring SA Request Messages	Optional
	Configuring an SA Message Filtering Rule	Optional
	Configuring SA Message Cache	Optional

 

1.3  Configuring Basic Functions of MSDP

 

 

1.3.1  Configuration Prerequisites

Before configuring the basic functions of MSDP, complete the following tasks:

l           Configure any unicast routing protocol so that all devices in the domain are interoperable at the network layer.

l           Configuring the basic functions of PIM-SM to enable intra-domain multicast forwarding.

Before configuring the basic functions of MSDP, prepare the following data:

l           IP addresses of MSDP peers

l           Address prefix list for an RP address filtering policy

1.3.2  Enabling MSDP

Follow these steps to enable MSDP:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enable IP multicast routing	multicast routing-enable	Required Disabled by default
Enable MSDP and enter MSDP view	msdp	Required Disabled by default

 

1.3.3  Creating an MSDP Peer Connection

An MSDP peering relationship is identified by an address pair, namely the address of the local MSDP peer and that of the remote MSDP peer. An MSDP peer connection must be created on both devices that are a pairs of MSDP peers.

Follow these steps to create an MSDP peer connection:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter MSDP view	msdp	—
Create an MSDP peer connection	peer peer-address connect-interface interface-type interface-number	Required No MSDP peer connection created by default

 

 

1.3.4  Configuring a Static RPF Peer

Configuring static RPF peers avoids RPF check of SA messages.

Follow these steps to configure a static RPF peer:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter MSDP view	msdp	—
Configure a static RPF peer	static-rpf-peer peer-address [ rp-policy ip-prefix-name ]	Required No static RPF peer configured by default

 

When configuring multiple static RPF peers on the same device, observe the following rules:

l           If you use the rp-policy keyword for all the static RPF peers, all the static RPF peers will be activated concurrently. SA messages will be filtered as per the configured prefix list and only those SA messages whose RP addresses pass the filtering will be accepted. If multiple static RPF peers use the same filtering policy at the same time, when a peer receives an SA message, it will forward the SA message to the other peers.

l           If you use the rp-policy keyword for none of the static RPF peers, according to the configuration sequence, only the first static RPF peer whose connection is in the UP state will be activated, and all SA messages from this peer will be accepted while the SA messages from other static RPF peers will be discarded. When this active static RPF peer fails (for example, when the configuration is removed or when the connection is torn down), based on the configuration sequence, the next RPF peer with its connection in the UP state will be selected as the activated RPF peer.

 

 

1.4  Configuring an MSDP Peer Connection

1.4.1  Configuration Prerequisites

Before configuring MSDP peer connection, complete the following tasks:

l           Configure any unicast routing protocol so that all devices in the domain are interoperable at the network layer.

l           Configuring basic functions of MSDP

Before configuring an MSDP peer connection, prepare the following data:

l           Description information of MSDP peers

l           Name of an MSDP mesh group

l           MSDP peer connection retry interval

1.4.2  Configuring MSDP Peer Description

With the MSDP peer description information, the administrator can easily distinguish different MSDP peers and thus better manage MSDP peers.

Follow these steps to configure description for an MSDP peer:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter MSDP view	msdp	—
Configure description for an MSDP peer	peer peer-address description text	Required No description for MSDP peers by default

 

1.4.3  Configuring an MSDP Mesh Group

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

On one hand, an MSDP peer in an MSDP mesh group forwards SA messages from outside the mesh group that have passed the RPF check to the other members in the mesh group; on the other hand, a mesh group member accepts SA messages from inside the group without performing an RPF check, and does not forward the message within the mesh group either. This mechanism not only avoids SA flooding but also simplifies the RPF check mechanism, because BGP is not needed to run between these MSDP peers.

By configuring the same mesh group name for multiple MSDP peers, you can create a mesh group with these MSDP peers.

Follow these steps to create an MSDP mesh group:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter MSDP view	msdp	—
Create an MSDP peer as a mesh group member	peer peer-address mesh-group name	Required An MSDP peer does not belong to any mesh group by default

 

 

1.4.4  Configuring MSDP Peer Connection Control

MSDP peers are interconnected over TCP. You can flexibly control sessions between MSDP peers by manually deactivating and reactivating the MSDP peering connections. When the connection between two MSDP peers is deactivated, SA messages will no longer be delivered between them, and the TCP connection is closed without any connection setup retry, but the configuration information will remain unchanged.

When a new MSDP peer is created, or when a previously deactivated MSDP peer connection is reactivated, or when a previously failed MSDP peer attempts to resume operation, a TCP connection is required. You can flexibly adjust the interval between MSDP peering connection retries.

Follow these steps to configure MSDP peer connection control:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter MSDP view	msdp	—-
Deactivate an MSDP peer	shutdown peer-address	Optional Active by default
Configure the interval between MSDP peer connection retries	timer retry interval	Optional 30 seconds by default

 

1.5  Configuring SA Messages Related Parameters

1.5.1  Configuration Prerequisites

Before configuring SA message related parameters, complete the following tasks:

l           Configure any unicast routing protocol so that all devices in the domain are interoperable at the network layer.

l           Configuring basic functions of MSDP

Before configuring SA message related parameters, prepare the following data:

l           ACL as a filtering rule for SA request messages

l           ACL as an SA message creation rule

l           ACL as a filtering rule for receiving or forwarding SA messages

l           Time-to-live (TTL) threshold for multicast packet encapsulation in SA messages

l           Maximum number of (S, G) entries learned from the specified MSDP peer that the router can cache

1.5.2  Configuring SA Message Content

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 has to 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 joins the source-side DR and builds an SPT. Since the (S, G) entries have timed out, remote receivers can never receive the multicast data from the multicast source.

If the source-side RP is enabled to encapsulate register messages in SA messages, when there is a multicast packet to deliver, the source-side RP encapsulates a register message containing the multicast packet in an SA message and sends it out. After receiving the SA message, the remote RP decapsulates the SA message and delivers the multicast data contained in the register message to the receivers along the RPT.

The MSDP peers deliver SA messages to one another. Upon receiving an SA message, a device performs RPF check on the message. If the device finds that the remote RP address is the same as the local RP address, it will discard the SA message. In the Anycast RP application, however, you need to configure RPs with the same IP address on two or more devices in the same PIM-SM domain, and configure these devices as MSDP peers to one another. Therefore, a logic RP address (namely the RP address on the logic interface) that is different from the actual RP address must be designated for SA messages so that the messages can pass the RPF check.

Follow these steps to configure the SA message content:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter MSDP view	msdp	—
Enable encapsulation of a registration message	encap-data-enable	Optional Disabled by default
Configure the interface address as the RP address in SA messages	originating-rp interface-type interface-number	Optional PIM RP address by default

 

1.5.3  Configuring SA Request Messages

By default, upon receiving a new Join message, a device does not send an SA request message to its designated 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. To enable a new receiver to get the currently active multicast source information as early as possible, you can configure devices to send SA request messages to the designated MSDP peers upon receiving a Join message of a new receiver.

Follow these steps to configure SA message transmission and filtering:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter MSDP view	msdp	—
Enable sending SA request messages	peer peer-address request-sa-enable	Optional Disabled by default
Configure a filtering rule for SA request messages	peer peer-address sa-request-policy [ acl acl-number ]	Optional SA request messages are not filtered by default

 

 

 

1.5.4  Configuring an SA Message Filtering Rule

By configuring an SA message creation rule, you can enable the router to filter the (S, G) entries to be advertised when creating an SA message, so that the propagation of messages of multicast sources is controlled.

By configuring a filtering rule for receiving or forwarding SA messages, you can enable the router to filter the (S, G) forwarding entries to be advertised when receiving or forwarding an SA message, so that the propagation of multicast source information is controlled at SA message reception or forwarding.

By configuring a TTL threshold for multicast data packet encapsulation in SA messages, you can control the multicast data packet encapsulation in SA messages and limit the propagation range of SA messages:

l           Before creating an SA message with an encapsulated multicast data packet, the router checks the TTL value of the multicast data packet. If the TTL value is less than the threshold, the router does not create an SA message; if the TTL value is greater than or equal to the threshold, the router encapsulates the multicast data in an SA message and sends the SA message out.

l           Upon receiving an SA message with an encapsulated multicast data packet, the router decrements the TTL value of the multicast packet by 1 and then checks the TTL value. If the TTL value is less than the threshold, the router does not forward the SA message to the designated MSDP peer; if the TTL value is greater than or equal to the threshold, the router re-encapsulates the multicast data in an SA message and sends the SA message out.

Follow these steps to configure a filtering rule for receiving or forwarding SA messages:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter MSDP view	msdp	—
Configuring an SA message creation rule	import-source [ acl acl-number ]	Required No restrictions on (S, G) entries by default
Configure a filtering rule for receiving or forwarding SA messages	peer peer-address sa-policy { import | export } [ acl acl-number ]	Required No filtering rule by default
Configure the TTL threshold for multicast data packet encapsulation in SA messages	peer peer-address minimum-ttl ttl-value	Optional 0 by default

 

1.5.5  Configuring SA Message Cache

To reduce the time spent in obtaining the multicast information, you can enable the SA cache mechanism to cache (S, G) entries contained in SA messages locally on the router. However, the more (S, G) entries are cached, the larger memory space of the router is used.

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

l           If the corresponding (S, G) entry does not exist in the cache, the router waits for the SA message its MSDP peer will send in the next cycle;

l           If the corresponding (S, G) entry exists in the cache, the router joins the corresponding SPT rooted at S.

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

Follow these steps to configure the SA message cache:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter MSDP view	msdp	—
Enable the SA message cache mechanism	cache-sa-enable	Required Enabled by default
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	Required 8192 by default

 

1.6  Displaying and Maintaining MSDP

To do...	Use the command...	Remarks
View the brief information of MSDP peers status	display msdp brief	Available in any view
View the detailed information about the status of MSDP peers	display msdp peer-status [ peer-address ]	Available in any view
View the (S, G) entry information in the SA cache	display msdp sa-cache [ group-address | source-address | as-number ] *	Available in any view
View the number of (S, G) entries in the SA cache	display msdp sa-count [ as-number ]	Available in any view
Reset the TCP connection with an MSDP peer	reset msdp peer [ peer-address ]	Available in user view
Clear (S, G) entries in the SA cache	reset msdp sa-cache [ group-address ]	Available in user view
Clear all statistics information of an MSDP peer	reset msdp statistics [ peer-address ]	Available in user view

 

1.7  MSDP Configuration Examples

1.7.1  Example of Configuration Leveraging BGP Routes

I. Network requirements

l           Two ISPs maintains their ASs, AS 100 and AS 200 respectively. OSPF is running within each AS, and BGP is running between the two ASs.

l           PIM-SM 1 belongs to AS 100, while PIM-SM 2 and PIM-SM 3 belong to AS 200.

l           Each PIM-SM domain has zero or one multicast source and one or more receivers. OSPF runs within each domain to provide unicast routes.

l           MSDP peering relationships need to be established among RPs of different PIM-SM domains leveraging BGP routes.

l           The respective Loopback 0 interfaces of Switch C, Switch D and Switch F are configured as the C-BSR and C-RP of the respective PIM-SM domains.

l           An MSDP peering relationship needs to be established between Switch C and Switch D through BGP, and an MSDP peering relationship needs to be established between Switch D and Switch F through IBGP.

II. Network diagram

Device	Interface	IP address	Device	Interface	IP address
Switch C	Vlan-int100	10.110.1.1/24	Switch D	Vlan-int300	10.110.4.1/24
	Vlan-int200	10.110.2.1/24		Vlan-int102	192.168.3.1/24
	Vlan-int101	192.168.1.1/24		Vlan-int101	192.168.1.2/24
	Loop0	1.1.1.1/32		Loop0	2.2.2.2/32
Switch F	Vlan-int400	10.110.3.1/24
	Vlan-int102	192.168.3.2/24
	Loop0	3.3.3.3/32

Figure 1-5 Network diagram for configuration leveraging a BGP route

III. Configuration procedure

 

 

1)         Configure IP addresses and unicast routing

Configure the IP address and subnet mask for each interface as per Figure 1-5. Detailed configuration steps are omitted.

Configure OSPF for interconnection between devices in each PIM-SM domain. Ensure the network-layer interoperation among Switch A, Switch B and Switch C in PIM-SM 1, the network-layer interoperation between Switch D and Switch E in PIM-SM 2, and the network-layer interoperation between Switch F and Switch G in PIM-SM 3, and ensure the dynamic update of routing information between the devices in each PIM-SM domain through a unicast routing protocol. Detailed configuration steps are omitted.

2)         Enable IP multicast routing, and enable PIM-SM on each interface

# Enable IP multicast routing on Switch C, and enable PIM-SM on each interface.

<SwitchC> system-view

[SwitchC] multicast routing-enable

[SwitchC] interface vlan-interface 100

[SwitchC-Vlan-interface100] pim sm

[SwitchC-Vlan-interface100] quit

[SwitchC] interface vlan-interface 200

[SwitchC-Vlan-interface200] pim sm

[SwitchC-Vlan-interface200] quit

[SwitchC] interface vlan-interface 101

[SwitchC-Vlan-interface101] pim sm

The configuration on Switch A, Switch B, Switch D, Switch E, Switch F and Switch G is similar to the configuration on Switch C.

# Configure BSR boundary on Switch C.

[SwitchC-Vlan-interface101] pim bsr-boundary

[SwitchC-Vlan-interface101] quit

The configuration on Switch D and Switch F is similar to the configuration on Switch C.

3)         Configure C-BSRs and C-RPs

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

[SwitchC] interface loopback 0

[SwitchC-LoopBack0] ip address 1.1.1.1 255.255.255.255

[SwitchC-LoopBack0] pim sm

[SwitchC-LoopBack0] quit

[SwitchC] pim

[SwitchC-pim] c-bsr loopback 0

[SwitchC-pim] c-rp loopback 0

[SwitchC-pim] quit

The configuration on Switch D and Switch F is similar to the configuration on Switch C.

4)         Configure inter-AS BGP and configure mutual route redistribution between BGP and OSPF

# Configure BGP on Switch C, and configure OSPF route redistribution.

[SwitchC] bgp 100

[SwitchC-bgp] router-id 1.1.1.1

[SwitchC-bgp] peer 192.168.1.2 as-number 200

[SwitchC-bgp] import-route ospf 1

[SwitchC-bgp] quit

# Configure IBGP and BGP on Switch D, and configure OSPF route redistribution.

<SwitchD> system-view

[SwitchD] bgp 200

[SwitchD-bgp] router-id 2.2.2.2

[SwitchD-bgp] peer 192.168.1.1 as-number 100

[SwitchD-bgp] peer 192.168.3.2 as-number 200

[SwitchD-bgp] import-route ospf 1

[SwitchD-bgp] quit

# Configure IBGP on Switch F, and configure OSPF route redistribution.

<SwitchF> system-view

[SwitchF] bgp 200

[SwitchF-bgp] router-id 3.3.3.3

[SwitchF-bgp] peer 192.168.3.1 as-number 200

[SwitchF-bgp] import-route ospf 1

[SwitchF-bgp] quit

# Configure BGP route redistribution in OSPF on Switch C.

[SwitchC] ospf 1

[SwitchC-ospf-1] import-route bgp

[SwitchC-ospf-1] quit

The configuration on Switch D and Switch F is similar to the configuration on Switch C.

Use the display bgp peer command to view the BGP peering relationships between the switches. For example:

# View the information about BGP peering relationship on Switch C.

[SwitchC] display bgp peer

 

 BGP local router ID : 1.1.1.1

 Local AS number : 100

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

 

  Peer         V  AS  MsgRcvd  MsgSent  OutQ PrefRcv Up/Down  State

  192.168.1.2  4  200      24       21     0       6 00:13:09 Established

# View the information about BGP peering relationship on Switch D.

[SwitchD] display bgp peer

 

 BGP local router ID : 2.2.2.2

 Local AS number : 200

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

 

  Peer         V  AS  MsgRcvd  MsgSent  OutQ PrefRcv Up/Down  State

  192.168.1.1  4  100      18       16     0       1 00:12:04 Established

  192.168.3.2  4  200      21       20     0       6 00:12:05 Established

# View the information about BGP peering relationships on Switch F.

[SwitchF] display bgp peer

 

BGP local router ID : 3.3.3.3

 Local AS number : 200

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

 

  Peer         V  AS  MsgRcvd  MsgSent  OutQ PrefRcv Up/Down  State

  192.168.3.1  4  200      16       14     0       1 00:10:58 Established

5)         Configure MSDP peers

# Configure an MSDP peer on Switch C.

[SwitchC] msdp

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

[SwitchC-msdp] quit

# Configure an MSDP peer on Switch D.

[SwitchD] msdp

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

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

[SwitchD-msdp] quit

# Configure MSDP peers on Switch F.

[SwitchF] msdp

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

[SwitchF-msdp] quit

When the multicast source (Source 1) sends multicast information, receivers in PIM-SM 2 and PIM-SM 3 can receive the multicast data. You can use the display msdp brief command to view the brief information of MSDP peering relationships between the switches. For example:

# View the brief information about MSDP peering relationship on Switch C.

[SwitchC] display msdp brief

MSDP Peer Brief Information

  Configured   Up           Listen       Connect      Shutdown     Down

  1            1            0            0            0            0

 

  Peer's Address     State     Up/Down time    AS     SA Count   Reset Count

  192.168.1.2        Up        00:12:27       200    13         0

# View the brief information about MSDP peering relationship on Switch D.

[SwitchD] display msdp brief

  Configured   Up           Listen       Connect      Shutdown     Down

  2            2            0            0            0            0

MSDP Peer Brief Information

  Peer's Address     State     Up/Down time    AS     SA Count   Reset Count

  192.168.3.2        Up        00:15:32       200    8          0

  192.168.1.1        Up        00:06:39       100    13         0

# View the brief information about MSDP peering relationships on Switch F.

[SwitchF] display msdp brief

MSDP Peer Brief Information

  Configured   Up           Listen       Connect      Shutdown     Down

  1            1            0            0            0            0

 

  Peer's Address     State     Up/Down time    AS     SA Count   Reset Count

  192.168.3.1        Up        01:07:08       200    8          0

# View the detailed MSDP peer information on Switch C.

[SwitchC] display msdp peer-status

  MSDP Peer 192.168.1.2, AS 200

  Description:

  Information about connection status:

    State: Up

    Up/down time: 00:15:47

    Resets: 0

    Connection interface: Vlan-interface101 (192.168.1.1)

    Number of sent/received messages: 16/16

    Number of discarded output messages: 0

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

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

    Import policy: none

    Export policy: none

  Information about SA-Requests:

    Policy to accept SA-Request messages: 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: none

  Input queue size: 0, Output queue size: 0

  Counters for MSDP message:

    Count of RPF check failure: 0

    Incoming/outgoing SA messages: 0/0

    Incoming/outgoing SA requests: 0/0

    Incoming/outgoing SA responses: 0/0

    Incoming/outgoing data packets: 0/0

1.7.2  Example of Anycast RP Application Configuration

I. Network requirements

l           The PIM-SM domain in this example has multiple multicast sources and receivers. OSPF runs within the domain to provide unicast routes.

l           The anycast RP application is configured in the PIM-SM domain. When a new member joins the multicast group, the switch directly connected to receivers can initiate a Join message to the topologically nearest RP.

l           An MSDP peering relationship is set up between Switch C and Switch F.

l           On Switch C and Switch F, the interface Loopback 1 is configured as a C-BSR, and Loopback 10 is configured as a C-RP.

l           The router ID of Switch C is 1.1.1.1, while the router ID of Switch F is 2.2.2.2.

II. Network diagram

Device	Interface	IP address	Device	Interface	IP address
Switch A	Vlan-int103	10.110.1.2/24	Switch D	Vlan-int300	10.110.4.1/24
Switch B	Vlan-int100	10.110.2.2/24		Vlan-int102	192.168.3.1/24
Switch C	Vlan-int103	10.110.1.1/24		Vlan-int101	192.168.1.2/24
	Vlan-int100	10.110.2.1/24	Switch F	Vlan-int200	10.110.3.1/24
	Vlan-int101	192.168.1.1/24		Vlan-int102	192.168.3.2/24
	Loop0	1.1.1.1/32		Loop0	2.2.2.2/32
	Loop1	3.3.3.3/32		Loop1	4.4.4.4/32
	Loop10	10.1.1.1/32		Loop10	10.1.1.1/32

Figure 1-6 Network diagram for anycast RP configuration

III. Configuration procedure

 

 

1)         Configure IP addresses and unicast routing

Configure the IP address and subnet mask for each interface as per Figure 1-6. Detailed configuration steps are omitted.

Configure OSPF for interconnection between the switches. Detailed configuration steps are omitted.

2)         Enable IP multicast routing, and enable PIM-SM on each interface

# Enable IP multicast routing on Switch C, and enable PIM-SM on each interface.

<SwitchC> system-view

[SwitchC] multicast routing-enable

[SwitchC] interface vlan-interface 103

[SwitchC-Vlan-interface103] pim sm

[SwitchC-Vlan-interface103] quit

[SwitchC] interface vlan-interface 100

[SwitchC-Vlan-interface100] pim sm

[SwitchC-Vlan-interface100] quit

[SwitchC] interface vlan-interface 101

[SwitchC-Vlan-interface101] pim sm

[SwitchC-Vlan-interface101] quit

[SwitchC] interface loopback 0

[SwitchC-LoopBack0] pim sm

[SwitchC-LoopBack0] quit

[SwitchC] interface loopback 1

[SwitchC-LoopBack1] pim sm

[SwitchC-LoopBack1] quit

[SwitchC] interface loopback 10

[SwitchC-LoopBack10] pim sm

[SwitchC-LoopBack10] quit

The configuration on Switch A, Switch B, Switch D, Switch E, Switch F and Switch G is similar to the configuration on Switch C.

3)         Configure C-BSRs and C-RPs

# On Switch C and Switch F, configure Loopback 1 as a C-BSR and configure Loopback 10 as a C-RP.

[SwitchC] interface loopback 1

[SwitchC-LoopBack1] ip address 3.3.3.3 255.255.255.255

[SwitchC-LoopBack1] pim sm

[SwitchC-LoopBack1] quit

[SwitchC] interface loopback 10

[SwitchC-LoopBack10] ip address 10.1.1.1 255.255.255.255

[SwitchC-LoopBack10] pim sm

[SwitchC-LoopBack10] quit

[SwitchC] pim

[SwitchC-pim] c-bsr loopback 1

[SwitchC-pim] c-rp loopback 10

[SwitchC-pim] quit

The configuration on Switch F is similar to the configuration on Switch C.

To view the PIM routing information on the switches, use the display pim routing-table command. When the multicast source (Source 1, with the address of 10.110.5.100/24) in the PIM-SM domain sends multicast data to the multicast group G (225.1.1.1), the receivers attached to Switch F can receive the multicast data.

# View the PIM routing information on Switch C.

[SwitchC] display pim routing-table

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

 

 (10.110.5.100, 225.1.1.1),

 RP: 10.1.1.1 (local)

     Protocol: pim-sm, Flag: SPT LOC ACT

     UpTime: 00:10:20

     Upstream interface: Vlan-interface100

         Upstream neighbor: 10.110.2.2

         RPF prime neighbor: 10.110.1.2

     Downstream interface(s) information:

     Total number of downstreams: 1

         1: Vlan-interface101

             Protocol: pim-sm, UpTime: 00:10:20, Expires: 00:03:10

# View the PIM routing information on Switch F.

[SwitchF] display pim routing-table

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

 

(10.110.5.100, 225.1.1.1)

 RP: 10.1.1.1 (local)

     Protocol: pim-sm, Flag: SPT ACT

     UpTime: 00:03:32

     Upstream interface: Vlan-interface102

         Upstream neighbor: 192.168.3.1

         RPF prime neighbor: 192.168.3.1

     Downstream interface(s) information:

     Total number of downstreams: 1

         1: Vlan-interface200

             Protocol: pim-sm, UpTime: 00:03:32, Expires: -

4)         Configure MSDP peers

# Configure an MSDP peer on Loopback0 of Switch C.

[SwitchC] interface loopback 0

[SwitchC-LoopBack0] ip address 1.1.1.1 255.255.255.255

[SwitchC-LoopBack0] pim sm

[SwitchC-LoopBack0] quit

[SwitchC] msdp

[SwitchC-msdp] originating-rp loopback 0

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

[SwitchC-msdp] quit

# Configure an MSDP peer on Loopback0 of Switch F.

<SwitchF> system-view

[SwitchF] interface loopback 0

[SwitchF-LoopBack0] ip address 2.2.2.2 255.255.255.255

[SwitchF-LoopBack0] pim sm

[SwitchF-LoopBack0] quit

[SwitchF] msdp

[SwitchF-msdp] originating-rp loopback 0

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

[SwitchF-msdp] quit

You can use the display msdp brief command to view the brief information of MSDP peering relationships between the switches.

# View the brief MSDP peer information on Switch C.

[SwitchC] display msdp brief

MSDP Peer Brief Information

  Configured   Up           Listen       Connect      Shutdown     Down

  1            1            0            0            0            0

 

  Peer's Address     State     Up/Down time    AS     SA Count   Reset Count

  2.2.2.2            Up        00:10:17        ?      0          0

# View the brief MSDP peer information on Switch F.

[SwitchF] display msdp brief

MSDP Peer Brief Information

  Configured   Up           Listen       Connect      Shutdown     Down

  1            1            0            0            0            0

 

  Peer's Address     State     Up/Down time    AS     SA Count   Reset Count

  1.1.1.1            Up        00:10:18        ?      0          0

1.7.3  Static RPF Peer Configuration Example

I. Network requirements

l           Two ISPs maintains their ASs, AS 100 and AS 200 respectively. OSPF is running within each AS, and BGP is running between the two ASs.

l           PIM-SM 1 belongs to AS 100, while PIM-SM 2 and PIM-SM 3 belong to AS 200.

l           Each PIM-SM domain has zero or one multicast source and one or more receivers. OSPF runs within each domain to provide unicast routes.

l           PIM-SM 2 and PIM-SM 3 are both PIM stub domains, and BGP is not required between these two domains and PIM-SM 1. Instead, static RPF peers are configured to avoid RPF check on SA messages.

l           The respective loopback interfaces of Switch C, Switch D and Switch F are configured as the C-BSR and C-RP of the respective PIM-SM domains.

l           The static RPF peers of Switch C are Switch D and Switch F, while Switch C is the only RPF peer of Switch D and Switch F. Any switch can receive SA messages sent by its static RPF peer(s) and permitted by the corresponding filtering policy.

II. Network diagram

Device	Interface	IP address	Device	Interface	IP address
Switch D	Vlan-int101	192.168.1.2/24	Switch C	Vlan-int101	192.168.1.1/24
	Loop0	2.2.2.2/32		Vlan-int102	192.168.3.1/24
Switch F	Vlan-int102	192.168.3.2/24		Loop0	1.1.1.1/32
	Loop0	3.3.3.3/32

Figure 1-7 Network diagram for static RPF peer configuration

III. Configuration procedure

 

 

1)         Configure IP addresses and unicast routing

Configure the IP address and subnet mask for each interface of each switch as per Figure 1-7.

Configure OSPF for interconnection between the switches. Ensure network-layer interoperation within the AS, and ensure the dynamic update of routing information between the switches in each PIM-SM domain through a unicast routing protocol. Detailed configuration steps are omitted.

Configure BGP among Switch C, Switch D, Switch C and Switch F, and configure mutual route redistribution between BGP and OSPF. Detailed configuration steps are omitted.

2)         Enable IP multicast routing, and enable PIM-SM on each interface

# Enable IP multicast routing on Switch C, and enable PIM-SM on each interface.

<SwitchC> system-view

[SwitchC] multicast routing-enable

[SwitchC] interface vlan-interface 101

[SwitchC-Vlan-interface101] pim sm

[SwitchC-Vlan-interface101] quit

[SwitchC] interface vlan-interface 102

[SwitchC-Vlan-interface102] pim sm

The configuration on Switch A, Switch B, Switch D, Switch E, Switch F and Switch G is similar to the configuration on Switch C.

# Configure BSR boundary on Switch C.

[SwitchC-Vlan-interface102] pim bsr-boundary

[SwitchC-Vlan-interface102] quit

[SwitchC] interface vlan-interface 101

[SwitchC-Vlan-interface101] pim bsr-boundary

[SwitchC-Vlan-interface101] quit

The configuration on Switch D and Switch F is similar to the configuration on Switch C.

3)         Configure C-BSRs and C-RPs.

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

[SwitchC] router-id 1.1.1.1

[SwitchC] interface loopback 0

[SwitchC-LoopBack0] ip address 1.1.1.1 255.255.255.255

[SwitchC-LoopBack0] pim sm

[SwitchC-LoopBack0] quit

[SwitchC] pim

[SwitchC-pim] c-bsr loopback 0

[SwitchC-pim] c-rp loopback 0

[SwitchC-pim] quit

The configuration on Switch D and Switch F is similar to the configuration on Switch C.

4)         Configure static RPF peers

# Configure Switch D and Switch F as MSDP peers and static RPF peers of Switch C.

[SwitchC] ip ip-prefix list-df permit 192.168.0.0 16 greater-equal 16 less-equal 32

[SwitchC] msdp

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

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

[SwitchC-msdp] static-rpf-peer 192.168.3.2 rp-policy list-df

[SwitchC-msdp] static-rpf-peer 192.168.1.2 rp-policy list-df

[SwitchC-msdp] quit

# Configure Switch C as MSDP peer and static RPF peer of Switch D.

<SwitchD> system-view

[SwitchD] ip ip-prefix list-c permit 192.168.0.0 16 greater-equal 16 less-equal 32

[SwitchD] msdp

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

[SwitchD-msdp] static-rpf-peer 192.168.1.1 rp-policy list-c

[SwitchD-msdp] quit

# Configure Switch C as MSDP peer and static RPF peer of Switch F.

<SwitchF> system-view

[SwitchF] ip ip-prefix list-c permit 192.168.0.0 16 greater-equal 16 less-equal 32

[SwitchF] msdp

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

[SwitchF-msdp] static-rpf-peer 192.168.3.1 rp-policy list-c

[SwitchF-msdp] quit

5)         Verify the configuration

Carry out the display bgp peer command to view the BGP peering relationships between the switches. If the command gives no output information, a BGP peering relationship has not been established between the switches.

When the multicast source (Source 1) in PIM-SM 1 sends multicast information, receivers in PIM-SM 2 and PIM-SM 3 can receive the multicast data. You can use the display msdp brief command to view the brief information of MSDP peering relationships between the switches. For example:

# View the brief MSDP peer information on Switch C.

[SwitchC] display msdp brief

MSDP Peer Brief Information

  Configured   Up           Listen       Connect      Shutdown     Down

  2            2            0            0            0            0

 

  Peer's Address     State     Up/Down time    AS     SA Count   Reset Count

  192.168.3.2        Up        01:07:08       ?        8           0

  192.168.1.2        Up        00:16:39       ?        13          0

# View the brief MSDP peer information on Switch D.

[SwitchD] display msdp brief

MSDP Peer Brief Information

  Configured   Up           Listen       Connect      Shutdown     Down

  1            1            0            0            0            0

 

  Peer's Address     State     Up/Down time    AS     SA Count   Reset Count

  192.168.1.1        Up        01:07:09       ?        8           0

# View the brief MSDP peer information on Switch F.

[SwitchF] display msdp brief

MSDP Peer Brief Information

  Configured   Up           Listen       Connect      Shutdown     Down

  1            1            0            0            0            0

 

  Peer's Address     State     Up/Down time    AS     SA Count   Reset Count

  192.168.3.1        Up        00:16:40       ?        13          0

1.8  Troubleshooting MSDP

1.8.1  MSDP Peers Stay in Down State

I. Symptom

The configured MSDP peers stay in the down state.

II. Analysis

l           A TCP connection–based MSDP peering relationship is established between the local interface address and the MSDP peer after the configuration.

l           The TCP connection setup will fail if there is a consistency between the local interface address and the MSDP peer address configured on the switch.

l           If no route is available between the MSDP peers, the TCP connection setup will also fail.

III. Solution

1)         Check that a route is available between the devices. Carry out the display ip routing-table command to check whether the unicast route between the switches is correct.

2)         Check that a unicast route is available between the two devices that will become MSDP peers to each other.

3)         Verify the interface address consistency between the MSDP peers. Use the display current-configuration command to verify that the local interface address and the MSDP peer address of the remote switch are the same.

1.8.2  No SA Entries in the Device’s SA Cache

I. Symptom

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

II. Analysis

l           The import-source command is used control sending (S, G) entries through SA messages to MSDP peers. If this command is executed without the acl-number argument, all the (S, G) entries will be filtered off, namely no (S, G) entries of the local domain will be advertised.

l           If the import-source command is not executed, the system will advertise all the (S, G) entries of the local domain. If MSDP fails to send (S, G) entries through SA messages, check whether the import-source command has been correct configured.

III. Solution

1)         Check that a route is available between the devices. Carry out the display ip routing-table command to check whether the unicast route between the devices is correct.

2)         Check that a unicast route is available between the two devices that will become MSDP peers to each other.

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

1.8.3  Inter-RP Communication Faults in Anycast RP Application

I. Symptom

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

II. Analysis

l           In the Anycast RP application, RPs in the same PIM-SM domain are configured to be MSDP peers to achieve load balancing among the RPs.

l           An MSDP peer address must be different from the anycast RP address, and the C-BSR and C-RP must be configured on different devices or interfaces.

l           If the originating-rp command is executed, MSDP will replace the RP address in the SA messages with the address of the interface specified in the command.

l           When an MSDP peer receives an SA message, it performs RPF check on the message. If the MSDP peer finds that the remote RP address is the same as the local RP address, it will discard the SA message.

III. Solution

1)         Check that a route is available between the devices. Carry out the display ip routing-table command to check whether the unicast route between the devices is correct.

2)         Check that a unicast route is available between the two devices that will become MSDP peer to each other.

3)         Check the configuration of the originating-rp command. In the Anycast RP application environment, be sure to 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.