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

doc: use :abbr:

Browse Source 
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This commit is contained in:
Quentin Young 2018-01-26 16:10:07 -05:00
parent dfab2669d3
commit d50b2aa038
No known key found for this signature in database
GPG Key ID: DAF48E0F57E0834F
7 changed files with 109 additions and 109 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
doc/user/isisd.rst
View File

@ -4,12 +4,12 @@
ISIS ISIS
**** ****
@acronym{ISIS,Intermediate System to Intermediate System} is a routing protocol :abbr:`ISIS (Intermediate System to Intermediate System)` is a routing protocol
which is described in @cite{ISO10589, RFC1195, RFC5308}. ISIS is an which is described in @cite{ISO10589, RFC1195, RFC5308}. ISIS is an
@acronym{IGP,Interior Gateway Protocol}. Compared with @acronym{RIP}, :abbr:`IGP (Interior Gateway Protocol)`. Compared with :abbr:`RIP`,
@acronym{ISIS} can provide scalable network support and faster :abbr:`ISIS` can provide scalable network support and faster
convergence times like @acronym{OSPF}. ISIS is widely used in large networks such as convergence times like :abbr:`OSPF`. ISIS is widely used in large networks such as
@acronym{ISP,Internet Service Provider} and carrier backbone networks. :abbr:`ISP (Internet Service Provider)` and carrier backbone networks.
.. _Configuring_isisd: .. _Configuring_isisd:
@ -23,7 +23,7 @@ specified (:ref:`Common_Invocation_Options`) to *isisd*.
running before invoking *isisd*. Also, if *zebra* is running before invoking *isisd*. Also, if *zebra* is
restarted then *isisd* must be too. restarted then *isisd* must be too.
Like other daemons, *isisd* configuration is done in @acronym{ISIS} Like other daemons, *isisd* configuration is done in :abbr:`ISIS`
specific configuration file :file:`isisd.conf`. specific configuration file :file:`isisd.conf`.
.. _ISIS_router: .. _ISIS_router:

162
doc/user/ospf_fundamentals.rst
View File

@ -7,9 +7,9 @@ OSPF Fundamentals
.. index:: Distance-vector routing protocol .. index:: Distance-vector routing protocol
@acronym{OSPF} is, mostly, a link-state routing protocol. In contrast :abbr:`OSPF` is, mostly, a link-state routing protocol. In contrast
to :term:`distance-vector` protocols, such as @acronym{RIP} or to :term:`distance-vector` protocols, such as :abbr:`RIP` or
@acronym{BGP}, where routers describe available :term:`paths` (i.e@. routes) :abbr:`BGP`, where routers describe available :term:`paths` (i.e@. routes)
to each other, in :term:`link-state` protocols routers instead to each other, in :term:`link-state` protocols routers instead
describe the state of their links to their immediate neighbouring describe the state of their links to their immediate neighbouring
routers. routers.
@ -23,14 +23,14 @@ routers.
.. index:: Link State DataBase .. index:: Link State DataBase
Each router describes their link-state information in a message known Each router describes their link-state information in a message known
as an @acronym{LSA,Link State Advertisement}, which is then propogated as an :abbr:`LSA (Link State Advertisement)`, which is then propogated
through to all other routers in a link-state routing domain, by a through to all other routers in a link-state routing domain, by a
process called :term:`flooding`. Each router thus builds up an process called :term:`flooding`. Each router thus builds up an
@acronym{LSDB,Link State Database} of all the link-state messages. From :abbr:`LSDB (Link State Database)` of all the link-state messages. From
this collection of LSAs in the LSDB, each router can then calculate the this collection of LSAs in the LSDB, each router can then calculate the
shortest path to any other router, based on some common metric, by shortest path to any other router, based on some common metric, by
using an algorithm such as @url{http://www.cs.utexas.edu/users/EWD/, using an algorithm such as @url{http://www.cs.utexas.edu/users/EWD/,
Edgser Dijkstra}'s @acronym{SPF,Shortest Path First}. Edgser Dijkstra}'s :abbr:`SPF (Shortest Path First)`.
.. index:: Link-state routing protocol advantages .. index:: Link-state routing protocol advantages
@ -53,17 +53,17 @@ other than (potentially) select between multiple routes. This overhead
is mostly negligible for modern embedded CPUs, even for networks with is mostly negligible for modern embedded CPUs, even for networks with
thousands of nodes. The primary scaling overhead lies more in coping thousands of nodes. The primary scaling overhead lies more in coping
with the ever greater frequency of LSA updates as the size of a with the ever greater frequency of LSA updates as the size of a
link-state area increases, in managing the @acronym{LSDB} and required link-state area increases, in managing the :abbr:`LSDB` and required
flooding. flooding.
This section aims to give a distilled, but accurate, description of the This section aims to give a distilled, but accurate, description of the
more important workings of @acronym{OSPF}@ which an administrator may need more important workings of :abbr:`OSPF`@ which an administrator may need
to know to be able best configure and trouble-shoot @acronym{OSPF}@. to know to be able best configure and trouble-shoot :abbr:`OSPF`@.
OSPF Mechanisms OSPF Mechanisms
--------------- ---------------
@acronym{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 propogating 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:
@ -79,7 +79,7 @@ broadly classed as:
two-way reachability between routers on a link. OSPF can additionally two-way reachability between routers on a link. OSPF can additionally
avail of other sources of reachability information, such as link-state avail of other sources of reachability information, such as link-state
information provided by hardware, or through dedicated reachability information provided by hardware, or through dedicated reachability
protocols such as @acronym{BFD,Bi-directional Forwarding Detection}. protocols such as :abbr:`BFD (Bi-directional Forwarding Detection)`.
OSPF also uses the Hello protocol to propagate certain state between OSPF also uses the Hello protocol to propagate certain state between
routers sharing a link, for example: routers sharing a link, for example:
@ -100,10 +100,10 @@ broadly classed as:
*LSAs* *LSAs*
At the heart of @acronym{OSPF} are @acronym{LSA,Link State At the heart of :abbr:`OSPF` are :abbr:`LSA (Link State Advertisement)`
Advertisement} messages. Despite the name, some @acronym{LSA}s do not, messages. Despite the name, some :abbr:`LSA`s do not, strictly speaking,
strictly speaking, describe link-state information. Common describe link-state information. Common :abbr:`LSA`s describe information
@acronym{LSA}s describe information such as: such as:
** **
@ -117,21 +117,21 @@ broadly classed as:
*External Routes* *External Routes*
Routes entirely external to @acronym{OSPF}@. Routers originating such Routes entirely external to :abbr:`OSPF`@. Routers originating such
routes are known as @acronym{ASBR,Autonomous-System Border Router} routes are known as :abbr:`ASBR (Autonomous-System Border Router)`
routers. routers.
*Summary Routes* *Summary Routes*
Routes which summarise routing information relating to OSPF areas Routes which summarise routing information relating to OSPF areas
external to the OSPF link-state area at hand, originated by external to the OSPF link-state area at hand, originated by
@acronym{ABR,Area Boundary Router} routers. :abbr:`ABR (Area Boundary Router)` routers.
*LSA Flooding* *LSA Flooding*
OSPF defines several related mechanisms, used to manage synchronisation of OSPF defines several related mechanisms, used to manage synchronisation of
@acronym{LSDB}s between neighbours as neighbours form adjacencies and :abbr:`LSDB`s between neighbours as neighbours form adjacencies and
the propogation, or :term:`flooding` of new or updated @acronym{LSA}s. the propogation, or :term:`flooding` of new or updated :abbr:`LSA`s.
:ref:`OSPF_Flooding`. :ref:`OSPF_Flooding`.
@ -141,11 +141,11 @@ broadly classed as:
*Areas* *Areas*
OSPF provides for the protocol to be broken up into multiple smaller OSPF provides for the protocol to be broken up into multiple smaller
and independent link-state areas. Each area must be connected to a and independent link-state areas. Each area must be connected to a
common backbone area by an @acronym{ABR,Area Boundary Router}. These common backbone area by an :abbr:`ABR (Area Boundary Router)`. These
@acronym{ABR} routers are responsible for summarising the link-state :abbr:`ABR` routers are responsible for summarising the link-state
routing information of an area into :term:`Summary LSAs`, possibly in a routing information of an area into :term:`Summary LSAs`, possibly in a
condensed (i.e. aggregated) form, and then originating these summaries condensed (i.e. aggregated) form, and then originating these summaries
into all other areas the @acronym{ABR} is connected to. into all other areas the :abbr:`ABR` is connected to.
Note that only summaries and external routes are passed between areas. Note that only summaries and external routes are passed between areas.
As these describe *paths*, rather than any router link-states, As these describe *paths*, rather than any router link-states,
@ -157,16 +157,16 @@ broadly classed as:
OSPF LSAs OSPF LSAs
--------- ---------
@acronym{LSA}s are the core object in OSPF@. Everything else in OSPF :abbr:`LSA`s are the core object in OSPF@. Everything else in OSPF
revolves around detecting what to describe in LSAs, when to update revolves around detecting what to describe in LSAs, when to update
them, how to flood them throughout a network and how to calculate them, how to flood them throughout a network and how to calculate
routes from them. routes from them.
There are a variety of different @acronym{LSA}s, for purposes such There are a variety of different :abbr:`LSA`s, for purposes such
as describing actual link-state information, describing paths (i.e. as describing actual link-state information, describing paths (i.e.
routes), describing bandwidth usage of links for routes), describing bandwidth usage of links for
@acronym{TE,Traffic Engineering} purposes, and even arbitrary data :abbr:`TE (Traffic Engineering)` purposes, and even arbitrary data
by way of *Opaque* @acronym{LSA}s. by way of *Opaque* :abbr:`LSA`s.
LSA Header LSA Header
^^^^^^^^^^ ^^^^^^^^^^
@ -175,8 +175,8 @@ All LSAs share a common header with the following information:
* Type * Type
Different types of @acronym{LSA}s describe different things in Different types of :abbr:`LSA`s describe different things in
@acronym{OSPF}@. Types include: :abbr:`OSPF`@. Types include:
* Router LSA * Router LSA
* Network LSA * Network LSA
@ -194,18 +194,18 @@ All LSAs share a common header with the following information:
The ID of the LSA, which is typically derived in some way from the The ID of the LSA, which is typically derived in some way from the
information the LSA describes, e.g. a Router LSA uses the Router ID as information the LSA describes, e.g. a Router LSA uses the Router ID as
the LSA ID, a Network LSA will have the IP address of the @acronym{DR} the LSA ID, a Network LSA will have the IP address of the :abbr:`DR`
as its LSA ID@. as its LSA ID@.
The combination of the Type, ID and Advertising Router ID must uniquely The combination of the Type, ID and Advertising Router ID must uniquely
identify the @acronym{LSA}@. There can however be multiple instances of identify the :abbr:`LSA`@. There can however be multiple instances of
an LSA with the same Type, LSA ID and Advertising Router ID, see an LSA with the same Type, LSA ID and Advertising Router ID, see
:ref:`OSPF_LSA_sequence_number,,LSA_Sequence_Number`. :ref:`OSPF_LSA_sequence_number,,LSA_Sequence_Number`.
* Age * Age
A number to allow stale @acronym{LSA}s to, eventually, be purged by routers A number to allow stale :abbr:`LSA`s to, eventually, be purged by routers
from their @acronym{LSDB}s. from their :abbr:`LSDB`s.
The value nominally is one of seconds. An age of 3600, i.e. 1 hour, is The value nominally is one of seconds. An age of 3600, i.e. 1 hour, is
called the :term:`MaxAge`. MaxAge LSAs are ignored in routing called the :term:`MaxAge`. MaxAge LSAs are ignored in routing
@ -229,9 +229,9 @@ All LSAs share a common header with the following information:
Link-State LSAs Link-State LSAs
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^
Of all the various kinds of @acronym{LSA}s, just two types comprise the Of all the various kinds of :abbr:`LSA`s, just two types comprise the
actual link-state part of @acronym{OSPF}, Router @acronym{LSA}s and actual link-state part of :abbr:`OSPF`, Router :abbr:`LSA`s and
Network @acronym{LSA}s. These LSA types are absolutely core to the Network :abbr:`LSA`s. These LSA types are absolutely core to the
protocol. protocol.
Instances of these LSAs are specific to the link-state area in which Instances of these LSAs are specific to the link-state area in which
@ -240,8 +240,8 @@ called :term:`intra-area routes`.
* Router LSA * Router LSA
Each OSPF Router must originate a router @acronym{LSA} to describe Each OSPF Router must originate a router :abbr:`LSA` to describe
itself. In it, the router lists each of its @acronym{OSPF} enabled itself. In it, the router lists each of its :abbr:`OSPF` enabled
interfaces, for the given link-state area, in terms of: interfaces, for the given link-state area, in terms of:
* Cost * Cost
@ -256,10 +256,10 @@ called :term:`intra-area routes`.
A link to a multi-access network, on which the router has at least one A link to a multi-access network, on which the router has at least one
Full adjacency with another router. Full adjacency with another router.
* @acronym{PtP,Point-to-Point} * :abbr:`PtP (Point-to-Point)`
A link to a single remote router, with a Full adjacency. No A link to a single remote router, with a Full adjacency. No
@acronym{DR, Designated Router} is elected on such links; no network :abbr:`DR (Designated Router)` is elected on such links; no network
LSA is originated for such a link. LSA is originated for such a link.
* Stub * Stub
@ -274,13 +274,13 @@ called :term:`intra-area routes`.
@headitem Link Type @tab Link ID @tab Link Data @headitem Link Type @tab Link ID @tab Link Data
* Transit * Transit
@tab Link IP address of the @acronym{DR} @tab Link IP address of the :abbr:`DR`
@tab Interface IP address @tab Interface IP address
* Point-to-Point * Point-to-Point
@tab Router ID of the remote router @tab Router ID of the remote router
@tab Local interface IP address, @tab Local interface IP address,
or the @acronym{ifindex,MIB-II interface index} or the :abbr:`ifindex (MIB-II interface index)`
for unnumbered links for unnumbered links
* Stub * Stub
@ -290,9 +290,9 @@ called :term:`intra-area routes`.
@end multitable @end multitable
Links on a router may be listed multiple times in the Router LSA, e.g. Links on a router may be listed multiple times in the Router LSA, e.g.
a @acronym{PtP} interface on which OSPF is enabled must *always* a :abbr:`PtP` interface on which OSPF is enabled must *always*
be described by a Stub link in the Router @acronym{LSA}, in addition to be described by a Stub link in the Router :abbr:`LSA`, in addition to
being listed as PtP link in the Router @acronym{LSA} if the adjacency being listed as PtP link in the Router :abbr:`LSA` if the adjacency
with the remote router is Full. with the remote router is Full.
Stub links may also be used as a way to describe links on which OSPF is Stub links may also be used as a way to describe links on which OSPF is
@ -301,25 +301,25 @@ called :term:`intra-area routes`.
* Network LSA * Network LSA
On multi-access links (e.g. ethernets, certain kinds of ATM and X@.25 On multi-access links (e.g. ethernets, certain kinds of ATM and X@.25
configurations), routers elect a @acronym{DR}@. The @acronym{DR} is configurations), routers elect a :abbr:`DR`@. The :abbr:`DR` is
responsible for originating a Network @acronym{LSA}, which helps reduce responsible for originating a Network :abbr:`LSA`, which helps reduce
the information needed to describe multi-access networks with multiple the information needed to describe multi-access networks with multiple
routers attached. The @acronym{DR} also acts as a hub for the flooding of routers attached. The :abbr:`DR` also acts as a hub for the flooding of
@acronym{LSA}s on that link, thus reducing flooding overheads. :abbr:`LSA`s on that link, thus reducing flooding overheads.
The contents of the Network LSA describes the: The contents of the Network LSA describes the:
* Subnet Mask * Subnet Mask
As the @acronym{LSA} ID of a Network LSA must be the IP address of the As the :abbr:`LSA` ID of a Network LSA must be the IP address of the
@acronym{DR}, the Subnet Mask together with the @acronym{LSA} ID gives :abbr:`DR`, the Subnet Mask together with the :abbr:`LSA` ID gives
you the network address. you the network address.
* Attached Routers * Attached Routers
Each router fully-adjacent with the @acronym{DR} is listed in the LSA, Each router fully-adjacent with the :abbr:`DR` is listed in the LSA,
by their Router-ID. This allows the corresponding Router @acronym{LSA}s to be by their Router-ID. This allows the corresponding Router :abbr:`LSA`s to be
easily retrieved from the @acronym{LSDB}@. easily retrieved from the :abbr:`LSDB`@.
Summary of Link State LSAs: Summary of Link State LSAs:
@ -328,28 +328,28 @@ Summary of Link State LSAs:
* Router LSA * Router LSA
@tab The Router ID @tab The Router ID
@tab The @acronym{OSPF} enabled links of the router, within @tab The :abbr:`OSPF` enabled links of the router, within
a specific link-state area. a specific link-state area.
* Network LSA * Network LSA
@tab The IP address of the @acronym{DR} for the network @tab The IP address of the :abbr:`DR` for the network
@tab The Subnet Mask of the network, and the Router IDs of all routers @tab The Subnet Mask of the network, and the Router IDs of all routers
on the network. on the network.
@end multitable @end multitable
With an LSDB composed of just these two types of @acronym{LSA}, it is With an LSDB composed of just these two types of :abbr:`LSA`, it is
possible to construct a directed graph of the connectivity between all possible to construct a directed graph of the connectivity between all
routers and networks in a given OSPF link-state area. So, not routers and networks in a given OSPF link-state area. So, not
surprisingly, when OSPF routers build updated routing tables, the first surprisingly, when OSPF routers build updated routing tables, the first
stage of @acronym{SPF} calculation concerns itself only with these two stage of :abbr:`SPF` calculation concerns itself only with these two
LSA types. LSA types.
Link-State LSA Examples Link-State LSA Examples
^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^
The example below (:ref:`OSPF_Link-State_LSA_Example`) shows two The example below (:ref:`OSPF_Link-State_LSA_Example`) shows two
@acronym{LSA}s, both originated by the same router (Router ID :abbr:`LSA`s, both originated by the same router (Router ID
192.168.0.49) and with the same @acronym{LSA} ID (192.168.0.49), but of 192.168.0.49) and with the same :abbr:`LSA` ID (192.168.0.49), but of
different LSA types. different LSA types.
The first LSA being the router LSA describing 192.168.0.49's links: 2 links The first LSA being the router LSA describing 192.168.0.49's links: 2 links
@ -357,7 +357,7 @@ to multi-access networks with fully-adjacent neighbours (i.e. Transit
links) and 1 being a Stub link (no adjacent neighbours). links) and 1 being a Stub link (no adjacent neighbours).
The second LSA being a Network LSA, for which 192.168.0.49 is the The second LSA being a Network LSA, for which 192.168.0.49 is the
@acronym{DR}, listing the Router IDs of 4 routers on that network which :abbr:`DR`, listing the Router IDs of 4 routers on that network which
are fully adjacent with 192.168.0.49. are fully adjacent with 192.168.0.49.
.. _OSPF_Link-State_LSA_Example: .. _OSPF_Link-State_LSA_Example:
@ -423,19 +423,19 @@ are fully adjacent with 192.168.0.49.
Note that from one LSA, you can find the other. E.g. Given the Note that from one LSA, you can find the other. E.g. Given the
Network-LSA you have a list of Router IDs on that network, from which Network-LSA you have a list of Router IDs on that network, from which
you can then look up, in the local @acronym{LSDB}, the matching Router you can then look up, in the local :abbr:`LSDB`, the matching Router
LSA@. From that Router-LSA you may (potentially) find links to other LSA@. From that Router-LSA you may (potentially) find links to other
Transit networks and Routers IDs which can be used to lookup the Transit networks and Routers IDs which can be used to lookup the
corresponding Router or Network LSA@. And in that fashion, one can find corresponding Router or Network LSA@. And in that fashion, one can find
all the Routers and Networks reachable from that starting @acronym{LSA}@. all the Routers and Networks reachable from that starting :abbr:`LSA`@.
Given the Router LSA instead, you have the IP address of the Given the Router LSA instead, you have the IP address of the
@acronym{DR} of any attached transit links. Network LSAs will have that IP :abbr:`DR` of any attached transit links. Network LSAs will have that IP
as their LSA ID, so you can then look up that Network LSA and from that as their LSA ID, so you can then look up that Network LSA and from that
find all the attached routers on that link, leading potentially to more find all the attached routers on that link, leading potentially to more
links and Network and Router LSAs, etc. etc. links and Network and Router LSAs, etc. etc.
From just the above two @acronym{LSA}s, one can already see the From just the above two :abbr:`LSA`s, one can already see the
following partial topology: following partial topology:
:: ::
@ -469,33 +469,33 @@ reachable addresses (though, OSPF will calculate routes to Router IDs).
External LSAs External LSAs
^^^^^^^^^^^^^ ^^^^^^^^^^^^^
External, or "Type 5", @acronym{LSA}s describe routing information which is External, or "Type 5", :abbr:`LSA`s describe routing information which is
entirely external to @acronym{OSPF}, and is "injected" into entirely external to :abbr:`OSPF`, and is "injected" into
@acronym{OSPF}@. Such routing information may have come from another :abbr:`OSPF`@. Such routing information may have come from another
routing protocol, such as RIP or BGP, they may represent static routes routing protocol, such as RIP or BGP, they may represent static routes
or they may represent a default route. or they may represent a default route.
An @acronym{OSPF} router which originates External @acronym{LSA}s is known as an An :abbr:`OSPF` router which originates External :abbr:`LSA`s is known as an
@acronym{ASBR,AS Boundary Router}. Unlike the link-state @acronym{LSA}s, and :abbr:`ASBR (AS Boundary Router)`. Unlike the link-state :abbr:`LSA`s, and
most other @acronym{LSA}s, which are flooded only within the area in most other :abbr:`LSA`s, which are flooded only within the area in
which they originate, External @acronym{LSA}s are flooded through-out which they originate, External :abbr:`LSA`s are flooded through-out
the @acronym{OSPF} network to all areas capable of carrying External the :abbr:`OSPF` network to all areas capable of carrying External
@acronym{LSA}s (:ref:`OSPF_Areas`). :abbr:`LSA`s (:ref:`OSPF_Areas`).
Routes internal to OSPF (intra-area or inter-area) are always preferred Routes internal to OSPF (intra-area or inter-area) are always preferred
over external routes. over external routes.
The External @acronym{LSA} describes the following: The External :abbr:`LSA` describes the following:
* IP Network number * IP Network number
The IP Network number of the route is described by the @acronym{LSA} ID The IP Network number of the route is described by the :abbr:`LSA` ID
field. field.
* IP Network Mask * IP Network Mask
The body of the External LSA describes the IP Network Mask of the The body of the External LSA describes the IP Network Mask of the
route. This, together with the @acronym{LSA} ID, describes the prefix route. This, together with the :abbr:`LSA` ID, describes the prefix
of the IP route concerned. of the IP route concerned.
* Metric * Metric
@ -511,7 +511,7 @@ The External @acronym{LSA} describes the following:
The address of the router to forward packets to for the route. This may 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 be, and usually is, left as 0 to specify that the ASBR originating the
External @acronym{LSA} should be used. There must be an internal OSPF External :abbr:`LSA` should be used. There must be an internal OSPF
route to the forwarding address, for the forwarding address to be route to the forwarding address, for the forwarding address to be
useable. useable.
@ -523,8 +523,8 @@ The External @acronym{LSA} describes the following:
AS External LSA Example AS External LSA Example
^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^
To illustrate, below is an example of an External @acronym{LSA} in the To illustrate, below is an example of an External :abbr:`LSA` in the
@acronym{LSDB} of an OSPF router. It describes a route to the IP prefix :abbr:`LSDB` of an OSPF router. It describes a route to the IP prefix
of 192.168.165.0/24, originated by the ASBR with Router-ID of 192.168.165.0/24, originated by the ASBR with Router-ID
192.168.0.49. The metric of 20 is external to OSPF. The forwarding 192.168.0.49. The metric of 20 is external to OSPF. The forwarding
address is 0, so the route should forward to the originating ASBR if address is 0, so the route should forward to the originating ASBR if
@ -579,7 +579,7 @@ like:
Summary LSAs Summary LSAs
^^^^^^^^^^^^ ^^^^^^^^^^^^
Summary LSAs are created by @acronym{ABR}s to summarise the destinations available within one area to other areas. These LSAs may describe IP networks, potentially in aggregated form, or @acronym{ASBR} routers. Summary LSAs are created by :abbr:`ABR`s to summarise the destinations available within one area to other areas. These LSAs may describe IP networks, potentially in aggregated form, or :abbr:`ASBR` routers.
.. _OSPF_Flooding: .. _OSPF_Flooding:

16
doc/user/ospfd.rst
View File

@ -4,12 +4,12 @@
OSPFv2 OSPFv2
****** ******
@acronym{OSPF,Open Shortest Path First} version 2 is a routing protocol :abbr:`OSPF (Open Shortest Path First)` version 2 is a routing protocol
which is described in :rfc:`2328`. OSPF is an which is described in :rfc:`2328`. OSPF is an
@acronym{IGP,Interior Gateway Protocol}. Compared with @acronym{RIP}, :abbr:`IGP (Interior Gateway Protocol)`. Compared with :abbr:`RIP`,
@acronym{OSPF} can provide scalable network support and faster :abbr:`OSPF` can provide scalable network support and faster
convergence times. OSPF is widely used in large networks such as convergence times. OSPF is widely used in large networks such as
@acronym{ISP,Internet Service Provider} backbone and enterprise :abbr:`ISP (Internet Service Provider)` backbone and enterprise
networks. networks.
@include ospf_fundamentals.texi @include ospf_fundamentals.texi
@ -26,7 +26,7 @@ specified (:ref:`Common_Invocation_Options`) to *ospfd*.
running before invoking *ospfd*. Also, if *zebra* is running before invoking *ospfd*. Also, if *zebra* is
restarted then *ospfd* must be too. restarted then *ospfd* must be too.
Like other daemons, *ospfd* configuration is done in @acronym{OSPF} Like other daemons, *ospfd* configuration is done in :abbr:`OSPF`
specific configuration file :file:`ospfd.conf`. specific configuration file :file:`ospfd.conf`.
.. _OSPF_router: .. _OSPF_router:
@ -92,7 +92,7 @@ Command {no router ospf} {}
be found in @cite{RFC 3509, Alternative Implementations of OSPF Area be found in @cite{RFC 3509, Alternative Implementations of OSPF Area
Border Routers}, and @cite{draft-ietf-ospf-shortcut-abr-02.txt}. Border Routers}, and @cite{draft-ietf-ospf-shortcut-abr-02.txt}.
Quote: "Though the definition of the @acronym{ABR,Area Border Router} Quote: "Though the definition of the :abbr:`ABR (Area Border Router)`
in the OSPF specification does not require a router with multiple in the OSPF specification does not require a router with multiple
attached areas to have a backbone connection, it is actually attached areas to have a backbone connection, it is actually
necessary to provide successful routing to the inter-area and necessary to provide successful routing to the inter-area and
@ -136,7 +136,7 @@ Command {no router ospf} {}
Do not speak OSPF interface on the Do not speak OSPF interface on the
given interface, but do advertise the interface as a stub link in the given interface, but do advertise the interface as a stub link in the
router-@acronym{LSA,Link State Advertisement} for this router. This router-:abbr:`LSA (Link State Advertisement)` for this router. This
allows one to advertise addresses on such connected interfaces without allows one to advertise addresses on such connected interfaces without
having to originate AS-External/Type-5 LSAs (which have global flooding having to originate AS-External/Type-5 LSAs (which have global flooding
scope) - as would occur if connected addresses were redistributed into scope) - as would occur if connected addresses were redistributed into
@ -1129,7 +1129,7 @@ A simple example, with MD5 authentication enabled:
area 0.0.0.1 authentication message-digest area 0.0.0.1 authentication message-digest
An @acronym{ABR} router, with MD5 authentication and performing summarisation An :abbr:`ABR` router, with MD5 authentication and performing summarisation
of networks between the areas: of networks between the areas:
:: ::

2
doc/user/ripd.rst
View File

@ -531,7 +531,7 @@ RIP Authentication
RIPv2 allows packets to be authenticated via either an insecure plain RIPv2 allows packets to be authenticated via either an insecure plain
text password, included with the packet, or via a more secure MD5 based text password, included with the packet, or via a more secure MD5 based
@acronym{HMAC, keyed-Hashing for Message AuthentiCation}, :abbr:`HMAC (keyed-Hashing for Message AuthentiCation)`,
RIPv1 can not be authenticated at all, thus when authentication is RIPv1 can not be authenticated at all, thus when authentication is
configured `ripd` will discard routing updates received via RIPv1 configured `ripd` will discard routing updates received via RIPv1
packets. packets.

4
doc/user/rpki.rst
View File

@ -6,10 +6,10 @@ Prefix Origin Validation Using RPKI
Prefix Origin Validation allows BGP routers to verify if the origin AS of Prefix Origin Validation allows BGP routers to verify if the origin AS of
an IP prefix is legitimate to announce this IP prefix. The required an IP prefix is legitimate to announce this IP prefix. The required
attestation objects are stored in the Resource Public Key Infrastructure attestation objects are stored in the Resource Public Key Infrastructure
(@acronym{RPKI}). However, RPKI-enabled routers do not store cryptographic (:abbr:`RPKI`). However, RPKI-enabled routers do not store cryptographic
data itself but only validation information. The validation of the data itself but only validation information. The validation of the
cryptographic data (so called Route Origin Authorization, or short cryptographic data (so called Route Origin Authorization, or short
@acronym{ROA}, objects) will be performed by trusted cache servers. The :abbr:`ROA`, objects) will be performed by trusted cache servers. The
RPKI/RTR protocol defines a standard mechanism to maintain the exchange of RPKI/RTR protocol defines a standard mechanism to maintain the exchange of
the prefix/origin AS mapping between the cache server and routers. the prefix/origin AS mapping between the cache server and routers.
In combination with a BGP Prefix Origin Validation scheme a router is able In combination with a BGP Prefix Origin Validation scheme a router is able

2
doc/user/snmp.rst
View File

@ -4,7 +4,7 @@
SNMP Support SNMP Support
************ ************
@acronym{SNMP,Simple Network Managing Protocol} is a widely implemented :abbr:`SNMP (Simple Network Managing Protocol)` is a widely implemented
feature for collecting network information from router and/or host. 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 but is able to connect to a SNMP agent using the SMUX protocol

20
doc/user/vnc.rst
View File

@ -5,15 +5,15 @@ VNC and VNC-GW
************** **************
This chapter describes how to use This chapter describes how to use
Virtual Network Control (@acronym{VNC}) services, Virtual Network Control (:abbr:`VNC`) services,
including Network Virtualization Authority (@acronym{NVA}) and including Network Virtualization Authority (:abbr:`NVA`) and
VNC Gateway (@acronym{VNC-GW}) functions. VNC Gateway (:abbr:`VNC-GW`) functions.
Background information on NVAs, Background information on NVAs,
Network Virtualization Edges (@acronym{NVE}s), underlay networks (@acronym{UN}s), Network Virtualization Edges (:abbr:`NVE`s), underlay networks (:abbr:`UN`s),
and virtual networks (@acronym{VN}s) is available from the and virtual networks (:abbr:`VN`s) is available from the
`https://datatracker.ietf.org/wg/nvo3,IETF Network Virtualization Overlays (@acronym{NVO3 <https://datatracker.ietf.org/wg/nvo3,IETF Network Virtualization Overlays (@acronym{NVO3>`_) Working Group}. `IETF Network Virtualization Overlays <https://datatracker.ietf.org/wg/nvo3>`_
VNC Gateways (@acronym{VNC-GW}s) support the import/export of routing VNC Gateways (:abbr:`VNC-GW`s) support the import/export of routing
information between VNC and customer edge routers (@acronym{CE}s) information between VNC and customer edge routers (:abbr:`CE`s)
operating within a VN. Both IP/Layer 3 (L3) VNs, and IP with operating within a VN. Both IP/Layer 3 (L3) VNs, and IP with
Ethernet/Layer 2 (L2) VNs are supported. Ethernet/Layer 2 (L2) VNs are supported.
@ -41,7 +41,7 @@ The chapter also provides sample configurations for basic example scenarios.
Configuring VNC Configuring VNC
=============== ===============
Virtual Network Control (@acronym{VNC}) service configuration commands Virtual Network Control (:abbr:`VNC`) service configuration commands
appear in the `router bgp` section of the BGPD configuration file appear in the `router bgp` section of the BGPD configuration file
(:ref:`BGP_Configuration_Examples`). The commands are broken down into (:ref:`BGP_Configuration_Examples`). The commands are broken down into
the following areas: the following areas:
@ -60,7 +60,7 @@ registered NVEs and overrides default parameters.
`Redistribution` and `Export` control VNC-GW operation, i.e., `Redistribution` and `Export` control VNC-GW operation, i.e.,
the import/export of routing the import/export of routing
information between VNC and customer edge routers (@acronym{CE}s) information between VNC and customer edge routers (:abbr:`CE`s)
operating within a VN. operating within a VN.
.. _General_VNC_Configuration: .. _General_VNC_Configuration: