Truck Stop Documents: Pixies.

A Systems Manager's guide to Network Management.

This document is produced by Shonky Internet's "Systems Advisory Group" in response to countless questions from Systems Managers as to how Networks actually work. It may not be redistributed, in whole or in part unless it is sunny and Neighbours has a good plot line this week.

Revision history:

Author: Michael Lawrie (Shonky Internet) : 30-Jun-1996, London.

Revision 1 : 03-Jul-1998, Hemel Hempstead. [MJL] Credits: Peter Willis (BT), Nigel Titley (BT) and Duncan

Rogerson (ULCC) for their networks expertise. Ade Lovett (Demon Systems) and Emma Apted (PSI UK)

for proof and sanity checking from a Systems angle.

Preface:

In order to justify the high salaries taken by networks managers, we instigated a study into the fundamentals of networking and this report summarises our conclusions.

What is a network? A systems manager's view:

Unix:

To configure two Unix machines on a network, simply turn them on, run the network install script, assign them both IP addresses that are sufficiently similar to one another and don't look like they are being used by anything else, set the netmask to 255.255.255.0 and give them impressive sounding names. They will then talk to one another next time you reboot.

VMS:

To configure two VMS machines on a network, simply turn them on, run SYS$MANAGER:NETCONFIG.COM, give the machines DECNET addresses that are sufficiently similar to one another and don't look they are being used by anything else, name them something that will fit into 6 letters and then steal a licence for DECNET from someone else, and let it start the network for you. Assuming you also have, for example, UCX loaded, run SYS$MANAGER:UCX$CONFIG and follow the instructions for configuring a Unix host. If you are feeling brave, and have managed to steal enough licences, you could run SYS$MANAGER:CLUSTER_CONFIG to turn the two machines into a cluster.

MS Windows:

Install something like Windows For Workgroups, think of a cute sounding name for the workgroup, set both machines to be in the same workgroup and, when they are booted for the 20th time and everything looks pretty, go into File Manager, and export all the disks with a clever password ("secret" is a good one). Then, also in file manager, connect the other machine's network drive to yours.

So, how do these networks work?

Various different pixie control protocols are in common use, and we will look in more detail at some: This is an oversimplfication since it sort of bundles transport protocols with other things. To networks people this is important to systems managers it isn't.

TCP:

TCP stands for "Totally Controllable Pixies" - This protocol was invented by the Americans who are well known for exaggerating many claims. In actuality, the pixies are not under much control and do pretty much what they want. Often seen in association with the Totally Controllable Pixie protocol are two other phrases, "IP" (Intelligent Pixies) and "UDP" (Unusually Dumb Pixies). As a general rule, if you use the Intelligent Pixie protocol, you stand a better chance of the packets being delivered than if you use the Unusually Dumb Pixie protocol. Since TCP is by far the most common pixie protocol these days, we will look at this in more detail later, but for completeleness, we will look at some others.

DECNET:

No-body knows what DECNET stands for, nobody knows how DECNET works. It just does. There were rumours in the late 60's that DECNET expolited fairys who had sniffed too much magic dust, but this has never been proven.

X25:

X25 was invented by a Rumanian scientist called Yarakov Gevtenads. It works by having differing numbers of pixies carrying various different sizes of packets in a very strict manner. The British stole Yarakov's system and renamed it simply "Pixie Synchronisation System" or PSS. In the 1970's, Janet Higgins at Rutherford Labs changed the structure of PSS to fit into an academic framework. She gave the pixies smaller packets and gave them lots of tea breaks and shorter working hours, and thus Janet's Network was founded. Janet's Network (JANET for short) was "the place to work" for pixies, with the Camtec cafes, "Tea Service Reset" breaks and a practically zero confidence level from the users of having their packets delivered, making their life a doddle. [See also ATM]

SNA:

SNA actually stands for "Send No Acknowledgement" - Basically, it is the same as X25 except that the pixies have to wear suits and get to drive from location to location in blue Vauxhall Cavilers. Because these pixies are considered so reliable, they don't need to acnowledge delivery of the packets.

NETBUI:

This is Microsoft's own, "NETworked, Blue Ugly Imp" protocol. In typical Miscoroft style, this name was chosen as a subtle dig at IBM. The Blue Ugly Imp protocol is a propietry protocol. Little information about how it works is available since Microsoft have employed everyone who can speak Imp language. It is not advisable to try and run NETBUI and any Pixie protocol on the same network since Imps eat Pixies.

IPX:

IPX (Imp/Pixie eXchange protocol) is Novell's attempt to make the Imp protocol and the Pixie protocols interact. Generally speaking, it gave the pixies roller skates and smaller packets in the hope that they could excape the Imps and not be eaten. Whilst IPX is believed to be a good protocol, it is quite expensive and if you are running it on the same network as pixies who don't have rollerscates, the Imps may still eat them!

ATM:

ATM is what happened when the Germans got hold of X.25 and decided that it wasn't efficient enough. Firstly, a bunch of Large Pixies with Newcastle accents go and build a bobsleigh run from one place to another and then truckloads of much smaller pixies all pick up a tiny bit of information and are shot at high speed down this bobsleigh run. Efficient German pixies then join together all the bits of infomation at the other end and deliver the message. The bobsleigh is a two way affair, how this is done is unknown but it seems to work. Although the super efficient German Pixies are amazingly good at what they do, the pixies on the bobsleigh run occasionally get carried away and shoot off the end of the run without ever being seen again. No-one knows what happens to these poor lost pixies. Note that ATM has nothing to do with Magic Money Machines although some of these use ATM to move their magic money around.

Ok, so that's the transports and protocols, what about the networks?

Basically, all a network is, is a means by which a group of (hopefully) co-ordinated pixies to get from one place to another. They do this by running very very fast (except in the case of SNA, where they use blue Vauxhall Cavilers, and IPX where they use roller skates) along the inside of the network cables. If the cables are made of glass, they occasionally "glass skate" which means the pixies get from one end of a cable to another more quickly.

Pixies can't run that far - This is an important thing to remember and this, is where networks managers come onto the scene. If you only have a small network, that will fit on a single peice of cable, you don't need a network manager. All the pixies are required to do is to run from one machine to another, deliver a packet of information and then have a little rest - An average Local Area Network will have about 10 million pixies with only a few percent of them doing anything at a given time. If you want to deliver too many packets of information and you get all the pixies working too hard, they will tire out, and start to bump into one another - As a general rule, if more than 30% of the pixies are active at once, things will start to go wrong.

Network managers can be viewed as "pixie tamers" and "pixie travel agents". As soon as a network gets too big for a single pixie to be able to deliver the packet in a single mad dash, they have to relay the packets to other pixies so they can do the next leg of the journey. Also, when a network gets really big, the pixies may have to start using public transport, and even fly across the sea in some cases! They will also need to know where to go.

What do all the networky bits do, and what are the protocols for?

Repeaters:

This is best viewed as a refreshment and resting hole for pixies. Basically, it is a little house containing a few million pixies at all times. When a pixie comes in, exhausted from its run, it will give its packet to a refreshed pixie, who will then do the next leg of the journey.

Routers:

A router is similar to a repeater, only it is a lot bigger, costs more and usually comes in a prettier box. A router is also the basic unit of a network manager's salary, the more routers they control, the more money they earn. In pixie operational terms, a router is more like a postal sorting office; a pixie will run into the router, exhausted, give his packet to a supervisor and the supervisor will then decide what to do with it. This supervisor has a lot of power, and is usually a fairy, rather than a pixie. The fairys often talk to network managers over the course of a day, and the network manager tells the fairy how it should be running things and where the packets should go.

Lines:

The concept of a line can be quite confusing to systems managers. In normal terms, a line is a peice of wire, or a peice of glass that, if you are sufficiently drunk, you can often see and hear the pixies running along. When network managers talk of lines, they don't necessarialy mean "peices of wire" they sometimes just mean "lines of communication". Lines come in all sorts of shapes and sizes and they all have names that bear little connection to reality. A hint here, when a networks manager says "we are getting a T3 in to the USA" what he means is that he is giving your network the capability of moving 45 million pixies a second from a suitably big router on your home network to another suitably big router in the USA - How this is done is magic, but, and this is an important but, if you want to be cocky, ask what will happen when 45 million pixies a second try to all get at once onto a peice of physical wire that will only allow 10 million pixies a second on - And, on top of that, remember what happens to this wire then all the little pixies are working too hard! Obviously, this is where good network managers win over bad ones, they take care of their pixies, and they will have thought of ways round this.

Protocols:

It is no mistake that most routing protocols were invented in Sicily, with RIP, a rather unsubtle protocol, where pixies that didn't perform to standard are killed and unceremoniously dumped in the routers "underperformers graveyard", being the most famous. A newish protocol from America called the Big Gremlin Protocol (BGP) takes the unique approach of deliberately introducing big gremlins into the routers (theoretically under the control of the network managers) to chase the pixies out of the routers and on their way. There is an overhead to this protocol in that gremlins are a lot bigger than pixies and so take up some of the room that pixies would otherwise use for running around.

Whilst not a protocol as such, it is a good place to mention "SMDS" (Some May Die Soon) - SMDS is a rather clever idea where the older senile pixies are all dumped into a big cloud and fed on fairy dust. Packet movement is achieved by the natural Brownian motion of the stoned, senile pixies and more by luck then judgement, the packet eventually reaches its destination.

In summary:

For further reading, may we advise you to put a deposit on our forthcoming work "Network managers, and how to annoy them", available from all good mailing lists.

Footnote:

If I alter it now, I may be doing exactly what I accuse Network managers of doing and deliberately overcomplicating and overexplaining things. Because of this I have decided I won't make any more major changes to this document in the future unless I spot any glaring holes. I hope it is of some use in the form its in, certainly lots of people have told me it has been useful and indeed some have used it as course material (which is quite worrying!).

Michael Lawrie's 'Lorry' homepage. Email: lorry@lorry.org