From: Scott M Vermillion (scott_ccie_list@it-ag.com)
Date: Sun Oct 26 2008 - 19:37:20 ARST
> Even further, let's think about ATM....
Hehe. Funny to me because ATM is the one thing I disdain more than FR in
the WAN domain!
I know that it had great potential and some really cool features and
functionality, but I was involved in a deployment of it back in the '90s
before anybody's product line was really where it needed to be for global,
mission-critical roll-out. I've still not forgiven ATM for the sins of the
vendors to this day... ;-)
Glad that was helpful to you Roger and thanks for saying as much. I
consider QoS to be a personal strong suit but will be kicking off a thorough
review of it in the coming week. Should be great fun and I'm genuinely
looking forward to it...
Regards,
Scott
-----Urspr|ngliche Nachricht-----
Von: Scott M Vermillion [mailto:scott_ccie_list@it-ag.com]
Gesendet: Sonntag, 26. Oktober 2008 22:09
An: 'Roger RPF'
Cc: ccielab@groupstudy.com
Betreff: RE: question regarding QoS on serial interfaces
Hey Roger,
That's all correct from my perspective; my initial attempt at wording the
part about setting the 'bandwidth nnn' above default didn't come out quite
right at all. No, I personally can't really ever see a situation where it
would be useful to set bandwidth *higher* than the physical clock rate of
your tail circuit (although just now I had a sense of paranoia wash over me
that someone is going to break out with some crazy Stupid Router Trick that
makes it seem like a perfectly reasonable thing to do!). You may want to
set bandwidth higher than the *default* of 1544 kbps if you truly have
higher throughput end-to-end. You may wish to set 'bandwidth nnn' *lower*
than the actual clock rate in the case of FR or any other situation where
your tail circuit is signaled faster than your end-to-end throughput.
Like yourself, it's also exceedingly rare that I implement serial in
production anymore. Occasionally a BRI in Europe or something, but pretty
much everything is some flavor of Ethernet these days it seems. Having said
that, I still often wind up facing a similar problem. I've got a 100 Mbps
or 1 Gbps Ethernet segment going from a Mobile Access Router 32xx that
terminates to a cellular data card a few cable feet away. This service
offers no more than a few Mbps of actual throughput (on a good day). So you
have to implement shaping to artificially introduce congestion in the router
so that you can implement CBWFQ or whatever it is that you're doing.
Otherwise, the router blissfully pushes traffic out at up to line rate of
the Ethernet segment, where it promptly gets dropped by the bottleneck
device at the other end of the cable. The router knows not and cares not.
The TCP stacks on the end hosts are able to adapt but any RTP/UDP type of
stuff dies a horrible death.
I think this is just another great example of a technology (FR) being far
too useful as an instrument with which to torture lab candidates to ever
fully go away. ;-)
Cheers Roger,
Scott
(Incidentally, since you have the book, check out the Q&A at the end of
Chapter 1; Questions 6 & 7 specifically)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Roger RPF
Sent: Sunday, October 26, 2008 2:34 PM
To: 'Scott M Vermillion'
Cc: ccielab@groupstudy.com
Subject: AW: question regarding QoS on serial interfaces
Hi Scott,
Thanks for this really helpful answer! I just read the first couple of pages
in the QoS Exam Certification Guide (it's my QoS bible as well...). I have
to say, I never paid attention to clock rate in combination with bandwidth
on the serial link. Might come from the fact that I never used serial links
in livenetworks :o)
But, if I got that right, the bandwidth command on a serial interface,
could/should not be set higher than the clock rate, because it would not be
possible to send more than clock rate, or in words of the Bible: "Bandwidth
only changes the behavior of other tools on an interface, and it affects the
results of some statistics, but it never changes the actual rate of sending
bits out an interface."
So this brings me to the question what happens if I have a clock rate of 2Mb
and I set the bandwidth to 3 Mb and do some QoS over it? Even if the
calculation of the QoS tools seems to be correct (due to the bandwidth
statement), the whole stuff would go wrong, because the Layer 1 bit rate
specified via clock rate would be lower....
right?
regards
Roger
-----Urspr|ngliche Nachricht-----
Von: nobody@groupstudy.com [mailto:nobody@groupstudy.com] Im Auftrag von
Scott M Vermillion
Gesendet: Samstag, 25. Oktober 2008 22:54
An: 'Roger RPF'; ccielab@groupstudy.com
Betreff: RE: question regarding QoS on serial interfaces
That second to last part wasn't worded very well:
> whether that be higher than the tail circuit clock rate or lower.
It would be an impressive QoS tool indeed that resulted in higher throughput
than the tail circuit clock rate! ;-)
What I meant to convey was that since the default is 1544 kbps, you should
set bandwidth higher than that if in fact you are being provided with
throughput greater than 1544 kbps (as in your example of a nailed-up E1 or
something).
Cisco has some great documentation on QoS in the Internetworking
Technologies Handbook, but I couldn't find a reference to post that
specifically addresses the issue. It is discussed in the opening chapter of
"Cisco QoS Exam Certification Guide" by Odom, which is my QoS bible.
-----Original Message-----
From: Scott M Vermillion [mailto:scott_ccie_list@it-ag.com]
Sent: Saturday, October 25, 2008 2:37 PM
To: 'Roger RPF'; 'ccielab@groupstudy.com'
Subject: RE: question regarding QoS on serial interfaces
Hi Roger,
QoS tools reference the *configured* bandwidth according to the 'bandwidth
nnn' command _OR_ the default BW, which as you noted would be 1544 kbps for
all serial interfaces; QoS mechanisms do not reference the actual clock rate
of a serial interface. The need to decouple bandwidth from clock rate
becomes apparent when you consider a FR circuit that's being
clocked/signaled at a speed several times that of the contracted CIR.
So yes, whenever you're implementing any kind of QoS in your network and you
have serial interfaces involved, manually set the bandwidth according to the
service you reasonably expect to receive end-to-end in the network, whether
that be higher than the tail circuit clock rate or lower.
Now for lab purposes, I'd be paying a visit to my friendly neighborhood
proctor! ;-)
Cheers,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Roger RPF
Sent: Saturday, October 25, 2008 3:32 AM
To: ccielab@groupstudy.com
Subject: question regarding QoS on serial interfaces
Hi group,
I have a question regarding QoS on serial links, I need confirmation. If a
task says for example: Apply 10% of the interface bandwidth to telnet and
20% to www, and the whole story has to be applied to Ser0/0 interface."
class-map telnet
match protocol telnet
class-map www
match protocol www
!
policy-map test
class telnet
bandwidth percent 10
class www
bandwidth percent 20
!
int ser0/0
service-policy output test
Question:
--------------
What about the bandwidth statement? If I check the clock rate of the
interface with sh control ser0/0, I see that the clock is set to 2Mb (for
example). Per default, my s0/0 interface has a bandwidth of 1.544Mb.
So what do you do in order to fulfill the task? Under the interface, set the
command bandwidt 2000? Leave it as it is, but then I guess the percentage
values are not calculated correctly, isn't it?
To me, if I'm using percentage values in such a scenario, I must set the
bandwidth command, isn't it?
regards
Roger
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sat Nov 01 2008 - 15:35:22 ARST