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