| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
Copy only exactly the data provided by the user even when it is not a
4-bytes multiple.
Type: fix
Change-Id: I2ef987c37e58523a38b46b09227529db2c26aa55
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
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>
|
|
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab
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>
|
|
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
Benoît Ganne
Neale Ranns
Dave Barach
Matthew Smith
Damjan Marion