aboutsummaryrefslogtreecommitdiffstats
path: root/src/vnet/lisp-gpe/lisp_gpe_adjacency.c
AgeCommit message (Collapse)AuthorFilesLines
2020-02-21ipsec: IPSec protection for multi-point tunnel interfacesNeale Ranns1-1/+1
Type: feature Signed-off-by: Neale Ranns <nranns@cisco.com> Change-Id: Iaba2ab11bfaa1c8db4023434e3043ac39500f938
2020-02-18misc: fix coverity warningsDave Barach1-1/+1
Type: fix Ticket: VPP-1837 Signed-off-by: Dave Barach <dave@barachs.net> Change-Id: I402b1b06db736b2a7a242ce70ffd409c7c0a4fc2
2019-12-03fib: constify the adjacency in the rewrite nodesNeale Ranns1-2/+4
Type: refactor Signed-off-by: Neale Ranns <nranns@cisco.com> Change-Id: I3aad20b35d89fc541fdf185096d71ca12b09a6e2
2019-11-12ip: IP address and prefix types (moved from LISP)Neale Ranns1-4/+4
Type: refactor Change-Id: I2c6b59013bfd21136a2955442c779685f951932b Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-05-16init / exit function orderingDave Barach1-1/+1
The vlib init function subsystem now supports a mix of procedural and formally-specified ordering constraints. We should eliminate procedural knowledge wherever possible. The following schemes are *roughly* equivalent: static clib_error_t *init_runs_first (vlib_main_t *vm) { clib_error_t *error; ... do some stuff... if ((error = vlib_call_init_function (init_runs_next))) return error; ... } VLIB_INIT_FUNCTION (init_runs_first); and static clib_error_t *init_runs_first (vlib_main_t *vm) { ... do some stuff... } VLIB_INIT_FUNCTION (init_runs_first) = { .runs_before = VLIB_INITS("init_runs_next"), }; The first form will [most likely] call "init_runs_next" on the spot. The second form means that "init_runs_first" runs before "init_runs_next," possibly much earlier in the sequence. Please DO NOT construct sets of init functions where A before B actually means A *right before* B. It's not necessary - simply combine A and B - and it leads to hugely annoying debugging exercises when trying to switch from ad-hoc procedural ordering constraints to formal ordering constraints. Change-Id: I5e4353503bf43b4acb11a45fb33c79a5ade8426c Signed-off-by: Dave Barach <dave@barachs.net>
2018-12-07FIB recusrion loop checks traverse midchain adjacenciesNeale Ranns1-44/+10
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-10-23c11 safe string handling supportDave Barach1-3/+3
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab Signed-off-by: Dave Barach <dave@barachs.net>
2018-01-30Allow the provider of a midchain adjacency to pass context data that is ↵Neale Ranns1-1/+3
returned in the fixup function Change-Id: I458e6e03b03e27775df33a2fd302743126d6ac44 Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-05-10completelly deprecate os_get_cpu_number, replace new occurencesDamjan Marion1-1/+1
Change-Id: I82c663bc0866c6c68ba354104b0bb059387f4b9d Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-04-13LISP: make statistics thread safeFilip Tehlar1-16/+4
Change-Id: I056dc6246f79d887d69ad459a6b8b3092a099baa Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2017-04-03Adjacency layout change and move to vnet/adjNeale Ranns1-2/+2
Change-Id: I03195a86c69f84a301051c6b3ab64456bbf28645 Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-03-21LISP statisticsFilip Tehlar1-0/+100
Change-Id: I399cac46d279e020ba33459ef759d9d29d3ac716 Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2017-03-01VPP-598: tcp stack initial commitDave Barach1-0/+2
Change-Id: I49e5ce0aae6e4ff634024387ceaf7dbc432a0351 Signed-off-by: Dave Barach <dave@barachs.net> Signed-off-by: Florin Coras <fcoras@cisco.com>
2017-02-21Rename LISP GPE API to GPEFilip Tehlar1-1/+1
Change-Id: I133c55bce46d40ffddabbbf8626cbd3d072522d4 Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2017-02-13Basic support for LISP-GPE encapsulated NSH packetsFlorin Coras1-3/+5
Change-Id: I97fedb0f70dd18ed9bbe985407cc5fe714e8a2e2 Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-12-28Reorganize source tree to use single autotools instanceDamjan Marion1-0/+542
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23 Signed-off-by: Damjan Marion <damarion@cisco.com>