mpls
—
Multiprotocol Label Switching
MultiProtocol Label Switching represents a mechanism which directs and carries
data in high-performance networks, its techniques being applicable to any
network layer protocol.
In an MPLS domain the assignment of a particular packet a
particular Forward Equivalence Class is done just once, as the packet enters
the network. The FEC to which the packet is assigned is encoded as a short
fixed length value known as a “label”. When a packet is
forwarded to the next hop, the label is sent along with it; that is, the
packets are “labeled” before they are forwarded.
A router capable of receiving and forwarding MPLS frames is called
“Label Switch Router” or LSR. Label scope is generally
router-wide meaning that a certain label has a specific meaning only for a
certain LSR.
Currently, NetBSD supports MPLS over
Ethernet interfaces and GRE tunnels. For these kind of interfaces, a label
is contained by a fixed sized “shim” that precedes any network
layer headers, just after data link layer headers.
In network bit order:
-------------------------------------------
| | | | |
| Label | TC | BoS | TTL |
| 20 bits | 3 bits | 1 bit | 8 bits |
| | | | |
-------------------------------------------
- Label
- 20 bits representing FEC, consequently the only information used to
forward the frame to next-hop
- Traffic Class Field
- 3 bits that are used for specifying a traffic class, usually used for
defining a type of service. This field was named the "Experimental
Field" in most early (pre-
RFC 5462
)
documents.
- Bottom of Stack
- One bit that is set for the last entry in the shim stack and 0 for all
others. An MPLS frame may contain more than one shim, the last one before
the network headers being marked by setting the BoS bit.
- TTL
- 8 bits, representing Time to Live, decremented at every LSR.
The MPLS behavior is controlled by the net.mpls
sysctl(8) tree:
net.mpls.accept
- If zero, MPLS frames are dropped on sight on ingress interfaces.
net.mpls.forwarding
- If zero, MPLS frames are not forwarded to next-hop.
net.mpls.ttl
- The default ttl for self generated MPLS frames.
net.mpls.inet_mapttl
- If set, TTL field from IP header will be mapped into the MPLS shim on
encapsulation, and the TTL field from MPLS shim will be copied into IP
header on decapsulation.
net.mpls.inet6_mapttl
- The IPv6 version of the above.
net.mpls.inet_map_prec
- If set, precedence field from IP header will be mapped into MPLS shim in
TC field on encapsulation, and the MPLS TC field will be copied into IP
Precedence field on decapsulation.
net.mpls.inet6_map_prec
- The IPv6 version of the above.
net.mpls.icmp_respond
- Returns ICMP TTL exceeded in transit when an MPLS frame is dropped because
of TTL = 0 on egress interface.
net.mpls.rfc4182
- Pop the Explicit Null labels as specified by
RFC
4182
In order to encapsulate and decapsulate to and from MPLS, an mpls
pseudo-interface must be created and packets that should be encapsulated must
be routed to that interface.
MPLS routes may be created using AF_MPLS
sa_family
sockaddrs for destination and tag fields.
Other protocols can be encapsulated using routes pointing to mpls
pseudo-interfaces, and AF_MPLS
sockaddrs for tags.
Decapsulation can be made using values of reserved labels set in the tag
field (see below). For more information about doing this using userland
utilities see the EXAMPLES section of
this manual page.
The netstat(1) and
route(8) utilities should be
used to manage routes from userland.
The NetBSD implementation stores route
tagging information into a sockaddr_mpls structure that is referenced by the
rt_tag field of rtentry struct. For storing multiple labels associated with
the next-hop, the current implementation abuses the sockaddr_mpls structure,
extending it in order to fit a stack of labels.
ldpd(8) should be used
in order to automatically import, manage and distribute labels among LSRs in
the same MPLS domain.
MPLS labels 0 through 15 are reserved. Out of those, only four are currently
defined:
- 0
- IPv4 Explicit NULL label. This label value is only legal at the bottom of
the label stack. It indicates that the label stack must be popped, and the
forwarding of the packet must then be based on the IPv4 header.
- 1
- Router Alert Label. Currently not implemented in
NetBSD.
- 2
- IPv6 Explicit NULL label. It indicates that the label stack must be
popped, and the forwarding of the packet must then be based on the IPv6
header.
- 3
- Implicit NULL label. This is a label that an LSR may assign and
distribute, but which never actually appears 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 will
pop the stack instead of doing the replacement. In this case, the LSR will
have to deduce by itself what is the original address family of the
encapsulated network packet. Currently, NetBSD
implementation is assuming that the latter address family is equal to the
next-hop address family specified in the Implicit Null Label MPLS
route.
- Create an MPLS interface and set an IP address:
# ifconfig mpls0 create up
# ifconfig mpls0 inet 192.168.0.1/32
- Route IP packets into MPLS domain with a specific tag
# route add 10.0.0.0/8 -ifp mpls0 -tag 25 -inet 192.168.1.100
- Create a static MPLS forwarding rule - swap the incoming label 50 to 33
and forward the frame to 192.168.1.101 and verify the route
# route add -mpls 50 -tag 33 -inet 192.168.1.101
add host 50: gateway 192.168.1.101
# route -n get -mpls 50
route to: 50
destination: 50
gateway: 192.168.1.101
Tag: 33
local addr: 192.168.1.180
interface: sk0
flags: <UP,GATEWAY,HOST,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 0 0
sockaddrs: <DST,GATEWAY,IFP,IFA,TAG>
- Route IP packets into MPLS domain but use a different source address for
local generated packets.
# route add 10.0.0.0/8 -ifa 192.168.1.180 -ifp mpls0 -tag 25 -inet 192.168.1.100
For the latter example, setting an IP address for the mpls0 interface is not
necessary.
- Route MPLS packets encapsulated with label 60 to 192.168.1.100 and POP
label
# route add -mpls 60 -tag 3 -inet 192.168.1.100
- Route IP packets into MPLS domain and prepend more tags
# route add 10/8 -ifa 192.168.1.200 -ifp mpls0 -tag 20,30,40 -inet 192.168.1.100
For the above example, tag 20 will be inserted at Bottom of Stack, while tag
40 will be set into the outermost shim.
- Replace label 60 with label 30, prepend two more labels: 40 and 41 (in
this order) and forward the result to 192.168.1.100
# route add -mpls 60 -tag 30,40,41 -inet 192.168.1.100
netstat(1),
route(4),
ldpd(8),
route(8),
sysctl(8)
Multiprotocol Label Switching
Architecture, RFC 3031.
MPLS Label Stack
Encoding, RFC 3032.
Removing a Restriction on the
use of MPLS Explicit NULL, RFC
4182.
MPLS Label Stack Entry: EXP
Field Renamed to Traffic Class Field, RFC
5462.
The mpls
support appeared in NetBSD
6.0.
User must be aware that encapsulating IP packets in MPLS implies a major
security effect when using firewalls. Currently neither
ipf(4) nor
pf(4) implement the heuristics in
order to look inside an MPLS frame. Moreover, it's technically impossible in
most cases for an LSR to know information related to encapsulated packet.
Therefore, MPLS Domains should be strictly controlled and, in most cases,
limited to trusted connections inside the same Autonomous System.
Users must be aware that the MPLS forwarding domain is entirely
separated from the inner (IP, IPv6 etc.) forwarding domain and once a packet
is encapsulated in MPLS, the former forwarding is used. This could result in
a different path for MPLS encapsulated packets than the original non-MPLS
one.
IP or IPv6 forwarding is not necessary for MPLS forwarding. Your
system may still forward IP or IPv6 packets encapsulated into MPLS if
net.mpls.forwarding
is set.