Network Uptime

This Issue:

* Starting Delimiter - The Results of our April Foolish Contest
* Uptime Update - Protocol Analysis on a Switched Network - Part 1
* Free/Shareware Pick of the Moment - Capture Packets with tcpdump
* Network Uptime Surf Report - Study Cisco at GroupStudy
* Network Uptime Management Tip - The Search for the NIC

====
Starting Delimiter
====

We have a fool! For those who didn't receive the last issue of the newsletter, Network Uptime ran our First Annual Network Uptime April Foolish Network Contest (I'll work on the name for next year). This year's winner is G.E., who works for a brewery (I am not making this up), although this particular foolish moment happened while in the employment of a different company. Here's G.E.'s foolish exploit:

"In a previous position with a previous company, I was given the opportunity to rewire a hub closet in one of our other buildings. The purpose was to 'clean up the mess'. I went from workstation to workstation to determine who was actually connected. One of the things that I was running into was that all of the outer walled office network connections, VP's, Directors, and such, were blocked by large pieces of furniture. I made a mental note to gather that info from the telecom guys who had wired them originally. Well, I forgot to do that. Two months later, my supervisor, myself, and two other guys in the department worked through the night to rewire the closet. Guess what? The 'bigwigs' couldn't connect. When I got home that night, my wife commented on my newly shaped behind!"

An unintended wireless implementation of high-level executives can be a career-limiting-move. To help ease the pain, a brand new CD-ROM burn of the Network Uptime Tools Library is on the way to Mr. E.

We're burning an extra CD-ROM for the winner of our next contest, if we ever have another. Perhaps we should have a contest to recommend contest ideas!

James Messer
Editor, Network Uptime
James@NetworkUptime.com

====
- Uptime Update -
Protocol Analysis on a Switched Network
Part 1 - Breaking Into the Link
====

Monitoring a switched LAN can be a challenging exercise. The advent of LAN switches has completely changed our methods for managing the network, and today's network manager must work harder than ever to find more creative ways of gathering information from an increasingly complex network.

Years ago, life was much simpler on most LANs (insert harp music here). A single wire ran through the middle of the room, and every device on the network would communicate through this strand of copper. Using network management tools and protocol analyzers was simple, since connecting to the network at any point provided a view of every packet traversing the network.

LAN switches dramatically changed the world of protocol analysis. Suddenly, networks were taking this single wire in the room and effectively slicing it into hundreds of smaller pieces! It now became a search and rescue mission to manage the network, and finding the needle in this new haystack was a daunting task. LAN switch manufacturers weren't providing assistance, because most early LAN switches neglected network management capabilities in an effort to get their product to the market as quickly as possible.

LAN switches also removed an important network analysis requirement - connectivity to a physical port! File servers and workstations now connect directly to a switched port, with no interface available to connect an analysis tool into the middle of this single strand of copper or fiber.

Today, there are four major methods of connecting into a switched network:

* LAN Hub - For a half-duplex Ethernet connection, a hub can be placed between the workstation and the switch to provide a connection for the protocol analysis or network management device.

* Tap - Some manufacturers are creating stand-alone taps that provide an interface for an analysis tool. These taps have the advantage of supporting many different network topologies and media.

* 'Mirror' port - Many LAN switches have the ability to redirect traffic from one port to another, providing a 'mirror' for the protocol analyzer to use for access.

* Matrix switch - Enterprise networks use matrix switches to provide an electronic A-B switch to provide connectivity for the protocol analyzer. Matrix switches can also be controlled in-band and out-of-band, providing a good solution for analysis connectivity in remote locations.

In the next issue of Network Uptime, we'll investigate the advantages and disadvantages of each of these solutions. We would also like to hear your comments on the method that YOU use for attaching your protocol analyzer. Which method do you use, and how well does it work? Would you like to use another method? Send your comments and thoughts to Switches@NetworkUptime.com.

====
Free/Shareware Pick of the Moment
====

tcpdump
http://www.NetworkUptime.com/tools/unix/analysis/capture/index.html

There are classics, and then there's tcpdump. Van Jacobson's history with protocols and the Internet is well known, and his packet capture program for Unix platforms is probably just as popular. If you have a Unix system without a packet capture utility, you should download tcpdump as part of your cache of network tools!

====
Network Uptime Surf Report
====

http://www.GroupStudy.com

Are you working towards a certification? The surf is up at GroupStudy.com, The Independent Website for the Cisco Certification Mailing List! This site contains mailing lists, online technical study notes, chat capabilities, a bookstore, and much more! If you're nose is in the books, you should stop by GroupStudy for additional help and support.

====
Network Uptime Management Tip
Finding the Right Network Interface Card
====

Almost all network analysis tools are now running in a graphical user interface of some kind, and most tools use the Windows 95/98/NT environment as their method of displaying graphs, charts, and dials. The Windows operating system allows for pretty pictures and more control over the environment, but many Ethernet drivers that are included with Windows have not been designed for high-speed protocol analysis. The inefficiencies built into many network drivers may prevent the analyzer from obtaining information when the network is at high utilizations, or errors at the physical layer may not propagate to the protocol analyzer results.

To work around some of these shortcomings, many protocol analyzer companies have worked with the most popular network card manufacturers to create enhanced network drivers. Some network card manufacturers have ndependently created drivers that work well for network analysis tools.

To determine the best network card for your protocol analyzer, visit the technical support web page for your protocol analyzer or give a call to the technical support engineers. In most cases, the protocol analyzer company has a list of the most efficient network cards, as well as the capabilities and disadvantages for each adapter.

====
Ending Delimiter
====

If you're reading a forwarded copy of Network Uptime, sign up for your own FREE subscription:

http://www.NetworkUptime.com/newsletter/

Promote Network Uptime! Add Network Uptime graphics and banners to your web page:

http://www.NetworkUptime.com/graphics

To unsubscribe from Network Uptime, use the above URL, or email Majordomo@NetworkUptime.com with the following text in the body of the message:

unsubscribe NetworkUptime

For questions or comments, email us at James@NetworkUptime.com or visit the web page!

==== End of Network Uptime ISSN: 1529-6938 Issue 02 00 00 00 00 05 00 01 (c)2000, NetworkUptime.com, Inc. http://www.NetworkUptime.com ====