Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Examples: Configuring MSDP

Understanding MSDP

The Multicast Source Discovery Protocol (MSDP) is used to connect multicast routing domains. It typically runs on the same router as the Protocol Independent Multicast (PIM) sparse-mode rendezvous point (RP). Each MSDP router establishes adjacencies with internal and external MSDP peers similar to the way BGP establishes peers. These peer routers inform each other about active sources within the domain. When they detect active sources, the routers can send PIM sparse-mode explicit join messages to the active source.

The peer with the higher IP address passively listens to a well-known port number and waits for the side with the lower IP address to establish a Transmission Control Protocol (TCP) connection. When a PIM sparse-mode RP that is running MSDP becomes aware of a new local source, it sends source-active type, length, and values (TLVs) to its MSDP peers. When a source-active TLV is received, a peer-reverse-path-forwarding (peer-RPF) check (not the same as a multicast RPF check) is done to make sure that this peer is in the path that leads back to the originating RP. If not, the source-active TLV is dropped. This TLV is counted as a “rejected” source-active message.

The MSDP peer-RPF check is different from the normal RPF checks done by non-MSDP multicast routers. The goal of the peer-RPF check is to stop source-active messages from looping. Router R accepts source-active messages originated by Router S only from neighbor Router N or an MSDP mesh group member. For more information about configuring MSDP mesh groups, see Example: Configuring MSDP with Active Source Limits and Mesh Groups.

Router R locates its MSDP peer-RPF neighbor (Router N) deterministically. A series of rules is applied in a particular order to received source-active messages, and the first rule that applies determines the peer-RPF neighbor. All source-active messages from other routers are rejected.

1. If Router X originated the source-active message (Router X is Router S), then Router X is also the peer-RPF neighbor, and its source-active messages are accepted.
2. If Router X is a member of the Router R mesh group, or is the configured peer, then Router X is the peer-RPF neighbor, and its source-active messages are accepted.
3. If Router X is the BGP next hop of the active multicast RPF route toward Router S (Router X installed the route on Router R), then Router X is the peer-RPF neighbor, and its source-active messages are accepted.
4. If Router X is an external BGP (EBGP) or internal BGP (IBGP) peer of Router R, and the last autonomous system (AS) number in the BGP AS-path to Router S is the same as Router X's AS number, then Router X is the peer-RPF neighbor, and its source-active messages are accepted.
5. If Router X uses the same next hop as the next hop to Router S, then Router X is the peer-RPF neighbor, and its source-active messages are accepted.
6. If Router X fits none of these criteria, then Router X is not an MSDP peer-RPF neighbor, and its source-active messages are rejected.

The MSDP peers that receive source-active TLVs can be constrained by BGP reachability information. If the AS path of the network layer reachability information (NLRI) contains the receiving peer's AS number prepended second to last, the sending peer is using the receiving peer as a next hop for this source. If the split horizon information is not being received, the peer can be pruned from the source-active TLV distribution list.

Configuring MSDP

To configure the Multicast Source Discovery Protocol (MSDP), include the msdp statement:

You can include this statement at the following hierarchy levels:

• [edit protocols]
• [edit routing-instances routing-instance-name protocols]
• [edit logical-systems logical-system-name protocols]
• [edit logical-systems logical-system-name routing-instances routing-instance-name protocols]

By default, MSDP is disabled.

Example: Configuring MSDP in a Routing Instance

This example shows how to configure MSDP in a VRF instance.

• Requirements
• Overview
• Configuration
• Verification

Requirements

Before you begin:

• Configure the router interfaces. See the Junos® OS Network Interfaces.
• Configure an interior gateway protocol or static routing. See the Junos OS Routing Protocols Configuration Guide.
• Enable PIM. See PIM Overview.

Overview

• Forwarding
• No forwarding
• Virtual router
• VPLS
• VRF

The main use of MSDP in a routing instance is to support anycast RPs in the network, which allows you to configure redundant RPs. Anycast RP addressing requires MSDP support to synchronize the active sources between RPs.

A designated router (DR) sends periodic join messages and prune messages toward a group-specific rendezvous point (RP) for each group for which it has active members. When a Protocol Independent Multicast (PIM) router learns about a source, it originates an MSDP source-address message if it is the DR on the upstream interface.

• authentication-key—By default, multicast routers accept and process any properly formatted MSDP messages from the configured peer address. This default behavior might violate the security policies in many organizations because MSDP messages by definition come from another routing domain beyond the control of the security practices of the multicast router's organization.

  The router can authenticate MSDP messages using the TCP message digest 5 (MD5) signature option for MSDP peering sessions. This authentication provides protection against spoofed packets being introduced into an MSDP peering session. Two organizations implementing MSDP authentication must decide on a human-readable key on both peers. This key is included in the MD5 signature computation for each MSDP segment sent between the two peers.

  You configure an MSDP authentication key on a per-peer basis, whether the MSDP peer is defined in a group or individually. If you configure different authentication keys for the same peer one in a group and one individually, the individual key is used.

  The peer key can be a text string up to 16 letters and digits long. Strings can include any ASCII characters with the exception of (,), &, and [. If you include spaces in an MSDP authentication key, enclose all characters in quotation marks (“ ”).

  Adding, removing, or changing an MSDP authentication key in a peering session resets the existing MSDP session and establishes a new session between the affected MSDP peers. This immediate session termination prevents excessive retransmissions and eventual session timeouts due to mismatched keys.

• import and export—All routing protocols use the routing table to store the routes that they learn and to determine which routes they advertise in their protocol packets. Routing policy allows you to control which routes the routing protocols store in, and retrieve from, the routing table.

  You can configure routing policy globally, for a group, or for an individual peer. This example shows how to configure the policy for an individual peer.

  If you configure routing policy at the group level, each peer in a group inherits the group's routing policy.

  The import statement applies policies to source-active messages being imported into the source-active cache from MSDP. The export statement applies policies to source-active messages being exported from the source-active cache into MSDP. If you specify more than one policy, they are evaluated in the order specified, from first to last, and the first matching policy is applied to the route. If no match is found for the import policy, MSDP shares with the routing table only those routes that were learned from MSDP routers. If no match is found for the export policy, the default MSDP export policy is applied to entries in the source-active cache. See Table 1 for a list of match conditions.

  Table 1: MSDP Source-Active Message Filter Match Conditions

  Match Condition	Matches On
  interface	Router interface or interfaces specified by name or IP address
  neighbor	Neighbor address (the source address in the IP header of the source-active message)
  route-filter	Multicast group address embedded in the source-active message
  source-address-filter	Multicast source address embedded in the source-active message

• local-address—Identifies the address of the router you are configuring as an MSDP router (the local router). When you configure MSDP, the local-address statement is required. The router must also be a Protocol Independent Multicast (PIM) sparse-mode rendezvous point (RP).
• peer—An MSDP router must know which routers are its peers. You define the peer relationships explicitly by configuring the neighboring routers that are the MSDP peers of the local router. After peer relationships are established, the MSDP peers exchange messages to advertise active multicast sources. You must configure at least one peer for MSDP to function. When you configure MSDP, the peer statement is required. The router must also be a Protocol Independent Multicast (PIM) sparse-mode rendezvous point (RP).

  You can arrange MSDP peers into groups. Each group must contain at least one peer. Arranging peers into groups is useful if you want to block sources from some peers and accept them from others, or set tracing options on one group and not others. This example shows how to configure the MSDP peers in groups. If you configure MSDP peers in a group, each peer in a group inherits all group-level options.

Figure 1 shows the topology for this example.

Figure 1: MSDP in a VRF Instance Topology

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

1. Configure the BGP export policy.

   [edit policy-options]user@host# set policy-statement bgp-to-ospf term 1 from protocol bgpuser@host# set policy-statement bgp-to-ospf term 1 then accept
2. Configure a policy that filters out certain source and group addresses and accepts all other source and group addresses.
   [edit policy-options]user@host# set policy-statement sa-filter term bad-groups from route-filter 224.0.1.2/32 exact user@host# set policy-statement sa-filter term bad-groups from route-filter 224.0.1.2/32 exact user@host# set policy-statement sa-filter term bad-groups from route-filter 224.77.0.0/16 orlonger user@host# set policy-statement sa-filter term bad-groups then reject user@host# set policy-statement sa-filter term bad-sources from source-address-filter 10.0.0.0/8 orlonger user@host# set policy-statement sa-filter term bad-sources from source-address-filter 127.0.0.0/8 orlonger user@host# set policy-statement sa-filter term bad-sources then reject user@host# set policy-statement sa-filter term accept-everything-else then accept
3. Configure the routing instance type and interfaces.
   [edit routing-instances]user@host# set VPN-100 instance-type vrf user@host# set VPN-100 interface ge-0/0/0.100 user@host# set VPN-100 interface lo0.100
4. Configure the routing instance route distinguisher and VRF target.
   [edit routing-instances]user@host# set VPN-100 route-distinguisher 10.255.120.36:100 user@host# set VPN-100 vrf-target target:100:1
5. Configure OSPF in the routing instance.
   [edit routing-instances]user@host# set VPN-100 protocols ospf export bgp-to-ospf user@host# set VPN-100 protocols ospf area 0.0.0.0 interface lo0.100 user@host# set VPN-100 protocols ospf area 0.0.0.0 interface ge-0/0/0.100
6. Configure PIM in the routing instance.
   [edit routing-instances]user@host# set VPN-100 protocols pim rp static address 11.11.47.100 user@host# set VPN-100 protocols pim interface lo0.100 mode sparse-dense user@host# set VPN-100 protocols pim interface lo0.100 version 2 user@host# set VPN-100 protocols pim interface ge-0/0/0.100 mode sparse-dense user@host# set VPN-100 protocols pim interface ge-0/0/0.100 version 2
7. Configure MSDP in the routing instance.
   [edit routing-instances]user@host# set VPN-100 protocols msdp export sa-filter user@host# set VPN-100 protocols msdp import sa-filter user@host# set VPN-100 protocols msdp group 100 local-address 10.10.47.100 user@host# set VPN-100 protocols msdp group 100 peer 10.255.120.39 authentication-key “New York”[edit routing-instances]user@host# set VPN-100 protocols msdp group to_pe local-address 10.10.47.100 [edit routing-instances]user@host# set VPN-100 protocols msdp group to_pe peer 11.11.47.100

8. If you are done configuring the device, commit the configuration.

   [edit routing-instances]user@host# commit

Results

Confirm your configuration by entering the show policy-options command and the show routing-instances command from configuration mode. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

To verify the configuration, run the following commands:

• show msdp instance VPN-100
• show msdp source-active VPN-100
• show multicast usage instance VPN-100
• show route table VPN-100.inet.4

Configuring the Interface to Accept Traffic from a Remote Source

You can configure an incoming interface to accept traffic from a remote source. A remote source is a source that is not on the same subnet as the incoming interface. This enables the remote source to be learned and advertised by MSDP so that receivers in other MSDP areas can join the source. You do not need to disable RPF checking, but you do need to ensure that the best path to reach the remote source is through the incoming interface.

In this sample configuration, the incoming interface (ge-1/3/0) is on a provider edge (PE) router on the receiver side of a multicast VPN.

1. Edit the incoming interface.
   [edit protocols pim interface ge-1/3/0.0]user@host# set accept-remote-source
2. If the incoming interface is not the only way to reach the remote source, ensure that the best path to reach the remote source is through the incoming interface. One way to do this is to use AS path prepending on the other possible routes.
   [edit policy-options policy-statement as-path-prepend term prepend]user@host# set from route-filter 192.168.0.0/16 orlongeruser@host# set from route-filter 172.16.0.0/16 orlongeruser@host# set then as-path-prepend "1 1 1 1"

   Another way to do this might be to configure a static route on the receiver side PE router to the source.

4. After the configuration is committed, use the show pim statistics and show msdp source commands to verify that the interface is accepting traffic from the remote source.

Example: Configuring MSDP with Active Source Limits and Mesh Groups

This example shows how to configure MSDP to filter source-active messages and limit the flooding of source-active messages.

• Requirements
• Overview
• Configuration
• Verification

Requirements

Before you begin:

• Configure the router interfaces. See the Junos® OS Network Interfaces.
• Configure an interior gateway protocol or static routing. See the Junos OS Routing Protocols Configuration Guide.
• Enable PIM sparse mode. See PIM Overview.
• Configure the router as a PIM sparse-mode RP. See Configuring Local PIM RPs.

Overview

A router interested in MSDP messages, such as an RP, might have to process a large number of MSDP messages, especially source-active messages, arriving from other routers. Because of the potential need for a router to examine, process, and create state tables for many MSDP packets, there is a possibility of an MSDP-based denial-of-service (DoS) attack on a router running MSDP. To minimize this possibility, you can configure the router to limit the number of source active messages the router accepts. Also, you can configure a threshold for applying random early discard (RED) to drop some but not all MSDP active source messages. Beginning with Junos OS 12.2, you can optionally configure a warning threshold so the device can log warning messages in the system log when a certain number of source-active messages have been received. It is helpful to review the system log messages for troubleshooting purposes and to detect if an excessive amount of source-active messages have been received. These log messages convey when the configured message limit has been exceeded, when the configured warning threshold has been exceeded, and when the number of messages drop below the configured warning threshold.

By default, the router accepts 25,000 source active messages before ignoring the rest. The limit can be from 1 through 1,000,000. The limit is applied to both the number of messages and the number of MSDP peers.

By default, the router accepts 24,000 source-active messages before applying the RED profile to prevent a possible DoS attack. This number can also range from 1 through 1,000,000. The next 1000 messages are screened by the RED profile and the accepted messages processed. If you configure no drop profiles (as this example does not), RED is still in effect and functions as the primary mechanism for managing congestion. In the default RED drop profile, when the packet queue fill-level is 0 percent, the drop probability is 0 percent. When the fill-level is 100 percent, the drop probability is 100 percent.

Note: The router ignores source-active messages with encapsulated TCP packets. Multicast does not use TCP; segments inside source-active messages are most likely the result of worm activity.

The number configured for the threshold must be less than the number configured for the maximum number of active MSDP sources.

The warning threshold is a percentage of maximum number of MSDP source-active messages received, so you must configure the source-active message limit to configure a warning threshold. The range for the warning threshold is 1 through 100 percent. You can further specify the amount of time (in seconds) between the log messages. The range is 6 through 32,767 seconds.

You can configure an active source limit globally, for a group, or for a peer. If active source limits are configured at multiple levels of the hierarchy (as shown in this example), all are applied.

You can configure an active source limit for an address range as well as for a specific peer. A per-source active source limit uses an IP prefix and prefix length instead of a specific address. You can configure more than one per-source active source limit. The longest match determines the limit.

Per-source active source limits can be combined with active source limits at the peer, group, and global (instance) hierarchy level. Per-source limits are applied before any other type of active source limit. Limits are tested in the following order:

• Per-source
• Per-peer or group
• Per-instance

An active source message must “pass” all limits established before being accepted. For example, if a source is configured with an active source limit of 10,000 active multicast groups and the instance is configured with a limit of 5000 (and there are no other sources or limits configured), only 5000 active source messages are accepted from this source.

MSDP mesh groups are groups of peers configured in a full-mesh topology that limits the flooding of source-active messages to neighboring peers. Every mesh group member must have a peer connection with every other mesh group member. When a source-active message is received from a mesh group member, the source-active message is always accepted but is not flooded to other members of the same mesh group. However, the source-active message is flooded to non-mesh group peers or members of other mesh groups. By default, standard flooding rules apply if mesh-group is not specified.

Caution: When configuring MSDP mesh groups, you must configure all members the same way. If you do not configure a full mesh, excessive flooding of source-active messages can occur.

A common application for MSDP mesh groups is peer-reverse-path-forwarding (peer-RPF) check bypass. For example, if there are two MSDP peers inside an autonomous system (AS), and only one of them has an external MSDP session to another AS, the internal MSDP peer often rejects incoming source-active messages relayed by the peer with the external link. Rejection occurs because the external MSDP peer must be reachable by the internal MSDP peer through the next hop toward the source in another AS, and this next-hop condition is not certain. To prevent rejections, configure an MSDP mesh group on the internal MSDP peer so it always accepts source-active messages.

Note: An alternative way to bypass the peer-RPF check is to configure a default peer. In networks with only one MSDP peer, especially stub networks, the source-active message always needs to be accepted. An MSDP default peer is an MSDP peer from which all source-active messages are accepted without performing the peer-RPF check. You can establish a default peer at the peer or group level by including the default-peer statement.

Table 2 explains how flooding is handled by peers in this example. Figure 2 illustrates source-active message flooding between different mesh groups and peers within the same mesh group.

Figure 2: Source-Active Message Flooding

• active-source-limit maximum 10000—Applies a limit of 10,000 active sources to all other peers.
• active-source-limit log-warning 80—(Optional) Applies a warning threshold of 80 percent. In this example, the active source maximum is 10,000, so the device will start logging warning messages once it receives 8,000 active source messages.
• active-source-limit log-interval 20—(Optional) Applies a 20 second waiting period between system log messages.
• data-encapsulation disable—On an RP router using MSDP, disables the default encapsulation of multicast data received in MSDP register messages inside MSDP source-active messages.

  MSDP data encapsulation mainly concerns bursty sources of multicast traffic. Sources that send only one packet every few minutes have trouble with the timeout of state relationships between sources and their multicast groups (S,G). Routers lose data while they attempt to reestablish (S,G) state tables. As a result, multicast register messages contain data, and this data encapsulation in MSDP source-active messages can be turned on or off through configuration.

  By default, MSDP data encapsulation is enabled. An RP running MSDP takes the data packets arriving in the source's register message and encapsulates the data inside an MSDP source-active message.

  However, data encapsulation creates both a multicast forwarding cache entry in the inet.1 table (this is also the forwarding table) and a routing table entry in the inet.4 table. Without data encapsulation, MSDP creates only a routing table entry in the inet.4 table. In some circumstances, such as the presence of Internet worms or other forms of DoS attack, the router's forwarding table might fill up with these entries. To prevent the forwarding table from filling up with MSDP entries, you can configure the router not to use MSDP data encapsulation. However, if you disable data encapsulation, the router ignores and discards the encapsulated data. Without data encapsulation, multicast applications with bursty sources having transmit intervals greater than about 3 minutes might not work well.

• group MSDP-group local-address 10.1.2.3—Specifies the address of the local router (this router).
• group MSDP-group mode mesh-group—Specifies that all peers belonging to the MSDP-group group are mesh group members.
• group MSDP-group peer 10.10.10.10—Prevents the sending of source-active messages to neighboring peer 10.10.10.10.
• group MSDP-group peer 10.10.10.10 active-source-limit maximum 7500—Applies a limit of 7500 active sources to MSDP peer 10.10.10.10 in group MSDP-group.
• peer 10.0.0.1 active-source-limit maximum 5000 threshold 4000—Applies a threshhold of 4000 active sources and a limit of 5000 active sources to MSDP peer 10.0.0.1.
• source 10.1.0.0/16 active-source-limit maximum 500—Applies a limit of 500 active sources to any source on the 10.1.0.0/16 network.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

1. (Optional) Disable data encapsulation.

   [edit protocols msdp]user@host# set data-encapsulation disable

2. Configure the active source limits.

   [edit protocols msdp]user@host# set peer 10.0.0.1 active-source-limit maximum 5000 threshold 4000user@host# set group MSDP-group peer 10.10.10.10 active-source-limit maximum 7500user@host# set active-source-limit maximum 10000user@host# set source 10.1.0.0/16 active-source-limit maximum 500

3. (Optional) Configure the threshold at which warning messages are logged and the amount of time between log messages.

   [edit protocols msdp]user@host# set active-source-limit log-warning 80user@host# set active-source-limit log-interval 20

4. Configure the mesh group.

   [edit protocols msdp]user@host# set group MSDP-group mode mesh-groupuser@host# set group MSDP-group peer 10.10.10.10user@host# set group MSDP-group local-address 10.1.2.3

5. If you are done configuring the device, commit the configuration.

   [edit routing-instances]user@host# commit

Results

Confirm your configuration by entering the show protocols command.

Verification

To verify the configuration, run the following commands:

• show msdp source-active
• show msdp statistics

Tracing MSDP Protocol Traffic

Tracing operations record detailed messages about the operation of routing protocols, such as the various types of routing protocol packets sent and received, and routing policy actions. You can specify which trace operations are logged by including specific tracing flags. The following table describes the flags that you can include.

1. (Optional) Configure tracing by including the traceoptions statement at the [edit routing-options] hierarchy level and set the all-packets-trace and all flags to trace all protocol packets.
   [edit routing-options traceoptions]user@host# set file all-packets-traceuser@host# set flag all
2. Configure the filename for the MSDP trace file.
   [edit protocols msdp group groupa traceoptions]user@host# set file msdp-trace
3. (Optional) Configure the maximum number of trace files.
   [edit protocols msdp group groupa traceoptions]user@host# set file files 5
4. (Optional) Configure the maximum size of each trace file.
   [edit protocols msdp group groupa traceoptions]user@host# set file size 1m
5. (Optional) Enable unrestricted file access.
   [edit protocols msdp group groupa traceoptions]user@host# set file world-readable
6. Configure tracing flags. Suppose you are troubleshooting issues with the source-active cache for groupa. The following example shows how to trace messages associated with the group address.
   [edit protocols msdp group groupa traceoptions]user@host# set flag source-active | match 230.0.0.3
7. View the trace file.
   user@host> file list /var/loguser@host> file show /var/log/msdp-trace

Disabling MSDP

To disable MSDP on the router, include the disable statement:

You can disable MSDP globally for all peers, for all peers in a group, or for an individual peer.

• Globally for all MSDP peers at the following hierarchy levels:
  • [edit protocols msdp]
  • [edit logical-systems logical-system-name protocols msdp]
  • [edit routing-instances routing-instance-name protocols msdp]
  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols msdp]
• For all peers in a group at the following hierarchy levels:
  • [edit protocols msdp group group-name]
  • [edit logical-systems logical-system-name protocols msdp group group-name]
  • [edit routing-instances routing-instance-name protocols msdp group group-name]
  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols msdp group group-name]
• For an individual peer at the following hierarchy levels:
  • [edit protocols msdp peer address]
  • [edit protocols msdp group group-name peer address]
  • [edit logical-systems logical-system-name protocols msdp peer address]
  • [edit logical-systems logical-system-name protocols msdp group group-name peer address]
  • [edit routing-instances routing-instance-name protocols msdp peer address]
  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols msdp peer address]
  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols msdp group group-name peer address]

If you disable MSDP at the group level, each peer in the group is disabled.

Example: Configuring MSDP

Configure a router to act as a PIM sparse-mode rendezvous point and an MSDP peer: