From: Quentin Young Date: Fri, 19 Jan 2018 19:13:00 +0000 (-0500) Subject: doc: Frr -> FRR X-Git-Tag: frr-5.0-dev~165^2~84 X-Git-Url: https://git.puffer.fish/?a=commitdiff_plain;h=dc1046f72608c0ee237c59957a240fbd135b794a;p=mirror%2Ffrr.git doc: Frr -> FRR Signed-off-by: Quentin Young --- diff --git a/doc/user/bgp.rst b/doc/user/bgp.rst index 9bc3b9a8af..fbc14ca140 100644 --- a/doc/user/bgp.rst +++ b/doc/user/bgp.rst @@ -107,7 +107,7 @@ BGP distance BGP decision process -------------------- -The decision process Frr BGP uses to select routes is as follows: +The decision process FRR BGP uses to select routes is as follows: @@ -258,7 +258,7 @@ The BGP MED (Multi_Exit_Discriminator) attribute has properties which can cause subtle convergence problems in BGP. These properties and problems have proven to be hard to understand, at least historically, and may still not be widely understood. The following attempts to collect together and -present what is known about MED, to help operators and Frr users in +present what is known about MED, to help operators and FRR users in designing and configuring their networks. The BGP :abbr:`MED ( Multi_Exit_Discriminator)` attribute is intended to @@ -281,7 +281,7 @@ MED values to those of AS X. The MED values have been set by different administrators, with different frames of reference. The default behaviour of BGP therefore is to not compare MED values across -routes received from different neighbouring ASes. In Frr this is done by +routes received from different neighbouring ASes. In FRR this is done by comparing the neighbouring, left-most AS in the received AS_PATHs of the routes and only comparing MED if those are the same. @@ -348,7 +348,7 @@ in response to the most common sequence of received updates. A deterministic order of evaluation tends to imply an additional overhead of sorting over any set of n routes to a destination. The implementation of -deterministic MED in Frr scales significantly worse than most sorting +deterministic MED in FRR scales significantly worse than most sorting algorithms at present, with the number of paths to a given destination. That number is often low enough to not cause any issues, but where there are many paths, the deterministic comparison may quickly become increasingly @@ -415,7 +415,7 @@ preferences between the routes: This particular type of oscillation in full-mesh iBGP topologies can be avoided by speakers preferring already selected, external routes rather than choosing to update to new a route based on a post-MED metric (e.g. -router-ID), at the cost of a non-deterministic selection process. Frr +router-ID), at the cost of a non-deterministic selection process. FRR implements this, as do many other implementations, so long as it is not overridden by setting :ref:`bgp_bestpath_compare-routerid`, and see also :ref:`BGP_decision_process`, . @@ -488,7 +488,7 @@ iBGP topology should follow the IGP topology. in. Setting this option will have a performance cost that may be noticeable when - there are many routes for each destination. Currently in Frr it is + there are many routes for each destination. Currently in FRR it is implemented in a way that scales poorly as the number of routes per destination increases. @@ -1804,11 +1804,11 @@ unicast neighbor, *bgpd* does not send these Capability Negotiation packets (at least not unless other optional BGP features require capability negotation). -By default, Frr will bring up peering with minimal common capability +By default, FRR will bring up peering with minimal common capability for the both sides. For example, local router has unicast and multicast capabilitie and remote router has unicast capability. In this case, the local router will establish the connection with unicast -only capability. When there are no common capabilities, Frr sends +only capability. When there are no common capabilities, FRR sends Unsupported Capability error and then resets the connection. If you want to completely match capabilities with remote peer. Please @@ -1938,10 +1938,10 @@ When bgp config-type cisco is specified, 'network' and 'aggregate-address' argument is displayed as 'A.B.C.D M.M.M.M' -Frr: network 10.0.0.0/8 +FRR: network 10.0.0.0/8 Cisco: network 10.0.0.0 -Frr: aggregate-address 192.168.0.0/24 +FRR: aggregate-address 192.168.0.0/24 Cisco: aggregate-address 192.168.0.0 255.255.255.0 Community attribute handling is also different. If there is no @@ -1972,7 +1972,7 @@ to specify *neighbor A.B.C.D send-community* command. .. index:: bgp config-type zebra ``bgp config-type zebra`` - Frr style BGP configuration. This is default. + FRR style BGP configuration. This is default. .. _BGP_instance_and_view: diff --git a/doc/user/filter.rst b/doc/user/filter.rst index 75f5933e7b..730e42403a 100644 --- a/doc/user/filter.rst +++ b/doc/user/filter.rst @@ -2,7 +2,7 @@ Filtering ********* -Frr provides many very flexible filtering features. Filtering is used +FRR provides many very flexible filtering features. Filtering is used for both input and output of the routing information. Once filtering is defined, it can be applied in any direction. diff --git a/doc/user/ipv6.rst b/doc/user/ipv6.rst index 0b1088e5d7..9a842ee595 100644 --- a/doc/user/ipv6.rst +++ b/doc/user/ipv6.rst @@ -4,13 +4,13 @@ IPv6 Support ************ -Frr fully supports IPv6 routing. As described so far, Frr supports +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 +and configure static IPv6 routing information. FRR IPv6 also provides automatic address configuration via a feature called ``address auto configuration``. To do it, the router must send router advertisement messages to the all nodes that exist on the network. -Previous versions of Frr could be built without IPv6 support. This is +Previous versions of FRR could be built without IPv6 support. This is no longer possible. Router Advertisement diff --git a/doc/user/kernel.rst b/doc/user/kernel.rst index 04559ffa9a..4161c4ae94 100644 --- a/doc/user/kernel.rst +++ b/doc/user/kernel.rst @@ -35,7 +35,7 @@ interfaces. *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 between kernel and Frr possible, similar to a routing + 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) @@ -45,7 +45,7 @@ interfaces. Today, the /dev/route special device file is obsolete. Netlink 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 + After the kernel configuration, please reconfigure and rebuild FRR. + You can use netlink as a dynamic routing update channel between FRR and the kernel. diff --git a/doc/user/main.rst b/doc/user/main.rst index a48a27d9c1..d42da83a46 100644 --- a/doc/user/main.rst +++ b/doc/user/main.rst @@ -351,7 +351,7 @@ addresses but unicast addresses. This table is fully separate from the default unicast table. However, RPF lookup can include the unicast table. -WARNING: RPF lookup results are non-responsive in this version of Frr, +WARNING: RPF lookup results are non-responsive in this version of FRR, i.e. multicast routing does not actively react to changes in underlying unicast topology! @@ -483,17 +483,17 @@ zebra FIB push interface ======================== Zebra supports a 'FIB push' interface that allows an external -component to learn the forwarding information computed by the Frr +component to learn the forwarding information computed by the FRR routing suite. This is a loadable module that needs to be enabled at startup as described in :ref:`Loadable_Module_Support`. -In Frr, the Routing Information Base (RIB) resides inside +In FRR, the Routing Information Base (RIB) resides inside zebra. Routing protocols communicate their best routes to zebra, and zebra computes the best route across protocols for each prefix. This latter information makes up the Forwarding Information Base (FIB). Zebra feeds the FIB to the kernel, which allows the IP stack in the kernel to forward packets according to the routes computed by -Frr. The kernel FIB is updated in an OS-specific way. For example, +FRR. The kernel FIB is updated in an OS-specific way. For example, the `netlink` interface is used on Linux, and route sockets are used on FreeBSD. diff --git a/doc/user/ospfd.rst b/doc/user/ospfd.rst index 78360c7503..65a5959447 100644 --- a/doc/user/ospfd.rst +++ b/doc/user/ospfd.rst @@ -79,7 +79,7 @@ Command {no router ospf} {} 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 + 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. @@ -186,7 +186,7 @@ Command {no router ospf} {} hold-time increasing by 400ms each time an SPF-triggering event occurs within the hold-time of the previous SPF calculation. - This command supercedes the *timers spf* command in previous Frr + This command supercedes the *timers spf* command in previous FRR releases. .. index:: {OSPF Command} {max-metric router-lsa [on-startup|on-shutdown] <5-86400>} {} @@ -309,7 +309,7 @@ OSPF area 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 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. + Summarizing Type-7 AS-external-LSAs isn't supported yet by FRR. :: diff --git a/doc/user/protocol.rst b/doc/user/protocol.rst index 2a9b76df03..2dce4c9855 100644 --- a/doc/user/protocol.rst +++ b/doc/user/protocol.rst @@ -32,7 +32,7 @@ seperate commands. Version 0 is used by all versions of GNU Zebra as of this writing, and versions of Quagga up to and including Quagga 0.98. Version 2 was created for 0.99.21 of Quagga. Version 3 designates VRF compatibility and was -released in 1.0. Version 4 will be used as of Frr 2.0 to indicate that +released in 1.0. Version 4 will be used as of FRR 2.0 to indicate that we are a different Routing Suite now and to hopefully prevent accidental Quagga <-> FRR issues. diff --git a/doc/user/ripd.rst b/doc/user/ripd.rst index dc9d7c06d2..53fca7c57f 100644 --- a/doc/user/ripd.rst +++ b/doc/user/ripd.rst @@ -86,7 +86,7 @@ to the packet on the basis of the interface that received the packet. Version 2 of RIP supports a variable length subnet mask (VLSM). By extending the subnet mask, the mask can be divided and reused. Each subnet can be used for different purposes such as large to middle size -LANs and WAN links. Frr *ripd* does not support the non-sequential +LANs and WAN links. FRR *ripd* does not support the non-sequential netmasks that are included in RIP Version 2. In a case of similar information with the same prefix and metric, the @@ -345,10 +345,10 @@ How to Announce RIP route .. index:: {RIP command} {no route `a.b.c.d/m`} {} {RIP command} {no route `a.b.c.d/m`} {} - This command is specific to Frr. The `route` command makes a static + This command is specific to FRR. The `route` command makes a static route only inside RIP. This command should be used only by advanced users who are particularly knowledgeable about the RIP protocol. In - most cases, we recommend creating a static route in Frr and + most cases, we recommend creating a static route in FRR and redistributing it in RIP using `redistribute static`. .. _Filtering_RIP_Routes: @@ -476,7 +476,7 @@ statement. Cisco applies route-map _before_ routes will exported to rip route table. -In current Frr's test implementation, *ripd* applies route-map +In current FRR's test implementation, *ripd* applies route-map after routes are listed in the route table and before routes will be announced to an interface (something like output filter). I think it is not so clear, but it is draft and it may be changed at future. diff --git a/doc/user/routeserver.rst b/doc/user/routeserver.rst index ac73e30b87..9ebbe17671 100644 --- a/doc/user/routeserver.rst +++ b/doc/user/routeserver.rst @@ -1,7 +1,7 @@ -.. _Configuring_Frr_as_a_Route_Server: +.. _Configuring_FRR_as_a_Route_Server: ********************************* -Configuring Frr as a Route Server +Configuring FRR as a Route Server ********************************* The purpose of a Route Server is to centralize the peerings between BGP @@ -11,8 +11,8 @@ speakers, each of which maintaining a BGP peering with the other three each of the four establishes a single BGP peering against the Route Server (:ref:`fig:route-server`). -We will first describe briefly the Route Server model implemented by Frr. +We will first describe briefly the Route Server model implemented by FRR. We will explain the commands that have been added for configuring that -model. And finally we will show a full example of Frr configured as Route +model. And finally we will show a full example of FRR configured as Route Server. diff --git a/doc/user/snmp.rst b/doc/user/snmp.rst index 286104e396..5c7da0e00c 100644 --- a/doc/user/snmp.rst +++ b/doc/user/snmp.rst @@ -6,7 +6,7 @@ SNMP Support @acronym{SNMP,Simple Network Managing Protocol} is a widely implemented feature for collecting network information from router and/or host. -Frr itself does not support SNMP agent (server daemon) functionality +FRR itself does not support SNMP agent (server daemon) functionality but is able to connect to a SNMP agent using the SMUX protocol (@cite{RFC1227}) or the AgentX protocol (@cite{RFC2741}) and make the routing protocol MIBs available through it. @@ -25,7 +25,7 @@ version of `net-snmp` which was formerly known as `ucd-snmp`. It is free and open software and available at `http://www.net-snmp.org/ `_ and as binary package for most Linux distributions. `net-snmp` has to be compiled with `--with-mib-modules=agentx` to -be able to accept connections from Frr using AgentX protocol or with +be able to accept connections from FRR using AgentX protocol or with `--with-mib-modules=smux` to use SMUX protocol. Nowadays, SMUX is a legacy protocol. The AgentX protocol should be @@ -36,11 +36,11 @@ preferred for any new deployment. Both protocols have the same coverage. AgentX configuration ==================== -To enable AgentX protocol support, Frr must have been build with the +To enable AgentX protocol support, FRR must have been build with the `--enable-snmp` or `--enable-snmp=agentx` option. Both the -master SNMP agent (snmpd) and each of the Frr daemons must be +master SNMP agent (snmpd) and each of the FRR daemons must be configured. In `/etc/snmp/snmpd.conf`, `master agentx` -directive should be added. In each of the Frr daemons, `agentx` +directive should be added. In each of the FRR daemons, `agentx` command will enable AgentX support. :: @@ -66,7 +66,7 @@ command will enable AgentX support. Upon successful connection, you should get something like this in the -log of each Frr daemons: +log of each FRR daemons: :: @@ -84,7 +84,7 @@ Then, you can use the following command to check everything works as expected: 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 need to configure Frr to use another transport, you can +was built. If need to configure FRR to use another transport, you can configure it through `/etc/snmp/frr.conf`: :: @@ -100,11 +100,11 @@ configure it through `/etc/snmp/frr.conf`: SMUX configuration ================== -To enable SMUX protocol support, Frr must have been build with the +To enable SMUX protocol support, FRR must have been build with the `--enable-snmp=smux` option. A separate connection has then to be established between the -SNMP agent (snmpd) and each of the Frr daemons. This connections +SNMP agent (snmpd) and each of the FRR daemons. This connections each use different OID numbers and passwords. Be aware that this OID number is not the one that is used in queries by clients, it is solely used for the intercommunication of the daemons. @@ -125,7 +125,7 @@ restrictions can be hard to debug. view all included .1 80 access MyROGroup "" any noauth exact all none none # - # the following line is relevant for Frr + # the following line is relevant for FRR # smuxpeer .1.3.6.1.4.1.3317.1.2.5 frr_ospfd @@ -159,7 +159,7 @@ MIB and command reference ========================= The following OID numbers are used for the interprocess communication of snmpd and -the Frr daemons with SMUX only. +the FRR daemons with SMUX only. :: (OIDs below .iso.org.dod.internet.private.enterprises) @@ -181,7 +181,7 @@ OID numbers are used for querying the SNMP daemon by a client: ospf6d .1.3.6.1.3.102 .iso.org.dod.internet.experimental.ospfv3 -The following syntax is understood by the Frr daemons for configuring SNMP using SMUX: +The following syntax is understood by the FRR daemons for configuring SNMP using SMUX: .. index:: {Command} {smux peer `oid`} {} {Command} {smux peer `oid`} {} diff --git a/doc/user/vnc.rst b/doc/user/vnc.rst index 6d9c4c40fe..525e4b1ecf 100644 --- a/doc/user/vnc.rst +++ b/doc/user/vnc.rst @@ -85,8 +85,8 @@ RFP Related Configuration The protocol that is used to communicate routing and Ethernet / L2 forwarding information between NVAs and NVEs is referred to as the Remote Forwarder Protocol (RFP). Currently, only a simple example RFP -is included in Frr. Developers may use this example as a starting -point to integrate Frr with an RFP of their choosing, e.g., +is included in FRR. Developers may use this example as a starting +point to integrate FRR with an RFP of their choosing, e.g., `OpenFlow`. The example code includes the following sample configuration: diff --git a/doc/user/vtysh.rst b/doc/user/vtysh.rst index a609c2fd7c..d94eba110e 100644 --- a/doc/user/vtysh.rst +++ b/doc/user/vtysh.rst @@ -4,7 +4,7 @@ VTY shell ********* -*vtysh* provides a combined frontend to all Frr daemons in a +*vtysh* provides a combined frontend to all FRR daemons in a single combined session. It is enabled by default at build time, but can be disabled through the *--disable-vtysh* option to *./configure*. @@ -30,7 +30,7 @@ that directory, plus membership in the *|INSTALL_VTY_GROUP|* group (which is the group that the daemons will change ownership of their sockets to). -To restrict access to Frr configuration, make sure no unauthorized users +To restrict access to FRR configuration, make sure no unauthorized users are members of the *|INSTALL_VTY_GROUP|* group. PAM support (experimental) @@ -103,7 +103,7 @@ file with incorrect owner or permissions. Writing the configuration can be triggered directly by invoking *vtysh -w*. This may be useful for scripting. Note this command -should be run as either the superuser or the Frr user. +should be run as either the superuser or the FRR user. We recommend you do not mix the use of the two types of files. Further, it is better not to use the integrated frr.conf file, as any syntax error in @@ -121,7 +121,7 @@ the daemon in whose file the error is made. 'write file' is issued. These commands need to be placed in :file:`vtysh.conf` to have any effect. - Note that since :file:`vtysh.conf` is not written by Frr itself, they + Note that since :file:`vtysh.conf` is not written by FRR itself, they therefore need to be manually placed in that file. This command has 3 states: