Cisco 2960S - Flow control

T

Tarrant64

Weaksauce
Joined
Mar 1, 2007
Messages
95
I've been digging into some performance issues on a LAN that has a couple of 2960s. The monitoring software I'm using has indicated a high amount of discarded outbound packets (up to 5%). The suggested resolutions were to enable flow control.

My question is does enabling flow control on all ports interrupt network traffic at all? this is a production network so I had already planned on doing it during off hours but also wanted to know if I should be prepared for any significant drop in traffic.

I'm thinking all I need to do is go into the switch,

priv exec mode
interface range fa0/1 - 48
flow control (not sure what options here, still reading up on that)

save my config.
 
Last edited:
why not plug a device into an unused port and test it?

Are you sure there isn't a duplex mismatch somewhere?
 
Check your 'show proc cpu sort' to ensure your switches aren't under heavy load. We had a bug in our switch stack about 6 months ago that caused normal usage to cause 70%+ loads and with a simple snmp check causing an addition 20%+ load, resulting in dropped frames.
 
I'm also a little skeptical. A 2960 isn't so old you should need to enable flow control. Flow control basically tells a device to stop sending data so that the switch port can catch up. If you're at the point where 5% of packets are being dropped because the interfaces can't keep up, something is probably wrong.

Sometimes small amounts of loss can happen due to very bursty traffic temporarily overwhelming an interface, particularly if it doesn't have a large input buffer. But I'd recommend following the advice of others here and looking for a source of the problem before attempting a random fix.
 
use ios command
?

You are having flow control issues on a 10/100 connection???

Anyways what you are looking for is ...

conf t
inter range fa0/0-24 or whatever size your switch is ...
flowcontrol recieve desired / off /on ---your choice
end
wr


Enable flow control on the other end, i.e. switch or PC etc.... and see what happens

You ought to wire shark your connection and see what exact traffic is being passed and then look for patterns...
 
Don't turn on flow control -- it probably won't fix anything. Flow control from the switch's perspective requires a pause frame to be sent from the connected host to the switch, which is essentially a white surrender flag. A host rarely does this unless something is really wrong with it or the NIC is awful. You can see this counter in "sh int" as an input/rx pause.

Instead, you're probably microbursting (this is financial industry slang, but is the same thing as Electro stated).

Run:
sh int | i proto|drops

You'll probably see drops all over the place that are very old ... so you should run "clear counters" and check later that day (good practice is to script clearing the counters in the morning so they're always current).

Then, isolate the problem and troubleshoot from there.
 
just2cool said:
Don't turn on flow control -- it probably won't fix anything. Flow control from the switch's perspective requires a pause frame to be sent from the connected host to the switch, which is essentially a white surrender flag. A host rarely does this unless something is really wrong with it or the NIC is awful. You can see this counter in "sh int" as an input/rx pause.

Instead, you're probably microbursting (this is financial industry slang, but is the same thing as Electro stated).

Run:
sh int | i proto|drops

You'll probably see drops all over the place that are very old ... so you should run "clear counters" and check later that day (good practice is to script clearing the counters in the morning so they're always current).

Then, isolate the problem and troubleshoot from there.
Click to expand...

^^^ This too....

However Just2cool I was just anwsering the OP's question on how to use the syntax. As far as troubleshooting... I use the layered approach ..

OP did you start with layer 1 before trying layer 2?

Do you have any CRC errors which usually mean a bad cable or connector or NIC. If you are having CRC errors you are going to get dropped frames too sometimes.

Can you post a ( show interface ) so we can see the counters here?
 
just2cool said:
Don't turn on flow control -- it probably won't fix anything. Flow control from the switch's perspective requires a pause frame to be sent from the connected host to the switch, which is essentially a white surrender flag. A host rarely does this unless something is really wrong with it or the NIC is awful. You can see this counter in "sh int" as an input/rx pause.

Instead, you're probably microbursting (this is financial industry slang, but is the same thing as Electro stated).

Run:
sh int | i proto|drops

You'll probably see drops all over the place that are very old ... so you should run "clear counters" and check later that day (good practice is to script clearing the counters in the morning so they're always current).

Then, isolate the problem and troubleshoot from there.
Click to expand...

lol, the term "microbursting" literally makes me cringe. While sometimes it legitimately happens (and this could certainly be one of those scenarios), it's one of those things that bad technicians use to explain away stuff they can't figure out, IME. Seriously, I wince whenever I hear someone in my office say that word to a customer. Half the time it's actually a queue-depth issue related to a bad QoS policy.

No knock against you j2c, I know you know your stuff, just an observation of mine.
 
try to use the test cable-diagnostics command in privileged EXEC mode.

Switch# test cable-diagnostics tdr interface g0/1
TDR test started on interface Gi0/1
A TDR test can take a few seconds to run on an interface
Use 'show cable-diagnostics tdr' to read the TDR results.

Switch# sh cable-diagnostics tdr int g0/1
TDR test last run on: January 01 00:09:09

Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi0/1 auto Pair A 20 +/- 4 meters N/A Open
Pair B 20 +/- 4 meters N/A Open
Pair C 21 +/- 4 meters N/A Open
Pair D 20 +/- 4 meters N/A Open
 
boylazer said:
try to use the test cable-diagnostics command in privileged EXEC mode.

Switch# test cable-diagnostics tdr interface g0/1
TDR test started on interface Gi0/1
A TDR test can take a few seconds to run on an interface
Use 'show cable-diagnostics tdr' to read the TDR results.

Switch# sh cable-diagnostics tdr int g0/1
TDR test last run on: January 01 00:09:09

Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi0/1 auto Pair A 20 +/- 4 meters N/A Open
Pair B 20 +/- 4 meters N/A Open
Pair C 21 +/- 4 meters N/A Open
Pair D 20 +/- 4 meters N/A Open
Click to expand...

It's unlikely it's a cabling issue if there are 10 ports having the same exact issue.
 
Electrofreak said:
lol, the term "microbursting" literally makes me cringe. While sometimes it legitimately happens (and this could certainly be one of those scenarios), it's one of those things that bad technicians use to explain away stuff they can't figure out, IME. Seriously, I wince whenever I hear someone in my office say that word to a customer. Half the time it's actually a queue-depth issue related to a bad QoS policy.

No knock against you j2c, I know you know your stuff, just an observation of mine.
Click to expand...

No offense taken. The financial industry is full of nutcases like myself. We actually look at packet rates down to the millisecond-by-millisecond level and export buffer levels from switches (5-10 microseconds granularity from the Nexus3K and the like). We've seen a 5 Gbps 1 milisecond burst of multicast traffic make a 6704 janus ASIC stall, and we're able to pin point what caused it. Also, QoS is disabled on trading networks -- everything is important. Run out of bandwidth? Then justify why and buy more. (Our corporate network has QoS)

Why? Well, if we lose one packet on our trading network or have it buffered for too long, we get notified immediately by other systems because that packet is a new price update / opportunity that we missed.

No normal environment would do this and the term "microburst" is probably applied too often for reasons like you mentioned.

This article explains microbursts on a nyse arcabook price feed (very lightweight compared to others)
http://www.corvil.com/Learn-More/Articles/Market-Data-Microbursts.aspx
 
You must log in or register to reply here.
Back
Top