Configuring MPLS

This chapter provides information about how MPLS functions on SR Linux and examples of common configuration tasks. It contains the following topics:

MPLS label manager

SR Linux features an MPLS label manager process that shares the MPLS label space among client applications that require MPLS labels; these applications include static MPLS forwarding and LDP.

For a protocol such as LDP to become operational, it must be configured with a reference to a predefined range of labels, called a label block. A label block configuration includes a start-label value and an end-label value. When the label block is made available to an application, the application can use any label in the range between the start-label and end-label, inclusive of those values.

The MPLS label manager ensures there is no configuration overlap between the labels of two different label blocks.

Static and dynamic label blocks

A label block can be static or dynamic:

A static label block is provided by the MPLS label manager to a client application when it is expected that the client application specifies the exact label value it wants to use with every label request.
A dynamic label block is provided by the MPLS label manager to a client application when it is expected that the client application requests the next available label when it needs a new entry.

A label block can be configured as shared or dedicated. When a label block is configured to be shared, it allows the label block to be made available to multiple protocols. If a label block is not configured as shared, it is reserved for the exclusive use of one protocol.

The label block used by LDP must be configured as a dynamic, non-shared label block. For static MPLS routes, it is necessary to configure a static label block and reference the static label block in the static MPLS configuration.

Configuring label blocks

To configure a static or dynamic label block, you specify the start and end label for the range.

The following example configures a static and dynamic label block.

--{ * candidate shared default }--[  ]--
# info system mpls
    system {
        mpls {
            label-ranges {
                static s1 {
                    start-label 10001
                    end-label 11000
                }
                dynamic d1 {
                    start-label 11001
                    end-label 12000
                }
            }
        }
    }

Displaying label block information

Use the info from state command to display information about the configured label blocks.

--{ * candidate shared default }--[  ]--
# info from state system mpls label-ranges
    system {
        mpls {
            label-ranges {
                static {
                    name s1
                    start-label 10001
                    end-label 11000
                    allocated-labels 10
                    free-labels 990
                    status ready
                    }
                }
            }
        }
    }

Static MPLS forwarding

Statically configured MPLS forwarding entries allow MPLS-labeled packets to be forwarded along a specific path that may differ from the normal shortest path provided by the underlay routing protocol.

Static next-hop-groups used by IPv4 and IPv6 static routes of the default network-instance support MPLS next hops. An MPLS next-hop has a next-hop IP address and a list of MPLS labels (currently limited to 1). When an IP packet matches a static route pointing to a next-hop-group with MPLS next-hops, the packet is MPLS encapsulated according to the selected next-hop.

Static MPLS routes are supported in the default network-instance. Static MPLS routes control the way that transit LSRs, penultimate LSRs, and egress LERs handle received MPLS packets. Each static MPLS route matches a particular label value and causes that label value to be popped from the label stack when it appears as the top label in any received MPLS packet, on any interface. If the static MPLS route points to a next-hop-group with MPLS next-hops, the packet is forwarded to the selected next-hop with a swap operation; ECMP is supported if there are multiple MPLS next-hops. When the pushed-mpls-label-stack parameter for the MPLS next-hop specifies the IPv4 or IPv6 IMPLICIT_NULL label value, no new label is pushed and a PHP pop-and-forward operation is performed.

Configuring an ingress LER

To configure an ingress LER, you specify the label to push to MPLS-encapsulated packets.

The following example shows the default network-instance configured for an ingress LER, specifying the label to push to MPLS-encapsulated packets. In this example, multiple next-hops (ECMP) are specified in a next-hop group.

--{ * candidate shared default }--[  ]--
# info network-instance default next-hop-groups group srva_tora_ipv4
    network-instance default {
        next-hop-groups {
            group srva_tora_ipv4 {
                nexthop 0 {
                    ip-address 192.13.1.3
                    resolve false
                    pushed-mpls-label-stack [
                        544334
                    ]
                }
                nexthop 2 {
                    ip-address 192.13.1.3
                    resolve false
                    pushed-mpls-label-stack [
                        205679
                    ]
                }
            }
        }
    }

Configuring a transit LSR

To configure a transit LSR, you specify a label block for MPLS and a next-hop to use for label-swap operations.

Specify a static label block for MPLS

The following example shows the default network-instance configured as a transit LSR in the label switched path.

This example configures MPLS to use a static label block named s2. The static label block is configured with a start-label value and an end-label value. See Configuring label blocks for an example of a static label block configuration.

The example configures incoming MPLS transit traffic with label 1000 to use the next-hops in next-hop-group nhop_group_1 for label-swap operations.

--{ * candidate shared default }--[  ]--
# info network-instance default mpls
    network-instance default {
        mpls {
            static-label-block s2
            static-entry 1000 preference 100 {
                operation swap
                next-hop-group nhop_group_1
            }
        }
    }

Specify next-hop for MPLS

The following example specifies the MPLS next-hop for nhop_group_1. Only one MPLS next-hop is supported per next-hop-group. In this example, the label for outgoing traffic to MPLS next-hop 192.35.1.5 is swapped to 1001.

--{ * candidate shared default }--[  ]--
# info network-instance default next-hop-groups group nhop_group_1
    network-instance default {
        next-hop-groups {
            group nhop_group_1 {
                nexthop 0 {
                    ip-address 192.35.1.5
                    resolve false
                    pushed-mpls-label-stack [
                        1001
                    ]
                }
            }
        }
    }

Configuring PHP

To configure PHP, you configure MPLS to pop the label for outgoing traffic for a next-hop.

The following example shows the default network-instance configured to perform PHP for the LSR. In this example, the setting for pushed-mpls-label-stack is IMPLICIT_NULL, which causes the label for outgoing traffic to MPLS next-hop 192.35.1.1 to be popped.

--{ * candidate shared default }--[  ]--
# info network-instance default next-hop-groups group nhop_group_2
    network-instance default {
        next-hop-groups {
            group nhop_group_2 {
                nexthop 0 {
                    ip-address 192.35.1.1
                    resolve false
                    pushed-mpls-label-stack [
                        IMPLICIT_NULL
                    ]
                }
            }
        }
    }

ACLs and MPLS traffic

How MPLS traffic is handled by SR Linux ACLs lists how traffic along an MPLS datapath is evaluated by each type of ACL that can be configured on SR Linux. See the SR Linux ACL and Policy-Based Routing Guide for information about configuring ACLs on SR Linux.

Table 1. How MPLS traffic is handled by SR Linux ACLs
MPLS datapath	Evaluated by ingress ACL rules?	Evaluated by egress ACL rules?	Evaluated by CPU QoS entries?	Evaluated by IP CPM filter rules?	Evaluated by IP capture filter rules?
IP → MPLS (LER)	Yes	No	N/A	N/A	Yes
MPLS → MPLS (LSR)	Yes	No	N/A	N/A	No
MPLS → term (label TTL expiry)	Yes	N/A	No	No	No
MPLS → IP (PHP)	Yes	Yes	N/A	N/A	No
MPLS → IP (UHP)	Yes	Yes	N/A	N/A	Yes
MPLS → IP → term (IP address is local)	Yes	N/A	Yes	Yes	Yes

MPLS MTU

The MPLS MTU defines the maximum-sized MPLS packet that can be transmitted from a routed subinterface, including the size of the transmitted label stack (4 bytes * number of label stack entries). If an MPLS packet containing any payload exceeds this size, the packet is dropped.

SR Linux supports a system-wide default MPLS MTU value. If you configure a default MPLS MTU value, that value is programmed as the operational MPLS MTU on all IP interfaces of the system. The supported range for the default MPLS MTU is 1284 to 9496 bytes; default 1508 bytes.

In addition to the system-wide default MPLS MTU, you can configure a subinterface-level MPLS MTU, which applies to subinterfaces of type routed. The supported range for the subinterface-level MPLS MTU is 1284-9496 bytes. If no MPLS MTU is configured for a subinterface, the default MTU value is taken from the system-wide default MPLS MTU.

Each 7250 IXR IMM supports a maximum of four different MPLS MTU values. If a line card already has four different MPLS MTU values, and a fifth MPLS MTU value is configured for a subinterface on the same line card, the subinterface is brought down with the reason mpls-mtu-resource-exceeded.

Configuring the MPLS MTU

You can configure a system-wide default MPLS MTU value, and you can configure a subinterface-level MPLS MTU that applies to subinterfaces of type routed. The supported range for the MPLS MTU is 1284 to 9496 bytes; default 1508 bytes. If no MPLS MTU is configured for a subinterface, the default MPLS MTU value is taken from the system-wide MPLS MTU.

Configure a system-wide default MPLS MTU value

--{ * candidate shared default }--[  ]--
# info system mtu
    system {
        mtu {
            default-mpls-mtu 4096
        }
    }

Configure an MPLS MTU for a routed subinterface

--{ * candidate shared default }--[  ]--
# info interface ethernet-1/1 subinterface 1
    interface ethernet-1/1 {
        subinterface 1 {
            type routed
            admin-state enable
            mpls-mtu 4096
            ipv4 {
                admin-state enable
                address 192.168.11.1/30 {
                }
            }
            ipv6 {
                admin-state enable
                address 2001:1::192:168:11:1/126 {
                }
            }
        }
    }

Displaying MPLS MTU information

Use the info from state command to display MPLS MTU information.

Display the system-wide default MPLS MTU value

--{ * candidate shared default }--[  ]--
# info from state system mtu default-mpls-mtu
    system {
        mtu {
            default-mpls-mtu 4096
        }
    }

Display the MPLS MTU for a subinterface

--{ * candidate shared default }--[  ]--
# info from state interface ethernet-1/1 subinterface 1 mpls-mtu
    interface ethernet-1/1 {
        subinterface 1 {
            mpls-mtu 4096
        }
    }

TTL propagation and TTL expiry

SR Linux supports the Uniform model for TTL propagation as described RFC 3032 and RFC 3443. The Uniform model makes all the nodes that an LSP traverses visible to nodes outside the tunnel.

ICMP extensions for MPLS

SR Linux MPLS support includes ICMP extensions for transit LSRs and egress LERs.

The ICMP extensions, defined in RFC 4950, are by default always enabled.

ICMP extensions for transit LSRs

When a transit LSR receives an MPLS packet that cannot be forwarded (for example, the label TTL has expired or the egress subinterface MPLS MTU was exceeded), the packet is extracted to the CPM, which attempts to find an IP packet under the remaining label stack. If an IP packet is found, the CPM generates the appropriate error message, such as time-exceeded, destination-unreachable, or parameter-problem.

For time-exceeded and destination-unreachable messages only, the CPM generates a multipart ICMPv4/ICMPv6 time-exceeded message with the label stack object of RFC4950. This object encodes the entire MPLS label stack as it was received by the LSR that sends the ICMP message and at least 128 bytes of the original datagram (zero padded to this length if necessary).

Configuring ICMP tunneling

ICMP tunneling is disabled by default. You can enable it for transit LSRs; on egress LERs, the setting for the icmp-tunneling option is not relevant.

If the icmp-tunneling option is disabled, all ICMP messages (including but not limited to multipath ICMP messages constructed according to RFC 4950) are injected into the default network instance for forwarding back to the source. The attempt to find a route to the source may be unsuccessful however.

If the icmp-tunneling option is enabled, all ICMP messages (including but not limited to multipath ICMP messages constructed according to RFC 4950) are injected in the forward direction of the LSP (that is, by re-adding the received label stack, resetting the MPLS TTL in all label stack entries to 255, and performing an ILM lookup on the top label). The source address of the ICMP message is an IP address of the LSR.

The following example enables ICMP tunneling for a transit LSR.

--{ * candidate shared default }--[  ]--
# info network-instance default mpls icmp-tunneling
    network-instance default {
        mpls {
            icmp-tunneling true
        }
    }

ICMP extensions for egress LERs

If the egress LER receives an MPLS packet that cannot be forwarded (for example, the label TTL has expired, the IP TTL has expired, or the egress subinterface IP MTU was exceeded) the packet is extracted to the CPM with an indication of the network-instance associated with the last popped label. The CPM generates the appropriate ICMP error message, such as time-exceeded, destination-unreachable, and so on.

For time-exceeded and destination-unreachable messages only, the CPM generates a multipart ICMPv4/ICMPv6 time-exceeded message with the label stack object of RFC4950. This object encodes the entire MPLS label stack as it was received by the egress LER and at least 128 bytes of the original datagram (zero padded to this length if necessary).

All ICMP messages (including but not limited to multipath ICMP messages constructed according to RFC 4950) are injected into the network instance associated with the last popped label for forwarding back to the source.

If the egress LER receives an MPLS packet, pops the remaining label stack, and finds an IP packet that must be forwarded to a host address on a local subnet, the packet may be queued if there is no ARP entry for the host address. If ARP cannot learn the MAC address of the host after about 3 seconds, the egress LER sends a destination-unreachable/host-unreachable message back to the source.

Label values

A packet traveling along an LSP is identified by its label, the 20-bit unsigned integer. The range is 0 to 1 048 575. Label values 0 to 31 are reserved and are defined as follows:

A value of 0 represents the IPv4 explicit null label. It indicates that the label stack must be popped, and the packet forwarding must be based on the IPv4 header.

The 7730 SXR implementation does not advertise an explicit null label, but can process an explicit null label if advertised. For LDP and SR-TE traffic, when the 7730 SXR receives a request from its peer for an explicit null push, the 7730 SXR honors the request and uses the explicit null label as the outermost transport label.
A value of 1 represents the router alert label. The label value is legal anywhere in the label stack except at the bottom. When a received packet contains this label value at the top of the label stack, it is delivered to a local software module for processing. Packet forwarding is determined by the label beneath it in the stack. However, if the packet is further forwarded, the router alert label is pushed back onto the label stack before forwarding. The use of this label is analogous to the use of the router alert option in IP packets. Because this label cannot typically occur at the bottom of the stack, it is not associated with a specific network layer protocol.

Note: The router alert label can occur at the bottom of the stack when some operations, administration, and management (OAM) tools are used.
A value of 3 represents the implicit null label. It is a label that a Label Switching Router (LSR) can assign and distribute, but which does not appear in the encapsulation. When an LSR would otherwise replace the label at the top of the stack with a new label, but the new label is implicit null, the LSR pops the stack instead of doing the replacement. Although this value may never appear in the encapsulation, it needs to be specified in the LDP protocol, so a value is reserved.
A value of 7 represents the Entropy Label Indicator (ELI) which precedes the actual Entropy Label (EL) that carries the entropy value of the packet in the label stack.
Values 4 to 6 and 8 to 31 are reserved for future use.

The router uses labels for MPLS, LDP, BGP Label Unicast, Segment Routing, as well as packet-based services such as VLL and VPLS.

To enable SR-MPLS features on SR Linux nodes, you must allocate a label range to the Segment Routing Global Block (SRGB). Other applications that require labels, such as LDP, can then be configured with a dynamic label block.

Configuring null label for static tunnels

For dynamic tunnels, SR Linux nodes honor reception of null label advertisement, meaning that the nodes push a null label when transmitting (or with implicit null, skip the push of the outermost tunnel label). However, SR Linux nodes do not support advertisement of null labels with dynamic tunnels.

For static tunnels, SR Linux supports the push of null labels using the nexthop pushed-mpls-label-stack command.

Note: Null labels are supported on 7250 IXR and 7730 SXR platforms.

To enable IPV4_EXPLICIT_NULL, IPV6_EXPLICIT_NULL, or IMPLICIT_NULL for a next-hop group, use the pushed-mpls-label-stack command.

The explicit null label option indicates that the label stack must be popped, and the packet forwarding must be based on the IP header.

The implicit null label option allows an egress LER to receive MPLS packets from the previous hop without the outer LSP label. The operation of the previous hop is referred to as penultimate hop popping (PHP). This option is signaled by the egress LER to the previous hop during the FEC signaling by the LDP control protocol.

In addition, the egress LER can be configured to receive MPLS packet with the implicit null label on a static LSP. LDP must be shut down before changing the implicit null configuration option.

Enable IPv4 explicit null label for next-hop group

The following example enables IPv4 explicit null labels for next-hop group null-group.

--{ candidate shared default }--[  ]--
# info network-instance default next-hop-groups group null-group
    network-instance default {
        next-hop-groups {
            group null-group {
                nexthop 1 {
                    resolve false
                    pushed-mpls-label-stack [
                        IPV4_EXPLICIT_NULL
                    ]
                }
            }
        }
    }

MPLS ECMP

The following sections describe MPLS ECMP options for SR Linux.

MPLS entropy label

Note: MPLS entropy label is supported on 7730 SXR platforms only.

The 7730 SXR supports MPLS entropy label, as described in RFC 6790. The entropy label provides greater granularity for load balancing on an LSR based on a hash label pushed by the iLER after deep inspection of various fields such as: source and destination IP address, source and destination MAC address, and so on, as applicable. In the absence of an entropy label, a typical LSR uses the MPLS label stack for load balancing, which commonly yields to per-service load balancing. The entropy label also removes the need for the LSR to inspect the payload below the label stack and check for an IPv4 or IPv6 header to achieve better (per-flow) load-balancing.

The 7730 SXR supports entropy label on LDP, BGP-LU, SR-ISIS, and TE Policy SR-MPLS tunnels.

Note: The 7730 SXR does not support per-packet load balancing, but rather per-flow load balancing (essentially, per-flow entropy label).

The ability of a node to receive and process the entropy label for an LSP is signaled using capability signaling (referred to as entropy label capability).

Inserting an entropy label adds two labels in the MPLS label stack: the entropy label itself and the entropy label indicator (ELI). The entropy label is inserted directly below the tunnel label and closest to the service payload that has advertised entropy label capability (which may be above the bottom of the stack). The value of the entropy label is calculated based on a hash of the packet payload header. The ELI is a special-purpose MPLS label (value = 7) that indicates that the entropy label follows in the stack. The entropy labeI is always placed immediately below the tunnel label to which hashing applies.

The router inserts an entropy label on a tunnel that is entropy-label-capable when the service has entropy label enabled, even if an implicit or explicit null label has been signaled by the downstream LSR or LER. This ensures consistent behavior and that the entropy label value, as determined by the iLER, is maintained where a tunnel with an implicit null label is stitched at a downstream LSR.

If multiple transport tunnels have the entropy-label command enabled, the entropy label and ELI are inserted below the lowest transport label in the stack. The LSR parses the label stack to detect the ELI. The LSR hashes over the label stack and obtains values for different packets on the service, which spreads the service traffic across the different links, and multiple large services are not brought across the same LAG link member.

Entropy label capability is advertised at the tunnel level by the downstream LSR, which indicates the capability of the node to receive and process the entropy label.

Note: The 7730 SXR also supports control word with entropy label.

An LSR for LDP tunnels passes the entropy label capability from the downstream LSP segment to upstream peers. Earlier releases that do not support the entropy label functionality do not pass the entropy label capability to their peers.

The entropy label is typically inserted only if the downstream peer signals entropy label support. The router inserts only a single entropy label, even if multiple LSP labels exist in a label stack. The entropy label and ELI are inserted immediately below the innermost tunnel label for which the downstream peer LER is known to be entropy-label-capable. This ensures that the entropy label is preserved as far as possible along a path through the network.

The 7730 SXR supports inserting EL/ELI labels before the service label, but after the following transport labels:

LDP
SR-ISIS
TE Policy SR-MPLS
BGP-LU
- LDP
- SR-ISIS
- TE Policy SR-MPLS
- Implicit or explicit null

The 7730 SXR is also supported in a Label Switching Router role for the preceding cases based on hashing rules.

Entropy label insertion is configured using the entropy-label command. If entropy label insertion is configured, the MTU is automatically reduced to account for the overhead of the entropy label and ELI. This reduction occurs whether or not the LSP tunnel used by the service is entropy-label-capable.

In some cases, such as when entropy label is enabled for transport and control word is enabled, the entropy label requires the insertion of two additional labels in the label stack. This insertion can result in an unsupported label stack depth or large changes in the label stack depth during the lifetime of an LSP; for example, because a primary path with entropy label capability enabled is switched to a secondary path for which the far end has not signaled entropy label capability.

Note: On the 7730 SXR, entropy labels do not count toward the label limit.

7730 SXR nodes operating in LSR and eLER roles support the processing of up to two entropy labels.

If an LSR is operating as an ASBR with NHS enabled, up to two EL/ELI label pairs are supported prior to the swapped label. If more than two EL/ELI pairs are present prior to the swapped label, the packet is dropped. Additional EL/ELI pairs are supported after the swap label.

eLER nodes support the termination of a maximum of two EL/ELIs. If more than two EL/ELI pairs are present in the label stack, excluding the payload, the packet is dropped.

On the LSR router, EL push at egress is dictated by the egress tunnel configuration. If the egress tunnel has entropy label enabled and the router popped an EL label, the router pushes an entropy label at egress. Other entropy labels in the label stack that are beneath the operated label do not influence this decision.

If the 7730 SXR does not pop an EL label prior to the operated label, and an EL is present deeper in the label stack, the router does not push a new entropy label, to optimize the label stack.

If more than one EL/ELI pair is in the incoming packet and one of the EL/ELI pairs is popped, the 7730 SXR entropy push operation is determined by the egress entropy configuration.

Ingress LER entropy labels

The 7730 SXR supports entropy labels per LSP, not per service.

The procedures at the ingress LER (iLER) are as specified in section 4.2 of RFC 6790. In general, the router inserts an entropy label in a packet if the downstream node for the LSP tunnel has signaled support for entropy labels and the entropy label is configured for the particular service.

RFC 6790 specifies that the iLER can insert several entropy labels in the label stack where the LSP hierarchy exists, one for each LSP in the hierarchy. However, this can result in unreasonably large label stacks. Therefore, when there are multiple LSPs in a hierarchy, the router only inserts a single entropy label and ELI pair within the innermost LSP label closest to the service payload that has advertised entropy label capability.

The following tables describe entropy label handling on iLER for tunnel over tunnel (ToT) use cases.

Table 2. Entropy label handling on iLER for ToT use cases (SR Policy)
Transport	Entropy Enabled?		Outcome
Transport	TE Policy (LSP)	SR-ISIS	Outcome
TE Policy SR-MPLS Uncolored	Yes	Yes	EL/ELI pushed after transport label stack
	Yes	No	EL/ELI pushed after transport label stack
	No	Yes	EL/ELI pushed after SR-ISIS label ahead of TE Policy stack

Table 3. Entropy label handling on iLER for ToT use cases (BGP-LU over MPLS/SR-ISIS)
Transport	Entropy Enabled?		Outcome
Transport	BGP	MPLS/SR	Outcome
BGP-LU over LDP/SR-ISIS	Yes	Yes	EL/ELI pushed after transport label stack
	Yes	No	EL/ELI pushed after transport label stack
	No	Yes	EL/ELI pushed after MPLS/SR-ISIS label ahead of BGP-LU label

Table 4. Entropy label handling on iLER for ToT use cases (BGP-LU over SR Policy)
Transport	Entropy Enabled?			Outcome
Transport	BGP	TE Policy (LSP)	SR-ISIS	Outcome
BGP-LU over TE Policy (SR-MPLS)	Yes	Yes	Yes	EL/ELI pushed after transport label stack
	Yes	No	Yes	EL/ELI pushed after transport label stack
	Yes	No	No	EL/ELI pushed after transport label stack
	Yes	Yes	No	EL/ELI pushed after transport label stack
	No	Yes	Yes	EL/ELI pushed after SR Label stack
	No	Yes	No	EL/ELI pushed after TE Policy stack
	No	No	Yes	EL/ELI pushed after SR-ISIS

LSR entropy labels

Regardless of the load-balancing option configured on an LSR, if an entropy label is found in the label stack, the LSR exclusively uses the entropy label for load balancing without taking into account the MPLS label stack or any other field after BoS=1.

If PHP is requested by a next-hop LER, the LSR retains the entropy labels that are found immediately below the tunnel label that is to be popped. The system retains and uses the entropy label information as input to the local hash routine if an applicable LSR load-balancing mode is configured.

If the received label stack contains an entropy label prior to the swapped label, and the entropy label capability is enabled for the egress tunnel, the received and popped entropy label is pushed back onto the stack. This logic allows the hash generated by the iLER to be preserved end-to-end.

For example, when a packet is received with EL hash label and is operating as NHS for BGP-LU and the egress has multiple BGP next hops (ECMP) with multiple LSPs or NHLFEs to every BGP-LU next hop, the incoming ELI is used to hash traffic across multiple BGP-LU peers, followed by ECMP across parallel LSPs/NHLFEs to the identified peer.

ABR/ASBR (BGP-LU/BGP Prefix SID swap)

As an example, consider an ASBR with the following received label stack:

SVC + BGP-LU + EL/ELI + tunnel (LDP, SR, TE Policy, null)

In this case, the BGP-LU-enabled ASBR pops the tunnel labels and swaps the BGP-LU label. And if it is also configured for entropy label push against the egress tunnel, the ASBR transmits the following label stack:

SVC + BGP-LU (new) + EL/ELI + tunnel (new)

Note:

If the 7730 SXR pops the entropy label and needs to push a new entropy label according to the egress tunnel configuration, it reuses the same EL label that it popped. Typically, the iLER has the most comprehensive access to the payload, which results in more detailed identification of flows represented in the entropy label. The 7730 SXR reuses the incoming label to preserve the most detailed view of traffic flow.
To avoid expanding the label stack depth, the 7730 SXR does not push more than one EL/ELI at egress even if multiple tunnels are configured for entropy label.

ABR/ASBR (full transport label termination, such as IP-VPN option-B)

As an additional example, consider an ABR with the following received label stack:

SVC + EL/ELI + BGP-LU + tunnel (LDP, SR, TE Policy, null)

In this case, the BGP-LU-enabled ABR pops the tunnel labels and swaps the SVC label, as follows:

If the ABR is configured for EL/ELI push at BGP-LU level, the ABR transmits the following label stack (regardless of the tunnel-level entropy label configuration):

SVC (new) + EL/ELI + BGP-LU (new) + tunnel (new)
If the ABR is not configured for EL/ELI push at BGP-LU level but is configured with entropy label for the tunnel, the ABR transmits the following label stack:

SVC (new) + BGP-LU (new) + EL/ELI + tunnel (new)

In either case, because the iLER computed EL is typically best to identify flows, and the iLER also has access to the payload, the same EL label is reused at egress.

Egress LER entropy labels

At an egress LER (eLER), if an entropy label and ELI are detected in the label stack, both are popped and the packet is processed as normal. This occurs whether or not the system has signaled entropy label capability.

If an ELI is popped that has the bottom of stack (BoS) bit set, the system discards the packet and raises a trap, as described in section 4.1 of RFC 6790.

Entropy labels on self-generated traffic

Entropy label push for self-generated traffic such as lsp-trace packets is not supported. If an OAM packet is received with an entropy label, the entropy label is popped and the packet is handed off to the appropriate subsystem for handling.

Configuring MPLS entropy labels

The entropy-label command provides local control at the head-end of an LSP over whether the entropy label is inserted on an LSP by overriding the entropy label capability signaled from the far-end LER.

Note:

When the 7730 SXR is configured as the inline route reflector (RR) for an IP-VPN service, the entropy label is terminated at ingress. Regardless of the egress configuration, a new entropy label is not pushed.

When the 7730 SXR is configured as the inline RR for a BGP-LU label termination, including swap with a new label, the entropy label is terminated. Regardless of the egress configuration, a new entropy label is not pushed.

To enable MPLS entropy labels, use the entropy-label command for the following protocols using the specified contexts:

BGP-LU: network-instance protocols bgp bgp-label labeled-unicast entropy-label
LDP: network-instance protocols ldp entropy-label
SR-ISIS: network-instance protocols isis instance segment-routing mpls entropy-label
TE policy: network-instance traffic-engineering-policies policy entropy-label

Depending on the context, the following entropy label parameters are available:

advertise-capability: when set to true, the router advertises the entropy label capability and includes the ELI/EL in the label stack only if the remote endpoint also signals support for the entropy label capability; when set to false (the default), no ELI/EL is included even if the endpoint signals support for the entropy label.
transmit: when set to enable, the router includes the ELI/EL in the label stack whether or not the remote endpoint signals support for the entropy label capability (default: disable)

Configure MPLS entropy labels for segment routing

The following shows a basic example of enabling entropy labels on SR-ISIS.

# info network-instance default protocols isis instance 1 segment-routing mpls
    network-instance default {
        protocols {
            isis {
                instance 1 {
                    segment-routing {
                        mpls {
                            entropy-label {
                                advertise-capability false
                                transmit enable
                            }
                        }
                    }
                }
            }
        }
    }

Displaying MPLS entropy label information from state

To display state information for MPLS entropy labels, you can use the following info from state commands:

info from state network-instance protocols ldp [ipv4 | ipv6] bindings received-prefix-fec prefix-fec entropy-label-transmit
info from state network-instance protocols ldp peers peer received-capabilities entropy-label-capability
info from state network-instance route-table next-hop mpls entropy-label-transmit
info from state network-instance traffic-engineering-policies policy segment-list entropy-label-transmit
info from state network-instance traffic-engineering-policies policy-database sr-uncolored policy segment-list entropy-label-transmit

MPLS ECMP (7730 SXR platforms)

For hash key generation on 7730 SXR platforms, SR Linux can parse the following seven unique header types:

Ethernet headers:
- The outermost Ethernet header on the wire counts as one unique header type.
- The inner payload Ethernet header (EVPN IFF (interface-ful) case) counts as one unique header type.
Up to two VLANs:
- The inner VLAN counts as one unique header type.
- The outer VLAN counts as one unique header type.
Up to 14 labels
Source/destination IP address
Source/destination Layer 4 port
Tunnel endpoint identifier (TEID) (TCP/UDP destination port 2123, 2152, or 3386)
Entropy label

The hash key is generated based on fields within the first 128 bytes of the frame. Special labels, such as pseudowire control word (CW), are not included in the hash calculation.

The following table lists the fields used for hash key generation for each LSR role on 7730 SXR platforms. Note that the number of ECMP links in the group is used only for IP and MPLS ECMP; LAG hash does not include ECMP link count in the hash calculation.

Table 5. Fields used for hash key generation
Role	Traffic type	Fields used for hash key generation
iLER	Layer 3 subinterface traffic	System IP Number of ECMP links in the group Ingress subinterface index Source IP Destination IP Layer 4 source port Layer 4 destination port TEID
	Layer 2 subinterface traffic	System IP Number of ECMP links in the group Ingress subinterface index Source MAC Destination MAC Outermost VLAN
	IRB traffic	System IP Number of ECMP links in the group Ingress subinterface index Source MAC Destination MAC Outermost VLAN Source port Destination port Source IP Destination IP TEID
LSR	Layer 2 payload (for example, MAC-VRF) traffic	System IP Number of ECMP links in the group Ingress subinterface index MPLS label stack Source MAC Destination MAC Outermost VLAN
	Layer 2 and Layer 3 payload (for example, EVPN IFF) traffic	System IP Number of ECMP links in the group Ingress subinterface index MPLS label stack Source MAC Destination MAC Outermost VLAN Source IP Destination IP Source port Destination port TEID
	Layer 3 payload (for example, IP-VPN) traffic	System IP Number of ECMP links in the group Ingress subinterface index MPLS label stack Source IP Destination IP Source port Destination port TEID
	ELI in stack	System IP Number of ECMP links in the group Ingress subinterface index Entropy label
eLER	Layer 3 subinterface traffic	System IP Number of ECMP links in the group Ingress subinterface index MPLS label stack Source IP Destination IP Source port Destination port TEID
	Layer 2 subinterface traffic	System IP Number of ECMP links in the group Ingress subinterface index Source MAC Destination MAC Outermost VLAN
	IRB symmetric traffic	System IP Number of ECMP links in the group Ingress subinterface index Source IP Destination IP Source port Destination port TEID
	IRB asymmetric traffic	System IP Number of ECMP links in the group Ingress subinterface index Source MAC Destination MAC Outermost VLAN

TEID as hash key

GTP TEID plays a crucial role in mobile backhaul networks. User equipment (UE) such as mobile phones transmit a TEID value to identify data flows. In many cases, all flows from UEs between a radio and its controller can have the same source IP (for the radio), destination IP (for the packet gateway), source port, and destination port. To perform load balancing, the system must inspect deeper into the packet to use the TEID value as an input to the hash key.

When the IPv4/IPv6 UDP destination port is 2123 or 2152, the system assumes that the next header is a GTP header. To perform hashing with GTP TEID in the label stack, the system uses the following logic:

If the next nibble following the MPLS BoS label is 4, the system assumes the payload is IPv4 and hashing is based on the MPLS label stack, IPv4, Layer 4, and TEID.
If the next nibble following the MPLS BoS label is 6, the system assumes the payload is IPv6 and hashing is based on the MPLS label stack, IPv6, Layer 4, and TEID.
If the next nibble following the MPLS BoS label is any value other than IPv4 or IPv6, the system assumes the payload is Ethernet and hashing is based on the MPLS label stack, Ethernet Layer 2, IP, and Layer 4.

Note: In the presence of an entropy label, the system uses only the entropy label for the hash calculation. The preceding TEID logic applies only to traffic without the entropy label.

iLER

For iLER Layer 2 subinterfaces, up to two VLANs are used for hash key generation. Up to 14 VLANs can be skipped for IP speculation to take effect.

LSR

If ELI is present, ELI is used for hashing. If ELI is not present, the MPLS label stack and Layer 2/3 properties are considered for hashing purposes. Label-only hash or label hash with Ethernet or IP headers can be configured to dictate the LSR hashing scope. In either case, if an entropy label is detected in the incoming label stack, it is used for hashing.

When no entropy label is present, up to 14 MPLS labels are used for hashing on the LSR:

If the first nibble is 4/6, hashing is based on source/destination IP and source/destination port, if destination TCP/UDP port = 2123 / 2152 / 3386, next-header is attempted to be hashed as described in TEID as hash key
If the first nibble is not 4/6, assume Ethernet, and hashing is based on source and destination MAC, Dot1q or QnQ tags based on ethertype, followed by hashing listed for the LSR role in Fields used for hash key generation.

eLER

If ELI is present, ELI is used for hashing.

MPLS LSR ECMP (7250 IXR platforms)

SR Linux supports two options to perform MPLS ECMP packet hashing:

LSR label-only hash (default)
LSR label hash with Ethernet or IP headers (with L4 and TEID)

LSR label-only hash

By default, MPLS packet hashing at an LSR is based on the whole label stack, along with the incoming port and system IP address. With this label-only hash option, the system hashes the packet using up to 14 labels in the MPLS stack.

The system uses the net result to select which LSP next-hop to send the packet to using a modulo operation of the hash result with the number of next-hops.

This same result feeds to a second round of hashing if there is a LAG on the egress port where the selected LSP has its NHLFE programmed.

LSR label hash with Ethernet or IP headers (with L4 and TEID)

With the LSR label hash option with Ethernet or IP headers (with L4 and TEID), the datapath performs Ethernet speculation after the bottom of the label stack or when the maximum label stack depth is reached. Regardless of the outcome of the Ethernet speculation, the system also attempts IPv4/IPv6 speculation by checking the first nibble after the bottom of the label stack to include the following in the hash:

source and destination IP address
UDP/TCP source and destination ports
GPRS tunneling protocol (GTP) tunnel endpoint identifier (TEID) when the UDP or TCP port is 2123 or 2152

If Ethernet header speculation is successful, source and destination MAC are included in the hash along with up to two VLANs.

Configuring MPLS ECMP hashing options

To configure MPLS ECMP hashing options on an LSR, use the system load-balancing lsr-profile command.

Enable the label-only hash option

The following example enables the label-only hash option on an LSR.

--{ candidate shared default }--[  ]--
# system load-balancing lsr-profile label-stack

Enable the LSR label hash option with Ethernet or IP headers (with L4 and TEID)

The following example enables the LSR label option with Ethernet or IP headers (with L4 and TEID) on an LSR.

--{ candidate shared default }--[  ]--
# system load-balancing lsr-profile label-eth-or-ip-l4-teid

Show reports for MPLS tunnel tables

You can issue a show command to display information about MPLS tunnel table entries. You can adjust the output of the report to filter by address type, encapsulation type, tunnel type, and destination prefix.

The following is an example of output from the show report.

--{ * candidate shared default }--[  ]--
# show network-instance default tunnel-table all
---------------------------------------------------------------------------------------------------
IPv4 tunnel table of network-instance "base"
--------------------------------------------------------------------------------------------------------
+-------------+-------+-------------+-----------+-----+--------+------+----------------+----------+
| IPv4 Prefix | Encap | Tunnel Type | Tunnel ID | FIB | Metric | Pref | Next-hop (Type)| Next-hop |
|             | Type  |             |           |     |        |      |                |          |
+=============+=======+=============+===========+=====+========+======+================+==========+
| 1.1.1.3/32  | mpls  | ldp         | 65629     | Y   | 2000   | 9    | 1.3.2.3 (mpls) | lag1.1   |
|             |       |             |           |     |        |      | 1.3.3.3 (mpls) | lag1.2   |
|             |       |             |           |     |        |      | 1.3.4.3 (mpls) | lag1.3   |
|             |       |             |           |     |        |      | 1.3.5.3 (mpls) | lag1.4   |
| 1.1.1.4/32  | mpls  | ldp         | 65631     | Y   | 2006   | 9    | 1.7.1.4 (mpls) | lag7.1   |
|             |       |             |           |     |        |      | 1.7.2.4 (mpls) | lag7.2   |
|             |       |             |           |     |        |      | 1.7.3.4 (mpls) | lag7.3   |
|             |       |             |           |     |        |      | 1.7.4.4 (mpls) | lag7.4   |
| 1.1.1.5/32  | mpls  | ldp         | 65630     | Y   | 2007   | 9    | 1.8.2.5 (mpls) | lag8.1   |
|             |       |             |           |     |        |      | 1.8.3.5 (mpls) | lag8.2   |
|             |       |             |           |     |        |      | 1.8.4.5 (mpls) | lag8.3   |
|             |       |             |           |     |        |      | 1.8.5.5 (mpls) | lag8.4   |
+-------------+-------+-------------+-----------+-----+--------+------+----------------+----------+

TTM preferences for supported tunnel types

The following table summarizes the TTM preferences for all supported tunnel types on the 7250 IXR and 7730 SXR systems.

Table 6. TTM preferences for supported tunnel types
Tunnel type	TTM preference
Uncolored SR-MPLS TE-Policy	8
LDP	9
SR-ISIS	11
BGP (LU)	12