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>
|
|
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>
|
|
- fixes in ip.api for dumping mroute path flags
Change-Id: I13b0cfb15d374250ed71bd4e13dda9b798c18204
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I5c1bc498f7299e175070eb288e40f8d037c9be3a
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I28e8a99b980ad343a4209e673201791b91ceab4e
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I8dc261e40b8398c5c8ab6bb69ecebbd0176055d9
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I9052202b8cbcf656e61d635253d515f0f3a8d145
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I798e4fb6470ae9e763f8de1c290ff0fc3c0b7f9e
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I5e679f2601e37688f2768620479dc2efb7d19ca3
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I46b4aeb6ec9ab6ee462f9c5074b5778d94bf8dc3
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Saves memory at no appreciable performance cost.
before:
DBGvpp# sh fib mem
FIB memory
Name Size in-use /allocated totals
Entry 80 7 / 150 560/12000
after:
DBGvpp# sh fib mem
FIB memory
Name Size in-use /allocated totals
Entry 72 7 / 7 504/504
Change-Id: Ic5d3920ceb57b54260dc9af2078c26484335fef1
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
- see draft-ietf-bier-mpls-encapsulation-10
- midpoint, head and tail functions
- supported payload protocols; IPv4 and IPv6 only.
Change-Id: I59d7363bb6fdfdce8e4016a68a9c8f5a5e5791cb
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
part 2;
- this adds the code to create an IP and MPLS table via the API.
- but the enforcement that the table must be created before it is used is still missing, this is so that CSIT can pass.
Change-Id: Id124d884ade6cb7da947225200e3bb193454c555
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
See issue VPP-964
Change-Id: I2aed5abdc02e47e7bb5b0ce78cb6589a1ce7302f
Signed-off-by: Marco Varlese <marco.varlese@suse.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: Ie5b88fd7187ed62218a2e4e0e493c33e3e9ecc2f
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
there are, intentionally, no validation checks in the ARP/ND code to prevent an ARP/ND entry from being installed for an address that is not local to the interface's sub-net. This is ok, since the adjacency/FIB code is designed to handle this case using the 'refinement' criteria - i.e. only installing a FIB entry for the address if the address 'refines' (i.e. is more specific than) the interface's sub-net.
However, the refinement criteria currently operates on the FIB entry's prefix (which is a /32, so on the address) and not on the next-hop in the path.
So, enter multiple ARP entries for the same address on different links, and this refinement criteria uses only the last added path, and so will remove the FIB entry should the ARP entries be added in the 'wrong' order.
This fix updates the refinement criteria to work on each path of the FIB entry. The entry is installed if one of the paths refines the covers and only paths refining the cover contribute forwarding.
Per-path refinement checks are stored in path-extensions. The patch is rather large as path-extension, which were previously used only for out-going MPLS labels, have been generalized.
Change-Id: I00be359148cb948c32c52109e832a70537a7920a
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I046d9402b79fdbc6a6663199ffff8e40a278fd51
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
1 - interface-DPO
Used in the Data-plane to change a packet's input interface
2 - MPLS multicast FIB entry
Same as a unicast entry but it links to a replicate not a load-balance DPO
3 - Multicast MPLS tunnel
Update MPLS tunnels to use a FIB path-list to describe the endpoint[s]. Use the path-list to generate the forwarding chain (DPOs) to link to .
4 - Resolve a path via a local label (of an mLDP LSP)
For IP multicast entries to use an LSP in the replication list, we need to decribe the 'resolve-via-label' where the label is that of a multicast LSP.
5 - MPLS disposition path sets RPF-ID
For a interface-less LSP (i.e. mLDP not RSVP-TE) at the tail of the LSP we still need to perform an RPF check. An MPLS disposition DPO performs the MPLS pop validation checks and sets the RPF-ID in the packet.
6 - RPF check with per-entry RPF-ID
An RPF-ID is used instead of a real interface SW if index in the case the IP traffic arrives from an LSP that does not have an associated interface.
Change-Id: Ib92e177be919147bafeb599729abf3d1abc2f4b3
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I063d85200d12b09545ae1c373c7fc69112ae3b34
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I0ccb337eb0ed50ccc64193533cd816f6e36e6db5
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Add IP[46] MFIB dump.
Change-Id: I4a2821f65e67a5416b291e4912c84f64989883b8
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I97fedb0f70dd18ed9bbe985407cc5fe714e8a2e2
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
Change-Id: Ie490b7fd5238cbad23f0199161cc14324fd9c554
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
1 - use the SR policy to construct the replicate DPO. Each bucket therein is a SR tunnel.
2 - install a special mfib entry that links via this replicate
3 - forwarding is now mfib-lookup -> replicate -> sr_rewrite (per-tunnel)
no need for a separate sr_replicate node.
4 - Stack the sr tunnel on the forwarding DPO of the first-hop FIB entry.
no need for a second lookup post SR encap.
5 - fix some path-list lock leaks in the MFIB entry.
Change-Id: I20de96ea4c4be4fae252625bde159d9c435c8315
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
- IPv[46] mfib tables with support for (*,G/m), (*,G) and (S,G) exact and longest prefix match
- Replication represented via a new replicate DPO.
- RPF configuration and data-plane checking
- data-plane signals sent to listening control planes.
The functions of multicast forwarding entries differ from their unicast conterparts, so we introduce a new mfib_table_t and mfib_entry_t objects. However, we re-use the fib_path_list to resolve and build the entry's output list. the fib_path_list provides the service to construct a replicate DPO for multicast.
'make tests' is added to with two new suites; TEST=mfib, this is invocation of the CLI command 'test mfib' which deals with many path add/remove, flag set/unset scenarios, TEST=ip-mcast, data-plane forwarding tests.
Updated applications to use the new MIFB functions;
- IPv6 NS/RA.
- DHCPv6
unit tests for these are undated accordingly.
Change-Id: I49ec37b01f1b170335a5697541c8fd30e6d3a961
Signed-off-by: Neale Ranns <nranns@cisco.com>
|