Properly set type
path->fp_type = FIB_PATH_TYPE_SPECIAL
for paths with (path->fp_cfg_flags & FIB_PATH_CFG_FLAG_DROP)
Type: fix
Change-Id: Id61dbcda781d872b878e6a6410c05b840795ed46
Signed-off-by: Alexander Skorichenko <askorichenko@netgate.com>
(cherry picked from commit 4b08632748727486e7ebfdcf4d992743595bc500)
When a periodic BFD packet cannot be sent because the interface is
disabled, the allocated buffer needs to be freed. This currently will
occur for IPv4 sessions. However, buffers will leak for IPv6 sessions as
in this case, bfd_transport_control_frame() and bfd_transport_udp6()
will not indicate failure.
With this fix, stop always returning success in bfd_transport_udp6() and
start returning the actual return value.
Type: fix
Change-Id: I5fa4d9206e32cccae3053ef24966d80e2022fc81
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
(cherry picked from commit 1f4023d55d7a9c777465d24065e91fc076602fb0)
Type: fix
In esp_encrypt_inline(), an index and pointer to the last processed SA
are stored. If the next packet uses the same SA, we defer on updating
counters until a different SA is encountered.
The pointer was being retrieved, then the SA was checked to see if the
packet should be dropped due to no crypto/integ algs, then the index was
updated. If the check failed, we would skip further processing and now
the pointer refers to a different SA than the index. When you have a
batch of packets that are encrypted using an SA followed by a packet
which is dropped for no algs and then more packets to be encrypted using
the original SA, the packets that arrive after the one that was dropped
end up being processed using a pointer that refers to the wrong SA data.
This can result in a segv.
Update the current_sa_index at the same time that the sa0 pointer is
updated.
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
Change-Id: I65f1511a37475b4f737f5e1b51749c0a30e88806
(cherry picked from commit dac9e566cd16fc375fff14280b37cb5135584fc6)
The recent TX flows generation fix introduced "l3_hdr_offset" which
represents the offset of the IP header in the buffer's data. The problem
is that it is erroneously defined as a 16-bit unsigned integer. If the
calculated offset is negative, "l3_hdr_offset" will get a value close to
UINT16_MAX. And the code will search the IP header somewhere beyond the
buffer's data. For example, this will occur in the case when an ICMP
error is being sent in response to a received packet.
With this fix, make "l3_hdr_offset" a signed integer.
Type: fix
Change-Id: I6f1283c7ba02656d0f592519b5863e68348c5583
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
(cherry picked from commit bae6b6d1f2a2e6623257afab21e05da2d795323a)
Currently, when IPFIX records generation is enabled for an interface in
the TX direction, some rewritten traffic is being sent from that
interface, and the Ethernet header's location has changed due to
rewriting, generated TX flows will contain fields with wrong and zero
values. For example, that can be observed when traffic is rewritten from
a subinterface to a hardware interface (i.e. when tags are removed). A
TX flow generated in this case will have wrong L2 fields because of an
incorrectly located Ethernet header. And zero L3/L4 fields because the
Ethernet type will match neither IP4 nor IP6.
The same code is executed to generate flows for both input and output
features. And the same mechanism is applied to identify the Ethernet
header in the buffer's data. However, such general code usually works
with the buffer's data conditionally based on the direction. For most
input features, the buffer's current_data will likely point to the IP
header. For most output features, the buffer's current_data will likely
point to the Ethernet header.
With this fix:
- Keep relying on ethernet_buffer_get_header() to locate the Ethernet
header for input features. And start using vlib_buffer_get_current()
to locate the Ethernet header for output features. The function will
account for the Ethernet header's position change in the buffer's
data if there is rewriting.
- After fixing Ethernet header determination in the buffer's data,
L3/L4 fields will contain non-zero but still incorrect data. That is
because IP header determination needs to be fixed too. It currently
relies on the fact that the Ethernet header is always located at the
beginning of the buffer's data and that l2_hdr_sz can be used as an
IP header offset. However, this may not be the case after rewriting.
So start calculating the actual offset of the IP header in the
buffer's data.
- Add a unit test to cover the case.
Type: fix
Change-Id: Icf3f9e6518912d06dff0d5aa48e103b3dc94edb7
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
(cherry picked from commit 64d6463d2eac0c0fe434f3a7aa56fe4d85c046d9)
As a result of recent fixes, all currently stored flows of an interface
are deleted when the feature is being disabled for the interface. This
includes stopping the timer and freeing the flow entries for further
reuse. The problem is that meta information is not cleared in the flow
entries being deleted. For example, packet delta count will keep its
value. The next flow that gets one of these pool entries will already
have a non-zero packet count. So the counting of packets will start from
a non-zero value. And incorrect packet delta count will be exported for
that flow.
With this fix, clear meta information too when clearing interface state.
Also, update the corresponding test to cover this case.
Type: fix
Change-Id: I9a73b3958adfd1676e66b0ed50f1478920671cca
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
(cherry picked from commit dab1dfeea9fec04a9a90a82dc5d770fbff344540)
Currently, TCP flags of a flow entry don't get reset once the flow is
exported (unlike other meta information about a flow - packet delta
count and octet delta count). So TCP flags are accumulated as long as
the flow is active. When the flow expires, it is exported the last time,
and its pool entry is freed for further reuse. The next flow that gets
this pool entry will already have non-zero TCP flags. If it's a TCP
flow, the flags will keep being accumulated. This might look fine when
exported. If it's a non-TCP flow, that will definitely look erroneous.
With this fix, reset TCP flags once the flow is exported. Also, cover
the reuse case with tests.
Type: fix
Change-Id: I5f8560afffcfe107909117d3d063e8a69793437e
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
(cherry picked from commit 21922cec7339f48989f230248de36a98816c4b1b)
Type: improvement
If an interface address is added, the glean adjacency for it's covering
prefix is updated with that address. In the case of multiple addresses
within the same prefix being added, the most recently added one will end
up being used as the sender protocol address for ARP requests.
Similar behavior occurs when an interface address is deleted. The glean
adjacency is updated to some appropriate entry under it's covering
prefix. If there were multiple interface addresses configured, we may
update the address on the adjacency even though the address currently in
use is not the one being deleted.
Add a new value PROVIDES_GLEAN to fib_entry_src_flag_t. The flag
identifies whether a source interface entry is being used as the address
for the glean adjacency for the covering prefix.
Update logic so that the glean is only updated on adding an interface
address if there is not already a sibling entry in use which has the
flag set. Also, only update the glean on deleting an interface address
if the address being deleted has the flag set.
Also update unit test which validates expected behavior in the case
where multiple addresses within a prefix are configured on an interface.
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
Change-Id: I7d918b8dd703735b20ec76e0a60af6d7e571b766
(cherry picked from commit 9e5694b405e0200725a993f0c17d452fab508435)
Currently, when L2 and L4 recording is enabled on the L2 datapath, the
L2 template will contain L4 fields and L2 flows will be exported with
those fields always set to zero.
With this fix, when L4 recording is enabled, add L4 fields to templates
other than the L2 template (i.e. to the IP4, IP6, L2_IP4, and L2_IP6
templates). And export L2 flows without L4 fields. Also, cover that case
in the tests.
Type: fix
Change-Id: Id5ed8b99af5634fb9d5c6e695203344782fdac01
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
(cherry picked from commit 6b027cfdbcb750b8aa1b8ab9a3904c1b2dca6f15)
When IPFIX flow record generation is enabled on an interface and the
active timer is set, flows will be saved and then exported according to
the active and passive timers. If then disable the feature on the
interface, the flow entries currently saved will remain in the state
tables. They will gradually expire and be exported. The problem is that
the template for them has already been removed. And they will be sent
with zero template ID which will make them unreadable.
A similar problem will occur if feature settings are "changed" on the
interface - i.e. disable the feature and re-enable it with different
settings (e.g. set a different datapath). The remaining flows that
correspond to the previous feature settings will be eventually sent
either with zero template ID or with template ID that corresponds to the
current feature settings on the interface (and look like garbage data).
With this fix, flush the current buffers before template removal and
clear the remaining flows of the interface during feature disabling.
Type: fix
Change-Id: I1e57db06adfdd3a02fed1a6a89b5418f85a35e16
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
(cherry picked from commit f68afe85a6e4d5e00fdad1af19a76eb40fdfa388)
When MAC address changes for an interface, address change callbacks are
executed for it. In turn adjacencies register a callback for MAC address
changes to be able to update their rewrite strings accordingly.
Subinterfaces inherit MAC address from the parent interface. When MAC
address of the parent interface changes, it also implies MAC address
change for its subinterfaces. The problem is that this is currently not
considered when address change callbacks are executed. After MAC address
change on the parent interface, packets sent from subinterfaces might
have wrong source MAC address as the result of stale adjacencies. For
example, ARP messages might be sent with the wrong (previous) MAC
address and address resolution will fail.
With this fix, when address change callbacks are executed for an
interface, they will be also executed for its subinterfaces. And
adjacencies will be able to update accordingly.
Type: fix
Change-Id: I87349698c10b9c3a31a28c0287e6dc711d9413a2
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
(cherry picked from commit 8a92b68bc8eaaec48d144fba62490a32f28eb422)
Currently, L2 flows are exported using L2_IP6 template if L3 or L4
recording is enabled on L2 datapath. That occurs because during feature
enable, L2 template is added and its ID is not saved immediately. Then
L2_IP4 and L2_IP6 templates are added overwriting "template_id" each
time. And in the end, the current value of "template_id" is saved for L2
template. The problem is that "template_id" at that point contains the
ID of L2_IP6 template.
With this fix, save the template ID immediately after adding a template
for all variants (datapaths). Also, cover the case with a test.
Type: fix
Change-Id: Id27288043b3b8f0e89e77f45ae9a01fa7439e20e
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
(cherry picked from commit 120095d3d33bfac64c1f3c870f8a332eeaf638f0)
memif_disconect may be called without barrier sync. It removes stuff in mq
without protection which may cause troubles for memif RX/TX worker threads.
The fix is to protect mq removal in memif_disconnect.
Type: fix
Change-Id: I368c466d1f13df98980dfa87e8442fbcd822a428
Signed-off-by: Steven Luong <sluong@cisco.com>
(cherry picked from commit 34c721fb47155135bf2173ca7b9a31aaacfde190)
Be less aggressive with rx events on connect/accept notification.
Type: fix
Signed-off-by: Florin Coras <fcoras@cisco.com>
Change-Id: Ie93a08c7eef69383bf0301a163fd2131dd51372a
(cherry picked from commit 054aa8c2f2681e3a4a4af02d9119fb6eaa5dbad6)
s->tx_fifo is 0 for the connecting half open session.
Type: fix
Change-Id: I2ba1ae99a2fa4fae1896587f40e0e4fb73c1edcb
Signed-off-by: Steven Luong <sluong@cisco.com>
(cherry picked from commit 947aa8fffcd85563ed0bad620f739e76c6002f50)
This patch provides minor improvements to the logic governing dequeuing
from the ring. Previously whenever a frame was dequeued
we've been trying to dequeue from the ring another one till
inflight == 0. Now threshold is set for 8 frames pending in the cache
to be consumed by the vnet. This threshold has been chosen based on
cache ring stats observation in the system under load.
Some unnecessary logic for setting deq_tail has been removed.
Also logging has been corrected, and cache ring logic simplied.
Type: improvement
Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com>
Change-Id: I19f3daf5913006e9cb23e142a163f596e85f5bda
(cherry picked from commit 7cc17f6df9b3f4b45aaac16ba0aa098d6cd58794)
If builtin apps refuse connections, they should be cleaned up.
Type: fix
Signed-off-by: Florin Coras <fcoras@cisco.com>
Change-Id: I95ef22902ac3fe873e15e250aa5f03031c2dc0c4
(cherry picked from commit 9ffec14a2202e1268c4a2f189c39a90986090a25)
pretty=on|off has been removed from qemu and its presence
causes VM boot up issues.
Type: fix
Change-Id: I4a9f15dba5015e81fbd32278b1c74b2606c32c8f
Signed-off-by: Naveen Joy <najoy@cisco.com>
If the control agent enabled a binding on an interface multiple times,
we would add the node in the feature arc multiple times.
Type: fix
Change-Id: I2ca247db0a0211f5fa3974a18ca4fcae8485cb12
Signed-off-by: Ole Troan <otroan@employees.org>
For blocking sessions, if fifo event still active before size check it
could lead to vpp not generating an event because of race to check flag
in vpp and to eventually unset flag in vcl.
Type: fix
Signed-off-by: Florin Coras <fcoras@cisco.com>
Change-Id: I0e350b9ff92a4e08a9249345ae224589c09d305b
This patch fixes configuration of priority, port and type of protocol
for inbound and outbound policies in policy-based IPsec of this plugin.
Type: fix
Signed-off-by: Gabriel Oginski <gabrielx.oginski@intel.com>
Change-Id: I01ddc2e13ebbe87380e66a525aac1b615f619604
Session state cannot be updated after async notification event is
generated for app. Instead, make sure quic sessions that accept new
streams are switched to listening state only on accept.
Type: fix
Fixes: 0242d30
Signed-off-by: Florin Coras <fcoras@cisco.com>
Change-Id: I9663ccadbea99d555ad49e871f7dff897239dc84
As per discussion on the VPP community call,
since the message is used in CSIT tests and did
not see the changes in a while, mark as production
for the purposes of change process.
Type: improvement
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
Change-Id: I4a79aafb1a9f37ac87faea7abea28cf01d1ffb4c
As discussed on the VPP call, since CSIT tests use these messages
and they have not been changedfor quite a while, bump the version
so these messages are considered as "production" from the change
process standpoint.
Type: improvement
Change-Id: I93a04b10b273d5904c0678fa0b85d47f9f683a9b
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
As per discussion on the VPP call - since the APIs are used
in CSIT tests, mark them as production from the change process
perspective.
Type: improvement
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
Change-Id: I9164073425384e8aa281445a2852fee49b777e2f
As per discussion on VPP call - since the APIs are used in CSIT tests,
and there has not been changes in a while, mark them as stable from
the API change process PoV.
Type: improvement
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
Change-Id: Ia644e1dfcd9d182cc6f10089fc44397a61e8aaf6
As per discussion on the VPP call: since the CSIT tests use these
APIs and the APIs have not changed in quite a while, stabilize the API
from the change process point of view.
Type: improvement
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
Change-Id: Id81999d03cce37764f6ed7d4f77ef5a71fe41ad1
