Bouncing ports

Dr_Atomic

How do you find if a particular port is bouncing or not? It's been so long since I've checked it, I've forgotten.

networker050184

Look at the log.

Forsaken_GA

syslog servers are wonderful things. If you don't have one setup, you need to lobby management for some gear.

Dr_Atomic

networker050184 wrote: »

Look at the log.

Yeah, I checked that already. Nothing evident. I thought I may have missed something.

networker050184

If you have logging set up correctly it will log any port bounces. Something along the lines of "%LINK-3-UPDOWN" or similar for that interface.

Dr_Atomic

The situation is that a building here has multiple 2950 switches, all converging to a 3550 aggregate switch. They say the students are experiencing intermittent connectivity, but no one complained while I was here, and I'm pinging to the DG fine and not seeing anything evident in the show log outputs. I was told there might be a network loop somewhere causing an issue, but with so many switches and ports to look at, I'm not sure where I would find that in the mix.

tiersten

You not got any form of centralised logging? If you have that then it should make your task significantly easier than just pinging the gateway and hoping for the best.

Heero

log ports going up/down to a syslog server.

On a side note, I came into work today and had 70,000 new emails becuase a syslog server was configured to send out a notification every time a certain port when up/down. Yeah, it happened 70,000 times in the course of several hours on a Sunday. I was off monday through wednesday so i didnt get that nice little suprise until today.

creamy_stew

If you have low bandwidth loop and all switches still are alive (as it seems) Set up a cacti server to snmp poll all interfaces on the routers/switches concerned.

If there's a loop, you'll see at least a couple of ports constanly utilizing close to 100% of their bandwidth.

edit:
*How many MAC's are the students entitled to per room? 3-4 at the most should be sufficient. -> port security DO THIS!
*set "storm control" (interface command) 2 Mbit rising and 1 falling should be plenty. DO THIS! (start by 1 and 0.5)
*Are you running STP? If so, are you allowing potential devices behind student ports to participate in your STP? Look into rootguard, bpduguard and bpdufilter

edit2:
What is the physical layout of the network?
Where are the STP roots?
Are all your switches running RSTP/MST?

edit3: "R" added

mikej412

Dr_Atomic wrote: »

The situation is that a building here has multiple 2950 switches, all converging to a 3550 aggregate switch. They say the students are experiencing intermittent connectivity, but no one complained while I was here, and I'm pinging to the DG fine and not seeing anything evident in the show log outputs. I was told there might be a network loop somewhere causing an issue, but with so many switches and ports to look at, I'm not sure where I would find that in the mix.

Is this a continuation of this thread: http://www.techexams.net/forums/ccnp/58668-solving-network-ethernet-loop.html

Or an entirely different issue/problem?

Do all users/students have the intermittent connectivity issue at the same time? Are all users affected equally? Or are the only people complaining the ones running Pandora or Streaming movies over the network? Or is it isolated to just a group of users/students at one time (gamers or pron downloaders)?

Have you considered it could be an issue upstream from the 3550 if all users are affected at the same time.

Define intermittent. Does everyone lose total connectivity once a day for 5 minutes at the same time? Or do "new users" plugging into the network have problems connecting to the network in the first place? Or do users lose access after they've been connected when lots of other people jump on the network (like maybe at lunch time)?

Is everyone hardwired to the network? Or are there Wireless Access Points hooked up to the switches?

creamy_stew

mikej412 wrote: »

Have you considered it could be an issue upstream from the 3550 if all users are affected at the same time.

Um that's a good place to start

My edits are based purely on what may cause hard-to-track problems in a campus/residential ethernet broadband environment.

Though, I still feel setting up a cacti (shouldn't take more than half a day) is well worth it. That way you would see if outgoing traffic has increased/decreased significantly.

edit: This is turning out to be quite interesting.
*Gets popcorn*

edit2: bases -> based

Netwurk

creamy_stew wrote: »

This is turning out to be quite interesting.
*Gets popcorn*

I have a different word than interesting for having to follow an issue across two threads

mikej412

creamy_stew wrote: »

Um that's a good place to start

The actual topology would be a good place to start. Trunks or Etherchannels? Bandwidth on the uplinks? Actual model numbers. Clear statement and scope of the actual problem -- and the size of the network.

creamy_stew

mikej412 wrote: »

Clear statement and scope of the actual problem.

What are you? Management?

Netwurk

creamy_stew wrote: »

What are you? Management?

He's trying to get some solid info so we can help the guy

And a couple of us have asked the size of the network but it is a mystery known ownly by the OP

creamy_stew

Netwurk wrote: »

He's trying to get some solid info so we can help the guy

And a couple of us have asked the size of the network but it is a mystery known ownly by the OP

I was trying to be funny. Obvously, t3h lulz failed.

wolverene13

creamy_stew wrote: »

If you have low bandwidth loop and all switches still are alive (as it seems) Set up a cacti server to snmp poll all interfaces on the routers/switches concerned.

There's an easier way to do this:

"show interfaces" is all you really need. Then you look for ports that are maxed out. Those ports are where the traffic caused by the loop is. If you see maxed out input traffic on a trunk (meaning the loop traffic is coming into that device from somewhere else), go to the device on the other end of the trunk and issue a "show interfaces" command on that device. Keep doing this until you reach a device that only has maxed out output traffic on the trunks. This means that the culprit is directly connected to the device you are currently logged into because the loop traffic is originating on that device, so you then check traffic on access ports. Once you find a maxed out access port, you know that the device or host connected to it is what is causing the loop. "show log" will also help in this scenario. I lot of times you'll see MAC flapping messages in the logs on the device where the loop is occurring because the switch is seeing the same MAC on two different ports.

chmorin

creamy_stew wrote: »

I was trying to be funny. Obvously, t3h lulz failed.

Nah, I laughed =D

Anyway... Don't get discouraged by the attack of questions. We want and will help you but we do need a little more information about the environment for these questions.