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.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
