Age | Commit message (Collapse) | Author | Files | Lines |
|
Free node frames in worker mains on refork. Otherwise these frames are
never returned to free pool and it causes massive memory leaks if
performed under traffic load
Type: fix
Signed-off-by: Dmitry Valter <d-valter@yandex-team.ru>
Change-Id: I15cbf024a3f4b4082445fd5e5aaa10bfcf77f363
|
|
The flow_report_process_send() function always allocates a frame.
However, when no template_send is needed, template_bi is ~0.
When this happens, no vectors are placed in the frame. When
the frame is then "put", a check for n_vectors == 0 prevents
the frame from actually being placed back on the free list.
Fix that by using a direct call to vlib_frame_free() when
there are no frame vctors.
Type: fix
Signed-off-by: Jon Loeliger <jdl@netgate.com>
Change-Id: I936b5cea4cb3c358247c3d2e1a77d034a322ea76
|
|
Type: fix
Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>
Change-Id: I2b8b6a3b5a6df71e84ce2f15ef7117f390121c2f
|
|
When the ipfix address was changed to be an ip_address instead of
an ip4_address the output when creating an exporter via the cli
should have been modified to take the address of the v4 part of
the addr.
Type: fix
Signed-off-by: Paul Atkins <patkins@graphiant.com>
Change-Id: I141456cd9092c861a4c4aefba4035dbde23efcd6
|
|
The current code that sends ipfix packets assumes IPv4. Modify this
so that it generates and sends packets based on whether the destination
address is IPv4 or IPv6. Where code is common across multiple places
pull it out into helper functions.
Type: improvement
Signed-off-by: Paul Atkins <patkins@graphiant.com>
Change-Id: I216c6c4c1b58cacedca22019f74a38c64a368b7e
|
|
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
|
|
Rename the local variables used when building ipfix export packets to make
it clear that they are v4 specific variables.
Type: improvement
Signed-off-by: Paul Atkins <patkins@graphiant.com>
Change-Id: I3a5a623aeb0b6f2b7fcdafb3fc19c500934c529b
|
|
When a new flow-report is created the caller provides 2 callback functions.
These functions both take a pointer to the exporter, plus a pointer to the
source and dest address. However the pointers to the address are not adding
any value as these are always set to the src/dest addresses of the exporter
(which is already being passed). Remove these parameters and leave the
callback functions to get the addresses out of the exporter.
Type: improvement
Signed-off-by: Paul Atkins <patkins@graphiant.com>
Change-Id: I36dec394f30e85cdca120dd8706b5d90f5e07c48
|
|
The ipfix exporter should be doing most of the work of building packets
and sending them rather than leaving every client of the exporter to do
all the work themselves. Start to move towards that by adding APIs to
get and send buffers. Store the state of this in new per thread data on
the report so that we can send with minimal use of atomics. We do need
an atomic for the sequence number in the packet though as that contains
the number of data_records sent for the 'stream', not just for a single
core. As the state is stored on the flow_report_t the caller needs to
know which report they are using, so add a field to the args struct used
to create the report that is used to pass back the report index on success.
Type: improvement
Signed-off-by: Paul Atkins <patkins@graphiant.com>
Change-Id: I222b98a3f0326b3b71b11e0866a8c9736bed6dc1
|
|
The existing api set_ipfix_exporter only allows for the creation of
a single exporter. In some cases it is desirable to export data to
multiple different destinations. Allow users to create multiple
ipfix exporters to support this.
Add a new api that allows for the creation of multiple exporters, and
store them in a pool of exporters. The exporter created by the old API
will always be in index 0 of the pool. Exporters created by the new API
will be given the next available index in the pool, and will return this
index to the API caller so that they can track the exporter they created.
The collector_address is the key for the exporter, so changes can be made
by doing a further call to the API with the same collector_address.
Type: improvement
Signed-off-by: Paul Atkins <patkins@graphiant.com>
Change-Id: Id71c98cffcf8d141d890b40fb90a40b90a91d1d6
|
|
Pass an ipfix_exporter to this function so that callers can choose which
exporter they are modifying.
Type: improvement
Signed-off-by: Paul Atkins <patkins@graphiant.com>
Change-Id: Ice0ed19a57baf15b1dc85cd27fe01913e36d7f4f
|
|
The functions that work on streams were getting the set of streams
directly from flow_report_main. Modify them to take an ipfix_exporter
as an argument, and then any processing they do is only for this
exporter.
Type: refactor
Signed-off-by: Paul Atkins <patkins@graphiant.com>
Change-Id: I32bd9a6ba32a15ec4d4ec9556a9b75f3d83fcd6e
|
|
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
|
|
Indent sections of code properly in vec_foreach loops.
Type: style
Signed-off-by: Paul Atkins <patkins@graphiant.com>
Change-Id: I90183ace164df753f3f47b6c4a6305ded21d744d
|
|
Type: fix
The ipfix process node has a hardcoded 5s sleep between sending packets.
The interval between template packets is configurable, but the timing
of packets being sent does not match configuration because of the time
being hardcoded. E.g. -
With template interval set to 3s, a packet will be sent every 5s.
With template interval set to 8s, a packet will be sent every 10s.
Honor the configuration by reducing the wait time to less than 5s if a
template will need to be sent less than 5s from the current time.
Change-Id: I8c11f7bc502ce5b20b6e82a7e7a135a8805a2bad
Signed-off-by: Matthew Smith <mgsmith@netgate.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: improvement
Signed-off-by: Florin Coras <fcoras@cisco.com>
Change-Id: Id13f33843b230a1d169560742c4f7b2dc17d8718
|
|
Use %U and unformat_udp_port instead of %u for unformat() call for
u16 collector_port number in set_ipfix_exporter_command_fn() to
avoid corruption of other variables which can happen if unformat()
with %u is used with a 16-bit variable. This avoids crash due to
corrupted fib_index value.
Type: fix
Signed-off-by: Elias Rudberg <elias.rudberg@bahnhof.net>
Change-Id: Id54273fcc458a7f9c5aa4025aa91711f160c1c1a
|
|
Type: fix
Change-Id: Id6687780b9a740323bd2eef58447864e70dc0235
Signed-off-by: Ignas Bacius <ignas@noia.network>
|
|
The vlib init function subsystem now supports a mix of procedural and
formally-specified ordering constraints. We should eliminate procedural
knowledge wherever possible.
The following schemes are *roughly* equivalent:
static clib_error_t *init_runs_first (vlib_main_t *vm)
{
clib_error_t *error;
... do some stuff...
if ((error = vlib_call_init_function (init_runs_next)))
return error;
...
}
VLIB_INIT_FUNCTION (init_runs_first);
and
static clib_error_t *init_runs_first (vlib_main_t *vm)
{
... do some stuff...
}
VLIB_INIT_FUNCTION (init_runs_first) =
{
.runs_before = VLIB_INITS("init_runs_next"),
};
The first form will [most likely] call "init_runs_next" on the
spot. The second form means that "init_runs_first" runs before
"init_runs_next," possibly much earlier in the sequence.
Please DO NOT construct sets of init functions where A before B
actually means A *right before* B. It's not necessary - simply combine
A and B - and it leads to hugely annoying debugging exercises when
trying to switch from ad-hoc procedural ordering constraints to formal
ordering constraints.
Change-Id: I5e4353503bf43b4acb11a45fb33c79a5ade8426c
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I4e836244409c98739a13092ee252542a2c5fe259
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Example:
buffers {
default data-size 1536
}
Change-Id: I5b4436850ca18025c9fdcfc7ed648c2c2732d660
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Ia083050389853c25b069f0f8286d50d3f4aef527
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Id4f37f5d4a03160572954a416efa1ef9b3d79ad1
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Instead of repeatedly cutting, pasting, and hacking to create a new
callback, use vnet_flow_rewrite_generic_callback(). Add three
arguments to the flow rewrite callback:
(in) pointer to an array of report elements,
(in) length of array,
(out) pointer to the stream index
Change existing code prototypes. Code owners encouraged to evaluate
whether they can use the generic callback or not, at leisure.
/* ipfix field definitions for a particular report */
typedef struct
{
u32 info_element;
u32 size;
} ipfix_report_element_t;
Best generated like so:
_(sourceIPv4Address, 4) \
_(destinationIPv4Address, 4) \
_(sourceTransportPort, 2) \
_(destinationTransportPort, 2) \
_(protocolIdentifier, 1) \
_(flowStartMicroseconds, 8) \
_(flowEndMicroseconds, 8)
static ipfix_report_element_t simple_report_elements[] = {
foreach_simple_report_ipfix_element
};
...
/* Set up the ipfix report */
memset (&a, 0, sizeof (a));
a.is_add = 1 /* to enable the report */ ;
a.domain_id = 1 /* pick a domain ID */ ;
a.src_port = UDP_DST_PORT_ipfix /* src port for reports */ ;
a.rewrite_callback = vnet_flow_rewrite_generic_callback;
a.report_elements = simple_report_elements;
a.n_report_elements = ARRAY_LEN (simple_report_elements);
a.stream_indexp = &jim->stream_index;
a.flow_data_callback = simple_flow_data_callback;
/* Create the report */
rv = vnet_flow_report_add_del (frm, &a, &template_id);
if (rv)
return rv;
...
Change-Id: If6131e6821d3a37a29269c0d58040cdf18ff05e4
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I9363cf54b73f7cfd8622af6f1cb250438ea0d3b6
Signed-off-by: Ole Troan <ot@cisco.com>
|