aboutsummaryrefslogtreecommitdiffstats
path: root/src/vnet/adj/adj_midchain.h
AgeCommit message (Collapse)AuthorFilesLines
2022-08-17fib: support "midchain delegate" removalAlexander Chernavin1-0/+5
Type: improvement Currently, once an adjacency is stacked on a FIB entry via adj_midchain_delegate_stack(), "midchain delegate" is created for the adjacency and the FIB index is stored there. And all further calls to adj_midchain_delegate_stack() even passing another FIB index will cause the function to still use the stored one. In other words, there is currently no way to stack an adjacency on another FIB index if "midchain delegate" already exists for it. Being able to stack on another FIB index is needed for the wireguard plugin. As per the protocol, peers can roam between different external endpoints. When an authenticated packet is received and it was sent from a different endpoint than currently stored, the endpoint needs to be updated and all futher communication needs to happen with that endpoint. Thus, the corresponding to that peer adjacencies need to be stacked on the FIB entry that corresponds to the new endpoint. With this change, add adj_midchain_delegate_remove() that removes "midchain delegate". When stacking on another FIB entry is needed, existing "midchain delegate" can be removed and then, a new one created with a new FIB index via adj_midchain_delegate_stack(). Signed-off-by: Alexander Chernavin <achernavin@netgate.com> Change-Id: Ibc1c99b248a5ef8ef64867f39f494fab627a1741
2021-10-06docs: vnet comment nitfixesNathan Skrzypczak1-1/+1
Type: improvement Change-Id: Iac01d7830b53819ace8f199554be10ab89ecdb97 Signed-off-by: Nathan Skrzypczak <nathan.skrzypczak@gmail.com>
2020-05-04fib: midchain adjacency optimisationsNeale Ranns1-0/+23
Type: improvement - inline some common encap fixup functions into the midchain rewrite node so we don't incur the cost of the virtual function call - change the copy 'guess' from ethernet_header (which will never happen) to an ip4 header - add adj-midchain-tx to multiarch sources - don't run adj-midchain-tx as a feature, instead put this node as the adj's next and at the end of the feature arc. - cache the feature arc config index (to save the cache miss going to fetch it) - don't check if features are enabled when taking the arc (since we know they are) the last two changes will also benefit normal adjacencies taking the arc (i.e. for NAT, ACLs, etc) for IPSec: - don't run esp_encrypt as a feature, instead when required insert this node into the adj's next and into the end of the feature arc. this implies that encrypt is always 'the last feature' run, which is symmetric with decrypt always being the first. - esp_encrpyt for tunnels has adj-midchain-tx as next node Change-Id: Ida0af56a704302cf2d7797ded5f118a781e8acb7 Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-03-26ADJ: midchain delegate to performing stackingNeale Ranns1-0/+21
this can be used by e.g. tunnels so it doesn't need to be implemented for each tunnel type. Change-Id: I0790f89aa49f83421612b35108cce67693285999 Signed-off-by: Neale Ranns <nranns@cisco.com>
2018-12-07FIB recusrion loop checks traverse midchain adjacenciesNeale Ranns1-1/+33
if a tunnel's destination address is reachable through the tunnel (see example config belwo) then search for and detect a recursion loop and don't stack the adjacency. Otherwise this results in a nasty surprise. DBGvpp# loop cre DBGvpp# set int state loop0 up DBGvpp# set int ip addr loop0 10.0.0.1/24 DBGvpp# create gre tunnel src 10.0.0.1 dst 1.1.1.1 DBGvpp# set int state gre0 up DBGvpp# set int unnum gre0 use loop0 DBGvpp# ip route 1.1.1.1/32 via gre0 DBGvpp# sh ip fib 1.1.1.1 ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] locks:[src:plugin-hi:2, src:default-route:1, ] 1.1.1.1/32 fib:0 index:11 locks:4 <<< this is entry #11 src:CLI refs:1 entry-flags:attached, src-flags:added,contributing,active, path-list:[14] locks:2 flags:shared,looped, uPRF-list:12 len:1 itfs:[2, ] path:[14] pl-index:14 ip4 weight=1 pref=0 attached-nexthop: oper-flags:recursive-loop,resolved, cfg-flags:attached, 1.1.1.1 gre0 (p2p) [@0]: ipv4 via 0.0.0.0 gre0: mtu:9000 4500000000000000fe2fb0cc0a0000010101010100000800 stacked-on entry:11: <<<< and the midchain forwards via entry #11 [@2]: dpo-drop ip4 src:recursive-resolution refs:1 src-flags:added, cover:-1 forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:12 to:[0:0]] [0] [@6]: ipv4 via 0.0.0.0 gre0: mtu:9000 4500000000000000fe2fb0cc0a0000010101010100000800 stacked-on entry:11: [@2]: dpo-drop ip4 DBGvpp# sh adj 1 [@1] ipv4 via 0.0.0.0 gre0: mtu:9000 4500000000000000fe2fb0cc0a0000010101010100000800 stacked-on entry:11: [@2]: dpo-drop ip4 flags:midchain-ip-stack midchain-looped <<<<< this is a loop counts:[0:0] locks:4 delegates: children: {path:14} Change-Id: I39b82bd1ea439be4611c88b130d40289fa0c1b59 Signed-off-by: Neale Ranns <nranns@cisco.com>
2018-01-30Allow the provider of a midchain adjacency to pass context data that is ↵Neale Ranns1-3/+10
returned in the fixup function Change-Id: I458e6e03b03e27775df33a2fd302743126d6ac44 Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-04-03Adjacency layout change and move to vnet/adjNeale Ranns1-21/+1
Change-Id: I03195a86c69f84a301051c6b3ab64456bbf28645 Signed-off-by: Neale Ranns <nranns@cisco.com>
2016-12-28Reorganize source tree to use single autotools instanceDamjan Marion1-0/+102
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23 Signed-off-by: Damjan Marion <damarion@cisco.com>