[c-nsp] Basic QoS on ATM subinterfaces

[Dave Weis]

Hello Tim

Tim Franklin wrote:
>> interface Virtual-Template1
>>   ip unnumbered Loopback0
>>   ip accounting output-packets
>>   no logging event link-status
>>   peer default ip address pool adsl1
>>   ppp authentication pap chap radius-ppp
>>   ppp authorization radius-ppp
>>   ppp link reorders
>>   ppp multilink
>>   ppp multilink fragment disable
>>   service-policy output IS-VOICE
> 
> That looks OK to me.
> 
>> in show queueing are MLP bundles. The PVC's that show up after that 
>> section all list the queueing as FIFO still:
> 
> To be honest, I've never looked at that.  Does 'show policy-map interface virtual-accessNNN' give you the right policy applied, and drops happening in the right class at the right times?

If I run it against an MLP bundle with a voice device behind it, I do 
see what I would expect:

router#show policy-map int Vi573
  Virtual-Access573

   Service-policy output: IS-VOICE

     Class-map: IS-VOICE (match-all)
       108729 packets, 22455543 bytes
       5 minute offered rate 0 bps, drop rate 0 bps
       Match: access-group name IS-VOICE
       Queueing
         Strict Priority
         Output Queue: Conversation 264
         Bandwidth 75 (%)
         Bandwidth 224640 (kbps) Burst 5616000 (Bytes)
         (pkts matched/bytes matched) 0/0
         (total drops/bytes drops) 0/0
       QoS Set
         dscp ef
           Packets marked 108729

     Class-map: EVERYTHING (match-all)
       332750 packets, 429378515 bytes
       5 minute offered rate 38000 bps, drop rate 0 bps
       Match: access-group name EVERYTHING
       QoS Set
         dscp default
           Packets marked 332750

     Class-map: class-default (match-any)
       0 packets, 0 bytes
       5 minute offered rate 0 bps, drop rate 0 bps
       Match: any

If I run it on a non-MLP virtual-access interface I get no output at all 
from the show policy-map command.

> (I have a feeling the underlying interface still says FIFO as it is just passing on the PPPoA packets after the virtual-access has decided which packets to encapsulate in which order, but *don't* take that as gospel).

Understood. I did find another document that I'm going to try and adapt:
http://www.cisco.com/en/US/tech/tk543/tk544/technologies_tech_note09186a0080094ad2.shtml

> I'd also second another poster's point that you'll want the individual VCs configured as something like vbr-nrt, not ubr, or you won't ever get the back-pressure to the service-policy.

Can you configure a VC as vbr-nrt without explicitly putting the rates? 
All of the PVC's are varying speeds with no explicit configuration for 
any one PVC.


-- 
Dave Weis
515-224-9229
djweis at internetsolver.com
http://www.internetsolver.com/
Please check out our Complete Support Service
http://www.internetsolver.com/completesupport/