if you want to put a shaper or any form of Qos onto a DSL router, you need to do it via an ATM subinterface, so it looks like:
interface ATM0 description $ES_WAN$ no ip address no ip redirects no ip unreachables no ip proxy-arp ip route-cache flow no ip mroute-cache no atm ilmi-keepalive ! interface ATM0.1 point-to-point pvc 0/38 encapsulation aal5mux ppp dialer dialer pool-member 1 service-policy output shaper
Also, all forms of ATM interfaces do not have any capability to detect congestion, so the hardware simply doesn't know when its saturated and packet loss occurs without any queueing whatsoever. This makes adding Qos challenging because with Ethernet the interface knows when its congested based on its bandwidth and load, this allows an attached Qos policy to kick in. To get around this on an ATM interface, you need to apply a nested shaper at the same bandwidth of the DSL interface. This means the shaper takes the responsibility of detecting the congestion (Cisco call it backpressure) which means once the shaper starts dropping packets the congestion is detected, and the nested Qos policy then kicks in to perform fancy queueing. To configure this outbound on the DSL interface where your upload speed is 768Kbps, you would do the following:
1.> Configure 2x ACL's one matching your critical traffic, and one matching standard traffic.
2.> Configure a marker on the inbound Ethernet interface (vlan1) to mark traffic going into the Ethernet interface (outbound flow), looks like:
class-map match-all markCS5 match access-group 102 class-map match-all markCS1 match access-group 101 ! policy-map marker class markCS5 set ip dscp cs5 class markCS1 set ip dscp cs1 ! Interface Vlan 1 bandwidth 8000 Ip address 1.1.1.1 255.0.0.0 (etc) service-policy input marker
3.> Now traffic is being marked as it hits the Ethernet interface, you need to match it and queue based on the DSCP values, and apply it to the atm subinterface:
class-map match-all critical match ip dscp cs5 class-map match-all standard match ip dscp cs1 ! ! policy-map qospolicyOUT class critical bandwidth 512000 (adjustable values) random-detect dscp-based class standard bandwidth 128000 (adjustable values) random-detect dscp-based ! policy-map shaper class class-default shape peak 768000 service-policy qospolicyOUT ! interface ATM0 description $ES_WAN$ no ip address no ip redirects no ip unreachables no ip proxy-arp ip route-cache flow no ip mroute-cache no atm ilmi-keepalive ! interface ATM0.1 point-to-point pvc 0/38 encapsulation aal5mux ppp dialer dialer pool-member 1 service-policy output shaper
4.> you will now be using CBWFQ (Class based weighted fair queuing) in the outboud direction, but this is only for traffic leaving the router outbound. In order to queue in the other direction you need to reverse the process, by marking inbound on the ATM, setting the values, then queuing outbound on the Vlan interface minus the shaper (As this is now Ethernet) Example where your bandwidth is 8Mbit.
policy-map qospolicyIN class critical bandwidth 5012000 (adjustable values) random-detect dscp-based class standard bandwidth 1028000 (adjustable values) random-detect dscp-based ! interface ATM0 description $ES_WAN$ no ip address no ip redirects no ip unreachables no ip proxy-arp ip route-cache flow no ip mroute-cache no atm ilmi-keepalive ! interface ATM0.1 point-to-point pvc 0/38 encapsulation aal5mux ppp dialer dialer pool-member 1 service-policy output shaper service-policy inbound marker ! Interface Vlan 1 bandwidth 8000 Ip address 1.1.1.1 255.0.0.0 (etc) service-policy input marker service-policy output qospolicyIN
I helped develop and test the IOS that supports this with Cisco a few years ago, but its just basic ATM based Qos for ADSL. Some people will question why I'm adding DSCP values inbound for an internet connection that will set them all to 0. The reason is that it allows the router to use DSCP-Based random early detection, which is very effective with low bandwidth traffic across the router, especially application and TCP. Its far more effective and flexible than standard policing and shaping.
In terms of marking stuff on Vlan1 with a higher priority outbound, you'd simply need to split the class-maps in half and apply one to vlan1 marking everything with CS5, then the other one to vlan2 marking everything with CS1. Outbound queueing and shaping on the atm0.1 will remain the same, obviously this is for outbound traffic only:
class-map match-all markCS5 match access-group 102 class-map match-all markCS1 match access-group 101 ! policy-map markVLAN1 class markCS5 set ip dscp cs5 ! policy-map markVLAN2 class markCS1 set ip dscp cs1 ! Interface Vlan 1 Ip address 1.1.1.1 255.0.0.0 (etc) service-policy input markVLAN1 ! Interface Vlan 2 Ip address 2.2.2.2 255.0.0.0 (etc) service-policy input markVLAN2
In terms of traffic coming back inbound, you will need to split your total available downstream bandwidth into two pieces across each Vlan interface. For example, with 8Mbps available download bandwidth, you may wish hosts on Vlan1 to have 7Mbps of bandwidth, and hosts on Vlan2 to have only 1Mbps of bandwidth inbound. To do this split the original Qos policy in half once again but across Vlan1 and 2 like so:
class-map match-all critical match ip dscp cs5 class-map match-all standard match ip dscp cs1 policy-map Vlan1_IN class critical bandwidth 7000000 (adjustable values) random-detect dscp-based ! policy-map Vlan2_IN class standard bandwidth 1000000 (adjustable values) random-detect dscp-based ! Interface Vlan 1 bandwidth 7000 Ip address 1.1.1.1 255.0.0.0 (etc) service-policy input markVLAN1 service-policy output Vlan1_IN ! Interface Vlan 2 bandwidth 1000 Ip address 2.2.2.2 255.0.0.0 (etc) service-policy input markVLAN2 service-policy output Vlan2_IN
This will allow each Vlan interface to queue according to its own bandwidth statement (7Mbit or 1Mbit) once you start downloading like hell, CBWFQ will kick in and start randomly dropping packets and the rate will be enforced…