Nexus7000: %ARP-3-INVAL_HDR_PROT_TYPE

[andreaspechiny]

Hi,

since yesterday we got a couple of this logging-events:

Oct 23 08:09:01 bciscon7k01 : 2012 Oct 23 06:09:01 UTC: %ARP-3-INVAL_HDR_PROT_TYPE:  arp [4290]  Found incorrect protocol type in ARP header: 0x1000

Oct 23 08:09:47 bciscon7k01 : 2012 Oct 23 06:09:47 UTC: last message repeated 2 times

Oct 23 08:10:53 bciscon7k01 : 2012 Oct 23 06:10:53 UTC: last message repeated 3 times

Oct 23 08:12:04 bciscon7k01 : 2012 Oct 23 06:12:04 UTC: last message repeated 2 times

the system is working for 120 days without this event.

our System:

Hardware

cisco Nexus7000 C7009 (9 Slot) Chassis ("Supervisor module-1X")

Software

  BIOS:      version 3.22.0

  kickstart: version 6.0(4)

  system:    version 6.0(4)

I can post the configuration, if it is requested.

I haven't found an error description or a bug report. Can anybody explain this explain this event? And do we have to react?

Kind regards

andreas

[Arumugam Muthaiah · Accepted solution]

Hi Andreas,

This is kind of informational message about the receipt of such an ARP packet and has no impact on the switch operation. The Nexus 7K itself is not the cause of the message. It just reports the invalid arp packet being received by the Nexus 7000.

This issue is almost matching with known Bug CSCtt06010 - Fix the syslog string ARP-3-INVAL_HDR

Symptom:
Syslog seen with ARP-3-INVAL_HDR.

Conditions:

• The syslog prints the Proto type seen in the ARP payload in unsigned integer which confuses the customer. It should be shown in hexadecimal.
  
• Also it prints both Header type and Proto type to show one of the field is wrong though the other one is correct which misleads.
  

Workaround:
None.

This message indicates that a device in your network is sending ARP packets with a hardware type '6' (instead of 1 for Ethernet) which is incorrect. The protocol type is 2048 (0x800 in hex), which is correct, however the message is printed when either value is wrong.

• CSCtt06010 was filed to split the hardware and protocol types into separate messages to make these logs less confusing. It was implemented in 5.2(3).  In the output of 'show ip arp statistics'  you should see the 'Invalid protocol packet' counter incrementing due to this message.
  

Example:

Nexus7010# sh ip arp statistics

ARP packet statistics for context default
Sent:
Total 228979, Requests 114572, Replies 1, Requests on L2 0, Replies on L2 0,
Gratuitous 114406, Tunneled 0, Dropped 0
Send packet drops details:
    MBUF operation failed               : 0
Received:
Total 119759, Requests 1, Replies 162, Requests on L2 0, Replies on L2 0
Proxy arp 0, Local-Proxy arp 0, Tunneled 0, Dropped 119596
Received packet drops details:
    Appeared on a wrong interface       : 0
    Incorrect length                    : 0
    Invalid protocol packet             : 0

• In order to determine the address of the device sending those ARP packets with hardware type of 6, you can either use SPAN for CPU traffic or use the Ethanalyzer tool. Once the log message is seen, the ARP packets can be looked at in the CPU capture, to determine the source address.
  
• A basic capture of ARP packets using Ethanalyzer uses the following command
  

     #ethanalyzer local interface inband capture-filter arp display-filter "arp.proto.type == 0x1000" limit-captured-frames 1000000

Refer:

Cisco Nexus 7000 Series Architecture: Built-in Wireshark Capability for Network Visibility and Control

http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/ps9512/white_paper_c11-554444.html

Regards,

Aru

**** Please rate if the post is useful ***

[andreaspechiny]

Hi Aru,

thanks for your detailed answer. I'll try to capture the traffic and determine the address.

So on your answer was very useful and let me relieve stress.

Regards,

Andreas

[Arumugam Muthaiah]

Hi Andreas,

Thanks for your kind response. Its my pleasure to support

Regards,

Aru