Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuring Multiprotocol BGP Multicast VPNs

Understanding Multiprotocol BGP-Based Multicast VPNs: Next-Generation

Multiprotocol BGP-based multicast VPNs (also referred to as next-generation Layer 3 VPN multicast) constitute the next evolution after dual multicast VPNs (draft-rosen) and provide a simpler solution for administrators who want to configure multicast over Layer 3 VPNs.

The main characteristics of multiprotocol BGP-based multicast VPNs are:

  • They extend Layer 3 VPN service (RFC 2547) to support IP multicast for Layer 3 VPN service providers.

  • They follow the same architecture as specified by RFC 2547 for unicast VPNs. Specifically, BGP is used as the control plane.

  • They eliminate the requirement for the virtual router (VR) model, which is specified in Internet draft draft-rosen-vpn-mcast, Multicast in MPLS/BGP VPNs, for multicast VPNs.

  • They rely on RFC-based unicast with extensions for intra-AS and inter-AS communication.

Multiprotocol BGP-based VPNs are defined by two sets of sites: a sender set and a receiver set. Hosts within a receiver site set can receive multicast traffic and hosts within a sender site set can send multicast traffic. A site set can be both receiver and sender, which means that hosts within such a site can both send and receive multicast traffic. Multiprotocol BGP-based VPNS can span organizations (so the sites can be intranets or extranets), can span service providers, and can overlap.

Site administrators configure multiprotocol BGP-based VPNs based on customer requirements and the existing BGP and MPLS VPN infrastructure.

Route Reflector Behavior in MVPNs

BGP-based multicast VPN (MVPN) customer multicast routes are aggregated by route reflectors. A route reflector (RR) might receive a customer multicast route with the same NLRI from more than one provider edge (PE) router, but the RR readvertises only one such NLRI. If the set of PE routers that advertise this NLRI changes, the RR does not update the route. This minimizes route churn. To achieve this, the RR sets the next hop to self. In addition, the RR sets the originator ID to itself. The RR avoids unnecessary best-path computation if it receives a subsequent customer multicast route for an NLRI that the RR is already advertising. This allows aggregation of source active and customer multicast routes with the same MVPN NLRI.

Example: Configuring Point-to-Multipoint LDP LSPs as the Data Plane for Intra-AS MBGP MVPNs

This example shows how to configure point-to-multipoint (P2MP) LDP label-switched paths (LSPs) as the data plane for intra-autonomous system (AS) multiprotocol BGP (MBGP) multicast VPNs (MVPNs). This feature is well suited for service providers who are already running LDP in the MPLS backbone and need MBGP MVPN functionality.

Requirements

Before you begin:

  • Configure the router interfaces. See the Junos OS Network Interfaces Library for Routing Devices.

  • Configure an interior gateway protocol or static routing. See the Junos OS Routing Protocols Library for Routing Devices.

  • Configure a BGP-MVPN control plane. See MBGP-Based Multicast VPN Trees in the Multicast Protocols User Guide .

  • Configure LDP as the signaling protocol on all P2MP provider and provider-edge routers. See LDP Operation in the Junos OS MPLS Applications User Guide.

  • Configure P2MP LDP LSPs as the provider tunnel technology on each PE router in the MVPN that belongs to the sender site set. See the Junos OS MPLS Applications User Guide.

  • Configure either a virtual loopback tunnel interface (requires a Tunnel PIC) or the vrf-table-label statement in the MVPN routing instance. If you configure the vrf-table-label statement, you can configure an optional virtual loopback tunnel interface as well.

  • In an extranet scenario when the egress PE router belongs to multiple MVPN instances, all of which need to receive a specific multicast stream, a virtual loopback tunnel interface (and a Tunnel PIC) is required on the egress PE router. See Configuring Virtual Loopback Tunnels for VRF Table Lookup in the in the Junos OS Services Interfaces Library for Routing Devices.

  • If the egress PE router is also a transit router for the point-to-multipoint LSP, a virtual loopback tunnel interface (and a Tunnel PIC) is required on the egress PE router. See Configuring Virtual Loopback Tunnels for VRF Table Lookup in the Multicast Protocols User Guide .

  • Some extranet configurations of MBGP MVPNs with point-to-multicast LDP LSPs as the data plane require a virtual loopback tunnel interface (and a Tunnel PIC) on egress PE routers. When an egress PE router belongs to multiple MVPN instances, all of which need to receive a specific multicast stream, the vrf-table-table statement cannot be used. In Figure 1, the CE1 and CE2 routers belong to different MVPNs. However, they want to receive a multicast stream being sent by Source. If the vrf-table-label statement is configured on Router PE2, the packet cannot be forwarded to both CE1 and CE2. This causes packet loss. The packet is forwarded to both Routers CE1 and CE2 if a virtual loopback tunnel interface is used in both MVPN routing instances on Router PE2. Thus, you need to set up a virtual loopback tunnel interface if you are using an extranet scenario wherein the egress PE router belongs to multiple MVPN instances that receive a specific multicast stream, or if you are using the egress PE router as a transit router for the point-to-multipoint LSP.

    Note:

    Starting in Junos OS Release 15.1X49-D50 and Junos OS Release 17.3R1, the vrf-table-label statement allows mapping of the inner label to a specific Virtual Routing and Forwarding (VRF). This mapping allows examination of the encapsulated IP header at an egress VPN router. For SRX Series Firewalls, the vrf-table-label statement is currently supported only on physical interfaces. As a workaround, deactivate vrf-table-label or use physical interfaces.

    Figure 1: Extranet Configuration of MBGP MVPN with P2MP LDP LSPs as Data PlaneExtranet Configuration of MBGP MVPN with P2MP LDP LSPs as Data Plane

    See Configuring Virtual Loopback Tunnels for VRF Table Lookup for more information.

Overview

This topic describes how P2MP LDP LSPs can be configured as the data plane for intra-AS selective provider tunnels. Selective P2MP LSPs are triggered only based on the bandwidth threshold of a particular customer’s multicast stream. A separate P2MP LDP LSP is set up for a given customer source and customer group pair (C-S, C-G) by a PE router. The C-S is behind the PE router that belongs in the sender site set. Aggregation of intra-AS selective provider tunnels across MVPNs is not supported.

When you configure selective provider tunnels, leaves discover the P2MP LSP root as follows. A PE router with a receiver for a customer multicast stream behind it needs to discover the identity of the PE router (and the provider tunnel information) with the source of the customer multicast stream behind it. This information is auto-discovered dynamically using the S-PMSI AD routes originated by the PE router with the C-S behind it.

The Junos OS also supports P2MP LDP LSPs as the data plane for intra-AS inclusive provider tunnels. These tunnels are triggered based on the MVPN configuration. A separate P2MP LSP LSP is set up for a given MVPN by a PE router that belongs in the sender site set. This PE router is the root of the P2MP LSP. Aggregation of intra-AS inclusive provider tunnels across MVPNs is not supported.

When you configure inclusive provider tunnels, leaves discover the P2MP LSP root as follows. A PE router with a receiver site for a given MVPN needs to discover the identities of PE routers (and the provider tunnel information) with sender sites for that MVPN. This information is auto-discovered dynamically using the intra-AS auto-discovery routes originated by the PE routers with sender sites.

Topology

Figure 2 shows the topology used in this example.

Figure 2: P2MP LDP LSPs as the Data Plane for Intra-AS MBGP MVPNsP2MP LDP LSPs as the Data Plane for Intra-AS MBGP MVPNs

In Figure 2, the routers perform the following functions:

  • R1 and R2 are provider (P) routers.

  • R0, R3, R4, and R5 are provider edge (PE) routers.

  • MBGP MVPN is configured on all PE routers.

  • Two VPNs are defined: green and red.

  • Router R0 serves both green and red CE routers in separate routing instances.

  • Router R3 is connected to a green CE router.

  • Router R5 is connected to overlapping green and red CE routers in a single routing instance.

  • Router R4 is connected to overlapping green and red CE routers in a single routing instance.

  • OSPF and multipoint LDP (mLDP) are running in the core.

  • Router R1 is a route reflector (RR), and router R2 is a redundant RR.

  • Routers R0, R3, R4, and R5 are client internal BGP (IBGP) peers.

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.

Procedure

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 P2MP LDP LSPs as the data plane for intra-AS MBGP MVPNs:

  1. Configure LDP on all routers.

  2. Configure the provider tunnel.

  3. Configure the selective provider tunnel.

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

Results

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

Verification

To verify the configuration, run the following commands:

  • ping mpls ldp p2mp to ping the end points of a P2MP LSP.

  • show ldp database to display LDP P2MP label bindings and to ensure that the LDP P2MP LSP is signaled.

  • show ldp session detail to display the LDP capabilities exchanged with the peer. The Capabilities advertised and Capabilities received fields should include p2mp.

  • show ldp traffic-statistics p2mp to display the data traffic statistics for the P2MP LSP.

  • show mvpn instance, show mvpn neighbor, and show mvpn c-multicast to display multicast VPN routing instance information and to ensure that the LDP P2MP LSP is associated with the MVPN as the S-PMSI.

  • show multicast route instance detail on PE routers to ensure that traffic is received by all the hosts and to display statistics on the receivers.

  • show route label label detail to display the P2MP forwarding equivalence class (FEC) if the label is an input label for an LDP P2MP LSP.

Example: Configuring Ingress Replication for IP Multicast Using MBGP MVPNs

Requirements

The routers used in this example are Juniper Networks M Series Multiservice Edge Routers, T Series Core Routers, or MX Series 5G Universal Routing Platforms. When using ingress replication for IP multicast, each participating router must be configured with BGP for control plane procedures and with ingress replication for the data provider tunnel, which forms a full mesh of MPLS point-to-point LSPs. The ingress replication tunnel can be selective or inclusive, depending on the configuration of the provider tunnel in the routing instance.

Overview

The ingress-replication provider tunnel type uses unicast tunnels between routers to create a multicast distribution tree.

The mpls-internet-multicast routing instance type uses ingress replication provider tunnels to carry IP multicast data between routers through an MPLS cloud, using MBGP (or Next Gen) MVPN. Ingress replication can also be configured when using MVPN to carry multicast data between PE routers.

The mpls-internet-multicast routing instance is a non-forwarding instance used only for control plane procedures. It does not support any interface configurations. Only one mpls-internet-multicast routing instance can be defined for a logical system. All multicast and unicast routes used for IP multicast are associated only with the default routing instance (inet.0), not with a configured routing instance. The mpls-internet-multicast routing instance type is configured for the default master instance on each router, and is also included at the [edit protocols pim] hierarchy level in the default instance.

For each mpls-internet-multicast routing instance, the ingress-replication statement is required under the provider-tunnel statement and also under the [edit routing-instances routing-instance-name provider-tunnel selective group source] hierarchy level.

When a new destination needs to be added to the ingress replication provider tunnel, the resulting behavior differs depending on how the ingress replication provider tunnel is configured:

  • create-new-ucast-tunnel—When this statement is configured, a new unicast tunnel to the destination is created, and is deleted when the destination is no longer needed. Use this mode for RSVP LSPs using ingress replication.

  • label-switched-path-template (Multicast)—When this statement is configured, an LSP template is used for the for the point-to-multipoint LSP for ingress replication.

Topology

The IP topology consists of routers on the edge of the IP multicast domain. Each router has a set of IP interfaces configured toward the MPLS cloud and a set of interfaces configured toward the IP routers. See Figure 3. Internet multicast traffic is carried between the IP routers, through the MPLS cloud, using ingress replication tunnels for the data plane and a full-mesh IBGP session for the control plane.

Figure 3: Internet Multicast TopologyInternet Multicast 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, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Border Router C

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 CLI User Guide.

The following example shows how to configure ingress replication on an IP multicast instance with the routing instance type mpls-internet-multicast. Additionally, this example shows how to configure a selective provider tunnel that selects a new unicast tunnel each time a new destination needs to be added to the multicast distribution tree.

This example shows the configuration of the link between Border Router C and edge IP Router C, from which Border Router C receives PIM join messages.

  1. Enable MPLS.

  2. Configure a signaling protocol, such as RSVP or LDP.

  3. Configure a full-mesh of IBGP peering sessions.

  4. Configure the multiprotocol BGP-related settings so that the BGP sessions carry the necessary NLRI.

  5. Configure an interior gateway protocol (IGP).

    This example shows a dual stacking configuration with OSPF and OSPF version 3 configured on the interfaces.

  6. Configure a global PIM instance on the interface facing the edge device.

    PIM is not configured in the core.

  7. Configure the ingress replication provider tunnel to create a new unicast tunnel each time a destination needs to be added to the multicast distribution tree.

    Note:

    Alternatively, use the label-switched-path-template statement to configure a point-to-point LSP for the ingress tunnel.

    Configure the point-to-point LSP to use the default template settings (this is needed only when using RSVP tunnels). For example:

  8. Commit the configuration.

Results

From configuration mode, confirm your configuration by issuing the show protocols and show routing-instances command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

Confirm that the configuration is working properly. The following operational output is for LDP ingress replication SPT-only mode. The multicast source behind IP Router B. The multicast receiver is behind IP Router C.

Checking the Ingress Replication Status on Border Router C

Purpose

Use the show ingress-replication mvpn command to check the ingress replication status.

Action
Meaning

The ingress replication is using a point-to-point LSP, and is in the Up state.

Checking the Routing Table for the MVPN Routing Instance on Border Router C

Purpose

Use the show route table command to check the route status.

Action
Meaning

The expected routes are populating the test.mvpn routing table.

Checking the MVPN Neighbors on Border Router C

Purpose

Use the show mvpn neighbor command to check the neighbor status.

Action

Checking the PIM Join Status on Border Router C

Purpose

Use the show pim join extensive command to check the PIM join status.

Action

Checking the Multicast Route Status on Border Router C

Purpose

Use the show multicast route extensive command to check the multicast route status.

Action

Checking the Ingress Replication Status on Border Router B

Purpose

Use the show ingress-replication mvpn command to check the ingress replication status.

Action
Meaning

The ingress replication is using a point-to-point LSP, and is in the Up state.

Checking the Routing Table for the MVPN Routing Instance on Border Router B

Purpose

Use the show route table command to check the route status.

Action
Meaning

The expected routes are populating the test.mvpn routing table.

Checking the MVPN Neighbors on Border Router B

Purpose

Use the show mvpn neighbor command to check the neighbor status.

Action

Checking the PIM Join Status on Border Router B

Purpose

Use the show pim join extensive command to check the PIM join status.

Action

Checking the Multicast Route Status on Border Router B

Purpose

Use the show multicast route extensive command to check the multicast route status.

Action

Example: Configuring MBGP Multicast VPNs

This example provides a step-by-step procedure to configure multicast services across a multiprotocol BGP (MBGP) Layer 3 virtual private network. (also referred to as next-generation Layer 3 multicast VPNs)

Requirements

This example uses the following hardware and software components:

  • Junos OS Release 9.2 or later

  • Five M Series, T Series, TX Series, or MX Series Juniper routers

  • One host system capable of sending multicast traffic and supporting the Internet Group Management Protocol (IGMP)

  • One host system capable of receiving multicast traffic and supporting IGMP

Depending on the devices you are using, you might be required to configure static routes to:

  • The multicast sender

  • The Fast Ethernet interface to which the sender is connected on the multicast receiver

  • The multicast receiver

  • The Fast Ethernet interface to which the receiver is connected on the multicast sender

Overview and Topology

This example shows how to configure the following technologies:

  • IPv4

  • BGP

  • OSPF

  • RSVP

  • MPLS

  • PIM sparse mode

  • Static RP

Topology

The topology of the network is shown in Figure 4.

Figure 4: Multicast Over Layer 3 VPN Example TopologyMulticast Over Layer 3 VPN Example Topology

Configuration

Note:

In any configuration session, it is a good practice to periodically verify that the configuration can be committed using the commit check command.

In this example, the router being configured is identified using the following command prompts:

  • CE1 identifies the customer edge 1 (CE1) router

  • PE1 identifies the provider edge 1 (PE1) router

  • P identifies the provider core (P) router

  • CE2 identifies the customer edge 2 (CE2) router

  • PE2 identifies the provider edge 2 (PE2) router

To configure MBGP multicast VPNs for the network shown in Figure 4, perform the following steps:

Configuring Interfaces

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 CLI User Guide.

  1. On each router, configure an IP address on the loopback logical interface 0 (lo0.0).

    Use the show interfaces terse command to verify that the IP address is correct on the loopback logical interface.

  2. On the PE and CE routers, configure the IP address and protocol family on the Fast Ethernet interfaces. Specify the inet protocol family type.

    Use the show interfaces terse command to verify that the IP address is correct on the Fast Ethernet interfaces.

  3. On the PE and P routers, configure the ATM interfaces' VPI and maximum virtual circuits. If the default PIC type is different on directly connected ATM interfaces, configure the PIC type to be the same. Configure the logical interface VCI, protocol family, local IP address, and destination IP address.

    Use the show configuration interfaces command to verify that the ATM interfaces' VPI and maximum VCs are correct and that the logical interface VCI, protocol family, local IP address, and destination IP address are correct.

Configuring OSPF

Step-by-Step Procedure
  1. On the P and PE routers, configure the provider instance of OSPF. Specify the lo0.0 and ATM core-facing logical interfaces. The provider instance of OSPF on the PE router forms adjacencies with the OSPF neighbors on the other PE router and Router P.

    Use the show ospf interfaces command to verify that the lo0.0 and ATM core-facing logical interfaces are configured for OSPF.

  2. On the CE routers, configure the customer instance of OSPF. Specify the loopback and Fast Ethernet logical interfaces. The customer instance of OSPF on the CE routers form adjacencies with the neighbors within the VPN routing instance of OSPF on the PE routers.

    Use the show ospf interfaces command to verify that the correct loopback and Fast Ethernet logical interfaces have been added to the OSPF protocol.

  3. On the P and PE routers, configure OSPF traffic engineering support for the provider instance of OSPF.

    The shortcuts statement enables the master instance of OSPF to use a label-switched path as the next hop.

    Use the show ospf overview or show configuration protocols ospf command to verify that traffic engineering support is enabled.

Configuring BGP

Step-by-Step Procedure
  1. On Router P, configure BGP for the VPN. The local address is the local lo0.0 address. The neighbor addresses are the PE routers' lo0.0 addresses.

    The unicast statement enables the router to use BGP to advertise network layer reachability information (NLRI). The signaling statement enables the router to use BGP as the signaling protocol for the VPN.

    Use the show configuration protocols bgp command to verify that the router has been configured to use BGP to advertise NLRI.

  2. On the PE and P routers, configure the BGP local autonomous system number.

    Use the show configuration routing-options command to verify that the BGP local autonomous system number is correct.

  3. On the PE routers, configure BGP for the VPN. Configure the local address as the local lo0.0 address. The neighbor addresses are the lo0.0 addresses of Router P and the other PE router, PE2.

    Use the show bgp group command to verify that the BGP configuration is correct.

  4. On the PE routers, configure a policy to export the BGP routes into OSPF.

    Use the show policy bgp-to-ospf command to verify that the policy is correct.

Configuring RSVP

Step-by-Step Procedure
  1. On the PE routers, enable RSVP on the interfaces that participate in the LSP. Configure the Fast Ethernet and ATM logical interfaces.

  2. On Router P, enable RSVP on the interfaces that participate in the LSP. Configure the ATM logical interfaces.

    Use the show configuration protocols rsvp command to verify that the RSVP configuration is correct.

Configuring MPLS

Step-by-Step Procedure
  1. On the PE routers, configure an MPLS LSP to the PE router that is the LSP egress point. Specify the IP address of the lo0.0 interface on the router at the other end of the LSP. Configure MPLS on the ATM, Fast Ethernet, and lo0.0 interfaces.

    To help identify each LSP when troubleshooting, configure a different LSP name on each PE router. In this example, we use the name to-pe2 as the name for the LSP configured on PE1 and to-pe1 as the name for the LSP configured on PE2.

    Use the show configuration protocols mpls and show route label-switched-path to-pe1 commands to verify that the MPLS and LSP configuration is correct.

    After the configuration is committed, use the show mpls lsp name to-pe1 and show mpls lsp name to-pe2 commands to verify that the LSP is operational.

  2. On Router P, enable MPLS. Specify the ATM interfaces connected to the PE routers.

    Use the show mpls interface command to verify that MPLS is enabled on the ATM interfaces.

  3. On the PE and P routers, configure the protocol family on the ATM interfaces associated with the LSP. Specify the mpls protocol family type.

    Use the show mpls interface command to verify that the MPLS protocol family is enabled on the ATM interfaces associated with the LSP.

Configuring the VRF Routing Instance

Step-by-Step Procedure
  1. On the PE routers, configure a routing instance for the VPN and specify the vrf instance type. Add the Fast Ethernet and lo0.1 customer-facing interfaces. Configure the VPN instance of OSPF and include the BGP-to-OSPF export policy.

    Use the show configuration routing-instances vpn-a command to verify that the routing instance configuration is correct.

  2. On the PE routers, configure a route distinguisher for the routing instance. A route distinguisher allows the router to distinguish between two identical IP prefixes used as VPN routes. Configure a different route distinguisher on each PE router. This example uses 65010:1 on PE1 and 65010:2 on PE2.

    Use the show configuration routing-instances vpn-a command to verify that the route distinguisher is correct.

  3. On the PE routers, configure default VRF import and export policies. Based on this configuration, BGP automatically generates local routes corresponding to the route target referenced in the VRF import policies. This example uses 2:1 as the route target.

    Note:

    You must configure the same route target on each PE router for a given VPN routing instance.

    Use the show configuration routing-instances vpn-a command to verify that the route target is correct.

  4. On the PE routers, configure the VPN routing instance for multicast support.

    Use the show configuration routing-instance vpn-a command to verify that the VPN routing instance has been configured for multicast support.

  5. On the PE routers, configure an IP address on loopback logical interface 1 (lo0.1) used in the customer routing instance VPN.

    Use the show interfaces terse command to verify that the IP address on the loopback interface is correct.

Configuring PIM

Step-by-Step Procedure
  1. On the PE routers, enable PIM. Configure the lo0.1 and the customer-facing Fast Ethernet interface. Specify the mode as sparse and the version as 2.

    Use the show pim interfaces instance vpn-a command to verify that PIM sparse-mode is enabled on the lo0.1 interface and the customer-facing Fast Ethernet interface.

  2. On the CE routers, enable PIM. In this example, we configure all interfaces. Specify the mode as sparse and the version as 2.

    Use the show pim interfaces command to verify that PIM sparse mode is enabled on all interfaces.

Configuring the Provider Tunnel

Step-by-Step Procedure
  1. On Router PE1, configure the provider tunnel. Specify the multicast address to be used.

    The provider-tunnel statement instructs the router to send multicast traffic across a tunnel.

    Use the show configuration routing-instance vpn-a command to verify that the provider tunnel is configured to use the default LSP template.

  2. On Router PE2, configure the provider tunnel. Specify the multicast address to be used.

    Use the show configuration routing-instance vpn-a command to verify that the provider tunnel is configured to use the default LSP template.

Configuring the Rendezvous Point

Step-by-Step Procedure
  1. Configure Router PE1 to be the rendezvous point. Specify the lo0.1 address of Router PE1. Specify the multicast address to be used.

    Use the show pim rps instance vpn-a command to verify that the correct local IP address is configured for the RP.

  2. On Router PE2, configure the static rendezvous point. Specify the lo0.1 address of Router PE1.

    Use the show pim rps instance vpn-a command to verify that the correct static IP address is configured for the RP.

  3. On the CE routers, configure the static rendezvous point. Specify the lo0.1 address of Router PE1.

    Use the show pim rps command to verify that the correct static IP address is configured for the RP.

  4. Use the commit check command to verify that the configuration can be successfully committed. If the configuration passes the check, commit the configuration.

  5. Start the multicast sender device connected to CE1.

  6. Start the multicast receiver device connected to CE2.

  7. Verify that the receiver is receiving the multicast stream.

  8. Use show commands to verify the routing, VPN, and multicast operation.

Results

The configuration and verification parts of this example have been completed. The following section is for your reference.

The relevant sample configuration for Router CE1 follows.

Router CE1

The relevant sample configuration for Router PE1 follows.

Router PE1

The relevant sample configuration for Router P follows.

Router P

The relevant sample configuration for Router PE2 follows.

Router PE2

The relevant sample configuration for Router CE2 follows.

Router CE2

Example: Configuring a PIM-SSM Provider Tunnel for an MBGP MVPN

This example shows how to configure a PIM-SSM provider tunnel for an MBGP MVPN. The configuration enables service providers to carry customer data in the core. This example shows how to configure PIM-SSM tunnels as inclusive PMSI and uses the unicast routing preference as the metric for determining the single forwarder (instead of the default metric, which is the IP address from the global administrator field in the route-import community).

Requirements

Before you begin:

Overview

When a PE receives a customer join or prune message from a CE, the message identifies a particular multicast flow as belonging either to a source-specific tree (S,G) or to a shared tree (*,G). If the route to the multicast source or RP is across the VPN backbone, then the PE needs to identify the upstream multicast hop (UMH) for the (S,G) or (*,G) flow. Normally the UMH is determined by the unicast route to the multicast source or RP.

However, in some cases, the CEs might be distributing to the PEs a special set of routes that are to be used exclusively for the purpose of upstream multicast hop selection using the route-import community. More than one route might be eligible, and the PE needs to elect a single forwarder from the eligible UMHs.

The default metric for the single forwarder election is the IP address from the global administrator field in the route-import community. You can configure a router to use the unicast route preference to determine the single forwarder election.

This example includes the following settings.

  • provider-tunnel family inet pim-ssm group-address—Specifies a valid SSM VPN group address. The SSM VPN group address and the source address are advertised by the type-1 autodiscovery route. On receiving an autodiscovery route with the SSM VPN group address and the source address, a PE router sends an (S,G) join in the provider space to the PE advertising the autodiscovery route. All PE routers exchange their PIM-SSM VPN group address to complete the inclusive provider multicast service interface (I-PMSI). Unlike a PIM-ASM provider tunnel, the PE routers can choose a different VPN group address because the (S,G) joins are sent directly toward the source PE.

    Note:

    Similar to a PIM-ASM provider tunnel, PIM must be configured in the default master instance.

  • unicast-umh-election—Specifies that the PE router uses the unicast route preference to determine the single-forwarder election.

Topology

Figure 5 shows the topology used in this example.

Figure 5: PIM-SSM Provider Tunnel for an MBGP MVPN TopologyPIM-SSM Provider Tunnel for an MBGP MVPN 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, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

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 a PIM-SSM provider tunnel for an MBGP MVPN:

  1. Configure the interfaces in the master routing instance on the PE routers. This example shows the interfaces for one PE router.

  2. Configure the autonomous system number in the global routing options. This is required in MBGP MVPNs.

  3. Configure the routing protocols in the master routing instance on the PE routers.

  4. Configure routing instance VPN-A.

  5. Configure routing instance VPN-B.

  6. Configure the topology such that the BGP route to the source advertised by PE1 has a higher preference than the BGP route to the source advertised by PE2.

  7. Configure a higher primary loopback address on PE2 than on PE1. This ensures that PE2 is the MBGP MVPN single-forwarder election winner.

  8. Configure the unicast-umh-election statement on PE3.

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

Results

Confirm your configuration by entering the show interfaces, show protocols, show routing-instances, and show routing-options commands 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, start the receivers and the source. PE3 should create type-7 customer multicast routes from the local joins. Verify the source-tree customer multicast entries on all PE routers. PE3 should choose PE1 as the upstream PE toward the source. PE1 receives the customer multicast route from the egress PEs and forwards data on the PSMI to PE3.

To confirm the configuration, run the following commands:

  • show route table VPN-A.mvpn.0 extensive

  • show multicast route extensive instance VPN-A

Example: Allowing MBGP MVPN Remote Sources

This example shows how to configure an MBGP MVPN that allows remote sources, even when there is no PIM neighborship toward the upstream router.

Requirements

Before you begin:

Overview

In this example, a remote CE router is the multicast source. In an MBGP MVPN, a PE router has the PIM interface hello interval set to zero, thereby creating no PIM neighborship. The PIM upstream state is None. In this scenario, directly connected receivers receive traffic in the MBGP MVPN only if you configure the ingress PE’s upstream logical interface to accept remote sources. If you do not configure the ingress PE’s logical interface to accept remote sources, the multicast route is deleted and the local receivers are no longer attached to the flood next hop.

This example shows the configuration on the ingress PE router. A static LSP is used to receive traffic from the remote source.

Topology

Figure 6 shows the topology used in this example.

Figure 6: MBGP MVPN Remote SourceMBGP MVPN Remote Source

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.

Procedure

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 allow remote sources:

  1. On the ingress PE router, configure the interfaces in the routing instance.

  2. Configure the autonomous system number in the global routing options. This is required in MBGP MVPNs.

  3. Configure the route distinguisher and the VRF target.

  4. Configure the provider tunnel.

  5. Configure BGP in the routing instance.

  6. Configure PIM in the routing instance, including the accept-remote-source statement on the incoming logical interface.

  7. Enable the MVPN Protocol in the routing instance.

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

Results

From configuration mode, confirm your configuration by entering the 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.

Verification

To verify the configuration, run the following commands:

  • show mpls lsp p2mp

  • show multicast route instance vpn-A extensive

  • show mvpn c-multicast

  • show pim join instance vpn-A extensive

  • show route forwarding-table destination destination

  • show route table vpn-A.mvpn.0

Example: Configuring BGP Route Flap Damping Based on the MBGP MVPN Address Family

This example shows how to configure an multiprotocol BGP multicast VPN (also called Next-Generation MVPN) with BGP route flap damping.

Requirements

This example uses Junos OS Release 12.2. BGP route flap damping support for MBGP MVPN, specifically, and on an address family basis, in general, is introduced in Junos OS Release 12.2.

Overview

BGP route flap damping helps to diminish route instability caused by routes being repeatedly withdrawn and readvertised when a link is intermittently failing.

This example uses the default damping parameters and demonstrates an MBGP MVPN scenario with three provider edge (PE) routing devices, three customer edge (CE) routing devices, and one provider (P) routing device.

Topology

Figure 7 shows the topology used in this example.

Figure 7: MBGP MVPN with BGP Route Flap DampingMBGP MVPN with BGP Route Flap Damping

On PE Device R4, BGP route flap damping is configured for address family inet-mvpn. A routing policy called dampPolicy uses the nlri-route-type match condition to damp only MVPN route types 3, 4, and 5. All other MVPN route types are not damped.

This example shows the full configuration on all devices in the CLI Quick Configuration section. The Configuring Device R4 section shows the step-by-step configuration for PE Device R4.

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.

Device R1

Device R2

Device R3

Device R4

Device R5

Device R6

Device R7

Configuring Device R4

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

  1. Configure the interfaces.

  2. Configure MPLS and the signaling protocols on the interfaces.

  3. Configure BGP.

    The BGP configuration enables BGP route flap damping for the inet-mvpn address family. The BGP configuration also imports into the routing table the routing policy called dampPolicy. This policy is applied to neighbor PE Device R2.

  4. Configure an interior gateway protocol.

  5. Configure a damping policy that uses the nlri-route-type match condition to damp only MVPN route types 3, 4, and 5.

  6. Configure the damping policy to disable BGP route flap damping.

    The no-damp policy (damping no-damp disable) causes any damping state that is present in the routing table to be deleted. The then damping no-damp statement applies the no-damp policy as an action and has no from match conditions. Therefore, all routes that are not matched by term1 are matched by this term, with the result that all other MVPN route types are not damped.

  7. Configure the parent_vpn_routes to accept all other BGP routes that are not from the inet-mvpn address family.

    This policy is applied as an OSPF export policy in the routing instance.

  8. Configure the VPN routing and forwarding (VRF) instance.

  9. Configure the router ID and the autonomous system (AS) number.

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

Results

From configuration mode, confirm your configuration by entering the 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.

Verification

Confirm that the configuration is working properly.

Verifying That Route Flap Damping Is Disabled

Purpose

Verify the presence of the no-damp policy, which disables damping for MVPN route types other than 3, 4, and 5.

Action

From operational mode, enter the show policy damping command.

Meaning

The output shows that the default damping parameters are in effect and that the no-damp policy is also in effect for the specified route types.

Verifying Route Flap Damping

Purpose

Check whether BGP routes have been damped.

Action

From operational mode, enter the show bgp summary command.

Meaning

The Damp State field shows that zero routes in the bgp.mvpn.0 routing table have been damped. Further down, the last number in the State field shows that zero routes have been damped for BGP peer 172.16.1.2.

Example: Configuring MBGP Multicast VPN Topology Variations

This section describes how to configure multicast virtual private networks (MVPNs) using multiprotocol BGP (MBGP) (next-generation MVPNs).

Requirements

To implement multiprotocol BGP-based multicast VPNs, auto-RP, bootstrap router (BSR) RP, and PIM dense mode you need JUNOS Release 9.2 or later.

To implement multiprotocol BGP-based multicast VPNs, sender-only sites, and receiver-only sites you need JUNOS Release 8.4 or later.

Overview and Topology

You can configure PIM auto-RP, bootstrap router (BSR) RP, PIM dense mode, and mtrace for next generation multicast VPN networks. Auto-RP uses PIM dense mode to propagate control messages and establish RP mapping. You can configure an auto-RP node in one of three different modes: discovery mode, announce mode, and mapping mode. BSR is the IETF standard for RP establishment. A selected router in a network acts as a BSR, which selects a unique RP for different group ranges. BSR messages are flooded using the data tunnel between PE routers. When you enable PIM dense mode, data packets are forwarded to all interfaces except the incoming interface. Unlike PIM sparse mode, where explicit joins are required for data packets to be transmitted downstream, data packets are flooded to all routers in the routing instance in PIM dense mode.

This section shows you how to configure a MVPN using MBGP. If you have multicast VPNs based on draft-rosen, they will continue to work as before and are not affected by the configuration of MVPNs using MBGP.

The network configuration used for most of the examples in this section is shown in Figure 8.

Figure 8: MBGP MVPN Topology Variations DiagramMBGP MVPN Topology Variations Diagram

In the figure, two VPNs, VPN A and VPN B, are serviced by the same provider at several sites, two of which have CE routers for both VPN A and VPN B (site 2 is not shown). The PE routers are shown with VRF tables for the VPN CEs for which they have routing information. It is important to note that no multicast protocols are required between the PE routers on the network. The multicast routing information is carried by MBGP between the PE routers. There may be one or more BGP route reflectors in the network. Both VPNs operate independently and are configured separately.

Both the PE and CE routers run PIM sparse mode and maintain forwarding state information about customer source (C-S) and customer group (C-G) multicast components. CE routers still send a customer's PIM join messages (PIM C-Join) from CE to PE, and from PE to CE, as shown in the figure. But on the provider's backbone network, all multicast information is carried by MBGP. The only addition over and above the unicast VPN configuration normally used is the use of a special provider tunnel (provider-tunnel) for carrying PIM sparse mode message content between provider nodes on the network.

There are several scenarios for MVPN configuration using MBGP, depending on whether a customer site has senders (sources) of multicast traffic, has receivers of multicast traffic, or a mixture of senders and receivers. MVPNs can be:

  • A full mesh (each MVPN site has both senders and receivers)

  • A mixture of sender-only and receiver-only sites

  • A mixture of sender-only, receiver-only, and sender-receiver sites

  • A hub and spoke (two interfaces between hub PE and hub CE, and all spokes are sender-receiver sites)

Each type of MVPN differs more in the configuration VPN statements than the provider tunnel configuration. For information about configuring VPNs, see the Junos OS VPNs Library for Routing Devices.

Configuring Full Mesh MBGP MVPNs

This example describes how to configure a full mesh MBGP MVPN:

Configuration Steps

Step-by-Step Procedure

In this example, PE-1 connects to VPN A and VPN B at site 1, PE-4 connects to VPN A at site 4, and PE-2 connects to VPN B at site 3. To configure a full mesh MVPN for VPN A and VPN B, perform the following steps:

  1. Configure PE-1 (both VPN A and VPN B at site 1):

  2. Configure PE-4 (VPN A at site 4):

  3. Configure PE-2 (VPN B at site 3):

Configuring Sender-Only and Receiver-Only Sites Using PIM ASM Provider Tunnels

This example describes how to configure an MBGP MVPN with a mixture of sender-only and receiver-only sites using PIM-ASM provider tunnels.

Configuration Steps

Step-by-Step Procedure

In this example, PE-1 connects to VPN A (sender-only) and VPN B (receiver-only) at site 1, PE-4 connects to VPN A (receiver-only) at site 4, and PE-2 connects to VPN A (receiver-only) and VPN B (sender-only) at site 3.

To configure an MVPN for a mixture of sender-only and receiver-only sites on VPN A and VPN B, perform the following steps:

  1. Configure PE-1 (VPN A sender-only and VPN B receiver-only at site 1):

  2. Configure PE-4 (VPN A receiver-only at site 4):

  3. Configure PE-2 (VPN A receiver-only and VPN B sender-only at site 3):

Configuring Sender-Only, Receiver-Only, and Sender-Receiver MVPN Sites

This example describes how to configure an MBGP MVPN with a mixture of sender-only, receiver-only, and sender-receiver sites.

Configuration Steps

Step-by-Step Procedure

In this example, PE-1 connects to VPN A (sender-receiver) and VPN B (receiver-only) at site 1, PE-4 connects to VPN A (receiver-only) at site 4, and PE-2 connects to VPN A (sender-only) and VPN B (sender-only) at site 3. To configure an MVPN for a mixture of sender-only, receiver-only, and sender-receiver sites for VPN A and VPN B, perform the following steps:

  1. Configure PE-1 (VPN A sender-receiver and VPN B receiver-only at site 1):

  2. Configure PE-4 (VPN A receiver-only at site 4):

  3. Configure PE-2 (VPN-A sender-only and VPN-B sender-only at site 3):

Configuring Hub-and-Spoke MVPNs

This example describes how to configure an MBGP MVPN in a hub and spoke topology.

Configuration Steps

Step-by-Step Procedure

In this example, which only configures VPN A, PE-1 connects to VPN A (spoke site) at site 1, PE-4 connects to VPN A (hub site) at site 4, and PE-2 connects to VPN A (spoke site) at site 3. Current support is limited to the case where there are two interfaces between the hub site CE and PE. To configure a hub-and-spoke MVPN for VPN A, perform the following steps:

  1. Configure PE-1 for VPN A (spoke site):

  2. Configure PE-4 for VPN A (hub site):

  3. Configure PE-2 for VPN A (spoke site):

Configuring Nonstop Active Routing for BGP Multicast VPN

BGP multicast virtual private network (MVPN) is a Layer 3 VPN application that is built on top of various unicast and multicast routing protocols such as Protocol Independent Multicast (PIM), BGP, RSVP, and LDP. Enabling nonstop active routing (NSR) for BGP MVPN requires that NSR support is enabled for all these protocols.

Before you begin:

The state maintained by MVPN includes MVPN routes, cmcast, provider-tunnel, and forwarding information. BGP MVPN NSR synchronizes this MVPN state between the primary and backup Routing Engines. While some of the state on the backup Routing Engine is locally built based on the configuration, most of it is built based on triggers from other protocols that MVPN interacts with. The triggers from these protocols are in turn the result of state replication performed by these modules. This includes route change notifications by unicast protocols, join and prune triggers from PIM, remote MVPN route notification by BGP, and provider-tunnel related notifications from RSVP and LDP.

Configuring NSR and unified in-service software upgrade (ISSU) support to the BGP MVPN protocol provides features such as various provider tunnel types, different MVPN modes (source tree, shared-tree), and PIM features. As a result, at the ingress PE, replication is turned on for dynamic LSPs. Thus, when NSR is configured, the state for dynamic LSPs is also replicated to the backup Routing Engine. After the state is resolved on the backup Routing Engine, RSVP sends required notifications to MVPN.

To enable BGP MVPN NSR support, the advertise-from-main-vpn-tables configuration statement needs to be configured at the [edit protocols bgp] hierarchy level.

Nonstop active routing configurations include two Routing Engines that share information so that routing is not interrupted during Routing Engine failover. When NSR is configured on a dual Routing Engine platform, the PIM control state is replicated on both Routing Engines.

This PIM state information includes:

  • Neighbor relationships

  • Join and prune information

  • RP-set information

  • Synchronization between routes and next hops and the forwarding state between the two Routing Engines

Junos OS supports NSR in the following PIM scenarios:

  • Dense mode

  • Sparse mode

  • SSM

  • Static RP

  • Auto-RP (for IPv4 only)

  • Bootstrap router

  • Embedded RP on the non-RP router (for IPv6 only)

  • BFD support

  • Draft Rosen multicast VPNs and BGP multicast VPNs

  • Policy features such as neighbor policy, bootstrap router export and import policies, scope policy, flow maps, and reverse path forwarding (RPF) check policies

To configure nonstop active routing:

  1. Because NSR requires you to configure graceful Routing Engine switchover (GRES), to enable GRES, include the graceful-switchover statement at the [edit chassis redundancy] hierarchy level.
  2. Include the synchronize statement at the [edit system] hierarchy level so that configuration changes are synchronized on both Routing Engines.
  3. Configure PIM settings on the desingated routerwith sparse mode and version, and static address pointing to the rendezvous points.

    For example, to set sparse mode, version 2 and static address:

  4. Configure per-packet load balancing on the designated router.

    For example, to set load-balance policy:

  5. Apply the load-balance policy on the designated router.
  6. Configure nonstop active routing on the designated router.

    For example, to set nonstop active routing on the designated router with address 10.210.255.201:

Release History Table
Release
Description
15.1X49-D50
Starting in Junos OS Release 15.1X49-D50 and Junos OS Release 17.3R1, the vrf-table-label statement allows mapping of the inner label to a specific Virtual Routing and Forwarding (VRF). This mapping allows examination of the encapsulated IP header at an egress VPN router. For SRX Series Firewalls, the vrf-table-label statement is currently supported only on physical interfaces. As a workaround, deactivate vrf-table-label or use physical interfaces.