proxmox-mirrors/mirror_frr
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_frr synced 2025-08-09 03:47:47 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

doc: spelling fixes

Browse Source 
* Run sphinxcontrib-spelling over docs
* Correct spelling errors
* Compile a dictionary for future spellchecking efforts

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This commit is contained in:
Quentin Young 2018-04-17 14:57:32 -04:00
parent 7b9fdc412d
commit d1e7591eb2
17 changed files with 356 additions and 123 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

236
doc/extra/spelling_wordlist.txt Normal file
View File

@ -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

4
doc/user/basic.rst
View File

@ -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 ``fpm`` module can be loaded for the *zebra* daemon. This provides the
Forwarding Plane Manager ("FPM") API. Forwarding Plane Manager ("FPM") API.
The module expects its argument to be either ``netlink`` or ``protobuf``, The module expects its argument to be either ``Netlink`` or ``protobuf``,
specifying the encapsulation to use. ``netlink`` is the default, and specifying the encapsulation to use. ``Netlink`` is the default, and
``protobuf`` may not be available if the module was built without protobuf ``protobuf`` may not be available if the module was built without protobuf
support. Refer to :ref:`zebra-fib-push-interface` for more information. support. Refer to :ref:`zebra-fib-push-interface` for more information.

49
doc/user/bgp.rst
View File

@ -4,13 +4,12 @@
BGP BGP
*** ***
:abbr:`BGP` stands for a Border Gateway Protocol. The lastest BGP version is 4. :abbr:`BGP` stands for a Border Gateway Protocol. The latest BGP version is 4.
It is referred as BGP-4. BGP-4 is one of the Exterior Gateway Protocols and BGP-4 is one of the Exterior Gateway Protocols and the de facto standard
de-fact standard of Inter Domain routing protocol. BGP-4 is described in interdomain routing protocol. BGP-4 is described in :rfc:`1771`.
:rfc:`1771`.
Many extensions have been added to :rfc:`1771`. :rfc:`2858` provides Many extensions have been added to :rfc:`1771`. :rfc:`2858` adds multiprotocol
multiprotocol support to BGP-4. support to BGP-4.
.. _starting-bgp: .. _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 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 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 check. It may increase the possibility of MED or IGP oscillation, unless
other measures were taken to avoid these. The exact behaviour will be other measures were taken to avoid these. The exact behaviour will be
sensitive to the iBGP and reflection topology. sensitive to the iBGP and reflection topology.
@ -507,7 +506,7 @@ Route Aggregation
.. index:: aggregate-address A.B.C.D/M summary-only .. index:: aggregate-address A.B.C.D/M summary-only
.. clicmd:: 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. not be announce.
.. index:: no aggregate-address A.B.C.D/M .. 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 (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached
Established is considered an implicit-EOR. Established is considered an implicit-EOR.
If the establish-wait optional value is given, then BGP will wait for 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 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 which EOR is expected would be peers established during the establish-wait
window, not necessarily all the configured neighbors. window, not necessarily all the configured neighbors.
@ -702,7 +701,7 @@ required.
This command specifies an announced route's nexthop as being equivalent to 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 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. via iBGP.
.. index:: neighbor PEER update-source <IFNAME|ADDRESS> .. index:: neighbor PEER update-source <IFNAME|ADDRESS>
@ -798,7 +797,7 @@ required.
This command enforces Generalized TTL Security Mechanism (GTSM), as This command enforces Generalized TTL Security Mechanism (GTSM), as
specified in RFC 5082. With this command, only neighbors that are the specified in RFC 5082. With this command, only neighbors that are the
specified number of hops away will be allowed to become neighbors. This 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: .. _peer-filtering:
@ -995,7 +994,7 @@ numerical order.
BGP Community Lists 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 community list can be used for matching or manipulating BGP communities
attribute in updates. attribute in updates.
@ -1037,7 +1036,7 @@ expanded community list.
These commands delete community lists specified by NAME. All of These commands delete community lists specified by NAME. All of
community lists shares a single name space. So community lists can be 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 .. index:: show ip community-list
.. clicmd:: 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 .. index:: ip community-list NAME permit|deny COMMUNITY
.. clicmd:: 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 automatically detected. If COMMUNITY can be compiled into communities
attribute, the community list is defined as a standard community list. attribute, the community list is defined as a standard community list.
Otherwise it is defined as an expanded community list. This feature is left 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: .. _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 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 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 happen only when BGP updates have completely same communities value
specified in the community list. specified in the community list.
@ -1265,7 +1264,7 @@ limit the BGP routes announcement into the internal network.
match community 1 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 When there is no match community-list returns deny. To avoid
filtering all of routes, we need to define permit any at last. 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 These commands delete extended community lists specified by `name`. All of
extended community lists shares a single name space. So extended community 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 .. index:: show ip extcommunity-list
.. clicmd:: show ip extcommunity-list .. clicmd:: show ip extcommunity-list
@ -1540,7 +1539,7 @@ BGP Large Communities in Route Map
BGP VRFs 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 .. index:: router bgp ASN vrf VRFNAME
.. clicmd:: router bgp ASN vrf VRFNAME .. clicmd:: router bgp ASN vrf VRFNAME
@ -1651,7 +1650,7 @@ address-family:
.. clicmd:: route-map vpn import|export MAP .. clicmd:: route-map vpn import|export MAP
Specifies an optional route-map to be applied to routes imported or exported 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] .. index:: no route-map vpn import|export [MAP]
.. clicmd:: 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 .. index:: import|export vpn
.. clicmd:: 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 .. index:: no import|export vpn
.. clicmd:: 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: .. _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 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* 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 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 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 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 global prefixes and NO_EXPORT prefixes and providing actions for customer
routes based on community values. Extensive use of route-maps and the 'call' routes based on community values. Extensive use of route-maps and the 'call'
feature to support selective advertising of prefixes. This example is intended 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. mistakes, if not serious flaws.
.. code-block:: frr .. code-block:: frr
@ -2431,7 +2430,7 @@ mistakes, if not serious flaws.
.. include:: rpki.rst .. 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 .. [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 .. [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 .. [ibgp-correctness] Griffin, T. and G. Wilfong, "On the correctness of IBGP configuration", ACM SIGCOMM 2002

2
doc/user/eigrpd.rst
View File

@ -222,7 +222,7 @@ Debug for EIGRP protocol.
Debug eigrp packets 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 .. index:: debug eigrp transmit
.. clicmd:: debug eigrp transmit .. clicmd:: debug eigrp transmit

14
doc/user/installation.rst
View File

@ -11,7 +11,7 @@ Installation
.. index:: Making FRR .. index:: Making FRR
Several distributions provide packages for FRR. Check your distribution's 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. 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 .. option:: --enable-gcc-rdynamic
Pass the ``-rdynamic`` option to the linker driver. This is in most cases 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 compiler is detected as gcc, but giving an explicit enable/disable is
suggested. suggested.
@ -173,7 +173,7 @@ customize the build to include or exclude specific features and dependencies.
.. option:: --enable-numeric-version .. option:: --enable-numeric-version
Alpine Linux does not allow non-numeric characters in the version string. 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. package builds.
You may specify any combination of the above options to the configure 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> .. option:: --enable-vty-group <group>
Create Unix Vty sockets (for use with vtysh) with group owndership set to Create Unix Vty sockets (for use with vtysh) with group ownership set to
`group`. This allows one to create a seperate group which is restricted 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 accessing only the vty sockets, hence allowing one to delegate this group to
individual users, or to run vtysh setgid to this group. individual users, or to run vtysh setgid to this group.
@ -255,11 +255,11 @@ do exist.
- :makevar:`CONFIG_NETLINK` - :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`). advanced interface between the Linux kernel and zebra (:ref:`kernel-interface`).
- :makevar:`CONFIG_RTNETLINK` - :makevar:`CONFIG_RTNETLINK`
Routing messages. 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 specify this option, *zebra* can detect routing information
updates directly from the kernel (:ref:`kernel-interface`). updates directly from the kernel (:ref:`kernel-interface`).
- :makevar:`CONFIG_IP_MULTICAST` - :makevar:`CONFIG_IP_MULTICAST`

6
doc/user/ipv6.rst
View File

@ -4,7 +4,7 @@
IPv6 Support 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 OSPFv3, and BGP-4+. You can give IPv6 addresses to an interface and configure
static IPv6 routing information. FRR IPv6 also provides automatic address static IPv6 routing information. FRR IPv6 also provides automatic address
configuration via a feature called ``address auto configuration``. To do it, configuration via a feature called ``address auto configuration``. To do it,
@ -20,12 +20,12 @@ Router Advertisement
.. index:: no ipv6 nd suppress-ra .. index:: no ipv6 nd suppress-ra
.. clicmd:: no ipv6 nd suppress-ra .. clicmd:: no ipv6 nd suppress-ra
Send router advertisment messages. Send router advertisement messages.
.. index:: ipv6 nd suppress-ra .. index:: ipv6 nd suppress-ra
.. clicmd:: 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] .. 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] .. clicmd:: ipv6 nd prefix ipv6prefix [valid-lifetime] [preferred-lifetime] [off-link] [no-autoconfig] [router-address]

10
doc/user/kernel.rst
View File

@ -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 This is a special filesystem mount that provides an easy way of getting
kernel information. kernel information.
- routing socket / netlink - routing socket / Netlink
On recent Linux kernels (2.0.x and 2.2.x), there is a kernel/user 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. 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 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'. messages'.
Today, the :file:`/dev/route` special device file is obsolete. Netlink 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 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.

8
doc/user/ospf6d.rst
View File

@ -42,13 +42,13 @@ OSPF6 router
an event which occurs outside of the holdtime of any previous SPF an event which occurs outside of the holdtime of any previous SPF
calculation, and also serves as a minimum holdtime). 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 'hold-time' milliseconds. The hold-time is adaptive and initially is
set to the `initial-holdtime` configured with the above command. set to the `initial-holdtime` configured with the above command.
Events which occur within the holdtime of the previous SPF calculation Events which occur within the holdtime of the previous SPF calculation
will cause the holdtime to be increased by `initial-holdtime`, bounded will cause the holdtime to be increased by `initial-holdtime`, bounded
by the `maximum-holdtime` configured with this command. If the adaptive 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 is reset to the `initial-holdtime`.
.. code-block:: frr .. code-block:: frr
@ -61,7 +61,7 @@ OSPF6 router
to 400ms and the `maximum holdtime` to 10s. Hence there will always be at 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 least 200ms between an event which requires SPF calculation and the actual
SPF calculation. Further consecutive SPF calculations will always be 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 time an SPF-triggering event occurs within the hold-time of the previous
SPF calculation. SPF calculation.
@ -126,7 +126,7 @@ OSPF6 interface
.. index:: ipv6 ospf6 network (broadcast|point-to-point) .. index:: ipv6 ospf6 network (broadcast|point-to-point)
.. clicmd:: 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: .. _redistribute-routes-to-ospf6:

10
doc/user/ospf_fundamentals.rst
View File

@ -18,7 +18,7 @@ to their immediate neighbouring routers.
.. index:: Link State Database .. index:: Link State Database
Each router describes their link-state information in a message known as an 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`. 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 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 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, :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 will nearly all be covered in greater detail further on. They may be
broadly classed as: broadly classed as:
@ -118,7 +118,7 @@ LSA Flooding
OSPF defines several related mechanisms, used to manage synchronisation of 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 `flooding` of new or updated :abbr:`LSA` s. propagation, or `flooding` of new or updated :abbr:`LSA` s.
.. index:: OSPF Areas overview .. 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 LSA | Router ID | The :abbr:`OSPF` enabled links of the |
| | | router, within a specific link-state area. | | | | 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 | | | :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, 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 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 :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 Tag
An arbitrary 4-bytes of data, not interpreted by OSPF, which may carry An arbitrary 4-bytes of data, not interpreted by OSPF, which may carry

49
doc/user/ospfd.rst
View File

@ -74,11 +74,10 @@ writing, *ospfd* does not support multiple OSPF processes.
which still can reach the backbone - this restriction exists primarily which still can reach the backbone - this restriction exists primarily
to ensure routing-loops are avoided. to ensure routing-loops are avoided.
With the "Cisco" or "IBM" ABR type, the default in this release of With the "Cisco" or "IBM" ABR type, the default in this release of FRR, this
FRR, this restriction is lifted, allowing an ABR to consider restriction is lifted, allowing an ABR to consider summaries learned from
summaries learnt from other ABRs through non-backbone areas, and hence other ABRs through non-backbone areas, and hence route via non-backbone
route via non-backbone areas as a last resort when, and only when, areas as a last resort when, and only when, backbone links are down.
backbone links are down.
Note that areas with fully-adjacent virtual-links are considered to be Note that areas with fully-adjacent virtual-links are considered to be
"transit capable" and can always be used to route backbone traffic, and "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 .. index:: no ospf rfc1583compatibility
.. clicmd:: 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 to section G.2 (changes) in section 16.4 a change to the path
preference algorithm that prevents possible routing loops that were preference algorithm that prevents possible routing loops that were
possible in the old version of OSPFv2. More specifically it demands 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 an event which occurs outside of the holdtime of any previous SPF
calculation, and also serves as a minimum holdtime). 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 'hold-time' milliseconds. The hold-time is adaptive and initially is
set to the `initial-holdtime` configured with the above command. set to the `initial-holdtime` configured with the above command.
Events which occur within the holdtime of the previous SPF calculation Events which occur within the holdtime of the previous SPF calculation
will cause the holdtime to be increased by `initial-holdtime`, bounded will cause the holdtime to be increased by `initial-holdtime`, bounded
by the `maximum-holdtime` configured with this command. If the adaptive 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 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 holdtime can be viewed with :clicmd:`show ip ospf`, where it is expressed as
a multiplier of the `initial-holdtime`. 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 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 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 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 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 SPF-triggering event occurs within the hold-time of the previous SPF
calculation. calculation.
@ -254,7 +253,7 @@ writing, *ospfd* does not support multiple OSPF processes.
router ospf router ospf
network 192.168.1.0/24 area 0.0.0.0 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 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 ospf on interface with address 192.168.1.1/23, but it does on interface with
address 192.168.1.129/25. 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 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 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. 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.
@ -303,7 +302,7 @@ OSPF area
With configuration above one Type-3 Summary-LSA with routing info 10.0.0.0/8 is 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 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 .. index:: area A.B.C.D range IPV4_PREFIX not-advertise
.. clicmd:: 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 .. index:: no area A.B.C.D range IPV4_PREFIX not-advertise
.. clicmd:: 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. range are not advertised into other areas.
This command makes sense in ABR only. 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 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. network-LSA) from range 10.0.0.0/8.
This command makes sense in ABR only. This command makes sense in ABR only.
@ -550,11 +549,11 @@ OSPF interface
Note that OSPF MD5 authentication requires that time never go backwards Note that OSPF MD5 authentication requires that time never go backwards
(correct time is NOT important, only that it never goes backwards), even (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 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 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. expected to work reliably.
.. index:: ip ospf message-digest-key KEYID md5 KEY .. index:: ip ospf message-digest-key KEYID md5 KEY
@ -624,7 +623,7 @@ OSPF interface
.. index:: no ip ospf network .. index:: no ip ospf network
.. clicmd:: 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) .. index:: ip ospf priority (0-255)
.. clicmd:: ip ospf priority (0-255) .. clicmd:: ip ospf priority (0-255)
@ -865,7 +864,7 @@ Opaque LSA
.. index:: no capability opaque .. index:: no capability opaque
.. clicmd:: 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 Engineering LSA. Prior to used MPLS TE, opaque-lsa must be enable in the
configuration file. Alternate command could be "mpls-te on" configuration file. Alternate command could be "mpls-te on"
(:ref:`ospf-traffic-engineering`). (:ref:`ospf-traffic-engineering`).
@ -978,9 +977,9 @@ Router Information
.. clicmd:: no pce scope .. clicmd:: no pce scope
The commands are conform to :rfc:`5088` and allow OSPF router announce Path The commands are conform to :rfc:`5088` and allow OSPF router announce Path
Compuatation Elemenent (PCE) capabilities through the Router Information Computation Element (PCE) capabilities through the Router Information (RI)
(RI) LSA. Router Information must be enable prior to this. The command LSA. Router Information must be enable prior to this. The command set/unset
set/unset respectively the PCE IP adress, Autonomous System (AS) numbers of respectively the PCE IP address, Autonomous System (AS) numbers of
controlled domains, neighbor ASs, flag and scope. For flag and scope, please controlled domains, neighbor ASs, flag and scope. For flag and scope, please
refer to :rfc`5088` for the BITPATTERN recognition. Multiple 'pce neighbor' refer to :rfc`5088` for the BITPATTERN recognition. Multiple 'pce neighbor'
command could be specified in order to specify all PCE neighbours. command could be specified in order to specify all PCE 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] .. 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] .. 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 prefix with /32 corresponding to a loopback interface are currently
supported. The 'no-php-flag' means NO Penultimate Hop Popping that allows SR supported. The 'no-php-flag' means NO Penultimate Hop Popping that allows SR
node to request to its neighbor to not pop the label. 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] .. 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] .. 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 self router. Optional JSON output can be obtained by appending 'json' to the
end of the command. end of the command.
@ -1289,7 +1288,7 @@ Then the :file:`ospfd.conf` itself:
! !
line vty line vty
A router information example with PCE advsertisement: A router information example with PCE advertisement:
.. code-block:: frr .. code-block:: frr

23
doc/user/pim.rst
View File

@ -77,7 +77,7 @@ Certain signals have special meanings to *pimd*.
.. clicmd:: ip pim ecmp rebalance .. clicmd:: ip pim ecmp rebalance
If pim is using ECMP and an interface goes down, cause pim to rebalance all 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 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 down. This command is vrf aware, to configure for a vrf, enter the vrf
submode. submode.
@ -93,8 +93,8 @@ Certain signals have special meanings to *pimd*.
.. clicmd:: ip pim keep-alive-timer (31-60000) .. clicmd:: ip pim keep-alive-timer (31-60000)
Modify the time out value for a S,G flow from 31-60000 seconds. 31 seconds 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 is chosen for a lower bound because some hardware platforms cannot see data
flowing in better than 30 second chunks. This comand is vrf aware, to flowing in better than 30 second chunks. This command is vrf aware, to
configure for a vrf, enter the vrf submode. configure for a vrf, enter the vrf submode.
.. index:: ip pim packets (1-100) .. 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 .. clicmd:: ip multicat boundary oil WORD
Set a pim multicast boundary, based upon the WORD prefix-list. If a pim join 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. prefix-list, PIM will ignore the join or report.
.. _pim-multicast-rib-insertion: .. _pim-multicast-rib-insertion:
@ -316,7 +316,7 @@ cause great confusion.
.. index:: show ip pim nexthop-lookup .. index:: show ip pim nexthop-lookup
.. clicmd:: 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. is especially useful if there are ECMP's available from the RPF lookup.
.. index:: show ip pim rp-info .. index:: show ip pim rp-info
@ -341,7 +341,7 @@ cause great confusion.
.. clicmd:: show ip pim state .. clicmd:: show ip pim state
Display information about known S,G's and incoming interface as well as the 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 .. index:: show ip pim upstream
.. clicmd:: show ip pim upstream .. clicmd:: show ip pim upstream
@ -351,9 +351,8 @@ cause great confusion.
.. index:: show ip pim upstream-join-desired .. index:: show ip pim upstream-join-desired
.. clicmd:: 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
Display upstream information for S,G's and if we desire to join the multicast tree
join the mcast tree
.. index:: show ip pim upstream-rpf .. index:: show ip pim upstream-rpf
.. clicmd:: 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 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 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 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 mode, the debug commands can be persistent across restarts of the FRR pimd if
the config was written out. the config was written out.
@ -406,4 +405,4 @@ the config was written out.
.. index:: debug pim zebra .. index:: debug pim zebra
.. clicmd:: 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.

12
doc/user/ripd.rst
View File

@ -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 based on the :term:`Bellman-Ford` algorithms. As a distance-vector
protocol, RIP router send updates to its neighbors periodically, thus protocol, RIP router send updates to its neighbors periodically, thus
allowing the convergence to a known topology. In each update, the 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. router.
*ripd* supports RIP version 2 as described in RFC2453 and RIP *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:: To stop *ripd*. Please use::
kill `cat /var/run/ripd.pid` kill `cat /var/run/ripd.pid`
Certain signals have special meaningss to *ripd*. Certain signals have special meanings to *ripd*.
+-------------+------------------------------------------------------+ +-------------+------------------------------------------------------+
| Signal | Action | | Signal | Action |
@ -187,8 +187,8 @@ RIP Version Control
RIP can be configured to send either Version 1 or Version 2 packets. The 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 default is to send RIPv2 while accepting both RIPv1 and RIPv2 (and replying
with packets of the appropriate version for REQUESTS / triggered updates). The with packets of the appropriate version for REQUESTS / triggered updates). The
version to receive and send can be specified globally, and further overriden on version to receive and send can be specified globally, and further overridden on
a per-interface basis if needs be for send and receive seperately (see below). 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 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 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 .. index:: no ip rip authentication key-chain KEY-CHAIN
.. clicmd:: 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 .. code-block:: frr
@ -640,7 +640,7 @@ for routes redistributed into RIP.
.. clicmd:: show ip rip status .. clicmd:: show ip rip status
The command displays current RIP status. It includes RIP timer, 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.
:: ::

6
doc/user/routemap.rst
View File

@ -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. allowing policy to be applied to routes.
Route maps are an ordered list of route map entries. Each entry may specify up 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:: .. glossary::
Matching Conditions Matching Conditions
A route-map entry may, optionally, specify one or more conditions which 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 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. matching conditions, then it always matches.
Set Actions 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. local-preference value is set to 200.
See :ref:`bgp-configuration-examples` for examples of more sophisticated 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.

14
doc/user/routeserver.rst
View File

@ -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 BGP attributes (next-hop, as-path and MED) that are usually modified by
standard BGP speakers before announcing a route. 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) :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 with normal BGP peers (A). There are some details that worth additional
comments: 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 This command configures the peer given by `peer`, `A.B.C.D` or `X:X::X:X` as
an RS-client. 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 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 BGP attributes (as-path, next-hop and MED) of the routes announced to that
peer are not modified. peer are not modified.
@ -225,7 +225,7 @@ in order to support the route server features.
Example of Route Server Configuration 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. 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 route server, and then we will show how to use the configurations of the BGP
routers to generate the configuration of the route server. 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 set community 65001:11111
It is posible to write a single route-map which is equivalent to It is possible to write a single route-map which is equivalent to the three
the three filters (the community-list, the prefix-list and the filters (the community-list, the prefix-list and the route-map). That route-map
route-map). That route-map can then be used inside the Import can then be used inside the Import policy in the route server. Lets see how to
policy in the route server. Lets see how to do it: do it:
.. code-block:: frr .. code-block:: frr

14
doc/user/vnc.rst
View File

@ -262,7 +262,7 @@ Defaults section.
.. clicmd:: export bgp|zebra route-map MAP-NAME .. clicmd:: export bgp|zebra route-map MAP-NAME
Specify that the named route-map should be applied to routes being exported 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 :ref:`configuring-export-of-routes-to-other-routing-protocols`. This item
is optional. is optional.
@ -270,7 +270,7 @@ Defaults section.
.. clicmd:: export bgp|zebra no route-map .. clicmd:: export bgp|zebra no route-map
Specify that no route-map should be applied to routes being exported to bgp 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 :ref:`configuring-export-of-routes-to-other-routing-protocols`. This item
is optional. is optional.
@ -279,7 +279,7 @@ Defaults section.
Specify that the named prefix-list filter should be applied to routes being 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 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 :ref:`configuring-export-of-routes-to-other-routing-protocols`. This item
is optional. 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)]) .. 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. 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 than one registration. The optional `mac` parameter specifies a layer-2 MAC
address that must match the registration(s) to be deleted. The optional address that must match the registration(s) to be deleted. The optional
`local-next-hop` parameter is used to delete specific local nexthop `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)]) .. 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 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 `*`. 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)])) .. 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: .. TBD make this its own example:
.. ..
.. @float Figure,fig:fig-vnc-gw-rr .. @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 .. @end float
.. An NVA can also import unicast routes from BGP without advertising the .. An NVA can also import unicast routes from BGP without advertising the
.. imported routes as VPN routes. Such imported routes, while not .. 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 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 .. code-block:: frr

2
doc/user/vtysh.rst
View File

@ -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* 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. combine it and write it out.
.. warning:: .. warning::

20
doc/user/zebra.rst
View File

@ -78,8 +78,8 @@ Standard Commands
.. clicmd:: no ip address LOCAL-ADDR peer PEER-ADDR/PREFIX .. clicmd:: no ip address LOCAL-ADDR peer PEER-ADDR/PREFIX
Configure an IPv4 Pointopoint address on the interface. (The concept of PtP Configure an IPv4 Point-to-Point address on the interface. (The concept of
addressing does not exist for IPv6.) PtP addressing does not exist for IPv6.)
`local-addr` has no subnet mask since the local side in PtP addressing is `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 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 .. index:: link-param use-bw BANDWIDTH
.. clicmd:: 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 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 draft-ietf-isis-te-metrics-extension-03.txt. There are respectively the
delay, jitter, loss, available bandwidth, reservable bandwidth and utilized 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 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 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 prevent traffic destined for a prefix to match less-specific routes (e.g.
default) should the specified gateways not be reachable. Eg: 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 (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 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 the `Netlink` interface is used on Linux, and route sockets are
used on FreeBSD. used on FreeBSD.
The FIB push interface aims to provide a cross-platform mechanism to 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 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 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. being the default.
Protobuf is one of a number of new serialization formats wherein the 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 encoding/decoding to/from the wire format is generated from the
schema. Protobuf messages can be extended easily while maintaining schema. Protobuf messages can be extended easily while maintaining
backward-compatibility with older code. Protobuf has the following backward-compatibility with older code. Protobuf has the following
advantages over netlink: advantages over Netlink:
- Code for serialization/deserialization is generated automatically. This - Code for serialization/deserialization is generated automatically. This
reduces the likelihood of bugs, allows third-party programs to be integrated 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 - The message format is not tied to an OS (Linux), and can be evolved
independently. 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 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`. and `protobuf`.
The zebra FPM interface uses replace semantics. That is, if a 'route The zebra FPM interface uses replace semantics. That is, if a 'route