From: Petr Lapukhov (petrsoft@gmail.com)
Date: Wed May 24 2006 - 12:42:43 ART
Victor,
first, you probably confuse a bit GTS and MQC/CBTS/CBWFQ :)
This is CBWFQ queueing, where we have default 75% of reserved interface
bandwidth to play with.
With GTS we simply configure "traffic-shape rate" regardless of interface
resources.
--Now, let's move to FRTS + CBWFQ. Basically, we just want to introduce CBWFQ as Per-VC queueing mechanism. We could do that in two ways:
1) Configure legacy FRTS (cir/mincir) and embed service policy (CBWFQ config) into map-class
2) Confiure map-class, then introduce Class-Based Traffic Shaping with service-policy, configuration, and embed yet another service policy into that "sandwich".
With both of those, we may configure adaptive traffic shaping (though there are some differences with features available).
Now, how should CBWFQ allocate bandwith for it's classes?
Let's imagine, that congestion has occured. If we have adaptive shaping configured (with mincir or shape adaptive), then our sending rate should probably reduce to minCIR. This is when congestion takes place, and therefore it sounds reasonable to allocate bandwidth from minCIR value.
HTH Petr
2006/5/24, Victor Cappuccio <cvictor@protokolgroup.com>: > > Hello Guys > > > > Quick question here about using GTS and Frame-relay TShaping > > > > In GTS we can reserve the bandwidth from the default 75% using the > max-reserved-bandwidth, is this same as in Frame-relay TShaping but using > frame-relay mincir? > > > > I thought that the frame-relay mincir would not have effect until I > receive > BECNS and then the router could throttle back to the mincir gradually. > > > > Example: look at Internetworks Experts Lab 16 Task 8.3 > > > > A little bit confused about that > > Thanks > > Victor. > > _______________________________________________________________________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Jun 01 2006 - 06:33:22 ART