summaryrefslogtreecommitdiffstats
path: root/src/vnet/config.c
AgeCommit message (Collapse)AuthorFilesLines
2020-05-13feature: Config end nodes are user specificNeale Ranns1-11/+21
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
2020-05-04fib: midchain adjacency optimisationsNeale Ranns1-0/+56
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>
2018-10-23c11 safe string handling supportDave Barach1-1/+1
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab Signed-off-by: Dave Barach <dave@barachs.net>
2018-05-17Fix failure during enable/disable of featuresMatthew Smith1-2/+2
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>
2016-12-28Reorganize source tree to use single autotools instanceDamjan Marion1-0/+361
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23 Signed-off-by: Damjan Marion <damarion@cisco.com>