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
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
|
@node Zebra
@chapter Zebra
@c SYNOPSIS
@command{zebra} is an IP routing manager. It provides kernel routing
table updates, interface lookups, and redistribution of routes between
different routing protocols.
@menu
* Invoking zebra:: Running the program
* Interface Commands:: Commands for zebra interfaces
* Static Route Commands:: Commands for adding static routes
* Multicast RIB Commands:: Commands for controlling MRIB behavior
* zebra Route Filtering:: Commands for zebra route filtering
* zebra FIB push interface:: Interface to optional FPM component
* zebra Terminal Mode Commands:: Commands for zebra's VTY
@end menu
@node Invoking zebra
@section Invoking zebra
Besides the common invocation options (@pxref{Common Invocation Options}), the
@command{zebra} specific invocation options are listed below.
@table @samp
@item -b
@itemx --batch
Runs in batch mode. @command{zebra} parses configuration file and terminates
immediately.
@item -k
@itemx --keep_kernel
When zebra starts up, don't delete old self inserted routes.
@item -r
@itemx --retain
When program terminates, retain routes added by zebra.
@end table
@node Interface Commands
@section Interface Commands
@menu
* Standard Commands::
* Link Parameters Commands::
@end menu
@node Standard Commands
@subsection Standard Commands
@deffn Command {interface @var{ifname}} {}
@end deffn
@deffn {Interface Command} {shutdown} {}
@deffnx {Interface Command} {no shutdown} {}
Up or down the current interface.
@end deffn
@deffn {Interface Command} {ip address @var{address/prefix}} {}
@deffnx {Interface Command} {ipv6 address @var{address/prefix}} {}
@deffnx {Interface Command} {no ip address @var{address/prefix}} {}
@deffnx {Interface Command} {no ipv6 address @var{address/prefix}} {}
Set the IPv4 or IPv6 address/prefix for the interface.
@end deffn
@deffn {Interface Command} {ip address @var{address/prefix} secondary} {}
@deffnx {Interface Command} {no ip address @var{address/prefix} secondary} {}
Set the secondary flag for this address. This causes ospfd to not treat the
address as a distinct subnet.
@end deffn
@deffn {Interface Command} {description @var{description} ...} {}
Set description for the interface.
@end deffn
@deffn {Interface Command} {multicast} {}
@deffnx {Interface Command} {no multicast} {}
Enable or disables multicast flag for the interface.
@end deffn
@deffn {Interface Command} {bandwidth <1-10000000>} {}
@deffnx {Interface Command} {no bandwidth <1-10000000>} {}
Set bandwidth value of the interface in kilobits/sec. This is for
calculating OSPF cost. This command does not affect the actual device
configuration.
@end deffn
@deffn {Interface Command} {link-detect} {}
@deffnx {Interface Command} {no link-detect} {}
Enable/disable link-detect on platforms which support this. Currently
only Linux and Solaris, and only where network interface drivers support reporting
link-state via the IFF_RUNNING flag.
@end deffn
@node Link Parameters Commands
@subsection Link Parameters Commands
@deffn {Interface Command} {link-params} {}
@deffnx {Interface Command} {no link-param} {}
Enter into the link parameters sub node. At least 'enable' must be set to activate the link parameters,
and consequently Traffic Engineering on this interface. MPLS-TE must be enable at the OSPF (@ref{OSPF Traffic Engineering})
or ISIS (@ref{ISIS Traffic Engineering}) router level in complement to this.
Disable link parameters for this interface.
@end deffn
Under link parameter statement, the following commands set the different TE values:
@deffn link-params {enable}
Enable link parameters for this interface.
@end deffn
@deffn link-params {metric <0-4294967295>} {}
@deffnx link-params {max-bw @var{bandwidth}} {}
@deffnx link-params {max-rsv-bw @var{bandwidth}} {}
@deffnx link-params {unrsv-bw <0-7> @var{bandwidth}} {}
@deffnx link-params {admin-grp @var{bandwidth}} {}
These commands specifies the Traffic Engineering parameters of the interface in conformity to RFC3630 (OSPF)
or RFC5305 (ISIS).
There are respectively the TE Metric (different from the OSPF or ISIS metric), Maximum Bandwidth (interface speed
by default), Maximum Reservable Bandwidth, Unreserved Bandwidth for each 0-7 priority and Admin Group (ISIS) or
Resource Class/Color (OSPF).
Note that @var{bandwidth} are specified in IEEE floating point format and express in Bytes/second.
@end deffn
@deffn link-param {delay <0-16777215> [min <0-16777215> | max <0-16777215>]} {}
@deffnx link-param {delay-variation <0-16777215>} {}
@deffnx link-param {packet-loss @var{percentage}} {}
@deffnx link-param {res-bw @var{bandwidth}} {}
@deffnx link-param {ava-bw @var{bandwidth}} {}
@deffnx link-param {use-bw @var{bandwidth}} {}
These command specifies additionnal Traffic Engineering parameters of the interface in conformity to
draft-ietf-ospf-te-metrics-extension-05.txt and draft-ietf-isis-te-metrics-extension-03.txt. There are
respectively the delay, jitter, loss, available bandwidth, reservable bandwidth and utilized bandwidth.
Note that @var{bandwidth} are specified in IEEE floating point format and express in Bytes/second.
Delays and delay variation are express in micro-second (µs). Loss is specified in @var{percentage} ranging
from 0 to 50.331642% by step of 0.000003.
@end deffn
@deffn link-param {neighbor <A.B.C.D> as <0-65535>} {}
@deffnx link-param {no neighbor} {}
Specifies the remote ASBR IP address and Autonomous System (AS) number for InterASv2 link in OSPF (RFC5392).
Note that this option is not yet supported for ISIS (RFC5316).
@end deffn
@node Static Route Commands
@section Static Route Commands
Static routing is a very fundamental feature of routing technology. It
defines static prefix and gateway.
@deffn Command {ip route @var{network} @var{gateway}} {}
@var{network} is destination prefix with format of A.B.C.D/M.
@var{gateway} is gateway for the prefix. When @var{gateway} is
A.B.C.D format. It is taken as a IPv4 address gateway. Otherwise it
is treated as an interface name. If the interface name is @var{null0} then
zebra installs a blackhole route.
@example
ip route 10.0.0.0/8 10.0.0.2
ip route 10.0.0.0/8 ppp0
ip route 10.0.0.0/8 null0
@end example
First example defines 10.0.0.0/8 static route with gateway 10.0.0.2.
Second one defines the same prefix but with gateway to interface ppp0. The
third install a blackhole route.
@end deffn
@deffn Command {ip route @var{network} @var{netmask} @var{gateway}} {}
This is alternate version of above command. When @var{network} is
A.B.C.D format, user must define @var{netmask} value with A.B.C.D
format. @var{gateway} is same option as above command
@example
ip route 10.0.0.0 255.255.255.0 10.0.0.2
ip route 10.0.0.0 255.255.255.0 ppp0
ip route 10.0.0.0 255.255.255.0 null0
@end example
These statements are equivalent to those in the previous example.
@end deffn
@deffn Command {ip route @var{network} @var{gateway} @var{distance}} {}
Installs the route with the specified distance.
@end deffn
Multiple nexthop static route
@example
ip route 10.0.0.1/32 10.0.0.2
ip route 10.0.0.1/32 10.0.0.3
ip route 10.0.0.1/32 eth0
@end example
If there is no route to 10.0.0.2 and 10.0.0.3, and interface eth0
is reachable, then the last route is installed into the kernel.
If zebra has been compiled with multipath support, and both 10.0.0.2 and
10.0.0.3 are reachable, zebra will install a multipath route via both
nexthops, if the platform supports this.
@example
zebra> show ip route
S> 10.0.0.1/32 [1/0] via 10.0.0.2 inactive
via 10.0.0.3 inactive
* is directly connected, eth0
@end example
@example
ip route 10.0.0.0/8 10.0.0.2
ip route 10.0.0.0/8 10.0.0.3
ip route 10.0.0.0/8 null0 255
@end example
This will install a multihop route via the specified next-hops if they are
reachable, as well as a high-metric blackhole route, which can be useful to
prevent traffic destined for a prefix to match less-specific routes (eg
default) should the specified gateways not be reachable. Eg:
@example
zebra> show ip route 10.0.0.0/8
Routing entry for 10.0.0.0/8
Known via "static", distance 1, metric 0
10.0.0.2 inactive
10.0.0.3 inactive
Routing entry for 10.0.0.0/8
Known via "static", distance 255, metric 0
directly connected, Null0
@end example
@deffn Command {ipv6 route @var{network} @var{gateway}} {}
@deffnx Command {ipv6 route @var{network} @var{gateway} @var{distance}} {}
These behave similarly to their ipv4 counterparts.
@end deffn
@deffn Command {ipv6 route @var{network} from @var{srcprefix} @var{gateway}} {}
@deffnx Command {ipv6 route @var{network} from @var{srcprefix} @var{gateway} @var{distance}} {}
Install a static source-specific route. These routes are currently supported
on Linux operating systems only, and perform AND matching on packet's
destination and source addresses in the kernel's forwarding path. Note that
destination longest-prefix match is "more important" than source LPM, e.g.
@command{"2001:db8:1::/64 from 2001:db8::/48"} will win over
@command{"2001:db8::/48 from 2001:db8:1::/64"} if both match.
@end deffn
@deffn Command {table @var{tableno}} {}
Select the primary kernel routing table to be used. This only works
for kernels supporting multiple routing tables (like GNU/Linux 2.2.x
and later). After setting @var{tableno} with this command,
static routes defined after this are added to the specified table.
@end deffn
@node Multicast RIB Commands
@section Multicast RIB Commands
The Multicast RIB provides a separate table of unicast destinations which
is used for Multicast Reverse Path Forwarding decisions. It is used with
a multicast source's IP address, hence contains not multicast group
addresses but unicast addresses.
This table is fully separate from the default unicast table. However,
RPF lookup can include the unicast table.
WARNING: RPF lookup results are non-responsive in this version of Frr,
i.e. multicast routing does not actively react to changes in underlying
unicast topology!
@deffn Command {ip multicast rpf-lookup-mode @var{mode}} {}
@deffnx Command {no ip multicast rpf-lookup-mode [@var{mode}]} {}
@var{mode} sets the method used to perform RPF lookups. Supported modes:
@table @samp
@item urib-only
Performs the lookup on the Unicast RIB. The Multicast RIB is never used.
@item mrib-only
Performs the lookup on the Multicast RIB. The Unicast RIB is never used.
@item mrib-then-urib
Tries to perform the lookup on the Multicast RIB. If any route is found,
that route is used. Otherwise, the Unicast RIB is tried.
@item lower-distance
Performs a lookup on the Multicast RIB and Unicast RIB each. The result
with the lower administrative distance is used; if they're equal, the
Multicast RIB takes precedence.
@item longer-prefix
Performs a lookup on the Multicast RIB and Unicast RIB each. The result
with the longer prefix length is used; if they're equal, the
Multicast RIB takes precedence.
@end table
The @code{mrib-then-urib} setting is the default behavior if nothing is
configured. If this is the desired behavior, it should be explicitly
configured to make the configuration immune against possible changes in
what the default behavior is.
WARNING: Unreachable routes do not receive special treatment and do not
cause fallback to a second lookup.
@end deffn
@deffn Command {show ip rpf @var{addr}} {}
Performs a Multicast RPF lookup, as configured with
@command{ip multicast rpf-lookup-mode @var{mode}}. @var{addr} specifies
the multicast source address to look up.
@example
> show ip rpf 192.0.2.1
Routing entry for 192.0.2.0/24 using Unicast RIB
Known via "kernel", distance 0, metric 0, best
* 198.51.100.1, via eth0
@end example
Indicates that a multicast source lookup for 192.0.2.1 would use an
Unicast RIB entry for 192.0.2.0/24 with a gateway of 198.51.100.1.
@end deffn
@deffn Command {show ip rpf} {}
Prints the entire Multicast RIB. Note that this is independent of the
configured RPF lookup mode, the Multicast RIB may be printed yet not
used at all.
@end deffn
@deffn Command {ip mroute @var{prefix} @var{nexthop} [@var{distance}]} {}
@deffnx Command {no ip mroute @var{prefix} @var{nexthop} [@var{distance}]} {}
Adds a static route entry to the Multicast RIB. This performs exactly as
the @command{ip route} command, except that it inserts the route in the
Multicast RIB instead of the Unicast RIB.
@end deffn
@node zebra Route Filtering
@section zebra Route Filtering
Zebra supports @command{prefix-list} and @command{route-map} to match
routes received from other frr components. The
@command{permit}/@command{deny} facilities provided by these commands
can be used to filter which routes zebra will install in the kernel.
@deffn Command {ip protocol @var{protocol} route-map @var{routemap}} {}
Apply a route-map filter to routes for the specified protocol. @var{protocol}
can be @b{any} or one of
@b{system},
@b{kernel},
@b{connected},
@b{static},
@b{rip},
@b{ripng},
@b{ospf},
@b{ospf6},
@b{isis},
@b{bgp},
@b{hsls}.
@end deffn
@deffn {Route Map} {set src @var{address}}
Within a route-map, set the preferred source address for matching routes
when installing in the kernel.
@end deffn
@example
The following creates a prefix-list that matches all addresses, a route-map
that sets the preferred source address, and applies the route-map to all
@command{rip} routes.
@group
ip prefix-list ANY permit 0.0.0.0/0 le 32
route-map RM1 permit 10
match ip address prefix-list ANY
set src 10.0.0.1
ip protocol rip route-map RM1
@end group
@end example
@node zebra FIB push interface
@section zebra FIB push interface
Zebra supports a 'FIB push' interface that allows an external
component to learn the forwarding information computed by the Frr
routing suite.
In Frr, the Routing Information Base (RIB) resides inside
zebra. Routing protocols communicate their best routes to zebra, and
zebra computes the best route across protocols for each prefix. This
latter information makes up the Forwarding Information Base
(FIB). Zebra feeds the FIB to the kernel, which allows the IP stack in
the kernel to forward packets according to the routes computed by
Frr. The kernel FIB is updated in an OS-specific way. For example,
the @code{netlink} interface is used on Linux, and route sockets are
used on FreeBSD.
The FIB push interface aims to provide a cross-platform mechanism to
support scenarios where the router has a forwarding path that is
distinct from the kernel, commonly a hardware-based fast path. In
these cases, the FIB needs to be maintained reliably in the fast path
as well. We refer to the component that programs the forwarding plane
(directly or indirectly) as the Forwarding Plane Manager or FPM.
The FIB push interface comprises of a TCP connection between zebra and
the FPM. The connection is initiated by zebra -- that is, the FPM acts
as the TCP server.
The relevant zebra code kicks in when zebra is configured with the
@code{--enable-fpm} flag. Zebra periodically attempts to connect to
the well-known FPM port. Once the connection is up, zebra starts
sending messages containing routes over the socket to the FPM. Zebra
sends a complete copy of the forwarding table to the FPM, including
routes that it may have picked up from the kernel. The existing
interaction of zebra with the kernel remains unchanged -- that is, the
kernel continues to receive FIB updates as before.
The encapsulation header for the messages exchanged with the FPM is
defined by the file @file{fpm/fpm.h} in the frr tree. The routes
themselves are encoded in netlink or protobuf format, with netlink
being the default.
Protobuf is one of a number of new serialization formats wherein the
message schema is expressed in a purpose-built language. Code for
encoding/decoding to/from the wire format is generated from the
schema. Protobuf messages can be extended easily while maintaining
backward-compatibility with older code. Protobuf has the following
advantages over netlink:
@itemize
@item
Code for serialization/deserialization is generated
automatically. This reduces the likelihood of bugs, allows third-party
programs to be integrated quickly, and makes it easy to add fields.
@item
The message format is not tied to an OS (Linux), and can be evolved
independently.
@end itemize
As mentioned before, zebra encodes routes sent to the FPM in netlink
format by default. The format can be controlled via the
@code{--fpm_format} command-line option to zebra, which currently
takes the values @code{netlink} and @code{protobuf}.
The zebra FPM interface uses replace semantics. That is, if a 'route
add' message for a prefix is followed by another 'route add' message,
the information in the second message is complete by itself, and
replaces the information sent in the first message.
If the connection to the FPM goes down for some reason, zebra sends
the FPM a complete copy of the forwarding table(s) when it reconnects.
@node zebra Terminal Mode Commands
@section zebra Terminal Mode Commands
@deffn Command {show ip route} {}
Display current routes which zebra holds in its database.
@example
@group
Router# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
B - BGP * - FIB route.
K* 0.0.0.0/0 203.181.89.241
S 0.0.0.0/0 203.181.89.1
C* 127.0.0.0/8 lo
C* 203.181.89.240/28 eth0
@end group
@end example
@end deffn
@deffn Command {show ipv6 route} {}
@end deffn
@deffn Command {show interface} {}
@end deffn
@deffn Command {show ip prefix-list [@var{name}]} {}
@end deffn
@deffn Command {show route-map [@var{name}]} {}
@end deffn
@deffn Command {show ip protocol} {}
@end deffn
@deffn Command {show ipforward} {}
Display whether the host's IP forwarding function is enabled or not.
Almost any UNIX kernel can be configured with IP forwarding disabled.
If so, the box can't work as a router.
@end deffn
@deffn Command {show ipv6forward} {}
Display whether the host's IP v6 forwarding is enabled or not.
@end deffn
@deffn Command {show zebra fpm stats} {}
Display statistics related to the zebra code that interacts with the
optional Forwarding Plane Manager (FPM) component.
@end deffn
@deffn Command {clear zebra fpm stats} {}
Reset statistics related to the zebra code that interacts with the
optional Forwarding Plane Manager (FPM) component.
@end deffn
|