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.
16 Besides the common invocation options (:ref:`common-invocation-options`), the
17 *zebra* specific invocation options are listed below.
21 .. option:: -b, --batch
23 Runs in batch mode. *zebra* parses configuration file and terminates
26 .. option:: -K TIME, --graceful_restart TIME
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.
33 .. option:: -r, --retain
35 When program terminates, do not flush routes installed by *zebra* from the
38 .. option:: -e X, --ecmp X
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.
45 .. option:: -n, --vrfwnetns
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
50 VRF defined by *Zebra*, as usual.
52 .. seealso:: :ref:`zebra-vrf`
54 .. option:: -o, --vrfdefaultname
56 When *Zebra* starts with this option, the default VRF name is changed to the
59 .. seealso:: :ref:`zebra-vrf`
61 .. option:: -z <path_to_socket>, --socket <path_to_socket>
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.
67 .. option:: --v6-rr-semantics
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
75 .. option:: --asic-offload [notify_on_offload|notify_on_ack]
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.
88 .. _interface-commands:
90 Configuration Addresses behaviour
91 =================================
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*.
113 .. _standard-commands:
119 .. clicmd:: interface IFNAME
122 .. clicmd:: interface IFNAME vrf VRF
128 Up or down the current interface.
131 .. clicmd:: ip address ADDRESS/PREFIX
133 .. clicmd:: ipv6 address ADDRESS/PREFIX
137 Set the IPv4 or IPv6 address/prefix for the interface.
140 .. clicmd:: ip address LOCAL-ADDR peer PEER-ADDR/PREFIX
143 Configure an IPv4 Point-to-Point address on the interface. (The concept of
144 PtP addressing does not exist for IPv6.)
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.
152 .. clicmd:: description DESCRIPTION ...
154 Set description for the interface.
157 .. clicmd:: multicast
160 Enable or disables multicast flag for the interface.
163 .. clicmd:: bandwidth (1-10000000)
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
171 .. clicmd:: link-detect
174 Enable/disable link-detect on platforms which support this. Currently only
175 Linux, and only where network interface drivers support reporting
176 link-state via the ``IFF_RUNNING`` flag.
178 In FRR, link-detect is on by default.
180 .. _link-parameters-commands:
182 Link Parameters Commands
183 ------------------------
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.
191 .. clicmd:: link-params
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
202 Under link parameter statement, the following commands set the different TE values:
206 Enable link parameters for this interface.
208 .. clicmd:: metric (0-4294967295)
210 .. clicmd:: max-bw BANDWIDTH
212 .. clicmd:: max-rsv-bw BANDWIDTH
214 .. clicmd:: unrsv-bw (0-7) BANDWIDTH
216 .. clicmd:: admin-grp BANDWIDTH
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
225 Note that BANDWIDTH is specified in IEEE floating point format and express
228 .. clicmd:: delay (0-16777215) [min (0-16777215) | max (0-16777215)]
230 .. clicmd:: delay-variation (0-16777215)
232 .. clicmd:: packet-loss PERCENTAGE
234 .. clicmd:: res-bw BANDWIDTH
236 .. clicmd:: ava-bw BANDWIDTH
238 .. clicmd:: use-bw BANDWIDTH
240 These command specifies additional Traffic Engineering parameters of the
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
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
251 .. clicmd:: neighbor <A.B.C.D> as (0-65535)
253 Specifies the remote ASBR IP address and Autonomous System (AS) number
254 for InterASv2 link in OSPF (RFC5392). Note that this option is not yet
255 supported for ISIS (RFC5316).
260 Nexthop tracking doesn't resolve nexthops via the default route by default.
261 Allowing this might be useful when e.g. you want to allow BGP to peer across
264 .. clicmd:: ip nht resolve-via-default
266 Allow IPv4 nexthop tracking to resolve via the default route. This parameter
267 is configured per-VRF, so the command is also available in the VRF subnode.
269 .. clicmd:: ipv6 nht resolve-via-default
271 Allow IPv6 nexthop tracking to resolve via the default route. This parameter
272 is configured per-VRF, so the command is also available in the VRF subnode.
274 Administrative Distance
275 =======================
277 Administrative distance allows FRR to make decisions about what routes
278 should be installed in the rib based upon the originating protocol.
279 The lowest Admin Distance is the route selected. This is purely a
280 subjective decision about ordering and care has been taken to choose
281 the same distances that other routing suites have choosen.
283 +------------+-----------+
284 | Protocol | Distance |
285 +------------+-----------+
287 +------------+-----------+
289 +------------+-----------+
291 +------------+-----------+
293 +------------+-----------+
295 +------------+-----------+
297 +------------+-----------+
299 +------------+-----------+
301 +------------+-----------+
303 +------------+-----------+
305 +------------+-----------+
307 +------------+-----------+
309 +------------+-----------+
311 +------------+-----------+
313 +------------+-----------+
315 +------------+-----------+
317 +------------+-----------+
319 An admin distance of 255 indicates to Zebra that the route should not be
320 installed into the Data Plane. Additionally routes with an admin distance
321 of 255 will not be redistributed.
323 Zebra does treat Kernel routes as special case for the purposes of Admin
324 Distance. Upon learning about a route that is not originated by FRR
325 we read the metric value as a uint32_t. The top byte of the value
326 is interpreted as the Administrative Distance and the low three bytes
327 are read in as the metric. This special case is to facilitate VRF
330 Route Replace Semantics
331 =======================
333 When using the Linux Kernel as a forwarding plane, routes are installed
334 with a metric of 20 to the kernel. Please note that the kernel's metric
335 value bears no resemblence to FRR's RIB metric or admin distance. It
336 merely is a way for the Linux Kernel to decide which route to use if it
337 has multiple routes for the same prefix from multiple sources. An example
338 here would be if someone else was running another routing suite besides
339 FRR at the same time, the kernel must choose what route to use to forward
340 on. FRR choose the value of 20 because of two reasons. FRR wanted a
341 value small enough to be choosen but large enough that the operator could
342 allow route prioritization by the kernel when multiple routing suites are
343 being run and FRR wanted to take advantage of Route Replace semantics that
344 the linux kernel offers. In order for Route Replacement semantics to
345 work FRR must use the same metric when issuing the replace command.
346 Currently FRR only supports Route Replace semantics using the Linux
351 Virtual Routing and Forwarding
352 ==============================
354 FRR supports :abbr:`VRF (Virtual Routing and Forwarding)`. VRF is a way to
355 separate networking contexts on the same machine. Those networking contexts are
356 associated with separate interfaces, thus making it possible to associate one
357 interface with a specific VRF.
359 VRF can be used, for example, when instantiating per enterprise networking
360 services, without having to instantiate the physical host machine or the
361 routing management daemons for each enterprise. As a result, interfaces are
362 separate for each set of VRF, and routing daemons can have their own context
365 This conceptual view introduces the *Default VRF* case. If the user does not
366 configure any specific VRF, then by default, FRR uses the *Default VRF*.
368 Configuring VRF networking contexts can be done in various ways on FRR. The VRF
369 interfaces can be configured by entering in interface configuration mode
370 :clicmd:`interface IFNAME vrf VRF`.
372 A VRF backend mode is chosen when running *Zebra*.
374 If no option is chosen, then the *Linux VRF* implementation as references in
375 https://www.kernel.org/doc/Documentation/networking/vrf.txt will be mapped over
376 the *Zebra* VRF. The routing table associated to that VRF is a Linux table
377 identifier located in the same *Linux network namespace* where *Zebra* started.
378 Please note when using the *Linux VRF* routing table it is expected that a
379 default Kernel route will be installed that has a metric as outlined in the
380 www.kernel.org doc above. The Linux Kernel does table lookup via a combination
381 of rule application of the rule table and then route lookup of the specified
382 table. If no route match is found then the next applicable rule is applied
383 to find the next route table to use to look for a route match. As such if
384 your VRF table does not have a default blackhole route with a high metric
385 VRF route lookup will leave the table specified by the VRF, which is undesirable.
387 If the :option:`-n` option is chosen, then the *Linux network namespace* will
388 be mapped over the *Zebra* VRF. That implies that *Zebra* is able to configure
389 several *Linux network namespaces*. The routing table associated to that VRF
390 is the whole routing tables located in that namespace. For instance, this mode
391 matches OpenStack Network Namespaces. It matches also OpenFastPath. The default
392 behavior remains Linux VRF which is supported by the Linux kernel community,
393 see https://www.kernel.org/doc/Documentation/networking/vrf.txt.
395 Because of that difference, there are some subtle differences when running some
396 commands in relationship to VRF. Here is an extract of some of those commands:
400 This command is available on configuration mode. By default, above command
401 permits accessing the VRF configuration mode. This mode is available for
402 both VRFs. It is to be noted that *Zebra* does not create Linux VRF.
403 The network administrator can however decide to provision this command in
404 configuration file to provide more clarity about the intended configuration.
406 .. clicmd:: netns NAMESPACE
408 This command is based on VRF configuration mode. This command is available
409 when *Zebra* is run in :option:`-n` mode. This command reflects which *Linux
410 network namespace* is to be mapped with *Zebra* VRF. It is to be noted that
411 *Zebra* creates and detects added/suppressed VRFs from the Linux environment
412 (in fact, those managed with iproute2). The network administrator can however
413 decide to provision this command in configuration file to provide more clarity
414 about the intended configuration.
416 .. clicmd:: show ip route vrf VRF
418 The show command permits dumping the routing table associated to the VRF. If
419 *Zebra* is launched with default settings, this will be the ``TABLENO`` of
420 the VRF configured on the kernel, thanks to information provided in
421 https://www.kernel.org/doc/Documentation/networking/vrf.txt. If *Zebra* is
422 launched with :option:`-n` option, this will be the default routing table of
423 the *Linux network namespace* ``VRF``.
425 .. clicmd:: show ip route vrf VRF table TABLENO
427 The show command is only available with :option:`-n` option. This command
428 will dump the routing table ``TABLENO`` of the *Linux network namespace*
431 .. clicmd:: show ip route vrf VRF tables
433 This command will dump the routing tables within the vrf scope. If `vrf all`
434 is executed, all routing tables will be dumped.
436 .. clicmd:: show <ip|ipv6> route summary [vrf VRF] [table TABLENO] [prefix]
438 This command will dump a summary output of the specified VRF and TABLENO
439 combination. If neither VRF or TABLENO is specified FRR defaults to
440 the default vrf and default table. If prefix is specified dump the
441 number of prefix routes.
443 By using the :option:`-n` option, the *Linux network namespace* will be mapped
444 over the *Zebra* VRF. One nice feature that is possible by handling *Linux
445 network namespace* is the ability to name default VRF. At startup, *Zebra*
446 discovers the available *Linux network namespace* by parsing folder
447 `/var/run/netns`. Each file stands for a *Linux network namespace*, but not all
448 *Linux network namespaces* are available under that folder. This is the case for
449 default VRF. It is possible to name the default VRF, by creating a file, by
450 executing following commands.
452 .. code-block:: shell
454 touch /var/run/netns/vrf0
455 mount --bind /proc/self/ns/net /var/run/netns/vrf0
457 Above command illustrates what happens when the default VRF is visible under
458 `var/run/netns/`. Here, the default VRF file is `vrf0`.
459 At startup, FRR detects the presence of that file. It detects that the file
460 statistics information matches the same file statistics information as
461 `/proc/self/ns/net` ( through stat() function). As statistics information
462 matches, then `vrf0` stands for the new default namespace name.
463 Consequently, the VRF naming `Default` will be overridden by the new discovered
464 namespace name `vrf0`.
466 For those who don't use VRF backend with *Linux network namespace*, it is
467 possible to statically configure and recompile FRR. It is possible to choose an
468 alternate name for default VRF. Then, the default VRF naming will automatically
469 be updated with the new name. To illustrate, if you want to recompile with
470 `global` value, use the following command:
472 .. code-block:: shell
474 ./configure --with-defaultvrfname=global
476 .. _zebra-table-allocation:
481 Some services like BGP flowspec allocate routing tables to perform policy
482 routing based on netfilter criteria and IP rules. In order to avoid
483 conflicts between VRF allocated routing tables and those services, Zebra
484 proposes to define a chunk of routing tables to use by other services.
486 Allocation configuration can be done like below, with the range of the
487 chunk of routing tables to be used by the given service.
489 .. clicmd:: ip table range <STARTTABLENO> <ENDTABLENO>
496 FRR supports ECMP as part of normal operations and is generally compiled
497 with a limit of 64 way ECMP. This of course can be modified via configure
498 options on compilation if the end operator desires to do so. Individual
499 protocols each have their own way of dictating ECMP policy and their
500 respective documentation should be read.
502 ECMP can be inspected in zebra by doing a `show ip route X` command.
504 .. code-block:: shell
506 eva# show ip route 4.4.4.4/32
507 Codes: K - kernel route, C - connected, S - static, R - RIP,
508 O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
509 T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
510 F - PBR, f - OpenFabric,
511 > - selected route, * - FIB route, q - queued, r - rejected, b - backup
512 t - trapped, o - offload failure
514 D>* 4.4.4.4/32 [150/0] via 192.168.161.1, enp39s0, weight 1, 00:00:02
515 * via 192.168.161.2, enp39s0, weight 1, 00:00:02
516 * via 192.168.161.3, enp39s0, weight 1, 00:00:02
517 * via 192.168.161.4, enp39s0, weight 1, 00:00:02
518 * via 192.168.161.5, enp39s0, weight 1, 00:00:02
519 * via 192.168.161.6, enp39s0, weight 1, 00:00:02
520 * via 192.168.161.7, enp39s0, weight 1, 00:00:02
521 * via 192.168.161.8, enp39s0, weight 1, 00:00:02
522 * via 192.168.161.9, enp39s0, weight 1, 00:00:02
523 * via 192.168.161.10, enp39s0, weight 1, 00:00:02
524 * via 192.168.161.11, enp39s0, weight 1, 00:00:02
525 * via 192.168.161.12, enp39s0, weight 1, 00:00:02
526 * via 192.168.161.13, enp39s0, weight 1, 00:00:02
527 * via 192.168.161.14, enp39s0, weight 1, 00:00:02
528 * via 192.168.161.15, enp39s0, weight 1, 00:00:02
529 * via 192.168.161.16, enp39s0, weight 1, 00:00:02
531 In this example we have 16 way ecmp for the 4.4.4.4/32 route. The `*` character
532 tells us that the route is installed in the Data Plane, or FIB.
534 If you are using the Linux kernel as a Data Plane, this can be inspected
535 via a `ip route show X` command:
537 .. code-block:: shell
539 sharpd@eva ~/f/doc(ecmp_doc_change)> ip route show 4.4.4.4/32
540 4.4.4.4 nhid 185483868 proto sharp metric 20
541 nexthop via 192.168.161.1 dev enp39s0 weight 1
542 nexthop via 192.168.161.10 dev enp39s0 weight 1
543 nexthop via 192.168.161.11 dev enp39s0 weight 1
544 nexthop via 192.168.161.12 dev enp39s0 weight 1
545 nexthop via 192.168.161.13 dev enp39s0 weight 1
546 nexthop via 192.168.161.14 dev enp39s0 weight 1
547 nexthop via 192.168.161.15 dev enp39s0 weight 1
548 nexthop via 192.168.161.16 dev enp39s0 weight 1
549 nexthop via 192.168.161.2 dev enp39s0 weight 1
550 nexthop via 192.168.161.3 dev enp39s0 weight 1
551 nexthop via 192.168.161.4 dev enp39s0 weight 1
552 nexthop via 192.168.161.5 dev enp39s0 weight 1
553 nexthop via 192.168.161.6 dev enp39s0 weight 1
554 nexthop via 192.168.161.7 dev enp39s0 weight 1
555 nexthop via 192.168.161.8 dev enp39s0 weight 1
556 nexthop via 192.168.161.9 dev enp39s0 weight 1
558 Once installed into the FIB, FRR currently has little control over what
559 nexthops are choosen to forward packets on. Currently the Linux kernel
560 has a `fib_multipath_hash_policy` sysctl which dictates how the hashing
561 algorithm is used to forward packets.
568 You can configure static mpls entries in zebra. Basically, handling MPLS
569 consists of popping, swapping or pushing labels to IP packets.
574 :abbr:`LSR (Labeled Switch Router)`
575 Networking devices handling labels used to forward traffic between and through
578 :abbr:`LER (Labeled Edge Router)`
579 A Labeled edge router is located at the edge of an MPLS network, generally
580 between an IP network and an MPLS network.
585 The push action is generally used for LER devices, which want to encapsulate
586 all traffic for a wished destination into an MPLS label. This action is stored
587 in routing entry, and can be configured like a route:
589 .. clicmd:: ip route NETWORK MASK GATEWAY|INTERFACE label LABEL
591 NETWORK and MASK stand for the IP prefix entry to be added as static
593 GATEWAY is the gateway IP address to reach, in order to reach the prefix.
594 INTERFACE is the interface behind which the prefix is located.
595 LABEL is the MPLS label to use to reach the prefix abovementioned.
597 You can check that the static entry is stored in the zebra RIB database, by
598 looking at the presence of the entry.
602 zebra(configure)# ip route 1.1.1.1/32 10.0.1.1 label 777
604 Codes: K - kernel route, C - connected, S - static, R - RIP,
605 O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
606 T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
608 > - selected route, * - FIB route
610 S>* 1.1.1.1/32 [1/0] via 10.0.1.1, r2-eth0, label 777, 00:39:42
612 MPLS Swap and Pop Action
613 ------------------------
615 The swap action is generally used for LSR devices, which swap a packet with a
616 label, with an other label. The Pop action is used on LER devices, at the
617 termination of the MPLS traffic; this is used to remove MPLS header.
619 .. clicmd:: mpls lsp INCOMING_LABEL GATEWAY OUTGOING_LABEL|explicit-null|implicit-null
621 INCOMING_LABEL and OUTGOING_LABEL are MPLS labels with values ranging from 16
623 GATEWAY is the gateway IP address where to send MPLS packet.
624 The outgoing label can either be a value or have an explicit-null label header. This
625 specific header can be read by IP devices. The incoming label can also be removed; in
626 that case the implicit-null keyword is used, and the outgoing packet emitted is an IP
627 packet without MPLS header.
629 You can check that the MPLS actions are stored in the zebra MPLS table, by looking at the
630 presence of the entry.
632 .. clicmd:: show mpls table
636 zebra(configure)# mpls lsp 18 10.125.0.2 implicit-null
637 zebra(configure)# mpls lsp 19 10.125.0.2 20
638 zebra(configure)# mpls lsp 21 10.125.0.2 explicit-null
639 zebra# show mpls table
641 Label Type Nexthop Label
642 -------- ------- --------------- --------
643 18 Static 10.125.0.2 implicit-null
644 19 Static 10.125.0.2 20
645 21 Static 10.125.0.2 IPv4 Explicit Null
653 Segment-Routing is source routing paradigm that allows
654 network operator to encode network intent into the packets.
655 SRv6 is an implementation of Segment-Routing
656 with application of IPv6 and segment-routing-header.
658 All routing daemon can use the Segment-Routing base
659 framework implemented on zebra to use SRv6 routing mechanism.
660 In that case, user must configure initial srv6 setting on
661 FRR's cli or frr.conf or zebra.conf. This section shows how
662 to configure SRv6 on FRR. Of course SRv6 can be used as standalone,
663 and this section also helps that case.
665 .. clicmd:: show segment-routing srv6 locator [json]
667 This command dump SRv6-locator configured on zebra. SRv6-locator is used
668 to route to the node before performing the SRv6-function. and that works as
669 aggregation of SRv6-function's IDs. Following console log shows two
670 SRv6-locators loc1 and loc2. All locators are identified by unique IPv6
671 prefix. User can get that information as JSON string when ``json`` key word
672 at the end of cli is presented.
676 router# sh segment-routing srv6 locator
678 Name ID Prefix Status
679 -------------------- ------- ------------------------ -------
680 loc1 1 2001:db8:1:1::/64 Up
681 loc2 2 2001:db8:2:2::/64 Up
683 .. clicmd:: show segment-routing srv6 locator NAME detail [json]
685 As shown in the example, by specifying the name of the locator, you
686 can see the detailed information for each locator. Locator can be
687 represented by a single IPv6 prefix, but SRv6 is designed to share this
688 Locator among multiple Routing Protocols. For this purpose, zebra divides
689 the IPv6 prefix block that makes the Locator unique into multiple chunks,
690 and manages the ownership of each chunk.
692 For example, loc1 has system as its owner. For example, loc1 is owned by
693 system, which means that it is not yet proprietary to any routing protocol.
694 For example, loc2 has sharp as its owner. This means that the shaprd for
695 function development holds the owner of the chunk of this locator, and no
696 other routing protocol will use this area.
700 router# show segment-routing srv6 locator loc1 detail
702 Prefix: 2001:db8:1:1::/64
704 - prefix: 2001:db8:1:1::/64, owner: system
706 router# show segment-routing srv6 locator loc2 detail
708 Prefix: 2001:db8:2:2::/64
710 - prefix: 2001:db8:2:2::/64, owner: sharp
712 .. clicmd:: segment-routing
714 Move from configure mode to segment-routing node.
718 Move from segment-routing node to srv6 node.
722 Move from srv6 node to locator node. In this locator node, user can
723 configure detailed settings such as the actual srv6 locator.
725 .. clicmd:: locator NAME
727 Create a new locator. If the name of an existing locator is specified,
728 move to specified locator's configuration node to change the settings it.
730 .. clicmd:: prefix X:X::X:X/M [function-bits-length 32]
732 Set the ipv6 prefix block of the locator. SRv6 locator is defined by
733 RFC8986. The actual routing protocol specifies the locator and allocates a
734 SID to be used by each routing protocol. This SID is included in the locator
737 Following example console log shows the typical configuration of SRv6
738 data-plane. After a new SRv6 locator, named loc1, is created, loc1's prefix
739 is configured as ``2001:db8:1:1::/64``. If user or some routing daemon
740 allocates new SID on this locator, new SID will allocated in range of this
741 prefix. For example, if some routing daemon creates new SID on locator
742 (``2001:db8:1:1::/64``), Then new SID will be ``2001:db8:1:1:7::/80``,
743 ``2001:db8:1:1:8::/80``, and so on. Each locator has default SID that is
744 SRv6 local function "End". Usually default SID is allocated as
745 ``PREFIX:1::``. (``PREFIX`` is locator's prefix) For example, if user
746 configure the locator's prefix as ``2001:db8:1:1::/64``, then default SID
747 will be ``2001:db8:1:1:1::``)
749 The function bits range is 16bits by default. If operator want to change
750 function bits range, they can configure with ``function-bits-length``
755 router# configure terminal
756 router(config)# segment-routinig
757 router(config-sr)# srv6
758 router(config-srv6)# locators
759 router(config-srv6-locs)# locator loc1
760 router(config-srv6-loc)# prefix 2001:db8:1:1::/64
762 router(config-srv6-loc)# show run
768 prefix 2001:db8:1:1::/64
772 .. _multicast-rib-commands:
774 Multicast RIB Commands
775 ======================
777 The Multicast RIB provides a separate table of unicast destinations which
778 is used for Multicast Reverse Path Forwarding decisions. It is used with
779 a multicast source's IP address, hence contains not multicast group
780 addresses but unicast addresses.
782 This table is fully separate from the default unicast table. However,
783 RPF lookup can include the unicast table.
785 WARNING: RPF lookup results are non-responsive in this version of FRR,
786 i.e. multicast routing does not actively react to changes in underlying
789 .. clicmd:: ip multicast rpf-lookup-mode MODE
792 MODE sets the method used to perform RPF lookups. Supported modes:
795 Performs the lookup on the Unicast RIB. The Multicast RIB is never used.
798 Performs the lookup on the Multicast RIB. The Unicast RIB is never used.
801 Tries to perform the lookup on the Multicast RIB. If any route is found,
802 that route is used. Otherwise, the Unicast RIB is tried.
805 Performs a lookup on the Multicast RIB and Unicast RIB each. The result
806 with the lower administrative distance is used; if they're equal, the
807 Multicast RIB takes precedence.
810 Performs a lookup on the Multicast RIB and Unicast RIB each. The result
811 with the longer prefix length is used; if they're equal, the
812 Multicast RIB takes precedence.
814 The `mrib-then-urib` setting is the default behavior if nothing is
815 configured. If this is the desired behavior, it should be explicitly
816 configured to make the configuration immune against possible changes in
817 what the default behavior is.
821 Unreachable routes do not receive special treatment and do not cause
822 fallback to a second lookup.
824 .. clicmd:: show ip rpf ADDR
826 Performs a Multicast RPF lookup, as configured with ``ip multicast
827 rpf-lookup-mode MODE``. ADDR specifies the multicast source address to look
832 > show ip rpf 192.0.2.1
833 Routing entry for 192.0.2.0/24 using Unicast RIB
835 Known via "kernel", distance 0, metric 0, best
836 * 198.51.100.1, via eth0
839 Indicates that a multicast source lookup for 192.0.2.1 would use an
840 Unicast RIB entry for 192.0.2.0/24 with a gateway of 198.51.100.1.
842 .. clicmd:: show ip rpf
844 Prints the entire Multicast RIB. Note that this is independent of the
845 configured RPF lookup mode, the Multicast RIB may be printed yet not
848 .. clicmd:: ip mroute PREFIX NEXTHOP [DISTANCE]
851 Adds a static route entry to the Multicast RIB. This performs exactly as the
852 ``ip route`` command, except that it inserts the route in the Multicast RIB
853 instead of the Unicast RIB.
855 .. _zebra-route-filtering:
857 zebra Route Filtering
858 =====================
860 Zebra supports :dfn:`prefix-list` s and :ref:`route-map` s to match routes
861 received from other FRR components. The permit/deny facilities provided by
862 these commands can be used to filter which routes zebra will install in the
865 .. clicmd:: ip protocol PROTOCOL route-map ROUTEMAP
867 Apply a route-map filter to routes for the specified protocol. PROTOCOL can
888 If you choose any as the option that will cause all protocols that are sending
889 routes to zebra. You can specify a :dfn:`ip protocol PROTOCOL route-map ROUTEMAP`
890 on a per vrf basis, by entering this command under vrf mode for the vrf you
891 want to apply the route-map against.
893 .. clicmd:: set src ADDRESS
895 Within a route-map, set the preferred source address for matching routes
896 when installing in the kernel.
899 The following creates a prefix-list that matches all addresses, a route-map
900 that sets the preferred source address, and applies the route-map to all
905 ip prefix-list ANY permit 0.0.0.0/0 le 32
906 route-map RM1 permit 10
907 match ip address prefix-list ANY
910 ip protocol rip route-map RM1
912 IPv6 example for OSPFv3.
916 ipv6 prefix-list ANY seq 10 permit any
917 route-map RM6 permit 10
918 match ipv6 address prefix-list ANY
919 set src 2001:db8:425:1000::3
921 ipv6 protocol ospf6 route-map RM6
926 For both IPv4 and IPv6, the IP address has to exist on some interface when
927 the route is getting installed into the system. Otherwise, kernel rejects
928 the route. To solve the problem of disappearing IPv6 addresses when the
929 interface goes down, use ``net.ipv6.conf.all.keep_addr_on_down``
930 :ref:`sysctl option <zebra-sysctl>`.
932 .. clicmd:: zebra route-map delay-timer (0-600)
934 Set the delay before any route-maps are processed in zebra. The
935 default time for this is 5 seconds.
937 .. _zebra-fib-push-interface:
939 zebra FIB push interface
940 ========================
942 Zebra supports a 'FIB push' interface that allows an external
943 component to learn the forwarding information computed by the FRR
944 routing suite. This is a loadable module that needs to be enabled
945 at startup as described in :ref:`loadable-module-support`.
947 In FRR, the Routing Information Base (RIB) resides inside
948 zebra. Routing protocols communicate their best routes to zebra, and
949 zebra computes the best route across protocols for each prefix. This
950 latter information makes up the Forwarding Information Base
951 (FIB). Zebra feeds the FIB to the kernel, which allows the IP stack in
952 the kernel to forward packets according to the routes computed by
953 FRR. The kernel FIB is updated in an OS-specific way. For example,
954 the `Netlink` interface is used on Linux, and route sockets are
957 The FIB push interface aims to provide a cross-platform mechanism to
958 support scenarios where the router has a forwarding path that is
959 distinct from the kernel, commonly a hardware-based fast path. In
960 these cases, the FIB needs to be maintained reliably in the fast path
961 as well. We refer to the component that programs the forwarding plane
962 (directly or indirectly) as the Forwarding Plane Manager or FPM.
964 .. program:: configure
966 The relevant zebra code kicks in when zebra is configured with the
967 :option:`--enable-fpm` flag and started with the module (``-M fpm``
968 or ``-M dplane_fpm_nl``).
972 The ``fpm`` implementation attempts to connect to ``127.0.0.1`` port ``2620``
973 by default without configurations. The ``dplane_fpm_nl`` only attempts to
974 connect to a server if configured.
976 Zebra periodically attempts to connect to the well-known FPM port (``2620``).
977 Once the connection is up, zebra starts sending messages containing routes
978 over the socket to the FPM. Zebra sends a complete copy of the forwarding
979 table to the FPM, including routes that it may have picked up from the kernel.
980 The existing interaction of zebra with the kernel remains unchanged -- that
981 is, the kernel continues to receive FIB updates as before.
983 The default FPM message format is netlink, however it can be controlled
984 with the module load-time option. The modules accept the following options:
986 - ``fpm``: ``netlink`` and ``protobuf``.
987 - ``dplane_fpm_nl``: none, it only implements netlink.
989 The zebra FPM interface uses replace semantics. That is, if a 'route
990 add' message for a prefix is followed by another 'route add' message,
991 the information in the second message is complete by itself, and
992 replaces the information sent in the first message.
994 If the connection to the FPM goes down for some reason, zebra sends
995 the FPM a complete copy of the forwarding table(s) when it reconnects.
997 For more details on the implementation, please read the developer's manual FPM
1003 ``fpm`` implementation
1004 ----------------------
1006 .. clicmd:: fpm connection ip A.B.C.D port (1-65535)
1008 Configure ``zebra`` to connect to a different FPM server than the default of
1011 .. clicmd:: show zebra fpm stats
1013 Shows the FPM statistics.
1019 Counter Total Last 10 secs
1029 nop_deletes_skipped 6 0
1032 updates_triggered 11 0
1033 redundant_triggers 0 0
1034 dests_del_after_update 0 0
1035 t_conn_down_starts 0 0
1036 t_conn_down_dests_processed 0 0
1037 t_conn_down_yields 0 0
1038 t_conn_down_finishes 0 0
1039 t_conn_up_starts 1 0
1040 t_conn_up_dests_processed 11 0
1041 t_conn_up_yields 0 0
1042 t_conn_up_aborts 0 0
1043 t_conn_up_finishes 1 0
1046 .. clicmd:: clear zebra fpm stats
1048 Reset statistics related to the zebra code that interacts with the
1049 optional Forwarding Plane Manager (FPM) component.
1052 ``dplane_fpm_nl`` implementation
1053 --------------------------------
1055 .. clicmd:: fpm address <A.B.C.D|X:X::X:X> [port (1-65535)]
1057 Configures the FPM server address. Once configured ``zebra`` will attempt
1058 to connect to it immediately.
1060 The ``no`` form disables FPM entirely. ``zebra`` will close any current
1061 connections and will not attempt to connect to it anymore.
1063 .. clicmd:: fpm use-next-hop-groups
1065 Use the new netlink messages ``RTM_NEWNEXTHOP`` / ``RTM_DELNEXTHOP`` to
1066 group repeated route next hop information.
1068 The ``no`` form uses the old known FPM behavior of including next hop
1069 information in the route (e.g. ``RTM_NEWROUTE``) messages.
1071 .. clicmd:: show fpm counters [json]
1073 Show the FPM statistics (plain text or JSON formatted).
1083 Output buffer current size: 0
1084 Output buffer peak size: 308
1085 Connection closes: 0
1086 Connection errors: 0
1087 Data plane items processed: 0
1088 Data plane items enqueued: 0
1089 Data plane items queue peak: 0
1091 User FPM configurations: 1
1092 User FPM disable requests: 0
1095 .. clicmd:: clear fpm counters
1097 Reset statistics related to the zebra code that interacts with the
1098 optional Forwarding Plane Manager (FPM) component.
1106 The zebra dataplane subsystem provides a framework for FIB
1107 programming. Zebra uses the dataplane to program the local kernel as
1108 it makes changes to objects such as IP routes, MPLS LSPs, and
1109 interface IP addresses. The dataplane runs in its own pthread, in
1110 order to off-load work from the main zebra pthread.
1113 .. clicmd:: show zebra dplane [detailed]
1115 Display statistics about the updates and events passing through the
1116 dataplane subsystem.
1119 .. clicmd:: show zebra dplane providers
1121 Display information about the running dataplane plugins that are
1122 providing updates to a FIB. By default, the local kernel plugin is
1126 .. clicmd:: zebra dplane limit [NUMBER]
1128 Configure the limit on the number of pending updates that are
1129 waiting to be processed by the dataplane pthread.
1132 zebra Terminal Mode Commands
1133 ============================
1135 .. clicmd:: show ip route
1137 Display current routes which zebra holds in its database.
1141 Router# show ip route
1142 Codes: K - kernel route, C - connected, S - static, R - RIP,
1143 B - BGP * - FIB route.
1145 K* 0.0.0.0/0 203.181.89.241
1146 S 0.0.0.0/0 203.181.89.1
1148 C* 203.181.89.240/28 eth0
1151 .. clicmd:: show ipv6 route
1153 .. clicmd:: show [ip|ipv6] route [PREFIX] [nexthop-group]
1155 Display detailed information about a route. If [nexthop-group] is
1156 included, it will display the nexthop group ID the route is using as well.
1158 .. clicmd:: show interface [NAME] [{vrf VRF|brief}] [json]
1160 .. clicmd:: show interface [NAME] [{vrf all|brief}] [json]
1162 .. clicmd:: show interface [NAME] [{vrf VRF|brief}] [nexthop-group]
1164 .. clicmd:: show interface [NAME] [{vrf all|brief}] [nexthop-group]
1166 Display interface information. If no extra information is added, it will
1167 dump information on all interfaces. If [NAME] is specified, it will display
1168 detailed information about that single interface. If [nexthop-group] is
1169 specified, it will display nexthop groups pointing out that interface.
1171 If the ``json`` option is specified, output is displayed in JSON format.
1173 .. clicmd:: show ip prefix-list [NAME]
1175 .. clicmd:: show route-map [NAME]
1177 .. clicmd:: show ip protocol
1179 .. clicmd:: show ip forward
1181 Display whether the host's IP forwarding function is enabled or not.
1182 Almost any UNIX kernel can be configured with IP forwarding disabled.
1183 If so, the box can't work as a router.
1185 .. clicmd:: show ipv6 forward
1187 Display whether the host's IP v6 forwarding is enabled or not.
1189 .. clicmd:: show zebra
1191 Display various statistics related to the installation and deletion
1192 of routes, neighbor updates, and LSP's into the kernel.
1194 .. clicmd:: show zebra client [summary]
1196 Display statistics about clients that are connected to zebra. This is
1197 useful for debugging and seeing how much data is being passed between
1198 zebra and it's clients. If the summary form of the command is choosen
1199 a table is displayed with shortened information.
1201 .. clicmd:: show zebra router table summary
1203 Display summarized data about tables created, their afi/safi/tableid
1204 and how many routes each table contains. Please note this is the
1205 total number of route nodes in the table. Which will be higher than
1206 the actual number of routes that are held.
1208 .. clicmd:: show nexthop-group rib [ID] [vrf NAME] [singleton [ip|ip6]] [type]
1210 Display nexthop groups created by zebra. The [vrf NAME] option
1211 is only meaningful if you have started zebra with the --vrfwnetns
1212 option as that nexthop groups are per namespace in linux.
1213 If you specify singleton you would like to see the singleton
1214 nexthop groups that do have an afi. [type] allows you to filter those
1215 only coming from a specific NHG type (protocol).
1217 .. clicmd:: show <ip|ipv6> zebra route dump [<vrf> VRFNAME]
1219 It dumps all the routes from RIB with detailed information including
1220 internal flags, status etc. This is defined as a hidden command.
1226 Many routing protocols require a router-id to be configured. To have a
1227 consistent router-id across all daemons, the following commands are available
1228 to configure and display the router-id:
1230 .. clicmd:: [ip] router-id A.B.C.D
1232 Allow entering of the router-id. This command also works under the
1233 vrf subnode, to allow router-id's per vrf.
1235 .. clicmd:: [ip] router-id A.B.C.D vrf NAME
1237 Configure the router-id of this router from the configure NODE.
1238 A show run of this command will display the router-id command
1239 under the vrf sub node. This command is deprecated and will
1240 be removed at some point in time in the future.
1242 .. clicmd:: show [ip] router-id [vrf NAME]
1244 Display the user configured router-id.
1246 For protocols requiring an IPv6 router-id, the following commands are available:
1248 .. clicmd:: ipv6 router-id X:X::X:X
1250 Configure the IPv6 router-id of this router. Like its IPv4 counterpart,
1251 this command works under the vrf subnode, to allow router-id's per vrf.
1253 .. clicmd:: show ipv6 router-id [vrf NAME]
1255 Display the user configured IPv6 router-id.
1262 The linux kernel has a variety of sysctl's that affect it's operation as a router. This
1263 section is meant to act as a starting point for those sysctl's that must be used in
1264 order to provide FRR with smooth operation as a router. This section is not meant
1265 as the full documentation for sysctl's. The operator must use the sysctl documentation
1266 with the linux kernel for that. The following link has helpful references to many relevant
1267 sysctl values: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
1269 Expected sysctl settings
1270 ------------------------
1272 .. option:: net.ipv4.ip_forward = 1
1274 This global option allows the linux kernel to forward (route) ipv4 packets incoming from one
1275 interface to an outgoing interface. If this is set to 0, the system will not route transit
1276 ipv4 packets, i.e. packets that are not sent to/from a process running on the local system.
1278 .. option:: net.ipv4.conf.{all,default,<interface>}.forwarding = 1
1280 The linux kernel can selectively enable forwarding (routing) of ipv4 packets on a per
1281 interface basis. The forwarding check in the kernel dataplane occurs against the ingress
1282 Layer 3 interface, i.e. if the ingress L3 interface has forwarding set to 0, packets will not
1285 .. option:: net.ipv6.conf.{all,default,<interface>}.forwarding = 1
1287 This per interface option allows the linux kernel to forward (route) transit ipv6 packets
1288 i.e. incoming from one Layer 3 interface to an outgoing Layer 3 interface.
1289 The forwarding check in the kernel dataplane occurs against the ingress Layer 3 interface,
1290 i.e. if the ingress L3 interface has forwarding set to 0, packets will not be routed.
1292 .. option:: net.ipv6.conf.all.keep_addr_on_down = 1
1294 When an interface is taken down, do not remove the v6 addresses associated with the interface.
1295 This option is recommended because this is the default behavior for v4 as well.
1297 .. option:: net.ipv6.route.skip_notify_on_dev_down = 1
1299 When an interface is taken down, the linux kernel will not notify, via netlink, about routes
1300 that used that interface being removed from the FIB. This option is recommended because this
1301 is the default behavior for v4 as well.
1303 Optional sysctl settings
1304 ------------------------
1306 .. option:: net.ipv4.conf.{all,default,<interface>}.bc_forwarding = 0
1308 This per interface option allows the linux kernel to optionally allow Directed Broadcast
1309 (i.e. Routed Broadcast or Subnet Broadcast) packets to be routed onto the connected network
1310 segment where the subnet exists.
1311 If the local router receives a routed packet destined for a broadcast address of a connected
1312 subnet, setting bc_forwarding to 1 on the interface with the target subnet assigned to it will
1313 allow non locally-generated packets to be routed via the broadcast route.
1314 If bc_forwarding is set to 0, routed packets destined for a broadcast route will be dropped.
1316 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
1317 If net.ipv4.conf.{all,default,<interface>}.bc_forwarding=1, then Router1 will forward each
1318 packet destined to 10.0.0.255 onto the eth1 interface with a broadcast DMAC (ff:ff:ff:ff:ff:ff).
1320 .. option:: net.ipv4.conf.{all,default,<interface>}.arp_accept = 1
1322 This per interface option allows the linux kernel to optionally skip the creation of ARP
1323 entries upon the receipt of a Gratuitous ARP (GARP) frame carrying an IP that is not already
1324 present in the ARP cache. Setting arp_accept to 0 on an interface will ensure NEW ARP entries
1325 are not created due to the arrival of a GARP frame.
1326 Note: This does not impact how the kernel reacts to GARP frames that carry a "known" IP
1327 (that is already in the ARP cache) -- an existing ARP entry will always be updated
1328 when a GARP for that IP is received.
1330 .. option:: net.ipv4.conf.{all,default,<interface>}.arp_ignore = 0
1332 This per interface option allows the linux kernel to control what conditions must be met in
1333 order for an ARP reply to be sent in response to an ARP request targeting a local IP address.
1334 When arp_ignore is set to 0, the kernel will send ARP replies in response to any ARP Request
1335 with a Target-IP matching a local address.
1336 When arp_ignore is set to 1, the kernel will send ARP replies if the Target-IP in the ARP
1337 Request matches an IP address on the interface the Request arrived at.
1338 When arp_ignore is set to 2, the kernel will send ARP replies only if the Target-IP matches an
1339 IP address on the interface where the Request arrived AND the Sender-IP falls within the subnet
1340 assigned to the local IP/interface.
1342 .. option:: net.ipv4.conf.{all,default,<interface>}.arp_notify = 1
1344 This per interface option allows the linux kernel to decide whether to send a Gratuitious ARP
1345 (GARP) frame when the Layer 3 interface comes UP.
1346 When arp_notify is set to 0, no GARP is sent.
1347 When arp_notify is set to 1, a GARP is sent when the interface comes UP.
1349 .. option:: net.ipv6.conf.{all,default,<interface>}.ndisc_notify = 1
1351 This per interface option allows the linux kernel to decide whether to send an Unsolicited
1352 Neighbor Advertisement (U-NA) frame when the Layer 3 interface comes UP.
1353 When ndisc_notify is set to 0, no U-NA is sent.
1354 When ndisc_notify is set to 1, a U-NA is sent when the interface comes UP.
1359 .. clicmd:: debug zebra mpls [detailed]
1361 MPLS-related events and information.
1363 .. clicmd:: debug zebra events
1367 .. clicmd:: debug zebra nht [detailed]
1369 Nexthop-tracking / reachability information
1371 .. clicmd:: debug zebra vxlan
1375 .. clicmd:: debug zebra pseudowires
1379 .. clicmd:: debug zebra packet [<recv|send>] [detail]
1381 ZAPI message and packet details
1383 .. clicmd:: debug zebra kernel
1387 .. clicmd:: debug zebra kernel msgdump [<recv|send>]
1389 Raw OS (netlink) message details.
1391 .. clicmd:: debug zebra rib [detailed]
1395 .. clicmd:: debug zebra fpm
1397 FPM (forwarding-plane manager) events.
1399 .. clicmd:: debug zebra dplane [detailed]
1401 Dataplane / FIB events.
1403 .. clicmd:: debug zebra pbr
1405 PBR (policy-based routing) events.
1407 .. clicmd:: debug zebra mlag
1411 .. clicmd:: debug zebra evpn mh <es|mac|neigh|nh>
1413 EVPN multi-hop events.
1415 .. clicmd:: debug zebra nexthop [detail]
1417 Nexthop and nexthop-group events.