NAME

mpls — Multiprotocol Label Switching

SYNOPSIS

options MPLS
pseudo-device ifmpls
#include <sys/types.h>
#include <netmpls/mpls.h>

DESCRIPTION

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.

MPLS shim header structure

In network bit order:

------------------------------------------- 
|               |        |       |        | 
| Label         | TC     | BoS   | TTL    | 
| 20 bits       | 3 bits | 1 bit | 8 bits | 
|               |        |       |        | 
-------------------------------------------

USAGE

The MPLS behavior is controlled by the net.mpls sysctl(8) tree: 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.

RESERVED LABELS

MPLS labels 0 through 15 are reserved. Out of those, only four are currently defined:

EXAMPLES

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

HISTORY

The mpls support appeared in NetBSD 6.0.

SECURITY CONSIDERATIONS

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.

Manual browser: mpls(4)