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, --keep_kernel
28 When zebra starts up, don't delete old self inserted routes.
30 .. option:: -r, --retain
32 When program terminates, do not flush routes installed by *zebra* from the
35 .. option:: -e X, --ecmp X
37 Run zebra with a limited ecmp ability compared to what it is compiled to.
38 If you are running zebra on hardware limited functionality you can
39 force zebra to limit the maximum ecmp allowed to X. This number
40 is bounded by what you compiled FRR with as the maximum number.
42 .. option:: -n, --vrfwnetns
44 When *Zebra* starts with this option, the VRF backend is based on Linux
45 network namespaces. That implies that all network namespaces discovered by
46 ZEBRA will create an associated VRF. The other daemons will operate on the VRF
47 VRF defined by *Zebra*, as usual.
49 .. seealso:: :ref:`zebra-vrf`
51 .. option:: -o, --vrfdefaultname
53 When *Zebra* starts with this option, the default VRF name is changed to the
56 .. seealso:: :ref:`zebra-vrf`
58 .. option:: --v6-rr-semantics
60 The linux kernel is receiving the ability to use the same route
61 replacement semantics for v6 that v4 uses. If you are using a
62 kernel that supports this functionality then run *Zebra* with this
63 option and we will use Route Replace Semantics instead of delete
66 .. _interface-commands:
68 Configuration Addresses behaviour
69 =================================
71 At startup, *Zebra* will first discover the underlying networking objects
72 from the operating system. This includes interfaces, addresses of
73 interfaces, static routes, etc. Then, it will read the configuration
74 file, including its own interface addresses, static routes, etc. All this
75 information comprises the operational context from *Zebra*. But
76 configuration context from *Zebra* will remain the same as the one from
77 :file:`zebra.conf` config file. As an example, executing the following
78 :clicmd:`show running-config` will reflect what was in :file:`zebra.conf`.
79 In a similar way, networking objects that are configured outside of the
80 *Zebra* like *iproute2* will not impact the configuration context from
81 *Zebra*. This behaviour permits you to continue saving your own config
82 file, and decide what is really to be pushed on the config file, and what
83 is dependent on the underlying system.
84 Note that inversely, from *Zebra*, you will not be able to delete networking
85 objects that were previously configured outside of *Zebra*.
91 .. _standard-commands:
96 .. index:: interface IFNAME
98 .. clicmd:: interface IFNAME
100 .. index:: interface IFNAME vrf VRF
102 .. clicmd:: interface IFNAME vrf VRF
107 .. index:: no shutdown
109 .. clicmd:: no shutdown
111 Up or down the current interface.
113 .. index:: ip address ADDRESS/PREFIX
115 .. clicmd:: ip address ADDRESS/PREFIX
116 .. index:: ipv6 address ADDRESS/PREFIX
118 .. clicmd:: ipv6 address ADDRESS/PREFIX
119 .. index:: no ip address ADDRESS/PREFIX
121 .. clicmd:: no ip address ADDRESS/PREFIX
122 .. index:: no ipv6 address ADDRESS/PREFIX
124 .. clicmd:: no ipv6 address ADDRESS/PREFIX
126 Set the IPv4 or IPv6 address/prefix for the interface.
128 .. index:: ip address LOCAL-ADDR peer PEER-ADDR/PREFIX
130 .. clicmd:: ip address LOCAL-ADDR peer PEER-ADDR/PREFIX
131 .. index:: no ip address LOCAL-ADDR peer PEER-ADDR/PREFIX
133 .. clicmd:: no ip address LOCAL-ADDR peer PEER-ADDR/PREFIX
135 Configure an IPv4 Point-to-Point address on the interface. (The concept of
136 PtP addressing does not exist for IPv6.)
138 `local-addr` has no subnet mask since the local side in PtP addressing is
139 always a single (/32) address. `peer-addr/prefix` can be an arbitrary subnet
140 behind the other end of the link (or even on the link in Point-to-Multipoint
141 setups), though generally /32s are used.
143 .. index:: description DESCRIPTION ...
145 .. clicmd:: description DESCRIPTION ...
147 Set description for the interface.
151 .. clicmd:: multicast
152 .. index:: no multicast
154 .. clicmd:: no multicast
156 Enable or disables multicast flag for the interface.
158 .. index:: bandwidth (1-10000000)
160 .. clicmd:: bandwidth (1-10000000)
161 .. index:: no bandwidth (1-10000000)
163 .. clicmd:: no bandwidth (1-10000000)
165 Set bandwidth value of the interface in kilobits/sec. This is for
166 calculating OSPF cost. This command does not affect the actual device
169 .. index:: link-detect
171 .. clicmd:: link-detect
172 .. index:: no link-detect
174 .. clicmd:: no link-detect
176 Enable/disable link-detect on platforms which support this. Currently only
177 Linux and Solaris, and only where network interface drivers support
178 reporting link-state via the ``IFF_RUNNING`` flag.
180 In FRR, link-detect is on by default.
182 .. _link-parameters-commands:
184 Link Parameters Commands
185 ------------------------
187 .. index:: link-params
188 .. clicmd:: link-params
190 .. index:: no link-param
191 .. clicmd:: no link-param
193 Enter into the link parameters sub node. At least 'enable' must be set to
194 activate the link parameters, and consequently Traffic Engineering on this
195 interface. MPLS-TE must be enable at the OSPF
196 (:ref:`ospf-traffic-engineering`) or ISIS (:ref:`isis-traffic-engineering`)
197 router level in complement to this. Disable link parameters for this
200 Under link parameter statement, the following commands set the different TE values:
202 .. index:: link-params [enable]
203 .. clicmd:: link-params [enable]
205 Enable link parameters for this interface.
207 .. index:: link-params [metric (0-4294967295)]
208 .. clicmd:: link-params [metric (0-4294967295)]
210 .. index:: link-params max-bw BANDWIDTH
211 .. clicmd:: link-params max-bw BANDWIDTH
213 .. index:: link-params max-rsv-bw BANDWIDTH
214 .. clicmd:: link-params max-rsv-bw BANDWIDTH
216 .. index:: link-params unrsv-bw (0-7) BANDWIDTH
217 .. clicmd:: link-params unrsv-bw (0-7) BANDWIDTH
219 .. index:: link-params admin-grp BANDWIDTH
220 .. clicmd:: link-params admin-grp BANDWIDTH
222 These commands specifies the Traffic Engineering parameters of the interface
223 in conformity to RFC3630 (OSPF) or RFC5305 (ISIS). There are respectively
224 the TE Metric (different from the OSPF or ISIS metric), Maximum Bandwidth
225 (interface speed by default), Maximum Reservable Bandwidth, Unreserved
226 Bandwidth for each 0-7 priority and Admin Group (ISIS) or Resource
229 Note that BANDIWDTH is specified in IEEE floating point format and express
232 .. index:: link-param delay (0-16777215) [min (0-16777215) | max (0-16777215)]
233 .. clicmd:: link-param delay (0-16777215) [min (0-16777215) | max (0-16777215)]
235 .. index:: link-param delay-variation (0-16777215)
236 .. clicmd:: link-param delay-variation (0-16777215)
238 .. index:: link-param packet-loss PERCENTAGE
239 .. clicmd:: link-param packet-loss PERCENTAGE
241 .. index:: link-param res-bw BANDWIDTH
242 .. clicmd:: link-param res-bw BANDWIDTH
244 .. index:: link-param ava-bw BANDWIDTH
245 .. clicmd:: link-param ava-bw BANDWIDTH
247 .. index:: link-param use-bw BANDWIDTH
248 .. clicmd:: link-param use-bw BANDWIDTH
250 These command specifies additional Traffic Engineering parameters of the
251 interface in conformity to draft-ietf-ospf-te-metrics-extension-05.txt and
252 draft-ietf-isis-te-metrics-extension-03.txt. There are respectively the
253 delay, jitter, loss, available bandwidth, reservable bandwidth and utilized
256 Note that BANDWIDTH is specified in IEEE floating point format and express
257 in Bytes/second. Delays and delay variation are express in micro-second
258 (µs). Loss is specified in PERCENTAGE ranging from 0 to 50.331642% by step
261 .. index:: link-param neighbor <A.B.C.D> as (0-65535)
262 .. clicmd:: link-param neighbor <A.B.C.D> as (0-65535)
264 .. index:: link-param no neighbor
265 .. clicmd:: link-param no neighbor
267 Specifies the remote ASBR IP address and Autonomous System (AS) number
268 for InterASv2 link in OSPF (RFC5392). Note that this option is not yet
269 supported for ISIS (RFC5316).
271 .. index:: table TABLENO
272 .. clicmd:: table TABLENO
274 Select the primary kernel routing table to be used. This only works for
275 kernels supporting multiple routing tables (like GNU/Linux 2.2.x and later).
276 After setting TABLENO with this command, static routes defined after this
277 are added to the specified table.
279 .. index:: ip nht resolve-via-default
280 .. clicmd:: ip nht resolve-via-default
282 Allows nexthop tracking to resolve via the default route. This is useful
283 when e.g. you want to allow BGP to peer across the default route.
287 Virtual Routing and Forwarding
288 ==============================
290 FRR supports :abbr:`VRF (Virtual Routing and Forwarding)`. VRF is a way to
291 separate networking contexts on the same machine. Those networking contexts are
292 associated with separate interfaces, thus making it possible to associate one
293 interface with a specific VRF.
295 VRF can be used, for example, when instantiating per enterprise networking
296 services, without having to instantiate the physical host machine or the
297 routing management daemons for each enterprise. As a result, interfaces are
298 separate for each set of VRF, and routing daemons can have their own context
301 This conceptual view introduces the *Default VRF* case. If the user does not
302 configure any specific VRF, then by default, FRR uses the *Default VRF*.
304 Configuring VRF networking contexts can be done in various ways on FRR. The VRF
305 interfaces can be configured by entering in interface configuration mode
306 :clicmd:`interface IFNAME vrf VRF`.
308 A VRF backend mode is chosen when running *Zebra*.
310 If no option is chosen, then the *Linux VRF* implementation as references in
311 https://www.kernel.org/doc/Documentation/networking/vrf.txt will be mapped over
312 the *Zebra* VRF. The routing table associated to that VRF is a Linux table
313 identifier located in the same *Linux network namespace* where *Zebra* started.
315 If the :option:`-n` option is chosen, then the *Linux network namespace* will
316 be mapped over the *Zebra* VRF. That implies that *Zebra* is able to configure
317 several *Linux network namespaces*. The routing table associated to that VRF
318 is the whole routing tables located in that namespace. For instance, this mode
319 matches OpenStack Network Namespaces. It matches also OpenFastPath. The default
320 behavior remains Linux VRF which is supported by the Linux kernel community,
321 see https://www.kernel.org/doc/Documentation/networking/vrf.txt.
323 Because of that difference, there are some subtle differences when running some
324 commands in relationship to VRF. Here is an extract of some of those commands:
329 This command is available on configuration mode. By default, above command
330 permits accessing the VRF configuration mode. This mode is available for
331 both VRFs. It is to be noted that *Zebra* does not create Linux VRF.
332 The network administrator can however decide to provision this command in
333 configuration file to provide more clarity about the intended configuration.
335 .. index:: netns NAMESPACE
336 .. clicmd:: netns NAMESPACE
338 This command is based on VRF configuration mode. This command is available
339 when *Zebra* is run in :option:`-n` mode. This command reflects which *Linux
340 network namespace* is to be mapped with *Zebra* VRF. It is to be noted that
341 *Zebra* creates and detects added/suppressed VRFs from the Linux environment
342 (in fact, those managed with iproute2). The network administrator can however
343 decide to provision this command in configuration file to provide more clarity
344 about the intended configuration.
346 .. index:: show ip route vrf VRF
347 .. clicmd:: show ip route vrf VRF
349 The show command permits dumping the routing table associated to the VRF. If
350 *Zebra* is launched with default settings, this will be the ``TABLENO`` of
351 the VRF configured on the kernel, thanks to information provided in
352 https://www.kernel.org/doc/Documentation/networking/vrf.txt. If *Zebra* is
353 launched with :option:`-n` option, this will be the default routing table of
354 the *Linux network namespace* ``VRF``.
356 .. index:: show ip route vrf VRF table TABLENO
357 .. clicmd:: show ip route vrf VRF table TABLENO
359 The show command is only available with :option:`-n` option. This command
360 will dump the routing table ``TABLENO`` of the *Linux network namespace*
363 By using the :option:`-n` option, the *Linux network namespace* will be mapped
364 over the *Zebra* VRF. One nice feature that is possible by handling *Linux
365 network namespace* is the ability to name default VRF. At startup, *Zebra*
366 discovers the available *Linux network namespace* by parsing folder
367 `/var/run/netns`. Each file stands for a *Linux network namespace*, but not all
368 *Linux network namespaces* are available under that folder. This is the case for
369 default VRF. It is possible to name the default VRF, by creating a file, by
370 executing following commands.
372 .. code-block:: shell
374 touch /var/run/netns/vrf0
375 mount --bind /proc/self/ns/net /var/run/netns/vrf0
377 Above command illustrates what happens when the default VRF is visible under
378 `var/run/netns/`. Here, the default VRF file is `vrf0`.
379 At startup, FRR detects the presence of that file. It detects that the file
380 statistics information matches the same file statistics information as
381 `/proc/self/ns/net` ( through stat() function). As statistics information
382 matches, then `vrf0` stands for the new default namespace name.
383 Consequently, the VRF naming `Default` will be overridden by the new discovered
384 namespace name `vrf0`.
386 For those who don't use VRF backend with *Linux network namespace*, it is
387 possible to statically configure and recompile FRR. It is possible to choose an
388 alternate name for default VRF. Then, the default VRF naming will automatically
389 be updated with the new name. To illustrate, if you want to recompile with
390 `global` value, use the following command:
392 .. code-block:: shell
394 ./configure --with-defaultvrfname=global
401 You can configure static mpls entries in zebra. Basically, handling MPLS
402 consists of popping, swapping or pushing labels to IP packets.
407 :abbr:`LSR (Labeled Switch Router)`
408 Networking devices handling labels used to forward traffic between and through
411 :abbr:`LER (Labeled Edge Router)`
412 A Labeled edge router is located at the edge of an MPLS network, generally
413 between an IP network and an MPLS network.
418 The push action is generally used for LER devices, which want to encapsulate
419 all traffic for a wished destination into an MPLS label. This action is stored
420 in routing entry, and can be configured like a route:
422 .. index:: [no] ip route NETWORK MASK GATEWAY|INTERFACE label LABEL
423 .. clicmd:: [no] ip route NETWORK MASK GATEWAY|INTERFACE label LABEL
425 NETWORK and MASK stand for the IP prefix entry to be added as static
427 GATEWAY is the gateway IP address to reach, in order to reach the prefix.
428 INTERFACE is the interface behind which the prefix is located.
429 LABEL is the MPLS label to use to reach the prefix abovementioned.
431 You can check that the static entry is stored in the zebra RIB database, by
432 looking at the presence of the entry.
436 zebra(configure)# ip route 1.1.1.1/32 10.0.1.1 label 777
438 Codes: K - kernel route, C - connected, S - static, R - RIP,
439 O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
440 T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
442 > - selected route, * - FIB route
444 S>* 1.1.1.1/32 [1/0] via 10.0.1.1, r2-eth0, label 777, 00:39:42
446 MPLS Swap and Pop Action
447 ------------------------
449 The swap action is generally used for LSR devices, which swap a packet with a
450 label, with an other label. The Pop action is used on LER devices, at the
451 termination of the MPLS traffic; this is used to remove MPLS header.
453 .. index:: [no] mpls lsp INCOMING_LABEL GATEWAY OUTGOING_LABEL|explicit-null|implicit-null
454 .. clicmd:: [no] mpls lsp INCOMING_LABEL GATEWAY OUTGOING_LABEL|explicit-null|implicit-null
456 INCOMING_LABEL and OUTGOING_LABEL are MPLS labels with values ranging from 16
458 GATEWAY is the gateway IP address where to send MPLS packet.
459 The outgoing label can either be a value or have an explicit-null label header. This
460 specific header can be read by IP devices. The incoming label can also be removed; in
461 that case the implicit-null keyword is used, and the outgoing packet emitted is an IP
462 packet without MPLS header.
464 You can check that the MPLS actions are stored in the zebra MPLS table, by looking at the
465 presence of the entry.
467 .. index:: show mpls table
468 .. clicmd:: show mpls table
472 zebra(configure)# mpls lsp 18 10.125.0.2 implicit-null
473 zebra(configure)# mpls lsp 19 10.125.0.2 20
474 zebra(configure)# mpls lsp 21 10.125.0.2 explicit-null
475 zebra# show mpls table
477 Label Type Nexthop Label
478 -------- ------- --------------- --------
479 18 Static 10.125.0.2 implicit-null
480 19 Static 10.125.0.2 20
481 21 Static 10.125.0.2 IPv4 Explicit Null
484 .. _multicast-rib-commands:
486 Multicast RIB Commands
487 ======================
489 The Multicast RIB provides a separate table of unicast destinations which
490 is used for Multicast Reverse Path Forwarding decisions. It is used with
491 a multicast source's IP address, hence contains not multicast group
492 addresses but unicast addresses.
494 This table is fully separate from the default unicast table. However,
495 RPF lookup can include the unicast table.
497 WARNING: RPF lookup results are non-responsive in this version of FRR,
498 i.e. multicast routing does not actively react to changes in underlying
501 .. index:: ip multicast rpf-lookup-mode MODE
502 .. clicmd:: ip multicast rpf-lookup-mode MODE
504 .. index:: no ip multicast rpf-lookup-mode [MODE]
505 .. clicmd:: no ip multicast rpf-lookup-mode [MODE]
507 MODE sets the method used to perform RPF lookups. Supported modes:
510 Performs the lookup on the Unicast RIB. The Multicast RIB is never used.
513 Performs the lookup on the Multicast RIB. The Unicast RIB is never used.
516 Tries to perform the lookup on the Multicast RIB. If any route is found,
517 that route is used. Otherwise, the Unicast RIB is tried.
520 Performs a lookup on the Multicast RIB and Unicast RIB each. The result
521 with the lower administrative distance is used; if they're equal, the
522 Multicast RIB takes precedence.
525 Performs a lookup on the Multicast RIB and Unicast RIB each. The result
526 with the longer prefix length is used; if they're equal, the
527 Multicast RIB takes precedence.
529 The `mrib-then-urib` setting is the default behavior if nothing is
530 configured. If this is the desired behavior, it should be explicitly
531 configured to make the configuration immune against possible changes in
532 what the default behavior is.
535 Unreachable routes do not receive special treatment and do not cause
536 fallback to a second lookup.
538 .. index:: show ip rpf ADDR
539 .. clicmd:: show ip rpf ADDR
541 Performs a Multicast RPF lookup, as configured with ``ip multicast
542 rpf-lookup-mode MODE``. ADDR specifies the multicast source address to look
547 > show ip rpf 192.0.2.1
548 Routing entry for 192.0.2.0/24 using Unicast RIB
550 Known via "kernel", distance 0, metric 0, best
551 * 198.51.100.1, via eth0
554 Indicates that a multicast source lookup for 192.0.2.1 would use an
555 Unicast RIB entry for 192.0.2.0/24 with a gateway of 198.51.100.1.
557 .. index:: show ip rpf
558 .. clicmd:: show ip rpf
560 Prints the entire Multicast RIB. Note that this is independent of the
561 configured RPF lookup mode, the Multicast RIB may be printed yet not
564 .. index:: ip mroute PREFIX NEXTHOP [DISTANCE]
565 .. clicmd:: ip mroute PREFIX NEXTHOP [DISTANCE]
567 .. index:: no ip mroute PREFIX NEXTHOP [DISTANCE]
568 .. clicmd:: no ip mroute PREFIX NEXTHOP [DISTANCE]
570 Adds a static route entry to the Multicast RIB. This performs exactly as the
571 ``ip route`` command, except that it inserts the route in the Multicast RIB
572 instead of the Unicast RIB.
574 .. _zebra-route-filtering:
576 zebra Route Filtering
577 =====================
579 Zebra supports :dfn:`prefix-list` s and :ref:`route-map` s to match routes
580 received from other FRR components. The permit/deny facilities provided by
581 these commands can be used to filter which routes zebra will install in the
584 .. index:: ip protocol PROTOCOL route-map ROUTEMAP
585 .. clicmd:: ip protocol PROTOCOL route-map ROUTEMAP
587 Apply a route-map filter to routes for the specified protocol. PROTOCOL can
602 .. index:: set src ADDRESS
603 .. clicmd:: set src ADDRESS
605 Within a route-map, set the preferred source address for matching routes
606 when installing in the kernel.
609 The following creates a prefix-list that matches all addresses, a route-map
610 that sets the preferred source address, and applies the route-map to all
615 ip prefix-list ANY permit 0.0.0.0/0 le 32
616 route-map RM1 permit 10
617 match ip address prefix-list ANY
620 ip protocol rip route-map RM1
623 .. _zebra-fib-push-interface:
625 zebra FIB push interface
626 ========================
628 Zebra supports a 'FIB push' interface that allows an external
629 component to learn the forwarding information computed by the FRR
630 routing suite. This is a loadable module that needs to be enabled
631 at startup as described in :ref:`loadable-module-support`.
633 In FRR, the Routing Information Base (RIB) resides inside
634 zebra. Routing protocols communicate their best routes to zebra, and
635 zebra computes the best route across protocols for each prefix. This
636 latter information makes up the Forwarding Information Base
637 (FIB). Zebra feeds the FIB to the kernel, which allows the IP stack in
638 the kernel to forward packets according to the routes computed by
639 FRR. The kernel FIB is updated in an OS-specific way. For example,
640 the `Netlink` interface is used on Linux, and route sockets are
643 The FIB push interface aims to provide a cross-platform mechanism to
644 support scenarios where the router has a forwarding path that is
645 distinct from the kernel, commonly a hardware-based fast path. In
646 these cases, the FIB needs to be maintained reliably in the fast path
647 as well. We refer to the component that programs the forwarding plane
648 (directly or indirectly) as the Forwarding Plane Manager or FPM.
650 The FIB push interface comprises of a TCP connection between zebra and
651 the FPM. The connection is initiated by zebra -- that is, the FPM acts
654 .. program:: configure
656 The relevant zebra code kicks in when zebra is configured with the
657 :option:`--enable-fpm` flag. Zebra periodically attempts to connect to
658 the well-known FPM port. Once the connection is up, zebra starts
659 sending messages containing routes over the socket to the FPM. Zebra
660 sends a complete copy of the forwarding table to the FPM, including
661 routes that it may have picked up from the kernel. The existing
662 interaction of zebra with the kernel remains unchanged -- that is, the
663 kernel continues to receive FIB updates as before.
665 The encapsulation header for the messages exchanged with the FPM is
666 defined by the file :file:`fpm/fpm.h` in the frr tree. The routes
667 themselves are encoded in Netlink or protobuf format, with Netlink
670 Protobuf is one of a number of new serialization formats wherein the
671 message schema is expressed in a purpose-built language. Code for
672 encoding/decoding to/from the wire format is generated from the
673 schema. Protobuf messages can be extended easily while maintaining
674 backward-compatibility with older code. Protobuf has the following
675 advantages over Netlink:
677 - Code for serialization/deserialization is generated automatically. This
678 reduces the likelihood of bugs, allows third-party programs to be integrated
679 quickly, and makes it easy to add fields.
680 - The message format is not tied to an OS (Linux), and can be evolved
683 As mentioned before, zebra encodes routes sent to the FPM in Netlink
684 format by default. The format can be controlled via the FPM module's
685 load-time option to zebra, which currently takes the values `Netlink`
688 The zebra FPM interface uses replace semantics. That is, if a 'route
689 add' message for a prefix is followed by another 'route add' message,
690 the information in the second message is complete by itself, and
691 replaces the information sent in the first message.
693 If the connection to the FPM goes down for some reason, zebra sends
694 the FPM a complete copy of the forwarding table(s) when it reconnects.
696 zebra Terminal Mode Commands
697 ============================
699 .. index:: show ip route
700 .. clicmd:: show ip route
702 Display current routes which zebra holds in its database.
706 Router# show ip route
707 Codes: K - kernel route, C - connected, S - static, R - RIP,
708 B - BGP * - FIB route.
710 K* 0.0.0.0/0 203.181.89.241
711 S 0.0.0.0/0 203.181.89.1
713 C* 203.181.89.240/28 eth0
716 .. index:: show ipv6 route
717 .. clicmd:: show ipv6 route
719 .. index:: show interface
720 .. clicmd:: show interface
722 .. index:: show ip prefix-list [NAME]
723 .. clicmd:: show ip prefix-list [NAME]
725 .. index:: show route-map [NAME]
726 .. clicmd:: show route-map [NAME]
728 .. index:: show ip protocol
729 .. clicmd:: show ip protocol
731 .. index:: show ipforward
732 .. clicmd:: show ipforward
734 Display whether the host's IP forwarding function is enabled or not.
735 Almost any UNIX kernel can be configured with IP forwarding disabled.
736 If so, the box can't work as a router.
738 .. index:: show ipv6forward
739 .. clicmd:: show ipv6forward
741 Display whether the host's IP v6 forwarding is enabled or not.
743 .. index:: show zebra
744 .. clicmd:: show zebra
746 Display various statistics related to the installation and deletion
747 of routes, neighbor updates, and LSP's into the kernel.
749 .. index:: show zebra fpm stats
750 .. clicmd:: show zebra fpm stats
752 Display statistics related to the zebra code that interacts with the
753 optional Forwarding Plane Manager (FPM) component.
755 .. index:: clear zebra fpm stats
756 .. clicmd:: clear zebra fpm stats
758 Reset statistics related to the zebra code that interacts with the
759 optional Forwarding Plane Manager (FPM) component.