Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

MPLS Overview

MPLS Overview

Multiprotocol Label Switching (MPLS) is a protocol that uses labels to route packets instead of using IP addresses. In a traditional network, each switch performs an IP routing lookup, determines a next-hop based on its routing table, and then forwards a packet to that next-hop. With MPLS, only the first device does a routing lookup, and, instead of finding the next-hop, finds the ultimate destination along with a path to that destination. The path of an MPLS packet is called a label-switched path (LSP).

MPLS applies one or more labels to a packet so it can follow the LSP to the destination. Each switch pops off its label and sends the packet to the next switch label in the sequence.

The Junos OS includes everything you need to configure MPLS. You do not need to install any additional programs or protocols. MPLS is supported on switches with a subset of the commands supported on routers. The Junos MPLS-configured switches can interact with each other and with Junos MPLS-configured routers.

MPLS has the following advantages over conventional packet forwarding:

  • Packets arriving on different ports can be assigned different labels.

  • A packet arriving at a particular provider edge (PE) switch can be assigned a label that is different from that of the same packet entering the network at a different PE switch. As a result, forwarding decisions that depend on the ingress PE switch can be easily made.

  • Sometimes it is desirable to force a packet to follow a particular route that is explicitly chosen at or before the time the packet enters the network, rather than letting it follow the route chosen by the normal dynamic routing algorithm as the packet travels through the network. In MPLS, a label can be used to represent the route so that the packet need not carry the identity of the explicit route.

This topic describes:

Why Use MPLS?

MPLS reduces the use of the forwarding table by using labels instead of the forwarding table. The size of forwarding tables on a switch are limited by silicon and using exact matching for forwarding to destination devices is cheaper than buying more sophisticated hardware. In addition, MPLS allows you to control where and how traffic is routed on your network – this is called traffic engineering.

Some reasons to use MPLS instead of another switching solution are:

  • MPLS can connect different technologies that would not otherwise be compatible---service providers have this compatibility issue when connecting clients with different autonomous systems in their networks. In addition, MPLS has a feature called Fast Reroute that provides alternate backups for paths – this prevents network degradation in case of a switch failure.

  • Other IP-based encapsulations such as Generic Route Encapsulation (GRE) or Virtual Extensible Local Area Networks (VXLAN) support only two levels of hierarchy, one for the transport tunnel and one piece of metadata. Using virtual servers means that you need multiple hierarchy levels. For example, one label is needed for top-of-rack (ToR), one label for the egress port that identifies the server, and one for the virtual server.

Why Not Use MPLS?

There are no protocols to auto-discover MPLS enabled nodes. MPLS protocol just exchanges label values for an LSP. They do not create the LSPs.

You must build the MPLS mesh, switch by switch. We recommend using scripts for this repetitive process.

MPLS hides suboptimal topologies from BGP where multiple exits may exist for the same route.

Large LSPs are limited by the circuits they traverse. You can work around this by creating multiple, parallel LSPs.

How Do I Configure MPLS?

There are three types of switches you must set up for MPLS:

  • Label Edge Router/Switch (LER) or ingress node to the MPLS network. This switch encapsulates the packets.

  • Label Switching Routers/Switches (LSR). One or more switches that transfer MPLS packets in the MPLS network.

  • Egress router/switch is the final MPLS device that removes the last label before packets leave the MPLS network.

Service providers (SP) use the term provider router (P) for a backbone router/switch doing label switching only. The customer-facing router at the SP is called a provider edge router (PE). Each customer needs a customer edge router (CE) to communicate with the PE. Customer facing routers typically can terminate IP addresses, L3VPNs, L2VPNs/ pseudowires, and VPLS before packets are transferred to the CE.

Configure the MPLS LER (Ingress) Switch and the Egress Switch

To configure MPLS, you must first create one or more named paths on the ingress and egress routers. For each path, you can specify some or all transit routers in the path, or you can leave it empty. See Configuring the Ingress and Egress Router Addresses for LSPs and Configuring the Connection Between Ingress and Egress Routers.

Configure LSRs for MPLS

Configure one or more MPLS LSRs by following these steps:

  1. Configure interfaces on each switch to transmit and receive MPLS packets using the usual interface command with MPLS appended. For example:

  2. Add those same interfaces under [edit protocols mpls]. For example:

  3. Configure the interfaces on each switch to handle MPLS labels with a protocol. For example, for LDP:

    To watch a demo of these configurations, see https://www.youtube.com/watch?v=xegWBCUJ4tE.

What Does the MPLS Protocol Do?

Multiprotocol Label Switching (MPLS) is an Internet Engineering Task Force (IETF)-specified framework that provides for the designation, routing, forwarding and switching of traffic flows through the network. In addition, MPLS:

  • Specifies mechanisms to manage traffic flows of various granularities, such as flows between different hardware, machines, or even flows between different applications.

  • Remains independent of the layer-2 and layer-3 protocols.

  • Provides a means to map IP addresses to simple, fixed-length labels used by different packet-forwarding and packet-switching technologies.

  • Interfaces to existing routing protocols, such as Resource ReSerVation Protocol (RSVP) and Open Shortest PathFirst (OSPF).

  • Supports IP, ATM, and Frame Relay layer-2 protocols.

  • Uses these additional technologies:

    • FRR: MPLS Fast Reroute improves convergence during a failure by mapping out alternate LSPs in advance.

    • Link Protection/ Next-hop backup: A bypass LSP is created for every possible link failure.

    • Node Protection/ Next-hop backup: A bypass LSP is created for every possible switch (node) failure.

    • VPLS: Creates Ethernet multipoint switching service over MPLS and emulates functions of an L2 switch.

    • L3VPN: IP-based VPN customers get individual virtual routing domains.

How Does MPLS Interface to Other Protocols?

Some of the protocols that work with MPLS are:

  • RSVP-TE: Resource Reservation Protocol - Traffic Engineering reserves bandwidth for LSPs.

  • LDP: Label Distribution Protocol is the defacto protocol used for distribution of MPLS packets and is usually configured to tunnel inside RSVP-TE.

  • IGP: Interior Gateway Protocol is a routing protocol. Edge routers (PE-routers) run BGP between themselves to exchange external (customer) prefixes. Edge and core (P) routers run IGP (usually OSPF or IS-IS) to find optimum path toward BGP next hops. P- and PE-routers use LDP to exchange labels for known IP prefixes (including BGP next hops). LDP indirectly builds end-to-end LSPs across the network core.

  • BGP: Border Gateway Protocol (BGP) allows policy-based routing to take place, using TCP as its transport protocol on port 179 to establish connections. The Junos OS routing protocol software includes BGP version 4. You do not configure BGP---configuring interfaces with MPLS and LDP/RSVP establishes the labels and the ability to transmit packets. BGP automatically determines the routes packets take.

  • OSPF and ISIS: These protocols are used for routing between the MPLS PE and CE. Open Shortest Path First (OSPF) is perhaps the most widely used interior gateway protocol (IGP) in large enterprise networks. IS-IS, another link-state dynamic routing protocol, is more common in large service provider networks. Assuming you're running L3VPN to your customers, on the SP edge between the PE and the CE you can run any protocol that your platform supports as a VRF aware instance.

If I Have Used Cisco MPLS, What Do I Need to Know?

Cisco Networks and Juniper Networks use different MPLS terminology.

What Cisco Calls:

Juniper Calls:

affinities

admin-groups

autoroute announce

TE shortcuts

forwarding adjacency

LSP-advertise

tunnel

LSP

make-before-break

adaptive

application-window

adjust-interval

shared risk link groups

fate-sharing

TTL Processing on Incoming MPLS Packets

The flow chart on Figure 1 illustrates TTL processing on incoming MPLS packets. On a transit LSR or an egress LER, MPLS pops one or more labels and can push one or more labels. The incoming TTL of the packet is determined by the configured TTL processing tunnel model.

When all of the following conditions are met, the incoming TTL is set to the TTL value found in the immediate inner header:

  • The outer label is popped as opposed to being swapped

  • The TTL processing model is configured to pipe

  • The inner header is MPLS or IP

If any of those conditions is not met, then the incoming TTL is set to the TTL value found in the outermost label. In all cases, the TTL values of any further inner labels are ignored.

When an IP packet is exposed after MPLS pops all the labels that should be popped, MPLS passes the packet to IP for further processing, including TTL checking. When the uniform tunnel model for TTL processing is in effect, MPLS sets the TTL value of the IP packet to the incoming TTL value that was just set. In other words, the TTL value is copied from the outermost label to the IP packet. When the pipe model for TTL processing is in effect, the TTL value in the IP header is left unchanged.

If an IP packet is not exposed by the label popping, then MPLS performs the TTL validation. If the incoming TTL is less than 2, the packet is dropped. If innermost packet is IP, an ICMP packet is built and sent. If the TTL does not expire and the packet needs to be sent out, the outgoing TTL is determined by the rules for outgoing MPLS packets.

Figure 1: TTL Processing on Incoming MPLS PacketsTTL Processing on Incoming MPLS Packets

MPLS Overview for ACX Series Universal Metro Routers

Multiprotocol Label Switching (MPLS) provides a mechanism for engineering network traffic patterns that is independent of routing tables by assigning short labels to network packets, which describe how to forward them through the network. MPLS is independent of any routing protocol and can be used for unicast packets. On the ACX Series routers, the following MPLS features are supported:

  • The configuration of a label-switching router (LSR) for processing of label-switched packets and forwarding of packets based on their labels.

  • The configuration of an ingress label edge router (LER) where IP packets are encapsulated within MPLS packets and forwarded to the MPLS domain, and as an egress LER where MPLS packets are decapsulated and the IP packets contained within the MPLS packets are forwarded using information in the IP forwarding table. Configuring MPLS on the LER is the same as configuring an LSR.

  • Uniform and pipe mode configuration providing different types of visibility in the MPLS network. Uniform mode makes all the nodes that a label-switched path (LSP) traverses visible to nodes outside the LSP tunnel. Uniform mode is the default. Pipe mode makes only the LSP ingress and egress points visible to nodes outside the LSP tunnel. Pipe mode acts like a circuit and must be enabled with the global no-propagate-ttl statement at the [edit protocols mpls] hierarchy level on each router that is in the path of the LSP. The no-propagate-ttl statement disables time-to-live (TTL) propagation at the router level and affects all RSVP-signalled or LDP-signalled LSPs. Only the global configuration of TTL propagation is supported.

  • Exception packet handling of IP packets not processed by the normal packet flow through the Packet Forwarding Engine. The following types of exception packet handling are supported:

    • Router alert

    • Time-to-live (TTL) expiry value

    • Virtual circuit connection verification (VCCV)

  • LSP hot standby for secondary paths configuration to maintain a path in a hot-standby state enabling swift cut over to the secondary path when downstream routers on the current active path indicate connectivity problems.

  • Redundancy for a label-switched path (LSP) path with the configuration of fast reroute.

  • Configuration of link protection to ensure that traffic traversing a specific interface from one router to another can continue to reach its destination in the event that this interface fails.

MPLS for EX Series Switches Overview

You can configure Junos OS MPLS on Juniper Networks EX Series Ethernet Switches to increase transport efficiency in the network. MPLS services can be used to connect various sites to a backbone network and to ensure better performance for low-latency applications such as voice over IP (VoIP) and other business-critical functions.

Note:

MPLS configurations on EX Series switches are compatible with configurations on other Juniper Networks devices that support MPLS and MPLS-based circuit cross-connect (CCC). MPLS features available on the switches depend upon which switch you are using. For information about the software features on the EX Series switches, see Feature Explorer.

Note:

MPLS configurations on the switches do not support:

  • Q-in-Q tunneling

This topic describes:

Benefits of MPLS

MPLS has the following advantages over conventional packet forwarding:

  • Packets arriving on different ports can be assigned different labels.

  • A packet arriving at a particular provider edge (PE) switch can be assigned a label that is different from that of the same packet entering the network at a different PE switch. As a result, forwarding decisions that depend on the ingress PE switch can be easily made.

  • Sometimes it is desirable to force a packet to follow a particular route that is explicitly chosen at or before the time the packet enters the network, rather than letting it follow the route chosen by the normal dynamic routing algorithm as the packet travels through the network. In MPLS, a label can be used to represent the route so that the packet need not carry the identity of the explicit route.

Additional Benefits of MPLS and Traffic Engineering

MPLS is the packet-forwarding component of the Junos OS traffic engineering architecture. Traffic engineering provides the capabilities to do the following:

  • Route primary paths around known bottlenecks or points of congestion in the network.

  • Provide precise control over how traffic is rerouted when the primary path is faced with single or multiple failures.

  • Provide efficient use of available aggregate bandwidth and long-haul fiber by ensuring that certain subsets of the network are not overutilized while other subsets of the network along potential alternate paths are underutilized.

  • Maximize operational efficiency.

  • Enhance the traffic-oriented performance characteristics of the network by minimizing packet loss, minimizing prolonged periods of congestion, and maximizing throughput.

  • Enhance statistically bound performance characteristics of the network (such as loss ratio, delay variation, and transfer delay) required to support a multiservice Internet.

MPLS Feature Support on QFX Series and EX4600 Switches

This topic describes the MPLS features that are supported on the QFX Series, EX4600, EX4650 switches. Be sure to check for any exceptions to this support in MPLS Limitations on QFX Series and EX4600 Switches. Configuring unsupported statements on the switch does not affect its operation.

Note:

EX4600 and EX4650 switches use the same chipset as QFX5100 switches—this is why EX Series switches are included here along with QFX Series switches. Other EX Series switches also support MPLS but with a different feature set.

Supported Features

The tables in this section lists the MPLS features that are supported on the QFX Series, EX4600, EX4650 switches, and the Junos OS release in which they were introduced. Table 1 lists the features for QFX10000 switches. Table 2 lists the features for QFX3500, QFX5100, QFX5120, QFX5110, QFX5200, QFX5210 switches.Table 3 lists the features for EX4600 and EX4650 switches.

Table 1: QFX10000 MPLS Features

Feature

QFX10002

QFX10008

QFX10016

QFX10000 standalone switch as an MPLS provider edge (PE) switch or provider switch

15.1X53-D10

15.1X53-D30

15.1X53-D60

Label edge router (LER)

15.1X53-D10

15.1X53-D30

15.1X53-D60

Label-switching router (LSR)

15.1X53-D10

15.1X53-D30

15.1X53-D60

BGP MPLS Ethernet VPN (EVPN)

17.4R1

17.4R1

17.4R1

BGP route reflectors

15.1X53-D10

15.1X53-D30

15.1X53-D60

Automatic bandwidth and dynamic label-switched path (LSP) count sizing

15.1X53-D60

15.1X53-D60, 17.2R1

15.1X53-D60, 17.2R1

BGP labeled unicast

15.1X53-D10

15.1X53-D30

15.1X53-D60

BGP link state distribution

17.1R1

17.1R1

17.1R1

Carrier-of-carriers and interprovider Layer 3 VPNs

17.1R1

17.1R1

17.1R1

Entropy labels

17.2R1

17.2R1

17.2R1

Ethernet-over-MPLS (L2 circuit)

15.1X53-D60

15.1X53-D60

15.1X53-D60

Fast reroute, one-to-one local protection and many-to-one local protection

15.1X53-D10

15.1X53-D30

15.1X53-D60

Fast reroute using detours and secondary LSP

15.1X53-D10

15.1X53-D30

15.1X53-D60

Flexible Ethernet services

17.3R1

17.3R1

17.3R1

Firewall filters

15.1X53-D30

15.1X53-D30

15.1X53-D60

RSVP graceful restart for OSPF

15.1X53-D10

15.1X53-D30

15.1X53-D60

IP-over-MPLS LSPs, both static and dynamic links

15.1X53-D10

15.1X53-D30

15.1X53-D60

IPv6 tunneling over an IPv4 network (6PE)

15.1X53-D10

15.1X53-D30

15.1X53-D60

LDP tunneling over RSVP

15.1X53-D10

15.1X53-D30

15.1X53-D60

L2 Circuit on aggregated interfaces

17.3R1

17.3R1

17.3R1

L3VPNs for both IPv4 and IPv6

15.1X53-D10

15.1X53-D30

15.1X53-D60

MPLS over integrated bridging and routing (IRB) interfaces

15.1X53-D10

15.1X53-D30

15.1X53-D60

MPLS over UDP

18.3R1

18.3R1

18.3R1

MTU signaling in RSVP

15.1X53-D10

15.1X53-D30

15.1X53-D60

Operation, Administration, and Maintenance (OAM) including ping, traceroute and Bidirectional Forwarding Detection (BFD)

15.1X53-D10

15.1X53-D30

15.1X53-D60

OSPF TE

15.1X53-D10

15.1X53-D30

15.1X53-D60

OSPFv2 as an interior gateway protocol (IGP)

15.1X53-D10

15.1X53-D30

15.1X53-D60

Path Computation Element Protocol for RSVP-TE

16.3R1

16.3R1

16.3R1

Pseudowire-over-aggregated Ethernet interfaces (core-facing interface)

15.1X53-D60 (supported only on network-to-network (NNI) interfaces)

15.1X53-D60 (supported only on NNI interfaces)

15.1X53-D60 (supported only on NNI interfaces)

RSVP support, including bandwidth allocation and traffic engineering

15.1X53-D10

15.1X53-D30

15.1X53-D60

RSVP fast reroute (FRR), including link-protection, node-link-protection, fast reroute using detours, and secondary LSP

15.1X53-D10

15.1X53-D30

15.1X53-D60

SNMP MIB support

15.1X53-D10

15.1X54-D30

15.1X53-D60

Static and dynamic LSPs

15.1X53-D10

15.1X53-D30

15.1X53-D60

Traffic engineering extensions (OSPF-TE, IS-IS-TE)

15.1X53-D10

15.1X53-D30

15.1X53-D60

Traffic engineering (TE)

Automatic bandwidth allocation and RSVP bandwidth

Dynamic bandwidth management using ingress LSP splitting and merging

15.1X53-D10

15.1X53-D30

15.1X53-D60

Virtual routing and forwarding (VRF) label support

15.1X53-D10

15.1X53-D30

15.1X53-D60

Table 2: QFX3500, QFX5100, QFX5110, QFX5120, QFX5200, QFX5210 MPLS Features

Feature

QFX3500

QFX5100

QFX5110

QFX5120

QFX5200

QFX5210

QFX Series standalone switches as MPLS provider edge (PE) switches or provider switches

12.2X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

Label edge router (LER)

12.2X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

Label-switching router (LSR)

12.2X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

Automatic bandwidth allocation on LSPs

Not supported

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

BGP labeled unicast

12.2X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

BGP link state distribution

Not supported

17.1R1

17.1R1

18.3R1

17.1R1

18.1R1

BGP route reflector

15.1X53-D10

15.1X53-D30

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

Carrier-to-carrier and interprovider BGP Layer 3 VPNs

14.1X53-D15

14.1X53-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

Class of service (CoS or QoS) for MPLS traffic

12.3X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

Dynamic label-switched path (LSP) count sizing: TE++

Not supported

17.2R1

VC/VCF 17.2R1

17.2R1

VC/VCF 17.2R1

18.3R1

17.2R1

18.1R1

Equal-cost multipath (ECMP) at LSRs:

  • SWAP

  • PHP

  • L3VPN

  • L2 Circuit

Not supported

14.1X53-D35 (Supported only on label stack. Not supported on flow label, entropy label, or ECMP label)

15.1X53-D210 (Supported only on label stack. Not supported on flow label, entropy label, or ECMP label)

18.3R1 (Supported only on label stack. Not supported on flow label, entropy label, or ECMP label)

15.1X53-D30

18.1R1

Entropy labels

Not supported

Not supported

Not supported

Not supported

Not supported

Not supported

Ethernet-over-MPLS ( L2 Circuit)

14.1X53-D10

14.1X53-D10

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

Fast reroute (FRR), one-to-one local protection and many-to-one local protection

14.1X53-D10

14.1X53-D10

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

FRR using detours and secondary LSP

Not supported

Not supported

Not supported

Not supported

Not supported

Not supported

Firewall filters

12.3X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

Flow-aware transport of pseudowires (FAT) flow labels

Not supported

Not supported

Not supported

Not supported

Not supported

Not supported

RSVP graceful restart for OSPF

12.2X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

Traffic engineering extensions (OSPF-TE, IS-IS-TE)

12.2X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

IP-over-MPLS LSPs, both static and dynamic links

12.2X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

IPv6 tunneling over an MPLS IPv4 network (6PE)

12.3X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

IPv6 over an MPLS core network

Not supported

Not supported

Not supported

Not supported

Not supported

Not supported

LDP tunneling over RSVP

12.2X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

Layer 3 VPNs for both IPv4 and IPv6

12.3X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

Loop-free alternate (LFA)

Not supported

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

18.1R1

18.1R1

MPLS over integrated bridging and routing (IRB) interfaces

Not supported

14.1X53-D40

18.1R1

18.3R1

18.1R1

18.1R1

MTU signaling in RSVP

12.3X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

Operation, Administration, and Maintenance (OAM) including MPLS ping, traceroute, and BFD

12.3X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

OSPF TE

12.3X50-D10

13.2X51-D15

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

OSPFv2 as an interior gateway protocol

12.2X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

Path Computation Element Protocol for RSVP-TE

Not supported

17.4R1

17.4R1

18.3R1

17.4R1

18.1R1

Pseudowire-over-aggregated Ethernet interfaces (core-facing interface)

14.1X53-D10

14.1X53-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

RSVP automatic bandwidth

12.2X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

RSVP fast reroute (FRR), including link-protection, node-link-protection, fast reroute using detours, and secondary LSP

14.1X53-D15

14.1X53-D15

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

RSVP-TE extensions (IS-IS and OSPF)

12.2X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

SNMP MIB support

12.2X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

Static and dynamic LSPs

12.2X50-D10

13.2X51-D10

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

Traffic engineering (TE) automatic bandwidth allocation on LSPs

13.1X51-D10

13.1X51-D10

VC/VCF (13.2X51-D10)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

Virtual routing and forwarding (VRF) label support

12.2X50-D10

13.2X51-D15

VC/VCF (14.1X53-D30)

15.1X53-D210

18.3R1

15.1X53-D30

18.1R1

VRF support in IRB Interfaces in a Layer 3 VPN

Not supported

17.3R1

17.3R1

18.3R1

17.3R1

18.1R1

Table 3: EX4600 and EX4650 MPLS Features

Feature

EX4600

EX4650

EX4600 and EX4650 standalone switches as MPLS provider edge (PE) switches or provider switches

14.1X53-D15

18.3R1

Label edge router (LER)

14.1X53-D15

18.3R1

Label-switching router (LSR)

14.1X53-D15

18.3R1

Automatic bandwidth allocation on LSPs

Not supported

18.3R1

BGP labeled unicast

14.1X53-D15

18.3R1

BGP link state distribution

Not supported

18.3R1

BGP route reflector

14.1X53-D15

18.3R1

Carrier-to-carrier and interprovider BGP Layer 3 VPNs

14.1X53-D15

18.3R1

Class of service (CoS or QoS) for MPLS traffic

14.1X53-D15

18.3R1

Dynamic label-switched path (LSP) count sizing: TE++

Not supported

18.3R1

Equal-cost multipath (ECMP) at LSRs:

  • SWAP

  • PHP

  • L3VPN

  • L2 Circuit

Not supported

18.3R1 (Supported only on label stack. Not supported on flow label, entropy label, or ECMP label)

Entropy labels

Not supported

Not supported

Ethernet-over-MPLS ( L2 Circuit)

14.1X53-D15

18.3R1

Fast reroute (FRR), one-to-one local protection and many-to-one local protection

14.1X53-D15

18.3R1

FRR using detours and secondary LSP

Not supported

Not supported

Firewall filters

14.1X53-D15

18.3R1

Flow-aware transport of pseudowires (FAT) flow labels

Not supported

Not supported

RSVP graceful restart for OSPF

13.2X51-D25

18.3R1

Traffic engineering extensions (OSPF-TE, IS-IS-TE)

14.1X53-D15

18.3R1

IP-over-MPLS LSPs, both static and dynamic links

14.1X53-D15

18.3R1

IPv6 tunneling over an MPLS IPv4 network (6PE)

14.1X53-D15

18.3R1

IPv6 over an MPLS core network

Not supported

Not supported

LDP tunneling over RSVP

14.1X53-D15

18.3R1

Layer 3 VPNs for both IPv4 and IPv6

14.1X53-D15

18.3R1

Loop-free alternate (LFA)

Not supported

Not supported

MPLS over integrated bridging and routing (IRB) interfaces

Not supported

18.3R1

MTU signaling in RSVP

14.1X53-D15

18.3R1

Operation, Administration, and Maintenance (OAM) including MPLS ping, traceroute, and BFD

14.1X53-D15

18.3R1

OSPF TE

14.1X53-D15

18.3R1

OSPFv2 as an interior gateway protocol

13.2X51-D25

18.3R1

Path Computation Element Protocol for RSVP-TE

Not supported

18.3R1

Pseudowire-over-aggregated Ethernet interfaces (core-facing interface)

14.1X53-D15

18.3R1

RSVP automatic bandwidth

14.1X53-D15

18.3R1

RSVP fast reroute (FRR), including link-protection, node-link-protection, fast reroute using detours, and secondary LSP

14.1X53-D15

18.3R1

RSVP-TE extensions (IS-IS and OSPF)

14.1X53-D15

18.3R1

SNMP MIB support

14.1X53-D15

18.3R1

Static and dynamic LSPs

14.1X53-D15

18.3R1

Traffic engineering (TE)automatic bandwidth allocation on LSPs

14.1X53-D15

18.3R1

Virtual routing and forwarding (VRF) label support

14.1X53-D15

18.3R1

VRF support in IRB Interfaces in a Layer 3 VPN

Not supported

18.3R1

MPLS Limitations on QFX Series and EX4600 Switches

MPLS is a fully implemented protocol on routers, while switches support a subset of the MPLS features. The limitations of each switch are listed in a separate section here, although many of the limitations are duplicates that apply to more than one switch.

MPLS Limitations on QFX10000 Switches

  • Configuring an MPLS firewall filter on a switch that is deployed as an egress provider edge (PE) switch has no effect.

  • Configuring the revert-timer statement at the [edit protocols mpls] hierarchy level has no effect.

  • These LDP features are not supported on the QFX10000 switches:

    • LDP multipoint

    • LDP link protection

    • LDP Bidirectional Forwarding Detection (BFD)

    • LDP Operation Administration and Management (OAM)

    • LDP multicast-only fast reroute (MoFRR)

  • Pseudowire-over-aggregated Ethernet interfaces on UNI are not supported.

  • MPLS-over-UDP tunnels are not supported on the following:

    • MPLS TTL propagation

    • IP fragmentation at the tunnel start point

    • CoS rewrite rules and priority propagation for RSVP LSP labels (ingress tunnels only)

    • Plain IPv6

    • Multicast traffic

    • Firewall filters on tunnel start and endpoints

    • CoS tunnel endpoints

    Note:

    MPLS-over-UDP tunnels are created only if corresponding RSVP-TE, LDP, or BGP-LU tunnels are not available for the destination route.

MPLS Limitations on EX4600, EX4650, QFX5100, QFX5110, QFX5120, QFX5200, and QFX5210 Switches

  • MPLS support differs on the various switches. EX4600 switches support only basic MPLS functionality while the QFX5100, QFX5110, QFX5120, QFX5200, and QFX5210 switches support some of the more advanced features. See MPLS Feature Support on QFX Series and EX4600 Switches for details.

  • On a QFX5100 switch, configuring integrated bridging and routing (IRB) interfaces on the MPLS core is implemented on the switch by using TCAM rules. This is the result of a chip limitation on the switch, which only allows for a limited amount of TCAM space. There is 1K TCAM space is allocated for IRB. If multiple IRBs exist, make sure that you have enough available TCAM space on the switch. To check the TCAM space, see TCAM Filter Space Allocation and Verification in QFX Devices from Junos OS 12.2x50-D20 Onward.

  • (QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, EX4600) When flexible-ethernet-services encapsulation is configured on an interface and vlan-bridge encapsulation is enabled on a CE connected logical interface, the switch drops packets if you also enable VLAN CCC encapsulation on a different logical unit of that same interface. Only one of the below combinations can be configured, not both:

    Or:

  • Layer 2 circuits on aggregated Ethernet (AE) interfaces are not supported on QFX5100, QFX5110, QFX5120, QFX5200, and QFX5210 switches.

  • Layer 2 circuit local switching is not supported on the EX4600, EX4650, QFX5100, QFX5110, QFX5120, QFX5200, and QFX5210 switches.

  • The EX4600, QFX5100, QFX5110, QFX5120, QFX5200, and QFX5210 switches do not depend on the VRF match for loopback filters configured at different routing instances. Loopback filters per routing instance (such as lo0.100, lo0.103, lo0.105) are not supported and may cause unpredictable behavior. We recommend that you only apply the loopback filter (lo0.0) to the master routing instance

  • On EX4600 and EX4650 switches, when loopback filters with both accept and deny terms for the same IP address are configured and if RSVP packets have that IP address in either source IP or destination IP, then those RSVP packets will be dropped even if accept terms have higher priority than deny terms. As per design, if the switch receives an RSVP packet with IP OPTION, the packet is copied to the CPU and then the original packet is dropped. Because RSVP packets are marked for drop, the accept term will not process these packets and the deny term will drop the packets.

  • On a link-protected, fast reroute Layer 2 circuit, you might see a traffic convergence delay of 200 to 300 milliseconds.

  • If you configure the BGP labeled unicast address family (using the labeled-unicast statement at the [edit protocols bgp family inet] hierarchy level) on a QFX Series switch or on an EX4600 switch deployed as a route reflector for BGP labeled routes, path selection will occur at the route reflector, and a single best path will be advertised. This will result in loss of BGP multipath informaton.

  • Although fast reroute (FRR) on regular interfaces is supported, the include-all and include-any options for FRR are not supported. See Fast Reroute Overview.

  • FRR is not supported on MPLS over IRB interfaces.

  • MPLS-based circuit cross-connects (CCC) are not supported—only circuit-based pseudowires are supported.

  • Configuring link aggregation groups (LAGs) on user-to-network interface (UNI) ports for L2 circuits is not supported.

  • MTU signaling in RSVP and discovery is supported in the control plane. However, this cannot be enforced in the data plane.

  • With L2 circuit-based pseudowires, if multiple equal-cost RSVP LSPs are available to reach an L2 circuit neighbor, one LSP is randomly used for forwarding. Use this feature to specify LSPs for specific L2 circuit traffic to load-share the traffic in the MPLS core.

  • Configuring an MPLS firewall filter on a switch that is deployed as an egress provider edge (PE) switch has no effect.

  • Firewall filters and policers on family mpls are only supported on QFX5100 switches that act as pure label-switching routers (LSRs) in an MPLS network. A pure LSR is a transit router that switches paths solely on the incoming label’s instructions. Firewall filters and policers on family mpls are not supported on QFX5100 ingress and egress provider edge (PE) switches. This includes switches that perform penultimate hop popping (PHP).

  • Configuring the revert-timer statement at the [edit protocols mpls] hierarchy level has no effect.

  • These are the hardware limitations for EX4600, EX4650, QFX5100, QFX5110, QFX5120, QFX5200, and QFX5210 switches:

    • Push of a maximum of three labels is supported in the MPLS edge switch if label swap is not done.

    • Push of a maximum of two labels is supported in the MPLS edge switch if label swap is done.

    • Pop at line rate is supported for a maximum of two labels.

    • Global label space is supported but interface-specific label space is not supported.

    • MPLS ECMP on PHY node with BOS=1 is not supported for single labels.

    • QFX Series switches with Broadcom chips do not support separate next hops for the same label with different S bits (S-0 and S-1). This includes the QFX3500, QFX3600, EX4600, QFX5100, and QFX5200 switches.

    • On EX4600, EX4650, QFX5100, QFX5110, QFX5120, QFX5200, and QFX5210 switches, the MPLS MTU command can cause unexpected behavior—this is due to SDK chipset limitations on this platform.

  • These LDP features are not supported on the EX4600, EX4650, QFX5100, QFX5110, QFX5120, QFX5200, and QFX5210 switches:

    • LDP multipoint

    • LDP link protection

    • LDP Bidirectional Forwarding Detection (BFD)

    • LDP Operation Administration and Management (OAM)

    • LDP multicast-only fast reroute (MoFRR)

  • Configuring unit with family mpls and unit with encapsulation vlan-bridge on the same physical interface is not supported on EX4600, EX4650, QFX5100, QFX5110, or QFX5120.

MPLS Limitations on QFX5100 Virtual Chassis and Virtual Chassis Fabric Switches

The following MPLS features are not supported by the QFX5100 VC and QFX5100 VCF switches:

  • Next-hop LSP

  • BFD including BFD triggered FRR

  • L2 VPN based on BGP (See RFC 6624)

  • VPLS

  • Extended VLAN CCC

  • Pseudowire protection using Ethernet OAM

  • Local switching of pseudo-wire

  • Pseudowire fault detection based on VCCV

  • QFX Series switches with Broadcom chipsets do not support separate next hops for the same label with different S bits (S-0 and S-1). This includes QFX3500, QFX3600, EX4600, QFX5100, and QFX5200 switches.

MPLS Limitations on QFX3500 Switches

  • If you configure the BGP labeled unicast address family (using the labeled-unicast statement at the [edit protocols bgp family inet] hierarchy level) on a QFX Series switch or on an EX4600 switch deployed as a route reflector for BGP labeled routes, path selection will occur at the route reflector, and a single best path will be advertised. This will result in loss of BGP multipath information.

  • Although fast reroute is supported, the include-all and include-any options for fast reroute are not supported. See Fast Reroute Overview for details.

  • MPLS-based circuit cross-connects (CCC) are not supported—only circuit-based pseudowires are supported.

  • MTU signaling in RSVP and discovery is supported in the control plane. However, this cannot be enforced in the data plane.

  • With Layer 2 (L2) circuit-based pseudowires, if multiple equal-cost RSVP label-switched paths (LSPs) are available to reach a L2 circuit neighbor, one LSP is randomly used for forwarding. Use this feature to specify LSPs for specific L2 circuit traffic to load-share the traffic in the MPLS core.

  • Configuring an MPLS firewall filter on a switch that is deployed as an egress provider edge (PE) switch has no effect.

  • Configuring the revert-timer statement at the [edit protocols mpls] hierarchy level has no effect.