QoS on pvc or virtual interfaces

fcolombo · ‎03-10-2009

Suppose you have some pvc configured on a physical interface, or some subinterfaces, point-to-point with an associated pvc.

All the traffic comes out from the same physical interface, so same buffer and hardware queue for all pvcs.

If you send all voip traffic using one pvc, interactive traffic with anether pvc, best-effort traffic with another pvc, how can you reserve bandwidth for different classess ?

I mean, how can you be sure that voice pvc will be dequeued before others pvc ?

Nicholas Matthews · ‎03-10-2009

Hi,

When you configure the priority queues and CBWFQ queues on different subinterfaces and pvcs, they all combine to service the same physical interface hardware-ring.

If you have two separate priority queues on two different PVCs, they will be effectively combined when it comes to send the packets out the physical interface.

If you're talking frame relay, you can skip using FRTS on a per-pvc basic, and apply a generic MQC configuration directly to the interface with the service-policy command if you would like to do the QoS across multiple PVCs.

hth,

nick

fcolombo · ‎03-12-2009

Hi,

just to be sure to understand.

when you have more FR pvc, or subinterfaces, you apply QoS policy through FRTS.

But the QoS policy under the map-class frame-relay is related to FIFO shaper's queue.

In that way we are ordering packets delayed by FRTS on every single pvc.

After that, with an algorithm, packets from shaper's queue is drained in the hardware queue.

If I want order the packets before they will be sent through the physicsl interface I need to configure

a new Qos policy related to the physical interface.

If that is right, is it the same for atm pvc ?

Have you some tech doc about this argument ?

Thanks a lot.

Joseph W. Doherty · ‎03-30-2009

"If you send all voip traffic using one pvc, interactive traffic with anether pvc, best-effort traffic with another pvc, how can you reserve bandwidth for different classess ? "

If using CBWFQ, first, insure your PVCs' bandwidths don't oversubscribe the physical interface bandwidth. Second, enforce the PVCs bandwidth allowances. (For FR, can be done with shapers, for ATM, can be done by the hardware.)

You might also want dedicated PVCs for real-time traffic so that your CIR is the same as the expected real-time traffic demand.

PS:

I also recall there's a technique to use a special two level queue for FR to insure multiple PVCs real-time traffic always goes first, but I haven't used that feature.