Choices, Choices: What's the Top Net Operating System?

By Charlie Schluting | Oct 6, 2005 | Print this Page
http://www.enterprisenetworkingplanet.com/netos/article.php/3554356/Choices-Choices--Whats-the-Top-Net-Operating-System.htm

It's an eternal debate we probably can't resolve in these pages, but we're going to give it a shot anyhow: Which operating system is the very best ... the one for which we'd forsake all others? Over the next few weeks we'll tackle that question.

This week, we'll begin by examining how effectively a network or systems administrator can operate using the various tools available on several platforms, including Microsoft Windows, OS X, Linux, and FreeBSD. Operating system usefulness should ultimately be determined separately for each task: desktops for administrators, desktops for users, and servers. It doesn't make sense to talk about how Microsoft's IIS makes a computer insecure when grandma will (hopefully) never be using that feature. The journey beings with a few examples of tasks that administrators do on a regular basis.

Sniffing the wire
More often than they'd like, administrators need to sniff packets from the wire to examine various anomalies on their network. This may seem like a straightforward task, but it really isn't. You must have a network card that supports promiscuous mode, so the hardware will read packets that aren't destined for it. Most 10/100/1000 Ethernet cards support this mode, so in Linux, FreeBSD, and OS X it normally "just works" when you run tcpdump. Sniffing wireless packets isn't nearly as seamless. Many wireless cards, such as the Airport, do not support this mode of operation. However, this isn't an operating system issue, it's a hardware limitation.

Sniffing packets in Windows, however, requires third-party programs. There are numerous commercial packet sniffing application for sale, but free ones exist too. Ethereal, a favorite among many some Unix users, is available for Windows. It does require that a Windows-based libpcap (called winpcap) library be installed first, but operates very well once it's installed. In short, packet sniffing is a common task, and can be done from any operating system.

Using Serial Ports
Talking to servers, routers, and switches with your serial port is always an interesting experience. It can seem that each device has it's own settings and requirements. Thus, the ability to quickly change serial port setting, or define multiple profiles, is a requirement.

Shipped with Windows, HyperTerminal does the job. Its terminal emulation isn't always the best, but most of the complaints result from users not using the correct terminal type. HyperTerminal provides a mechanism to create multiple saved profiles, so dealing with various serial port settings isn't too cumbersome. Many people dislike HyperTerminal, but you can get the job done using it.

In Solaris, Linux and FreeBSD the options are all the same. They all come with the "tip" program, which uses /etc/remote to define profiles. It works well enough, but new users generally prefer to install minicom, which builds on all Unix operating systems and provides the same functionality.

OS X, however, presents some challenges. Most Apple hardware comes lacking a serial port, so you need to purchase a serial-to-USB adapter. Some of these adapters come with drivers for OS X, so the only remaining issue is finding an application to talk to the serial port. Minicom can also be installed on OS X. It seems that you can get the job done with any operating system, again.

Trunking for Peace
When operating a network with many VLANs, the operator might need to access a specific network directly. Instead of plugging his or her laptop into a switch port configured to live on a specific VLAN, he can instead run a trunk to his workstation. The VLAN trunk is the method by which switches and routers connect together to share networks. If you connect a trunk to a desktop machine, you can configure it to talk directly to specific VLANs. This is very beneficial for troubleshooting, and makes sniffing packets on all networks much easier.

The idea is that you'll need to create multiple interfaces, one for each network you wish to talk to. Since this is on a VLAN trunk, you also need to specify which VLAN tag is being used, so it knows which packets to send to the new virtual interface. When configured properly, an administrator can easily bring up an interface in any VLAN that exists on the trunk. Beyond simply sniffing broadcast packets, this is very useful when troubleshooting routing issues too.

802.1q (the trunking protocol) is supported on a few select gigabit network cards from Sun. Before the latest patches, VLANs were quite painful to get working on a SunFire V210 with Solaris 9. It's supposed to work, but results vary.

In FreeBSD and OS X, creating a new VLAN interface and assigning IP addresses is a snap. The required commands are built into the ifconfig utility. Linux provides the vconfig utility that provides the same functionality. More expensive network cards will handle VLAN tagging, i.e. adding the VLAN id, within hardware. It can be difficult to tell whether the VLAN tags are dealt with in hardware vs. the operating system's software in Linux and BSD. The telltale method is to run tcpdump and see if the VLAN identifications are in the packets. If not, then they are being stripped by the hardware before the operating system gets the packet. This can be quite confusing at first, but the ability to do this in software means that any network card can be used to talk 802.1q.

Windows doesn't support 802.1q natively, but some network cards' drivers do provide this functionality. The Intel Pro cards come with a very simple GUI for configuration of VLANs. It works, but this is dependent on the network card and vendor's software.

These are just three examples of tasks that many people perform daily. In a more general sense, most people will use SSH or a remote desktop to manage a server, which can be done from any operating system. There are likely numerous other examples of administrator utilities that function only partially on the various platforms.

In general, the more advanced features are going to show up in open source operating systems first. Others may show up as feature-limited versions in commercial operating systems, or may not appear at all. A given platform's usefulness to an administrator is mostly going to depend on what the administered servers are running, and of course, that person's level of comfort with the operating system.