Re: [vpp-dev] Question about ip4(6)-glean node behavior and packet drops
IOS Classic, IOS XR, and NXOS behave slightly differently under the covers. To avoid disclosing trade secrets, I can’t go into the minutiae. VPP uses buffers which hit glean adjacencies – e.g. an ip4 icmp echo request – to manufacture the outbound neighbor discovery packet (e.g. ip4 arp request). D. From: Burt Silverman Sent: Sunday, September 30, 2018 9:36 PM To: Dave Barach (dbarach) Cc: ru...@microsoft.com; vpp-dev Subject: Re: [vpp-dev] Question about ip4(6)-glean node behavior and packet drops 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<http://Lists.Fd.Io> mailto: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<mailto:vpp-dev@lists.fd.io> mailto:vpp-dev@lists.fd.io>> On Behalf Of Rui Cai via Lists.Fd.Io<http://Lists.Fd.Io> Sent: Friday, September 28, 2018 5:14 PM To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Cc: vpp-dev@lists.fd.io<mailto: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<mailto:vpp-dev%2bow...@lists.fd.io> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [bur...@gmail.com<mailto:bur...@gmail.com>] -=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10720): https://lists.fd.io/g/vpp-dev/message/10720 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Question about ip4(6)-glean node behavior and packet drops
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 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 *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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Question about ip4(6)-glean node behavior and packet drops
Ray, > On 29 Sep 2018, at 02:01, Rui Cai via Lists.Fd.Io > wrote: > > Thanks for the explanation, Dave! It makes sense. > > In general, does VPP not use the behavior of queuing and reinjection for any > scenario due to the resource exhaustion attack reason? Or is there such > pattern (queue & re-inject) for a particular scenario I can study? (virtual) reassembly is one. I only know the implementation in src/plugins/map It’s an attack vector, so it’s wrapped in lots of checks. Cheers Ole > From: Dave Barach (dbarach) > Sent: Friday, September 28, 2018 2:53 PM > To: Ray Cai ; vpp-dev@lists.fd.io > Subject: RE: Question about ip4(6)-glean node behavior and packet drops > > 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 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 (#10712): https://lists.fd.io/g/vpp-dev/message/10712 > Mute This Topic: https://lists.fd.io/mt/26380933/675193 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [otr...@employees.org] > -=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10714): https://lists.fd.io/g/vpp-dev/message/10714 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Question about ip4(6)-glean node behavior and packet drops
Thanks for the explanation, Dave! It makes sense. In general, does VPP not use the behavior of queuing and reinjection for any scenario due to the resource exhaustion attack reason? Or is there such pattern (queue & re-inject) for a particular scenario I can study? Thanks, -Ray From: Dave Barach (dbarach) Sent: Friday, September 28, 2018 2:53 PM To: Ray Cai ; vpp-dev@lists.fd.io Subject: RE: Question about ip4(6)-glean node behavior and packet drops 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<mailto:vpp-dev@lists.fd.io> mailto: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<mailto:vpp-dev@lists.fd.io> Cc: vpp-dev@lists.fd.io<mailto: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 (#10712): https://lists.fd.io/g/vpp-dev/message/10712 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Question about ip4(6)-glean node behavior and packet drops
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 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] -=-=-=-=-=-=-=-=-=-=-=-
[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 (#10710): https://lists.fd.io/g/vpp-dev/message/10710 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] -=-=-=-=-=-=-=-=-=-=-=-
