summaryrefslogtreecommitdiffstats
path: root/docs/gettingstarted/developers/fib20/routes.rst
diff options
context:
space:
mode:
authorPaul Vinciguerra <pvinci@vinciconsulting.com>2019-10-27 17:28:10 -0400
committerDave Barach <openvpp@barachs.net>2019-10-28 13:51:13 +0000
commit7fa3dd2881be537ec6144850064ad1419dc12f3e (patch)
tree7fa013d6e23f16f73b0ca97628c1374a009b49bd /docs/gettingstarted/developers/fib20/routes.rst
parent3b5e222f8a4d0ccd4ec4eace2551491f13de85d9 (diff)
docs: cleanup typos on readthrough
Type: style Change-Id: I3b15035ea6c13cd1ca3cdc9dfa9b10a6e1be9880 Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
Diffstat (limited to 'docs/gettingstarted/developers/fib20/routes.rst')
-rw-r--r--docs/gettingstarted/developers/fib20/routes.rst18
1 files changed, 9 insertions, 9 deletions
diff --git a/docs/gettingstarted/developers/fib20/routes.rst b/docs/gettingstarted/developers/fib20/routes.rst
index 62fcc00bd78..464a24af5d3 100644
--- a/docs/gettingstarted/developers/fib20/routes.rst
+++ b/docs/gettingstarted/developers/fib20/routes.rst
@@ -10,19 +10,19 @@ the route is resolved as the graph is complete from *fib_entry_t* to *ip_adjacen
In some routing models a VRF will consist of a set of tables for IPv4 and IPv6, and
unicast and multicast. In VPP there is no such grouping. Each table is distinct from
-each other. A table is indentified by its numerical ID. The ID range is separate for
+each other. A table is identified by its numerical ID. The ID range is separate for
each address family.
A table is comprised of two route data-bases; forwarding and non-forwarding. The
forwarding data-base contains routes against which a packet will perform a longest
prefix match (LPM) in the data-plane. The non-forwarding DB contains all the routes
-with which VPP has been programmed Рsome of these routes may be unresolved for reasons
+with which VPP has been programmed some of these routes may be unresolved for reasons
that prevent their insertion into the forwarding DB
(see section: Adjacency source FIB entries).
The route data is decomposed into three parts; entry, path-list and paths;
-* The *fib_entry_t*, which contains the routeճ prefix, is representation of that prefix's entry in the FIB table.
+* The *fib_entry_t*, which contains the routes prefix, is representation of that prefix's entry in the FIB table.
* The *fib_path_t* is a description of where to send the packets destined to the route's prefix. There are several types of path.
* Attached next-hop: the path is described with an interface and a next-hop. The next-hop is in the same sub-net as the router's own address on that interface, hence the peer is considered to be *attached*
@@ -37,10 +37,10 @@ The route data is decomposed into three parts; entry, path-list and paths;
.. figure:: /_images/fib20fig2.png
-Figure 2: Route data model Рclass diagram
+Figure 2: Route data model class diagram
Figure 2 shows an example of a route with two attached-next-hop paths. Each of these
-paths will *resolve* by finding the adjacency that matches the pathճ attributes, which
+paths will *resolve* by finding the adjacency that matches the paths attributes, which
are the same as the key for the adjacency data-base [#f3]_. The *forwarding information (FI)*
is the set of adjacencies that are available for load-balancing the traffic in the
data-plane. A path *contributes* an adjacency to the route's forwarding information, the
@@ -68,10 +68,10 @@ forwarding information of multiple sources to be combined. Instead the FIB must
to use the forwarding information from only one source. This choice is based on a static
priority assignment [#f4]_. The FIB must maintain the information each source has added
so it can be restored should that source become the best source. VPP has two
-*control-plane* sources; the API and the CLI Рthe API has the higher priority.
+*control-plane* sources; the API and the CLI the API has the higher priority.
Each *source* data is represented by a *fib_entry_src_t* object of which a
*fib_entry_t* maintains a sorted vector.n A prefix is *connected* when it is
-applied to a routerճ interface.
+applied to a routers interface.
The following configuration:
@@ -84,7 +84,7 @@ attached, and 192.168.1.1/32 which is connected and local (a.k.a receive or for-
Both prefixes are *interface* sourced. The interface source has a high priority, so
the accidental or nefarious addition of identical prefixes does not prevent the
router from correctly forwarding. Packets matching a connected prefix will
-generate an ARP request for the packetճ destination address, this process is known
+generate an ARP request for the packets destination address, this process is known
as a *glean*.
An *attached* prefix also results in a glean, but the router does not have its own
@@ -147,7 +147,7 @@ So while the following configuration is accepted:
$ ip arp 192.168.1.2 GigabitEthernet0/8/0 dead.dead.dead
$ set interface ip table GigabitEthernet0/8/0 2
-it does not result in the desired behaviour, where the adj-fib and connecteds are
+it does not result in the desired behaviour, where the adj-fib and connected adjacencies are
moved to table 2.
Recursive Routes