Selecting the appropriate queuing mode lets you balance traffic-class isolation against logical-interface scale and is a mandatory first step before you apply any interface-level QoS policy.
From Release 7.2.12 onward, all Layer 3 queuing capabilities also apply to Layer 2 physical and bundle interfaces, but not to their sub-interfaces.
| Attribute |
8xVOQ |
4xVOQ |
|---|---|---|
| VOQs per interface |
8 |
4 |
| Supported internal traffic classes |
8 (TC0–TC7), each mapped to a separate VOQ |
8 mapped to 4; traffic classes must be remapped in the QoS policy |
| Logical-interface scale |
Standard |
Approximately double (since fewer VOQs per interface, the system supports twice the interfaces) |
| Default queue hierarchy |
P1 + P2 + 6 PN hierarchy (main interface default) |
Same hierarchy, but applies to only four VOQs |
| Typical use case |
Maximum traffic-class isolation |
High interface fan-out (number of active interfaces per line card or NPU) where fewer dedicated VOQs are acceptable |
P1 + P2 + 6 PN refers to the default queuing and scheduling hierarchy where:
P1—one hardware queue reserved for the single most critical class (TC 7).
P2—one queue for the next-most-critical class (TC 6).
6 PN—six normal-priority queues, one each for TC 5, 4, 3, 2, 1, 0
That adds up to the eight VOQs that the 8xVOQ mode allocates per interface. If you move the router to 4xVOQ mode, TC7 still maps to P1 and TC 6 to P2, but the eight internal traffic classes must be remapped so that the four VOQs can carry multiple classes.
In both modes, queues are allocated per interface regardless of policy applied.