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

• 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
• 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.
• Configure a BGP-MVPN control plane. See MBGP-Based Multicast VPN Trees in the Multicast Protocols Configuration Guide.
• Configure LDP as the signaling protocol on all P2MP provider and provider-edge routers. See LDP Operation in the Junos OS MPLS Applications Configuration 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 Configuration 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 and Junos Services Interfaces Configuration Guide in the in the Junos Services Interfaces Configuration Release 11.2.
• 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 and Junos Services Interfaces Configuration Guide in the Junos Services Interfaces Configuration Release 11.2.
• 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 S. 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.

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

  

Overview

This example shows how to configure P2MP LSP LSPs 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.

Figure 2 shows the topology used in this example.

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

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

Step-by-Step Procedure

1. Configure LDP on all routers.

   [edit protocols ldp]user@host# set interface fe-0/2/1.0user@host# set interface fe-0/2/3.0user@host# set p2mp

2. Configure the provider tunnel.

   [edit routing-instance red ]user@host# set instance-type mvpnuser@host# set interface vt-0/1/0.1user@host# set interface lo0.1user@host# set route-distinguisher 10.254.1.1:1user@host# set provider-tunnel ldp-p2mp

3. Configure the selective provider tunnel.

   user@host# set provider-tunnel selective group 224.1.1.1/32 source 192.168.1.1/32 ldp-p2mp

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

   user@host# commit

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

• 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
• Overview
• Configuration

Requirements

The routers used in this example are Juniper Networks M Series Multiservice Edge Routers, T Series Core Routers, or MX Series 3D Universal Edge Routers. 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—When this statement is configured, an LSP template is used for the for the point-to-multipoint LSP for ingress replication.

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 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 routing instance type for IM-A to be mpls-internet-multicast.
   [edit routing-instances]

   user@host# set IM-A instance-type mpls-internet-multicast
2. 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.
   [edit routing-instances]

   user@host# set IM-A provider-tunnel ingress-replication create-new-ucast-tunnel

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

3. Configure the point-to-point LSP to use the default template settings (this is needed only when using RSVP tunnels).
   [edit routing-instances]

   user@host# set IM-A provider-tunnel ingress-replication label-switched-path label-switched-path-template default-template
4. Configure selective ingress replication provider tunnels.
   [edit routing-instances]

   user@host# set IM-A provider-tunnel selective group 232.1.1.1/32 source 192.168.195.145/32 ingress-replication label-switched-path
5. Configure the MVPN Protocol in the routing instance.
   [edit routing-instances]

   user@host# set IM-A protocols mvpn

   user@host# up
6. Add the mpls-internet-multicast configuration statement under the [edit protocols pim] hierarchy level in the master instance.
   [edit protocols]

   user@host# set pim mpls-internet-multicast
7. Commit the configuration.
   [edit]

   user@host# commit
8. Use the show ingress-replication mvpn command to check the ingress replication status.
   [edit]

   user@host# run show ingress-replication mvpn

   Ingress Tunnel: mvpn:1
     Application: MVPN
     Unicast tunnels
       Leaf Address       Tunnel-type       Mode       State
       10.255.245.2         P2P LSP           New        Up
       10.255.245.4         P2P LSP           New        Up
   

9. Use the show mvpn instance command to show the ingress replication tunnel type.
   [edit]

   user@host# run show mvpn instance IM-A

   MVPN instance:  
   Legend for provider tunnel 
   I-P-tnl -- inclusive provider tunnel S-P-tnl -- selective provider tunnel  
   
   Legend for c-multicast routes properties (Pr) 
   DS -- derived from (*, c-g)          RM -- remote VPN route 
   Instance : IM-A
      MVPN Mode : SPT-ONLY
      Provider tunnel: S-P-tnl:INGRESS-REPLICATION:MPLS Label 18:10.255.245.6
      Neighbor               S-P-tnl
      10.255.245.2           INGRESS-REPLICATION:MPLS Label 22:10.255.245.2
      10.255.245.7           INGRESS-REPLICATION:MPLS Label 19:10.255.245.7
   
   

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.

• Requirements
• Overview and Topology
• Configuration

Requirements

• 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 systems capable of receiving multicast traffic and supporting IGMP

• 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

• IPv4
• BGP
• OSPF
• RSVP
• MPLS
• PIM sparse mode
• Static RP

The topology of the network is shown in Figure 4.

Figure 4: Multicast 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.

• 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
• Configuring OSPF
• Configuring BGP
• Configuring RSVP
• Configuring MPLS
• Configuring the VRF Routing Instance
• Configuring PIM
• Configuring the Provider Tunnel
• Configuring the Rendezvous Point
• Results

Configuring Interfaces

Step-by-Step Procedure

1. On each router, configure an IP address on the loopback logical interface 0 (lo0.0).
   [edit interfaces]user@CE1# set lo0 unit 0 family inet address 192.168.6.1/32 primary
   user@PE1# set lo0 unit 0 family inet address 192.168.7.1/32 primary
   user@P# set lo0 unit 0 family inet address 192.168.8.1/32 primary
   user@PE2# set lo0 unit 0 family inet address 192.168.9.1/32 primary
   user@CE2# set lo0 unit 0 family inet address 192.168.0.1/32 primary

   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.
   [edit interfaces]user@CE1# set fe-1/3/0 unit 0 family inet address 10.10.12.1/24user@CE1# set fe-0/1/0 unit 0 family inet address 10.0.67.13/30
   [edit interfaces]user@PE1# set fe-0/1/0 unit 0 family inet address 10.0.67.14/30
   [edit interfaces]user@PE2# set fe-0/1/0 unit 0 family inet address 10.0.90.13/30
   [edit interfaces]user@CE2# set fe-0/1/0 unit 0 family inet address 10.0.90.14/30user@CE2# set fe-1/3/0 unit 0 family inet address 10.10.11.1/24

   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.
   [edit interfaces]user@PE1# set at-0/2/0 atm-options pic-type atm1 user@PE1# set at-0/2/0 atm-options vpi 0 maximum-vcs 256user@PE1# set at-0/2/0 unit 0 vci 0.128user@PE1# set at-0/2/0 unit 0 family inet address 10.0.78.5/32 destination 10.0.78.6
   [edit interfaces]user@P# set at-0/2/0 atm-options pic-type atm1user@P# set at-0/2/0 atm-options vpi 0 maximum-vcs 256user@P# set at-0/2/0 unit 0 vci 0.128user@P# set at-0/2/0 unit 0 family inet address 10.0.78.6/32 destination 10.0.78.5user@P# set at-0/2/1 atm-options pic-type atm1user@P# set at-0/2/1 atm-options vpi 0 maximum-vcs 256user@P# set at-0/2/1 unit 0 vci 0.128user@P# set at-0/2/1 unit 0 family inet address 10.0.89.5/32 destination 10.0.89.6
   [edit interfaces]user@PE2# set at-0/2/1 atm-options pic-type atm1user@PE2# set at-0/2/1 atm-options vpi 0 maximum-vcs 256user@PE2# set at-0/2/1 unit 0 vci 0.128user@PE2# set at-0/2/1 unit 0 family inet address 10.0.89.6/32 destination 10.0.89.5

   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.
   user@PE1# set protocols ospf area 0.0.0.0 interface at-0/2/0.0user@PE1# set protocols ospf area 0.0.0.0 interface lo0.0
   user@P# set protocols ospf area 0.0.0.0 interface lo0.0user@P# set protocols ospf area 0.0.0.0 interface alluser@P# set protocols ospf area 0.0.0.0 interface fxp0 disable
   user@PE2# set protocols ospf area 0.0.0.0 interface lo0.0user@PE2# set protocols ospf area 0.0.0.0 interface at-0/2/1.0

   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.
   user@CE1# set protocols ospf area 0.0.0.0 interface fe-0/1/0.0user@CE1# set protocols ospf area 0.0.0.0 interface fe-1/3/0.0user@CE1# set protocols ospf area 0.0.0.0 interface lo0.0
   user@CE2# set protocols ospf area 0.0.0.0 interface fe-0/1/0.0user@CE2# set protocols ospf area 0.0.0.0 interface fe-1/3/0.0user@CE2# set protocols ospf area 0.0.0.0 interface lo0.0

   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.

   user@PE1# set protocols ospf traffic-engineering shortcuts
   user@P# set protocols ospf traffic-engineering shortcuts
   user@PE2# set protocols ospf traffic-engineering shortcuts

   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.

   user@P# set protocols bgp group group-mvpn type internaluser@P# set protocols bgp group group-mvpn local-address 192.168.8.1user@P# set protocols bgp group group-mvpn family inet unicastuser@P# set protocols bgp group group-mvpn family inet-mvpn signalinguser@P# set protocols bgp group group-mvpn neighbor 192.168.9.1user@P# set protocols bgp group group-mvpn neighbor 192.168.7.1

   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.
   user@PE1# set routing-options autonomous-system 0.65010
   user@P# set routing-options autonomous-system 0.65010
   user@PE2# set routing-options autonomous-system 0.65010

   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.
   user@PE1# set protocols bgp group group-mvpn type internaluser@PE1# set protocols bgp group group-mvpn local-address 192.168.7.1user@PE1# set protocols bgp group group-mvpn family inet-vpn unicastuser@PE1# set protocols bgp group group-mvpn family inet-mvpn signalinguser@PE1# set protocols bgp group group-mvpn neighbor 192.168.9.1user@PE1# set protocols bgp group group-mvpn neighbor 192.168.8.1
   user@PE2# set protocols bgp group group-mvpn type internaluser@PE2# set protocols bgp group group-mvpn local-address 192.168.9.1user@PE2# set protocols bgp group group-mvpn family inet-vpn unicastuser@PE2# set protocols bgp group group-mvpn family inet-mvpn signalinguser@PE2# set protocols bgp group group-mvpn neighbor 192.168.7.1user@PE2# set protocols bgp group group-mvpn neighbor 192.168.8.1

   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.
   user@PE1# set policy-options policy-statement bgp-to-ospf from protocol bgpuser@PE1# set policy-options policy-statement bgp-to-ospf then accept
   user@PE2# set policy-options policy-statement bgp-to-ospf from protocol bgpuser@PE2# set policy-options policy-statement bgp-to-ospf then accept

   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.
   user@PE1# set protocols rsvp interface fe-0/1/0.0user@PE1# set protocols rsvp interface at-0/2/0.0
   user@PE2# set protocols rsvp interface fe-0/1/0.0 user@PE2# set protocols rsvp interface at-0/2/1.0
2. On Router P, enable RSVP on the interfaces that participate in the LSP. Configure the ATM logical interfaces.
   user@P# set protocols rsvp interface at-0/2/0.0user@P# set protocols rsvp interface at-0/2/1.0

   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.

   user@PE1# set protocols mpls label-switched-path to-pe2 to 192.168.9.1user@PE1# set protocols mpls interface fe-0/1/0.0user@PE1# set protocols mpls interface at-0/2/0.0user@PE1# set protocols mpls interface lo0.0
   user@PE2# set protocols mpls label-switched-path to-pe1 to 192.168.7.1user@PE2# set protocols mpls interface fe-0/1/0.0user@PE2# set protocols mpls interface at-0/2/1.0user@PE2# set protocols mpls interface lo0.0

   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.
   user@P# set protocols mpls interface at-0/2/0.0user@P# set protocols mpls interface at-0/2/1.0

   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.
   user@PE1# set interfaces at-0/2/0 unit 0 family mpls
   user@P# set interfaces at-0/2/0 unit 0 family mplsuser@P# set interfaces at-0/2/1 unit 0 family mpls
   user@PE2# set interfaces at-0/2/1 unit 0 family mpls

   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.
   user@PE1# set routing-instances vpn-a instance-type vrfuser@PE1# set routing-instances vpn-a interface lo0.1user@PE1# set routing-instances vpn-a interface fe-0/1/0.0user@PE1# set routing-instances vpn-a protocols ospf export bgp-to-ospfuser@PE1# set routing-instances vpn-a protocols ospf area 0.0.0.0 interface all
   user@PE2# set routing-instances vpn-a instance-type vrfuser@PE2# set routing-instances vpn-a interface lo0.1user@PE2# set routing-instances vpn-a interface fe-0/1/0.0user@PE2# set routing-instances vpn-a protocols ospf export bgp-to-ospfuser@PE2# set routing-instances vpn-a protocols ospf area 0.0.0.0 interface all

   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.
   user@PE1# set routing-instances vpn-a route-distinguisher 65010:1
   user@PE2# set routing-instances vpn-a route-distinguisher 65010:2

   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.

   user@PE1# set routing-instances vpn-a vrf-target target:2:1
   user@PE2# set routing-instances vpn-a vrf-target target:2:1

   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.
   user@PE1# set routing-instances vpn-a protocols mvpn
   user@PE2# set routing-instances vpn-a protocols mvpn

   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.
   user@PE1# set interfaces lo0 unit 1 family inet address 10.10.47.101/32
   user@PE2# set interfaces lo0 unit 1 family inet address 10.10.47.100/32

   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 and P routers, enable the provider instance of PIM. Add the core-facing ATM interfaces. On the PE routers, also configure the lo0.0 interface. Specify the mode as sparse and the version as 2.
   user@PE1# set protocols pim interface at-0/2/0.0 mode sparse user@PE1# set protocols pim interface at-0/2/0.0 version 2user@PE1# set protocols pim interface lo0.0 mode sparseuser@PE1# set protocols pim interface lo0.0 version 2
   user@P# set protocols pim interface at-0/2/0.0 mode sparse user@P# set protocols pim interface at-0/2/0.0 version 2user@P# set protocols pim interface at-0/2/1.0 mode sparseuser@P# set protocols pim interface at-0/2/1.0 version 2
   user@PE2# set protocols pim interface at-0/2/1.0 mode sparse user@PE2# set protocols pim interface at-0/2/1.0 version 2user@PE2# set protocols pim interface lo0.0 mode sparseuser@PE2# set protocols pim interface lo0.0 version 2

   Use the show pim interfaces command to verify that PIM sparse-mode is enabled on the core-facing ATM interfaces.

2. On the PE routers, enable the VPN customer instance of PIM. Configure the lo0.1 and the customer-facing Fast Ethernet interface. Specify the mode as sparse and the version as 2.
   user@PE1# set routing-instances vpn-a protocols pim interface lo0.1 mode sparse user@PE1# set routing-instances vpn-a protocols pim interface lo0.1 version 2 user@PE1# set routing-instances vpn-a protocols pim interface fe-0/1/0.0 mode sparseuser@PE1# set routing-instances vpn-a protocols pim interface fe-0/1/0.0 version 2
   user@PE2# set routing-instances vpn-a protocols pim interface lo0.1 mode sparse user@PE2# set routing-instances vpn-a protocols pim interface lo0.1 version 2 user@PE2# set routing-instances vpn-a protocols pim interface fe-0/1/0.0 mode sparseuser@PE2# set routing-instances vpn-a protocols pim interface fe-0/1/0.0 version 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.

3. On the CE routers, enable the customer instance of PIM. In this example, we configure all interfaces. Specify the mode as sparse and the version as 2.
   user@CE1# set protocols pim interface all
   user@CE2# set protocols pim interface all mode sparseuser@CE2# set protocols pim interface all version 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. The pim-asm statement instructs the router to accept the multicast stream from any source.

   user@PE1# set routing-instances vpn-a provider-tunnel pim-asm group-address 224.1.1.1

   Use the show configuration routing-instance vpn-a command to verify that the multicast group address is correct on Router PE1.

2. On Router PE2, configure the provider tunnel. Specify the multicast address to be used.
   user@PE2# set routing-instances vpn-a provider-tunnel pim-asm group-address 224.1.1.1

   Use the show configuration routing-instance vpn-a command to verify that the multicast group address is correct on Router PE2.

Configuring the Rendezvous Point

Step-by-Step Procedure

1. Configure Router PE1 to be the rendezvous point for the provider instance of PIM. Specify the lo0.0 address of Router PE1.
   user@PE1# set protocols pim rp local address 192.168.7.1

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

2. Configure the static rendezvous point on Router P and the PE2 router for the provider instance of PIM. Specify the lo0.0 address of Router PE1. Specify the version as 2.
   user@P# set protocols pim rp static address 192.168.7.1 version 2
   user@PE2# set protocols pim rp static address 192.168.7.1 version 2

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

3. Configure Router PE1 to be the rendezvous point for the customer instance of PIM. Specify the lo0.1 address of Router PE1. Specify the multicast address to be used.
   user@PE1# set routing-instances vpn-a protocols pim rp local address 10.10.47.101user@PE1# set routing-instances vpn-a protocols pim rp local group-ranges 224.1.1.1/32

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

4. On Router PE2, configure the static rendezvous point for the customer instance of PIM. Specify the lo0.1 address of Router PE1.
   user@PE2# set routing-instances vpn-a protocols pim rp static address 10.10.47.101

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

5. On the CE routers, configure the static rendezvous point for the customer instance of PIM. Specify the lo0.1 address of Router PE1.
   user@CE1# set protocols pim rp static address 10.10.47.101 version 2
   user@CE2# set protocols pim rp static address 10.10.47.101 version 2

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

6. Use the commit check command to verify that the configuration can be successfully committed. If the configuration passes the check, commit the configuration.
7. Start the multicast sender device connected to CE1.
8. Start the multicast receiver device connected to CE2.
9. Verify that the receiver is receiving the multicast stream.
10. 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.

The relevant sample configuration for Router PE1 follows.

The relevant sample configuration for Router P follows.

The relevant sample configuration for Router PE2 follows.

The relevant sample configuration for Router CE2 follows.

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
• Overview
• Configuration
• Verification

Requirements

Before you begin:

• Configure the router interfaces. See the Junos® OS Network Interfaces.
• Configure the BGP-to-OSPF routing policy. See the Routing Policy Configuration Guide.

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.

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

Figure 5 shows the topology used in this example.

Figure 5: PIM-SSM Provider Tunnel for an MBGP MVPN 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 interfaces in the master routing instance on the PE routers. This example shows the interfaces for one PE router.

   [edit interfaces]user@host# set fe-0/2/0 unit 0 family inet address 192.168.195.109/30user@host# set fe-0/2/1 unit 0 family inet address 192.168.195.5/27user@host# set fe-0/2/2 unit 0 family inet address 20.10.1.1/30user@host# set fe-0/2/2 unit 0 family isouser@host# set fe-0/2/2 unit 0 family mplsuser@host# set lo0 unit 1 family inet address 10.10.47.100/32user@host# set lo0 unit 2 family inet address 10.10.48.100/32

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

   [edit routing-options]user@host# set autonomous-system 100

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

   user@host# set protocols mpls interface all
   [edit protocols bgp group ibgp]user@host# set type internaluser@host# set family inet-vpn anyuser@host# set family inet-mvpn signalinguser@host# set neighbor 10.255.112.155
   [edit protocols isis]user@host# set level 1 disableuser@host# set interface alluser@host# set interface fxp0.0 disable
   [edit protocols ospf]user@host# set traffic-engineeringuser@host# set area 0.0.0.0 interface alluser@host# set area 0.0.0.0 interface fxp0.0 disable
   user@host# set protocols ldp interface all
   [edit protocols pim]user@host# set rp static address 10.255.112.155user@host# set interface all mode sparse-denseuser@host# set interface all version 2user@host# set interface fxp0.0 disable

4. Configure routing instance VPN-A.

   [edit routing-instances VPN-A]user@host# set instance-type vrfuser@host# set interface fe-0/2/1.0user@host# set interface lo0.1user@host# set route-distinguisher 10.255.112.199:100user@host# set provider-tunnel pim-ssm group-address 232.1.1.1user@host# set vrf-target target:100:100user@host# set vrf-table-labeluser@host# set routing-options auto-exportuser@host# set protocols ospf export bgp-to-ospfuser@host# set protocols ospf area 0.0.0.0 interface lo0.1user@host# set protocols ospf area 0.0.0.0 interface fe-0/2/1.0user@host# set protocols pim rp static address 10.10.47.101user@host# set protocols pim interface lo0.1 mode sparse-denseuser@host# set protocols pim interface lo0.1 version 2user@host# set protocols pim interface fe-0/2/1.0 mode sparse-denseuser@host# set protocols pim interface fe-0/2/1.0 version 2user@host# set protocols mvpn

5. Configure routing instance VPN-B.

   [edit routing-instances VPN-B]user@host# set instance-type vrfuser@host# set interface fe-0/2/0.0user@host# set interface lo0.2user@host# set route-distinguisher 10.255.112.199:200user@host# set provider-tunnel pim-ssm group-address 232.2.2.2user@host# set vrf-target target:200:200user@host# set vrf-table-labeluser@host# set routing-options auto-exportuser@host# set protocols ospf export bgp-to-ospfuser@host# set protocols ospf area 0.0.0.0 interface lo0.2user@host# set protocols ospf area 0.0.0.0 interface fe-0/2/0.0user@host# set protocols pim rp static address 10.10.48.101user@host# set protocols pim interface lo0.2 mode sparse-denseuser@host# set protocols pim interface lo0.2 version 2user@host# set protocols pim interface fe-0/2/0.0 mode sparse-denseuser@host# set protocols pim interface fe-0/2/0.0 version 2user@host# set protocols mvpn

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.

   [edit protocols bgp]user@host# set group ibgp local-preference 120

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

   [edit]user@host# set interface lo0 unit 1 family inet address 1.1.1.1/32 primary

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

   [edit]user@host# set routing-instances VPN-A protocols mvpn unicast-umh-electionuser@host# set routing-instances VPN-B protocols mvpn unicast-umh-election

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

   user@host# commit

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

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
• 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.
• Configure the point-to-multipoint static LSP. See Configuring Point-to-Multipoint LSPs for an MBGP MVPN.

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.

Figure 6 shows the topology used in this example.

Figure 6: MBGP 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.

Step-by-Step Procedure

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

   [edit routing-instances vpn-A]user@host# set instance-type vrf user@host# set interface ge-1/0/0.213 user@host# set interface ge-1/0/0.484 user@host# set interface ge-1/0/1.200 user@host# set interface ge-1/0/2.0 user@host# set interface ge-1/0/7.0 user@host# set interface vt-1/1/0.0

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

   user@host# set routing-options autonomous-system 100

3. Configure the route distinguisher and the VRF target.

   [edit routing-instances vpn-A]user@host# set route-distinguisher 10.0.0.10:04 user@host# set vrf-target target:65000:04

4. Configure the provider tunnel.

   [edit routing-instances vpn-A]user@host# set provider-tunnel rsvp-te label-switched-path-template mvpn-dynamic user@host# set provider-tunnel selective group 224.0.9.0/32 source 10.1.1.2/32 rsvp-te static-lsp mvpn-static

5. Configure BGP in the routing instance.

   [edit routing-instances vpn-A]user@host# set protocols bgp group 1a type external user@host# set protocols bgp group 1a peer-as 65213 user@host# set protocols bgp group 1a neighbor 10.2.213.9

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

   [edit routing-instances vpn-A]user@host# set protocols pim interface all hello-interval 0 user@host# set protocols pim interface ge-1/0/2.0 accept-remote-source

7. Enable the MVPN Protocol in the routing instance.

   [edit routing-instances vpn-A]user@host# set protocols mvpn

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

   user@host# commit

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

• 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
• Overview
• Configuration
• Verification

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.

Figure 7 shows the topology used in this example.

Figure 7: MBGP 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.

Configuring Device R4

Step-by-Step Procedure

1. Configure the interfaces.

   [edit interfaces]user@R4# set ge-1/2/0 unit 10 family inet address 10.1.1.10/30user@R4# set ge-1/2/0 unit 10 family mplsuser@R4# set ge-1/2/1 unit 17 family inet address 10.1.1.17/30user@R4# set ge-1/2/1 unit 17 family mplsuser@R4# set vt-1/2/0 unit 4 family inetuser@R4# set lo0 unit 4 family inet address 1.1.1.4/32user@R4# set lo0 unit 104 family inet address 100.1.1.4/32

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

   [edit protocols]user@R4# set mpls interface alluser@R4# set mpls interface ge-1/2/0.10user@R4# set rsvp interface all aggregateuser@R4# set ldp interface ge-1/2/0.10user@R4# set ldp p2mp

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.

   [edit protocols bgp group ibgp]user@R4# set type internaluser@R4# set local-address 1.1.1.4user@R4# set family inet-vpn unicastuser@R4# set family inet-vpn anyuser@R4# set family inet-mvpn signaling dampinguser@R4# set neighbor 1.1.1.2 import dampPolicyuser@R4# set neighbor 1.1.1.5

4. Configure an interior gateway protocol.

   [edit protocols ospf]user@R4# set traffic-engineering[edit protocols ospf area 0.0.0.0]user@R4# set interface alluser@R4# set interface lo0.4 passiveuser@R4# set interface ge-1/2/0.10

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

   [edit policy-options policy-statement dampPolicy term term1]user@R4# set from family inet-mvpnuser@R4# set from nlri-route-type 3user@R4# set from nlri-route-type 4user@R4# set from nlri-route-type 5user@R4# set then accept

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.

   [edit policy-options policy-statement dampPolicy]user@R4# set then damping no-dampuser@R4# set then accept[edit policy-options]user@R4# set damping no-damp disable

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.

   [edit policy-options policy-statement parent_vpn_routes]user@R4# set from protocol bgpuser@R4# set then accept

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

   [edit routing-instances vpn-1]user@R4# set instance-type vrfuser@R4# set interface vt-1/2/0.4user@R4# set interface ge-1/2/1.17user@R4# set interface lo0.104user@R4# set route-distinguisher 100:100user@R4# set vrf-target target:1:1user@R4# set protocols ospf export parent_vpn_routesuser@R4# set protocols ospf area 0.0.0.0 interface lo0.104 passiveuser@R4# set protocols ospf area 0.0.0.0 interface ge-1/2/1.17user@R4# set protocols pim rp static address 100.1.1.2user@R4# set protocols pim interface ge-1/2/1.17 mode sparseuser@R4# set protocols mvpn

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

   [edit routing-instances vpn-A]user@R4# set routing-options router-id 1.1.1.4user@R4# set routing-options autonomous-system 1001

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

    user@R4# commit

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, 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
• Verifying Route Flap Damping

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.

Default damping information:
  Halflife: 15 minutes
  Reuse merit: 750 Suppress/cutoff merit: 3000
  Maximum suppress time: 60 minutes
  Computed values:
    Merit ceiling: 12110
    Maximum decay: 6193
Damping information for "no-damp":
  Damping disabled

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.

Groups: 1 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
bgp.l3vpn.0          
                       6          6          0          0          0          0
bgp.l3vpn.2          
                       0          0          0          0          0          0
bgp.mvpn.0           
                       2          2          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
1.1.1.2                1001       3159       3155       0       0    23:43:47 Establ
  bgp.l3vpn.0: 3/3/3/0
  bgp.l3vpn.2: 0/0/0/0
  bgp.mvpn.0: 1/1/1/0
  vpn-1.inet.0: 3/3/3/0
  vpn-1.mvpn.0: 1/1/1/0
1.1.1.5                1001       3157       3154       0       0    23:43:40 Establ
  bgp.l3vpn.0: 3/3/3/0
  bgp.l3vpn.2: 0/0/0/0
  bgp.mvpn.0: 1/1/1/0
  vpn-1.inet.0: 3/3/3/0
  vpn-1.mvpn.0: 1/1/1/0

Meaning

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