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

2020-06-03 Thread Benoit Ganne (bganne) via lists.fd.io
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 reall

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

2020-06-03 Thread Klement Sekera via lists.fd.io
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 (close

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

2020-06-03 Thread Dave Barach via lists.fd.io
+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 manu

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

2020-06-03 Thread Dave Barach via lists.fd.io
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): * @clie

Re: [vpp-dev] ixge and rdma drivers

2020-06-03 Thread Christian Hopps
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 i

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

2020-06-03 Thread Dave Barach via lists.fd.io
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] Assertion failure triggered by "ip mroute add" command (master branch)

2020-06-03 Thread Elias Rudberg
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 name

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

2020-06-03 Thread John Lo (loj) via lists.fd.io
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: [**EXTERNAL**] [vpp-dev] VPP fast-path vs slow-path

2020-06-03 Thread Gudimetla, Leela Sankar via lists.fd.io
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: Leel

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

2020-06-03 Thread Damjan Marion via lists.fd.io
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, > Lee

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

2020-06-03 Thread Nagaraju Vemuri
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 L

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

2020-06-03 Thread Balaji Venkatraman via lists.fd.io
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 bridg

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

2020-06-03 Thread Benoit Ganne (bganne) via lists.fd.io
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

2020-06-03 Thread John Lo (loj) via lists.fd.io
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

2020-06-03 Thread Nagaraju Vemuri
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: > > ht

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

2020-06-03 Thread Andrew Yourtchenko
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 20.05.1

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

2020-06-03 Thread Nagaraju Vemuri
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 of

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

2020-06-03 Thread Andrew Yourtchenko
Cool, thanks a lot for checking! Just build VPP off the latest master or latest stable/2005 - the fix is in both branches already, so it should “just work correctly”. --a > On 3 Jun 2020, at 19:52, Nagaraju Vemuri wrote: > >  > Sure Andrew. > I will help with that. > > Do I need to configur

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

2020-06-03 Thread John Lo (loj) via lists.fd.io
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 b

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

2020-06-03 Thread Nagaraju Vemuri
Also, do we have any counters to validate this patch? On Wed, Jun 3, 2020 at 11:41 AM John Lo (loj) wrote: > 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 DMA

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

2020-06-03 Thread John Lo (loj) via lists.fd.io
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 t

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

2020-06-03 Thread Elias Rudberg
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 runnin