CBWFQ versus PQ

[ciscomummiez]

We are running a lot of voice traffic over satellite links. Until now we have used PQ to prioritize traffic. The reason for this is that no bandwidth has to be reserved for voice and all bandwidth are available for any application as long as it is not used. Satellite bandwidth are expensive so reserving a bandwidth for voice to avoid queuing and jitter is not an option. We have been looking into CBWFQ lately because of lots of gre tunnels with high priority traffic inside. With only PQ it?s not possible to prioritize gre tunnel traffic individually. What I have tested is to use QOS pre-classify with policy map to tag the tunnel tos header and then use PQ to match the different preferences. Is it possible to just use CBWFQ and avoid jitter without reserving any bandwidth making it unavailable for other traffic?

[smalkeric]

Guaranteeing bandwidth with class-based weighted fair queuing (CBWFQ). CBWFQ is a mechanism to provide guaranteed bandwidth to particular traffic classes while still fairly serving all other traffic in the network. To characterize a class, you assign it bandwidth, weight, and maximum packet limit. The bandwidth assigned to a class is the minimum bandwidth delivered to the class during congestion. Refer the following URL

http://www.cisco.com/en/US/products/ps6612/products_white_paper09186a00804fce7f.shtml

[Aaron Dhiman]

You need to use Cisco LLQ, which is simply a PQ for voice and CBWFQ for your other traffic. The CBWFQ will provide only bandwidth guarantees, but no guarantee for delay or jitter.

So, keep your voice in PQ, then put your high priority traffic with bandwidth guarantees and WRED in CBWFQ.