cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
1969
Views
0
Helpful
5
Replies
haidar_alm
Beginner

Link Overutilization

Hello,

Our Desktop team is planning to upgrade 40sh PCs remotely over a 10 MB link. I argued that this may cause issues since the link is only 10 MB considering the amount of PCs they are trying to upgrade.

They will still go ahead with it since this was approved by a manager, the argument was that this will be done after hours and we will see how they will get on in the morning!

I'm planning to clear the counters so that I can check first thing in the morning if there were any errors, ....etc.

I'm just wondering what will happen when a link is over-utilized and cannot take the load? I assume that packets will be dropped and connectivity issues will occur?

Also, any other useful commands that may help other than the sh int?

Would like to get your opinion on this plz.

Many thanks,

1 ACCEPTED SOLUTION

Accepted Solutions
Calin C.
Contributor

Hello,

If you have no QoS strategy there, regarding packet congestion, packet prioritization or shaping, when the link is full then the packets will be delivered by FIFO method (first-in-first-out). The rest of the packets which cannot be delivered right away, will be queued. When queue is full, the packet will be dropped (tail dropping effect). This is the technical explanation.

What your Desktop team will see is that they will lose connection to their remote systems (PC) or encounter delay in command processing. You also will have problems reaching your remote network devices if you have any.

As a suggestions, why they don't split these 40 PCs over multiple days, depending on the upgrade size / PC. In this way, they might have a chance to do it.

Cheers,

Calin

View solution in original post

5 REPLIES 5
Calin C.
Contributor

Hello,

If you have no QoS strategy there, regarding packet congestion, packet prioritization or shaping, when the link is full then the packets will be delivered by FIFO method (first-in-first-out). The rest of the packets which cannot be delivered right away, will be queued. When queue is full, the packet will be dropped (tail dropping effect). This is the technical explanation.

What your Desktop team will see is that they will lose connection to their remote systems (PC) or encounter delay in command processing. You also will have problems reaching your remote network devices if you have any.

As a suggestions, why they don't split these 40 PCs over multiple days, depending on the upgrade size / PC. In this way, they might have a chance to do it.

Cheers,

Calin

View solution in original post

Hi Calin,

Are you from Romania mate?


I was born there

sry for the side tracking and back to the topic.

I did suggest that they split this into mini small groups, however, their argument was that it will be alright!

there is a Qos policy in place, but i'm not sure how it's configured since it was done by a 3rd party contractor.

Mahesh Gohil
Rising star

Hi haidar,

I suggest you to put some qos on 10mb link and restrict some bandwidth for this activity so that you could

have some free bw incase of any emergency.

also you can enable ip accounting and see which IP's traffic is more and during such crisis you can guide that this PC is generating more traffic. so that you can remove that PC from network for time being

Regards

Mahesh

Hi Mahesh,

Can IP Accounting be used on layer 2 switches?

I don't have much knowledge on this, will do some reading and see if I can apply it, it looks like a good feature to have enabled especially in situations like this one.

Many thanks,

Haidar

IP accounting can only be used on routing platforms OR on switching platforms that are performing forwarding in software (not regular forwarding of TCP/UDP packets).

If the upgrade is UDP based you will probably see a lot of failures in the upgrade process from dropped packets. Only real way to solve this is to provide more bandwidth or stagger the upgrades, QoS will not help.

If the upgrade is TCP based, they should naturally backoff (slow down) when they notice there are a lot of retransmission from the oversaturation of the link. QoS may help if you can guarantee a per-flow bandwidth that way all 40 hosts get some reserved bandwidth (per destination flow policing/shaping).

However, since bandwidth is limited if you oversaturate and drop, there is a chance the software you are upgrading will not be able to handle the drops. Best decision is to stagger upgrades or divide and conquer.