]>
Commit | Line | Data |
---|---|---|
1 | .. _zebra: | |
2 | ||
3 | ***** | |
4 | Zebra | |
5 | ***** | |
6 | ||
7 | *zebra* is an IP routing manager. It provides kernel routing | |
8 | table updates, interface lookups, and redistribution of routes between | |
9 | different routing protocols. | |
10 | ||
11 | .. _invoking-zebra: | |
12 | ||
13 | Invoking zebra | |
14 | ============== | |
15 | ||
16 | Besides the common invocation options (:ref:`common-invocation-options`), the | |
17 | *zebra* specific invocation options are listed below. | |
18 | ||
19 | .. program:: zebra | |
20 | ||
21 | .. option:: -b, --batch | |
22 | ||
23 | Runs in batch mode. *zebra* parses configuration file and terminates | |
24 | immediately. | |
25 | ||
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 | Under the \*BSD's, there is no way to properly store the originating | |
33 | route and the route types in this case will show up as a static route | |
34 | with an admin distance of 255. | |
35 | ||
36 | .. option:: -r, --retain | |
37 | ||
38 | When program terminates, do not flush routes installed by *zebra* from the | |
39 | kernel. | |
40 | ||
41 | .. option:: -e X, --ecmp X | |
42 | ||
43 | Run zebra with a limited ecmp ability compared to what it is compiled to. | |
44 | If you are running zebra on hardware limited functionality you can | |
45 | force zebra to limit the maximum ecmp allowed to X. This number | |
46 | is bounded by what you compiled FRR with as the maximum number. | |
47 | ||
48 | .. option:: -n, --vrfwnetns | |
49 | ||
50 | When *Zebra* starts with this option, the VRF backend is based on Linux | |
51 | network namespaces. That implies that all network namespaces discovered by | |
52 | ZEBRA will create an associated VRF. The other daemons will operate on the VRF | |
53 | VRF defined by *Zebra*, as usual. | |
54 | ||
55 | .. seealso:: :ref:`zebra-vrf` | |
56 | ||
57 | .. option:: -z <path_to_socket>, --socket <path_to_socket> | |
58 | ||
59 | If this option is supplied on the cli, the path to the zebra | |
60 | control socket(zapi), is used. This option overrides a -N <namespace> | |
61 | option if handed to it on the cli. | |
62 | ||
63 | .. option:: --v6-rr-semantics | |
64 | ||
65 | The linux kernel is receiving the ability to use the same route | |
66 | replacement semantics for v6 that v4 uses. If you are using a | |
67 | kernel that supports this functionality then run *Zebra* with this | |
68 | option and we will use Route Replace Semantics instead of delete | |
69 | than add. | |
70 | ||
71 | .. option:: --asic-offload [notify_on_offload|notify_on_ack] | |
72 | ||
73 | The linux kernel has the ability to use asic-offload ( see switchdev | |
74 | development ). When the operator knows that FRR will be working in | |
75 | this way, allow them to specify this with FRR. At this point this | |
76 | code only supports asynchronous notification of the offload state. | |
77 | In other words the initial ACK received for linux kernel installation | |
78 | does not give zebra any data about what the state of the offload | |
79 | is. This option takes the optional paramegers notify_on_offload | |
80 | or notify_on_ack. This signals to zebra to notify upper level | |
81 | protocols about route installation/update on ack received from | |
82 | the linux kernel or from offload notification. | |
83 | ||
84 | .. option:: -s <SIZE>, --nl-bufsize <SIZE> | |
85 | ||
86 | Allow zebra to modify the default receive buffer size to SIZE | |
87 | in bytes. Under \*BSD only the -s option is available. | |
88 | ||
89 | .. _interface-commands: | |
90 | ||
91 | Configuration Addresses behaviour | |
92 | ================================= | |
93 | ||
94 | At startup, *Zebra* will first discover the underlying networking objects | |
95 | from the operating system. This includes interfaces, addresses of | |
96 | interfaces, static routes, etc. Then, it will read the configuration | |
97 | file, including its own interface addresses, static routes, etc. All this | |
98 | information comprises the operational context from *Zebra*. But | |
99 | configuration context from *Zebra* will remain the same as the one from | |
100 | :file:`zebra.conf` config file. As an example, executing the following | |
101 | :clicmd:`show running-config` will reflect what was in :file:`zebra.conf`. | |
102 | In a similar way, networking objects that are configured outside of the | |
103 | *Zebra* like *iproute2* will not impact the configuration context from | |
104 | *Zebra*. This behaviour permits you to continue saving your own config | |
105 | file, and decide what is really to be pushed on the config file, and what | |
106 | is dependent on the underlying system. | |
107 | Note that inversely, from *Zebra*, you will not be able to delete networking | |
108 | objects that were previously configured outside of *Zebra*. | |
109 | ||
110 | ||
111 | Interface Commands | |
112 | ================== | |
113 | ||
114 | .. _standard-commands: | |
115 | ||
116 | Standard Commands | |
117 | ----------------- | |
118 | ||
119 | ||
120 | .. clicmd:: interface IFNAME | |
121 | ||
122 | ||
123 | .. clicmd:: interface IFNAME vrf VRF | |
124 | ||
125 | ||
126 | .. clicmd:: shutdown | |
127 | ||
128 | ||
129 | Up or down the current interface. | |
130 | ||
131 | ||
132 | .. clicmd:: ip address ADDRESS/PREFIX | |
133 | ||
134 | .. clicmd:: ipv6 address ADDRESS/PREFIX | |
135 | ||
136 | ||
137 | ||
138 | Set the IPv4 or IPv6 address/prefix for the interface. | |
139 | ||
140 | ||
141 | .. clicmd:: ip address LOCAL-ADDR peer PEER-ADDR/PREFIX | |
142 | ||
143 | ||
144 | Configure an IPv4 Point-to-Point address on the interface. (The concept of | |
145 | PtP addressing does not exist for IPv6.) | |
146 | ||
147 | ``local-addr`` has no subnet mask since the local side in PtP addressing is | |
148 | always a single (/32) address. ``peer-addr/prefix`` can be an arbitrary subnet | |
149 | behind the other end of the link (or even on the link in Point-to-Multipoint | |
150 | setups), though generally /32s are used. | |
151 | ||
152 | ||
153 | .. clicmd:: description DESCRIPTION ... | |
154 | ||
155 | Set description for the interface. | |
156 | ||
157 | ||
158 | .. clicmd:: mpls enable | |
159 | ||
160 | Enable or disable mpls kernel processing on the interface, for linux. Interfaces | |
161 | configured with mpls will not automatically turn on if mpls kernel modules do not | |
162 | happen to be loaded. This command will fail on 3.X linux kernels and does not | |
163 | work on non-linux systems at all. | |
164 | ||
165 | .. clicmd:: multicast | |
166 | ||
167 | ||
168 | Enable or disable multicast flag for the interface. | |
169 | ||
170 | ||
171 | .. clicmd:: bandwidth (1-10000000) | |
172 | ||
173 | ||
174 | Set bandwidth value of the interface in kilobits/sec. This is for | |
175 | calculating OSPF cost. This command does not affect the actual device | |
176 | configuration. | |
177 | ||
178 | ||
179 | .. clicmd:: link-detect | |
180 | ||
181 | ||
182 | Enable or disable link-detect on platforms which support this. Currently only | |
183 | Linux, and only where network interface drivers support reporting | |
184 | link-state via the ``IFF_RUNNING`` flag. | |
185 | ||
186 | In FRR, link-detect is on by default. | |
187 | ||
188 | .. _link-parameters-commands: | |
189 | ||
190 | Link Parameters Commands | |
191 | ------------------------ | |
192 | ||
193 | .. note:: | |
194 | ||
195 | At this time, FRR offers partial support for some of the routing | |
196 | protocol extensions that can be used with MPLS-TE. FRR does not | |
197 | support a complete RSVP-TE solution currently. | |
198 | ||
199 | .. clicmd:: link-params | |
200 | ||
201 | ||
202 | Enter into the link parameters sub node. At least 'enable' must be | |
203 | set to activate the link parameters, and consequently routing | |
204 | information that could be used as part of Traffic Engineering on | |
205 | this interface. MPLS-TE must be enable at the OSPF | |
206 | (:ref:`ospf-traffic-engineering`) or ISIS | |
207 | (:ref:`isis-traffic-engineering`) router level in complement to | |
208 | this. | |
209 | ||
210 | Under link parameter statement, the following commands set the different TE values: | |
211 | ||
212 | .. clicmd:: enable | |
213 | ||
214 | Enable link parameters for this interface. | |
215 | ||
216 | .. clicmd:: metric (0-4294967295) | |
217 | ||
218 | .. clicmd:: max-bw BANDWIDTH | |
219 | ||
220 | .. clicmd:: max-rsv-bw BANDWIDTH | |
221 | ||
222 | .. clicmd:: unrsv-bw (0-7) BANDWIDTH | |
223 | ||
224 | .. clicmd:: admin-grp BANDWIDTH | |
225 | ||
226 | These commands specifies the Traffic Engineering parameters of the interface | |
227 | in conformity to RFC3630 (OSPF) or RFC5305 (ISIS). There are respectively | |
228 | the TE Metric (different from the OSPF or ISIS metric), Maximum Bandwidth | |
229 | (interface speed by default), Maximum Reservable Bandwidth, Unreserved | |
230 | Bandwidth for each 0-7 priority and Admin Group (ISIS) or Resource | |
231 | Class/Color (OSPF). | |
232 | ||
233 | Note that BANDWIDTH is specified in IEEE floating point format and express | |
234 | in Bytes/second. | |
235 | ||
236 | .. clicmd:: delay (0-16777215) [min (0-16777215) | max (0-16777215)] | |
237 | ||
238 | .. clicmd:: delay-variation (0-16777215) | |
239 | ||
240 | .. clicmd:: packet-loss PERCENTAGE | |
241 | ||
242 | .. clicmd:: res-bw BANDWIDTH | |
243 | ||
244 | .. clicmd:: ava-bw BANDWIDTH | |
245 | ||
246 | .. clicmd:: use-bw BANDWIDTH | |
247 | ||
248 | These command specifies additional Traffic Engineering parameters of the | |
249 | interface in conformity to draft-ietf-ospf-te-metrics-extension-05.txt and | |
250 | draft-ietf-isis-te-metrics-extension-03.txt. There are respectively the | |
251 | delay, jitter, loss, available bandwidth, reservable bandwidth and utilized | |
252 | bandwidth. | |
253 | ||
254 | Note that BANDWIDTH is specified in IEEE floating point format and express | |
255 | in Bytes/second. Delays and delay variation are express in micro-second | |
256 | (µs). Loss is specified in PERCENTAGE ranging from 0 to 50.331642% by step | |
257 | of 0.000003. | |
258 | ||
259 | .. clicmd:: neighbor <A.B.C.D> as (0-65535) | |
260 | ||
261 | Specifies the remote ASBR IP address and Autonomous System (AS) number | |
262 | for InterASv2 link in OSPF (RFC5392). Note that this option is not yet | |
263 | supported for ISIS (RFC5316). | |
264 | ||
265 | Global Commands | |
266 | ------------------------ | |
267 | ||
268 | .. clicmd:: zebra protodown reason-bit (0-31) | |
269 | ||
270 | This command is only supported for linux and a kernel > 5.1. | |
271 | Change reason-bit frr uses for setting protodown. We default to 7, but | |
272 | if another userspace app ever conflicts with this, you can change it here. | |
273 | The descriptor for this bit should exist in :file:`/etc/iproute2/protodown_reasons.d/` | |
274 | to display with :clicmd:`ip -d link show`. | |
275 | ||
276 | Nexthop Tracking | |
277 | ================ | |
278 | ||
279 | Nexthop tracking doesn't resolve nexthops via the default route by default. | |
280 | Allowing this might be useful when e.g. you want to allow BGP to peer across | |
281 | the default route. | |
282 | ||
283 | .. clicmd:: zebra nexthop-group keep (1-3600) | |
284 | ||
285 | Set the time that zebra will keep a created and installed nexthop group | |
286 | before removing it from the system if the nexthop group is no longer | |
287 | being used. The default time is 180 seconds. | |
288 | ||
289 | .. clicmd:: ip nht resolve-via-default | |
290 | ||
291 | Allow IPv4 nexthop tracking to resolve via the default route. This parameter | |
292 | is configured per-VRF, so the command is also available in the VRF subnode. | |
293 | ||
294 | .. clicmd:: ipv6 nht resolve-via-default | |
295 | ||
296 | Allow IPv6 nexthop tracking to resolve via the default route. This parameter | |
297 | is configured per-VRF, so the command is also available in the VRF subnode. | |
298 | ||
299 | .. clicmd:: show ip nht [vrf NAME] [A.B.C.D|X:X::X:X] [mrib] | |
300 | ||
301 | Show nexthop tracking status for address resolution. If vrf is not specified | |
302 | then display the default vrf. If ``all`` is specified show all vrf address | |
303 | resolution output. If an ipv4 or ipv6 address is not specified then display | |
304 | all addresses tracked, else display the requested address. The mrib keyword | |
305 | indicates that the operator wants to see the multicast rib address resolution | |
306 | table. An alternative form of the command is ``show ip import-check`` and this | |
307 | form of the command is deprecated at this point in time. | |
308 | ||
309 | PBR dataplane programming | |
310 | ========================= | |
311 | ||
312 | Some dataplanes require the PBR nexthop to be resolved into a SMAC, DMAC and | |
313 | outgoing interface | |
314 | ||
315 | .. clicmd:: pbr nexthop-resolve | |
316 | ||
317 | Resolve PBR nexthop via ip neigh tracking | |
318 | ||
319 | Administrative Distance | |
320 | ======================= | |
321 | ||
322 | Administrative distance allows FRR to make decisions about what routes | |
323 | should be installed in the rib based upon the originating protocol. | |
324 | The lowest Admin Distance is the route selected. This is purely a | |
325 | subjective decision about ordering and care has been taken to choose | |
326 | the same distances that other routing suites have chosen. | |
327 | ||
328 | +------------+-----------+ | |
329 | | Protocol | Distance | | |
330 | +------------+-----------+ | |
331 | | System | 0 | | |
332 | +------------+-----------+ | |
333 | | Kernel | 0 | | |
334 | +------------+-----------+ | |
335 | | Connect | 0 | | |
336 | +------------+-----------+ | |
337 | | Static | 1 | | |
338 | +------------+-----------+ | |
339 | | NHRP | 10 | | |
340 | +------------+-----------+ | |
341 | | EBGP | 20 | | |
342 | +------------+-----------+ | |
343 | | EIGRP | 90 | | |
344 | +------------+-----------+ | |
345 | | BABEL | 100 | | |
346 | +------------+-----------+ | |
347 | | OSPF | 110 | | |
348 | +------------+-----------+ | |
349 | | ISIS | 115 | | |
350 | +------------+-----------+ | |
351 | | OPENFABRIC | 115 | | |
352 | +------------+-----------+ | |
353 | | RIP | 120 | | |
354 | +------------+-----------+ | |
355 | | Table | 150 | | |
356 | +------------+-----------+ | |
357 | | SHARP | 150 | | |
358 | +------------+-----------+ | |
359 | | IBGP | 200 | | |
360 | +------------+-----------+ | |
361 | | PBR | 200 | | |
362 | +------------+-----------+ | |
363 | ||
364 | An admin distance of 255 indicates to Zebra that the route should not be | |
365 | installed into the Data Plane. Additionally routes with an admin distance | |
366 | of 255 will not be redistributed. | |
367 | ||
368 | Zebra does treat Kernel routes as special case for the purposes of Admin | |
369 | Distance. Upon learning about a route that is not originated by FRR | |
370 | we read the metric value as a uint32_t. The top byte of the value | |
371 | is interpreted as the Administrative Distance and the low three bytes | |
372 | are read in as the metric. This special case is to facilitate VRF | |
373 | default routes. | |
374 | ||
375 | Route Replace Semantics | |
376 | ======================= | |
377 | ||
378 | When using the Linux Kernel as a forwarding plane, routes are installed | |
379 | with a metric of 20 to the kernel. Please note that the kernel's metric | |
380 | value bears no resemblence to FRR's RIB metric or admin distance. It | |
381 | merely is a way for the Linux Kernel to decide which route to use if it | |
382 | has multiple routes for the same prefix from multiple sources. An example | |
383 | here would be if someone else was running another routing suite besides | |
384 | FRR at the same time, the kernel must choose what route to use to forward | |
385 | on. FRR choose the value of 20 because of two reasons. FRR wanted a | |
386 | value small enough to be chosen but large enough that the operator could | |
387 | allow route prioritization by the kernel when multiple routing suites are | |
388 | being run and FRR wanted to take advantage of Route Replace semantics that | |
389 | the linux kernel offers. In order for Route Replacement semantics to | |
390 | work FRR must use the same metric when issuing the replace command. | |
391 | Currently FRR only supports Route Replace semantics using the Linux | |
392 | Kernel. | |
393 | ||
394 | .. _zebra-vrf: | |
395 | ||
396 | Virtual Routing and Forwarding | |
397 | ============================== | |
398 | ||
399 | FRR supports :abbr:`VRF (Virtual Routing and Forwarding)`. VRF is a way to | |
400 | separate networking contexts on the same machine. Those networking contexts are | |
401 | associated with separate interfaces, thus making it possible to associate one | |
402 | interface with a specific VRF. | |
403 | ||
404 | VRF can be used, for example, when instantiating per enterprise networking | |
405 | services, without having to instantiate the physical host machine or the | |
406 | routing management daemons for each enterprise. As a result, interfaces are | |
407 | separate for each set of VRF, and routing daemons can have their own context | |
408 | for each VRF. | |
409 | ||
410 | This conceptual view introduces the *Default VRF* case. If the user does not | |
411 | configure any specific VRF, then by default, FRR uses the *Default VRF*. The | |
412 | name "default" is used to refer to this VRF in various CLI commands and YANG | |
413 | models. It is possible to change that name by passing the ``-o`` option to all | |
414 | daemons, for example, one can use ``-o vrf0`` to change the name to "vrf0". | |
415 | The easiest way to pass the same option to all daemons is to use the | |
416 | ``frr_global_options`` variable in the | |
417 | :ref:`Daemons Configuration File <daemons-configuration-file>`. | |
418 | ||
419 | Configuring VRF networking contexts can be done in various ways on FRR. The VRF | |
420 | interfaces can be configured by entering in interface configuration mode | |
421 | :clicmd:`interface IFNAME vrf VRF`. | |
422 | ||
423 | A VRF backend mode is chosen when running *Zebra*. | |
424 | ||
425 | If no option is chosen, then the *Linux VRF* implementation as references in | |
426 | https://www.kernel.org/doc/Documentation/networking/vrf.txt will be mapped over | |
427 | the *Zebra* VRF. The routing table associated to that VRF is a Linux table | |
428 | identifier located in the same *Linux network namespace* where *Zebra* started. | |
429 | Please note when using the *Linux VRF* routing table it is expected that a | |
430 | default Kernel route will be installed that has a metric as outlined in the | |
431 | www.kernel.org doc above. The Linux Kernel does table lookup via a combination | |
432 | of rule application of the rule table and then route lookup of the specified | |
433 | table. If no route match is found then the next applicable rule is applied | |
434 | to find the next route table to use to look for a route match. As such if | |
435 | your VRF table does not have a default blackhole route with a high metric | |
436 | VRF route lookup will leave the table specified by the VRF, which is undesirable. | |
437 | ||
438 | If the :option:`-n` option is chosen, then the *Linux network namespace* will | |
439 | be mapped over the *Zebra* VRF. That implies that *Zebra* is able to configure | |
440 | several *Linux network namespaces*. The routing table associated to that VRF | |
441 | is the whole routing tables located in that namespace. For instance, this mode | |
442 | matches OpenStack Network Namespaces. It matches also OpenFastPath. The default | |
443 | behavior remains Linux VRF which is supported by the Linux kernel community, | |
444 | see https://www.kernel.org/doc/Documentation/networking/vrf.txt. | |
445 | ||
446 | Because of that difference, there are some subtle differences when running some | |
447 | commands in relationship to VRF. Here is an extract of some of those commands: | |
448 | ||
449 | .. clicmd:: vrf VRF | |
450 | ||
451 | This command is available on configuration mode. By default, above command | |
452 | permits accessing the VRF configuration mode. This mode is available for | |
453 | both VRFs. It is to be noted that *Zebra* does not create Linux VRF. | |
454 | The network administrator can however decide to provision this command in | |
455 | configuration file to provide more clarity about the intended configuration. | |
456 | ||
457 | .. clicmd:: netns NAMESPACE | |
458 | ||
459 | This command is based on VRF configuration mode. This command is available | |
460 | when *Zebra* is run in :option:`-n` mode. This command reflects which *Linux | |
461 | network namespace* is to be mapped with *Zebra* VRF. It is to be noted that | |
462 | *Zebra* creates and detects added/suppressed VRFs from the Linux environment | |
463 | (in fact, those managed with iproute2). The network administrator can however | |
464 | decide to provision this command in configuration file to provide more clarity | |
465 | about the intended configuration. | |
466 | ||
467 | .. clicmd:: show ip route vrf VRF | |
468 | ||
469 | The show command permits dumping the routing table associated to the VRF. If | |
470 | *Zebra* is launched with default settings, this will be the ``TABLENO`` of | |
471 | the VRF configured on the kernel, thanks to information provided in | |
472 | https://www.kernel.org/doc/Documentation/networking/vrf.txt. If *Zebra* is | |
473 | launched with :option:`-n` option, this will be the default routing table of | |
474 | the *Linux network namespace* ``VRF``. | |
475 | ||
476 | .. clicmd:: show ip route vrf VRF table TABLENO | |
477 | ||
478 | The show command is only available with :option:`-n` option. This command | |
479 | will dump the routing table ``TABLENO`` of the *Linux network namespace* | |
480 | ``VRF``. | |
481 | ||
482 | .. clicmd:: show ip route vrf VRF tables | |
483 | ||
484 | This command will dump the routing tables within the vrf scope. If ``vrf all`` | |
485 | is executed, all routing tables will be dumped. | |
486 | ||
487 | .. clicmd:: show <ip|ipv6> route summary [vrf VRF] [table TABLENO] [prefix] | |
488 | ||
489 | This command will dump a summary output of the specified VRF and TABLENO | |
490 | combination. If neither VRF or TABLENO is specified FRR defaults to | |
491 | the default vrf and default table. If prefix is specified dump the | |
492 | number of prefix routes. | |
493 | ||
494 | .. _zebra-table-allocation: | |
495 | ||
496 | Table Allocation | |
497 | ================ | |
498 | ||
499 | Some services like BGP flowspec allocate routing tables to perform policy | |
500 | routing based on netfilter criteria and IP rules. In order to avoid | |
501 | conflicts between VRF allocated routing tables and those services, Zebra | |
502 | proposes to define a chunk of routing tables to use by other services. | |
503 | ||
504 | Allocation configuration can be done like below, with the range of the | |
505 | chunk of routing tables to be used by the given service. | |
506 | ||
507 | .. clicmd:: ip table range <STARTTABLENO> <ENDTABLENO> | |
508 | ||
509 | .. _zebra-ecmp: | |
510 | ||
511 | ECMP | |
512 | ==== | |
513 | ||
514 | FRR supports ECMP as part of normal operations and is generally compiled | |
515 | with a limit of 64 way ECMP. This of course can be modified via configure | |
516 | options on compilation if the end operator desires to do so. Individual | |
517 | protocols each have their own way of dictating ECMP policy and their | |
518 | respective documentation should be read. | |
519 | ||
520 | ECMP can be inspected in zebra by doing a ``show ip route X`` command. | |
521 | ||
522 | .. code-block:: shell | |
523 | ||
524 | eva# show ip route 4.4.4.4/32 | |
525 | Codes: K - kernel route, C - connected, S - static, R - RIP, | |
526 | O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, | |
527 | T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, | |
528 | F - PBR, f - OpenFabric, | |
529 | > - selected route, * - FIB route, q - queued, r - rejected, b - backup | |
530 | t - trapped, o - offload failure | |
531 | ||
532 | D>* 4.4.4.4/32 [150/0] via 192.168.161.1, enp39s0, weight 1, 00:00:02 | |
533 | * via 192.168.161.2, enp39s0, weight 1, 00:00:02 | |
534 | * via 192.168.161.3, enp39s0, weight 1, 00:00:02 | |
535 | * via 192.168.161.4, enp39s0, weight 1, 00:00:02 | |
536 | * via 192.168.161.5, enp39s0, weight 1, 00:00:02 | |
537 | * via 192.168.161.6, enp39s0, weight 1, 00:00:02 | |
538 | * via 192.168.161.7, enp39s0, weight 1, 00:00:02 | |
539 | * via 192.168.161.8, enp39s0, weight 1, 00:00:02 | |
540 | * via 192.168.161.9, enp39s0, weight 1, 00:00:02 | |
541 | * via 192.168.161.10, enp39s0, weight 1, 00:00:02 | |
542 | * via 192.168.161.11, enp39s0, weight 1, 00:00:02 | |
543 | * via 192.168.161.12, enp39s0, weight 1, 00:00:02 | |
544 | * via 192.168.161.13, enp39s0, weight 1, 00:00:02 | |
545 | * via 192.168.161.14, enp39s0, weight 1, 00:00:02 | |
546 | * via 192.168.161.15, enp39s0, weight 1, 00:00:02 | |
547 | * via 192.168.161.16, enp39s0, weight 1, 00:00:02 | |
548 | ||
549 | In this example we have 16 way ecmp for the 4.4.4.4/32 route. The ``*`` character | |
550 | tells us that the route is installed in the Data Plane, or FIB. | |
551 | ||
552 | If you are using the Linux kernel as a Data Plane, this can be inspected | |
553 | via a ``ip route show X`` command: | |
554 | ||
555 | .. code-block:: shell | |
556 | ||
557 | sharpd@eva ~/f/doc(ecmp_doc_change)> ip route show 4.4.4.4/32 | |
558 | 4.4.4.4 nhid 185483868 proto sharp metric 20 | |
559 | nexthop via 192.168.161.1 dev enp39s0 weight 1 | |
560 | nexthop via 192.168.161.10 dev enp39s0 weight 1 | |
561 | nexthop via 192.168.161.11 dev enp39s0 weight 1 | |
562 | nexthop via 192.168.161.12 dev enp39s0 weight 1 | |
563 | nexthop via 192.168.161.13 dev enp39s0 weight 1 | |
564 | nexthop via 192.168.161.14 dev enp39s0 weight 1 | |
565 | nexthop via 192.168.161.15 dev enp39s0 weight 1 | |
566 | nexthop via 192.168.161.16 dev enp39s0 weight 1 | |
567 | nexthop via 192.168.161.2 dev enp39s0 weight 1 | |
568 | nexthop via 192.168.161.3 dev enp39s0 weight 1 | |
569 | nexthop via 192.168.161.4 dev enp39s0 weight 1 | |
570 | nexthop via 192.168.161.5 dev enp39s0 weight 1 | |
571 | nexthop via 192.168.161.6 dev enp39s0 weight 1 | |
572 | nexthop via 192.168.161.7 dev enp39s0 weight 1 | |
573 | nexthop via 192.168.161.8 dev enp39s0 weight 1 | |
574 | nexthop via 192.168.161.9 dev enp39s0 weight 1 | |
575 | ||
576 | Once installed into the FIB, FRR currently has little control over what | |
577 | nexthops are chosen to forward packets on. Currently the Linux kernel | |
578 | has a ``fib_multipath_hash_policy`` sysctl which dictates how the hashing | |
579 | algorithm is used to forward packets. | |
580 | ||
581 | .. _zebra-mpls: | |
582 | ||
583 | MPLS Commands | |
584 | ============= | |
585 | ||
586 | You can configure static mpls entries in zebra. Basically, handling MPLS | |
587 | consists of popping, swapping or pushing labels to IP packets. | |
588 | ||
589 | MPLS Acronyms | |
590 | ------------- | |
591 | ||
592 | :abbr:`LSR (Labeled Switch Router)` | |
593 | Networking devices handling labels used to forward traffic between and through | |
594 | them. | |
595 | ||
596 | :abbr:`LER (Labeled Edge Router)` | |
597 | A Labeled edge router is located at the edge of an MPLS network, generally | |
598 | between an IP network and an MPLS network. | |
599 | ||
600 | MPLS Push Action | |
601 | ---------------- | |
602 | ||
603 | The push action is generally used for LER devices, which want to encapsulate | |
604 | all traffic for a wished destination into an MPLS label. This action is stored | |
605 | in routing entry, and can be configured like a route: | |
606 | ||
607 | .. clicmd:: ip route NETWORK MASK GATEWAY|INTERFACE label LABEL | |
608 | ||
609 | NETWORK and MASK stand for the IP prefix entry to be added as static | |
610 | route entry. | |
611 | GATEWAY is the gateway IP address to reach, in order to reach the prefix. | |
612 | INTERFACE is the interface behind which the prefix is located. | |
613 | LABEL is the MPLS label to use to reach the prefix abovementioned. | |
614 | ||
615 | You can check that the static entry is stored in the zebra RIB database, by | |
616 | looking at the presence of the entry. | |
617 | ||
618 | :: | |
619 | ||
620 | zebra(configure)# ip route 1.1.1.1/32 10.0.1.1 label 777 | |
621 | zebra# show ip route | |
622 | Codes: K - kernel route, C - connected, S - static, R - RIP, | |
623 | O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, | |
624 | T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, | |
625 | F - PBR, | |
626 | > - selected route, * - FIB route | |
627 | ||
628 | S>* 1.1.1.1/32 [1/0] via 10.0.1.1, r2-eth0, label 777, 00:39:42 | |
629 | ||
630 | MPLS Swap and Pop Action | |
631 | ------------------------ | |
632 | ||
633 | The swap action is generally used for LSR devices, which swap a packet with a | |
634 | label, with an other label. The Pop action is used on LER devices, at the | |
635 | termination of the MPLS traffic; this is used to remove MPLS header. | |
636 | ||
637 | .. clicmd:: mpls lsp INCOMING_LABEL GATEWAY OUTGOING_LABEL|explicit-null|implicit-null | |
638 | ||
639 | INCOMING_LABEL and OUTGOING_LABEL are MPLS labels with values ranging from 16 | |
640 | to 1048575. | |
641 | GATEWAY is the gateway IP address where to send MPLS packet. | |
642 | The outgoing label can either be a value or have an explicit-null label header. This | |
643 | specific header can be read by IP devices. The incoming label can also be removed; in | |
644 | that case the implicit-null keyword is used, and the outgoing packet emitted is an IP | |
645 | packet without MPLS header. | |
646 | ||
647 | You can check that the MPLS actions are stored in the zebra MPLS table, by looking at the | |
648 | presence of the entry. | |
649 | ||
650 | .. clicmd:: show mpls table | |
651 | ||
652 | :: | |
653 | ||
654 | zebra(configure)# mpls lsp 18 10.125.0.2 implicit-null | |
655 | zebra(configure)# mpls lsp 19 10.125.0.2 20 | |
656 | zebra(configure)# mpls lsp 21 10.125.0.2 explicit-null | |
657 | zebra# show mpls table | |
658 | Inbound Outbound | |
659 | Label Type Nexthop Label | |
660 | -------- ------- --------------- -------- | |
661 | 18 Static 10.125.0.2 implicit-null | |
662 | 19 Static 10.125.0.2 20 | |
663 | 21 Static 10.125.0.2 IPv4 Explicit Null | |
664 | ||
665 | ||
666 | .. _zebra-srv6: | |
667 | ||
668 | Segment-Routing IPv6 | |
669 | ==================== | |
670 | ||
671 | Segment-Routing is source routing paradigm that allows | |
672 | network operator to encode network intent into the packets. | |
673 | SRv6 is an implementation of Segment-Routing | |
674 | with application of IPv6 and segment-routing-header. | |
675 | ||
676 | All routing daemon can use the Segment-Routing base | |
677 | framework implemented on zebra to use SRv6 routing mechanism. | |
678 | In that case, user must configure initial srv6 setting on | |
679 | FRR's cli or frr.conf or zebra.conf. This section shows how | |
680 | to configure SRv6 on FRR. Of course SRv6 can be used as standalone, | |
681 | and this section also helps that case. | |
682 | ||
683 | .. clicmd:: show segment-routing srv6 locator [json] | |
684 | ||
685 | This command dump SRv6-locator configured on zebra. SRv6-locator is used | |
686 | to route to the node before performing the SRv6-function. and that works as | |
687 | aggregation of SRv6-function's IDs. Following console log shows two | |
688 | SRv6-locators loc1 and loc2. All locators are identified by unique IPv6 | |
689 | prefix. User can get that information as JSON string when ``json`` key word | |
690 | at the end of cli is presented. | |
691 | ||
692 | :: | |
693 | ||
694 | router# sh segment-routing srv6 locator | |
695 | Locator: | |
696 | Name ID Prefix Status | |
697 | -------------------- ------- ------------------------ ------- | |
698 | loc1 1 2001:db8:1:1::/64 Up | |
699 | loc2 2 2001:db8:2:2::/64 Up | |
700 | ||
701 | .. clicmd:: show segment-routing srv6 locator NAME detail [json] | |
702 | ||
703 | As shown in the example, by specifying the name of the locator, you | |
704 | can see the detailed information for each locator. Locator can be | |
705 | represented by a single IPv6 prefix, but SRv6 is designed to share this | |
706 | Locator among multiple Routing Protocols. For this purpose, zebra divides | |
707 | the IPv6 prefix block that makes the Locator unique into multiple chunks, | |
708 | and manages the ownership of each chunk. | |
709 | ||
710 | For example, loc1 has system as its owner. For example, loc1 is owned by | |
711 | system, which means that it is not yet proprietary to any routing protocol. | |
712 | For example, loc2 has sharp as its owner. This means that the shaprd for | |
713 | function development holds the owner of the chunk of this locator, and no | |
714 | other routing protocol will use this area. | |
715 | ||
716 | :: | |
717 | ||
718 | router# show segment-routing srv6 locator loc1 detail | |
719 | Name: loc1 | |
720 | Prefix: 2001:db8:1:1::/64 | |
721 | Chunks: | |
722 | - prefix: 2001:db8:1:1::/64, owner: system | |
723 | ||
724 | router# show segment-routing srv6 locator loc2 detail | |
725 | Name: loc2 | |
726 | Prefix: 2001:db8:2:2::/64 | |
727 | Chunks: | |
728 | - prefix: 2001:db8:2:2::/64, owner: sharp | |
729 | ||
730 | .. clicmd:: segment-routing | |
731 | ||
732 | Move from configure mode to segment-routing node. | |
733 | ||
734 | .. clicmd:: srv6 | |
735 | ||
736 | Move from segment-routing node to srv6 node. | |
737 | ||
738 | .. clicmd:: locators | |
739 | ||
740 | Move from srv6 node to locator node. In this locator node, user can | |
741 | configure detailed settings such as the actual srv6 locator. | |
742 | ||
743 | .. clicmd:: locator NAME | |
744 | ||
745 | Create a new locator. If the name of an existing locator is specified, | |
746 | move to specified locator's configuration node to change the settings it. | |
747 | ||
748 | .. clicmd:: prefix X:X::X:X/M [func-bits 32] | |
749 | ||
750 | Set the ipv6 prefix block of the locator. SRv6 locator is defined by | |
751 | RFC8986. The actual routing protocol specifies the locator and allocates a | |
752 | SID to be used by each routing protocol. This SID is included in the locator | |
753 | as an IPv6 prefix. | |
754 | ||
755 | Following example console log shows the typical configuration of SRv6 | |
756 | data-plane. After a new SRv6 locator, named loc1, is created, loc1's prefix | |
757 | is configured as ``2001:db8:1:1::/64``. If user or some routing daemon | |
758 | allocates new SID on this locator, new SID will allocated in range of this | |
759 | prefix. For example, if some routing daemon creates new SID on locator | |
760 | (``2001:db8:1:1::/64``), Then new SID will be ``2001:db8:1:1:7::/80``, | |
761 | ``2001:db8:1:1:8::/80``, and so on. Each locator has default SID that is | |
762 | SRv6 local function "End". Usually default SID is allocated as | |
763 | ``PREFIX:1::``. (``PREFIX`` is locator's prefix) For example, if user | |
764 | configure the locator's prefix as ``2001:db8:1:1::/64``, then default SID | |
765 | will be ``2001:db8:1:1:1::``) | |
766 | ||
767 | The function bits range is 16bits by default. If operator want to change | |
768 | function bits range, they can configure with ``func-bits`` | |
769 | option. | |
770 | ||
771 | :: | |
772 | ||
773 | router# configure terminal | |
774 | router(config)# segment-routinig | |
775 | router(config-sr)# srv6 | |
776 | router(config-srv6)# locators | |
777 | router(config-srv6-locs)# locator loc1 | |
778 | router(config-srv6-loc)# prefix 2001:db8:1:1::/64 | |
779 | ||
780 | router(config-srv6-loc)# show run | |
781 | ... | |
782 | segment-routing | |
783 | srv6 | |
784 | locators | |
785 | locator loc1 | |
786 | prefix 2001:db8:1:1::/64 | |
787 | ! | |
788 | ... | |
789 | ||
790 | .. _multicast-rib-commands: | |
791 | ||
792 | Multicast RIB Commands | |
793 | ====================== | |
794 | ||
795 | The Multicast RIB provides a separate table of unicast destinations which | |
796 | is used for Multicast Reverse Path Forwarding decisions. It is used with | |
797 | a multicast source's IP address, hence contains not multicast group | |
798 | addresses but unicast addresses. | |
799 | ||
800 | This table is fully separate from the default unicast table. However, | |
801 | RPF lookup can include the unicast table. | |
802 | ||
803 | WARNING: RPF lookup results are non-responsive in this version of FRR, | |
804 | i.e. multicast routing does not actively react to changes in underlying | |
805 | unicast topology! | |
806 | ||
807 | .. clicmd:: ip multicast rpf-lookup-mode MODE | |
808 | ||
809 | ||
810 | MODE sets the method used to perform RPF lookups. Supported modes: | |
811 | ||
812 | urib-only | |
813 | Performs the lookup on the Unicast RIB. The Multicast RIB is never used. | |
814 | ||
815 | mrib-only | |
816 | Performs the lookup on the Multicast RIB. The Unicast RIB is never used. | |
817 | ||
818 | mrib-then-urib | |
819 | Tries to perform the lookup on the Multicast RIB. If any route is found, | |
820 | that route is used. Otherwise, the Unicast RIB is tried. | |
821 | ||
822 | lower-distance | |
823 | Performs a lookup on the Multicast RIB and Unicast RIB each. The result | |
824 | with the lower administrative distance is used; if they're equal, the | |
825 | Multicast RIB takes precedence. | |
826 | ||
827 | longer-prefix | |
828 | Performs a lookup on the Multicast RIB and Unicast RIB each. The result | |
829 | with the longer prefix length is used; if they're equal, the | |
830 | Multicast RIB takes precedence. | |
831 | ||
832 | The ``mrib-then-urib`` setting is the default behavior if nothing is | |
833 | configured. If this is the desired behavior, it should be explicitly | |
834 | configured to make the configuration immune against possible changes in | |
835 | what the default behavior is. | |
836 | ||
837 | .. warning:: | |
838 | ||
839 | Unreachable routes do not receive special treatment and do not cause | |
840 | fallback to a second lookup. | |
841 | ||
842 | .. clicmd:: show ip rpf ADDR | |
843 | ||
844 | Performs a Multicast RPF lookup, as configured with ``ip multicast | |
845 | rpf-lookup-mode MODE``. ADDR specifies the multicast source address to look | |
846 | up. | |
847 | ||
848 | :: | |
849 | ||
850 | > show ip rpf 192.0.2.1 | |
851 | Routing entry for 192.0.2.0/24 using Unicast RIB | |
852 | ||
853 | Known via "kernel", distance 0, metric 0, best | |
854 | * 198.51.100.1, via eth0 | |
855 | ||
856 | ||
857 | Indicates that a multicast source lookup for 192.0.2.1 would use an | |
858 | Unicast RIB entry for 192.0.2.0/24 with a gateway of 198.51.100.1. | |
859 | ||
860 | .. clicmd:: show ip rpf | |
861 | ||
862 | Prints the entire Multicast RIB. Note that this is independent of the | |
863 | configured RPF lookup mode, the Multicast RIB may be printed yet not | |
864 | used at all. | |
865 | ||
866 | .. clicmd:: ip mroute PREFIX NEXTHOP [DISTANCE] | |
867 | ||
868 | ||
869 | Adds a static route entry to the Multicast RIB. This performs exactly as the | |
870 | ``ip route`` command, except that it inserts the route in the Multicast RIB | |
871 | instead of the Unicast RIB. | |
872 | ||
873 | .. _zebra-route-filtering: | |
874 | ||
875 | zebra Route Filtering | |
876 | ===================== | |
877 | ||
878 | Zebra supports :dfn:`prefix-list` s and :ref:`route-map` s to match routes | |
879 | received from other FRR components. The permit/deny facilities provided by | |
880 | these commands can be used to filter which routes zebra will install in the | |
881 | kernel. | |
882 | ||
883 | .. clicmd:: ip protocol PROTOCOL route-map ROUTEMAP | |
884 | ||
885 | Apply a route-map filter to routes for the specified protocol. PROTOCOL can | |
886 | be: | |
887 | ||
888 | - any, | |
889 | - babel, | |
890 | - bgp, | |
891 | - connected, | |
892 | - eigrp, | |
893 | - isis, | |
894 | - kernel, | |
895 | - nhrp, | |
896 | - openfabric, | |
897 | - ospf, | |
898 | - ospf6, | |
899 | - rip, | |
900 | - sharp, | |
901 | - static, | |
902 | - ripng, | |
903 | - table, | |
904 | - vnc. | |
905 | ||
906 | If you choose any as the option that will cause all protocols that are sending | |
907 | routes to zebra. You can specify a :dfn:`ip protocol PROTOCOL route-map ROUTEMAP` | |
908 | on a per vrf basis, by entering this command under vrf mode for the vrf you | |
909 | want to apply the route-map against. | |
910 | ||
911 | .. clicmd:: set src ADDRESS | |
912 | ||
913 | Within a route-map, set the preferred source address for matching routes | |
914 | when installing in the kernel. | |
915 | ||
916 | ||
917 | The following creates a prefix-list that matches all addresses, a route-map | |
918 | that sets the preferred source address, and applies the route-map to all | |
919 | *rip* routes. | |
920 | ||
921 | .. code-block:: frr | |
922 | ||
923 | ip prefix-list ANY permit 0.0.0.0/0 le 32 | |
924 | route-map RM1 permit 10 | |
925 | match ip address prefix-list ANY | |
926 | set src 10.0.0.1 | |
927 | ||
928 | ip protocol rip route-map RM1 | |
929 | ||
930 | IPv6 example for OSPFv3. | |
931 | ||
932 | .. code-block:: frr | |
933 | ||
934 | ipv6 prefix-list ANY seq 10 permit any | |
935 | route-map RM6 permit 10 | |
936 | match ipv6 address prefix-list ANY | |
937 | set src 2001:db8:425:1000::3 | |
938 | ||
939 | ipv6 protocol ospf6 route-map RM6 | |
940 | ||
941 | ||
942 | .. note:: | |
943 | ||
944 | For both IPv4 and IPv6, the IP address has to exist on some interface when | |
945 | the route is getting installed into the system. Otherwise, kernel rejects | |
946 | the route. To solve the problem of disappearing IPv6 addresses when the | |
947 | interface goes down, use ``net.ipv6.conf.all.keep_addr_on_down`` | |
948 | :ref:`sysctl option <zebra-sysctl>`. | |
949 | ||
950 | .. clicmd:: zebra route-map delay-timer (0-600) | |
951 | ||
952 | Set the delay before any route-maps are processed in zebra. The | |
953 | default time for this is 5 seconds. | |
954 | ||
955 | .. _zebra-fib-push-interface: | |
956 | ||
957 | zebra FIB push interface | |
958 | ======================== | |
959 | ||
960 | Zebra supports a 'FIB push' interface that allows an external | |
961 | component to learn the forwarding information computed by the FRR | |
962 | routing suite. This is a loadable module that needs to be enabled | |
963 | at startup as described in :ref:`loadable-module-support`. | |
964 | ||
965 | In FRR, the Routing Information Base (RIB) resides inside | |
966 | zebra. Routing protocols communicate their best routes to zebra, and | |
967 | zebra computes the best route across protocols for each prefix. This | |
968 | latter information makes up the Forwarding Information Base | |
969 | (FIB). Zebra feeds the FIB to the kernel, which allows the IP stack in | |
970 | the kernel to forward packets according to the routes computed by | |
971 | FRR. The kernel FIB is updated in an OS-specific way. For example, | |
972 | the ``Netlink`` interface is used on Linux, and route sockets are | |
973 | used on FreeBSD. | |
974 | ||
975 | The FIB push interface aims to provide a cross-platform mechanism to | |
976 | support scenarios where the router has a forwarding path that is | |
977 | distinct from the kernel, commonly a hardware-based fast path. In | |
978 | these cases, the FIB needs to be maintained reliably in the fast path | |
979 | as well. We refer to the component that programs the forwarding plane | |
980 | (directly or indirectly) as the Forwarding Plane Manager or FPM. | |
981 | ||
982 | .. program:: configure | |
983 | ||
984 | The relevant zebra code kicks in when zebra is configured with the | |
985 | :option:`--enable-fpm` flag and started with the module (``-M fpm`` | |
986 | or ``-M dplane_fpm_nl``). | |
987 | ||
988 | .. note:: | |
989 | ||
990 | The ``fpm`` implementation attempts to connect to ``127.0.0.1`` port ``2620`` | |
991 | by default without configurations. The ``dplane_fpm_nl`` only attempts to | |
992 | connect to a server if configured. | |
993 | ||
994 | Zebra periodically attempts to connect to the well-known FPM port (``2620``). | |
995 | Once the connection is up, zebra starts sending messages containing routes | |
996 | over the socket to the FPM. Zebra sends a complete copy of the forwarding | |
997 | table to the FPM, including routes that it may have picked up from the kernel. | |
998 | The existing interaction of zebra with the kernel remains unchanged -- that | |
999 | is, the kernel continues to receive FIB updates as before. | |
1000 | ||
1001 | The default FPM message format is netlink, however it can be controlled | |
1002 | with the module load-time option. The modules accept the following options: | |
1003 | ||
1004 | - ``fpm``: ``netlink`` and ``protobuf``. | |
1005 | - ``dplane_fpm_nl``: none, it only implements netlink. | |
1006 | ||
1007 | The zebra FPM interface uses replace semantics. That is, if a 'route | |
1008 | add' message for a prefix is followed by another 'route add' message, | |
1009 | the information in the second message is complete by itself, and | |
1010 | replaces the information sent in the first message. | |
1011 | ||
1012 | If the connection to the FPM goes down for some reason, zebra sends | |
1013 | the FPM a complete copy of the forwarding table(s) when it reconnects. | |
1014 | ||
1015 | For more details on the implementation, please read the developer's manual FPM | |
1016 | section. | |
1017 | ||
1018 | FPM Commands | |
1019 | ============ | |
1020 | ||
1021 | ``fpm`` implementation | |
1022 | ---------------------- | |
1023 | ||
1024 | .. clicmd:: fpm connection ip A.B.C.D port (1-65535) | |
1025 | ||
1026 | Configure ``zebra`` to connect to a different FPM server than the default of | |
1027 | ``127.0.0.1:2060`` | |
1028 | ||
1029 | .. clicmd:: show zebra fpm stats | |
1030 | ||
1031 | Shows the FPM statistics. | |
1032 | ||
1033 | Sample output: | |
1034 | ||
1035 | :: | |
1036 | ||
1037 | Counter Total Last 10 secs | |
1038 | ||
1039 | connect_calls 3 2 | |
1040 | connect_no_sock 0 0 | |
1041 | read_cb_calls 2 2 | |
1042 | write_cb_calls 2 0 | |
1043 | write_calls 1 0 | |
1044 | partial_writes 0 0 | |
1045 | max_writes_hit 0 0 | |
1046 | t_write_yields 0 0 | |
1047 | nop_deletes_skipped 6 0 | |
1048 | route_adds 5 0 | |
1049 | route_dels 0 0 | |
1050 | updates_triggered 11 0 | |
1051 | redundant_triggers 0 0 | |
1052 | dests_del_after_update 0 0 | |
1053 | t_conn_down_starts 0 0 | |
1054 | t_conn_down_dests_processed 0 0 | |
1055 | t_conn_down_yields 0 0 | |
1056 | t_conn_down_finishes 0 0 | |
1057 | t_conn_up_starts 1 0 | |
1058 | t_conn_up_dests_processed 11 0 | |
1059 | t_conn_up_yields 0 0 | |
1060 | t_conn_up_aborts 0 0 | |
1061 | t_conn_up_finishes 1 0 | |
1062 | ||
1063 | ||
1064 | .. clicmd:: clear zebra fpm stats | |
1065 | ||
1066 | Reset statistics related to the zebra code that interacts with the | |
1067 | optional Forwarding Plane Manager (FPM) component. | |
1068 | ||
1069 | ||
1070 | ``dplane_fpm_nl`` implementation | |
1071 | -------------------------------- | |
1072 | ||
1073 | .. clicmd:: fpm address <A.B.C.D|X:X::X:X> [port (1-65535)] | |
1074 | ||
1075 | Configures the FPM server address. Once configured ``zebra`` will attempt | |
1076 | to connect to it immediately. | |
1077 | ||
1078 | The ``no`` form disables FPM entirely. ``zebra`` will close any current | |
1079 | connections and will not attempt to connect to it anymore. | |
1080 | ||
1081 | .. clicmd:: fpm use-next-hop-groups | |
1082 | ||
1083 | Use the new netlink messages ``RTM_NEWNEXTHOP`` / ``RTM_DELNEXTHOP`` to | |
1084 | group repeated route next hop information. | |
1085 | ||
1086 | The ``no`` form uses the old known FPM behavior of including next hop | |
1087 | information in the route (e.g. ``RTM_NEWROUTE``) messages. | |
1088 | ||
1089 | .. clicmd:: show fpm counters [json] | |
1090 | ||
1091 | Show the FPM statistics (plain text or JSON formatted). | |
1092 | ||
1093 | Sample output: | |
1094 | ||
1095 | :: | |
1096 | ||
1097 | FPM counters | |
1098 | ============ | |
1099 | Input bytes: 0 | |
1100 | Output bytes: 308 | |
1101 | Output buffer current size: 0 | |
1102 | Output buffer peak size: 308 | |
1103 | Connection closes: 0 | |
1104 | Connection errors: 0 | |
1105 | Data plane items processed: 0 | |
1106 | Data plane items enqueued: 0 | |
1107 | Data plane items queue peak: 0 | |
1108 | Buffer full hits: 0 | |
1109 | User FPM configurations: 1 | |
1110 | User FPM disable requests: 0 | |
1111 | ||
1112 | ||
1113 | .. clicmd:: clear fpm counters | |
1114 | ||
1115 | Reset statistics related to the zebra code that interacts with the | |
1116 | optional Forwarding Plane Manager (FPM) component. | |
1117 | ||
1118 | ||
1119 | .. _zebra-dplane: | |
1120 | ||
1121 | Dataplane Commands | |
1122 | ================== | |
1123 | ||
1124 | The zebra dataplane subsystem provides a framework for FIB | |
1125 | programming. Zebra uses the dataplane to program the local kernel as | |
1126 | it makes changes to objects such as IP routes, MPLS LSPs, and | |
1127 | interface IP addresses. The dataplane runs in its own pthread, in | |
1128 | order to off-load work from the main zebra pthread. | |
1129 | ||
1130 | ||
1131 | .. clicmd:: show zebra dplane [detailed] | |
1132 | ||
1133 | Display statistics about the updates and events passing through the | |
1134 | dataplane subsystem. | |
1135 | ||
1136 | ||
1137 | .. clicmd:: show zebra dplane providers | |
1138 | ||
1139 | Display information about the running dataplane plugins that are | |
1140 | providing updates to a FIB. By default, the local kernel plugin is | |
1141 | present. | |
1142 | ||
1143 | ||
1144 | .. clicmd:: zebra dplane limit [NUMBER] | |
1145 | ||
1146 | Configure the limit on the number of pending updates that are | |
1147 | waiting to be processed by the dataplane pthread. | |
1148 | ||
1149 | ||
1150 | DPDK dataplane | |
1151 | ============== | |
1152 | ||
1153 | The zebra DPDK subsystem programs the dataplane via rte_XXX APIs. | |
1154 | This module needs be compiled in via "--enable-dp-dpdk=yes" | |
1155 | and enabled at start up time via the zebra daemon option "-M dplane_dpdk". | |
1156 | ||
1157 | To program the PBR rules as rte_flows you additionally need to configure | |
1158 | "pbr nexthop-resolve". This is used to expland the PBR actions into the | |
1159 | {SMAC, DMAC, outgoing port} needed by rte_flow. | |
1160 | ||
1161 | ||
1162 | .. clicmd:: show dplane dpdk port [detail] | |
1163 | ||
1164 | Displays the mapping table between zebra interfaces and DPDK port-ids. | |
1165 | Sample output: | |
1166 | ||
1167 | :: | |
1168 | Port Device IfName IfIndex sw,domain,port | |
1169 | ||
1170 | 0 0000:03:00.0 p0 4 0000:03:00.0,0,65535 | |
1171 | 1 0000:03:00.0 pf0hpf 6 0000:03:00.0,0,4095 | |
1172 | 2 0000:03:00.0 pf0vf0 15 0000:03:00.0,0,4096 | |
1173 | 3 0000:03:00.0 pf0vf1 16 0000:03:00.0,0,4097 | |
1174 | 4 0000:03:00.1 p1 5 0000:03:00.1,1,65535 | |
1175 | 5 0000:03:00.1 pf1hpf 7 0000:03:00.1,1,20479 | |
1176 | ||
1177 | .. clicmd:: show dplane dpdk pbr flows | |
1178 | Displays the DPDK stats per-PBR entry. | |
1179 | Sample output: | |
1180 | ||
1181 | :: | |
1182 | Rules if pf0vf0 | |
1183 | Seq 1 pri 300 | |
1184 | SRC Match 77.0.0.8/32 | |
1185 | DST Match 88.0.0.8/32 | |
1186 | Tableid: 10000 | |
1187 | Action: nh: 45.0.0.250 intf: p0 | |
1188 | Action: mac: 00:00:5e:00:01:fa | |
1189 | DPDK flow: installed 0x40 | |
1190 | DPDK flow stats: packets 13 bytes 1586 | |
1191 | ||
1192 | .. clicmd:: show dplane dpdk counters | |
1193 | Displays the ZAPI message handler counters | |
1194 | ||
1195 | Sample output: | |
1196 | ||
1197 | :: | |
1198 | Ignored updates: 0 | |
1199 | PBR rule adds: 1 | |
1200 | PBR rule dels: 0 | |
1201 | ||
1202 | ||
1203 | zebra Terminal Mode Commands | |
1204 | ============================ | |
1205 | ||
1206 | .. clicmd:: show ip route | |
1207 | ||
1208 | Display current routes which zebra holds in its database. | |
1209 | ||
1210 | :: | |
1211 | ||
1212 | Router# show ip route | |
1213 | Codes: K - kernel route, C - connected, S - static, R - RIP, | |
1214 | B - BGP * - FIB route. | |
1215 | ||
1216 | K* 0.0.0.0/0 203.181.89.241 | |
1217 | S 0.0.0.0/0 203.181.89.1 | |
1218 | C* 127.0.0.0/8 lo | |
1219 | C* 203.181.89.240/28 eth0 | |
1220 | ||
1221 | ||
1222 | .. clicmd:: show ipv6 route | |
1223 | ||
1224 | .. clicmd:: show [ip|ipv6] route [PREFIX] [nexthop-group] | |
1225 | ||
1226 | Display detailed information about a route. If [nexthop-group] is | |
1227 | included, it will display the nexthop group ID the route is using as well. | |
1228 | ||
1229 | .. clicmd:: show interface [NAME] [{vrf VRF|brief}] [json] | |
1230 | ||
1231 | .. clicmd:: show interface [NAME] [{vrf all|brief}] [json] | |
1232 | ||
1233 | .. clicmd:: show interface [NAME] [{vrf VRF|brief}] [nexthop-group] | |
1234 | ||
1235 | .. clicmd:: show interface [NAME] [{vrf all|brief}] [nexthop-group] | |
1236 | ||
1237 | Display interface information. If no extra information is added, it will | |
1238 | dump information on all interfaces. If [NAME] is specified, it will display | |
1239 | detailed information about that single interface. If [nexthop-group] is | |
1240 | specified, it will display nexthop groups pointing out that interface. | |
1241 | ||
1242 | If the ``json`` option is specified, output is displayed in JSON format. | |
1243 | ||
1244 | .. clicmd:: show ip prefix-list [NAME] | |
1245 | ||
1246 | .. clicmd:: show route-map [NAME] | |
1247 | ||
1248 | .. clicmd:: show ip protocol | |
1249 | ||
1250 | .. clicmd:: show ip forward | |
1251 | ||
1252 | Display whether the host's IP forwarding function is enabled or not. | |
1253 | Almost any UNIX kernel can be configured with IP forwarding disabled. | |
1254 | If so, the box can't work as a router. | |
1255 | ||
1256 | .. clicmd:: show ipv6 forward | |
1257 | ||
1258 | Display whether the host's IP v6 forwarding is enabled or not. | |
1259 | ||
1260 | .. clicmd:: show ip neigh | |
1261 | ||
1262 | Display the ip neighbor table | |
1263 | ||
1264 | .. clicmd:: show pbr rule | |
1265 | ||
1266 | Display the pbr rule table with resolved nexthops | |
1267 | ||
1268 | .. clicmd:: show zebra | |
1269 | ||
1270 | Display various statistics related to the installation and deletion | |
1271 | of routes, neighbor updates, and LSP's into the kernel. In addition | |
1272 | show various zebra state that is useful when debugging an operator's | |
1273 | setup. | |
1274 | ||
1275 | .. clicmd:: show zebra client [summary] | |
1276 | ||
1277 | Display statistics about clients that are connected to zebra. This is | |
1278 | useful for debugging and seeing how much data is being passed between | |
1279 | zebra and it's clients. If the summary form of the command is chosen | |
1280 | a table is displayed with shortened information. | |
1281 | ||
1282 | .. clicmd:: show zebra router table summary | |
1283 | ||
1284 | Display summarized data about tables created, their afi/safi/tableid | |
1285 | and how many routes each table contains. Please note this is the | |
1286 | total number of route nodes in the table. Which will be higher than | |
1287 | the actual number of routes that are held. | |
1288 | ||
1289 | .. clicmd:: show nexthop-group rib [ID] [vrf NAME] [singleton [ip|ip6]] [type] | |
1290 | ||
1291 | Display nexthop groups created by zebra. The [vrf NAME] option | |
1292 | is only meaningful if you have started zebra with the --vrfwnetns | |
1293 | option as that nexthop groups are per namespace in linux. | |
1294 | If you specify singleton you would like to see the singleton | |
1295 | nexthop groups that do have an afi. [type] allows you to filter those | |
1296 | only coming from a specific NHG type (protocol). | |
1297 | ||
1298 | .. clicmd:: show <ip|ipv6> zebra route dump [<vrf> VRFNAME] | |
1299 | ||
1300 | It dumps all the routes from RIB with detailed information including | |
1301 | internal flags, status etc. This is defined as a hidden command. | |
1302 | ||
1303 | ||
1304 | Router-id | |
1305 | ========= | |
1306 | ||
1307 | Many routing protocols require a router-id to be configured. To have a | |
1308 | consistent router-id across all daemons, the following commands are available | |
1309 | to configure and display the router-id: | |
1310 | ||
1311 | .. clicmd:: [ip] router-id A.B.C.D | |
1312 | ||
1313 | Allow entering of the router-id. This command also works under the | |
1314 | vrf subnode, to allow router-id's per vrf. | |
1315 | ||
1316 | .. clicmd:: [ip] router-id A.B.C.D vrf NAME | |
1317 | ||
1318 | Configure the router-id of this router from the configure NODE. | |
1319 | A show run of this command will display the router-id command | |
1320 | under the vrf sub node. This command is deprecated and will | |
1321 | be removed at some point in time in the future. | |
1322 | ||
1323 | .. clicmd:: show [ip] router-id [vrf NAME] | |
1324 | ||
1325 | Display the user configured router-id. | |
1326 | ||
1327 | For protocols requiring an IPv6 router-id, the following commands are available: | |
1328 | ||
1329 | .. clicmd:: ipv6 router-id X:X::X:X | |
1330 | ||
1331 | Configure the IPv6 router-id of this router. Like its IPv4 counterpart, | |
1332 | this command works under the vrf subnode, to allow router-id's per vrf. | |
1333 | ||
1334 | .. clicmd:: show ipv6 router-id [vrf NAME] | |
1335 | ||
1336 | Display the user configured IPv6 router-id. | |
1337 | ||
1338 | .. _zebra-sysctl: | |
1339 | ||
1340 | sysctl settings | |
1341 | =============== | |
1342 | ||
1343 | The linux kernel has a variety of sysctl's that affect it's operation as a router. This | |
1344 | section is meant to act as a starting point for those sysctl's that must be used in | |
1345 | order to provide FRR with smooth operation as a router. This section is not meant | |
1346 | as the full documentation for sysctl's. The operator must use the sysctl documentation | |
1347 | with the linux kernel for that. The following link has helpful references to many relevant | |
1348 | sysctl values: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt | |
1349 | ||
1350 | Expected sysctl settings | |
1351 | ------------------------ | |
1352 | ||
1353 | .. option:: net.ipv4.ip_forward = 1 | |
1354 | ||
1355 | This global option allows the linux kernel to forward (route) ipv4 packets incoming from one | |
1356 | interface to an outgoing interface. If this is set to 0, the system will not route transit | |
1357 | ipv4 packets, i.e. packets that are not sent to/from a process running on the local system. | |
1358 | ||
1359 | .. option:: net.ipv4.conf.{all,default,<interface>}.forwarding = 1 | |
1360 | ||
1361 | The linux kernel can selectively enable forwarding (routing) of ipv4 packets on a per | |
1362 | interface basis. The forwarding check in the kernel dataplane occurs against the ingress | |
1363 | Layer 3 interface, i.e. if the ingress L3 interface has forwarding set to 0, packets will not | |
1364 | be routed. | |
1365 | ||
1366 | .. option:: net.ipv6.conf.{all,default,<interface>}.forwarding = 1 | |
1367 | ||
1368 | This per interface option allows the linux kernel to forward (route) transit ipv6 packets | |
1369 | i.e. incoming from one Layer 3 interface to an outgoing Layer 3 interface. | |
1370 | The forwarding check in the kernel dataplane occurs against the ingress Layer 3 interface, | |
1371 | i.e. if the ingress L3 interface has forwarding set to 0, packets will not be routed. | |
1372 | ||
1373 | .. option:: net.ipv6.conf.all.keep_addr_on_down = 1 | |
1374 | ||
1375 | When an interface is taken down, do not remove the v6 addresses associated with the interface. | |
1376 | This option is recommended because this is the default behavior for v4 as well. | |
1377 | ||
1378 | .. option:: net.ipv6.route.skip_notify_on_dev_down = 1 | |
1379 | ||
1380 | When an interface is taken down, the linux kernel will not notify, via netlink, about routes | |
1381 | that used that interface being removed from the FIB. This option is recommended because this | |
1382 | is the default behavior for v4 as well. | |
1383 | ||
1384 | Optional sysctl settings | |
1385 | ------------------------ | |
1386 | ||
1387 | .. option:: net.ipv4.conf.{all,default,<interface>}.bc_forwarding = 0 | |
1388 | ||
1389 | This per interface option allows the linux kernel to optionally allow Directed Broadcast | |
1390 | (i.e. Routed Broadcast or Subnet Broadcast) packets to be routed onto the connected network | |
1391 | segment where the subnet exists. | |
1392 | If the local router receives a routed packet destined for a broadcast address of a connected | |
1393 | subnet, setting bc_forwarding to 1 on the interface with the target subnet assigned to it will | |
1394 | allow non locally-generated packets to be routed via the broadcast route. | |
1395 | If bc_forwarding is set to 0, routed packets destined for a broadcast route will be dropped. | |
1396 | e.g. | |
1397 | Host1 (SIP:192.0.2.10, DIP:10.0.0.255) -> (eth0:192.0.2.1/24) Router1 (eth1:10.0.0.1/24) -> BC | |
1398 | If net.ipv4.conf.{all,default,<interface>}.bc_forwarding=1, then Router1 will forward each | |
1399 | packet destined to 10.0.0.255 onto the eth1 interface with a broadcast DMAC (ff:ff:ff:ff:ff:ff). | |
1400 | ||
1401 | .. option:: net.ipv4.conf.{all,default,<interface>}.arp_accept = 1 | |
1402 | ||
1403 | This per interface option allows the linux kernel to optionally skip the creation of ARP | |
1404 | entries upon the receipt of a Gratuitous ARP (GARP) frame carrying an IP that is not already | |
1405 | present in the ARP cache. Setting arp_accept to 0 on an interface will ensure NEW ARP entries | |
1406 | are not created due to the arrival of a GARP frame. | |
1407 | Note: This does not impact how the kernel reacts to GARP frames that carry a "known" IP | |
1408 | (that is already in the ARP cache) -- an existing ARP entry will always be updated | |
1409 | when a GARP for that IP is received. | |
1410 | ||
1411 | .. option:: net.ipv4.conf.{all,default,<interface>}.arp_ignore = 0 | |
1412 | ||
1413 | This per interface option allows the linux kernel to control what conditions must be met in | |
1414 | order for an ARP reply to be sent in response to an ARP request targeting a local IP address. | |
1415 | When arp_ignore is set to 0, the kernel will send ARP replies in response to any ARP Request | |
1416 | with a Target-IP matching a local address. | |
1417 | When arp_ignore is set to 1, the kernel will send ARP replies if the Target-IP in the ARP | |
1418 | Request matches an IP address on the interface the Request arrived at. | |
1419 | When arp_ignore is set to 2, the kernel will send ARP replies only if the Target-IP matches an | |
1420 | IP address on the interface where the Request arrived AND the Sender-IP falls within the subnet | |
1421 | assigned to the local IP/interface. | |
1422 | ||
1423 | .. option:: net.ipv4.conf.{all,default,<interface>}.arp_notify = 1 | |
1424 | ||
1425 | This per interface option allows the linux kernel to decide whether to send a Gratuitious ARP | |
1426 | (GARP) frame when the Layer 3 interface comes UP. | |
1427 | When arp_notify is set to 0, no GARP is sent. | |
1428 | When arp_notify is set to 1, a GARP is sent when the interface comes UP. | |
1429 | ||
1430 | .. option:: net.ipv6.conf.{all,default,<interface>}.ndisc_notify = 1 | |
1431 | ||
1432 | This per interface option allows the linux kernel to decide whether to send an Unsolicited | |
1433 | Neighbor Advertisement (U-NA) frame when the Layer 3 interface comes UP. | |
1434 | When ndisc_notify is set to 0, no U-NA is sent. | |
1435 | When ndisc_notify is set to 1, a U-NA is sent when the interface comes UP. | |
1436 | ||
1437 | Useful sysctl settings | |
1438 | ---------------------- | |
1439 | ||
1440 | .. option:: net.ipv6.conf.all.use_oif_addrs_only = 1 | |
1441 | ||
1442 | When enabled, the candidate source addresses for destinations routed via this interface are | |
1443 | restricted to the set of addresses configured on this interface (RFC 6724 section 4). If | |
1444 | an operator has hundreds of IP addresses per interface this solves the latency problem. | |
1445 | ||
1446 | Debugging | |
1447 | ========= | |
1448 | ||
1449 | .. clicmd:: debug zebra mpls [detailed] | |
1450 | ||
1451 | MPLS-related events and information. | |
1452 | ||
1453 | .. clicmd:: debug zebra events | |
1454 | ||
1455 | Zebra events | |
1456 | ||
1457 | .. clicmd:: debug zebra nht [detailed] | |
1458 | ||
1459 | Nexthop-tracking / reachability information | |
1460 | ||
1461 | .. clicmd:: debug zebra vxlan | |
1462 | ||
1463 | VxLAN (EVPN) events | |
1464 | ||
1465 | .. clicmd:: debug zebra pseudowires | |
1466 | ||
1467 | Pseudowire events. | |
1468 | ||
1469 | .. clicmd:: debug zebra packet [<recv|send>] [detail] | |
1470 | ||
1471 | ZAPI message and packet details | |
1472 | ||
1473 | .. clicmd:: debug zebra kernel | |
1474 | ||
1475 | Kernel / OS events. | |
1476 | ||
1477 | .. clicmd:: debug zebra kernel msgdump [<recv|send>] | |
1478 | ||
1479 | Raw OS (netlink) message details. | |
1480 | ||
1481 | .. clicmd:: debug zebra rib [detailed] | |
1482 | ||
1483 | RIB events. | |
1484 | ||
1485 | .. clicmd:: debug zebra fpm | |
1486 | ||
1487 | FPM (forwarding-plane manager) events. | |
1488 | ||
1489 | .. clicmd:: debug zebra dplane [detailed] | |
1490 | ||
1491 | Dataplane / FIB events. | |
1492 | ||
1493 | .. clicmd:: debug zebra pbr | |
1494 | ||
1495 | PBR (policy-based routing) events. | |
1496 | ||
1497 | .. clicmd:: debug zebra mlag | |
1498 | ||
1499 | MLAG events. | |
1500 | ||
1501 | .. clicmd:: debug zebra evpn mh <es|mac|neigh|nh> | |
1502 | ||
1503 | EVPN multi-hop events. | |
1504 | ||
1505 | .. clicmd:: debug zebra nexthop [detail] | |
1506 | ||
1507 | Nexthop and nexthop-group events. | |
1508 | ||
1509 | Scripting | |
1510 | ========= | |
1511 | ||
1512 | .. clicmd:: zebra on-rib-process script SCRIPT | |
1513 | ||
1514 | Set a Lua script for :ref:`on-rib-process-dplane-results` hook call. | |
1515 | SCRIPT is the basename of the script, without ``.lua``. | |
1516 | ||
1517 | Data structures | |
1518 | --------------- | |
1519 | ||
1520 | .. _const-struct-zebra-dplane-ctx: | |
1521 | ||
1522 | const struct zebra_dplane_ctx | |
1523 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
1524 | ||
1525 | .. code-block:: console | |
1526 | ||
1527 | * integer zd_op | |
1528 | * integer zd_status | |
1529 | * integer zd_provider | |
1530 | * integer zd_vrf_id | |
1531 | * integer zd_table_id | |
1532 | * integer zd_ifname | |
1533 | * integer zd_ifindex | |
1534 | * table rinfo (if zd_op is DPLANE_OP_ROUTE*, DPLANE_NH_*) | |
1535 | ||
1536 | * prefix zd_dest | |
1537 | * prefix zd_src | |
1538 | * integer zd_afi | |
1539 | * integer zd_safi | |
1540 | * integer zd_type | |
1541 | * integer zd_old_type | |
1542 | * integer zd_tag | |
1543 | * integer zd_old_tag | |
1544 | * integer zd_metric | |
1545 | * integer zd_old_metric | |
1546 | * integer zd_instance | |
1547 | * integer zd_old_instance | |
1548 | * integer zd_distance | |
1549 | * integer zd_old_distance | |
1550 | * integer zd_mtu | |
1551 | * integer zd_nexthop_mtu | |
1552 | * table nhe | |
1553 | ||
1554 | * integer id | |
1555 | * integer old_id | |
1556 | * integer afi | |
1557 | * integer vrf_id | |
1558 | * integer type | |
1559 | * nexthop_group ng | |
1560 | * nh_grp | |
1561 | * integer nh_grp_count | |
1562 | ||
1563 | * integer zd_nhg_id | |
1564 | * nexthop_group zd_ng | |
1565 | * nexthop_group backup_ng | |
1566 | * nexthop_group zd_old_ng | |
1567 | * nexthop_group old_backup_ng | |
1568 | ||
1569 | * integer label (if zd_op is DPLANE_OP_LSP_*) | |
1570 | * table pw (if zd_op is DPLANE_OP_PW_*) | |
1571 | ||
1572 | * integer type | |
1573 | * integer af | |
1574 | * integer status | |
1575 | * integer flags | |
1576 | * integer local_label | |
1577 | * integer remote_label | |
1578 | ||
1579 | * table macinfo (if zd_op is DPLANE_OP_MAC_*) | |
1580 | ||
1581 | * integer vid | |
1582 | * integer br_ifindex | |
1583 | * ethaddr mac | |
1584 | * integer vtep_ip | |
1585 | * integer is_sticky | |
1586 | * integer nhg_id | |
1587 | * integer update_flags | |
1588 | ||
1589 | * table rule (if zd_op is DPLANE_OP_RULE_*) | |
1590 | ||
1591 | * integer sock | |
1592 | * integer unique | |
1593 | * integer seq | |
1594 | * string ifname | |
1595 | * integer priority | |
1596 | * integer old_priority | |
1597 | * integer table | |
1598 | * integer old_table | |
1599 | * integer filter_bm | |
1600 | * integer old_filter_bm | |
1601 | * integer fwmark | |
1602 | * integer old_fwmark | |
1603 | * integer dsfield | |
1604 | * integer old_dsfield | |
1605 | * integer ip_proto | |
1606 | * integer old_ip_proto | |
1607 | * prefix src_ip | |
1608 | * prefix old_src_ip | |
1609 | * prefix dst_ip | |
1610 | * prefix old_dst_ip | |
1611 | ||
1612 | * table iptable (if zd_op is DPLANE_OP_IPTABLE_*) | |
1613 | ||
1614 | * integer sock | |
1615 | * integer vrf_id | |
1616 | * integer unique | |
1617 | * integer type | |
1618 | * integer filter_bm | |
1619 | * integer fwmark | |
1620 | * integer action | |
1621 | * integer pkt_len_min | |
1622 | * integer pkt_len_max | |
1623 | * integer tcp_flags | |
1624 | * integer dscp_value | |
1625 | * integer fragment | |
1626 | * integer protocol | |
1627 | * integer nb_interface | |
1628 | * integer flow_label | |
1629 | * integer family | |
1630 | * string ipset_name | |
1631 | ||
1632 | * table ipset (if zd_op is DPLANE_OP_IPSET_*) | |
1633 | * integer sock | |
1634 | * integer vrf_id | |
1635 | * integer unique | |
1636 | * integer type | |
1637 | * integer family | |
1638 | * string ipset_name | |
1639 | ||
1640 | * table neigh (if zd_op is DPLANE_OP_NEIGH_*) | |
1641 | ||
1642 | * ipaddr ip_addr | |
1643 | * table link | |
1644 | ||
1645 | * ethaddr mac | |
1646 | * ipaddr ip_addr | |
1647 | ||
1648 | * integer flags | |
1649 | * integer state | |
1650 | * integer update_flags | |
1651 | ||
1652 | * table br_port (if zd_op is DPLANE_OP_BR_PORT_UPDATE) | |
1653 | ||
1654 | * integer sph_filter_cnt | |
1655 | * integer flags | |
1656 | * integer backup_nhg_id | |
1657 | ||
1658 | * table neightable (if zd_op is DPLANE_OP_NEIGH_TABLE_UPDATE) | |
1659 | ||
1660 | * integer family | |
1661 | * integer app_probes | |
1662 | * integer ucast_probes | |
1663 | * integer mcast_probes | |
1664 | ||
1665 | * table gre (if zd_op is DPLANE_OP_GRE_SET)** | |
1666 | ||
1667 | * integer link_ifindex | |
1668 | * integer mtu | |
1669 | ||
1670 | ||
1671 | .. _const-struct-nh-grp: | |
1672 | ||
1673 | const struct nh_grp | |
1674 | ^^^^^^^^^^^^^^^^^^^ | |
1675 | ||
1676 | .. code-block:: console | |
1677 | ||
1678 | * integer id | |
1679 | * integer weight | |
1680 | ||
1681 | ||
1682 | .. _zebra-hook-calls: | |
1683 | ||
1684 | Zebra Hook calls | |
1685 | ---------------- | |
1686 | ||
1687 | .. _on-rib-process-dplane-results: | |
1688 | ||
1689 | on_rib_process_dplane_results | |
1690 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
1691 | ||
1692 | Called when RIB processes dataplane events. | |
1693 | Set script location with the ``zebra on-rib-process script SCRIPT`` command. | |
1694 | ||
1695 | **Arguments** | |
1696 | ||
1697 | * :ref:`const struct zebra_dplane_ctx<const-struct-zebra-dplane-ctx>` ctx | |
1698 | ||
1699 | ||
1700 | .. code-block:: lua | |
1701 | ||
1702 | function on_rib_process_dplane_results(ctx) | |
1703 | log.info(ctx.rinfo.zd_dest.network) | |
1704 | return {} |