]>
Commit | Line | Data |
---|---|---|
0efdf0fe | 1 | .. _zebra: |
42fc5d26 QY |
2 | |
3 | ***** | |
4 | Zebra | |
5 | ***** | |
6 | ||
d1a242fd | 7 | *zebra* is an IP routing manager. It provides kernel routing |
42fc5d26 QY |
8 | table updates, interface lookups, and redistribution of routes between |
9 | different routing protocols. | |
10 | ||
0efdf0fe | 11 | .. _invoking-zebra: |
42fc5d26 QY |
12 | |
13 | Invoking zebra | |
14 | ============== | |
15 | ||
0efdf0fe | 16 | Besides the common invocation options (:ref:`common-invocation-options`), the |
42fc5d26 QY |
17 | *zebra* specific invocation options are listed below. |
18 | ||
d1a242fd | 19 | .. program:: zebra |
42fc5d26 | 20 | |
c9365894 | 21 | .. option:: -b, --batch |
42fc5d26 | 22 | |
d1a242fd QY |
23 | Runs in batch mode. *zebra* parses configuration file and terminates |
24 | immediately. | |
42fc5d26 | 25 | |
d4644d41 DS |
26 | .. option:: -K TIME, --graceful_restart TIME |
27 | ||
28 | If this option is specified, the graceful restart time is TIME seconds. | |
29 | Zebra, when started, will read in routes. Those routes that Zebra | |
30 | identifies that it was the originator of will be swept in TIME seconds. | |
31 | If no time is specified then we will sweep those routes immediately. | |
32 | ||
c9365894 | 33 | .. option:: -r, --retain |
42fc5d26 | 34 | |
da7e1a92 QY |
35 | When program terminates, do not flush routes installed by *zebra* from the |
36 | kernel. | |
42fc5d26 | 37 | |
0d8df934 DS |
38 | .. option:: -e X, --ecmp X |
39 | ||
40 | Run zebra with a limited ecmp ability compared to what it is compiled to. | |
41 | If you are running zebra on hardware limited functionality you can | |
42 | force zebra to limit the maximum ecmp allowed to X. This number | |
43 | is bounded by what you compiled FRR with as the maximum number. | |
44 | ||
204ed384 PG |
45 | .. option:: -n, --vrfwnetns |
46 | ||
47 | When *Zebra* starts with this option, the VRF backend is based on Linux | |
48 | network namespaces. That implies that all network namespaces discovered by | |
49 | ZEBRA will create an associated VRF. The other daemons will operate on the VRF | |
80ca5b6d | 50 | VRF defined by *Zebra*, as usual. |
204ed384 | 51 | |
f90115c5 | 52 | .. seealso:: :ref:`zebra-vrf` |
013f9762 | 53 | |
cc6743c2 PG |
54 | .. option:: -o, --vrfdefaultname |
55 | ||
56 | When *Zebra* starts with this option, the default VRF name is changed to the | |
57 | parameter. | |
58 | ||
59 | .. seealso:: :ref:`zebra-vrf` | |
60 | ||
6ed85950 DS |
61 | .. option:: -z <path_to_socket>, --socket <path_to_socket> |
62 | ||
63 | If this option is supplied on the cli, the path to the zebra | |
64 | control socket(zapi), is used. This option overrides a -N <namespace> | |
65 | option if handed to it on the cli. | |
66 | ||
4354d381 DS |
67 | .. option:: --v6-rr-semantics |
68 | ||
69 | The linux kernel is receiving the ability to use the same route | |
70 | replacement semantics for v6 that v4 uses. If you are using a | |
71 | kernel that supports this functionality then run *Zebra* with this | |
72 | option and we will use Route Replace Semantics instead of delete | |
73 | than add. | |
74 | ||
e4876266 DS |
75 | .. option:: --asic-offload [notify_on_offload|notify_on_ack] |
76 | ||
77 | The linux kernel has the ability to use asic-offload ( see switchdev | |
78 | development ). When the operator knows that FRR will be working in | |
79 | this way, allow them to specify this with FRR. At this point this | |
80 | code only supports asynchronous notification of the offload state. | |
81 | In other words the initial ACK received for linux kernel installation | |
82 | does not give zebra any data about what the state of the offload | |
83 | is. This option takes the optional paramegers notify_on_offload | |
84 | or notify_on_ack. This signals to zebra to notify upper level | |
85 | protocols about route installation/update on ack received from | |
86 | the linux kernel or from offload notification. | |
87 | ||
0efdf0fe | 88 | .. _interface-commands: |
42fc5d26 | 89 | |
4d25da4f PG |
90 | Configuration Addresses behaviour |
91 | ================================= | |
92 | ||
93 | At startup, *Zebra* will first discover the underlying networking objects | |
94 | from the operating system. This includes interfaces, addresses of | |
95 | interfaces, static routes, etc. Then, it will read the configuration | |
96 | file, including its own interface addresses, static routes, etc. All this | |
97 | information comprises the operational context from *Zebra*. But | |
98 | configuration context from *Zebra* will remain the same as the one from | |
99 | :file:`zebra.conf` config file. As an example, executing the following | |
100 | :clicmd:`show running-config` will reflect what was in :file:`zebra.conf`. | |
101 | In a similar way, networking objects that are configured outside of the | |
102 | *Zebra* like *iproute2* will not impact the configuration context from | |
103 | *Zebra*. This behaviour permits you to continue saving your own config | |
104 | file, and decide what is really to be pushed on the config file, and what | |
105 | is dependent on the underlying system. | |
106 | Note that inversely, from *Zebra*, you will not be able to delete networking | |
107 | objects that were previously configured outside of *Zebra*. | |
108 | ||
109 | ||
42fc5d26 QY |
110 | Interface Commands |
111 | ================== | |
112 | ||
0efdf0fe | 113 | .. _standard-commands: |
42fc5d26 QY |
114 | |
115 | Standard Commands | |
116 | ----------------- | |
117 | ||
d1a242fd QY |
118 | |
119 | .. clicmd:: interface IFNAME | |
120 | ||
204ed384 PG |
121 | |
122 | .. clicmd:: interface IFNAME vrf VRF | |
123 | ||
42fc5d26 | 124 | |
d1a242fd | 125 | .. clicmd:: shutdown |
42fc5d26 | 126 | |
42fc5d26 | 127 | |
d1a242fd | 128 | Up or down the current interface. |
42fc5d26 | 129 | |
42fc5d26 | 130 | |
d1a242fd | 131 | .. clicmd:: ip address ADDRESS/PREFIX |
42fc5d26 | 132 | |
d1a242fd | 133 | .. clicmd:: ipv6 address ADDRESS/PREFIX |
42fc5d26 | 134 | |
42fc5d26 | 135 | |
42fc5d26 | 136 | |
d1a242fd | 137 | Set the IPv4 or IPv6 address/prefix for the interface. |
42fc5d26 | 138 | |
42fc5d26 | 139 | |
d1a242fd | 140 | .. clicmd:: ip address LOCAL-ADDR peer PEER-ADDR/PREFIX |
42fc5d26 | 141 | |
42fc5d26 | 142 | |
d1e7591e QY |
143 | Configure an IPv4 Point-to-Point address on the interface. (The concept of |
144 | PtP addressing does not exist for IPv6.) | |
42fc5d26 | 145 | |
d1a242fd QY |
146 | `local-addr` has no subnet mask since the local side in PtP addressing is |
147 | always a single (/32) address. `peer-addr/prefix` can be an arbitrary subnet | |
148 | behind the other end of the link (or even on the link in Point-to-Multipoint | |
149 | setups), though generally /32s are used. | |
42fc5d26 | 150 | |
42fc5d26 | 151 | |
d1a242fd | 152 | .. clicmd:: description DESCRIPTION ... |
42fc5d26 | 153 | |
d1a242fd | 154 | Set description for the interface. |
42fc5d26 | 155 | |
42fc5d26 | 156 | |
d1a242fd | 157 | .. clicmd:: multicast |
42fc5d26 | 158 | |
42fc5d26 | 159 | |
d1a242fd | 160 | Enable or disables multicast flag for the interface. |
42fc5d26 | 161 | |
42fc5d26 | 162 | |
d1a242fd | 163 | .. clicmd:: bandwidth (1-10000000) |
d1a242fd | 164 | |
d1a242fd QY |
165 | |
166 | Set bandwidth value of the interface in kilobits/sec. This is for | |
167 | calculating OSPF cost. This command does not affect the actual device | |
168 | configuration. | |
169 | ||
d1a242fd QY |
170 | |
171 | .. clicmd:: link-detect | |
d1a242fd | 172 | |
d1a242fd QY |
173 | |
174 | Enable/disable link-detect on platforms which support this. Currently only | |
32d9e333 DS |
175 | Linux, and only where network interface drivers support reporting |
176 | link-state via the ``IFF_RUNNING`` flag. | |
4c97fd1a | 177 | |
30980e0a | 178 | In FRR, link-detect is on by default. |
42fc5d26 | 179 | |
0efdf0fe | 180 | .. _link-parameters-commands: |
42fc5d26 QY |
181 | |
182 | Link Parameters Commands | |
183 | ------------------------ | |
184 | ||
85400b29 MS |
185 | .. note:: |
186 | ||
187 | At this time, FRR offers partial support for some of the routing | |
188 | protocol extensions that can be used with MPLS-TE. FRR does not | |
189 | support a complete RSVP-TE solution currently. | |
190 | ||
d1a242fd | 191 | .. clicmd:: link-params |
42fc5d26 | 192 | |
42fc5d26 | 193 | |
85400b29 MS |
194 | Enter into the link parameters sub node. At least 'enable' must be |
195 | set to activate the link parameters, and consequently routing | |
196 | information that could be used as part of Traffic Engineering on | |
197 | this interface. MPLS-TE must be enable at the OSPF | |
198 | (:ref:`ospf-traffic-engineering`) or ISIS | |
199 | (:ref:`isis-traffic-engineering`) router level in complement to | |
200 | this. Disable link parameters for this interface. | |
42fc5d26 | 201 | |
d1a242fd | 202 | Under link parameter statement, the following commands set the different TE values: |
42fc5d26 | 203 | |
d1a242fd | 204 | .. clicmd:: link-params [enable] |
42fc5d26 | 205 | |
d1a242fd | 206 | Enable link parameters for this interface. |
42fc5d26 | 207 | |
d1a242fd | 208 | .. clicmd:: link-params [metric (0-4294967295)] |
42fc5d26 | 209 | |
d1a242fd | 210 | .. clicmd:: link-params max-bw BANDWIDTH |
42fc5d26 | 211 | |
d1a242fd | 212 | .. clicmd:: link-params max-rsv-bw BANDWIDTH |
42fc5d26 | 213 | |
d1a242fd | 214 | .. clicmd:: link-params unrsv-bw (0-7) BANDWIDTH |
42fc5d26 | 215 | |
d1a242fd | 216 | .. clicmd:: link-params admin-grp BANDWIDTH |
42fc5d26 | 217 | |
d1a242fd QY |
218 | These commands specifies the Traffic Engineering parameters of the interface |
219 | in conformity to RFC3630 (OSPF) or RFC5305 (ISIS). There are respectively | |
220 | the TE Metric (different from the OSPF or ISIS metric), Maximum Bandwidth | |
221 | (interface speed by default), Maximum Reservable Bandwidth, Unreserved | |
222 | Bandwidth for each 0-7 priority and Admin Group (ISIS) or Resource | |
223 | Class/Color (OSPF). | |
42fc5d26 | 224 | |
d1a242fd QY |
225 | Note that BANDIWDTH is specified in IEEE floating point format and express |
226 | in Bytes/second. | |
42fc5d26 | 227 | |
d1a242fd | 228 | .. clicmd:: link-param delay (0-16777215) [min (0-16777215) | max (0-16777215)] |
42fc5d26 | 229 | |
d1a242fd | 230 | .. clicmd:: link-param delay-variation (0-16777215) |
42fc5d26 | 231 | |
d1a242fd | 232 | .. clicmd:: link-param packet-loss PERCENTAGE |
42fc5d26 | 233 | |
d1a242fd | 234 | .. clicmd:: link-param res-bw BANDWIDTH |
42fc5d26 | 235 | |
d1a242fd | 236 | .. clicmd:: link-param ava-bw BANDWIDTH |
42fc5d26 | 237 | |
d1a242fd | 238 | .. clicmd:: link-param use-bw BANDWIDTH |
42fc5d26 | 239 | |
d1e7591e | 240 | These command specifies additional Traffic Engineering parameters of the |
d1a242fd QY |
241 | interface in conformity to draft-ietf-ospf-te-metrics-extension-05.txt and |
242 | draft-ietf-isis-te-metrics-extension-03.txt. There are respectively the | |
243 | delay, jitter, loss, available bandwidth, reservable bandwidth and utilized | |
244 | bandwidth. | |
42fc5d26 | 245 | |
d1a242fd QY |
246 | Note that BANDWIDTH is specified in IEEE floating point format and express |
247 | in Bytes/second. Delays and delay variation are express in micro-second | |
248 | (µs). Loss is specified in PERCENTAGE ranging from 0 to 50.331642% by step | |
249 | of 0.000003. | |
42fc5d26 | 250 | |
d1a242fd | 251 | .. clicmd:: link-param neighbor <A.B.C.D> as (0-65535) |
42fc5d26 | 252 | |
d1a242fd | 253 | .. clicmd:: link-param no neighbor |
42fc5d26 | 254 | |
d1a242fd QY |
255 | Specifies the remote ASBR IP address and Autonomous System (AS) number |
256 | for InterASv2 link in OSPF (RFC5392). Note that this option is not yet | |
257 | supported for ISIS (RFC5316). | |
42fc5d26 | 258 | |
43b8e264 QY |
259 | .. clicmd:: ip nht resolve-via-default |
260 | ||
261 | Allows nexthop tracking to resolve via the default route. This is useful | |
262 | when e.g. you want to allow BGP to peer across the default route. | |
263 | ||
f90115c5 | 264 | .. _zebra-vrf: |
80ca5b6d | 265 | |
9187f11a DS |
266 | Administrative Distance |
267 | ======================= | |
268 | ||
269 | Administrative distance allows FRR to make decisions about what routes | |
270 | should be installed in the rib based upon the originating protocol. | |
271 | The lowest Admin Distance is the route selected. This is purely a | |
272 | subjective decision about ordering and care has been taken to choose | |
273 | the same distances that other routing suites have choosen. | |
274 | ||
275 | +------------+-----------+ | |
276 | | Protocol | Distance | | |
277 | +------------+-----------+ | |
278 | | System | 0 | | |
279 | +------------+-----------+ | |
280 | | Kernel | 0 | | |
281 | +------------+-----------+ | |
282 | | Connect | 0 | | |
283 | +------------+-----------+ | |
284 | | Static | 1 | | |
285 | +------------+-----------+ | |
286 | | NHRP | 10 | | |
287 | +------------+-----------+ | |
288 | | EBGP | 20 | | |
289 | +------------+-----------+ | |
290 | | EIGRP | 90 | | |
291 | +------------+-----------+ | |
292 | | BABEL | 100 | | |
293 | +------------+-----------+ | |
294 | | OSPF | 110 | | |
295 | +------------+-----------+ | |
296 | | ISIS | 115 | | |
297 | +------------+-----------+ | |
298 | | OPENFABRIC | 115 | | |
299 | +------------+-----------+ | |
300 | | RIP | 120 | | |
301 | +------------+-----------+ | |
302 | | Table | 150 | | |
303 | +------------+-----------+ | |
304 | | SHARP | 150 | | |
305 | +------------+-----------+ | |
306 | | IBGP | 200 | | |
307 | +------------+-----------+ | |
308 | | PBR | 200 | | |
309 | +------------+-----------+ | |
310 | ||
311 | An admin distance of 255 indicates to Zebra that the route should not be | |
312 | installed into the Data Plane. Additionally routes with an admin distance | |
313 | of 255 will not be redistributed. | |
314 | ||
315 | Zebra does treat Kernel routes as special case for the purposes of Admin | |
316 | Distance. Upon learning about a route that is not originated by FRR | |
317 | we read the metric value as a uint32_t. The top byte of the value | |
318 | is interpreted as the Administrative Distance and the low three bytes | |
319 | are read in as the metric. This special case is to facilitate VRF | |
320 | default routes. | |
321 | ||
ba5e7ae2 DS |
322 | Route Replace Semantics |
323 | ======================= | |
324 | ||
325 | When using the Linux Kernel as a forwarding plane, routes are installed | |
326 | with a metric of 20 to the kernel. Please note that the kernel's metric | |
327 | value bears no resemblence to FRR's RIB metric or admin distance. It | |
328 | merely is a way for the Linux Kernel to decide which route to use if it | |
329 | has multiple routes for the same prefix from multiple sources. An example | |
330 | here would be if someone else was running another routing suite besides | |
331 | FRR at the same time, the kernel must choose what route to use to forward | |
332 | on. FRR choose the value of 20 because of two reasons. FRR wanted a | |
333 | value small enough to be choosen but large enough that the operator could | |
334 | allow route prioritization by the kernel when multiple routing suites are | |
335 | being run and FRR wanted to take advantage of Route Replace semantics that | |
336 | the linux kernel offers. In order for Route Replacement semantics to | |
337 | work FRR must use the same metric when issuing the replace command. | |
338 | Currently FRR only supports Route Replace semantics using the Linux | |
339 | Kernel. | |
340 | ||
80ca5b6d QY |
341 | Virtual Routing and Forwarding |
342 | ============================== | |
42fc5d26 | 343 | |
80ca5b6d QY |
344 | FRR supports :abbr:`VRF (Virtual Routing and Forwarding)`. VRF is a way to |
345 | separate networking contexts on the same machine. Those networking contexts are | |
346 | associated with separate interfaces, thus making it possible to associate one | |
347 | interface with a specific VRF. | |
204ed384 | 348 | |
204ed384 | 349 | VRF can be used, for example, when instantiating per enterprise networking |
80ca5b6d QY |
350 | services, without having to instantiate the physical host machine or the |
351 | routing management daemons for each enterprise. As a result, interfaces are | |
352 | separate for each set of VRF, and routing daemons can have their own context | |
353 | for each VRF. | |
204ed384 PG |
354 | |
355 | This conceptual view introduces the *Default VRF* case. If the user does not | |
80ca5b6d QY |
356 | configure any specific VRF, then by default, FRR uses the *Default VRF*. |
357 | ||
204ed384 | 358 | Configuring VRF networking contexts can be done in various ways on FRR. The VRF |
80ca5b6d | 359 | interfaces can be configured by entering in interface configuration mode |
614aa5c1 | 360 | :clicmd:`interface IFNAME vrf VRF`. |
204ed384 PG |
361 | |
362 | A VRF backend mode is chosen when running *Zebra*. | |
363 | ||
364 | If no option is chosen, then the *Linux VRF* implementation as references in | |
80ca5b6d | 365 | https://www.kernel.org/doc/Documentation/networking/vrf.txt will be mapped over |
204ed384 PG |
366 | the *Zebra* VRF. The routing table associated to that VRF is a Linux table |
367 | identifier located in the same *Linux network namespace* where *Zebra* started. | |
eff8e8a2 DS |
368 | Please note when using the *Linux VRF* routing table it is expected that a |
369 | default Kernel route will be installed that has a metric as outlined in the | |
370 | www.kernel.org doc above. The Linux Kernel does table lookup via a combination | |
371 | of rule application of the rule table and then route lookup of the specified | |
372 | table. If no route match is found then the next applicable rule is applied | |
373 | to find the next route table to use to look for a route match. As such if | |
374 | your VRF table does not have a default blackhole route with a high metric | |
375 | VRF route lookup will leave the table specified by the VRF, which is undesirable. | |
204ed384 | 376 | |
80ca5b6d QY |
377 | If the :option:`-n` option is chosen, then the *Linux network namespace* will |
378 | be mapped over the *Zebra* VRF. That implies that *Zebra* is able to configure | |
379 | several *Linux network namespaces*. The routing table associated to that VRF | |
380 | is the whole routing tables located in that namespace. For instance, this mode | |
381 | matches OpenStack Network Namespaces. It matches also OpenFastPath. The default | |
382 | behavior remains Linux VRF which is supported by the Linux kernel community, | |
383 | see https://www.kernel.org/doc/Documentation/networking/vrf.txt. | |
204ed384 PG |
384 | |
385 | Because of that difference, there are some subtle differences when running some | |
386 | commands in relationship to VRF. Here is an extract of some of those commands: | |
387 | ||
204ed384 PG |
388 | .. clicmd:: vrf VRF |
389 | ||
390 | This command is available on configuration mode. By default, above command | |
52119114 | 391 | permits accessing the VRF configuration mode. This mode is available for |
d66a93dd PG |
392 | both VRFs. It is to be noted that *Zebra* does not create Linux VRF. |
393 | The network administrator can however decide to provision this command in | |
394 | configuration file to provide more clarity about the intended configuration. | |
204ed384 | 395 | |
204ed384 PG |
396 | .. clicmd:: netns NAMESPACE |
397 | ||
80ca5b6d QY |
398 | This command is based on VRF configuration mode. This command is available |
399 | when *Zebra* is run in :option:`-n` mode. This command reflects which *Linux | |
400 | network namespace* is to be mapped with *Zebra* VRF. It is to be noted that | |
401 | *Zebra* creates and detects added/suppressed VRFs from the Linux environment | |
d66a93dd PG |
402 | (in fact, those managed with iproute2). The network administrator can however |
403 | decide to provision this command in configuration file to provide more clarity | |
404 | about the intended configuration. | |
204ed384 | 405 | |
204ed384 PG |
406 | .. clicmd:: show ip route vrf VRF |
407 | ||
408 | The show command permits dumping the routing table associated to the VRF. If | |
80ca5b6d QY |
409 | *Zebra* is launched with default settings, this will be the ``TABLENO`` of |
410 | the VRF configured on the kernel, thanks to information provided in | |
411 | https://www.kernel.org/doc/Documentation/networking/vrf.txt. If *Zebra* is | |
412 | launched with :option:`-n` option, this will be the default routing table of | |
413 | the *Linux network namespace* ``VRF``. | |
204ed384 | 414 | |
204ed384 PG |
415 | .. clicmd:: show ip route vrf VRF table TABLENO |
416 | ||
80ca5b6d QY |
417 | The show command is only available with :option:`-n` option. This command |
418 | will dump the routing table ``TABLENO`` of the *Linux network namespace* | |
419 | ``VRF``. | |
420 | ||
5a81528c PG |
421 | .. clicmd:: show ip route vrf VRF tables |
422 | ||
423 | This command will dump the routing tables within the vrf scope. If `vrf all` | |
424 | is executed, all routing tables will be dumped. | |
425 | ||
a3fd74f7 DS |
426 | .. clicmd:: show <ip|ipv6> route summary [vrf VRF] [table TABLENO] [prefix] |
427 | ||
428 | This command will dump a summary output of the specified VRF and TABLENO | |
429 | combination. If neither VRF or TABLENO is specified FRR defaults to | |
430 | the default vrf and default table. If prefix is specified dump the | |
431 | number of prefix routes. | |
432 | ||
c94e6725 PG |
433 | By using the :option:`-n` option, the *Linux network namespace* will be mapped |
434 | over the *Zebra* VRF. One nice feature that is possible by handling *Linux | |
435 | network namespace* is the ability to name default VRF. At startup, *Zebra* | |
436 | discovers the available *Linux network namespace* by parsing folder | |
437 | `/var/run/netns`. Each file stands for a *Linux network namespace*, but not all | |
438 | *Linux network namespaces* are available under that folder. This is the case for | |
439 | default VRF. It is possible to name the default VRF, by creating a file, by | |
440 | executing following commands. | |
441 | ||
442 | .. code-block:: shell | |
443 | ||
444 | touch /var/run/netns/vrf0 | |
445 | mount --bind /proc/self/ns/net /var/run/netns/vrf0 | |
446 | ||
447 | Above command illustrates what happens when the default VRF is visible under | |
448 | `var/run/netns/`. Here, the default VRF file is `vrf0`. | |
449 | At startup, FRR detects the presence of that file. It detects that the file | |
450 | statistics information matches the same file statistics information as | |
451 | `/proc/self/ns/net` ( through stat() function). As statistics information | |
452 | matches, then `vrf0` stands for the new default namespace name. | |
56f0bea7 | 453 | Consequently, the VRF naming `Default` will be overridden by the new discovered |
c94e6725 PG |
454 | namespace name `vrf0`. |
455 | ||
456 | For those who don't use VRF backend with *Linux network namespace*, it is | |
457 | possible to statically configure and recompile FRR. It is possible to choose an | |
458 | alternate name for default VRF. Then, the default VRF naming will automatically | |
459 | be updated with the new name. To illustrate, if you want to recompile with | |
460 | `global` value, use the following command: | |
461 | ||
cc4345d4 | 462 | .. code-block:: shell |
c94e6725 PG |
463 | |
464 | ./configure --with-defaultvrfname=global | |
465 | ||
df55b448 DS |
466 | .. _zebra-ecmp: |
467 | ||
468 | ECMP | |
469 | ==== | |
470 | ||
471 | FRR supports ECMP as part of normal operations and is generally compiled | |
472 | with a limit of 64 way ECMP. This of course can be modified via configure | |
473 | options on compilation if the end operator desires to do so. Individual | |
474 | protocols each have their own way of dictating ECMP policy and their | |
475 | respective documentation should be read. | |
476 | ||
477 | ECMP can be inspected in zebra by doing a `show ip route X` command. | |
478 | ||
479 | .. code-block:: shell | |
480 | ||
481 | eva# show ip route 4.4.4.4/32 | |
482 | Codes: K - kernel route, C - connected, S - static, R - RIP, | |
483 | O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, | |
484 | T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, | |
485 | F - PBR, f - OpenFabric, | |
486 | > - selected route, * - FIB route, q - queued, r - rejected, b - backup | |
487 | t - trapped, o - offload failure | |
488 | ||
489 | D>* 4.4.4.4/32 [150/0] via 192.168.161.1, enp39s0, weight 1, 00:00:02 | |
490 | * via 192.168.161.2, enp39s0, weight 1, 00:00:02 | |
491 | * via 192.168.161.3, enp39s0, weight 1, 00:00:02 | |
492 | * via 192.168.161.4, enp39s0, weight 1, 00:00:02 | |
493 | * via 192.168.161.5, enp39s0, weight 1, 00:00:02 | |
494 | * via 192.168.161.6, enp39s0, weight 1, 00:00:02 | |
495 | * via 192.168.161.7, enp39s0, weight 1, 00:00:02 | |
496 | * via 192.168.161.8, enp39s0, weight 1, 00:00:02 | |
497 | * via 192.168.161.9, enp39s0, weight 1, 00:00:02 | |
498 | * via 192.168.161.10, enp39s0, weight 1, 00:00:02 | |
499 | * via 192.168.161.11, enp39s0, weight 1, 00:00:02 | |
500 | * via 192.168.161.12, enp39s0, weight 1, 00:00:02 | |
501 | * via 192.168.161.13, enp39s0, weight 1, 00:00:02 | |
502 | * via 192.168.161.14, enp39s0, weight 1, 00:00:02 | |
503 | * via 192.168.161.15, enp39s0, weight 1, 00:00:02 | |
504 | * via 192.168.161.16, enp39s0, weight 1, 00:00:02 | |
505 | ||
506 | In this example we have 16 way ecmp for the 4.4.4.4/32 route. The `*` character | |
507 | tells us that the route is installed in the Data Plane, or FIB. | |
508 | ||
509 | If you are using the Linux kernel as a Data Plane, this can be inspected | |
510 | via a `ip route show X` command: | |
511 | ||
512 | .. code-block:: shell | |
513 | ||
514 | sharpd@eva ~/f/doc(ecmp_doc_change)> ip route show 4.4.4.4/32 | |
515 | 4.4.4.4 nhid 185483868 proto sharp metric 20 | |
516 | nexthop via 192.168.161.1 dev enp39s0 weight 1 | |
517 | nexthop via 192.168.161.10 dev enp39s0 weight 1 | |
518 | nexthop via 192.168.161.11 dev enp39s0 weight 1 | |
519 | nexthop via 192.168.161.12 dev enp39s0 weight 1 | |
520 | nexthop via 192.168.161.13 dev enp39s0 weight 1 | |
521 | nexthop via 192.168.161.14 dev enp39s0 weight 1 | |
522 | nexthop via 192.168.161.15 dev enp39s0 weight 1 | |
523 | nexthop via 192.168.161.16 dev enp39s0 weight 1 | |
524 | nexthop via 192.168.161.2 dev enp39s0 weight 1 | |
525 | nexthop via 192.168.161.3 dev enp39s0 weight 1 | |
526 | nexthop via 192.168.161.4 dev enp39s0 weight 1 | |
527 | nexthop via 192.168.161.5 dev enp39s0 weight 1 | |
528 | nexthop via 192.168.161.6 dev enp39s0 weight 1 | |
529 | nexthop via 192.168.161.7 dev enp39s0 weight 1 | |
530 | nexthop via 192.168.161.8 dev enp39s0 weight 1 | |
531 | nexthop via 192.168.161.9 dev enp39s0 weight 1 | |
532 | ||
533 | Once installed into the FIB, FRR currently has little control over what | |
534 | nexthops are choosen to forward packets on. Currently the Linux kernel | |
535 | has a `fib_multipath_hash_policy` sysctl which dictates how the hashing | |
536 | algorithm is used to forward packets. | |
537 | ||
b03d3432 PG |
538 | .. _zebra-mpls: |
539 | ||
540 | MPLS Commands | |
541 | ============= | |
542 | ||
543 | You can configure static mpls entries in zebra. Basically, handling MPLS | |
544 | consists of popping, swapping or pushing labels to IP packets. | |
545 | ||
546 | MPLS Acronyms | |
547 | ------------- | |
548 | ||
549 | :abbr:`LSR (Labeled Switch Router)` | |
550 | Networking devices handling labels used to forward traffic between and through | |
551 | them. | |
552 | ||
553 | :abbr:`LER (Labeled Edge Router)` | |
554 | A Labeled edge router is located at the edge of an MPLS network, generally | |
555 | between an IP network and an MPLS network. | |
556 | ||
557 | MPLS Push Action | |
558 | ---------------- | |
559 | ||
560 | The push action is generally used for LER devices, which want to encapsulate | |
561 | all traffic for a wished destination into an MPLS label. This action is stored | |
562 | in routing entry, and can be configured like a route: | |
563 | ||
03750f1e | 564 | .. clicmd:: ip route NETWORK MASK GATEWAY|INTERFACE label LABEL |
b03d3432 | 565 | |
56f0bea7 | 566 | NETWORK and MASK stand for the IP prefix entry to be added as static |
b03d3432 PG |
567 | route entry. |
568 | GATEWAY is the gateway IP address to reach, in order to reach the prefix. | |
569 | INTERFACE is the interface behind which the prefix is located. | |
570 | LABEL is the MPLS label to use to reach the prefix abovementioned. | |
571 | ||
572 | You can check that the static entry is stored in the zebra RIB database, by | |
573 | looking at the presence of the entry. | |
574 | ||
575 | :: | |
576 | ||
577 | zebra(configure)# ip route 1.1.1.1/32 10.0.1.1 label 777 | |
578 | zebra# show ip route | |
579 | Codes: K - kernel route, C - connected, S - static, R - RIP, | |
580 | O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, | |
581 | T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, | |
582 | F - PBR, | |
583 | > - selected route, * - FIB route | |
584 | ||
585 | S>* 1.1.1.1/32 [1/0] via 10.0.1.1, r2-eth0, label 777, 00:39:42 | |
586 | ||
587 | MPLS Swap and Pop Action | |
588 | ------------------------ | |
589 | ||
590 | The swap action is generally used for LSR devices, which swap a packet with a | |
591 | label, with an other label. The Pop action is used on LER devices, at the | |
592 | termination of the MPLS traffic; this is used to remove MPLS header. | |
593 | ||
03750f1e | 594 | .. clicmd:: mpls lsp INCOMING_LABEL GATEWAY OUTGOING_LABEL|explicit-null|implicit-null |
b03d3432 PG |
595 | |
596 | INCOMING_LABEL and OUTGOING_LABEL are MPLS labels with values ranging from 16 | |
597 | to 1048575. | |
598 | GATEWAY is the gateway IP address where to send MPLS packet. | |
599 | The outgoing label can either be a value or have an explicit-null label header. This | |
600 | specific header can be read by IP devices. The incoming label can also be removed; in | |
601 | that case the implicit-null keyword is used, and the outgoing packet emitted is an IP | |
602 | packet without MPLS header. | |
603 | ||
604 | You can check that the MPLS actions are stored in the zebra MPLS table, by looking at the | |
605 | presence of the entry. | |
606 | ||
b03d3432 PG |
607 | .. clicmd:: show mpls table |
608 | ||
609 | :: | |
610 | ||
611 | zebra(configure)# mpls lsp 18 10.125.0.2 implicit-null | |
612 | zebra(configure)# mpls lsp 19 10.125.0.2 20 | |
613 | zebra(configure)# mpls lsp 21 10.125.0.2 explicit-null | |
614 | zebra# show mpls table | |
615 | Inbound Outbound | |
616 | Label Type Nexthop Label | |
617 | -------- ------- --------------- -------- | |
618 | 18 Static 10.125.0.2 implicit-null | |
619 | 19 Static 10.125.0.2 20 | |
620 | 21 Static 10.125.0.2 IPv4 Explicit Null | |
621 | ||
622 | ||
4c6f9934 HS |
623 | .. _zebra-srv6: |
624 | ||
4ccd4033 | 625 | Segment-Routing IPv6 |
4c6f9934 HS |
626 | ==================== |
627 | ||
628 | Segment-Routing is source routing paradigm that allows | |
629 | network operator to encode network intent into the packets. | |
630 | SRv6 is an implementation of Segment-Routing | |
631 | with application of IPv6 and segment-routing-header. | |
632 | ||
633 | All routing daemon can use the Segment-Routing base | |
634 | framework implemented on zebra to use SRv6 routing mechanism. | |
635 | In that case, user must configure initial srv6 setting on | |
636 | FRR's cli or frr.conf or zebra.conf. This section shows how | |
637 | to configure SRv6 on FRR. Of course SRv6 can be used as standalone, | |
638 | and this section also helps that case. | |
639 | ||
640 | .. index:: show segment-routing srv6 locator [json] | |
641 | .. clicmd:: show segment-routing srv6 locator [json] | |
642 | ||
4ccd4033 HS |
643 | This command dump SRv6-locator configured on zebra. SRv6-locator is used |
644 | to route to the node before performing the SRv6-function. and that works as | |
645 | aggregation of SRv6-function's IDs. Following console log shows two | |
646 | SRv6-locators loc1 and loc2. All locators are identified by unique IPv6 | |
647 | prefix. User can get that information as JSON string when ``json`` key word | |
648 | at the end of cli is presented. | |
4c6f9934 HS |
649 | |
650 | :: | |
651 | ||
652 | router# sh segment-routing srv6 locator | |
653 | Locator: | |
654 | Name ID Prefix Status | |
655 | -------------------- ------- ------------------------ ------- | |
4ccd4033 HS |
656 | loc1 1 2001:db8:1:1::/64 Up |
657 | loc2 2 2001:db8:2:2::/64 Up | |
658 | ||
659 | .. index:: show segment-routing srv6 locator NAME detail [json] | |
660 | .. clicmd:: show segment-routing srv6 locator NAME detail [json] | |
661 | ||
662 | As shown in the example, by specifying the name of the locator, you | |
663 | can see the detailed information for each locator. Locator can be | |
664 | represented by a single IPv6 prefix, but SRv6 is designed to share this | |
665 | Locator among multiple Routing Protocols. For this purpose, zebra divides | |
666 | the IPv6 prefix block that makes the Locator unique into multiple chunks, | |
667 | and manages the ownership of each chunk. | |
668 | ||
669 | For example, loc1 has system as its owner. For example, loc1 is owned by | |
670 | system, which means that it is not yet proprietary to any routing protocol. | |
671 | For example, loc2 has sharp as its owner. This means that the shaprd for | |
672 | function development holds the owner of the chunk of this locator, and no | |
673 | other routing protocol will use this area. | |
674 | ||
675 | :: | |
676 | ||
677 | router# show segment-routing srv6 locator loc1 detail | |
678 | Name: loc1 | |
679 | Prefix: 2001:db8:1:1::/64 | |
680 | Chunks: | |
681 | - prefix: 2001:db8:1:1::/64, owner: system | |
682 | ||
683 | router# show segment-routing srv6 locator loc2 detail | |
684 | Name: loc2 | |
685 | Prefix: 2001:db8:2:2::/64 | |
686 | Chunks: | |
687 | - prefix: 2001:db8:2:2::/64, owner: sharp | |
4c6f9934 HS |
688 | |
689 | .. index:: segment-routing | |
690 | .. clicmd:: segment-routing | |
4ccd4033 HS |
691 | |
692 | Move from configure mode to segment-routing node. | |
693 | ||
4c6f9934 HS |
694 | .. index:: srv6 |
695 | .. clicmd:: srv6 | |
4ccd4033 HS |
696 | |
697 | Move from segment-routing node to srv6 node. | |
698 | ||
4c6f9934 HS |
699 | .. index:: locators |
700 | .. clicmd:: locators | |
701 | ||
4ccd4033 HS |
702 | Move from srv6 node to locator node. In this locator node, user can |
703 | configure detailed settings such as the actual srv6 locator. | |
4c6f9934 HS |
704 | |
705 | .. index:: locator NAME | |
706 | .. clicmd:: locator NAME | |
4c6f9934 | 707 | |
4ccd4033 HS |
708 | Create a new locator. If the name of an existing locator is specified, |
709 | move to specified locator's configuration node to change the settings it. | |
4c6f9934 | 710 | |
4ccd4033 HS |
711 | .. index:: prefix X:X::X:X/M [function-bits-length 32] |
712 | .. clicmd:: prefix X:X::X:X/M [function-bits-length 32] | |
4c6f9934 | 713 | |
4ccd4033 HS |
714 | Set the ipv6 prefix block of the locator. SRv6 locator is defined by |
715 | RFC8986. The actual routing protocol specifies the locator and allocates a | |
716 | SID to be used by each routing protocol. This SID is included in the locator | |
717 | as an IPv6 prefix. | |
718 | ||
719 | Following example console log shows the typical configuration of SRv6 | |
720 | data-plane. After a new SRv6 locator, named loc1, is created, loc1's prefix | |
721 | is configured as ``2001:db8:1:1::/64``. If user or some routing daemon | |
722 | allocates new SID on this locator, new SID will allocated in range of this | |
723 | prefix. For example, if some routing daemon creates new SID on locator | |
724 | (``2001:db8:1:1::/64``), Then new SID will be ``2001:db8:1:1:7::/80``, | |
725 | ``2001:db8:1:1:8::/80``, and so on. Each locator has default SID that is | |
726 | SRv6 local function "End". Usually default SID is allocated as | |
727 | ``PREFIX:1::``. (``PREFIX`` is locator's prefix) For example, if user | |
728 | configure the locator's prefix as ``2001:db8:1:1::/64``, then default SID | |
729 | will be ``2001:db8:1:1:1::``) | |
730 | ||
731 | The function bits range is 16bits by default. If operator want to change | |
732 | function bits range, they can configure with ``function-bits-length`` | |
733 | option. | |
4c6f9934 HS |
734 | |
735 | :: | |
736 | ||
737 | router# configure terminal | |
738 | router(config)# segment-routinig | |
739 | router(config-sr)# srv6 | |
740 | router(config-srv6)# locators | |
4ccd4033 HS |
741 | router(config-srv6-locs)# locator loc1 |
742 | router(config-srv6-loc)# prefix 2001:db8:1:1::/64 | |
4c6f9934 HS |
743 | |
744 | router(config-srv6-loc)# show run | |
745 | ... | |
746 | segment-routing | |
747 | srv6 | |
748 | locators | |
4ccd4033 HS |
749 | locator loc1 |
750 | prefix 2001:db8:1:1::/64 | |
4c6f9934 HS |
751 | ! |
752 | ... | |
753 | ||
80ca5b6d QY |
754 | .. _multicast-rib-commands: |
755 | ||
42fc5d26 QY |
756 | Multicast RIB Commands |
757 | ====================== | |
758 | ||
759 | The Multicast RIB provides a separate table of unicast destinations which | |
d1a242fd | 760 | is used for Multicast Reverse Path Forwarding decisions. It is used with |
42fc5d26 QY |
761 | a multicast source's IP address, hence contains not multicast group |
762 | addresses but unicast addresses. | |
763 | ||
d1a242fd | 764 | This table is fully separate from the default unicast table. However, |
42fc5d26 QY |
765 | RPF lookup can include the unicast table. |
766 | ||
dc1046f7 | 767 | WARNING: RPF lookup results are non-responsive in this version of FRR, |
42fc5d26 QY |
768 | i.e. multicast routing does not actively react to changes in underlying |
769 | unicast topology! | |
770 | ||
d1a242fd | 771 | .. clicmd:: ip multicast rpf-lookup-mode MODE |
42fc5d26 | 772 | |
42fc5d26 | 773 | |
d1a242fd | 774 | MODE sets the method used to perform RPF lookups. Supported modes: |
42fc5d26 | 775 | |
9eb95b3b QY |
776 | urib-only |
777 | Performs the lookup on the Unicast RIB. The Multicast RIB is never used. | |
42fc5d26 | 778 | |
9eb95b3b QY |
779 | mrib-only |
780 | Performs the lookup on the Multicast RIB. The Unicast RIB is never used. | |
42fc5d26 | 781 | |
9eb95b3b QY |
782 | mrib-then-urib |
783 | Tries to perform the lookup on the Multicast RIB. If any route is found, | |
784 | that route is used. Otherwise, the Unicast RIB is tried. | |
42fc5d26 | 785 | |
9eb95b3b QY |
786 | lower-distance |
787 | Performs a lookup on the Multicast RIB and Unicast RIB each. The result | |
788 | with the lower administrative distance is used; if they're equal, the | |
789 | Multicast RIB takes precedence. | |
42fc5d26 | 790 | |
9eb95b3b QY |
791 | longer-prefix |
792 | Performs a lookup on the Multicast RIB and Unicast RIB each. The result | |
793 | with the longer prefix length is used; if they're equal, the | |
794 | Multicast RIB takes precedence. | |
42fc5d26 | 795 | |
9eb95b3b QY |
796 | The `mrib-then-urib` setting is the default behavior if nothing is |
797 | configured. If this is the desired behavior, it should be explicitly | |
798 | configured to make the configuration immune against possible changes in | |
799 | what the default behavior is. | |
42fc5d26 | 800 | |
d1a242fd | 801 | .. warning:: |
1e31580f | 802 | |
d1a242fd QY |
803 | Unreachable routes do not receive special treatment and do not cause |
804 | fallback to a second lookup. | |
42fc5d26 | 805 | |
d1a242fd | 806 | .. clicmd:: show ip rpf ADDR |
42fc5d26 | 807 | |
d1a242fd QY |
808 | Performs a Multicast RPF lookup, as configured with ``ip multicast |
809 | rpf-lookup-mode MODE``. ADDR specifies the multicast source address to look | |
810 | up. | |
42fc5d26 | 811 | |
d1a242fd | 812 | :: |
42fc5d26 QY |
813 | |
814 | > show ip rpf 192.0.2.1 | |
815 | Routing entry for 192.0.2.0/24 using Unicast RIB | |
d1a242fd QY |
816 | |
817 | Known via "kernel", distance 0, metric 0, best | |
818 | * 198.51.100.1, via eth0 | |
a8c90e15 | 819 | |
42fc5d26 | 820 | |
d1a242fd QY |
821 | Indicates that a multicast source lookup for 192.0.2.1 would use an |
822 | Unicast RIB entry for 192.0.2.0/24 with a gateway of 198.51.100.1. | |
42fc5d26 | 823 | |
d1a242fd | 824 | .. clicmd:: show ip rpf |
42fc5d26 | 825 | |
d1a242fd QY |
826 | Prints the entire Multicast RIB. Note that this is independent of the |
827 | configured RPF lookup mode, the Multicast RIB may be printed yet not | |
828 | used at all. | |
42fc5d26 | 829 | |
d1a242fd | 830 | .. clicmd:: ip mroute PREFIX NEXTHOP [DISTANCE] |
42fc5d26 | 831 | |
42fc5d26 | 832 | |
d1a242fd QY |
833 | Adds a static route entry to the Multicast RIB. This performs exactly as the |
834 | ``ip route`` command, except that it inserts the route in the Multicast RIB | |
835 | instead of the Unicast RIB. | |
42fc5d26 | 836 | |
0efdf0fe | 837 | .. _zebra-route-filtering: |
42fc5d26 QY |
838 | |
839 | zebra Route Filtering | |
840 | ===================== | |
841 | ||
0efdf0fe | 842 | Zebra supports :dfn:`prefix-list` s and :ref:`route-map` s to match routes |
013f9762 | 843 | received from other FRR components. The permit/deny facilities provided by |
d1a242fd QY |
844 | these commands can be used to filter which routes zebra will install in the |
845 | kernel. | |
42fc5d26 | 846 | |
d1a242fd | 847 | .. clicmd:: ip protocol PROTOCOL route-map ROUTEMAP |
42fc5d26 | 848 | |
013f9762 | 849 | Apply a route-map filter to routes for the specified protocol. PROTOCOL can |
431dd37e | 850 | be: |
013f9762 | 851 | |
563018b9 DS |
852 | - any, |
853 | - babel, | |
854 | - bgp, | |
013f9762 | 855 | - connected, |
563018b9 DS |
856 | - eigrp, |
857 | - isis, | |
858 | - kernel, | |
859 | - nhrp, | |
860 | - openfabric, | |
013f9762 QY |
861 | - ospf, |
862 | - ospf6, | |
563018b9 DS |
863 | - rip, |
864 | - sharp, | |
865 | - static, | |
866 | - ripng, | |
867 | - table, | |
868 | - vnc. | |
869 | ||
870 | If you choose any as the option that will cause all protocols that are sending | |
871 | routes to zebra. You can specify a :dfn:`ip protocol PROTOCOL route-map ROUTEMAP` | |
872 | on a per vrf basis, by entering this command under vrf mode for the vrf you | |
873 | want to apply the route-map against. | |
d1a242fd | 874 | |
d1a242fd QY |
875 | .. clicmd:: set src ADDRESS |
876 | ||
877 | Within a route-map, set the preferred source address for matching routes | |
878 | when installing in the kernel. | |
879 | ||
880 | ||
881 | The following creates a prefix-list that matches all addresses, a route-map | |
882 | that sets the preferred source address, and applies the route-map to all | |
883 | *rip* routes. | |
884 | ||
9eb95b3b | 885 | .. code-block:: frr |
42fc5d26 | 886 | |
d1a242fd QY |
887 | ip prefix-list ANY permit 0.0.0.0/0 le 32 |
888 | route-map RM1 permit 10 | |
889 | match ip address prefix-list ANY | |
890 | set src 10.0.0.1 | |
42fc5d26 | 891 | |
d1a242fd | 892 | ip protocol rip route-map RM1 |
a8c90e15 | 893 | |
1d0372dd TB |
894 | IPv6 example for OSPFv3. |
895 | ||
896 | .. code-block:: frr | |
897 | ||
898 | ipv6 prefix-list ANY seq 10 permit any | |
899 | route-map RM6 permit 10 | |
900 | match ipv6 address prefix-list ANY | |
901 | set src 2001:db8:425:1000::3 | |
902 | ||
903 | ipv6 protocol ospf6 route-map RM6 | |
904 | ||
905 | ||
906 | .. note:: | |
907 | ||
908 | For both IPv4 and IPv6, the IP address has to exist at the point the | |
909 | route-map is created. Be wary of race conditions if the interface is | |
910 | not created at startup. On Debian, FRR might start before ifupdown | |
911 | completes. Consider a reboot test. | |
42fc5d26 | 912 | |
03750f1e | 913 | .. clicmd:: zebra route-map delay-timer (0-600) |
3d34678f DS |
914 | |
915 | Set the delay before any route-maps are processed in zebra. The | |
916 | default time for this is 5 seconds. | |
917 | ||
0efdf0fe | 918 | .. _zebra-fib-push-interface: |
42fc5d26 QY |
919 | |
920 | zebra FIB push interface | |
921 | ======================== | |
922 | ||
923 | Zebra supports a 'FIB push' interface that allows an external | |
dc1046f7 | 924 | component to learn the forwarding information computed by the FRR |
d1a242fd | 925 | routing suite. This is a loadable module that needs to be enabled |
0efdf0fe | 926 | at startup as described in :ref:`loadable-module-support`. |
42fc5d26 | 927 | |
dc1046f7 | 928 | In FRR, the Routing Information Base (RIB) resides inside |
42fc5d26 QY |
929 | zebra. Routing protocols communicate their best routes to zebra, and |
930 | zebra computes the best route across protocols for each prefix. This | |
931 | latter information makes up the Forwarding Information Base | |
932 | (FIB). Zebra feeds the FIB to the kernel, which allows the IP stack in | |
933 | the kernel to forward packets according to the routes computed by | |
dc1046f7 | 934 | FRR. The kernel FIB is updated in an OS-specific way. For example, |
d1e7591e | 935 | the `Netlink` interface is used on Linux, and route sockets are |
42fc5d26 QY |
936 | used on FreeBSD. |
937 | ||
938 | The FIB push interface aims to provide a cross-platform mechanism to | |
939 | support scenarios where the router has a forwarding path that is | |
940 | distinct from the kernel, commonly a hardware-based fast path. In | |
941 | these cases, the FIB needs to be maintained reliably in the fast path | |
942 | as well. We refer to the component that programs the forwarding plane | |
943 | (directly or indirectly) as the Forwarding Plane Manager or FPM. | |
944 | ||
80ca5b6d QY |
945 | .. program:: configure |
946 | ||
42fc5d26 | 947 | The relevant zebra code kicks in when zebra is configured with the |
9d736133 RZ |
948 | :option:`--enable-fpm` flag and started with the module (``-M fpm`` |
949 | or ``-M dplane_fpm_nl``). | |
950 | ||
951 | .. note:: | |
952 | ||
953 | The ``fpm`` implementation attempts to connect to ``127.0.0.1`` port ``2620`` | |
954 | by default without configurations. The ``dplane_fpm_nl`` only attempts to | |
955 | connect to a server if configured. | |
956 | ||
957 | Zebra periodically attempts to connect to the well-known FPM port (``2620``). | |
958 | Once the connection is up, zebra starts sending messages containing routes | |
959 | over the socket to the FPM. Zebra sends a complete copy of the forwarding | |
960 | table to the FPM, including routes that it may have picked up from the kernel. | |
961 | The existing interaction of zebra with the kernel remains unchanged -- that | |
962 | is, the kernel continues to receive FIB updates as before. | |
963 | ||
964 | The default FPM message format is netlink, however it can be controlled | |
965 | with the module load-time option. The modules accept the following options: | |
966 | ||
967 | - ``fpm``: ``netlink`` and ``protobuf``. | |
968 | - ``dplane_fpm_nl``: none, it only implements netlink. | |
42fc5d26 QY |
969 | |
970 | The zebra FPM interface uses replace semantics. That is, if a 'route | |
971 | add' message for a prefix is followed by another 'route add' message, | |
972 | the information in the second message is complete by itself, and | |
973 | replaces the information sent in the first message. | |
974 | ||
975 | If the connection to the FPM goes down for some reason, zebra sends | |
976 | the FPM a complete copy of the forwarding table(s) when it reconnects. | |
977 | ||
9d736133 RZ |
978 | For more details on the implementation, please read the developer's manual FPM |
979 | section. | |
980 | ||
981 | FPM Commands | |
982 | ============ | |
983 | ||
984 | ``fpm`` implementation | |
985 | ---------------------- | |
986 | ||
9d736133 RZ |
987 | .. clicmd:: fpm connection ip A.B.C.D port (1-65535) |
988 | ||
03750f1e QY |
989 | Configure ``zebra`` to connect to a different FPM server than the default of |
990 | ``127.0.0.1:2060`` | |
9d736133 | 991 | |
9d736133 RZ |
992 | .. clicmd:: show zebra fpm stats |
993 | ||
994 | Shows the FPM statistics. | |
995 | ||
996 | Sample output: | |
997 | ||
998 | :: | |
999 | ||
1000 | Counter Total Last 10 secs | |
1001 | ||
1002 | connect_calls 3 2 | |
1003 | connect_no_sock 0 0 | |
1004 | read_cb_calls 2 2 | |
1005 | write_cb_calls 2 0 | |
1006 | write_calls 1 0 | |
1007 | partial_writes 0 0 | |
1008 | max_writes_hit 0 0 | |
1009 | t_write_yields 0 0 | |
1010 | nop_deletes_skipped 6 0 | |
1011 | route_adds 5 0 | |
1012 | route_dels 0 0 | |
1013 | updates_triggered 11 0 | |
1014 | redundant_triggers 0 0 | |
1015 | dests_del_after_update 0 0 | |
1016 | t_conn_down_starts 0 0 | |
1017 | t_conn_down_dests_processed 0 0 | |
1018 | t_conn_down_yields 0 0 | |
1019 | t_conn_down_finishes 0 0 | |
1020 | t_conn_up_starts 1 0 | |
1021 | t_conn_up_dests_processed 11 0 | |
1022 | t_conn_up_yields 0 0 | |
1023 | t_conn_up_aborts 0 0 | |
1024 | t_conn_up_finishes 1 0 | |
1025 | ||
1026 | ||
9d736133 RZ |
1027 | .. clicmd:: clear zebra fpm stats |
1028 | ||
6d8589da RZ |
1029 | Reset statistics related to the zebra code that interacts with the |
1030 | optional Forwarding Plane Manager (FPM) component. | |
9d736133 RZ |
1031 | |
1032 | ||
1033 | ``dplane_fpm_nl`` implementation | |
1034 | -------------------------------- | |
1035 | ||
9d736133 RZ |
1036 | .. clicmd:: fpm address <A.B.C.D|X:X::X:X> [port (1-65535)] |
1037 | ||
1038 | Configures the FPM server address. Once configured ``zebra`` will attempt | |
1039 | to connect to it immediately. | |
1040 | ||
03750f1e QY |
1041 | The ``no`` form disables FPM entirely. ``zebra`` will close any current |
1042 | connections and will not attempt to connect to it anymore. | |
9d736133 | 1043 | |
5f66e9a0 RZ |
1044 | .. clicmd:: fpm use-next-hop-groups |
1045 | ||
1046 | Use the new netlink messages ``RTM_NEWNEXTHOP`` / ``RTM_DELNEXTHOP`` to | |
1047 | group repeated route next hop information. | |
1048 | ||
f41ddc27 | 1049 | The ``no`` form uses the old known FPM behavior of including next hop |
03750f1e | 1050 | information in the route (e.g. ``RTM_NEWROUTE``) messages. |
5f66e9a0 | 1051 | |
9d736133 RZ |
1052 | .. clicmd:: show fpm counters [json] |
1053 | ||
1054 | Show the FPM statistics (plain text or JSON formatted). | |
1055 | ||
1056 | Sample output: | |
1057 | ||
1058 | :: | |
1059 | ||
1060 | FPM counters | |
1061 | ============ | |
1062 | Input bytes: 0 | |
1063 | Output bytes: 308 | |
1064 | Output buffer current size: 0 | |
1065 | Output buffer peak size: 308 | |
1066 | Connection closes: 0 | |
1067 | Connection errors: 0 | |
1068 | Data plane items processed: 0 | |
1069 | Data plane items enqueued: 0 | |
1070 | Data plane items queue peak: 0 | |
1071 | Buffer full hits: 0 | |
1072 | User FPM configurations: 1 | |
1073 | User FPM disable requests: 0 | |
1074 | ||
1075 | ||
9d736133 RZ |
1076 | .. clicmd:: clear fpm counters |
1077 | ||
6d8589da RZ |
1078 | Reset statistics related to the zebra code that interacts with the |
1079 | optional Forwarding Plane Manager (FPM) component. | |
9d736133 RZ |
1080 | |
1081 | ||
3fdcb303 MS |
1082 | .. _zebra-dplane: |
1083 | ||
1084 | Dataplane Commands | |
1085 | ================== | |
1086 | ||
1087 | The zebra dataplane subsystem provides a framework for FIB | |
1088 | programming. Zebra uses the dataplane to program the local kernel as | |
1089 | it makes changes to objects such as IP routes, MPLS LSPs, and | |
1090 | interface IP addresses. The dataplane runs in its own pthread, in | |
1091 | order to off-load work from the main zebra pthread. | |
1092 | ||
1093 | ||
3fdcb303 MS |
1094 | .. clicmd:: show zebra dplane [detailed] |
1095 | ||
1096 | Display statistics about the updates and events passing through the | |
1097 | dataplane subsystem. | |
1098 | ||
1099 | ||
3fdcb303 MS |
1100 | .. clicmd:: show zebra dplane providers |
1101 | ||
1102 | Display information about the running dataplane plugins that are | |
1103 | providing updates to a FIB. By default, the local kernel plugin is | |
1104 | present. | |
1105 | ||
1106 | ||
3fdcb303 MS |
1107 | .. clicmd:: zebra dplane limit [NUMBER] |
1108 | ||
1109 | Configure the limit on the number of pending updates that are | |
1110 | waiting to be processed by the dataplane pthread. | |
1111 | ||
1112 | ||
42fc5d26 QY |
1113 | zebra Terminal Mode Commands |
1114 | ============================ | |
1115 | ||
d1a242fd | 1116 | .. clicmd:: show ip route |
42fc5d26 | 1117 | |
d1a242fd | 1118 | Display current routes which zebra holds in its database. |
42fc5d26 QY |
1119 | |
1120 | :: | |
1121 | ||
42fc5d26 QY |
1122 | Router# show ip route |
1123 | Codes: K - kernel route, C - connected, S - static, R - RIP, | |
d1a242fd | 1124 | B - BGP * - FIB route. |
42fc5d26 | 1125 | |
d1a242fd QY |
1126 | K* 0.0.0.0/0 203.181.89.241 |
1127 | S 0.0.0.0/0 203.181.89.1 | |
1128 | C* 127.0.0.0/8 lo | |
42fc5d26 | 1129 | C* 203.181.89.240/28 eth0 |
a8c90e15 | 1130 | |
42fc5d26 | 1131 | |
d1a242fd | 1132 | .. clicmd:: show ipv6 route |
42fc5d26 | 1133 | |
da3ef85b | 1134 | .. clicmd:: show [ip|ipv6] route [PREFIX] [nexthop-group] |
fbe49edb | 1135 | |
da3ef85b SW |
1136 | Display detailed information about a route. If [nexthop-group] is |
1137 | included, it will display the nexthop group ID the route is using as well. | |
1138 | ||
da3ef85b SW |
1139 | .. clicmd:: show interface [NAME] [{vrf VRF|brief}] [nexthop-group] |
1140 | ||
da3ef85b SW |
1141 | .. clicmd:: show interface [NAME] [{vrf all|brief}] [nexthop-group] |
1142 | ||
1143 | Display interface information. If no extra information is added, it will | |
1144 | dump information on all interfaces. If [NAME] is specified, it will display | |
1145 | detailed information about that single interface. If [nexthop-group] is | |
1146 | specified, it will display nexthop groups pointing out that interface. | |
42fc5d26 | 1147 | |
d1a242fd | 1148 | .. clicmd:: show ip prefix-list [NAME] |
42fc5d26 | 1149 | |
d1a242fd | 1150 | .. clicmd:: show route-map [NAME] |
42fc5d26 | 1151 | |
d1a242fd | 1152 | .. clicmd:: show ip protocol |
42fc5d26 | 1153 | |
854cdf7c | 1154 | .. clicmd:: show ip forward |
42fc5d26 | 1155 | |
d1a242fd QY |
1156 | Display whether the host's IP forwarding function is enabled or not. |
1157 | Almost any UNIX kernel can be configured with IP forwarding disabled. | |
1158 | If so, the box can't work as a router. | |
42fc5d26 | 1159 | |
854cdf7c | 1160 | .. clicmd:: show ipv6 forward |
42fc5d26 | 1161 | |
d1a242fd | 1162 | Display whether the host's IP v6 forwarding is enabled or not. |
42fc5d26 | 1163 | |
d1a242fd | 1164 | .. clicmd:: show zebra |
42fc5d26 | 1165 | |
d1a242fd QY |
1166 | Display various statistics related to the installation and deletion |
1167 | of routes, neighbor updates, and LSP's into the kernel. | |
42fc5d26 | 1168 | |
46677ed2 DS |
1169 | .. clicmd:: show zebra client [summary] |
1170 | ||
1171 | Display statistics about clients that are connected to zebra. This is | |
1172 | useful for debugging and seeing how much data is being passed between | |
1173 | zebra and it's clients. If the summary form of the command is choosen | |
1174 | a table is displayed with shortened information. | |
1175 | ||
46677ed2 DS |
1176 | .. clicmd:: show zebra router table summary |
1177 | ||
1178 | Display summarized data about tables created, their afi/safi/tableid | |
1179 | and how many routes each table contains. Please note this is the | |
1180 | total number of route nodes in the table. Which will be higher than | |
1181 | the actual number of routes that are held. | |
1182 | ||
a8ad9a89 | 1183 | .. clicmd:: show nexthop-group rib [ID] [vrf NAME] [singleton [ip|ip6]] [type] |
083954e9 DS |
1184 | |
1185 | Display nexthop groups created by zebra. The [vrf NAME] option | |
1186 | is only meaningful if you have started zebra with the --vrfwnetns | |
1187 | option as that nexthop groups are per namespace in linux. | |
1188 | If you specify singleton you would like to see the singleton | |
a8ad9a89 SW |
1189 | nexthop groups that do have an afi. [type] allows you to filter those |
1190 | only coming from a specific NHG type (protocol). | |
da3ef85b | 1191 | |
d29fd1b7 | 1192 | .. clicmd:: show <ip|ipv6> zebra route dump [<vrf> VRFNAME] |
1193 | ||
1194 | It dumps all the routes from RIB with detailed information including | |
1195 | internal flags, status etc. This is defined as a hidden command. | |
1196 | ||
13b01f2f JAG |
1197 | |
1198 | Router-id | |
1199 | ========= | |
1200 | ||
1201 | Many routing protocols require a router-id to be configured. To have a | |
1202 | consistent router-id across all daemons, the following commands are available | |
1203 | to configure and display the router-id: | |
1204 | ||
03750f1e | 1205 | .. clicmd:: [ip] router-id A.B.C.D |
13b01f2f | 1206 | |
17d1eafa | 1207 | Allow entering of the router-id. This command also works under the |
98a3fb0a | 1208 | vrf subnode, to allow router-id's per vrf. |
13b01f2f | 1209 | |
03750f1e | 1210 | .. clicmd:: [ip] router-id A.B.C.D vrf NAME |
17d1eafa DS |
1211 | |
1212 | Configure the router-id of this router from the configure NODE. | |
1213 | A show run of this command will display the router-id command | |
1214 | under the vrf sub node. This command is deprecated and will | |
1215 | be removed at some point in time in the future. | |
98a3fb0a | 1216 | |
98a3fb0a | 1217 | .. clicmd:: show [ip] router-id [vrf NAME] |
13b01f2f JAG |
1218 | |
1219 | Display the user configured router-id. | |
1220 | ||
98a3fb0a SM |
1221 | For protocols requiring an IPv6 router-id, the following commands are available: |
1222 | ||
03750f1e | 1223 | .. clicmd:: ipv6 router-id X:X::X:X |
98a3fb0a SM |
1224 | |
1225 | Configure the IPv6 router-id of this router. Like its IPv4 counterpart, | |
1226 | this command works under the vrf subnode, to allow router-id's per vrf. | |
1227 | ||
98a3fb0a | 1228 | .. clicmd:: show ipv6 router-id [vrf NAME] |
13b01f2f | 1229 | |
98a3fb0a | 1230 | Display the user configured IPv6 router-id. |
8d150f52 | 1231 | |
cbacd05b DS |
1232 | Expected sysctl settings |
1233 | ======================== | |
1234 | ||
1235 | The linux kernel has a variety of sysctl's that affect it's operation as a router. This | |
1236 | section is meant to act as a starting point for those sysctl's that must be used in | |
1237 | order to provide FRR with smooth operation as a router. This section is not meant | |
1238 | as the full documentation for sysctl's. The operator must use the sysctl documentation | |
1239 | with the linux kernel for that. | |
1240 | ||
1241 | .. option:: net.ipv4.ip_forward = 1 | |
1242 | ||
1243 | This option allows the linux kernel to forward ipv4 packets incoming from one interface | |
1244 | to an outgoing interface. Without this no forwarding will take place from off box packets. | |
1245 | ||
1246 | .. option:: net.ipv6.conf.all_forwarding=1 | |
1247 | ||
1248 | This option allows the linux kernel to forward ipv6 packets incoming from one interface | |
1249 | to an outgoing interface. Without this no forwarding will take place from off box packets. | |
1250 | ||
1251 | .. option:: net.ipv6.conf.all.keep_addr_on_down=1 | |
1252 | ||
1253 | When an interface is taken down, do not remove the v6 addresses associated with the interface. | |
1254 | This option is recommended because this is the default behavior for v4 as well. | |
1255 | ||
1256 | .. option:: net.ipv6.route.skip_notify_on_dev_down=1 | |
1257 | ||
1258 | When an interface is taken down, the linux kernel will not notify, via netlink, about routes | |
1259 | that used that interface being removed from the FIB. This option is recommended because this | |
1260 | is the default behavior for v4 as well. | |
8d150f52 MS |
1261 | |
1262 | Debugging | |
1263 | ========= | |
1264 | ||
1265 | .. clicmd:: debug zebra mpls [detailed] | |
1266 | ||
1267 | MPLS-related events and information. | |
1268 | ||
1269 | .. clicmd:: debug zebra events | |
1270 | ||
1271 | Zebra events | |
1272 | ||
1273 | .. clicmd:: debug zebra nht [detailed] | |
1274 | ||
1275 | Nexthop-tracking / reachability information | |
1276 | ||
1277 | .. clicmd:: debug zebra vxlan | |
1278 | ||
1279 | VxLAN (EVPN) events | |
1280 | ||
1281 | .. clicmd:: debug zebra pseudowires | |
1282 | ||
1283 | Pseudowire events. | |
1284 | ||
1285 | .. clicmd:: debug zebra packet [<recv|send>] [detail] | |
1286 | ||
1287 | ZAPI message and packet details | |
1288 | ||
1289 | .. clicmd:: debug zebra kernel | |
1290 | ||
1291 | Kernel / OS events. | |
1292 | ||
1293 | .. clicmd:: debug zebra kernel msgdump [<recv|send>] | |
1294 | ||
1295 | Raw OS (netlink) message details. | |
1296 | ||
1297 | .. clicmd:: debug zebra rib [detailed] | |
1298 | ||
1299 | RIB events. | |
1300 | ||
1301 | .. clicmd:: debug zebra fpm | |
1302 | ||
1303 | FPM (forwarding-plane manager) events. | |
1304 | ||
1305 | .. clicmd:: debug zebra dplane [detailed] | |
1306 | ||
1307 | Dataplane / FIB events. | |
1308 | ||
1309 | .. clicmd:: debug zebra pbr | |
1310 | ||
1311 | PBR (policy-based routing) events. | |
1312 | ||
1313 | .. clicmd:: debug zebra mlag | |
1314 | ||
1315 | MLAG events. | |
1316 | ||
1317 | .. clicmd:: debug zebra evpn mh <es|mac|neigh|nh> | |
1318 | ||
1319 | EVPN multi-hop events. | |
1320 | ||
1321 | .. clicmd:: debug zebra nexthop [detail] | |
1322 | ||
1323 | Nexthop and nexthop-group events. | |
1324 |