Dave Barach has a gdb VPP video that uses the "ip probe-neighbor".
However, clearly, VPP does not support this CLI anymore. Thanks to Damjan
to find this commit that removed the CLI:
https://gerrit.fd.io/r/c/vpp/+/22819
Neale,
What is the alternative? Do I create a dynamic ARP entry and t
Hemant,
in my case, VPP acts as a bump in the wire, not as an interface to an
application, so my metadata about the original packet is limited.
Damjan,
the hack with reacquiring the pointer after the clone is working as expected.
I found an example using the L2 flag approach in src/vnet/interfa
> On 12.04.2021., at 12:50, David Gohberg wrote:
>
> Damjan,
>
> After looking at the vlib_buffer_clone_256 function I realize that it
> modifies the original buffer pointer, like you said.
> my packets are coming in down a custom node path (originating from an asic
> data plane), so they wi
If VPP doesn’t have an elegant way, note, a networking forwarding asic (e.g.,
switching asic) usually maintains two copies of headers of a packet. One copy
has all the original headers and the other copy is modified in the data path.
The asic should know what happened to the copy and provide t
I see vlib_buffer_reset(), but haven’t used it yet nor looked at any code that
uses it.
https://docs.fd.io/vpp/17.07/d0/d83/vlib_2buffer_8h.html#a2db4de69d8fc1ff619d0ad7a45ac08fe
Using vlib_buffer_advance() when the packet node-traversal is known is ok. I
know what arc is my node using
Damjan,
After looking at the vlib_buffer_clone_256 function I realize that it modifies
the original buffer pointer, like you said.
my packets are coming in down a custom node path (originating from an asic data
plane), so they will always have the l2 header.
The node that performs the cloning is
> On 12.04.2021., at 10:34, David Gohberg wrote:
>
> [Edited Message Follows]
>
> moving the buffer backwards by 14 looks correct for small packets, but for
> 1500 byte packets I get `truncated-ip - 14 bytes missing` error from tcpdump.
> After the clone I'm restoring the original offset:
>
[Edited Message Follows]
moving the buffer backwards by 14 looks correct for small packets, but for 1500
byte packets I get `truncated-ip - 14 bytes missing` error from tcpdump. After
the clone I'm restoring the original offset:
vlib_buffer_advance (b0, -14);
u16 n_cloned = vlib_buffer_clone (vm
moving the buffer backwards by 14 looks correct for small packets, but for 1500
byte packets I get `truncated-ip - 14 bytes missing` error from tcpdump
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19176): https://lists.fd.io/g/vpp-dev/message/191
Hemant,
I think you meant a negative 14, since the buffer points to the start of the IP
header, and we need to go backwards the size of the Ethernet header. Is there a
programmatic way to set the buffer to point to the start of the data, without
knowing the packet structure? offset calculations
10 matches
Mail list logo
