RSVP in Conjunction with CBWFQ
CBWFQ and RSVP can be configured on the same interface.There is, in general,
no specific interaction between the two.They are configured as if the other
mechanism were not present. However, because RSVP reserves bandwidth for its
clients and CBWFQ guarantees bandwidth for its classes, it is possible to configure
the router to guarantee bandwidth to each of them in such a way that the
total guaranteed bandwidth exceeds the circuit speed.
This constitutes a potential problem. In a congestion situation, if you have
promised the majority of the circuit bandwidth to two mechanisms separately,
which one will succeed in getting the bandwidth it needs? You cannot promise
three-quarters of the bandwidth to CBWFQ and half the bandwidth to RSVP
and expect that they would both have sufficient bandwidth in a congestion situation.
In practice, if you need to guarantee bandwidth to classes as well as to RSVP
sessions, you would avoid an overlapping bandwidth guarantee like this. Still,
there is nothing in the IOS code to prevent you from making this configuration.
So, what exactly does happen if you over-subscribe the guaranteed bandwidth
by promising it to both RSVP and CBWFQ? Because of the WFQ implementation
in the routers, RSVP wins out in the end, taking as much bandwidth as it
needs from all other classes equally.