X-Git-Url: https://gerrit.fd.io/r/gitweb?a=blobdiff_plain;f=docs%2Fdeveloper%2Fcorefeatures%2Ffib%2Ffastconvergence.rst;fp=docs%2Fgettingstarted%2Fdevelopers%2Ffib20%2Ffastconvergence.rst;h=e1c5d0cc0955df85cbd0caa843ca00d4cfca71a5;hb=9ad39c026c8a3c945a7003c4aa4f5cb1d4c80160;hp=b07e08cea6d95c808170ec0d828e74f0c9df78d4;hpb=f47122e07e1ecd0151902a3cabe46c60a99bee8e;p=vpp.git diff --git a/docs/gettingstarted/developers/fib20/fastconvergence.rst b/docs/developer/corefeatures/fib/fastconvergence.rst similarity index 98% rename from docs/gettingstarted/developers/fib20/fastconvergence.rst rename to docs/developer/corefeatures/fib/fastconvergence.rst index b07e08cea6d..e1c5d0cc095 100644 --- a/docs/gettingstarted/developers/fib20/fastconvergence.rst +++ b/docs/developer/corefeatures/fib/fastconvergence.rst @@ -55,9 +55,9 @@ The FIB needs to hook into these notifications to trigger convergence. Whenever an interface goes down, VPP issues a callback to all -registerd clients. The adjacency code is such a client. The adjacency +registered clients. The adjacency code is such a client. The adjacency is a leaf node in the FIB control-plane graph (containing fib_path_t, -fib_entry_t etc). A back-walk from the adjacnecy will trigger a +fib_entry_t etc). A back-walk from the adjacency will trigger a re-resolution of the paths. FIB is a client of BFD in order to receive BFD notifications. BFD @@ -81,7 +81,7 @@ concrete representation of forwarding in a large network. Large networks are built in layers, it's how you scale them. We'll take here a hypothetical service provider (SP) network, but the concepts apply equally to data center leaf-spines. This is a rudimentary -description, but it should serve our purpose. +description, but it should serve our purpose. An SP manages a BGP autonomous system (AS). The SP's goal is both to attract traffic into its network to serve its customers, but also to @@ -207,7 +207,7 @@ in the FIB we see: [0] [@12]: dpo-load-balance: [proto:ip4 index:17 buckets:2 uRPF:22 to:[0:0]] [0] [@5]: ipv4 via 10.0.0.2 GigEthernet0/0/0: mtu:9000 next:3 001111111111dead000000000800 [1] [@5]: ipv4 via 10.0.1.2 GigEthernet0/0/1: mtu:9000 next:4 001111111111dead000000010800 - + the load-balance object used by this route is index 20, but note that the next load-balance in the chain is index 17, i.e. it is exactly the same instance that appears in the forwarding chain for the IGP @@ -225,12 +225,12 @@ the resulting update to the IGP route is: .. code-block:: console - DBGvpp# sh ip fib 1.1.1.1/32 + DBGvpp# sh ip fib 1.1.1.1/32 ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] epoch:0 flags:none locks:[adjacency:1, recursive-resolution:1, default-route:1, ] 1.1.1.1/32 fib:0 index:15 locks:4 API refs:1 src-flags:added,contributing,active, path-list:[23] locks:2 flags:shared, uPRF-list:25 len:2 itfs:[1, 2, ] - path:[27] pl-index:23 ip4 weight=1 pref=0 attached-nexthop: + path:[27] pl-index:23 ip4 weight=1 pref=0 attached-nexthop: 10.0.0.2 GigEthernet0/0/0 [@0]: arp-ipv4: via 10.0.0.2 GigEthernet0/0/0 path:[28] pl-index:23 ip4 weight=1 pref=0 attached-nexthop: oper-flags:resolved, @@ -374,7 +374,7 @@ In the FIB we see: .. code-block:: console - DBGvpp# sh ip fib 8.0.0.0/32 + DBGvpp# sh ip fib 8.0.0.0/32 ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] epoch:0 flags:none locks:[adjacency:1, recursive-resolution:2, default-route:1, ] 8.0.0.0/16 fib:0 index:18 locks:2 API refs:1 src-flags:added,contributing,active, @@ -426,7 +426,7 @@ and we see: .. code-block:: console - DBGvpp# sh ip fib 8.8.0.0 + DBGvpp# sh ip fib 8.8.0.0 ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] epoch:0 flags:none locks:[adjacency:1, recursive-resolution:4, default-route:1, ] 8.8.0.0/16 fib:0 index:77 locks:2 API refs:1 src-flags:added,contributing,active, @@ -527,7 +527,7 @@ branch of the graph that we don't want to traverse. Withdrawing the /32 triggers a synchronous walk of the children of the /32 route, we want a synchronous walk because we want to converge ASAP. This synchronous walk will encounter path-lists in the /32 route's child dependent list. -These path-lists (and thier LB maps) will be updated. If a path-list is +These path-lists (and their LB maps) will be updated. If a path-list is popular, then it will spawn a async walk of the path-list's child dependent routes, if not it will walk those routes. So the walk effectively proceeds breadth first across the path-lists, then returns @@ -541,7 +541,7 @@ Let's withdraw one of the IGP routes. DBGvpp# ip route del 1.1.1.2/32 via 10.0.1.2 GigEthernet0/0/1 - DBGvpp# sh ip fib 8.8.0.0 + DBGvpp# sh ip fib 8.8.0.0 ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] epoch:0 flags:none locks:[adjacency:1, recursive-resolution:4, default-route:1, ] 8.8.0.0/16 fib:0 index:77 locks:2 API refs:1 src-flags:added,contributing,active,