Protocols


Protocols are the software standards (quite literally, software agreements) that are used to communicate over a network. There are protocols in all seven layers of the ISO/OSI network model. However, for our purposes, the main protocols of interest are those used by applications and the operating system at the transport layer. You are undoubtedly already familiar with transport protocols because they are the ones that you learn to set up when you add or modify a network computer. Figure 10.6 shows the ISO/OSI seven-layer protocol stack, including the protocols discussed in the following sections.

Figure 10.6. The ISO/OSI protocol stack.


Note

For more in depth information on network protocols, refer to Upgrading and Repairing Networks.


Transport Protocols

Each NOS comes with a set of transport protocols that support each kind of network client on the network. In the past, you were forced to know a little bit about the nature of multiple transport protocols, but that is no longer really the case. The rise of the Internet and ubiquity of TCP/IP over Ethernet networking requires that every client be able to run TCP/IP as its transport protocol in order to use a browser or get access to network services such as email or files stored on servers. In a world where printers, scanners, storage, and even refrigerators require TCP/IP addressing, we are now as close to a universal standard as we're likely to get.

Note

NetBEUI was the first of the Windows automated network protocols used for Windows 95. By 1998, Windows 98 was using TCP/IP, but NetBEUI didn't quite disappear. Windows XP was the first version to ship without NetBEUI, which Microsoft no longer supports. If you still are using NetBEUI for Print and File Services, you should consider removing that transport protocol from your network and using one that is supported, such as IPX or, better yet, TCP/IP.


If you are working with a recent NOS, chances are good that you will find that TCP/IP is the only protocol stack installed from a larger set of available transport protocols. If you are supporting Macintosh, UNIX/Linux, or NetWare (and particularly legacy versions of these operating systems), you might need to install other protocols, such as AppleTalk or IPX/SPX in order for those clients to be able to communicate with the server system.

For Windows Server 2003, you should install these other legacy transport protocols by following these steps:

1.

Make sure you have access to the Windows Server 2003 installation disks.

2.

Select Network Connections from the Windows Control Panel folder.

3.

Double-click the named connection to which you want to add a protocol. The Connection Status dialog box appears.

4.

Click the Properties button to open the Connection Properties dialog box, which is shown in Figure 10.7.

Figure 10.7. The Connection Properties dialog box.


5.

Click the Install button to open the Select Network Component Type dialog box, shown in Figure 10.8.

Figure 10.8. The Select Network Component Type dialog box.


6.

Select the Protocol component in the list and then click the Add button. The Select Network Protocol dialog box appears, as shown in Figure 10.9.

Figure 10.9. The Select Network Protocol dialog box.


7.

Click the network protocol you want to install; then click the OK button. The network transport protocols included with Windows Server 2003 Standard Edition are AppleTalk, TCP/IP versions 4 and 6, NWLink/NetBIOS Compatible Transport, and Reliable Multicast Protocol.

8.

Close all open dialog boxes and confirm that you want to install the protocol.

9.

Verify that you have installed the protocol by double-clicking the network connection to open the Properties dialog box. The protocol should be listed as one of the components.

One transport protocol that doesn't get a lot of press but is widely used in many NOSs, particularly for applications such as streaming media, is User Datagram Protocol (UDP). UDP, like its cousin TCP, runs over the IP network-layer protocol and operates at the transport layer of the ISO/OSI network model. UDP uses a more compact form for data transmission, called a datagram, which has only a small amount of header information and which does less data checking to see if the data was correctly transmitted. Whereas missing a section of a document would definitely be a problem, dropping a frame in a movie would not be. UDP is therefore attractive in certain situations. The lightweight nature of UDP makes it faster than TCP because less processing is required to deconstruct and reconstruct the data. UDP traffic uses a separate port from TCP.

You should be judicious in your choices of which transport protocols you install. All network services add additional overhead to a server, so from the standpoint of obtaining maximum performance, you should seek to minimize the number of running services. However, transport protocols also provide a new pathway for exploits, and they represent an additional security path that needs to be monitored and protected.

Note

When running a server, you want to streamline the software used on that server to the absolute minimum. This applies doubly to protocols of any kind. You need to be cautious and always try to understand what is running on your server and why.

From time to time, you should open the Task Manager in Windows or a process list in UNIX/Linux, or you should use some other utility that will show you what applications, processes, and daemons are running on your server. You should then identify which processes to stop or eliminate.

If you are adding the NWLink protocol, you need to be sure to add the Microsoft Client Service for NetWare (CSNW) to provide NetWare access to your server. Windows Server 2003 also provides native file and print services support for Macintosh and UNIX clients.

You can find additional server protocol support from third-party vendors.


Several years ago, servers supporting Macintosh clients would install AppleTalk, those supporting Novell clients would install IPX/SPX, and so forth. While those protocols are still options, they now mainly exist to support legacy clients. The predominance of TCP/IP means that you can support almost any client (except those from before 1998) with TCP/IP alone (supported by other required naming and application services, as detailed in the following section). Thus, having a detailed knowledge of multiple transport protocols is becoming less and less necessary for server administrators.

Application-Layer Protocols

Whereas transport protocols are few, application-layer protocols are many. Some are specific to the NOS you are using, and many can be installed as part of the server's OS distribution that you are using.

Here are some examples:

  • You have one IP address to use for your enterprise but many computers to service. The service that provides the dynamic assignment of private IP address is Dynamic Host Configuration Protocol (DHCP).

  • You type a URL into a browser, and data is requested from the correct system, either locally or on the Internet. That service is Domain Name System (DNS).

  • You search for a printer on your network, and that search is optimized. Here a directory service is used, probably utilizing some variant of Lightweight Directory Access Protocol (LDAP) as its protocol.

Note

TCP/IP, DNS, DHCP, and all the other protocols described in this chapter are big topics that require more space to learn than we have available in this book. Many networking books have been written for beginning, intermediate, and advanced users who need general information about protocols or services or who are trying to solve specific network problems. Among the books you might want to consult are Upgrading and Repairing Networks (a companion book in this series), Sams Teach Yourself Networking in 24 Hours, Sams Teach Yourself TCP/IP in 24 Hours, Sams Teach Yourself Network Troubleshooting in 24 Hours, Local Area High Speed Networks, and Networking with Microsoft TCP/IP.


The aforementioned protocols are genericthat is, a version of each of these services is found in all NOSs, with only slight variations between them. The main idea with these protocols is that they interoperate well between operating systems. You want a DNS request from a Windows server to be able to get an appropriate DNS response, and you want an LDAP request to Active Directory on Microsoft Windows to be able to get an appropriate LDAP response from an eDirectory service running on a Novell NetWare server.

A number of network protocols are specific to particular NOSs but are nonetheless quite important. Chief among them are name resolution protocols. These protocols resolve a friendly, easy-to-remember name, such as Columbia, to its TCP/IP address and vice versa. Currently Windows server technology recommends the use of Network Basic Input/Output System (NetBIOS) or a combination of NetBIOS and Windows Internet Name System (WINS), which is also known as NBT. WINS is an older Windows name resolution service that has been largely replaced on most networks by DNS. NetBIOS is an API that extends network BIOS functions. WINS uses a distributed database listing for name resolution. In fact, you can still find LMHOSTS text files with network resource listings, but because these files must be manually maintained, they tend to be used only on small networks or for absolutely essential and nonchanging resources.

Protocol Binding

The addition of protocols to a network interface is called protocol binding. The process by which a network interface is created is similar to how drivers are loaded. Protocols load one at a time for each network interface, and the order of binding shown in the network connection is the order in which they are loaded. The important point is that the order in which protocols are bound can affect network performance, and you can modify this binding order.

Consider a situation where your network interface runs both TCP/IP for general networking and IPX/SPX for NetWare connectivity. If IPX/SPX is listed before TCP/IP, switching the order will improve your network interface's performance for most general networking tasks.

To change your protocol binding order in Windows Server 2003, you follow these steps:

1.

Select the Network Connections folder from the Control Panel.

2.

Select the Advanced Settings command from the Advanced menu in the window.

3.

In the Advanced Settings dialog box, select the Adapters and Bindings tab (see Figure 10.10). Then click the network adapter you want to modify and then click the protocol binding you want to change.

Figure 10.10. The Advanced Settings dialog box.


4.

Use the up- and down-arrow buttons to change the protocol binding order.

5.

Click the OK button to make your changes.

You also might want to modify the provider order on the Provider Order tab (see Figure 10.10) of the Advanced Settings dialog box. For example, if you don't use Windows Terminal Services, you can move it to the bottom of the list.

The Advanced Settings dialog box is also a great place to determine what protocols you are using and to get rid of the ones you don't need.

Network Operations Management

Network monitoring and management software encompasses such a large category of software (and hardware) tools that entire books have been written about it. The software can be simple, as in the case of the command prompt utilities you have already seen: ipconfig and ifconfig, ping, tracert/traceroute, nslookup, and so forth.

For larger enterprises managing hundreds and thousands of systems, it is common to see network console applications that have so much functionality that entire books have been written about each one of them. Beyond simple console applications are the network framework products that support many snap-in monitoring and management tools.

Let's consider network utilities by category, according to tasks, in order to get a feel for what tools you might want to acquire for your monitoring and management toolkit. The following are the areas that most commonly require management:

  • Command-line TCP/IP utilities or graphical utilities based on them

  • Performance Console and Monitor in older versions of Windows and in Sun Solaris and some other versions of Linux

  • Port scanners and protocol analyzers (packet sniffers)

  • Network discovery (typically Simple Network Management Protocol [SNMP] based), inventory or asset, and mapping software

  • Bandwidth management and Quality of Service (QoS) management tools

  • Event monitoring and analysis tools

  • Network loading, routing, and path analysis tools

  • Time synchronization managers

  • Remote access management tools

  • Wireless networking utilities

  • Network security monitors

Consider this list as a starting place for core tools because, depending on the kind of network you have, you might want to deploy additional tools.

Most of these tools are created for use on a single NOS, perhaps with a single protocol, and often come with only with a diagnostic function. (This is not always the case, however.) True network operation management in enterprises where many servers are managed requires both a diagnostic function and a management console. That's where applications such as LANDesk (see Figure 10.11), Alteris, Microsoft Operations Manager and SMS, and Novell ZENworks come into play. You can use these and other applications you find online or in other publications, such as trade magazines.

Figure 10.11. LANDesk's central console lets you manage and monitor a network as well as perform a number of related tasks.


The previously mentioned products are integrated solutions characterized by the concept of a central management console. That is, all these applications let you monitor and analyze a network, perform reconfiguration of systems, remotely install software, and more. Not all these capabilities are included in the base version of each product, but you can add additional capabilities as you need them.

There is a lot of overlap in these different products, and there are many more capable products in this area as well. Some products, such as ZENworks, are notable for directory service management, and others, such as LANDesk, are broad and battle tested and have strong Macintosh client support. Alteris uses a Web console approach that is relatively easy to use (when you know the product). These products are not cheap. Depending on the size of the deployment and the types of capabilities you purchase, you are probably looking at a few thousand dollars per deployed server and $300 or $400 dollars per client. But this category of software pays for itself quickly.

Finally, some of the network management tools that can be added to enterprise frameworks are Hewlett-Packard OpenView, Computer Associates Unicenter, and IBM Tivoli. Each of these frameworks is built so that you can add to them applications that are written in a consistent form. The framework helps you navigate to and employ the software that is installed into it, and the software is written in a consistent manner so that, as with a graphical user interface, you already know how to operate the software at a basic level. Frameworks can add all the tool types mentioned here, as well as application services, such as server antivirus and spam elimination utilities, backup, data migration, and many other tools.




Upgrading and Repairing Servers
Upgrading and Repairing Servers
ISBN: 078972815X
EAN: 2147483647
Year: 2006
Pages: 240

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net