Yes, this makes perfect sense. It was the name 'shaping queues' that was throwing me off. I pictured a shaping queue being define one-per shape command. Instead, the concept of a shaper+queue and the class-based queues is kind of merged in this particular situation. I believe that there is only one set of queues -- not a shaper-specific queue that the class-based queues feed into.
Whew, I need an animation or something! Thanks again for everyone's help. Keller Giacomarro [email protected] On Sun, Jul 15, 2012 at 1:49 AM, Kim Pedersen <[email protected]> wrote: > Hi, > > Im not sure where this is different than what the previous graphic > showed you. > > Whats important to remember is that you are 2 queueing structures. 1 > for shaping queues (ie queues used when shaping is active) and 1 for > software queues. They are not the same thing. > The shaping queues are what you create with your service policy > definition _under_ the shaper. > The software queues are the rest. > > As per the graphic (the one i linked to): > > Situation 1: > ---------------- > If a packet comes in, and shaping is active, it gets thrown into the > shaping queues. Which class under the shaping queue is dependent on > what type of traffic it is. > > When time comes that a packet needs to be de-qeueued from the shaping > queues, the scheduler looks at your shaping queues and take things > such as bandwidth reservations into account. > > If theres no congestion on the interface, the packet is sent > immediately (by putting it on the TX ring). If there is congestion > however, it is moved into the regular software queues for processing. > > Situation 2: > ---------------- > A packet comes in and shaping is not active, the packet completely > bypasses the shaping and with that, also the shaping queues. > If congestion is occuring on the interface, the packet is put into the > software queues and are released according to those by the software > queue scheduler. > > If there's no congestion, the packet is sent immediately. > > Hope that helps. > > Kim > > On Sun, Jul 15, 2012 at 6:57 AM, Keller Giacomarro <[email protected]> > wrote: > > Found another graphic in the CCIE R&S Cert Guide that again redefined > what > > I think is happening! I think there is a shaping active check early in > the > > process that doesn't actually use a shaping queue -- it just checks to > see > > if shaping is currently active or not. > > > > This is with a parent policy-map with a shaper, and a child policy-map > with > > many classes and reserved bandwidth. > > > > - Packet needs to be sent out an interface > > - If shaping is not active, go directly to the interface software queue > > (FIFO, WFQ, etc) and then the tx_ring > > - if shaping is active, pass the packet into the child policy-map for > > prioritization, marking, policing, etc > > - the child policy-map immediately processes the traffic and puts it into > > the shaping queue in the correct prioritized order > > - the shaper dequeues the shaping queue into the interface software queue > > (FIFO, WFQ) at the shaping rate as normal > > - the interface software queue feeds into the tx_ring, where the packet > is > > finally transmitted > > > > The thing that might disprove this is the 'show policy-map interface' > > command, which shows that both the shaping queue and the child policy-map > > queues fill up. If the above were true, I would expect the child > > policy-map queues to process data, but not actually increase in size. > This > > may be a show command anomaly? > > > > Okay, hit me -- where have I got it wrong? > > > > Keller Giacomarro > > [email protected] > > > > > > On Sat, Jul 14, 2012 at 7:32 PM, Keller Giacomarro <[email protected] > >wrote: > > > >> Thanks everyone for the good information -- I think that this is a more > >> complicated topic than I realized. > >> > >> > >> I think Carlos hit it on the head; what's going on the router doesn't > >> exactly line up with the metaphors of queues that we are taught. In > this > >> case, although we configure a CBWFQ policy as a child policy of a shaper > >> policy-map, the router doesn't really handle it that way. > >> > >> Traffic shaping is its own thing. > >> CBWFQ using 'bandwidth' and 'priority' is its own thing. > >> Combining the two doesn't chain them together -- it is its own separate > >> process. > >> > >> The way I'm interpreting what everyone is saying is this: > >> tx_ring is minimal > >> When a shaper policy-map is configured with a bandwidth/priority policy > as > >> its child, the shaping is being done by directly interacting with the > child > >> policy-map's queues. There is no shaper queue that backs up into the > CBWFQ > >> queues. Instead, the CBWFQ queues are being shaped themselves. > >> > >> Am I correct in saying that we only have two layers of queues in play? > >> > >> What I thought it was before: > >> CBWFQ queues (multiple) -> Traffic Shaper (single) -> tx_ring -> > interface > >> This would imply that as the shaper queues packets because the CIR is > >> exceeded, they are fed back into the CBWFQ queues. The traffic shaper > then > >> de-queues from the CBWFQ queues in accordance with the > bandwidth/priority > >> settings in the CBWFQ queues. > >> > >> However, it is sounding like the process is not nearly that > >> straightforward. It's almost like the router is using the CBWFQ queues > IN > >> PLACE OF the shaper queue, that they are one and the same. > >> > >> Regardless, I think I have a handle enough on the functionality for the > >> exam -- the nitty gritty is just a matter of curiosity now. Interested > in > >> seeing the internal workings of it. > >> > >> Responses: > >> > >> I don't fully understand what you are saying here. What do you mean by > >> "without full flow information" ? > >> > >> > >> I think I was confused here, my understanding is a little different now. > >> I still don't know what the Cisco poster meant by the shaper using > WFQ/HQF > >> to dequeue the CBWFQ queues, as I would expect dequeueing to be > determined > >> by the settings in the CBWFQ queues. > >> > >> Please attach the policy config and what is that drives your attention > >> from this output! > >> > >> > >> It is based on the simplified config I posted earlier in the thread: > >> > >> policy-map pm-shaper > >> class class-default > >> shaper average percent 100 > >> service-policy pm-cbwfq > >> ! > >> policy-map pm-cbwfq > >> class cm-ssh > >> bandwidth percent 5 > >> class cm-http > >> bandwidth percent 20 > >> class class-default > >> fair-queue > >> > >> And in the original output I highlighted in bold, which apparently > >> doesn't stick when sent via the mailing list. > >> > >> gateway#show policy-map int f0/1 > >> FastEthernet0/1 > >> > >> Service-policy output: pm-wan-out-shaper > >> > >> Class-map: class-default (match-any) > >> 600317 packets, 143960388 bytes > >> 30 second offered rate 631000 bps, drop rate 14000 bps > >> Match: any > >> Traffic Shaping > >> Target/Average Byte Sustain Excess Interval > Increment > >> Rate Limit bits/int bits/int (ms) (bytes) > >> 600000/600000 937 3750 3750 6 468 > >> > >> Adapt Queue Packets Bytes Packets Bytes Shaping > >> Active Depth Delayed Delayed Active > >> ---> - 3 598394 141284492 90698 94225802 yes > >> > >> > >> Class-map: cm-ssh (match-all) > >> 70238 packets, 105192011 bytes > >> 30 second offered rate 621000 bps, drop rate 14000 bps > >> Match: protocol ssh > >> Queueing > >> Output Queue: Conversation 74 > >> Bandwidth 5 (%) > >> Bandwidth 30 (kbps) > >> (pkts matched/bytes matched) 62464/93671468 > >> ----> (depth/total drops/no-buffer drops) 2/1816/3 > >> exponential weight: 9 > >> mean queue depth: 1 > >> > >> > >> The traffic shaper depth is 3, while the only class with any sort of > >> traffic is 2. I am now thinking that this is a show command anomaly, > they > >> should be the same. > >> > >> Thanks again, all -- your comments have really helped! > >> > >> Keller Giacomarro > >> [email protected] > >> > >> > >> > >> On Sat, Jul 14, 2012 at 7:10 PM, Carlos G Mendioroz <[email protected] > >wrote: > >> > >>> Keller Giacomarro @ 14/07/2012 07:07 -0300 dixit: > >>> > >>> I am trying to wrap my head around how QoS queueing actually > functions. > >>>> If > >>>> you're able, please confirm or debunk my understanding! > >>>> > >>> > >>> Let's see if I can help. In any case, the guys that usually chime in > with > >>> details are Peter Lapukhov and, in other forums, Ivan Pepelnjak. > >>> One issue with queueing is that usually a metaphor is used to > >>> understand/explain it, but it does not always play nice down to > >>> implementation details. > >>> > >>> > >>> Your 'normal' QoS setup involves a CBWFQ policy-map applied outbound > on a > >>>> WAN interface. As the tx_ring fills up, packets are queued into the > >>>> CBWFQ > >>>> policy-map queues (one per class-map), and are dequeued as normal. > The > >>>> tx_ring filling up is the trigger for filling queues. Okay, simple so > >>>> far. > >>>> > >>> > >>> Sort of. The tx_ring filling up is the trigger to start "software > >>> queues". But some of the CBWFQ configuration may be active even if the > >>> tx_ring does not fill: police and shape commands (and remarking). > >>> > >>> > >>> The complication comes when you have an interface with a rate limit > >>>> higher > >>>> than your CIR (like a home Internet connection via 100Mbps ethernet > with > >>>> a > >>>> CIR of 512Kbps). If CBWFQ is applied directly to the interface, even > if > >>>> the bandwidth is set, the tx_ring clears faster than the WAN circuit > will > >>>> take the data, and the software queues are bypassed entirely. In this > >>>> situation, applying a CBWFQ policy-map directly to the interface, even > >>>> setting the bandwidth command, does absolutely nothing. > >>>> > >>>> Here's where I get fuzzier. The solution to this is to put something > >>>> else > >>>> between the CBWFQ policy-map and the tx_ring: a shaper via nested > policy > >>>> maps. The shaper is configured to the correct CIR. As the shaper > sees > >>>> that the interface is transmitting too fast, it begins to fill up the > >>>> CBWFQ > >>>> policy-map queues instead of transmitting. In this way, the physical > >>>> interface is faster than the CIR but we still create the necessary > >>>> 'backpressure' to fill up the software queues. > >>>> > >>> > >>> I would not call this "backpressure". And the shaper is not "seeing" > the > >>> interface txing too fast, because it will never do so. > >>> > >>> Let's recap, it's all about when something happens, and that something > is > >>> packet transmission. > >>> > >>> When tx_ring is empty, a packet is transmitted when a packet is > received. > >>> So the trigger is packet reception. (And the code that does the tx is > in > >>> the rx interrupt service). (Well, not really transmitted, but enqueued > at a > >>> hardware level, so forget about it, its gone :) > >>> > >>> Now, if the tx_ring is full, the rx interrupt service just lets the > >>> packet in "a queue". It has to check first if the "queue" has space, > >>> and this is quite involved too. > >>> Then, when the tx_ring gets a place, it looks for which packet from the > >>> queue has to be transmitted next. The tx is now controlled by the AR, > the > >>> rate of the tx interface. And CBWFQ is just a fancy way of defining > which > >>> should be the next packet to be xmitted. > >>> > >>> When a shaper enters the mix, basically there's another trigger. If the > >>> tx_ring gets space, it now has to check if actually getting a packet > from > >>> the queue would exceed the shaper rate, and if it would... it has to do > >>> nothing. Well, nothing for a calculated amount of time. Call it sleep, > >>> delay, whatever. > >>> > >>> > >>> Two things muck with my understanding: > >>>> In https://supportforums.cisco.**com/thread/2132501< > https://supportforums.cisco.com/thread/2132501>, a Cisco employee says > >>>> that the shaper uses WFQ (or HQF in the newest releases) to de-queue > the > >>>> CBWFQ queues. Why is the shaper implementing any dequeueing strategy > at > >>>> all? Shouldn't the CBWFQ policy-map be handling that (such as policy > >>>> queues going first, etc)? And how can it possibly do that without > full > >>>> flow information? > >>>> > >>> > >>> I don't fully understand what you are saying here. What do you mean by > >>> "without full flow information" ? > >>> But the "shaper" has to choose the next packet to tx, and that usually > >>> comes from a child policy. Or may be fair-queues, parallel flows > >>> (conversations) with a neat selection algorithm. > >>> > >>> The other issue is that the show commands on my router support my > >>>> understanding...almost. If I'm moving a lot of ssh data upstream (via > >>>> scp), I can see the shaper queue fill and the CBWFQ queue fill, makes > >>>> sense. Most of the time their values are the same. However, they > do > >>>> on occasion differ by a number or two. Show command artifact, or an > >>>> indication that I have no idea what I'm talking about? > >>>> > >>>> gateway#show policy-map int f0/1 > >>>> FastEthernet0/1 > >>>> > >>>> Service-policy output: pm-wan-out-shaper > >>>> > >>>> Class-map: class-default (match-any) > >>>> 600317 packets, 143960388 bytes > >>>> 30 second offered rate 631000 bps, drop rate 14000 bps > >>>> Match: any > >>>> Traffic Shaping > >>>> Target/Average Byte Sustain Excess Interval > >>>> Increment > >>>> Rate Limit bits/int bits/int (ms) > (bytes) > >>>> 600000/600000 937 3750 3750 6 468 > >>>> > >>>> Adapt *Queue* Packets Bytes Packets Bytes > >>>> Shaping > >>>> Active *Depth* Delayed Delayed > >>>> Active > >>>> - *3* 598394 141284492 90698 94225802 > yes > >>>> > >>>> > >>>> Class-map: cm-ssh (match-all) > >>>> 70238 packets, 105192011 bytes > >>>> 30 second offered rate 621000 bps, drop rate 14000 bps > >>>> Match: protocol ssh > >>>> Queueing > >>>> Output Queue: Conversation 74 > >>>> Bandwidth 5 (%) > >>>> Bandwidth 30 (kbps) > >>>> (pkts matched/bytes matched) 62464/93671468 > >>>> *(depth/total drops/no-buffer drops) 2*/1816/3 > >>>> > >>>> exponential weight: 9 > >>>> mean queue depth: 1 > >>>> > >>> > >>> Please attach the policy config and what is that drives your attention > >>> from this output! > >>> > >>> > >>> > >>>> Appreciate your input -- hopefully this helps someone else too, as > none > >>>> of > >>>> the standard study resources I've read have adequately explained how > this > >>>> works! > >>>> > >>>> Keller Giacomarro > >>>> [email protected] > >>>> > >>>> > >>> HTH, > >>> -Carlos > >>> > >>> -- > >>> Carlos G Mendioroz <[email protected]> LW7 EQI Argentina > >>> > >>> > >>> > >> > > _______________________________________________ > > For more information regarding industry leading CCIE Lab training, > please visit www.ipexpert.com > > > > Are you a CCNP or CCIE and looking for a job? Check out > www.PlatinumPlacement.com > > > > http://onlinestudylist.com/mailman/listinfo/ccie_rs > > > > -- > // Freedom Matters > // CCIE #29189 > // www.packet-forwarding.net > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com http://onlinestudylist.com/mailman/listinfo/ccie_rs
