Saturation on full duplex? 4

[jimfixit]

Okay, so traditional eithernet says that 40% utilization is pretty much saturation, mainly because at that point statistically speaking collisions pick up to the point that effencieny begins to fall of.

But collisions are a thing of the past where full duplex is concerned so, in a switched environment, what is the reaalistic utilization before you'd consider the 'network' to be saturated?

I mean, I realize it's going to depend on what's on the end of the connections...slow server etc, may cause retransmission but, in general what's a good 'starting point' to mark monitoring thresholds when you have a switched 10/100/1000 environment?

 

[jneiberger]

On a full duplex (point-to-point) link, I'd say an average utilization over 75-80% is a useful monitoring point. If you're averaging over that then you probably would benefit by upgrading to gigabit Ethernet, but that's just my opinion.

 

[vipergg]

We have seen when even full duplex links start getting between 90-100% the interface will start dropping random packets so like a previous user said a usuage of 80% should be looked at for upgrade to a gig interface or etherchanneling 2 or more fast interfaces together.

 

[jdeisenm]

Vipereg, what were the devices on each end the saturated link? Did you see the packet drops using a "sh int"?

 

[BuckWeet]

You need to take something else into consideration.. Your buffers and processing power.. When you're switching packets you need to make sure the devices you're using can really push the line rates of the interface.. Some routers/switches are oversubscribed.. For example a 3745 router.. It can have a gig interface, but no way could it ever push a gig of traffic, this comes down to processing power. Example of a switch if you have QoS configured, there are individual buffers for each traffic class.. If all traffic is being put into the default class, you might not get full line rate as the switch buffers are split up for different traffic types.. You might start dropping traffic.

there are many more scenarios to think about then just saying one answer = all..


BuckWeet

 

[vipergg]

The saturated link was a uplink between a 5509 and a 6509 at 100/full . We have snmp management and knew the link was very busy and you could ping between the 2 ends when it was very busy and watch it drop packets . There was no QOS or anything running , adding another 100/full in a etherchannel relieved that until we got a gig interface that we could use.

 

[wybnormal]

Keep in mind that on most decent network equipment, ICMP packets do not have the priority in a congested moment of time. So even if the TCP packets make it, the ICMP may not and make you think there is a problem. Buckweet (long time no speak) has the right of it with the suggestion of looking at the buffers. If the buffers are not dropping packets, there is not a congestion problem even if you are pushing the link hard. If you are dropping packets, make sure the cable plant is up to the task and then look at which buffers are dropping. I had a case once with a gig link that kept dropping traffic but it was not nearly congested. The issue was the few billion 128B packets that overwhelmed the buffers for the small packet type. The large buffers were hardly being used at all but a very noisy application managed to break the link by an out of the normal design flaw (according to them, feature)

If you really want to know what is happening and what to do, get a sniffer on the link. That is the only "for sure" way to see just what is really happening on the wire.


MikeS

http://www.packetattack.com

http://www.packetpress.net

Home of the book "Network Security Using Linux"

 

[voltron1011]

Good sniffers go a long way to diagnosing network problems, as well as preventative maintanance. The problem is trying to get management to buy off on these costly devices. Most of the time, management has the 'if ain't broke, don't fix it' mentality (I know mine does), and there's no way they'll drop that much dough for two network 'toys'.

 

[wybnormal]

Costly? Why do you say that? Ethereal or whatever they call it now, Wireshark I think, is free and works very well. A couple of the best features is that you can colorize the packet types and rebuild the streams.

Wildpackets has a sniffer that is around 2K which is a bargin given how much time and effort can be wasted on something like this.

I would not bother with "Sniffer" any more given the cost vs. other sniffers.

MikeS

http://www.packetattack.com

http://www.packetpress.net

Home of the book "Network Security Using Linux"

 

[voltron1011]

Sorry, I meant costly if you actually want something that'll do more than just ethernet (like fiber). Also, it's nice to have devices that'll also test the physical cable itself (like a FLUKE). My prior comments were actually based on management's lack of wanting to buy any kind of test/troubleshooting equipment at all.

 

[jdeisenm]

Where are you placing your capture tool(s)?
1) Inline (if so, what kind of tap?)
2) Port Monitor to local switchport
3) Port monitor to vlan
4) Hub (half duplex)
5) Other

Is anybody using a matrix switch?
Do you capture access port, trunks or vlans?

Personally, I've have an all cisco environment so usually I do a monitor session on a specific switch port with my laptop directly connected to the switch.

This isn't a survey but rather I'd like to hear some thought one's method and why it works.

I know there is no 1 right answer as the environment and available tools play a big part.

 

[wybnormal]

Inline is best with a passive tap. That way the bad guys even if they run a scan will never see you

I normally just run a monitor (span) port and flip between the VLANs as needed but you also need to remember that hooking to a switch in a chain of switches will not give you all the data even if you say "monitor VLAN 10". The span will not cross to the other switches unless you specifically configure VSPAN and/or RSPAN. Many so-called network engineers :::cough:: either forget this or do not know it. (I learned it the hard way more than a few years ago )

So picking WHERE to see your traffic depends on your ultimate GOAL. I need to see the WAN traffic most of the time so I have a monitor port set up to watch the one switch where the two WAN routers tie together for the corporate office. This gives me the most information on WAN traffic but it's useless for internet inbound/outbound traffic which is on a different VLAN. So there is second monitor port.

Also, if one can be clever, you can actually send the traffic back to your desk a varity of ways. Wireless bridge tied to the switch port and an AP at your desk or close enough to patch it in and configure it with a private SSID and some type of encryption if you are paranoid. A remote PC with VNC or Remote Desktop works also.

http://www.packetattack.com

http://www.packetpress.net

Home of the book "Network Security Using Linux"

 

[voltron1011]

That's some valuable info there, wybnormal.

 

[jdeisenm]

I happen to be tied to the same wire closet as my core switches so I have dedicated ports at my desk labeled with the switch/blade/interface. Then I make not of the interfaces of key devices (wan routers, trunks, key severs) and have monitor command ready to go in notepad like this. If possible, I use the same switch port on each switch for my destination.

#wan router core switch 1
no mon ses 1
mon ses 1 source g3/1
mon ses 1 dest g3/48

#internet router core switch 2
no mon ses 1
mon ses 1 s int g3/3
mon ses 1 d int g3/48