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
So far, we've talked about the tangibles of your network—the cabling
, 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
- Messaging protocols such as X.400
- Customized protocols such as Microsoft Challenge Handshake
Protocol (MS-CHAP, a variation of the CHAP protocol)
for a fairly comprehensive dictionary of protocols.
As a general rule of thumb, a protocol's job is to do the
- 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).
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.
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
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.
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.
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.)
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
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.
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.
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.
||Supports applications and
||Handles encryption of data,
and representation of data the way the network understands it
to the way the application requires it.
||Handles the connection
and sessions between applicationsx
end-to-end connectivity, flow control
||The routing layer
||The switching layer
||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.
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.
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!