Updated: 2022/Sep/29

Please read Privacy Policy. It's for your privacy.

MPLS(4)                      Device Drivers Manual                     MPLS(4)

     mpls - Multiprotocol Label Switching

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

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

     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

     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-

     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

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

     1.   Create an MPLS interface and set an IP address:

          # ifconfig mpls0 create up
          # ifconfig mpls0 inet

     2.   Route IP packets into MPLS domain with a specific tag

          # route add -ifp mpls0 -tag 25 -inet

     3.   Create a static MPLS forwarding rule - swap the incoming label 50 to
          33 and forward the frame to and verify the route

          # route add -mpls 50 -tag 33 -inet
          add host 50: gateway
          # route -n get -mpls 50
             route to: 50
          destination: 50
                  Tag: 33
           local addr:
            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>

     4.   Route IP packets into MPLS domain but use a different source address
          for local generated packets.

          # route add -ifa -ifp mpls0 -tag 25 -inet
          For the latter example, setting an IP address for the mpls0
          interface is not necessary.

     5.   Route MPLS packets encapsulated with label 60 to and
          POP label

          # route add -mpls 60 -tag 3 -inet

     6.   Route IP packets into MPLS domain and prepend more tags

          # route add 10/8 -ifa -ifp mpls0 -tag 20,30,40 -inet
          For the above example, tag 20 will be inserted at Bottom of Stack,
          while tag 40 will be set into the outermost shim.

     7.   Replace label 60 with label 30, prepend two more labels: 40 and 41
          (in this order) and forward the result to

          # route add -mpls 60 -tag 30,40,41 -inet

     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

     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.

NetBSD 9.99                   September 14, 2018                   NetBSD 9.99