This is deliberate, traditional router behavior. Alternatives involving queueing packets for reinjection after glean resolution events give rise to resource exhaustion attacks. Mitigating that kind of attack burns clock cycles, which in turn gives rise to a different kind of attack.
HTH... Dave From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Rui Cai via Lists.Fd.Io Sent: Friday, September 28, 2018 5:14 PM To: vpp-dev@lists.fd.io Cc: vpp-dev@lists.fd.io Subject: [SUSPICIOUS] [vpp-dev] Question about ip4(6)-glean node behavior and packet drops Hello VPP experts: I have question about the behavior of ip4(6)-glean nodes. In particular, I'm noticing the node is dropping the original packet that triggered glean process. The VPP I'm running is 18.07 with DPDK 18.02. I'm using VPP as a simple forwarding application where final destination's MAC address is not known to VPP at the beginning. I'm sending IPv4 packet using scapy and for the 1st packet VPP receives, I see VPP redirects this packet to ip4-glean node where it will send an ARP request to learn forwarding destination's MAC address. However, it appears the ip4-glean node will also drop my original packet that triggered this process. Is this an expected behavior? If I keep deleting the arp entry of my final destination IP in VPP repeatedly (not that a normal application would keep doing this, but just for experiment), I see no packets reaching my final destination. In general, is there some notion of "pending" packets in VPP? Like taking a packet out of current input vector and process such packet later, without blocking next input vectors getting generated? Thanks a lot, -Ray
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10711): https://lists.fd.io/g/vpp-dev/message/10711 Mute This Topic: https://lists.fd.io/mt/26380933/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
