[c-nsp] QoS on ADSL: it works! well, in some locations.

[Adam Atkinson]

I have read the archives of this mailing list, and blog.ioshints.info, 
and various Cisco docs and Cisco press books. I have what I believe to 
be a working config but I get the impression from mail on this list 
earlier this year that what I have done is not the preferred option, so 
I'm wondering there's actually anything wrong with what I've got. (Since 
it seems to work, you can understand I'm a bit loath to mess with it.)

I have access to a number of 837s mostly running 12.4(17b) and 877s 
mostly running 12.4(24)T2. Yes, I appreciate that these are 
substantially different pieces of hardware and very different software 
versions.

On one 877 I get this output to "show policy-map int virtual-access 3 out"

router#sh policy-map int virtual-access 3 out
  Virtual-Access3

   Service-policy output: shaper

     Class-map: class-default (match-any)
       17083 packets, 1701441 bytes
       5 minute offered rate 0 bps, drop rate 0 bps
       Match: any
       Queueing
       queue limit 256 packets
       (queue depth/total drops/no-buffer drops) 0/69669/0
       (pkts output/bytes output) 3008129/2580223256
       shape (average) cir 392000, bc 1568, be 1568
       target shape rate 392000

       Service-policy : nicetosmall

         Class-map: highprec (match-any)
           16134 packets, 1462276 bytes
           5 minute offered rate 0 bps, drop rate 0 bps
           Match:  precedence 4  5  6  7
             16134 packets, 1462276 bytes
             5 minute rate 0 bps
           Queueing
           queue limit 256 packets
           (queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0
           (pkts output/bytes output) 1016237/90520107
           bandwidth 384 kbps
           Fair-queue: per-flow queue limit 64

         Class-map: class-default (match-any)
           949 packets, 239165 bytes
           5 minute offered rate 0 bps, drop rate 0 bps
           Match: any
           Queueing
           queue limit 256 packets
           (queue depth/total drops/no-buffer drops/flowdrops) 0/69669/0/0
           (pkts output/bytes output) 1991892/2489703149
           Fair-queue: per-flow queue limit 64
             Exp-weight-constant: 9 (1/512)
             Mean queue depth: 1 packets
             class     Transmitted       Random drop      Tail/Flow drop 
Minimum Maximum Mark
                       pkts/bytes    pkts/bytes       pkts/bytes 
thresh  thresh  prob

             0           68671/36922972     1354/391185       244/41326 
           20            40  1/10
             1         1630623/2396487300  63232/93468168     220/326224 
            22            40  1/10
             2           34163/33976614      278/292357        36/26855 
             24            40  1/10
             3          258435/22316263     3994/331861       311/19786 
             26            40  1/10
             4               0/0               0/0              0/0 
             28            40  1/10
             5               0/0               0/0              0/0 
             30            40  1/10
             6               0/0               0/0              0/0 
             32            40  1/10
             7               0/0               0/0              0/0 
             34            40  1/10


which certainly _looks_ as though it's doing things. And it also passes 
the acid test that if I (try to) flood the link with traffic which 
belongs in the child default class, people who belong in the child 
"highprec" class don't notice anything.

The ip precedence values are of course applied using an incoming 
policy-map on vlan1.

 From advice in various locations, what I did was:

put ppp multilink on dialer interface
put policy-map on dialer interface
in policy map have parent class shaping to the highest traffic I was 
able to actually get out of the dialer, and put children doing the 
actual "meat" of the job I wanted doing.

On the ATM interface I have:

  pvc 0/38
   vbr-nrt 448 448 1
   tx-ring-limit 3
   encapsulation aal5snap
   protocol ppp dialer

So we have the "set tx ring to 3" and "use vbr-nrt instead of ubr, or at 
  least tell the router you are" pieces of advice.

There are two flies in the ointment. On another 877, connected to a 
different ISP, the ppp multilink statement doesn't take effect and
just this seems to kill the whole plan.

And secondly I get the impression from some things I've read that even 
on the 877 which works I "should" have put the policy-map on the pvc 
rather than on the dialer, though I'm not quite sure why. Would it be 
better somehow?

On the 837s I couldn't get the two-level policies to work (the commands 
were accepted but not policies showed as being present in the config). I 
don't think they have enough oomph to run 12.4(20)T or later. Is there 
any hope at all on 837s with only 12.4(17b)?

I expect any experimenting with 2-level policy maps straight on the pvc 
will take place on the router(s) where multilink isn't working. I've 
seen some claims that it may be necessary to try vbr-rt or cbr so I 
guess they'll go in the mix.

Older documentation I've found talked about using one policy on dialer 
and another on pvc but 12.4(20)T and later very much don't seem to want 
you to do that.

I get the impression from archives of this list that going the pvc route 
it doesn't matter if we use a subinterface or not, though in many 
examples people seem to use one.

Given that ppp multilink can't be relied upon to work I expect on 877s 
and better in future the pvc approach is what I need to use.