Age | Commit message (Collapse) | Author | Files | Lines |
|
Type: feature
from the API doc, a table replace is:
"
The use-case is that, for some unspecified reason, the control plane
has a very different set of entries it wants in the table than VPP
currently has. The CP would thus like to 'replace' VPP's current table
only by specifying what the new set of entries shall be, i.e. it is not
going to delete anything that already eixts.
the CP delcartes the start of this procedure with this begin_replace
API Call, and when it has populated all the entries it wants, it calls
the below end_replace API. From this point on it is of coursce free
to add and delete entries as usual.
The underlying mechanism by which VPP implements this replace is
purposefully left unspecified.
"
In the FIB, the algorithm is implemented using mark and sweep.
Algorithm goes:
1) replace_begin: this marks all the entries in that table as 'stale'
2) download all the entries that should be in this table
- this clears the stale flag on those entries
3) signal the table converged: ip_table_replace_end
- this removes all entries that are still stale
this procedure can be used when an agent first connects to VPP,
as an alternative to dump and diff state reconciliation.
Change-Id: I168edec10cf7670866076b129ebfe6149ea8222e
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Type: fix
all other uses of the fib_entry_get_preifx in the code base don't pass
the prefix into recursive functions.
Change-Id: Ic1c56acd406a733b215ee2fd98b6bed58b490a4f
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Type: fix
Change-Id: Ib7ac53d1b59b641ccd3b1d733107d7f1ba174314
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
they can use the 'auto' adj for all traffic
Type: fix
Change-Id: Id2b9557683252a94badc8f9dfab5f7b2ae26f1ee
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Type: fix
Change-Id: I7ed9726d8c5ca26715a84b004a18fd7f93142486
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Type: fix
Change-Id: I1af0e4a9bc23a3b6b6d3a74df093801ab6cae1f8
Signed-off-by: Lijian Zhang <Lijian.Zhang@arm.com>
|
|
Type: refactor
Signed-off-by: Simon Zhang <yuwei1.zhang@intel.com>
Change-Id: I8674ff5f6f6336b256b7df8187afbb36ddef71fb
|
|
Type: fix
Ticket: 1729
The flags that are permanently set on a path-list should form part of
its key in the path-list DB. Otherwise, if shared, they will not behave
as expected.
Change-Id: I0aa7c7c5d270c97b08014e4a47ddbdcee2358706
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Type: fix
Ticket: 1728
Change-Id: I679c2b8c5b0f751c9476db3669ab3f6c26dcdd28
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Add the FIB_SOURCE_INVALID fib source type. This allows to spot
uninitialized fib source more easily (0 no longer means special) and we
can use it as placeholder when no source is present.
Use it to fix FIB_ENTRY_DBG() which was accessing the 1st source, even
when no sources were present.
Type: fix
Fixes: 710071bf0e
Change-Id: I980b6a6a07616d4a8d6f2db166a1dd335721c74d
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
Type: feature
Change-Id: Ib24547a7c4c73ceb5383d1ca8f14ec40e6a90f01
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
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>
|
|
Type: fix
Fixes: 097fa66b
Change-Id: I690e31433b64f11399c08b4a0318762916c2c2f0
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
When removing duplicates in urpf_itfs vector we search for the 1st next
different entry in the vector, but the loop test is in the wrong order:
(urpf->furpf_itfs[i] == urpf->furpf_itfs[j]
&& j < vec_len(urpf->furpf_itfs))
We must check for overflow before checking equality.
Type: fix
Fixes: 3ee44040c66cbe47ff292ac7fb0badccbe2afe6d
Change-Id: I63729aff12057d5abce6c24ec24339cd9cd79494
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
whole route
Type: fix
Fixes: 097fa66b
Change-Id: I017ab5797670eb278c27c6e306cd8cadaacddf9d
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Type: fix
Fixes: 59fa121f
Change-Id: I9eb4fe1612734e54932228527c37bf33b705dbdb
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Usually the adj cover refinement check which ensures that for any
adj sourced prefix its cover is connected, is satified by the presence
of the interface source. The interface source has a high priority
hence during the adj refinement check get_flags() which uses the best
source, usually returns the flags for the interface source. However,
in the presence of higher priority sources that interpose get_flags does
not return connected and the check fails.
With this change add a specific check for the interface source if the
best is not connected.
Type: feature
Change-Id: Iabc3e29fe7c447fc3ef313e40b00d48fab09fba4
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Enhance the route add/del APIs to take a set of paths rather than just one.
Most unicast routing protocols calcualte all the available paths in one
run of the algorithm so updating all the paths at once is beneficial for the client.
two knobs control the behaviour:
is_multipath - if set the the set of paths passed will be added to those
that already exist, otherwise the set will replace them.
is_add - add or remove the set
is_add=0, is_multipath=1 and an empty set, results in deleting the route.
It is also considerably faster to add multiple paths at once, than one at a time:
vat# ip_add_del_route 1.1.1.1/32 count 100000 multipath via 10.10.10.11
100000 routes in .572240 secs, 174751.80 routes/sec
vat# ip_add_del_route 1.1.1.1/32 count 100000 multipath via 10.10.10.12
100000 routes in .528383 secs, 189256.54 routes/sec
vat# ip_add_del_route 1.1.1.1/32 count 100000 multipath via 10.10.10.13
100000 routes in .757131 secs, 132077.52 routes/sec
vat# ip_add_del_route 1.1.1.1/32 count 100000 multipath via 10.10.10.14
100000 routes in .878317 secs, 113854.12 routes/sec
vat# ip_route_add_del 1.1.1.1/32 count 100000 multipath via 10.10.10.11 via 10.10.10.12 via 10.10.10.13 via 10.10.10.14
100000 routes in .900212 secs, 111084.93 routes/sec
Change-Id: I416b93f7684745099c1adb0b33edac58c9339c1a
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
Signed-off-by: Ole Troan <ot@cisco.com>
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
|
|
redirect
Change-Id: I2a3ba2a3d73ea8511e3a511855b041432328f0a8
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
- all packets input on interface X are load-balanced over the set of
paths provided.
Change-Id: Ic27cb88c4cd5d6d3462570632daff7a43d5a652d
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
and document scaling
Change-Id: I65d8999e65616d77e525963c770d91e9b0d5e593
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
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>
|
|
Change-Id: Ie9c2954eee90ca1a1fc1aa8280f93b2340b544c1
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I215e1e0208a073db80ec6f87695d734cf40fabe3
Signed-off-by: Jim Thompson <jim@netgate.com>
|
|
Change-Id: I53ab8d17914e6563110354e4052109ac02bf8f3b
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
|
|
Change-Id: I4e1cde754eb4d6406cd6cd51f37d89552bdb6a53
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
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>
|
|
Change-Id: I04dbfb914706b25fcc3bd6ee0d19cfdc810234ae
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Ib27952935393163eaabf005c69b1cbc2feca2b98
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
when adding a recursive path the table is locked
so that it can be removed when the last recursive path
is removed. however, not all RR source'd prefixs use
a recursive path. so flushing the table of all RR source'd
entries is not correct.
Change-Id: Id4010774011046e66ddc443ac83cb8e9245313dd
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I90762b59f94175f278380c95776471a30bc94d34
Signed-off-by: mu.duojiao <mu.duojiao@zte.com.cn>
|
|
since it can realloc when new ctx are added. If
not we can get some nasty memory corruption.
Change-Id: I617709c3013acbcb8aee07dc147894f0de896555
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
in the same maaner as with other tunnel tyeps we use
the FIB to cache and track the destination used to reach
the tunnel endpoint. Post encap we can then ship the packet
straight to this adjacency and thus elide the costly second
lookup.
- SA add and del function so they can be used both directly
from the API and for tunnels.
- API change for the SA dump to use the SA type
- ipsec_key_t type for convenience (copying, [un]formating)
- no matching tunnel counters in ipsec-if-input
Change-Id: I9d144a59667f7bf96442f4ca66bef5c1d3c7f1ea
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Adding "Mtrie mheap usage" in output of "show ip fib memory" command, for displaying the total Mtrie Mheap usage together with memery usage of each node and each table
Change-Id: I2bcc570924e44a2b406f69cfc2f2f8d5abb61a39
Signed-off-by: Lollita Liu <lollita.liu@ericsson.com>
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
- fixes in ip.api for dumping mroute path flags
Change-Id: I13b0cfb15d374250ed71bd4e13dda9b798c18204
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Ic112180e53a55993b06ba18102202d6ac5854def
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
this is the case when the ADJ fib is in the non-forwarding trie
Change-Id: I7bcda475b3b1e142d16363147dba3a1e2c5a07f9
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I28e8a99b980ad343a4209e673201791b91ceab4e
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I7a48890c075826fbd8c75436dfdc5ffff230a693
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
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>
|
|
Change-Id: I9d2f52e756363df011026773bfffa838a557313f
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I7531a64d7072d85514ca579827b6ea0e9cef6f08
Signed-off-by: Vijayabhaskar Katamreddy <vkatamre@cisco.com>
|
|
Change-Id: I77af4f3a7e826ea5c1a23ee8b348faefe9f2facc
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Ie7827b6a31968a355687d27325c0f30cab1bc890
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
|
|
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I9052202b8cbcf656e61d635253d515f0f3a8d145
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
keep the number of buckets in the load-balanced fixed. If a
path goes dwon fill its buckets with those from the next
available up path.
Change-Id: I15603ccb899fa9b77556b898c99136379cf32eae
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I3c84daf046dbad972b36e48fa2548bbe20c7b338
Signed-off-by: Vijayabhaskar Katamreddy <vkatamre@cisco.com>
|
|
match against a packet's source address to determine
the VRF for the subsequent destination address lookup.
Change-Id: I48ee0ef54dcb891f0ec7f879e4d3b925a0ed0081
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I798e4fb6470ae9e763f8de1c290ff0fc3c0b7f9e
Signed-off-by: Neale Ranns <nranns@cisco.com>
|