How to increase output queue-limit more than 4096 on Giga int ?

[ashish-nagpal]

Hi,

I am using Cisco 10k router (Cisco C10008 (PRE2-RP)), IOS : "c10k2-p11-mz.122-27.SBB4" & "c10k2-p11-mz.122-28.SB8".

I have some Giga interfaces with max hold-queue limit 4096.

Due to some customer requirement, I need to increase output queue-limit from more than 4096, which is a max value Giga int take.

Is there any way to increase the queue-limit for Giga interface?

[paolo bevilacqua]

What would be the customer requirement ? Because what you want to do doesn't make sense at all.

[ashish-nagpal]

I know this much information may not make sense, but the thing is, this all was working fine with ATM link but Gagalink.

I am running multiple traffic classes with varying queue-limit in each class and due to huge b/w of link, queue-limit required is more than 4096 packets in each class.

The error I am getting is as follow:

router(config-subif)#service-policy output cos-out

Queue-limit 16384 not supported on GigabitEthernet1/1/1.1, overridden to 4096

Queue-limit 32768 not supported on GigabitEthernet1/1/1.1, overridden to 4096

Queue-limit 8192 not supported on GigabitEthernet1/1/1.1, overridden to 4096

[paolo bevilacqua]

Can you post the service policy? I'm unsure of what they're trying to do in practice.

[ashish-nagpal]

Here is the config:

++++++++++++++++++++++++++++++++++++++

policy-map cos_police

class voice

priority

police percent 30 2 ms 0 ms conform-action transmit exceed-action drop violate-action drop

queue-limit 16384

class data1

bandwidth remaining percent 13

queue-limit 32768

class class-default

bandwidth remaining percent 87

queue-limit 8192

!

policy-map cos_out

class class-default

shape 600000

service-policy cos_police

!

interface GigabitEthernet1/1/1.1

description - BW=450

encapsulation dot1Q 90

ip address 10.0.0.1 255.255.255.252

service-policy output cos_out

++++++++++++++++++++++++++++++++++++++

What basically I need is to know,if there is any way to increase the Giga interface output queue-limit from 4096 ?

[paolo bevilacqua]

There is no way. Beside, with the low speed shaping, the queue limits are too large and would not apply. Verify first how things work without any queue-limit that are not recommended by cisco.

Note for the voice class, you if you enter values for the priority statement, policing is not necessary.

[ashish-nagpal]

It is 10k router. There is no option to put any value after priority statement in voice class here and even cisco says to use "police" when no value(percentage/bytes) can be given for priority statement as it works in the same way.

Thanks for even considering my query but can I have a logical reason that why am I not able to increase queue-limit in case of giga interface, whereas ATM has automatically manipulated itself with higher queue-limit?

[paolo bevilacqua]

Hi, I wasn't aware of the priority commands limitation for your case.

Different hardware has different drivers and logic. The gigabit being a musch faster interface allows only smaller queues to be built. In fact, the shaping you're doing on is already a artifice, as the QoS should be applied to the real point of congestion.

If sharing the bandwidth is the only goal, it should not much difference what is the queue limit. After all, is not that queued traffic can be kept to huge amounts, it must be dropped at some point.

[ashish-nagpal]

I agree with you. B/W ATM interface having was 45MB and throughput was not higher than it. now I have increased link b/w in a huge proportion but perhaps some day requirement is increased then again I would think about this limit though I know large queue will increase delay and require more buffering and processing power. But you know customers, they will point queue-limit again. :)

[nstathak]

why do the need greater 4096 especially on a GE interface. I do see the config from the ATM interface, different type of card which is made to buffer and the GE max is 4096 never seen it bigger than that.

[ashish-nagpal]

I don't require in particular actually. It is just that earlier ATM interface had higher queue limit with lesser access-link b/w but if I change the limit to lesser one now, customer would keep on asking that why it's been changed without understanding the nature of interface and link. :)