Age | Commit message (Collapse) | Author | Files | Lines |
|
Type: improvement
1) stack the interpose on any path-extensions (e.g. labels) from the
next best source
2) allow more than 1 source to contribute a DPO for a given prefix
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: Idc2fbb36cfbd2387081765d8af0f1fbe61612160
|
|
Type: feature
Use the FIB to provide SAS (in so far as it is today)
- Use the glean adjacency as the record of the connected prefixes
= there's a glean per-{interface, protocol, connected-prefix}
- Keep the glean up to date with whatever the recieve host prefix is
(since it can change)
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
Change-Id: I0f3dd1edb1f3fc965af1c7c586709028eb9cdeac
|
|
Type: fix
Change-Id: I6011f5d6eae79019d3c16a260a9bedf0a76d2151
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Type: feature
the fib_source_t enum alone no longer defines the priority and
behaviour, instead each source must be allocated these attributes.
This allows the creation of other sources by the plugins (and
soon over the API).
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: I890ee820fbc16079ee417ea1fbc163192806e853
|
|
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>
|
|
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>
|
|
Change-Id: I9052202b8cbcf656e61d635253d515f0f3a8d145
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
The interpose source allows the source/provider to insert/interpose
a DPO in the forwarding chain of the FIB entry ahead of the forwarding
provided by the next best source. For example if the API source (i.e
the 'control plane') has provided an adjacency for forwarding, then
an interpose source (e.g. a monitoring service) couold interpose a
replicatte DPO to copy the traffic to another location AND forward
using the API's adjacency.
To use the interose feature an existing source (i.e FIB_SOURCE_PLUGIN_HI)
cn specifiy as a flag FIB_ENTRY_FLAG_INTERPOSE and provide a DPO to
interpose. One might also consider using interpose in conjunction with
FIB_ENTRY_FLAG_COVER_INHERIT to ensure the interpose object affects
all prefixes in the sub-tree.
Change-Id: I8b2737b985f8f7c08123406d0491881def347b52
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
forwarding provided by the source is pushed to all other entries
it covers in the sub-tree
Change-Id: I2a45222ef653358f55c2436de3e3c6353cfadba2
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
This reverts commit 84517cfd1508f6da24937f310f7fffe752f22584.
Change-Id: Ic7eeffa2ed4607d3d653f34b93c20c833c789ee1
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Most FIB entries will only ever have one source providing forwarding
information. Currently the source infom is stored in a vector of sources
on the FIB entry. Change this to a union of one source inline and a vector.
This saves the need to alloc a vector of sources for each FIB entry.
before:
vpp# ip route add count 1500000 1.0.0.1/32 via 10.10.10.2 loop0
4.392857e5 routes/sec
vpp# ip route del count 1500000 1.0.0.1/32 via 10.10.10.2 loop0
9.175464e5 routes/sec
vpp# ip route add count 1500000 1.0.0.1/32 via 10.10.10.2 loop0
5.193375e5 routes/sec
vpp# sh fib mem
FIB memory
Name Size in-use /allocated totals
Entry 72 1500011/ 1500011 108000792/108000792
Entry Source 32 1500011/ 1500011 48000352/48000352
after:
vpp# ip route add count 1500000 1.0.0.1/32 via 10.10.10.2 loop0
4.726560e5 routes/sec
vpp# ip route del count 1500000 1.0.0.1/32 via 10.10.10.2 loop0
1.041629e6 routes/sec
vpp# ip route add count 1500000 1.0.0.1/32 via 10.10.10.2 loop0
5.702895e5 routes/sec
vpp# sh fib mem
FIB memory
Name Size in-use /allocated totals
Entry 96 1500011/ 1500011 144001056/144001056
Entry Source 32 0 / 0 0/0
Change-Id: Ic71e413eaff1ec152656beda3b94186f7894ea49
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
[support for VPWS/VPLS]
- switch to using dpo_proto_t rather than fib_protocol_t in fib_paths so that we can describe L2 paths
- VLIB nodes to handle pop/push of MPLS labels to L2
Change-Id: Id050d06a11fd2c9c1c81ce5a0654e6c5ae6afa6e
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23
Signed-off-by: Damjan Marion <damarion@cisco.com>
|