Virtual-Access Service Policy

Posted: October 14, 2009 in QoS, WAN (L2TP / PPP / FR)

Over the last few months I have learned the hard way that the difficult aspect of implementing QoS (in production networks) is not developing the policy but enabling it on the interface. Various different implementations make it very difficult and there is mixed IOS support all around. In particular I was trying to get a priority queue working on a Virtual-Access interface.

Doing some research it quickly became apparent that
1. Cisco does not support per session queuing
2. That some IOS could do it but many people had tried and failed.

Using a Cisco-AV-Pair “lcp:interface-config=service-policy output/input [policy name]”, after some playing around I managed to get something to stick and learned quite a bit on the way. Logical interfaces in IOS do not necessarily naturally allow for a state of congestion. This means that for anything to hit the priority queue you will firstly need a shaper. Now that the logical circuit can become congested the fancy queuing can be put to use. Until the interface becomes congested you will not see packets hit the priority queue, by doing some maths and pinging with timeout set to zero you can force this;

LNS#show policy-map int vi2.1
Virtual-Access2.1

Service-policy output: 128k-shaper

Class-map: class-default (match-any)
732 packets, 201845 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
128000/128000 1984 7936 7936 62 992

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
– 0 628 126309 100 85780 no

Service-policy : 128k-QoS

Class-map: Prec2 (match-all)
150 packets, 79500 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip precedence 2
Queueing
Strict Priority
Output Queue: Conversation 24
Bandwidth 64 (kbps) Burst 1600 (Bytes)
(pkts matched/bytes matched) 100/50500
(total drops/bytes drops) 70/35000

Class-map: Prec1 (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 32 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any)
582 packets, 122345 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 16
(total queued/total drops/no-buffer drops) 0/34/0

I’ve seen this working in a production environment using IOS
c7200p-advipservicesk9-mz.124-4.XD10.bin
c7200-js-mz.122-31.SB9.bin

My lab used and the same setup as the previous post
c3660-is-mz.123-23.bin

I guess this could even potentially be in the lab exam, doubt it though.

Comments
  1. Tinsle_B says:

    This is really useful information.

    I have been looking for config examples for L2TP QoS and they are hard to find.

    Would you be able to share the configs you used for this?

    • doccieshavespecialpowers says:

      The actual QoS config doesn’t really change, Only how you apply it

      Policy-map ‘name’
      Shape average ‘x’
      Class class-default
      Service-policy ‘normalpolicy’

      You should be able to apply it directly under the virtual-template for testing. Some IOS versions may accept the configuration but not perform the queuing correctly so load testing is essential

Leave a comment