1. Home
  2. Cisco Systems
  3. %IP-4-ZERO_ADDR: Zero MAC address for xxx.yyy.zzz.66 in ARP cache

%IP-4-ZERO_ADDR: Zero MAC address for xxx.yyy.zzz.66 in ARP cache

My 3550 switch is producing a strange error in the logs; every few minutes I see:

%IP-4-ZERO_ADDR: Zero MAC address for xxx.yyy.zzz.66 in ARP cache

'sh ver' has a corresponding indication of the issue:

Invalid parameter block -- no serial number or mac address available.

and sure enough, 'sh arp' produces:

Internet xxx.yyy.zzz.66 - 0000.0000.0000 ARPA Vlan1

xxx.yyy.zzz.66 is the management address I have assigned to the switch under interface vlan 1. Cisco documentation says this error should be reported to TAC (but we don't have an account). It seems to be a problem related to a missing or corrupted file stored in non-volitile memory. It causes the switch to be unreachable at this address.

If I console to the switch and ping another address on the subnet, the switch becomes reachable for awhile but eventually becomes unreachable again. The arp entry remains the same. Also the problem does not affect reachability to other devices in the management subnet - only its own address.

Here are the pertinent configuration sections:

interface Vlan1 ip address xxx.yyyy.zzzz.66 255.255.255.224

ip default-gateway xxx.yyy.zzz.65

I'm sure this issue has a simple resolution, but I can't find any information! I hope somone out there has seen this before...

Regards,

Tom

Reply to
funkknob
Loading thread data ...

I know of no way to fix this in general. It may be that this platform has an unusual NVRAM that is user accessible as a file in the flash.

You could try manually assigning a mac as a workaround.

int vlan 1 mac-add xxxx.xxxx.xxxx

Reply to
Bod43

Hi Bod,

I wish I could do that...

Switch#conf t Enter configuration commands, one per line. End with CNTL/Z. Switch(config)#int vlan 1 Switch(config-if)#mac? macro

It doesn't seem to be an option. Running the standard image (can't figure out how to determine if this switch is licensed for the enhanced image).

Regards,

Tom

snipped-for-privacy@hotmail.co.uk wrote:

Reply to
funkknob

C2950 #sh flash

Directory of flash:/

2 -rwx 2490607 Mar 01 1993 00:03:30 c2950-i6q4l2-mz.121-9.EA1.bin 3 -rwx 269 Jan 01 1970 00:01:03 env_vars

#more env_vars MAC_ADDR=00:09:nn:nn:nn:nn MODEL_NUM=WS-C2950-24 MODEL_REVISION_NUM=E0 MOTHERBOARD_ASSEMBLY_NUM=73-nnnn-10 MOTHERBOARD_REVISION_NUM=B0 MOTHERBOARD_SERIAL_NUM=FOC06nnnAnn POWER_SUPPLY_PART_NUM=34-0nnn-01 POWER_SUPPLY_SERIAL_NUM=PHI06nnnnnW SYSTEM_SERIAL_NUM=FOCnnnnWnFn

Where n=digit.

You never know???

I don't know if we have a 3550 anywhere or not.

Create the file and tftp it on. The file is a Unix text file with a new-line at the end of the last line.

If you don't know how to create a unix text file try a windows one first I guess.

I have seen windows format text files work for configs that are tftped to routers.

Reply to
Bod43

Thanks for the info. I have another 3550 here (which we'll call the 'good' switch) and I have discovered that it seems to use the file system_env_vars to store this data. On the problem switch, this file appears to be corrupted:

Switch#more flash:system_env_vars

00000000: 424F4F54 3D666C61 73683A63 33353530 BOOT =fla sh:c 3550 00000010: 2D697073 65727669 6365736B 392D6D7A -ips ervi cesk 9-mz 00000020: 2E313232 2D32352E 53454532 2F633335 .122 -25. SEE2 /c35 00000030: 35302D69 70736572 76696365 736B392D 50-i pser vice sk9- 00000040: 6D7A2E31 32322D32 352E5345 45322E62 mz.1 22-2 5.SE E2.b 00000050: 696E0AXX XXXXXXXX XXXXXXXX XXXXXXXX in.X XXXX XXXX XXX

Whereas on the good switch, it follows a similar format to your 2950:

Switch#more flash:system_env_vars BOOT=flash:c3550-ipbase-mz.122-25.SEB4/c3550-ipbase-mz.122-25.SEB4.bin MAC_ADDR=00:17:5A:xx:yy:zz MODEL_NUM=WS-C3550-24PWR-SMI MODEL_REVISION_NUM=L0 MOTHERBOARD_ASSEMBLY_NUM=73-xxxx-yy MOTHERBOARD_REVISION_NUM=A0 MOTHERBOARD_SERIAL_NUM=CATxxxxxxxx POWER_SUPPLY_PART_NUM=341-0029-04 POWER_SUPPLY_SERIAL_NUM=LITxxxxxx SYSTEM_SERIAL_NUM=CATxxxxxxx

I have deleted this file from the good switch and after a reboot it seems to still have access to this information and behaves normally. I see all the information output from 'sh ver'. In other words, the file seems unnecessary.

I have now deleted the system_env_vars file from the problem switch and have scheduled a reboot during our maintenance window tonight. I believe this will fix the problem - I'll post again tomorrow with the result.

Regards,

Tom

Reply to
mr.tom.warren

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.