[c-nsp] nexus 7K COPP ARP traffic?

[schilling]

sorry to resurrect this thread since this is still not very clear to me.

If one of default system-defined CoPP policy is applied to control-plane.
    If there is svi 100 on a nexus7k, there are 2 end hosts connected to 2
ports on a module (for example F3).
         If host 1 sends 1000 packets of arp for host 2's IP in one second,
and CoPP for arp is set to only permit 10 arp packets per second, it's
understood that there will be only 10 arp request reach the CPU during that
1 second. However, will host 2 receive all 1000 arp packets in that one
second or only receive 10 arp request in that one second?
         What if host 1 sends 1000 packets of arp for svi 100 ip address
i.e default gateway? Will host 2 receive 1000 or 10 arp request in that one
second?

    What if there is no svi100 on the nexus7k and nexus7k is just layer 2
switch for vlan 100? Will host 2 receive all 1000 arp packets in that one
second or only receive 10 arp request in that one second?




The following are from Nexus7k 6.x unicast routing guide:

The default system-defined CoPP policy rate limits ARP broadcast packets
bound for the supervisor module. The default system-defined CoPP policy
prevents an ARP broadcast storm from affecting the control plane traffic
but does not affect bridged packets.


http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/unicast/configuration/guide/b-7k-Cisco-Nexus-7000-Series-NX-OS-Unicast-Routing-Configuration-Guide-Release-6x/n7k_unicast_config_ipv4.html#concept_F7B72665C1F84709B2A25E5FC2DD07EF

Address Resolution Protocol

Networking devices and Layer 3 switches use Address Resolution Protocol
(ARP) to map IP (network layer) addresses to (Media Access Control
[MAC]-layer) addresses to enable IP packets to be sent across networks.
Before a device sends a packet to another device, it looks in its own ARP
cache to see if there is a MAC address and corresponding IP address for the
destination device. If there is no entry, the source device sends a
broadcast message to every device on the network.

Each device compares the IP address to its own. Only the device with the
matching IP address replies to the device that sends the data with a packet
that contains the MAC address for the device. The source device adds the
destination device MAC address to its ARP table for future reference,
creates a data-link header and trailer that encapsulates the packet, and
proceeds to transfer the data.
Figure 1. ARP Process



When the destination device lies on a remote network that is beyond another
device, the process is the same except that the device that sends the data
sends an ARP request for the MAC address of the default gateway. After the
address is resolved and the default gateway receives the packet, the
default gateway broadcasts the destination IP address over the networks
connected to it. The device on the destination device network uses ARP to
obtain the MAC address of the destination device and delivers the packet.
ARP is enabled by default.

The default system-defined CoPP policy rate limits ARP broadcast packets
bound for the supervisor module. The default system-defined CoPP policy
prevents an ARP broadcast storm from affecting the control plane traffic
but does not affect bridged packets.
Best,

Schilling

On Mon, Apr 2, 2012 at 5:36 PM, Tóth András <diosbejgli at gmail.com> wrote:

> Hi Jeffrey,
>
> All ARP requests which are broadcasts arriving in a vlan where an SVI
> is up would be punted to CPU and throttled by CoPP and HW
> rate-limiters. If there are no L3 interfaces, packets should not go to
> CPU.
>
> Perhaps they came from the management port, where CoPP is not applied.
> It's difficult to tell post-mortem, we'd need to see which process was
> using the CPU and confirm the type and source of packets hitting the
> CPU with an inband SPAN capture or an ethanalyzer capture.
>
> Best regards,
> Andras
>
>
> On Mon, Mar 26, 2012 at 5:54 PM, Jeffrey G. Fitzwater
> <jfitz at princeton.edu> wrote:
> >
> > I am trying to understand if ALL ARP (requests ) packets that a nexus 7K
> sees, need to be punted to the CPU and therefor managed by COPP policies /
> rate-limits?
> >
> > Over the weekend we had a data loop that cooked the CPU and we are
> trying to understand what packets that were control plane processed, caused
> the CPU load.
> >
> > We currently have a Nexus 7k running 5.2.1, that only has L2 interfaces,
> other than the management VRF port.   I would think that the CPU would
> never have to process any ARP requests for non-management traffic since it
> does not have any L3 interfaces.
> >
> >
> > My understanding is that other sites have had similar issues and
> changing the COPP profile stopped  the CPU form being saturated during this
> kind of event.
> >
> > The COPP profile can be ( lenient, moderate, strict ).
> >
> >
> > Thanks in advance for any info on this issue.
> >
> >
> >
> > Jeff Fitzwater
> > OIT Netwrok Systems
> > Princeton University
> >
> >
> >
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>