Age | Commit message (Collapse) | Author | Files | Lines |
|
Type: refactor
Change-Id: I5235bf3e9aff58af6ba2c14e8c6529c4fc9ec86c
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
IPFIX buffers are stored on a per worker thread basis. Currently, the
flush callbacks will flush only buffers stored for the main thread. And
buffers for worker threads will not be sent until their size reach the
path MTU configured for the exporter. So if traffic is constant, the
problem will unlikely to be visible. Buffers will be sent once they
reach the maximum size. However, if traffic stops at some point and
flush is triggered in order to make the plugin send all currently
buffered data, this will not happen. And collectors will not receive
that data. The plugin will keep the remaining data until traffic starts
again, the buffers reach the maximum size, and be sent.
With this fix, flush buffers for worker threads and for the main thread
when the flush callbacks are triggered.
This will allow to remove @tag_fixme_vpp_workers from the unit tests
that don't set timers. The tests that set timers will still be failing
for other multi-worker related problems.
Type: fix
Change-Id: I9a7d9cef8ddbec7ee68c79309e48e7bc0953d488
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
|
|
Currently, when flowprobe_export_send() calls vlib_time_now(), a pointer
to the main thread's vlib_main_t is always passed (the one cached in
flow_report_main). However, that code can also be executed from a worker
thread. And passing a pointer to the main thread's vlib_main_t to
vlib_time_now() from a worker thread may cause time synchronization
issues. Also, running a debug binary will cause an assertion failure in
vlib_time_now() in this case.
With this fix, flowprobe_export_send() passes the pointer to the current
thread's vlib_main_t to vlib_time_how().
This doesn't allow to remove @tag_fixme_vpp_workers from the unit tests
yet as they will be failing for other multi-worker related problems.
Type: fix
Change-Id: Ia35e3a4176777b88cf8ca8af8af7c42c495cbc6a
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Type: feature
Currently, the plugin supports only IPFIX flow record generation for
outbound packets.
With this change:
- add a new API message for enabling the feature on an interface that
accepts direction (rx, tx, both);
- update existing debug command for feature enabling to accept
direction;
- update existing debug command for showing currently enabled feature
on interfaces to display direction;
- update templates to include a direction field;
- generate flow records on the specified direction and data path;
- report direction in flow data;
- update tests to use the new API;
- add tests for inbound flows.
Change-Id: I121fd904b38408641036ebeea848df7a4e5e0b30
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
|
|
Modify the ipfix_exporter to use ip_address instead of the ipv4 specific
version. Modify the current code so that it writes into the v4 specific
part of the address, i.e. we are not yet fully supporting IPv6. For the
exporter configured via the original API (the one that is always in slot0)
we will not support IPv6 addresses.
Type: improvement
Signed-off-by: Paul Atkins <patkins@graphiant.com>
Change-Id: Ic9854ac62aaee76a7a55a958234c456fd9828c4c
|
|
Pull out the fields in flow_report_main_t that are specific to a single
exporter and move them into a new structure that represents an exporter.
Add a pool of exporters to flow_report_main_t and do a pool_get() to get
the entry at index 0, so that the existing users of the code need only
change the path at which they access the old fields and have no need to
make further code changes. In functions that were accessing the fields
that now make up the ipfix_exporter create a local var that points to the
first (always valid) exporter and use this as the base for the fields
rather than finding them from flow_report_main.
This is in preparation for supporting multiple flow_exporters.
Note that at the moment the code supports multiple 'streams' for a given
exporter, where each stream has its own source port, domain id and template
space. But all streams within an exporter have the same destination address,
so this is not the same as multiple exporters.
Type: refactor
Signed-off-by: Paul Atkins <patkins@graphiant.com>
Change-Id: I49f5c7fb9e901773351d31dc8a59178c37e99301
|
|
Skip 802.1q headers due to correct EtherType, ip addresses, ports.
Ticket: VPP-1997
Type: fix
Change-Id: I1a552fa6abe5b1459dd7d2c5ac6ad0f62c51417c
Signed-off-by: Daniel Béreš <daniel.beres@pantheon.tech>
|
|
Change-Id: I7a6df4317beed78e394dc4ba8edd350ca5b2bc80
Type: fix
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Type: refactor
Change-Id: Id10cbf52e8f2dd809080a228d8fa282308be84ac
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
trajectory trace has been broken for a while because we used to save the
buffer trajectory in a vector pointed to in opaque2. This does not work
well when opaque2 is copied (eg. because of a clone) as 2 buffers end up
sharing the same vector.
This dedicates a full cacheline in the buffer metadata instead when
trajectory is compiled in. No dynamic allocation, no sharing, no tears.
Type: refactor
Change-Id: I6a028ca1b48d38f393a36979e5e452c2dd48ad3f
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
Type: fix
Ticket: VPP-1859
Signed-off-by: jan_cavojsky <Jan.Cavojsky@pantheon.tech>
Change-Id: Iaa5045001621ec99dc8579e8e989adf81dc60525
|
|
Type: improvement
Signed-off-by: Florin Coras <fcoras@cisco.com>
Change-Id: Id13f33843b230a1d169560742c4f7b2dc17d8718
|
|
Type: style
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: I26a19e42076e031ec5399d5ca05cb49fd6fbe1cd
|
|
In one's complement, there are two representations of zero: the all
zero and the all one bit values, often referred to as +0 and -0. See
RFC 1624 section 3 for more details.
This used to be taken care of in ip4_header_checksum(), but it is no
longer the case. The check ip->checksum == ip4_header_checksum (ip) is
no longer correct in the -0 case.
Always use ip4_header_checksum_is_valid() instead (which behaves
correctly since 9a79a1ab931c3b5a7ae07d6f0fcfef7c4368a2c4).
Type: fix
Fixes: e5f0050c7a5d411f96af6401797529d58825e2af
Change-Id: Iacc6b60645a834287b085aecb9e3fdb4554cf0cf
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
Type: docs
Change-Id: I9b5e5137eb4c1e89f6e8d7a278cd11a0fd496471
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
|
|
Change-Id: Ia083050389853c25b069f0f8286d50d3f4aef527
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
* u32/u64/uword mismatches
* pointer-to-int fixes
* printf formatting issues
* issues with incorrect "ULL" and related suffixes
* structure alignment and padding issues
Change-Id: I70b989007758755fe8211c074f651150680f60b4
Signed-off-by: David Johnson <davijoh3@cisco.com>
|
|
Change-Id: Id4f37f5d4a03160572954a416efa1ef9b3d79ad1
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: Ieb8b53977fc8484c19780941e232ee072b667de3
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I853386aebfe488ebb10328435b81b6e3403c5dd0
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
- always use 'va_args' as pointer in all format_* functions
- u32 for all 'indent' params as it's declaration was inconsistent
Change-Id: Ic5799309a6b104c9b50fec309cba789c8da99e79
Signed-off-by: Christophe Fontaine <christophe.fontaine@enea.com>
|
|
Upon hash collision, the flow start time was not reset.
The hash computation techniques (crc32 or xxhash) also both
had bugs which are now fixed.
Change-Id: I94d72997f34018d1699324264f7dded2a5cbd776
Signed-off-by: Pierre Pfister <ppfister@cisco.com>
|
|
When passive timer has less than 1 second left, it'll be forcifully
changed to 0 when converting from f64 to u64. As a result the
assertion will fail at the beginning of the passive timer start
fuction. This commit fixed this bug by adding a check of the delta.
Change-Id: I899b6e0ab4967dcecc821daf7e812dbbc90969ce
Signed-off-by: Andrew Li <zhaoxili@cisco.com>
|
|
- fixed problem with tcp_flag
- changed flowtimestamp into NTP format
Change-Id: I4ef05d6c69c5c078a0c80d59c5ccb0c85b924ba6
Signed-off-by: Ole Troan <ot@cisco.com>
|
|
crc_u32 was not defined for non x86_64 with SSE4.2 processors.
Calls to "crc_u32" are removed and replaced by either a call to
clib_crc32c or a call to clib_xxhash, as the result is not used
as a check value but as a hash.
Change-Id: I3af4d68e2e5ebd0c9b0a6090f848d043cb0f20a2
Signed-off-by: Christophe Fontaine <christophe.fontaine@enea.com>
|
|
Change-Id: I67839281623721bf42f0a918a53356143d9dc78a
Signed-off-by: Ole Troan <ot@cisco.com>
Signed-off-by: Pavel Kotucek <pkotucek@cisco.com>
Signed-off-by: Ole Troan <ot@cisco.com>
|