cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1103
Views
15
Helpful
5
Replies

Switch 2960 strange behaviour

gaston05
Level 1
Level 1

I'm new at CISCO I'm starting my journey now, studying for CCNA.

In my work I have a network with a  switch 2960 that yesterday started to behave in a weird way.

Internally we lost a lots of packages, in some ports, and in other ones there where no problem.

 

As it was a critical switch and an important server was down, My first reaction after the firsts tests was to reboot-it. and then all went back to normal. I have a monitor on all ports with snmp, but there was no evident sings of flood neither saw  a augmentation of traffic  in any port, so i ruled  out a DoD attack or an evident flood from one or several servers.

 

So when it rebooted and suddenly the problem was "solved"  I wonder ¿What would be happening?  And I ask you folks,  ¿what test I should have done from the admin console ?

 

Sorry for this question with no troubleshoot at all

 

Thank you

Regards.

1 Accepted Solution

Accepted Solutions

Having a syslog server would be nice. But without a syslog server you could have before rebooting the switch done a show log, and copied the output so that you would have that information for review later. It is possible that the output of show interface might have had helpful information, were some interfaces experiencing dropped packets, were there overruns or collisions, was there perhaps some sign of duplex mismatch, etc. 

If it happened once and nothing changes then it is likely that it will happen again. If it does happen again, gather the data that you can, take a quick look and hope to spot something. If you need to reboot the switch to get things working again, you at least would have material for a more thorough examination after the fact.

HTH

Rick

View solution in original post

5 Replies 5

balaji.bandi
Hall of Fame
Hall of Fame

At this stage hard to say - If you have Logs it will give evedence what happend, since the switch rebooted you have lost all the logs, until you have any syslog server, you can go and look.

 

we also need high level information - where this switch connected in the part of your network.

 

Internally we lost a lots of packages

packets or packages ?

 

if the DoS attacck happends internal same broadcast domain, monitoring the Port usage will help, and get some alerts if the port utilisation go up than normal if you have any NMS, check any interface drops ?

 

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Thank you Balaji for your Answer. I understand that rebooting the switch was a mistake. And the importance of  the syslog that I do not have.

To give you mor details, It's a simple network, one interface connected to Internet via a router, the other interfaces directly connected to servers. No VLAN, no routing. Our gateway was connected to port gi0/1 and lets say that from the server connected to port gi0/5 i had no lost packets (ping test) to the default GW connected in but from the server connected in gi0/15 I did a ping to another server connected to port gi0/16 and had a loss of 22%, also had loss packets to the default GW from those servers.

 

I tested several servers, and the results were erratic, some of them has no problemas at all, and some others has enormous lost of packages  between servers and to the gateway,  that's why i decided to reboot the switch and then all went back to normal.

 

Thats why I was trouble to know what test should  I do before reboot it, looking at the syslog would give me an input I imagine that.

 

Thank you very much

 

Regards

 

 

Having a syslog server would be nice. But without a syslog server you could have before rebooting the switch done a show log, and copied the output so that you would have that information for review later. It is possible that the output of show interface might have had helpful information, were some interfaces experiencing dropped packets, were there overruns or collisions, was there perhaps some sign of duplex mismatch, etc. 

If it happened once and nothing changes then it is likely that it will happen again. If it does happen again, gather the data that you can, take a quick look and hope to spot something. If you need to reboot the switch to get things working again, you at least would have material for a more thorough examination after the fact.

HTH

Rick

I would like to respond to a comment from the original poster: " I understand that rebooting the switch was a mistake." I do not necessarily agree that rebooting the switch was a mistake. Sometimes, especially when an important part of the network is down and you are not sure what the issue is, it might be important to get the network back up. It is nice to be able to do some troubleshooting or to gather some information for later examination. But at some point it is important to just get the network back up. And if you are not sure what to look for then I would suggest that recovery is more important than trying to figure out what to look for. Now I think you are better prepared for the next time. But I think your decision to just reboot was appropriate at the time you made it.

I am glad that our suggestions have been helpful. Thank you for marking this question as solved. This will help other participants in the community to identify discussions which have helpful information. This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.

 

HTH

Rick

marioiram
Level 1
Level 1

Just like Balaji mentioned at this point without logs or more information is really hard to say what could have been the issue, something I can think of is always make sure devices are grounded and plugged into stable power connections.