[c-nsp] ME3600X Output Drops
Ivan
cisco-nsp at itpro.co.nz
Mon Aug 27 07:28:17 EDT 2012
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
>
>
>
More information about the cisco-nsp
mailing list