NICs and networking protocols aren't as sexy a topic as microprocessors and motherboards. They don't come with code names of mountains, cities, or rivers, nor are they supported by a team of blue-faced men doing wild drum antics. Instead, reading about NICs is a little like reading about plumbing. However, your network interface can make all the difference when you are trying to squeeze the last drop of value from a $15,000 quad-processor server. Network interface technologies are therefore one of the most active areas of server hardware development today. Types of NICsNICs run the gamut from costing $15 for 10/100BaseTX Fast Ethernet cards up to being very specialized high-speed multi-gigabit cards costing upward of $1,500. These more expensive cards perform special functions, such as TCP/IP offloading. Note TCP/IP offloading takes the TCP/IP processing that your CPU does and offloads the TCP/IP stack onto a specialized and optimized application-specific integrated circuit (ASIC) on the network card. You don't want to spend tens of thousands of dollars on a departmental server and then sip through a straw the data the server produces or consumes. That's why server administrators always opt for and recommend superior networking equipment for reliable and dependable connectivity. When you network a modern server or set of servers, you need to put aside some of your older, hard-won PC networking skills. Long gone are the days of the 16-bit ISA (Industry Standard Architecture) bus, or even IBM's proprietary 32-bit MCA (Microchannel Architecture) or EISA (Enhanced ISA) networking cards. They are history as far as server technologies are concerned, although you may from time to time find them in legacy server systems. You can also forget about networking connections such as BNC or AUI type connectors. Technologies that relied on those connections are also a thing of the past but are also still seen from time to time on production networks. Apple and Novell held out a long time with their protocols and standards AppleTalk and IPX/SPX, but both have given way to TCP/IP in lieu of proprietary systems and technology. While client systems are overwhelmingly supplied these days with 32-bit PCI Ethernet cards and RJ-45 connectors, server networking employs many different networking standards and will almost always have multiple network interfaces running at the same time (called multihoming). In multihoming, a computer has two or more network addresses, where each address is identified by its own NIC. Multihoming is most often used to communicate with different networks, often to provide a physical and protocol isolation between the two networks. A firewall or proxy server is an example of a dual-homed system. Table 10.1 summarizes the different NICs available today.
EthernetEthernet (along with its variations) is by far the most predominant networking hardware standard in use today. This is the case for several reasons, but the fact that the hardware tends to be relatively inexpensive and easy to find, native support from all operating systems, and the reliability of TCP/IP over Ethernet have all contributed to the widespread support of Ethernet. There are three Ethernet standards:
Most server motherboards ship with at least one Ethernet port, and nearly all these ports (and the aforementioned cards) use the RJ-45 connector type. The newer motherboards tend to ship with onboard GigE built in. Figure 10.1 shows a dual-homed server motherboard. Figure 10.1. A dual-homed network server board.
Unless you are working with older equipment, it is best to use GigE NICs in your servers. The cost of NICs that support GigE isn't much more than the cost of those that support Fast Ethernet, and as the technology gets more widespread, the cost of hubs and switches will continue to decrease. As it is, the cost of GigE hubs and switches is quite reasonable, around $10 to $40 per port. The main difference in pricing is between unmanaged (but autosensing) ports and managed (and intelligent) ports. The intelligence here relates to the inclusion of special algorithms to manage traffic as well as techniques for increasing the speed accuracy of data going through the port. Fibre ChannelFibre Channel is today's preferred interconnection technology for high-speed server storage I/O connections. The current speeds (called throughput) range between 1Gbps and 2Gbps (gigabits per second). Fibre Channel may become less popular in the next few years as faster Ethernet technologies arrive, but for the foreseeable future, you can expect Fibre Channel to be strongly supported, if for no other reason than that it's a highly reliable technology. Note To read further details about Fibre Channel, go to the Fibre Channel Industry Association (FICA) website, at www.fibrechannel.org. FICA is the industry standards group for Fibre Channel vendors. It writes the standard specification and does plug festsmeetings at which vendors get to test their equipment against other vendors' equipmentamong other things. To see what the future has in store for Fibre Channel, you may want to take a look at the road map at www.fibrechannel.org/OVERVIEW/Roadmap.html. The majority of SANs are built using Fibre Channel technology. Because Chapter 12, "Storage Area Networks," describes SANs in some detail, this section takes a brief look at the NIC hardware used. More and more server administrators are being asked to integrate storage server technologies, and Fibre Channel host bus adapters (HBAs) are something you may be asked to install and support. (An HBA is the Fibre Channel equivalent of a NIC.)
The name for an HBA or another Fibre Channel device with an address is a node, and a Fibre Channel node offers multiple ports or listening channels, just as you find in TCP/IP devices. A Fibre Channel node comes with a unique 64-bit worldwide name (see www.t13.org/docs2002/e02136r1.pdf) that is assigned by the card's manufacturer. In a switched-fabric network, a port is assigned a 24-bit ID; in an arbitrated loop network, a port is assigned an 8-bit address. In both cases, these addresses are dynamically assigned, and when the two SAN Fibre Channel network types are interconnected, the 8-bit address is translated to 24 bits for compatibility. A channel, as first described in mainframe interconnects, is a dedicated interconnect pipe. Because Fibre Channel is often the next step up from direct attached storage (DAS) SCSI, you will often see the two technologies compared and differentiated. Fibre Channel provides longer wire lengths, more ports, and greater remote administration possibilities. An arbitrated loop can provide theoretical support for up to 127 ports, and a switched-fabric network can support 224, or 16,777,216, ports. Latency issues reduce these theoretical results significantly, to perhaps 50 ports for an arbitrated loop and 15,000 for a switched-fabric network. A Fibre Channel HBA is most often found as a PCI card (as shown in Figure 10.2) and is driven in Windows by a SCSIPort or Storport minidriver. It is common to see Fibre Channel HBAs with dual ports to provide additional fault tolerance. Fibre Channel HBAs connect to either fiber-optic or copper cable; the former is faster, and the latter is cheaper. Copper has a range of around 30m (or 100 feet), whereas optical cable can work up to 2km for multimode or 10km for single-mode cable. You will also find that copper cable is more susceptible to crosstalk, while optical cable requires a conversion between light and electrical signals as it traverses switches and HBAs. Figure 10.2. Fibre Channel NICs look similar to Ethernet NICs but use optical cabling.
In terms of connections, Fibre Channel HBAs are not standardized connections. Depending on the technology type, you will find any of the following: Gigabit interface converters (GBICs), Gigabit link modules (GLMs), small form factor (SFF) adapters, and media interface adapters. Therefore, when selecting a Fibre Channel HBA, it is important to know what type of SAN you are going to connect it to. Wireless Ethernet (Wi-Fi)Wireless Ethernet, or Wi-Fi, is based on the IEEE 802.11 standard for radio frequency (RF) broadcasts. A Wi-Fi NIC is both a sender and a receiver of radio signals. 802.11 standards operate at different radio frequencies. The 802.11b standard operates at 900MHz (where some older phones operate), and while the 802.11g standard operates at 2GHz (where newer wireless phones and microwave ovens operate). Wi-Fi lets you do away with wires entirely. However, you still need at least one wired connection to connect to the Internet, so at least one of your wireless devices must be a router with a connection to your ISP's modem or a similar gateway device. Other important issues in Wi-Fi are interoperability standards (e.g. 802.11a versus 802.11g), coverage areas, and security concerns. Still, there is a lot of interest in adding Wi-Fi capabilities to servers as well as all other computers, no matter the pros and cons. From the standpoint of wireless NICs, there is no differentiation yet between adding a Wi-Fi Ethernet card to a server and adding that card to a PC. The main issue with adding Wi-Fi to a general-purpose server is whether you can find the appropriate drivers or management software to work with your card. The speed of the connection may also become a bottleneck because wireless network speeds have yet to break significant ground in the backbone area of networks. Because the backbone is where production servers are most likely to be located, this is a significant drawback. You can add Wi-Fi networking to a server by installing a PCI card, an external USB device, or even a PC Card with an adapter. None of the wireless standards is considered a high-throughput network interface, which is why Wi-Fi technology doesn't really get much discussion when it comes to server networking standards, so you don't find many servers that have Wi-Fi. The trend in wireless networking has been to market special-purpose wireless devices in the form of wireless routers or wireless access points. You buy these devices as appliances and then connect to these standards through a network card or a hub. This is a much more common and cost-effective approach to creating a server-based Wi-Fi solution than simply adding a Wi-Fi PCI card to a server. The most important consideration when adding Wi-Fi to a server is the selection of the wireless protocol. If you intend to stream large files or multiple files to a set of clients, then your server needs to connect wirelessly using one of the faster wireless standards. 802.11b is not sufficient, and 802.11g or 802.11a may be only marginally effective. You might want to install one of the newest protocols or use technologies such as double-speed 802.11g that several vendors offer. It is always best with Wi-Fi technology to minimize the number of different vendors' products you use. You will almost certainly find that a technology such as D-Links's Super G might be compatible with NetGear's Super G but will almost certainly have problems attaining the rated throughput when connected to a Linksys Wireless-G with SpeedBooster product. Hardware CompatibilityWhile on the surface a NIC might not seem like very exotic technology, it is an essential part of network services for your computer. The last few years have seen the speeds of new NICs rise dramatically. Often new NICs are the first kinds of add-in cards that take advantage of new bus interface standards. This section looks at the kinds of NICs that are on the market today. The following are the most common form factors for server NIC interfaces:
Although external adapters, or PC Cards (with or without adapters, such as IDE adapters), are available, they aren't commonly used with servers.
PCI, PCI-X, and PCI Express are all related hardware standards. There are currently as many as 10 different types of PCI slots on motherboards. PCI itself is available as the following:
PCI-X is available as the following:
Finally, the emerging PCI Express standard supports four different channel depths:
Figure 10.3 shows some pictures of the different kinds of PCI slots. Figure 10.3. Different PCI package types.
For PCI Express, the number refers to the number of channels, and this is also a measure of the expected throughput of the board. The x1 and x4 standards appeared first, and the x8 and x16 cards appeared shortly thereafter. Of the aforementioned standards, the two high-performance options that are the most commonly available are 64-bit/66MHz PCI and PCI-X. The problem with both of these standards is that you may only find one or two of these kinds of card interfaces on a server motherboard. PCI-X comes in several different channel widths, including 1x, 4x, and 16x, and you may need to use the higher-performance slot to support an enhanced graphics board (or something else). Therefore, you might want to consider breakout boxes or PCI expansion systems of the type sold by Magma Mobility Electronics (see www.mobl.com/expansion/pci/7slot6466/#) if you need to provide enhanced I/O. Figure 10.4 shows a seven-card expansion chassis as well as a serial bridging PCI card that provides a 5Gbps full-duplex link to the PCI expansion system. Most often, this type of breakout box is a connectivity solution for storage devices, SANs, or network attached storage (NAS). Figure 10.4. Magma's external PCI expansion chassis and PCI director card.
Installing Network Interface Devices and DriversAs you're probably well aware, your network interface isn't just about hardware. Software plays an essential role in system performance and stability. From the underlying protocols used in the operating system to the NIC's drivers for the operating system, knowing how to correctly install your network interface devices is a critical skill. Well-implemented driver software can help ensure the stability of your server, and bad driver software can cripple your systems. So yes, the type and version of the network driver you use do make a difference. Network drivers are among the most heavily used pieces of software on a network computer, so it shouldn't surprise you that driver software tends to get corrupted more easily than other system functions. While architecting Windows 2000 Server, Microsoft found that poorly written or malfunctioning device drivers were the second most common reason for system restarts, lagging only slightly behind human error. So today Microsoft requires that its Data Center Edition use certified NICs and drivers only. When you install a NIC, your operating system may or may not recognize the card automatically. Not all operating systems can handle plug-and-play, and not all adapters are listed in the operating system's database of device drivers. Therefore, it is always a good idea to check whether you have an up-to-date installation disk from the network card vendor before you begin an installation. Also, you should check your vendor's website to find the current driver version offered online; this will usually be the most up-to-date and current set of drivers available for your NIC. When you are installing a popular network card, such as NetGear's FA311 or GA311 (Fast and GigE cards), into a popular operating system, chances are that the card's driver is contained in the operating system distribution's installation routine. However, the more exotic the NIC, the smaller the vendor, or the less commonly used the operating system, the less likely that the very latest driver is available or even that any driver is available. You should be sure to have your vendor's device drivers on hand when you install your NIC. Note Make life easy on yourself. Instead of trying to physically navigate to your vendor's website, enter a search string such as "GA311 driver download" into your favorite search engine. Chances are that one of the first few matches will take you directly to the page. Many nonstandard sites maintain libraries of network card drivers, and they are particularly useful when you are trying to locate an older version of a driver. Tip A NIC without a suitable driver for your server's operating system is nothing more than toxic landfill. It's the software that makes it work. It is really important to understand how to install your NIC driver software, but it is perhaps more important to know how to uninstall your NIC driver software. The reasoning for this is simple: Many operating systems don't really delete a driver you uninstall; they merely leave the software on disk. When you go to reinstall the software, you may find that you have reverted back to the driver you've just been using. If the driver version number is the same, then it can be impossible to determine that the driver software is the cause of your problem. Each operating system is a little different in the manner in which it handles NIC and driver installation, but the differences are largely superficial. Let's take a brief look at how two operating systems install a NIC and its driver. We will look at configuring a Windows Server 2003 server and a Red Hat Linux server. When you install a new NIC into a Windows Server 2003 server, the operating system almost always recognizes that a new card has been detected and tries to match that card to one that is contained within its driver database. During installation of the NOS, many NIC drivers are copied to the Windows system folder (C:\Windows\Drivers Cache\i386), and installed drivers are copied to C:\Windows\System32\Drivers. There are a few generic system drivers in C:\Windows\System, but mostly this folder contains *.DLL files. If Windows doesn't find the correct driver for your NIC, it will ask you to provide a path to an installation disk. There's a chance that the driver is the Windows Update website, but very often, if the driver you need is for a NIC, you're not going to have the network or Internet access needed to utilize the Windows Update site. In some cases, you may need to use another system to help facilitate the download. Note A DLL file is a file that contains executable code and data bound to a program at load time or runtime. It is used among several programs that share the DLL simultaneously. On the remote chance that Windows Server 2003 doesn't recognize your device as a plug-and-play device, you can initiate an installation with the Add/Remove Hardware applet found in the Control Panel. After you launch it, this applet searches for new hardware. If it finds more than one new device, it generates a list and asks you to specify whether it has found the correct one. You can instead specify the NIC as the item you want to install and manually provide the driver software. In some instances, vendors make use of their own installation executable or application files and setup routines, but for the large majority of NIC vendors, the preferred choice is to use the routines that the OS provides. You are most likely to encounter vendor installation programs when the network or host bus adapter you are installing comes with associated software such as network management software. In any case, you should consult the manual for your NIC before installing any software. After you successfully install your NIC, it should immediately be fully operational. It is a good idea to go into the Windows Device Manager to ensure that there are no alerts or warnings next to your new card. Note The Device Manager, which is accessible through the System applet within the Windows Control Panel, is a tool that is included with just about every Microsoft Windows operating system in use today. The Device Manager can display and control the hardware attached to a computer running a Windows-based operating system. When a piece of hardware is not working, the offending hardware is identified in the Device Manager, allowing the user to deal with it. Disabled devices are marked with a red X; a yellow exclamation point indicates a failed or malfunctioning device. Certainly, when you are experiencing difficulties with your network card, one of your troubleshooting stops should be the Device Manager. If you decide to reinstall your driver software, you need to make sure that the driver software currently in use is deleted. Opening up your NIC's properties dialog box and rolling back the driver is not sufficient. Instead, you should use the Add/Remove Hardware applet to completely uninstall all traces of the NIC from the OS. You should then restart your system and reinstall the driver from which you wish to restore. Remember that Windows doesn't automatically delete drivers from its cache. Driver rollback is a feature in Windows XP and Windows Server 2003 that stores the past driver when you replace a device driver and allows you to revert back to the previous version. Keep in mind that there is only one version of the driver stored, so if you are trying to fix a problem, you should try rollback first before you install a new version in order to fix a problem. Device Driver UpgradesIf you have a NIC that is commonly used in other systems, chances are that any plug-and-play OS will recognize it. Should you use the version of the driver that your operating system provides or the one that you find on the disk that came with your card? Different people will give you different answers and advice on this issue. Many people prefer to use the device driver with the latest revision number obtained from the vendor's website. If your hardware was purchased significantly later than the last revision of the operating system, then you might want to use the version found on the disk in preference to the version your OS provides. If the OS is newer than the hardware in question, you should use the OS version. There are no hard-and-fast rules concerning versioning, and you may find that an older version of a driver works better (that is, is faster or more compatible) than a newer one. NICs and their drivers are notoriously difficult to diagnose when problems occur. Therefore, it is always good to have an extra NIC or two handy to substitute for one that is deemed problematic. Having another card to swap in and out can help you troubleshoot a problem by isolating it. If another NIC works, then you know it was the last NIC installed. When considering stocking replacements, you should keep a duplicate card as well as a different modeland preferably a different vendor's card entirelyjust in case your problem is a problem with that brand or version of the card. Troubleshooting a Network InterfaceBecause a network interface comprises both a hardware component and its related software, your troubleshooting needs to test both aspects of its connectivity. You should go through the troubleshooting process one step at a time. Before you begin other testing, you should open a command prompt and enter the ipconfig /all command to determine whether your NIC has an acceptable IP address and is healthy. If your network interface's address is dynamically assigned by DHCP and no address appears or if you are having problems, you can try using ipconfig /release followed by ipconfig /renew to refresh your connection. In certain instances, such as with Windows XP Professional Edition, this solves many connection problems. If the information ipconfig /all lists is accurate, you can try using the ping utility to test your NIC to see if you're able to send and receive data. To do so, you open a command prompt and type the following: ping 127.0.0.1. You should see a reply from the loopback address of your HOSTS file if your card is active. You can also install a loopback adapter as an interface in your system and then use the preceding command to ping that interface. It's a common technique that is used to determine whether a network stack is operating properly. Some systems don't let you install a loopback adapter, so you should make sure that your system does have this feature or install it if it doesn't. You can also use ping localhost, and that command will return a reply. This is because in your HOSTS file, 127.0.0.1 maps to the domain name localhost. If either or both of these commands fail, you should suspect that there is a problem with the card itself. You can try to ping by IP address to see if you have network connectivity and by the network client by name to test name resolution. Either test will show you whether data can travel from your PC to another system without error or trouble. In some environments (perhaps on your corporate network), the ping tool may be turned off, so you might not be able to test connectivity. In such instances, ping is not really turned off so much as it is blocked. After all, if TCP/IP is installed, then so is the ping utility because ping uses a protocol called Internet Control Message Protocol (ICMP), which is an extension to Internet Protocol (IP) within the TCP/IP suite of protocols. ICMP produces error messages, test packets, and other informational messages so that you can find problems on your network. Because ICMP can also be exploited by attackers and crackers, it's important that you disable itfor example, by blocking it with an access list on a firewall. If ICMP is blocked, you will not be able to use ping. If ICMP is blocked, open a browser or My Network Places and try to navigate to another system's shared folders if any are available. You should be able to see whether network activity is occurring by looking in the Network Connection dialog box, by seeing a system tray icon, or by using a utility such as Network Monitor, which can capture and analyze data on a network to which it is connected to and configured.
If you don't detect a connection, it's time to check out the physical mediathat is, your cabling. The first thing to test is that the cable into the NIC is active and functional. The easiest way to test your cable (and everything else behind it) is to move that cable to another network interface and see if that second interface remains active. If it does not, you should go back and swap the cable or swap the connection port on the hub, switch, or other device to try to correct the problem. Your NIC should indicate its status. You should check that the NIC has link light activity. A healthy NIC should indicate its condition by displaying a lit up link integrity light. For example, a 10/100Mbps card often has two green lightsa 10 LNK (or link) light, a 100 LNK lightand one yellow ACT (activity) light. If the two LNK lights are lit, this indicates that there is a good connection. If the lights are off, there is no connection. Similarly, the lights should be on at the port of the hub or switch to which the cable is connected. The ACT light on the NIC should flash when there is network traffic passing through it, and the flashing should intensify or appear steady if there is heavy network traffic. A broadcast storm is an excellent indicator of too much network activity. A broadcast storm is the arrival of too many packets at a computer for a period of time. The LNK light on your NIC (or other network infrastructure device) should appear solid. Broadcast storms disable all functionality on most networks, so if your NIC or other device has steady LNK lights on, this may indicate a problem. Contact your network administrator if you suspect that you have a problem. If the NIC appears active and simultaneously you have no network traffic, the next step is to perform a test from the server itself. To do so, you need to be logged in to the server as an administrator (either in front of or through a terminal session). First, you need to check that the driver software is loaded correctly. For Windows Server 2003, you should do the following:
If the network interface appears active and healthy, you might want to try moving the NIC to a different PCI slot. An interrupt (IRQ) conflict may be the problem. In very rare instances, the network protocol stack you are using may be corrupted and need to be replaced. This is much more common for modems than it is for NICs, but it does happen. You need to make sure your server's installation disk is handy prior to performing this action. To reinstall the network protocol stack in Windows Server 2003, do the following:
Removing a protocol stack should be done only as a last resort. Often, the problems encountered with a network interface do not arise because of a NIC's malfunctioning but due to some network service issue such as inappropriate addressing, security issues, and other software configuration problems. NOSs provide a number of tools that can help you determine whether any of these issues are your problem. The TCP/IP protocol stack has a rather large collection of useful tools (such as ping) that are freely available and are part of all current NOS toolsets that use TCP/IP. Table 10.2 lists some of the most common commands.
These commands vary by operating system, so be sure to check the man files or help files of your OS to see whether the command exists and what syntax that version supports. Note For a listing of UNIX command programs, see the Wikipedia listing at http://en.wikipedia.org/wiki/List_of_Unix_programs; for DOS command, see http://en.wikipedia.org/wiki/List_of_DOS_commands; and for Windows, see http://en.wikibooks.org/wiki/Guide_to_Windows_commands. Locating BottlenecksMany of the factors described in the preceding section can contribute to or cause network traffic slowdowns. However, because a network slowdown can also be caused by applications and by the network protocol stack, sometimes you need to take a more general approach, involving probing the different protocol layers. Let's take a look at how this is done with TCP/IP, which is representative of many other networking protocols. The first thing you should determine is whether your latency is due to a problem with the network or whether it's an application-specific issue. For example, you might think you have a latency issue because of your NIC when what is really slowing down the network is the transfer of a large database, the sending and receiving of files via FTP, and so on. The list of examples of what could cause problems on a network is virtually infinite. For example, you could have a bad NIC (commonly known as a chattering NIC) that sends endless amounts of data out on your network, causing saturation. In any case, your primary goal is to isolate the problem. To accomplish this goal, you should do a packet trace during a suspected slowdown. You can send a sample of data to determine the source of latency by using another ICMP-based tool called tracert (for Windows) or traceroute (for UNIX and Linux systems). To see tracert in action, you should open a command prompt and type the following: tracert <12.1.1.1>. You should replace the IP address in this example with one you know or with the hostname of a system you want to check. For instance, you can check latency to your favorite website by sending a ping to Yahoo.com. Because Yahoo allows ICMP to pass its network, you are able to receive a response. If you perform the same test with MSN.com, you will find that ICMP has been disabled. This should show you the importance of understanding how to test and what tools you should use to perform tests. When you send a TRacert to 12.1.1.1, you should see three connect times for the next server in line to the name server as shown here: C:\>tracert 12.1.1.1 Tracing route to 12.1.1.1 over a maximum of 30 hops 1 10 ms 5ms 4ms 142.55.25.1 2 75 ms 15ms 94 ms 11.1.0.43 3 55 ms 82 ms 102 ms 11.1.0.1 Trace complete. An asterisk indicates that your outgoing packet has collided with an incoming packet, called a data collision. You see more collisions when network traffic is higher. If all three packets are asterisked, then you may have a dead connection. You should also write a tracefile by using tracert. At the command prompt, you type the following: tracert <mydomain.com> >> C:\text.txt. The results of your trace will be data that you can analyze. The idea is to figure out who is retransmitting packetsa client or a server? If the client is retransmitting packets, the server isn't acknowledging their receipt. If the server is retransmitting packets and the client doesn't acknowledge them, you know the problem is local. You can use tracert to determine the path a data packet uses and the latency of each hop. There are also some very sophisticated protocol analyzers you can purchase to analyze network traffic for an enterprise. Such tools come in the form of both software and hardware/software combinations. Most NOSs also come bundled with packet analyzers. Microsoft's Network Monitor (netmon) is one such tool. Network Monitor ships as a lighter version (with less functionality) in Windows Server 2003 and in a fully functional version as part of the Microsoft Systems Management Server (SMS) package. The next step is to probe the performance of the TCP stack. If the entire stack has problems (that is, the latency is being experienced across all server applications), you likely have an operating system problem. When only a single application is involved, you can isolate the issue by examining the traffic at the port used by that application. When only one user is affected by the problem, you should suspect that a security issue needs to be resolved. Note If you are unsure of the port number a specific application uses, the first place to look is a listing of well-known ports. Port traffic must be registered by application, and you can find a complete listing of well-known ports at www.iana.org/assignments/port-numbers. This may not solve your problem, but it is a good starting point. If you monitor traffic by port, you can see activity for each port as the application you want to diagnose sends and receives data. You can use a packet sniffer to not only determine the port traffic uses but also look inside the data to see what was sent and received. An example of an application that does port monitoring and sniffing is HHD Software Accurate Network Monitor (see www.hhdsoftware.com/netmon.html), which works with various versions of Windows, including Windows Server 2003. Another example is ObjectPlanet's Network Probe (see www.objectplanet.com/Probe/). Monitoring an application's traffic also allows you to determine whether a bottleneck is an application or a TCP issue. You should look at the TCP window size advertisements. The TCP window size is the amount of data that can be received and stored in a buffer during a connection. The sending system can only send out that much data before it must stop and wait for an acknowledgement. The advertisement referred to is the communication that indicates the size of the buffer. The size of that window is generally around 8760 or higher. If you see a lower Window size, you are seeing a slow application layer that is trying to take data out of the TCP buffer. When the application is slow, you may find that Window size drops to zero, which means the application is preventing additional data from being transferred. The Window size is a measure of the amount of unacknowledged data that can be transferred, so if a recipient receives a zero-size window, no more data can be sent back. In diagnosing network slowdowns, you should look for the following issues:
All these problems can cause degradations in network and/or system performance. Multihoming and Fault ToleranceWhen you install two or more concurrently active network interfaces, you have a dual-homed or multihomed system. There are several reasons you might want to have a dual-homed system:
Many server motherboards come with two network interfaces. The intent is to provide one network interface for monitoring the motherboard and another for network communication. You might also want to have two interfaces so that you can use one to talk to an external network and the second to communicate to an internal network. Consider, for example, a motherboard that comes with both a GigE port and a Fast Ethernet port. If you are using this board as a firewall server and one of the connections is to the Internet, you can use the Fast Ethernet port to connect to the Internet and the GigE port to connect to your internal network. Unless the server is on an Internet backbone or Internet2, you would rarely be able to saturate a Fast Ethernet network interface. Configuring a dual-homed system isn't much more difficult than configuring a system with a single network interface. A couple extra issues add complexity, and one issue can be a gotcha. First, to have a dual-homed or multihomed system you need to have two or more network interfaces. When you have multiple NICs installed, they are given default and generic interface names. In Windows Server 2003, that would be Local Area Connection, Local Area Connection 1, Local Area Connection 2, and so forth. These NICs can be renamed for easier identification. For UNIX/Linux (depending on the distribution), that designation is commonly seen as le0, le1, and so forth. These are logical names (just like with Windows), and they can be renamed with more appropriate names, such as External, Internal, or whatever is appropriate. The key is that you have to be able to recognize which network adapter is which. When you have two or more of the same model of NIC installed, that can be a challenge, and you need to be careful. Many server programs that require two or more active network interfaces for successful operation are likely to include network adapter configuration as part of their routines. This is certainly true of any network "front-facing" server, such as a firewall or network traffic director. Microsoft Internet Security and Acceleration (ISA) Server is also a solid-performing firewall and proxy server solution. Tip If your NOS supports plug-and-play and you use exactly the same network card, some operating systems may not recognize that there are two instances of the same card, and they may not properly configure the second card. This is not true of all cards, models, or operating systems, but it comes up from time to time and is an issue you should watch out for when implementing a multihomed system. |