* Invoking zebra:: Running the program
* Interface Commands:: Commands for zebra interfaces
* Static Route Commands:: Commands for adding static routes
+* Multicast RIB Commands:: Commands for controlling MRIB behavior
* zebra Route Filtering:: Commands for zebra route filtering
+* zebra FIB push interface:: Interface to optional FPM component
* zebra Terminal Mode Commands:: Commands for zebra's VTY
@end menu
@node Interface Commands
@section Interface Commands
+@menu
+* Standard Commands::
+* Link Parameters Commands::
+@end menu
+
+@node Standard Commands
+@subsection Standard Commands
+
@deffn Command {interface @var{ifname}} {}
@end deffn
@deffn {Interface Command} {bandwidth <1-10000000>} {}
@deffnx {Interface Command} {no bandwidth <1-10000000>} {}
-Set bandwidth value of the interface in kilobits/sec. This is for
-calculating OSPF cost. This command does not affect the actual device
+Set bandwidth value of the interface in kilobits/sec. This is for
+calculating OSPF cost. This command does not affect the actual device
configuration.
@end deffn
@deffn {Interface Command} {link-detect} {}
@deffnx {Interface Command} {no link-detect} {}
-Enable/disable link-detect on platforms which support this. Currently
+Enable/disable link-detect on platforms which support this. Currently
only Linux and Solaris, and only where network interface drivers support reporting
link-state via the IFF_RUNNING flag.
@end deffn
+@node Link Parameters Commands
+@subsection Link Parameters Commands
+
+@deffn {Interface Command} {link-params} {}
+@deffnx {Interface Command} {no link-param} {}
+Enter into the link parameters sub node. At least 'enable' must be set to activate the link parameters,
+and consequently Traffic Engineering on this interface. MPLS-TE must be enable at the OSPF (@ref{OSPF Traffic Engineering})
+or ISIS (@ref{ISIS Traffic Engineering}) router level in complement to this.
+Disable link parameters for this interface.
+@end deffn
+
+Under link parameter statement, the following commands set the different TE values:
+
+@deffn link-params {enable}
+Enable link parameters for this interface.
+@end deffn
+
+@deffn link-params {metric <0-4294967295>} {}
+@deffnx link-params {max-bw @var{bandwidth}} {}
+@deffnx link-params {max-rsv-bw @var{bandwidth}} {}
+@deffnx link-params {unrsv-bw <0-7> @var{bandwidth}} {}
+@deffnx link-params {admin-grp @var{bandwidth}} {}
+These commands specifies the Traffic Engineering parameters of the interface in conformity to RFC3630 (OSPF)
+or RFC5305 (ISIS).
+There are respectively the TE Metric (different from the OSPF or ISIS metric), Maximum Bandwidth (interface speed
+by default), Maximum Reservable Bandwidth, Unreserved Bandwidth for each 0-7 priority and Admin Group (ISIS) or
+Resource Class/Color (OSPF).
+
+Note that @var{bandwidth} are specified in IEEE floating point format and express in Bytes/second.
+@end deffn
+
+@deffn link-param {delay <0-16777215> [min <0-16777215> | max <0-16777215>]} {}
+@deffnx link-param {delay-variation <0-16777215>} {}
+@deffnx link-param {packet-loss @var{percentage}} {}
+@deffnx link-param {res-bw @var{bandwidth}} {}
+@deffnx link-param {ava-bw @var{bandwidth}} {}
+@deffnx link-param {use-bw @var{bandwidth}} {}
+These command specifies additionnal Traffic Engineering parameters of the interface in conformity to
+draft-ietf-ospf-te-metrics-extension-05.txt and draft-ietf-isis-te-metrics-extension-03.txt. There are
+respectively the delay, jitter, loss, available bandwidth, reservable bandwidth and utilized bandwidth.
+
+Note that @var{bandwidth} are specified in IEEE floating point format and express in Bytes/second.
+Delays and delay variation are express in micro-second (µs). Loss is specified in @var{percentage} ranging
+from 0 to 50.331642% by step of 0.000003.
+@end deffn
+
+@deffn link-param {neighbor <A.B.C.D> as <0-65535>} {}
+@deffnx link-param {no neighbor} {}
+Specifies the remote ASBR IP address and Autonomous System (AS) number for InterASv2 link in OSPF (RFC5392).
+Note that this option is not yet supported for ISIS (RFC5316).
+@end deffn
+
+
@node Static Route Commands
@section Static Route Commands
default) should the specified gateways not be reachable. Eg:
@example
-zebra> show ip route 10.0.0.0/8
+zebra> show ip route 10.0.0.0/8
Routing entry for 10.0.0.0/8
Known via "static", distance 1, metric 0
10.0.0.2 inactive
These behave similarly to their ipv4 counterparts.
@end deffn
+@deffn Command {ipv6 route @var{network} from @var{srcprefix} @var{gateway}} {}
+@deffnx Command {ipv6 route @var{network} from @var{srcprefix} @var{gateway} @var{distance}} {}
+Install a static source-specific route. These routes are currently supported
+on Linux operating systems only, and perform AND matching on packet's
+destination and source addresses in the kernel's forwarding path. Note that
+destination longest-prefix match is "more important" than source LPM, e.g.
+@command{"2001:db8:1::/64 from 2001:db8::/48"} will win over
+@command{"2001:db8::/48 from 2001:db8:1::/64"} if both match.
+@end deffn
+
@deffn Command {table @var{tableno}} {}
Select the primary kernel routing table to be used. This only works
for kernels supporting multiple routing tables (like GNU/Linux 2.2.x
-and later). After setting @var{tableno} with this command,
+and later). After setting @var{tableno} with this command,
static routes defined after this are added to the specified table.
@end deffn
+@node Multicast RIB Commands
+@section Multicast RIB Commands
+
+The Multicast RIB provides a separate table of unicast destinations which
+is used for Multicast Reverse Path Forwarding decisions. It is used with
+a multicast source's IP address, hence contains not multicast group
+addresses but unicast addresses.
+
+This table is fully separate from the default unicast table. However,
+RPF lookup can include the unicast table.
+
+WARNING: RPF lookup results are non-responsive in this version of Frr,
+i.e. multicast routing does not actively react to changes in underlying
+unicast topology!
+
+@deffn Command {ip multicast rpf-lookup-mode @var{mode}} {}
+@deffnx Command {no ip multicast rpf-lookup-mode [@var{mode}]} {}
+
+@var{mode} sets the method used to perform RPF lookups. Supported modes:
+
+@table @samp
+@item urib-only
+Performs the lookup on the Unicast RIB. The Multicast RIB is never used.
+@item mrib-only
+Performs the lookup on the Multicast RIB. The Unicast RIB is never used.
+@item mrib-then-urib
+Tries to perform the lookup on the Multicast RIB. If any route is found,
+that route is used. Otherwise, the Unicast RIB is tried.
+@item lower-distance
+Performs a lookup on the Multicast RIB and Unicast RIB each. The result
+with the lower administrative distance is used; if they're equal, the
+Multicast RIB takes precedence.
+@item longer-prefix
+Performs a lookup on the Multicast RIB and Unicast RIB each. The result
+with the longer prefix length is used; if they're equal, the
+Multicast RIB takes precedence.
+@end table
+
+The @code{mrib-then-urib} setting is the default behavior if nothing is
+configured. If this is the desired behavior, it should be explicitly
+configured to make the configuration immune against possible changes in
+what the default behavior is.
+
+WARNING: Unreachable routes do not receive special treatment and do not
+cause fallback to a second lookup.
+@end deffn
+
+@deffn Command {show ip rpf @var{addr}} {}
+
+Performs a Multicast RPF lookup, as configured with
+@command{ip multicast rpf-lookup-mode @var{mode}}. @var{addr} specifies
+the multicast source address to look up.
+
+@example
+> show ip rpf 192.0.2.1
+Routing entry for 192.0.2.0/24 using Unicast RIB
+ Known via "kernel", distance 0, metric 0, best
+ * 198.51.100.1, via eth0
+@end example
+
+Indicates that a multicast source lookup for 192.0.2.1 would use an
+Unicast RIB entry for 192.0.2.0/24 with a gateway of 198.51.100.1.
+@end deffn
+
+@deffn Command {show ip rpf} {}
+
+Prints the entire Multicast RIB. Note that this is independent of the
+configured RPF lookup mode, the Multicast RIB may be printed yet not
+used at all.
+@end deffn
+
+@deffn Command {ip mroute @var{prefix} @var{nexthop} [@var{distance}]} {}
+@deffnx Command {no ip mroute @var{prefix} @var{nexthop} [@var{distance}]} {}
+
+Adds a static route entry to the Multicast RIB. This performs exactly as
+the @command{ip route} command, except that it inserts the route in the
+Multicast RIB instead of the Unicast RIB.
+@end deffn
+
+
@node zebra Route Filtering
@section zebra Route Filtering
Zebra supports @command{prefix-list} and @command{route-map} to match
-routes received from other quagga components. The
+routes received from other frr components. The
@command{permit}/@command{deny} facilities provided by these commands
can be used to filter which routes zebra will install in the kernel.
@end group
@end example
+@node zebra FIB push interface
+@section zebra FIB push interface
+
+Zebra supports a 'FIB push' interface that allows an external
+component to learn the forwarding information computed by the Frr
+routing suite. This is a loadable module that needs to be enabled
+at startup as described in @ref{Loadable Module Support}.
+
+In Frr, the Routing Information Base (RIB) resides inside
+zebra. Routing protocols communicate their best routes to zebra, and
+zebra computes the best route across protocols for each prefix. This
+latter information makes up the Forwarding Information Base
+(FIB). Zebra feeds the FIB to the kernel, which allows the IP stack in
+the kernel to forward packets according to the routes computed by
+Frr. The kernel FIB is updated in an OS-specific way. For example,
+the @code{netlink} interface is used on Linux, and route sockets are
+used on FreeBSD.
+
+The FIB push interface aims to provide a cross-platform mechanism to
+support scenarios where the router has a forwarding path that is
+distinct from the kernel, commonly a hardware-based fast path. In
+these cases, the FIB needs to be maintained reliably in the fast path
+as well. We refer to the component that programs the forwarding plane
+(directly or indirectly) as the Forwarding Plane Manager or FPM.
+
+The FIB push interface comprises of a TCP connection between zebra and
+the FPM. The connection is initiated by zebra -- that is, the FPM acts
+as the TCP server.
+
+The relevant zebra code kicks in when zebra is configured with the
+@code{--enable-fpm} flag. Zebra periodically attempts to connect to
+the well-known FPM port. Once the connection is up, zebra starts
+sending messages containing routes over the socket to the FPM. Zebra
+sends a complete copy of the forwarding table to the FPM, including
+routes that it may have picked up from the kernel. The existing
+interaction of zebra with the kernel remains unchanged -- that is, the
+kernel continues to receive FIB updates as before.
+
+The encapsulation header for the messages exchanged with the FPM is
+defined by the file @file{fpm/fpm.h} in the frr tree. The routes
+themselves are encoded in netlink or protobuf format, with netlink
+being the default.
+
+Protobuf is one of a number of new serialization formats wherein the
+message schema is expressed in a purpose-built language. Code for
+encoding/decoding to/from the wire format is generated from the
+schema. Protobuf messages can be extended easily while maintaining
+backward-compatibility with older code. Protobuf has the following
+advantages over netlink:
+
+@itemize
+@item
+Code for serialization/deserialization is generated
+automatically. This reduces the likelihood of bugs, allows third-party
+programs to be integrated quickly, and makes it easy to add fields.
+@item
+The message format is not tied to an OS (Linux), and can be evolved
+independently.
+@end itemize
+
+As mentioned before, zebra encodes routes sent to the FPM in netlink
+format by default. The format can be controlled via the FPM module's
+load-time option to zebra, which currently takes the values @code{netlink}
+and @code{protobuf}.
+
+The zebra FPM interface uses replace semantics. That is, if a 'route
+add' message for a prefix is followed by another 'route add' message,
+the information in the second message is complete by itself, and
+replaces the information sent in the first message.
+
+If the connection to the FPM goes down for some reason, zebra sends
+the FPM a complete copy of the forwarding table(s) when it reconnects.
+
@node zebra Terminal Mode Commands
@section zebra Terminal Mode Commands
@example
@group
-Router# show ip route
-Codes: K - kernel route, C - connected, S - static, R - RIP,
+Router# show ip route
+Codes: K - kernel route, C - connected, S - static, R - RIP,
B - BGP * - FIB route.
K* 0.0.0.0/0 203.181.89.241
@deffn Command {show ipv6forward} {}
Display whether the host's IP v6 forwarding is enabled or not.
@end deffn
+
+@deffn Command {show zebra fpm stats} {}
+Display statistics related to the zebra code that interacts with the
+optional Forwarding Plane Manager (FPM) component.
+@end deffn
+
+@deffn Command {clear zebra fpm stats} {}
+Reset statistics related to the zebra code that interacts with the
+optional Forwarding Plane Manager (FPM) component.
+@end deffn
projects / mirror_frr.git / blobdiff