We have been having an issue with our Catalyst 3560 switch running IOS 12.2(37) where the devices plugged into it can run a continuous ping without issue within the same VLAN fine but when we disconnect the CSU connection from the router the switch stops sending ICMP requests to the devices only after 4 hrs. The result is the devices start to get a "request timeout" message where they were working just fine for 3 hr and 59 minutes. It seems like this issue happens right at the 4 hr mark and you can set your watch to it.
Can someone tell me what part of the switch config could be causing this to happen? I am new to Networking so they tasked me with trying to figure out this problem.
Part of the config that I think look suspicious is the "mac-address-table aging-time" settings. I have taken part of the config out to share with you and want to know if this is a problem or not.
mac-address-table aging-time 0
mac-address-table aging-time 0 vlan 1
mac-address-table aging-time 0 vlan 2
mac-address-table aging-time 0 vlan 3
Any help would be appreciated.
Well first what are you pinging? Another PC within the same switch on the same VLAN?
Second, are you using DHCP? If you have a 4 hour expiration on your DHCP leases and you drop connectivity to the DHCP server, you will lose your IP address.
The two devices I am working with are Windows pc's that have static IP addresses. We do have DHCP setup for other devices off the switch in the same that same VLAN and I could understand the DHCP removing the ip address after 4 hrs for those devices but if the two devices I am working with are static why would it still fail?
Just as a test I took the two devices and put them on a hub and they were able to ping for 24 hrs straight so I know its not the TCP/IP stack on the devices or the NICs.
>> router the switch stops sending ICMP requests to the devices only after 4 hrs
4 hours is exactly the ARP entry timeout default value in a Cisco router, until a destination MAC address to be used to send the ICMP packet is present in the ARP table the device will send the packet.
As the ARP entry expires and it cannot be renewed the device stops to send ICMP requests
Hope to help
Thanks for that bit of insight. I would like to do some testing in the lab. Do you have some config recommendations that I could implement that would keep the ARP entry table from flushing after 4 hrs?
Are you using port security on your interfaces?
Things I would recommend looking at is first the MAC table on the switch to make sure it has the MAC addresses of both switches in its table still. Because the devices are on the same VLAN, they dont need a default gateway to ping each other so there should not be anything on the router thats the issue.
Is your switch running as your router? If the switch trunks to your router and the router is your default gateway, then your ARP table will be on the router and not your switch.
Because you have both PCs plugged into the same switch on the same VLAN with static addresses, you should not have issues with layer three because you are not routing. You will want to be looking at your mac-address table by doing sh mac-address. It doesn't hurt to perform a sh ip arp on the router to make sure the router is seeing the PC's. I would also try pinging the PC's from the router to see if you can ping them.
It seems that some more testing has revealed that the there is a delay of 150 on the trunks (orange) between sw1 and sw2 on the router (rtr) config that connects the switches (see picture). The ones labled PC4 and PC5 have static so shoudl be able to ping all day long but like I said after 4 hrs it fails and does not make sense since this is local traffic within the switch unless there is something that is causing them to go to the router instead of keeping that traffic local. But then it does not explain why it is stops working when the link is cut with the CSU on the router (yellow).
Funny part to all this is that PC1 and PC2 can still ping each other after 4 hrs and they are on the same VLAN as PC4 and PC5. PC1 and PC2 are special OS that work using BOOTP so I don't know how that plays into this.
what was the outcome here ?It seems Giuseppe had the right information with the default flush on the ARP?
Just curious to know ---
We spent some time in the lab going over the issue and came to find out from the configs that a new NAC system was running against the ports that were giving us the problem. Seems that another group is testing NAC solution and that is what caused the issue.
Thanks for everyones assistance.