RE: CBWFQ on a Frame link...

From: Scott Morris (swm@emanon.com)
Date: Sun Sep 05 2004 - 15:42:45 GMT-3


That's very true... But my problem with it is that since that happens, why
couldn't that be an automatic implication if you WANT to just do queuing at
a subinterface level?

So yeah, I know from the way things are now why it doesn't work... It just
makes no sense that a known workaround exists (so obviously there's a good
reason to do this), yet it hasn't been taken a step further. :) Besides, I
just enjoy finding logical flaws in coding as we configure around stuff!
(smirk)

If you are creating a logical interface, then you should be able to able to
create a separate queuing structure. *shrug* Different decisions likely
made at different times though for programming/usage sake.

Furthering your point, (which was much more concise there than mine) when
you do a policing policy (which has no buffer/queue) then this will not
work.

 
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP,
JNCIP, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
 

-----Original Message-----
From: Daniel Ginsburg [mailto:dginsburg@gmail.com]
Sent: Sunday, September 05, 2004 1:35 PM
To: Scott Morris
Cc: Carlos G Mendioroz; Bob Sinclair; Mike Calhoon; ccielab@groupstudy.com
Subject: Re: CBWFQ on a Frame link...

On Sun, 5 Sep 2004 12:21:02 -0400, Scott Morris <swm@emanon.com> wrote:
> Thanks. :)
>
> Sorry for the wording... It's a restriction with the WFQ engine
> (coding problem?)... You are allowed to apply a policy (see the
> example I did on my router there) that has traffic-shaping listed, but
> you are not allowed to apply a policy that has queuing specifics to a
subinterface.
>
> My guess is that the way that part of IOS is coded implies an overall
> control of software queuing mechanisms from the main physical
> interface, although logically that makes little difference. It's just
> one of those things.
>

I think this is because subinterfaces have no separate queues, so queueing
policy on a subinterface simply doesn't make sense. However traffic shaping
invents a queue - traffic shaping delays excess traffic in a buffer and you
can put some traffic in this buffer ahead of other.

> With FRTS, you are doing independent shaping on each PVC, but you can
> CALL queuing mechanisms like priority or CBWFQ as well. Which
> furthers the "why not" question posed earlier. :)
>
> But if you are simply looking to deploy CBWFQ without using FRTS or a
> map-class, then you have to do it via a hierarchical policy deployment.
>

--
dg


This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:37 GMT-3