1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
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>
|
