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

Understanding Junos OS MPLS Components for EX Series Switches

Provider Edge Switches

To implement MPLS on a network, you must configure two provider edge (PE) switches—that is, an ingress PE switch and an egress PE switch. In addition, you must configure one or more provider switches as transit switches within the network to support the forwarding of MPLS packets.

The ingress PE switch (the entry point to the MPLS tunnel) receives a packet, analyzes it, and pushes an MPLS label onto it. This label places the packet in a forwarding equivalence class (FEC) and determines its handling and destination through the MPLS tunnel. The egress PE switch (the exit point from the MPLS tunnel) pops the MPLS label off the outgoing packet.

Within an MPLS tunnel, the network traffic is bidirectional. Therefore, each PE switch can be configured to be both an ingress switch and an egress switch, depending on the direction of the traffic.

The following MPLS components are configured on the PE switches but not on the provider switches:

• MPLS Protocol and Label-Switched Paths
• Circuit Cross-Connect for Customer Edge Interfaces
• IP Over MPLS for Customer Edge Interfaces
• BGP for Layer 2 VPN and Layer 3 VPN Configurations (EX8200 and EX4500 Switches Only)
• Routing Instances for Layer 2 VPN and Layer 3 VPN (EX8200 and EX4500 Switches Only)
• Ethernet Encapsulation for Layer 2 VPN (EX8200 and EX4500 Switches Only)
• LDP for Layer 2 Circuits (EX8200 and EX4500 Switches Only)

MPLS Protocol and Label-Switched Paths

Each PE switch must be configured to support the MPLS protocol. The configuration of a label-switched path (LSP) depends upon which signaling protocol is used:

• If the RSVP signaling protocol is used, the LSPs must be explicitly configured at the [edit protocols mpls] hierarchy level.
• If the LDP signaling protocol is used, LSP configuration is not required. (LDP signaling is used with Layer 2 circuit configurations.)

Circuit Cross-Connect for Customer Edge Interfaces

You can configure the customer edge interface of the PE switches as a circuit cross-connect (CCC) to create a transparent connection between two circuits. When you configure an interface as a CCC, the interface is removed from the default VLAN if it was a member of that VLAN. The interface becomes an MPLS tunnel—used exclusively for MPLS packets. You can create different CCCs for different customers or for segregating different traffic streams over different MPLS tunnels.

Using a CCC configuration, you can connect the following types of interfaces:

• A local interface with a remote interface or VLAN
• A local VLAN with a remote interface or VLAN

Note: To configure a VLAN circuit as a CCC, you must enable VLAN tagging and specify a VLAN ID. You must specify the same VLAN ID on both ends of the CCC. The VLAN CCC configuration must use the same type of switch for both PE switches. For example, you cannot use an EX8200 switch for one PE switch and an EX3200, EX4200, or EX4500 switch for the other PE switch.

MPLS on EX Series switches does not support the following types of CCC configurations:

• Routed VLAN interfaces (RVIs) on switches other than EX8200 switches
• Q-in-Q tunneling

On EX8200 switches only, the following types of CCC configurations are supported:

• Local switching—Connecting interfaces on the same switch
• MPLS tunneling—Using LSPs as the conduit to connect two distant interface circuits
• LSP stitching—Connecting LSPs that fall into two different traffic engineering database areas
• RVIs on customer edge interfaces

IP Over MPLS for Customer Edge Interfaces

You can configure the customer edge interfaces of the PE switches for IP over MPLS using a Layer 3 interface and a static route from the ingress PE switch to the egress PE switch. See Configuring MPLS on Provider Edge Switches Using IP Over MPLS (CLI Procedure).

BGP for Layer 2 VPN and Layer 3 VPN Configurations (EX8200 and EX4500 Switches Only)

If you are implementing a Layer 2 virtual private network (VPN) or a Layer 3 VPN, you must configure the BGP routing protocol on the PE switches.

Routing Instances for Layer 2 VPN and Layer 3 VPN (EX8200 and EX4500 Switches Only)

If you are implementing a Layer 2 VPN or a Layer 3 VPN, you must configure a routing instance. A routing instance is a collection of routing tables, interfaces, and routing protocol parameters. The set of interfaces belongs to the routing tables, and the routing protocol parameters control the information in the routing tables.

EX Series switches support the following types of routing instances:

• Layer 2 VPN—To support a Layer 2 VPN
• VPN routing and forwarding (VRF)—To support a Layer 3 VPN

Each routing instance has a unique name and a corresponding IP unicast table. For example, if you configure a routing instance with the name my-instance, its corresponding IP unicast table will be my-instance.inet.0. All routes for my-instance are installed in my-instance.inet.0.

Ethernet Encapsulation for Layer 2 VPN (EX8200 and EX4500 Switches Only)

If you are implementing a Layer 2 VPN, you must also configure the physical layer encapsulation type on the customer edge interface and within the routing instance.

LDP for Layer 2 Circuits (EX8200 and EX4500 Switches Only)

If you are implementing a Layer 2 circuit configuration, you must configure LDP as the signaling protocol on the PE switches.

Provider Switch

You must configure one or more provider switches as transit switches within the network to support the forwarding of MPLS packets. You can add provider switches without changing the configuration of the PE switches.

A provider switch does not analyze the packets. It refers to an MPLS label forwarding table and swaps one label for another. The new label determines the next hop along the MPLS tunnel. A provider switch cannot perform push or pop operations.

Components Required for All Switches in the MPLS Network

The following MPLS components are configured on both the PE switches and the provider switches:

• Routing Protocol
• Traffic Engineering
• MPLS Protocol
• RSVP
• LDP
• Family mpls

Routing Protocol

MPLS works in coordination with the interior gateway protocol (IGP). Therefore, you must configure OSPF or IS-IS as the routing protocol on the loopback interface and core interfaces of both the PE switches and the provider switches.

The core interfaces can be either Gigabit Ethernet or 10-Gigabit Ethernet interfaces, and they can be configured as either individual interfaces or as aggregated Ethernet interfaces.

Note: The core interfaces cannot be configured with VLAN tagging or a VLAN ID. When you configure them to belong to family mpls, they are removed from the default VLAN if they were members of that VLAN. They operate as an exclusive tunnel for MPLS traffic.

Traffic Engineering

Traffic engineering maps traffic flows onto an existing physical topology and provides the ability to move traffic flow away from the shortest path selected by the IGP and to a potentially less congested physical path across a network.

Traffic engineering enables the selection of specific end-to-end paths to send given types of traffic through your network. The configuration of traffic engineering depends upon which routing protocol is being used:

• With OSPF—Traffic engineering needs to be enabled.
• With IS-IS—Traffic engineering is enabled by default.

MPLS Protocol

You must enable the MPLS protocol on all switches that participate in the MPLS network and apply it to the core interfaces of both the PE and provider switches. You do not need to apply it to the loopback interface, because the MPLS protocol uses the framework established by the signaling protocol to create LSPs. On the PE switches, the configuration of the MPLS protocol must also include the definition of an LSP.

RSVP

RSVP is a signaling protocol that allocates and distributes labels throughout an MPLS network. RSVP sets up unidirectional paths between the ingress PE switch and the egress PE switch. RSVP makes the LSPs dynamic; it can detect topology changes and outages and establish new LSPs to allow traffic to move around a failure.

You must enable RSVP and apply it to the loopback interface and the core interface of both the PE and provider switches. The path message contains the configured information about the resources required for the LSP to be established.

When the egress switch receives the path message, it sends a reservation message back to the ingress switch. This reservation message is passed along from switch to switch along the same path as the original path message. Once the ingress switch receives this reservation message, an RSVP path is established.

The established LSP stays active as long as the RSVP session remains active. RSVP continues activity through the transmissions and responses to RSVP path and reservation messages. If the messages stop for three minutes, the RSVP session terminates and the LSP is lost.

RSVP runs as a separate software process in the Junos OS and is not in the packet-forwarding path.

LDP

LDP is a signaling protocol available on EX8200 switches and EX4500 switches. LDP is a simple, fast-acting signaling protocol that automatically establishes LSP adjacencies within an MPLS network. Switches then share LSP updates such as hello packets and LSP advertisements across the adjacencies.

Because LDP runs on top of an IGP such as IS-IS or OSPF, you must configure LDP and the IGP on the same set of interfaces. After both are configured, LDP begins transmitting and receiving LDP messages through all LDP-enabled interfaces. Because of LDP's simplicity, it cannot perform true traffic engineering like RSVP. LDP does not support bandwidth reservation or traffic constraints.

Note: LDP can be used with basic MPLS or with MPLS and a Layer 2 circuit configuration.

Family mpls

You must configure the core interfaces used for MPLS traffic to belong to family mpls.

Note: You can enable family mpls on either individual interfaces or on aggregated Ethernet interfaces. You cannot enable it on tagged VLAN interfaces.

MPLS Support on EX4500 Standalone Switches and EX4500 Virtual Chassis

• MPLS is not supported in a mixed EX4200 and EX4500 Virtual Chassis.
• IP over MPLS is not supported when an EX4500 switch is positioned as a non-penultimate hop popping (PHP) MPLS switch; that is, when the label operation is swap. However, EX4500 switches support CCC, Layer2 VPNs, Layer2 circuits, and Layer3 VPNs the same way these are supported on EX8200 switches.
• MPLS over RVIs, LSP statistics, unicast reverse-path forwarding (RPF) statistics, MPLS class of service (CoS), traffic policing, Diffserv-aware LSPs, graceful Routing Engine switchover (GRES), and equal-cost multipath (ECMP) are not supported.
• LSP ping and traceroute for CCCs, Layer 2 circuits, and Layer 2 VPNs are not supported.
• An MPLS configuration that consists of a mix of EX8200 and EX4500 switches does not support VLAN-CCCs.
• VLAN-CCCs require that the VLAN ID is the same at both ends of the connection. The VLAN ID translation feature is not supported.
• EX4500 standalone switches and EX4500 Virtual Chassis support a maximum of 125 instances of Layer 2 VPN, Layer 3 VPN, or CCC connections; or a combination of these.

  Note: EX4500 switches do not support non-stop routing (NSR) for MPLS. With NSR support for MPLS, EX4500 switches can support up to 225 simultaneous instances of Layer 2 VPN or Layer 3 VPN or CCC connections.

• Time to live (TTL) of MPLS packets is not decremented in the ingress MPLS switch.
• The pipe model of TTL handling is not supported on a Layer 3 VPN if an EX4500 switch is configured as the ingress provider edge (PE) switch.