Fairmont Raffles Hotels International Uses NetMRI
"Like checking my emails or drinking my coffee, opening and looking into our NetMRI has been part of my habit. This tool is just so amazing...With NetMRI, I can have a full picture on what is happening in our network. I guess things will never be the same without Netcordia's NetMRI."
—Michael Vicera, Network Analyst
More CustomersConnect With Us
The Network Monitor, Volume 3 Number 1
Take the Next Step:
Related Information
Articles
- Chesapeake News
- What's New In Frame Relay
- TTCP Tool - Network Performance Testing
- Having Hardware Problems? Bruce Enders Can Help.
Tech Tips
Chesapeake News
Chesapeake Computer Consultants, Inc. is the leading provider of advanced networking technology services to Fortune 1000 companies nationwide. We take pride in the fact that our instructors provide solutions to real life networking problems and we are constantly evaluating ways to provide the student with the necessary tools to get the job done. It is with this in mind that Chesapeake is excited to announce two new advance course offerings for the networking professional.
The first course is Configuring, Monitoring and Troubleshooting Dialup Services (CMTD) which provides fundamental and practical knowledge on Cisco access and ISDN dial-up services. Students will learn how to install, configure, monitor and troubleshoot basic Cisco access and ISDN dial-up services. The second is Catalyst 5000 Switch Family (CAT) which is designed to provide students with hands-on experience necessary to place, configure and maintain Catalyst 5000 family switches in a network. Both courses will be offered in the state-of-the-art Annapolis facility. To find out more about Chesapeake's Training and customized services, contact Gary Birmingham, Director of Training.
Follow-up on the Chesapeake Subnet Calculator
In addition to providing the highest level of training, Chesapeake provides the advanced tools to help solve networking challenges. In The Network Monitor, Vol. 2, No. 4, Chesapeake announced the introduction of the first Java-Based Subnet Calculator which was designed to automate the process of determining Subnet Mask calculations. More than 1,800 people have downloaded this program. " Based on the feedback we received from our training and consulting clients, there is a real need for advanced, platform independent tools which facilitate learning and provide solutions to complex network design and configuration challenges." explained Terry Slattery, President of Chesapeake Computer Consultants, Inc. "We're very excited about the initial response to our release of the Chesapeake Subnet Calculator as we have other advanced, Java-based networking tools in the development pipeline which will further distinguish Chesapeake as the technology leader in the internetworking professional services market." Stay connected to The Network Monitor for the latest developments.
What's New In Frame Relay
By Peter J. Welcher, Ph.D., CCIE, Senior Consultant
Cisco IOS 11.2 has introduced some nifty new Frame Relay features. They include LMI autosense, Frame Relay SVC support, and Frame Relay Traffic Shaping. We'll take a look at them in this month's article and also talk briefly about Frame Relay compression.
I suggest SNA fans look at the documentation. Although the material won't be covered here, there's now a whole chapter on the "fras" command variants (BNN and BAN), for those who wish to talk LLC2 to their FEP. There's also DLSw-Lite support for DLSw over Frame Relay.
LMI Autosense
When necessary a Cisco router will automatically determine the LMI type of the connected switch. This takes place when physical interface is up, line protocol is down, and Frame Relay encapsulation is specified for the interface, but there is no configured LMI type. (In fact, with some experimentation, it appears to do this when the configured LMI fails to match the switch, but that's not what's documented).
The router sends out a full status request in all three LMI types, ANSI, ITU, then Cisco in rapid succession. The router then listens on DLCI's 0 and 1023. Any reply and the router will configure itself accordingly. If multiple replies are sent, the router uses the last reply received. The only way you can really see this in action is using "debug frame-relay lmi."
This is pretty nifty stuff! It means that when doing NBMA model (the Frame Relay network is all one big subnet), you can now get away with a very small amount of configuration:
interface serial 0 encapsulation frame-relay ietf
Not that I'm recommending NBMA model (see previous Frame Relay articles). Note that this also opens the door to Frame Relay AutoInstall with switches doing ANSI or ITU LMI.
Frame Relay SVCsAn SVC is a Switched Virtual Circuit. Think of it as placing a phone call.
You won't be able to try this at home unless you're lucky enough to have a service provider who's providing you with SVCs. Technical issues are fading with switch support for SVCs (I believe Stratacom switches will allow SVCs Real Soon Now). Whether your provider is interested in offering the service may also be a business decision on their part: presumably they receive less income from SVCs ("pay per use") and the billing may be more complicated (since someone's got to track actual usage). Of course, the reverse side of that (lower rates) is why we're all interested in SVCs.
Configuring SVCs on the router is relatively easy. You need a command to enable SVC support and a map-group command to specify the "phone book." Additional class statements point to map-class statements indicating differing types of service. In the example below, the addresses in the first entry in "my-fr-phonebook" are at the "normal" level of service. The second entries use a slower connection. Here's how it might look:
interface serial 0 encapsulation frame-relay ietf ip address A.B.C.D 255.255.255.0 frame-relay svc map-group my-fr-phonebook map-list my-fr-phonebook source-addr e164 111222 dest-addr e164 111333 ip A.B.C.E class normal-class broadcast ipx 123fde.0000.0c01.2345 class normal-class broadcast map-list my-fr-phonebook source-addr e164 111222 dest-addr e164 111555 ip A.B.C.F class slow-class broadcast ipx 123ggg.0000.0c01.6789 class slow-class broadcast map-class normal-class frame-relay cir in 1000000 frame-relay cir out 128000 map-class slow-class frame-relay cir in 128000 frame-relay cir out 56000
I'm taking liberties a bit here with the documentation. Although it's not clear how to configure multiple destinations for SVCs, the syntax shown above is the obvious analog to the way it works for ATM.
The map class commands allow us to specify: custom-queue list or priority list (to prioritize traffic); cir in and out; minimum acceptable cir in and out; bc (committed burst size) and be (excess burst size) both in and out; idle timeout duration; and whether BECN throttles the frame transmission rate. So we get a lot of control over the SVC calls that get placed by our router.
To see status information with SVCs, you may use a new command: show frame-relay lapf.
Traffic Shaping
IOS Release 11.2 supports both generic traffic shaping on interfaces and Frame Relay traffic shaping. The Frame Relay traffic shaping allows: rate enforcement per PVC or SVC; dynamic traffic throttling in response to BECN packets; and custom or priority queuing per virtual circuit.
The intent is to allow guaranteed bandwidth for each type of traffic. The queuing features let us prioritize per circuit, and the rate enforcement makes sure that we won't have a burst on one virtual circuit denying access line bandwidth to the others.
Rate enforcement also makes better use of bandwidth with WAN-hostile protocols (ones that "blast away at full tilt," never noticing that they're also retransmitting a lot of information and that it might make more sense to back off and slow down). With rate enforcement, the router controls the pace at which packets are fed into each virtual circuit.
I see the key issue here being where traffic policing takes place. If your provider is kind enough not to have enforcement at its Frame Relay switch, your frames may make it deep into its network before congestion causes them to be discarded. They may feed out of your central router at the access speed, say T1 speed, and perhaps get discarded only when they have to cross a 56K access line to the slow remote site.(See Figure 2.) With rate enforcement, the centralsite router can buffer (up to a point) then discard excess frames per VC. This ensures that the rate at which frames are fed into a VC doesn't exceed the speed or excess burst capacity at the other end of the VC.
Here's what a sample Frame Relay traffic shaping configuration might look like:
interface serial 0 encapsulation frame-relay ietf frame-relay traffic-shaping frame-relay class my-map-class map-class frame-relay my-map-class frame-relay traffic-rate 28000 56000 frame-relay custom-queue-list 8 queue-list 8 ...
The map class "my-map-class" specifies an average traffic rate of 28 Kbps, with a peak of 56 Kbps. Traffic will be prioritized according to custom queue list 8.
A map class with traffic shaping parameters may be specified by using the "class" command. This looks like:
interface serial 0.100 point-to-point ip address A.B.C.D 255.255.255.224 frame-relay interface-dlci 100 class my-slow-map-class map-class frame-relay my-slow-map-class frame-relay traffic-rate 9600 16000 frame-relay priority-group 2 priority-list 2 ...
Frame Relay Compression
Frame Relay compression has been in the IOS since version 11.0 or so. The method is Stacker compression. It's a payload compression, since intervening Frame Relay switches need to be able to use the Frame Relay header to forward the frame.
It's really easy to turn on compression for a point-to-point subinterface:
interface serial 0.100 point-to-point ip address ... frame-relay interface-dlci 100 frame-relay payload-compress packet-by-packet
Be careful to watch your CPU! I'd expect to be able to handle something like 128 Kbps to a maximum of 256 Kbps of data (precompression) on a 2500 model router. So use caution and keep an eye on "show process cpu."
By the way, it appears that compression can operate asymmetrically. In the lab, we've experimented by turning on compression at one end of a PVC, and observed that we still seemed to be able to communicate just fine with the other end of the PVC. However, I'd suggest testing this out for yourself before you rely on it -- don't give Murphy's Law a chance to rear its ugly head!
Dr. Peter J. Welcher (CCIE #1773), Chesapeake Senior Consultant-Instructor, teaches the Cisco ICRC, ACRC, ICWC, CIT, and CID courses, and the NETSYS Connectivity and Performance Tools course. He also consults on network design and management.
TTCP Tool - Network Performance Testing
As network administrators, we need tools that allow us to generate network traffic and analyze the network's throughput performance. Cisco has included a useful tool in recent IOS releases which we'll talk about and analyze how to use it.
Most often, we've used tools like FTP and Ping to generate TCP/IP traffic between end systems, and then analyzed network performance while this traffic was flowing. The problem with this approach is that we often do not have access to the end systems or they may have FTP performance that is incapable of testing high bandwidth networks. In many cases, we find that we have to install dedicated hardware to perform the tests - a process that may be impractical if the network consists of many remote LAN and WAN segments.
Introducing TTCP
The Unix community has had a good tool for many years for doing this kind of testing: the Test TCP (TTCP) program. The source for TTCP is available from a variety of sources on the Net.
To use TTCP, you start a copy of TTCP in receive mode at one place within the network, then start a second copy in transmit mode at another place within the network. The results of the transfer of data from the transmitter to the receiver indicate the approximate performance of the path between the source and destination. By selecting the source and destination at various points with the network, you can analyze critical portions of the path.
TTCP has a real advantage over tools like FTP. If you have a high performance network, it is difficult for any single computer system to transfer data to or from disk at rates which are sufficient for real network testing. TTCP achieves high performance by filling a memory buffer with data, then repeatedly transmitting this data. Since everything is running from memory, you have a traffic transmitter and receiver that can operate at true network speeds.
Cisco has implemented a copy of TTCP in IOS 11.2 and later, currently as an undocumented command. Since it is undocumented, you will not find it by using the interactive help function. Instead, just type the command ttcp, then press RETURN. If the router model you are using supports TTCP, it will respond with a series of questions for the TTCP parameters. Because TTCP can create enormous amounts of network traffic, it is a privileged command.
This gives us a more widely available resource within our networks for generating traffic when performing network analysis and tuning. Because this capability is in the router, we no longer have to install special traffic generators in the network. You'll find that Cisco routers, because they are very efficient at moving IP data, are very good traffic transmitters and receivers. Now you can perform high-speed network traffic analysis without the need for extra equipment.
TTCP Capabilities
The Cisco version of TTCP sends and receives TCP data (the Unix version also does UDP.) You have control over the number of packets sent, the packet size, the port number at which the transmitter and receiver rendezvous, and several other parameters. By changing the parameters, you can test various buffering mechanisms in the network equipment between the transmitter and receiver.
And the destination doesn't have to be another router. To test throughput to a remote server, start only a transmitter and specify the discard port (TCP port 9) on the remote server.
TTCP reports the amount of data transferred, the transfer time, and the approximate throughput. By comparing the actual throughput with the theoretical bandwidth between the transmitter and receiver, you can tell whether the network is operating as expected. Variations in throughput may indicate a significant amount of other traffic, overloaded network equipment, or perhaps communications errors which are causing packets to be corrupted or dropped. By performing tests on individual segments of the path, you can determine which links or devices should be examined in more detail.
Using TTCP
TCP is a connection oriented protocol, so we must have a receiver listening before a transmitter can connect. So the first step is to start up a TTCP receiver (or use the discard port on a destination system.) Then the transmitter is started. TTCP uses the time and the amount of data transferred, to calculate the throughput between the transmitter and the receiver.
Now that we know a little about TTCP, let's take a look at how to setup and run a network test. In this example, we'll test the throughput of a point-to-point 56Kbps link between two routers.
First, we must start the receiver. On the Cisco router, we would enter the following commands. The default values are in brackets, so just pressing RETURN accepts the default values. In starting the receive session below, we are modifying the receiver's TCP window size to mimic that used by Sun workstations. The last line of the startup output shows the parameters TTCP is using and that it is ready to receive.
Seattle#ttcp transmit or receive [receive]: buflen [8192]: bufalign [16384]: bufoffset [0]: port [5001]: sinkmode [y]: rcvwndsize [2144]: 4096 show tcp information at end [n]: ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001, rcvwndsize=4096 tcp
Then, we start the transmitter.
Tokyo#ttcp transmit or receive [receive]: trans Target IP address: 137.112.32.66 buflen [8192]: nbuf [2048]: 50 bufalign [16384]: bufoffset [0]: port [5001]: sinkmode [y]: buffering on writes [y]: show tcp information at end [n]: ttcp-t: buflen=8192, nbuf=50, align=16384/0, port=5001 tcp -> 137.112.32.66
When the connection is made, the receiver outputs a status line showing that it has accepted the connection. Upon completion of the transfer, the receiver statistics are output, showing the amount of data transferred, the transfer time, the calculated throughput, and the number of I/O calls to read the data:
ttcp-r: accept from 137.112.32.65 (mss 1460, sndwnd 2144, rcvwnd 4096) ttcp-r: 409600 bytes in 61064 ms (61.064 real seconds) (~5 kB/sec) +++ ttcp-r: 301 I/O calls ttcp-r: 0 sleeps (0 ms total) (0 ms average) Seattle#
Similarly, the transmitter outputs a status line when it connects to the receiver. When the transfer is complete, the transmitter statistics are output:
ttcp-t: connect (mss 1460, sndwnd 4096, rcvwnd 2144) ttcp-t: 409600 bytes in 60504 ms (60.504 real seconds) (~5 kB/sec) +++ ttcp-t: 50 I/O calls ttcp-t: 0 sleeps (0 ms total) (0 ms average) Tokyo#
Throughput Analysis
TTCP calculates the approximate throughput in kilobytes per second. In this case, our throughput is 5KBps, which translates to 40Kbps (5KBps * 8 bits/Byte = 40Kbps.) This is over a 56Kbps point-to-point link. Is this throughput is reasonable?
Using the receive stats, let's analyze the link. The TCP buffer size on the transmitter is 8192 bytes. When TCP hands this size packet to IP, it will be broken into five 1500 byte IP packets, plus one 693 byte packet (for a total of 8192 bytes.) To send all 50 buffers, the router will need to send 300 IP packets (note the 301 I/O calls in the receiver stats - one packet during set connection setup and 300 to transfer the data.) Performing an engineering approximation analysis, we estimate that each packet will have a 40 byte TCP/IP header. We use the following calculation to determine the approximate throughput:
50 buffers * 8192 bytes each = 409,600 bytes 301 IP packets * 40 bytes of header = 12,040 bytes Total data transmitted = 421,640 bytes 421,640 bytes * 8 bits/byte = 3,373,120 bits 3,373,120 bits / 61.064 seconds = 55,239 bits/second
This is very close to 56Kbps, indicating that our link is otherwise unloaded. If we had included the HDLC framing overhead, and more accurately measured the number of bytes in the TCP and IP headers, we could determine the exact protocol overhead and therefore the exact theoretical data rate. But for most network analysis, this calculation is good enough.
Features of TTCP
TTCP sends normal IP datagrams, which are handled just like any other user data within the network. If you run tests during periods when there is other user data on the network, you will be measuring the throughput that results from the combined traffic load. The results of the above test indicate a dedicated link with no other traffic. Be aware of long running tests on routers where you are also running routing protocols - they will affect the link and the router's ability to process the packets quickly and possibly affect your analysis.
Using the other features of TTCP, you can set the size of the buffers that are used for transmission, the number of times the buffer is sent, and many other variations. We've heard of people using TTCP to validate the delivered CIR on Frame Relay links. Think up some useful tests of your own using these parameters.
When running TTCP tests, don't forget to examine router CPU, memory utilization, and interface statistics to see if the routers are operating efficiently. Are you seeing input interface drops? Output interface drops? Are the error counters incrementing with each test? Is the throughput near the theoretical maximum of the data path, or is the throughput much lower, perhaps indicating a problem along the path?
TTCP Source Code
The source code for TTCP for Unix is available on the Internet from a variety of sources. Download TTCP here.
Happy testing!
If you find this article useful, drop us an email message at info@netcordia.com.
Having Hardware Problems? Bruce Enders Can Help.
Chesapeake Computer Consultant-Instructor Bruce Enders knows he was born with a knack for making things work. "As a child," recalls Bruce, "I was always taking things apart and putting them back together. I horrified my mother when, at age two, I dismantled a light fixture and put my finger in it. I've had an electrical bent ever since."
No wonder then that Bruce is considered >Chesapeake's "hardware guru." After just a year with the company, he has already found his niche as the resident expert at teaching the Installation and Maintenance of Cisco Routers (IMCR) class. It's a calling that has come quite naturally.
Bruce started his professional career at Western Electric, then a division of AT&T. As the youngest and most junior installer, he was given the responsibility to manage central office telephone switching installations and modifications. After AT&T's divestiture, Bruce worked as a maintenance engineer for Western Electric and trained technicians in operations and repair.
He spent the next few years with American Chain and Cable Company in Frederick, Maryland. As the senior field service engineer, he was responsible for everything the company built in the United States and Canada -- from micro-computers up to large scale mechanical controls.
"Soon after I started the job," he remembers, "I was sent to the company's largest regional client to respond to a downed billing system. Although I had never been inside a DEC computer, I was told to go and see what I could do. I took out the manual and, with an assistant, figured out what was wrong. After an emergency trip to Radio Shack at 4:30 the next morning to get computer chips, we had the system up and running by 8:00 a.m." In fact, Bruce handled the situation so effectively that, in 1977, he accepted an engineering position with Digital Equipment Corporation (DEC) in Birmingham, Alabama.
In 1981, Bruce became co-owner of Data Systems Marketing, a manufacturer's representative firm based in the Washington, D.C., area. As vice president of engineering and government system sales, he single-handedly led the company into the government contract arena, winning a bid to develop a large-scale communications system for a U.S. government agency. Thanks to his efforts, the company's gross sales increased from $4.5 million to over $14 million annually. Bruce sold out his part of the company and, after several years in retail, the computer industry beckoned once again. Bruce then found his current home at Chesapeake.
"One of my concerns of getting back in the technological world," he admits, "was that I would be lost. The overriding truth is that computers are the same as when I left -- they're just smaller and faster. It was an eye-opener. We all think technology takes major leaps, when it usually is small steps."
In addition to IMCR, Bruce is also certified to teach ICRC and Frame Relay. "I strive to make my classes instructive and fun," says Bruce. "I'd do somersaults in front of a class if it would keep the students' attention. I learn as much from my students as they learn from me and approach teaching from this viewpoint. I try to identify my students' objectives and incorporate them into my teaching. I want my students to get everything out of my course that they expect." His efforts obviously pay off. A recent student critique gave this praise about Bruce: "I have a short attention span, but you made the class both enjoyable and informative."
Although Bruce spends most of his time teaching, he does short-term consulting jobs, from installing routers to troubleshooting systems to gathering statistics. Among his favorite consulting jobs was helping an Internet Service Provider analyze its through-put problems.
"I like the family feel at Chesapeake," says Bruce. "It's very much of a team. And I find the combination of consulting and instructing fulfilling because both services provide answers to real-world problems." He adds, "I can imagine always staying in this industry because I can never see getting bored with it. There's always something new."
Using Hot Standby Routing Protocol
If you are using the HSRP (Hot Standby Router Protocol) capability and the STANDBY TRACK feature to monitor another interface on the router (typically the interface to the "outside world"), you should use the STANDBY PREEMPT command on both interfaces. This will allow the routers to efficiently switch the leader role when the priority is lowered, as a result of the second interface going down.
Router Access Control
If you want to control what information hosts can telnet to or from a router, use the IP ACCESSCLASS command. Build a standard IP access list to define which IP addresses will be allowed, then apply the list to the console or vty line.
Using the 'ip accessclass 1 in' command limits inbound access to only those hosts allowed by standard IP access list 1. Conversely, using 'ip accessclass 2 out' enables users on the router or access server to telnet only to those hosts whose IP addresses are allowed by standard IP access list 2. Note the difference in using IP ACCESSCLASS to control telnet and IP ACCESSGROUP to filter data packets.
Back to The Network Monitor Archive
Copyright © 1997 Chesapeake Computer Consultants, Inc. All rights reserved.