LLQ queue when not congested

[markc.williams]

LLQ in our policy-map;

R1(config-pmap-c)#priority 1024

I understand that when the link is congested;

-its servers traffic for this queue first

-it also polices this queue to 1024kbps

But what happens when the interface is not congested, and I send 2048kbps worth of traffic that matches this queue?

Is the strict priority queuing always enabled?

Does all the traffic get served first? Or does it handle traffic for the queue above 1024 as FIFO?

Thanks in advance

[Joseph W. Doherty]

If interface isn't congested, traffic isn't queued in the LLQ (although it's counted against class stats), so at least on software routers, it's possible to transmit more LLQ class data then what's limited by the implicit policer. (If this is an issue, you can configure an explicit policer within the class.)

If there's no interface congestion, it's FCFS, if there's some interface congestion, tx-ring is FIFO. (NB: tx-ring overflow is what is placed into software queues.)

NB: a congested interface is one with packets waiting; different thing from "congested link" which often (incorrectly) means 100% utilization, truly congested link would be one unable to support substained offered load (i.e. exactly 100% utilization doesn't have to be congested). Also, 100% utilization doesn't have to have a congested interface, and a congestioned interface can happen with almost nil utilization.

e.g.

100 Mbps ingress; 100 Mbps egress, egress can be 100% utilized but interface can't congest

100 Mbps ingress; 10 Mbps egress, 2 packets ingress back-to-back will congest egress interface

100 Mbps ingress 10% load; 10 Mbps ingress, egress link 100% utilization, but not congested

If you have to discard egress packets, then you have a congested link

[Joseph W. Doherty]

NB:

100 Mbps ingress 10% load; 10 Mbps ingress, egress link 100% utilization, but not congested

should be

100 Mbps ingress 10% load; 10 Mbps egress, egress link 100% utilization, but not congested