Re: QoS for PPPoE / ADSL

Hi Andrew,

The reason I'd like to be able to trigger congestion through the use
of a parent shaper is that many QoS features don't activate unless the
interface is experiencing congestion. Since the interface over which
the PPPoE session is established is clocked at 100Mbps, none of the
queueing configuration is going to work when my upstream offered data
rate exceeds the line sync rate -- "IOS says: you're trying to send
1.3Mbps of data upstream, via a 100Mbps interface -- you've got HEAPS
of room!". Of course, there'll be evidence of the problem in upper
layer protocols, and some transports will respond better than others.

So I can configure LLQ and CBWFQ all day long, but unless IOS thinks
the interface is experiencing congestion, none of the configuration is
going to take effect.

The solution is to configure a parent shaper that shapes all outbound
to a specified rate (in my case, say, 1.2Mbps), and this is where I
don't think a 'static' configuration is ideal.

Regarding LLQ.. I see what you're saying, but remember that the
in-built policer function only activates under congestion. Without
congestion, the LLQ can chew up as much bandwidth as is available,
potentially introducing a problem if there's a burst of traffic in
another class. This is a good reason to configure a policer explicitly
for the LLQ.

I've decided to graph my upstream (and downstream, while I'm at it)
sync speeds for a week or two, so that I can settle on a sensible
'shape average' value for the parent shaper. I'm going to use SNMP
with Cacti to do it, rather than any kind of dynamic method based on
IOS scripting (although that would be 'way cool').

cheers,
Dale

On Sun, May 10, 2009 at 12:43 PM, ALL From_NJ <all.from.nj_at_gmail.com> wrote:
> I have not done this scenario myself, so I don't suppose my response will be
> as helpful as another. Appreciate this question Dale as it made me look up
> a few things I had forgetten that I forgot. Thx!
>
> Oh well ... hope these comments help.
>
> For LLQ you should configure what you need and that's that. What does your
> traffic need for the LLQ? Ok ... so ... configure it, guarantee it, and
> you are cool (always!). If the line rate fluctuates, and you do not have
> enough for your LLQ, then you need a diff line. Sorry for stating the
> obvious ...
>
> For the other traffic, my intial thoughts are that configuring the
> class-default for wred is probably all you need. The other traffic will
> battle it out in the individual queues, and traffic will be dropped when
> needed.
>
> LLQ for your important stuff, and wred for the rest. The important traffic
> will get through and the other traffic will "come and go" as available
> bandwidth provides.
>
> Hope this is not too far off or too simplistic of an approach. Further, I
> look forward to hearing yours and the other expert's opinions. Kindest
> regards,
>
> Andrew

Blogs and organic groups at http://www.ccie.net
Received on Sun May 10 2009 - 18:28:28 ART