cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4472
Views
5
Helpful
7
Replies

Use bandwidth of VAI in QoS Parent Policy

Scott Pettit
Level 9
Level 9

Hi all,

Have been trying to solve this myself for a couple of days but haven't managed to find an answer.  I've done a similar solution before where I put bandwidth inherit on the Dialer interface of the CPE and it inherited the ATM interface speed (the upload sync rate) and prevented the CPE from maxing out and hitting hardware queuing in the DSLAM.  I can't seem to find a way to do this downstream from our ASR1K to the customer though.

Platform is ASR1001 with IOS 3.7.2 or 15.2(4)S

Problem description:

We have many xDSL users (ADSL2+ and VDSL2).  They all sync at different speeds depending on how far they are from the DSLAM.

Example:

Customer A might be connected at 40000kbps/10000kbps (VDSL2)

Customer B might be connected at 5000kbps/600kbps (ADSL)

When they connect and the PPPoE session comes up, the bandwidth on the Virtual Access Interface is equal to the customer's downstream sync rate, so Customer A's virtual access interface, Virtual-Access 2.13 will say 40000kbps, and Customer B's virtual access interface Virtual-Access 2.39 will say 5000kbps.

Using RADIUS, we apply a sub-qos-policy-out to the PPPoE session.

I want to shape the customer to 80% of their sync rate so that we do not hit interface congestion in the DSL network which makes VoIP perform poorly.

I cannot use an absolute value for the shape, because the sync rate varies for each customer.

The problem I have is at present the policy-map is using the interface bandwidth of Gi0/0/1 (1Gbit) instead of the bandwidth of the Virtual Access Interface.  Therefore the customer is being limited to 800Mbit which means the QoS policy will never take effect.

RADIUS Config Below:

cisco-avpair += ip:sub-qos-policy-out=QOS-POLICY-OUT-PARENT-DSL

Class Maps

class-map match-any QOS-CLASS-VOIP-RTP-DSL

match protocol rtp audio

match access-group name QOS-VOIP-RTP

class-map match-any QOS-CLASS-VIDEO-RTP-DSL

match protocol rtp video

Policy Maps

policy-map QOS-POLICY-OUT-CHILD-DSL

class QOS-CLASS-VOIP-RTP-DSL

  priority percent 5

class QOS-CLASS-VIDEO-RTP-DSL

  priority percent 10

class class-default

  fair-queue

policy-map QOS-POLICY-OUT-PARENT-DSL

class class-default

  shape average percent 80

   service-policy QOS-POLICY-OUT-CHILD-DSL

Output of Show Interface Vi2.44

show int vi2.44

Virtual-Access2.44 is up, line protocol is up

  Hardware is Virtual Access interface

  Interface is unnumbered. Using address of Loopback4000

  MTU 1500 bytes, BW 48422 Kbit/sec, DLY 100000 usec,

     reliability 255/255, txload 5/255, rxload 1/255

  Encapsulation PPP, LCP Open, multilink Closed

  Open: IPCP, IPV6CP

  PPPoVPDN vaccess, cloned from AAA, AAA, Virtual-Template1

  Vaccess status 0x0

  Protocol l2tp, tunnel id 51815, session id 24465

  Keepalive set (60 sec)

     246037 packets input, 285563771 bytes

     141575 packets output, 18807810 bytes

  Time to interface disconnect:  idle 00:29:58

  Last clearing of "show interface" counters never

Output of Show Policy-Map on Virtual Access Interface

show policy-map interface vi2.44

Virtual-Access2.44

SSS session identifier 1011 -

  Service-policy output: QOS-POLICY-OUT-PARENT-DSL

    Class-map: class-default (match-any) 

      105059 packets, 18013377 bytes

      30 second offered rate 217000 bps, drop rate 0000 bps

      Match: any

      Queueing

      queue limit 555 packets

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts output/bytes output) 104996/19900029

      shape (average) cir 800000000, bc 3200000, be 3200000

      target shape rate 800000000

      Service-policy : QOS-POLICY-OUT-CHILD-DSL

        queue stats for all priority classes:

          Queueing

          queue limit 512 packets

          (queue depth/total drops/no-buffer drops) 0/0/0

          (pkts output/bytes output) 0/0

        Class-map: QOS-CLASS-VOIP-RTP-DSL (match-any) 

          0 packets, 0 bytes

          30 second offered rate 0000 bps, drop rate 0000 bps

          Match: protocol rtp audio

          Match: access-group name QOS-VOIP-RTP

          Priority: 5% (40000 kbps), burst bytes 1000000, b/w exceed drops: 0

        Class-map: QOS-CLASS-VIDEO-RTP-DSL (match-any) 

          0 packets, 0 bytes

          30 second offered rate 0000 bps, drop rate 0000 bps

          Match: protocol rtp video

          Priority: 10% (80000 kbps), burst bytes 2000000, b/w exceed drops: 0

        Class-map: class-default (match-any) 

          105059 packets, 18013377 bytes

          30 second offered rate 217000 bps, drop rate 0000 bps

          Match: any

          Queueing

          queue limit 555 packets

          (queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0

          (pkts output/bytes output) 104996/19900029

          Fair-queue: per-flow queue limit 138 packets

Output of Show Run Interface Vi2.44

show run int vi2.44

Building configuration...

Current configuration : 257 bytes

!

interface Virtual-Access2.44

ip flow ingress

ip flow egress

ipv6 unnumbered Loopback4000

ipv6 enable

ipv6 mtu 1492

ipv6 nd reachable-time 30

ipv6 nd other-config-flag

no ipv6 nd ra suppress

ipv6 dhcp server PPP-RADIUS

ppp timeout idle 1800

end

This comes off the Virtual-Template 1

interface Virtual-Template1

ip unnumbered Loopback4000

ip flow ingress

ip flow egress

load-interval 30

ipv6 unnumbered Loopback4000

ipv6 enable

ipv6 mtu 1492

ipv6 nd reachable-time 30

ipv6 nd other-config-flag

no ipv6 nd ra suppress

ipv6 dhcp server PPP-RADIUS

peer ip address forced

no peer default ip address

no snmp trap link-status

keepalive 60

ppp max-configure 3

ppp mtu adaptive

no ppp lcp fast-start

ppp mru match

ppp authentication pap callin pppoe-dialin

ppp authorization pppoe-dialin

ppp ipcp address required

ppp ipcp no-renegotiation

ppp multilink

ppp timeout retry 8

ppp timeout ncp 10

ppp timeout authentication 18

ppp timeout idle 1800

end

Underlying Physical Interface that L2TP Session Comes in on

interface GigabitEthernet0/0/1.4003

description L2TP Tunnel

encapsulation dot1Q 4003

vrf forwarding XXXXXXX

ip address XXXXXXX 255.255.255.252

7 Replies 7

tim
Level 1
Level 1

I've actually asked TAC about htis very thing. Ticket is still open and I am awaiting for a reply. Will let you know what they say, unless you managed to find a way yourself already?

Hi Tim,

I also have TAC case 624352829 open, so far the engineer hasn't been able to provide a solution...

If anyone from Cisco who does know how to do this is reading, it'd be much appreciated if you could contact the engineer on this case and provide some instruction

-Scott

Chris Rogers
Level 1
Level 1

Hi,

Just wondering if you ever got to the bottom of this with Cisco? I have exactly the same issue.

Thanks

Chris

Chris,

TAC confirmed that currently it just won't do what is required in the way we are looking at it.

A possible tidy/ish solution they did suggest is to use 'bandwidth qos-reference' applied via RADIUS but they also point out in the same sentance that the ASR1K platform doesn't support that command at all at the moment, let alone via RADIUS.

The only other way to do this is to configure a whole bunch of policy-maps for different speeds and then apply the correct one via RADIUS. For example, you can create a policy-map that shapes your tails at 0.5Mbit or 1Mbit intervals and then use a check attribute in RADIUS to match a range of sync speeds which are handed over to RADIUS in the RADIUS requests sent by the LNS.

For example in freeradius you can do something like this for a test account, repeating the check lines for each of your sync speed ranges and policy maps that you want to use:

user@realm Connect-Info >= "160000\/1000", Connect-Info <= "287000\/1000"

        Cisco-AVPair = "ip:sub-qos-policy-out=135K-POLICYMAP",

        Fall-Through = Yes

user@realm Connect-Info >= "288000\1000", Connect-Info <= "415000\/1000"

        Cisco-AVPair = "ip:sub-qos-policy-out=250K-POLICYMAP",

        Fall-Through = Yes

user@realm Cleartext-Password := "password"

        Framed-IP-Address = x.x.x.x,

        Framed-IP-Netmask = 255.255.255.255,

        Framed-Protocol = PPP,

        Service-Type = Framed-User

This then applies a policy-map to your subscriber interface based on their sync speed which is essentially what we are trying to do. Just not as tidy as we would like to have done it

No we didn't get a solution for this involving the VAI.  We did however add a bunch of parent shapers in 5M increments and gave the customer the ability to control this online up to the max speed of their service.

I thought about what you're suggesting with FreeRADIUS but didn't quite get there - I like that idea though, will give it a go.

The main reason we wanted the VAI bandwidth was to deal with cases where a customer has variable copper in their area resulting in sync rates that change a bit.  We still want them to have a great experience as far as Voice/Video being prioritised and smooth TCP performance.  The RADIUS idea might do that

This can be achieved using FreeRADIUS in a slightly different way to Tim's suggestion.

If you have a parent shaper configured similarly to what you have now, but with an arbitrary shape average value like:

shape average 10000000

you can at login-time substitute the value for shape average with an AV pair like:

Cisco-AVPair += "ip:qos-policy-out=add-class(sub,(class-default),shape(VALUE))

where VALUE is your target shaper bandwidth.

The trick is to get the bandwidth from Connect-Info via a regex in FreeRADIUS then return an AV pair in the response. This can be done in post-auth (under sites-enabled/default or wherever) with the following code:

if ( "%{reply:Cisco-AVPair[*]}" =~ /ip:sub-qos-policy-out=QOS-POLICY-OUT-PARENT-DSL/ ) {
        if ( "%{request:Connect-Info}" =~ /[^\/]*/ ) {
            update reply {
                Cisco-AVPair += "ip:qos-policy-out=add-class(sub,(class-default),shape(%{0}))"
            }
        }
    }

The first line checks for the existence of the policy in the Cisco-AVPair list that has been returned already by authenticating against your SQL DB. If we have that, then we read the Connect-Info AV pair from the request, regex it to return only the value on the left-hand of the "/" then insert this value into an AV pair to be returned.

 

 

bhwillis
Level 1
Level 1

if "bandwidth qos-reference" on the virtual-template is not available in the IOS on your box (and it's not available in the most recent/advanced version), then the "add-class" syntax ("radius-based policing") might work for you:

https://supportforums.cisco.com/docs/DOC-19702

http://www.cisco.com/en/US/docs/ios-xml/ios/isg/configuration/15-1s/isg-radius-pol.html

https://supportforums.cisco.com/thread/2223937

The documentation is not very good & the syntax is horrible, but it's there.  When I tried it on our boxes it removed all the QoS from the virtual-access, but there are others for whom it seems to have worked.

Best of luck.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: