Hi Andreas, > The setup this happens on has not been changed, except for VPP and kernel > upgrades. I can't say which upgrade did trigger this problem, but it feels > like a kernel version thing at the moment (5.0, 5.3 and 5.6 tested, all > exhibit this, 4.x might not - need to retest).
Note that it works perfectly fine for me in a VM with kernel 5.3.0-1018-azure #19~18.04.1-Ubuntu on Ubuntu 18.04 using veth. Maybe try to bisect kernel commits to see what triggers this behavior on your system? > There is nothing that messes with the interface and the interface is up > all the time. The problem occurs randomly, but only when load is sent > through VPP. Once the interface is messed up, it will stay that way and > not TX any traffic any more. Best ben > > > It seems that somehow the interface is messed up. Anything I can > do to > > debug this further? > > > > VPP is current from master branch, OS is Ubuntu 18.04.4 with the > 5.3.0-42- > > generic kernel. > > > > Andreas > > > > Am Fr., 3. Apr. 2020 um 11:03 Uhr schrieb Andreas Schultz via > lists.fd.io <http://lists.fd.io> > > <http://lists.fd.io> <andreas.schultz=travelping....@lists.fd.io > <mailto:travelping....@lists.fd.io> > > <mailto:travelping....@lists.fd.io > <mailto:travelping....@lists.fd.io> > >: > > > > > > Hi again, > > > > forget my first description of the problem. After using a > VPP node > > handoff PCAP trace I've discovered that ARP answers are only send > on the > > correct interface. > > > > Or at least VPP tries. The node trace shows that VPP tries > to send > > the ARP answer (it hits host-ens224-tx), but the packet is not > seen by a > > tcpdump/dumpcap on the raw host interface. It seems that somehow > the af- > > packet interface is screwed. > > > > Andreas > > > > Am Fr., 3. Apr. 2020 um 10:46 Uhr schrieb Andreas Schultz > via > > lists.fd.io <http://lists.fd.io> <http://lists.fd.io> > > <andreas.schultz=travelping....@lists.fd.io > <mailto:travelping....@lists.fd.io> > > <mailto:travelping....@lists.fd.io > <mailto:travelping....@lists.fd.io> > >: > > > > > > Hi, > > > > I have two interfaces that are connected to the same > layer L2 > > network. Both interfaces have IPs from the same /24 IP range, but > they are > > in different FIBs. > > > > My problem is now that ARP are answered on the wrong > interface > > (with the correct MAC). With the attached config a ARP request for > > 172.20.16.105 (interface ens224) is answered on interface ens161. > > > > In itself the answer on the wrong interface would > not be a big > > problem, but the underlying switch is confused by seeing the MAC > address > > on the wrong interface. > > > > I could understand this behavior if both > interfaces/IP where > > in the same FIB, but they are not! > > > > It seems to me that the ARP responder node should > filter by > > src/dst FIB index? Is there an option or setting to enable that? > > > > Regards, > > Andreas > > > > Config: > > > > ip table add 1 > > ip table add 2 > > > > create host-interface name ens224 > > set interface mac address host-ens224 > 00:0c:29:46:1f:53 > > set interface mtu 1500 host-ens224 > > set interface ip table host-ens224 1 > > set interface ip address host-ens224 > 172.20.16.105/24 <http://172.20.16.105/24> > > <http://172.20.16.105/24> > > set interface state host-ens224 up > > > > create host-interface name ens161 > > set interface mac address host-ens161 > 00:50:56:86:ed:f9 > > set interface mtu 1500 host-ens161 > > set interface ip table host-ens161 2 > > set interface ip address host-ens161 > 172.20.16.106/24 <http://172.20.16.106/24> > > <http://172.20.16.106/24> > > set interface state host-ens161 up > > > > > > > > > > -- > > > > > > Andreas Schultz > > > > > > > > > > > > -- > > > > > > Andreas Schultz > > > > -- > > > > Principal Engineer > > > > t: +49 391 819099-224 > > > > > > > > ------------------------------- enabling your networks ----- > -------- > > ---------------- > > > > Travelping GmbH > > Roentgenstraße 13 > > 39108 Magdeburg > > Germany > > > > > > > > t: +49 391 819099-0 > > f: +49 391 819099-299 > > > > e: i...@travelping.com <mailto:i...@travelping.com> > <mailto:i...@travelping.com <mailto:i...@travelping.com> > > > w: https://www.travelping.com/ > > > > Company registration: Amtsgericht Stendal > > Geschaeftsfuehrer: Holger Winkelmann > > Reg. No.: HRB 10578 > > VAT ID: DE236673780 > > > > > > > > > > -- > > > > > > Andreas Schultz > > > > -- > > > > Principal Engineer > > > > t: +49 391 819099-224 > > > > ------------------------------- enabling your networks ----------- > -------- > > ---------- > > > > Travelping GmbH > > Roentgenstraße 13 > > 39108 Magdeburg > > Germany > > > > > > > > t: +49 391 819099-0 > > f: +49 391 819099-299 > > > > e: i...@travelping.com <mailto:i...@travelping.com> > <mailto:i...@travelping.com <mailto:i...@travelping.com> > > > w: https://www.travelping.com/ > > > > Company registration: Amtsgericht Stendal > > Geschaeftsfuehrer: Holger Winkelmann > > Reg. No.: HRB 10578 > > VAT ID: DE236673780 > > > > > -- > > > Andreas Schultz > > -- > > Principal Engineer > > t: +49 391 819099-224 > > ------------------------------- enabling your networks ------------------- > ---------- > > Travelping GmbH > Roentgenstraße 13 > 39108 Magdeburg > Germany > > > > t: +49 391 819099-0 > f: +49 391 819099-299 > > e: i...@travelping.com <mailto:i...@travelping.com> > w: https://www.travelping.com/ > > Company registration: Amtsgericht Stendal > Geschaeftsfuehrer: Holger Winkelmann > Reg. No.: HRB 10578 > VAT ID: DE236673780
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15998): https://lists.fd.io/g/vpp-dev/message/15998 Mute This Topic: https://lists.fd.io/mt/72745159/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
