Arp-cache and mac-address-table

[jbanker]

I am running into an issue where some users cannot reach the default gateway. Approx once a week users who log in to their workstations in the afternoon(12pm) cannot get out the gateway to the outside. They have no problem internally but cannot leave externally. Other users on the same module, subnet etc. can still get out. Whats weird is later in the day (approx 4pm) they can get out. It seems as other users log out the can get out.

It seems to me that this is an arp issue or a cache is getting full but I cannot figure this problem out. Here is what I have done: cleared the arp-cache (arp timeout is the default 4 hours), mac-address tables, cleared ip route, changed NICS on some pc's, checked port channels for errors. None of this has worked.

I am currently using 6500's switches as my core routers and 6500 as well for my access layer switches. Does anyone have any ideas?

[globalnettech]

Hello,

in order to fix your problem, you might want to try and add a static ARP entry for your default gateway (in global configuration mode):

arp 192.168.1.1 0002.0700.eb5f arpa

What IOS version(s) are you running on your 6500s ? I am asking because this could also be an IOS bug...

Regards,

GNT

[royalblues]

Check for any IP conflicts on the network.

Narayan

[jbanker]

Here is my IOS version on my core: IOS (tm) s72033_rp Software (s72033_rp-PK9SV-M), Version 12.2(17d)SXB10

My access layer 6500: s3223_rp Software (s3223_rp-ADVENTERPRISEK9_WAN-M), Version 12.2(18)SXF4, RELEASE SOFTWARE

[Kevin Dorrell]

Are you using NAT? I am guessing that you are using NAT, that it is not configured for overload, and you are running out of inside global addresses. But that is only a guess.

Kevin Dorrell

Luxembourg

[jbanker]

Thanks guys! We aren't using NAT for users, we all are using public IP's. I have not tried the static arp command for the gateway yet and I will update my IOS or atleast chek for bugs.

The same issue happened again this morning but I reset my edge interfaces and my VPN concentrator and got rid of the issue so I believe I have it down to one of the two. This issue started happening when we implemented a VPN concentrator and hardware client at a site. i didn't think it was an issue but it just might be.