[c-nsp] ME3600x buffer calculations- revisited

[Waris Sagheer (waris)]

Hi Jay,
Can you please help with the following question? Appreciate your support.

Best Regards,

[http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg]

Waris Sagheer
Technical Marketing Manager
Service Provider Access Group (SPAG)
waris at cisco.com<mailto:waris at cisco.com>
Phone: +1 408 853 6682
Mobile: +1 408 835 1389

CCIE - 19901


<http://www.cisco.com/>



This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

For corporate legal information go to:http://www.cisco.com/web/about/doing_business/legal/cri/index.html



From: Julie Rudolph <Julie.Rudolph at cdw.com<mailto:Julie.Rudolph at cdw.com>>
Date: Thursday, December 26, 2013 7:53 PM
To: Waris Sagheer <waris at cisco.com<mailto:waris at cisco.com>>, "cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>" <cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>>
Subject: RE: [c-nsp] ME3600x buffer calculations- revisited

There is another troubling layer to this.  I also need to traffic shape the egress traffic.  But, I am unable to write the policies in such a way that when I apply the shaping, I also increase the queue limit.

So, here is one of *present* sample configurations that I’m working with:
----- SAMPLE CFG -----
policy-map CUST1-EGRESS-PARENT-PM
class class-default
  shape average 10000000
   service-policy CUST1-EGRESS-CHILD-PM
!
policy-map CUST1-EGRESS-CHILD-PM
class REAL-TIME-DSCP-CM
  priority
  police 8000000
  queue-limit 2000000 bytes
class SIGNALING-DSCP-CM
  bandwidth 1000
  set dscp af31
  queue-limit 2000000 bytes
class VIDEO-DSCP-CM
  bandwidth remaining percent 10
 class class-default
  queue-limit 2000000 bytes
  bandwidth 1000
----- END -----

The problem is that applying the traffic shaping uses the default queue-limit of 49152 bytes (see snippet below), but since it is not a leaf class, I cannot alter the queue-limit.  So, when I send traffic down this interface, it is still hamstrung by that 49152 byte limit.  I’ve tried a couple of configurations to try to address this (including those in http://www.gossamer-threads.com/lists/cisco/nsp/163596) but no configs I can come up with seem to address this.  What am I missing?  How can you shape traffic AND allow for higher queue-limit AND allow for a child policy?    Since the traffic is stepping down from a 10gig input interface to a 100mb interface (which in turn needs to be shaped down to 10mb/sec), I definitely need something.  And, since I’m dealing with voice traffic (udp), dropping packets doesn’t alter the traffic stream (obviously).  i.e. no tcp to back off the traffic.

----- SNIPPET----
ME3600X#show policy-map int gig0/2 output
GigabitEthernet0/2

  Service-policy output: CUST1-EGRESS-PARENT-PM

    Class-map: class-default (match-any)
      7592059 packets, 1108656945 bytes
      30 second offered rate 99000 bps, drop rate 0000 bps
      Match: any
  Traffic Shaping
    Average Rate Traffic Shaping
    Shape 10000 (kbps)
      Output Queue:
        Default Queue-limit 49152 bytes                                       >>>>>> this seems to be the problem.
        Tail Packets Drop: 0
        Tail Bytes Drop: 0

      Service-policy : CUST1-EGRESS-CHILD-PM

        Class-map: REAL-TIME-DSCP-CM (match-any)
<CUT>
----- END SNIPPET -----

What am I missing??

Thanks much,
Julie


Julie Rudolph

From: Julie Rudolph
Sent: Thursday, December 26, 2013 4:12 PM
To: 'Waris Sagheer (waris)'; cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
Subject: RE: [c-nsp] ME3600x buffer calculations- revisited

Great, thanks so much.


1)      Was the dynamic allocation of buffers to the queues/classes that needed them always there, even in 12.2x code releases?

2)      Could you oversubscribe the 18Mbytes in code prior to any 15.x release?  I do not recall reading anything in the release notes about a change in the behavior such as this so I assume it was always there.  (Sorry if I missed something in the docs.) So, perhaps the only limiting factor to how much burst or maximum throughput a port could handle had to do with the 491520 Bytes (pre-15.24S) per queue max.  (If you couldn’t oversubscribe the 18MB, then that would come out to a max of ~38 queues that could be maxed out to 491520 bytes).

3)      I see now how the availability of the queue percent feature allows the ability of a queue to use more than the old (old = 15.2(4)S) max of 2Mbytes provided the resources are available.   Not a question, just a comment.  And a sigh of relief.

-Julie