Rate limiting link to remote site

Unanswered Question
Jul 8th, 2009
User Badges:

We have a remote site used for DR that is backing up large amounts of data across a DS3, sourced from gigabit ports.


The DS3 is getting taxed and some applications are lossing connectivity to the remote end as a result of the congestion.


Would rate limiting be a good choice for traffic management in this situation, or should the traffic be managed on the source?


I am concerned about limiting traffic on the router that is originating from a backup source.


Could there be a potential for dropped packets corrupting databases getting copied, or would it all get retransmitted?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (5 ratings)
Loading.
Istvan_Rabai Wed, 07/08/2009 - 09:25
User Badges:
  • Gold, 750 points or more

Hi Richard,


I think you need to introduce QoS on the DS3 link.


To guarantee some bandwidth to those "some applications" that lose connectivity as a result of data backup.


That would prevent bandwidth starvation of those applications caused by the data backup.


If you need further help in configuring QoS, please provide further details about your environment and traffic requirements.


Cheers:

Istvan

Joseph W. Doherty Wed, 07/08/2009 - 11:09
User Badges:
  • Super Bronze, 10000 points or more

Agree with Istvan that something other that rate-limiting, might better serve.


If your platform supports it, WFQ (as provided by CBWFQ) might be a good start.


e.g.


policy-map CBWFQ

class class-default

fair-queue


inteface (DS3)

service-policy output CBWFQ

wilson_1234_2 Wed, 07/08/2009 - 12:55
User Badges:

Thanks guys,


"Some Applications loosing connectivity" was a poor choice of words.


What is happening is there is an SRDF storage device linked to a remote site device that is what seems to be flapping.


There is data that is being copied from one end to the other, the amount of traffic is not restricted from the devices, it send it to the remote site on a gigabit link and then hits the DS3.


I get high utilization alerts on the DS3 when the copies are being done and the guys operating the file copies are saying the link is dropping out.


So, i am not sure that QoS would fit this scenario because the device causing the congestion, is getting the entire pipe.



Joseph W. Doherty Wed, 07/08/2009 - 16:54
User Badges:
  • Super Bronze, 10000 points or more

"So, i am not sure that QoS would fit this scenario because the device causing the congestion, is getting the entire pipe. "


The basic CBWFQ example I provided will share bandwidth between flows. If you're currently using FIFO (often the default at DS3), and if your platform supports it, you might try what I suggested and see if it help. BTW, you would want it on egress, both sides.

wilson_1234_2 Thu, 07/09/2009 - 06:25
User Badges:

Thanks Joseph,


Please help me to understand:


policy-map CBWFQ

class class-default

fair-queue


inteface (DS3)

service-policy output CBWFQ



In this example it looks like all that has been done is to change the transmited class default traffic from FIFO to CBWFQ.


And the reason is to utilize the function of sharing bandwidth between flows?

Joseph W. Doherty Thu, 07/09/2009 - 09:04
User Badges:
  • Super Bronze, 10000 points or more

"In this example it looks like all that has been done is to change the transmited class default traffic from FIFO to CBWFQ.


And the reason is to utilize the function of sharing bandwidth between flows?"


Yes and yes. Moving from FIFO to FQ keeps one or just few flows from (usually) adversely impacting other non-bandwidth demanding flows, yet all available bandwidth can be utilized.


CBWFQ can easily be expanded to provide even further traffic treatment differences if you find that necessary.

wilson_1234_2 Tue, 07/14/2009 - 10:25
User Badges:

Sorry Joseph,


Since all of the traffic is classed as default (for the moment), and the FQ mechanism allows bandwidth per flow,


how is the bandwidth allocated between the flows?


What determines which connection gets bandwidth and how much?


For example, are all connections guarenteed bandwidth?


What if one connection wants to use all of the link?

Joseph W. Doherty Tue, 07/14/2009 - 13:53
User Badges:
  • Super Bronze, 10000 points or more

"how is the bandwidth allocated between the flows? "


That depends on the actual implementation. "True" FQ, without weights, should insure each flow gets a equal proportional guaranteed share of bandwidth. Since some flows don't want their full guaranteed bandwidth, excess is proportionally provided to flows wanting more.


"What determines which connection gets bandwidth and how much? "


The scheduling algorithm.


"For example, are all connections guarenteed bandwidth? "


An equal share yes, absolute share, no.


"What if one connection wants to use all of the link?"


Depends on what other flows want.



Some examples:


4 flows, each wants all bandwidth - each gets 25%


4 flows, each wants half of all bandwidth - each gets 25%


4 flows, each wants 20% of all bandwidth - each gets 20% (20% unused)


4 flows, 2 want 10%, 1 wants 25%, 1 wants all - 2 get 10%, 1 gets 25%, 1 gets 55%


4 flows, 2 want 10%, 1 wants 45%, 1 wants all - 2 get 10%, 2 get 40%


This note (http://www.cisco.com/en/US/tech/tk39/tk824/technologies_tech_note09186a00800c9699.shtml) has more details, although it uses ATM and 7200 in example.

Actions

This Discussion