Hi Neale,
Please find the pcap attached.
I have created two tunnels IPv4 GRE tunnel and & IPv6 based tunnel.
The IPv4 based tunnel is working fine where as IPv6 based tunnels the
packets are getting dropped.
--
*Vikram*
On Tue, Jan 5, 2021 at 9:43 PM Neale Ranns wrote:
> Hi,
>
>
>
> It’s not
Hi Vikram,
I don’t see a v6 tunnel encapped packet in that trace.
/neale
From: Vikram Sachdeva
Date: Monday, 18 January 2021 at 09:11
To: Neale Ranns
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] GRE Tunnel IP6 over IP6
Hi Neale,
Please find the pcap attached.
I have created two tunnels
Hi Stanislas,
All I can say is the buffer management routine are widely used & tested so
chances are the bug comes from your code but it is hard to guess what is
happening without looking into it. If you can share it, we can have a quick
look to see if we can spot any obvious error there.
By
Hi everyone,
I agree with opinion #3 as well. It allows us to keep 0 as “unknown" (i.e., not
set by the driver), and we can specify ~0 as “Not Applicable” (typically the
case for virtual links) and change format_vnet_hw_interface_link_speed
accordingly.
Best regards,
Mohammed
> On 18 Jan
Hi Stanislav,
As you noted, vlib_buffer_validate_alloc_free() is the only place that
would change the "known state" of a buffer. All of the calls to that
function are in vlib/buffer_funcs.h in inline functions in conditional
blocks with a condition like 'if (CLIB_DEBUG > 0)'. One of those calls
I am used to the bihash's easy to understand key-value pair API to program
an entry for table lookup using the hash.
https://github.com/FDio/vpp/blob/master/src/vppinfra/bihash_48_8.h#L39
The value in the struct is a u64.
To see how I program a classifier entry for use by the data
Hi Matthew,
Many thanks for opening my eyes. Now everything is perfectly clear for me.
On Mon, 18 Jan 2021 at 18:10, Matthew Smith wrote:
>
> Hi Stanislav,
>
> As you noted, vlib_buffer_validate_alloc_free() is the only place that
> would change the "known state" of a buffer. All of the calls
Hi all,
I'm using the python api to create a ACL rule and apply it to the egress side
of an interface. The VPP version = 20.09-release, and the ACL plugin version
is 1.4.
The rule is to block all the packets addressed to a host's address at port
. When the rule is added to the
Hi Hyong,
When you use acl plugin to apply an acl to an interface, it has the implicit
“deny everything” in the end of processing.
If you want to only drop a selected port, you need to add an explicit “permit”
at the end. If you didn’t do it, I would expect the results as you describe
them.
Hi,
Thanks for the great info! I'll take a look at the test code and apply to my
own testing.
Thanks,
--Hyong
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18540): https://lists.fd.io/g/vpp-dev/message/18540
Mute This Topic:
Please see this PR to fix what I need.
https://github.com/FDio/vpp/pull/33
Please review - thanks.
Hemant
From: vpp-dev@lists.fd.io On Behalf Of hemant via
lists.fd.io
Sent: Monday, January 18, 2021 10:52 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] classifier howto?
I am
Hi Matt,
I am adding the list so that maybe VPP DPDK plugin users/maintainers can chime
in.
In my opinion #3 setting link speed to ~0 makes sense as VPP usually use ~0 as
"invalid".
The original issue I attempted to fix in DPDK was that the Mellanox DPDK driver
was not able to return link
12 matches
Mail list logo
