|
||||||||||||
IntroductionThere are 10 (binary) kinds of people, those who have been
reading these articles and those who haven't . The second group will
probably never see these words. Those in the first group may
have noticed I like to talk about things I've been doing. I hope this
keeps the topics fresh and real-world. It certainly helps me out with
having to do less preparation before writing. This month is another
article relating to work I've been doing. I and some of our other folks have been working on a QoS
project for a large network. We're describing the architecture, the
configurations, things to consider, initial testing and deployment,
etc. in the customer's specific environment. One of the tasks was
testing and demonstrating QoS in the lab. (Stress-testing QoS,
hence the title). We put together a set
of freeware and used it for this. Feedback suggests the demo is
effective. The original idea for this sort of thing is something I first saw with a Cisco SE in San Francisco, Eric Mar, who had a road show QoS Boot Camp a few years back. He was kind enough to run through it for me and some others. It provided the core idea for the DQOS course labs when I and some other folks wrote the initial outline. (No, I didn't write the actual course slides and materials). Since then, I've borrowed ideas from the now-retired DQOS course labs, and some other sources, including some quick and dirty demos I've done over time. The key idea here is to vividly demonstrate the benefits of
QoS.
For Cisco, the intent was indubitably sales and showing off the new
capabilities that differentiated Cisco routers. For you and me, the
goal
might be to demonstrate the value and efficacy of QoS to management,
consulting customers, etc. If you want your management chain to
allocate time, training, staff, or money for QoS, they need
to understand what it does for the network and why its important. Vivid here means either showing
something or (as a fallback) listening
to something. Seeing is believing. Dry numbers in show command output
or some test tool window may be more informative, but are less
effective, particularly with not-so-technical managers. This article describes in general terms how you can put
together your own QoS demo. I don't want to give away all our secrets
and added value, but a lot of what I've been doing is something
you can do on your own. This is also a great way to work with QoS in a
lab, looking at the technical information and seeing how that
correlates with what you're seeing or hearing. The Basic IdeaThe way the demo works is to congest a link that carries loading traffic plus the demo traffic. You then show how ugly things are without QoS, and then apply QoS to the interface to make some things better. It can be particularly effective if you have two video streams or two phone calls, and only one is improved. That makes it evident that the congestion and packet drops are still present, but that QoS has protected the important traffic.Important thing to note: QoS is not a panacea, and doesn't make up for not having enough bandwidth. QoS provides priority access to the bandwidth -- winners, which implies there are also losers. Don't let your boss leave the demo thinking QoS will make any amount of video or audio work. Nor will it replace buying more bandwidth, although QoS may allow you to delay having to buy more bandwidth for a little while. The point to make is that QoS can protect important traffic, IF you have enough bandwidth for that traffic plus some left over for the remaining Best Effort Traffic. You do have to tune what you demo to the bandwidth on the
link. I suggest you not do demos on Gigabit Ethernet. You would
probably need some costly power tools or several computers to generate
enough traffic to congest it. Rather, work with fractional-T1 to say 6
Mbps links. This reflects most real-world WAN links today, except
perhaps at corporate HQ or data center. Congesting links at this speed
doesn't take a lot of effort, and yet you can run some fairly
interesting multi-media traffic over them for demo purposes. Serial
links are good for the bottleneck link, especially if you want to cause
congestion by adjusting the clockrate downwards. The following figure shows that you can do a demo with a
rather minimal set of equipment. Using multiple laptops attached via a
switch can help if you want to classify traffic based on IP address.
My definition of "Interesting" (as in "interesting demo") varies with speed. If you're working with a 128-256 Kbps link, forget video and stick to audio. Run some $10 handsets into FXS ports on a pair of 2600's and you can demo QoS interacting with VoIP. I've steered clear of mixing IPT (IP Telephony) and QoS demos, just due to complexity. With the VoIP approach, you can pre-configure and not have to fuss with the telephony side of things while demoing QoS. If you're working in the T1 or above range, consider video. For ideas, see below. If your critical application is TCP-based or web-based,
there's a way to make QoS impact visible there too. See below
("web"). Free Tool ToolkitThe starting point in building your own QoS demo(s) is to have a toolkit of free or inexpensive programs you can use. Here's what's in my bag of tricks now.
Cisco used to provide the lovely QDM tool for free, which you
put into flash in your router. It allowed CBWFQ to be configured with a
GUI, and provided graphs of the Cisco Class-Based QoS MIB. As you can
probably tell from my prior article, I really liked this applet.
Regretfully, Cisco declared it End of Life a while back. Other things you might want to buy to use with this:
Examining the free tools
Commercial ToolsIf you've got some money for a "real" QoS lab, then you either
want to introduce WAN delay and jitter simulation or load up on
connections or traffic. There are a vast number of vendors and tools.
Here are some we've noticed:
For example, if you're doing serious testing ability of an
IPSec VPN box to hold up under a large number of connections or high
traffic load, you might use something like one of Ixia's product. My
earlier article on that particular topic was focussed more on the cheap
"do it yourself" quick testing approach. How to Build Your DemoStart with only the key applications running. Make sure they use less bandwidth than your link has. Use Ethereal to determine average traffic level for each application. Another option: if you set up classification and marking, the "show policy interface" command will tell you the average traffic in each class. That tells you how much bandwidth to provide in your output QoS policy using priority and bandwidth commands.Then add background traffic to overload the link. By adding or
removing the "service-policy out policy-name"
command from the relevant interface, you can ensure that the video or
audio is bad until QoS is applied. Test thoroughly before
demonstrating, because it may take a few iterations to get it working
smoothly. Hint: if you're using G.729 voice compression, it's such a small stream I found it hard to clobber with other traffic. G.711 uses more bandwidth and is easier to "step on". I used a small PERL script to launch several applications at
one time. This was mostly for convenience in starting the demo. A Little JavaScripting Goes a Long WayHere's the source code for the magic web page mentioned above. It uses a smidge of JavaScript to defeat caching and cause repeated loading of the web page image. I commented each line out below to ensure it doesn't do anything when you view this document! So if you're trying to cut and paste, paste into Wordpad, remove the "//" and leading spaces, and save. Then change the file extension to .html and you're ready to load.. load... load that image!. // <!DOCTYPE html PUBLIC "-//w3c//dtd html 4.0 transitional//en"> // <html> // <head> // <title>bigimage</title> // <script language="JavaScript1.2"> <!--BEGIN HIDING // function doit() // { // // wait time in msec // setTimeout("document.location.reload(1)", 1000); // // Flag is 1: force reload, no matter what user preferences are re cache // } // // end hiding contents from old browsers // // --> // </script> // </head> // <body onload="doit()"> // <h2>Now is the time to load an image... </h2> // <img src="bigimage4.jpg" title="" alt="big image 4" // style="width: 400px; height: 500px;"> // <br> // </body> // </html> For what it's worth, I tend compose basic pages using Netscape
Composer, then add scripting using WordPad. I've been avoiding MS Word,
it adds way too much junk to HTML pages, trying to control appearance.
That tends to make them impossible to hand-edit when you want to. EtherealHere's a sample of the grapher in Ethereal. Every time I show this to someone who hasn't seen it, they say "where do you download that from", so it's certainly an eye-catcher. The graphs show traffic from capturing myself hitting www.cnn.com and www.cnbc.com with a web browser. The red and green graphs show me alternately clicking on refresh. The blue graph is a different address, my guess is a separate server for the graphics for one of the two sites.This can be very useful for baselining a QoS demo lab, since
you can put in a filter such as address or protocol ("http") and easily
graph all the matching traffic. Caution: it's in Bytes / second, not
bps, and you do have to switch it from Packets/second. I've never
understood why anyone would want Packets/second, they rarely seem all
that interesting to me. ![]() This shows captured packets. If you capture inbound to a router and (separately) outbound, you can compare the two. The Cisco Class-Based QoS MIB does all this with one set of polls. The CBQOS tool mentioned earlier takes some work to build and get working, but displays this data. The commercial software I know of that reports on the CB QoS MIB is unfortunately costly. SummarySeveral of my prior articles discussed QoS. For configuring QoS, you'll want to use the newest cut at it, CBWFQ and the Modular QoS CLI. For more about this, see the article, New Quality of Service Features in Cisco IOS 12.1, http://www.netcraftsmen.net/welcher/papers/newqos121.html.If you don't have time to roll your own QoS demo, we'd of course be glad to come do it as a brief consulting engagement. It might also be useful to talk about QoS-readiness, and what your organization's QoS needs might be. When we started experiencing problems with the CBQOS freeware,
I wrote some PERL. I have a rough tool that offers you a set of
choices, then polls CB QoS data and displays it in real time using
gnuplot. This may or may not be the subject of a future article.
Your comments, questions, and suggestions for future articles
are of course welcome! See below to decipher my email address. Dr. Peter J. Welcher (CCIE #1773, CCSI #94014, CCIP) is a
Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a
high-end consulting firm and Cisco Premier Partner dedicated to quality
consulting and knowledge transfer. NetCraftsmen has ten CCIE's, with
expertise including large network high-availability routing/switching
and design, VoIP, QoS, MPLS, IPSec VPN, wireless LAN and
bridging, network management, security, IP multicast, and other
areas. See
http://www.netcraftsmen.net for more information about
NetCraftsmen. Pete's links start at
http://www.netcraftsmen.net/welcher . New articles will be posted
under the Articles link. Questions, suggestions for articles, etc. can
be sent to pjw
<at> netcraftsmen <dot> net (formatted this
way to fool email harvesting software). 12/4/2004 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||