I read that a traditional Cisco CEF router behaves as follows:

"When the ping process tries to send the first packet and does not see an
ARP entry, it initiates an ARP request. It continues to try to send the
packet, and then drops the packet after a defined wait period. When an ARP
response is received and the ARP entry is completed using a background
process, the ping success rate is 100 percent."

Is that the same exact thing that happens with VPP? It is difficult for me
to be certain. For example, it seems that if (in the traditional CEF
router) the predefined wait period was set long enough (longer than the ARP
processing time) then all the ping packets would be forwarded. That's not
what they show in the text, though, at
https://www.cisco.com/c/en/us/support/docs/ip/express-forwarding-cef/17812-cef-incomp.html#t4

Burt

On Fri, Sep 28, 2018 at 5:53 PM Dave Barach via Lists.Fd.Io <dbarach=
cisco....@lists.fd.io> wrote:

> 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/541103
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [bur...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10719): https://lists.fd.io/g/vpp-dev/message/10719
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]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to