diff options
| -rw-r--r-- | doc/extra/spelling_wordlist.txt | 236 | ||||
| -rw-r--r-- | doc/user/basic.rst | 4 | ||||
| -rw-r--r-- | doc/user/bgp.rst | 49 | ||||
| -rw-r--r-- | doc/user/eigrpd.rst | 2 | ||||
| -rw-r--r-- | doc/user/installation.rst | 14 | ||||
| -rw-r--r-- | doc/user/ipv6.rst | 6 | ||||
| -rw-r--r-- | doc/user/kernel.rst | 10 | ||||
| -rw-r--r-- | doc/user/ospf6d.rst | 8 | ||||
| -rw-r--r-- | doc/user/ospf_fundamentals.rst | 10 | ||||
| -rw-r--r-- | doc/user/ospfd.rst | 49 | ||||
| -rw-r--r-- | doc/user/pim.rst | 23 | ||||
| -rw-r--r-- | doc/user/ripd.rst | 12 | ||||
| -rw-r--r-- | doc/user/routemap.rst | 6 | ||||
| -rw-r--r-- | doc/user/routeserver.rst | 14 | ||||
| -rw-r--r-- | doc/user/vnc.rst | 14 | ||||
| -rw-r--r-- | doc/user/vtysh.rst | 2 | ||||
| -rw-r--r-- | doc/user/zebra.rst | 20 | ||||
| -rw-r--r-- | lib/table.h | 1 |
18 files changed, 357 insertions, 123 deletions
diff --git a/doc/extra/spelling_wordlist.txt b/doc/extra/spelling_wordlist.txt new file mode 100644 index 0000000000..4c9455e8e9 --- /dev/null +++ b/doc/extra/spelling_wordlist.txt @@ -0,0 +1,236 @@ +abr +Admin +AFI +agentx +AgentX +APK +apps +ARP +ASes +ASv +autoconfiguration +Autoconfiguration +autoconfigured +autodetected +babeld +backtrace +backtraces +behaviour +bgp +bgpd +BGPD +blackhole +charon +cisco +Cisco +cli +clicmd +conf +config +Config +cr +crashlog +dataplane +de +deconfigured +deserialization +dev +distincts +dstmask +eBGP +eigrp +eigrpd +EOR +eth +ethernet +ethernets +extcommunity +failover +fallback +favour +filesystem +Flavel +frontend +frr +FRR +frrvty +gcc +ge +glibc +gre +hardcoded +holddown +Holddown +holdtime +honour +honoured +hostname +hsls +iBGP +ibm +ietf +igmp +inet +init +insta +interdomain +internet +ip +IP +iptables +ipv +IPv +isis +isisd +lan +le +libc +libcap +libexecinfo +Loc +localhost +logfile +loopback +lsa +LSA +lsas +LSAs +Masaki +Mbit +Mbits +mib +motd +mpls +mrib +mroute +mroutes +mrouting +mtu +multicast +Multicast +multicasting +multihop +multipath +Multipath +Multipoint +multiprotocol +Multiprotocol +namespace +nd +neighbour +neighbouring +neighbours +Netlink +netmask +netmasks +nexthop +nexthops +nflog +nhrp +NHRP +nhrpd +noauth +noninterfering +Noninterfering +nopassword +nve +NVE +opennhrp +optimisation +optimisations +ospf +OSPF +ospfd +pathing +pce +peerings +performant +php +pid +pim +pimd +ppp +pre +prepend +Prepend +prepended +proc +protobuf +Protobuf +PtP +ra +readonly +rebalance +reconverge +reestablish +reestimated +requestlist +reservable +Reservable +rfc +RFP +RIBs +ripd +Ripd +ripng +ripngd +Roughan +rp +rpki +rtt +RTT +Rxmt +µs +safi +setgid +sm +smux +smuxpeer +snmp +SNMP +snmpd +snmptrap +snmptrapd +Solaris +src +stateful +stdout +strftime +strongSwan +subagents +subsubsections +summarisation +summarise +summarising +supercedes +synchronisation +sysctl +syslogd +tc +te +Timestamp +tmp +trapsink +txt +unicast +Unicast +unix +urib +useable +username +usr +vertices +vici +vn +VN +VNC +vrf +vrfs +vty +Vty +vtysh +wildcard +wildcarded +Wilfong +xDSL +xFF diff --git a/doc/user/basic.rst b/doc/user/basic.rst index 4a5056e233..f134133da4 100644 --- a/doc/user/basic.rst +++ b/doc/user/basic.rst @@ -440,8 +440,8 @@ If FPM is enabled during compile-time and installed as part of the package, the ``fpm`` module can be loaded for the *zebra* daemon. This provides the Forwarding Plane Manager ("FPM") API. -The module expects its argument to be either ``netlink`` or ``protobuf``, -specifying the encapsulation to use. ``netlink`` is the default, and +The module expects its argument to be either ``Netlink`` or ``protobuf``, +specifying the encapsulation to use. ``Netlink`` is the default, and ``protobuf`` may not be available if the module was built without protobuf support. Refer to :ref:`zebra-fib-push-interface` for more information. diff --git a/doc/user/bgp.rst b/doc/user/bgp.rst index 899977e830..3298460a58 100644 --- a/doc/user/bgp.rst +++ b/doc/user/bgp.rst @@ -4,13 +4,12 @@ BGP *** -:abbr:`BGP` stands for a Border Gateway Protocol. The lastest BGP version is 4. -It is referred as BGP-4. BGP-4 is one of the Exterior Gateway Protocols and -de-fact standard of Inter Domain routing protocol. BGP-4 is described in -:rfc:`1771`. +:abbr:`BGP` stands for a Border Gateway Protocol. The latest BGP version is 4. +BGP-4 is one of the Exterior Gateway Protocols and the de facto standard +interdomain routing protocol. BGP-4 is described in :rfc:`1771`. -Many extensions have been added to :rfc:`1771`. :rfc:`2858` provides -multiprotocol support to BGP-4. +Many extensions have been added to :rfc:`1771`. :rfc:`2858` adds multiprotocol +support to BGP-4. .. _starting-bgp: @@ -182,7 +181,7 @@ The decision process FRR BGP uses to select routes is as follows: The advantage of this is that the route-selection (at this point) will be more deterministic. The disadvantage is that a few or even one lowest-ID - router may attract all trafic to otherwise-equal paths because of this + router may attract all traffic to otherwise-equal paths because of this check. It may increase the possibility of MED or IGP oscillation, unless other measures were taken to avoid these. The exact behaviour will be sensitive to the iBGP and reflection topology. @@ -507,7 +506,7 @@ Route Aggregation .. index:: aggregate-address A.B.C.D/M summary-only .. clicmd:: aggregate-address A.B.C.D/M summary-only - This command specifies an aggregate address. Aggreated routes will + This command specifies an aggregate address. Aggregated routes will not be announce. .. index:: no aggregate-address A.B.C.D/M @@ -568,7 +567,7 @@ Redistribute to BGP (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the establish-wait optional value is given, then BGP will wait for - peers to reach established from the begining of the update-delay till the + peers to reach established from the beginning of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. @@ -702,7 +701,7 @@ required. 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 modifiation is done also for routes learned + keyword `all` is specified the modification is done also for routes learned via iBGP. .. index:: neighbor PEER update-source <IFNAME|ADDRESS> @@ -798,7 +797,7 @@ required. This command enforces Generalized TTL Security Mechanism (GTSM), as specified in RFC 5082. With this command, only neighbors that are the specified number of hops away will be allowed to become neighbors. This - command is mututally exclusive with *ebgp-multihop*. + command is mutually exclusive with *ebgp-multihop*. .. _peer-filtering: @@ -995,7 +994,7 @@ numerical order. BGP Community Lists ------------------- -BGP community list is a user defined BGP communites attribute list. BGP +BGP community list is a user defined BGP communities attribute list. BGP community list can be used for matching or manipulating BGP communities attribute in updates. @@ -1037,7 +1036,7 @@ expanded community list. These commands delete community lists specified by NAME. All of community lists shares a single name space. So community lists can be - removed simpley specifying community lists name. + removed simply specifying community lists name. .. index:: show ip community-list .. clicmd:: show ip community-list @@ -1093,11 +1092,11 @@ is called as named community lists. .. index:: ip community-list NAME permit|deny COMMUNITY .. clicmd:: ip community-list NAME permit|deny COMMUNITY - When community list type is not specifed, the community list type is + When community list type is not specified, the community list type is automatically detected. If COMMUNITY can be compiled into communities attribute, the community list is defined as a standard community list. Otherwise it is defined as an expanded community list. This feature is left - for backward compability. Use of this feature is not recommended. + for backward compatibility. Use of this feature is not recommended. .. _bgp-community-in-route-map: @@ -1118,7 +1117,7 @@ Following commands can be used in Route Map. This command perform match to BGP updates using community list WORD. When the one of BGP communities value match to the one of communities value in - community list, it is match. When `exact-match` keyword is spcified, match + community list, it is match. When `exact-match` keyword is specified, match happen only when BGP updates have completely same communities value specified in the community list. @@ -1265,7 +1264,7 @@ limit the BGP routes announcement into the internal network. match community 1 -Following exmaple filter BGP routes which has communities value 1:1. +Following example filter BGP routes which has communities value 1:1. When there is no match community-list returns deny. To avoid filtering all of routes, we need to define permit any at last. @@ -1389,7 +1388,7 @@ Lists. These commands delete extended community lists specified by `name`. All of extended community lists shares a single name space. So extended community - lists can be removed simpley specifying the name. + lists can be removed simply specifying the name. .. index:: show ip extcommunity-list .. clicmd:: show ip extcommunity-list @@ -1540,7 +1539,7 @@ BGP Large Communities in Route Map BGP VRFs ======== -Bgpd supports multiple VRF instances via the *router bgp* command: +BPGD supports multiple VRF instances via the *router bgp* command: .. index:: router bgp ASN vrf VRFNAME .. clicmd:: router bgp ASN vrf VRFNAME @@ -1651,7 +1650,7 @@ address-family: .. clicmd:: route-map vpn import|export MAP Specifies an optional route-map to be applied to routes imported or exported - betwen the current unicast VRF and VPN. + between the current unicast VRF and VPN. .. index:: no route-map vpn import|export [MAP] .. clicmd:: no route-map vpn import|export [MAP] @@ -1661,12 +1660,12 @@ address-family: .. index:: import|export vpn .. clicmd:: import|export vpn - Enables import or export of routes betwen the current unicast VRF and VPN. + Enables import or export of routes between the current unicast VRF and VPN. .. index:: no import|export vpn .. clicmd:: no import|export vpn - Disables import or export of routes betwen the current unicast VRF and VPN. + Disables import or export of routes between the current unicast VRF and VPN. .. _displaying-bgp-information: @@ -1813,7 +1812,7 @@ operational network. :rfc:`2842` adopted a feature called Capability Negotiation. *bgpd* use this Capability Negotiation to detect the remote peer's capabilities. If a peer is only configured as an IPv4 unicast neighbor, *bgpd* does not send these Capability Negotiation packets (at least not unless other -optional BGP features require capability negotation). +optional BGP features require capability negotiation). By default, FRR will bring up peering with minimal common capability for the both sides. For example, if the local router has unicast and multicast @@ -2219,7 +2218,7 @@ A more complex example. With upstream, peer and customer sessions. Advertising global prefixes and NO_EXPORT prefixes and providing actions for customer routes based on community values. Extensive use of route-maps and the 'call' feature to support selective advertising of prefixes. This example is intended -as guidance only, it has NOT been tested and almost certainly containts silly +as guidance only, it has NOT been tested and almost certainly contains silly mistakes, if not serious flaws. .. code-block:: frr @@ -2431,7 +2430,7 @@ mistakes, if not serious flaws. .. include:: rpki.rst -.. [#med-transitivity-rant] For some set of objects to have an order, there *must* be some binary ordering relation that is defined for *every* combination of those objects, and that relation *must* be transitive. I.e.:, if the relation operator is <, and if a < b and b < c then that relation must carry over and it *must* be that a < c for the objects to have an order. The ordering relation may allow for equality, i.e. a < b and b < a may both be true amd imply that a and b are equal in the order and not distinguished by it, in which case the set has a partial order. Otherwise, if there is an order, all the objects have a distinct place in the order and the set has a total order) +.. [#med-transitivity-rant] For some set of objects to have an order, there *must* be some binary ordering relation that is defined for *every* combination of those objects, and that relation *must* be transitive. I.e.:, if the relation operator is <, and if a < b and b < c then that relation must carry over and it *must* be that a < c for the objects to have an order. The ordering relation may allow for equality, i.e. a < b and b < a may both be true and imply that a and b are equal in the order and not distinguished by it, in which case the set has a partial order. Otherwise, if there is an order, all the objects have a distinct place in the order and the set has a total order) .. [bgp-route-osci-cond] McPherson, D. and Gill, V. and Walton, D., "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", IETF RFC3345 .. [stable-flexible-ibgp] Flavel, A. and M. Roughan, "Stable and flexible iBGP", ACM SIGCOMM 2009 .. [ibgp-correctness] Griffin, T. and G. Wilfong, "On the correctness of IBGP configuration", ACM SIGCOMM 2002 diff --git a/doc/user/eigrpd.rst b/doc/user/eigrpd.rst index c626faf4e2..6034bf8948 100644 --- a/doc/user/eigrpd.rst +++ b/doc/user/eigrpd.rst @@ -222,7 +222,7 @@ Debug for EIGRP protocol. Debug eigrp packets - ``debug eigrp`` will show EIGRP packets that are sent and recevied. + ``debug eigrp`` will show EIGRP packets that are sent and received. .. index:: debug eigrp transmit .. clicmd:: debug eigrp transmit diff --git a/doc/user/installation.rst b/doc/user/installation.rst index 6c68815eae..8501054fdb 100644 --- a/doc/user/installation.rst +++ b/doc/user/installation.rst @@ -11,7 +11,7 @@ Installation .. index:: Making FRR Several distributions provide packages for FRR. Check your distribution's -respositories to find out if a suitable version is available. +repositories to find out if a suitable version is available. FRR depends on various libraries depending on your operating system. @@ -135,7 +135,7 @@ customize the build to include or exclude specific features and dependencies. .. option:: --enable-gcc-rdynamic Pass the ``-rdynamic`` option to the linker driver. This is in most cases - neccessary for getting usable backtraces. This option defaults to on if the + necessary for getting usable backtraces. This option defaults to on if the compiler is detected as gcc, but giving an explicit enable/disable is suggested. @@ -173,7 +173,7 @@ customize the build to include or exclude specific features and dependencies. .. option:: --enable-numeric-version Alpine Linux does not allow non-numeric characters in the version string. - With this option, we provide a way to strip out these characters for apk dev + With this option, we provide a way to strip out these characters for APK dev package builds. You may specify any combination of the above options to the configure @@ -221,8 +221,8 @@ options to control the behaviour of FRR daemons. .. option:: --enable-vty-group <group> - Create Unix Vty sockets (for use with vtysh) with group owndership set to - `group`. This allows one to create a seperate group which is restricted to + Create Unix Vty sockets (for use with vtysh) with group ownership set to + `group`. This allows one to create a separate group which is restricted to accessing only the vty sockets, hence allowing one to delegate this group to individual users, or to run vtysh setgid to this group. @@ -255,11 +255,11 @@ do exist. - :makevar:`CONFIG_NETLINK` - Kernel/User netlink socket. This is a brand new feature which enables an + Kernel/User Netlink socket. This is a brand new feature which enables an advanced interface between the Linux kernel and zebra (:ref:`kernel-interface`). - :makevar:`CONFIG_RTNETLINK` Routing messages. - This makes it possible to receive netlink routing messages. If you + This makes it possible to receive Netlink routing messages. If you specify this option, *zebra* can detect routing information updates directly from the kernel (:ref:`kernel-interface`). - :makevar:`CONFIG_IP_MULTICAST` diff --git a/doc/user/ipv6.rst b/doc/user/ipv6.rst index 9d079028ca..585c3a505a 100644 --- a/doc/user/ipv6.rst +++ b/doc/user/ipv6.rst @@ -4,7 +4,7 @@ IPv6 Support ************ -FRR fully supports IPv6 routing. As described so far, Frr supports RIPng, +FRR fully supports IPv6 routing. As described so far, FRR supports RIPng, OSPFv3, and BGP-4+. You can give IPv6 addresses to an interface and configure static IPv6 routing information. FRR IPv6 also provides automatic address configuration via a feature called ``address auto configuration``. To do it, @@ -20,12 +20,12 @@ Router Advertisement .. index:: no ipv6 nd suppress-ra .. clicmd:: no ipv6 nd suppress-ra - Send router advertisment messages. + Send router advertisement messages. .. index:: ipv6 nd suppress-ra .. clicmd:: ipv6 nd suppress-ra - Don't send router advertisment messages. + Don't send router advertisement messages. .. index:: ipv6 nd prefix ipv6prefix [valid-lifetime] [preferred-lifetime] [off-link] [no-autoconfig] [router-address] .. clicmd:: ipv6 nd prefix ipv6prefix [valid-lifetime] [preferred-lifetime] [off-link] [no-autoconfig] [router-address] diff --git a/doc/user/kernel.rst b/doc/user/kernel.rst index 8c65901a00..4c2c7a5008 100644 --- a/doc/user/kernel.rst +++ b/doc/user/kernel.rst @@ -26,17 +26,17 @@ information, updating kernel routing tables, and for looking up interfaces. This is a special filesystem mount that provides an easy way of getting kernel information. -- routing socket / netlink +- routing socket / Netlink On recent Linux kernels (2.0.x and 2.2.x), there is a kernel/user - communication support called `netlink`. It makes asynchronous communication + communication support called `Netlink`. It makes asynchronous communication between kernel and FRR possible, similar to a routing socket on BSD systems. Before you use this feature, be sure to select (in kernel configuration) the - kernel/netlink support option 'Kernel/User network link driver' and 'Routing + kernel/Netlink support option 'Kernel/User network link driver' and 'Routing messages'. Today, the :file:`/dev/route` special device file is obsolete. Netlink - communication is done by reading/writing over netlink socket. + communication is done by reading/writing over Netlink socket. After the kernel configuration, please reconfigure and rebuild FRR. You can - use netlink as a dynamic routing update channel between FRR and the kernel. + use Netlink as a dynamic routing update channel between FRR and the kernel. diff --git a/doc/user/ospf6d.rst b/doc/user/ospf6d.rst index 3c84135405..56f95e64b0 100644 --- a/doc/user/ospf6d.rst +++ b/doc/user/ospf6d.rst @@ -42,13 +42,13 @@ OSPF6 router an event which occurs outside of the holdtime of any previous SPF calculation, and also serves as a minimum holdtime). - Consecutive SPF calculations will always be seperated by at least + Consecutive SPF calculations will always be separated by at least 'hold-time' milliseconds. The hold-time is adaptive and initially is set to the `initial-holdtime` configured with the above command. Events which occur within the holdtime of the previous SPF calculation will cause the holdtime to be increased by `initial-holdtime`, bounded by the `maximum-holdtime` configured with this command. If the adaptive - hold-time elapses without any SPF-triggering event occuring then + hold-time elapses without any SPF-triggering event occurring then the current holdtime is reset to the `initial-holdtime`. .. code-block:: frr @@ -61,7 +61,7 @@ OSPF6 router to 400ms and the `maximum holdtime` to 10s. Hence there will always be at least 200ms between an event which requires SPF calculation and the actual SPF calculation. Further consecutive SPF calculations will always be - seperated by between 400ms to 10s, the hold-time increasing by 400ms each + separated by between 400ms to 10s, the hold-time increasing by 400ms each time an SPF-triggering event occurs within the hold-time of the previous SPF calculation. @@ -126,7 +126,7 @@ OSPF6 interface .. index:: ipv6 ospf6 network (broadcast|point-to-point) .. clicmd:: ipv6 ospf6 network (broadcast|point-to-point) - Set explicitly network type for specifed interface. + Set explicitly network type for specified interface. .. _redistribute-routes-to-ospf6: diff --git a/doc/user/ospf_fundamentals.rst b/doc/user/ospf_fundamentals.rst index c35df85ddf..7db822c820 100644 --- a/doc/user/ospf_fundamentals.rst +++ b/doc/user/ospf_fundamentals.rst @@ -18,7 +18,7 @@ to their immediate neighbouring routers. .. index:: Link State Database Each router describes their link-state information in a message known as an -:abbr:`LSA (Link State Advertisement)`, which is then propogated through to all +:abbr:`LSA (Link State Advertisement)`, which is then propagated through to all other routers in a link-state routing domain, by a process called `flooding`. Each router thus builds up an :abbr:`LSDB (Link State Database)` of all the link-state messages. From this collection of LSAs in the LSDB, each router can @@ -59,7 +59,7 @@ OSPF Mechanisms --------------- :abbr:`OSPF` defines a range of mechanisms, concerned with detecting, -describing and propogating state through a network. These mechanisms +describing and propagating state through a network. These mechanisms will nearly all be covered in greater detail further on. They may be broadly classed as: @@ -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 -propogation, or `flooding` of new or updated :abbr:`LSA` s. +propagation, or `flooding` of new or updated :abbr:`LSA` s. .. index:: OSPF Areas overview @@ -306,7 +306,7 @@ Summary of Link State LSAs: | Router LSA | Router ID | The :abbr:`OSPF` enabled links of the | | | | router, within a specific link-state area. | +-------------+----------------------------+--------------------------------------------+ -| Network LSA | The IP address of the | The subet mask of the network and the | +| Network LSA | The IP address of the | The subnet mask of the network and the | | | :abbr:`DR` for the network | Router IDs of all routers on the network | +-------------+----------------------------+--------------------------------------------+ @@ -478,7 +478,7 @@ Forwarding Address The address of the router to forward packets to for the route. This may be, and usually is, left as 0 to specify that the ASBR originating the External :abbr:`LSA` should be used. There must be an internal OSPF route to the - forwarding address, for the forwarding address to be useable. + forwarding address, for the forwarding address to be usable. Tag An arbitrary 4-bytes of data, not interpreted by OSPF, which may carry diff --git a/doc/user/ospfd.rst b/doc/user/ospfd.rst index f1b77ffe09..63e04a0493 100644 --- a/doc/user/ospfd.rst +++ b/doc/user/ospfd.rst @@ -74,11 +74,10 @@ writing, *ospfd* does not support multiple OSPF processes. which still can reach the backbone - this restriction exists primarily to ensure routing-loops are avoided. - With the "Cisco" or "IBM" ABR type, the default in this release of - FRR, this restriction is lifted, allowing an ABR to consider - summaries learnt from other ABRs through non-backbone areas, and hence - route via non-backbone areas as a last resort when, and only when, - backbone links are down. + With the "Cisco" or "IBM" ABR type, the default in this release of FRR, this + restriction is lifted, allowing an ABR to consider summaries learned from + other ABRs through non-backbone areas, and hence route via non-backbone + areas as a last resort when, and only when, backbone links are down. Note that areas with fully-adjacent virtual-links are considered to be "transit capable" and can always be used to route backbone traffic, and @@ -102,7 +101,7 @@ writing, *ospfd* does not support multiple OSPF processes. .. index:: no ospf rfc1583compatibility .. clicmd:: no ospf rfc1583compatibility - :rfc:`2328`, the sucessor to :rfc:`1583`, suggests according + :rfc:`2328`, the successor to :rfc:`1583`, suggests according to section G.2 (changes) in section 16.4 a change to the path preference algorithm that prevents possible routing loops that were possible in the old version of OSPFv2. More specifically it demands @@ -152,13 +151,13 @@ writing, *ospfd* does not support multiple OSPF processes. an event which occurs outside of the holdtime of any previous SPF calculation, and also serves as a minimum holdtime). - Consecutive SPF calculations will always be seperated by at least + Consecutive SPF calculations will always be separated by at least 'hold-time' milliseconds. The hold-time is adaptive and initially is set to the `initial-holdtime` configured with the above command. Events which occur within the holdtime of the previous SPF calculation will cause the holdtime to be increased by `initial-holdtime`, bounded by the `maximum-holdtime` configured with this command. If the adaptive - hold-time elapses without any SPF-triggering event occuring then + hold-time elapses without any SPF-triggering event occurring then the current holdtime is reset to the `initial-holdtime`. The current holdtime can be viewed with :clicmd:`show ip ospf`, where it is expressed as a multiplier of the `initial-holdtime`. @@ -172,7 +171,7 @@ writing, *ospfd* does not support multiple OSPF processes. In this example, the `delay` is set to 200ms, the initial holdtime is set to 400ms and the `maximum holdtime` to 10s. Hence there will always be at least 200ms between an event which requires SPF calculation and the actual SPF - calculation. Further consecutive SPF calculations will always be seperated + calculation. Further consecutive SPF calculations will always be separated by between 400ms to 10s, the hold-time increasing by 400ms each time an SPF-triggering event occurs within the hold-time of the previous SPF calculation. @@ -254,7 +253,7 @@ writing, *ospfd* does not support multiple OSPF processes. router ospf network 192.168.1.0/24 area 0.0.0.0 - Prefix length in interface must be equal or bigger (ie. smaller network) than + Prefix length in interface must be equal or bigger (i.e. smaller network) than prefix length in network statement. For example statement above doesn't enable ospf on interface with address 192.168.1.1/23, but it does on interface with address 192.168.1.129/25. @@ -289,7 +288,7 @@ OSPF area Summarize intra area paths from specified area into one Type-3 summary-LSA announced to other areas. This command can be used only in ABR and ONLY - router-LSAs (Type-1) and network-LSAs (Type-2) (ie. LSAs with scope area) can + router-LSAs (Type-1) and network-LSAs (Type-2) (i.e. LSAs with scope area) can be summarized. Type-5 AS-external-LSAs can't be summarized - their scope is AS. Summarizing Type-7 AS-external-LSAs isn't supported yet by FRR. @@ -303,7 +302,7 @@ OSPF area With configuration above one Type-3 Summary-LSA with routing info 10.0.0.0/8 is announced into backbone area if area 0.0.0.10 contains at least one intra-area - network (ie. described with router or network LSA) from this range. + network (i.e. described with router or network LSA) from this range. .. index:: area A.B.C.D range IPV4_PREFIX not-advertise .. clicmd:: area A.B.C.D range IPV4_PREFIX not-advertise @@ -311,7 +310,7 @@ OSPF area .. index:: no area A.B.C.D range IPV4_PREFIX not-advertise .. clicmd:: no area A.B.C.D range IPV4_PREFIX not-advertise - Instead of summarizing intra area paths filter them - ie. intra area paths from this + Instead of summarizing intra area paths filter them - i.e. intra area paths from this range are not advertised into other areas. This command makes sense in ABR only. @@ -332,7 +331,7 @@ OSPF area One Type-3 summary-LSA with routing info 11.0.0.0/8 is announced into backbone area if - area 0.0.0.10 contains at least one intra-area network (ie. described with router-LSA or + area 0.0.0.10 contains at least one intra-area network (i.e. described with router-LSA or network-LSA) from range 10.0.0.0/8. This command makes sense in ABR only. @@ -550,11 +549,11 @@ OSPF interface 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 reestabish adjacencies + across resets, if ospfd is to be able to promptly reestablish adjacencies with its neighbours after restarts/reboots. The host should have system time - be set at boot from an external or non-volatile source (eg battery backed + 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-volative storage and restored at boot if MD5 authentication is to be + non-volatile storage and restored at boot if MD5 authentication is to be expected to work reliably. .. index:: ip ospf message-digest-key KEYID md5 KEY @@ -624,7 +623,7 @@ OSPF interface .. index:: no ip ospf network .. clicmd:: no ip ospf network - Set explicitly network type for specifed interface. + Set explicitly network type for specified interface. .. index:: ip ospf priority (0-255) .. clicmd:: ip ospf priority (0-255) @@ -865,7 +864,7 @@ Opaque LSA .. index:: no capability opaque .. clicmd:: no capability opaque - *ospfd* support Opaque LSA (:rfc:`2370`) as fondment for MPLS Traffic + *ospfd* supports Opaque LSA (:rfc:`2370`) as fundamental for MPLS Traffic Engineering LSA. Prior to used MPLS TE, opaque-lsa must be enable in the configuration file. Alternate command could be "mpls-te on" (:ref:`ospf-traffic-engineering`). @@ -978,9 +977,9 @@ Router Information .. clicmd:: no pce scope The commands are conform to :rfc:`5088` and allow OSPF router announce Path - Compuatation Elemenent (PCE) capabilities through the Router Information - (RI) LSA. Router Information must be enable prior to this. The command - set/unset respectively the PCE IP adress, Autonomous System (AS) numbers of + Computation Element (PCE) capabilities through the Router Information (RI) + LSA. Router Information must be enable prior to this. The command set/unset + 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. @@ -1025,7 +1024,7 @@ This is an EXPERIMENTAL support of Segment Routing as per draft .. index:: [no] segment-routing prefix A.B.C.D/M index (0-65535) [no-php-flag] .. clicmd:: [no] segment-routing prefix A.B.C.D/M index (0-65535) [no-php-flag] - Set the Segment Rounting index for the specifyed prefix. Note that, only + Set the Segment Routing index for the specified prefix. Note that, only prefix with /32 corresponding to a loopback interface are currently supported. The 'no-php-flag' means NO Penultimate Hop Popping that allows SR node to request to its neighbor to not pop the label. @@ -1033,7 +1032,7 @@ This is an EXPERIMENTAL support of Segment Routing as per draft .. index:: show ip ospf database segment-routing <adv-router ADVROUTER|self-originate> [json] .. clicmd:: show ip ospf database segment-routing <adv-router ADVROUTER|self-originate> [json] - Show Segment Routing Data Base, all SR nodes, specific advertized router or + Show Segment Routing Data Base, all SR nodes, specific advertised router or self router. Optional JSON output can be obtained by appending 'json' to the end of the command. @@ -1289,7 +1288,7 @@ Then the :file:`ospfd.conf` itself: ! line vty -A router information example with PCE advsertisement: +A router information example with PCE advertisement: .. code-block:: frr diff --git a/doc/user/pim.rst b/doc/user/pim.rst index 2dda88a6d1..cf2c82171b 100644 --- a/doc/user/pim.rst +++ b/doc/user/pim.rst @@ -77,7 +77,7 @@ Certain signals have special meanings to *pimd*. .. clicmd:: ip pim ecmp rebalance If pim is using ECMP and an interface goes down, cause pim to rebalance all - S,G flows aross the remaining nexthops. If this command is not configured + S,G flows across the remaining nexthops. If this command is not configured pim only modifies those S,G flows that were using the interface that went down. This command is vrf aware, to configure for a vrf, enter the vrf submode. @@ -93,8 +93,8 @@ Certain signals have special meanings to *pimd*. .. clicmd:: ip pim keep-alive-timer (31-60000) Modify the time out value for a S,G flow from 31-60000 seconds. 31 seconds - is choosen for a lower bound because some hardware platforms cannot see data - flowing in better than 30 second chunks. This comand is vrf aware, to + is chosen for a lower bound because some hardware platforms cannot see data + flowing in better than 30 second chunks. This command is vrf aware, to configure for a vrf, enter the vrf submode. .. index:: ip pim packets (1-100) @@ -209,7 +209,7 @@ is in a vrf, enter the interface command with the vrf keyword at the end. .. clicmd:: ip multicat boundary oil WORD Set a pim multicast boundary, based upon the WORD prefix-list. If a pim join - or IGMP report is received on this interface and the Group is denyed by the + or IGMP report is received on this interface and the Group is denied by the prefix-list, PIM will ignore the join or report. .. _pim-multicast-rib-insertion: @@ -316,7 +316,7 @@ cause great confusion. .. index:: show ip pim nexthop-lookup .. clicmd:: show ip pim nexthop-lookup - Display information about a S,G pair and how the RPF would be choosen. This + Display information about a S,G pair and how the RPF would be chosen. This is especially useful if there are ECMP's available from the RPF lookup. .. index:: show ip pim rp-info @@ -341,7 +341,7 @@ cause great confusion. .. clicmd:: show ip pim state Display information about known S,G's and incoming interface as well as the - OIL and how they were choosen. + OIL and how they were chosen. .. index:: show ip pim upstream .. clicmd:: show ip pim upstream @@ -351,9 +351,8 @@ cause great confusion. .. index:: show ip pim upstream-join-desired .. clicmd:: show ip pim upstream-join-desired -{show PIM Information} {show ip pim upstream-join-desired} {} - Display upstream information for S,G's and if we desire to - join the mcast tree + Display upstream information for S,G's and if we desire to + join the multicast tree .. index:: show ip pim upstream-rpf .. clicmd:: show ip pim upstream-rpf @@ -369,8 +368,8 @@ PIM Debug Commands ================== The debugging subsystem for PIM behaves in accordance with how FRR handles -debugging. You can specify debugging at the enable cli mode as well as the -configure cli mode. If you specify debug commands in the configuration cli +debugging. You can specify debugging at the enable CLI mode as well as the +configure CLI mode. If you specify debug commands in the configuration cli mode, the debug commands can be persistent across restarts of the FRR pimd if the config was written out. @@ -406,4 +405,4 @@ the config was written out. .. index:: debug pim zebra .. clicmd:: debug pim zebra - This gathers data about events from zebra that come up through the zapi. + This gathers data about events from zebra that come up through the ZAPI. diff --git a/doc/user/ripd.rst b/doc/user/ripd.rst index d2686d2eae..973e61949e 100644 --- a/doc/user/ripd.rst +++ b/doc/user/ripd.rst @@ -10,7 +10,7 @@ XNS routing protocol. RIP is a :term:`distance-vector` protocol and is based on the :term:`Bellman-Ford` algorithms. As a distance-vector protocol, RIP router send updates to its neighbors periodically, thus allowing the convergence to a known topology. In each update, the -distance to any given network will be broadcasted to its neighboring +distance to any given network will be broadcast to its neighboring router. *ripd* supports RIP version 2 as described in RFC2453 and RIP @@ -42,7 +42,7 @@ Please note that *zebra* must be invoked before *ripd*. To stop *ripd*. Please use:: kill `cat /var/run/ripd.pid` -Certain signals have special meaningss to *ripd*. +Certain signals have special meanings to *ripd*. +-------------+------------------------------------------------------+ | Signal | Action | @@ -187,8 +187,8 @@ RIP Version Control RIP can be configured to send either Version 1 or Version 2 packets. The default is to send RIPv2 while accepting both RIPv1 and RIPv2 (and replying with packets of the appropriate version for REQUESTS / triggered updates). The -version to receive and send can be specified globally, and further overriden on -a per-interface basis if needs be for send and receive seperately (see below). +version to receive and send can be specified globally, and further overridden on +a per-interface basis if needs be for send and receive separately (see below). It is important to note that RIPv1 cannot be authenticated. Further, if RIPv1 is enabled then RIP will reply to REQUEST packets, sending the state of its RIP @@ -570,7 +570,7 @@ To prevent such unauthenticated querying of routes disable RIPv1, .. index:: no ip rip authentication key-chain KEY-CHAIN .. clicmd:: no ip rip authentication key-chain KEY-CHAIN - Specifiy Keyed MD5 chain. + Specify Keyed MD5 chain. .. code-block:: frr @@ -640,7 +640,7 @@ for routes redistributed into RIP. .. clicmd:: show ip rip status The command displays current RIP status. It includes RIP timer, - filtering, version, RIP enabled interface and RIP peer inforation. + filtering, version, RIP enabled interface and RIP peer information. :: diff --git a/doc/user/routemap.rst b/doc/user/routemap.rst index a0f28b5fc8..bddf2ba26d 100644 --- a/doc/user/routemap.rst +++ b/doc/user/routemap.rst @@ -8,14 +8,14 @@ Route maps provide a means to both filter and/or apply actions to route, hence 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: +to four distinct sets of clauses: .. glossary:: 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 + the Match Policy. If a route-map entry does not explicitly specify any matching conditions, then it always matches. Set Actions @@ -313,5 +313,5 @@ This means that if a route matches ip access-list number 10 it's local-preference value is set to 200. See :ref:`bgp-configuration-examples` for examples of more sophisticated -useage of route-maps, including of the ``call`` action. +usage of route-maps, including of the ``call`` action. diff --git a/doc/user/routeserver.rst b/doc/user/routeserver.rst index f2c2c6d33e..e677a3030d 100644 --- a/doc/user/routeserver.rst +++ b/doc/user/routeserver.rst @@ -130,7 +130,7 @@ It is also common to demand from a route server that it does not modify some BGP attributes (next-hop, as-path and MED) that are usually modified by standard BGP speakers before announcing a route. -The announcement processing model implemented by Frr is shown in +The announcement processing model implemented by FRR is shown in :ref:`fig-rs-processing`. The figure shows a mixture of RS-clients (B, C and D) with normal BGP peers (A). There are some details that worth additional comments: @@ -175,7 +175,7 @@ in order to support the route server features. This command configures the peer given by `peer`, `A.B.C.D` or `X:X::X:X` as an RS-client. - Actually this command is not new, it already existed in standard Frr. It + Actually this command is not new, it already existed in standard FRR. It enables the transparent mode for the specified peer. This means that some BGP attributes (as-path, next-hop and MED) of the routes announced to that peer are not modified. @@ -225,7 +225,7 @@ in order to support the route server features. Example of Route Server Configuration ------------------------------------- -Finally we are going to show how to configure a Frr daemon to act as a +Finally we are going to show how to configure a FRR daemon to act as a Route Server. For this purpose we are going to present a scenario without route server, and then we will show how to use the configurations of the BGP routers to generate the configuration of the route server. @@ -502,10 +502,10 @@ RA had the following filters configured for input from peer B: set community 65001:11111 -It is posible to write a single route-map which is equivalent to -the three filters (the community-list, the prefix-list and the -route-map). That route-map can then be used inside the Import -policy in the route server. Lets see how to do it: +It is possible to write a single route-map which is equivalent to the three +filters (the community-list, the prefix-list and the route-map). That route-map +can then be used inside the Import policy in the route server. Lets see how to +do it: .. code-block:: frr diff --git a/doc/user/vnc.rst b/doc/user/vnc.rst index ff6050ca68..d0934fe6fa 100644 --- a/doc/user/vnc.rst +++ b/doc/user/vnc.rst @@ -262,7 +262,7 @@ Defaults section. .. clicmd:: export bgp|zebra route-map MAP-NAME Specify that the named route-map should be applied to routes being exported - to bgp or zebra. This paramter is used in conjunction with + to bgp or zebra. This parameter is used in conjunction with :ref:`configuring-export-of-routes-to-other-routing-protocols`. This item is optional. @@ -270,7 +270,7 @@ Defaults section. .. clicmd:: export bgp|zebra no route-map Specify that no route-map should be applied to routes being exported to bgp - or zebra. This paramter is used in conjunction with + or zebra. This parameter is used in conjunction with :ref:`configuring-export-of-routes-to-other-routing-protocols`. This item is optional. @@ -279,7 +279,7 @@ Defaults section. Specify that the named prefix-list filter should be applied to routes being exported to bgp or zebra. Prefix-lists for ipv4 and ipv6 are independent of - each other. This paramter is used in conjunction with + each other. This parameter is used in conjunction with :ref:`configuring-export-of-routes-to-other-routing-protocols`. This item is optional. @@ -696,7 +696,7 @@ manually and dynamically added information. .. clicmd:: clear vnc prefix (\*|A.B.C.D/M|X:X::X:X/M) (\*|[(vn|un) (A.B.C.D|X:X::X:X|\*) [(un|vn) (A.B.C.D|X:X::X:X|\*)] [mac xx:xx:xx:xx:xx:xx] [local-next-hop (A.B.C.D|X:X::X:X)]) Delete the information identified by prefix, VN address, and UN address. - Any or all of these parameters may be wilcarded to (potentially) match more + Any or all of these parameters may be wildcarded to (potentially) match more than one registration. The optional `mac` parameter specifies a layer-2 MAC address that must match the registration(s) to be deleted. The optional `local-next-hop` parameter is used to delete specific local nexthop @@ -706,7 +706,7 @@ manually and dynamically added information. .. clicmd:: clear vnc mac (\*|xx:xx:xx:xx:xx:xx) virtual-network-identifier (\*|(1-4294967295)) (\*|[(vn|un) (A.B.C.D|X:X::X:X|\*) [(un|vn) (A.B.C.D|X:X::X:X|\*)] [prefix (\*|A.B.C.D/M|X:X::X:X/M)]) Delete mac forwarding information. Any or all of these parameters may be - wilcarded to (potentially) match more than one registration. The default + wildcarded to (potentially) match more than one registration. The default value for the `prefix` parameter is the wildcard value `*`. .. index:: clear vnc nve (\*|((vn|un) (A.B.C.D|X:X::X:X) [(un|vn) (A.B.C.D|X:X::X:X)])) @@ -1042,7 +1042,7 @@ Configuration for ``NVA 2``: .. TBD make this its own example: .. .. @float Figure,fig:fig-vnc-gw-rr -.. @center @image{fig-vnc-gw-rr,400pt,,Frr VNC Gateway with RR} +.. @center @image{fig-vnc-gw-rr,400pt,,FRR VNC Gateway with RR} .. @end float .. An NVA can also import unicast routes from BGP without advertising the .. imported routes as VPN routes. Such imported routes, while not @@ -1297,7 +1297,7 @@ reflector configuration. BGP route reflectors ``BGP Route Reflector 1`` and FRR-based NVA with redundant route reflectors -:file:`bgpd.conf` for ``Bgpd Route Reflector 1`` on 192.168.1.100: +:file:`bgpd.conf` for ``BPGD Route Reflector 1`` on 192.168.1.100: .. code-block:: frr diff --git a/doc/user/vtysh.rst b/doc/user/vtysh.rst index 71aab3975e..07109a0e54 100644 --- a/doc/user/vtysh.rst +++ b/doc/user/vtysh.rst @@ -93,7 +93,7 @@ Configuration saving, file ownership and permissions ---------------------------------------------------- The :file:`frr.conf` file is not written by any of the daemons; instead *vtysh* -contains the neccessary logic to collect configuration from all of the daemons, +contains the necessary logic to collect configuration from all of the daemons, combine it and write it out. .. warning:: diff --git a/doc/user/zebra.rst b/doc/user/zebra.rst index 7c886e785e..0927a4dbe9 100644 --- a/doc/user/zebra.rst +++ b/doc/user/zebra.rst @@ -78,8 +78,8 @@ Standard Commands .. clicmd:: no ip address LOCAL-ADDR peer PEER-ADDR/PREFIX - Configure an IPv4 Pointopoint address on the interface. (The concept of PtP - addressing does not exist for IPv6.) + Configure an IPv4 Point-to-Point address on the interface. (The concept of + PtP addressing does not exist for IPv6.) `local-addr` has no subnet mask since the local side in PtP addressing is always a single (/32) address. `peer-addr/prefix` can be an arbitrary subnet @@ -201,7 +201,7 @@ Link Parameters Commands .. index:: link-param use-bw BANDWIDTH .. clicmd:: link-param use-bw BANDWIDTH - These command specifies additionnal Traffic Engineering parameters of the + These command specifies additional Traffic Engineering parameters of the interface in conformity to draft-ietf-ospf-te-metrics-extension-05.txt and draft-ietf-isis-te-metrics-extension-03.txt. There are respectively the delay, jitter, loss, available bandwidth, reservable bandwidth and utilized @@ -304,8 +304,8 @@ nexthops, if the platform supports this. This will install a multihop route via the specified next-hops if they are reachable, as well as a high-metric blackhole route, which can be useful to -prevent traffic destined for a prefix to match less-specific routes (eg -default) should the specified gateways not be reachable. Eg: +prevent traffic destined for a prefix to match less-specific routes (e.g. +default) should the specified gateways not be reachable. E.g.: :: @@ -505,7 +505,7 @@ latter information makes up the Forwarding Information Base (FIB). Zebra feeds the FIB to the kernel, which allows the IP stack in the kernel to forward packets according to the routes computed by FRR. The kernel FIB is updated in an OS-specific way. For example, -the `netlink` interface is used on Linux, and route sockets are +the `Netlink` interface is used on Linux, and route sockets are used on FreeBSD. The FIB push interface aims to provide a cross-platform mechanism to @@ -530,7 +530,7 @@ kernel continues to receive FIB updates as before. The encapsulation header for the messages exchanged with the FPM is defined by the file :file:`fpm/fpm.h` in the frr tree. The routes -themselves are encoded in netlink or protobuf format, with netlink +themselves are encoded in Netlink or protobuf format, with Netlink being the default. Protobuf is one of a number of new serialization formats wherein the @@ -538,7 +538,7 @@ message schema is expressed in a purpose-built language. Code for encoding/decoding to/from the wire format is generated from the schema. Protobuf messages can be extended easily while maintaining backward-compatibility with older code. Protobuf has the following -advantages over netlink: +advantages over Netlink: - Code for serialization/deserialization is generated automatically. This reduces the likelihood of bugs, allows third-party programs to be integrated @@ -546,9 +546,9 @@ advantages over netlink: - The message format is not tied to an OS (Linux), and can be evolved independently. -As mentioned before, zebra encodes routes sent to the FPM in netlink +As mentioned before, zebra encodes routes sent to the FPM in Netlink format by default. The format can be controlled via the FPM module's -load-time option to zebra, which currently takes the values `netlink` +load-time option to zebra, which currently takes the values `Netlink` and `protobuf`. The zebra FPM interface uses replace semantics. That is, if a 'route diff --git a/lib/table.h b/lib/table.h index 9637fec149..a9d788b35a 100644 --- a/lib/table.h +++ b/lib/table.h @@ -24,6 +24,7 @@ #include "memory.h" #include "hash.h" +#include "prefix.h" DECLARE_MTYPE(ROUTE_TABLE) DECLARE_MTYPE(ROUTE_NODE) |