Sorry John, I may take some more time to test this.
For now, we are using a work-around using arping to avoid flood. On Thu, Jun 4, 2020 at 2:02 PM John Lo (loj) <l...@cisco.com> wrote: > Any input packets with mcast bit set on its DMAC will not be dropped. > This would apply to all mcast/bcast packets. Only packets with unicast > DMAC not matching interface MAC are dropped by NIC or ethernet-input > node. -John > > > > *From:* Balaji Venkatraman (balajiv) <bala...@cisco.com> > *Sent:* Thursday, June 04, 2020 4:55 PM > *To:* John Lo (loj) <l...@cisco.com>; Nagaraju Vemuri < > nagarajuiit...@gmail.com> > *Cc:* Andrew 👽 Yourtchenko <ayour...@gmail.com>; vpp-dev@lists.fd.io > *Subject:* Re: [vpp-dev] VPP forwarding packets not destined to it #vpp > > > > Hi John, > > > > I assume the pass thru/drop applies to multicast frames too(assuming we > have IGMP enabled segment). Correct? > > > > Thanks! > > > > -- > > Regards, > > Balaji. > > > > > > *From: *<vpp-dev@lists.fd.io> on behalf of "John Lo (loj) via lists.fd.io" > <loj=cisco....@lists.fd.io> > *Reply-To: *"John Lo (loj)" <l...@cisco.com> > *Date: *Wednesday, June 3, 2020 at 1:38 PM > *To: *Nagaraju Vemuri <nagarajuiit...@gmail.com> > *Cc: *Andrew 👽 Yourtchenko <ayour...@gmail.com>, "vpp-dev@lists.fd.io" < > vpp-dev@lists.fd.io> > *Subject: *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 <nagarajuiit...@gmail.com> > *Sent:* Wednesday, June 03, 2020 3:10 PM > *To:* John Lo (loj) <l...@cisco.com> > *Cc:* Andrew 👽 Yourtchenko <ayour...@gmail.com>; vpp-dev@lists.fd.io > *Subject:* Re: [vpp-dev] VPP forwarding packets not destined to it #vpp > > > > Also, do we have any counters to validate this patch? > > > > On Wed, Jun 3, 2020 at 11:41 AM John Lo (loj) <l...@cisco.com> 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 DMAC which does not match interface MAC. If you can > pull/clone the latest VPP, either master or stable/2005 branch, and build, > the image should have my patch included. Please let us know if it solve > your problem or not. > > > > Regards, > > John > > > > *From:* Nagaraju Vemuri <nagarajuiit...@gmail.com> > *Sent:* Wednesday, June 03, 2020 1:52 PM > *To:* Andrew 👽 Yourtchenko <ayour...@gmail.com> > *Cc:* John Lo (loj) <l...@cisco.com>; vpp-dev@lists.fd.io > *Subject:* 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 <ayour...@gmail.com> > 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 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 - still TBD. > > > > Would you be able to build the VPP in your own environment and give the > feedback whether John’s fix addresses the issue you are seeing ? > > > > --a > > > > On 3 Jun 2020, at 19:23, Nagaraju Vemuri <nagarajuiit...@gmail.com> wrote: > > Thanks John. > > > > Which release will have your fixes? > > > > > > On Wed, Jun 3, 2020 at 10:21 AM John Lo (loj) <l...@cisco.com> 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: > > https://gerrit.fd.io/r/c/vpp/+/27027 > > https://gerrit.fd.io/r/c/vpp/+/27311 > > > > Perhaps it is the issue you are hitting. > > > > Regards, > > John > > > > *From:* Nagaraju Vemuri <nagarajuiit...@gmail.com> > *Sent:* Wednesday, June 03, 2020 1:06 PM > *To:* John Lo (loj) <l...@cisco.com> > *Cc:* vpp-dev@lists.fd.io > *Subject:* 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 L3 IP address. > > When we send traffic, this linux bridge forwards traffic from one > interface of VM to another interface on a different VM. > > If the bridge has no mac-to-port binding info, it is forwarding packets to > all interfaces, so all VPPs receive these packets. > > And the VPP whose MAC is not matching with this packet, just forwards this > packet again. > > We want VPP to drop a packet if the destination MAC doesnt match with VPP > interfaces MAC addresses. > > > > Hope I am clear now. > > > > Thanks, > > Nagaraju > > > > > > > > On Wed, Jun 3, 2020 at 8:53 AM John Lo (loj) <l...@cisco.com> wrote: > > 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 each of the interface is on a separate VPP instance? > > > > > Hence VPP receives some packets whose MAC address is owned by some other > VPP instance. > > We want to drop such packets. By default VPP is forwarding these packets. > > 1. How is VPP receiving packets from its interface and forwarding > them? > 2. Is the interface in L3 mode with an IP address/subnet configured? > 3. It can be helpful to provide “show interface addr” output or, even > better, provide a packet trace from VPP on how one or more of the packet is > received and forwarded. > > > > Regards, > > John > > > > *From:* vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> *On Behalf Of *Nagaraju > Vemuri > *Sent:* Tuesday, June 02, 2020 8:13 PM > *To:* vpp-dev@lists.fd.io > *Subject:* [vpp-dev] VPP forwarding packets not destined to it #vpp > > > > Hi, > > We are using linux bridge to connect different interfaces owned by > different VPP instances. > When the bridge has no binding info about MAC-to-port, bridge is flooding > packets to all interfaces. > Hence VPP receives some packets whose MAC address is owned by some other > VPP instance. > We want to drop such packets. By default VPP is forwarding these packets. > > We tried using "set interface l2 forward <interface> disable", but this > did not help. > > Please suggest what we can do. > > > Thanks, > Nagaraju > > > > > -- > > Thanks, > Nagaraju Vemuri > > > > > -- > > Thanks, > Nagaraju Vemuri > > > > > -- > > Thanks, > Nagaraju Vemuri > > > > > -- > > Thanks, > Nagaraju Vemuri > -- Thanks, Nagaraju Vemuri
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16680): https://lists.fd.io/g/vpp-dev/message/16680 Mute This Topic: https://lists.fd.io/mt/74640593/21656 Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
