Age | Commit message (Collapse) | Author | Files | Lines |
|
Type: fix
Presently a local label associated with an attached or connected prefix will link to the glean. This is a problem since it will never use the adj-fibs that are installed for that attached prefix. Instead link the local label to a lookup in the table in which the attached link is bound.
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: Iad49fb6168b9ba47216a9a52bd262363b49c3c43
|
|
Type: fix
IPv6 link-local FIB entries are never needed for attached export.
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: I08aad78e754d89ad54d07a211fb7a0d7fbc7a0fe
|
|
Type: fix
re-evaluate the import/export state of a prefix when the interface it is attached to rebinds to a different table.
Only attached routes have import/export requirements, so we can back walk from the glean adjacency when the interface rebinds tables.
There are two cases to consider.
1. the rebind may change the prefix from/to import
2. the import VRF may change
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: I25b6af43b3b2d8f701dfbe7a08710dc56b3f5778
|
|
correctly.
Type: fix
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: I4bc2eb394a8f9d01c5a12de2ce963c22209d5439
|
|
When adding a route via a udp encap instance, FIB_ENTRY_FLAG_IMPORT
should not be set. In particular, fib_route_attached_cross_table should
always return false for such paths.
Modified test_udp_encap to leverage the bug that needed to be fixed.
Type: fix
Signed-off-by: Arthur de Kerhor <arthurdekerhor@gmail.com>
Change-Id: Iaa9489e96d1cff09751f92c62caf7999d924fd7f
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: I53ab8d17914e6563110354e4052109ac02bf8f3b
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.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: 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>
|
|
Change-Id: Ie473dca3264b480b007d2eb500aaa557b889c7c1
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
|
|
- support both pipe and uniform modes for all MPLS LSP
- all API programming for output-labels requires that the mode (and associated data) is specificed
- API changes in MPLS, BIER and IP are involved
- new DPO [sub] types for MPLS labels to handle the two modes.
Change-Id: I87b76401e996f10dfbdbe4552ff6b19af958783c
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
- IPv6 link local table is a per-SW interface array of IPv6 unicast FIBs
- the per-interface ocst is sizeof(fib_table_t) which is small,
w.r.t. the cost of an interface
- FE80::/10 in the 'global' table points to a DPO that performs a lookup in the
input interface's LL fib.
Change-Id: Ice834b25ebeeacb2e929d7c864d7ec8c09918cbe
Signed-off-by: Neale Ranns <neale.ranns@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>
|
|
Change-Id: Ie8f6bb4fcd3e4fa269e86a77d2f21c87f372b783
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
as decsribed in section 2.2
ihttps://tools.ietf.org/html/draft-ietf-bier-mpls-encapsulation-10
with BIFT encoding from:
https://tools.ietf.org/html/draft-wijnandsxu-bier-non-mpls-bift-encoding-00
changes:
1 - introduce the new BIFT lookup table. BIER tables that have an associated
MPLS label are added to the MPLS-FIB. Those that don't are added to the
BIER table
2 - BIER routes that have no associated output MPLS label will add a BIFT label.
3 - The BIER FMask has a path-list as a member to resolve via any possible path.
Change-Id: I1fd4d9dbd074f0e855c16e9329b81460ebe1efce
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>
|
|
Change-Id: I8c42e26152f2ed1246f91b789887bfc923418bdf
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>
|
|
[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>
|
|
Paths are given a preference, lowest value is 'best'. Only paths that are up are up contribute to fprwarding - that's unchanged. What's new is that of the path's that re up only those that have the best preference contribute. A poor man's primary and backup. It's not true primary/backup function because the FIB must converge before the lower preference paths are used.
Change-Id: Ie4453c4a7b1094c6c2b51fe1594b8302103bb68e
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: If088e75801831befc6bddb77ea20abe9288b93c4
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
- only build them for popular path-lists (where popular means more than 64 children)
the reason to have a map is to improve convergence speed for recursive prefixes - if there are only a few this technique is not needed
- only build them when there is at least one path that has recursive constraints, i.e. a path that can 'fail' in a PIC scenario.
- Use the MAPS in the switch path.
- PIC test cases for functionality (not convergence performance)
Change-Id: I70705444c8469d22b07ae34be82cfb6a01358e10
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>
|
|
allow this config to function:
set int ip address loop0 169.254.1.1/32 (the default GW address for attached hosts)
set int unnumbered af_packet0 use loop0 ('enable' IP on the host interface)
ip route add 192.168.1.1/32 via af_packet0 (where to find the host)
repeat for each host and host interface.
Inter-host communication is throught the /32 routes.
To allow this:
1 - attached host routes have the ATTACHED flag set, so the ARP code accepts then as legitimate sources
2 - unnumbered interfaces inherit the source address from the IP interface
Change-Id: Ib66c5f0e848c528f79372813adc3a0c11b50717f
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I6d2afda991d771fb4a89fc3f6544f8e940a9b9f0
Signed-off-by: Shwetha Bhandari <shwethab@cisco.com>
|
|
the path-extension vector
Change-Id: I8bd8f6917ace089edb1f65bd017b478ee198c03f
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I97fedb0f70dd18ed9bbe985407cc5fe714e8a2e2
Signed-off-by: Florin Coras <fcoras@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>
|
|
1) vec_free the fe_srcs of a fib_entry_t when the fib_entry_t is itself reed
2) in the load-balance fixup if a drop path is required add this to a new vector of next-hops 'fixed_nhs'. This vector is managed by the load-balance function. The caller continues to manage its own set. The function is now const implying that the caller is safe to assume the next-hops do not change.
Change-Id: I0f29203ee16b9a270f40edf237488fa99ba65320
Signed-off-by: Neale Ranns <nranns@cisco.com>
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
|
|
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23
Signed-off-by: Damjan Marion <damarion@cisco.com>
|