Age | Commit message (Collapse) | Author | Files | Lines |
|
Type: fix
Using the adjacency to modify the interface's feature arc doesn't work, since there are potentially more than one adj per-interface.
Instead have the interface, when it is created, register what the end node of the feature arc is. This end node is then also used as the interface's tx node (i.e. it is used as the adjacency's next-node).
rename adj-midhcain-tx as 'tunnel-output', that's a bit more intuitive.
There's also a fix in config string handling to:
1- prevent false sharing of strings when the end node of the arc is different.
2- call registered listeners when the end node is changed
For IPSec the consequences are that one cannot provide per-adjacency behaviour using different end-nodes - this was previously done for the no-SA and an SA with no protection. These cases are no handled in the esp-encrypt node.
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: If3a83d03a3000f28820d9a9cb4101d244803d084
|
|
When removing an interface we must reset all per-interface per-feature
arc data to ensure we do not get wrong feature arc config data when the
sw_if_index is recycled.
Type: fix
Change-Id: I8c9d850d7c62b7b77193da4258ab5fb9bdda85a6
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
A predicate function which says whether a given sw_if_index has a
certain feature enabled.
int vnet_feature_is_enabled (const char *arc_name,
const char *feature_node_name,
u32 sw_if_index)
returns 1 if the feature is enabled
returns 0 if the feature is not enabled
returns VNET_API_ERROR_INVALID_VALUE if the arc name is not found
returns VNET_API_ERROR_INVALID_VALUE_2 if the feature node name is not found
returns VNET_API_ERROR_INVALID_SW_IF_INDEX if the sw_if_index is not found
Type: improvement
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: Id9ed53e2ae9252efc750ae80fd610456b95cefa4
|
|
Type: fix
it is possible for a user to change the end node of a feature arc, but
this change should only apply to that 'instnace' of the arc, not all
arcs. for example, if a tunnel has its ipx-output end node changed to
adj-midchain-tx, this shouldn't affect all ipx-output arcs. obviously...
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: I41daea7ba6907963e42140307d065c8bcfdcb585
|
|
Type: improvement
- inline some common encap fixup functions into the midchain
rewrite node so we don't incur the cost of the virtual function call
- change the copy 'guess' from ethernet_header (which will never happen) to an ip4 header
- add adj-midchain-tx to multiarch sources
- don't run adj-midchain-tx as a feature, instead put this node as the
adj's next and at the end of the feature arc.
- cache the feature arc config index (to save the cache miss going to fetch it)
- don't check if features are enabled when taking the arc (since we know they are)
the last two changes will also benefit normal adjacencies taking the arc (i.e. for NAT, ACLs, etc)
for IPSec:
- don't run esp_encrypt as a feature, instead when required insert this
node into the adj's next and into the end of the feature arc. this
implies that encrypt is always 'the last feature' run, which is
symmetric with decrypt always being the first.
- esp_encrpyt for tunnels has adj-midchain-tx as next node
Change-Id: Ida0af56a704302cf2d7797ded5f118a781e8acb7
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
DBGvpp# set interface feature local0 arp-foo arc bad-arc
set interface feature: Unknown arc name (bad-arc)...
DBGvpp# set interface feature local0 arp-foo arc arp
set interface feature: Feature (arp-foo) not registered to arc (arp)...
See 'show features verbose' for valid feature/arc combinations.
DBGvpp# set interface feature local0 arp-disabled arc arp
Type: fix
Change-Id: I036bb2a75dd2d40f6901e4fde3eb14925238e19b
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
|
|
Type: fix
Change-Id: Idf694477c18852e5541c28a493a56b302122e46c
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
|
|
Type: refactor
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: I1d8b88fe1eefc850865297b4f025b97e6373a6bd
|
|
If an arc declaration includes '.last_in_arc = "some-node"', assume
that folks mean it and add explicit ordering constraints.
Fix the "arp" arc declaration which claimed that the arc ends at
arp-disabled, but the arc really ends at error-drop.
Type: fix
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: Ie2de1fb30091671cbc7c62770903a2e05987f141
|
|
Change-Id: I53ab8d17914e6563110354e4052109ac02bf8f3b
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
|
|
Verify that last node in the computed feature order matches
reality. This check doesn't make sense in all cases, so we skip it if
the newly-added vnet_feature_arc_registration_t ".last_in_arc" datum
is a NULL pointer.
Change-Id: Ia99c3e2b2da2e4780a7d5bc71670c5742a66fef2
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Add the VNET_FEATURE_ARC_ORDER macro, which allows specification of
bulk order constraints. Here's an example:
VNET_FEATURE_ARC_ORDER(ip4_unicast_arc_order, static) = {
.arc_name = "ip4-unicast",
.node_names = VNET_FEATURES ("ip4-flow-classify",
"ip4-inacl",
"ip4-source-check-via-rx",
"ip4-source-check-via-any",
"ip4-source-and-port-range-check-rx",
"ip4-policer-classify",
"ipsec4-input",
"vpath-input-ip4",
"ip4-vxlan-bypass",
"ip4-not-enabled",
"ip4-lookup"),
};
Simply list feature nodes in the desired order, and you're
done. Multiple macro instances per are are fine / expected /
tested.
Under the covers: generate "a before b" tuples by chain-dragging
across the ordered list. No need to touch existing per-feature
constraints.
Fixed a long-broken "you lose!" error message.
Change-Id: I259282e426fd305e22c8d65886787c41a1d348d3
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: Ib2221a43347c66940b6b5f71914a451ca4627d2f
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
|
|
the ip4-dhcp-client-detect feature MUST run prior to nat44-out2in, or
inbound dhcp broadcast packets will be dropped. Certain dhcp servers
answer lease renewal dhcp-request packets with broadcast dhcp-acks, leading
to unrecoverable lease loss.
In detail, this constraint:
VNET_FEATURE_INIT (ip4_snat_out2in, static) = {
.arc_name = "ip4-unicast",
.node_name = "nat44-out2in",
.runs_after = VNET_FEATURES ("acl-plugin-in-ip4-fa"),
};
doesn't get the job done:
ip4-unicast:
[17] nat44-out2in
[23] ip4-dhcp-client-detect
[26] ip4-not-enabled
Add a proper constraint:
VNET_FEATURE_INIT (ip4_snat_out2in, static) = {
.arc_name = "ip4-unicast",
.node_name = "nat44-out2in",
.runs_after = VNET_FEATURES ("acl-plugin-in-ip4-fa",
"ip4-dhcp-client-detect"),
};
and the interface feature order is OK, at least in this regard:
ip4-unicast:
[17] ip4-dhcp-client-detect
[18] nat44-out2in
[26] ip4-not-enabled
We need to carefully audit (especially) the ip4-unicast feature arc,
which has [gasp] 37 features on it!
Change-Id: I5e749ead7ab2a25d80839a331de6261e112977ad
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
vnet_feature_enable_disable_with_index() checks the
return status of vnet_config_{add,del}_feature().
If the config string heap index returned is the same
index that was in use prior to the add/delete, it is
concluded that a failure occurred and processing of
the feature stops.
Sometimes the config index that is returned
can legitimately be the same index that was in used
before the add/delete. The old list of features can
have its heap entry deallocated before a new entry for
the new list is allocated. The heap entry for the new
list can be the entry that was deallocated while
deleting the old one.
Make vnet_config_{add,del}_feature() return ~0 on
failure. Look for that return value as an indication
that an error occurred in
vnet_enable_disable_feature_by_index().
Change-Id: I88bb3ff88a76971c1b5e5ece74784ce8ba78373c
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
|
|
We need to keep original linked list so destructire can remove entries.
Change-Id: I5ff5ca0e1a417d88707255207725bba46433c943
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
This change fixes a bug which would corrupt features infra by making
feature infra resistant to double-removal. It also fixes 'out of memory'
issue by properly initializing the bihash tables.
Change-Id: I78ac03139234a9a0e0b48e7bdfac1c38a0069e82
Signed-off-by: Klement Sekera <ksekera@cisco.com>
|
|
ip4-local feature arc existed but not ip6-local one.
This patch also adds node name to the 'show ip local' command and fixes
a minor include issue in vnet/ip/ip4.h file.
Change-Id: I9bb8a7159917d58f89afcce974680de20d946a70
Signed-off-by: Pierre Pfister <ppfister@cisco.com>
|
|
Change-Id: Ifa11f356d727b69cb121a2bf4cfb9d87883f545d
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
Drop comes before lookup when enabled. is_first_or_last is not required when setting a feature, the anchor is added in find_config_with_features().
Don't make the PG interfaces automatically L3 enabled, this way we can have tests that check the L3 protocol disbaled behaviour.
Change-Id: Icef22a920b27ff9cec6ab2da6b05f05c532cb60f
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
node_index memeber from the rewrite for space - this is only used for formtting
before:
ip4-rewrite * * * * 2.66e1 256.00
after:
ip4-rewrite * * * * 2.40e1 256.00
Change-Id: Ic397150727cad38811564777419ad6bd26b8a3a6
Signed-off-by: Neale Ranns <nranns@wasa-ucs-11.cisco.com>
|
|
After VPP-635 was merged, did one more pass. While the code was waiting
to be merged, a few changes were merged to master with the same issue.
This is a few additional changes addressing the same issue. See VPP-635.
Change-Id: I7abeac5c260c1e2e9d9d318fd1aae24cd6932efc
Signed-off-by: Billy McFall <bmcfall@redhat.com>
|
|
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23
Signed-off-by: Damjan Marion <damarion@cisco.com>
|