From: Quentin Young Date: Thu, 1 Feb 2018 21:10:11 +0000 (-0500) Subject: doc: fixup some build warnings X-Git-Tag: frr-5.0-dev~165^2~50 X-Git-Url: https://git.puffer.fish/?a=commitdiff_plain;h=013f9762db7b5f9a4570971f917f4a0857188f42;p=mirror%2Ffrr.git doc: fixup some build warnings Signed-off-by: Quentin Young --- diff --git a/doc/user/bgp.rst b/doc/user/bgp.rst index a4c141fd32..d02973f28d 100644 --- a/doc/user/bgp.rst +++ b/doc/user/bgp.rst @@ -279,7 +279,7 @@ and sometimes not, depending on the properties of those other routes, means MED can cause the order of preference over all the routes to be undefined. That is, given routes A, B, and C, if A is preferred to B, and B is preferred to C, then a well-defined order should mean the preference is transitive (in the sense of -orders [#med-transitivity-rant])_ and that A would be preferred to C. +orders [#med-transitivity-rant]_) and that A would be preferred to C. However, when MED is involved this need not be the case. With MED it is possible that C is actually preferred over A. So A is preferred to B, B is @@ -409,7 +409,7 @@ induce; in general on arbitrary networks. There may be iBGP topology specific ways to reduce the instability risks, even while using MED, e.g.: by constraining the reflection topology and by tuning -IGP costs between route-reflector clusters, see RFC3345 for details. In the +IGP costs between route-reflector clusters, see :rfc:`3345` for details. In the near future, the Add-Path extension to BGP may also solve MED oscillation while still allowing MED to be used as intended, by distributing "best-paths per neighbour AS". This would be at the cost of distributing at least as many @@ -420,12 +420,12 @@ Add-Path reflector. More generally, the instability problems that MED can introduce on more complex, non-full-mesh, iBGP topologies may be avoided either by: -- Setting :ref:`bgp_always-compare-med`, however this allows MED to be compared +- Setting :clicmd:`bgp always-compare-med`, however this allows MED to be compared across values set by different neighbour ASes, which may not produce coherent desirable results, of itself. - Effectively ignoring MED by setting MED to the same value (e.g.: 0) using - :ref:`routemap_set_metric` on all received routes, in combination with - setting :ref:`bgp_always-compare-med` on all speakers. This is the simplest + :clicmd:`set metric METRIC` on all received routes, in combination with + setting :clicmd:`bgp always-compare-med` on all speakers. This is the simplest and most performant way to avoid MED oscillation issues, where an AS is happy not to allow neighbours to inject this problematic metric. @@ -443,6 +443,7 @@ paper above for an example. Hence the guideline that the iBGP topology should follow the IGP topology. .. _bgp_deterministic-med: + .. index:: bgp deterministic-med .. clicmd:: bgp deterministic-med @@ -463,11 +464,11 @@ Note that there are other sources of indeterminism in the route selection process, specifically, the preference for older and already selected routes from eBGP peers, :ref:`BGP_decision_process`. +.. _bgp_always-compare-med: + .. index:: bgp always-compare-med .. clicmd:: bgp always-compare-med -.. _bgp_always-compare-med: - Always compare the MED on routes, even when they were received from different neighbouring ASes. Setting this option makes the order of preference of routes more defined, and should eliminate MED induced diff --git a/doc/user/conf.py b/doc/user/conf.py index 1eac6af763..b0bcb2ed43 100644 --- a/doc/user/conf.py +++ b/doc/user/conf.py @@ -123,7 +123,7 @@ language = None # List of patterns, relative to source directory, that match files and # directories to ignore when looking for source files. -exclude_patterns = ['_build'] +exclude_patterns = ['_build', 'rpki.rst', 'ospf_fundamentals.rst'] # The reST default role (used for this markup: `text`) to use for all # documents. diff --git a/doc/user/eigrpd.rst b/doc/user/eigrpd.rst index 7c2c55d166..7c8109fa97 100644 --- a/doc/user/eigrpd.rst +++ b/doc/user/eigrpd.rst @@ -188,19 +188,10 @@ How to Announce EIGRP route Show EIGRP Information ====================== -To display EIGRP routes. - -.. index:: show ip eigrp topology -.. clicmd:: show ip eigrp topology - - Show EIGRP routes. - -The command displays all EIGRP routes. - .. index:: show ip eigrp topology .. clicmd:: show ip eigrp topology - The command displays current EIGRP status + Display current EIGRP status. :: diff --git a/doc/user/index.rst b/doc/user/index.rst index 0929fb51ad..036c87c86e 100644 --- a/doc/user/index.rst +++ b/doc/user/index.rst @@ -7,22 +7,24 @@ Welcome to FRR's documentation! overview installation basic - zebra - ripd - ripngd - ospfd - ospf6d - isisd - nhrpd - bgp - babeld - vnc vtysh filter routemap ipv6 kernel snmp + zebra protocol + bgp + babeld + eigrpd + isisd + nhrpd + ospfd + ospf6d pim + ripd + ripngd + vnc + appendix diff --git a/doc/user/installation.rst b/doc/user/installation.rst index 356d243e47..471448d004 100644 --- a/doc/user/installation.rst +++ b/doc/user/installation.rst @@ -166,6 +166,10 @@ customize the build to include or exclude specific features and dependencies. Build without VTYSH. +.. option:: --enable-fpm + + Build with FPM module support. + You may specify any combination of the above options to the configure script. By default, the executables are placed in :file:`/usr/local/sbin` and the configuration files in :file:`/usr/local/etc`. The :file:`/usr/local/` diff --git a/doc/user/isisd.rst b/doc/user/isisd.rst index 1dffc2cf8f..50592cc21b 100644 --- a/doc/user/isisd.rst +++ b/doc/user/isisd.rst @@ -410,8 +410,6 @@ Showing ISIS information Show the ISIS routing table, as determined by the most recent SPF calculation. -.. _ospf-traffic-engineering: - Traffic Engineering =================== @@ -444,6 +442,10 @@ Traffic Engineering Show Traffic Engineering router parameters. +.. seealso:: + + :ref:`ospf-traffic-engineering` + .. _Debugging_ISIS: Debugging ISIS diff --git a/doc/user/ospf_fundamentals.rst b/doc/user/ospf_fundamentals.rst index ac9a343ad5..d01fd74984 100644 --- a/doc/user/ospf_fundamentals.rst +++ b/doc/user/ospf_fundamentals.rst @@ -73,8 +73,8 @@ The Hello Protocol The OSPF Hello protocol allows OSPF to quickly detect changes in two-way reachability between routers on a link. OSPF can additionally avail of other sources of reachability information, such as link-state information provided by -hardware, or through dedicated reachability protocols such as :abbr:`BFD -(Bidirectional Forwarding Detection)`. +hardware, or through dedicated reachability protocols such as +:abbr:`BFD (Bidirectional Forwarding Detection)`. OSPF also uses the Hello protocol to propagate certain state between routers sharing a link, for example: @@ -118,7 +118,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 neighbours as neighbours form adjacencies and the propogation, or :term:`flooding` of new or updated :abbr:`LSA` s. :ref:`OSPF_Flooding`. @@ -191,7 +191,7 @@ All LSAs share a common header with the following information: - Age A number to allow stale :abbr:`LSA` s to, eventually, be purged by routers - from their :abbr:`LSDB`s. + from their :abbr:`LSDB` s. The value nominally is one of seconds. An age of 3600, i.e. 1 hour, is called the :term:`MaxAge`. MaxAge LSAs are ignored in routing @@ -540,6 +540,6 @@ like::: Summary LSAs ^^^^^^^^^^^^ -Summary LSAs are created by :abbr:`ABR`s to summarise the destinations +Summary LSAs are created by :abbr:`ABR` s to summarise the destinations available within one area to other areas. These LSAs may describe IP networks, potentially in aggregated form, or :abbr:`ASBR` routers. diff --git a/doc/user/overview.rst b/doc/user/overview.rst index 2b5e2f9b2b..c3549417d7 100644 --- a/doc/user/overview.rst +++ b/doc/user/overview.rst @@ -262,13 +262,12 @@ Italicized lists are private. +--------------------------------+------------------------------+ The Development list is used to discuss and document general issues related to -project development and governance. The public `Slack instance -`_, and weekly technical meetings provide a higher -bandwidth channel for discussions. The results of such discussions are -reflected in updates, as appropriate, to code (i.e., merges), `GitHub -`_ tracked issues, and for governance -or process changes, updates to the Development list and either this file or -information posted at https://frrouting.org/. +project development and governance. The public `Slack`_ instance and weekly +technical meetings provide a higher bandwidth channel for discussions. The +results of such discussions are reflected in updates, as appropriate, to code +(i.e., merges), `GitHub issues`_ tracked issues, and for governance or process +changes, updates to the Development list and either this file or information +posted at `FRR`_. .. index:: Bug Reports .. index:: Bug hunting @@ -298,5 +297,6 @@ When you send a bug report, please be careful about the points below. Bug reports help us improve FRR and are very much appreciated. .. _FRR: |PACKAGE_URL| -.. _GitHub: http://github.com/frrouting/frr/ -.. _GitHub issues: http://github.com/frrouting/frr/ +.. _GitHub: https://github.com/frrouting/frr/ +.. _GitHub issues: https://github.com/frrouting/frr/issues +.. _Slack: https://frrouting.slack.com/ diff --git a/doc/user/routemap.rst b/doc/user/routemap.rst index 735838b0e6..471a286283 100644 --- a/doc/user/routemap.rst +++ b/doc/user/routemap.rst @@ -10,52 +10,49 @@ allowing policy to be applied to routes. Route maps are an ordered list of route map entries. Each entry may specify up to four distincts sets of clauses: -- :dfn:`Matching Policy` +.. glossary:: - This specifies the policy implied if the *Matching Conditions* are - met or not met, and which actions of the route-map are to be taken, if - any. The two possibilities are: + Matching Conditions + A route-map entry may, optionally, specify one or more conditions which + must be matched if the entry is to be considered further, as governed by + the Match Policy. If a route-map entry does not explicitely specify any + matching conditions, then it always matches. - - :dfn:`permit`: If the entry matches, then carry out the :term:`Set - Actions`. Then finish processing the route-map, permitting the route, - unless an *Exit Action* indicates otherwise. + Set Actions + A route-map entry may, optionally, specify one or more Set Actions to set + or modify attributes of the route. - - :dfn:`deny`: If the entry matches, then finish processing the route-map and - deny the route (return ``deny``). + Matching Policy + This specifies the policy implied if the :term:`Matching Conditions` are + met or not met, and which actions of the route-map are to be taken, if + any. The two possibilities are: - The *Matching Policy* is specified as part of the command which - defines the ordered entry in the route-map. See below. + - :dfn:`permit`: If the entry matches, then carry out the + :term:`Set Actions`. Then finish processing the route-map, permitting + the route, unless an :term:`Exit Policy` action indicates otherwise. -- :dfn:`Matching Conditions` + - :dfn:`deny`: If the entry matches, then finish processing the route-map and + deny the route (return `deny`). - A route-map entry may, optionally, specify one or more conditions which must - be matched if the entry is to be considered further, as governed by the Match - Policy. If a route-map entry does not explicitely specify any matching - conditions, then it always matches. + The `Matching Policy` is specified as part of the command which defines + the ordered entry in the route-map. See below. -- :dfn:`Set Actions` + Call Action + Call to another route-map, after any :term:`Set Actions` have been carried out. + If the route-map called returns `deny` then processing of the route-map + finishes and the route is denied, regardless of the :term:Matching Policy` or + the :term:`Exit Policy`. If the called route-map returns `permit`, then + :term:`Matching Policy` and :term:`Exit Policy` govern further behaviour, as normal. - A route-map entry may, optionally, specify one or more *Set Actions* to - set or modify attributes of the route. + Exit Policy + An entry may, optionally, specify an alternative :dfn:`Exit Policy` to + take if the entry matched, rather than the normal policy of exiting the + route-map and permitting the route. The two possibilities are: -- :dfn:`Call Action` + - :dfn:`next`: Continue on with processing of the route-map entries. - Call to another route-map, after any *Set Actions* have been carried out. - If the route-map called returns *deny* then processing of the route-map - finishes and the route is denied, regardless of the *Matching Policy* or - the *Exit Policy*. If the called route-map returns *permit*, then - *Matching Policy* and *Exit Policy* govern further behaviour, as normal. - -- :dfn:`Exit Policy` - - An entry may, optionally, specify an alternative *Exit Policy* to - take if the entry matched, rather than the normal policy of exiting the - route-map and permitting the route. The two possibilities are: - - - :dfn:`next`: Continue on with processing of the route-map entries. - - - :dfn:`goto N`: Jump ahead to the first route-map entry whose order in - the route-map is >= N. Jumping to a previous entry is not permitted. + - :dfn:`goto N`: Jump ahead to the first route-map entry whose order in + the route-map is >= N. Jumping to a previous entry is not permitted. The default action of a route-map, if no entries match, is to deny. I.e. a route-map essentially has as its last entry an empty *deny* entry, which @@ -188,11 +185,11 @@ Route Map Match Command Route Map Set Command ===================== +.. program:: configure + .. index:: set tag TAG .. clicmd:: set tag TAG -.. program:: configure - Set a tag on the matched route. This tag value can be from (1-4294967295). Additionally if you have compiled with the :option:`--enable-realms` configure option. Tag values from (1-255) are sent to the Linux kernel as a diff --git a/doc/user/zebra.rst b/doc/user/zebra.rst index b04b8c7365..4f1692e58c 100644 --- a/doc/user/zebra.rst +++ b/doc/user/zebra.rst @@ -34,6 +34,8 @@ Besides the common invocation options (:ref:`Common_Invocation_Options`), the When program terminates, retain routes added by zebra. +.. program:: configure + .. _Interface_Commands: Interface Commands @@ -444,28 +446,28 @@ longer-prefix zebra Route Filtering ===================== -Zebra supports :dfn:`prefix-list`s and :ref:`Route_Map`s to match routes -received from other frr components. The permit/deny facilities provided by +Zebra supports :dfn:`prefix-list` s and :ref:`Route_Map` s to match routes +received from other FRR components. The permit/deny facilities provided by these commands can be used to filter which routes zebra will install in the kernel. .. index:: ip protocol PROTOCOL route-map ROUTEMAP .. clicmd:: ip protocol PROTOCOL route-map ROUTEMAP - Apply a route-map filter to routes for the specified protocol. PROTOCOL can - be **any** or one of - - - system, - - kernel, - - connected, - - static, - - rip, - - ripng, - - ospf, - - ospf6, - - isis, - - bgp, - - hsls. + Apply a route-map filter to routes for the specified protocol. PROTOCOL can + be **any** or one of + + - system, + - kernel, + - connected, + - static, + - rip, + - ripng, + - ospf, + - ospf6, + - isis, + - bgp, + - hsls. .. index:: set src ADDRESS .. clicmd:: set src ADDRESS