diff options
Diffstat (limited to 'doc/user')
33 files changed, 1725 insertions, 423 deletions
diff --git a/doc/user/.readthedocs.yaml b/doc/user/.readthedocs.yaml new file mode 100644 index 0000000000..ba5698c1d5 --- /dev/null +++ b/doc/user/.readthedocs.yaml @@ -0,0 +1,15 @@ +# Required +version: 2 + +# Set the version of Python and other tools you might need +build: + os: ubuntu-22.04 + tools: + python: "3.11" + +python: + install: + - requirements: doc/user/requirements.txt +# Build documentation in the docs/ directory with Sphinx +sphinx: + configuration: doc/user/conf.py diff --git a/doc/user/babeld.rst b/doc/user/babeld.rst index bda0045a60..b7b7c1fcb4 100644 --- a/doc/user/babeld.rst +++ b/doc/user/babeld.rst @@ -26,8 +26,7 @@ The *zebra* daemon must be running before *babeld* is invoked. Also, if *zebra* is restarted then *babeld* must be too. -Configuration of *babeld* is done in its configuration file -:file:`babeld.conf`. +.. include:: config-include.rst .. _babel-configuration: diff --git a/doc/user/basic.rst b/doc/user/basic.rst index 337cfff937..5fdd1887fa 100644 --- a/doc/user/basic.rst +++ b/doc/user/basic.rst @@ -11,45 +11,22 @@ The following sections discuss commands common to all the routing daemons. Config Commands =============== - - - - -In a config file, you can write the debugging options, a vty's password, +In the config file, you can write the debugging options, a vty's password, routing daemon configurations, a log file name, and so forth. This information forms the initial command set for a routing beast as it is starting. -Config files are generally found in |INSTALL_PREFIX_ETC|. +.. _config-file: -Config Methods --------------- - -There are two ways of configuring FRR. +Integrated Config File +---------------------- -Traditionally each of the daemons had its own config file. The daemon name plus -``.conf`` was the default config file name. For example, zebra's default config -file was :file:`zebra.conf`. This method is deprecated. - -Because of the amount of config files this creates, and the tendency of one -daemon to rely on others for certain functionality, most deployments now use -"integrated" configuration. In this setup all configuration goes into a single -file, typically :file:`/etc/frr/frr.conf`. When starting up FRR using an init -script or systemd, ``vtysh`` is invoked to read the config file and send the -appropriate portions to only the daemons interested in them. Running -configuration updates are persisted back to this single file using ``vtysh``. -This is the recommended method. To use this method, add the following line to -:file:`/etc/frr/vtysh.conf`: - -.. code-block:: frr - - service integrated-vtysh-config - -If you installed from source or used a package, this is probably already -present. - -If desired, you can specify a config file using the :option:`-f` or -:option:`--config_file` options when starting a daemon. +FRR uses a single configuration file located in |INSTALL_PREFIX_ETC|/frr.conf. +When FRR is started using an init script or ``systemd``, ``vtysh`` is invoked to +read the config file and send the appropriate portions to only the daemons +interested in them. Running configuration updates are persisted back to this +single file using ``vtysh`` as well. +.. include:: prior-config-files.rst .. _basic-config-commands: @@ -92,9 +69,6 @@ Basic Config Commands of some routine in FRR mistakenly blocking/hogging the processing loop and should be reported as a FRR bug. - The default limit is 5 seconds (i.e. 5000), but this can be changed by the - deprecated ``--enable-time-check=...`` compile-time option. - This command has no effect if :clicmd:`service cputime-stats` is disabled. .. clicmd:: service walltime-warning (1-4294967295) @@ -106,9 +80,6 @@ Basic Config Commands provide an immediate sign that FRR is not operating correctly due to externally caused starvation.) - The default limit is 5 seconds as above, including the same deprecated - ``--enable-time-check=...`` compile-time option. - .. clicmd:: log trap LEVEL These commands are deprecated and are present only for historical @@ -158,6 +129,20 @@ Basic Config Commands deprecated ``log trap`` command) will be used. The ``no`` form of the command disables logging to a file. +.. clicmd:: log daemon DAEMON file [FILENAME [LEVEL]] + + Configure file logging for a single FRR daemon. If you want to log + into a file, please specify ``filename`` as in this example: + + :: + + log daemon bgpd file /var/log/frr/bgpd.log informational + + If the optional second argument specifying the logging level is not present, + the default logging level (typically debugging, but can be changed using the + deprecated ``log trap`` command) will be used. The ``no`` form of the command + disables logging to a file for a single FRR daemon. + .. clicmd:: log syslog [LEVEL] Enable logging output to syslog. If the optional second argument specifying @@ -221,7 +206,7 @@ Basic Config Commands enabled log destinations. The note that logging includes full command lines, including passwords. If the daemon startup option `--command-log-always` is used to start the daemon then this command is turned on by default - and cannot be turned off and the [no] form of the command is dissallowed. + and cannot be turned off and the [no] form of the command is disallowed. .. clicmd:: log filtered-file [FILENAME [LEVEL]] @@ -679,25 +664,29 @@ Terminal Mode Commands .. _common-show-commands: -.. clicmd:: show thread cpu [r|w|t|e|x] +.. clicmd:: show event cpu [r|w|t|e|x] This command displays system run statistics for all the different event types. If no options is specified all different run types are displayed together. Additionally you can ask to look at (r)ead, (w)rite, (t)imer, - (e)vent and e(x)ecute thread event types. If you have compiled with - disable-cpu-time then this command will not show up. + (e)vent and e(x)ecute thread event types. -.. clicmd:: show thread poll +.. clicmd:: show event poll This command displays FRR's poll data. It allows a glimpse into how we are setting each individual fd for the poll command at that point in time. -.. clicmd:: show thread timers +.. clicmd:: show event timers This command displays FRR's timer data for timers that will pop in the future. +.. clicmd:: show configuration running [<json|xml> [translate WORD]] [with-defaults] DAEMON + + This command displays the northbound/YANG configuration data for a + daemon in text/vty, json, or xml format. + .. clicmd:: show yang operational-data XPATH [{format <json|xml>|translate TRANSLATOR|with-config}] DAEMON Display the YANG operational data starting from XPATH. The default @@ -780,7 +769,7 @@ These options apply to all |PACKAGE_NAME| daemons. .. option:: --command-log-always Cause the daemon to always log commands entered to the specified log file. - This also makes the `no log commands` command dissallowed. Enabling this + This also makes the `no log commands` command disallowed. Enabling this is suggested if you have need to track what the operator is doing on this router. diff --git a/doc/user/bfd.rst b/doc/user/bfd.rst index 1a42996771..3ca104a3a9 100644 --- a/doc/user/bfd.rst +++ b/doc/user/bfd.rst @@ -10,6 +10,7 @@ the following RFCs: * :rfc:`5880` * :rfc:`5881` +* :rfc:`5882` * :rfc:`5883` Currently, there are two implementations of the BFD commands in FRR: @@ -26,6 +27,8 @@ This document will focus on the later implementation: *bfdd*. Starting BFD ============ +.. include:: config-include.rst + *bfdd* default configuration file is :file:`bfdd.conf`. *bfdd* searches the current directory first then |INSTALL_PREFIX_ETC|/bfdd.conf. All of *bfdd*'s command must be configured in :file:`bfdd.conf`. @@ -43,9 +46,7 @@ may also be specified (:ref:`common-invocation-options`). /usr/lib/frr/bfdd --bfdctl /tmp/bfdd.sock - The default UNIX socket location is: - - #define BFDD_CONTROL_SOCKET "|INSTALL_PREFIX_STATE|/bfdd.sock" + The default UNIX socket location is |INSTALL_PREFIX_STATE|/bfdd.sock This option overrides the location addition that the -N option provides to the bfdd.sock @@ -224,12 +225,6 @@ BFD peers and profiles share the same BFD session configuration commands. BFD Peer Specific Commands -------------------------- -.. clicmd:: label WORD - - Labels a peer with the provided word. This word can be referenced - later on other daemons to refer to a specific peer. - - .. clicmd:: profile BFDPROF Configure peer to use the profile configurations. @@ -353,6 +348,33 @@ The following commands are available inside the interface configuration node. that interface. +.. _bfd-rip-peer-config: + +RIP BFD configuration +--------------------- + +The following commands are available inside the interface configuration node: + +.. clicmd:: ip rip bfd + + Automatically create BFD session for each RIP peer discovered in this + interface. When the BFD session monitor signalize that the link is down + the RIP peer is removed and all the learned routes associated with that + peer are removed. + + +.. clicmd:: ip rip bfd profile BFD_PROFILE_NAME + + Selects a BFD profile for the BFD sessions created in this interface. + + +The following command is available in the RIP router configuration node: + +.. clicmd:: bfd default-profile BFD_PROFILE_NAME + + Selects a default BFD profile for all sessions without a profile specified. + + .. _bfd-static-peer-config: BFD Static Route Monitoring Configuration @@ -415,7 +437,6 @@ Here is an example of BFD configuration: bfd peer 192.168.0.1 - label home-peer no shutdown ! ! @@ -429,7 +450,7 @@ Here is an example of BFD configuration: ! Peers can be identified by its address (use ``multihop`` when you need -to specify a multi hop peer) or can be specified manually by a label. +to specify a multi hop peer). Here are the available peer configurations: @@ -472,7 +493,6 @@ Here are the available peer configurations: ! configure a peer with every option possible peer 192.168.0.4 - label peer-label detect-multiplier 50 receive-interval 60000 transmit-interval 3000 @@ -520,7 +540,6 @@ You can inspect the current BFD peer status with the following commands: Echo receive interval: 50ms peer 192.168.1.1 - label: router3-peer ID: 2 Remote ID: 2 Status: up @@ -543,7 +562,6 @@ You can inspect the current BFD peer status with the following commands: frr# show bfd peer 192.168.1.1 BFD Peer: peer 192.168.1.1 - label: router3-peer ID: 2 Remote ID: 2 Status: up diff --git a/doc/user/bgp.rst b/doc/user/bgp.rst index 97d7ce6b75..4619fec6a7 100644 --- a/doc/user/bgp.rst +++ b/doc/user/bgp.rst @@ -14,10 +14,7 @@ interdomain routing protocol. BGP-4 is described in :rfc:`1771` and updated by Starting BGP ============ -The default configuration file of *bgpd* is :file:`bgpd.conf`. *bgpd* searches -the current directory first, followed by |INSTALL_PREFIX_ETC|/bgpd.conf. All of -*bgpd*'s commands must be configured in :file:`bgpd.conf` when the integrated -config is not being used. +.. include:: config-include.rst *bgpd* specific invocation options are described below. Common options may also be specified (:ref:`common-invocation-options`). @@ -86,6 +83,15 @@ be specified (:ref:`common-invocation-options`). be done to see if this is helping or not at the scale you are running at. +.. option:: --v6-with-v4-nexthops + + Allow BGP to peer in the V6 afi, when the interface only has v4 addresses. + This allows bgp to install the v6 routes with a v6 nexthop that has the + v4 address encoded in the nexthop. Zebra's equivalent option currently + overrides the bgp setting. This setting is only really usable when + the operator has turned off communication to zebra and is running bgpd + as a complete standalone process. + LABEL MANAGER ------------- @@ -452,10 +458,19 @@ Administrative Distance Metrics Sets the administrative distance for a particular route. + If the system has a static route configured from the kernel, it has a + distance of 0. In some cases, it might be useful to override the route + from the FRR. E.g.: Kernel has a statically configured default route, + and you received another default route from the BGP and want to install + it to be preferred over the static route. In such a case, you MUST set + a higher distance from the kernel. + + .. seealso:: :ref:`administrative-distance` + .. _bgp-requires-policy: Require policy on EBGP -------------------------------- +---------------------- .. clicmd:: bgp ebgp-requires-policy @@ -476,8 +491,8 @@ Require policy on EBGP exit1# show bgp summary - IPv4 Unicast Summary (VRF default): - BGP router identifier 10.10.10.1, local AS number 65001 vrf-id 0 + IPv4 Unicast Summary: + BGP router identifier 10.10.10.1, local AS number 65001 VRF default vrf-id 0 BGP table version 4 RIB entries 7, using 1344 bytes of memory Peers 2, using 43 KiB of memory @@ -509,6 +524,27 @@ Reject routes with AS_SET or AS_CONFED_SET types This command enables rejection of incoming and outgoing routes having AS_SET or AS_CONFED_SET type. +Enforce first AS +---------------- + +.. clicmd:: bgp enforce-first-as + + To configure a router to deny an update received from an external BGP (eBGP) + peer that does not list its autonomous system number at the beginning of + the `AS_PATH` in the incoming update, use the ``bgp enforce-first-as`` command + in router configuration mode. + + In order to exclude an arbitrary neighbor from this enforcement, use the + command ``no neighbor NAME enforce-first-as``. And vice-versa if a global + enforcement is disabled, you can override this behavior per neighbor too. + + Default: enabled. + +.. note:: + + If you have a peering to RS (Route-Server), most likely you MUST disable the + first AS enforcement. + Suppress duplicate updates -------------------------- @@ -831,7 +867,10 @@ The following functionality is provided by graceful restart: 1. The feature allows the restarting router to indicate to the helping peer the routes it can preserve in its forwarding plane during control plane restart by sending graceful restart capability in the OPEN message sent during - session establishment. + session establishment. Graceful restart notification flag and/or restart + time can also be changed during the dynamic BGP capabilities. If using + dynamic capabilities, no session reset is required, thus it's very useful + to increase restart time before doing a software upgrade or so. 2. The feature allows helping router to advertise to all other peers the routes received from the restarting router which are preserved in the forwarding plane of the restarting router during control plane restart. @@ -1020,7 +1059,7 @@ BGP GR Global Mode Commands This command will enable BGP graceful restart functionality at the global level. -.. clicmd:: bgp graceful-restart disable +.. clicmd:: bgp graceful-restart-disable This command will disable both the functionality graceful restart and helper mode. @@ -1288,10 +1327,31 @@ section for the specific AF to redistribute into. Protocol availability for redistribution is determined by BGP AF; for example, you cannot redistribute OSPFv3 into ``address-family ipv4 unicast`` as OSPFv3 supports IPv6. -.. clicmd:: redistribute <babel|connected|eigrp|isis|kernel|openfabric|ospf|ospf6|rip|ripng|sharp|static|table> [metric (0-4294967295)] [route-map WORD] +.. clicmd:: redistribute <babel|connected|eigrp|isis|kernel|openfabric|ospf|ospf6|rip|ripng|sharp|static> [metric (0-4294967295)] [route-map WORD] Redistribute routes from other protocols into BGP. +.. clicmd:: redistribute <table|table-direct> (1-65535)] [metric (0-4294967295)] [route-map WORD] + + Redistribute routes from a routing table ID into BGP. There are two + techniques for redistribution: + + - Standard Table Redistribution ``table (1-65535)``: + - Routes from the specified routing table ID are imported into the + default routing table using the ``ip import-table ID`` command. + - These routes are identified by the protocol type "T[ID]" when + displayed with ``show (ip|ipv6) route``. + - The ``redistribute table ID`` command then integrates these routes + into BGP. + + - Direct Table Redistribution ``table-direct (1-65535)``: + - This method directly imports routes from the designated routing table + ID into BGP, omitting the step of adding to the default routing table. + - This method is especially relevant when the specified table ID is + checked against routing by appending the appropriate `ip rules`. + +Redistribute routes from a routing table number into BGP. + .. clicmd:: redistribute vnc-direct Redistribute VNC direct (not via zebra) routes to BGP process. @@ -1411,6 +1471,23 @@ Defining Peers peers ASN is the same as mine as specified under the :clicmd:`router bgp ASN` command the connection will be denied. +.. clicmd:: neighbor PEER oad + + Mark a peer belonging to the One Administrative Domain. + + Some networks span more than one autonomous system and require more + flexibility in the propagation of path attributes.It is worth noting that + these multi-AS networks have a common or single administrative entity. + These networks are said to belong to One Administrative Domain (OAD). + It is desirable to carry IBGP-only attributes across EBGP peerings when + the peers belong to an OAD. + + Enabling this peering sub-type will allow the propagation of non-transitive + attributes across EBGP peerings (e.g. local-preference). Make sure to + turn this peering type on for all peers in the OAD. + + Disabled by default. + .. clicmd:: bgp listen range <A.B.C.D/M|X:X::X:X/M> peer-group PGNAME Accept connections from any peers in the specified prefix. Configuration @@ -1483,6 +1560,16 @@ Configuring Peers value is carried encoded as uint32. To enable backward compatibility we need to disable IEEE floating-point encoding option per-peer. +.. clicmd:: neighbor PEER enforce-first-as + + Discard updates received from the specified (eBGP) peer if the AS_PATH + attribute does not contain the PEER's ASN as the first AS_PATH segment. + + You can enable or disable this enforcement globally too using + ``bgp enforce-first-as`` command. + + Default: enabled. + .. clicmd:: neighbor PEER extended-optional-parameters Force Extended Optional Parameters Length format to be used for OPEN messages. @@ -1517,7 +1604,10 @@ Configuring Peers Configure an unnumbered BGP peer. ``PEER`` should be an interface name. The session will be established via IPv6 link locals. Use ``internal`` for iBGP - and ``external`` for eBGP sessions, or specify an ASN if you wish. + and ``external`` for eBGP sessions, or specify an ASN if you wish. Finally + this connection type is meant for point to point connections. If you are + on an ethernet segment and attempt to use this with more than one bgp + neighbor, only one neighbor will come up, due to how this feature works. .. clicmd:: neighbor PEER next-hop-self [force] @@ -1536,10 +1626,12 @@ Configuring Peers .. clicmd:: neighbor PEER update-source <IFNAME|ADDRESS> - Specify the IPv4 source address to use for the :abbr:`BGP` session to this - neighbour, may be specified as either an IPv4 address directly or as an + Specify the IPv4 or IPv6 source address to use for the :abbr:`BGP` session to this + neighbour, may be specified as either an IP address directly or as an interface name (in which case the *zebra* daemon MUST be running in order - for *bgpd* to be able to retrieve interface state). + for *bgpd* to be able to retrieve interface state). When there are multiple + addresses on the choosen IFNAME then BGP will use the address that matches + the most number of bits in comparison to the destination peer address. .. code-block:: frr @@ -1582,7 +1674,18 @@ Configuring Peers modifying the `net.core.optmem_max` sysctl to a larger value to avoid out of memory errors from the linux kernel. -.. clicmd:: neighbor PEER send-community +.. clicmd:: neighbor PEER send-community <both|all|extended|standard|large> + + Send the communities to the peer. + + Default: enabled. + +.. clicmd:: neighbor PEER send-community extended rpki + + Send the extended RPKI communities to the peer. RPKI extended community + can be send only to iBGP and eBGP-OAD peers. + + Default: enabled. .. clicmd:: neighbor PEER weight WEIGHT @@ -1669,10 +1772,25 @@ Configuring Peers Configure BGP to send best known paths to neighbor in order to preserve multi path capabilities inside a network. +.. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> addpath-tx-best-selected (1-6) + + Configure BGP to calculate and send N best known paths to the neighbor. + .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> disable-addpath-rx Do not accept additional paths from this neighbor. +.. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> addpath-rx-paths-limit (1-65535) + + Limit the maximum number of paths a BGP speaker can receive from a peer, optimizing + the transmission of BGP routes by selectively relaying pertinent routes instead of + the entire set. + + If this command is configured, the sender will only send the number of paths specified + in PATHS-LIMIT capability. + + To exchange this limit, both peers must support the PATHS-LIMIT capability. + .. clicmd:: neighbor PEER ttl-security hops NUMBER This command enforces Generalized TTL Security Mechanism (GTSM), as @@ -1688,6 +1806,28 @@ Configuring Peers turning on this command will allow BGP to install v4 routes with v6 nexthops if you do not have v4 configured on interfaces. +.. clicmd:: neighbor PEER capability dynamic + + Allow BGP to negotiate the Dynamic Capability with its peers. + + Dynamic Capability defines a new BGP message (CAPABILITY) that can be used + to set/unset BGP capabilities without bringing down a BGP session. + + This includes changing graceful-restart (LLGR also) timers, + enabling/disabling add-path, and other supported capabilities. + +.. clicmd:: neighbor PEER capability fqdn + + Allow BGP to negotiate the FQDN Capability with its peers. + + FQDN Capability defines a new BGP message (CAPABILITY) allowing the + use of peer's name and domain name. + + This capability is activated by default. The ``no neighbor PEER capability + fqdn`` avoid negotiation of that capability. This is useful for peers who + are not supporting this capability or supporting BGP Capabilities + Negotiation RFC 2842. + .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> accept-own Enable handling of self-originated VPN routes containing ``accept-own`` community. @@ -1729,6 +1869,12 @@ Configuring Peers and will not be displayed as part of a `show run`. The no form of the command turns off this ability. +.. clicmd:: bgp default-originate timer (0-3600) + + Set the period to rerun the default-originate route-map scanner process. The + default is 5 seconds. With a full routing table, it might be useful to increase + this setting to avoid scanning the whole BGP table aggressively. + .. clicmd:: bgp default ipv4-unicast This command allows the user to specify that the IPv4 Unicast address @@ -1803,6 +1949,35 @@ Configuring Peers outputs. It's easier to troubleshoot if you have a number of BGP peers and a number of routes to check. +.. clicmd:: bgp default dynamic-capability + + This command enables dynamic capability advertisement by default + for all the neighbors. + + For ``datacenter`` profile, this is enabled by default. + +.. clicmd:: bgp default software-version-capability + + This command enables software version capability advertisement by default + for all the neighbors. + + For ``datacenter`` profile, this is enabled by default. + + .. code-block:: frr + + IPv4 Unicast Summary: + BGP router identifier 10.0.0.6, local AS number 65001 VRF default vrf-id 0 + BGP table version 12 + RIB entries 23, using 4600 bytes of memory + Peers 3, using 2174 KiB of memory + + Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc + 10.0.0.4 4 65001 20 22 12 0 0 00:00:11 5 12 FRRouting/8.5.1 + 10.0.0.5 4 65001 21 22 12 0 0 00:00:11 5 12 FRRouting/9.0 + 192.168.67.7 4 65001 27 31 12 0 0 00:00:23 2 10 FRRouting/9.1-dev-MyOwnFRRVersion-g3c8c08dcd9 + + Total number of neighbors 3 + .. clicmd:: neighbor PEER advertisement-interval (0-600) Setup the minimum route advertisement interval(mrai) for the @@ -1989,7 +2164,6 @@ Capability Negotiation .. clicmd:: neighbor PEER strict-capability-match - Strictly compares remote capabilities and local capabilities. If capabilities are different, send Unsupported Capability error then reset connection. @@ -2032,6 +2206,13 @@ Capability Negotiation Disabled by default. +.. clicmd:: neighbor PEER aigp + + Send and receive AIGP attribute for this neighbor. This is valid only for + eBGP neighbors. + + Disabled by default. iBGP neighbors have this option enabled implicitly. + .. _bgp-as-path-access-lists: AS Path Access Lists @@ -2088,10 +2269,31 @@ Using AS Path in Route Map Prepend the existing last AS number (the leftmost ASN) to the AS_PATH. The no form of this command removes this set operation from the route-map. -.. clicmd:: set as-path replace <any|ASN> +.. clicmd:: set as-path replace <any|ASN> [<ASN>] + + Replace a specific AS number to local AS number or a configured AS number. + ``any`` replaces each AS number in the AS-PATH with either the local AS + number or the configured AS number. + +.. clicmd:: set as-path replace as-path-access-list WORD [<ASN>] + + Replace some AS numbers from the AS_PATH of the BGP path's NLRI. Substituted + AS numbers are conformant with the regex defined in as-path access-list + WORD. Changed AS numbers are replaced either by the local AS number or the + configured AS number. + The no form of this command removes this set operation from the route-map. + +.. clicmd:: set as-path exclude all + + Remove all AS numbers from the AS_PATH of the BGP path's NLRI. The no form of + this command removes this set operation from the route-map. + +.. clicmd:: set as-path exclude as-path-access-list WORD + + Remove some AS numbers from the AS_PATH of the BGP path's NLRI. Removed AS + numbers are conformant with the regex defined in as-path access-list WORD. + The no form of this command removes this set operation from the route-map. - Replace a specific AS number to local AS number. ``any`` replaces each - AS number in the AS-PATH with the local AS number. .. _bgp-communities-attribute: @@ -2584,11 +2786,23 @@ BGP Extended Communities in Route Map .. clicmd:: set extcommunity rt EXTCOMMUNITY - This command set Route Target value. + This command sets Route Target value. + +.. clicmd:: set extcommunity nt EXTCOMMUNITY + + This command sets Node Target value. + + If the receiving BGP router supports Node Target Extended Communities, + it will install the route with the community that contains it's own + local BGP Identifier. Otherwise, it's not installed. .. clicmd:: set extcommunity soo EXTCOMMUNITY - This command set Site of Origin value. + This command sets Site of Origin value. + +.. clicmd:: set extcomumnity color EXTCOMMUNITY + + This command sets colors values. .. clicmd:: set extcommunity bandwidth <(1-25600) | cumulative | num-multipaths> [non-transitive] @@ -2772,7 +2986,7 @@ Labeled unicast *bgpd* supports labeled information, as per :rfc:`3107`. -.. clicmd:: bgp labeled-unicast explicit-null +.. clicmd:: bgp labeled-unicast <explicit-null|ipv4-explicit-null|ipv6-explicit-null> By default, locally advertised prefixes use the `implicit-null` label to encode in the outgoing NLRI. The following command uses the `explicit-null` @@ -2876,12 +3090,45 @@ address-family: Specifies the route-target list to be attached to a route (export) or the route-target list to match against (import) when exporting/importing between - the current unicast VRF and VPN. + the current unicast VRF and VPN. The `rt vpn export RTLIST` command is not + mandatory and can be replaced or completed by the `set extcommunity rt` + command in the route-map attached with the `route-map vpn export`. The below + configuration illustrates how the route target is selected based on the + prefixes, and not solely on vrf criterium: + + .. code-block:: frr + + access-list acl1 permit 192.0.2.0/24 + access-list acl2 permit 192.0.3.0/24 + route-map rmap permit 10 + match address acl1 + set extcommunity rt 65001:10 + ! + route-map rmap permit 20 + match address acl1 + set extcommunity rt 65001:20 + ! + router bgp 65001 vrf vrf1 + ! + address-family ipv4 unicast + rd vpn export 65001:1 + import vpn + export vpn + rt vpn import 65001:1 + route-map vpn export rmap + The RTLIST is a space-separated list of route-targets, which are BGP extended community values as described in :ref:`bgp-extended-communities-attribute`. +.. clicmd:: label vpn export allocation-mode per-vrf|per-nexthop + + Select how labels are allocated in the given VRF. By default, the `per-vrf` + mode is selected, and one label is used for all prefixes from the VRF. The + `per-nexthop` will use a unique label for all prefixes that are reachable + via the same nexthop. + .. clicmd:: label vpn export (0..1048575)|auto Enables an MPLS label to be attached to a route exported from the current @@ -2945,6 +3192,14 @@ by issuing the following command under the interface configuration context. This configuration will install VPN prefixes originated from an e-bgp session, and with the next-hop directly connected. +.. clicmd:: mpls bgp l3vpn-multi-domain-switching + +Redistribute labeled L3VPN routes from AS to neighboring AS (RFC-4364 option +B, or within the same AS when the iBGP peer uses ``next-hop-self`` to rewrite +the next-hop attribute). The labeled L3VPN routes received on this interface are +re-advertised with local labels and an MPLS table swap entry is set to bind +the local label to the received label. + .. _bgp-l3vpn-srv6: L3VPN SRv6 @@ -2959,6 +3214,31 @@ L3VPN SRv6 Specify the SRv6 locator to be used for SRv6 L3VPN. The Locator name must be set in zebra, but user can set it in any order. +L3VPN SRv6 SID reachability +--------------------------- + +In the context of IPv4 L3VPN over SRv6 specific usecase, 2001:db8:12::2 +is the peer IPv6 address of r2, and 2001:db8:2:2:: is the SRv6 SID +advertised by router r2 for prefix P. On r1, the SID reachability is +checked in order to install the prefix P. The below output indicates +that the 2001:db8:2:2:: prefix is valid. + + +.. code-block:: frr + + r1# show bgp nexthop detail + Current BGP nexthop cache: + 2001:db8:2:2:: valid [IGP metric 0], #paths 4 + gate 2001:db8:12::2, if eth0 + Last update: Tue Nov 14 10:36:28 2023 + Paths: + 1/1 192.168.2.0/24 VRF vrf10 flags 0x4018 + 1/3 192.168.2.0/24 RD 65002:10 VRF default flags 0x418 + 2001:db8:12::2 valid [IGP metric 0], #paths 0, peer 2001:db8:12::2 + if eth0 + Last update: Tue Nov 14 10:36:26 2023 + Paths: + General configuration ^^^^^^^^^^^^^^^^^^^^^ @@ -3201,6 +3481,77 @@ Example configuration: exit-address-family ! +.. _bgp-evpn-mac-vrf-site-of-origin: + +EVPN MAC-VRF Site-of-Origin +^^^^^^^^^^^^^^^^^^^^^^^^^^^ +In some EVPN deployments it is useful to associate a logical VTEP's Layer 2 +domain (MAC-VRF) with a Site-of-Origin "site" identifier. This provides a +BGP topology-independent means of marking and import-filtering EVPN routes +originated from a particular L2 domain. One situation where this is valuable +is when deploying EVPN using anycast VTEPs, i.e. Active/Active MLAG, as it +can be used to avoid ownership conflicts between the two control planes +(EVPN vs MLAG). + +Example Use Case (MLAG Anycast VTEPs): + +During normal operation, an MLAG VTEP will advertise EVPN routes for attached +hosts using a shared anycast IP as the BGP next-hop. It is expected for its +MLAG peer to drop routes originated by the MLAG Peer since they have a Martian +(self) next-hop. However, prior to the anycast IP being assigned to the local +system, the anycast BGP next-hop will not be considered a Martian (self) IP. +This results in a timing window where hosts that are locally attached to the +MLAG pair's L2 domain can be learned both as "local" (via MLAG) or "remote" +(via an EVPN route with a non-local next-hop). This can trigger erroneous MAC +Mobility events, as the host "moves" between one MLAG Peer's Unique VTEP-IP +and the shared anycast VTEP-IP, which causes unnecessary control plane and +data plane events to propagate throughout the EVPN domain. +By associating the MAC-VRF of both MLAG VTEPs with the same site identifier, +EVPN routes originated by one MLAG VTEP will ignored by its MLAG peer, ensuring +that only the MLAG control plane attempts to take ownership of local hosts. + +The EVPN MAC-VRF Site-of-Origin feature works by influencing two behaviors: + +1. All EVPN routes originating from the local MAC-VRF will have a + Site-of-Origin extended community added to the route, matching the + configured value. +2. EVPN routes will be subjected to a "self SoO" check during MAC-VRF + or IP-VRF import processing. If the EVPN route is found to carry a + Site-of-Origin extended community whose value matches the locally + configured MAC-VRF Site-of-Origin, the route will be maintained in + the global EVPN RIB ("show bgp l2vpn evpn route") but will not be + imported into the corresponding MAC-VRF ("show bgp vni") or IP-VRF + ("show bgp [vrf <vrfname>] [ipv4 | ipv6 [unicast]]"). + +The import filtering described in item (2) is constrained just to Type-2 +(MAC-IP) and Type-3 (IMET) EVPN routes. + +The EVPN MAC-VRF Site-of-Origin can be configured using a single CLI command +under ``address-family l2vpn evpn`` of the EVPN underlay BGP instance. + +.. clicmd:: mac-vrf soo <site-of-origin-string> + +Example configuration: + +.. code-block:: frr + + router bgp 100 + neighbor 192.168.0.1 remote-as 101 + ! + address-family ipv4 l2vpn evpn + neighbor 192.168.0.1 activate + advertise-all-vni + mac-vrf soo 100.64.0.0:777 + exit-address-family + +This configuration ensures: + +1. EVPN routes originated from a local L2VNI will have a Site-of-Origin + extended community with the value ``100.64.0.0:777`` +2. Received EVPN routes carrying a Site-of-Origin extended community with the + value ``100.64.0.0:777`` will not be imported into a local MAC-VRF (L2VNI) + or IP-VRF (L3VNI). + .. _bgp-evpn-mh: EVPN Multihoming @@ -3324,7 +3675,7 @@ route maybe fragmented. The number of EVIs per-EAD route can be configured via the following BGP command - -.. clicmd:: [no] ead-es-frag evi-limit (1-1000) +.. clicmd:: ead-es-frag evi-limit (1-1000) Sample Configuration ^^^^^^^^^^^^^^^^^^^^^ @@ -3502,7 +3853,7 @@ When default route is present in R2'2 BGP table, 10.139.224.0/20 and 192.0.2.1/3 *> 192.0.2.1/32 10.10.10.1 0 0 1 i *> 192.0.2.5/32 10.10.10.1 0 0 1 i - Displayed 4 routes and 4 total paths + Displayed 4 routes and 4 total paths Router2# show ip bgp neighbors 10.10.20.3 !--- Output suppressed. @@ -3550,7 +3901,7 @@ When default route is not present in R2'2 BGP table, 10.139.224.0/20 and 192.0.2 *> 192.0.2.1/32 10.10.10.1 0 0 1 i *> 192.0.2.5/32 10.10.10.1 0 0 1 i - Displayed 3 routes and 3 total paths + Displayed 3 routes and 3 total paths Router2# show ip bgp neighbors 10.10.20.3 @@ -3619,12 +3970,20 @@ Debugging information on BGP events such as peer connection / disconnection, session establishment / teardown, and capability negotiation. -.. clicmd:: debug bgp updates +.. clicmd:: debug bgp updates [detail] Enable or disable debugging for BGP updates. This provides information on BGP UPDATE messages transmitted and received between local and remote instances. + If ``detail`` is specified, the output will include the full BGP UPDATE with + detailed information such as attribute length, withdraw length, and more. + +.. clicmd:: debug bgp updates <in|out> [<A.B.C.D|X:X::X:X|WORD> [prefix-list WORD]] + + Enable or disable debugging for BGP updates. Optionally, you can specify + a prefix-list to filter the updates for an arbitrary neighbor. + .. clicmd:: debug bgp keepalives Enable or disable debugging for BGP keepalives. This provides information on @@ -3725,6 +4084,26 @@ The following are available in the top level *enable* mode: Clear BGP message statistics for a specified peer or for all peers, optionally filtered by activated address-family and sub-address-family. +.. clicmd:: clear bgp [ipv4|ipv6] [unicast] PEER|\* capabilities + + Clear specific BGP capabilities for a specified peer or for all peers. This + includes such capabilities like FQDN capability, that can't be controlled by + any other configuration knob. + + For example, if you want to change the FQDN, you MUST reset the BGP session + in order to send a new FQDN capability to the peer. This command allows you + to resend FQDN capability without resetting the session. + + .. code-block:: frr + + hostname bgp-new.example.com + clear bgp 10.10.10.1 capabilities + +.. note:: + + Changing the hostname is possible only when connected to the specific daemon. + If you change the hostname via ``vtysh``, it won't be changed. + The following are available in the ``router bgp`` mode: .. clicmd:: write-quanta (1-64) @@ -3848,8 +4227,8 @@ structure is extended with :clicmd:`show bgp [afi] [safi]`. exit1# show ip bgp summary wide - IPv4 Unicast Summary (VRF default): - BGP router identifier 192.168.100.1, local AS number 65534 vrf-id 0 + IPv4 Unicast Summary: + BGP router identifier 192.168.100.1, local AS number 65534 VRF default vrf-id 0 BGP table version 3 RIB entries 5, using 920 bytes of memory Peers 1, using 27 KiB of memory @@ -3860,6 +4239,12 @@ structure is extended with :clicmd:`show bgp [afi] [safi]`. Total number of neighbors 1 exit1# +If PfxRcd and/or PfxSnt is shown as ``(Policy)``, that means that the EBGP +default policy is turned on, but you don't have any filters applied for +incoming/outgoing directions. + +.. seealso:: :ref:`bgp-requires-policy` + .. clicmd:: show bgp [afi] [safi] [all] [wide|json] .. clicmd:: show bgp vrfs [<VRFNAME$vrf_name>] [json] @@ -4101,6 +4486,122 @@ structure is extended with :clicmd:`show bgp [afi] [safi]`. If ``afi`` is specified, with ``all`` option, routes will be displayed for each SAFI in the selected AFI. +.. clicmd:: show [ip] bgp [<view|vrf> VIEWVRFNAME] [afi] [safi] detail [json] + + Display the detailed version of all routes from the specified bgp vrf table + for a given afi + safi. + + If no vrf is specified, then it is assumed as a default vrf and routes + are displayed from default vrf table. + + If ``all`` option is specified as vrf name, then all bgp vrf tables routes + from a given afi+safi are displayed in the detailed output of routes. + + If ``json`` option is specified, detailed output is displayed in JSON format. + + Following are sample output for few examples of how to use this command. + +.. code-block:: frr + + torm-23# sh bgp ipv4 unicast detail (OR) sh bgp vrf default ipv4 unicast detail + + !--- Output suppressed. + + BGP routing table entry for 172.16.16.1/32 + Paths: (1 available, best #1, table default) + Not advertised to any peer + Local, (Received from a RR-client) + 172.16.16.1 (metric 20) from torm-22(172.16.16.1) (192.168.0.10) + Origin IGP, metric 0, localpref 100, valid, internal + Last update: Fri May 8 12:54:05 2023 + BGP routing table entry for 172.16.16.2/32 + Paths: (1 available, best #1, table default) + Not advertised to any peer + Local + 0.0.0.0 from 0.0.0.0 (172.16.16.2) + Origin incomplete, metric 0, weight 32768, valid, sourced, bestpath-from-AS Local, best (First path received) + Last update: Wed May 8 12:54:41 2023 + + Displayed 2 routes and 2 total paths + +.. code-block:: frr + + torm-23# sh bgp vrf all detail + + Instance default: + + !--- Output suppressed. + + BGP routing table entry for 172.16.16.1/32 + Paths: (1 available, best #1, table default) + Not advertised to any peer + Local, (Received from a RR-client) + 172.16.16.1 (metric 20) from torm-22(172.16.16.1) (192.168.0.10) + Origin IGP, metric 0, localpref 100, valid, internal + Last update: Fri May 8 12:44:05 2023 + BGP routing table entry for 172.16.16.2/32 + Paths: (1 available, best #1, table default) + Not advertised to any peer + Local + 0.0.0.0 from 0.0.0.0 (172.16.16.2) + Origin incomplete, metric 0, weight 32768, valid, sourced, bestpath-from-AS Local, best (First path received) + Last update: Wed May 8 12:45:01 2023 + + Displayed 2 routes and 2 total paths + + Instance vrf3: + + !--- Output suppressed. + + BGP routing table entry for 192.168.0.2/32 + Paths: (1 available, best #1, vrf vrf3) + Not advertised to any peer + Imported from 172.16.16.1:12:[2]:[0]:[48]:[00:02:00:00:00:58]:[32]:[192.168.0.2], VNI 1008/4003 + Local + 172.16.16.1 from torm-22(172.16.16.1) (172.16.16.1) announce-nh-self + Origin IGP, localpref 100, valid, internal, bestpath-from-AS Local, best (First path received) + Extended Community: RT:65000:1008 ET:8 Rmac:00:02:00:00:00:58 + Last update: Fri May 8 02:41:55 2023 + BGP routing table entry for 192.168.1.2/32 + Paths: (1 available, best #1, vrf vrf3) + Not advertised to any peer + Imported from 172.16.16.1:13:[2]:[0]:[48]:[00:02:00:00:00:58]:[32]:[192.168.1.2], VNI 1009/4003 + Local + 172.16.16.1 from torm-22(172.16.16.1) (172.16.16.1) announce-nh-self + Origin IGP, localpref 100, valid, internal, bestpath-from-AS Local, best (First path received) + Extended Community: RT:65000:1009 ET:8 Rmac:00:02:00:00:00:58 + Last update: Fri May 8 02:41:55 2023 + + Displayed 2 routes and 2 total paths + + +.. code-block:: frr + + torm-23# sh bgp vrf vrf3 ipv4 unicast detail + + !--- Output suppressed. + + BGP routing table entry for 192.168.0.2/32 + Paths: (1 available, best #1, vrf vrf3) + Not advertised to any peer + Imported from 172.16.16.1:12:[2]:[0]:[48]:[00:02:00:00:00:58]:[32]:[192.168.0.2], VNI 1008/4003 + Local + 172.16.16.1 from torm-22(172.16.16.1) (172.16.16.1) announce-nh-self + Origin IGP, localpref 100, valid, internal, bestpath-from-AS Local, best (First path received) + Extended Community: RT:65000:1008 ET:8 Rmac:00:02:00:00:00:58 + Last update: Fri May 8 02:23:35 2023 + BGP routing table entry for 192.168.1.2/32 + Paths: (1 available, best #1, vrf vrf3) + Not advertised to any peer + Imported from 172.16.16.1:13:[2]:[0]:[48]:[00:02:00:00:00:58]:[32]:[192.168.1.2], VNI 1009/4003 + Local + 172.16.16.1 from torm-22(172.16.16.1) (172.16.16.1) announce-nh-self + Origin IGP, localpref 100, valid, internal, bestpath-from-AS Local, best (First path received) + Extended Community: RT:65000:1009 ET:8 Rmac:00:02:00:00:00:58 + Last update: Fri May 8 02:23:55 2023 + + Displayed 2 routes and 2 total paths + .. _bgp-display-routes-by-community: Displaying Routes by Community Attribute diff --git a/doc/user/bmp.rst b/doc/user/bmp.rst index 1983995c1f..0f46832059 100644 --- a/doc/user/bmp.rst +++ b/doc/user/bmp.rst @@ -36,8 +36,8 @@ The `BMP` implementation in FRR has the following properties: successfully. OPEN messages for failed sessions cannot currently be mirrored. -- **route monitoring** is available for IPv4 and IPv6 AFIs, unicast and - multicast SAFIs. Other SAFIs (VPN, Labeled-Unicast, Flowspec, etc.) are not +- **route monitoring** is available for IPv4 and IPv6 AFIs, unicast, multicast, + EVPN and VPN SAFIs. Other SAFIs (VPN, Labeled-Unicast, Flowspec, etc.) are not currently supported. - monitoring peers that have BGP **add-path** enabled on the session will @@ -146,10 +146,10 @@ associated with a particular ``bmp targets``: Send BMP Statistics (counter) messages at the specified interval (in milliseconds.) -.. clicmd:: bmp monitor AFI SAFI <pre-policy|post-policy> +.. clicmd:: bmp monitor AFI SAFI <pre-policy|post-policy|loc-rib> Perform Route Monitoring for the specified AFI and SAFI. Only IPv4 and - IPv6 are currently valid for AFI. SAFI valid values are currently + IPv6 are currently valid for AFI. SAFI valid values are currently unicast, multicast, evpn and vpn. Other AFI/SAFI combinations may be added in the future. diff --git a/doc/user/config-include.rst b/doc/user/config-include.rst new file mode 100644 index 0000000000..3a341513b4 --- /dev/null +++ b/doc/user/config-include.rst @@ -0,0 +1,12 @@ +.. +.. January 12 2024, Christian Hopps <chopps@labn.net> +.. +.. Copyright (c) 2024, LabN Consulting, L.L.C. +.. +.. + +Configuration for the daemon should be saved in the FRR integrated configuration +file located in |INSTALL_PREFIX_ETC|/frr.conf, see :ref:`config-file` for more +information on system configuration. + +.. include:: prior-config-files.rst diff --git a/doc/user/eigrpd.rst b/doc/user/eigrpd.rst index fa157c4659..58a2957ad0 100644 --- a/doc/user/eigrpd.rst +++ b/doc/user/eigrpd.rst @@ -24,21 +24,17 @@ known topology. Starting and Stopping eigrpd ============================ -The default configuration file name of *eigrpd*'s is :file:`eigrpd.conf`. When -invocation *eigrpd* searches directory |INSTALL_PREFIX_ETC|. If -:file:`eigrpd.conf` is not there next search current directory. If an -integrated config is specified configuration is written into :file:`frr.conf`. +.. include:: config-include.rst -The EIGRP protocol requires interface information maintained by *zebra* daemon. -So running *zebra* is mandatory to run *eigrpd*. Thus minimum sequence for -running EIGRP is: +If starting daemons by hand then please note, the EIGRP protocol requires +interface information maintained by *zebra* daemon. So running *zebra* is +mandatory to run *eigrpd*. Thus minimum sequence for running EIGRP is: :: # zebra -d # eigrpd -d - Please note that *zebra* must be invoked before *eigrpd*. To stop *eigrpd*, please use:: diff --git a/doc/user/installation.rst b/doc/user/installation.rst index 2310d397cd..d17112d8aa 100644 --- a/doc/user/installation.rst +++ b/doc/user/installation.rst @@ -234,10 +234,9 @@ options from the list below. assigned to the realm. See the tc man page. This option is currently not compatible with the usage of nexthop groups in the linux kernel itself. -.. option:: --disable-irdp +.. option:: --enable-irdp - Disable IRDP server support. This is enabled by default if we have - both `struct in_pktinfo` and `struct icmphdr` available to us. + Enable IRDP server support. This is deprecated. .. option:: --disable-rtadv @@ -275,6 +274,10 @@ options from the list below. Build with FPM module support. +.. option:: --enable-fpm-listener + + Build a small fpm listener for testing. + .. option:: --with-service-timeout=X Set timeout value for FRR service. The time of restarting or reloading FRR @@ -310,13 +313,6 @@ options from the list below. make these arrays at build time. Additionally if this parameter is not passed in FRR will default to 16 ECMP. -.. option:: --enable-shell-access - - Turn on the ability of FRR to access some shell options( telnet/ssh/bash/etc. ) - from vtysh itself. This option is considered extremely unsecure and should only - be considered for usage if you really really know what you are doing. This - option is deprecated and will be removed on Feb 1, 2024. - .. option:: --enable-gcov Code coverage reports from gcov require adjustments to the C and LD flags. @@ -330,11 +326,6 @@ options from the list below. Build with configuration rollback support. Requires SQLite3. -.. option:: --enable-confd=<dir> - - Build the ConfD northbound plugin. Look for the libconfd libs and headers - in `dir`. - .. option:: --enable-sysrepo Build the Sysrepo northbound plugin. @@ -351,20 +342,6 @@ options from the list below. Use libpam for PAM support in vtysh. -.. option:: --enable-time-check XXX - - This option is deprecated as it was replaced by the - :clicmd:`service cputime-stats` CLI command, which may be adjusted at - runtime rather than being a compile-time setting. See there for further - detail. - -.. option:: --disable-cpu-time - - This option is deprecated as it was replaced by the - :clicmd:`service cputime-warning NNN` CLI command, which may be adjusted at - runtime rather than being a compile-time setting. See there for further - detail. - .. option:: --enable-pcreposix Turn on the usage of PCRE Posix libs for regex functionality. @@ -390,19 +367,38 @@ and the configuration files in :file:`/usr/local/etc`. The :file:`/usr/local/` installation prefix and other directories may be changed using the following options to the configuration script. +.. option:: --enable-ccls + + Enable the creation of a :file:`.ccls` file in the top level source + directory. + + Some development environments (e.g., LSP server within emacs, et al.) can + utilize :clicmd:`ccls` to provide highly sophisticated IDE features (e.g., + semantically accurate jump-to definition/reference, and even code + refactoring). The `--enable-ccls` causes :file:`configure` to generate a + configuration for the :clicmd:`ccls` command, based on the configured + FRR build environment. + .. option:: --prefix <prefix> Install architecture-independent files in `prefix` [/usr/local]. .. option:: --sysconfdir <dir> - Look for configuration files in `dir` [`prefix`/etc]. Note that sample - configuration files will be installed here. + Look for configuration files in `dir`/frr [`prefix`/etc]. Note that sample + configuration files will be installed here. Should be ``/etc`` unless + your platform splits package configuration locations. .. option:: --localstatedir <dir> - Configure zebra to use `dir` for local state files, such as pid files and - unix sockets. + Configure base directory for local state. Indirectly controls + ``--runstatedir``. Should be ``/var`` in most cases. + +.. option:: --runstatedir <dir> + + Configure FRR to use `dir`/frr for local state files, such as pid files and + unix sockets. Should be ``/var/run`` (default through ``--localstatedir``) + or ``/run`` in most cases. .. option:: --with-scriptdir <dir> @@ -581,9 +577,9 @@ the options you chose: ./configure \ --prefix=/usr \ - --localstatedir=/var/run/frr \ + --sysconfdir=/etc \ + --localstatedir=/var \ --sbindir=/usr/lib/frr \ - --sysconfdir=/etc/frr \ --enable-pimd \ --enable-watchfrr \ ... diff --git a/doc/user/isisd.rst b/doc/user/isisd.rst index 570b8bd182..40669a3c02 100644 --- a/doc/user/isisd.rst +++ b/doc/user/isisd.rst @@ -22,8 +22,7 @@ interface information from *zebra* in order to function. Therefore *zebra* must be running before invoking *isisd*. Also, if *zebra* is restarted then *isisd* must be too. -Like other daemons, *isisd* configuration is done in :abbr:`ISIS` specific -configuration file :file:`isisd.conf`. +.. include:: config-include.rst .. _isis-router: @@ -124,7 +123,7 @@ ISIS Timer Set LSP refresh interval in seconds, globally, for an area (level-1) or a domain (level-2). -.. clicmd:: max-lsp-lifetime [level-1 | level-2] (360-65535) +.. clicmd:: max-lsp-lifetime [level-1 | level-2] (350-65535) Set LSP maximum LSP lifetime in seconds, globally, for an area (level-1) or a domain (level-2). @@ -166,6 +165,11 @@ flavors (local LFA, Remote LFA and TI-LFA). Configure a prefix-list to select eligible PQ nodes for remote LFA backups (valid for all protected interfaces). +.. clicmd:: redistribute <ipv4 | ipv6> table (1-65535) <level-1 | level-2> [metric (0-16777215)|route-map WORD] + + Redistribute routes from a given routing table into the given ISIS + level database. + .. _isis-region: ISIS region @@ -220,17 +224,17 @@ ISIS interface Add padding to IS-IS hello packets during adjacency formation only. -.. clicmd:: isis hello-interval (1-600) [level-1 | level-2] +.. clicmd:: isis hello-interval [level-1 | level-2] (1-600) Set Hello interval in seconds globally, for an area (level-1) or a domain (level-2). -.. clicmd:: isis hello-multiplier (2-100) [level-1 | level-2] +.. clicmd:: isis hello-multiplier [level-1 | level-2] (2-100) Set multiplier for Hello holding time globally, for an area (level-1) or a domain (level-2). -.. clicmd:: isis metric [(0-255) | (0-16777215)] [level-1 | level-2] +.. clicmd:: isis metric [level-1 | level-2] [(0-255) | (0-16777215)] Set default metric value globally, for an area (level-1) or a domain (level-2). Max value depend if metric support narrow or wide value (see @@ -297,7 +301,7 @@ Showing ISIS information Show summary information about ISIS. -.. clicmd:: show isis hostname +.. clicmd:: show isis [vrf <NAME|all>] hostname Show information about ISIS node. @@ -316,17 +320,17 @@ Showing ISIS information Show the ISIS database globally, for a specific LSP id without or with details. -.. clicmd:: show isis topology [level-1|level-2] [algorithm (128-255)] +.. clicmd:: show isis [vrf <NAME|all>] topology [level-1|level-2] [algorithm [(128-255)]] Show topology IS-IS paths to Intermediate Systems, globally, in area (level-1) or domain (level-2). -.. clicmd:: show isis route [level-1|level-2] [prefix-sid|backup] [algorithm (128-255)] +.. clicmd:: show isis [vrf <NAME|all>] route [level-1|level-2] [prefix-sid|backup] [algorithm [(128-255)]] Show the ISIS routing table, as determined by the most recent SPF calculation. -.. clicmd:: show isis fast-reroute summary [level-1|level-2] +.. clicmd:: show isis [vrf <NAME|all>] fast-reroute summary [level-1|level-2] Show information about the number of prefixes having LFA protection, and network-wide LFA coverage. @@ -431,7 +435,7 @@ Known limitations: clear the Node flag that is set by default for Prefix-SIDs associated to loopback addresses. This option is necessary to configure Anycast-SIDs. -.. clicmd:: show isis segment-routing node [algorithm (128-255)] +.. clicmd:: show isis segment-routing node [algorithm [(128-255)]] Show detailed information about all learned Segment Routing Nodes. @@ -589,6 +593,40 @@ The following command show Flex-Algo information: includes an 'algorithm (128-255)' optional argument. See :ref:`showing-isis-information` and :ref:`isis-segment-routing`. +.. _isis-srv6: + +Segment Routing over IPv6 (SRv6) +================================ + +This feature enables extensions in IS-IS to support Segment Routing over IPv6 +data plane (SRv6) as per RFC 9352. + +.. clicmd:: segment-routing srv6 + + Enable Segment Routing over IPv6 data plane (SRv6). + +.. clicmd:: locator NAME + + Specify the SRv6 locator to use for SRv6. The locator must be configured in + Zebra. Once the locator is configured, IS-IS automatically allocates prefix + SID and adjacency SIDs, creates local SID entries in the data plane, and + advertises them in the IGP domain. + +.. clicmd:: interface NAME + + Specify the dummy interface used to install SRv6 SIDs in the Linux data plane. + The interface must be created manually. By default, the interface is 'sr0'. + The interface can be created using the iproute2 utility: + + .. code-block:: bash + + ip link add sr0 type dummy + ip link set sr0 up + +.. clicmd:: show isis segment-routing srv6 node + + Show detailed information about all learned SRv6 Nodes. + Debugging ISIS ============== @@ -769,6 +807,33 @@ A Segment Routing configuration, with IPv4, IPv6, SRGB and MSD configuration. segment-routing prefix 2001:db8:1000::1/128 index 101 explicit-null ! +An SRv6 configuration: + +.. code-block:: frr + + hostname HOSTNAME + password PASSWORD + log file /var/log/isisd.log + ! + ! + interface eth0 + ipv6 router isis FOO + ip router isis FOO + isis hello-interval 5 + ! + interface eth1 + ip router isis FOO + ! + ! + router isis FOO + net 49.0001.1111.1111.1111.00 + is-type level-2-only + metric-style wide + segment-routing srv6 + locator loc1 + ! + line vty + .. _isis-vrf-config-examples: diff --git a/doc/user/ldpd.rst b/doc/user/ldpd.rst index 682443a456..cbed734e42 100644 --- a/doc/user/ldpd.rst +++ b/doc/user/ldpd.rst @@ -32,9 +32,7 @@ options (:ref:`common-invocation-options`). The *zebra* daemon must be running before *ldpd* is invoked. -Configuration of *ldpd* is done in its configuration file -:file:`ldpd.conf`. - +.. include:: config-include.rst .. _understanding-ldp: diff --git a/doc/user/mgmtd.rst b/doc/user/mgmtd.rst index 6614a568f8..aa7ccaac3a 100644 --- a/doc/user/mgmtd.rst +++ b/doc/user/mgmtd.rst @@ -356,7 +356,7 @@ MGMT Show commands Currenlty supported values for 'candidate' and 'running' only ('operational' shall be supported in future soon). -.. clicmd:: show mgmt database-contents [candidate|operation|running] [xpath WORD] [file WORD] json|xml +.. clicmd:: show mgmt datastore-contents [candidate|operation|running] [xpath WORD] [file WORD] json|xml This command dumps the subtree pointed by the xpath in JSON or XML format. If filepath is not present then the tree will be printed on the shell. @@ -364,3 +364,46 @@ MGMT Show commands .. clicmd:: show mgmt commit-history This command dumps details of upto last 10 commits handled by MGMTd. + + +MGMT Daemon debug commands +========================== + +The following debug commands enable debugging within the management daemon: + +.. clicmd:: debug mgmt backend + + Enable[/Disable] debugging messages related to backend operations within the + management daemon. + +.. clicmd:: debug mgmt datastore + + Enable[/Disable] debugging messages related to YANG datastore operations + within the management daemon. + +.. clicmd:: debug mgmt frontend + + Enable[/Disable] debugging messages related to frontend operations within the + management daemon. + +.. clicmd:: debug mgmt transaction + + Enable[/Disable] debugging messages related to transactions within the + management daemon. + + +MGMT Client debug commands +========================== + +The following debug commands enable debugging within the management front and +backend clients: + +.. clicmd:: debug mgmt client backend + + Enable[/Disable] debugging messages related to backend operations inside the + backend mgmtd clients. + +.. clicmd:: debug mgmt client frontend + + Enable[/Disable] debugging messages related to frontend operations inside the + frontend mgmtd clients. diff --git a/doc/user/ospf6d.rst b/doc/user/ospf6d.rst index 8dacb9c9dc..ea41ba53b3 100644 --- a/doc/user/ospf6d.rst +++ b/doc/user/ospf6d.rst @@ -9,8 +9,13 @@ described in :rfc:`2740`. .. _ospf6-router: -OSPF6 router -============ +Configuring OSPF6 +***************** + +.. include:: config-include.rst + +Configuration Commands +====================== .. clicmd:: router ospf6 [vrf NAME] @@ -287,6 +292,19 @@ OSPF6 interface Sets interface's Router Dead Interval. Default value is 40. +.. clicmd:: ipv6 ospf6 graceful-restart hello-delay HELLODELAYINTERVAL + + Set the length of time during which Grace-LSAs are sent at 1-second intervals + while coming back up after an unplanned outage. During this time, no hello + packets are sent. + + A higher hello delay will increase the chance that all neighbors are notified + about the ongoing graceful restart before receiving a hello packet (which is + crucial for the graceful restart to succeed). The hello delay shouldn't be set + too high, however, otherwise the adjacencies might time out. As a best practice, + it's recommended to set the hello delay and hello interval with the same values. + The default value is 10 seconds. + .. clicmd:: ipv6 ospf6 retransmit-interval RETRANSMITINTERVAL Sets interface's Rxmt Interval. Default value is 5. @@ -299,10 +317,135 @@ OSPF6 interface Sets interface's Inf-Trans-Delay. Default value is 1. -.. clicmd:: ipv6 ospf6 network (broadcast|point-to-point) +.. clicmd:: ipv6 ospf6 network (broadcast|point-to-point|point-to-multipoint) Set explicitly network type for specified interface. + The only functional difference between ``point-to-point`` (PtP) and + ``point-to-multipoint`` (PtMP) mode is the packet addressing for database + flooding and updates. PtP will use multicast packets while PtMP will + unicast them. Apart from this, + :clicmd:`ipv6 ospf6 p2p-p2mp connected-prefixes <include|exclude>` has a + different default for PtP and PtMP. There are no other differences, in + particular FRR does not impose a limit of one neighbor in PtP mode. + + FRR does not support NBMA mode for IPv6 and likely never will, as NBMA is + considered deprecated for IPv6. Refer to `this IETF OSPF working group + discussion + <https://mailarchive.ietf.org/arch/msg/ospf/8GAbr4qSMMt5J7SvAcZQ1H7ARhk/>`_ + for context. + +OSPF6 point-to-point and point-to-multipoint operation +====================================================== + +OSPFv3, by default, operates in broadcast mode where it elects a DR and BDR +for each network segment. This can be changed to point-to-point (PtP) / +point-to-multipoint (PtMP) mode by configuration. The actual physical +interface characteristics do not matter for this setting, all interfaces can +be configured for all modes. However, routers must be configured for the same +mode to form adjacencies. + +The main advantages of PtP/PtMP mode are: + +- no DR/BDR election +- adjacencies can be suppressed in a pairwise manner for any two routers, e.g. + to represent the underlying topology if it isn't a true full mesh +- distinct costs can be set for each pair of routers and direction + +The main downside is less efficient flooding on networks with a large number +of OSPFv3 routers. + +.. warning:: + + All options in this section should be considered "advanced" configuration + options. Inconsistent or nonsensical combinations can easily result in a + non-functional setup. + +.. clicmd:: ipv6 ospf6 p2p-p2mp disable-multicast-hello + + Disables sending normal multicast hellos when in PtP/PtMP mode. Some + vendors do this automatically for PtMP mode while others have a separate + ``no-broadcast`` option matching this. + + If this setting is used, you must issue + :clicmd:`ipv6 ospf6 neighbor X:X::X:X poll-interval (1-65535)` for each + neighbor to send unicast hello packets. + +.. clicmd:: ipv6 ospf6 p2p-p2mp config-neighbors-only + + Only form adjacencies with neighbors that are explicitly configured with + the :clicmd:`ipv6 ospf6 neighbor X:X::X:X` command. Hellos from other + routers are ignored. + + .. warning:: + + This setting is not intended to provide any security benefit. Do not + run OSPFv3 over untrusted links without additional security measures + (e.g. IPsec.) + +.. clicmd:: ipv6 ospf6 p2p-p2mp connected-prefixes <include|exclude> + + For global/ULA prefixes configured on this interfaces, do (not) advertise + the full prefix to the area. Regardless of this setting, the router's own + address, as a /128 host route with the "LA" (Local Address) bit set, will + always be advertised. + + The default is to include connected prefixes for PtP mode and exclude them + for PtMP mode. Since these prefixes will cover other router's addresses, + these addresses can become unreachable if the link is partitioned if the + other router does not advertise the address as a /128. However, conversely, + if all routers have this flag set, the overall prefix will not be advertised + anywhere. End hosts on this link will therefore be unreachable (and + blackholing best-practices for non-existing prefixes apply.) It may be + preferable to have only one router announce the connected prefix. + + The Link LSA (which is not propagated into the area) always includes all + prefixes on the interface. This setting only affects the Router LSA that + is visible to all routers in the area. + + .. note:: + + Before interacting with this setting, consider either not configuring + any global/ULA IPv6 address on the interface, or directly configuring a + /128 if needed. OSPFv3 relies exclusively on link-local addresses to do + its signaling and there is absolutely no reason to configure global/ULA + addresses as far as OSPFv3 is concerned. + +.. clicmd:: ipv6 ospf6 neighbor X:X::X:X + + Explicitly configure a neighbor by its link-local address on this interface. + This statement has no effect other than allowing an adjacency when + :clicmd:`ipv6 ospf6 p2p-p2mp config-neighbors-only` is set. This command + does **not** cause unicast hellos to be sent. + + Only link-local addresses can be used to establish explicit neighbors. + When using this command, you should probably assign static IPv6 link-local + addresses to all routers on this link. It would technically be possible to + use the neighbor's Router ID (IPv4 address) here to ease working with + changing link-local addresses but this is not planned as a feature at the + time of writing. Global/ULA IPv6 addresses cannot be supported here due to + the way OSPFv3 works. + +.. clicmd:: ipv6 ospf6 neighbor X:X::X:X poll-interval (1-65535) + + Send unicast hellos to this neighbor at the specified interval (in seconds.) + The interval is only used while there is no adjacency with this neighbor. + As soon as an adjacency is formed, the interface's + :clicmd:`ipv6 ospf6 hello-interval HELLOINTERVAL` value is used. + (``hello-interval`` must be the same on all routers on this link.) + + :rfc:`2328` recommends a "much larger" value than ``hello-interval`` for + this setting, but this is a legacy of ATM and X.25 networks and nowadays you + should probably just use the same value as for ``hello-interval``. + +.. clicmd:: ipv6 ospf6 neighbor X:X::X:X cost (1-65535) + + Use a distinct cost for paths traversing this neighbor. The default is + to use the interface's cost value (which may be automatically calculated + based on link bandwidth.) Note that costs are directional in OSPF and the + reverse direction must be set on the other router. + + OSPF6 route-map =============== @@ -343,15 +486,19 @@ Graceful Restart To perform a graceful shutdown, the "graceful-restart prepare ipv6 ospf" EXEC-level command needs to be issued before restarting the ospf6d daemon. + When Graceful Restart is enabled and the ospf6d daemon crashes or is killed + abruptely (e.g. SIGKILL), it will attempt an unplanned Graceful Restart once + it restarts. + .. clicmd:: graceful-restart helper enable [A.B.C.D] Configure Graceful Restart (RFC 5187) helper support. - By default, helper support is disabled for all neighbours. + By default, helper support is disabled for all neighbors. This config enables/disables helper support on this router - for all neighbours. + for all neighbors. To enable/disable helper support for a specific - neighbour, the router-id (A.B.C.D) has to be specified. + neighbor, the router-id (A.B.C.D) has to be specified. .. clicmd:: graceful-restart helper strict-lsa-checking diff --git a/doc/user/ospf_fundamentals.rst b/doc/user/ospf_fundamentals.rst index c566059121..3032d2771e 100644 --- a/doc/user/ospf_fundamentals.rst +++ b/doc/user/ospf_fundamentals.rst @@ -12,7 +12,7 @@ OSPF Fundamentals :term:`distance-vector` protocols, such as :abbr:`RIP` or :abbr:`BGP`, where routers describe available `paths` (i.e. routes) to each other, in :term:`link-state` protocols routers instead describe the state of their links -to their immediate neighbouring routers. +to their immediate neighboring routers. .. index:: single: Link State Announcement @@ -127,7 +127,7 @@ LSA Flooding """""""""""" OSPF defines several related mechanisms, used to manage synchronisation of -:abbr:`LSDB` s between neighbours as neighbours form adjacencies and the +:abbr:`LSDB` s between neighbors as neighbors form adjacencies and the propagation, or `flooding` of new or updated :abbr:`LSA` s. @@ -259,7 +259,7 @@ called `intra-area routes`. LSA is originated for such a link. Stub - A link with no adjacent neighbours, or a host route. + A link with no adjacent neighbors, or a host route. - Link ID and Data @@ -339,8 +339,8 @@ The example below shows two :abbr:`LSA` s, both originated by the same router of different LSA types. The first LSA being the router LSA describing 192.168.0.49's links: 2 links -to multi-access networks with fully-adjacent neighbours (i.e. Transit -links) and 1 being a Stub link (no adjacent neighbours). +to multi-access networks with fully-adjacent neighbors (i.e. Transit +links) and 1 being a Stub link (no adjacent neighbors). The second LSA being a Network LSA, for which 192.168.0.49 is the :abbr:`DR`, listing the Router IDs of 4 routers on that network which diff --git a/doc/user/ospfd.rst b/doc/user/ospfd.rst index 5171832604..47f8fad17b 100644 --- a/doc/user/ospfd.rst +++ b/doc/user/ospfd.rst @@ -32,8 +32,7 @@ Configuring OSPF Therefore *zebra* must be running before invoking *ospfd*. Also, if *zebra* is restarted then *ospfd* must be too. -Like other daemons, *ospfd* configuration is done in :abbr:`OSPF` specific -configuration file :file:`ospfd.conf` when the integrated config is not used. +.. include:: config-include.rst .. _ospf-multi-instance: @@ -240,6 +239,17 @@ To start OSPF process you have to specify the OSPF router. This configuration setting MUST be consistent across all routers within the OSPF domain. +.. clicmd:: neighbor A.B.C.D [poll-interval (1-65535)] [priority (0-255)] + + + Configures OSPF neighbors for non-broadcast multi-access (NBMA) networks + and point-to-multipoint non-broadcast networks. The `poll-interval` + specifies the rate for sending hello packets to neighbors that are not + active. When the configured neighbor is discovered, hello packets will be + sent at the rate of the hello-interval. The default `poll-interval` is 60 + seconds. The `priority` is used to for the Designated Router (DR) election + on non-broadcast multi-access networks. + .. clicmd:: network A.B.C.D/M area A.B.C.D .. clicmd:: network A.B.C.D/M area (0-4294967295) @@ -314,7 +324,7 @@ To start OSPF process you have to specify the OSPF router. This command controls the ospf instance's socket buffer sizes. The 'no' form resets one or both values to the default. - + .. clicmd:: no socket-per-interface Ordinarily, ospfd uses a socket per interface for sending @@ -581,7 +591,7 @@ Interfaces Note that OSPF MD5 authentication requires that time never go backwards (correct time is NOT important, only that it never goes backwards), even across resets, if ospfd is to be able to promptly reestablish adjacencies - with its neighbours after restarts/reboots. The host should have system time + with its neighbors after restarts/reboots. The host should have system time be set at boot from an external or non-volatile source (e.g. battery backed clock, NTP, etc.) or else the system clock should be periodically saved to non-volatile storage and restored at boot if MD5 authentication is to be @@ -599,6 +609,38 @@ Interfaces KEY is the actual message digest key, of up to 16 chars (larger strings will be truncated), and is associated with the given KEYID. +.. clicmd:: ip ospf authentication key-chain KEYCHAIN + + Specify that HMAC cryptographic authentication must be used on this interface + using a key chain. Overrides any authentication enabled on a per-area basis + (:clicmd:`area A.B.C.D authentication message-digest`). + + ``KEYCHAIN``: Specifies the name of the key chain that contains the authentication + key(s) and cryptographic algorithms to be used for OSPF authentication. The key chain + is a logical container that holds one or more authentication keys, + allowing for key rotation and management. + + Note that OSPF HMAC cryptographic authentication requires that time never go backwards + (correct time is NOT important, only that it never goes backwards), even + across resets, if ospfd is to be able to promptly reestablish adjacencies + with its neighbors after restarts/reboots. The host should have system time + be set at boot from an external or non-volatile source (e.g. battery backed + clock, NTP, etc.) or else the system clock should be periodically saved to + non-volatile storage and restored at boot if HMAC cryptographic authentication is to be + expected to work reliably. + + Example: + + .. code:: sh + + r1(config)#key chain temp + r1(config-keychain)#key 13 + r1(config-keychain-key)#key-string ospf + r1(config-keychain-key)#cryptographic-algorithm hmac-sha-256 + r1(config)#int eth0 + r1(config-if)#ip ospf authentication key-chain temp + r1(config-if)#ip ospf area 0 + .. clicmd:: ip ospf cost (1-65535) @@ -635,7 +677,20 @@ Interfaces :clicmd:`ip ospf dead-interval minimal hello-multiplier (2-20)` is also specified for the interface. -.. clicmd:: ip ospf network (broadcast|non-broadcast|point-to-multipoint|point-to-point [dmvpn]) +.. clicmd:: ip ospf graceful-restart hello-delay (1-1800) + + Set the length of time during which Grace-LSAs are sent at 1-second intervals + while coming back up after an unplanned outage. During this time, no hello + packets are sent. + + A higher hello delay will increase the chance that all neighbors are notified + about the ongoing graceful restart before receiving a hello packet (which is + crucial for the graceful restart to succeed). The hello delay shouldn't be set + too high, however, otherwise the adjacencies might time out. As a best practice, + it's recommended to set the hello delay and hello interval with the same values. + The default value is 10 seconds. + +.. clicmd:: ip ospf network (broadcast|non-broadcast|point-to-multipoint [delay-reflood|non-broadcast]|point-to-point [dmvpn]) When configuring a point-to-point network on an interface and the interface has a /32 address associated with then OSPF will treat the interface @@ -647,6 +702,20 @@ Interfaces point-to-point, but the HUB will be a point-to-multipoint. To make this topology work, specify the optional 'dmvpn' parameter at the spoke. + When the network is configured as point-to-multipoint and `non-broadcast` + is specified, the network doesn't support broadcast or multicast delivery + and neighbors cannot be discovered from OSPF hello received from the + OSPFAllRouters (224.0.0.5). Rather, they must be explicitly configured + using the :clicmd:`neighbor A.B.C.D` configuration command as they are + on non-broadcast networks. + + When the network is configured as point-to-multipoint and `delay-reflood` + is specified, LSAs received on the interface from neighbors on the + interface will not be flooded back out on the interface immediately. + Rather, they will be added to the neighbor's link state retransmission + list and only sent to the neighbor if the neighbor doesn't acknowledge + the LSA prior to the link state retransmission timer expiring. + Set explicitly network type for specified interface. .. clicmd:: ip ospf priority (0-255) @@ -679,6 +748,15 @@ Interfaces OSPF (:ref:`redistribute-routes-to-ospf`). This is the only way to advertise non-OSPF links into stub areas. +.. clicmd:: ip ospf prefix-suppression [A.B.C.D] + + Configure OSPF to not advertise the IPv4 prefix associated with the + OSPF interface. The associated IPv4 prefix will be omitted from an OSPF + router-LSA or advertised with a host mask in an OSPF network-LSA as + specified in RFC 6860, "Hiding Transit-Only Networks in OSPF". If an + optional IPv4 address is specified, the prefix suppression will apply + to the OSPF interface associated with the specified interface address. + .. clicmd:: ip ospf area (A.B.C.D|(0-4294967295)) @@ -770,15 +848,19 @@ Graceful Restart To perform a graceful shutdown, the "graceful-restart prepare ip ospf" EXEC-level command needs to be issued before restarting the ospfd daemon. + When Graceful Restart is enabled and the ospfd daemon crashes or is killed + abruptely (e.g. SIGKILL), it will attempt an unplanned Graceful Restart once + it restarts. + .. clicmd:: graceful-restart helper enable [A.B.C.D] Configure Graceful Restart (RFC 3623) helper support. - By default, helper support is disabled for all neighbours. + By default, helper support is disabled for all neighbors. This config enables/disables helper support on this router - for all neighbours. + for all neighbors. To enable/disable helper support for a specific - neighbour, the router-id (A.B.C.D) has to be specified. + neighbor, the router-id (A.B.C.D) has to be specified. .. clicmd:: graceful-restart helper strict-lsa-checking @@ -788,7 +870,7 @@ Graceful Restart affects the restarting router. By default 'strict-lsa-checking' is enabled" -.. clicmd:: graceful-restart helper supported-grace-time +.. clicmd:: graceful-restart helper supported-grace-time (10-1800) Supports as HELPER for configured grace period. @@ -860,10 +942,11 @@ Showing Information Show detailed information about the OSPF link-state database. -.. clicmd:: show ip ospf route [json] +.. clicmd:: show ip ospf route [detail] [json] Show the OSPF routing table, as determined by the most recent SPF - calculation. + calculation. When detail option is used, it shows more information + to the CLI like advertising router ID for each route, etc. .. clicmd:: show ip ospf [vrf <NAME|all>] border-routers [json] @@ -874,7 +957,7 @@ Showing Information .. clicmd:: show ip ospf graceful-restart helper [detail] [json] - Displays the Grcaeful Restart Helper details including helper + Displays the Graceful Restart Helper details including helper config changes. .. _opaque-lsa: @@ -888,7 +971,7 @@ Opaque LSA - *ospfd* supports Opaque LSA (:rfc:`2370`) as partial support for + *ospfd* supports Opaque LSA (:rfc:`5250`) as partial support for MPLS Traffic Engineering LSAs. The opaque-lsa capability must be enabled in the configuration. An alternate command could be "mpls-te on" (:ref:`ospf-traffic-engineering`). Note that FRR @@ -896,6 +979,18 @@ Opaque LSA extensions that are used with MPLS-TE; it does not support a complete RSVP-TE solution. +.. clicmd:: ip ospf capability opaque [A.B.C.D] + + Enable or disable OSPF LSA database exchange and flooding on an interface. + The default is that opaque capability is enabled as long as the opaque + capability is enabled with the :clicmd:`capability opaque` command at the + OSPF instance level (using the command above). Note that disabling opaque + LSA support on an interface will impact the applications using opaque LSAs + if the opaque LSAs are not received on other flooding paths by all the + OSPF routers using those applications. For example, OSPF Graceful Restart + uses opaque-link LSAs and disabling support on an interface will disable + graceful restart signaling on that interface. + .. clicmd:: show ip ospf [vrf <NAME|all>] database (opaque-link|opaque-area|opaque-external) .. clicmd:: show ip ospf [vrf <NAME|all>] database (opaque-link|opaque-area|opaque-external) LINK-STATE-ID @@ -1005,7 +1100,7 @@ Router Information respectively the PCE IP address, Autonomous System (AS) numbers of controlled domains, neighbor ASs, flag and scope. For flag and scope, please refer to :rfc`5088` for the BITPATTERN recognition. Multiple 'pce neighbor' - command could be specified in order to specify all PCE neighbours. + command could be specified in order to specify all PCE neighbors. .. clicmd:: show ip ospf router-info diff --git a/doc/user/overview.rst b/doc/user/overview.rst index 5ea33d62c9..2ef88acd7a 100644 --- a/doc/user/overview.rst +++ b/doc/user/overview.rst @@ -358,6 +358,8 @@ BGP :t:`Outbound Route Filtering Capability. E. Chen, Y. Rekhter. August 2008.` - :rfc:`5292` :t:`Address-Prefix-Based Outbound Route Filter for BGP-4. E. Chen, S. Sangli. August 2008.` +- :rfc:`5396` + :t:`Textual Representation of Autonomous System (AS) Numbers. G. Michaelson, G. Huston. December 2008.` - :rfc:`5492` :t:`Capabilities Advertisement with BGP-4. J. Scudder, R. Chandra. February 2009.` - :rfc:`5575` @@ -426,6 +428,8 @@ BGP :t:`Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages. A. Azimov, E. Bogomazov, R. Bush, K. Patel, K. Sriram. May 2022.` - :rfc:`9384` :t:`A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection (BFD). J. Haas. March 2023.` +- :rfc:`9494` + :t:`Long-Lived Graceful Restart for BGP. J. Uttaro, E. Chen, B. Decraene, J. Scudder. November 2023.` OSPF ---- @@ -465,6 +469,8 @@ BFD :t:`Bidirectional Forwarding Detection (BFD), D. Katz, D. Ward. June 2010` - :rfc:`5881` :t:`Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop), D. Katz, D. Ward. June 2010` +- :rfc:`5882` + :t:`Generic Application of Bidirectional Forwarding Detection (BFD), D. Katz, D. Ward. June 2010` - :rfc:`5883` :t:`Bidirectional Forwarding Detection (BFD) for Multihop Paths, D. Katz, D. Ward. June 2010` diff --git a/doc/user/pathd.rst b/doc/user/pathd.rst index ec107fbe47..2519ac4912 100644 --- a/doc/user/pathd.rst +++ b/doc/user/pathd.rst @@ -327,7 +327,7 @@ Configuration Commands Delete or specify a bandwidth constraint for a dynamic candidate path. -.. clicmd:: metric [bound] METRIC VALUE [required] +.. clicmd:: metric [bound] METRIC VALUE [required] [computed] Delete or specify a metric constraint for a dynamic candidate path. @@ -475,6 +475,9 @@ Configuration Commands Specify the maximum SID depth in a PCC definition. +.. clicmd:: no msd [(1-32)] + + Default the maximum SID depth to 4. .. clicmd:: peer WORD [precedence (1-255)] @@ -531,7 +534,7 @@ retrieved via PCEP a random number based name is generated. Display PCC information. -.. clicmd:: show sr-te pcep session [NAME] +.. clicmd:: show sr-te pcep session [NAME] [json] Display the information of a PCEP session, if not name is specified all the sessions will be displayed. diff --git a/doc/user/pbr.rst b/doc/user/pbr.rst index 0cdb206dd5..6ea153cc35 100644 --- a/doc/user/pbr.rst +++ b/doc/user/pbr.rst @@ -4,35 +4,32 @@ PBR *** -:abbr:`PBR` is Policy Based Routing. This implementation supports a very simple -interface to allow admins to influence routing on their router. At this time -you can only match on destination and source prefixes for an incoming interface. -At this point in time, this implementation will only work on Linux. +:abbr:`PBR` is Policy Based Routing, which means forwarding based on +packet fields other than solely the destination IP address. +This implementation currently works only on Linux. Note that some +functionality (VLAN matching, packet mangling) is not supported by +the default Linux kernel dataplane provider. .. _starting-pbr: Starting PBR ============ -Default configuration file for *pbrd* is :file:`pbrd.conf`. The typical -location of :file:`pbrd.conf` is |INSTALL_PREFIX_ETC|/pbrd.conf. - -If the user is using integrated config, then :file:`pbrd.conf` need not be -present and the :file:`frr.conf` is read instead. +.. include:: config-include.rst .. program:: pbrd -:abbr:`PBR` supports all the common FRR daemon start options which are +:abbr:`PBR` supports all the common FRR daemon start options, which are documented elsewhere. .. _nexthop-groups: -Nexthop Groups -============== +PBR Nexthop Groups +================== -Nexthop groups are a way to encapsulate ECMP information together. It's a -listing of ECMP nexthops used to forward packets for when a pbr-map is matched. -For detailed instructions on how to specify a nexthop group on the CLI, see +A nexthop group is a list of ECMP nexthops used to forward packets +when a pbr-map is matched. +For details on specifying a nexthop group in the CLI, see the nexthop-groups section. Showing Nexthop Group Information @@ -42,7 +39,7 @@ Showing Nexthop Group Information Display information on a PBR nexthop-group. If ``NAME`` is omitted, all nexthop groups are shown. Setting ``json`` will provide the same - information in an array of objects which obey the schema below: + information in an array of objects that adhere to the schema below: +-----------+----------------------------+---------+ | Key | Description | Type | @@ -74,118 +71,205 @@ Showing Nexthop Group Information PBR Maps ======== -PBR maps are a way to group policies that we would like to apply to individual -interfaces. These policies when applied are matched against incoming packets. -If matched the nexthop-group or nexthop is used to forward the packets to the -end destination. +PBR maps are a way to specify a set of rules that are applied to +packets received on individual interfaces. +If a received packet matches a rule, the rule's nexthop-group or +nexthop is used to forward it; any other actions +specified in the rule are also applied to the packet. .. clicmd:: pbr-map NAME seq (1-700) - Create a pbr-map with NAME and sequence number specified. This command puts - you into a new submode for pbr-map specification. To exit this mode type - exit or end as per normal conventions for leaving a sub-mode. + Create a pbr-map rule with map NAME and specified sequence number. + This command puts the CLI into a new submode for pbr-map rule specification. + To exit this submode, type ``exit`` or ``end``. .. clicmd:: match src-ip PREFIX - When a incoming packet matches the source prefix specified, take the packet - and forward according to the nexthops specified. This command accepts both - v4 and v6 prefixes. This command is used in conjunction of the - :clicmd:`match dst-ip PREFIX` command for matching. + Match the packet's source IP address. + + This command accepts both v4 and v6 prefixes. .. clicmd:: match dst-ip PREFIX - When a incoming packet matches the destination prefix specified, take the - packet and forward according to the nexthops specified. This command accepts - both v4 and v6 prefixes. This command is used in conjunction of the - :clicmd:`match src-ip PREFIX` command for matching. + Match the packet's destination IP address. + + This command accepts both v4 and v6 prefixes. .. clicmd:: match src-port (1-65535) - When a incoming packet matches the source port specified, take the - packet and forward according to the nexthops specified. + Match the packet's UDP or TCP source port. .. clicmd:: match dst-port (1-65535) - When a incoming packet matches the destination port specified, take the - packet and forward according to the nexthops specified. + Match the packet's UDP or TCP destination port. + +.. clicmd:: match ip-protocol PROTOCOL -.. clicmd:: match ip-protocol [tcp|udp] + Match the packet's IP protocol. - When a incoming packet matches the specified ip protocol, take the - packet and forward according to the nexthops specified. + Protocol names are queried from the protocols database (``/etc/protocols``; + see ``man 5 protocols`` and ``man 3 getprotobyname``). .. clicmd:: match mark (1-4294967295) - Select the mark to match. This is a linux only command and if attempted - on another platform it will be denied. This mark translates to the - underlying `ip rule .... fwmark XXXX` command. + Match the packet's meta-information mark. + The mark value is attached to the packet by the kernel/dataplane and + is platform-specific. + Currently, this field is supported only on linux and corresponds to + the underlying `ip rule .... fwmark XXXX` command. .. clicmd:: match dscp (DSCP|0-63) - Match packets according to the specified differentiated services code point - (DSCP) in the IP header; if this value matches then forward the packet - according to the nexthop(s) specified. The passed DSCP value may also be a - standard name for a differentiated service code point like cs0 or af11. + Match the packet's IP differentiated services code point (DSCP). + The specified DSCP may also be a standard name for a + differentiated service code point such as ``cs0`` or ``af11``. - You may only specify one dscp per route map sequence; to match on multiple - dscp values you will need to create several sequences, one for each value. + You may only specify one dscp per route map rule; to match on multiple + dscp values you will need to create several rules, one for each value. .. clicmd:: match ecn (0-3) - Match packets according to the specified explicit congestion notification - (ECN) field in the IP header; if this value matches then forward the packet - according to the nexthop(s) specified. + Match the packet's IP explicit congestion notification (ECN) field. + +.. clicmd:: match pcp (0-7) + + Match the packet's 802.1Q Priority Code Point. + Zero is the default (nominally, "best effort"). + The Linux kernel dataplane provider does not currently support + matching PCPs, + so this field will be ignored unless other dataplane providers are used. + +.. clicmd:: match vlan (1-4094) + + Match the packet's VLAN (802.1Q) identifier. + Note that VLAN IDs 0 and 4095 are reserved. + The Linux kernel dataplane provider does not currently support + VLAN-matching facilities, + so this field will be ignored unless other dataplane providers are used. + +.. clicmd:: match vlan (tagged|untagged|untagged-or-zero) + + Match packets according to whether or not they have a VLAN tag. + Use `untagged-or-zero` to also match packets with either no VLAN tag + or with the reserved VLAN ID of 0 (indicating an untagged frame that + includes other 802.1Q fields). + The Linux kernel dataplane provider does not currently support + VLAN-matching facilities, + so this field will be ignored unless other dataplane providers are used. + +.. clicmd:: set nexthop-group NAME + + Action: + forward the packet using nexthop-group NAME. + +.. clicmd:: set nexthop [A.B.C.D|X:X::X:XX|blackhole] [interface] [nexthop-vrf NAME] + Action: + forward the packet using the specified single nexthop. + If `blackhole`, packets will be sent to a blackhole route and dropped. + +.. clicmd:: set vrf unchanged|NAME + + Action: + If set to ``unchanged``, the rule will use the vrf table the interface + is in as its lookup. + If set to NAME, the rule will use that vrf table as its lookup. + + Not supported with NETNS VRF backend. .. clicmd:: set queue-id (1-65535) - Set the egress port queue identifier for matched packets. The Linux Kernel - provider does not currently support packet mangling, so this field will be - ignored unless another provider is used. + Action: + set the egress port queue identifier. + The Linux Kernel dataplane provider does not currently support + packet mangling, + so this field will be ignored unless another dataplane provider is used. .. clicmd:: set pcp (0-7) - Set the 802.1Q priority code point (PCP) for matched packets. A PCP of zero - is the defaul (nominally, "best effort"). The Linux Kernel provider does not - currently support packet mangling, so this field will be ignored unless - another provider is used. + Action: + set the 802.1Q priority code point (PCP). + A PCP of zero is the default (nominally, "best effort"). + The Linux Kernel dataplane provider does not currently support + packet mangling, + so this field will be ignored unless another dataplane provider is used. .. clicmd:: set vlan (1-4094) - Set the VLAN tag for matched packets. Identifiers 0 and 4095 are reserved. - The Linux Kernel provider does not currently support packet mangling, so - this field will be ignored unless another provider is used. + Action: + set the VLAN tag. Identifiers 0 and 4095 are reserved. + The Linux Kernel dataplane provider does not currently support + packet mangling, + so this field will be ignored unless another dataplane provider is used. .. clicmd:: strip vlan - Strip inner vlan tags from matched packets. The Linux Kernel provider does not currently support packet mangling, so this field will be ignored unless another provider is used. It is invalid to specify both a `strip` and `set - vlan` action. + Action: + strip inner vlan tags. + The Linux Kernel dataplane provider does not currently support + packet mangling, + so this field will be ignored unless another dataplane provider is used. + It is invalid to specify both a `strip` and `set vlan` action. -.. clicmd:: set nexthop-group NAME +.. clicmd:: set src-ip [A.B.C.D/M|X:X::X:X/M] - Use the nexthop-group NAME as the place to forward packets when the match - commands have matched a packet. + Action: + Set the source IP address of matched packets, possibly using a mask `M`. + The Linux Kernel dataplane provider does not currently support + packet mangling, + so this field will be ignored unless another dataplane provider is used. -.. clicmd:: set nexthop [A.B.C.D|X:X::X:XX] [interface] [nexthop-vrf NAME] +.. clicmd:: set dst-ip [A.B.C.D/M|X:X::X:X/M] - Use this individual nexthop as the place to forward packets when the match - commands have matched a packet. + Action: + set the destination IP address of matched packets, possibly using a mask + `M`. + The Linux Kernel dataplane provider does not currently support + packet mangling, + so this field will be ignored unless another dataplane provider is used. -.. clicmd:: set vrf unchanged|NAME +.. clicmd:: set src-port (1-65535) - If unchanged is set, the rule will use the vrf table the interface is in - as its lookup. If NAME is specified, the rule will use that vrf table as - its lookup. + Action: + set the source port of matched packets. Note that this action only makes + sense with layer 4 protocols that use ports, such as TCP, UDP, and SCTP. + The Linux Kernel dataplane provider does not currently support + packet mangling, + so this field will be ignored unless another dataplane provider is used. - Not supported with NETNS VRF backend. +.. clicmd:: set dst-port (1-65535) + + Action: + set the destination port of matched packets. Note that this action only + makes sense with layer 4 protocols that use ports, such as TCP, UDP, and + SCTP. + The Linux Kernel dataplane provider does not currently support + packet mangling, + so this field will be ignored unless another dataplane provider is used. + +.. clicmd:: set dscp DSCP + + Action: + set the differentiated services code point (DSCP) of matched packets. + The Linux Kernel dataplane provider does not currently support + this action, + so this field will be ignored unless another dataplane provider is used. + +.. clicmd:: set ecn (0-3) + + Action: + set the explicit congestion notification (ECN) of matched packets. + The Linux Kernel dataplane provider does not currently support + this action, + so this field will be ignored unless another dataplane provider is used. -.. clicmd:: show pbr map [NAME] [detail|json] +.. clicmd:: show pbr map [NAME] [detail] [json] Display pbr maps either all or by ``NAME``. If ``detail`` is set, it will - give information about the rules unique ID used internally and some extra + give information about each rule's unique internal ID and some extra debugging information about install state for the nexthop/nexthop group. Setting ``json`` will provide the same information in an array of objects - which obey the schema below: + that adher to the schema below: +----------+--------------------------------+---------+ | Key | Description | Type | @@ -197,9 +281,9 @@ end destination. | policies | Rules to match packets against | Array | +----------+--------------------------------+---------+ - Each element of the ``policies`` array is composed of a handful of objects + Each element of the ``policies`` array is composed of a set of objects representing the policies associated with this map. Each policy is - described as below (not all fields are required): + described below (not all fields are required): +-----------------+-------------------------------------------+---------+ | Key | Description | Type | @@ -227,8 +311,8 @@ end destination. | nexthopGroup | This policy's nexthop group (if relevant) | Object | +-----------------+-------------------------------------------+---------+ - Finally, the ``nexthopGroup`` object above cotains information we know - about the configured nexthop for this policy: + Finally, the ``nexthopGroup`` object above contains information FRR + knows about the configured nexthop for this policy: +---------------------+--------------------------------------+---------+ | Key | Description | Type | @@ -239,7 +323,7 @@ end destination. +---------------------+--------------------------------------+---------+ | installed | Is this nexthop group installed? | Boolean | +---------------------+--------------------------------------+---------+ - | installedInternally | Do we think this group is installed? | Integer | + | installedInternally | Does FRR think NHG is installed? | Integer | +---------------------+--------------------------------------+---------+ @@ -251,19 +335,19 @@ end destination. PBR Policy ========== -After you have specified a PBR map, in order for it to be turned on, you must -apply the PBR map to an interface. This policy application to an interface +After you have specified a PBR map, in order for it to be enabled, it must +be applied to an interface. This policy application to an interface causes the policy to be installed into the kernel. .. clicmd:: pbr-policy NAME - This command is available under interface sub-mode. This turns - on the PBR map NAME and allows it to work properly. + This command is available under interface sub-mode. + It enables the PBR map NAME on the interface. .. note:: - This will not dynamically create PBR maps on sub-interfaces (i.e. vlans) - even if one is on the master. Each must have the PBR map explicitly added - to the interface. + This command will not dynamically create PBR maps on sub-interfaces + (i.e. vlans), even if one is on the master. + Each sub-interface must have the PBR map enabled explicitly. .. clicmd:: show pbr interface [NAME] [json] @@ -285,9 +369,9 @@ causes the policy to be installed into the kernel. .. clicmd:: pbr table range (10000-4294966272) (10000-4294966272) - Set or unset the range used to assign numeric table ID's to new + Set or unset the range used to assign numeric table IDs to new nexthop-group tables. Existing tables will not be modified to fit in this - range, so it is recommended to configure this before adding nexthop groups. + range, so this range should be configured before adding nexthop groups. .. seealso:: :ref:`pbr-details` @@ -299,23 +383,23 @@ PBR Debugs .. clicmd:: debug pbr events|map|nht|zebra - Debug pbr in pbrd daemon. You specify what types of debugs to turn on. + Debug pbr in pbrd daemon. You must specify what types of debugs to turn on. .. _pbr-details: PBR Details =========== -Under the covers a PBR map is translated into two separate constructs in the +Internally, a PBR map is translated into two separate constructs in the Linux kernel. -The PBR map specified creates a `ip rule ...` that is inserted into the Linux +The PBR map creates an `ip rule ...` that is inserted into the Linux kernel that points to a table to use for forwarding once the rule matches. -The creation of a nexthop or nexthop-group is translated to a default route in a -table with the nexthops specified as the nexthops for the default route. +The creation of a nexthop or nexthop-group is translated to a +table with a default route having the specified nexthop(s). Sample configuration diff --git a/doc/user/pim.rst b/doc/user/pim.rst index d70c3c0e64..80a6a2787c 100644 --- a/doc/user/pim.rst +++ b/doc/user/pim.rst @@ -23,12 +23,11 @@ network for optimizing forwarding of overlay BUM traffic. Starting and Stopping pimd ========================== -The default configuration file name of *pimd*'s is :file:`pimd.conf`. When -invoked *pimd* searches directory |INSTALL_PREFIX_ETC|. If -:file:`pimd.conf` is not there then next search current directory. +.. include:: config-include.rst -*pimd* requires zebra for proper operation. Additionally *pimd* depends on -routing properly setup and working in the network that it is working on. +If starting daemons by hand then please note, *pimd* requires zebra for proper +operation. Additionally *pimd* depends on routing properly setup and working in +the network that it is working on. :: diff --git a/doc/user/pimv6.rst b/doc/user/pimv6.rst index 856939038f..d550c8e89c 100644 --- a/doc/user/pimv6.rst +++ b/doc/user/pimv6.rst @@ -15,12 +15,11 @@ do S,G mrouting. Starting and Stopping pim6d =========================== -The default configuration file name of *pim6d*'s is :file:`pim6d.conf`. When -invoked *pim6d* searches directory |INSTALL_PREFIX_ETC|. If -:file:`pim6d.conf` is not there then next search current directory. +.. include:: config-include.rst -*pim6d* requires zebra for proper operation. Additionally *pim6d* depends on -routing properly setup and working in the network that it is working on. +If starting daemons by hand then please note, *pim6d* requires zebra for proper +operation. Additionally *pim6d* depends on routing properly setup and working in +the network that it is working on. :: diff --git a/doc/user/prior-config-files.rst b/doc/user/prior-config-files.rst new file mode 100644 index 0000000000..a01b688859 --- /dev/null +++ b/doc/user/prior-config-files.rst @@ -0,0 +1,23 @@ +.. +.. January 12 2024, Christian Hopps <chopps@labn.net> +.. +.. Copyright (c) 2024, LabN Consulting, L.L.C. +.. +.. + +Prior versions of FRR supported reading and writing per-daemon config files; +however, with the introduction of the centralized management daemon ``mgmtd`` +this could no longer be supported. + +In order to allow for an orderly transition from per-daemon config files to the +integrated config file, FRR daemons will continue to try and **read** their +specific per-daemon configuration file as before. Additionally the config can +still be loaded directly using the ``-f`` or ``--config-file`` CLI options; +however, these files will **not** be updated when the configuration is written +(e.g., with the ``write mem`` command). + +.. warning:: + + Per-daemon files will **no longer** be updated when the user issues a ``write + memory`` command. Therefore these per-daemon config files should only be used + as a mechanism for transitioning to the integrated config, and then removed. diff --git a/doc/user/requirements.txt b/doc/user/requirements.txt new file mode 100644 index 0000000000..483a4e9600 --- /dev/null +++ b/doc/user/requirements.txt @@ -0,0 +1 @@ +sphinx_rtd_theme diff --git a/doc/user/ripd.rst b/doc/user/ripd.rst index 67323e61f3..ea13dc92df 100644 --- a/doc/user/ripd.rst +++ b/doc/user/ripd.rst @@ -21,15 +21,15 @@ version 1 as described in RFC1058. Starting and Stopping ripd ========================== -The default configuration file name of *ripd*'s is :file:`ripd.conf`. When -invocation *ripd* searches directory |INSTALL_PREFIX_ETC|. If :file:`ripd.conf` -is not there next search current directory. +.. include:: config-include.rst RIP uses UDP port 520 to send and receive RIP packets. So the user must have the capability to bind the port, generally this means that the user must have -superuser privileges. RIP protocol requires interface information maintained by -*zebra* daemon. So running *zebra* is mandatory to run *ripd*. Thus minimum -sequence for running RIP is like below: +superuser privileges. + +If starting daemons by hand then please note, RIP protocol requires interface +information maintained by *zebra* daemon. So running *zebra* is mandatory to run +*ripd*. Thus minimum sequence for running RIP is like below: :: @@ -159,6 +159,11 @@ RIP Configuration If `poisoned-reverse` is also set, the router sends the poisoned routes with highest metric back to the sending router. +.. clicmd:: allow-ecmp [1-MULTIPATH_NUM] + + Control how many ECMP paths RIP can inject for the same prefix. If specified + without a number, a maximum is taken (compiled with ``--enable-multipath``). + .. _rip-version-control: RIP Version Control diff --git a/doc/user/ripngd.rst b/doc/user/ripngd.rst index df7a0e249e..f898bed57a 100644 --- a/doc/user/ripngd.rst +++ b/doc/user/ripngd.rst @@ -12,6 +12,8 @@ reincarnation of the RIP protocol. Invoking ripngd =============== +.. include:: config-include.rst + There are no `ripngd` specific invocation options. Common options can be specified (:ref:`common-invocation-options`). @@ -38,6 +40,10 @@ Currently ripngd supports the following commands: Set RIPng static routing announcement of NETWORK. +.. clicmd:: allow-ecmp [1-MULTIPATH_NUM] + + Control how many ECMP paths RIPng can inject for the same prefix. If specified + without a number, a maximum is taken (compiled with ``--enable-multipath``). .. _ripngd-terminal-mode-commands: @@ -88,6 +94,53 @@ RIPng routes can be filtered by a distribute-list. `distribute-list` can be applied to both incoming and outgoing data. +.. _ripng-route-map: + +RIPng route-map +=============== + +Usage of *ripngd*'s route-map support. + +Route-map statement (:ref:`route-map`) is needed to use route-map +functionality. + +.. clicmd:: match interface WORD + + This command match to incoming interface. Notation of this match is + different from Cisco. Cisco uses a list of interfaces - NAME1 NAME2 ... + NAMEN. Ripngd allows only one name (maybe will change in the future). Next - + Cisco means interface which includes next-hop of routes (it is somewhat + similar to "ipv6 next-hop" statement). Ripngd means interface where this route + will be sent. This difference is because "next-hop" of same routes which + sends to different interfaces must be different. + +.. clicmd:: match ipv6 address WORD + +.. clicmd:: match ipv6 address prefix-list WORD + + Match if route destination is permitted by access-list/prefix-list. + +.. clicmd:: match metric (0-4294967295) + + This command match to the metric value of RIPng updates. For other protocol + compatibility metric range is shown as (0-4294967295). But for RIPng protocol + only the value range (0-16) make sense. + +.. clicmd:: set ipv6 next-hop local IPV6_ADDRESS + + Set the link-local IPv6 nexthop address. + +.. clicmd:: set metric (1-16) + + Set a metric for matched route when sending announcement. The metric value + range is very large for compatibility with other protocols. For RIPng, valid + metric values are from 1 to 16. + +.. clicmd:: set tag (1-4294967295) + + Set a tag on the matched route. + + Sample configuration ==================== diff --git a/doc/user/routemap.rst b/doc/user/routemap.rst index b7f5336564..791762aa7b 100644 --- a/doc/user/routemap.rst +++ b/doc/user/routemap.rst @@ -185,9 +185,11 @@ Route Map Match Command Matches the specified `local-preference`. -.. clicmd:: match community COMMUNITY_LIST +.. clicmd:: match community COMMUNITY_LIST [<exact-match|any>] - Matches the specified `community_list` + Matches the specified `community_list`. ``exact-match`` specifies to + do the exact matching of the communities, while ``any`` - can match any + community specified in COMMUNITY_LIST. .. clicmd:: match peer IPV4_ADDR @@ -212,7 +214,7 @@ Route Map Match Command .. clicmd:: match source-protocol PROTOCOL_NAME - This is a ZEBRA specific match command. Matches the + This is a ZEBRA and BGP specific match command. Matches the originating protocol specified. .. clicmd:: match source-instance NUMBER @@ -335,6 +337,10 @@ Route Map Set Command Set the BGP community attribute. +.. clicmd:: set extended-comm-list <EXTCOMMUNITY_LIST_NAME> delete + + Set BGP extended community list for deletion. + .. clicmd:: set ipv6 next-hop local IPV6_ADDRESS Set the BGP-4+ link local IPv6 nexthop address. @@ -374,13 +380,13 @@ Route Map Exit Action Command .. clicmd:: on-match next -.. clicmd:: continue - Proceed on to the next entry in the route-map. -.. clicmd:: on-match goto N +.. clicmd:: continue (1-65535) + + Proceed to the specified sequence in the route-map. -.. clicmd:: continue N +.. clicmd:: on-match goto N Proceed processing the route-map at the first entry whose order is >= N diff --git a/doc/user/rpki.rst b/doc/user/rpki.rst index 4053536247..76910ee7b9 100644 --- a/doc/user/rpki.rst +++ b/doc/user/rpki.rst @@ -62,8 +62,9 @@ otherwise ``bgpd`` daemon won't startup. This command enables the RPKI configuration mode. Most commands that start with *rpki* can only be used in this mode. - When it is used in a telnet session, leaving of this mode cause rpki to be - initialized. + This command is available either in *configure node* for default *vrf* or + in *vrf node* for specific *vrf*. When it is used in a telnet session, + leaving of this mode cause rpki to be initialized. Executing this command alone does not activate prefix validation. You need to configure at least one reachable cache server. See section @@ -90,6 +91,9 @@ Examples of the error:: router(config)# rpki % [BGP] Unknown command: rpki + router(config-vrf)# rpki + % [BGP] Unknown command: rpki + Note that the RPKI commands will be available in vtysh when running ``find rpki`` regardless of whether the module is loaded. @@ -98,7 +102,14 @@ Note that the RPKI commands will be available in vtysh when running Configuring RPKI/RTR Cache Servers ---------------------------------- -The following commands are independent of a specific cache server. +RPKI/RTR can be configured independently, either in configure node, or in *vrf* +sub context. If configured in configure node, the core *bgp* instance of default +*vrf* is impacted by the configuration. + +Each RPKI/RTR context is mapped to a *vrf* and can be made up of a specific list +of cache-servers, and specific settings. + +The following commands are available for independent of a specific cache server. .. clicmd:: rpki polling_period (1-3600) @@ -166,7 +177,7 @@ Validating BGP Updates .. code-block:: frr ! Allow for invalid routes in route selection process - route bgp 60001 + route bgp 65001 ! ! Set local preference of invalid prefixes to 10 route-map rpki permit 10 @@ -200,35 +211,39 @@ Debugging Displaying RPKI --------------- -.. clicmd:: show rpki prefix <A.B.C.D/M|X:X::X:X/M> [(1-4294967295)] [json] +.. clicmd:: show rpki configuration [vrf NAME] [json] + + Display RPKI configuration state including timers values. + +.. clicmd:: show rpki prefix <A.B.C.D/M|X:X::X:X/M> [(1-4294967295)] [vrf NAME] [json] Display validated prefixes received from the cache servers filtered by the specified prefix. -.. clicmd:: show rpki as-number ASN [json] +.. clicmd:: show rpki as-number ASN [vrf NAME] [json] Display validated prefixes received from the cache servers filtered by ASN. -.. clicmd:: show rpki prefix-table [json] +.. clicmd:: show rpki prefix-table [vrf NAME] [json] Display all validated prefix to origin AS mappings/records which have been received from the cache servers and stored in the router. Based on this data, the router validates BGP Updates. -.. clicmd:: show rpki cache-server [json] +.. clicmd:: show rpki cache-server [vrf NAME] [json] Display all configured cache servers, whether active or not. -.. clicmd:: show rpki cache-connection [json] +.. clicmd:: show rpki cache-connection [vrf NAME] [json] Display all cache connections, and show which is connected or not. -.. clicmd:: show bgp [afi] [safi] <A.B.C.D|A.B.C.D/M|X:X::X:X|X:X::X:X/M> rpki <valid|invalid|notfound> +.. clicmd:: show bgp [vrf NAME] [afi] [safi] <A.B.C.D|A.B.C.D/M|X:X::X:X|X:X::X:X/M> rpki <valid|invalid|notfound> Display for the specified prefix or address the bgp paths that match the given rpki state. -.. clicmd:: show bgp [afi] [safi] rpki <valid|invalid|notfound> +.. clicmd:: show bgp [vrf NAME] [afi] [safi] rpki <valid|invalid|notfound> Display all prefixes that match the given rpki state. @@ -244,25 +259,52 @@ RPKI Configuration Example debug bgp keepalives debug rpki ! + vrf VRF1 + rpki + rpki polling_period 1000 + rpki timeout 10 + ! SSH Example: + rpki cache example.com 22 rtr-ssh ./ssh_key/id_rsa preference 1 + ! TCP Example: + rpki cache rpki-validator.realmv6.org 8282 preference 2 + exit + ! + exit-vrf + ! rpki rpki polling_period 1000 rpki timeout 10 ! SSH Example: - rpki cache example.com source 141.22.28.223 22 rtr-ssh ./ssh_key/id_rsa ./ssh_key/id_rsa.pub preference 1 + rpki cache example.com source 198.51.100.223 22 rtr-ssh ./ssh_key/id_rsa preference 1 ! TCP Example: rpki cache rpki-validator.realmv6.org 8282 preference 2 exit ! - router bgp 60001 - bgp router-id 141.22.28.223 - network 192.168.0.0/16 - neighbor 123.123.123.0 remote-as 60002 - neighbor 123.123.123.0 route-map rpki in - neighbor 123.123.123.0 update-source 141.22.28.223 + router bgp 65001 + bgp router-id 198.51.100.223 + neighbor 203.0.113.1 remote-as 65002 + neighbor 203.0.113.1 update-source 198.51.100.223 + address-family ipv4 + network 192.0.2.0/24 + neighbor 203.0.113.1 route-map rpki in + exit-address-family + ! + address-family ipv6 + neighbor 203.0.113.1 activate + neighbor 203.0.113.1 route-map rpki in + exit-address-family + ! + router bgp 65001 vrf VRF1 + bgp router-id 198.51.100.223 + neighbor 203.0.113.1 remote-as 65002 + address-family ipv4 + network 192.0.2.0/24 + neighbor 203.0.113.1 route-map rpki in + exit-address-family ! address-family ipv6 - neighbor 123.123.123.0 activate - neighbor 123.123.123.0 route-map rpki in + neighbor 203.0.113.1 activate + neighbor 203.0.113.1 route-map rpki in exit-address-family ! route-map rpki permit 10 diff --git a/doc/user/sharp.rst b/doc/user/sharp.rst index 3e73a599ed..2be38a31df 100644 --- a/doc/user/sharp.rst +++ b/doc/user/sharp.rst @@ -13,11 +13,7 @@ labs. Starting SHARP ============== -Default configuration file for *sharpd* is :file:`sharpd.conf`. The typical -location of :file:`sharpd.conf` is |INSTALL_PREFIX_ETC|/sharpd.conf. - -If the user is using integrated config, then :file:`sharpd.conf` need not be -present and the :file:`frr.conf` is read instead. +.. include:: config-include.rst .. program:: sharpd @@ -67,6 +63,11 @@ keyword. At present, no sharp commands will be preserved in the config. Install a label into the kernel that causes the specified vrf NAME table to be used for pop and forward operations when the specified label is seen. +.. clicmd:: sharp watch [vrf VRF_NAME] neighbor + + Instruct zebra to notify sharpd about neighbor events in the specified vrf. + If no vrf is specified then assume default. + .. clicmd:: sharp watch <nexthop <A.B.C.D|X:X::X:X>|import <A.B.C.D/M:X:X::X:X/M> [connected] Instruct zebra to monitor and notify sharp when the specified nexthop is diff --git a/doc/user/snmp.rst b/doc/user/snmp.rst index 0bf3565b2e..3c2d11a6a7 100644 --- a/doc/user/snmp.rst +++ b/doc/user/snmp.rst @@ -126,54 +126,121 @@ An example below is how to query SNMP for BGP: $ # Information about the peers (bgp4V2PeerTable): $ snmpwalk -c public -v2c -On -Ln localhost .1.3.6.1.3.5.1.1.2 ... - .1.3.6.1.3.5.1.1.2.1.1.1.4.192.168.10.124 = Gauge32: 0 - .1.3.6.1.3.5.1.1.2.1.1.2.16.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Gauge32: 0 - .1.3.6.1.3.5.1.1.2.1.2.1.4.192.168.10.124 = INTEGER: 1 - .1.3.6.1.3.5.1.1.2.1.2.2.16.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = INTEGER: 2 - .1.3.6.1.3.5.1.1.2.1.3.1.4.192.168.10.124 = Hex-STRING: C0 A8 0A 11 - .1.3.6.1.3.5.1.1.2.1.3.2.16.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Hex-STRING: 2A 02 47 80 0A BC 00 00 00 00 00 00 00 00 00 01 - .1.3.6.1.3.5.1.1.2.1.4.1.4.192.168.10.124 = INTEGER: 1 - .1.3.6.1.3.5.1.1.2.1.4.2.16.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = INTEGER: 2 - .1.3.6.1.3.5.1.1.2.1.5.1.4.192.168.10.124 = Hex-STRING: C0 A8 0A 7C - .1.3.6.1.3.5.1.1.2.1.5.2.16.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Hex-STRING: 2A 02 47 80 0A BC 00 00 00 00 00 00 00 00 00 02 - .1.3.6.1.3.5.1.1.2.1.6.1.4.192.168.10.124 = Gauge32: 179 - .1.3.6.1.3.5.1.1.2.1.6.2.16.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Gauge32: 179 - .1.3.6.1.3.5.1.1.2.1.7.1.4.192.168.10.124 = Gauge32: 65002 - .1.3.6.1.3.5.1.1.2.1.7.2.16.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Gauge32: 65002 - .1.3.6.1.3.5.1.1.2.1.8.1.4.192.168.10.124 = Hex-STRING: C0 A8 0A 11 - .1.3.6.1.3.5.1.1.2.1.8.2.16.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Hex-STRING: C0 A8 0A 11 - .1.3.6.1.3.5.1.1.2.1.9.1.4.192.168.10.124 = Gauge32: 41894 - .1.3.6.1.3.5.1.1.2.1.9.2.16.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Gauge32: 39960 - .1.3.6.1.3.5.1.1.2.1.10.1.4.192.168.10.124 = Gauge32: 65001 - .1.3.6.1.3.5.1.1.2.1.10.2.16.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Gauge32: 65001 - .1.3.6.1.3.5.1.1.2.1.11.1.4.192.168.10.124 = Hex-STRING: C8 C8 C8 CA - .1.3.6.1.3.5.1.1.2.1.11.2.16.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Hex-STRING: C8 C8 C8 CA - .1.3.6.1.3.5.1.1.2.1.12.1.4.192.168.10.124 = INTEGER: 2 - .1.3.6.1.3.5.1.1.2.1.12.2.16.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = INTEGER: 2 - .1.3.6.1.3.5.1.1.2.1.13.1.4.192.168.10.124 = INTEGER: 6 - .1.3.6.1.3.5.1.1.2.1.13.2.16.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = INTEGER: 6 + .1.3.6.1.3.5.1.1.2.1.1.1.1.192.168.10.124 = Gauge32: 0 + .1.3.6.1.3.5.1.1.2.1.1.1.2.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Gauge32: 0 + .1.3.6.1.3.5.1.1.2.1.2.1.1.192.168.10.124 = INTEGER: 1 + .1.3.6.1.3.5.1.1.2.1.2.1.2.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = INTEGER: 2 + .1.3.6.1.3.5.1.1.2.1.3.1.1.192.168.10.124 = Hex-STRING: C0 A8 0A 11 + .1.3.6.1.3.5.1.1.2.1.3.1.2.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Hex-STRING: 2A 02 47 80 0A BC 00 00 00 00 00 00 00 00 00 01 + .1.3.6.1.3.5.1.1.2.1.4.1.1.192.168.10.124 = INTEGER: 1 + .1.3.6.1.3.5.1.1.2.1.4.1.2.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = INTEGER: 2 + .1.3.6.1.3.5.1.1.2.1.5.1.1.192.168.10.124 = Hex-STRING: C0 A8 0A 7C + .1.3.6.1.3.5.1.1.2.1.5.1.2.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Hex-STRING: 2A 02 47 80 0A BC 00 00 00 00 00 00 00 00 00 02 + .1.3.6.1.3.5.1.1.2.1.6.1.1.192.168.10.124 = Gauge32: 179 + .1.3.6.1.3.5.1.1.2.1.6.1.2.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Gauge32: 179 + .1.3.6.1.3.5.1.1.2.1.7.1.1.192.168.10.124 = Gauge32: 65002 + .1.3.6.1.3.5.1.1.2.1.7.1.2.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Gauge32: 65002 + .1.3.6.1.3.5.1.1.2.1.8.1.1.192.168.10.124 = Hex-STRING: C0 A8 0A 11 + .1.3.6.1.3.5.1.1.2.1.8.1.2.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Hex-STRING: C0 A8 0A 11 + .1.3.6.1.3.5.1.1.2.1.9.1.1.192.168.10.124 = Gauge32: 41894 + .1.3.6.1.3.5.1.1.2.1.9.1.2.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Gauge32: 39960 + .1.3.6.1.3.5.1.1.2.1.10.1.1.192.168.10.124 = Gauge32: 65001 + .1.3.6.1.3.5.1.1.2.1.10.1.2.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Gauge32: 65001 + .1.3.6.1.3.5.1.1.2.1.11.1.1.192.168.10.124 = Hex-STRING: C8 C8 C8 CA + .1.3.6.1.3.5.1.1.2.1.11.1.2.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Hex-STRING: C8 C8 C8 CA + .1.3.6.1.3.5.1.1.2.1.12.1.1.192.168.10.124 = INTEGER: 2 + .1.3.6.1.3.5.1.1.2.1.12.1.2.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = INTEGER: 2 + .1.3.6.1.3.5.1.1.2.1.13.1.1.192.168.10.124 = INTEGER: 6 + .1.3.6.1.3.5.1.1.2.1.13.1.2.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = INTEGER: 6 $ # Information about the BGP table (bgp4V2NlriTable): $ snmpwalk -c public -v2c -On -Ln localhost .1.3.6.1.3.5.1.1.9 ... - .1.3.6.1.3.5.1.1.9.1.22.1.4.10.0.2.0.24.192.168.10.124 = Gauge32: 1 - .1.3.6.1.3.5.1.1.9.1.22.1.4.10.10.100.0.24.192.168.10.124 = Gauge32: 1 - .1.3.6.1.3.5.1.1.9.1.22.1.4.172.16.31.1.32.192.168.10.124 = Gauge32: 1 - .1.3.6.1.3.5.1.1.9.1.22.1.4.172.16.31.2.32.192.168.10.124 = Gauge32: 1 - .1.3.6.1.3.5.1.1.9.1.22.1.4.172.16.31.3.32.192.168.10.124 = Gauge32: 1 - .1.3.6.1.3.5.1.1.9.1.22.1.4.192.168.0.0.24.192.168.10.124 = Gauge32: 1 - .1.3.6.1.3.5.1.1.9.1.22.1.4.192.168.1.0.24.192.168.10.124 = Gauge32: 1 - .1.3.6.1.3.5.1.1.9.1.22.1.4.192.168.10.0.24.192.168.10.124 = Gauge32: 1 - .1.3.6.1.3.5.1.1.9.1.22.2.16.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.0.64.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Gauge32: 1 - .1.3.6.1.3.5.1.1.9.1.24.1.4.10.0.2.0.24.192.168.10.124 = Hex-STRING: 02 01 FD E9 - .1.3.6.1.3.5.1.1.9.1.24.1.4.10.10.100.0.24.192.168.10.124 = Hex-STRING: 02 01 FD E9 - .1.3.6.1.3.5.1.1.9.1.24.1.4.172.16.31.1.32.192.168.10.124 = Hex-STRING: 02 01 FD E9 - .1.3.6.1.3.5.1.1.9.1.24.1.4.172.16.31.2.32.192.168.10.124 = Hex-STRING: 02 01 FD E9 - .1.3.6.1.3.5.1.1.9.1.24.1.4.172.16.31.3.32.192.168.10.124 = Hex-STRING: 02 01 FD E9 - .1.3.6.1.3.5.1.1.9.1.24.1.4.192.168.0.0.24.192.168.10.124 = Hex-STRING: 02 01 FD E9 - .1.3.6.1.3.5.1.1.9.1.24.1.4.192.168.1.0.24.192.168.10.124 = Hex-STRING: 02 01 FD E9 - .1.3.6.1.3.5.1.1.9.1.24.1.4.192.168.10.0.24.192.168.10.124 = Hex-STRING: 02 01 FD E9 - .1.3.6.1.3.5.1.1.9.1.24.2.16.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.0.64.42.2.71.128.10.188.0.0.0.0.0.0.0.0.0.2 = Hex-STRING: 02 01 FD E9 + .1.3.6.1.3.5.1.1.9.1.1.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = Gauge32: 0 + .1.3.6.1.3.5.1.1.9.1.1.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = Gauge32: 0 + .1.3.6.1.3.5.1.1.9.1.1.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Gauge32: 0 + .1.3.6.1.3.5.1.1.9.1.1.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Gauge32: 0 + .1.3.6.1.3.5.1.1.9.1.2.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.2.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.2.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 2 + .1.3.6.1.3.5.1.1.9.1.2.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 2 + .1.3.6.1.3.5.1.1.9.1.3.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.3.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.3.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.3.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.4.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.4.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.4.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 2 + .1.3.6.1.3.5.1.1.9.1.4.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 2 + .1.3.6.1.3.5.1.1.9.1.5.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = Hex-STRING: 0A 00 00 00 + .1.3.6.1.3.5.1.1.9.1.5.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = Hex-STRING: 0A 00 00 02 + .1.3.6.1.3.5.1.1.9.1.5.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Hex-STRING: 20 01 0D B8 00 00 00 00 00 00 00 00 00 00 00 01 + .1.3.6.1.3.5.1.1.9.1.5.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Hex-STRING: 20 01 0D B8 00 01 00 00 00 00 00 00 00 00 00 00 + .1.3.6.1.3.5.1.1.9.1.6.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = Gauge32: 31 + .1.3.6.1.3.5.1.1.9.1.6.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = Gauge32: 32 + .1.3.6.1.3.5.1.1.9.1.6.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Gauge32: 128 + .1.3.6.1.3.5.1.1.9.1.6.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Gauge32: 56 + .1.3.6.1.3.5.1.1.9.1.7.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.7.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.7.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.7.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.8.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = Gauge32: 0 + .1.3.6.1.3.5.1.1.9.1.8.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = Gauge32: 0 + .1.3.6.1.3.5.1.1.9.1.8.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Gauge32: 0 + .1.3.6.1.3.5.1.1.9.1.8.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Gauge32: 0 + .1.3.6.1.3.5.1.1.9.1.9.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.9.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = INTEGER: 3 + .1.3.6.1.3.5.1.1.9.1.9.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.9.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 3 + .1.3.6.1.3.5.1.1.9.1.10.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.10.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.10.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 4 + .1.3.6.1.3.5.1.1.9.1.10.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 4 + .1.3.6.1.3.5.1.1.9.1.11.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = Hex-STRING: C0 A8 0C 01 + .1.3.6.1.3.5.1.1.9.1.11.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = Hex-STRING: C0 A8 0C 01 + .1.3.6.1.3.5.1.1.9.1.11.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Hex-STRING: FE 80 00 00 00 00 00 00 30 39 84 FF FE 9A 24 2B + .1.3.6.1.3.5.1.1.9.1.11.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Hex-STRING: FE 80 00 00 00 00 00 00 30 39 84 FF FE 9A 24 2B + .1.3.6.1.3.5.1.1.9.1.14.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = INTEGER: 0 + .1.3.6.1.3.5.1.1.9.1.14.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = INTEGER: 0 + .1.3.6.1.3.5.1.1.9.1.14.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 0 + .1.3.6.1.3.5.1.1.9.1.14.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 0 + .1.3.6.1.3.5.1.1.9.1.15.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = Gauge32: 0 + .1.3.6.1.3.5.1.1.9.1.15.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = Gauge32: 0 + .1.3.6.1.3.5.1.1.9.1.15.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Gauge32: 0 + .1.3.6.1.3.5.1.1.9.1.15.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Gauge32: 0 + .1.3.6.1.3.5.1.1.9.1.16.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.16.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.16.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 1 + .1.3.6.1.3.5.1.1.9.1.16.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 1 + 1.3.6.1.3.5.1.1.9.1.17.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = Gauge32: 1 + 1.3.6.1.3.5.1.1.9.1.17.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = Gauge32: 2 + 1.3.6.1.3.5.1.1.9.1.17.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Gauge32: 1 + 1.3.6.1.3.5.1.1.9.1.17.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Gauge32: 2 + 1.3.6.1.3.5.1.1.9.1.18.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = INTEGER: 0 + 1.3.6.1.3.5.1.1.9.1.18.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = INTEGER: 0 + 1.3.6.1.3.5.1.1.9.1.18.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 0 + 1.3.6.1.3.5.1.1.9.1.18.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 0 + 1.3.6.1.3.5.1.1.9.1.19.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = INTEGER: 0 + 1.3.6.1.3.5.1.1.9.1.19.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = INTEGER: 0 + 1.3.6.1.3.5.1.1.9.1.19.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 0 + 1.3.6.1.3.5.1.1.9.1.19.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = INTEGER: 0 + 1.3.6.1.3.5.1.1.9.1.20.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = Gauge32: 0 + 1.3.6.1.3.5.1.1.9.1.20.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = Gauge32: 0 + 1.3.6.1.3.5.1.1.9.1.20.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Gauge32: 0 + 1.3.6.1.3.5.1.1.9.1.20.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Gauge32: 0 + 1.3.6.1.3.5.1.1.9.1.21.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = Hex-STRING: 00 00 00 00 + 1.3.6.1.3.5.1.1.9.1.21.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = Hex-STRING: 00 00 00 00 + 1.3.6.1.3.5.1.1.9.1.21.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Hex-STRING: 00 00 00 00 + 1.3.6.1.3.5.1.1.9.1.21.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Hex-STRING: 00 00 00 00 + 1.3.6.1.3.5.1.1.9.1.22.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = Gauge32: 1 + 1.3.6.1.3.5.1.1.9.1.22.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = Gauge32: 1 + .1.3.6.1.3.5.1.1.9.1.22.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Gauge32: 1 + .1.3.6.1.3.5.1.1.9.1.22.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Gauge32: 1 + .1.3.6.1.3.5.1.1.9.1.24.1.1.1.1.10.0.0.0.31.1.192.168.12.1.1 = Hex-STRING: 02 01 FD E9 + .1.3.6.1.3.5.1.1.9.1.24.1.1.1.1.10.0.0.2.32.1.192.168.12.1.1 = Hex-STRING: 02 01 FD E9 + .1.3.6.1.3.5.1.1.9.1.24.1.2.1.2.32.1.13.184.0.0.0.0.0.0.0.0.0.0.0.1.128.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Hex-STRING: 02 01 FD E9 + .1.3.6.1.3.5.1.1.9.1.24.1.2.1.2.32.1.13.184.0.1.0.0.0.0.0.0.0.0.0.0.56.2.32.1.13.184.0.0.0.0.0.0.0.0.0.18.0.1.1 = Hex-STRING: 02 01 FD E9 + The AgentX protocol can be transported over a Unix socket or using TCP or UDP. It usually defaults to a Unix socket and depends on how NetSNMP was built. If diff --git a/doc/user/snmptrap.rst b/doc/user/snmptrap.rst index 7e306b743d..df534e28bd 100644 --- a/doc/user/snmptrap.rst +++ b/doc/user/snmptrap.rst @@ -4,8 +4,9 @@ Handling SNMP Traps To handle snmp traps make sure your snmp setup of frr works correctly as described in the frr documentation in :ref:`snmp-support`. -The BGP4 mib will send traps on peer up/down events. These should be visible in -your snmp logs with a message similar to: +BGP handles both :rfc:`4273` and [Draft-IETF-idr-bgp4-mibv2-11]_ MIBs. +The BGP4 MIBs will send traps on peer up/down events. These should be +visible in your snmp logs with a message similar to: :: @@ -199,3 +200,18 @@ a siren, have your display flash, etc., be creative ;). # mail the notification echo "$MAIL" | mail -s "$SUBJECT" $EMAILADDR + +.. _traps-mib-selection: + +Traps Mib Selection in BGP +-------------------------- + +Both :rfc:`4273` and [Draft-IETF-idr-bgp4-mibv2-11]_ MIBs define traps for +dealing with up/down events and state transition. The user has the +possibility to select the MIB he wants to receive traps from: + +.. clicmd:: bgp snmp traps <rfc4273|bgp4-mibv2> + +By default, only rfc4273 traps are enabled and sent. + +.. [Draft-IETF-idr-bgp4-mibv2-11] <https://tools.ietf.org/id/draft-ietf-idr-bgp4-mibv2-11.txt> diff --git a/doc/user/static.rst b/doc/user/static.rst index 05847ba394..922c71a073 100644 --- a/doc/user/static.rst +++ b/doc/user/static.rst @@ -12,21 +12,13 @@ of static routes. Starting STATIC =============== -Default configuration file for *staticd* is :file:`staticd.conf`. The typical -location of :file:`staticd.conf` is |INSTALL_PREFIX_ETC|/staticd.conf. - -If the user is using integrated config, then :file:`staticd.conf` need not be -present and the :file:`frr.conf` is read instead. - -If the user has not fully upgraded to using the staticd.conf and still has -a non-integrated config with zebra.conf holding the static routes, *staticd* -will read in the :file:`zebrad.conf` as a backup. - .. program:: staticd :abbr:`STATIC` supports all the common FRR daemon start options which are documented elsewhere. +.. include:: config-include.rst + .. _static-route-commands: Static Route Commands @@ -90,7 +82,7 @@ a static prefix and gateway, with several possible forms. Multiple nexthop static route ============================= -To create multiple nexthops to the same NETWORK, just reenter the same +To create multiple nexthops to the same NETWORK (also known as a multipath route), just reenter the same network statement with different nexthop information. .. code-block:: frr @@ -122,7 +114,7 @@ nexthops, if the platform supports this. ip route 10.0.0.0/8 null0 255 -This will install a multihop route via the specified next-hops if they are +This will install a multipath route via the specified next-hops if they are reachable, as well as a high-distance blackhole route, which can be useful to prevent traffic destined for a prefix to match less-specific routes (e.g. default) should the specified gateways not be reachable. E.g.: @@ -164,3 +156,23 @@ network 9.9.9.9/24: .. code-block:: frr ip route 9.9.9.9/24 6.6.6.6 color 123 + +SRv6 Route Commands +==================== + +It is possible to specify a static route for ipv6 prefixes using an SRv6 +`segments` instruction. The `/` separator can be used to specify +multiple segments instructions. + +.. code-block:: frr + + ipv6 route X:X::X:X <X:X::X:X|nexthop> segments U:U::U:U/Y:Y::Y:Y/Z:Z::Z:Z + + +:: + + router(config)# ipv6 route 2005::1/64 ens3 segments 2001:db8:aaaa::7/2002::4/2002::3/2002::2 + + router# show ipv6 route + [..] + S>* 2005::/64 [1/0] is directly connected, ens3, seg6 2001:db8:aaaa::7,2002::4,2002::3,2002::2, weight 1, 00:00:06 diff --git a/doc/user/vrrp.rst b/doc/user/vrrp.rst index ef3aebeafa..d99fc23ef5 100644 --- a/doc/user/vrrp.rst +++ b/doc/user/vrrp.rst @@ -24,11 +24,7 @@ protocol. Starting VRRP ============= -The configuration file for *vrrpd* is :file:`vrrpd.conf`. The typical location -of :file:`vrrpd.conf` is |INSTALL_PREFIX_ETC|/vrrpd.conf. - -If using integrated config, then :file:`vrrpd.conf` need not be present and -:file:`frr.conf` is read instead. +.. include:: config-include.rst .. program:: vrrpd diff --git a/doc/user/vtysh.rst b/doc/user/vtysh.rst index 1ab54f09ab..9722231d33 100644 --- a/doc/user/vtysh.rst +++ b/doc/user/vtysh.rst @@ -18,8 +18,9 @@ administrator with an external editor. .. warning:: - This also means the ``hostname`` and ``banner motd`` commands (which both do - have effect for vtysh) need to be manually updated in :file:`vtysh.conf`. + This also means the ``hostname``, ``domainname``, and ``banner motd`` commands + (which do have effect for vtysh) need to be manually updated + in :file:`vtysh.conf`. .. clicmd:: copy FILENAME running-config @@ -130,14 +131,14 @@ could be made SGID (set group ID) to the |INSTALL_VTY_GROUP| group. at all. -.. _integrated-configuration-mode: +.. _integrated-configuration-file: -Integrated configuration mode +Integrated configuration file ============================= -Integrated configuration mode uses a single configuration file, -:file:`frr.conf`, for all daemons. This replaces the individual files like -:file:`zebra.conf` or :file:`bgpd.conf`. +FRR uses a single configuration file, :file:`frr.conf`, for all daemons. This +replaces the individual files like :file:`zebra.conf` or :file:`bgpd.conf` used +in previous versions of the software. :file:`frr.conf` is located in |INSTALL_PREFIX_ETC|. All daemons check for the existence of this file at startup, and if it exists will not load their diff --git a/doc/user/zebra.rst b/doc/user/zebra.rst index d7e768b710..72b4f20418 100644 --- a/doc/user/zebra.rst +++ b/doc/user/zebra.rst @@ -50,7 +50,8 @@ Besides the common invocation options (:ref:`common-invocation-options`), the When *Zebra* starts with this option, the VRF backend is based on Linux network namespaces. That implies that all network namespaces discovered by ZEBRA will create an associated VRF. The other daemons will operate on the VRF - VRF defined by *Zebra*, as usual. + VRF defined by *Zebra*, as usual. If this option is specified when running + *Zebra*, one must also specify the same option for *mgmtd*. .. seealso:: :ref:`zebra-vrf` @@ -68,6 +69,12 @@ Besides the common invocation options (:ref:`common-invocation-options`), the option and we will use Route Replace Semantics instead of delete than add. +.. option:: --routing-table <tableno> + + Specify which kernel routing table *Zebra* should communicate with. + If this option is not specified the default table (RT_TABLE_MAIN) is + used. + .. option:: --asic-offload=[notify_on_offload|notify_on_ack] The linux kernel has the ability to use asic-offload ( see switchdev @@ -87,6 +94,13 @@ Besides the common invocation options (:ref:`common-invocation-options`), the Allow zebra to modify the default receive buffer size to SIZE in bytes. Under \*BSD only the -s option is available. +.. option:: --v6-with-v4-nexthops + + Signal to zebra that v6 routes with v4 nexthops are accepted + by the underlying dataplane. This will be communicated to + the upper level daemons that can install v6 routes with v4 + nexthops. + .. _interface-commands: Configuration Addresses behaviour @@ -156,23 +170,23 @@ Standard Commands Set description for the interface. -.. clicmd:: mpls enable +.. clicmd:: mpls <enable|disable> - Enable or disable mpls kernel processing on the interface, for linux. Interfaces + Choose mpls kernel processing value on the interface, for linux. Interfaces configured with mpls will not automatically turn on if mpls kernel modules do not - happen to be loaded. This command will fail on 3.X linux kernels and does not - work on non-linux systems at all. + happen to be loaded. This command will fail on 3.X linux kernels and does not + work on non-linux systems at all. 'enable' and 'disable' will respectively turn + on and off mpls on the given interface. -.. clicmd:: multicast +.. clicmd:: multicast <enable|disable> Enable or disable multicast flag for the interface. -.. clicmd:: bandwidth (1-10000000) - +.. clicmd:: bandwidth (1-1000000) - Set bandwidth value of the interface in kilobits/sec. This is for + Set bandwidth value of the interface in Megabits/sec. This is for calculating OSPF cost. This command does not affect the actual device configuration. @@ -199,20 +213,14 @@ Link Parameters Commands .. clicmd:: link-params + Enter into the link parameters sub node. This command activates the link + parameters and allows to configure routing information that could be used + as part of Traffic Engineering on this interface. MPLS-TE must be enabled at + the OSPF (:ref:`ospf-traffic-engineering`) or ISIS + (:ref:`isis-traffic-engineering`) router level in complement to this. To + disable link parameters, use the ``no`` version of this command. - Enter into the link parameters sub node. At least 'enable' must be - set to activate the link parameters, and consequently routing - information that could be used as part of 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. - - Under link parameter statement, the following commands set the different TE values: - -.. clicmd:: enable - - Enable link parameters for this interface. +Under link parameter statement, the following commands set the different TE values: .. clicmd:: metric (0-4294967295) @@ -238,7 +246,7 @@ Link Parameters Commands as specified in RFC3630 (OSPF) or RFC5305 (ISIS). Admin-group is also known as Resource Class/Color in the OSPF protocol. -.. clicmd:: [no] affinity AFFINITY-MAP-NAME +.. clicmd:: affinity AFFINITY-MAP-NAME This commands configures the Traffic Engineering Admin-Group of the interface using the affinity-map definitions (:ref:`affinity-map`). @@ -249,7 +257,7 @@ Link Parameters Commands ``admin-grp`` and ``affinity`` commands provide two ways of setting admin-groups. They cannot be both set on the same interface. -.. clicmd:: [no] affinity-mode [extended|standard|both] +.. clicmd:: affinity-mode [extended|standard|both] This commands configures which admin-group format is set by the affinity command. ``extended`` Admin-Group is the default and uses the RFC7308 format. @@ -320,11 +328,15 @@ the default route. Allow IPv4 nexthop tracking to resolve via the default route. This parameter is configured per-VRF, so the command is also available in the VRF subnode. + This is enabled by default for a traditional profile. + .. clicmd:: ipv6 nht resolve-via-default Allow IPv6 nexthop tracking to resolve via the default route. This parameter is configured per-VRF, so the command is also available in the VRF subnode. + This is enabled by default for a traditional profile. + .. clicmd:: show ip nht [vrf NAME] [A.B.C.D|X:X::X:X] [mrib] [json] Show nexthop tracking status for address resolution. If vrf is not specified @@ -356,6 +368,8 @@ outgoing interface Resolve PBR nexthop via ip neigh tracking +.. _administrative-distance: + Administrative Distance ======================= @@ -402,16 +416,34 @@ the same distances that other routing suites have chosen. +------------+-----------+ An admin distance of 255 indicates to Zebra that the route should not be -installed into the Data Plane. Additionally routes with an admin distance +installed into the Data Plane. Additionally routes with an admin distance of 255 will not be redistributed. Zebra does treat Kernel routes as special case for the purposes of Admin -Distance. Upon learning about a route that is not originated by FRR -we read the metric value as a uint32_t. The top byte of the value +Distance. Upon learning about a route that is not originated by FRR +we read the metric value as a uint32_t. The top byte of the value is interpreted as the Administrative Distance and the low three bytes -are read in as the metric. This special case is to facilitate VRF +are read in as the metric. This special case is to facilitate VRF default routes. +.. code-block:: shell + + $ # Set administrative distance to 255 for Zebra + $ ip route add 192.0.2.0/24 metric $(( 2**32 - 2**24 )) dev lo + $ vtysh -c 'show ip route 192.0.2.0/24 json' | jq '."192.0.2.0/24"[] | (.distance, .metric)' + 255 + 0 + $ # Set administrative distance to 192 for Zebra + $ ip route add 192.0.2.0/24 metric $(( 2**31 + 2**30 )) dev lo + $ vtysh -c 'show ip route 192.0.2.0/24 json' | jq '."192.0.2.0/24"[] | (.distance, .metric)' + 192 + 0 + $ # Set administrative distance to 128, and metric 100 for Zebra + $ ip route add 192.0.2.0/24 metric $(( 2**31 + 100 )) dev lo + $ vtysh -c 'show ip route 192.0.2.0/24 json' | jq '."192.0.2.0/24"[] | (.distance, .metric)' + 128 + 100 + Route Replace Semantics ======================= @@ -745,6 +777,44 @@ presence of the entry. 21 Static 10.125.0.2 IPv4 Explicit Null +MPLS label chunks +----------------- + +MPLS label chunks are handled in the zebra label manager service, +which ensures a same label value or label chunk can not be used by +multiple CP routing daemons at the same time. + +Label requests originate from CP routing daemons, and are resolved +over the default MPLS range (16-1048575). There are two kind of +requests: +- Static label requests request an exact label value or range. For +instance, segment routing label blocks requests originating from +IS-IS are part of it. +- Dynamic label requests only need a range of label values. The +'bgp l3vpn export auto' command uses such requests. + +Allocated label chunks table can be dumped using the command + +.. clicmd:: show debugging label-table [json] + +:: + + zebra# show debugging label-table + Proto ospf: [300/350] + Proto srte: [500/500] + Proto isis: [1200/1300] + Proto ospf: [20000/21000] + Proto isis: [22000/23000] + +.. clicmd:: mpls label dynamic-block (16-1048575) (16-1048575) + + Define a range of labels where dynamic label requests will + allocate label chunks from. This command guarantees that + static label values outside that range will not conflict + with the dynamic label requests. When the dynamic-block + range is configured, static label requests that match that + range are not accepted. + .. _zebra-srv6: Segment-Routing IPv6 @@ -762,6 +832,35 @@ FRR's cli or frr.conf or zebra.conf. This section shows how to configure SRv6 on FRR. Of course SRv6 can be used as standalone, and this section also helps that case. +.. clicmd:: show segment-routing srv6 manager [json] + + This command dumps the SRv6 information configured on zebra, including + the encapsulation parameters (e.g., the IPv6 source address used for + the encapsulated packets). + + Example:: + + router# sh segment-routing srv6 manager + Parameters: + Encapsulation: + Source Address: + Configured: fc00:0:1::1 + + + To get the same information in json format, you can use the ``json`` keyword:: + + rose-srv6# sh segment-routing srv6 manager json + { + "parameters":{ + "encapsulation":{ + "sourceAddress":{ + "configured":"fc00:0:1::1" + } + } + } + } + + .. clicmd:: show segment-routing srv6 locator [json] This command dump SRv6-locator configured on zebra. SRv6-locator is used @@ -922,6 +1021,14 @@ and this section also helps that case. ! ... +.. clicmd:: encapsulation + + Configure parameters for SRv6 encapsulation. + +.. clicmd:: source-address X:X::X:X + + Configure the source address of the outer encapsulating IPv6 header. + .. _multicast-rib-commands: Multicast RIB Commands @@ -1220,6 +1327,12 @@ FPM Commands The ``no`` form uses the old known FPM behavior of including next hop information in the route (e.g. ``RTM_NEWROUTE``) messages. +.. clicmd:: fpm use-route-replace + + Use the netlink ``NLM_F_REPLACE`` flag for updating routes instead of + two different messages to update a route + (``RTM_DELROUTE`` + ``RTM_NEWROUTE``). + .. clicmd:: show fpm counters [json] Show the FPM statistics (plain text or JSON formatted). @@ -1243,6 +1356,9 @@ FPM Commands User FPM configurations: 1 User FPM disable requests: 0 +.. clicmd:: show fpm status [json] + + Show the FPM status. .. clicmd:: clear fpm counters @@ -1377,8 +1493,6 @@ zebra Terminal Mode Commands .. clicmd:: show ip prefix-list [NAME] -.. clicmd:: show route-map [NAME] - .. clicmd:: show ip protocol .. clicmd:: show ip forward |