From: Scott Morris (swm@emanon.com)
Date: Sun Sep 05 2004 - 13:21:02 GMT-3
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.
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.
HTH,
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: Carlos G Mendioroz [mailto:tron@huapi.ba.ar]
Sent: Sunday, September 05, 2004 8:06 AM
To: Scott Morris
Cc: 'Bob Sinclair'; 'Mike Calhoon'; ccielab@groupstudy.com
Subject: Re: CBWFQ on a Frame link...
Scott,
I don't follow your first paragraph...
It seems to imply that shapping is simpler than queueing ? Or that you can
shape w/o queueing ?
FRTS allows to have independent queuing on different PVCs.
I'm not very confident on the following but this is how I think it goes:
Queueing is a layer 2 issue, subinterfaces is a layer 3 issue.
So it does not matter if subinterraces are used or not. It matters if you do
per-PVC policy (FRTS) or not.
BTW, good luck on voice!
Scott Morris wrote:
> If it involves queuing, then you cannot. If your main policy involves
> something simply like shaping, then yes you can. And you can further
> apply a service-policy within the policy to really take care of your
> queuing needs.
>
> You're not supposed to allow queuing on a sub-interface, and yet the
> workaround is documented. Go figure.
>
> But otherwise, you're correct to think through what you do or don't need.
>
> Some semi-related information:
> http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_featur
> e_guid
> e09186a00802261cc.html
> http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note0918
> 6a0080
> 114326.shtml
>
> Emanon-R1#sh policy
> Policy Map total
> Class one
> Bandwidth 11 (%) Max Threshold 64 (packets)
> Class two
> Bandwidth 26 (%) Max Threshold 64 (packets)
> Class three
> Bandwidth 4 (%) Max Threshold 64 (packets)
> Class four
> Bandwidth 22 (%) Max Threshold 64 (packets)
> Class five
> Bandwidth 15 (%) Max Threshold 64 (packets)
> Class six
> Bandwidth 15 (%) Max Threshold 64 (packets)
> Class class-default
> Bandwidth 7 (%) Max Threshold 64 (packets)
>
> Policy Map shape
> Class class-default
> Traffic Shaping
> Average Rate Traffic Shaping
> CIR 64000 (bps) Max. Buffers Limit 1000 (Packets)
> service-policy total
>
> Emanon-R1#conf t
> Emanon-R1(config)#int s0/0.1
> Emanon-R1(config-subif)#service-policy output total <== Not taken
> here CBWFQ : Not supported on subinterfaces
> Emanon-R1(config-subif)#exit Emanon-R1(config)#pol
> Emanon-R1(config)#policy-map shape Emanon-R1(config-pmap)#class
> class-default Emanon-R1(config-pmap-c)#shape average 64000
> Emanon-R1(config-pmap-c)#serv Emanon-R1(config-pmap-c)#service-policy
> total Emanon-R1(config-pmap-c)#exit Emanon-R1(config-pmap)#exit
> Emanon-R1(config)#int s0/0.1
> Emanon-R1(config-subif)#service-policy output shape <== Taken here
> Emanon-R1(config-subif)#^Z
> 12w4d: %SYS-5-CONFIG_I: Configured from console by console
>
> Notice that it's working now...
>
> Emanon-R1#sh policy-map int s0/0.1
>
> Serial0/0.1
>
> Service-policy output: shape
>
> Class-map: class-default (match-any)
> 170 packets, 166409 bytes
> 5 minute offered rate 5000 bps, drop rate 0 bps
> Match: any
> Traffic Shaping
> Target/Average Byte Sustain Excess Interval Increment
> Rate Limit bits/int bits/int (ms) (bytes)
> 64000/64000 2000 8000 8000 125 1000
>
> Adapt Queue Packets Bytes Packets Bytes Shaping
> Active Depth Delayed Delayed Active
> - 0 170 166409 8 5867 no
>
> Service-policy : total
>
> Class-map: one (match-all)
> 0 packets, 0 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: ip precedence 1
> Queueing
> Output Queue: Conversation 25
> Bandwidth 11 (%) Max Threshold 64 (packets)
> (pkts matched/bytes matched) 0/0
> (depth/total drops/no-buffer drops) 0/0/0
>
> Class-map: two (match-all)
> 0 packets, 0 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: ip precedence 2
> Queueing
> Output Queue: Conversation 26
> Bandwidth 26 (%) Max Threshold 64 (packets)
> (pkts matched/bytes matched) 0/0
> (depth/total drops/no-buffer drops) 0/0/0
>
> Class-map: three (match-all)
> 0 packets, 0 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: ip precedence 3
> Queueing
> Output Queue: Conversation 27
> Bandwidth 4 (%) Max Threshold 64 (packets)
> (pkts matched/bytes matched) 0/0
> (depth/total drops/no-buffer drops) 0/0/0
>
> Class-map: four (match-all)
> 0 packets, 0 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: ip precedence 4
> Queueing
> Output Queue: Conversation 28
> Bandwidth 22 (%) Max Threshold 64 (packets)
> (pkts matched/bytes matched) 0/0
> (depth/total drops/no-buffer drops) 0/0/0
>
> Class-map: five (match-all)
> 0 packets, 0 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: ip precedence 5
> Queueing
> Output Queue: Conversation 29
> Bandwidth 15 (%) Max Threshold 64 (packets)
> (pkts matched/bytes matched) 0/0
> (depth/total drops/no-buffer drops) 0/0/0
>
> Class-map: six (match-all)
> 26 packets, 1565 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: ip precedence 6
> Queueing
> Output Queue: Conversation 30
> Bandwidth 15 (%) Max Threshold 64 (packets)
> (pkts matched/bytes matched) 1/48
> (depth/total drops/no-buffer drops) 0/0/0
>
> Class-map: class-default (match-any)
> 144 packets, 164844 bytes
> 5 minute offered rate 5000 bps, drop rate 0 bps
> Match: any
> Queueing
> Output Queue: Conversation 31
> Bandwidth 7 (%) Max Threshold 64 (packets)
> (pkts matched/bytes matched) 4/1304
> (depth/total drops/no-buffer drops) 0/0/0 Emanon-R1#
>
> HTH,
>
>
> 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: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of Bob Sinclair
> Sent: Saturday, September 04, 2004 9:51 PM
> To: Mike Calhoon; ccielab@groupstudy.com
> Subject: Re: CBWFQ on a Frame link...
>
> Mike,
>
> I find that I cannot apply a service-policy to a frame-relay
> subinterface, and when applied to the physical it does not match on
> traffic across the subinterfaces. If you have a single DLCI on a
> physical interface, then perhaps CBWFQ without a map-class will work
> for you, otherwise I would think carefully about using a map-class.
>
> Bob Sinclair
> CCIE #10427, CISSP, MCSE
> www.netmasterclass.net
>
> ----- Original Message -----
> From: "Mike Calhoon" <mcalhoon27@earthlink.net>
> To: <ccielab@groupstudy.com>
> Sent: Saturday, September 04, 2004 8:45 PM
> Subject: CBWFQ on a Frame link...
>
>
>
>>Hello group,
>>
>>
>>
>> Just a general question.here's the scenario: You get a QoS
>> question,
>
> not
>
>>necessarily traffic-shaping, that is to be applied to an interface
>>that happens to be a frame-relay interface. You configure the
>>solution using CBWFQ. The question does not mention anything about
>>frame-relay or
>
> DLCI's,
>
>>etc. Is it okay for you to just apply to policy-map directly to the
>>interface, or should you always enable FRTS and put the policy-map
>>inside
>
> a
>
>>frame-relay map-class? Any thoughts would be appreciated.
>>
>>
>>
>> Thanks,
>>
>> Mike
>>
>>______________________________________________________________________
>>_ Please help support GroupStudy by purchasing your study materials
>>from:
>>http://shop.groupstudy.com
>>
>>Subscription information may be found at:
>>http://www.groupstudy.com/list/CCIELab.html
>
>
> ______________________________________________________________________
> _ Please help support GroupStudy by purchasing your study materials
> from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _ Please help support GroupStudy by purchasing your study materials
> from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
-- Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:37 GMT-3