Hi Waris,
Thanks very much for the detailed email. It really helps to get
information on default queue-sizes and improvements on the road-map.
I was wondering if when using many EVCs on a physical interface, is
there any difference between applying a policy on the physical port vs
individual policies on each EVC (in terms of queue-limit and buffers).
That is if you apply the policy per EVC will each EVC have separate QoS
resources (such as buffer space)? I am trying to work out if it is
better to apply polices to the port or the service instance.
Lastly is there any way to match at the "vlan level" when the EVC is
matching untagged or default traffic? I have tried but haven't been
able to get a successful config for this.
Thanks
Ivan
On 27/Aug/2012 4:34 p.m., Waris Sagheer (waris) wrote:
Problem Statement:
When there is a speed mismatch that is 10 Gig ingress interface/1Gig egress
interface or 1 Gig ingress interface/100M egress interface, microbursts can
happen.
For example, 10 Gig Ingress interface----->1 Gig Egress Interface
Traffic rate 500 M, traffic direction 10 Gig to 1 Gig interface. Instantaneous
burst is possible which can cause the default queue buffers to run out at
egress interface resulting in packet drops at the 1 Gig egress interface..
ME3800X/ME3600X/ME3600X-24CX default queue-limit values in time and bytes for
10/100/1000/10000 Mbps Interfaces:
In Bytes:
10/100/1000/10000 Mbps --> 12/12/12/120 Kbytes respectively
In Time:
10/100/1000/10000 Mbps --> 10000/1000/100/100 usec respectively
How to fix this problem?
Current Solution:
Increase the queue-limit by using the "queue-limit xx" command.
Queue-Limit Ranges:
200 to 491520 bytes
1 to 3932 us
1 to 2457 packets (Assuming 1 packet = 200 bytes) [Packet unit is supported in
15.1(2)EY]
How to pick the right value?
Currently there is no other way except for trial and error. It is best to start
from 200K Bytes and monitor the drops. Increase the queue-limit if the drops
are still seen.
Roadmap Queue-limit Feature Enhancements to fix this issue:
Step 1:We are planning to increase the default queue-limit to 40KB increase of
12 KB in case of 1Gig interface.
Step 2:We are planning to introduce a feature called flexible queue-limit in
Release 15.3(1)S, Q4CY12 which would allow the queue-limit to be increases as
percentages of buffer.
Similar feature is supported on ME3400E.
http://www.cisco.com/en/US/docs/switches/metro/me3400e/software/release/12.2_58_ex/command/reference/cli1.html#wp5095786
Step 3:To pick the right value, watermark counter will be introduced in 2HCY13
which will record the maximum tail drop value. This will enable the customers
to tweak their queue-limit value accordingly. The feature is currently
available in IOS XR.
Queue-limit Value Configuration:
12.xx Release Output
Example of user configurable queue limit value,
Switch(config-pmap-c)#queue-limit ?
<1-491520> <200-491520> in bytes, <1-3932> in us, maximum threshold (in
us by default)
15.xx Outputs
There is an issue with the command help which shows higher value than supported
by the platform, it will be fixed in the future release.
ME3800X-H-1(config-pmap-c)#queue-limit ?
<1-8192000> in bytes, <1-3400> in ms, <1-8192000> in packets by default
<< Range is shown higher than the platform can support
ME3800X-H-1(config-pmap-c)#queue-limit 8192000 bytes
QOS: Qlimit threshold value is out of range
Min and Max bytes qlimit are 200 & 491520 <<< Valid supported range
queue-limit: platform params check fail
ME3800X-H-1(config-pmap-c)#queue-limit 2500 packets
QOS: Qlimit threshold value is out of range
Min and Max packets qlimit are 1 & 2457 << Valid supported range
queue-limit: platform params check fail
Queue-Limit Policy Configuration Example:
In many cases QoS policy will only be required to help with the issue of packet
drops. ME platforms support three level hiearchy [Port, Vlan & Class] and
Queue-limit is only supported at the class or third level.
Valid supported Queue-limit Policy Example:
class-map match-all vlan60
match vlan 60
!
policy-map EFP-qlimit
class vlan60 <<<<< Using vlan level confirms it is the
second level and the child policy is the third level
shape average 100000000
service-policy COS-OUT-L3-NSP
!
policy-map COS-OUT-L3-NSP
class class-default
queue-limit 256 packets
interface GigabitEthernet0/5
switchport trunk allowed vlan none
switchport mode trunk
service instance 2 ethernet
encapsulation dot1q 60
rewrite ingress tag pop 1 symmetric
service-policy output EFP-qlimit
bridge-domain 60
Three Level Class-default Policy Example:
policy-map leaf
class class-default
queue-limit xxxxx bytes
policy-map logical
class class-default
service-policy leaf
policy-map root
class class-default
service-policy logical
Invalid Queue-Limit Policy Configuration Example:
This case "class-default" is being considered as the port level.
Following QOS policy configuration failed because the configuration check
assumes user is trying to apply the queue-limit at the vlan level which is not
supported.
policy-map child-1
class class-default
queue-limit 256 packets
!
policy-map VLAN-OUT
class class-default <<<<< Class default is being assumed at the port
level , Child policy at the second level
shape average 5000000
service-policy child-1
!
interface GigabitEthernet0/5
switchport trunk allowed vlan none
switchport mode trunk
!
service instance 2 ethernet
encapsulation dot1q 60
rewrite ingress tag pop 1 symmetric
bridge-domain 60
3600-HL-2-N(config)#interface GigabitEthernet0/5
3600-HL-2-N(config-if)#no service instance 1 ethernet
3600-HL-2-N(config-if-srv)#service-policy output VLAN-OUT
QOS: queue-limit command not supported in non-leaf classes
QoS: Policy attachment failed for policymap VLAN-OUT
*Feb 13 09:55:28.700: %QOSMGR-3-QLIMIT_LEVEL_ERROR: Qlimit command not
supported in non-leaf classes
Regards,
Waris
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
