diff options
Diffstat (limited to 'static/netbsd/man4/mpls.4 3.html')
| -rw-r--r-- | static/netbsd/man4/mpls.4 3.html | 261 |
1 files changed, 261 insertions, 0 deletions
diff --git a/static/netbsd/man4/mpls.4 3.html b/static/netbsd/man4/mpls.4 3.html new file mode 100644 index 00000000..1a36be39 --- /dev/null +++ b/static/netbsd/man4/mpls.4 3.html @@ -0,0 +1,261 @@ +<table class="head"> + <tr> + <td class="head-ltitle">MPLS(4)</td> + <td class="head-vol">Device Drivers Manual</td> + <td class="head-rtitle">MPLS(4)</td> + </tr> +</table> +<div class="manual-text"> +<section class="Sh"> +<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1> +<p class="Pp"><code class="Nm">mpls</code> — + <span class="Nd">Multiprotocol Label Switching</span></p> +</section> +<section class="Sh"> +<h1 class="Sh" id="SYNOPSIS"><a class="permalink" href="#SYNOPSIS">SYNOPSIS</a></h1> +<p class="Pp"><code class="Cd">options MPLS</code> + <br/> + <code class="Cd">pseudo-device mpls</code> + <br/> + <code class="In">#include <<a class="In">sys/types.h</a>></code> + <br/> + <code class="In">#include <<a class="In">netmpls/mpls.h</a>></code></p> +</section> +<section class="Sh"> +<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1> +<p class="Pp">MultiProtocol Label Switching represents a mechanism which directs + and carries data in high-performance networks, its techniques being + applicable to any network layer protocol.</p> +<p class="Pp">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.</p> +<p class="Pp">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.</p> +<p class="Pp">Currently, <span class="Ux">NetBSD</span> 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.</p> +<section class="Ss"> +<h2 class="Ss" id="MPLS_shim_header_structure"><a class="permalink" href="#MPLS_shim_header_structure">MPLS + shim header structure</a></h2> +<p class="Pp">In network bit order:</p> +<div class="Bd Pp Li"> +<pre>------------------------------------------- +| | | | | +| Label | TC | BoS | TTL | +| 20 bits | 3 bits | 1 bit | 8 bits | +| | | | | +-------------------------------------------</pre> +</div> +<dl class="Bl-tag"> + <dt>Label</dt> + <dd>20 bits representing FEC, consequently the only information used to + forward the frame to next-hop</dd> + <dt>Traffic Class Field</dt> + <dd>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-<code class="Li">RFC 5462</code>) + documents.</dd> + <dt>Bottom of Stack</dt> + <dd>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.</dd> + <dt>TTL</dt> + <dd>8 bits, representing Time to Live, decremented at every LSR.</dd> +</dl> +</section> +</section> +<section class="Sh"> +<h1 class="Sh" id="USAGE"><a class="permalink" href="#USAGE">USAGE</a></h1> +<p class="Pp">The MPLS behavior is controlled by the + <code class="Li">net.mpls</code> <a class="Xr">sysctl(8)</a> tree:</p> +<dl class="Bl-tag"> + <dt id="net.mpls.accept"><a class="permalink" href="#net.mpls.accept"><code class="Li">net.mpls.accept</code></a></dt> + <dd>If zero, MPLS frames are dropped on sight on ingress interfaces.</dd> + <dt id="net.mpls.forwarding"><a class="permalink" href="#net.mpls.forwarding"><code class="Li">net.mpls.forwarding</code></a></dt> + <dd>If zero, MPLS frames are not forwarded to next-hop.</dd> + <dt id="net.mpls.ttl"><a class="permalink" href="#net.mpls.ttl"><code class="Li">net.mpls.ttl</code></a></dt> + <dd>The default ttl for self generated MPLS frames.</dd> + <dt id="net.mpls.inet_mapttl"><a class="permalink" href="#net.mpls.inet_mapttl"><code class="Li">net.mpls.inet_mapttl</code></a></dt> + <dd>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.</dd> + <dt id="net.mpls.inet6_mapttl"><a class="permalink" href="#net.mpls.inet6_mapttl"><code class="Li">net.mpls.inet6_mapttl</code></a></dt> + <dd>The IPv6 version of the above.</dd> + <dt id="net.mpls.inet_map_prec"><a class="permalink" href="#net.mpls.inet_map_prec"><code class="Li">net.mpls.inet_map_prec</code></a></dt> + <dd>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.</dd> + <dt id="net.mpls.inet6_map_prec"><a class="permalink" href="#net.mpls.inet6_map_prec"><code class="Li">net.mpls.inet6_map_prec</code></a></dt> + <dd>The IPv6 version of the above.</dd> + <dt id="net.mpls.icmp_respond"><a class="permalink" href="#net.mpls.icmp_respond"><code class="Li">net.mpls.icmp_respond</code></a></dt> + <dd>Returns ICMP TTL exceeded in transit when an MPLS frame is dropped because + of TTL = 0 on egress interface.</dd> + <dt id="net.mpls.rfc4182"><a class="permalink" href="#net.mpls.rfc4182"><code class="Li">net.mpls.rfc4182</code></a></dt> + <dd>Pop the Explicit Null labels as specified by <code class="Li">RFC + 4182</code></dd> +</dl> +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. +<p class="Pp">MPLS routes may be created using <code class="Dv">AF_MPLS</code> + <code class="Li">sa_family</code> sockaddrs for destination and tag fields. + Other protocols can be encapsulated using routes pointing to mpls + pseudo-interfaces, and <code class="Dv">AF_MPLS</code> 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 <a class="Sx" href="#EXAMPLES">EXAMPLES</a> section of + this manual page.</p> +<p class="Pp">The <a class="Xr">netstat(1)</a> and <a class="Xr">route(8)</a> + utilities should be used to manage routes from userland.</p> +<p class="Pp">The <span class="Ux">NetBSD</span> 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.</p> +<p class="Pp"><a class="Xr">ldpd(8)</a> should be used in order to automatically + import, manage and distribute labels among LSRs in the same MPLS domain.</p> +<section class="Ss"> +<h2 class="Ss" id="RESERVED_LABELS"><a class="permalink" href="#RESERVED_LABELS">RESERVED + LABELS</a></h2> +<p class="Pp">MPLS labels 0 through 15 are reserved. Out of those, only four are + currently defined:</p> +<dl class="Bl-tag"> + <dt>0</dt> + <dd>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.</dd> + <dt>1</dt> + <dd>Router Alert Label. Currently not implemented in + <span class="Ux">NetBSD</span>.</dd> + <dt>2</dt> + <dd>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.</dd> + <dt>3</dt> + <dd>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, <span class="Ux">NetBSD</span> + implementation is assuming that the latter address family is equal to the + next-hop address family specified in the Implicit Null Label MPLS + route.</dd> +</dl> +</section> +</section> +<section class="Sh"> +<h1 class="Sh" id="EXAMPLES"><a class="permalink" href="#EXAMPLES">EXAMPLES</a></h1> +<ol class="Bl-enum"> + <li>Create an MPLS interface and set an IP address: + <div class="Bd Pp Li"> + <pre># ifconfig mpls0 create up +# ifconfig mpls0 inet 192.168.0.1/32</pre> + </div> + </li> + <li>Route IP packets into MPLS domain with a specific tag + <div class="Bd Pp Li"> + <pre># route add 10.0.0.0/8 -ifp mpls0 -tag 25 -inet 192.168.1.100</pre> + </div> + </li> + <li>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 + <div class="Bd Pp Li"> + <pre># 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></pre> + </div> + </li> + <li>Route IP packets into MPLS domain but use a different source address for + local generated packets. + <div class="Bd Pp Li"> + <pre># route add 10.0.0.0/8 -ifa 192.168.1.180 -ifp mpls0 -tag 25 -inet 192.168.1.100</pre> + </div> + For the latter example, setting an IP address for the mpls0 interface is not + necessary.</li> + <li>Route MPLS packets encapsulated with label 60 to 192.168.1.100 and POP + label + <div class="Bd Pp Li"> + <pre># route add -mpls 60 -tag 3 -inet 192.168.1.100</pre> + </div> + </li> + <li>Route IP packets into MPLS domain and prepend more tags + <div class="Bd Pp Li"> + <pre># route add 10/8 -ifa 192.168.1.200 -ifp mpls0 -tag 20,30,40 -inet 192.168.1.100</pre> + </div> + For the above example, tag 20 will be inserted at Bottom of Stack, while tag + 40 will be set into the outermost shim.</li> + <li>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 + <div class="Bd Pp Li"> + <pre># route add -mpls 60 -tag 30,40,41 -inet 192.168.1.100</pre> + </div> + </li> +</ol> +</section> +<section class="Sh"> +<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE + ALSO</a></h1> +<p class="Pp"><a class="Xr">netstat(1)</a>, <a class="Xr">route(4)</a>, + <a class="Xr">ldpd(8)</a>, <a class="Xr">route(8)</a>, + <a class="Xr">sysctl(8)</a></p> +<p class="Pp"><cite class="Rs"><span class="RsT">Multiprotocol Label Switching + Architecture</span>, <span class="RsR">RFC 3031</span>.</cite></p> +<p class="Pp"><cite class="Rs"><span class="RsT">MPLS Label Stack + Encoding</span>, <span class="RsR">RFC 3032</span>.</cite></p> +<p class="Pp"><cite class="Rs"><span class="RsT">Removing a Restriction on the + use of MPLS Explicit NULL</span>, <span class="RsR">RFC + 4182</span>.</cite></p> +<p class="Pp"><cite class="Rs"><span class="RsT">MPLS Label Stack Entry: EXP + Field Renamed to Traffic Class Field</span>, <span class="RsR">RFC + 5462</span>.</cite></p> +</section> +<section class="Sh"> +<h1 class="Sh" id="HISTORY"><a class="permalink" href="#HISTORY">HISTORY</a></h1> +<p class="Pp">The <code class="Nm">mpls</code> support appeared in + <span class="Ux">NetBSD 6.0</span>.</p> +</section> +<section class="Sh"> +<h1 class="Sh" id="SECURITY_CONSIDERATIONS"><a class="permalink" href="#SECURITY_CONSIDERATIONS">SECURITY + CONSIDERATIONS</a></h1> +<p class="Pp">User must be aware that encapsulating IP packets in MPLS implies a + major security effect when using firewalls. Currently neither + <a class="Xr">ipf(4)</a> nor <a class="Xr">pf(4)</a> 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.</p> +<p class="Pp">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.</p> +<p class="Pp">IP or IPv6 forwarding is not necessary for MPLS forwarding. Your + system may still forward IP or IPv6 packets encapsulated into MPLS if + <code class="Li">net.mpls.forwarding</code> is set.</p> +</section> +</div> +<table class="foot"> + <tr> + <td class="foot-date">September 14, 2018</td> + <td class="foot-os">NetBSD 10.1</td> + </tr> +</table> |