aboutsummaryrefslogtreecommitdiffstats
path: root/src/vnet/config.c
AgeCommit message (Collapse)AuthorFilesLines
2022-04-04vppinfra: make _vec_len() read-onlyDamjan Marion1-2/+2
Use of _vec_len() to set vector length breaks address sanitizer. Users should use vec_set_len(), vec_inc_len(), vec_dec_len () instead. Type: improvement Change-Id: I441ae948771eb21c23a61f3ff9163bdad74a2cb8 Signed-off-by: Damjan Marion <damarion@cisco.com>
2021-11-19fib: Don't use [midchain] adjacencies to change an interface's feature arcNeale Ranns1-0/+27
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
2020-11-05feature: reset interface feature arc on interface deletionBenoît Ganne1-0/+8
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>
2020-07-23feature: fix feature config data initialization overflowBenoît Ganne1-5/+10
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>
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>