diff options
author | Neale Ranns <nranns@cisco.com> | 2019-11-08 12:42:31 +0000 |
---|---|---|
committer | Ole Trøan <otroan@employees.org> | 2019-11-26 09:15:11 +0000 |
commit | 9db6ada779794779158163f6293b479ae7f6ad5e (patch) | |
tree | 53dd65975958b2d87b1cd312e612b45d7225e531 /test/test_l2_flood.py | |
parent | 0d3d4824a46205e776ff32c82be4cb514f459a5f (diff) |
fib: Table Replace
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>
Diffstat (limited to 'test/test_l2_flood.py')
0 files changed, 0 insertions, 0 deletions