Warning

 

Close

Confirm Action

Are you sure you wish to do this?

Confirm Cancel
Member Login
Site Notices
10/20/2017 1:01:18 AM
9/22/2017 12:11:25 AM
Posted: 8/3/2005 2:27:45 PM EDT
[Last Edit: 8/3/2005 2:29:53 PM EDT by macro]
All you CCIE / CCNP folks....

Ever deal with an issue where an MSFC would not age out an ARP cache entry?
I had a PC with a static address connected to a Cat4K cascaded behind a Cat6K, the MSFC cached the MAC/IP pair...then the same PC was set for DHCP (DHCP pool service running on the MSFC)...reboot the PC....it comes up with the DHCP address, MSFC builds an ARP cache entry for the new MAC/IP pair....but doesnt age out the old one.

Now the MSFC sees two IP's for one MAC...and the PC cant connect to anything past its own subnet (assuming that the layer 2 switch had a cam entry for the destination - if not it went to the router and had the same problem)

I tried to 'clear ip cache ip prefix'....did nothing....took the command but wouldnt clear the entry.
I noticed that there was a CEF entry in the RIB as well....tried to 'clear ip cef ip prefix'......same result....nothing.

I left it and went on to other things.....a few hours later I checked in on it and the bad ARP cache entry had aged out.

Anyone care to explain that one to me?
I am guessing bug....but I ran the bug toolkit against the IOS version and saw nothing that described those particular symptoms.

I plan to upgrade to a new rev (its old 12.1 code from before i worked here)
Hoping the new IOS makes the difference.
Link Posted: 8/4/2005 12:25:22 AM EDT
try re-initializing the TCP/IP stack? *shrug*
Link Posted: 8/4/2005 5:03:29 AM EDT
Definitely sounds like bug, or erratic behavior. If it's old code, go ahead and upgrade. If you don't need to upgrade, try a reload to kick it in the ass. The bad thing about Cisco these days (especially their VOIP stuff) is that it suffers from the Microsoft familiar "If it doesn't work, restart it and it will" syndrome.

Good luck!
Link Posted: 8/4/2005 5:26:25 AM EDT
If this is the same problem I'm talking about, cisco has done this for 15+ years on purpose. They claim it's for security purposes. In 1994 I wrote some software to detect when a server went down and had another take-over its IP address. Unfortunately (and we confirmed this with a very expensive call to cisco) cisco refused to replace the ARP entry for the old server like every other device I've ever seen that runs TCP/IP. You have to login to the route and type "clear arp" at the enable prompt. That might fix your problem. It's absolutely ridiculous that cisco has refused to fix this problem for over a decade and a half.z
Link Posted: 8/13/2005 4:30:19 PM EDT
You are going to have a default aging on your cam table for any arp entries. You can manually clear the ARP if required....

I know that on critical systems you can use a static cam table entry. MSFCs can be pretty cooky....the recommendation to upgrade the code is a wise one since Cisco TAC will more than likely tell you the same thing.
Link Posted: 9/4/2005 9:30:36 PM EDT
************** UPDATE ***************

So after a few isolated incidents with very interesting symptoms, it appeared that the 'ARP' issue was actually more of a MLS issue. I was in the process of testing the theory when (BIG DRAMATIC PAUSE)................the damn power went out, C6k's bounced to UPS power.....generator kicked in.......POWER SURGE IN UPS LINE CARD!!!!!!!!!!!!!!!............UPS down......generator starts acting flakey.....my C6K's start rebooting .... over and over and over again!

After about an hour and change, power was restored, the C6k's came up....and now, for about a week....not one issue!!!

Cisco is getting more and more like Microsoft....when in doubt and the symptoms dont match the configurations....REBOOT!
Top Top