.
Are you connecting to the switch via the console port(and if so, are you using the null modem cable provided, or another solution), or is this a telnet/ssh connection that you’re establishing to manage the switch? If you are connecting via telnet, do we see the same results if we use the console port?
- Separate Management vlan.
Commonly in L2 Switches, assigning an IP address to a vlan makes it manageable via that vlan. The switch does this by putting the CPU in the vlan. If that vlan has lots of BC/MC traffic, the switch CPU is going to be hit with that traffic and it will slow down any management. If VLAN 1 is the Management VLAN, and has an IP address assigned, the CPU will see vlan 1 Broadcast traffic only. To reduce the BC/MC traffic to the CPU, you can use a separate management vlan, which is used only to manage the switch and does not carry general network traffic.
- CoS Queue 1
The symptoms appear to be that administration via http/telnet takes too long and some packets against that interface are lost from a client directly connected to the switch.
The MC data and UC data both go through the same COS Q to access the CPU – unregistered MC data will flood to all ports in the VLAN of which the CPU port is a member, and since the COS Q is rate limited and FIFO’d, the percentage chance that a UC pkt getting to the CPU in the environment of lot’s of MC data, it very small. Registered MC, doesn’t go to the CPU port.
- CPU Utilization.
If the console does not respond because the router CPU utilization is high, it is important to find and correct the cause of the high CPU utilization. For example, if process-switched IP traffic causes problems, then this is reflected in the “IP Input” process in the output from the show processes cpu command. In this situation, it is important to collect the output from show interfaces, show interfaces stat, and possibly show processes to further diagnose the problem. To fix the problem, you would need to reduce the amount of IP traffic that is process switched.
- Memory Allocation Failure:
Either the switch has used all available memory, or the memory has been fragmented into such small pieces that the switch cannot find a usable available block. More on this in a separate post.
- Console Prompt slow.
-
- Incorrect settings in Hyperterminal – If Flow Control is not set to none, you will typically get output, but no input. Correct Settings in HT are 9600, 8, N, 1, no flow control.
- Wrong serial cable – If a straight-through serial cable is used rather than a null modem cable, you will get output, but no input.
- Emulation problems within Hyperterminal – use Tera Term.
- Make sure the Scroll Lock is off.
- Traffic does not Pass, Console Unresponsive:
If traffic no longer passes through the router and the console is unresponsive, there is probably a problem with the system. Generally this means that the router is caught in a continuous loop or stuck at a function. This is almost always caused by a bug in the software.
Obtain a stack trace from ROM Monitor. Obtaining stack traces during a problem makes it possible to determine where in the code the router is looping or stuck.
- Traffic does not Pass, Console Responsive:
Traffic problems occur when the console remains responsive but traffic does not pass through the switch/router. information can be collected from the switch/router through the console port.
Possible Causes
-
-
- Routing issue – Changes in the network topology or in the configuration of some routers could have affected the routing tables.
- High CPU Utilization – Issue the show process cpu command. If the CPU is above 95%, the performance of the router can be affected, and packets can be delayed or dropped.
- Interface down – One of the router interfaces can be down. There are multiple events that could cause this.
- Wedged interfaces – This is a particular case of buffer leaks that causes the input queue of an interface to fill up to the point where it can no longer accept packets. Reload the router.
-
.
Hasan Mansur 