Bandwidth Saturation

[mellalBrahim]

greetings everyone, 

nowadays i'am facing a big issue, on my network a have a replication link to our backup datacenter, and this link is a lease link with 20Mbps.

latetly some server's jobs fail down since the saturation of this link, and the ping get up to 500ms.

and the  txload 47/255, rxload 254/255 of the interface connected to the SP.

my questions are: 

    * how can i caltulcate the bandwidth utilisation of that interface? 

    * how can i use the QOS to optimaze this link.

many thanks.

[Kasun Bandara · Accepted solution]

1. you can get a bandwidth utilization graph from ISP. it will show how much bandwidth is hitting on replication time

2. QoS is to good to control critical or non critical traffic by policing/shaping/dropping them. in your case, if you are not worry about replication time, you can shape the traffic (but replication job will take more time). dropping is not an option to you because as you send replication traffic. check below.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_plcshp/configuration/xe-3s/qos-plcshp-xe-3s-book/qos-plcshp-pct-shp.html

[mellalBrahim]

thank you sharing with i'll follow cautiously these steps, and to you with results.

[Joseph W. Doherty]

BTW, with what @Kasun Bandara suggested, i.e. policing/shaping, both can "mitigate" this issue too.

However, they both suffer from always limiting your replication traffic's bandwidth usage, i.e. the replication traffic cannot otherwise take advantage of unused bandwidth.

Second, you must decide on how much bandwidth you're going to shape or police your replication traffic to.

You restrict it too much, and its very much slowed, especially annoying when there's bandwidth going unused (you're paying for 20 Mbps, take full advantage of it), you restrict it too little, and you have the same problem you have now.

What I suggested doesn't set a cap on replication traffic's bandwidth usage, it just insures it gets "lower or equal priority" vs. other traffic.

(BTW, years ago, had a similar situation where a "new" client backup application backed up user data to a DC server.  This backup app pushed our WAN links to 100% all day long.  But, prioritized as shown, all other traffic performed pretty much like the backup app wasn't using the link at all.)

Also, BTW, you can only shape on egress.  You can police on ingress or egress.

[Joseph W. Doherty]

"how can i caltulcate the bandwidth utilisation of that interface?"

txload 47/255 = 16.4% - rxload 254/255 = 99.6%

"how can i use the QOS to optimaze this link."

Do you control/manage the device at your DC with connection to SP's network?  If so, what would likely work very well is placing your replication traffic into a background/scavenger like class.

Logically, something like:

policy-map Example
class replication-traffic
bandwidth percent 1 !BTW, this still allows this traffic to use 100% of bandwidth, but it, mostly, allows other traffic to use the link first
class class-default
bandwidth percent 99

or if your egress device supports FQ, this might work too:

policy-map Example
class class-default
fair-queue

If you only manage device that's connected to the SP, even with the best of QoS features, an "ideal" QoS mitigation isn't very likely.  You can, as @Kasun Bandara mentions, possibly police the inbound replication traffic, but there's lots of "gotchas" doing that.  If replication traffic is TCP based, you can also shape outbound ACKs, but that too, is far from "ideal".

[mellalBrahim]

thank a lot for you response Joseph W. Doherty i'll try it and back to you with a feedback.