Hey,

You can do that as well. You just need a dummy class. So, something like the 
following should work:

class-map match-all DUMMY
 match qos-group 7
!
policy-map test-100m
 class DUMMY
 class class-default
  shape average 100000000
  queue-limit percent 100
!
interface blah
 service instance blah
 service-policy output test-100m


Keep in mind though that it's not always the best idea to allocate the entire 
buffer space to everything indiscriminately. The box itself handles 
oversubscription fine and I've never had any issues with it not working well 
enough. However, allocating a huge amount of buffer space on a small ( say, 
2mbps ) service is kind of counter-intuitive. You can easily end up with 
seconds worth of buffering ( and latency ) before you start dropping packets. 
Usually, you wouldn't want that.

My thoughts and words are my own.

Kind Regards,

Spyros
-----Original Message-----
From: cisco-nsp [mailto:[email protected]] On Behalf Of 
CiscoNSP List
Sent: Wednesday, September 16, 2015 12:10 PM
To: James Bensley <[email protected]>; [email protected]
Subject: Re: [c-nsp] Tail drops on ME3600 with shaping policy


Thanks very much James - Very helpful!


So there's no singular way I can test this (queue-limit percent 100) on a 
single service instance under an Interface? i.e. Id have to re-do the entire 
qos policy for the Interface and associated service instances?


In our current situation, we have ~30 service instances, all varying subscribed 
speeds under one Interface...only a few of them are showing tail drops, so I 
was hoping to test the queue limit "fix" on one or two of them...but from what 
Im reading in your reply, this doesnt look to be possible?


Cheers.

________________________________________
From: James Bensley <[email protected]>
Sent: Wednesday, 16 September 2015 6:24 PM
To: CiscoNSP List; [email protected]
Subject: Re: [c-nsp] Tail drops on ME3600 with shaping policy

Make sure you are on a decent recent image (worked fine for me from
15.3(3)S3 up to 15.3(3)S6 (haven't ventured into 15.4 or 15.5) and pretty much 
"queue-limit percent 100" everywhere is the way forward with these boxes.

I made some notes on this when I was having the same problem here, I'm a bit 
fuzzy on it now because it "just works", hopefully that will clear some things 
up:
http://null.53bits.co.uk/index.php?page=me3600-3800-buffer-oversubscription

Short version though, the ME3600's/ME3800's use a 3 tiered map to so you can 
apply different QoS policies at different levels in the switch, at the port 
level, service instance or VLAN level, then down at the individual traffic 
class level.


Try this with your configuration, note the parent policy is matching customer 
VLANs, we then apply the child policy to that VLAN, otherwise using your config 
we are trying to set queue-limit percent 100 to the entire port when we have 
multiple VLANs here (which we shall assume are different customers) and they 
might have different QoS SLAs, so we need to match more specifically down to 
that customer class before we can increase the buffers):


int foo
 service-policy output int_foo_parent_policy

 service instance 1065 ethernet
  description CUST_A
  encapsulation dot1q 1065
  rewrite ingress tag pop 1 symmetric
  bridge-domain 1065

 service instance 1066 ethernet
  description CUST_A
  encapsulation dot1q 1066
  rewrite ingress tag pop 1 symmetric
  bridge-domain 1066

 service instance 1067 ethernet
  description CUST_B
  encapsulation dot1q 1067
  rewrite ingress tag pop 1 symmetric
  bridge-domain 1067

class-map match-any CUST1-VLANs
 match vlan 1065
 match vlan 1066

class-map match-any CUST2-VLANs
 match vlan 1067

policy-map child_policy_map
 class class-default
  queue-limit percent 100

policy-map  int_foo_parent_policy
 class CUST1-VLANs
  shape average 100000000
   service-policy child_policy_map
 class CUST2-VLANs
  shape average 200000000
   service-policy child_policy_map



Cheers,
James.
_______________________________________________
cisco-nsp mailing list  [email protected] 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


This e-mail and any attachment(s) contained within are confidential and are 
intended only for the use of the individual to whom they are addressed. The 
information contained in this communication may be privileged, or exempt from 
disclosure. If the reader of this message is not the intended recipient, you 
are hereby notified that any dissemination, distribution, or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender and delete the communication without 
retaining any copies. Connecticore SA is not responsible for, nor endorses, any 
opinion, recommendation, conclusion, solicitation, offer or agreement or any 
information contained in this communication.
_______________________________________________
cisco-nsp mailing list  [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to