Cisco Catalyst 2960-x takes long time to communicate with users

[rn04]

Hello,

I have a Cisco Catalyst 2960-x switch that is connected to up to 10 users. Most of these users change over time, meaning that we connect and disconnect different users very regularly.

Every time a new user is connected, it takes about 2 minutes to start communicating with it. This is very annoying as the set up requires swapping users very frequently. We have a similar but more simplistic setup where we use a $50 Linksys switch and the connection happens within ~15 seconds. 

Is there a specific setting I should be looking at? What information should I provide so you guys can help me troubleshoot this? 

Thanks in advance.

[Richard Burts]

We do not yet know enough to give you good advice about your issue. Is this 2960 the only device in your network? Or are there other routers and/or switches in the network? (if there is more than one device we will need to figure whether the delay is really in the 2960 or whether it might be in something else)

When you say you change users, is that a new user on the same machine? Or a new user on a machine that has not been on the network? When you change users does the IP address stay the same or does the IP address change? Are the IP addresses hard coded or do the machines get assigned an IP address using DHCP?

What do you mean takes two minutes to start communicating? Does that mean two minutes to get assigned an IP address? Or two minutes to get authenticated? Or two minutes to get a user prompt?

HTH

Rick

[rn04]

Thanks for your prompt response. Sorry, I was vague. Let me start over and describe my set up.

We have one switch (2960-x) which has IP addresses hardcoded and assigned to each port. To this switch, we have two PCs connected at all times to the same two ports, thus same two IP addresses. The other ports have also assigned fixed IP addresses, but the machines we connect to those ports are basically a circuit board with a LAN network adapter; these machines change frequently. Think about the whole system as a debug station, where we troubleshoot dozens of machines on daily basis.

So, we connect a machine and takes up to 2 minutes to establish communication; If I ping the IP address right after I connected the machine to the router, it will timeout, only after ~two minutes it returns the packages. Under the previous configuration, we had a cheap router that assigned a random IP within a range of IP set in a DHCP table.

It's being like this since day 1. It also happens if I connect a laptop for example; I'd have to wait around to minutes to connect to the network. It happens on every port and it's independent of the number of machines connected to the router. I hope this makes more sense now.    

[Richard Burts]

I am a little puzzled how you assign an IP address to a port on the 2960 switch. Not knowing how that is done makes it hard to evaluate whether this may contribute to the delay.  

It does help to know that your 2 minute delay is to begin responding to pings. In that case I can think of two things that may be at work here.

1) (less likely) it may take some time for the layer 2 mac address table to recognize that a new device is connected and to correctly update the mac address table.

2) (more likely) there is at least one (and potentially more than one) arp table that associates the IP address with a mac address. It may take some time for the entry in that table to age out and for the new mac address to be associated with the IP in the arp table.

HTH

Rick

[rn04]

I'm attaching the config file we used to assign the IP addresses.

[Richard Burts]

Thank you for posting the config which was helpful. Now I do see how they tie the IP address to the interface in DHCP using the interface name as the client ID. This does add one more element which may cause/contribute to the delay.

At this point I believe that we can pretty much dismiss the updating of the mac address table as a cause of the delay. So I would suggest that if you want to investigate further that you concentrate of processing of DHCP and of ARP as the factors that are causing the delay. The DHCP is local to the switch and if you want to investigate there are some debugs you could use to see how long it takes after disconnecting one device and connecting another device for DHCP to react and to assign the IP to the new device. For arp there is an arp table maintained by the switch and there might be an arp table maintained by your testing device(s). So it is not necessarily local to the switch. On the switch there are debugs for arp which could show how long it takes for arp to change and to recognize the new device/new mac associated with the IP address.

HTH

Rick

[Richard Burts]

I have two more thoughts about this.

1) there is another factor that may contribute to the delay. Each interface is configured as a trunk and is running spanning tree as point to point. So there will be spanning tree activity for each vlan on each interface..When you change a device there are several things that need to happen in spanning tree. Spanning tree must detect that a device disconnected (is that interface going down?), must detect that a new device is connected (is this interface coming up?) and must process for spanning tree convergence. This could certainly contribute to the delay. 

2) you might get some insight into what is going on from the syslog generated by the switch. Make sure that logging buffered is enabled (logging buffered debug), change a device, then look in the logs to see what messages were generated (show logging).

HTH

Rick