Have your favorite orchestrator prepopulate arp / ND tables. APIs are available.
From: Andreas Schultz <[email protected]> Sent: Friday, December 14, 2018 8:32 AM To: Dave Barach (dbarach) <[email protected]> Cc: [email protected] Subject: Re: [vpp-dev] first packet to yet unknown IP is lost Dave Barach (dbarach) <[email protected]<mailto:[email protected]>> schrieb am Fr., 14. Dez. 2018 um 14:19 Uhr: This is a conscious design decision / best practice used in routers for decades. We’re not going to change this behavior. Imagine what happens when a DDoS attack sends one packet to each of a large number of nonexistent hosts behind a certain router: all of its packet buffers end up on a reinject queue waiting for ARP replies. Even with ARP throttling [which vpp also uses] and with aggressive drop timers, it’s a bad idea. Mhh, I do understand your argument for packets routed through VPP. But I'm not talking about packets arriving from somewhere and being destined to a host on a local net, what I'm interested in are packets originating in VPP (either through a memif socket or some other API within VPP. These packets are either generated by the memif socket application wanting to talk to someone, an VPP component wanting to talk to someone or something responding to a host. In the first two cases, no DDoS can trigger that and the later case other mechanisms should protect the API from overload. Would it be possible to mark local originating packets and treat them accordingly? Andreas D. From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of Andreas Schultz Sent: Friday, December 14, 2018 5:04 AM To: [email protected]<mailto:[email protected]> Subject: [vpp-dev] first packet to yet unknown IP is lost Hi, There seems to some problem with ARP resolution and IP forwarding. The first packet destined to an yet unknown IP is dropped. It does triggers a ARP request, but the packet should be held in some kind of queue till then ARP response arrives and the be forwarded. Clearly this does not happen (at least with AF-Packet interfaces). The simplest way to observe this to start a new VPP instance and try to ping its interfaces. The first ICMP request will not be answered. Regards Andreas -- -- Dipl.-Inform. Andreas Schultz ----------------------- enabling your networks ---------------------- Travelping GmbH Phone: +49-391-81 90 99 0 Roentgenstr. 13 Fax: +49-391-81 90 99 299<tel:+49%20391%20819099299> 39108 Magdeburg Email: [email protected]<mailto:[email protected]> GERMANY Web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 --------------------------------------------------------------------- -- -- Dipl.-Inform. Andreas Schultz ----------------------- enabling your networks ---------------------- Travelping GmbH Phone: +49-391-81 90 99 0 Roentgenstr. 13 Fax: +49-391-81 90 99 299 39108 Magdeburg Email: [email protected]<mailto:[email protected]> GERMANY Web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 ---------------------------------------------------------------------
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11605): https://lists.fd.io/g/vpp-dev/message/11605 Mute This Topic: https://lists.fd.io/mt/28751128/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
