diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/developer/workflow.rst | 98 | ||||
| -rw-r--r-- | doc/user/bgp.rst | 47 | ||||
| -rw-r--r-- | doc/user/filter.rst | 9 | ||||
| -rw-r--r-- | doc/user/ospf6d.rst | 65 | ||||
| -rw-r--r-- | doc/user/ospfd.rst | 24 | ||||
| -rw-r--r-- | doc/user/pim.rst | 8 |
6 files changed, 228 insertions, 23 deletions
diff --git a/doc/developer/workflow.rst b/doc/developer/workflow.rst index 58b9c36e01..dae175a732 100644 --- a/doc/developer/workflow.rst +++ b/doc/developer/workflow.rst @@ -880,6 +880,104 @@ doesn't warrant an update to checkpatch, it is documented here. | should be wrapped in parentheses | all usages of the macro, which would be highly disruptive. | +------------------------------------------+---------------------------------------------------------------+ +Types of configurables +---------------------- + +.. note:: + + This entire section essentially just argues to not make configuration + unnecessarily involved for the user. Rather than rules, this is more of + a list of conclusions intended to help make FRR usable for operators. + + +Almost every feature FRR has comes with its own set of switches and options. +There are several stages at which configuration can be applied. In order of +preference, these are: + +- at configuration/runtime, through YANG. + + This is the preferred way for all FRR knobs. Not all daemons and features + are fully YANGified yet, so in some cases new features cannot rely on a + YANG interface. If a daemon already implements a YANG interface (even + partial), new CLI options must be implemented through a YANG model. + + .. warning:: + + Unlike everything else in this section being guidelines with some slack, + implementing and using a YANG interface for new CLI options in (even + partially!) YANGified daemons is a hard requirement. + + +- at configuration/runtime, through the CLI. + + The "good old" way for all regular configuration. More involved for users + to automate *correctly* than YANG. + +- at startup, by loading additional modules. + + If a feature introduces a dependency on additional libraries (e.g. libsnmp, + rtrlib, etc.), this is the best way to encapsulate the dependency. Having + a separate module allows the distribution to create a separate package + with the extra dependency, so FRR can still be installed without pulling + everything in. + + A module may also be appropriate if a feature is large and reasonably well + isolated. Reducing the amount of running the code is a security benefit, + so even if there are no new external dependencies, modules can be useful. + + While modules cannot currently be loaded at runtime, this is a tradeoff + decision that was made to allow modules to change/extend code that is very + hard to (re)adjust at runtime. If there is a case for runtime (un)loading + of modules, this tradeoff can absolutely be reevaluated. + +- at startup, with command line options. + + This interface is only appropriate for options that have an effect very + early in FRR startup, i.e. before configuration is loaded. Anything that + affects configuration load itself should be here, as well as options + changing the environment FRR runs in. + + If a tunable can be changed at runtime, a command line option is only + acceptable if the configured value has an effect before configuration is + loaded (e.g. zebra reads routes from the kernel before loading config, so + the netlink buffer size is an appropriate command line option.) + +- at compile time, with ``./configure`` options. + + This is the absolute last preference for tunables, since the distribution + needs to make the decision for the user and/or the user needs to rebuild + FRR in order to change the option. + + "Good" configure options do one of three things: + + - set distribution-specific parameters, most prominently all the path + options. File system layout is a distribution/packaging choice, so the + user would hopefully never need to adjust these. + + - changing toolchain behavior, e.g. instrumentation, warnings, + optimizations and sanitizers. + + - enabling/disabling parts of the build, especially if they need + additional dependencies. Being able to build only parts of FRR, or + without some library, is useful. **The only effect these options should + have is adding or removing files from the build result.** If a knob + in this category causes the same binary to exist in different variants, + it is likely implemented incorrectly! + + .. note:: + + This last guideline is currently ignored by several configure options. + ``vtysh`` in general depends on the entire list of enabled daemons, + and options like ``--enable-bgp-vnc`` and ``--enable-ospfapi`` change + daemons internally. Consider this more of an "ideal" than a "rule". + + +Whenever adding new knobs, please try reasonably hard to go up as far as +possible on the above list. Especially ``./configure`` flags are often enough +the "easy way out" but should be avoided when at all possible. To a lesser +degree, the same applies to command line options. + + Compile-time conditional code ----------------------------- diff --git a/doc/user/bgp.rst b/doc/user/bgp.rst index b5950538dd..88f0483901 100644 --- a/doc/user/bgp.rst +++ b/doc/user/bgp.rst @@ -401,6 +401,22 @@ Route Selection paths learned from any of eBGP, iBGP, or confederation neighbors will be multipath if they are otherwise considered equal cost. +.. clicmd:: maximum-paths (1-128) + + Sets the maximum-paths value used for ecmp calculations for this + bgp instance in EBGP. The maximum value listed, 128, can be limited by + the ecmp cli for bgp or if the daemon was compiled with a lower + ecmp value. This value can also be set in ipv4/ipv6 unicast/labeled + unicast to only affect those particular afi/safi's. + +.. clicmd:: maximum-paths ibgp (1-128) [equal-cluster-length] + + Sets the maximum-paths value used for ecmp calculations for this + bgp instance in IBGP. The maximum value listed, 128, can be limited by + the ecmp cli for bgp or if the daemon was compiled with a lower + ecmp value. This value can also be set in ipv4/ipv6 unicast/labeled + unicast to only affect those particular afi/safi's. + .. _bgp-distance: Administrative Distance Metrics @@ -1442,12 +1458,13 @@ Configuring Peers session will be established via IPv6 link locals. Use ``internal`` for iBGP and ``external`` for eBGP sessions, or specify an ASN if you wish. -.. clicmd:: neighbor PEER next-hop-self [all] +.. clicmd:: neighbor PEER next-hop-self [force] This command specifies an announced route's nexthop as being equivalent to - the address of the bgp router if it is learned via eBGP. If the optional - keyword `all` is specified the modification is done also for routes learned - via iBGP. + the address of the bgp router if it is learned via eBGP. This will also + bypass third-party next-hops in favor of the local bgp address. If the + optional keyword ``force`` is specified the modification is done also for + routes learned via iBGP. .. clicmd:: neighbor PEER attribute-unchanged [{as-path|next-hop|med}] @@ -2177,6 +2194,12 @@ communities attribute. The following commands can be used in route maps: +.. clicmd:: match alias WORD + + This command performs match to BGP updates using community alias WORD. When + the one of BGP communities value match to the one of community alias value in + community alias, it is match. + .. clicmd:: match community WORD exact-match [exact-match] This command perform match to BGP updates using community list WORD. When @@ -3016,10 +3039,13 @@ The conditional BGP announcements are sent in addition to the normal announcements that a BGP router sends to its peer. The conditional advertisement process is triggered by the BGP scanner process, -which runs every 60 seconds. This means that the maximum time for the conditional -advertisement to take effect is 60 seconds. The conditional advertisement can take -effect depending on when the tracked route is removed from the BGP table and -when the next instance of the BGP scanner occurs. +which runs every 60 by default. This means that the maximum time for the +conditional advertisement to take effect is the value of the process timer. + +As an optimization, while the process always runs on each timer expiry, it +determines whether or not the conditional advertisement policy or the routing +table has changed; if neither have changed, no processing is necessary and the +scanner exits early. .. clicmd:: neighbor A.B.C.D advertise-map NAME [exist-map|non-exist-map] NAME @@ -3027,6 +3053,11 @@ when the next instance of the BGP scanner occurs. exist-map or non-exist-map command in BGP table and conditionally advertises the routes specified by advertise-map command. +.. clicmd:: bgp conditional-advertisement timer (5-240) + + Set the period to rerun the conditional advertisement scanner process. The + default is 60 seconds. + Sample Configuration ^^^^^^^^^^^^^^^^^^^^^ .. code-block:: frr diff --git a/doc/user/filter.rst b/doc/user/filter.rst index 1fb9beccdc..cbbcd47dc3 100644 --- a/doc/user/filter.rst +++ b/doc/user/filter.rst @@ -137,6 +137,15 @@ Showing ip prefix-list .. clicmd:: show ip prefix-list detail .. clicmd:: show ip prefix-list detail NAME +.. clicmd:: debug prefix-list NAME match <A.B.C.D/M|X:X::X:X/M> [address-mode] + + Execute the prefix list matching code for the specified list and prefix. + Shows which entry matched, if any. (``address-mode`` is used for + PIM RP lookups and skips prefix length checks.) + + The return value from this command is success only if the prefix-list + result is to permit the prefix, so the command can be used in scripting. + Clear counter of ip prefix-list ------------------------------- diff --git a/doc/user/ospf6d.rst b/doc/user/ospf6d.rst index 04ee1643d8..5344f4cb05 100644 --- a/doc/user/ospf6d.rst +++ b/doc/user/ospf6d.rst @@ -85,6 +85,61 @@ OSPF6 router change to take effect, user can use this cli instead of restarting the ospf6d daemon. +.. _ospf6-debugging: + +OSPFv3 Debugging +================ + +The following debug commands are supported: + +.. clicmd:: debug ospf6 abr + + Toggle OSPFv3 ABR debugging messages. + +.. clicmd:: debug ospf6 asbr + + Toggle OSPFv3 ASBR debugging messages. + +.. clicmd:: debug ospf6 border-routers + + Toggle OSPFv3 border router debugging messages. + +.. clicmd:: debug ospf6 flooding + + Toggle OSPFv3 flooding debugging messages. + +.. clicmd:: debug ospf6 interface + + Toggle OSPFv3 interface related debugging messages. + +.. clicmd:: debug ospf6 lsa + + Toggle OSPFv3 Link State Advertisements debugging messages. + +.. clicmd:: debug ospf6 message + + Toggle OSPFv3 message exchange debugging messages. + +.. clicmd:: debug ospf6 neighbor + + Toggle OSPFv3 neighbor interaction debugging messages. + +.. clicmd:: debug ospf6 nssa + + Toggle OSPFv3 Not So Stubby Area (NSSA) debugging messages. + +.. clicmd:: debug ospf6 route + + Toggle OSPFv3 routes debugging messages. + +.. clicmd:: debug ospf6 spf + + Toggle OSPFv3 Shortest Path calculation debugging messages. + +.. clicmd:: debug ospf6 zebra + + Toggle OSPFv3 zebra interaction debugging messages. + .. _ospf6-area: OSPF6 area @@ -332,13 +387,3 @@ Larger example with policy and various options set: ipv6 access-class access6 exec-timeout 0 0 ! - - -Configuration Limits -==================== - -Ospf6d currently supports 100 interfaces addresses if MTU is set to -default value, and 200 interface addresses if MTU is set to jumbo -packet size or larger. - - diff --git a/doc/user/ospfd.rst b/doc/user/ospfd.rst index 8d67ec865f..e8ca394727 100644 --- a/doc/user/ospfd.rst +++ b/doc/user/ospfd.rst @@ -710,8 +710,17 @@ Redistribution -Graceful Restart Helper -======================= +Graceful Restart +================ + +.. clicmd:: graceful-restart [grace-period (1-1800)] + + + Configure Graceful Restart (RFC 3623) restarting support. + When enabled, the default grace period is 120 seconds. + + To perform a graceful shutdown, the "graceful-restart prepare ip ospf" + EXEC-level command needs to be issued before restarting the ospfd daemon. .. clicmd:: graceful-restart helper-only [A.B.C.D] @@ -743,6 +752,17 @@ Graceful Restart Helper restarts. By default, it supports both planned and unplanned outages. + +.. clicmd:: graceful-restart prepare ip ospf + + + Initiate a graceful restart for all OSPF instances configured with the + "graceful-restart" command. The ospfd daemon should be restarted during + the instance-specific grace period, otherwise the graceful restart will fail. + + This is an EXEC-level command. + + .. _showing-ospf-information: Showing Information diff --git a/doc/user/pim.rst b/doc/user/pim.rst index 83d19d6188..6f9aa289b4 100644 --- a/doc/user/pim.rst +++ b/doc/user/pim.rst @@ -93,11 +93,13 @@ Certain signals have special meanings to *pimd*. down. This command is vrf aware, to configure for a vrf, enter the vrf submode. -.. clicmd:: ip pim join-prune-interval (60-600) +.. clicmd:: ip pim join-prune-interval (5-600) Modify the join/prune interval that pim uses to the new value. Time is specified in seconds. This command is vrf aware, to configure for a vrf, - enter the vrf submode. + enter the vrf submode. The default time is 60 seconds. If you enter + a value smaller than 60 seconds be aware that this can and will affect + convergence at scale. .. clicmd:: ip pim keep-alive-timer (31-60000) @@ -199,7 +201,7 @@ is in a vrf, enter the interface command with the vrf keyword at the end. Set the DR Priority for the interface. This command is useful to allow the user to influence what node becomes the DR for a lan segment. -.. clicmd:: ip pim hello (1-180) (1-180) +.. clicmd:: ip pim hello (1-180) (1-630) Set the pim hello and hold interval for a interface. |