Abstract
This white paper provides the guidelines for the QOS implementation in the DSL environment
It also demonstrates the auto-degradation of the Service category/Class of Service parameters or the Service category/Class of Service itself on the PVC using different scenarios when the DSL line trains at a rate lower than the configured guaranteed bandwidth.
Guidelines to be Followed while Configuring Layer 2/Layer 3 QOS on PVC
In the DSL world, PVCs are provisioned by the Service Provider based upon certain service contract for a guaranteed traffic rate and hence provide reliable service to all customers. Service contracts also aid the Service Providers to police the traffic exceeding the requested/granted rate.
DSL flavors of Cisco 800/1800 series Integrated Services Routers fixed configuration models and Cisco DSL High speed WAN interface cards (HWICs) /WAN interface cards (WICs) support PVC with the following service categories to provide the bandwidth guarantee for various applications. (Appendix A provides information on all platforms and DSL HWICs/WICs supporting these features)
Table 1.
The user can choose the appropriate Service category to suffice his network demands and configure the parameters for the Service categories inline with the Service contract of the PVC.
It is important for the user to realize that they are not necessarily restricted to a particular type of service category to carry out their ATM traffic nor they are bound to establish the same service categories on both ends of the link. However, each service category uses certain traffic parameters that best define the transmission characteristic of a type of traffic and will help them to optimize their flow and to meet the requirement of their traffic contract.
Following table provides information on the various traffic parameters available for the different service categories
Table 2.
|
Service Category |
Traffic Parameter Used to Guarantee Cell Rate |
|
CBR |
PCR |
|
nrt-VBR |
SCR |
|
rt-VBR |
SCR |
|
UBR + |
MCR |
|
UBR |
none |
In addition, each service category has a default transmission priority associated with it. Therefore, the user will achieve the best use of the bandwidth and optimize the performance for their traffic if they choose the service category that best represents the type of traffic and applications that will be carried over the PVC. The primary thing to keep in mind is that the ATM service category defines how the ATM network devices and other treat the cells of the VC with respect to bandwidth guarantees, cell delays and cell loss.
The next step would be to configure the QOS on the Layer 3 queues using the MQC (Modular QOS CLI) once the service category along with the required parameters is configured on the PVC.
Following are the list of guidelines that need to be taken care while configuring the QOS on the layer 3 Software Queues
• Service policies providing the Layer 3 QOS using CBWFQ/LLQ have to be applied at the PVC level and should not be done at the interface or sub interface level.
• To provide preferential treatment to voice traffic, the hardware queue length has to be modified in such way that congestion is realized at the output queue on each PVC and hence the software queue (Layer 3 queue) stores the packet in the buffer to be treated by the congestion management mechanism such as (CBWFQ/LLQ).
The length of the hardware queue has to be calculated based on applications in the network that need specialized treatment.
Please refer to Appendix B for guidance on determining the ideal value for the hardware queue-limit
The command to modify the length of the hardware queue on per-pvc basis is
Table 3.
|
Command |
Purpose |
|
tx-ring-limit <specify the length of the queue> |
Modifies the length of the hardware queue |
• Class-Based Traffic shaping is not supported on the DSL interface.
• QOS on Layer 3 queues is not supported on the PVC configured as UBR as there is no bandwidth guarantee provided by the PVC at layer 2. By default all the PVCs are in UBR mode. Hence when the customer requires QOS on Layer 3 queues, the PVC has to be configured as CBR or VBR-rt or VBR-nrt or UBR+ depending on nature of applications in the network.
Deployment Scenarios
Following section focuses on explaining the common deployments done in the field. It also demonstrates the QOS operation at Layer 2 and Layer 3 in each of the scenarios.
Scenario 1:
This is most common scenario, where all the customer traffic flows over single PVC. Bandwidth guarantee at layer two is provided using CBR or VBR or UBR+. Service policy is applied on the PVC to provide layer 3 classifications and bandwidth guarantee for different types of traffic like Voice, Critical data or normal data.
Following scenarios depict the layer 2 and layer 3 QOS functioning on single PVC with different Class of Service at layer 2.
Figure 1. Single PVC with "CBR" Class of Service
In this scenario, PVC is defined with CBR service category having the PCR value of 1500 Kbps. There are two different classes defined to classify the Voice and Critical data information and then bandwidth guarantee is provided to those classes using Service Policy. All other non-classified traffic would fall into the default class which uses Fair-queue for congestion management.
Following are the details on the bandwidth allocation for different applications:
• Class RT: Strict Priority bandwidth of 400 Kbps using LLQ
• Class MC: Assured bandwidth of 200 Kbps using CBWFQ
• Class-Default: Fair-queue
Running Configuration
877(CPE):
Building configuration...
Current configuration : 1623 bytes
!
version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname ADSL_877
!
boot-start-marker
boot-end-marker
!
no aaa new-model
!
resource policy
!
ip cef
!
class-map match-any RT
match ip dscp ef
class-map match-all MC
match ip dscp af43
!
policy-map QOS
class RT
priority 400
class MC
bandwidth 200
class class-default
fair-queue
!
interface ATM0
no ip address
no atm ilmi-keepalive
dsl operating-mode auto
!
interface ATM0.1 point-to-point
ip address 20.1.1.2 255.255.255.0
no snmp trap link-status
pvc 1/99
protocol ip 20.1.1.1 broadcast
cbr 1500
tx-ring-limit 3
service-policy output QOS
!
interface FastEthernet0
duplex full
speed 100
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
!
interface Dot11Radio0
no ip address
shutdown
speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0
54.0
station-role root
!
interface Vlan1
ip address 10.1.1.2 255.255.255.0
ip route 0.0.0.0 0.0.0.0 20.1.1.1
!
no ip http server
no ip http secure-server
control-plane
!
line con 0
exec-timeout 0 0
no modem enable
line aux 0
line vty 0 4
login
!
scheduler max-task-time 5000
end
But as per the setting on the DSLAM profile the line trains-up at only 832 Kbps. Due to this change the CPE automatically downgrades the CBR PVCs PCR rate to 832 Kbps.
Following is the snapshot of the notification sent on the Console:
ADSL_877#
*Mar 21 10:11:56.715: %LINK-3-UPDOWN: Interface ATM0, changed state to up
*Mar 21 10:11:57.715: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM0, changed state to up
*Mar 21 10:12:02.447: %DSLSAR-1-DOWNGRADEDBW: PCR and SCR for VCD 1 (1/99) has been reduced to 832k 832k due to insufficient upstream bandwidth
To confirm the Congestion management mechanism after the downgrade of the PCR rate, three different streams with the following specification were sent:
Traffic matching the RT class (Voice): 370 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 370*8*121 = 358 Kbps)
Traffic matching the MC class (Data): 200 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 200*8*121 = 193 Kbps)
Unclassified Traffic: 1500 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 1500*8*121 = 1.45 Mbps)
The output confirms that the voice and data traffic are received without any drops and only the excess traffic in the default-class is dropped.
Traffic matching the RT class (Voice): 370 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 370*8*121 = 358 Kbps)
Traffic matching the MC class (Data): 200 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 200*8*121 = 193 Kbps)
Unclassified Traffic: 1500 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 89*8*121 = 86 Kbps)
Following is the snapshot taken from the Traffic Generator and Traffic Reflector:
Traffic Details of PVC with PCR rate of 832 Kbps (requested 1500 Kbps as PCR rate):
Generator(TGN:OFF,Fa0/0:3/3)#show send
Summary of sending traffic streams on FastEthernet0/0
ts# template state interval/rate send-amount/left-to-send total-sent
1 IP on 370 pps 0 0 3805
2 IP on 200 pps 0 0 2057
3 IP on 1500 pps 0 0 15424
Reflector(Fast Counting)#show fast-count
Fast-count counts count pps or sec/packet
Interface: FastEthernet0/0
Filter: dscpef incoming 3805 370.002 pps
Filter: dscpaf43 incoming 2057 199.902 pps
Filter: dscpnone incoming 932 89.614 pps
Following snapshot shows the output of the Policy map command on the router while providing the congestion management
Policy Map Output with CBWFQ and LLQ
ADSL_877#show policy-map interface atm 0.1
ATM0.1: VC 1/99 -
Service-policy output: QOS
Class-map: RT (match-any)
3805 packets, 506065 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp ef (46)
3805 packets, 506065 bytes
5 minute rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 72
Bandwidth 400 (kbps) Burst 10000 (Bytes)
(pkts matched/bytes matched) 3805/506065
(total drops/bytes drops) 0/0
Class-map: MC (match-all)
2057 packets, 273581 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp af43 (38)
Queueing
Output Queue: Conversation 73
Bandwidth 200 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 2057/273581
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
15424 packets, 2051392 bytes
5 minute offered rate 36000 bps, drop rate 34000 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 64
(total queued/total drops/no-buffer drops) 0/14492/0
ADSL_877#
Figure 2. Single PVC with "VBR-rt" Class of Service
In this scenario, PVC is defined with VBR-rt service category having PCR value of 1500 Kbps and SCR value of 1500 Kbps. There are two different classes defined to classify the Voice and Critical data information and then bandwidth guarantee is provided to those classes using Service Policy. All other non-classified traffic would fall into the default class which uses Fair-queue for congestion management.
Following are the details on the bandwidth allocation for different applications:
• Class RT: Strict Priority bandwidth of 400 Kbps using LLQ
• Class MC: Assured bandwidth of 200 Kbps using CBWFQ
• Class-Default: Fair-queue
Running Configuration
877(CPE):
Building configuration...
Current configuration : 1393 bytes
!
version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname ADSL_877
!
boot-start-marker
boot-end-marker
!
no aaa new-model
!
resource policy
!
ip cef
!
class-map match-any RT
match ip dscp ef
class-map match-all MC
match ip dscp af43
!
policy-map QOS
class RT
priority 400
class MC
bandwidth 200
class class-default
fair-queue
!
interface ATM0
no ip address
no atm ilmi-keepalive
dsl operating-mode auto
!
interface ATM0.1 point-to-point
ip address 20.1.1.2 255.255.255.0
no snmp trap link-status
pvc 1/99
protocol ip 20.1.1.1 broadcast
vbr-rt 1500 1500
tx-ring-limit 3
service-policy output QOS
!
!
interface FastEthernet0
duplex full
speed 100
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
switchport access vlan 2
!
interface Dot11Radio0
no ip address
shutdown
speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0
54.0
station-role root
!
interface Vlan1
ip address 10.1.1.2 255.255.255.0
!
ip route 30.1.1.0 255.255.255.0 20.1.1.1
!
no ip http server
no ip http secure-server
!
control-plane
!
line con 0
exec-timeout 0 0
no modem enable
line aux 0
line vty 0 4
login
!
scheduler max-task-time 5000
end
ADSL_877#
But as per the setting on the DSLAM profile the line trains-up at only 832 Kbps. Due to this change the CPE automatically downgrades the VBR-rt PVCs PCR rate and SCR rate to 832 Kbps.
Following is the snapshot of the notification sent on the Console:
ADSL_877#
*Mar 21 10:11:56.715: %LINK-3-UPDOWN: Interface ATM0, changed state to up
*Mar 21 10:11:57.715: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM0, changed state to up
*Mar 21 10:12:02.447: %DSLSAR-1-DOWNGRADEDBW: PCR and SCR for VCD 1 (1/99) has been reduced to 832k 832k due to insufficient upstream bandwidth
To confirm the Congestion management mechanism after the downgrade of the PCR and SCR, three different streams with the following specification were sent:
Traffic matching the RT class (Voice): 370 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 370*8*121 = 358 Kbps)
Traffic matching the MC class (Data): 200 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 200*8*121 = 193 Kbps)
Unclassified Traffic: 1500 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 1500*8*121 = 1.45 Mbps)
The output confirms that the voice and data traffic are sent without any drops and only the excess traffic in the default-class is dropped.
Traffic matching the RT class (Voice): 370 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 370*8*121 = 358 Kbps)
Traffic matching the MC class (Data): 200 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 200*8*121 = 193 Kbps)
Unclassified Traffic: 1500 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 87*8*121 = 84 Kbps)
Following is the snapshot taken from the Traffic Generator and Traffic Reflector:
Traffic Details of PVC with PCR and SCR rate of 832 Kbps (requested 1500 Kbps as PCR and SCR rate):
Generator(TGN:OFF,Fa0/0:3/3)#show send
Summary of sending traffic streams on FastEthernet0/0
ts# template state interval/rate send-amount/left-to-send total-sent
1 IP on 370 pps 0 0 8660
2 IP on 200 pps 0 0 4681
3 IP on 1500 pps 0 0 35107
Reflector(Fast Counting)#show fast-count
Fast-count counts count pps or sec/packet
Interface: FastEthernet0/0
Filter: dscpef incoming 8660 370.011 pps
Filter: dscpaf43 incoming 4681 200.017 pps
Filter: dscpnone incoming 2033 86.460 pps
Following snapshot shows the output of the Policy map command on the router while providing the congestion management
Policy Map Output with CBWFQ and LLQ
ADSL_877#show policy-map interface atm0.1
ATM0.1: VC 1/99 -
Service-policy output: QOS
Class-map: RT (match-any)
8660 packets, 1151780 bytes
5 minute offered rate 32000 bps, drop rate 0 bps
Match: ip dscp ef (46)
8660 packets, 1151780 bytes
5 minute rate 32000 bps
Queueing
Strict Priority
Output Queue: Conversation 72
Bandwidth 400 (kbps) Burst 10000 (Bytes)
(pkts matched/bytes matched) 8660/1151780
(total drops/bytes drops) 0/0
Class-map: MC (match-all)
4681 packets, 622573 bytes
5 minute offered rate 20000 bps, drop rate 0 bps
Match: ip dscp af43 (38)
Queueing
Output Queue: Conversation 73
Bandwidth 200 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 4681/622573
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
35107 packets, 4669231 bytes
5 minute offered rate 123000 bps, drop rate 114000 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 64
(total queued/total drops/no-buffer drops) 0/33074/0
ADSL_877#
Figure 3. Single PVC with "UBR+" Class of Service
In this scenario, PVC is defined with UBR+ service category having PCR value of 1500 Kbps and MCR value of 1500 Kbps. There are two different classes defined to classify the Voice and Critical data information and then bandwidth guarantee is provided to those classes using Service Policy. All other non-classified traffic would fall into the default class which uses Fair-queue for congestion management.
Following are the details on the bandwidth allocation for different applications
• Class RT: Strict Priority bandwidth of 400 Kbps using LLQ
• Class MC: Assured bandwidth of 200 Kbps using CBWFQ
• Class-Default: Fair-queue
Running Configuration
877(CPE):
Building configuration...
Current configuration : 1452 bytes
!
version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname ADSL-877
!
boot-start-marker
boot-end-marker
!
enable password lab
!
no aaa new-model
!
resource policy
!
memory-size iomem 25
ip cef
!
!
class-map match-any RT
match ip dscp ef
class-map match-all MC
match ip dscp af43
!
!
policy-map QOS
class RT
priority 400
class MC
bandwidth 200
class class-default
fair-queue
!
!
interface ATM0
no ip address
no atm ilmi-keepalive
dsl operating-mode auto
!
interface ATM0.1 point-to-point
ip address 20.1.1.2 255.255.255.0
no snmp trap link-status
pvc 0/34
protocol ip 20.1.1.1 broadcast
ubr+ 1500 1500
tx-ring-limit 3
service-policy output QOS
!
!
interface FastEthernet0
speed 100
!
interface FastEthernet1
shutdown
!
interface FastEthernet2
shutdown
!
interface FastEthernet3
duplex full
speed 10
!
interface Dot11Radio0
no ip address
shutdown
speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0
station-role root
!
interface Vlan1
ip address 10.1.1.2 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 20.1.1.1
!
!
no ip http server
no ip http secure-server
!
!
control-plane
!
!
line con 0
exec-timeout 0 0
no modem enable
line aux 0
line vty 0 4
login
!
scheduler max-task-time 5000
!
webvpn context Default_context
ssl authenticate verify all
!
no inservice
!
end
ADSL-877#
But as per the setting on the DSLAM profile the line trains-up at only 832 Kbps. Due to this change the CPE automatically downgrades the UBR+ PVCs PCR rate and MCR rate to 832 Kbps.
Following is the snapshot of the notification sent on the Console:
ADSL-877#
*May 2 17:12:43.367: %LINK-3-UPDOWN: Interface ATM0, changed state to down
*May 2 17:14:01.627: %LINK-3-UPDOWN: Interface ATM0, changed state to up
*May 2 17:14:02.627: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM0, changed state to up
*May 2 17:14:07.215: %DSLSAR-1-DOWNGRADEDBW: PCR and SCR for VCD 1 (0/34) has been reduced to 832k 832k due to insufficient upstream bandwidth
ADSL-877#
To confirm the Congestion management mechanism after the downgrade of the PCR and MCR, three different streams with the following specification were sent:
Traffic matching the RT class (Voice): 370 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 370*8*121 = 358 Kbps)
Traffic matching the MC class (Data): 200 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 200*8*121 = 193 Kbps)
Unclassified Traffic: 1500 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 1500*8*121 = 1.45 Mbps)
The output confirms that the voice and data traffic are sent without any drops and only the excess traffic in the default-class is dropped.
Traffic matching the RT class (Voice): 370 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 370*8*121 = 358 Kbps)
Traffic matching the MC class (Data): 200 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 200*8*121 = 193 Kbps)
Unclassified Traffic: 1500 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 85*8*121 = 83 Kbps)
Following is the snapshot taken from the Traffic Generator and Traffic Reflector:
Traffic Details of PVC with PCR and MCR rate of 832 Kbps (requested 1500 Kbps as PCR and MCR rate):
Generator(TGN:OFF,Fa2/1:3/3)#show send
Summary of sending traffic streams on FastEthernet2/1
ts# template state interval/rate send-amount/left-to-send total-sent
1 IP on 370 pps 0 0 11398
2 IP on 200 pps 0 0 6161
3 IP on 1500 pps 0 0 46207
Generator(TGN:OFF,Fa2/1:3/3)#
Reflector(FastCounting)#show fast-count
Fast-count counts count pps or sec/packet
Interface: FastEthernet2/0
Filter: dscpef incoming 11398 369.984 pps
Filter: dscpaf43 incoming 6161 200.000 pps
Filter: dscpnone incoming 2656 85.911 pps
Reflector(FastCounting)#
Following snapshot shows the output of the Policy map command on the router while providing the congestion management
Policy Map Output with CBWFQ and LLQ
ADSL-877#sh policy-map int atm 0.1
ATM0.1: VC 0/34 -
Service-policy output: QOS
Class-map: RT (match-any)
13951 packets, 1855483 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp ef (46)
13951 packets, 1855483 bytes
5 minute rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 72
Bandwidth 400 (kbps) Burst 10000 (Bytes)
(pkts matched/bytes matched) 13951/1855483
(total drops/bytes drops) 0/0
Class-map: MC (match-all)
8204 packets, 1091132 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp af43 (38)
Queueing
Output Queue: Conversation 73
Bandwidth 200 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 8204/1091132
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
66634 packets, 8862322 bytes
5 minute offered rate 35000 bps, drop rate 32000 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 64
(total queued/total drops/no-buffer drops) 0/55146/0
ADSL-877#
Scenario 2:
Figure 4.
Two Point-to-Point PVCs are defined with CBR service category, with one having the PCR rate as 400 Kbps and the other with 600 Kbps. There are two different classes defined to classify the Voice and Critical data information. All other non-classified traffic would fall into the default class which uses Fair-queue for congestion management.
Then the same Service Policy providing the bandwidth guarantee with above defined classes is configured on both the PVCs.
Following are the details on the bandwidth allocation for different applications
• Class RT: Strict Priority bandwidth of 150 Kbps using LLQ
• Class MC: Assured bandwidth of 100 Kbps using CBWFQ
• Class-Default: Fair-queue
Running Configuration
877(CPE):
Building configuration...
Current configuration : 1623 bytes
!
version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname ADSL_877
!
boot-start-marker
boot-end-marker
!
no aaa new-model
!
resource policy
!
ip cef
!
class-map match-any RT
match ip dscp ef
class-map match-all MC
match ip dscp af43
!
policy-map QOS
class RT
priority 150
class MC
bandwidth 100
class class-default
fair-queue
!
interface ATM0
no ip address
no atm ilmi-keepalive
dsl operating-mode auto
!
interface ATM0.1 point-to-point
ip address 20.1.1.2 255.255.255.0
no snmp trap link-status
pvc 1/99
protocol ip 20.1.1.1 broadcast
cbr 400
tx-ring-limit 3
service-policy output QOS
!
interface ATM0.2 point-to-point
ip address 40.1.1.2 255.255.255.0
no snmp trap link-status
pvc 2/99
protocol ip 40.1.1.1 broadcast
cbr 600
tx-ring-limit 3
service-policy output QOS
!
interface FastEthernet0
duplex full
speed 100
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
switchport access vlan 2
!
interface Dot11Radio0
no ip address
shutdown
speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0
54.0
station-role root
!
interface Vlan1
ip address 10.1.1.2 255.255.255.0
!
interface Vlan2
ip address 50.1.1.1 255.255.255.0
!
ip route 30.1.1.0 255.255.255.0 20.1.1.1
ip route 70.1.1.0 255.255.255.0 40.1.1.1
!
no ip http server
no ip http secure-server
!
control-plane
!
line con 0
exec-timeout 0 0
no modem enable
line aux 0
line vty 0 4
login
!
scheduler max-task-time 5000
end
But as per the setting on the DSLAM profile the line trains-up at only 832 Kbps. Due to this change, CPE is able to grant the requested bandwidth to the first PVC alone i.e. 400 Kbps. The second PVC which requested 600 Kbps is provided only the remaining 432 Kbps as PCR rate.
Following is the snapshot of the notification sent on the Console:
ADSL_877#
*Mar 22 01:01:00.671: %LINK-3-UPDOWN: Interface ATM0, changed state to up
*Mar 22 01:01:01.671: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM0, changed state to up
*Mar 22 01:01:05.075: %DSLSAR-1-DOWNGRADEDBW: PCR and SCR for VCD 2 (2/99) has been reduced to 432k 432k due to insufficient upstream bandwidth
To confirm the Congestion management mechanism after the downgrade of the PCR rate, three different streams with the following specification were sent on each PVC simultaneously:
PVC 1:
Traffic matching the RT class (Voice): 370 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 125*8*121 = 121 Kbps)
Traffic matching the MC class (Data): 200 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 100*8*121 = 97 Kbps)
Unclassified Traffic: 1500 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 1000*8*121 = 968 Kbps)
The output confirms that the voice and data traffic are sent without any drops and only the excess traffic in the default-class is dropped.
Traffic matching the RT class (Voice): 370 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 125*8*121 = 121 Kbps)
Traffic matching the MC class (Data): 200 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 100*8*121 = 97 Kbps)
Unclassified Traffic: 1500 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 93*8*121 = 90 Kbps)
PVC 2:
Traffic matching the RT class (Voice): 370 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 125*8*121 = 121 Kbps)
Traffic matching the MC class (Data): 200 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 100*8*121 = 97 Kbps)
Unclassified Traffic: 1500 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 1000*8*121 = 968 Kbps)
The output confirms that the voice and data traffic are sent without any drops and only the excess traffic in the default-class is dropped.
Traffic matching the RT class (Voice): 370 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 125*8*121 = 121 Kbps)
Traffic matching the MC class (Data): 200 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 100*8*121 = 97 Kbps)
Unclassified Traffic: 1500 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 118*8*121 = 114 Kbps)
Following is the snapshot taken from the Traffic Generator and Traffic Reflector:
Traffic Details for PVC 1 with PCR rate of 400 Kbps :
Generator(TGN:OFF,Fa0/0:3/3)#show send
Summary of sending traffic streams on FastEthernet0/0
ts# template state interval/rate send-amount/left-to-send total-sent
1 IP on 125 pps 0 0 1709
2 IP on 100 pps 0 0 1367
3 IP on 1000 pps 0 0 13676
Reflector(Fast Counting)#show fast-count
Fast-count counts count pps or sec/packet
Interface: FastEthernet0/0
Filter: dscpef incoming 1709 125.018 pps
Filter: dscpaf43 incoming 1367 99.985 pps
Filter: dscpnone incoming 1288 92.676 pps
Traffic Details for PVC 2 with PCR rate of 432 Kbps (requested 600 Kbps as PCR rate):
Generator(TGN:OFF,Fa0/0:3/3)#show send
Summary of sending traffic streams on FastEthernet0/0
ts# template state interval/rate send-amount/left-to-send total-sent
1 IP on 125 pps 0 0 1627
2 IP on 100 pps 0 0 1302
3 IP on 1000 pps 0 0 13017
Reflector(Fast Counting)#show fast-count
Fast-count counts count pps or sec/packet
Interface: FastEthernet0/0
Filter: dscpef incoming 1627 124.990 pps
Filter: dscpaf43 incoming 1302 100.007 pps
Filter: dscpnone incoming 1559 117.869 pps
Following snapshot shows the output of the Policy map command on the router while providing the congestion management
Following snapshot shows the output of the Policy map command on the router while providing the congestion management
PVC 1:
DSL_877#sh policy-map interface atm0.1
ATM0.1: VC 1/99 -
Service-policy output: QOS
Class-map: RT (match-any)
1709 packets, 227297 bytes
5 minute offered rate 34000 bps, drop rate 0 bps
Match: ip dscp ef (46)
1709 packets, 227297 bytes
5 minute rate 34000 bps
Queueing
Strict Priority
Output Queue: Conversation 40
Bandwidth 150 (kbps) Burst 3750 (Bytes)
(pkts matched/bytes matched) 1709/227297
(total drops/bytes drops) 0/0
Class-map: MC (match-all)
1367 packets, 181811 bytes
5 minute offered rate 27000 bps, drop rate 0 bps
Match: ip dscp af43 (38)
Queueing
Output Queue: Conversation 41
Bandwidth 100 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 1367/181811
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
13676 packets, 1818908 bytes
5 minute offered rate 292000 bps, drop rate 274000 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 32
(total queued/total drops/no-buffer drops) 0/12388/0
ADSL_877#
PVC 2:
ADSL_877#show policy-map interface atm0.2
ATM0.2: VC 2/99 -
Service-policy output: QOS
Class-map: RT (match-any)
1627 packets, 216391 bytes
5 minute offered rate 6000 bps, drop rate 0 bps
Match: ip dscp ef (46)
1627 packets, 216391 bytes
5 minute rate 6000 bps
Queueing
Strict Priority
Output Queue: Conversation 72
Bandwidth 150 (kbps) Burst 3750 (Bytes)
(pkts matched/bytes matched) 1627/216391
(total drops/bytes drops) 0/0
Class-map: MC (match-all)
1302 packets, 173166 bytes
5 minute offered rate 6000 bps, drop rate 0 bps
Match: ip dscp af43 (38)
Queueing
Output Queue: Conversation 73
Bandwidth 100 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 1302/173166
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
13017 packets, 1731261 bytes
5 minute offered rate 97000 bps, drop rate 85000 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 64
(total queued/total drops/no-buffer drops) 0/11458/0
ADSL_877#
Scenario 3:
Figure 5.
Two Point-to-Point PVCs are configured with CBR and VBR-rt service category .The PCR rate for the CBR PVC is 400 Kbps and the PCR and SCR rate for the VBR-rt PVC is 700 Kbps. There are two different classes defined to classify the Voice and Critical data information. All other non-classified traffic would fall into the default class which uses Fair-queue for congestion management.
Then the same Service Policy providing the bandwidth guarantee with above defined classes is configured on both the PVCs.
Following are the details on the bandwidth allocation for different applications
• Class RT: Strict Priority bandwidth of 150 Kbps using LLQ
• Class MC: Assured bandwidth of 100 Kbps using CBWFQ
• Class-Default: Fair-queue
Running Configuration
877(CPE):
Building configuration...
Current configuration : 1630 bytes
!
version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname ADSL_877
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!
resource policy
!
ip cef
!
class-map match-any RT
match ip dscp ef
class-map match-all MC
match ip dscp af43
!
!
policy-map QOS
class RT
priority 150
class MC
bandwidth 100
class class-default
fair-queue
!
interface ATM0
no ip address
no atm ilmi-keepalive
dsl operating-mode auto
!
interface ATM0.1 point-to-point
ip address 20.1.1.2 255.255.255.0
no snmp trap link-status
pvc 1/99
protocol ip 20.1.1.1 broadcast
cbr 400
tx-ring-limit 3
service-policy output QOS
!
!
interface ATM0.2 point-to-point
ip address 40.1.1.2 255.255.255.0
no snmp trap link-status
pvc 2/99
protocol ip 40.1.1.1 broadcast
vbr-rt 700 700
tx-ring-limit 3
service-policy output QOS
!
!
interface FastEthernet0
duplex full
speed 100
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
switchport access vlan 2
!
interface Dot11Radio0
no ip address
shutdown
speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0
54.0
station-role root
!
interface Vlan1
ip address 10.1.1.2 255.255.255.0
!
interface Vlan2
ip address 50.1.1.1 255.255.255.0
!
ip route 30.1.1.0 255.255.255.0 20.1.1.1
ip route 70.1.1.0 255.255.255.0 40.1.1.1
!
!
no ip http server
no ip http secure-server
!
control-plane
!
!
line con 0
exec-timeout 0 0
no modem enable
line aux 0
line vty 0 4
login
!
scheduler max-task-time 5000
end
ADSL_877#
But as per the setting on the DSLAM profile the line trains-up at only 832 Kbps. Due to this change, CPE is able to grant the requested bandwidth to the first PVC alone ie 400 Kbps. The second PVC is which requested 700 Kbps for both PCR and SCR is provided only the remaining 432 Kbps as PCR and SCR rate.
Following is the snapshot of the notification sent on the Console:
ADSL_877#
*Mar 22 01:01:00.671: %LINK-3-UPDOWN: Interface ATM0, changed state to up
*Mar 22 01:01:01.671: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM0, changed state to up
*Mar 22 01:01:05.075: %DSLSAR-1-DOWNGRADEDBW: PCR and SCR for VCD 2 (2/99) has been reduced to 432k 432k due to insufficient upstream bandwidth
To confirm the Congestion management mechanism after the downgrade of the PCR rate and SCR rate, three different streams with the following specification were sent were sent on each PVC simultaneously:
PVC 1:
Traffic matching the RT class (Voice): 370 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 125*8*121 = 121 Kbps)
Traffic matching the MC class (Data): 200 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 100*8*121 = 97 Kbps)
Unclassified Traffic: 1500 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 1000*8*121 = 968 Kbps)
The output confirms that the voice and data traffic are sent without any drops and only the excess traffic in the default-class is dropped.
Traffic matching the RT class (Voice): 370 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 125*8*121 = 121 Kbps)
Traffic matching the MC class (Data): 200 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 100*8*121 = 97 Kbps)
Unclassified Traffic: 1500 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 92*8*121 = 89 Kbps)
PVC 2:
Traffic matching the RT class (Voice): 370 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 125*8*121 = 121 Kbps)
Traffic matching the MC class (Data): 200 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 100*8*121 = 97 Kbps)
Unclassified Traffic: 1500 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 1000*8*121 = 968 Kbps)
The output confirms that the voice and data traffic are sent without any drops and only the excess traffic in the default-class is dropped.
Traffic matching the RT class (Voice): 370 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 125*8*121 = 121 Kbps)
Traffic matching the MC class (Data): 200 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 100*8*121 = 97 Kbps)
Unclassified Traffic: 1500 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 117*8*121 = 113 Kbps)
Following is the snapshot taken from the Traffic Generator and Traffic Reflector:
Traffic Details for PVC 1 with PCR rate of 400 Kbps :
Generator(TGN:OFF,Fa0/0:3/3)#show send
Summary of sending traffic streams on FastEthernet0/0
ts# template state interval/rate send-amount/left-to-send total-sent
1 IP on 125 pps 0 0 2004
2 IP on 100 pps 0 0 1603
3 IP on 1000 pps 0 0 16033
Reflector(Fast Counting)#show fast-count
Fast-count counts count pps or sec/packet
Interface: FastEthernet0/0
Filter: dscpef incoming 2004 124.945 pps
Filter: dscpaf43 incoming 1603 100.031 pps
Filter: dscpnone incoming 1497 92.101 pps
Traffic Details for PVC 2 with PCR and SCR rate of 432 Kbps (originally requested 700 Kbps as PCR and SCR rate):
Generator(TGN:OFF,Fa0/0:3/3)#show send
Summary of sending traffic streams on FastEthernet0/0
ts# template state interval/rate send-amount/left-to-send total-sent
1 IP on 125 pps 0 0 2310
2 IP on 100 pps 0 0 1848
3 IP on 1000 pps 0 0 18475
Reflector(Fast Counting)#show fast-count
Fast-count counts count pps or sec/packet
Interface: FastEthernet0/0
Filter: dscpef incoming 2310 124.986 pps
Filter: dscpaf43 incoming 1848 99.978 pps
Filter: dscpnone incoming 2180 116.736 pps
Following snapshot shows the output of the Policy map command on the router while providing the congestion management
Policy Map Output with CBWFQ and LLQ
PVC 1:
ADSL_877#sh policy-map interface atm0.1
ATM0.1: VC 1/99 -
Service-policy output: QOS
Class-map: RT (match-any)
2004 packets, 266532 bytes
5 minute offered rate 2000 bps, drop rate 0 bps
Match: ip dscp ef (46)
2004 packets, 266532 bytes
5 minute rate 2000 bps
Queueing
Strict Priority
Output Queue: Conversation 40
Bandwidth 150 (kbps) Burst 3750 (Bytes)
(pkts matched/bytes matched) 2004/266532
(total drops/bytes drops) 0/0
Class-map: MC (match-all)
1603 packets, 213199 bytes
5 minute offered rate 1000 bps, drop rate 0 bps
Match: ip dscp af43 (38)
Queueing
Output Queue: Conversation 41
Bandwidth 100 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 1603/213199
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
16033 packets, 2132389 bytes
5 minute offered rate 108000 bps, drop rate 101000 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 32
(total queued/total drops/no-buffer drops) 0/14536/0
ADSL_877#
PVC 2:
ADSL_877#sh policy-map interface atM 0.2
ATM0.2: VC 2/99 -
Service-policy output: QOS
Class-map: RT (match-any)
2310 packets, 307230 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp ef (46)
2310 packets, 307230 bytes
5 minute rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 72
Bandwidth 150 (kbps) Burst 3750 (Bytes)
(pkts matched/bytes matched) 2310/307230
(total drops/bytes drops) 0/0
Class-map: MC (match-all)
1848 packets, 245784 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp af43 (38)
Queueing
Output Queue: Conversation 73
Bandwidth 100 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 1848/245784
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
18475 packets, 2457175 bytes
5 minute offered rate 48000 bps, drop rate 43000 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 64
(total queued/total drops/no-buffer drops) 0/16295/0
ADSL_877#
Scenario 4:
Figure 6.
In this scenario, Cisco 877/1801 series Integrated Services Router Cisco 877/1801 series Integrated Services Router acts as an external modem functioning in transparent bridging mode. Cisco 877/1801 series Integrated Services Router is connected to a Cisco 871 series Integrated Services Router with FastEthernet interface as the WAN interface.
In typical deployments, Cisco 871 series Integrated Services Routers are normally used behind a modem (Cable/DSL modem) will not be able to detect the congestion. And hence turning on the queuing mechanism (LLQ/CBWFQ) may not produce the desired effect. Hence it is recommended to apply traffic shaping (CBTS) so that the traffic flow matches the modem characteristics (Cisco 877/1801 series Integrated Services Router) before we can apply LLQ/CBWFQ on Cisco 871 series Integrated Services Router.
The PVC on Cisco 877/1801 series Integrated Services Router is defined with CBR service category having the PCR value of 1500 Kbps.
On Cisco 871 series Integrated Services Router, there are two different classes defined to classify the Voice and Critical data information and then bandwidth guarantee is provided to those classes using Service Policy. All other non-classified traffic would fall into the default class which uses Fair-queue for congestion management.
Following are the details on the bandwidth allocation for different applications
• Class RT: Strict Priority bandwidth of 400 Kbps using LLQ
• Class MC: Assured bandwidth of 200 Kbps using CBWFQ
• Class-Default: Fair-queue
A parent policy is defined with average shaping rate of 832 Kbps .Then the service policy defined above (with different classes for Voice and critical data) is used as the child policy under the parent policy. This method of referencing a child policy under another parent policy is defined as Hierarchical QOS.
By following the above defined deployment method, Cisco 871 series Integrated Services Router would get synchronized to external modem characteristics and queuing mechanism would fetch the expected results.
Running Configuration
877 (External Modem):
877#sh running-config
Building configuration...
Current configuration : 1084 bytes
!
version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname 877
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
no ip routing
no ip cef
!
!
multilink bundle-name authenticated
!
!
!
interface ATM0
no ip address
no ip route-cache
no atm ilmi-keepalive
dsl operating-mode auto
!
interface ATM0.1 point-to-point
no ip route-cache
no snmp trap link-status
pvc 17/75
cbr 1500
encapsulation aal5snap
!
bridge-group 1
!
interface FastEthernet0
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
!
interface Dot11Radio0
no ip address
no ip route-cache
shutdown
speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0
54.0
station-role root
!
interface Vlan1
no ip address
no ip route-cache
bridge-group 1
!
!
!
no ip http server
no ip http secure-server
!
!
!
control-plane
!
bridge 1 protocol ieee
!
line con 0
no modem enable
line aux 0
line vty 0 4
login
!
scheduler max-task-time 5000
end
877#
871(CPE):
871#show running-config
Building configuration...
Current configuration : 1215 bytes
!
version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname 871
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
ip cef
!
!
multilink bundle-name authenticated
!
!
class-map match-any RT
match ip dscp ef
class-map match-all MC
match ip dscp af43
!
!
policy-map QOS
class RT
priority 400
class MC
bandwidth 200
class class-default
fair-queue
policy-map parent
class class-default
shape average 832000
service-policy QOS
!
!
interface FastEthernet0
duplex full
speed 100
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
!
interface FastEthernet4
ip address 10.1.1.1 255.255.255.0
duplex auto
speed auto
service-policy output parent
!
interface Dot11Radio0
no ip address
shutdown
speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0
54.0
station-role root
!
interface Vlan1
ip address 20.1.1.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 FastEthernet4
!
!
no ip http server
no ip http secure-server
!
!
control-plane
!
!
line con 0
no modem enable
line aux 0
line vty 0 4
!
scheduler max-task-time 5000
end
871#
But as per the setting on the DSLAM profile the line trains-up at only 832 Kbps. Due to this change the Cisco 877/1801 series Integrated Services Router automatically downgrades the CBR PVCs PCR rate to 832 Kbps.
Following is the snapshot of the notification sent on the Console:
877#
*May 8 06:03:55.167: %LINK-3-UPDOWN: Interface ATM0, changed state to up
*May 8 06:03:56.167: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM0, changed state to up
*May 8 06:04:01.575: %DSLSAR-1-DOWNGRADEDBW: PCR and SCR for VCD 1 (17/75) has been reduced to 832k 832k due to insufficient upstream bandwidth
To confirm the Congestion management mechanism after the downgrade of the PCR rate, three different streams with the following specification were sent on the PVC.
Traffic matching the RT class (Voice): 370 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 125*8*121 = 121 Kbps)
Traffic matching the MC class (Data): 200 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 100*8*121 = 97 Kbps)
Unclassified Traffic: 1500 PPS (Resultant Layer 3 Throughput sent = PPS*8*Packet size = 1000*8*121 = 968 Kbps)
The output confirms that the voice and data traffic are sent without any drops and only the excess traffic in the default-class is dropped.
Traffic matching the RT class (Voice): 370 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 125*8*121 = 121 Kbps)
Traffic matching the MC class (Data): 200 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 100*8*121 = 97 Kbps)
Unclassified Traffic: 1500 PPS (Resultant Layer 3 Throughput received = PPS*8*Packet size = 266*8*121 = 257 Kbps)
Following is the snapshot taken from the Traffic Generator and Traffic Reflector:
Traffic Details of PVC with PCR rate of 832 Kbps (requested 1500 Kbps as PCR rate):
Generator(TGN:OFF,Fa0/0:3/3)#show send
Summary of sending traffic streams on FastEthernet0/0
ts# template state interval/rate send-amount/left-to-send total-sent
1 IP on 125 pps 0 0 7288
2 IP on 100 pps 0 0 5830
3 IP on 800 pps 0 0 46645
Generator(TGN:OFF,Fa0/0:3/3)#
Reflector(FastCounting)#show fast-count
Fast-count counts count pps or sec/packet
Interface: FastEthernet0/0
Filter: dscpef incoming 7287 124.768 pps
Filter: dscpaf43 incoming 5829 99.808 pps
Filter: dscpnone incoming 15569 266.101 pps
Following snapshot shows the output of the Policy map command on the router while providing the congestion management
Policy Map Output with CBWFQ and LLQ on 871
871#sh policy-map interface f4
FastEthernet4
Service-policy output: parent
Class-map: class-default (match-any)
59765 packets, 8068719 bytes
5 minute offered rate 336000 bps, drop rate 73000 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
832000/832000 5200 20800 20800 25 2600
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 45020 6078144 44905 6062397 no
Service-policy : QOS
Class-map: RT (match-any)
7288 packets, 983880 bytes
5 minute offered rate 43000 bps, drop rate 0 bps
Match: ip dscp ef (46)
7288 packets, 983880 bytes
5 minute rate 43000 bps
Queueing
Strict Priority
Output Queue: Conversation 72
Bandwidth 400 (kbps) Burst 10000 (Bytes)
(pkts matched/bytes matched) 7273/981855
(total drops/bytes drops) 0/0
Class-map: MC (match-all)
5830 packets, 787050 bytes
5 minute offered rate 38000 bps, drop rate 0 bps
Match: ip dscp af43 (38)
Queueing
Output Queue: Conversation 73
Bandwidth 200 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 5819/785565
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
46647 packets, 6297789 bytes
5 minute offered rate 257000 bps, drop rate 73000 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 64
(total queued/total drops/no-buffer drops) 0/14745/0
871#
Appendix A
Routers/DSL HWICs/WICs supporting different ATM service category/class of service to provide preferential treatment for different applications
Table 4.
Appendix B
Guidelines for determining appropriate Hardware-Queue Length
The transmit ring serves as a staging area for packets in line to be transmitted. The router needs to enqueue a sufficient number of packets on the transmit ring and guarantee that the interface driver has packets with which to fill available cell timeslots.
The primary reason to tune the transmit ring is to reduce latency caused by queuing on the hardware queue. When tuning the transmit ring, consider the following:
• On any network interface, queuing forces a choice between latency and the amount of burst that the interface can sustain. Larger queue sizes sustain longer bursts while increasing delay. Tune the size of a queue when you feel the VC's traffic is experiencing unnecessary delay.
• Consider the packet size. Configure a tx-ring-limit value that accommodates four packets. For example, if your packets are 1500 bytes, set a tx-ring-limit value of 16 = (4 packets) * (4 particles).
• Configure a low value with low-bandwidth VCs, such as a 128 kbps SCR. For example, on a low-speed VC with an SCR of 160 kbps, a tx-ring-limit of ten is relatively high and can lead to significant latency (for example, hundreds of milliseconds) in the driver-level queue. Tune the tx-ring-limit down to its minimum value in this configuration.
In other words, the size of the transmit ring needs to be small enough to avoid introducing latency due to queuing, and it needs to be large enough to avoid drops and a resulting impact to TCP-based flows.
An interface first removes the packets from the layer-3 queuing system and then queues them on the transmit ring. Service policies apply only to packets in the layer-3 queues and are transparent to the transmit ring.
Queuing on the transmit ring introduces a serialization delay that is directly proportional to the depth of the ring. An excessive serialization delay can impact latency budgets for delay-sensitive applications such as voice.
Thus, Cisco recommends reducing the size of the transmit ring for VCs carrying voice. This will help ensure that the packets are queued in the layer 3 queues and appropriate priority can be given to voice packets using LLQ.
Select a value based on the amount of serialization delay, expressed in seconds, introduced by the transmit ring. Use the following formula:
• ((P*8)*D)/S
• P = Packet size in bytes. Multiply by eight to convert to bits.
• D = Transmit-ring depth.
• S = Speed of the VC in bps.