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

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

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

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

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 Configuration Basics 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, which can be configured with a range of 1284-9496 bytes; default is 1508 bytes. In addition, 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.

If a subinterface has a configured (or inherited) MPLS MTU of x bytes and it is associated with an untagged port with port MTU y bytes, and x+14 > y then the subinterface is brought down for reason mpls-mtu-too-large.

If a subinterface has a configured (or inherited) MPLS MTU of x bytes and it is associated with a dot1q port with port MTU y bytes, and x+18 > y then the subinterface is brought down for reason mpls-mtu-too-large.

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-9496 bytes. The default for the system-wide MPLS MTU is 1508 bytes, If no MPLS MTU is configured for a subinterface, the default MTU value is taken from the system-wide MPLS MTU.

The following example configures a system-wide default MPLS MTU value:

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

The following example configures 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 {
                address 192.168.11.1/30 {
                }
            }
            ipv6 {
                address 2001:1::192:168:11:1/126 {
                }
            }
        }
    }

Displaying MPLS MTU information

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

To 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
        }
    }

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

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