mirror of
https://git.proxmox.com/git/mirror_frr
synced 2025-08-06 16:20:08 +00:00
doc: use :term:, will add glossary later
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This commit is contained in:
parent
29adcd5008
commit
dfab2669d3
@ -6,7 +6,7 @@ EIGRP
|
|||||||
|
|
||||||
EIGRP -- Routing Information Protocol is widely deployed interior gateway
|
EIGRP -- Routing Information Protocol is widely deployed interior gateway
|
||||||
routing protocol. EIGRP was developed in the 1990's. EIGRP is a
|
routing protocol. EIGRP was developed in the 1990's. EIGRP is a
|
||||||
@dfn{distance-vector} protocol and is based on the @dfn{dual} algorithms.
|
:term:`distance-vector` protocol and is based on the :term:`dual` algorithms.
|
||||||
As a distance-vector protocol, the EIGRP router send updates to its
|
As a distance-vector protocol, the EIGRP router send updates to its
|
||||||
neighbors as networks change, thus allowing the convergence to a
|
neighbors as networks change, thus allowing the convergence to a
|
||||||
known topology.
|
known topology.
|
||||||
@ -33,7 +33,7 @@ EIGRP is like below:
|
|||||||
|
|
||||||
# zebra -d
|
# zebra -d
|
||||||
# eigrpd -d
|
# eigrpd -d
|
||||||
|
|
||||||
|
|
||||||
Please note that *zebra* must be invoked before *eigrpd*.
|
Please note that *zebra* must be invoked before *eigrpd*.
|
||||||
|
|
||||||
@ -100,7 +100,7 @@ EIGRP Configuration
|
|||||||
router eigrp 1
|
router eigrp 1
|
||||||
network 10.0.0.0/8
|
network 10.0.0.0/8
|
||||||
!
|
!
|
||||||
|
|
||||||
|
|
||||||
Passive interface
|
Passive interface
|
||||||
|
|
||||||
@ -114,7 +114,7 @@ EIGRP Configuration
|
|||||||
interface, all receiving packets are ignored and eigrpd does
|
interface, all receiving packets are ignored and eigrpd does
|
||||||
not send either multicast or unicast EIGRP packets except to EIGRP neighbors
|
not send either multicast or unicast EIGRP packets except to EIGRP neighbors
|
||||||
specified with `neighbor` command. The interface may be specified
|
specified with `neighbor` command. The interface may be specified
|
||||||
as `default` to make eigrpd default to passive on all interfaces.
|
as `default` to make eigrpd default to passive on all interfaces.
|
||||||
|
|
||||||
The default is to be passive on all interfaces.
|
The default is to be passive on all interfaces.
|
||||||
|
|
||||||
@ -218,9 +218,9 @@ The command displays all EIGRP routes.
|
|||||||
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply
|
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply
|
||||||
r - reply Status, s - sia Status
|
r - reply Status, s - sia Status
|
||||||
|
|
||||||
P 10.0.2.0/24, 1 successors, FD is 256256, serno: 0
|
P 10.0.2.0/24, 1 successors, FD is 256256, serno: 0
|
||||||
via Connected, enp0s3
|
via Connected, enp0s3
|
||||||
|
|
||||||
|
|
||||||
EIGRP Debug Commands
|
EIGRP Debug Commands
|
||||||
====================
|
====================
|
||||||
|
@ -8,9 +8,9 @@ OSPF Fundamentals
|
|||||||
.. index:: Distance-vector routing protocol
|
.. index:: Distance-vector routing protocol
|
||||||
|
|
||||||
@acronym{OSPF} is, mostly, a link-state routing protocol. In contrast
|
@acronym{OSPF} is, mostly, a link-state routing protocol. In contrast
|
||||||
to @dfn{distance-vector} protocols, such as @acronym{RIP} or
|
to :term:`distance-vector` protocols, such as @acronym{RIP} or
|
||||||
@acronym{BGP}, where routers describe available @dfn{paths} (i.e@. routes)
|
@acronym{BGP}, where routers describe available :term:`paths` (i.e@. routes)
|
||||||
to each other, in @dfn{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.
|
||||||
|
|
||||||
@ -25,7 +25,7 @@ routers.
|
|||||||
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 @acronym{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 @dfn{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
|
@acronym{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
|
||||||
@ -131,7 +131,7 @@ broadly classed as:
|
|||||||
*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
|
@acronym{LSDB}s between neighbours as neighbours form adjacencies and
|
||||||
the propogation, or @dfn{flooding} of new or updated @acronym{LSA}s.
|
the propogation, or :term:`flooding` of new or updated @acronym{LSA}s.
|
||||||
|
|
||||||
:ref:`OSPF_Flooding`.
|
:ref:`OSPF_Flooding`.
|
||||||
|
|
||||||
@ -143,13 +143,13 @@ broadly classed as:
|
|||||||
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 @acronym{ABR,Area Boundary Router}. These
|
||||||
@acronym{ABR} routers are responsible for summarising the link-state
|
@acronym{ABR} routers are responsible for summarising the link-state
|
||||||
routing information of an area into @dfn{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 @acronym{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,
|
||||||
routing between areas hence is by @dfn{distance-vector}, @strong{not}
|
routing between areas hence is by :term:`distance-vector`, @strong{not}
|
||||||
link-state.
|
link-state.
|
||||||
|
|
||||||
:ref:`OSPF_Areas`.
|
:ref:`OSPF_Areas`.
|
||||||
@ -208,13 +208,13 @@ All LSAs share a common header with the following information:
|
|||||||
from their @acronym{LSDB}s.
|
from their @acronym{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 @dfn{MaxAge}. MaxAge LSAs are ignored in routing
|
called the :term:`MaxAge`. MaxAge LSAs are ignored in routing
|
||||||
calculations. LSAs must be periodically refreshed by their Advertising
|
calculations. LSAs must be periodically refreshed by their Advertising
|
||||||
Router before reaching MaxAge if they are to remain valid.
|
Router before reaching MaxAge if they are to remain valid.
|
||||||
|
|
||||||
Routers may deliberately flood LSAs with the age artificially set to
|
Routers may deliberately flood LSAs with the age artificially set to
|
||||||
3600 to indicate an LSA is no longer valid. This is called
|
3600 to indicate an LSA is no longer valid. This is called
|
||||||
@dfn{flushing} of an LSA@.
|
:term:`flushing` of an LSA@.
|
||||||
|
|
||||||
It is not abnormal to see stale LSAs in the LSDB, this can occur where
|
It is not abnormal to see stale LSAs in the LSDB, this can occur where
|
||||||
a router has shutdown without flushing its LSA(s), e.g. where it has
|
a router has shutdown without flushing its LSA(s), e.g. where it has
|
||||||
@ -236,7 +236,7 @@ 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
|
||||||
they are originated. Routes calculated from these two LSA types are
|
they are originated. Routes calculated from these two LSA types are
|
||||||
called @dfn{intra-area routes}.
|
called :term:`intra-area routes`.
|
||||||
|
|
||||||
* Router LSA
|
* Router LSA
|
||||||
|
|
||||||
@ -296,7 +296,7 @@ called @dfn{intra-area routes}.
|
|||||||
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
|
||||||
*not* spoken, known as @dfn{passive interfaces}, see :ref:`OSPF_passive-interface,,passive-interface`.
|
*not* spoken, known as :term:`passive interfaces`, see :ref:`OSPF_passive-interface,,passive-interface`.
|
||||||
|
|
||||||
* Network LSA
|
* Network LSA
|
||||||
|
|
||||||
|
@ -738,7 +738,7 @@ Redistribute routes to OSPF
|
|||||||
external routes are not permitted.
|
external routes are not permitted.
|
||||||
|
|
||||||
Note that for connected routes, one may instead use
|
Note that for connected routes, one may instead use
|
||||||
@dfn{passive-interface}, see :ref:`OSPF_passive-interface`.
|
:term:`passive-interface`, see :ref:`OSPF_passive-interface`.
|
||||||
|
|
||||||
.. index:: {OSPF Command} {default-information originate} {}
|
.. index:: {OSPF Command} {default-information originate} {}
|
||||||
|
|
||||||
|
@ -6,8 +6,8 @@ RIP
|
|||||||
|
|
||||||
RIP -- Routing Information Protocol is widely deployed interior gateway
|
RIP -- Routing Information Protocol is widely deployed interior gateway
|
||||||
protocol. RIP was developed in the 1970s at Xerox Labs as part of the
|
protocol. RIP was developed in the 1970s at Xerox Labs as part of the
|
||||||
XNS routing protocol. RIP is a @dfn{distance-vector} protocol and is
|
XNS routing protocol. RIP is a :term:`distance-vector` protocol and is
|
||||||
based on the @dfn{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 broadcasted to its neighboring
|
||||||
|
Loading…
Reference in New Issue
Block a user