cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1769
Views
5
Helpful
8
Replies

Link Congestion

d_ferraro
Level 1
Level 1

At what point would a link become "congested". We have mrtg running and we can see all the statistics, but at what point should we consider adding an additional link(aggregate ports)? Is there a certain percentage when congestion gets high enough to degrade performance and/or drop packets?

thanks in advance!

8 Replies 8

Hi

Link Utilization needs to be carefully monitored when the link bandwidth is limited. If the utilization of links exceeds a X-X %, a link congestion trigger should be reported. ( X number is depend on you , it should be 60% as per me)

If your link is always been utilized more that 75 % to 85 % then you should plan for link upgradation or additional link . ( Depending on you company budget )

Regards

Chetan Kumar

Thanks for your response.

Do you know of any Cisco documentation with what there suggestions would be?

"If your link is always been utilized more that 75 % to 85 % then you should plan for link upgradation or additional link ."

Why 75 - 85%? What are you basing this off? I am with you, 75 - 85% sounds like a good number, but I am looking for specific information on why this is a target number.

When thinking about it, if a link stayed steady at 99% utilization and I guaranteed it would never hit 100% would I ever need to add additional links? Is there a reason I would not want to have a high utilization port as long as it never hits 100%?

I manage 700 access switches and about 25 routed distribution switches. I constantly have admins telling me that they need link aggregation. After I show them the stats that show they are using 50% of the link, then they come back and say that 35% is congested and another link should be added.

I need hard facts so that I can speak with absolute certenty when speaking to these people. I have been going with if you hit 80% utilization then I will add another link, but that is not based on any facts, that is just what sounds good to me.

Hi

1]  Why 75 - 85%? What are you basing this off? I am with you, 75 - 85% sounds like a good number, but I am looking for specific information on why this is a target number.

---> The Reasone that i told 75 % to 85 % because when you utilization can reach 85 % then you have only 15 % in buffer and that can be utilize any time & cause link congestion, If reaching 85% was never planned .

2] When thinking about it, if a link stayed steady at 99% utilization and I guaranteed it would never hit 100% would I ever need to add additional links? Is there a reason I would not want to have a high utilization port as long as it never hits 100%?

----> Number are never steady , it will vary time to time( In case of 99 %). If you think that you will never reach 100 % and sure about that , So no need to add an link .

Adding an link will take you more Cost , So definelty I think that any document can't give you perfect number, which you can make presentation for you Management for approval.

Monitoring 24*7 gives you your report & on that basis you can take you decision .

Regards

Chetan Kumar

You probably won't find anything specific at Cisco regarding this topic.

But consider the behavior of TCP/IP window as utilization increases.

Generally, things will start really slowing down @ 60 to 70 %, BUT

applications all vary, tcp configs all vary, its a moving target.

keep in mind your links are full duplex, you need to look at both sides, (Tx & Rx).

Where is the congestion occuring that the admins are complaining about?

you see how your devices are doing at the inerface level by checking for drops, etc..

what evidence do they have ? We in networking tend to be judged guilty until proven innocent.

d_ferraro
Level 1
Level 1

--->VMiller,

so our team is seeing this on one of the links:

So looking at the "max" stats, I would have said that the switch only got up to 59% utilization, and your suggesting that I need to combine "In" and "Out" and this link had reached 100% utilization at one point?

Correct. You had a spike Wednesday that hit 58.9 percent of the available output bandwidth. With full duplex, you have the thoretical maximum available in both directions. Overall your utilization is fairly low. I'd be curious on what triggered the spike.

As far as users saying that things are running slow, there is nothing to suggest that adding bandwidth would change anything. If at all possible, you need to capture some of the request-response behavior between the clients and their target systemss

"With full duplex,  you have the thoretical maximum available in both directions"

wouldnt I have 1000Mb in both directions via full duplex?

Also I have MRTG also polling stats on the vlan that the suspected congestion is accuring. So from the physical interface stats it appears that congestion is not accuring, but when I look at the stats on interface vlan136 I see this:

ifName:Vl136
Max Speed:1000.0  Mbits/s

router1#sho int vlan136

Vlan136 is up, line protocol is up
  Hardware is EtherSVI, address is 0022.0dc0.4000 (bia 0022.0dc0.4000)
  Internet address is xx.xx.xx.xx/24
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 46/255, rxload 88/255

So that leads me to another question. Is there a limit on the amount of traffic that can be sent across a single vlan interface? Is there a default vlan speed that is allowed, if so what is it? Is there a way to increase it if so?

Yes in theory the link speed is equal in both directions.

Don't confuse a vlan with its underlying layer 1 & 2. Vlans are logical constructs.

SInce it is an "interface"  you get a bandwidth by default.

Any limits to traffic would probably show themselves as drops or que buildup on the physical interface first.

To get a better measure of whats going on, monitor the physical interface that is associated with the VLAN

in question. 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: