Re: [vpp-dev] NAT44 UDP sessions are not clearing

Transitory means that the session has not been fully established. Transitory (wait-closed) means the session has been established and then closed and it’s in transitory timeout, after which it will move to transitory (closed). Sessions in this state are not eligible for freeing. Transitory

Re: [vpp-dev] SEGMENTATION FAULT in load_balance_get()

Please test https://gerrit.fd.io/r/c/vpp/+/27407 and report results. -Original Message- From: vpp-dev@lists.fd.io On Behalf Of Dave Barach via lists.fd.io Sent: Wednesday, June 3, 2020 7:08 AM To: Benoit Ganne (bganne) ; raj...@rtbrick.com Cc: vpp-dev ; Neale Ranns (nranns) Subject:

Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Use the force and read the source: /*? * Layer 2 flooding can be enabled and disabled on each * interface and on each bridge-domain. Use this command to * manage bridge-domains. It is enabled by default. * * @cliexpar * Example of how to enable flooding (where 200 is the bridge-domain-id): *

Re: [vpp-dev] ixge and rdma drivers

Looking forward at new purchases. I was trying to find the list of native supported PCI devices. The obvious ones I see are avf and rdma. So Intel 710 (now 810?) virtual function and mellanox connectx-(456?) That's not a lot to choose from, but the mellanox choice is pretty good one I suppose

Re: [vpp-dev] SEGMENTATION FAULT in load_balance_get()

+1, can't tell which poison pattern is involved without a scorecard. load_balance_alloc_i (...) is clearly not thread-safe due to calls to pool_get_aligned (...) and vlib_validate_combined_counter(...). Judicious use of pool_get_aligned_will_expand(...), _vec_resize_will_expand(...) and a

Re: [vpp-dev] Assertion failure triggered by "ip mroute add" command (master branch)

Hi Elias, It is probably a bug but I could not reproduce it. Note that commit 30cca512c (build: remove valgrind leftovers, 2019-11-25) is present in stable/2001 so probably not the culprit... Can you share how you built VPP and your complete startup.conf? You seems to be running those commands

Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

I recently submitted two patches, one for master and the other for stable/2005, to fix an issue with L3 virtual interfaces not filter input packets with wrong unicast MAC address: https://gerrit.fd.io/r/c/vpp/+/27027 https://gerrit.fd.io/r/c/vpp/+/27311 Perhaps it is the issue you are hitting.

Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

20.05.1. The fix was ready just a little bit too late to be a safe to merge right at the moment of the release, so given the size of the patch and that the issue was there for a couple of releases already I made a call to postpone it till the first dot release. As for the timing for the

Re: [**EXTERNAL**] [vpp-dev] VPP fast-path vs slow-path

Gentle reminder on this. Any info would be much appreciated. Thanks, Leela sankar Gudimetla Embedded Software Engineer 3 | Ciena San Jose, CA, USA M | +1.408.904.2160 [Ciena Logo] From: on behalf of "Gudimetla, Leela Sankar via lists.fd.io" Reply-To:

Re: [**EXTERNAL**] [vpp-dev] VPP fast-path vs slow-path

I’t was just my decision to optimiize code for ipv4, ipv6, mpls traffic, knowing that 99.99% of traffic falls under that category…. > On 3 Jun 2020, at 18:22, Gudimetla, Leela Sankar via lists.fd.io > wrote: > > Gentle reminder on this. Any info would be much appreciated. > > Thanks, >

Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Hi John, Sorry, I should have been more clear. We are using Virtual machines(KVM based) on which VPP runs. KVM qemu creates bridge (using brctl) on physical machine and creates TAP interfaces from this bridge for Virtual Machines(VMs) networking. We run VPP on VMs and configure interfaces with

Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Please clarify the following: > When the bridge has no binding info about MAC-to-port, bridge is flooding > packets to all interfaces. 1. Is this linux bridge that’s in the kernel so not a bridge domain inside VPP? 2. So packets are flooded to all interfaces in the bridge. Are you saying

Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Thanks John. Which release will have your fixes? On Wed, Jun 3, 2020 at 10:21 AM John Lo (loj) wrote: > I recently submitted two patches, one for master and the other for > stable/2005, to fix an issue with L3 virtual interfaces not filter input > packets with wrong unicast MAC address: > >

Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Hi Nagaraju, No extra config required than standard L3 setup you already have with IP address/subnet on your interface. Such L3 interface should drop packets with unicast DMAC which does not match interface MAC. If you can pull/clone the latest VPP, either master or stable/2005 branch, and

Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Hi Nagaraju, Perhaps you need to disable it on the interface in question? Seems like it is enabled by default. Thanks! -- Balaji set bridge-domain flood Summary/usage set bridge-domain flood [disable]. Description Layer 2 flooding can be enabled and disabled on each interface and on each

Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Sure Andrew. I will help with that. Do I need to configure something in VPP with this patch to drop such packets? Thanks, Nagaraju On Wed, Jun 3, 2020 at 10:48 AM Andrew  Yourtchenko wrote: > 20.05.1. The fix was ready just a little bit too late to be a safe to > merge right at the moment

[vpp-dev] Assertion failure triggered by "ip mroute add" command (master branch)

Hello VPP experts, There seems to be a problem with "ip mroute add" causing assertion failure. This happens for the current master branch and the stable/2005 branch, but not for stable/1908 and stable/2001. Doing the following is enough to see the problem: create int rdma host-if enp101s0f1

Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

We can use “show node counters” which should display counter for packets dropped due to MAC mismatch. -John From: Nagaraju Vemuri Sent: Wednesday, June 03, 2020 3:10 PM To: John Lo (loj) Cc: Andrew  Yourtchenko ; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] VPP forwarding packets not destined

Re: [vpp-dev] Assertion failure triggered by "ip mroute add" command (master branch)

Hi Ben! > It is probably a bug but I could not reproduce it. > Note that commit 30cca512c (build: remove valgrind > leftovers, 2019-11-25) is present in stable/2001 > so probably not the culprit... Agreed. > Can you share how you built VPP and your complete startup.conf? > You seems to be

Re: [vpp-dev] SEGMENTATION FAULT in load_balance_get()

Neale is away and might be slow to react. I suspect the issue is when creating new load balance entry through load_blance_create(), which will get a new element from the load balance pool. This in turn will update the pool free bitmap, which can grow. As it is backed by a vector, it can be