Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Resiliency in Multicast L3 VPNs with Redundant Virtual Tunnels

Redundant Virtual Tunnels Providing Resiliency in Delivering Multicast Traffic Overview

In multicast Layer 3 VPNs, virtual tunnel (VT) interfaces are needed to facilitate virtual routing and forwarding (VRF) table lookup based on MPLS labels.

Junos OS supports redundant VTs at the Packet Forwarding Engine level to improve resiliency in delivering multicast traffic.

Note:

Redundant VTs are supported only on MX Series routers with MPCs.

To create redundant VTs at the Packet Forwarding Engine level, you add member VTs (vt- interfaces) to a parent VT (rvt interface).

Configuring redundant VT interfaces on MX Series routers with MPCs has the following characteristics:

  • When creating a redundant VT, you can add unconfigured VTs as members of the redundant VT. You configure the redundant VT the same way you configure a regular VT, and the member VTs inherit the configuration of the parent redundant VT.

  • When a VT with an existing configuration joins a redundant VT, you must configure the redundant VT with the settings from the existing configuration.

  • You can create up to 16 redundant VTs.

  • You can add up to 32 VTs as members of the redundant VTs.

    Note:

    The actual number of VTs you can create is determined by the type of chassis and the number of line cards you have.

  • When you add more than two VTs to a redundant VT, the members are in active mode by default, and traffic through the redundant VT is load balanced across all members of the redundant VT.

  • When you add only two members, you can configure the members in one of two ways:

    • Both members in active mode

    • One member in active mode and the other in backup mode

      Best Practice:

      To set one member to active mode and the other to backup mode, we recommend that the members be hosted on different MPCs. That way, if an MPC fails, it does not bring down the entire rvt interface.

  • Class of service and firewall configurations involving VT interfaces work the same on redundant VT interfaces.

Note:

Redundant VTs help to provide resiliency and improve uptime in your network when delivering multicast traffic. When enhanced-ip is enabled at the [edit chassis network-services] hierarchy level, failure of a VT that is a member of a redundant VT can typically be detected and fail over to another member VT provided within 50 milliseconds.

Configuring Redundant Virtual Tunnels to Provide Resiliency in Delivering Multicast Traffic

In multicast Layer 3 VPNs, virtual tunnel (VT) interfaces are needed to facilitate virtual routing and forwarding (VRF) table lookup based on MPLS labels.

Junos OS supports redundant VTs at the Packet Forwarding Engine level to improve resiliency in delivering multicast traffic.

Note:

Redundant VTs are supported only on MX Series routers with MPCs.

To create redundant VTs at the Packet Forwarding Engine level, add member VTs (vt- interfaces) to a redundant VT (rvt interface), and add that redundant VT interface to a vrf routing instance.

To configure a redundant VT:

  1. Enable tunnel services on the MX Series router.

    For example:

    See Tunnel Interface Configuration on MX Series Routers Overview for more information.

  2. Create the redundant VT interface type.

    For example:

  3. Enable enhanced-ip under network services.
  4. Create the redundant VT interface.

    For example:

    See redundancy-group (Interfaces) for more information.

    Note:

    You configure the remaining parameters for a redundant VT (rvt) interface the same way as you configure a VT (vt-) interface.

  5. Add the redundant VT to the appropriate routing instance.

    For example:

    Note:

    Because the rvt interface contains two or more vt- member interfaces, providing redundancy, adding an rvt interface and a vt- interface to the same routing instance is not supported.

    See Configuring Routing Instances on PE Routers in VPNs for detailed information about configuring routing instances.

Example: Configuring Redundant Virtual Tunnels to Provide Resiliency in Delivering Multicast Traffic

This example shows how to configure redundant virtual tunnels (VTs) in a multiprotocol BGP (MBGP) multicast VPN (MVPN). You configure a virtual loopback tunnel to facilitate virtual routing and forwarding (VRF) table lookup based on MPLS labels. Redundant VTs configured through this method provide near-immediate (less than 50 milliseconds) failover if one of the VTs fails.

Requirements

This example uses the following hardware and software components:

  • MPCs on MX Series routers

  • Junos OS Release 15.2

Overview

When a VT with an existing configuration joins a redundant VT, you must configure the redundant VT with the settings from the existing configuration.

You can add member VTs to a parent VT for redundancy.

On MX Series routers with MPCs, you can configure redundant VTs in these ways:

  • You can create up to 16 redundant VTs.

  • You can add up to 32 VTs as members of the redundant VTs.

    Note:

    The actual number of VTs you can create is determined by the type of chassis and the number of line cards you have.

  • When you add more than two VTs to a redundant VT, the members are in active mode by default.

  • When you add only two members, you can configure the members in one of these ways:

    • Both members in active mode

    • One member in active mode and the other in backup mode

Topology

In this example, Device PE2 has a redundant VT interface configured in a multicast LDP routing instance. The redundant VT interface in this example contains two member VT interfaces, one in active mode and the other in backup mode.

Figure 1 shows the topology used in this example.

Figure 1: Redundant VT Interfaces in MBGP MVPNRedundant VT Interfaces in MBGP MVPN

The following example shows the configuration for the customer edge (CE), provider (P), and provider edge (PE) devices in Figure 1. See Step-by-Step Procedure to configure Device PE2.

Configuration

Device P

Device PE2

Device CE2

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

In this section, the rvt interface is configured on Device PE2.

  1. Configure the redundant virtual tunnel redundancy group and tunnel services on the chassis.

  2. Configure the physical interfaces and loopback interfaces.

  3. Configure the rvt interface.

    Note:

    In this example, one member of the rvt interface is set to be active and the other interface is set to be the backup. This approach requires member interfaces to be on separate MPCs.

  4. Configure MPLS.

  5. Configure BGP.

  6. Configure an interior gateway protocol.

  7. Configure LDP, PIM, and RSVP.

  8. Configure the routing policy.

  9. Configure the routing instance.

  10. Add the rvt interface to the routing instance.

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

Results

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

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

Verification

Confirm that the configuration is working properly.

Verifying the Creation of Virtual Tunnel and Redundant Virtual Tunnel Interfaces

Purpose

Verify that the rvt interface is created and that the appropriate member vt- interfaces are contained within the rvt interface.

Action

From operational mode, enter the show interfaces terse | match rvt0 command.

Meaning

The output shows that rvt0 was created and that it contains vt-1/0/10 and vt-2/0/10 as member interfaces.

Verifying the Inclusion of the rvt Interface in the Multicast Route

Purpose

Verify that the vpn1 multicast routing instance is running and that it contains the rvt0 interface.

Action

From operational mode, enter the show multicast route extensive instance vpn1 command.

Meaning

The output shows that the vpn1 routing instance is running and contains rvt0.

Verifying Traffic Through the rvt Interface and Its Member Interfaces

Purpose

Verify that traffic passes through the rvt0 interface and its member interfaces as expected. For this section, start streams of unicast and multicast traffic from the source to the receiver.

Note:

In this example, all traffic through the rvt0 interface is expected to pass through the active vt-1/0/10 interface, and no traffic is expected to pass through the backup vt-2/0/10 interface.

Action

From operational mode, enter the monitor interface rvt0 command.

From this output, rvt0 is enabled and up and traffic is flowing through it.

Now enter the monitor interface vt-1/0/10 command.

From this output, all traffic that is passing through the rvt0 interface is passing through the active vt-1/0/10 interface, as expected.

Now enter the monitor interface vt-2/0/10 command.

From this output, even though vt-2/0/10 is enabled and up, no traffic is passing through. This is expected, because the interface is set to backup.

Meaning

While everything is running normally, traffic does pass through the redundant virtual interface, rvt0, and all of the traffic passes through its active member interface. If neither member interface is set to be active or backup, the traffic is expected to be load balanced across both interfaces.

Verifying Immediate Failover to the Backup Virtual Tunnel

Purpose

Verify that when the MPC containing the active member interface fails or is restarted, all traffic through the rvt0 interfaces immediately fails over to the backup member interface.

Best Practice:

For this task, we recommend you have one window open showing the live statistics of the backup interface, through the monitor interface vt-2/0/10 command, and another window from which you can restart the MPC containing the active member interface.

Action

From operational mode, enter the request chassis fpc slot 1 restart command and observe the live statistics of the backup member interface.

Meaning

The output shows that the traffic through the rvt0 interface is immediately fully carried by the backup member interface.

Understanding Redundant Virtual Tunnel Interfaces in MBGP MVPNs

In multiprotocol BGP (MBGP) multicast VPNs (MVPNs), VT interfaces are needed for multicast traffic on routing devices that function as combined provider edge (PE) and provider core (P) routers to optimize bandwidth usage on core links. VT interfaces prevent traffic replication when a P router also acts as a PE router (an exit point for multicast traffic).

Starting in Junos OS Release 12.3, you can configure up to eight VT interfaces in a routing instance, thus providing Tunnel PIC redundancy inside the same multicast VPN routing instance. When the active VT interface fails, the secondary one takes over, and you can continue managing multicast traffic with no duplication.

Redundant VT interfaces are supported with RSVP point-to-multipoint provider tunnels as well as multicast LDP provider tunnels. This feature also works for extranets.

You can configure one of the VT interfaces to be the primary interface. If a VT interface is configured as the primary, it becomes the next hop that is used for traffic coming in from the core on the label-switched path (LSP) into the routing instance. When a VT interface is configured to be primary and the VT interface is used for both unicast and multicast traffic, only the multicast traffic is affected.

If no VT interface is configured to be the primary or if the primary VT interface is unusable, one of the usable configured VT interfaces is chosen to be the next hop that is used for traffic coming in from the core on the LSP into the routing instance. If the VT interface in use goes down for any reason, another usable configured VT interface in the routing instance is chosen. When the VT interface in use changes, all multicast routes in the instance also switch their reverse-path forwarding (RPF) interface to the new VT interface to allow the traffic to be received.

To realize the full benefit of redundancy, we recommend that when you configure multiple VT interfaces, at least one of the VT interfaces be on a different Tunnel PIC from the other VT interfaces. However, Junos OS does not enforce this.

Example: Configuring Redundant Virtual Tunnel Interfaces in MBGP MVPNs

This example shows how to configure redundant virtual tunnel (VT) interfaces in multiprotocol BGP (MBGP) multicast VPNs (MVPNs). To configure, include multiple VT interfaces in the routing instance and, optionally, apply the primary statement to one of the VT interfaces.

Requirements

The routing device that has redundant VT interfaces configured must be running Junos OS Release 12.3 or later.

Overview

In this example, Device PE2 has redundant VT interfaces configured in a multicast LDP routing instance, and one of the VT interfaces is assigned to be the primary interface.

Figure 2 shows the topology used in this example.

Figure 2: Multiple VT Interfaces in MBGP MVPN TopologyMultiple VT Interfaces in MBGP MVPN Topology

The following example shows the configuration for the customer edge (CE), provider (P), and provider edge (PE) devices in Figure 2. The section Step-by-Step Procedure describes the steps on Device PE2.

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.

Device CE1

Device CE2

Device CE3

Device P

Device PE1

Device PE2

Device PE3

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.

To configure redundant VT interfaces in an MBGP MVPN:

  1. Configure the physical interfaces and loopback interfaces.

  2. Configure the VT interfaces.

    Each VT interface is configurable under one routing instance.

  3. Configure MPLS on the physical interfaces.

  4. Configure BGP.

  5. Configure an interior gateway protocol.

  6. Configure LDP.

  7. Configure the routing policy.

  8. Configure the routing instance.

  9. Configure redundant VT interfaces in the routing instance.

    Make vt-1/1/0.0 the primary interface.

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

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 configuration instructions in this example to correct it.

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

Verification

Confirm that the configuration is working properly.

Note:

The show multicast route extensive instance instance-name command also displays the VT interface in the multicast forwarding table when multicast traffic is transmitted across the VPN.

Checking the LSP Route

Purpose

Verify that the expected LT interface is assigned to the LDP-learned route.

Action
  1. From operational mode, enter the show route table mpls command.

  2. From configuration mode, change the primary VT interface by removing the primary statement from the vt-1/1/0.0 interface and adding it to the vt-1/2/1.0 interface.

  3. From operational mode, enter the show route table mpls command.

Meaning

With the original configuration, the output shows the vt-1/1/0.0 interface. If you change the primary interface to vt-1/2/1.0, the output shows the vt-1/2/1.0 interface.

Release History Table
Release
Description
12.3
Starting in Junos OS Release 12.3, you can configure up to eight VT interfaces in a routing instance, thus providing Tunnel PIC redundancy inside the same multicast VPN routing instance.