aboutsummaryrefslogtreecommitdiffstats
path: root/src/vnet/adj/adj_midchain_delegate.c
AgeCommit message (Collapse)AuthorFilesLines
2023-02-02fib: keep AddressSanitizer happyBenoît Ganne1-3/+2
adj_delegate_remove() makes 'ad' invalid, invalidate it only after its use. Type: fix Change-Id: I6908d3dd2962ebd3fdf37e946cb19dae727bda09 Signed-off-by: Benoît Ganne <bganne@cisco.com>
2022-08-17fib: support "midchain delegate" removalAlexander Chernavin1-0/+26
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
2019-07-19fib: FIB Entry trackingNeale Ranns1-9/+7
Instead of all clients directly RR sourcing the entry they are tracking, use a deidcated 'tracker' object. This tracker object is a entry delegate and a child of the entry. The clients are then children of the tracker. The benefit of this aproach is that each time a new client tracks the entry it doesn't RR source it. When an entry is sourced all its children are updated. Thus, new clients tracking an entry is O(n^2). With the tracker as indirection, the entry is sourced only once. Type: feature Change-Id: I5b80bdda6c02057152e5f721e580e786cd840a3b Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-03-26ADJ: midchain delegate to performing stackingNeale Ranns1-0/+183
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>