Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

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.

  1. S ------------------> N ------------------> R

Router R (the router that accepts or rejects active-source messages) 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.

The six rules applied to source-active messages originating at Router S received at Router R from Router N are as follows:

  1. If Router N originated the source-active message (Router N is Router S), then Router N is also the peer-RPF neighbor, and its source-active messages are accepted.

  2. If Router N is a member of the Router R mesh group, or is the configured peer, then Router N is the peer-RPF neighbor, and its source-active messages are accepted.

  3. If Router N is the BGP next hop of the active multicast RPF route toward Router S (Router N installed the route on Router R), then Router N is the peer-RPF neighbor, and its source-active messages are accepted.

  4. If Router N 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 N's AS number, then Router N is the peer-RPF neighbor, and its source-active messages are accepted.

  5. If Router N uses the same next hop as the next hop to Router S, then Router N is the peer-RPF neighbor, and its source-active messages are accepted.

  6. If Router N fits none of these criteria, then Router N 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.

For information about configuring MSDP mesh groups, see Example: Configuring MSDP with Active Source Limits and Mesh Groups.

See Also

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.

See Also

Example: Configuring MSDP in a Routing Instance

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

Requirements

Before you begin:

Overview

You can configure MSDP in the following types of instances:

  • 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.

This example includes the following MSDP settings.

  • 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.

Topology

Figure 1 shows the topology for this example.

Figure 1: MSDP in a VRF Instance TopologyMSDP in a VRF Instance Topology

Configuration

Procedure

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure an MSDP routing instance:

  1. Configure the BGP export policy.

  2. Configure a policy that filters out certain source and group addresses and accepts all other source and group addresses.

  3. Configure the routing instance type and interfaces.

  4. Configure the routing instance route distinguisher and VRF target.

  5. Configure OSPF in the routing instance.

  6. Configure PIM in the routing instance.

  7. Configure MSDP in the routing instance.

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

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

See Also

Configuring the Interface to Accept Traffic from a Remote Source

You can configure an incoming interface to accept multicast traffic from a remote source. A remote source is a source that is not on the same subnet as the incoming interface. Figure 2 shows such a topology, where R2 connects to the R1 source on one subnet, and to the incoming interface on R3 (ge-1/3/0.0 in the figure) on another subnet.

Figure 2: Accepting Multicast Traffic from a Remote SourceAccepting Multicast Traffic from a Remote Source

In this topology R2 is a pass-through device not running PIM, so R3 is the first hop router for multicast packets sent from R1. Because R1 and R3 are in different subnets, the default behavior of R3 is to disregard R1 as a remote source. You can have R3 accept multicast traffic from R1, however, by enabling accept-remote-source on the target interface.

To accept traffic from a remote source:

  1. Identify the router and physical interface that you want to receive multicast traffic from the remote source.
  2. Configure the interface to accept traffic from the remote source.
    Note:

    If the interface you identified is not the only path from the remote source, you need to ensure that it is the best path. For example you can configure a static route on the receiver side PE router to the source, or you can prepend the AS path on the other possible routes:

  3. Commit the configuration changes.
  4. Confirm that the interface you configured accepts traffic from the remote source.

See Also

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

Before you begin:

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 detection (RED) to drop some but not all MSDP active source messages.

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.

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. .

Table 2: Source-Active Message Flooding Explanation

Source-Active Message Received From

Source-Active Message Flooded To

Source-Active Message Not Flooded To

Peer 21

Peer 11, Peer 12, Peer 13, Peer 31, Peer 32

Peer 22

Peer 11

Peer 21, Peer 22, Peer 31, Peer 32

Peer 12, Peer 13

Peer 31

Peer 21, Peer 22, Peer 11, Peer 12, Peer 13, Peer 32

–

Figure 3 illustrates source-active message flooding between different mesh groups and peers within the same mesh group.

Figure 3: Source-Active Message FloodingSource-Active Message Flooding

This example includes the following settings:

  • active-source-limit maximum 10000—Applies a limit of 10,000 active sources to all other peers.

  • 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.

Topology

Configuration

Procedure

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure MSDP source active routes and mesh groups:

  1. (Optional) Disable data encapsulation.

  2. Configure the active source limits.

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

  4. Configure the mesh group.

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

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

See Also

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.

Flag

Description

all

Trace all operations.

general

Trace general events.

keepalive

Trace keepalive messages.

normal

Trace normal events.

packets

Trace all MSDP packets.

policy

Trace policy processing.

route

Trace MSDP changes to the routing table.

source-active

Trace source-active packets.

source-active-request

Trace source-active request packets.

source-active-response

Trace source-active response packets.

state

Trace state transitions.

task

Trace task processing.

timer

Trace timer processing.

You can configure MSDP tracing for all peers, for all peers in a particular group, or for a particular peer.

In the following example, tracing is enabled for all routing protocol packets. Then tracing is narrowed to focus only on MSDP peers in a particular group. To configure tracing operations for MSDP:

  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.
  2. Configure the filename for the MSDP trace file.
  3. (Optional) Configure the maximum number of trace files.
  4. (Optional) Configure the maximum size of each trace file.
  5. (Optional) Enable unrestricted file access.
  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.
  7. View the trace file.

See Also

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:

Related Documentation