From: Quentin Young Date: Fri, 2 Feb 2018 18:33:41 +0000 (-0500) Subject: doc: add glossary X-Git-Tag: frr-5.0-dev~165^2~45 X-Git-Url: https://git.puffer.fish/?a=commitdiff_plain;h=623333072e3cd32e66debfeb970b67c94520e1c9;p=mirror%2Ffrr.git doc: add glossary Glossary of some common terms, fixes non-existing glossary definition warnings. Signed-off-by: Quentin Young --- diff --git a/doc/user/eigrpd.rst b/doc/user/eigrpd.rst index e063b9a464..309ee27cc4 100644 --- a/doc/user/eigrpd.rst +++ b/doc/user/eigrpd.rst @@ -4,9 +4,15 @@ EIGRP ***** +.. glossary:: + + DUAL + The *Diffusing Update ALgorithm*, a :term:`Bellman-Ford` based routing + algorithm used by EIGRP. + EIGRP -- Routing Information Protocol is widely deployed interior gateway routing protocol. EIGRP was developed in the 1990's. EIGRP is a -:term:`distance-vector` protocol and is based on the :term:`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 neighbors as networks change, thus allowing the convergence to a known topology. diff --git a/doc/user/glossary.rst b/doc/user/glossary.rst new file mode 100644 index 0000000000..af52857932 --- /dev/null +++ b/doc/user/glossary.rst @@ -0,0 +1,37 @@ +.. glossary:: + + distance-vector + A distance-vector routing protocol in data networks determines the best + route for data packets based on distance. Distance-vector routing + protocols measure the distance by the number of routers a packet has to + pass. Some distance-vector protocols also take into account network + latency and other factors that influence traffic on a given route. To + determine the best route across a network, routers on which a + distance-vector protocol is implemented exchange information with one + another, usually routing tables plus hop counts for destination networks + and possibly other traffic information. Distance-vector routing protocols + also require that a router informs its neighbours of network topology + changes periodically. [distance-vector-rp]_ + + link-state + Link-state algorithms (also known as shortest path first algorithms) + flood routing information to all nodes in the internetwork. Each router, + however, sends only the portion of the routing table that describes the + state of its own links. In link-state algorithms, each router builds a + picture of the entire network in its routing tables. Distance vector + algorithms (also known as Bellman-Ford algorithms) call for each router + to send all or some portion of its routing table, but only to its + neighbors. In essence, link-state algorithms send small updates + everywhere, while distance vector algorithms send larger updates only to + neighboring routers. Distance vector algorithms know only about their + neighbors. [link-state-rp]_ + + Bellman-Ford + The Bellman–Ford algorithm is an algorithm that computes shortest paths + from a single source vertex to all of the other vertices in a weighted + digraph. [bellman-ford]_ + + +.. [distance-vector-rp] https://en.wikipedia.org/wiki/Distance-vector_routing_protocol +.. [link-state-rp] https://en.wikipedia.org/wiki/Link-state_routing_protocol +.. [bellman-ford] https://en.wikipedia.org/wiki/Bellman-Ford_algorithm diff --git a/doc/user/index.rst b/doc/user/index.rst index 036c87c86e..54ee8b12f8 100644 --- a/doc/user/index.rst +++ b/doc/user/index.rst @@ -26,5 +26,6 @@ Welcome to FRR's documentation! ripd ripngd vnc + glossary appendix diff --git a/doc/user/ospf_fundamentals.rst b/doc/user/ospf_fundamentals.rst index 479b53a73c..b0c6f69f7b 100644 --- a/doc/user/ospf_fundamentals.rst +++ b/doc/user/ospf_fundamentals.rst @@ -6,26 +6,25 @@ OSPF Fundamentals .. index:: Link-state routing protocol .. index:: Distance-vector routing protocol -:abbr:`OSPF` is, mostly, a link-state routing protocol. In contrast -to :term:`distance-vector` protocols, such as :abbr:`RIP` or -:abbr:`BGP`, where routers describe available :term:`paths` (i.e. routes) -to each other, in :term:`link-state` protocols routers instead -describe the state of their links to their immediate neighbouring -routers. +:abbr:`OSPF` is, mostly, a link-state routing protocol. In contrast to +:term:`distance-vector` protocols, such as :abbr:`RIP` or :abbr:`BGP`, where +routers describe available `paths` (i.e. routes) to each other, in +:term:`link-state` protocols routers instead describe the state of their links +to their immediate neighbouring routers. .. index:: Link State Announcement .. index:: Link State Advertisement .. index:: LSA flooding .. index:: Link State Database -Each router describes their link-state information in a message known -as an :abbr:`LSA (Link State Advertisement)`, which is then propogated -through to all other routers in a link-state routing domain, by a -process called :term:`flooding`. Each router thus builds up an -:abbr:`LSDB (Link State Database)` of all the link-state messages. From -this collection of LSAs in the LSDB, each router can then calculate the -shortest path to any other router, based on some common metric, by using an -algorithm such as `Edgar Djikstra's `_ +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 +other routers in a link-state routing domain, by a process called `flooding`. +Each router thus builds up an :abbr:`LSDB (Link State Database)` of all the +link-state messages. From this collection of LSAs in the LSDB, each router can +then calculate the shortest path to any other router, based on some common +metric, by using an algorithm such as +`Edgar Djikstra's `_ :abbr:`SPF (Shortest Path First)` algorithm. .. index:: Link-state routing protocol advantages @@ -119,7 +118,7 @@ LSA Flooding OSPF defines several related mechanisms, used to manage synchronisation of :abbr:`LSDB` s between neighbours as neighbours form adjacencies and the -propogation, or :term:`flooding` of new or updated :abbr:`LSA` s. +propogation, or `flooding` of new or updated :abbr:`LSA` s. .. index:: OSPF Areas overview @@ -132,7 +131,7 @@ OSPF provides for the protocol to be broken up into multiple smaller and independent link-state areas. Each area must be connected to a common backbone area by an :abbr:`ABR (Area Boundary Router)`. These :abbr:`ABR` routers are responsible for summarising the link-state routing information of an area into -:term:`Summary LSAs`, possibly in a condensed (i.e. aggregated) form, and then +`Summary LSAs`, possibly in a condensed (i.e. aggregated) form, and then originating these summaries into all other areas the :abbr:`ABR` is connected to. @@ -196,13 +195,13 @@ All LSAs share a common header with the following information: from their :abbr:`LSDB` s. 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 `MaxAge`. MaxAge LSAs are ignored in routing calculations. LSAs must be periodically refreshed by their Advertising Router before reaching MaxAge if they are to remain valid. Routers may deliberately flood LSAs with the age artificially set to 3600 to indicate an LSA is no longer valid. This is called - :term:`flushing` of an LSA. + `flushing` of an LSA. 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 @@ -224,7 +223,7 @@ protocol. Instances of these LSAs are specific to the link-state area in which they are originated. Routes calculated from these two LSA types are -called :term:`intra-area routes`. +called `intra-area routes`. - Router LSA @@ -273,7 +272,7 @@ called :term:`intra-area routes`. is Full. Stub links may also be used as a way to describe links on which OSPF is - *not* spoken, known as :term:`passive interfaces`, see + *not* spoken, known as `passive interfaces`, see :clicmd:`passive-interface INTERFACE`. - Network LSA diff --git a/doc/user/ospfd.rst b/doc/user/ospfd.rst index 430b32af1c..771182024c 100644 --- a/doc/user/ospfd.rst +++ b/doc/user/ospfd.rst @@ -713,8 +713,8 @@ Redistribute routes to OSPF for NSSA areas and are not redistributed at all into Stub areas, where external routes are not permitted. - Note that for connected routes, one may instead use - :term:`passive-interface`; + Note that for connected routes, one may instead use the `passive-interface` + configuration. .. seealso:: @@ -760,9 +760,9 @@ Redistribute routes to OSPF .. _ospf-distribute-list: - Apply the access-list filter, NAME, to - redistributed routes of the given type before allowing the routes to - redistributed into OSPF (:ref:`OSPF redistribution `). + Apply the access-list filter, NAME, to + redistributed routes of the given type before allowing the routes to + redistributed into OSPF (:ref:`OSPF redistribution `). .. index:: default-metric (0-16777214) .. clicmd:: default-metric (0-16777214)