Sunday, April 18, 2010

How to find queue utilisation on 7600/ES+ cards

Cisco usually provides various technical characteristics about their products, but you never get the details you need. One big mystery are the ES/ES+ cards on the 7600 platform. We've been using the ES+ cards for quite a long time and i was trying to get a comparison with the ES+T ones, which come in lower prices. The most worrying fact (regarding a specific project's needs) was a difference in QoS (especially egress) :

76-ES+T-20G : (16, 8, 4) (Level 4 Queues, Level 3 Shaper, Level 2 Shaper) queues per port
7600-ES+20G3CXL : 64,000 ingress queues & 64,000 egress queues

This seems like a big difference, but it may not be relevant to your case, unless you know how to count them easily.

An easy way to start experimenting is the "sh tech-support" command, which includes a lot of information. A variant of this is "sh hw-module slot x tech-support", if you're interested in a specific module. Beware of bug CSCta88917 if you try this. Bug toolkit doesn't say anything useful, but after we opened a new SR, we had to rma the whole module, because according to the tac engineer the crash was due to a faulty sensor (any idea why GOLD didn't catch it?).

Anyway, the command that displays the queue usage is "show platform hardware qos np x queue resources" and this is the output from a 7600-ES+20G3CXL card in slot 9 of a 7600:


7600#rem com mod 9 show platform hardware qos np 0 queue resources

np tm level groups entity
----------------------------------------------
0 0 L4 4096/15 32768/34
0 0 L3 256/13 4096/15
0 0 L2 8/11 256/13
0 0 L1 32/10 32/10
----------------------------------------------
0 1 L4 4096/14 32768/51
0 1 L3 256/10 4096/14
0 1 L2 8/5 256/6
0 1 L1 32/5 32/5
----------------------------------------------
0 2 L4 4096/6 32768/16
0 2 L3 256/6 4096/6
0 2 L2 8/5 256/5
0 2 L1 32/5 32/5

7600#rem com mod 9 show platform hardware qos np 1 queue resources

np tm level groups entity
----------------------------------------------
1 0 L4 4096/15 32768/34
1 0 L3 256/13 4096/15
1 0 L2 8/11 256/13
1 0 L1 32/10 32/10
----------------------------------------------
1 1 L4 4096/5 32768/10
1 1 L3 256/5 4096/5
1 1 L2 8/5 256/5
1 1 L1 32/5 32/5
----------------------------------------------
1 2 L4 4096/5 32768/10
1 2 L3 256/5 4096/5
1 2 L2 8/5 256/5
1 2 L1 32/5 32/5


You can see the queues per NP and per level. 7600-ES+20G3CXL has two NPs, each one controlling 10 ports. Each NP has 3 tm; tm 0 in each NP doesn't seem to be updated by the configuration changes (any clue?). The ones that interest you are tm 1 and tm 2 entity values, which control 5 ports each.

Summarizing it up :

NP 0, tm 1 : ports 1-5
NP 0, tm 2 : ports 6-10
NP 1, tm 1 : ports 11-15
NP 1, tm 2 : ports 16-20

According to the above outputs, there are 32768+32768 entities per NP, so i don't know if the official number of 64000 queues is totally correct. i.e. can you use all of them on the first 5 ports? 7600/ES+ QoS documentation provides some info, but it's not very clear.

These are the values you start with:


level entity
-------------------
L4 32768/10
L3 4096/5
L2 256/5
L1 32/5


If you have a single level policy, then you only reserve queues from L4 level.
If you have a hierarchical policy with 2 levels, then you reserve queues from L4 and L3 levels.
If you have a hierarchical policy with 3 levels, then you reserve queues from L4, L3 and L2 levels.

Service instance, port-channel service instance, and Layer 3 subinterface support 2-level policy-map:
- parent => class-default
--- child => user defined classes

Main interface supports 3-level policy-map:
- grand-parent => class-default
--- parent => user defined classes
----- child => user defined classes


Examples

If you have the following 2-level egress H-QoS applied on a main interface


7600#sh policy-map int gi9/6 | i Class
Class-map: class-default (match-any)
Class-map: 1A-CLASS (match-all)
Class-map: 1B-CLASS (match-all)
Class-map: 1C-CLASS (match-all)
Class-map: 1D-CLASS (match-all)
Class-map: 1E-CLASS (match-all)
Class-map: class-default (match-any)


then the output becomes...

Before:

level entity
-------------------
L4 32768/10
L3 4096/5
L2 256/5
L1 32/5


After:

level entity
-------------------
L4 32768/16
L3 4096/6
L2 256/5
L1 32/5


which means you're using :

1 L3 queue
6 L4 queues


If you have the following 3-level egress H-QoS applied on a main interface


7600#sh policy-map int gi9/1 | i Class
Class-map: class-default (match-any)
Class-map: 1A-CLASS (match-all)
Class-map: 2A-CLASS (match-all)
Class-map: 2B-CLASS (match-all)
Class-map: 2C-CLASS (match-all)
Class-map: 2D-CLASS (match-all)
Class-map: class-default (match-any)
Class-map: 1B-CLASS (match-all)
Class-map: 2A-CLASS (match-all)
Class-map: 2B-CLASS (match-all)
Class-map: 2C-CLASS (match-all)
Class-map: 2D-CLASS (match-all)
Class-map: class-default (match-any)
Class-map: 1C-CLASS (match-all)
Class-map: 2A-CLASS (match-all)
Class-map: 2B-CLASS (match-all)
Class-map: 2C-CLASS (match-all)
Class-map: 2D-CLASS (match-all)
Class-map: class-default (match-any)
Class-map: 1D-CLASS (match-all)
Class-map: class-default (match-any)


then the output becomes...

Before:

level entity
-------------------
L4 32768/10
L3 4096/5
L2 256/5
L1 32/5


After:

level entity
-------------------
L4 32768/27
L3 4096/10
L2 256/6
L1 32/5


which means you're using :

1 L2 queue
5 L3 queues
17 L4 queues


Notes

1) Does anyone have any explanation about the 2 extra L4 queues from the last example? If you count the leaf classes, you'll find they are 15. I guess the last 2 classes (that have no child) reserve an extra "hidden" child queue, probably in order to make their depth equal to the others'.

2)
In IOS hierarchical levels are represented as follows and current support is up to five levels:

• Physical or main interface
• Subinterface or logical layer
• Grandparent class
• Parent class
• Child class

A policy map with 2 levels has :
• 3 levels of hierarchy when attached on the main interface
• 4 levels of hierarchy when attached on a subinterface

A policy map with 3 levels has :
• 4 levels of hierarchy when attached on the main interface
• 5 levels of hierarchy when attached on a subinterface

4 comments:

  1. This is definitely valuable information. Thanks.

    About the first note - that's the thing that also instanteneously popped into my mind. An easy way to test this would be to remove 1D-CLASS, and it should be:
    1 L2
    4 L3
    16 L4

    This would be a similar approach to hardware engineering that Cisco choose when designing Sasquatch - there you could also have only limited amount of queue structures, and it was up to you if you'd use it in all instances or they would be "lost".

    P.S.: Another great feature of ES+ is the ability to shape on ingress. This is not available virtually on any platform. Sure, there is ingres shaping on ME3750, but there it is a bit of a "cheat" since data have to travel twice through an ASIC: Packet comes into an ASIC and is output to NPE (this output shapes, but from NPE perspective it's ingress direction)

    ReplyDelete
  2. Although I think that the same entity number( 32768 and the rest of them) is shown also in the ES+T cards. So I am a bit confused of what the entities might be! :)

    ReplyDelete
  3. I am just unable to apply hierarchical service policy to SIP 400 - SPA-5X1GE can be applied.
    IOS:c7600rsp72043-adventerprisek9-mz.122-33.SRD3
    am I trying something impossible

    ReplyDelete
    Replies
    1. It would probably be better to upgrade first to 12.2SRE or 15.2S, since many things have been added on these releases.

      Delete

 
Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.
Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Greece License.