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
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
[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
.. 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,
.. 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,
.. 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,
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
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,
Code Review / vpp.git / blobdiff