Understanding Protocols and the OSI Network Model

Getting a handle on the invisible part of your network—the protocols that are in use—can be of enormous value in helping you detect problems.

• By Bill Heldman
• May 01, 2002

So far, we've talked about the tangibles of your network—the cabling infrastructure, as well as the switches, hubs and routers. Those are things you can see and touch. But there are invisible components in your network that are just as powerful as the hardware that they're running on. I'm talking, of course, about the protocols running on your network.

According to www.dictionary.com, definition 5, the word protocol means "a standard procedure for regulating data transmission between computers." That is, a protocol is an agreement between devices on the way that they are going to pass data between them.

There are a variety of protocols that you could potentially get involved with and take an interest in:

• WAN protocols such as High Speed Serial Interface (HSSI, pronounced "hissy"), Fiber Distributed Data Interface (FDDI) and X.25
• Routing protocols such as Open Shortest Path First (OSPF) and Interior Gateway Routing Protocol (IGRP)
• LAN protocols such as Transmission Control Protocol/Internet Protocol TCP/IP, Internetwork Packet eXchange (IPX) and AppleTalk
• Application protocols such as Remote Procedure Call (RPC)
• Interprocess Control Protocols (IPC) such as Named Pipes
• Proprietary protocols such as Citrix Corporation's Intelligent Console Architecture (ICA) protocol
• Internet protocols such as Hyptertext Transfer Protocol (HTTP)
• Messaging protocols such as X.400
• Customized protocols such as Microsoft Challenge Handshake Protocol (MS-CHAP, a variation of the CHAP protocol)

See http://www.protocols.com/pbook/ for a fairly comprehensive dictionary of protocols.

As a general rule of thumb, a protocol's job is to do the following things:

• Determine how the sending device will tell the receiving device when it has finished sending some data
• Determine how the receiving device will know when it has successfully received the data
• The method by which the data will be compressed (if any)
• The way in which the devices will know that an error has been made during the transmission of data (error-checking)

You should also note that protocols can be implemented within software or hardware (in the hardware's firmware code).

Protocols
The protocols that are in use on the network are also considered a part of the infrastructure. A protocol is simply an agreed upon way of communicating. If you and I talk with each other in English, we've agreed that the way we'll communicate will be through the English protocol.

Without a network protocol, two computing devices couldn't communicate with one another. Common network protocols include the ubiquitous TCP/IP, IPX, Microsoft's NetBEUI and AppleTalk. But there are many other different kinds of protocols as noted above.

Now for a brief discussion of the main network protocols you'll likely run into during your administrative experience.

A Quick TCP/IP Overview
TCP/IP is actually a huge suite of protocols using ports on a computer that the data travel through (not physical ports—logical). The TCP/IP suite is broken down into two different ways of transmitting data: Transmission Control Protocol (TCP) a connection-oriented protocol that guarantees the stream of the data (packet 1, packet 2, etc.) and guarantees that the packets will get where they need to go (using robust error correction methods) and User Datagram Protocol, a connectionless protocol that relies on datagrams, typically used in a broadcast format. Underneath the TCP/IP suite are many protocols that have specialized uses: Domain Name Service (DNS), for example, is a protocol under the umbrella of the TCP/IP suite that denotes the conversion of IP domain names (not NT/2000 domain names) to IP addresses and vice-versa.

Some protocols function as both UDP and TCP (such as DNS), others only utilize one or the other. DNS utilizes port 53. The Simple Mail Transfer Protocol (SMTP) is a TCP protocol designed for e-mail transfer and utilizes port 25. A good way to find more about all of these is to simply visit www.webopedia.com, key in a search string you'd like to look for (such as SMTP) then follow the links.

Set Your Goal on Becoming a TCP/IP Master
By far, the best training you can give yourself regarding protocols is in the area of TCP/IP. Plan on becoming a TCP/IP expert and you'll save yourself many hours of troubleshooting grief when it comes to network performance issues. Note that there are extensive elements involved with TCP/IP—things like DNS and Dynamic Host Configuration Protocol (DHCP)—that are included when I say that you should consider becoming a TCP/IP expert. Without good knowledge of the Windows components that use TCP/IP, in addition to the common TCP/IP commands, you won't get very far in your career.

You don't have to get thousands of dollars in training to get a wonderful TCP/IP education. There are numerous places where you can obtain free online TCP/IP information. Just key in "TCP/IP Overview" in any good search engine and you'll get thousands of hits. That, coupled with some Windows NT/2000 software, a connection to another computer and one to the Internet and you're off to the races. It's very easy to set up a TCP/IP lab because you don't need powerhouse computers to find out how the protocol works.

And, if you don't know how it works, the best thing you can do for your education is to make sure that you do—intimately so. For example, whenever new things are being considered for TCP/IP, or a change needs to be made to an existing component, a Request for Comment (RFC) is put online by the Internet Engineering Task Force (IETF, www.ietf.org; you can review and submit your own additions to RFCs by going to www.rfc-editor.org). I know people who passionately review the RFCs, know what's inside them and are in touch with the entire world of TCP/IP. Do you have to get that carried away? Probably not, but you should understand that as far as an understanding of TCP/IP goes, you don't need to spend a dime (other than your Internet connection) to get a boatload of information about it.

IPX
Older Novell Netware servers utilized a protocol called Internet Packet eXchange (IPX). Novell servers have been able to utilize TCP/IP for a long time now and Netware 6 now uses native TCP/IP instead of IPX.

If you're an administrator who has both Windows NT/2000 and Netware boxes to support, chances are you'll need to understand IPX. You can visit www.webopedia.com and key in IPX as your search string—notice that there's a good link to a Cisco Web site discussion of IPX—or you can visit www.novell.com for more information.

NetBEUI
Pronounced "net-booey," this is an older Windows-centric protocol that was very fast but not routable. Hence, as larger networks sprung up NetBEUI wound up being moved further back on the stage. Today, NetBEUI is something that isn't used very often in most corporate environments. Unfortunately, junior admins discover that if they can't get TCP/IP working correctly, they can install NetBEUI on the client and the server and the Windows systems can continue to talk to one another. NetBEUI becomes a crutch in cases like this.

I should point out that NetBEUI can be used as a Routing and Remote Access (RRAS) protocol that allows admins to set up a "poor man's" security context in which the user can connect to the network via NetBEUI but can't surf the Web because he's not an IP client. This is probably NetBEUI's strongest claim to fame today.

Remember: NetBEUI cannot cross routers.

AppleTalk
It's unlikely that in your administrative experience you will never cross a Macintosh computer that you have to support. Macintosh computers are the workhorse of most publishing, music- and video-production studios and marketing departments. They got a steady foothold in the business back when Windows didn't do graphics very well and they've just held on. (For good reason: Mac OS X is very sexy—all TCP/IP, by the way). So, it's highly likely that you'll support a Mac or two in your career.

With older Macs, you'll have to support the AppleTalk protocol. Both Windows NT and Win2K have built-in support for Macintosh computers—all you have to do is install and configure it. You will run into some difficulty understanding AppleTalk, Macs and a funny thing called "seeding a zone," but there is a lot of information out there for you.

Note: With Macs favorably priced these days, a savvy admin with a few bucks in his pocket—one who's building a little home test network—might consider a Mac laptop to knock around a little. You know, kick the tires, see what makes it run differently than the Windows boxes. (Ditto for RedHat Linux, which can run on basically nothing of a computer.)

Router Protocols
Any discussion of your company's infrastructure typically will not include the routers and WAN circuits. This is a different area of study, one that's much more complex and specialized. However, you may find that routers are introduced when two buildings within the same localized campus are connected to one another. You can even use Win2K as a router in a situation such as this (a huge facet of the 70-221, Designing a Windows 2000 Network Infrastructure exam involves utilizing Win2K Server or Advanced Server's strengths as a router).

Generally, folks who work on routers and WAN circuits (called internetworkers in the business) don't concern themselves with the infrastructure, though that's not a hard and fast rule. As a student of all things pertaining to networking, I recommend that you confine your studies to the infrastructure until you're completely sure of yourself in this area, then branch out to internetworking at a later time. It seems to me that the Windows networking arena has a logical tight linkage with the infrastructure, whereas internetworking duties are more specialized and tend to remain that way.

You'll run into router terminology when you're designing an Exchange 2000 deployment (E2K uses a methodology that's similar to routing, in which different E2K boxes throughout the enterprise can find one another through a number of circuits) and with Win2K routers. Win2K supports the following routing protocols:

• Routing Information Protocol (RIP)—(Supported as well in NT 3.51 and 4.0) RIP is a distance-vector protocol, meaning that it announces its distance and direction from its nearest neighbors on a routine basis. RIP is still supported in Win2K.
• Open Shortest Path First (OSPF)—A link-state protocol that allows routers to mesh together, providing a picture of the entire network. This protocol is as popular in hardware routers as Cisco's proprietary Interior Gateway Routing Protocol (IGRP).

Win2K also supports things such as demand-dial routing, a routing-like feature that's a component of RRAS.

In general, most shops already have robust hardware-based routing infrastructures in place that are handled by internetworking folks, either on a full-time or contractual basis, so you'll not likely get much of an opportunity to mess around with routers unless you become a CCNA and transfer to the internetworking team.

Sybex publishes a virtual e-trainer software program that can simulate the Cisco router interface and give you some hands-on training with router technology. If you've got deep pockets, you can get into Cisco 2600 routers for around $2,500-3,000 and have something at home to mess around with. Or hey, you might even be able to buy a cheap used Cisco unit through eBay.

Where Are the Big Bucks? Lots of administrators I run into think that the holy grail of networking, the Cisco Certified Internetworking Expert certification, is going to be their next stop. I believe the reason is due to the fact that CCIEs make so much money—it's not uncommon to hear about actual CCIEs who earn a good six-figure income. But administrators new to the business need to realize that people working full-time on routers, while they're paid well, are subject to 365-day-a-year call-out, live lonely lives in cold data centers working on routers and usually have no backup assistance. When a router fails, the entire company is hounding the router person to get it fixed right now! Router folks live a solitary, specialized existence. It's not as glamorous as junior administrators might think it is. Also, it's extremely difficult to achieve a CCIE title. There are very few in the world, it requires a tremendous amount of effort and study and typically your job has to involve routine work on Cisco routers in order for you to even have a fair shot at the certification. My advice? You're much better off concentrating on a Windows Networking component that's highly specialized—such as SQL Server, Systems Management Server or BizTalk—if you're interested in big bucks. Personally, the networking and infrastructure side of the house are much more interesting than internetworking, although you have a slight edge over your peers if you understand routing protocols.

Other Protocols
There are other incidental protocols that you'll run into from time to time. The three most common of these would be Remote Procedure Call (RPC), used by Pre-E2K Exchange boxes, X.400, a messaging protocol used by E2K and HTTP, which is the protocol of the Internet (besides TCP/IP). When considering well-used messaging protocols, you should be sure you understand SMTP, especially the easy-to-learn command set that you can use to test whether or not SMTP is working.

OSI Model
One of the things that is very difficult to digest, especially for novices to the systems administration world is the Open Systems International model, a standards model that defines seven layers in which protocols can operate in a networked environment. Easy to remember with one of several different mnemonics that have been invented (my favorite is All People Seem To Need Data Processing) the OSI model, from layer 7 (the top layer) down looks like table 1.

Number Layer Description 7 Application Supports applications and end-user processes. 6 Presentation Handles encryption of data, and representation of data the way the network understands it to the way the application requires it. 5 Session Handles the connection and sessions between applicationsx 4 Transport Error recovery, end-to-end connectivity, flow control 3 Network The routing layer 2 Data link The switching layer 1 Physical The actual media the data's running over, the electrical or radio specifications, etc.

Table 1. OSI Model

You can get more information on the OSI model by keying in OSI on www.webopedia.com or on OSI itself by visiting www.osi.ch on the Internet. Or, navigate to www.yahoo.com, www.google.com, www.excite.com (you get the idea) and key in OSI at the search prompt. You'll get more data than you can shake a stick at.

Here's the problem with the OSI model: It has been redefined in different ways to fit different ideas about networking. In the Institute of Electrical and Electronics Engineers (IEEE) world, the 802.2 standard breaks the Data Link layer into sublayers, called the Media Access Control (MAC) and Logical Link Control (LLC) layers. There are other derivations that you'll run into when you're concerning yourself with the OSI model.

When I was studying for my Microsoft TCP/IP test, I actually wrote down each layer on a piece of paper (along with the sublayers), and next to it I wrote down bullets showing what the layers are responsible for. I then memorized the whole thing. Today, I don't think I could regurgitate the list, but then I don't think I need to either; there are good online references to help refresh my memory.

So, what should you commit to memory with the OSI model? Basically a generalized idea that the OSI model is out there and that most manufacturers adhere closely to it. Also,. Remember that switches operate at layer 2 and routers at layer 3 and that there is such a thing as a layer 3 switch (routes and switches). Additionally, that the data moves from the application layer down the stack, across the wire, and up the layers on the other computer—which means that the process could break down in the midst of any of the layers—understanding the layers will help you understand where things broke down at.

Parting Advice
This has been a fun series of articles to write. I hope you find some good information out of the articles that you can use in your career. The things I've written about in the previous three articles have predominantly been "school of hard knocks" things I've learned over a long period of time. If I can help you get where you need to go faster, then I've met my goal.

Now for some advice points you can use in your everyday experiences with your network:

Get rid of the hubs in your network and convert to switches, especially if you're having routine network performance issues. The intelligent management aspect of switches is well worth the price of admission. Switches are not difficult to learn how to manage and most of them work basically the same way, though the interface may be a little different. (It's like learning how to drive a stick shift. Once you do, you can count on knowing how to drive most automobiles with a manual transmission.)

Stay with one brand of switch. Don't intermingle vendors. You'll just get confused and there may be proprietary operational characteristics that introduce unneeded complexities to the network.

In a network that uses an older version of Novell Netware in addition to Microsoft Windows networking (NT 4.0, Windows 2000, etc.), get rid of the IPX protocol altogether. Forcing everything to run on the TCP/IP protocol and getting rid of IPX will greatly improve the performance of your network. Getting rid of IPX is a tremendous undertaking, however, because your workstations are likely relying on it, and it is doubtless buried in applications or devices you may not at first consider (such as printers.) Note that once IPX is out of your network, you can also have your router person remove IPX routing-a move that will tremendously speed up your routers.

Force all server NICs and their associated switch ports to a given data transfer rate. Both server NICs and the port that the server connects to on the switch can usually be adjusted for a given data transfer rate. Unfortunately, in today's automated technology, both the NIC and the switch port have as one of their settings "autodetect," meaning that the NIC will detect what data transfer rate it should be using as will the switch port. I say this is unfortunate because often the two will detect erroneously—the server's NIC will think it should be at 10Base-T half-duplex, whereas the switch port thinks it should communicate at 10Base-T full-duplex. (half-duplex essentially means a one-way conversation—you talk, then I talk—whereas full-duplex implies a two-way conversation can take place. Windows NT 4.0 Service Pack 3 and above can communicate at full-duplex.) I've seen more performance issues arise due to this autodetect characteristic with switch ports and NICs than any other element on the network. Set all server NICs for a standard data transfer rate (100Base-T, full-duplex, for example) and force the switch ports to match. You'll be happy you went through the effort. Check other network operating systems (NOS) to see what data transfer rates they can operate at.

Bottom Line
So, what's the final skinny? Infrastructure is fun! There's a lot to know and it'll take you a little while to learn it, but once you've learned how to manage your infrastructure as well as your server farm, you are the master of your domain. You will understand how the data leaves the servers, gets onto the pipe and where it goes from there. You'll be able to pinpoint sluggishness much more easily than before and, best of all, you can design a killer network that operates well.

Next month we'll talk about something virtually all admins hate to do—document their network. Ugh!