cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2109
Views
0
Helpful
2
Replies

ethanalyzer capturing ARPs on N9K control-plane

stuartkendrick
Level 1
Level 1

I want to capture ARPs on the Control Plane of Nexus 93180YC-EX

 

mdf-a-rtr# ethanalyzer local interface inband capture-filter arp limit-captured-frames 500000 capture-ring-buffer files 64 write usb1:2019-11-08/mdf-a-rtr-inband-arps.pcap

mdf-b-rtr# ethanalyzer local interface inband capture-filter arp limit-captured-frames 500000 capture-ring-buffer files 64 write usb1:2019-11-08/mdf-b-rtr-inband-arps.pcap

 

These particular N9K function as the vPC/HSRP pair servicing the access-layer:  Stacks of Cat2960X.  ~30 VLANs total. The Cat2960X in turn support ~2000 hosts -- in fact, their ARP tables contain ~2000 entries typically

 

Ostensibly, this works -- I can look at the pcaps and see ARP Requests / Replies. However, on closer inspection, ~80% of the ARP activity I see is limited to a single VLAN (VLAN13).  As an example, I logged into a handful of hosts on various VLANs and deleted their ARP entries for the default router.  This of course kicks off an immediate ARP Request from the host for the default router.  I would predict that I would have seen each of these ARP Requests / Replies in the pcaps accumulating on the N9K.  Instead, I only saw the ARP Request / Reply for the test station on VLAN13

i.e. filtering the pcaps as follows:

arp.src.proto_ipv4 == 10.82.13.13 or arp.dst.proto_ipv4 == 10.82.13.13 or arp.src.proto_ipv4 == 10.82.24.98 or arp.dst.proto_ipv4 == 10.82.24.98 or arp.src.proto_ipv4 == 10.82.24.132 or arp.dst.proto_ipv4 == 10.82.24.132 or arp.src.proto_ipv4 == 10.82.72.11 or arp.dst.proto_ipv4 == 10.82.72.11 or arp.src.proto_ipv4 == 10.82.74.100 or arp.dst.proto_ipv4 == 10.82.74.100 shows only the ARP Request / Reply for 10.82.13.13 ARPing for 10.82.13.1 (the default gateway) ... none of the other exchanges show up

 

I would have predicted that I would see ARP exchanges for all (5) of these test stations

 

From https://tools.cisco.com/security/center/resources/copp_best_practices , I would have predicted that *all* ARPs pass through the CPU and thus would be captured by ethanalyzer

Control plane packets – Network device generated or received packets that are used for the creation and operation of the network itself. From the perspective of the network device, control plane packets always have a receive destination IP address and are handled by the CPU in the network device route processor. Examples include protocols such as ARP, BGP, OSPF, and other protocols that glue the network together.

 

Would anyone have insights to offer?  Are ARPs sometimes handled by some pathway which dodges ethanalyzer?

 

--sk

2 Replies 2

stuartkendrick
Level 1
Level 1

Why do I want capture ARPs off the Control-Plane?  Because COPP is dropping ARPs ... and I want to identify which host(s) are pushing COPP to do this

 

mdf-a-rtr# show policy-map interface control-plane module 1 class aicustom-copp-class-normal
Control Plane

Service-policy input: aicustom-copp-policy-strict

class-map aicustom-copp-class-normal (match-any)
match access-group name aicustom-copp-acl-mac-dot1x
match protocol arp
set cos 1
threshold: 900, level: 5
police cir 1400 kbps , bc 32000 bytes
module 1 :
transmitted 8298473324 bytes;
dropped 12900480 bytes;

mdf-a-rtr#

 

--sk

 

 

As I dig into this, I find that ethanalyzer captures ARPs fine if I don't filter ... it is only once I am filtering, with "capture-filter arp", that it starts dropping most ARPs.  This surprises me.  Has anyone else encountered this contrast:  ethanalyzer starts losing frames when asked to filter?

 

--sk

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: