Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Example: Configuring Sender-Based RPF in a BGP MVPN with MLDP Point-to-Multipoint Provider Tunnels

This example shows how to configure sender-based reverse-path forwarding (RPF) in a BGP multicast VPN (MVPN). Sender-based RPF helps to prevent multiple provider edge (PE) routers from sending traffic into the core, thus preventing duplicate traffic being sent to a customer.

Requirements

No special configuration beyond device initialization is required before configuring this example.

Sender-based RPF is supported on MX Series platforms with MPC line cards. As a prerequisite, the router must be set to network-services enhanced-ip mode.

Sender-based RPF is supported only for MPLS BGP MVPNs with RSVP-TE point-to-multipoint provider tunnels. Both SPT-only and SPT-RPT MVPN modes are supported.

Sender-based RPF does not work when point-to-multipoint provider tunnels are used with label-switched interfaces (LSI). Junos OS only allocates a single LSI label for each VRF, and uses this label for all point-to-multipoint tunnels. Therefore, the label that the egress receives does not indicate the sending PE router. LSI labels currently cannot scale to create a unique label for each point-to-multipoint tunnel. As such, virtual tunnel interfaces (vt) must be used for sender-based RPF functionality with point-to-multipoint provider tunnels.

This example requires Junos OS Release 21.1R1 or later on the PE router that has sender-based RPF enabled.

Overview

This example shows a single autonomous system (intra-AS scenario) in which one source sends multicast traffic (group 224.1.1.1) into the VPN (VRF instance vpn-1). Two receivers subscribe to the group. They are connected to Device CE2 and Device CE3, respectively. MLDP point-to-multipoint LSPs with inclusive provider tunnels are set up among the PE routers. PIM (C-PIM) is configured on the PE-CE links.

For MPLS, the signaling control protocol used here is LDP. Optionally, you can use RSVP to signal both point-to-point and point-to-point tunnels.

OSPF is used for interior gateway protocol (IGP) connectivity, though IS-IS is also a supported option. If you use OSPF, you must enable OSPF traffic engineering.

For testing purposes, routers are used to simulate the source and the receivers. Device PE2 and Device PE3 are configured to statically join the 224.1.1.1 group by using the set protocols igmp interface interface-name static group 224.1.1.1 command. In the case when a real multicast receiver host is not available, as in this example, this static IGMP configuration is useful. On the CE devices attached to the receivers, to make them listen to the multicast group address, the example uses set protocols sap listen 224.1.1.1. A ping command is used to send multicast traffic into the BGP MBPN.

Sender-based RPF is enabled on Device PE2, as follows:

You can optionally configure hot-root-standby with sender-based-rpf.

Topology

Figure 1 shows the sample network.

Figure 1: Sender-Based RPF in a BGP MVPN Sender-Based RPF in a BGP MVPN

Set Commands for All Devices in the Topology shows the configuration for all of the devices in Figure 1.

The section Configuring Device PE2 describes the steps on Device PE2.

Set Commands for All Devices in the Topology

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.

Device CE1

Device CE2

Device CE3

Device P

Device PE1

Device PE2

Device PE3

Procedure

Step-by-Step Procedure

Configuring Device PE2

Procedure

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 Device PE2:

  1. Enable enhanced IP mode.

  2. Configure the device interfaces.

  3. Configure IGMP on the interface facing the customer edge.

  4. (Optional) Force the PE device to join the multicast group with a static configuration.

    Normally, this would happen dynamically in a setup with real sources and receivers.

  5. Configure RSVP on the interfaces facing the provider core.

  6. Configure MPLS.

  7. Configure internal BGP (IBGP) among the PE routers.

  8. Configure an OSPF or IS-IS.

  9. (Optional) Configure LDP.

    RSVP can be used instead for MPLS signaling.

  10. Configure a routing policy to be used in the VPN.

    The policy is used for exporting the BGP into the PE-CE IGP session.

  11. Configure the routing instance.

  12. Configure the provider tunnel.

  13. Configure the VRF target.

    In the context of unicast IPv4 routes, choosing vrf-target has two implications. First, every locally learned (in this case, direct and static) route at the VRF is exported to BGP with the specified route target (RT). Also, every received inet-vpn BGP route with that RT value is imported into the VRF vpn-1. This has the advantage of a simpler configuration, and the drawback of less flexibility in selecting and modifying the exported and imported routes. It also implies that the VPN is full mesh and all the PE routers get routes from each other, so complex configurations like hub-and-spoke or extranet are not feasible. If any of these features are required, it is necessary to use vrf-import and vrf-export instead.

  14. Configure the PE-CE OSPF session.

  15. Configure the PE-CE PIM session.

  16. Enable the MVPN mode.

    Both rpt-spt and spt-only are supported with sender-based RPF.

  17. Enable sender-based RPF.

  18. Configure the router ID, the router distinguisher, and the AS number.

Results

From configuration mode, confirm your configuration by entering the show chassis, show interfaces, show protocols, show policy-options, show routing-instances, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying Sender-Based RPF

Purpose

Make sure that sender-based RPF is enabled on Device PE2.

Action

Checking the BGP Routes

Purpose

Make sure the expected BGP routes are being added to the routing tables on the PE devices.

Action

Checking the PIM Joins on the Downstream CE Receiver Devices

Purpose

Make sure that the expected join messages are being sent.

Action

Meaning

Both Device CE2 and Device CE3 send C-Join packets upstream to their neighboring PE routers, their unicast next-hop to reach the C-Source.

Checking the PIM Joins on the PE Devices

Purpose

Make sure that the expected join messages are being sent.

Action

Meaning

Both Device CE2 and Device CE3 send C-Join packets upstream to their neighboring PE routers, their unicast next-hop to reach the C-Source.

The C-Join state points to BGP as the upstream interface. Actually, there is no PIM neighbor relationship between the PEs. The downstream PE converts the C-PIM (C-S, C-G) state into a Type 7 source-tree join BGP route, and sends it to the upstream PE router toward the C-Source.

Checking the Multicast Routes

Purpose

Make sure that the C-Multicast flow is integrated in MVPN vpn-1 and sent by Device PE1 into the provider tunnel.

Action

Meaning

The output shows that, unlike the other PE devices, Device PE2 is using sender-based RPF. The output on Device PE2 includes the upstream RPF sender. The Sender Id field is only shown when sender-based RPF is enabled.

Checking the MVPN C-Multicast Routes

Purpose

Check the MVPN C-multicast route information,

Action

Meaning

The output shows the provider tunnel and label information.

Checking the Source PE

Purpose

Check the details of the source PE,

Action

Meaning

The output shows the provider tunnel and label information.