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.

"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.

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?

"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.

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?

"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.