Download Introduction To Networking - Alfagate Infocom Technology.... Main

Introduction To Networking
Introduction
A network is simply a group of two or more Personal Computers linked together. Many types of
networks exist, but the most common types of networks are Local-Area Networks (LANs), and
Wide-Area Networks (WANs).
In a LAN, computers are connected together within a "local" area (for example, an office or
home). In a WAN, computers are further apart and are connected via telephone/communication
lines, radio waves or other means of connection.
How are Networks Categorized?
Networks are usually classified using three properties: Topology, Protocol and Architecture.
Topology specifies the geometric arrangement of the network. Common topologies are a bus, ring
and star.You can check out a figure showing the three common types of network topologies here.
Protocol specifies a common set of rules and signals the computers on the network use to
communicate. Most networks use Ethernet, but some networks may use IBM's Token Ring
protocol. We recommend Ethernet for both home and office networking. For more information,
please select the Ethernet link on the left.
Architecture refers to one of the two major types of network architecture: Peer-to-peer or
client/server. In a Peer-to-Peer networking configuration, there is no server, and computers
simply connect with each other in a workgroup to share files, printers and Internet access.
This is most commonly found in home configurations and is only practical for workgroups of a
dozen or less computers. In a client/server network there is usually an NT Domain Controller, to
which all of the computers log on. This server can provide various services, including centrally
routed Internet Access, mail (including e-mail), file sharing and printer access, as well as
ensuring security across the network. This is most commonly found in corporate configurations,
where network security is essential.
Network Topologies
Introduction
Network topologies can take a bit of time to understand when you're all new to this kind of cool
stuff, but it's very important to fully understand them as they are key elements to understanding
and troubleshooting networks and will help you decide what actions to take when you're faced
with network problems.
I will try to be as simple as possible and give some examples you can relate to, so let's get stuck
right into this stuff !
The Stuff :)
There are two types of topologies: Physical and Logical. The physical topology of a network
refers to the layout of cables, computers and other peripherals. Try to imagine yourself in a room
with a small network, you can see network cables coming out of every computer that is part of the
network, then those cables plug into a hub or switch. What you're looking at is the physical
topology of that network !
Logical topology is the method used to pass the information between the computers. In other
words, looking at that same room, if you were to try to see how the network works with all the
computers talking (think of the computers generating traffic and packets of data going
everywhere on the network) you would be looking at the logical part of the network. The way the
computers will be talking to each other and the direction of the traffic is controlled by the various
protocols (like Ethernet) or, if you like, rules.
If we used token ring, then the physical topology would have to change to meet the requirements
of the way the token ring protocol works (logically).
If it's all still confusing, consider this: The physical topology describes the layout of the network,
just like a map shows the layout of various roads, and the logical topology describes how the data
is sent accross the network or how the cars are able to travel (the direction and speed) at every
road on the map.
The most common types of physical topologies, which we are going to analyse, are: Bus,
Hub/Star and Ring
The Physical Bus Topology
Bus topology is fairly old news and you probably won't be seeing much of these around in any
modern office or home.
With the Bus topology, all workstations are connect directly to the main backbone that carries the
data. Traffic generated by any computer will travel across the backbone and be received by all
workstations. This works well in a small network of 2-5 computers, but as the number of
computers increases so will the network traffic and this can greatly decrease the performance and
available bandwidth of your network.
As you can see in the above example, all computers are attached to a continuous cable which
connects them in a straight line. The arrows clearly indicate that the packet generated by Node 1
is transmitted to all computers on the network, regardless the destination of this packet.
Also, because of the way the electrical signals are transmitted over this cable, its ends must be
terminated by special terminators that work as "shock absorbers", absorbing the signal so it won't
reflect back to where it came from. The value of 50Ohms has been selected after carefully taking
in consideration all the electrical characteristics of the cable used, the voltage that the signal
which runs through the cables, the maximum and minimum length of the bus and a few more.
If the bus (the long yellow cable) is damaged anywhere in its path, then it will most certainly
cause the network to stop working or, at the very least, cause big communication problems
between the workstations.
Thinnet - 10 Base2, also known as coax cable (Black in colour) and Thicknet - 10 Base 5 (Yellow
in colour) is used in these type of topologies.
The Physical HUB or STAR Topology
The Star or Hub topology is one of the most common network topologies found in most offices
and home networks. It has become very popular in contrast to the bus type (which we just spoke
about), because of the cost and the ease of troubleshooting.
The advantage of the star topology is that if one computer on the star topology fails, then only the
failed computer is unable to send or receive data. The remainder of the network functions
normally.
The disadvantage of using this topology is that because each computer is connected to a central
hub or switch, if this device fails, the entire network fails!
A classic example of this type of topology is the UTP (10 base T), which normaly has a blue
colour. Personally I find it boring, so I decided to go out and get myself green, red and yellow
colours :)
The Physical Ring Topology
In the ring topology, computers are connected on a single circle of cable. Unlike the bus
topology, there are no terminated ends. The signals travel around the loop in one direction and
pass through each computer, which acts as a repeater to boost the signal and send it to the next
computer. On a larger scale, multiple LANs can be connected to each other in a ring topology by
using Thicknet coaxial or fiber-optic cable.
The method by which the data is transmitted around the ring is called token passing. IBM's token
ring uses this method. A token is a special series of bits that contains control information.
Possession of the token allows a network device to transmit data to the network. Each network
has only one token.
The Physical Mesh Topology
In a mesh topology, each computer is connected to every other computer by a separate cable. This
configuration provides redundant paths through the new work, so if one computer blows up, you
don't lose the network :) On a large scale, you can connect multiple LANs using mesh topology
with leased telephone lines, Thicknet coaxial cable or fiber optic cable.
Again, the big advantage of this topology is its backup capabilities by providing multiple paths
through the network.
The Physical Hybrid Topology
With the hybrid topology, two or more topologies are combined to form a complete network. For
example, a hybrid topology could be the combination of a star and bus topology. These are also
the most common in use.
Star-Bus
In a star-bus topology, several star topology networks are linked to a bus connection. In this
topology, if a computer fails, it will not affect the rest of the network. However, if the central
component, or hub, that attaches all computers in a star, fails, then you have big problems since
no computer will be able to communicate.
Star-Ring
In the Star-Ring topology, the computers are connected to a central component as in a star
network. These components, however, are wired to form a ring network.
Like the star-bus topology, if a single computer fails, it will not affect the rest of the network. By
using token passing, each computer in a star-ring topology has an equal chance of
communicating. This allows for greater network traffic between segments than in a star-bus
topology.
Introduction To Data Transmission
Introduction
Routable protocols enable the transmission of data between computers in different segments of a
network. However, high volumes of certain kinds of network traffic can affect network efficiency
because they slow down transmission speed. The amount of network traffic generated varies with
the 3 types of data transmissions:

Broadcast

Multicast

Unicast
We are going to have a look at each one of these data transmissions because it's very important to
know the type of traffic they generate, what they are used for and why they exist on the network.
Before we proceed, please note that understanding the OSI Model (especially Layer 2 and 3),
Ethernet and the way a packet is structured is fundamental to understanding a broadcast, multicast
or unicast.
Media Access Control - MAC Addresses
Introduction
Media Access Control (MAC) addresses are talked about in various sections on the site, such as
the OSI-Layer 2, Multicast, Broadcast and Unicast. We are going to analyse them in depth here
so we can get a firm understanding of them since they are part of the fundamentals of networking.
MAC addresses are physical addresses, unlike IP addresses which are logical addresses. Logical
addresses require you to load special drivers and protocols in order to be able to configure your
network card/computer with an IP Address, whereas a MAC address doesn't require any drivers
whatsoever. The reason for this is that the MAC address is actually "burnt-in" into your network
card's memory chipset.
The Reason for MAC
Each computer on a network needs to be identified in some way. If you're thinking of IP
addresses, then you're correct to some extent, because an IP address does identify one unique
machine on a network, but that is not enough. Got you mixed up?
Check the diagram and explanation below to see why :
You see, the IP address of a machine exists on the 3rd Layer of the OSI model and, when a packet
reaches the computer, it will travel from Layer 1 upwards, so we need to be able to identify the
computer before Layer 3.
This is where the MAC address - Layer 2 comes into the picture. All machines on a network will
listen for packets that have their MAC address in the destination field of the packet (they also
listen for broadcasts and other stuff, but that's analysed in other sections). The Physical Layer
understands the electrical signals on the network and creates the frame which gets passed to the
Datalink layer. If the packet is destined for the computer then the MAC address in the destination
field of the packet will match, so it will accept it and pass it onto the Layer above (3) which, in
turn, will check the network address of the packet (IP Address), to make sure it matches with the
network address to which the computer has been configured.
Looking at a MAC
Let's now have a look at a MAC address and see what it looks like! I have taken my workstations
MAC address as an example:
When looking at a MAC address, you will always see it in HEX format. It is very rare that a
MAC address is represented in Binary format because it is simply tooooo long as we will see
futher on.
When a vendor, e.g Intel, creates network cards, they don't just give them any MAC address they
like, this would create a big confusion in identifying who created this network card and could
possibly result in clashing with another MAC address from another vendor e.g D-link, who
happened to choose the same MAC address for one of their network cards !
To make sure problems like this are not experienced, the IEEE group split the MAC address in
half, and used the first half to identify the vendor, and the second half is for the vendor to allocate
as serial numbers:
The Vendor code is specified by RFC - 1700. You might find a particular vendor having more
than just one code; this is because of the wide range of products they might have. They just apply
for more, as they need !
Keep in mind that even tho the MAC address is "burnt-in" to the network card's memory, some
vendors will allow you to download special programs to change the second half of the MAC
address on the card. This is because the vendors actually reuse the same MAC addresses for their
network cards because they create so many that they run out of numbers ! But at the same time,
the chances of you buying two network cards which have the same MAC address are so small
that it's almost impossible !
Let's start talking bits and bytes!
Now that we know what a MAC address looks like, we need to start analysing it. A MAC address
of any network card is always the same length, that is, 6 Bytes long or 48 Bits long. If you're
scratching your head wondering where these figures came from, then just have a look at the
picture below which makes it a bit easier to understand:
So that completes the discussion regarding MAC Addresses! I hope you have understood it all
because it's very important so you can expand your knowledge and truly understand what
happens in a network !
Unicast
Introduction
Compaired to broadcasts and Multicasts, a Unicast is very simple and one of the most common
data transmissions in a network.
The Reason for Unicast
Well it's pretty obvious why they came up with Unicasts, imagine trying to send data between 2
computers on a network, using broadcasts ! All you would get would be a very slow transfer and
possibly a conjested network with low bandwidth availability.
Data transfers are almost all of the times, unicasts. You have the sender e.g a webserver and the
receiver e.g a workstation. Data is transfered between these two hosts only, where as a broadcast
or a multicast is destined either everyone or just a group of computers.
In example above, my workstation sends a request to the Windows 2000 Server. The request is a
simple Unicast because it's directed to one machine (the server) and nothing else. You just need
to keep in mind that because we are talking about a Ethernet network, the traffic, hence the
packets, are seen by all machines (in this case the Linux Server aswell) but they will not process
them once they see that the destination MAC address in the packets do not match their own and
are also not set to FF:FF:FF:FF:FF:FF which would indicate that the packet is a broadcast.
There really isn't much more to say for Unicasts... so I guess i'll stop right here :)
Introduction To Multicast
Introduction
To understand what we are going to talk about, you must be familiar with how MAC addresses
are structured and how they work. The MAC Addresses page is available to help you learn more
about them..
A multicast is similar to a broadcast in the sense that its target is a number of machines on a
network, but not all. Where a broadcast is directed to all hosts on the network, a multicast is
directed to a group of hosts. The hosts can choose whether they wish to participate in the
multicast group (often done with the Internet Group Management Protocol), whereas in a
broadcast, all hosts are part of the broadcast group whether they like it or not :).
As you are aware, each host on an Ethernet network has a unique MAC address, so here's the
million dollar question: How do you talk to a group of hosts (our multicast group), where each
host has a different MAC address, and at the same time ensure that the other hosts, which are not
part of the multicast group, don't process the information ? You will soon know exactly how all
this works.
To keep things in perspective and make it easy to understand, we are going to concentrate only on
an Ethernet network using the IP protocol, which is what 80-90 % of home networks and offices
use.
Breaking things down...
In order to explain Multicasting the best I can and to make it easier for you understand, I decided
to break it down into 3 sections:
1) Hardware/Ethernet Multicasting
2) IP Multicasting
3) Mapping IP Multicast to Ethernet Multicast
A typical multicast on an Ethernet network, using the TCP/IP protocol, consists of two parts:
Hardware/Ethernet multicast and IP Multicast. Later on I will talk about Mapping IP Multicast to
Ethernet Multicast which is really what happens with multicasting on our Ethernet network using
the TCP/IP protocol.
The brief diagram below shows you the relationship between the 3 and how they complete the
multicasting model:
Hardware/Ethernet Multicasting
When a computer joins a multicast group, it needs to be able to distinguish between normal
unicasts (which are packets directed to one computer or one MAC address) and multicasts. With
hardware multicasting, the network card is configured, via its drivers, to watch out for particular
MAC addresses (in this case, multicast MAC addresses) apart from its own. When the network
card picks up a packet which has a destination MAC that matches any of the multicast MAC
addresses, it will pass it to the upper layers for further processing.
And this is how they do it :
Ethernet uses the low-order bit of the high-order octet to distinguish conventional unicast
addresses from multicast addresses. A unicast would have this bit set to ZERO (0), whereas a
multicast would be set to ONE (1)
To understand this, we need to analyse the destination MAC address of a unicast and multicast
packet, so you can see what we are talking about:
When a normal (unicast) packet is put on the network by a computer, it contains the Source and
Destination MAC address, found in the 2nd Layer of the OSI model. The following picture is an
example of my workstation (192.168.0.6) sending a packet to my network's gateway
(192.168.0.5):
Now let's analyse the destination MAC address:
When my gateway receives the packet, it knows it's a unicast packet as explained in the above
picture.
Let's now have a look at the MAC address of a multicast packet. Keep in mind, a multicast packet
is not directed to one host but a number of hosts, so the destination MAC address will not match
the unique MAC address of any computer, but the computers which are part of the multicast
group will recognise the destination MAC address and accept it for processing.
The following multicast packet was sent from my NetWare server. Notice the destination MAC
address (it's a multicast):
Analysis of a multicast destination MAC address:
So now you should be able to understand how computers can differentiate between a normal or
unicast packet and a multicast packet. Again, the destination MAC address 01-00-5E-00-00-05 is
not the MAC address of a particular host-computer but the MAC address that can be recognised
by computers that are part of the multicast group. I should also note that you will never find a
source address that is a multicast MAC address, the source address will always be a real one, to
identify which computer the packet came from.
The IEEE group used a special Rule to determine the various MAC addresses that will be
considered for multicasting. This Rule is covered in the last section of this page, but you don't
need to know it now in order to understand Hardware multicasting. Using this special rule it was
determined that MAC address 01:00:5E:00:00:05 will be used for the OSPF protocol, which
happens to be a routing protocol, and then this MAC address also maps to an IP address which is
analysed in IP Multicast.
IP Multicast
The IP Multicast is the second part of multicasting which, combined with the hardware
multicasting, gives us a multicasting model that works for our Ethernet network. If hardware
multicasting fails to work, then the packet will never arrive at the network layer upon which IP
multicasting is based, so the whole model fails.
With IP multicasting the hardware multicasting MAC address is mapped to an IP Address. Once
Layer 2 (Datalink) picks the multicast packet from the network (because it recognises it, as the
destination MAC address is a multicast) it will strip the MAC addresses off and send the rest to
the above layer, which is the Network Layer. At that point, the Network Layer needs to be able to
understand it's dealing with a multicast, so the IP address is set in a way that allows the computer
to see it as a multicast datagram. A host may send multicast datagrams to a multicast group
without being a member.
Multicasts are used a lot between routers so they can discover each other on an IP network. For
example, an Open Shortest Path First (OSPF) router sends a "hello" packet to other OSPF routers
on the network. The OSPF router must send this "hello" packet to an assigned multicast address,
which is 224.0.0.5, and the other routers will respond.
IP Multicast uses Class D IP Adresses:
Let's have a look at an example so we can understand that a bit better:
The picture below is a screenshot from my packet sniffer, it shows a multicast packet which was
sent from my NetWare server, notice the destination IP address:
The screenshot above shows the packet which was captured, it's simply displaying a quick
summary of what was caught. But, when we look on the left we see the above packet in much
more detail.
You can clearly see the markings I have put at the bottom which show you that the destination IP
for this packet is IP Address 224.0.0.5. This corresponds to a multicast IP and therefore is a
multicast packet.
The MAC header also shows a destination MAC address of 01-00-5E-00-00-05 which we
analysed in the previous section to show you how this is identified as a multicast packet at Layer
2 (Datalink Layer).
Some examples of IP multicast addresses:
224.0.0.0 Base Address (Reserved) [RFC1112,JBP]
224.0.0.1 All Systems on this Subnet [RFC1112,JBP]
224.0.0.2 All Routers on this Subnet [JBP]
224.0.0.3 Unassigned [JBP]
224.0.0.4 DVMRP Routers [RFC1075,JBP]
224.0.0.5 OSPFIGP OSPFIGP All Routers [RFC2328,JXM1]
Remember that these IP Addresses have been assigned by the IEEE !
Now all that's left is to explain how the IP multicast and MAC multicast map between each
other...
Mapping IP Multicast to Ethernet Multicast
The last part of multicast which combines the Hardware Multicasting and IP Multicasting is the
Mapping between them. There is a rule for the mapping, and this is it:
To map an IP Multicast address to the corresponding Hardward/Ethernet multicast address,
place the low-order 23 bits of the IP multicast address into the low-order 23 bits of the special
Ethernet multicast address. The rest of the high-order bits are defined by the IEEE (yellow colour
in the example)
The above rule basically determines the Hardware MAC address. Let's have a look at a real
example to understand this.
We are going to use Multicast IP Address 224.0.0.5 - a multicast for the OSPF routing protocol.
The picture below shows us the analysis of the IP address in binary so we can clearly see all the
bits:
It might seem a bit confusing at first, but let's break it down:
We have an IP Address of 224.0.0.5, this is then converted into binary so we can clearly see the
mapping of the 23 bits to the MAC address of the computer. The MAC Address part which is in
yellow has been defined by the IEEE group. So the yellow and pink line make the one MAC
Address as shown in binary mode, then we convert it from binary to hex and that's about it !
NOTE
You should keep in mind that multicast routers should not forward any multicast datagram with
destination addresses in the following 224.0.0.0 and 224.0.0.255. The next page (multicasting
list) gives a bit more information on this.
This just about does it for multicasting !
Multicast IP List
Introduction
This page contains all the Multicast IP Addresses and shows what protocol they are mapped to.
Should you ever use a packet sniffer to try and see what's on the network and you capture a
packet with a destination IP Address of 224.X.X.X, then simply look up this list and you will
know what the purpose of that packet was :)
Internet Multicast Addressess
Host Extensions for IP Multicasting [RFC1112] specifies the extensions required of a host
implementation of the Internet Protocol (IP) to support multicasting. Current addresses are listed
below.
The range of addresses between 224.0.0.0 and 224.0.0.255, inclusive, is reserved for the use of
routing protocols and other low-level topology discovery or maintenance protocols, such as
gateway discovery and group membership reporting. Multicast routers should not forward
any multicast datagram with destination addresses in this range, regardless of its TTL.
224.0.0.0 Base Address (Reserved) [RFC1112,JBP]
224.0.0.1 All Systems on this Subnet [RFC1112,JBP]
224.0.0.2 All Routers on this Subnet [JBP]
224.0.0.3 Unassigned [JBP]
224.0.0.4 DVMRP Routers [RFC1075,JBP]
224.0.0.5 OSPFIGP OSPFIGP All Routers [RFC1583,JXM1]
224.0.0.6 OSPFIGP OSPFIGP Designated Routers [RFC1583,JXM1]
224.0.0.7 ST Routers [RFC1190,KS14]
224.0.0.8 ST Hosts [RFC1190,KS14]
224.0.0.9 RIP2 Routers [RFC1723,GSM11]
224.0.0.10 IGRP Routers [Dino Farinacci]
224.0.0.11 Mobile-Agents [Bill Simpson]
224.0.0.12 DHCP Server / Relay Agent [RFC1884]
224.0.0.12 - 224.0.0.255 Unassigned [JBP]
224.0.1.0 VMTP Managers Group [RFC1045,DRC3]
224.0.1.1 NTP Network Time Protocol [RFC1119,DLM1]
224.0.1.2 SGI-Dogfight [AXC]
224.0.1.3 Rwhod [SXD]
224.0.1.4 VNP [DRC3]
224.0.1.5 Artificial Horizons - Aviator [BXF]
224.0.1.6 NSS - Name Service Server [BXS2]
224.0.1.7 AUDIONEWS - Audio News Multicast [MXF2]
224.0.1.8 SUN NIS+ Information Service [CXM3]
224.0.1.9 MTP Multicast Transport Protocol [SXA]
224.0.1.10 IETF-1-LOW-AUDIO [SC3]
224.0.1.11 IETF-1-AUDIO [SC3]
224.0.1.12 IETF-1-VIDEO [SC3]
224.0.1.13 IETF-2-LOW-AUDIO [SC3]
224.0.1.14 IETF-2-AUDIO [SC3]
224.0.1.15 IETF-2-VIDEO [SC3]
224.0.1.16 MUSIC-SERVICE [Guido van Rossum]
224.0.1.17 SEANET-TELEMETRY [Andrew Maffei]
224.0.1.18 SEANET-IMAGE [Andrew Maffei]
224.0.1.19 MLOADD [Braden]
224.0.1.20 any private experiment [JBP]
224.0.1.21 DVMRP on MOSPF [John Moy]
224.0.1.22 SVRLOC [Veizades]
224.0.1.23 XINGTV <[email protected]>
224.0.1.24 microsoft-ds <[email protected]>
224.0.1.25 nbc-pro <[email protected]>
224.0.1.26 nbc-pfn <[email protected]>
224.0.1.27 lmsc-calren-1 [Uang]
224.0.1.28 lmsc-calren-2 [Uang]
224.0.1.29 lmsc-calren-3 [Uang]
224.0.1.30 lmsc-calren-4 [Uang]
224.0.1.31 ampr-info [Janssen]
224.0.1.32 mtrace [Casner]
224.0.1.33 RSVP-encap-1 [Braden]
224.0.1.34 RSVP-encap-2 [Braden]
224.0.1.35 SVRLOC-DA [Veizades]
224.0.1.36 rln-server [Kean]
224.0.1.37 proshare-mc [Lewis]
224.0.1.38 - 224.0.1.255 Unassigned [JBP]
224.0.2.1 "rwho" Group (BSD) (unofficial) [JBP]
224.0.2.2 SUN RPC PMAPPROC_CALLIT [BXE1]
224.0.3.000-224.0.3.255 RFE Generic Service [DXS3]
224.0.4.000-224.0.4.255 RFE Individual Conferences [DXS3]
224.0.5.000-224.0.5.127 CDPD Groups [Bob Brenner]
224.0.5.128-224.0.5.255 Unassigned [IANA]
224.0.6.000-224.0.6.127 Cornell ISIS Project [Tim Clark]
224.0.6.128-224.0.6.255 Unassigned [IANA]
224.0.7.000-224.0.7.255 Where-Are-You [Simpson]
224.0.8.000-224.0.8.255 INTV [Tynan]
224.0.9.000-224.0.9.255 Internet Railroad [Malamud]
224.1.0.0-224.1.255.255 ST Multicast Groups [RFC1190,KS14]
224.2.0.0-224.2.255.255 Multimedia Conference Calls [SC3]
224.252.0.0-224.255.255.255 DIS transient groups [Joel Snyder]
232.0.0.0-232.255.255.255 VMTP transient groups [RFC1045,DRC3]
These addresses are listed in the Domain Name Service under MCAST.NET
and 224.IN-ADDR.ARPA.
Note that when used on an Ethernet or IEEE 802 network, the 23
low-order bits of the IP Multicast address are placed in the low-order
23 bits of the Ethernet or IEEE 802 net multicast address
1.0.94.0.0.0. See the section on "IANA ETHERNET ADDRESS BLOCK".
REFERENCES
[RFC1045] Cheriton, D., "VMTP: Versatile Message Transaction
Protocol Specification", RFC 1045, Stanford University,
February 1988.
[RFC1075] Waitzman, D., C. Partridge, and S. Deering "Distance Vector
Multicast Routing Protocol", RFC-1075, BBN STC, Stanford
University, November 1988.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting",
STD 5, RFC 1112, Stanford University, August 1989.
[RFC1119] Mills, D., "Network Time Protocol (Version 1), Specification
and Implementation", STD 12, RFC 1119, University of
Delaware, July 1988.
[RFC1190] Topolcic, C., Editor, "Experimental Internet Stream
Protocol, Version 2 (ST-II)", RFC 1190, CIP Working Group,
October 1990.
[RFC1583] Moy, J., "The OSPF Specification", RFC 1583, Proteon,
March 1994.
[RFC1723] Malkin, G., "RIP Version 2: Carying Additional Information",
RFC 1723, Xylogics, November 1994.
[RFC1884] Hinden, R., and S. Deering, "IP Version 6 Addressing
Architecture", RFC 1884, Ipsilon Networks, Xerox PARC,
December 1995.
Data Transmission - Broadcast
Introduction
The term "Broadcast" is used very frequently in the networking world . You will see it in most
networking books and articles, or see it happening on your hub/switch when all the LED's start
flashing at the same time !
If you have been into networking for a while you most probably have come across the terms
"broadcast" and "subnet broadcast" . When I first dived into the networking world, I was
constantly confused between the two, because they both carried the "broadcast" term in them. We
will analyse both of them here, to help you understand exactly what they are and how they are
used !
Broadcast
A Broadcast means that the network delivers one copy of a packet to each destination. On bus
technologies like Ethernet, broadcast delivery can be accomplished with a single packet
transmission. On networks composed of switches with point-to-point connections, software must
implement broadcasting by forwarding copies of the packet across individual connections until all
switches have received a copy. We will be focusing only on Ethernet broadcasts.
The picture below illustrates a router which has sent a broadcast to all devices on its network:
Normally, when the computers on the network receive a packet, they will first try to match the
MAC address of the packet with their own and if that is successful, they process the packet and
hand it to the OSI layer above (Network Layer), if the MAC address is not matched, then the
packet is discarded and not processed. However, when they see a MAC address of
FF:FF:FF:FF:FF:FF, they will process this packet because they recognise it as a broadcast.
But what does a "broadcast" look like ?
Check out the image below, which is taken from my packet sniffer:
Let's now have a closer look at the above packet:
The image above shows a broadcast packet. You can clearly see that the "MAC destination
address" is set to FF:FF:FF:FF:FF:FF. The "Address IP destination" is set to 255.255.255.255,
this is the IP broadcast address and ensures that no matter what IP address the receiving
computer(s) have, they will not reject the data but process it.
Now you might ask yourself "Why would a workstation want to create a broadcast packet ?"
The answer to that lies within the various protocols used on our networks !
Let's take for example Address Resolution Protocol, or ARP. ARP is used to find out which MAC
address (effectively , which network card or computer) has a particular IP address bound to it.
You will find a detailed example of the whole process in the IP Routing section.
For a network device such as a router to ask "Who has IP address 192.168.0.100 ? ", it must
"shout" it out so it can grab everyone's attention, which is why it will use a broadcast to make
sure everyone listens and processes the packet on the network.
In the example image above, the particular machine was looking for a DHCP server (notice the
"bootps" protocol under the UDP Header - Layer 4, which is basically DHCP).
Subnet Broadcast or Direct Broadcast
A Subnet or Direct broadcast is targetted not to all hosts on a network, but to all hosts on a
subnet. Since a physical network can contain different subnets/networks e.g 192.168.0.0 and
200.200.200.0, the purpose of this special broadcast is to send a message to all the hosts in a
particular subnet.
In the example below, Router A sends a subnet broadcast onto the network. Hosts A,B,C and the
Server are configured to be part of the 192.168.0.0 network so they will receive and process the
data, but Host D is configured with a different IP Adress, so it's part of a different network, it will
accept the packet cause of its broadcast MAC address, but will drop the packet when it reaches its
Network Layer, where it will see that this packet was for a different IP network.
It is very similar to the network broadcast we just talked about but varies slightly in the sense that
its IP broadcast is not set to 255.255.255.255 , but is set to the subnet broadcast address. For
example, my home network is a Class C network : 192.168.0.0 with a subnetmask of
255.255.255.0 or, if you like to keep it simple, : 192.168.0.0/24.
This means that the available valid hosts for this network are from 192.168.0.1 to 192.168.0.254.
In this Class C network, as in every other network, there are 2 addresses which I can't use. The
first one is preserved to identify the network (192.168.0.0) and the second one for the subnet
broadcast (192.168.0.255).
The above packet, captured from my packet sniffer, shows my workstation broadcasting to the
subnet 192.168.0.0. From the broadcast address you can tell that I am using a full Class C
network range, otherwise the Destination IP wouldn't be 192.168.0.255.
The Packet decoder on the right shows you the contents of each header from the above packet.
Looking at the MAC Header (Datalink Layer), the destination MAC address is set to
FF:FF:FF:FF:FF:FF and the IP Header (Network Layer) has the Destination IP set to
192.168.0.255 which is, as I said, the Subnet Broadcast Address. Again, all computers on the
network which are part of the 192.168.0.0 subnet will process this packet, the rest will drop the
packet once they see it's for a network to which they do not belong.
In this example, I double clicked at my "Network Places" and was searching for a computer, this
forced my workstation to send out a Subnet Broadcast on the network asking if a particular
computer existed on the network.
And that just about does it for the broadcasting section !
Controlling Broadcasts and Multicasts
Introduction
The first step in controlling broadcast and multicast traffic is to identify which devices are
involved in a broadcast or multicast storm. The following protocols can send broadcast or
multicast packets:

Address Resolution Protocol (ARP)






Open Shortest Path First (OSPF)
IP Routing Information Protocol Version 1 (RIP1)
Service Advertising Protocol (SAP)
IPX Routing Information Protocol (RIP)
NetWare Link Services Protocol (NLSP)
AppleTalk Address Resolution Protocol (AARP)
After identifying the source of the broadcast or multicast storm, you must examine the packets to
find out which protocol or application triggered the broadcast or multicast storm. For example, if
a single device is responsible for a broadcast storm, you can examine the device's broadcast
traffic to determine exactly what the device was doing. For example, you can find out what the
device was looking for or what the device was announcing.
Broadcast or multicast storms are often caused by a fault that occurs during the device discovery
process. For example, if an IPX-based printing environment has been misconfigured, a print
driver client may continually send SAP packets to locate a specific print server. Unanswered
broadcast or multicast requests usually indicate that a device is missing or has been
misconfigured.
Examine the broadcast traffic on your company's network. Do you see numerous unanswered,
repeat queries? Do you see protocols (such as IP RIP1, SAP, and IPX RIP) that just "blab" all day
even when no other devices may be listening?
Or, is the majority of the broadcast and multicast traffic on your company's network purposeful?
That is, does the broadcast and multicast traffic have a request-reply communication pattern? For
example, are broadcast lookups answered?
Do broadcast packets contain meaningful information? For example, if a network has numerous
routers, do broadcast packets contain routing update information?
Is the broadcast rate acceptable? Does your company's network need RIP updates every 30
seconds, or can you increase the interval to one minute?
BROADCAST/MULTICAST DOMAINS
If your company's network is experiencing excessive broadcast or multicast traffic, you should
also check the scope of the broadcast or multicast domain. (A broadcast or multicast domain is
the range of devices that are affected by a broadcast or a multicast packet.) Understanding
broadcast and multicast domains can help you determine how harmful a broadcast storm can be
from any point on the network.
The scope of a broadcast and multicast domain depends, to some degree, on the network design.
For example, the picture below shows two networks, a switched network and a routed network:
On a switched network, Device 1 sends a broadcast or multicast packet that is propagated to all
ports of the switch. (A typical layer-2 switch does not filter either broadcast or multicast traffic.)
On a routed network, however, a router does not forward broadcast traffic. If Device 1 sends a
broadcast packet, only Device 2 and the router see the broadcast packet. If appropriate, the router
processes the broadcast packet and sends a reply. Because the broadcast packet is not forwarded,
it does not affect Devices 3 or 4.
Introduction To Subnetting
Introduction
So you have made it this far hey ? Well you are in for an AWESOME ride.
Subnetting is one of my favorite subjects. It can be as simple as 1,2,3 or as complex as trying to
get free tech support from Microsoft :)
Getting serious now.. Subnetting is a very interesting and important topic. I gather that most of
you have heard about it or have some idea what it's all about. For those who haven't dealt with
subnets before... hang in there because you're not alone ! Keep in mind we also have the website's
forum where you can post questions or read up on other people's questions and answers. It's an
excellent source of information and I recommend you use it !
For some reason a lot of people consider Subnetting to be a difficult subject, which is true to
some extent, but I must say that I think that most of them see it that way because they do not have
solid foundations on networking (essential !), and especially the IP protocol. But for you guys
(and girls), the above doesn't apply, because we have covered IP in the best possible way and we
DO have solid foundations. Right ?
Some Advice !
If you started reading the IP protocol on this site from the begining and have understood
everything, then you won't have any problem understanding subnetting... but (there is always a
darn "but" !) on the other hand if you do not understand very well what we have been talking
about in the previous pages, then you're going to find this somewhat difficult. Which ever the
case, I'm going to try and explain subnetting as simply as possible and hope to answer all your
questions.
Now, because Subnetting is a big topic to talk about and analyse in one page (yeah right !) I've
split it throughout a few sections to break it down into smaller pieces. Logically, as you move on
to higher sections, the concepts and material difficulty will increase :


Section 1: Basic Subnetting Concepts. This section is to help you understand what a
subnet really is. Introduction to the Default Subnet masks is covered at first and then you
get to see and learn how the network is affected by changing the subnet mask. There are
plenty of them cool diagrams (which you only find on this site !) to ensure that you get
the picture right :)
Section 2: Subnet Masks and Their Effect. Here we will look at the Default Subnet mask
in a bit more detail and introduce a few new concepts. Classless and Classful IP
Addresses are covered here and you get to learn how the subnet mask affects them.

Section 3: The Subnet Mask Bits. Detailed analysis of subnet mask bits. Learn to
recognise the number of bits in a subnet mask, followed by an introduction to complex
subnets.

Section 4: Routing and Communications between Subnets. Understand how routers deal
with subnets, how computers which are in different subnets can communicate with each
other, along with a few general notes on subnetting that you should know.

Section 5: Subnetting Guidelines. Some last information to help you plan your new
networks and a few things to keep in mind so you can avoid future problems with
subnets.
IP Subnetting - The Basic Concepts
Introduction
Introduction ? We already did that in the previous page :)
Let's get stuck right into this cool topic !
What is Subnetting ?
When we Subnet a network, we basically split it into smaller networks. For example, when a set
of IP Addresses is given to a company, e.g 254 they might want to "break" (the correct term is
"partition") that one network into smaller ones, one for each department. This way, their
Technical department and Management department can each have a small network of their own.
By subnetting the network we can partition it to as many smaller networks as we need and this
also helps reduce traffic and hides the complexity of the network.
By default, all type of Classes (A, B and C) have a subnet mask, we call it the "Default Subnet
mask". You need to have one because:
1) All computers need the subnet mask field filled when configuring IP
2) You need to set some logical boundaries in your network
3) You should at least enter the default subnet mask for the Class you're using
In the previous pages I spoke about IP Classes, Network IDs and Host IDs, the fact is that the
Subnet mask is what determines the Network ID and Host ID portion of an IP Address.
The table below shows clearly the subnetmask that applies for each network Class.
When dealing with subnet masks in the real world, we are free in most cases to use any type of
subnet mask in order to meet our needs. If for example we require one network which can contain
up to 254 computers, then a Class C network with its default subnet mask will do fine, but if we
need more, then we might consider a Class B network with its default subnet mask.
Note that the default subnet masks have been set by the IEEE committee, the same guys that set
and approve the different standards and protocols.
We will have a closer look at this later on and see how we can achieve a Class C network with
more than 254 hosts.
Understanding the concept
Let's stop here for one moment and have a look at what I mean by partitioning one network into
smaller ones by using different subnet masks.
The picture below shows our example network (192.168.0.0). All computers here have been
configured with the default Class C subnet mask (255.255.255.0):
Because of the subnet mask we used, all these computers are part of the one network marked in
blue. This also means that any one of these hosts (computers, router and server) can communicate
with each other.
If we now wanted to partition this network into smaller segments, then we would need to change
the subnet mask appropriately so we can get the desired result. Let's say we needed to change the
subnet mask from 255.255.255.0 to 255.255.255.224 on each configured host.
The picture below shows us how the computers will see the network once the subnet mask has
changed:
In reality, we have just created 8 networks from the one large (blue) network we had, but I am
keeping things simple for now and showing only 2 of these smaller networks because I want you
to understand the concept of subnetting and see how important the subnet mask is.
In the next pages which are to follow I will analyse in great depth the way subnetting works and
how to calculate it. It is very important that you understand the concepts introduced in this
section, so make sure you do, before continuing !
Subnet Masks & Their Effect
Introduction
There are a few different ways to approach subnetting and it can get confusing because of the
complexity of some subnets and the flexibility they offer. For this reason I created this little
paragraph to let you know how we are going to approach and learn subnetting. So.....
We are going to analyse the common subnet masks for each Class, giving detailed examples for
most of them and allowing you to "see" how everything is calculated and understand the different
effects a subnet mask can have as you change it. Once you have mastered this, you can then go on
and create your custom subnet masks using any type of Class.
Default Subnet masks of each Class
By now you should have some idea what the subnet mask does and how it's used to partition a
network. What you need to keep in mind is that each Class has its DEFAULT subnet mask, which
we can change to suit our needs. I have already mentioned this in the previous page, but we need
to look into it in a bit more detail.
The picture below shows our 3 Network Classes with their respective default subnet mask:
The Effect of a Subnet Mask on an IP Address
In the IP Classes page we analysed and showed clearly how an IP Address consists of two parts,
1) The Network ID and 2) The Host ID. This rule applies for all IP Addresses that use the default
subnet mask and we call them Classful IP Addresses.
We can see this once again in the picture below, where the IP Address is analysed in Binary,
because this is the way you should work when dealing with subnet masks:
We are looking at an IP Address with its subnet mask for the first time. What we have done is
take the decimal subnet mask and converted it to binary, along with the IP Address. It is essential
to work in binary because it makes things clearer and we can avoid making silly mistakes. The
ones (1) in the subnet mask "lock" or, if you like, define the Network ID portion. If we change
any bit within the Network ID of the IP Address, then we immediately move to a different
network. So in this example, we have a 24 bit subnet mask.
NOTE:
All Class C Classful IP Addresses have a 24 bit subnet mask (255.255.255.0).
All Class B Classful IP Addresses have a 16 bit subnet mask (255.255.0.0).
All Class A Classful IP Addresses have an 8 bit subnet mask (255.0.0.0).
On the other hand, the use of an IP Address with a subnet mask other than the default results in
the standard Host bits (the Bits used to indentify the HOST ID) being divided in to two parts: a
Subnet ID and Host ID. These type of IP Addresses are called Classless IP Addresses.
In order to understand what a "Classless IP Address" is without getting confused, we are going to
take the same IP Address as above, and make it a Classless IP Address by changing the default
subnet mask:
Looking at the picture above you will now notice that we have a Subnet ID, something that didn't
exist before. As the picture explains, we have borrowed 3 bits from the Host ID and used them to
create a Subnet ID. Effectively we partitioned our Class C network into smaller networks.
If you're wondering how many smaller networks, you'll find the answer on the next page. I prefer
that you understanding everything here rather than blasting you with more Subnet ID's, bits and
all the rest :)
Summary
In this page we saw the default subnet mask of each Class and also introduced the Classful and
Classless IP Addresses, which are a result of using various subnet masks.
When we use IP Addresses with their default subnet masks, e.g 192.168.0.10 is a Class C IP
Address so the default subnet mask would be 255.255.255.0, then these are "Classful IP
Addresses".
On the other hand, Classless IP Addresses have their subnet mask modified in a way so that there
is a "Subnet ID". This Subnet ID is created by borrowing Bits from the Host ID portion.
The picture below shows us both examples:
I hope that you have understood the new concepts and material on this page. Next we are going to
talk about subnet bits, learn how to calculate how many bits certain subnet masks are and see the
different and most used subnet masks available.
If you think you might have not understood a few sections throughout this page, I would suggest
you read it once more :)
Subnetting Analysis
Introduction
So we have covered to some depth the subnetting topic, but there is still much to learn ! We are
going to explain here the available subnet masks and analyse a Class C network, using a specific
subnet mask. It's all pretty simple, as long as you understand the logic behind it.
Understanding the use, and analysing different subnet masks
Okay, so we know what a subnet mask is, but we haven't spoken (yet) about the different values
they take, and the guidelines we need when we use them. That's what we are going to do here !
The truth is that you cannot take any subnet mask you like and apply it to a computer or any other
device, because depending on the random subnet mask you choose, it will either create a lot of
routing and communication problems, or it won't be accepted at all by the device you're trying to
configure.
For this reason we are going to have a look at the various subnet masks so you know exactly what
you need to use, and how to use it. Most important, we are going to make sure we understand
WHY you need to choose specific subnet masks, depending on your needs. Most people simply
use a standard subnet mask without understanding what that does. This is not the case for the
visitors to this site.
Let's first have a look at the most common subnet masks and then I'll show you where these
numbers come from :)
Common Subnet Masks
In order to keep this place tidy, we are going to see the common Subnet masks for each Class.
Looking at each Class's subnet mask is possibly the best and easiest way to learn them.
Numer of bits
Class A
Class B
Class C
0 (default mask)
255.0.0.0
(default_mask)
255.255.0.0
(default_mask)
255.255.255.0
(default_mask)
1
255.128.0.0 (default
+1)
255.255.128.0
(default+1)
255.255.255.128
(default+1)
2
255.192.0.0
(default+2)
255.255.192.0
(default+2)
255.255.255.192
(default+2)
3
255.224.0.0
(default+3)
255.255.224.0
(default+3)
255.255.255.224
(default+3)
4
255.240.0.0
(default+4)
255.255.240.0
(default+4)
255.255.255.240
(default+4)
5
255.248.0.0
(default+5)
255.255.248.0
(default+5)
255.255.255.248
(default+5)
6
255.252.0.0
(default+6)
255.255.252.0
(default+6)
255.255.255.252
(default+6)
7
255.254.0.0
(default+7)
255.255.254.0
(default+7)
255.255.255.254
(default+7) * Only 1 Host
per subnet
8
255.255.0.0
(default+8)
255.255.255.0
(default+8)
255.255.255.255
(default+8) * Reserved
for Broadcasts
The above table might seem confusing at first, but don't despair ! It's simple, really, you just need
to look at it in a different way !
The trick to understanding the pattern of the above table is to think of it in the following way:
Each Class has its default subnet mask, which I have noted using the Green colour, and all we are
doing is borrowing a Bit at a time (starting from 1, all the way to 8) from the Host ID portion of
each class. I have used various colours to show you the decimal numbers that we get each time
we borrow a bit from the Host ID portion. If you can't understand how these decimal numbers
work out, then you should read up on the Binary & IP page.
Each time we borrow a bit from the Host ID, we split the network into a different number of
networks. For example, when we borrowed 3 Bits in the Class C network, we ended up
partitioning the network into 8 smaller networks. Let's take a look at a detailed example (which
we will break into three parts) so we can fully understand all the above.
We are going to do an analysis using the Class C network and 3 Bits which we took from the
Host ID. The analysis will take place once we convert our decimal numbers to binary, something
that's essential for this type of work. We will see how we get 8 networks from such a
configuration and their ranges !
In this first part, we can see clearly where the 8 Networks come from. The rule applies to all types
of Subnets, no matter what Class they are. Simply take the Subnet Bits and place them into the
power of 2 and you get your Networks.
Now, that was the easy part. The second part is slightly more complicated and I need you focused
so you don't get mixed up!
At first the diagram below seems quite complex, so try to follow me as we go through it:
The IP Address and Subnet mask is show in Binary format. We focus on the last octec which
contains all the information we are after. Now, the last octec has 2 parts, the Subnet ID and Host
ID. When we want to calculate the Subnets and Hosts, we deal with them one at a time. Once
that's done, we put the Subnet ID and Host ID portion together so we can get the last octec's
decimal number.
We know we have 8 networks (or subnets) and, by simply counting or incrementing our binary
value by one each time, we get to see all the networks available. So we start off with 000 and
finish at 111. On the right hand side I have also put the equivalent decimal number for each
network.
Next we take the Host ID portion, where the first available host is 0 0001 (1 in Decimal), because
the 0 0000 (0 in Decimal) value is reserved as it is the Network Address (see IP Classes page),
and the last value which is 1 1111 (31 in decimal) is used as a Broadcast Address for each Subnet
(see Broadcast page).
Note
I've given a formula in the IP Classes page that allows you to calculate the available hosts, that's
exactly what we are doing here for each subnet. This formula is :2 to the power of X -2. Where X
is the number of Bits we have in the Host ID field, which for our example is 5. When we apply
this formula, we get 2 to the power of 5 - 2 = 30 Valid (usable) IP Addresess. If you're wondering
why we subtract 2, it's because one is used for the Network Address of that subnet and the other
for the Broadcast Address of that subnet. This shouldn't be new news to anyone :)
Summing up, these are the ranges for each subnet in our new network:
I hope the example didn't confuse you too much; the above example is one of the simplest type,
which is why I chose a Class C network, they are the easiest to work with.
If you did find it somewhat difficult, try to read over it slowly. After a few times, you will get to
understand it. These things do need time to sink in !
Subnet Routing & Communications
Introduction
So we understand all (almost !) about subnetting, but there are few questions/topics which we
haven't talked about as yet. Experience shows you can never know everything 100% ! Routing
and Communication between subnets is the main topic here. We have analysed subnetting and
understood how it works, but haven't yet dealt with the "communication" side of things. These,
along with a few other things I would like to bring to your attention, are going to be analysed here
! It's an easy and very interesting page, so sit back and read through it comfortably.
Communication Between Subnets
So, after reading all the previous pages about subnetting, let me ask you the following:
Do you think computers that are on the same physical network but configured to be on separate
subnets are able to communicate ?
The answer is "no". Why ? Simply because you must keep in mind that we are talking about the
communication between 2 different networks !
Looking at our example of the Class C network on the previous page, the fact is that one
computer is part of the network 192.168.0.0 and the other one part of network 192.168.0.32, and
these are two different networks. In our example, from the moment we modified the default
subnet mask from 255.255.255.0 to 255.255.255.224, we split that one network to 8 smaller ones.
Let's try it !
And because we just have to prove it..... we are going to try it on my home network ! In the worst
case I'll have to spend all night trying to figure out what went wrong but it will be worth it ! :)
Without complicating things, here is a diagram of my home network (I've excluded any
computers we are not going to be using, in order to save space):
Well, that's the network we have to play with. I have put on the diagram the results of a few
simple pings from each host and as you can see, they all came out nice: PASS.
So in order to proceed to phase 2 of our experiment, I modified the Subnet mask of my
workstation to 192.168.0.35 / 255.255.255.224 , my Slackware Linux Firewall to 192.168.0.1 /
255.255.255.224 (internal Network Interface Card) and my NetWare 6 Server to 192.168.0.10 /
255.255.255.224 as shown in the diagram below:
As you can see, the results for my workstation were devastating ... alone and totaly unaware that
the other two servers are still there ! When my workstation tries to actually ping the Linux
Firewall, it will get no reply, because its Gateway is a host which belongs to another network,
something that we knew would never work.
So, we have concluded that there cannot be any sort of communication between the computers of
Network 1 and Network 2.
So how can two hosts in two different subnets talk to each other ? That's what we are going to
have a look at right now !
Building The Bridge
There is a way to allow the communication between my workstation and my servers and the
Internet. Actually there are a few ways to achieve this and I'm going to show you a few ways,
even though some might seem silly or impractical. We are not interested in the best solution at the
moment, we just want to know the ways in which we can establish communication between the
two subnets.
Considering that subnets are smaller networks, you would remember that we use routers to
achieve communications between two networks. This example of my home network is no
exception to this rule.
We need a router which will route packets from one network to the other. Let's have a look at the
different ways we can solve this problem:
Method 1: Using a Server with 2 Network Cards
Our first option is to use one of the Servers, or a new Server which has at least 2 network cards
installed. By connecting each network card to one of our networks and configuring the network
cards so that each one belongs to one subnet/network we can route packets between them:
The above diagram shows pretty much everything that's needed. The 2nd network card has been
installed and it's been assigned an IP Address that falls within our Network 1 range and therefore
can communicate with my workstation . On the other hand the NetWare server now acts as a
Gateway for Network 1, so my workstation is reconfigured to use it as its Gateway. Any packets
from Network 1 to Network 2 or the Internet will pass through the NetWare server
Method 2: Binding 2 IP Addresses to the same network card
This method is possibly the best and easiest way around our problem. We use the same network
card on the NetWare server and bind another IP Address to it.
This second IP Address will obviously fall within the Network 1 IP range so that my workstation
can communicate with the server:
As noted on the diagram, the only problem we might encounter is the need for the operating
system of the server to support this type of configuration, but most modern operating systems
would comply.
Once configured, the Server takes care of any routing between the two networks.
Method 3: Installing a router
The third method is to install a router in the network.
This might seem a bit far fetched but remember that we are looking at all possible ways to
establish communications between our networks ! If this was a large network, then a router could
possibly be the ideal solution, but given the size of my network, well... let's just say it would be a
silly idea :)
My workstation in this setup would forward all packets to its Gateway, which is the router's
interface and is connected to Network 1 and it will be able to see all other servers and access the
Internet. It's a similar setup to Method 1 but instead of a Server we have a dedicated router. Oh,
and by the way, if we would end up using such a configuration in real life.. the hub which both of
the router's interface's connect to, would be replaced by some type of WAN link.
That completes our discussion on Subnet routing and communication.
Subnetting Guidelines
Introduction
There is always that day when you are called upon to provide a solution to a network problem.
The number of problems that can occur in a network are numerous and believe it or not, most of
them can be avoided if the initial design and installation of the network are done properly.
When I say "done properly" I don't just mean connecting the correct wires into the wall sockets !
Looking at it from an Administrator's point of view, I'd say that a "properly done job" is one that
has had a lot of thought put into it to avoid silly routing problems and solve today's and any future
needs.
This page contains all the information you need to know in order to design a network that won't
suffer from any of the above problems. I've seen some network setups which suffered from all the
above, and you would be amazed how frequently I see them at large companies.
Guidelines - Plan for Growth
When creating subnets for your network, answer the following questions:

How many subnets are needed today?
Calculate the maximum number of subnets required by rounding up
the maximum number to the nearest power of two.
For example, if an organization needs five subnets, 2 to the power of 2 or 4 will not
provide enough subnet addressing space, so you must round up to
2 to the power of 3 = 8 subnets.

How many subnets are needed in the future?
You must plan for future growth. For example, if 9 subnets are
required today, and you choose to provide for 2 to the power of 4 = 16 subnets, this
might not be enough when the seventeenth subnet needs to be deployed.
In this example, it might be wise to provide for more growth and
select 2 to the power of 5 = 32 as the maximum number of subnets.

What are the maximum number of hosts on a given segment?
You must ensure that there are enough bits available to assign host
addresses to the organization’s largest subnet.
If the largest subnet needs to support 40 host addresses today, 2 to the power of 5 =
32 will not provide enough host address space, so you would need
to round up to 2 to the power of 6 = 64.

How many hosts will there be in the future?
Besides planning for additional subnets, you must also plan for more
hosts to be added to each subnet in the future.
Make sure the organization’s address allocation provides enough
bits to deploy the required subnet addressing plan.
When developing subnets, class C addresses present the greatest
challenge because fewer bits are available to divide between subnet
addresses and host addresses. If you accommodate too many
subnets, there may be no room for additional hosts and growth in
the future.
All the above points will help you succeed in creating a well designed network which will have
the ability to cater for any additional future requirements. And if you do happen to have any
problems, well, there is always the website's forum where you can post your questions and
problems :)
Supernetting/CIDR Introduction
Introduction
Supernetting, also known as Classless InterDomain Routing (CIDR), is another awesome subject.
It exists thanks to the wide adoption of the Internet, which lead to the exhaustion of the available
IP Addresses. More specifically, supernetting was invented in 1993 with the purpose of extending
the 32 bit IP address lifetime until the adoption of IPv6 was complete.
Putting it as simply as possible, supernets are used to combine multiple Class C networks into
groups, which the router, in turn, treats as one big network. It might not seem like a smart thing to
do, but if you look at the picture on a larger scale you will notice some of the really awesome
advantages this offers.
The creation of Supernets is also known as Address Aggregation.
The Big Picture
Consider this realistic example: You work for a large ISP with a few hundred networks to which
it provides services like Internet access, e-mail etc. These networks, which basically are your
ISP's clients, consist of 254 host IPs each (One full Class C network for each client), and they
each have a permanent connection to your headquarters via ISDN (represented by the yellow
lines) and from there your ISP has a direct connection to the Internet Backbone.
This diagram shows the example network we're talking about. Our main focus is the two routers
the ISP has, Router No.1 and Router No.2, because these will be affected when we supernet the
networks.
Routers No.1 & No.2 exchange information with each other and update their tables, which
contain the networks they know about. Router 2 connects directly to 10 networks and needs to let
Router 1 know about each one of them. Router 1 in turn will also advertise these networks to the
Internet Backbone Router so it too will know about these networks.
The above setup requires that Router No.1 and the Internet Backbone Router each have more than
13 separate entries in their routing tables to make sure that each network is accessible from them.
This is not so bad for this example, but try to imagine the problems and the complexity of a
similar setup where you have thousands of networks, where the routing tables would be enormous
! Also, you should keep in mind that the larger the routing table, the more work the router needs
to do because it has a huge table of routes to maintain and look through all the time.
By using Supernetting, we could supernet the whole network so it appears to the Internet as
follows:
You can clearly see that all the clients' networks have been combined into one big network. Even
though Router No.1 and the Internet Backbone router see only one big network, Router No.2
knows all about the smaller Class C networks since it is the one "hiding" them from the rest of the
world and makes sure it sends the correct data to each network.
We are going to look at a more detailed example later on so we can understand exactly how
supernetting works.
NOTE
There are some limitations with Supernetting - this is why there is a rule which we must follow so
we don't bump into big routing problems and upset the network. We will have a closer look at the
rule on the next page.
The reason for evolution
Supernetting has become very popular and there are a lot of reasons why:

Class B network address space has nearly been exhausted

A small percentage of class C network addresses have been
assigned to networks

Routing tables in Internet routers have grown to a size beyond
the ability of software and people to effectively manage

The 32-bit IP address space will eventually be exhausted
How Supernets work
If you understand how Subnetting works, then you will surely understand Supernetting.
Supernets are the opposite of Subnets in that they combine multiple Class C networks into blocks
rather than dividing them into segments.
When Subnetting, we borrow bits from the Host ID portion, which increases the number of bits
used for the Network ID portion. With Supernetting we do exactly the opposite, meaning we take
the bits from the Network ID portion and give them to the Host ID portion, as illustrated in the
picture below:
The next page deals with a detailed example to give you an in-depth analysis of Supernetting. The
main concept you need to understand is that Supernetting is all about combining multiple Class C
networks into one or more groups and it does this by taking bits from the Network ID portion
and, by doing so, the bits assigned to the Host ID portion increase.
I think that's a pretty good introduction to Supernetting :)
Let's take a look at an example to see and understand how exactly Supernetting works in practice.
Supernetting/CIDR Analysis
Introduction
We have had a good introduction to Supernetting (CIDR) and we are about to have a look at an
example to finally give answers to all those questions you have about the subject.
NOTE:This page requires you to have basic knowledge and understanding on Internet Protocol,
Subnetting and Binary notation. These are covered in great detail on other pages and I
recommend you have a quick look over these topics if you think you're not up to scratch.
Guideline - Rule to Supernetting / CIDR
Before we get in to deep waters, we must talk about the main rule that applies to creating
Supernets. For our example, this rule dictates that, in order to create Supernets from Class C IP
Addresses, the network address must be consecutive and the third octec of the first IP Address
must be divisible by two.
If we had 8 networks we wanted to combine, then the third octec of the first IP address would
need to be divisible by eight and not two.
There is one more rule you should know and this rule has to do with the routers of the network,
which will need to work with the new changes. This rule dictates that all routers on the network
must be running static routing or using a classless routing protocol such as RIP2 or OSPF.
Classless routing protocols include the subnet mask information and can also pass supernetting
information. Routing protocols such as RIP1 do NOT include subnet mask information and
would just create problems!
The Example
Here is an example involving two companies that want to use Supernetting to solve their network
requirements. We are going to determine which company mets the criteria for a Supernet (we are
assuming the routers are setup in a way that will support supernetting):
As you can see, Companys No.1's network passes the test, therefore we can Supernet its two
networks.
The Analysis of Company 1's Network & creation of its Supernet
Let's now take Company No.1's network, see how the Supernet will be created and determine
various important parameters like the new network's broadcast address, the identification of the
new supernets etc.
To begin, we must take our two networks and look at them in binary format, this is the only way
to "see" exactly what we're doing when supernetting, and take a look at the Network and Host ID
portions:
If you have problems understanding why we have no Subnet ID, please read up on the IP and
Subnetting sections on this site where everything is explained as simply as possible using cool 3D
diagrams.
Now we need to create the Supernet. This means that we are going to take one bit from the
Network ID of these networks and give it to the Host ID portion. This 1 Bit is our Supernet ID.
So our subnet mask will now be reduced from 24 bits to 23 bits. You might get confused or ask
why we call this extra Bit we are giving to the Host ID a Supernet ID?
The answer is simple, the one Bit that we are taking from the Network ID is given to the Host ID
but, in order for us to clearly "see" where the supernet is created, we colour it Green and give it
the "Supernet ID" label:
So there you have it, a new supernet created!
Now I can point out something new; I waited to show you this because I didn't want to confuse
you :)
We have one Supernet made from two networks (203.31.218.0 and 203.31.219.0). In order to
identify these two networks we name the first one (203.31.218.0) Supernet 0 and the second one
(203.31.219.0) Supernet 1. This is to distinguish between the two networks and nothing more.
It actually makes more sense if you look at the values the Supernet ID field takes:
It's very important to understand that Supernet 0 and 1 are part of the same new network ! This
means that there is only one network address, one network broadcast address and not two as you
might expect.
Let's now have a look at some more important information regarding the new network:
ITEM
VALUE
Supernet range
203.31.218.0 - 203.31.219.255
Subnet Mask
255.255.254.0
Supernet Network Address
203.31.218.0
Supernet Broadcast Address
203.31.219.255
Supernet 0
203.31.218.0
Supernet 1
203.31.219.0
Valid IP Address range
203.31.218.1 - 203.31.219.254
Reserved IP Addresses
203.31.218.0, 203.31.219.255
The above table shows pretty much all the information someone would need about the new
network.
Let me also point out to you (in case you didn't ask yourself :> ) that IP Addresses
203.31.218.255 and 203.31.219.0, which would have been used as the broadcast address for our
first old network and the network address of our old second network, are now usuable addresses!
Yes, you can actually assign them to hosts, because we have a Supernet. Now, even though you
can use these addresses, I would probably not use them unless I really needed to. Not that it
makes a difference, but I always tend to reserve these types of addresses, it's just a habit of mine
:)
Also, every host that will be part of this Supernet will need to be configured with the new Subnet
mask, 255.255.254.0 as noted in the table above. Any host that isn't reconfigured will have big
problems trying to communicate with the rest of the network.
Well that completes the analysis of our Supernet example. As I pointed out in the beginning, you
must have your IP, Subnetting and Binary Notation up to date otherwise you will have difficulties
understanding a lot of the material so make sure you read up on those sections before giving this
page another shot :)
The Supernetting/CIDR Chart
Introduction
Because subnet masks can get very confusing, the creators of this wonderful network technology
also made available a few things to make life somewhat easier.
The following chart is really a summary of what we've seen so far. It gives you a good idea of the
networks we can combine and the result we'd see.
The Supernetting/CIDR chart
There are four columns available in our chart:
The CIDR Block, the Supernet Mask, Number of Class C Networks and the Number of Hosts
column.
Class C
CIDR Block Supernet Mask Number of Class C Networks Number of Hosts
/14
255.252.0.0
1024
262144
/15
255.254.0.0
512
131072
/16
255.255.0.0
256
65536
/17
255.255.128.0
128
32768
/18
255.255.192.0
64
16384
/19
255.255.224.0
32
8192
/20
255.255.240.0
16
4096
/21
255.255.248.0
8
2048
/22
255.255.252.0
4
1024
/23
255.255.254.0
2
512
/24
255.255.255.0
1
254
/25
255.255.255.128
1/2
126
/26
255.255.255.192
1/4
62
/27
255.255.255.224
1/8
32
/28
255.255.255.240
1/16
16
/29
255.255.255.248
1/32
8
/30
255.255.255.252
1/64
4
I am going to explain the meaning of each column, although you probably already know most of
them.
The CIDR Block
The CIDR Block simply represents the number of bits used for the subnet mask. For example, /14
means 14 bits assigned to the subnet mask, it is a lot easier telling someone you have a 14 bit
subnet mask rather than a subnet mask of 255.252.0.0 :)
Note: In the above paragraph, I called the 14 bits as a subnet mask, when in fact it's a supernet
mask, but because when you configure any network device, the field you will need to enter the
value is usually named as the 'subnet mask', I decided to name it 'subnet mask' aswell, in order to
avoid confusion.
I'd like you to pay particular attention to the CIDR Block /24, and /25 to /30. These blocks are
highlighted in yellow and blue because I want them to grab your attention :)
When we use a CIDR Block of 24 (24 bit subnet mask) we are not Supernetting ! This is a default
subnet mask for a Class C network. With CIDR Blocks /25 to /30 we are actually Subnetting and
not Supernetting !
Now you might wonder why I have them in the chart. The fact is that those particular CIDR
Blocks are valid, regardless of whether applying them to a network means we are Subnetting and
not Supernetting. If you have dealt with any ISPs and IP Address assignments, chances are you
would have been given your IP Addresses in CIDR format.
A good example is if you wanted a permanent connection to your ISP and only required 2 IP
Addresses, one for your router and one for your Firewall, you would be assigned one /30 CIDR
Block. With such a subnet mask you will have 4 IP Addresses, from which 2 will be reserved
(one for the Network address and one for the Broadcast address) and you're left with 2 that you
can assign to your hosts (router and firewall).
The Supernet Mask
Basically, this is your Subnet mask. When you configure the devices that will be attached to the
specified network, this is the value you will enter as a Subnet mask. It's also the decimal value the
CIDR Block specifies. For example, a /24 CIDR block means a 24 bit Subnet mask, which in its
turn translates to 255.255.255.0 :) Simple stuff !
Number of Class C Networks
This number shows us how many Class C Networks are combined by using a specific Supernet
mask or, if you like, CIDR Block. For example, the /24 CIDR Block, 255.255.255.0 Supernet
mask is 1 Class C Network, whereas a /20 CIDR Block, 255.255.240.0 Supernet mask is 16 Class
C networks.
Number Of Hosts
This value represents the number of hosts per Supernet. For example, when we use a /20 CIDR
Block, which means a Subnet (or Supernet) mask of 255.255.240.0, we can have up to 4096
hosts. Pretty straightforward stuff.
There is one thing you must be careful of though ! The value 4096 does not represent the valid,
usable IP Addresses. If you wanted to find out how many of these IP Addresses you can actually
use, in other words, assign to hosts, then you simply take 2 IP Addresses from that number (the
first and last IP Address), so you're left with 4094 IP Addresses to play with :)
Why take 2 away ? You shouldn't be asking questions like that if you have read the IP and
Subnetting sections but I'll tell you anyway :) One is reserved for the Network Address and one
for the Broadcast Address of that network !
Summary
That completes the explanation of the Supernetting/CIDR chart. You will see that Supernetting
and Subnetting have quite a few things in common, and this is simply because they work on the
same principle.
Again, if you have the whole topic, or certain sections hard to understand, you should give
yourself a small break, and then come back for another round :)
Network Cabling
Introduction
This section talks about the cabling used in today's networks. There's a lot of different type of
cabling in today's networks and I am not going to cover all of them, but I will be talking about the
most common cables, which include UTP CAT5 straight through and crossover, Coax and a few
more.
Cabling is very important if you want a network to work properly with minimum problems and
bandwidth losses. There are certain rules which must never be broken when you're trying to
design a network, otherwise you'll have problems when computers try to communicate. I have
seen sites which suffer from enormous problems because the initial desgin of the network was not
done properly !
In the near future, cabling will probably be something old and outdated since wireless
communication seems to be gaining more ground, day by day. With that in mind, around 95% of
companies still rely on cables, so don't worry about it too much :)
Let's have a quick look at the history of cabling which will allow us to appreciate what we have
today !
The Beginning
We tend to think of digital communication as a new idea but in 1844 a man called Samuel Morse
sent a message 37 miles from Washington D.C. to Baltimore, using his new invention ‘The
Telegraph’. This may seem a far cry from today's computer networks but the principles remain
the same.
Morse code is type of binary system which uses dots and dashes in different sequences to
represent letters and numbers. Modern data networks use 1s and 0s to achieve the same result.
The big difference is that while the telegraph operators of the mid 19th Century could perhaps
transmit 4 or 5 dots and dashes per second, computers now communicate at speeds of up to 1
Giga bit, or to put it another way, 1,000,000,000 separate 1s and 0s every second.
Although the telegraph and the teletypewriter were the forerunners of data communications, it has
only been in the last 35 years that things have really started to speed up. This was borne out of the
necessity for computers to communicate at ever ncreasing speeds and has driven the development
of faster and faster networking equipment, higher and higher specification cables and connecting
hardware.
Development of new network technology
Ethernet was developed in the mid 1970's by the Xerox Corporation at its Palo Alto Research
Centre (PARC) in California and in 1979 DEC and Intel joined forces with Xerox to standardize
the Ethernet system for everyone to use. The first specification by the three companies, called the
'Ethernet Blue Book', was released in 1980, it was also known as the 'DIX standard' after their
initials.
It was a 10 Mega bits per second system (10Mbps, = 10 million 1s and 0s per second) and used a
large coaxial backbone cable running throughout the building, with smaller coax cables tapped
off at 2.5m intervals to connect to the workstations. The large coax, which was usually yellow,
became known as 'Thick Ethernet' or 10Base5 - the '10' refers to the speed (10Mbps), the 'Base'
because it is a base band system (base band uses all of its bandwidth for each transmission, as
opposed to broad band which splits the bandwidth into separate channels to use concurrently) and
the '5' is short for the system's maximum cable length, in this case 500m.
The Institute of Electrical and Electronic Engineers (IEEE) released the official Ethernet standard
in 1983 called the IEEE 802.3 after the name of the working group responsible for its
development and, in 1985, version 2 (IEEE 802.3a) was released. This second version is
commonly known as 'Thin Ethernet' or 10Base2; in this case the maximum length is 185m even
though the '2' suggest that it should be 200m.
Since 1983, various standard have been introduced because of the increased bandwidth
requirements, so far we are up to the Gigabit rate !
Unshielded Twisted Pair
Introduction
Unshielded Twisted Pair cable is most certainly by far the most popular cable around the world.
UTP cable is used not only for networking but also for the traditional telephone (UTP-Cat 1).
There are 6 different types of UTP categories and, depending on what you want to achieve, you
would need the appropriate type of cable. UTP-CAT5 is the most popular UTP cable, it came to
replace the good old coaxial cable which was not able to keep up with the constant growing need
for faster and more reliable networks.
Characteristics
The characteristics of UTP are very good and make it easy to work with, install, expand and
troubleshoot and we are going to look at the different wiring schemes available for UTP, how to
create a straight through UTP cable, rules for safe operation and a lot of other cool stuff !
So let's have a quick look at each of the UTP categories available today:
Category 1/2/3/4/5/6 – a specification for the type of copper wire (most telephone and network
wire is copper) and jacks. The number (1, 3, 5, etc) refers to the revision of the specification and
in practical terms refers to the number of twists inside the wire (or the quality of connection in a
jack).
CAT1 is typically telephone wire. This type of wire is not capable of supporting computer
network traffic and is not twisted. It is also used by phone companies who provide ISDN, where
the wiring between the customer's site and the phone company's network uses CAT 1 cable.
CAT2, CAT3, CAT4, CAT5 and CAT6 are network wire specifications. This type of wire can
support computer network and telephone traffic. CAT2 is used mostly for token ring networks,
supporting speeds up to 4 Mbps. For higher network speeds (100Mbps plus) you must use CAT5
wire, but for 10Mbps CAT3 will suffice. CAT3, CAT4 and CAT5 cable are actually 4 pairs of
twisted copper wires and CAT5 has more twists per inch than CAT3 therefore can run at higher
speeds and greater lengths. The "twist" effect of each pair in the cables will cause any
interference presented/picked up on one cable to be cancelled out by the cable's partner which
twists around the initial cable. CAT3 and CAT4 are both used for Token Ring and have a
maximum length of 100 meters.
CAT6 wire was originally designed to support gigabit Ethernet (although there are standards that
will allow gigabit transmission over CAT5 wire, that's CAT 5e). It is similar to CAT5 wire, but
contains a physical separator between the 4 pairs to further reduce electromagnetic interference.
The next pages (check menu) show you how UTP cable is wired and the different wiring
schemes. It's well worth visiting and reading about.
Straight Thru UTP Cables
Introduction
We will be mainly focussing on the wiring of CAT5 cables here because they are the most
popluar cables around ! You will find info on wiring the classic CAT1 phone cables as well. It is
very important you know how exactly to wire UTP cables because it's the base of a solid network
and will help you avoid hours of frustration and troubleshooting if you do it right the first time :)
On the other hand, if you are dealing with a poorly cabled network, then you will be able to find
the problem and fix it more efficiently.
Wiring the UTP cables !
We are now going to look at how UTP cables are wired. There are 2 popular wiring schemes that
most people use today: the T-568A and T-568B, that differ only in which color coded pairs are
connected - pair 2 and 3 are reversed. Both work equally well, as long as you don't mix them! If
you always use only one version, you're OK, but if you mix A and B in a cable run, you will get
crossed pairs!
UTP cables are terminated with standard connectors, jacks and punchdowns. The jack/plug is
often referred to as an "RJ-45", but that is really a telco designation for the "modular 8 pin
connector" terminated with a USOC pinout used for telephones. The male connector on the end
of a patchcord is called a "plug" and the receptacle on the wall outlet is a "jack."
As I've already mentioned, UTP has 4 twisted pairs of wires, we'll now look at the pairs to see
what colour codes they have :
As you can see in the picture on the left, the 4 pairs are labeled. Pairs 2 & 3 are used for normal
10/100Mbit networks, while Pairs 1 & 4 are reserved. In Gigabit Ethernet, all 4 pairs are used.
CAT5 cable is the most common type of UTP around the world ! It's flexible, easy to install and
very reliable when wired properly :)
The left and center pictures show the end of a CAT5 cable with an RJ-45 connector; used by all
cables to connect to a hub or to your computer's network card. The picture to the right shows a
stripped CAT5 cable, indicating the 4 twisted pairs.
And to be a bit fancy, don't think that UTP CAT5 cable only comes in one boring colour... those
days are over ! You get a wide range of choices today :
.......
........
T-568A & T-568B 4-pair Wiring
Ethernet is generally carried in 8-conductor cables with 8-pin modular plugs and jacks. The
connector standard is called "RJ-45" and is just like a standard RJ-11 modular telephone
connector, except it is a bit wider to carry more pins.
Note: Keep in mind that the wiring schemes we are going to talk about are all for straight through
cables only ! Cross over cables are examined on a separate page !
The eight-conductor data cable contains 4 pairs of wires. Each pair consists of a solid colored
wire and a white wire with a stripe of the same color. The pairs are twisted together. To maintain
reliability on Ethernet, you should not untwist them any more than necessary (like about 1 cm).
The pairs designated for 10 and 100 Mbit Ethernet are Orange and Green. The other two pairs,
Brown and Blue, can be used for a second Ethernet line or for phone connections.
There are two wiring standards for these cables, called "T568A" (also called "EIA") and "T568B"
(also called "AT&T" and "258A"). They differ only in connection sequence - that is, which color
is on which pin, not in the definition of what electrical signal is on a particular color.
T-568A is supposed to be the standard for new installations, while T-568B is an acceptable
alternative. However, most off-the-shelf data equipment and cables seem to be wired to T568B.
T568B is also the AT&T standard. In fact, I have seen very few people using T568A to wire their
network. It's important not to mix systems, as both you and your equipment will become
hopelessly confused.
Pin Number Designations for T568B
Note that the odd pin numbers are always the white with stripe color (1,3,5,7). The wires connect
to RJ-45 8-pin connectors as shown below:
Color Codes for T568B
Pin color - pair name
1 white/orange (pair 2) TxData +
2 orange (pair 2) ........ TxData 3 white/green (pair 3) ..RecvData+
4 blue (pair 1)
5 white/blue (pair 1)
6 green (pair 3) ...........RecvData7 white/brown (pair 4)
8 brown (pair 4)
The wall jack may be wired in a different sequence because the wires are often crossed inside the
jack. The jack should either come with a wiring diagram or at least designate pin numbers.
Note that the blue pair is on the centre pins; this pair translates to the red/green pair for ordinary
telephone lines which is also in the centre pair of an RJ-11. (green=wh/blu; red=blu)
Pin Number Designations for T568A
The T568A specification reverses the orange and green connections so that pairs 1 and 2 are on
the centre 4 pins, which makes it more compatible with the telco voice connections. (Note that in
the RJ-11 plug at the top, pairs 1 and 2 are on the centre 4 pins.) T568A goes:
Color Codes for T568A
Pin color - pair name
1 white/green (pair 3) ..RecvData+
2 green (pair 3) ..........RecvData3 white/orange (pair 2) TxData +
4 blue (pair 1)
5 white/blue (pair 1)
6 orange (pair 2) .........TxData 7 white/brown (pair 4)
8 brown (pair 4)
The diagram below shows the 568A and 568B in comparison:
Where are they used ?
The most common application for a straight through cable is a connection between a PC and a
hub/switch. In this case the PC is connected directly to the hub/switch which will automatically
cross over the cable internaly, using special circuits. In the case of a CAT1 cable, which is usually
found in telephone lines, only 2 wires are used, these do not require any special cross over since
the phones connect directly to the phone socket.
The picture above shows us a standard CAT5 straight thru cable, used to connect a PC to a HUB.
You might get a bit confused because you might expect the TX+ of one side to connect to the
TX+ of the other side but this is not the case. When you connect a PC to a HUB, the HUB it will
automatically x-over the cable for you by using its internal circuits, this results Pin 1 from the PC
(which is TX+) to connect to Pin 1 of the HUB (which connects to RX+).This happens for the
rest of the pinouts aswell.
If the HUB didn't x-over the pinouts using its internal circuits (this happens when you use the
Uplink port on the hub) then Pin 1 from the PC (which is TX+) would connect to Pin 1 of the
HUB (which would be TX+ in this case). So you notice that no matter what we do with the HUB
port (uplink or normal), the signals assigned to the 8 Pins on the PC side of things, will always
remain the same, the HUB's pinouts though will change depending wether the port is set to
normal or uplink.
This pretty much concludes our discussion on straight thru UTP cables !
CAT5 UTP X-Over Cable
Introduction
The cross-over (x-over) CAT5 UTP cable has to be one of the most used cables after the classic
straight-thru cable. The x-over cable allows us to connect two computers without needing a hub
or switch. If you recall, the hub does the x-over for you internally, so you only need to use a
straight thru cable from the PC to the hub. Since now we don't have a hub, we need to manually
do the x-over.
Why do we need an x-over ?
When sending or receiving data between two devices, e.g computers, one will be sending while
the other receives. All this is done via the network cable and if you look at a network cable you
will notice that it contains multiple cables. Some of these cables are used to send data, while
others are used to receive data and this is exactly what we take into account when creating an xover cable. We basically connect the TX (transmit) of one end to the RX (receive) of the other !
The diagram below shows this in the simplest way possible:
CAT5 X-over
There is only one way to make a CAT5 x-over cable and it's pretty simple. Those who read the
"wiring utp" section know an x-over cable is a a 568A on one end and a 568B on the other. If you
haven't read the wiring section, don't worry because I'll be giving you enough information to
understand what we are talking about.
As mentioned previously, an x-over cable is as simple as connecting the TX from one end to the
RX of the other and vice versa.
Let's now have a look at the pinouts of a typical x-over CAT5 cable:
As you can see, only 4 pins are needed for a x-over cable. When you buy a x-over cable, you
might find that all 8 pins are used, these cables aren't any different from the above, it's just that
there are cables running to the unsed pins. This won't make any difference in performance, but is
just a habit some people follow.
Here are the pinouts for a x-over cable which has all 8 pins connected:
Where else can I use a x-over ?
X-over cables are not just used to connect computers, but a variety of other devices. Prime
example are switches and hubs. If you have two hubs and you need to connect them, you would
usually use the special uplink port which, when activated through a little switch (in most cases),
makes that particular port not cross the tx and rx, but leave them as if they where straight through.
What happens though if you haven't got any uplink ports or they are already used ?
The X-over cable will allow you to connect them and solve your problem. The diagram below
shows a few examples to make it simpler:
As you can see in the above diagram, thanks to the uplink port, there is no need for a x-over
cable.
Let's now have have look at how to cope when we don't have an uplink to spare, in which case we
must make a x-over cable to connect the two hubs:
All the above should explain a x-over cable, where we use it and why we need it. I thought it
would be a good idea to include, as a last picture, the pinouts of a straight thru and a x-over cable
so you can compare them side by side:
10Base-T/2/5/F/35 - Ethernet
Introduction
The 10Base-T UTP Ethernet and 10Base-2 Coax Ethernet were very popular around the early to
mid 1990's when 100Mbit network cards and hubs/switches were very expensive. Today's prices
have dropped so much that most vendors don't focus on the 10Base networks but the 100Base
ones and, at the same time, support the 10 BaseT and 10Base-2 standard. We will also talk about
the 10Base5/F and 35 shortly.
So what does 10 BaseT/2/5/F/35 mean ?
To make it simpler to distinguish cables they are categorised; that's how we got the CAT1, 2, 3
etc cables. Each category is specific for speed and type of network. But since one type of cable
can support various speeds, depending on its quality and wiring, the cables are named using the
"BaseT" to show exactly what type of networks the specific cable is made to handle.
We are going to break the "10 Base T (and the rest) " into 3 parts so we can make it easier to
understand:
10
The number 10 represents the frequency in MHz (Mega HertZ) for which this cable is made. In
this case it is 10 MHz. The greater the MHz, the greater speeds the cable can handle. If you try to
use this type of cable for greater frequencies (and, therefore, speeds) then it either will not work
or become extremely unreliable. The 10 MHz speed translates to 10Mbit per second, which in
theory means 1.2 MBytes per second. In practice though, you wouldn't get more than 800 KBytes
per second.
Base
The word "Base" refers to Baseband. Baseband is the type of communication used by Ethernet
and it means that when a computer is transmitting, it uses all the available bandwith, whereas
Broadband (cable modems) shares the bandwidth available. This is the reason cable modem users
notice a slowdown in speed when they are connected on a busy node, or when their neighbour is
downloading all the time at maximum speed ! Of course with Ethernet you will notice a
slowdown in speed but it will be smaller in comparison to broadband.
T/2/5/F/35
The "T" refers to "Twisted Pair" physical medium that carries the signal. This shows the structure
of the cable and tells us it contains pairs which are twisted. For example, UTP has twisted pairs
and this is the cable used in such cases. For more information, see the "UTP -Unshielded Twisted
Pair" page where you can find information on pinouts for the cables.
10Base-T
A few years ago, the 10 BaseT cables used CAT3 cables, which are used for speeds up to 10Mbit,
but today you will find mostly CAT5 cables, which are good for speeds up to 100 Mhz or
100Mbit, these cables are also used for 10Mbit networks. Only 2 pairs of the UTP cable are used
with the 10Base-T specification and the maximum length is 100 meters. Minimum length
between nodes is 2.5 meters.
10Base-2
This specification uses Coaxial cable which is usually black, sometimes also called "Thinwire
coax", "Thin Ethernet" or "RJ-58" cable. Maximum length is 185 meters while the minimum
length between nodes is 0.5 meters. 10Base-2 uses BNC connectors which, depending on the
configuration, require special terminators. The 10Base-2 specification is analysed here in great
detail (also contains pictures) if you wish to read more about it.
10Base-5
This specification uses what's called "Thickwire" coaxial cable, which is usually yellow. The
maximum length is 500 meters while the minimum length between nodes is 2.5 meters. Also,
special connectors are used to interface to the network card, these are called AUI (Attachment
Unit Interface) connectors and are similar to the DB-15 pin connectors most soundcards use for
their joystick/MIDI port.
Most networks use UTP cable and RJ-45 connectors or Coaxial cable with BNC "T" connectors,
for this reason special devices made their way to the market that allow you to connect an AUI
network card to these different cable networks.
The picture below shows you a few of these devices:
10Base-F
This specification uses fibre optic cable. Fibre optic cable is considered to be more secure than
UTP or any other type of cabling because it is nearly impossible to tap into. It is also resistant to
electro magnetic interference and attenuation. Even though the 10Base-F specification is for
speeds up to 10Mbits per second, depending on the type of fibre and equiptment you use, you can
get speeds of up to 2Gigabits per second !
10Base-35
The 10Base-35 specification uses broadband coaxial cable. It is able to carry multiple baseband
channels for a maximum length of 3,600 meters or 3.6 Kms.
Summary
To summarise, keep the following in mind:




10Base-T works for 10Mbit networks only and uses unshielded twisted pair cable with
RJ-45 connectors at each end and maximum length of 100 meters. They also only use 2
pairs of cables.
10Base-2 works for 10Mbit networks only and uses Coaxial cable. Maximum length is
185 meters and BNC "T" connectors are used to connect to the computers; there are
special terminators at each of the coaxial cable.
10Base-5 works for 10Mbit networks only and uses Thick Coaxial cable. Maximum
length is 500 meters and special "AUI" connectors (DB-15) are used to interface with the
network card.
10Base-F works for 10Mbit networks only and uses cool fibre optic cable :)
100Base-(T) TX/T4/FX - Ethernet
Introduction
The 100Base-TX (sometimes referred to 100Base-T) cable is the most popular cable around since
it has actually replaced the older 10Base-T and 10Base-2 (Coaxial). The 100Base-TX cable
provides fast speeds up to 100Mbits and is more reliable since it uses CAT5 cable (see the CAT
1/2/3/4/5 page).There is also 100Base-T4 and 100Base-FX available, which we discuss later.
So what does 100Base-TX/T4/FX mean ?
To make it simpler to distinguish cables they are categorised; that's how we got the CAT1, 2, 3
etc cables. Each category is specific for speed and type of network. But since one type of cable
can support various speeds, depending on its quality and wiring, the cables are named using the
"BaseT" to show exactly what type of networks the specific cable is made to handle.
We are going to break the "100Base-T?" into 3 parts so we can make it easier to understand:
100
The number 100 represents the frequency in MHz (Mega HertZ) for which this cable is made. In
this case it is 100 MHz. The greater the MHz, the greater speeds the cable can handle. If you try
to use this type of cable for greater frequencies (and, therefore, speeds) it will either not work or
become extremely unreliable. The 100 MHz speed translates to 100Mbit per second, which in
theory means 12 MBytes per second. In practice though, you wouldn't get more than 4 MBytes
per second.
Base
The word "Base" refers to Baseband. Baseband is the type of communication used by Ethernet
and it means that when a computer is transmitting, it uses all the available bandwith, whereas
Broadband (cable modems) shares the bandwidth available. This is the reason cable modem users
notice a slowdown in speed when they are connected on a busy node, or when their neighbour is
downloading all the time at maximum speed ! Of course with Ethernet you will notice a
slowdown in speed but it will be smaller in comparison to broadband.
TX/T4/FX
The "T" refers to "Twisted Pair" physical medium that carries the signal. This shows the structure
of the cable and tells us it contains pairs which are twisted. For example, UTP has twisted pairs
and this is the cable used in such cases. The 100Base-T is used sometimes to refer to the
100Base-TX cable specification. For more information, see the "UTP -Unshielded Twisted Pair"
page where you can find information on pinouts for the cables. All 100Mbit rated cables, except
the 100Base-FX, use CAT5 cable.
100Base-TX
The TX (sometimes refered as "T" only) means it's a CAT5 UTP straight through cable using 2 of
the 4 available pairs and supports speeds up to 100Mbits. Maximum length is 100 meters and
minimum length between nodes is 2.5 meters.
100Base-T4
The T4 means it's a CAT5 UTP straight through cable using all 4 available pairs and supports
speeds up to 100Mbits. Maximum length is 100 meters and minimum length between nodes is 2.5
meters.
100Base-FX
The FX means it's a 2 strand fiber cable and supports speeds up to 100Mbits. Maximum length is
usually upto 2 kms.
Summary
To summarise, keep the following in mind:




100Base-TX/T4 works for 100Mbit networks only and uses unshielded twisted pair cable
with RJ-45 connectors at each end
All CAT5 UTP cables have 4 pairs of cables (8 wires).
100Base-TX (sometimes called 100Base-T) uses 2 of the 4 available pairs within the
UTP cable, whereas the 100Base-T4 uses all 4 pairs.
100Base-FX also works for speeds up to 100Mbits but uses fibre optic cable instead of
UTP.
Fibre Optic Cable
Introduction
In the 1950's more research and development into the transmission of visible images through
optical fibres led to some success in the medical world where it was being used in remote
illumination and viewing instruments. In 1966 Charles Kao and George Hockham proposed the
transmission of information over glass fibre and realised that to make it a practical proposition,
much lower losses in the cables were essential.
This was the driving force behind the developments to improve the optical losses in fibre
manufacturing and today optical losses are significantly lower than the original target set by
Charles Kao and George Hockham.
The advantages of using fibre optics
Because of the Low loss, high bandwidth properties of fibre cables they can be used over greater
distances than copper cables. In data networks this can be as much as 2km without the use of
repeaters. Their light weight and small size also make them ideal for applications where running
copper cables would be impractical and, by using multiplexors, one fibre could replace hundreds
of copper cables. This is pretty impressive for a tiny glass filament, but the real benefit in the data
industry is its immunity to Electro Magnetic Interference (EMI), and the fact that glass is not an
electrical conductor.
Because fibre is non-conductive it can be used where electrical isolation is needed, for instance,
between buildings where copper cables would require cross bonding to eliminate differences in
earth potentials. Fibres also pose no threat in dangerous environments such as chemical plants
where a spark could trigger an explosion. Last but not least is the security aspect, it is very, very
difficult to tap into a fibre cable to read the data signals.
Fibre construction
There are many different types of fibre cable, but for the purposes of this explanation we will deal
with one of the most common types, 62.5/125 micron loose tube. The numbers represent the
diameters of the fibre core and cladding, these are measured in microns which are millionths of a
metre.
Loose tube fibre cable can be indoor or outdoor, or both, the outdoor cables usually have the tube
filled with gel to act as a moisture barrier to the ingress of water. The number of cores in one
cable can be anywhere from 4 to 144.
Over the years a variety of core sizes have been produced but these days there are three main
sizes that are used in data communications, these are 50/125, 62.5/125 and 8.3/125. The 50/125
and 62.5/125 micron multi-mode cables are the most widely used in data networks, although
recently the 62.5 has become the more popular choice. This is rather unfortunate because the
50/125 has been found to be the better option for Gigabit Ethernet applications.
The 8.3/125 micron is a single mode cable which until now hasn't been widely used in data
networking due to the high cost of single mode hardware. Things are beginning to change
because the length limits for Gigabit Ethernet over 62.5/125 fibre has been reduced to around
220m and now using 8.3/125 may be the only choice for some campus size networks. Hopefully,
this shift to single mode may start to bring the costs down.
What's the difference between single-mode and multi-mode?
With copper cables larger size means less resistance and therefore more current, but with fibre the
opposite is true. To explain this we first need to understand how the light propagates within the
fibre core.
Light propagation
Light travels along a fibre cable by a process called 'Total Internal Reflection' (TIR), this is made
possible by using two types of glass which have different refractive indexes. The inner core has a
high refractive index and the outer cladding has a low index. This is the same principle as the
reflection you see when you look into a pond. The water in the pond has a higher refractive index
than the air and if you look at it from a shallow angle you will see a reflection of the surrounding
area, however, if you look straight down at the water you can see the bottom of the pond.
At some specific angle between these two view points the light stops reflecting off the surface of
the water and passes through the air/water interface allowing you to see the bottom of the pond.
In multi-mode fibres, as the name suggests, there are multiple modes of propagation for the rays
of light. These range from low order modes, which take the most direct route straight down the
middle, to high order modes, which take the longest route as they bounce from one side to the
other all the way down the fibre.
This has the effect of scattering the signal because the rays from one pulse of light arrive at the
far end at different times; this is known as Intermodal Dispersion (sometimes referred to as
Differential Mode Delay, DMD). To ease the problem, graded index fibres were developed.
Unlike the examples above which have a definite barrier between core and cladding, these have a
high refractive index at the centre which gradually reduces to a low refractive index at the
circumference. This slows down the lower order modes allowing the rays to arrive at the far end
closer together, thereby reducing intermodal dispersion and improving the shape of the signal.
So what about the single-mode fibre?
Well, what's the best way to get rid of Intermodal Dispersion?, easy, only allow one mode of
propagation. So a smaller core size means higher bandwidth and greater distances. Simple as that
! :)
Direct Cable Connection
Introduction
From the early PC days, Direct Cable Connection (dcc) was the most popular way to transfer data
from one PC to another. Of course, it might seem a bit of an "old fashioned" way to transfer data
these days but remember that back then most PC's were running Dos 6.22 or Windows for
Workgroups 3.11 if you were lucky !
Today, most computers are equipped with a network card and have an x-over or hub which will
allow you to transfer data a lot faster than a serial or parallel cable. But still, there is always a
time when you require a simple transfer via serial or parallel and that's what this page is about.
There is a variety of programs which allow you to use the above mentioned cables to successfully
transfer data between PCs but you should know that you can achieve your goal without them as
well since Windows 95 and above supports the direct cable connection method.
Installing Windows programs or components to transfer data is out of this section's scope, but I
have included some notes on what you should check before attempting the Direct Connection via
cable, this info is included in the "Important DCC Info". We will also be learning how to create
the cables required to meet our goals and comparing the speed of the two (Serial and Parallel)
Because the page ended up being quite long, I decided to split it in order to make it easier to read.
Simply click on the subject you'd like to read about:
Serial Direct Connection
Parallel Direct Connection
Serial Direct Cable Connection
Introduction
The Serial Direct Connection is the one which utilizes the COM ports of your computers. Every
computer has at least 2 COM ports, COM1 and COM2. The "COM" stands for
"Communications". It's pinouts are a lot simpler when compared to the parallel port, but the speed
is also a lot slower :)
To give you an idea of how fast (or slow) a serial port is, at its best you will get around 12 to 14
KB per second. That's pretty slow when you're used to a network connection, but let me show you
how serial data is transferred so you can also understand why it's a lot slower:
The above picture gives you an idea on how serial data is transferred. Each coloured block that is
numbered is sent from PC 1 to PC 2. PC 2 will receive the data in the same order it was sent, in
other words it will receive data block 1 first and then 2, all the way to block 7. This is a pretty
good representation of data flow in a serial cable. Serial ports transmit data sequentially over one
pair of wires (the rest of the wires are used to controll the transfer).
Another way you can think of it is like a one lane road where the road is wide enough to only fit
one car at a time (one data block at a time in our example above), so you would imagine that the
road cannont process several cars at one time.
The Serial port
Most new computers have two COM ports with 9 pins each, these are DB-9 male connectors.
Older computers would have one DB-9 male connector and one DB-25 male connector. The 25
pin male connector is pretty much the same as the 9 pin, it's just bigger.
Let's have a look at a serial port to see what we are talking about:
Different pinouts are used for the DB-9 and DB-25 connectors and we will have a look at them in
a moment. Let's just have another quick look at the COM ports of a new computer:
Notice the COM ports, they are both DB-9 connectors, there is no more DB-25 ! The connector
above the two blue COM ports is an LPT or Parallel port.
The serial port of a computer is able to run at different speeds, thus allowing us to connect
different devices which communicate at different speeds with the computer. The following table
shows the speeds at which most computers' serial ports are able to run and how many KB/sec
they translate to:
Now we will have a look at the pin outs of both DB-9 and DB-25 connectors:
The Cable
All that's left now is the pinouts required to allow us to use the serial cable for direct connection.
There is a special term for this type of a cable, it's call a "null modem" cable, which basically
means you need to have TX and RX crossed over. Because you can have different configurations,
e.g DB-9 to DB-9, DB-9 to DB-25, and DB-25 to DB-25, I have created different tables to show
you the pinouts for each one:
1) DB-9 to DB-9. You use this configuration when you need a cable with a DB-9 connector on
each end:
2) DB-9 to DB-25. You use this configuration when you need a cable with one DB-9 and one
DB-25 connector on either end:
3) DB-25 to DB-25. You use this configuration when you need a cable with a DB-25 connector
on each end:
Well, that pretty much covers everything about serial direct connection via a null modem cable.
If you're using third party software to connect your computers, you probably won't stumble into
big problems, but if you're using Windows software be sure you have unique names for each of
your computers because Windows will treat the direct connection as a "network" connection. This
means you will be able to see the other computer via Network Neighborhood.
Parallel Direct Cable Connection
Parallel Direct Connection
The Parallel Direct Connection is the second solution to transfer data from one computer to
another. The cable required is slightly more complicated as it has more wires that need to be
connected, but the speeds you will get from it will make it well worth the time and effort required
to make the cable.
Most people would know the parallel Direct Cables as "Laplink" cables. You get one when you
buy the Laplink program or PCAnywhere, it's usually a yellow cable, but you'll be able to make
your own by the time you finish reading this page.
Because of the variety of parallel (LPT) ports, 4 to be precise, but we use the same cable for
everyone one of them. We will have a look at them all to make sure we cover everything :)
Now, as far as speed's concerned, with a standard LPT port you're looking at around 40 to 60 KB
per second whereas with the faster LPT ports you should expect something around 1MB per
second ! Whichever way you see it, it's a huge improvement in comparison to the serial cable
(Null modem cable).
Let's have a quick look at the way data is transferred over a parallel link, this will help us
understand why it's also a lot faster than the serial method of transfer:
This diagram shows a parallel transfer. In serial transfer there is one block of data moved at a
time, whereas with parallel and, more specificaly in our example, there are 4 data blocks moved
at a time. Parallel ports transmit data simultaneously over multiple lines and are therefore faster
than serial.
If you're having difficulties understanding the diagram just think of a 4 lane highway, which is
our parallel cable, where 4 cars at a time are moving whereas the serial cable is like a one lane
highway with one car at a time moving. Hope that helps :)
What does the parallel port (LPT) look like ?
The picture below shows a parallel port, also known as LPT port, of a new computer.
With new computers, you will always find the LPT port right above the two COM ports and it's
usually colour coded purple. No matter what type of LPT port you have, they all look the same,
it's the electronic characteristics which changes amongst the 4 different types of LPT ports and
that's transparent to everyone. All LPT ports are female DB-25 connectors.
So what are the different LPT ports ?
Before we get stuck into the pinouts of the LPT port, let's have a look at the different types of
LPT ports available. Again, depending on the LPT port, you would expect different speed rates:
Because it might seem a bit confusing at the begining, I have include a bit more techincal
information on the various ports to help you understand more about them. To keep it simple, I
have categorised and colour coded them to show which ports match the table above:
4 bit ports
The port can do 8 bit byte output and 4 bit nibble input. These ports are often called
"unidirectional" and are most commonly found on desktop bus cards (also called IO expansion
cards, serial/parallel cards, or even 2S+P cards) and older laptops. This is still the most common
type of port, especially on desktop systems. 4 bit ports are capable of effective transfer rates of
about 40-60 KBytes per second in typical devices but can be pushed upwards of 140 KBytes/sec
with certain design tricks.
8 bit ports
These ports can do both 8 bit input and output and are sometimes called "bidirectional ports" but
that term is often misused by vendors to refer to 4 bit ports as well. Most newer laptops have 8 bit
capability although it may need to be enabled with the laptop's vendor-specific CMOS setup
function. This is discussed below. A relatively smaller percentage of LPT bus cards have 8bit
capability that sometimes must be enabled with a hardware jumper on the board itself. True 8 bit
ports are preferable to 4 bit ports because they are considerably faster when used with external
devices that take advantage of the 8 bit capability. 8 bit ports are capable of speeds ranging from
80-300 KBytes per second, again depending on the speed of the attached device, the quality of the
driver software and the port's electrical characteristics.
EPP ports
Can do both 8bit input and output at ISA bus speeds. These ports are as fast as 8 bit bus cards and
can achieve transfer rates upwards of 600 KByte per second. These ports are usually used by nonprinter peripheral devices such as external CDROMs, tape drives, hard drives, network adaptors
and more.
ECP ports
Can do both 8 bit input and output at bus speeds. The specification for this port type was jointly
developed by Microsoft and Hewlett-Packard. ECP ports are distinguished by having DMA
capability, on-board FIFOs at least 16 bytes deep, some hardware data compression capability
and are generally featured more than other ports. These ports are as fast as 8 bit bus cards and can
achieve transfer rates upwards of 1 Mbyte per second and faster on PCs whose buses will support
it. The design is capable of faster transfer rates in the future.
Laplink cable is used to link two PCs with MSDOS 6.0 or later very effectively by using
INTERSVR.EXE (on Host) and INTERLNK.EXE (on GUEST) PCs. But it can also be used to
data-transfer at faster speed with DCC Feature of Win9x/Me/2000.
Let's now have a quick look at the pinouts of an LPT port:
The Cable
As explained, there are different LPT ports, but the cable used is the same for all types of LPT
ports. Depending on your computer bios LPT settings you will be able to achieve different speed
transfers as outlined in the table above.
The picture below clearly shows the pinouts of the required cable:
One wire should be attached to the metal body of the Male pins on both sides, this is also shown
as the "metal body" on the diagram.
Now, because I understand how much trouble someone can fall into when trying to create a cable
and get it to work properly, I have included the DirectParallel Connection Monitor Utility, for all
the DCC users to troubleshoot and test DCC connection and cable on both computers. It provides
detailed information about the connection, the cable being used for the connection, the I/O mode
(4-bit, 8-bit, ECP, EPP), the parallel port types, I/O address, and IRQ.
And that pretty much finishes the discussion on Parallel Cable Connections !
USB Direct Cable Connection
Introduction
Serial and Parallel Direct Cable Connections are considered to be a bit "old fashioned" these
days. USB Direct Cable Connection (DCC), on the other hand, belongs in the "new fashioned"
category :) USB DCC is a few years old, but because most people would use their network card
to transfer data, the DCC hasn't been very well known for the USB port, but does exist.... and the
catch is that you can't make it, but you must buy it ! But don't be tempted to leave the page just as
yet, there is a lot of information on USB which is always good to know. Keep reading .... :)
Let's have a closer look and see what it's all about !
About USB
USB stands for Universal Serial Bus. Most peripherals for computers these days come in a USB
version. The USB port was designed to be very flexible and for this reason you are able to
connect printers, external hard drives, cdroms, joysticks, scanners, digital cameras, modems, hubs
and a lot of other cool stuff to it.
The Universal Serial Bus gives you a single, standardized, easy-to-use way to connect up to 127
devices to a computer. The 127 number is a theoretical number :) In practice it's a lot less ! The
devices you connect can even power through the USB port of your computer if they draw less
than 500mA, which is half an Ampere (I). A good example is my little Canon scanner, it only has
one cable which is used to power the scanner up and to transfer the data to the computer !
Currently there are 2 versions of the USB port, the initial version which is USB v1.1 and the
newer version USB v2 which has hit the market since the end of 2001. Most people have
computers and devices which use the first version, but all new computers will now come with
USB v2. This new version of the USB port is backwards compatible with the older version and
also a lot faster.
The table below compares the two USB ports so you can see the speed difference:
Keep in mind that when you're using a USB DCC cable, you won't get such great speeds, but
somewhere around the 500KBytes/sec. This also depends on the type of CPU, O/S, the quality of
the cable and electronic components and protocols running on your system.
Another thing which you should keep in mind is the Windows operating system that supports the
USB port:
The USB Cable
The USB standard uses A and B connectors to avoid confusion. "A" connectors head "upstream"
toward the computer, while "B" connectors head "downstream" and connect to individual
devices. This might seem confusing to some, but it was designed to avoid confusion between
consumers because it would be more complicated for most people to try and figure out which end
goes where.
And this is what the USB cable and connectors actually look like:
As mentioned earlier, the USB port can power certain devices and also transfer data at the same
time. For this to happen, the USB port must have at least 4 cables of which 2 are for the power,
and 2 for the data.
The diagram is to help you understand what the cable contains:
The USB DCC (Finally :) )
As I mentioned in the introduction of this page, the USB DCC cable cannot be made, because it
requires special electronic circuits built around the cable. Parallel Technologies manufacture USB
DCC cables and they call it the "NET-LinQ":
..........................
The USB DCC cable can also be used to connect a computer to your network. The way it works
is pretty simple. Assuming you have Computers A, B , C and D. Computer A, B and C are
connected via an Ethernet LAN and Computer D hasn't got a network card to connect to the
network. Using the NET-LinQ or other similar cables you can connect Computer D with any of
the other 3 computers as long as they have a USB port, then by configuring the network protocols
on Computer D, it will be able to see and connect to the rest of the network !
This completes the discusion about USB Direct Cable Connection.
Important Direct Cable Connection Notes
Important Points for DCC
This page was designed to provide some notes on Direct Cable Connection (File-transfer) of
Win9x/ME/2000 with LAPLINK (Printer port) Cable or Null-Modem (serial port) Cable.
I've successfully used Laplink cable to link two PCs for FILE TRANSFER only (not playing
Games), with WIN95 and Direct Cable Connection program using the NetBeui protocol on each
computer. You can quickly check to see if the protocol is installed by doubleclicking on the
"Network Section" in Control Panel of your Windows operating system.
In addition to the above, you must have installed "Client for Microsoft Networks", "File and
Printer Sharing for Microsoft Networks" and optionally the TCP/IP protocol, which will require
some configuration. Providing a simply IP Address and subnetmask will be enough for our
purposes, the rest of the fields can be ignored. If you would like to allow users to access your files
and printer, then ensure both the options in "File and Print Sharing" are selected.
Once you have completed the above steps, you should have the following listed in the "Network
Selection" window::




Client for Microsoft Networks
TCP/IP
Netbeui
File and Printer Sharing for Microsoft Networks
Once your changes are complete, Windows might prompt you to reboot the system, so make sure
all work is saved before answering "yes"!
You should also share the Disks on both computers by right-clicking on the selected disks
installed in your system and select the "Sharing" option that will appear in the menu. You can
access them via your "My Computer" icon on your desktop.
After you complete these actions, you will see a blue hand "holding" your shared drives,
indicating that the drive is shared with the rest of the network!
Introduction To Protocols
Introduction
In the networking and communications area, a protocol is the formal specification that defines the
procedures that must be followed when transmitting or receiving data. Protocols define the
format, timing, sequence, and error checking used on the network.
In plain english, the above means that if you have 2 or more devices e.g computers which want to
communicate, then they need a common "Protocol" which is a set of rules that guide the
computers on how and when to talk to each other.
The way this "defenition" happens in computer land is by the RFC's (Requests For Comments)
where the IETF (a group of enginners with no life) make up the new standards and protocols and
then the major vendors (IBM, Cisco, Microsoft, Novell) follow these standards and implement
them in their products to make more money and try to take over this world !
There are hundreads of protocols out there and it is impossible to list them all here, but instead we
have included some of the most popular protocols around so you can read up on them and learn
more about them.
The table below shows the most popular TCP/IP protocols. The OSI model is there for you to see
which layer each of these protocols work at.
One thing which you should keep in mind is that as you move from the lower layers (Physical) to
the upper layers (Applications), more processing time is needed by the device that's dealing with
the protocol.
Please note: All routing protocols can be found under the "Networking/Routing" menu option.
TCP/IP Protocol Stack ..................The OSI Model
...
Currently available protocols to read about are :










Internet Protocol (IP)
TCP
UDP
ICMP
DNS
FTP
TFTP
Ethernet
RIP
OSPF
Transmission Control Protocol (TCP) Introduction
Introduction
The Transmission Control Protocol, or TCP as we will refer to it from now on, is one of the most
important and well-known protocols in the world on networks today. Used in every type of
network world-wide, it enables millions of data transmissions to reach their destination and works
as a bridge, connecting hosts with one another and allowing them to use various programs in
order to exchange data.
The Need For Reliable Delivery
TCP is defined by RFC 793 and was introduced to the world towards the end of 1981. The
motivation behind creating such a protocol was the fact that back in the early 80s, computer
communication systems were playing a very important role for the military, education and normal
office environments. As such, there was the need to create a mechanism that would be robust,
reliable and complete data transmission on various mediums without great losses.
TCP was designed to be able to deliver all of the above, and so it was adopted promptly by the
rest of the world.
Because TCP is not the type of protocol you can analyse in one page, it has been separated and
analysed over 13 pages in order to cover all its characteristics and help you gain a better
understanding of how it works and what its capabilities are.
Section 1: TCP, A Transport Protocol. This page is a brief introduction to TCP. It will show you
how TCP fits into the OSI Model, by using simple diagrams. It also helps you understand the
concept of a "Transport Protocol".
Section 2: Quick TCP Overview. This page is aimed for readers requiring a good and quick
overview of the protocol's features without getting into too much technical detail.
Section 3: The TCP Header/Segment. Find out what the "TCP Header" and "TCP Segment" refer
to. These two terms are used quite often when talking about the protocol, thus it is essential we
understand what these two terms are related to.
Section 4: In-Depth TCP Analysis. This subsection is a whole topic in itself and deals with the indepth analysis of the TCP Header. We examine each field step-by-step, using plenty of examples
and our well known cool-3D diagrams to make sure you understand all the material. This analysis
is covered over 7 pages of hardcore information, so be prepared!
Section 4.1: TCP Analysis - [Section 1]: Source & Destination port number. Find out what ports
are and how they are used in a typical data transfer.
Section 4.2: TCP Analysis - [Section 2]: Sequence & Acknowledgement Numbers. At last,
everything you wanted to know about sequence and acknowledgment numbers. We will cover
them in much detail using plenty of diagrams to ensure you are not left with unanswered
questions.
Section 4.3: TCP Analysis - [Section 3]: Header Length. We examine the meaning of this field
and how it is calculated.
Section 4.4: TCP Analysis - [Section 4]: TCP Flag Options. This is one of the most important
pages in our in-depth analysis. Here you will learn what these flags are, how many flags the
protocol supports and lastly, how they are used. We will also examine how hackers can use
specific flags to gain vital information on remote systems.
Section 4.5: TCP Analysis - [Section 5]: Window Size, Checksum & Urgent Pointer. These fields
play one of the most important roles in bandwidth utilisation. Find out how you can increase data
throughput and minimise delays between WAN links by playing around with these fields! This
page is highly recommended for anyone seeking details about WAN link efficiency and data
throughput.
Section 4.6: TCP Analysis - [Section 6]: TCP Options. This page is considered to be an extension
to the previous one. Here you will learn about selective acknowledgments, window scalling and
several other options available to TCP that ensure data is handled the best possible way as it
transits to its destination.
Section 4.7: TCP Analysis - [Section 7]: Data. The reason for all of the above! Our last section
provides an overview of TCP protocol and concludes with several good notes.
You will surely agree that there is much to cover in this fantastic protocol. So, let us not loose
any more time and begin our cool analysis! If you need to grab any brain food, now's your
chance cause once we start .... there is no stopping till we're done!
TCP, A Transport Protocol
Introduction
Understanding how each protocol fits into the OSI Model is essential for any network engineer.
This page analyses how TCP is classified as a 'transport protocol' and gives you an insight into
what to expect from the protocol.
Fitting TCP into the OSI Model
As most of you are well aware, every protocol has its place within the OSI Model. The OSI
Model is an indication of the complexity and intelligence of the protocol. As a general rule, the
higher you move up the OSI Model, the more intelligent protocols become. The positioning of the
layer also reflects how CPU entensive they are, whereas the lower layers of the OSI Model are
quite the opposite, that is, less CPU intensive and less intelligent.
TCP is placed at the 4th layer of the OSI Model, which is also known as the transport layer. If
you have read through the OSI model pages, you will recall that the transport layer is responsible
for establishing sessions, data transfer and tearing down virtual connections.
With this in mind, you would expect any protocol that's placed in the transport layer to implement
certain features and characteristics that would allow it to support the functionality the layer
provides.
So as we analyse TCP, you will surely agree that it fits right into the transport layer.
The diagram below shows you where the TCP header is located within a frame that's been
generated by a computer and sent to the network. If you rotate it 90 degrees to your left, you
would get something similar to the previous diagram. This of course is because each layer
appends its own information, or header if you like:
The frame is made up of six 3d blocks so you can see which piece is added by every OSI layer.
You can see that the TCP Header containing all the options the protocol supports, is placed right
after the IP Header (Layer 3), and before the data section that contains upper layer information
(Layers 5,6,7).
Note: For those who are wondering about the presence of the FCS block at the end, it contains a
special checksum that is placed by the datalink layer in order to allow the receiving host to detect
if the current frame has been corrupt during transit.
Please refer to the Ethernet II Frame page for more information.
Where and why would we use the TCP ?
TCP is used in almost every type of network. As a protocol, it is not restricted to any type of
network topology, whether it be a local area network (LAN) or wide area network (WAN). Being
a transport protocol, we call it a transport protocol because it's located in the transport layer of the
OSI model its primary job is to get data from one location to another, regardless of the physical
network and location.
As most of you already know, there are two types of transport protocols, TCP being one of them
and UDP (User Datagram Protocol) being the other. The difference between these two transport
protocols is that TCP offers an extremely reliable and robust method of transferring data,
ensuring that the data being transferred does not become corrupt in any way. UDP, on the other
hand, offers a non reliable way of transferring data without being able to guarantee the data has
arrived to its destination or its integrity when it does arrive.
The concept of a transport protocol
As we mentioned, TCP is a transport protocol and this means it is used to transfer data of other
protocols. At first, this might sound weird or confusing but this is exactly why it was designed,
adding substantial functionality to the protocols it carries.
The diagram below is the simplest way to show the concept of a 'transport' protocol:
In the pages to follow, we will have a closer look at how TCP manages to provide its reliable data
transfer method and make sure packets get to their destination without errors. This whole process
is the work of many 'subsystems' within the TCP that work together to provide the reliability that
TCP gives us.
Before we dive in deeper though, let's have a quick overall view of the protocol. If you're not
interested in too much technical detail, then the next page is for you! For those looking for an indepth analysis, you should read the quick-overview page to give you an idea on what we will be
analysing soon.
Quick Overview Of The Transmission Control Protocol - TCP
Introduction
To assist in making this process as painless and understandable as possible, we are going to
provide a quick overview of the protocol and then start analysing each component-field in the
pages to come, using examples and the cool 3D diagrams you all love:)
As previously mentioned on a number of occasions, TCP is one of the two protocols that lives at
the Transport layer and is used to carry data from one host to another. What makes TCP so
popular is the way it works when sending and receiving data. Unlike UDP, TCP will check for
errors in every packet it receives in an endless struggle to avoid data corruption.
Some common protocols that use TCP are: FTP, Telnet, HTTP, HTTPS, DNS, SMTP and POP3.
Let's have a closer look at the main characteristics of this wonderful protocol.
When people refer to "TCP/IP" remember that they are talking about a suite of protocols and not
just one protocol, like most people think. TCP/IP is not one protocol. Please see the Protocols
section for more information.
Main Features
Here are the main features of the TCP that we are going to analyse:






Reliable Transport
Connection-Oriented
Flow Control
Windowing
Acknowledgements
More overhead
Reliable Transport
It's a reliable transport because of the different techniques it uses to ensure that the data received
is error free. TCP is a robust protocol used for file transfers where data error is not an option.
When you decide to download a 50MB file from a website, you wouldn't want to find out after
the download is complete that the file has an error! Even though, in reality, this does happen, it
just goes to show that you can't always be perfect with certain things.
This picture shows the TCP header within an ethernet II frame. Right below this you will find our
second diagram that zooms into to the TCP header, displaying the field the protocol contains:
The diagram on the left shows the individual breakdown of each field within the TCP header
along with its length in bits.
Remember that 8 bits equal to 1 byte.
The most popular fields within the TCP header are the Source Port, Destination Port and Code
bits. These Code bits are also known as 'flags'.
The rest of the fields help make sure all TCP segments make it to their destination and are
reassembled in the correct order, while at the same time providing an error free mechanism
should a few segments go missing and never reach their destination.
Keep in mind that in the pages to follow we will have a detailed look into each available field, for
now we are just providing an overview of them.
Connection Oriented
What this basically means is that a connection is established between the two hosts or rather, the
two computers, before any data is transferred. When the term "connection is established" is used,
this means that both computers know about each other and have agreed on the exchange of data.
This is also where the famous 3-way handshake happens. You will find the SYN and ACK bits in
the Code bits field which are used to perform the 3-way handshake. Thanks to the 3-way
handshake, TCP is connection oriented.
The following diagram explains the procedure of the 3-way handshake:
STEP 1: Host A sends the initial packet to Host B. This packet has the "SYN" bit enabled. Host
B receives the packet and sees the "SYN" bit which has a value of "1" (in binary, this means ON)
so it knows that Host A is trying to establish a connection with it.
STEP 2: Assuming Host B has enough resources, it sends a packet back to Host A and with the
"SYN and ACK" bits enabled (1). The SYN that Host B sends, at this step, means 'I want to
synchronise with you' and the ACK means 'I acknowledge your previous SYN request'.
STEP 3: So... after all that, Host A sends another packet to Host B and with the "ACK" bit set
(1), it effectively tells Host B 'Yes, I acknowledge your previous request'.
Once the 3-way handshake is complete, the connection is established (virtual circuit) and the data
transfer begins.
Flow Control
Flow control is used to control the data flow between the connection. If for any reason one of the
two hosts are unable to keep up with the data transfer, it is able to send special signals to the other
end, asking it to either stop or slow down so it can keep up.
For example, if Host B was a webserver from which people could download games, then
obviously Host A is not going to be the only computer downloading from this webserver, so Host
B must regulate the data flow to every computer downloading from it. This means it might turn to
Host A and tell it to wait for a while until more resources are available because it has another 20
users trying to download at the same time.
Below is a diagram that illustrates a simple flow control session between two hosts. At this point,
we only need to understand the concept of flow control:
Generally speaking, when a machine receives a flood of data too quickly for it to process, it stores
it in a memory section called a buffer. This buffering action solves the problem only if the data
bursts are small and don't last long.
However, if the data burst continues it will eventually exhaust the memory of the receiving end
and that will result in the arriving data being discarded. So in this situation the receiving end will
simply issue a "Not ready" or "Stop" indicator to the sender, or source of the flood. After the
receiver processes the data it has in its memory, it sends out a "Ready" or "Go" transport indicator
and the sending machine receives the "Go" indicator and resumes its transmission.
Windowing
Data throughput, or transfer efficiency, would be low if the transmitting machine had to wait for
an acknowledgment after sending each packet of data (the correct term is segment as we will see
on the next page). Because there is time available after the sender transmits the data segment and
before it finishes processing acknowledgments from the receiving machine, the sender uses the
break to transmit more data. If we wanted to briefly define Windowing we could do so by stating
that it is the number of data segments the transmitting machine is allowed to send without
receiving an acknowledgment for them.
Windowing controls how much information is transferred from one end to the other. While some
protocols quantify information by observing the number of packets, TCP/IP measures it by
counting the number of bytes.
Let's explain what is happening in the above diagram.
Host B is sending data to Host A, using a window size equal to one. This means that Host B is
expecting an "ACK" for each data segment it sends to Host A. Once the first data segment is sent,
Host A receives it and sends an "ACK 2" to Host B. You might be wondering why "ACK 2" and
not just "ACK"?
The "ACK 2" is translated by Host B to say: 'I acknowledge (ACK) the packet you just sent me
and I am ready to receive the second (2) segment'. So Host B gets the second data segment ready
and sends it off to Host A, expecting an "ACK 3" response from Host A so it can send the third
data segment for which, as the picture shows, it receives the "ACK 3".
However, if it received an "ACK 2" again, this would mean something went wrong with the
previous transmission and Host B will retransmit the lost segment. We will see how this works in
the Acknowledgments section later on. Let's now try a different Window size to get a better
understanding.. let's say 3!
Keep in mind the way the "ACK's" work, otherwise you might find the following example a bit
confusing. If you can't understand it, read the previous example again where the Window size
was equal to one.
In the above example, we have a window size equal to 3, which means that Host B can send 3
data segments to Host A before expecting an "ACK" back. Host B sends the first 3 segments
(Send 1, Send 2 and Send 3), Host A receives them all in good condition and then sends the
"ACK 4" to Host B. This means that Host A acknowledged the 3 data segments Host B sent and
awaits the next data segments which, in this case, would be 4, 5 and 6.
Acknowledgments
Reliable data delivery ensures the integrity of a stream of data sent from one machine to the other
through a fully functional data link. This guarantees the data won't be duplicated or lost. The
method that achieves this is known as positive acknowledgment with retransmission. This
technique requires a receiving machine to communicate with the transmitting source by sending
an acknowledgment message back to the sender when it receives data. The sender documents
each segment it sends and waits for this acknowledgment before sending the next segment. When
it sends a segment, the transmitting machine starts a timer and retransmits if it expires before an
acknowledgment is returned from the receiving end.
This figure shows how the Acknowledgments work. If you examine the diagram closely you will
see the window size of this transfer which is equal to 3. At first, Host B sends 3 data segments to
Host A and they are received in perfect condition so, based on what we learned, Host A sends an
"ACK 4" acknowledging the 3 data segments and requesting the next 3 data segments which will
be 4, 5, 6. As a result, Host B sends data segments 4, 5, 6 but 5 gets lost somewhere along the
way and Host A doesn't receive it so, after a bit of waiting, it realises that 5 got lost and sends an
"ACK 5" to Host B, indicating that it would like data segment 5 retransmitted. Now you see why
this method is called "positive acknowledgment with retransmission".
At this point Host B sends data segment 5 and waits for Host A to send an "ACK" so it can
continue sending the rest of the data. Host A receives the 5th data segment and sends "ACK 7"
which means 'I received the previous data segment, now please send me the next 3'. The next step
is not shown on the diagram but it would be Host B sending data segments 7, 8 and 9.
More Overhead
As you can see, there is quite a neat mechanism under the TCP hood that enables data to be
transferred error free. All the features the protocol supports come at a price, and this is the
overhead associated with TCP.
When we talk about overhead, we are referring to all the different fields contained within the TCP
header and error checking that takes place to ensure no portion of the data is corrupt. While for
most this is a fair trade off, some people simply can't spare the extra processing power, bandwidth
and increased time the TCP transactions require, for this reason we have the alternative UDP
protocol, which you can read about in the UDP protocol section.
At this point our quick overview of the TCP has reached its conclusion. From the next page
onwards, we start to dive in deeper, so take a deep breath and jump right into it!
The TCP Header/Segment
Introduction
This page will introduce several new concepts, nothing of great difficulty, but essential for you to
understand. We will learn what a TCP segment is, analyse it and start to explore the guts of TCP
:)
So buckle up and get ready. It's all really simple, you just need to clear your mind and try to see
things in the simplest form and you will discover how easy and friendly TCP really is. You can
only feel comfortable with something once you get to know it.
TCP Header and TCP Segment
If we wanted to be more accurate with the terms we use, then perhaps we would title this page as
"Analysing A TCP Segment". Why? Well, that's what it's called in the networking world so we
need to know it by the correct term.
This of course leads us to another new definition, a TCP segment:
The unit of transfer between the TCP software on to machines is called a TCP segment.
If your expression has transformed itself to resemble a confused person, then don't worry, just
keep reading...
Understanding this term is easier than you thought 5 seconds ago, just take a good look at the
diagram below:
Now you see that a TCP segment is basically the TCP header plus the data that's right behind it
and, of course, the data belongs to the upper layers (5,6,7).
The data contents could be part of a file transfer, or the response from a http request, the fact is
that we really are not interested in the data's contents, but only in the fact that it's part of the TCP
segment.
The screen shot below was taken from my packet sniffer, and it shows the DATA portion
belonging to the TCP Header:
If you tried to capture a similar packet from any packet sniffer, it is more likely to display the
Data portion within the TCP header, just as the screen shot on the left.
So the question is whether a TCP header and a TCP segment are basically the same thing.
Even though it might seem they are, in most cases, when referring to the TCP header, we are
talking about the header without the data, whereas a TCP segment includes the data.
Getting Ready To Analyse The TCP Header
We are now ready to begin examining the structure of the TCP header. However, be sure to keep
in mind that the 'TCP Header' is the same thing as a 'TCP Segment', meaning it's the TCP header
information plus the Data, just as the diagrams above show.
The last screen shot certainly gives out a fair bit of information, but there is still much that hasn't
been revealed, not to mention nothing's really been analysed as yet :)
Analysing The TCP Header
Introduction
A fair amount of time was spent trying to figure out which way to analyse the TCP header. Most
websites and other resources mention the protocol's main characteristics with a bit of information
attached, leaving the reader with a lot of questions and making it difficult to comprehend how
certain aspects of the protocol works.
For this reason a different approach was selected. Our method certainly gets right into the
protocol's guts and contains a lot of information which some of you might choose to skip, but it is
guaranteed to satisfy you by giving a thorough understanding of what is going on.
Get Ready.... Here It Comes!
For those who skipped the first introduction page of the protocol, you will be happy to find out
that the tcp quick-overview page contains a brief summary of the protocol's main characteristics
to help refresh your memory. If you need to dive into the details at any point, simply return to this
page!
The diagram below shows the TCP header captured from a packet that I was running on the
network. We'll be using it to help us through our step by step analysis of TCP.
As you can see, the TCP header has been completely expanded to show us all the fields the
protocol contains. The numbers on the right are each field's length in bits. This is also shown in
the quick TCP overview page.
Since much time was spent to ensure our analysis was complete in all aspects, be sure that by the
end of it, you will understand each field's purpose and how it works.
We should also point out that when the packet in our example arrives to its destination, only
section 7 (the last one) is sent to the upper OSI layers because it contains the data it is waiting for.
The rest of the information (including the MAC header, IP Header and TCP header) is overhead
which serves the purpose of getting the packet to its destination and allowing the receiving end to
figure out what to do with the packet, e.g. send the data to the correct local application.
Now you're starting to understand the somewhat complex mechanisim involved in determing how
data gets from one point to another!
Since you have made it this far, you can select the section you want to read about by simply
clicking on the coloured area on the above packet, or by using the menu below. It is highly
recommended that you start from the first section and slowly progress to the final one. This will
avoid confusion and limit the case of you scratching your head halfway through any of the other
sections:







Section 1: Source & Destination Port Number
Section 2: Sequence & Acknowledgement Numbers
Section 3: Header Length
Section 4: TCP Flag Options
Section 5: Window Size, Checksum & Urgent Pointer
Section 6: TCP Options
Section 7: Data
TCP Analysis - Section 1: Source & Destination port number
Introduction
This section contains one of the most well-known fields in the TCP header, the Source and
Destination port numbers. These fields are used to specify the application or services offered on
local or remote hosts.
You will come to understand how important ports are and how they can be used to gain
information on remote systems that have been targetted for attacks. We will cover basic and
advanced port communications using detailed examples and colourful diagrams, but for now, we
will start with some basics to help break down the topic and allow us to smoothly progress in to
more advanced and complex information.
When a host needs to generate a request or send data, it requires some information:
1) IP Address of the desired host to which it wants to send the data or request.
2) Port number to which the data or request should be sent to on the remote host. In the case of a
request, it allows the sender to specify the service it is intending to use. We will analyse this soon.
1) The IP Address is used to uniquely identify the desired host we need to contact. This
information is not shown in the above packet because it exists in the IP header section located
right above the TCP header we are analysing. If we were to expand the IP header, we would
(certainly) find the source and destination IP Address fields in there.
2) The 2nd important aspect, the port number, allows us to identify the service or application our
data or request must be sent to, as we have previously stated. When a host, whether it be a simple
computer or a dedicated server, offers various services such as http, ftp, telnet, all clients
connecting to it must use a port number to choose which particular service they would like to use.
The best way to understand the concept is through examples and there are plenty of them below,
so let's take a look at a few, starting from a simple one and then moving towards something
slightly more complicated.
Time To Dive Deeper!
Let's consider your web browser for a moment.
When you send a http request to download a webpage, it must be sent to the correct web server in
order for it to receive it, process it and allow you to view the page you want. This is achieved by
obtaining the correct IP address via DNS resolution and sending the request to the correct port
number at the remote machine (web server). The port value, in the case of an http request, is
usually 80.
Once your request arrives at the web server, it will check that the packet is indeed for itself. This
is done by observing the destination IP Address of the newly received packet. Keep in mind that
this particular step is a function of the Network layer.
Once it verifies that the packet is in fact for the local machine, it will process the packet and see
that the destination port number is equal to 80. It then realises it should send the data (or request)
to the http deamon that's waiting in the background to serve clients:
Using this neat method we are able to use the rest of the services offered by the server. So, to use
the FTP service, our workstation generates a packet that is directed to the server's IP address, that
is 200.0.0.1, but this time with a destination port of 21.
The diagram that follows illustrates this process:
By now you should understand the purpose of the destination port and how it allows us to select
the services we require from hosts that offer them.
For those who noticed, our captured packet at the beginning of this page also shows the existence
of another port, the source port, which we are going to take a look at below.
Understanding the Source Port
The source port serves analogues to the destination port, but is used by the sending host to help
keep track of new incoming connections and existing data streams.
As most of you are well aware, in TCP/UDP data communications, a host will always provide a
destination and source port number. We have already analysed the destination port, and how it
allows the host to select the service it requires. The source port is provided to the remote
machine, in the case of our example, this is the Internet Server, in order for it to reply to the
correct session initiated by the other side.
This is achieved by reversing the destination and source ports. When the host (in our example,
Host A) receives this packet, it will identify the packet as a reply to the previous packet it sent:
As Host A receives the Internet Server's reply, the Transport layer will notice the reversed ports
and recognise it as a response to the previous packet it sent (the one with the green arrow).
The Transport and Session layers keep track of all new connections, established connections and
connections that are in the process of being torn down, which explains how Host A remembers
that it's expecting a reply from the Internet Server.
Of course the captured packet that's displayed at the beginning of the page shows different port
numbers than the ones in these diagrams. In that particular case, the workstation sends a request
to its local http proxy server that runs on port 8080, using port 3025 as its source port.
We should also note that TCP uses a few more mechanisms to accurately keep track of these
connections. The pages to follow will analyse them as well, so don't worry about missing out on
any information, just grab some brain food (hhmmm chocolate...), sit back, relax and continue
reading!
TCP Analysis - Section 2: Sequence & Acknowledgement Numbers
Introduction
This page will closely examine the Sequence and Acknowledgement numbers. The very purpose
of their existence is related directly to the fact that the Internet, and generally most networks, are
packet switched (we will explain shortly) and because we nearly always send and receive data
that is larger than the maximum transmission unit (a.k.a MTU - analysed on sections 5 and 6 )
which is 1500 on most networks.
Let's take a look at the fields we are about to analyse:
As you can see, the Sequence number proceeds the Acknowledgement number.
We are going to explain how these numbers increment and what they mean, how various
operating systems handle them in a different manner and lastly, what way these numbers can
become a security hazard for those who require a solid secure network.
TCP - Connection Oriented Protocol
The Sequence and Acknowledgement fields are two of the many features that help us classify
TCP as a connection oriented protocol. As such, when data is sent through a TCP connection,
they help the remote hosts keep track of the connection and ensure that no packet has been lost on
the way to its destination.
TCP utilizes positive acknowledgments, timeouts and retransmissions to ensure error-free,
sequenced delivery of user data. If the retransmission timer expires before an acknowledgment is
received, data is retransmitted starting at the byte after the last acknowledged byte in the stream.
A further point worth mentioning is the fact that Sequence numbers are generated differently on
each operating system. Using special algorithims (and sometimes weak ones), an operating
system will generate these numbers, which are used to track the packets sent or received, and
since both Sequence and Acknowledgement fields are 32bit, there are 2^32= 4,294,967,296
possibilities of generating a different number!
Initial Sequence Number (ISN)
When two hosts need to transfer data using the TCP transport protocol, a new connection is
created. This involves the first host that wishes to initiate the connection, to generate what is
called an Initial Sequence Number (ISN), which is basically the first sequence number that's
contained in the Sequence field we are looking at. The ISN has always been the subject of
security issues, as it seems to be a favourite way for hackers to 'hijack' TCP connections.
Believe it or not, hijacking a new TCP connection is something an experienced hacker can
alarmingly achieve with very few attempts. The root of this security problem starts with the way
the ISN is generated.
Every operating system uses its own algorithm to generate an ISN for every new connection, so
all a hacker needs to do is figure out, or rather predict, which algorithm is used by the specific
operating system, generate the next predicted sequence number and place it inside a packet that is
sent to the other end. If the attacker is successful, the receiving end is fooled and thinks the packet
is a valid one coming from the host that initiated the connection.
At the same time, the attacker will launch a flood attack to the host that initiated the TCP
connection, keeping it busy so it won't send any packets to the remote host with which it tried to
initiate the connection.
Here is a brief illustration of the above-mentioned attack:
As described, the hacker must find the ISN algorithm by sampling the Initial Sequence Numbers
used in all new connections by Host A. Once this is complete and the hacker knows the algorithm
and they are ready to initiate their attack:
Timing is critical for the hacker, so he sends his first fake packet to the Internet Banking Server
while at the same time starts flooding Host A with garbage data in order to consume the host's
bandwidth and resources. By doing so, Host A is unable to cope with the data it's receiving and
will not send any packets to the Internet Banking Server.
The fake packet sent to the Internet Banking Server will contain valid headers, meaning it will
seem like it originated from Host A's IP Address and will be sent to the correct port the Internet
Banking Server is listening to.
There have been numerous reports published online that talk about the method each operating
system uses to generate its ISN and how easy or difficult it is to predict. Do not be alarmed to
discover that the Windows operating system's ISN algorithm is by far the easiest to predict!
Programs such as 'nmap' will actually test to see how difficult it can be to discover the ISN
algorithm used in any operating system. In most cases, hackers will first sample TCP ISN's from
the host victim, looking for patterns in the initial sequence numbers chosen by TCP
implementations when responding to a connection request. Once a pattern is found it's only a
matter of minutes for connections initiated by the host to be hijacked.
Example of Sequence and Acknowledgment Numbers
To help us understand how these newly introduced fields are used to track a connection's packets,
an example is given below.
Before we proceed, we should note that you will come across the terms "ACK flag" or "SYN
flag"; these terms should not be confused with the Sequence and Acknowledgment numbers as
they are different fields within the TCP header. The screen shot below is to help you understand:
You can see the Sequence number and Acknowledgement number fields, followed by the TCP
Flags to which we're referring.
The TCP Flags (light purple section) will be covered on the pages to come in much greater depth,
but because we need to work with them now to help us examine how the Sequence and
Acknowledgement numbers work, we are forced to analyse a small portion of them.
To keep things simple, remember that when talking about Sequence and Acknowledgement
numbers we are referring to the blue section, while SYN and ACK flags refer to the light purple
section.
The next diagram shows the establishment of a new connection to a web server - the Gateway
Server. The first three packets are part of the 3-way handshake performed by TCP before any data
is transferred between the two hosts, while the small screen shot under the diagram is captured by
our packet sniffer:
To make sure we understand what is happening here, we will analyse the example step by step.
Step 1
Host A wishes to download a webpage from the Gateway Server. This requires a new connection
between the two to be established so Host A sends a packet to the Gateway Server. This packet
has the SYN flag set and also contains the ISN generated by Host A's operating system, that is
1293906975. Since Host A is initiating the connection and hasn't received a reply from the
Gateway Server, the Acknowledgment number is set to zero (0).
In short, Host A is telling the Gateway Server the following: "I'd like to initiate a new connection
with you. My Sequence number is 1293906975".
Step 2
The Gateway Server receives Host A's request and generates a reply containing its own generated
ISN, that is 3455719727, and the next Sequence number it is expecting from Host A which is
1293906976. The Server also has the SYN & ACK flags set, acknowledging the previous packet
it received and informing Host A of its own Sequence number.
In short, the Gateway Server is telling Host A the following: "I acknowledge your sequence
number and expecting your next packet with sequence number 1293906976. My sequence
number is 3455719727".
Step 3
Host A receives the reply and now knows Gateway's sequence number. It generates another
packet to complete the connection. This packet has the ACK flag set and also contains the
sequence number that it expects the Gateway Server to use next, that is 3455719728.
In short, Host A is telling the Gateway Server the following: "I acknowledge your last packet.
This packet's sequence number is 1293906976, which is what you're expecting. I'll also be
expecting the next packet you send me to have a sequence number of 3455719728".
Now, someone might be expecting the next packet to be sent from the Gateway Server, but this is
not the case. You might recall that Host A initiated the connection because it wanted to download
a web page from the Gateway Server. Since the 3-way TCP handshake has been completed, a
virtual connection between the two now exists and the Gateway Server is ready to listen to Host
A's request.
With this in mind, it's now time for Host A to ask for the webpage it wanted, which brings us to
step number 4.
Step 4
In this step, Host A generates a packet with some data and sends it to the Gateway Server. The
data tells the Gateway Server which webpage it would like sent.
Note that the sequence number of the segment in line 4 is the same as in line 3 because the ACK
does not occupy sequence number space.
So keep in mind that any packets generated, which are simply acknowledgments (in other words,
have only the ACK flag set and contain no data) to previously received packets, never increment
the sequence number.
Last Notes
There are other important roles that the Sequence and Acknowledgement numbers have during
the communication of two hosts. Because segments (or packets) travel in IP datagrams, they can
be lost or delivered out of order, so the receiver uses the sequence numbers to reorder the
segments. The receiver collects the data from arriving segments and reconstructs an exact copy of
the stream being sent.
If we have a closer look at the diagram above, we notice that the TCP Acknowledgement number
specifies the sequence number of the next segment expected by the receiver. Simply scroll back
to Step 2 and you will see what I mean.
Summary
This page has introduced the Sequence and Acknowledgement fields within the TCP header. We
have seen how hackers hijack connections by discovering the algorithms used to produce the
ISNs and we examined step by step the way Sequence and Acknowledgement numbers increase.
The next page examines the TCP header length field, so take a quick break if it's required and let's
continue!
TCP Analysis - Section 3: Header Length
Introduction
The third field under close examination is the TCP Header length. There really isn't that much to
say about the Header length other than to explain what it represents and how to interpret its
values, but this alone is very important as you will soon see.
Let's take a quick look at this field, noting its location within the TCP structure:
You might also have seen the Header length represented as "Data offset" in other packet sniffers
or applications, this is virtually the same as the Header length, only with a 'fancier' name.
Analysing the Header length
If you open any networking book that covers the TCP header, you will almost certainly find the
following description for this particular field:
"An interger that specifies the length of the segment header measured in 32-bit multiples"
(Internetworking with TCP/IP, Douglas E. Comer, p. 204, 1995). This description sounds
impressive, but when you look at the packet, you're most likely to scratch your head thinking:
what exactly did that mean?
Well, you can cease being confused because we are going to cover it step by step, giving answers
to all possible questions you might have. If we don't cover your questions completely, well...
there are always our forums to turn to!
Step 1 - What portion is the "Header length" ?
Before we dive into analysing the meaning of the values used in this field, which by the way
changes with every packet, we need to understand which portion on the packet is the "Header
length".
Looking at the screen shot on the left, the light blue highlighted section shows us the section
that's counted towards the Header length value. With this in mind, you can see that the total
length of the light blue section (header length) is 28 bytes.
The Header length field is required because of the TCP Options field, which contains various
options that might or might not be used. Logically, if no options are used then the header length
will be much smaller.
If you take a look at our example, you will notice the 'TCP Options' is equal to 'yes', meaning
there are options in this field that are used in this particular connection. We've expanded the
section to show the TCP options used and these are 'Max Segment' and 'SACK OK'. These will be
analysed in the pages which follow, at the present time though we are interested in whether the
TCP options are used or not.
As the packet in our screenshot reaches the receiving end, the receiver will read the header length
field and know exactly where the data portion starts.
This data will be carried to the layers above, while the TCP header will be stripped and
disregarded. In this example, we have no data, which is normal since the packet is initiating a 3way handshake (Flags, SYN=1), but we will cover that in more depth on the next page.
The main issue requiring our attention deals with the values used for the header length field and
learning how to interpret them correctly.
Step 2 - Header Value Analysis
From the screen shot above, we can see our packet sniffer indicating that the field has a value of
7(hex) and this is interpreted as 28 bytes. To calculate this, you take the value of 7, multiply it by
32 and divide the result by 8: 7x32=224/8=28 bytes.
Do you recall the definition given at the beginning of this page? "An interger that specifies the
length of the segment header measured in 32-bit multiples". This was the formal way of
describing these calculations :)
The calculation given is automatically performed by our packet sniffer, which is quite thoughtful,
wouldn't you agree? This can be considered, if you like, as an additional 'feature' found on most
serious packet sniffers.
Below you will find another screen shot from our packet sniffer that shows a portion of the TCP
header (left frame) containing the header length field. On the right frame, the packet sniffer
shows the packet's contents in hex:
By selecting the Header length field on the left, the program automatically highlights the
corresponding section and hex value on the right frame. According to the packet sniffer, the hex
value '70' is the value for the header length field.
If you recall at the beginning of the page, we mentioned the header length field being 4 bits long.
This means that when viewing the value in hex, we should only have one digit or character
highlighted, but this isn't the case here because the packet sniffer has incorrectly highlighted the
'7' and '0' together, giving us the impression that the field is 8 bits long!
Note: In hex, each character e.g '7' represents 4 bits. This means that on the right frame, only '7'
should be highlighted, and not "70". Furthermore, if we were to convert '7' hex to binary, the
result would be '0111' (notice the total amount of bits is equal to 4).
Summary
The 'Header length' field is very simple as it contains only a number that allows the receiving end
to calculate the number of bytes in the TCP Header. At the same time, it is mandatory because
without it there is no way the receiver will know where the data portion begins!
Logically, wherever the TCP header ends, the data begins - this is clear in the screen shots
provided on this page. So, if you find yourself analysing packets and trying to figure out where
the data starts, all you need to do is find the TCP Header, read the "Header length" value and you
can find exactly where the data portion starts!
Next up are the TCP flags that most of us have come across when talking about the famous 3-way
handshake and virtual connections TCP creates before exchanging data.
TCP Analysis - Section 4: TCP Flag Options
Introduction
As we have seen in the previous pages, some TCP segments carry data while others are simple
acknowledgements for previously received data. The popular 3-way handshake utilises the SYNs
and ACKs available in the TCP to help complete the connection before data is transferred.
Our conclusion is that each TCP segment has a purpose, and this is determined with the help of
the TCP flag options, allowing the sender or receiver to specify which flags should be used so the
segment is handled correctly by the other end.
Let's take a look at the TCP flags field to begin our analysis:
You can see the 2 flags that are used during the 3-way handshake (SYN, ACK) and data transfers.
As with all flags, a value of '1' means that a particular flag is 'set' or, if you like, is 'on'. In this
example, only the "SYN" flag is set, indicating that this is the first segment of a new TCP
connection.
In addition to this, each flag is one bit long, and since there are 6 flags, this makes the Flags
section 6 bits in total.
You would have to agree that the most popular flags are the "SYN", "ACK" and "FIN", used to
establish connections, acknowledge successful segment transfers and, lastly, terminate
connections. While the rest of the flags are not as well known, their role and purpose makes them,
in some cases, equally important.
We will begin our analysis by examining all six flags, starting from the top, that is, the Urgent
Pointer:
1st Flag - Urgent Pointer
The first flag is the Urgent Pointer flag, as shown in the previous screen shot. This flag is used to
identify incoming data as 'urgent'. Such incoming segments do not have to wait until the previous
segments are consumed by the receiving end but are sent directly and processed immediately.
An Urgent Pointer could be used during a stream of data transfer where a host is sending data to
an application running on a remote machine. If a problem appears, the host machine needs to
abort the data transfer and stop the data processing on the other end. Under normal circumstances,
the abort signal will be sent and queued at the remote machine until all previously sent data is
processed, however, in this case, we need the abort signal to be processed immediately.
By setting the abort signal's segment Urgent Pointer flag to '1', the remote machine will not wait
till all queued data is processed and then execute the abort. Instead, it will give that specific
segment priority, processing it immediately and stopping all further data processing.
If you're finding it hard to understand, consider this real-life example:
At your local post office, hundreds of trucks are unloading bags of letters from all over the world.
Because the amount of trucks entering the post office building are abundant, they line up one
behind the other, waiting for their turn to unload their bags.
As a result, the queue ends up being quite long. However, a truck with a big red flag suddenly
joins the queue and the security officer, whose job it is to make sure no truck skips the queue,
sees the red flag and knows it's carrying very important letters that need to get to their destination
urgently. By following the normal procedures, the security officer signals to the truck to skip the
queue and go all the way up to the front, giving it priority over the other the trucks.
In this example, the trucks represent the segments that arrive at their destination and are queued
in the buffer waiting to be processed, while the truck with the red flag is the segment with the
Urgent Pointer flag set.
A further point to note is the existence of theUrgent Pointer field. This field is covered in section
5, but we can briefly mention that when the Urgent Pointer flag is set to '1' (that's the one we are
analysing here), then the Urgent Pointer field specifies the position in the segment where urgent
data ends.
2nd Flag - ACKnowledgement
The ACKnowledgement flag is used to acknowledge the successful receipt of packets.
If you run a packet sniffer while transferring data using the TCP, you will notice that, in most
cases, for every packet you send or receive, an ACKnowledgement follows. So if you received a
packet from a remote host, then your workstation will most probably send one back with the
ACK field set to "1".
In some cases where the sender requires one ACKnowledgement for every 3 packets sent, the
receiving end will send the ACK expected once (the 3rd sequential packet is received). This is
also called Windowing and is covered extensively in the pages that follow.
3rd Flag - PUSH
The Push flag, like the Urgent flag, exists to ensure that the data is given the priority (that it
deserves) and is processed at the sending or receiving end. This particular flag is used quite
frequently at the beginning and end of a data transfer, affecting the way the data is handled at
both ends.
When developers create new applications, they must make sure they follow specific guidelines
given by the RFC's to ensure that their applications work properly and manage the flow of data in
and out of the application layer of the OSI model flawlessly. When used, the Push bit makes sure
the data segment is handled correctly and given the appropriate priority at both ends of a virtual
connection.
When a host sends its data, it is temporarily queued in the TCP buffer, a special area in the
memory, until the segment has reached a certain size and is then sent to the receiver. This design
guarantees that the data transfer is as efficient as possible, without waisting time and bandwidth
by creating multiple segments, but combining them into one or more larger ones.
When the segment arrives at the receiving end, it is placed in the TCP incoming buffer before it is
passed onto the application layer. The data queued in the incoming buffer will remain there until
the other segments arrive and, once this is complete, the data is passed to the application layer
that's waiting for it.
While this procedure works well in most cases, there are a lot of instances where this 'queueing'
of data is undesirable because any delay during queuing can cause problems to the waiting
application. A simple example would be a TCP stream, e.g real player, where data must be sent
and processed (by the receiver) immediately to ensure a smooth stream without any cut offs.
A final point to mention here is that the Push flag is usually set on the last segment of a file to
prevent buffer deadlocks. It is also seen when used to send HTTP or other types of requests
through a proxy - ensuring the request is handled appropriately and effectively.
4th Flag - Reset (RST) Flag
The reset flag is used when a segment arrives that is not intended for the current connection. In
other words, if you were to send a packet to a host in order to establish a connection, and there
was no such service waiting to answer at the remote host, then the host would automatically reject
your request and then send you a reply with the RST flag set. This indicates that the remote host
has reset the connection.
While this might prove very simple and logical, the truth is that in most cases this 'feature' is used
by most hackers in order to scan hosts for 'open' ports. All modern port scanners are able to detect
'open' or 'listening' ports thanks to the 'reset' function.
The method used to detect these ports is very simple: When attempting to scan a remote host, a
valid TCP segment is constructed with the SYN flag set (1) and sent to the target host. If there is
no service listening for incoming connections on the specific port, then the remote host will reply
with ACK and RST flag set (1). If, on the other hand, there is a service listening on the port, the
remote host will construct a TCP segment with the ACK flag set (1). This is, of course, part of the
standard 3-way handshake we have covered.
Once the host scanning for open ports receives this segment, it will complete the 3-way
handshake and then terminate it using the FIN (see below) flag, and mark the specific port as
"active".
5th Flag - SYNchronisation Flag
The fifth flag contained in the TCP Flag options is perhaps the most well know flag used in TCP
communications. As you might be aware, the SYN flag is initialy sent when establishing the
classical 3-way handshake between two hosts:
In the above diagram, Host A needs to download data from Host B using TCP as its transport
protocol. The protocol requires the 3-way handshake to take place so a virtual connection can be
established by both ends in order to exchange data.
During the 3-way handshake we are able to count a total of 2 SYN flags transmitted, one by each
host. As files are exchanged and new connections created, we will see more SYN flags being sent
and received.
6th Flag - FIN Flag
The final flag available is the FIN flag, standing for the word FINished. This flag is used to tear
down the virtual connections created using the previous flag (SYN), so because of this reason, the
FIN flag always appears when the last packets are exchanged between a connection.
It is important to note that when a host sends a FIN flag to close a connection, it may continue to
receive data until the remote host has also closed the connection, although this occurs only under
certain circumstances. Once the connection is teared down by both sides, the buffers set aside on
each end for the connection are released.
A normal teardown procedure is depicted below:
The above diagram represents an existing connection betwen Host A and B, where the two hosts
are exchanging data. Once the data transfer is complete, Host A sends a packet with the FIN,
ACK flags set (STEP 1).
With this packet, Host A is ACKnowledging the previous stream while at the same time initiating
the TCP close procedure to kill this connection. At this point, Host A's application will stop
receiving any data and will close the connection from this side.
In response to Host A's request to close the connection, Host B will send an ACKnowledgement
(STEP 2) back, and also notify its application that the connection is no longer available. Once this
is complete, the host (B) will send its own FIN, ACK flags (STEP 3) to close their part of the
connection.
If you're wondering why this procedure is required, then you may need to recall that TCP is a Full
Duplex connection, meaning that there are two directions of data flow. In our example this is the
connection flow from Host A to Host B and vice versa. In addition, it requires both hosts to close
the connection from their side, hence the reason behind the fact that both hosts must send a FIN
flag and the other host must ACKnowledge it.
Lastly, at Step 4, Host A willl acknowledge the request Host B sent at STEP 3 and the closedown
procedure for both sides is now complete!
Summary
This page dealt with the TCP Flag Options available to make life either more difficult, or easy,
depending on how you look at the picture :)
Perhaps the most important information given on this page that is beneficial to remember is the
TCP handshake procedure and the fact that TCP is a Full Duplex connection.
The following section will examine the TCP Window size, Checksum and Urgent Pointer fields,
all of which are relevant and very important. For this reason we strongly suggest you read
through these topics, rather than skip over them.
TCP Analysis - Section 5: Window Size, Checksum & Urgent Pointer
Introduction
Our fifth section contains some very interesting fields that are used by the TCP transport protocol.
We see how TCP helps control how much data is transferred per segment, make sure there are no
errors in the segment and, lastly, flag our data as urgent, to ensure it gets the priority it requires
when leaving the sender and arriving at the recipient.
So let's not waste any time and get right into our analysis!
The fifth section we are analysing here occupies a total of 6 bytes in the TCP header. These
values, like most of the fields in the protocol's header, remain constant in size, regardless of the
amount of application data.
This means that while the values they contain will change, the total amount of space the field
occupied will not.
The Window Flag
The Window size is considered to be one of the most important flags within the TCP header. This
field is used by the receiver to indicate to the sender the amount of data that it is able to accept.
Regardless of who the sender or receiver is, the field will always exist and be used.
You will notice that the largest portion of this page is dedicated to the Window size field. The
reason behind this is because this field is of great importance. The Window size field is the key to
efficient data transfers and flow control. It trully is amazing once you start to realise how
important this flag is and how many functions it contains.
The Window size field uses 'bytes' as a metric. So in our example above, the number 64,240 is
equal to 64,240 bytes, or 62.7 kb (64,240/1024).
The 62.7 kbytes reflects the amount of data the receiver is able to accept, before transmitting to
the sender (the server) a new Window value. When the amount of data transmitted is equal to the
current Window value, the sender will expect a new Window value from the receiver, along with
an acknowledgement for the Window just received.
The above process is required in order to maintain flawless data transmission and high efficiency.
We should however note that the Window size field selected is not in any case just a random
value, but one calculated using special formulas like the one in our example below:
In this example, Host A is connected to a Web server via a 10 Mbit link. According to our
formula, to calculate the best Window value we need the following information: Bandwidth and
Delay. We are aware of the link's bandwidth: 10,000,000 bits (10 Mbits), and we can easily find
out the delay by issuing a 'ping' from Host A to the Web server which gives us an average Round
Trip Time response (RTT) of 10 milliseconds or 0.01 seconds.
We are then able to use this information to calculate the most efficient Window size (WS):
WS = 10,000,000 x 0.01 => WS = 100,000 bits or (100,000/8)/1024 = 12,5 kbytes
For 10 Mbps bandwidth and a round-trip delay of 0.01 sec, this gives a window size of about 12
kb or nine 1460-byte segments:
This should yield maximum throughput on a 10 Mbps LAN, even if the delay is as high as 10 ms
because most LANs have round-trip delay of less than a few milliseconds. When bandwidth is
lower, more delay can be tolerated for the same fixed window size, so a window size of 12 kb
works well at lower speeds, too.
Windowing - A Form of Flow Control
Apart from the Windowing concept being a key factor for efficient data transmission, it is also a
form of flow control, where a host (the receiver) is able to indicate to the other (the sender) how
much data it can accept and then wait for further instructions.
The fact is that in almost all cases, the default value of 62 kbytes is used as a Window size. In
addition, even though a Window size of 62 kbytes might have been selected by the receiver, the
link is constantly monitored for packet losses and delays during the data transfer by both hosts,
resulting in small increases or decreases of the original Window size in order to optimise the
bandwidth utilisation and data throughput.
This automatic self-correcting mechanisim ensures that the two hosts will try to make use of the
pipe linking them in the best possible way, but do keep in mind that this is not a guarantee that
they will always succeed. This is generally the reason why a user is able to manually modify the
Window size until the best value is found and this, as we explained, depends greatly on the link
between the hosts and its delay.
In the case where the Window size falls to zero, the remote TCP can send no more data. It must
wait until buffer space becomes available and it receives a packet announcing a non-zero Window
size.
Lastly, for those who deal with Cisco routers, you might be interested to know that you are able
to configure the Window size on Cisco routers running the Cisco IOS v9 and greater. Routers
with versions 12.2(8)T and above support Window Scaling, a feature that's automatically enabled
for Window sizes above 65,535, with a maximum value of 1,073,741,823 bytes!
Window Scalling will be dealt with in greater depth on the following page.
On the Server Side: Larger Window Size = More Memory
Most network administrators who have worked with very busy web servers would recall the
massive amounts of memory they require. Since we now understand the concept of a 'Window
size', we are able to quickly analyse how it affects busy web servers that have thousands of clients
connecting to them and requesting data.
When a client connects to a web server, the server is required to reserve a small amount of
memory (RAM) aside for the client's session. The amount of required memory is the same
amount as the window size and, as we have seen, this value depends on the bandwidth and delay
between the client and server.
To give you an idea how the window size affects the server's requirements in memory, let's take
an example:
If you had a web server that served 10,000 clients on a local area network (LAN) running at 100
Mbits with a 0.1 second round trip delay and wanted maximum performance/efficiency for your
file transfers, according to our formula, you would need to allocate a window of 1.25 MB for
each client, or 12 Gigs of memory for all your clients! Assuming of course that all 10,000 clients
are connected to your web server simultaneously.
To support large file transfers in both directions (server to client and vice versa), your server
would need: [(100,000,000 x 0.1) 10,000 x 2] = over 24 Gigs of memory just for the socket
buffers!
So you can see how important it is for clients not to use oversized window values! In fact, the
current TCP standard requires that the receiver must be capable of accepting a full window's
worth of data at all times. If the receiver over-subscribes its buffer space, it may have to drop an
incoming packet. The sender will discover this packet loss and invoke TCP congestion control
mechanisms even though the network is not congested.
It is clear that receivers should not over-subscribe buffer space (window size) if they wish to
maintain high performance and avoid packet loss.
Checksum Flag
The TCP Checksum field was created to ensure that the data contained in the TCP segment
reaches the correct destination and is error-free. For those network gurus who are wondering how
TCP would ensure the segment arrives to the correct destination (IP Address), you will be happy
to know that there is a little bit more information used than just the TCP header to calculate the
checksum and, naturally, it would include a portion of the IP Header.
This 'extra' piece of information is called the pseudo-header and we will shortly analyse its
contents but, for now, let's view a visual representation of the sections used to calculate the TCP
checksum:
The above diagram shows you the pseudo header, followed by the TCP header and the data this
segment contains. However, once again, be sure to remember that the pseudo header is included
in the Checksum calculation to ensure the segment has arrived at the correct receiver.
Let's now take a look how the receiver is able to verify it is the right receiver for the segment it
just received by analysing the pseudo header.
The Pseudo Header
The pseudo header is a combination of 5 different fields, used during the calculation of the TCP
checksum. It is important to note (and remember!) that the pseudo header is not transmitted to the
receiver, but is simply involved in the checksum calculation.
Here are the 5 fields as they are defined by the TCP RFC:
When the segment arrives at its destination and is processed through the OSI layers, once the
transport layer (Layer 4) is reached, the receiver will recreate the pseudo header in order to
recalculate the TCP header checksum and compare the result with the value stored in the segment
it has received.
If we assume the segment somehow managed to find its way to a wrong machine, when the
pseudo header is recreated, the wrong IP Address will be inserted into the Destination IP Address
field and the result will be an incorrect calculated checksum. Therefore, the receiver that wasn't
supposed to receive the segment will drop it as it's obviously not meant to be there.
Now you know how the checksum field guarantees that the correct host will receive the packet, or
that it will get there without any errors!
However, be sure to keep in mind that even though these mechanisms exist and work wonderfully
in theory, when it comes to the practical part, there is a possibility that packets with errors might
make their way through to the application!
It's quite amazing once you sit down and think for a minute that this process happens for every
single packet that is sent and received between hosts that use TCP and UDP (UDP calculates the
same way its checksum) as their transport protocol!
Lastly, during the TCP header checksum calculation, the field is set to zero (0) as shown below.
This action is performed only during the checksum calculation on either end because it is
unknown at the time. Once the value is calculated, it is then inserted into the field, replacing the
inital zero (0) value.
This is also illustrated in the screen shot below:
In summarising the procedure followed when calculating the checksum, the following process
occurs, from the sender all the way to the receiver:
The sender prepares the segment that is to be sent to the receiving end. The checksum is set to
zero, in fact 4 zeros (hex) or 8 zeros (0000 0000) if you look at it in binary, because the checksum
is an 8 bit field.
The checksum in then calculated using the pseudo header, TCP header and lastly the data to be
attached to the specific segment. The result is then stored in the checksum field and the segment
is sent!
The segment arrives at the receiver and is processed. When it reaches the 4th OSI layer where the
TCP lives, the checksum field is set once again to zero. The receiver will then create its own
pseudo header for the segment received by entering its own IP Address in the Destination IP
Address field (as shown in the previous diagrams) and makes use of the TCP header and data to
calculate the new checksum.
If all is successfully accomplished, the result should be identical with the one the checksum field
segment had when it arrived. When this occurs, the packet is then further processed and the data
is handed to the application awaiting it.
If, however, the checksum is different, then the packet should be discarded (dropped) and a
notification will be sent to the receiver depending on how the TCP stack is implemented on the
receiver's operating system.
The Urgent Pointer
In section 4, we analysed the TCP Flag options and amongst them we found the Urgent Pointer
flag. The urgent pointer flag in the TCP Flag allows us to mark a segment of data as 'urgent',
while this urgent pointer field specifies where exactly the urgent data ends.
To help you understand this, take a look at the following diagram:
You may also be interested to know that the Urgent Pointer can also be used when attacking
remote hosts. From the case studies we have analysed, we see that certain applications, which
supposedly guard your system from attack attempts, do not properly log attacks when the URG
flag is set. One particular application happens to be the famous BlackIce Server v2.9, so beware!
As a final conclusion this section, if you find yourself capturing thousands of packets in order to
view one with the URG bit set, don't be disappointed if you are unable to catch any such packets!
We found it nearly impossible to get our workstation to generate such packets using telnet, http,
ftp and other protocols. The best option and by far the easiest way would be to look for packet
crafting programs that allow you to create packets with different flags and options set.
Summary
While this section was a fairly extensive, we have covered some very important sections of the
TCP protocol. You now know what a TCP Window is and how you can calculate it depending on
your bandwidth and delay.
We also examined the Checksum field, which is used by the receiver to verify the segment it
received is not corrupt and at the same time checking to make sure it didn't receive the segment
accidently!
Lastly, we examined in great detail the usage of the URG flag and Urgent Pointer field, which are
used to define an incoming segment that contains urgent data.
After enjoying such a thorough analysis, we're sure you're ready for more! The next section deals
with the TCP Options located at the end of the TCP header.
TCP Analysis - Section 6: TCP Options
Introduction
The TCP Options are located at the end of the TCP Header which is also why they are covered
last. Thanks to the TCP Options field we have been able to enhance the TCP protocol by
introducing new features or 'addons' as some people like to call them, defined by their respective
RFC's.
As data communication continues to become more complex and less tolerable to errors and
latency, it was clear that these new features had to be incorporated to the TCP transport to help
overcome the problems created by the new links and speeds available.
To give you an example, Window Scaling, mentioned in the previous pages and elaborated here,
is possible using the TCP Options field because the original Window field is only 16 bits long,
allowing a maximum decimal number of 65,535. Clearly this is far too small when we want to
express 'Window size' values using numbers in the range of thousands to a million e.g 400,000 or
950,000.
Before we delve into any details, let's take a look at the TCP Options field:
As you can see, the TCP Options field is the sixth section of the TCP Header analysis.
Located at the end of the header and right before the Data section, it allows us to make use of the
new enhancements recommended by the engineers who help design the protocols we use in data
communications today.
TCP Options
Most of the TCP Options we will be analysing are required to appear only during the initial SYN
and SYN/ACK phase of the 3-way-handshake TCP performs to establish a virtual link before
transferring any data. Other options, however, can be used at will, during the TCP session.
It is also important to note that the TCP Options may occupy space at the end of the TCP header
and are a multiple of 8 bits in length. This means that if we use one TCP Option that is 4 bits in
length, there must be another 4 bits of padding in order to comply with the TCP RFC. So the TCP
Options length MUST be in multiples of 8 bits, that is 8, 16, 24, 32 e.t.c
Here's a brief view of the TCP Options we are going to analyse:





Maximum Segment Size (MSS)
Window Scaling
Selective Acknowledgements (SACK)
Timestamps
Nop
Let's now take a look at the exciting options available and explain the purpose of each one.
Maximum Segment Size (MSS)
The Maximum Segment Size is used to define the maximum segment that will be used during a
connection between two hosts. As such, you should only see this option used during the SYN and
SYN/ACK phase of the 3-way-handshake. The MSS TCP Option occupies 4 bytes (32 bits) of
length.
If you have previously come across the term "MTU" which stands for Maximum Transfer Unit,
you will be pleased to know that the MSS helps define the MTU used on the network.
If your scratching your head because the MSS and MTU field doesn't make any sense to you, or it
is not quite clear, don't worry, the following diagram will help you get the big picture:
You can see the Maximum Segment Size consists of the TCP Header and Data, while the
Maximum Transfer Unit includes the MSS plus the IP Header.
It would also benefit us to recognise the correct terminology that corresponds to each level of the
OSI Model: The TCP Header and Data is called a Segment (Layer 4), while the IP Header and the
Segment is called an IP Datagram (Layer 3).
Furthermore, regardless of the size the MTU will have, there is an additional 18 bytes overhead
placed by the Datalink layer. This overhead includes the Source and Destination MAC Address,
the Protocol type, followed by the Frame Check Sequence placed at the end of the frame.
This is also the reason why we can only have a maximum MTU of 1500 bytes. Since the
maximum size of an Ethernet II frame is 1518 bytes, subtracting 18 bytes (Datalink overhead)
leaves us with 1500 bytes to play with.
TCP usually computes the Maximum Segment Size (MSS) that results in IP Datagrams that
match the network MTU. In practice, this means the MSS will have such a value that if we add
the IP Header as well, the IP Datagram (IP Header+TCP Header+DATA) would be equal to the
network MTU.
If the MSS option is omitted by one or both ends of the connection, then the value of 536 bytes
will be used. The MSS value of 536 bytes is defined by RFC 1122 and is calculated by taking the
default value of an IP Datagram, 576 bytes, minus the standard length of the IP and TCP Header
(40 bytes), which gives us 536 bytes.
In general, it is very important to use the best possible MSS value for your network because your
network performance could be extremely poor if this value is too large or too small. To help you
understand why, lets look at a simple example:
If you wanted to transfer 1 byte of data through the network, you would need to create a datagram
with 40 bytes of overhead, 20 for the IP Header and 20 for the TCP Header. This means that your
using 1/41 of your available network bandwidth for data. The rest is nothing but overhead!
On the other hand, if the MSS is very large, your IP Datagrams will also be very large, meaning
that they will most probably fail to fit into one packet should the MTU be too small. Therefore
they will require to be fragmented, increasing the overhead by a factor of 2.
Window Scaling
We briefly mentioned Window Scaling in the previous section of the TCP analysis, though you
will soon discover that this topic is quite broad and requires a great deal of attention.
After gaining a sound understanding of what the Window size flag is used for, Window Scaling
is, in essence, an extention to the Window size flag. Because the largest possible value in the
Window size flag is only 65,535 bytes (64 kb), it was clear that a larger field was required in
order to increase the value to a whopping 1 Gig! Thus, Window Scaling was born.
The Window Scaling option can be a maximum of 30 bits in size, which includes the original 16
bit Window size field covered in the previous section. So that's 16 (original window field) + 14
(TCP Options 'Window Scaling') = 30 bits in total.
If you're wondering where on earth would someone use such an extremely large Window size,
think again. Window Scaling was created for high-latency, high-bandwidth WAN links where a
limited Window size can cause severe performance problems.
To consolidate all these technological terms and numbers, an example would prove to beneficial:
The above example assumes we are using the maximum Window size of 64 kbs and because the
WAN link has very high latency, the packets take some time to arrive to their destination, that is,
Host B. Due to the high latency, Host A has stopped transmitting data since there are 64 kbs of
data sent and they have not yet been acknowledged.
When the Time = 4, Host B has received the data and sends the long awaited acknowledgement
to Host A so it can continue to send data, but the acknowledgement will not arrive until
somewhere around Time = 6.
So, from Time = 1 up until Time = 6, Host A is sitting and waiting. You can imagine how poor
the performance of this transfer would be in this situation. If we were to transfer a 10 Mb file, it
would take hours!
Let's now consider the same example, using Window Scaling:
As you can see, with the use of Window Scaling, the window size has increased to256 kb! Since
the value is quite large, which translates to more data during transit, Host B has already received
the first few packets, while Host A is still sending the first 256 kb window.
On Time = 2, Host B sends an Acknowledgement to Host A, which is still busy sending data.
Host A will receive the Acknowledgement before it finishes the 256 kb window and will
therefore continue sending data without pause since it will soon receive another
Acknowledgement from Host B.
Clearly the difference that a large window size has made is evident, increasing the network
performance and minimising the ideal time for the sending host.
The Window Scale option is defined in RFC 1072, which lets a system advertise 30-bit (16 from
the original window + 14 from the TCP Options) Window size values, with a maximum buffer
size of 1 GB. This option has been clarified and redefined in RFC 1323, which is the specification
that all implementations employ today.
Lastly, for those who deal with Cisco routers, it may benefit you to know that you are also able to
configure the Window size on Cisco routers running the Cisco IOS v9 and greater. Also, routers
with versions 12.2(8)T and above support Window Scaling, which is automatically enabled for
Window sizes above 65,535 bytes (64 kb), with a maximum value of 1,073,741,823 bytes (1
GByte)!
Selective Acknowledgments (SACK)
TCP has been designed to be a fairly robust protocol though, despite this, it still has several
disadvantages, one of which concerns Acknowledgements, which also happens to be the reason
Selective Acknowledgement were introduced with RFC 1072.
The problem with the good old plain Acknowledgements is that there are no mechanisms for a
receiver to state "I'm still waiting for bytes 20 through 25, but have received bytes 30 through
35". And if your wondering whether this is possible, then the answer is 'yes' it is!
If segments arrive out of order and there is a hole in the receiver's queue, then using the 'classical'
Acknowledgements supported by TCP, can only say "I've received everything up to byte 20". The
sender then needs to recognise that something has gone wrong and continue sending from that
point onwards (byte 20).
As you may have concluded, the above situation is totally unacceptable, so a more robust service
had to be created, hence Selective Acknowledgments!
Firstly, when a virtual connection is established using the classic 3-way-handshake the hosts must
send a "Selective Acknowledgments Permitted" in the TCP Options to indicate that they are able
to use SACK's. From this point onwards, the SACK option is sent whenever a selective
acknowledgment is required.
For example, if we have a Windows98 client that is waiting for byte 4,268, but the SACK option
shows that the Windows98 client has also received bytes 7,080 through 8,486, it is obvious that it
is missing bytes 4,268 through 7,079, so the server should only resend the missing 2,810 bytes,
rather than restarting the entire transfer at byte number 4,268.
Lastly, we should note that the SACK field in the TCP Options uses two 16 bit fields, a total of
32 bits together. The reason there are two fields is because the receiver must be able to specify
the range of bytes it has received, just like the example we used. In the case where Window
Scaling is also used, these 2 x 16 bit fields can be expanded to two 24 or 32 bit fields.
Timestamps
Another aspect of TCP's flow-control and reliability services is the round-trip delivery times that
a virtual circuit is experiencing. The round-trip delivery time will accurately determine how long
TCP will wait before attempting to retransmit a segment that has not been acknowledged.
Because every network has unique latency characteristics, TCP has to understand these
characteristics in order to set accurate acknowledgment timer threshold values. LANs typically
have very low latency times, and as such TCP can use low values for the acknowledgment timers.
If a segment is not acknowledged quickly, a sender can retransmit the questionable data quickly,
thus minimizing any lost bandwidth and delay.
On the other hand, using a low threshold value on a WAN is sure to cause problems simply
because the acknowledgment timers will expire before the data ever reaches the destination.
Therefore, in order for TCP to accurately set the timer threshold value for a virtual circuit, it has
to measure the round-trip delivery times for various segments. Finally, it has to monitor
additional segments throughout the connection's lifetime to keep up with the changes in the
network. This is where the Timestamp option comes into the picture.
Similarly to the majority of the other TCP Options covered here, the Timestamp option must be
sent during the 3-way-handshake in order to enable its use during any subsequent segments.
The Timestamp field consists of a Timestamp Echo and Timestamp Reply field, both of which
the reply field is always set to zero by the sender and completed by the receiver after which it is
sent back to the original sender. Both timestamp fields are 4 bytes long!
Nop
The nop TCP Option means "No Option" and is used to separate the different options used within
the TCP Option field. The implementation of the nop field depends on the operating system used.
For example, if options MSS and SACK are used, Windows XP will usually place two nop's
between them, as was indicated in the first picture on this page.
Lastly, we should note that the nop option occupies 1 byte. In our example at the beggining of the
page, it would occupy 2 bytes since it's used twice. You should also be aware that this field is
usually checked by hackers when trying to determine the remote host's operating system.
Summary
This page provided all the available TCP Options that have been introduced to the TCP protocol
in its efforts to extend its reliability and performance. While these options are critical in some
cases, most users are totally unaware of their existence, especially network administrators. The
information provided here is essential to help administrators deal with odd local and wan network
problems that can't be solved by rebooting a server or router :)
The final page to this topic is a summary covering the previous six pages of TCP, as there is little
to analyse in the data section of the TCP Segment. It is highly suggested you read it as a recap to
help you remember the material covered.
TCP Analysis - Section 7: Data & Quick Summary
Introduction
Finally, the last page of our incredible TCP Analysis. As most of you would expect, this section is
dedicated to the DATA, which is also the reason all the previous pages exist!
The Data
The following diagram may have been tiresome, however, it will be displayed one final time to
note the data portion of the packet:
Your knowledge regarding the procedure followed when the above packet arrives to its
destination is assumed. However, a summary is given below to refresh our understanding in order
to avoid confusion.
When the above packet arrives at the receiver, a decapsulation process is required in order to
remove each OSI layer's overhead and pass the Data portion to the application that's waiting for
it. As such, when the packet is received in full by the network card, it is given to the 2nd OSI
layer (Datalink) which, after performing a quick check on the packet for errors, it will strip the
overhead associated with that layer, meaning the yellow blocks will be removed.
The remaining portion, that is, the IP header, TCP header and Data, now called an IP Datagram,
will be passed to the 3rd OSI layer (Network) where another check will be performed and if
found to be error free, the IP header will be stripped and the rest (now called a Segment) is passed
to the 4th OSI layer.
The TCP protocol (4th OSI layer) will accept the segment and perform its own error check on the
segment. Assuming it is found error free, the TCP header is stripped off and remaining data is
given to the upper layers eventually arriving at the application waiting for it.
Summary
Our in-depth analysis of the the TCP protocol has reached its conclusion. After reading all these
pages, we are sure you have a much better understanding regarding the TCP protocol's purpose
and process, and you are able to really appreciate its functions.
We hope you have enjoyed our analysis and we're sure you will be back for more!
User Datagram Protocol - UDP
Some common protocols which use UDP are: DNS, TFTP, ARP, RARP and SNMP.
When people refer to "TCP/IP" remember that they are talking about a suite of protocols, and not
just one (as most people think). TCP/IP is NOT one protocol. Please see the Protocols section for
more information.
The User Datagram Protocol (UDP) is defined by IETF RFC768
UDP - User Datagram Protocol
The second protocol used at the Transport layer is UDP. Application developers can use UDP in
place of TCP. UDP is the scaled-down economy model and is considered a thin protocol. Like a
thin person in a car, a thin protocol doesn't take up a lot of room - or in this case, much bandwidth
on a network.
UDP as mentioned dosen't offer all the bells and whistles of TCP, but it does a fabulous job of
transporting information that doesn't require reliable delivery and it does so using far fewer
network resources.
Unreliable Transport
UDP is considered to be an unreliable transport protocol. When UDP sends segments over a
network, it just sends them and forgets about them. It doesn't follow through, check on them, or
even allow for an acknowledgment of safe arrival, in other words .... complete abandonment!
This does not mean that UDP is ineffective, only that it doesn't handle issues of reliability.
The picture below shows us the UDP header within a data packet. This is to show you the
different fields a UDP header contains:
Connection-less Oriented
For those who read about TCP, you would know it is a connection oriented protocol, but UDP
isn't. This is because UDP doesn't create a virtual circuit (establish a connection before data
transfer), nor does it contact the destination before delivering information to it. No 3-way
handshake or anything like that here!
Since UDP assumes that the application will use its own reliability method, it doesn't use any,
which obviously makes things transfer faster.
Less Overhead
The very low overhead, compared to TCP, is a result of the lack of windowing or
acknowledgments. This certainly speeds things up but you get an unreliable (in comparison to
TCP) service. There really isn't much more to write about UDP so I'll finish here.
Domain Name System (DNS) Introduction
Introduction
DNS is a very well known protocol. It is used for resolving host names and domain names to IP
addresses. The fact is that when you type www.firewall.cx it is translated into an IP address via
special queries that take place from your PC, but I'll explain how that works later on.
Because there is a fair bit of material to cover for the DNS protocol, and I don't want to confuse
you with too much information on one page, I have broken it down into 5 sections, each covering
a specific part of the protocol.
People who want specific information on the DNS protocol can go straight to the section they
need, the rest of us who just want to learn it all can start reading in the order presented:
Section 1: The DNS Protocol. How and why the DNS protocol was born. Page contains a bit of
historical information and also compares DNS with the OSI Reference model, where you will see
the layers on which DNS works. Internet DNS hierarchy is also analysed here, giving you the
chance to understand how domains on the Internet are structured.
Section 2: The DNS Resolution Process. What really happens when a host requests a DNS
resolution. Full analysis of the whole resolution process using a real life example. Understand
Name Servers and the role they play in the DNS system.
Section 3: The DNS Query Message Format. This section, along with the next one gives you the
DNS packet format in all its glory. Learn how DNS queries are generated and formatted. See,
learn and understand the various fields within the packets as your taken through a full detailed
analysis of the packet structure using the cool 3D diagrams.
Section 4: The DNS Response Message Format. This is the continuation of the section above,
dealing with the DNS response that's received. You will learn how the response packet is
generated, formatted and sent to the resolver. Again, you're taken through a full detailed analysis
of the packet structure using the cool 3D diagrams.
Section 5: The DNS Server (BIND). Based on BIND for Linux, this section is broken into a
futher 6 pages:

Section 5.1: Introduction to the DNS Server. Learn how a DNS server is setup on a Linux
machine. Over 85% of DNS servers on the Internet run on Linux and Unix based systems
while Microsoft and Novell DNS servers follow the same structure. DNS Zones and
Domains are also covered on this page, this is essential for understanding how DNS
Servers work.

Section 5.2: The db.DOMAIN file. Complete analysis of the zone data file for a Primary
DNS server. See what is contains and understand how its structured.

Section 5.3: The db.ADDR file. Complete analysis of the zone data file for a Primary
DNS server. See what is contains and understand how its structured.

Section 5.4: Other common files. Analysing the rest of the files which are common to all
DNS servers.

Section 5.5: Slave DNS Server. Instructions on setting up a secondary DNS server.

Section 5.6: DNS Caching. The key to an efficient DNS server. This is a must for any
DNS Administrator. Learn how DNS caching helps improve performance and reduce
traffic. Includes analysis of specific parameters within the DNS packet, which helps make
DNS caching a reality, and find out how to avoid problems that come with Domain
redelegation or website transfers.
As you can see, there's plenty of stuff to cover. But don't despair because is all cool stuff ! Grab
something to drink and let's dive into the DNS waters ! You will be amazed at the stuff you'll find
:)
The DNS Protocol
Introduction
If you ever wondered where DNS came from, this is your chance to find out ! The quick
summary on DNS's history will also help you understand why DNS servers are run mostly on
Linux and Unix-type systems. We then get to see the layers of the OSI Model on which DNS
works and, towards the end of the page, you will find out how the Domains (and DNS servers)
are structured on the Internet to ensure uptime and effectiveness.
The History
DNS began in the early days when the Internet was only a small network created by the
Department of Defence for research purposes. Host names (simple computer names) of
computers were manually entered into a file (called HOSTS) which was located on a central
server. Each site/computer that needed to resolve host names had to download this file. But as the
number of hosts grew, so did the HOSTS file (Linux, Unix, Windows and NetWare still use such
files) until it was far too large for computers to download and it was generating great amounts of
traffic ! So they thought ... Stuff this .. let's find a better solution ... and in 1984 the Domain Name
System was introduced.
The Protocol
The Domain Name System is a 'hierarchically distributed database', which is a fancy way of
saying that its layers are arranged in a definite order and that its data is distributed across a wide
range of machines (just like the roots of a tree branch out from the main root).
Most companies today have their own little DNS server to ensure the computers can find each
other without problems. If you're using Windows 2000 and Active Directory, then you surely are
using DNS for the name resolutions of your computers. Microsoft has created its own version of a
"DNS" server, called a WINS server, which stands for Windows Internet Name Service, but this
is old technology and uses protocols that are nowhere near as efficient as DNS, so it was natural
for Microsoft to move away from WINS and towards DNS, after all, the whole Internet works on
DNS :)
The DNS protocol works when your computer sends out a DNS query to a name server to resolve
a domain. For example, you type "www.firewall.cx" in your web browser, this triggers a DNS
request, which your computer sends to a DNS server in order to get the website's IP Address !
There is a detailed example on the pages to follow so I won't get into too much detail for the
moment.
The DNS protocol normally uses the UDP protocol as a means of transport because of its small
overhead in comparison to TCP; the less overhead a protocol has, the faster it is !
In the case where there are constant errors and the computer trying to request a DNS resolution
can't get an error free answer, or any answer at all, it will switch to TCP to ensure the data arrives
without errors.
This process, though, depends on the operating system you're using. Some operating systems
might not allow DNS to use the TCP protocol, thus limiting it to UDP only. It is rare that you will
get so many errors that you can't resolve any hostname or domain name to an IP Address.
The DNS protocol utilises Port 53 for its service. This means that a DNS server listens on Port 53
and expects any client wishing to use the service to use the same port. There are, however, cases
where you might need to use a different port, something possible depending on the operating
system and DNS server you are running.
In the following pages we'll be looking at the actual DNS packet format, where you are able to
see exactly the contents of DNS query, so we won't analyse the packet structure here.
Next we'll take a close look at how the Internet domains and DNS servers are structured to make
sure the model works flawlessly and efficiently !
The Internet Domain Name Server Hierarchy
This interesting section will help you understand how domain names on the Internet are
structured and where DNS servers fit in to the picture. When you think about the millions of
domain names registered today, you probably think that you have to be superhuman to manage
such a structure of DNS servers !
Well that's not that case. The DNS structure has been designed in such a way that no DNS server
needs to know about all possible domains, but only those immediately above and below it.
The picture below shows part of the Internet DNS hierarchical structure:
.......
Let's explain how it works :
Internic controls the "root" domain, which includes all the top level domains. These are marked in
a green oval for clarity. Within the green oval you have the ROOT DNS servers, which know all
about the authoritative DNS servers for the domains immediately below them e.g firewall.cx,
cisco.com, microsoft.com etc. These ROOT DNS servers can tell you which DNS server takes
care of firewall.cx, cisco.com, microsoft.com and the rest.
Each domain, including the ones we are talking about (cisco, firewall, microsoft), have what we
call a "Primary DNS" and "Secondary DNS". The Primary DNS is the one that holds all the
information about its domain. The Secondary acts as a backup in case the Primary DNS fails. The
process in which a Primary DNS server sends its copy to the Secondary DNS server is called
Zone Transfer and is covered in the DNS Database section.
Today there are hundreds of websites at which you are able to register your own domain and,
once you've done that, you have the power to manage it yourself. In the example above, Cisco
bought the "Cisco.com" domain and then created your resource records. Some examples of
resource records for the Cisco domain in our example are: support , www and routers. These will
be analysed in depth on the next pages.
So here comes the million dollar question :)
How do you create subdomains and www's (known as resouce records) ?
The answer is pretty simple:
You use a special DNS administration interface (usually web based - provided by the guys with
whom you registered your domain) that allows you to create, change and delete the subdomains,
www's or whatever resource record you can come up with. When you're making changes to the
DNS settings of your domain, you're actually changing the contents of specific files that are
located on that server.
These changes then slowly propagate to the authoritative DNS servers, which are responsible for
your domain area and then the whole Internet will contact these DNS servers when they need to
access any section of your domain.
For example, if you need to resolve ftp.firewall.cx, your computer will locate and contact the
DNS Server responsible for the .CX domains, which will let you know the DNS server that's in
charge of the Firewall.cx domain. The DNS server of Firewall.cx in turn will let your computer
know the IP Address of ftp.firewall.cx because it holds all the information for the firewall.cx
domain.
That completes our first section. It's not that hard after all!
DNS Resolution Process
Introduction
This section will help you understand how the DNS queries work on the Internet and your home
network. There are two ways to use the domain name system in order to resolve a host or domain
name to an IP Address and we're going to look at them here. There is also a detailed example
later on this page to help you understand it better.
Queries and Resolution
As mentioned in the introduction section, there are two ways for a client to use the domain name
system to get an answer.
One of these involves the client contacting the name servers (this is also called a non Recursive
query) one at a time until it finds the authority server that contains the information it requires,
while the other way is to ask the name server system to perform the complete translation (this is
also called a Recursive query), in which case the client will send the query and get a response that
contains the IP Address of the domain it's looking for.
It's really exciting to see how DNS queries work. While analysing with you the packets that are
sent and received from the DNS server, I'm going to show you how the client chooses the method
by which it wants its query to be resolved, so you will truly understand how these cool features
work ! The DNS Query/Response Message Format pages contain all this packet analysis
information, so let's continue and prepare for it !
Our Example DNS Resolution
We will now look at what happens when your workstation requests a domain to be resolved. The
example that follows will show you the whole procedure step by step, so make sure you take your
time to read it and understand it !
When someone wants to visit the Cisco website (www.cisco.com), they go to their web browser
and type "http://www.cisco.com" or just "www.cisco.com" and, after a few seconds, the website
is displayed. But what happens in the background after they type the address and hit enter is
pretty much unknown to most users. That's what we are going to find out now !
The picture below shows us what would happen in the above example: (for simplicity we are not
illustrating both Primary and Secondary DNS servers, only the Primary)
Explanation :
1. You open your web browser and enter www.cisco.com in the address field. At that point, the
computer doesn't know the IP address for www.cisco.com, so it sends a DNS query to your ISP's
DNS server (It's querying the ISP's DNS because this has been set through the dial-up properties;
if you're on a permanent connection then it's set through your network card's TCP/IP properties).
2. Your ISP's DNS server doesn't know the IP for www.cisco.com, so it will ask one of the
ROOT DNS servers.
3. The ROOT DNS server checks its database and finds that the Primary DNS for Cisco.com is
198.133.219.25. It replies to your ISP's server with that answer.
4. Your ISP's DNS server now knows where to contact Cisco's DNS server and find out if
www.cisco.com exists and its IP. Your ISP's DNS server sends a recursive query to Cisco.com's
DNS server and asks for an IP address for www.cisco.com.
5. Cisco's DNS server checks its database and finds an entry for "www.cisco.com". This entry has
an IP address of 198.133.219.25. In other words, the webserver is running on the same physical
server as the DNS ! If it wasn't running on the same server, then it would have a different IP. (Just
a note, you can actually make it look like it's on the same physical server, but actually run the
web server on a different box. This is achieved by using some neat tricks like port forwarding)
6. Your ISP's DNS server now knows the IP address for www.cisco.com and sends the result to
your computer.
7. Your computer now knows who it needs to contact to get to the website. So it sends an http
request directly to Cisco's webserver and downloads the webpage.
I hope you didn't find it too hard to follow. Remember that this query is the most common type.
The other type of query (non recursive) follows the same procedure, the difference is that the
client does all the running around trying to find the authoritative DNS server for the desired
domain, I like to think of it as "self service" :)
DNS Query Message Format
Introduction
This section will deal with the analysis of the DNS packets. This will allow us to see the way
DNS messages are formatted and the options and variables they contain. To understand a
protocol, you must understand the information the protocol carries from one host to another.
Because the DNS message format can vary, depending on the query and the answer, I've broken
this analysis into two parts. Part 1 analyses the DNS format of a query, in other words, it shows
how the packet looks when we ask a DNS server to resolve a domain. Part 2 analyses the DNS
format of an answer, where the DNS server is responding to our query.
I find this method more informative and easy to understand rather than combining the analysis of
queries and answers.
DNS Analysis - Host Query
As mentioned in the previous sections of the DNS Protocol, a DNS query is generated when the
client needs to resolve a domain name into an IP Address. This could be the result of entering
"www.firewall.cx" in the url field of your web browser, or simply by launching a program that
uses the Internet and therefore generates DNS queries in order to successfully communicate with
the host or server it needs.
Now, I've also included a live example (using my packet analyser), so you can compare theory
with practice for a better understanding. After this we will have a look at the meaning of each
field in the packet, so let's check out what a packet containing a DNS query would look like on
our network:
This is the captured packet we are going to deal with. To generate this packet, I typed "ping
www.firewall.cx" from my linux prompt. The command generated this packet, which was put on
my network with the destination being a name server in Australia. Notice the Port Destination
which is set to 53, on which the port DNS works, and the protocol used for the DNS Query,
which is UDP.
Ethernet II (Check Ethernet Frames for more info.) is the most common type of frame found on
LANs, in fact it probably is the only type you will find on 85% of all networks if you're only
running TCP/IP and Windows or Unix-like machines. This particular one contains a DNS section,
which could be either a Query or Response. We are assuming a Query, so it can fit nicely in our
example.
We are going to take the DNS Section above and analyse its contents, which are already shown in
the picture above (Right hand side, labeled "Capture") taken from my packet analyser.
Here they are again in a cool 3D diagram:
From this whole packet, the DNS Query Section is the part we're interested in (analysed shortly),
the rest is more or less overhead and information to let the server know a bit more information
about our query.
The analysis of each 3D block (field) is shown in the left picture below so you can understand the
function of each field and the DNS Query Section captured by my wonderful packet sniffer on the
right:
All fields in the DNS Query section except the DNS Name field (underlined in red in the picture
above), have set lengths. The DNS Name field has no set length because it varies depending on
the domain name length as we are going to see soon.
For example, a query for www.cisco.com will require DNS Name field to be smaller than a query
for support.novell.com simply because the second domain is longer.
The DNS Name Field
To prove this I captured a few packets that show different lengths for the domain names I just
mentioned but, because the DNS section in a packet provides no length field, we need to look one
level above, which is the UDP header, in order to calculate the DNS section length. By
subtracting the UDP header length (always 8 bytes - check UDP page for more information) from
the bytes in the Length field, we are left with the length of the DNS section:
The two examples clearly show that the Length Field in the UDP header varies depending on the
domain we are trying to resolve. The UDP header is 8 bytes in both examples and all fields in the
DNS Section, except for the DNS Name field, are always 2 bytes.
The Flags/Parameters Field
The Parameter Field (labeled Flags) is one of the most important fields in DNS because it is
responsible for letting the server or client know a lot of important information about the DNS
packet. For example, it contains information as to whether the DNS packet is a query or response
and, in the case of a query, if it should be a recursive or non-recursive type. This is most
important because as we've already seen, it determines how the query is handled by the server.
Let's have a closer look at the flags and explain the meaning of each one. I've marked the bit
numbers with black on the left hand side of each flag parameter so you can see which ones are
used during a response. The picture on the right hand side explains the various bits. You won't see
all 16 bits used in a query as the rest are used during a response or might be reserved:
As you can see, only bits 1, 2-5, 7, 8 and 12 are used in this query. The rest will be a combination
of reserved bits and bits that are used only in responses. When you read the DNS response
message format page, you will find a similar packet captured which is a reponse to the above
query and the rest of the bits used are analysed.
And that just about does it for the DNS Query message format page. Next up is the DNS
Response message format page which I'm sure you will find just as interesting!
DNS Response Message Format
Introduction
The previous page delt with the DNS Query message formats. We analysed them in great detail
and showed how various options are selected by the host using the Flags/Parameters field.
On this page we will see and analyse the responses we get from the generated queries. These
responses, in the case of a recursive query, come directly from the DNS server to which we sent
the query and, in the case of a non-recursive query, will come from the last DNS server the client
contacts in order to get the required information.
Lastly, keep in mind that this page is the continuation of the previous page, so it's important to
understand the previous material ! If you have any doubts, read the previous section again.
Now that we have all that out of the way ....let's grab a few DNS responses and get our hands
dirty :)
DNS Analysis - Server Response
Here is the response (highlighted) to the previous DNS query sent to an Australian DNS server
(139.130.4.4), where I asked for the resolution of www.firewall.cx:
Something worth paying attention to is the time this query took to come back to my Linux file
server. The time taken, from the moment the packet was sent from the Linux file server, until it
received the answer, was only 0.991 seconds !
During this short period of time the packet travelled from Greece to Australia, reached the DNS
server, which sent its queries to other DNS servers until it found the answer and then generated a
DNS response that was sent back to Greece where my home network is !
There are a lot of factors that contribute to this fairly fast reponse. The transport protocol UDP,
which does not require any 3-way handshake, the load of the DNS server to which I sent the
query, the load of DNS servers it then had to ask, the speed at which all these servers and myself
are connected to the Internet and the general load between the routers that my packet had to travel
in order to get to its various destinations !
As you can clearly see, there is a lot happening for just one DNS query and response. Try to
consider what happenes when you have 20,000,000 DNS queries happening at once on the
Internet and you have a good idea on how well this protocol and the underlying technology have
been designed !
Following is the Ethernet II packet that runs on the local network. The structure is the same, but
varies in size, regardless of whether it's a DNS Query or Response:
Now, to make the analysis of the DNS Section easier I have also included the DNS Query (left
hand side) and DNS Response (right hand side). This allows you to compare what we sent and
what we received :
........
By comparing the two packets, you can see that there are fields in the DNS Response packet
(marked with green arrows) that didn't exist in the Query. Let's see again what each field means
and anaylse them again as we did in the previous page.
The DNS Section in a response packet is considerably larger and more complex than that of a
query. For this reason we are going to analyse it in parts rather than all together. The query had
only one section that required in-depth analysis whereas the response has three since the first one
is the original query sent.
Here is the DNS Section of a DNS response in 3D:
You can clearly see that everything after the light green 3D block labeled "DNS Query Section"
is new. We are going to focus on these 3 new blocks, which are part of the DNS Response
Section, as the rest has been covered in the previous page.
DNS Response Section
The analysis of this section won't be too difficult because the format that is followed in each 3D
block of our DNS Response Section is identical. For this reason, I have not analysed all 3 3D
blocks, but only a few to help you get the idea.
The diagram below shows you the contents of the 3 3D blocks (sections) we are looking at:
Answers Section, Authoritative Name Servers Section and the Additional Records Sections:
What we need to need understand is that each one of these three sections have identical fields.
Even though the information they contain might seem a bit different, the fields are exactly the
same and we will see this shortly.
In the picture above, I have only expanded the first part of the Answer section which is
underlined in green so you can compare the fields with the ones contained in the left hand picture.
This next picture shows you the expanded version from the first part of the Answers and
Authoritative sections. I have already marked and labeled the fields to prove to you that they are
all identical and vary only in the information they contain:
If you look carefully you will notice that the Resource Data field is presented first, where
according to the analysis of the sections in the picture above (left side), you would expect it last.
The truth is that it is last, but it's presented first just because my packet sniffer likes to make the
data more readable and less confusing.
This is also the reason the first line of each part in each section is used to give you a quick
summary of the information captured.
For example, looking at line 1, part 1 in the Answers Section (underlined in green), you get a
summary of what's to follow: www.firewall.cx, type INET, cname firewall.
This proves that all fields in all of these 3 sections contained in the DNS Response Section are
identical, but contain different values/data.
You also might wonder why there are 2 parts in each section ?
Could there be more or less parts, depending on the domain name or is there always 2 parts in
each section ?
The answer is simple and logical, there are as many parts as needed, depending always on the
domain setup. For example, if I had more than two name servers for the Firewall.cx domain, you
would see more than two parts in the Authoritative nameserver section and the other sections.
Our example has only 2 parts per section whereas the one we see below has a lot more :
This DNS Response Section is based on a query generated for the IBM.COM domain:
As you can see, our query for IBM.COM gave us a response which has 4 parts per section !
Again, each part in every section has identical fields, but different data/values.
You might have noticed a pattern here as well. In every DNS Response you will find the same
number of parts per section.
For example, the picture on the left shows us 4 parts for the Answers, Authoritative and
Additional records sections and this is no coincidence.
The reason this is no coincidence - between the 3 sections (Answers, Authoritative and
Additional records) is the Type field and I will explain why.
The Type Field
The Type field determines the type or part of information we require about a domain. To give you
the simplest example, when we have a Type=A , we are given the IP Address of the domain or
host (look at Answers section above), whereas a Type=NS means we are given the Authoritative
Name Servers that are responsible for the domain (look at Authoritative Name Servers section
above).
Looking at the picture below, which is from our first example (query for firewall.cx) we can see
exactly how the Type field is responsible for the data we receive about a domain:
As you can see, the Type field in the first part of the Authoritative Name Servers section is set to
NS, which means this part contains information about the Authoritative name servers of the
queried domain.
Going to the first part of the Additional records, we can see that the Type field here is set to A,
which means the data contained in this part is an IP Address for a particular host.
So where is the logic to all this ?
Well, if I told you which servers are authoritative for a domain (Authoritative Name Server
Section), it would be useless if I answered you without giving you their IP Addresses (Additional
Records Section).
This is the reason in this example we have been told about the Name Servers for the firewall.cx
domain (Authoritative Name Server Section), but also given their IP Address (Additional Records
Section).
The same rule and logic explains why there are 2 parts for all three sections of this example.
Let's have a look at the different values the Type field can have, this will also give you an insight
into the information we can request and receive about any domain:
Type
Meaning
Contents
A
Host Address
32-Bit IP Address of host or domain
CNAME
Canonical Name (Alias)
Canonical domain name for and alias e.g www
HINFO
CPU & OS
Name of CPU and Operating System
MINFO
Mailbox
Info about a mailbox or mail list
MX
Mail Exchange
16-bit preference and name of the host that acts as a mail exchange server for a domain e.g
mail.firewall.cx
NS
Name Server
Authoritative name server for the domain
PTR
Pointer
Symbolic link for a domain. e.g net.firewall.cx points to www.firewall.cx
SOA
Start Of Authority
Multiple fields that specify which parts of the naming hiererchy a server implements
TXT
Arbitrary Text
Uninterpreted string of ASCII text
The above values the Type field can take are contained within the DNS database, which is
covered next.
Our discussion on the DNS Response message format is now complete !
Introduction To The DNS Database (BIND)
Introduction
This page is dedicated to the database that drives DNS servers all over the world. Because over
80% of the DNS servers are based on Unix, Linux and the BIND (Berkely Internet Name
Domain) program, our example will be based on a DNS server running the latest version of Bind
at the time of writing, which is Bind v 9.2.1.
Before we start though, we're going to talk about the "Zone" concept and its relation to the
"Domain" concept. This will help you understand how the database is structured and set up.
Zones and Domains
The programs that store information about the domain name space are called name servers, as you
probably already know. Name Servers generally have complete information about some part of
the domain name space (a zone), which they load from a file. The name server is then said to
have authority for that zone.
The term zone is not one that you come across every day while you're surfing on the Internet. We
tend to think that the "domain" concept is all there is when it comes to DNS, which makes life
easy for us, but when dealing with DNS servers that hold data for our domains (name servers),
then we need to introduce the zone term since it is essential so we can understand the setup of a
DNS server.
The difference between a zone and a domain is important, but subtle. The best way to understand
the difference is by using a good example, which is coming up next.
The COM domain is divided into many zones, including the hp.com zone, sun.com, it.com. At the
top of the domain, there is also a com zone.
The diagram below shows you how a zone fits within a domain:
The trick to understanding how it works is to remember that a zone exists "inside" a domain.
Name servers load zone files, not domains. Zone files contain information about the portion of a
domain for which they are responsible. This could be the whole domain (sun.com, it.com) or
simply a portion of it (hp.com + pr.hp.com).
In our example, the hp.com domain has two subdomains, support.hp.com and pr.hp.com. The first
one, support.hp.com is controlled by its own name servers as it has its own zone, called the
support.hp.com zone. The second one though, pr.hp.com is controlled by the same name server
that takes care of the hp.com zone.
The hp.com zone has very little information about the support.hp.com zone, it simply knows its
right below. If anyone requires more information on support.hp.com, it will be requested to
contact the authoritative name servsers for that subdomain, which are the name servers for that
zone.
So you see that even though support.hp.com is a subdomain just like pr.hp.com, it is not setup
and controlled the same way as pr.hp.com.
On the other hand, the Sun.com domain has one zone (sun.com zone) that contains and controlls
the whole domain. This zone is loaded by the authoritative name servers.
BIND ? Never heard of it !
As I mentioned in the beginning of this page, BIND stands for Berkely Internet Name Domain.
Keeping things simple, it's a program you download (www.bind.org) and install on your Unix or
Linux server to give it the ability to become a DNS server for your private (lan) or public
(Internet) network.
The majority of DNS servers are based on BIND as it's a proven and reliable DNS server. The
download is approximately 4.8 MBytes. I'm not going to explain how to unzip, untar and compile
BIND since it's out of the scope of this page's. If you follow the instructions provided you
shouldn't have any problems.
Setting up your Zone Data
No matter what Linux distribution you have, the file structure is pretty much the same. I have
BIND installed on my Linux server, which runs Slackware v8 with kernel 2.4.19. By following
the installation procedure found in the documentation provided with BIND, you will have the
server installed within 15 min at most.
Once the installation of BIND is complete you need to start creating your zone data files.
Remember, these are the files the DNS server will load in order to understand how your domain
is setup and the various hosts within it.
A DNS server has multiple files that contain information about the domain setup. From these
files, one will map all host names to IP Addresses and other files will map the IP Address back to
hostnames. The name-to-IP Address lookup is sometimes called forward mapping and the IP
Address-to-name lookup reverse mapping. Each network will have its own file for reversemapping.
As a convention in this section, a file that maps hostnames to IP Addresses will be called
db.DOMAIN, where DOMAIN is the name of your domain e.g. db.space.net, and db is short for
DataBase.The files mapping IP Address to hostnames are called db.ADDR where ADDR is the
network number without trailing zeros or the specification of a netmask, e.g db.192.168.0 for the
192.168.0.0 network.
The collection of our db.DOMAIN and db.ADDR files are our Zone Data files. There are a few
other zone data files, some of which are created during the installation of BIND: named.ca,
localhost.zone and named.local.
Named.ca contains information about the root servers on the Internet, should your DNS server
require to contact one of them. Localhost.zone and Named.local are there to cover the loopback
network. The loopback address is a special address hosts use to direct traffic to themselves. This
is usually IP Address 127.0.0.1, which belongs to the 127.0.0.0/24 network.
These files must be present in each DNS server and are the same for every DNS server.
Quick Summary of files so far..
Let's have a quick look at the files we have covered so far to make sure we don't lose track:
1) Following files must be created by you and will contain the data for our zone:


db.DOMAIN e.g db.space.net - Host to IP Address mapping
db.ADDR e.g db.192.168.0 - IP Address to Host mapping
2) Following files are usually created by the BIND installation:


named.ca - Contains the ROOT DNS servers
named.local & localhost.zone - Special files so the server can direct traffic to itself.
You should also be aware that the file names can change, there is no standard for names, it's just
very convenient and tidy to keep some type of convention.
To tie all the zone data files together a name server needs a configuration file. BIND version 8
and above calls it named.conf and it can be found in your /etc dir once you install the BIND
package. Named.conf simply tells the name server where your zone files are located and we will
be analysing this file later on.
Most entries in the zone data files are called DNS resource records. Since DNS lookups are case
insensitive, you can enter names in your zone data files in uppercase, lowercase or mixed case. I
tend to use lowercase.
Resource records must start in the first column of a line. The DNS RFCs have samples that
present the order in which one should enter the resource records. Some people choose to follow
this order, while others don't. You are not required to follow this order, but I do :)
Here is the order of resource records in the zone data file:
SOA record - Indicates authority for this zone.
NS record - Lists a name server for this zone
MX record - Indicates the mail exchange server for the domain
A record - Name to IP Address mapping (gives the IP Address for a host)
CNAME record - Canonical name (used for aliases)
PTR record - Address to name mapping (used in db.ADDR)
The next page deals with the construction of our first zone data file, db.space.net for the space.net
domain.
The db.space.net Zone Data File
Introduction
It's time to start creating our zone files. We'll follow the standard format, which is given in the
DNS RFCs, in order to keep everything neat and less confusing.
First step is to decide on the domain we're using and I've already chosen space.net. This means
that the first zone file will be db.space.net. Note that this file is to be placed on the Master DNS
server for our domain. We will progressively build our database by populating it step by step and
explaining each step we take. At the end of the step by step example, we'll grab each step's data
and put it all together so we can see how the final version of our file will look. This, I believe, is
the best method of explaining how to create a zone file without confusing the hell out of everyone
!
Constructing db.space.net
Note: The actual entries for our file are marked with bold green characters using italic format.
Anything else, such as plain green coloured characters, is used to help you identify specific
commands I'm talking about that have been used in the zone file we are creating. Also, keep in
mind we are setting up a primary DNS server. For a simple DNS caching or secondary name
server, the setup is a lot simpler and covered on other pages.
The first entry for our file is the Default TTL - Time To Live. This is defined using the $TTL
control statement. $TTL specifies the time to live for all records in the file that follow the
statement and don't have an explicit TTL. We are going to set ours to 3 hours.
$TTL 3h
Next up is the SOA Record. The SOA (Start Of Authority) resource record indicates that this
name server is the best source of information for the data within this zone (this record is required
in each db.DOMAIN and db.ADDR file), which is the same as saying this name server is
Authoritative for this zone. There can be only one SOA record in every data zone file
(db.DOMAIN).
space.net. IN SOA voyager.space.net. admin.voyager.space.net. (
1 ; Serial Number
3h ; Refresh after 3 hours
1h ; Retry after 1 hour
1w ; Expire after 1 week
1h ) ; Negative caching TTL of 1 hour
Let's explain the meaning of this:
space.net. is the domain name and must always be stated in the first column of our line, be sure
you include the trailing dot "." after the domain name, I'll explain later on why this is needed.
The IN stands for Internet. This is one class of data and while other classes exist, you won't see
them at all because they are not used :)
The SOA is an important resource record. What follows is the actual primary name server for
space.net. In our example, this is the server named "voyager" and its Fully Qualified Domain
Name (FQDN) is voyager.space.net. Notice the trailing "." is present here as well.
Next up is the entry admin.voyager.space.net. which is nothing but the email of the person
responsible for this domain. Take the dot "." after the admin entry and replace it with with "@"
and you have a valid email address: [email protected]. Most times you will see root,
postmaster or hostmaster where I have placed "admin".
The "(" parentheses allow the SOA record to span more than one line, while in most cases the
fields that follow are used by the secondary name servers and any other name server requesting
information about the domain.
The serial number "1 ; Serial Number" entry is used by the secondary name server to keep track
of changes that might have occured in the master's zone file. When the secondary name server
contacts the primary name server, it will check to see if this value is the same. If the secondary's
name server is lower than the primary's, then its data is out of date and, when equal, it means the
data is up to date. This means when you make any modifications to the primary's zone file, you
must increment the serial number at least by one.
The refresh "3h ; Refresh after 3 hours" tells the secondary name server how often to check that
the data for this zone is up to date.
If the secondary name server tries to contact the primary and fails, the retry "1 h ; Retry after 1
hour" is used to tell the secondary name server how long to wait until it tries to contact the
primary again.
If the secondary name server fails to contact the primary for longer than the time specified in the
fourth entry "1 w ; Expire after 1 week", then the zone data on the secondary name server is
considered too old and will expire.
The last line "1 h ) ; Negative caching TTL of 1 day" is how long a name server will send
negative responses about the zone. These negative responses say that a particular domain or type
of data sought for a particular domain name doesn't exist. Notice the SOA section finishes with
the ")" parentheses.
Next up are the name server (NS) records:
; Name Servers defined here
space.net. IN NS voyager.space.net.
space.net. IN NS gateway.space.net.
These entries define the two name servers (voyager and gateway) for our domain space.net. These
entries will be also in the db.ADDR file for this domain as we will see later on.
It's time to enter our MX records. These records define the mail exchange servers for our domain,
and this is how any client, host or email server is able to find a domain's email server:
; Mail Exchange servers defined here
space.net. IN MX 10 voyager.space.net.
space.net. IN MX 20 gateway.space.net.
Let's explain what exactly these entries mean. The first line specifies that voyager.space.net is a
mail exchanger for space.net, just as the second line (...IN MX 20 gateway...) specifies that
gateway.space.net is also a mail exchanger for the domain. The MX record is what indicates that
the following hosts are mail exchangers and the numbers right after the MX record (10, and 20)
indicate the priority level.
These entries were introduced to prevent mail loops. When another email server (unlikely for a
private domain like mine, but the same rule applies for the Internet) wants to send mail to
space.net, it will try to contact first the mail exchanger with the smallest number, which in our
case is voyager.space.net. The smaller the number, the higher the priority if there are more than
one mail servers.
In our example, if we replaced:
space.net. IN MX 10 voyager.space.net.
space.net. IN MX 20 gateway.space.net.
with
space.net. IN MX 50 voyager.space.net.
space.net. IN MX 100 gateway.space.net.
the result in matter of priority, would be the same. Let's now have a look our next part of our zone
file: Host IP Addresses and Alias records:
; Host addresses defined here
localhost.space.net. IN A 127.0.0.1
voyager.space.net. IN A 192.168.0.15
enterprise.space.net. IN A 192.168.0.5
gateway.space.net. IN A 192.168.0.10
admin.space.net. IN A 192.168.0.1
; Aliases
www.space.net. IN CNAME voyager.space.net.
Most fields in this section are easy to understand. We start by defining our localhost (local
loopback) "localhost.space.net. IN A 127.0.0.1" and continue with the servers I have on my home
network, these include voyager, enterprise, gateway and admin (my workstation). The "A" record
stands for IP Address. So "voyager.space.net. IN A 192.168.0.15" translates to a host called
voyager located in the space.net domain with an INternet ip Address of 192.168.0.15.
The second block has the aliases table, where we created a Canonical Name (CNAME) record. A
CNAME record simply maps an alias to its canonical name; in our example, www is the alias and
voyager.space.net is the canonical name. When a name server looks up a name and finds
CNAME records, it replaces the name (alias - www) with its canonical name (voyager.space.net)
and looks up the canonical name (voyager.space.net). For example, when a name server looks up
www.space.net, it will replace the www with voyager and lookup the IP Address for
voyager.space.net. This also explains the meaning of "www" in our webbrowser, it's nothing
more than an alias which, ultimately, is replaced with the CNAME record defined.
That completes a simple domain setup! We have now created a working zone file that looks like
this:
$TTL 3h
space.net. IN SOA voyager.space.net. admin.voyager.space.net. (
1 ; Serial Number
3h ; Refresh after 3 hours
1h ; Retry after 1 hour
1w ; Expire after 1 week
1h ) ; Negative caching TTL of 1 day
; Name Servers defined here
space.net. IN NS voyager.space.net.
space.net. IN NS gateway.space.net.
; Mail Exchange servers defined here
space.net. IN MX 10 voyager.space.net.
space.net. IN MX 20 gateway.space.net.
; Host Addresses Defined Here
localhost.space.net. IN A 127.0.0.1
voyager.space.net. IN A 192.168.0.15
enterprise.space.net. IN A 192.168.0.5
gateway.space.net. IN A 192.168.0.10
admin.space.net. IN A 192.168.0.1
; Aliases
www.space.net. IN CNAME voyager.space.net.
A quick glance at this file tells you a lot about my home domain space.net! This is probably the
best time to explain why we should not omit the trailing dot at the end of the domain name:
If we took gateway.space.net as an example and omitted the dot "." at the end, that particular
entry would turn out like this: gateway.space.net.space.net, not what you intended at all! As you
see, the space.net is appended to the end of our Fully Qualified Domain Name for the particular
resource record (gateway). This is why it's so important to never forget that extra dot "." at the
end!
Next is our db.ADDR file, which will take the name db.192.168.0.
The db.192.168.0 Zone Data File
Introduction
The db.192.168.0 zone data file is the second file we are creating for our DNS server. As outlined
in the DNS-BIND introduction, this file's purpose is to provide the IP Address -to- name
mappings. Note that this file is to be placed on the Master DNS server for our domain.
Constructing db.192.168.0
While we start to construct the file, you will notice many similarities with our previous file. Since
most resource records have already been covered and explained in detail, I will not repeat their
analysis again on this page.
The first line is our $TTL control statement:
$TTL 3h
Next up is the Start Of Authority resource record:
0.168.192.in-addr.arpa. IN SOA voyager.space.net. admin.space.net. (
1 ; Serial
3h ; Refresh after 3 hours
1h ; Retry after 1 hour
1w ; Expire after one week
1h ) ; Negative Caching TTL of 1 hour
As you can see, everything above, except the first column of the first line, is identical to the
db.space.net file. The "0.168.192.in-addr.arpa" entry is my network in reverse order. You simply
take your network address, reverse it, and add an ".in-addr.arpa." at the end.
Name server resource records are next. The syntax is nearly the same as the previous file,
remember that we don't enter the full reversed IP Address for the name servers but only the first 3
octecs which represent the network they belong to:
; Name Servers defined here
0.168.192.in-addr.arpa. IN NS voyager.space.net.
0.168.192.in-addr.arpa. IN NS gateway.space.net.
If you find it hard to remember this method, simply remind yourself that we replace the domain
name (previous file) with the network address reversed, followed by the ".in-addr.arpa.".
The PTR resource record follows since we use this to create our IP Address-to-name mappings:
; IP Address to Name mappings
1.0.168.192.in-addr.arpa. IN PTR admin.space.net.
5.0.168.192.in-addr.arpa. IN PTR enterprise.space.net.
10.0.168.192.in-addr.arpa. IN PTR gateway.space.net.
15.0.168.192.in-addr.arpa. IN PTR voyager.space.net.
And now we'll look at the whole file with all its entries:
$TTL 3h
0.168.192.in-addr.arpa. IN SOA voyager.space.net. admin.space.net. (
1 ; Serial
3h ; Refresh after 3 hours
1h ; Retry after 1 hour
1w ; Expire after one week
1h ) ; Negative Caching TTL of 1 hour
; Name Servers defined here
0.168.192.in-addr.arpa. IN NS voyager.space.net.
0.168.192.in-addr.arpa. IN NS gateway.space.net.
; IP Address to Name mappings
1.0.168.192.in-addr.arpa. IN PTR admin.space.net.
5.0.168.192.in-addr.arpa. IN PTR enterprise.space.net.
10.0.168.192.in-addr.arpa. IN PTR gateway.space.net.
15.0.168.192.in-addr.arpa. IN PTR voyager.space.net.
This completes the db.192.168.0 Zone data file. Remember the whole purpose of this file is to
provide an IP Address-to-name mapping, which is why we do not use the domain name in front
of each sentence but the reversed IP Address followed by the in-addr.arpa. entry.
Common BIND Files
Introduction
So far we have covered in great detail the main files required for the space.net domain. These
files, which we named db.space.net and db.192.168.0, define all the resouce records and hosts
available in the space.net domain.
Now, even though the contents of these files are common for every domain but vary in their
contents (e.g resource records defined for each domain), there are some files that are common and
have pretty much the same contents for any type of domain !
We will be looking at these files on this page and analysing them to help you understand why
they exist and how they fit into the big picture :)
Our Common Files
There are 3 common files that we're going to look at. However, the first two files' contents change
slightly depending on the domain, this is because they must be aware of the various hosts and the
domain name for which they are created. The third file is always the same amongst all DNS
servers and I'll explain more about it later on.
So here are our files:



named.local or db.127.0.0
named.conf (analysed at the end)
named.ca or db.cache
We are going to take each file and look at its contents, this will make them easier to understand.
The named.local File
The named.local file, or db.127.0.0 as some might call it, is used to cover the loopback network.
Since no one was given the responsibility for the 127.0.0.0 network, we need this file to make
sure there are no errors when the DNS server needs to direct traffic to itself (127.0.0.1 IP Address
- Loopback).
When installing BIND, you will find this file in your caching example directory:
/var/named/caching-example, so you can either create a new one or modify the existing one to
meet your requirements.
The file is no different than our example db.addr file we saw previously:
$TTL 3h
0.0.127.in-addr.arpa. IN SOA voyager.space.net. admin.space.net. (
1 ; Serial
3h ; Refresh after 3 hours
1h ; Retry after 1 hour
1w ; Expire after 1 week
1h ) ; Negative caching TTL of 1 hour
0.0.127.in-addr.arpa. IN NS voyager.space.net.
0.0.127.in-addr.arpa. IN NS gateway.space.net.
1.0.0.127.in-addr.arpa. IN PTR localhost.
That's all there is for named.local file !
The named.ca File
The named.ca file (also known as the "root hints file") is created when you install BIND and
dosen't need to be modified unless you have an old version of BIND or it's been a while since you
installed BIND.
The purpose of this file is to let your DNS server know about the ROOT Servers on the Internet.
There is no point showing the whole content of this file because it's quite big, so I'll show you an
entry of a ROOT server so you can see what it looks like:
; last update: Aug 22, 1997
; related version of root zone: 1997082200
;
;
; formerly NS.INTERNIC.NET
;
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
The domain name "." refers to the root zone and the "3600000" is an explicit time to live for the
records in the file, but it is generally ignored :) The rest are self explanatory. If you want to grab a
new copy of the root hint file you can ftp to ftp.rs.internic.net (198.41.0.6) and log on
anonymously, there you will find the latest up to date version.
The named.conf File
The named.conf file is usually located in the /etc directory and is the key file that ties all the zone
data files together and lets the DNS server know where they are located in the system. This file is
automatically created during the installation but you must edit it in order to add new entries that
will point to any new zone files you have created.
Let's have a close look at the named.conf file and explain:
options {
directory "/var/named";
};
// Root Servers
zone "." IN {
type hint;
file "named.ca";
};
// Entry for Space.net - name to ip mapping
zone "space.net" IN {
type master;
file "db.space.net";
};
// Entry for Space.net - ip to name mapping
zone "0.168.192.in-addr.arpa" IN {
type master;
file "db.192.168.0";
};
// Entry for Local Loopback
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
};
At first glance it might seem a maze, but it's a lot simpler than you think. Break down each
paragraph and you can see clearly the pattern that follows. Starting from the top, the options
section simply defines the directory where all the files to follow are located, the rest are simply
comments.
The root servers section tells the DNS server where to find the root hints file, which contains all
the root servers. Next up is the entry for our domain space.net, we let the DNS server know which
file contains all the zone entries for this domain and let it know that it will act as a master DNS
server for the domain. The same applies for the entry to follow, which contains the IP to Name
mappings, this is the 0.168.192.in-addr.arpa zone.
The last entry is required for the local loopback. We tell the DNS server which file contains the
local loopback entries.
Notice the "IN" class that is present in each section ? If we accidentally forgot to include it in our
zone files, it wouldn't matter because the DNS server will automatically figure out the class from
our named.conf file. It's imperative not to forget the "IN" (Internet) class in the named.conf,
whereas it really doesnt matter if you don't put it in the zone files. It's good practice still to enter it
in the zone files as we did, just to make sure you don't have any problems later on.
And that ends our discussion for the common DNS (BIND) files. Next up is the configuration of
our Slave/Secondary DNS server.
The Secondary (Slave) DNS Server
Introduction
Setting up a Secondary (or Slave) DNS sever is much easier than you might think. All the hard
work is done when you setup the Master DNS server by creating your database zone files and
configuring named.conf.
If you are wondering how is it that the Slave DNS server is easy to setup, well you need to
remember that all the Slave DNS server does is update its database from the Master DNS server
(zone transfer) so almost all the files we configure on the Master DNS server are copied to the
Slave DNS server, which acts as a backup in case the Master DNS server fails.
Setting up the Slave DNS Server
Let's have a closer look at the requirements for getting our Slave DNS server up and running.
Keeping in mind that the Slave DNS server is on another machine, we are assuming that you have
downloaded and successfully installed the same BIND version on it. We need to copy 3 files from
the Master DNS server, make some minor modifications to one file and launch our Slave DNS
server.... the rest will happen automatically :)
So which files do we copy ?
The files required are the following:



named.conf (our configuration file)
named.ca or db.cache (the root hints file, contains all root servers)
named.local (local loopback for the specific DNS server so it can direct traffic to itself)
The rest of the files, which are our db.DOMAIN (db.space.net for our example) and db.inaddr.arpa (db.192.168.0 for our example), will be transferred automatically (zone transfer) as
soon as the newly brought up Slave DNS server contacts the Master DNS server to check for any
zone files.
How do I copy the files ?
There are plenty of ways to copy the files between servers. The method you will use depends on
where the servers are located. If, for example, they are right next to you, you can simply use a
floppy disk to copy them or use ftp to transfer them.
If you're going to try to transfer them over a network, and especially over a public one (Internet),
then you might consider something more secure than ftp. I would recommend you use SCP,
which stands for Secure CoPy and uses SSH (Secure SHell).
SCP can be used independently of SSH as long as there is an SSH server on the other side. SCP
will allow you to transfer files over an encrypted connection and therefore is preferred for
sensitive files, plus you get to learn a new command :)
The command used is as follows: scp localfile-to-copy username@remotehost:desitnation-folder.
Here is the command line I used from my Gateway server (Master DNS): scp /etc/named.conf
root@voyager:/etc/
Keep in mind that the files we copy are placed in the same directory as on the Master DNS server.
Once we have copied all three files we need to modify the named.conf file. To make things
simple, I am going to show you the original file copied from the Master DNS and the modified
version which now sits on the Slave DNS server.
The Master named.conf file is a clear cut/paste from the "Other Common Files" page, whereas
the Slave named.conf has been modifed to suit our Slave DNS server. To help you see the
changes, I have marked them in red:
Master named.conf file
options {
directory "/var/named";
};
// Root Servers
zone "." IN {
type hint;
file "named.ca";
};
// Entry for Space.net - name to ip mapping
zone "space.net" IN {
type master;
file "db.space.net";
};
// Entry for Space.net - ip to name mapping
zone "0.168.192.in-addr.arpa" IN {
type master;
file "db.192.168.0";
};
// Entry for Local Loopback
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
};
Slave named.conf file
options {
directory "/var/named";
};
// Root Servers
zone "." IN {
type hint;
file "named.ca";
};
// Entry for Space.net - name to ip mapping
zone "space.net" IN {
type slave;
file "bak.space.net";
masters { 192.168.0.10 ; } ;
};
// Entry for Space.net - ip to name mapping
zone "0.168.192.in-addr.arpa" IN {
type salve;
file "bak.192.168.0";
masters { 192.168.0.10 ; } ;
};
// Entry for Local Loopback
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
};
As you can see, most of the slave's named.conf file is similair to the master's, except for a few
fields and values, which we are going to explain right now.
The type value is now slave, and that's pretty logical since it tells the dns server if it's a master or
slave.
The file "bak.space.net"; entry basically tells the server what name to give the zone files once
they are transfered from the master dns server. I tend to follow the bak.domain format because
that's the way I see the slave server, a backup dns server. It is not imperative to use this name
scheme, you can change it to whatever you wish. Once the server is up and running, you will see
these files soon appear in the /var/named directory.
Lastly, the masters {192.168.0.10}; entry informs our slave server that this is the IP Address of
the master DNS which it needs to contact and retrieve the zone files.
That's all there is to setup the slave DNS server ! As I told you, once the master is setup, the slave
is a peice of cake cause it involves very few changes.
DNS Caching
Introduction
In the previous pages I spoke about the Internet Domain Hierarchy and explained how the ROOT
servers are the DNS servers, which contain all the information about authoritative DNS servers
the domains immediately below e.g firewall.cx, microsoft.com. In fact, when a request is passed
to any of the ROOT DNS servers, they will redirect the client to the appropriate authoritative
DNS server that is in charge of the domain the client is after.
For example, if you're trying to resolve firewall.cx and your machine contacts a ROOT DNS
server, the server will point your computer to the DNS server in charge of the .CX domain, which
in turn will point your computer to the DNS server in charge of firewall.cx.
The Big Picture
As you can see, a simple DNS request can become quite a task in order to successfully resolve the
domain. This also means that there's a fair bit of traffic generated in order to complete the
procedure. Whether you're paying a flat rate to your ISP or your company has a permanent
connection to the Internet, the truth is that someone ends up paying for all these DNS requests !
The above example was only for one computer trying to resolve one domain. Try to imagine a
company that has 500 computers connected to the Internet or an ISP with 150,000 subscribers.
Now you're starting to get the big picture !
All that traffic is going to end up on the Internet if something isn't done about it, not to mention
who will be paying for it !
This is where DNS Caching comes in. If we're able to cache all these requests, then we don't need
to ask the ROOT DNS or any other external DNS server as long as we are trying to resolve
previously visited sites or domains, because our caching system would "remember" all the
previous domains we visited (and therefore resolved) and would be able to give us the IP Address
we're looking for !
Note: You should keep in mind that when you install BIND, by default it's setup to be a DNS
Caching server, so all you need to do it startup the service, which is called 'named'.
Almost all Internet name servers use name caching to optimise search costs. Each of these servers
maintains a cache which contains all recently used names as well as a record of where the
mapping information for that name was obtained. When a client (e.g your computer) asks the
server to resolve a domain, the server will first check to see whether it has authority (meaning if it
is in charge) for that domain. If not, the server checks its cache to see if the domain is in there and
it will find it if it's been recently resolved.
Assuming that the server does find it in the cache, it will take the information and pass it on to the
client but also mark the information as a nonauthoritative binding, which means the server tells
the client "Here is the information you required, but keep in mind, I am not in charge of this
domain".
The information can be out of date and, if it is critical for the client that it does not receive such
information, it will then try to contact the authoritative DNS server for the domain and obtain the
up to date information it requires.
DNS Caching does come with its problems !
As you can clearly see, DNS caching can save you a lot of money, but it comes with its problems
!
Caching does work well in the domain name system because name to address binding changes
infrequently. However, it does change. If the servers cached the information the first time it was
requested and never change that information, the entries in the cache could become incorrect.
The solution to the problem !
Fortunately there is a solution that will prevent DNS servers from giving out incorrect
information. To ensure that the information in the cache is correct, every DNS server will time
each entry and dispose of the ones that have exceeded a reasonable time. When a DNS server is
asked for the information after it has removed the entry from its cache, it must go back to the
authoritative source and obtain it again.
Whenever an authoritative DNS server responds to a request, it includes a Time To Live (TTL)
value in the response. This TTL value is set in the zone files as you've probably already seen in
the previous pages.
If you manage DNS server an are planning to introduce changes like redelegate (move) your
domain to some other hosting company or if the IP Address your website currently has or
changing mail servers, in the next couple weeks, then it's a good idea to get your TTL changes to
a very small value well before the scheduled changes. Reason for this is because any dns server
that will query your domain, website or any resource record that belongs to your domain, will
cache the data for the amount of time the TTL is set.
By decreasing the $TTL value to e.g 1 hour, this will ensure that all dns data from your domain
will expire in the requesters cache 1 hour after it was received. If you didn't do this, then the
servers and clients (simple home users) who access your site or domain, will cache the dns data
for the currently set time, which is normaly around 3 days. Not a good thing when you make a big
change :)
So keep in mind all the above when your about the perform a change in the DNS server zone
files. a couple of days before making the change, decrease the $TTL value to a reasonable value,
not more than a few hours, and then once you complete the change, be sure you set it back to
what it was.
I hope this has given you an insight on how you can save yourself, or company money and
problems which occur when changing field and values in the DNS zone files !
File Transfer Protocol - FTP
Introduction
File transfer is among the most frequently used TCP/IP applications and it accounts for a lot of
the network traffic on the Internet. Various standard file transfer protocols existed even before the
Internet was available to everyone and it was these early versions of the file transfer software that
helped create today's standard known as the File Transfer Protocol (FTP). Most recent
specifications of the protocol are listed in RFC 959.
The Protocol
FTP uses TCP as a transport protocol. This means that FTP inherits TCP's robustness and is very
reliable for transferring files. Chances are if you download files, you've probably used ftp a few
hundred times without realising it ! And if you have a huge warez collection, then make that a
couple of thousand times :)
The picture below shows where FTP stands in contrast to the OSI model. As I have noted in other
sections, it's important to understand the concept of the OSI model, because it will greatly help
you understand all this too :)
Now, we mentioned that FTP uses TCP as a transport, but we didn't say which ports it uses! Port
numbers 21 and 20 are used for FTP. Port 21 is used to establish the connection between the 2
computers (or hosts) and port 20 to transfer data (via the Data channel).
But there are some instances where port 21 is used for both, establishing a connection and data
transfer and I will analyse them shortly.
The best thing you can do to "see" it yourself is to grab a packet sniffer which you will
conveniently find in our download section and try to capture a few packets while you're ftp'ing to
a site.
Both Ports - 20 and 21 - Active FTP Mode
I have included a screenshot from my workstation which clearly shows the 2 ports used. In the
example, I have ftp'ed into ftp.cdrom.com. Please click here to view the full picture
Only Port 21 - Passive FTP Mode
Now, in the next picture I ftp'ed into my NetWare server here at home and guess what .... Only
Port 21 was used ! Here is the screen shot:
Please click here to view the full picture.
Let me explain why this is happening:
FTP has two separate modes of operation: Active and Passive. You will use either one depending
on whether your PC is behind a firewall.
Active Mode FTP
Active mode is usually used when there isn't any firewall between you and the FTP server. In
such cases you have a direct connection to the Internet. When you (the client) try to establish a
connection to a FTP server, your workstation includes a second port number (using the PORT
command) that is used when data is to be exchanged, this is known as the Data Channel.
The FTP server then starts the exchange of data from its own port 20 to whatever port was
designated by your workstation (in the screen shot, my workstation used port 1086), and because
the server initiated the communication, it's not controlled by the workstation client. This can also
potentially allow uninvited data to arrive to your computer from anywhere posing as a normal
FTP transfer. This is one of the reasons Passive FTP is more secure.
Passive Mode FTP
Using normal or passive FTP, a client begins a session by sending a request to communicate
through TCP port 21, the port that is conventionally assigned for this use at the FTP server. This
communication is known as the Control Channel connection.
At this point, a PASV command is sent instead of a PORT command. Instead of specifying a port
that the server can send to, the PASV command asks the server to specify a port it wishes to use
for the Data Channel connection. The server replies on the Control Channel with the port number
which the client then uses to initiate an exchange on the Data Channel. The server will thus
always be responding to client-initiated requests on the Data Channel and the firewall can
correlate these.
It's simple to configure your client FTP program to use either Active or Passive FTP. For
example, in Cute FTP, you can set your program to use Passive FTP by going to FTP--> Settings
--> Options and then selecting the "Firewall" tab :
If you remove the above options, then your workstation will be using (if possible) Active FTP
mode, and I say "if possible" cause if your already behind a firewall, there is probably no way
you will be using Active FTP, so the program will automatically change to Passive FTP mode.
So let's have a look at the process of a computer establishing an FTP connection with a server: .
........
..........
The above is assuming a direct connection to the FTP server. For simplicity reasons, we are
looking at the way the FTP connection is created and not worring if it's a Passive or Active FTP
connection. Since FTP is using TCP as a transport, you would expect to see the 3-way handshake.
Once that is completed and there is data connection established, the client will send its login
name and then password. After the authentication sequence is finished and the user is
authenticated to the Server, it's allowed access and is ready to leach the site dry :)
Finally, below are the most commonly used FTP commands:
ABOR: abort previous FTP command
LIST and NLST: list file and directories
DELE: delete a file
RMD: remove a directory
MKD: create a directory
PWD: print current working directory ( show you which dir. your at)
PASS: send password
PORT: request open port number on specific IP address/port number
QUIT: log off from server
RETR: retrieve file
STOR: send or put file
SYST: identity system type
TYPE: specify type (A for ASCII, I for binary)
USER: send username
And that just about complete's our analysis on the FTP protocol !
Trivial File Transport Protocol - TFTP
Introduction
TFTP is a file transport protocol and its name suggests it's something close to the FTP protocol
(File Transfer Protocol), which is true .. to a degree. TFTP isn't very popular because it's not
really used on the Internet because of its limitations which we'll explore next.
The Protocol
TFTP's main difference from FTP is the transport protocol it uses and the lack of any
authentication mechanisim. Where FTP uses the robust TCP protocol to establish connections and
complete the file transfers, TFTP uses the UDP protocol which is unsecure and has no error
checking built in to it (unless they have implemented some type of error checking in the program
you are using to transfer files), this also explains why you are more likely to find TFTP in a LAN,
rather than a WAN (Wide Area Network) or on the Internet.
The major limitations with TFTP are authentication and directory visibility, meaning you don't
get to see the files and directories available at the TFTP server.
As mentioned, TFTP uses UDP as a transport, as opposed to TCP which FTP uses, and works on
port 69, you can clearly see that in the cool 3D diagram on the left.
Port 69 is the default port for TFTP, but if you like, you can modify the settings on your TFTP
server so it runs on a different port.
You will find some very good TFTP servers and clients in the download section.
Now, to make things a bit clearer I have included a screen shot of my workstation tftp'ing into a
TFTP server which I have setup in my little network.
You can see my workstation (192.168.0.100) contacting the TFTP server (192.168.0.1) on port 69
(destination port). In this first packet, my workstation is contacting the server and requesting the
file I entered before I connected to the server. Click here for the full picture.
Because you don't get a listing of the files and directories, you must know which file you want to
download ! In the response I received (2nd packet) the server gets straight into business and starts
sending the file. No authentication whatsoever !
Note: The workstation usally won't send back any acknowlegement (because UDP, which is the
transport protocol, by nature, never sends acknowledgements), but the software developers can
incorporate such a feature by forcing the workstation to send a small packet which the TFTP
server is able to pickup as an acknowledgement of the previous data packet it sent to the
workstation.
In the example I provide, you can see my workstation sending small packets to the server after it
receives one packet from it. These small acknowledgements have been added by the software
company who created the program I was using for this example.
Below is a screen shot of the program I used to TFTP (TFTP Client) to the server:
Notice how I entered the file I wanted to downloaded (server.exe), and selected the name which
the file will be saved as on my local computer (Local File). If I didn't provide the Remote File
name, I would simply get an error poping up at the server side, complaing that no such file exists.
You can also send files using TFTP, as it's not just for downloading :)
So where is TFTP used ?
TFTP is used mostly for backing up router configuration files like Cisco and its IOS images, it is
also used for diskless booting PC's where, after the workstation has booted from the network
card's ROM, TFTP is used to download the program it needs to load and run from a central
server.
Below is a diagram which shows what takes place during a TFTP session:
.....
In this diagram we are assuming that there is no error checking built into the software running at
both ends (client and server).
And that pretty much sums it all up for the TFTP protocol.
Introduction To The Internet Control Message Protocol
Introduction
The Internet Control Message Protocol, or ICMP as we will be calling it, is a very popular
protocol and actually part of an Internet Protocol (IP) implementation. Because IP wasn't
designed to be absolutely reliable, ICMP came into the scene to provide feedback on problems
which existed in the communication environment.
If I said the word 'Ping' most people who work with networks would recognise that a 'ping' is part
of ICMP and in case you didn't know that, now you do :)
ICMP is one of the most useful protocols provided to troubleshoot network problems like DNS
resolutions, routing, connectivity and a lot more. Personally, I use ICMP a lot, but you need to
keep its limits in mind beause you might end up spending half a day trying to figure out why
you're not getting a 'ping reply' ('echo reply' is the correct term) from, for example,
www.firewall.cx when, in fact, the site's webserver is configured NOT to reply to 'pings' for
security reasons !
Cool Note
A few years ago there was a program released, which still circulates around the Internet, called
Click ( I got my hands on version 1.4). Click was designed to run on a Windows platform and
work against Mirc users. The program would utilise the different messages available within the
ICMP protocol to send special error messages to Mirc users, making the remote user's program
think it had lost connectivity with the IRC server, thus disconnecting them from the server ! The
magic is not what the program can do, but how it does it ! This is where a true networking guru
will be able to identify and fix any network security weakness.
The Protocol
ICMP is defined in RFC (Request For Comments) 792. Looking at its position in the OSI model
we can see that it's sitting in the Network layer (layer 3) alongside IP. There are no ports used
with ICMP, this is because of where the protocol sits in the OSI model. Ports are only used for
protocols which work at the Session layer and above:
The ICMP protocol uses different 'messages' to identify the purpose of an ICMP packet, for
example, an 'echo' (ping) is one type of ICMP message.
I am going to break down the different message descriptions as they have been defined by the
RFC792.
There is a lot of information to cover in ICMP so I have broken it down to multiple pages rather
than sticking everything into one huge page that would bore you!
Also, I haven't included all the messages which ICMP supports, rather I selected a few of the
more common ones that you're likely to come across. You can always refer to the RFC792 to get
the details on all messages.
We will start with a visual example of where the ICMP header and information are put in a
packet, to help you understand better what we are dealing with :)
The structure is pretty simple, not a lot involved, but the contents of the ICMP header will change
depending on the message it contains. For example, the header information for an 'echo' (ping)
message (this is the correct term) is different to that of a 'destination unreachable' message, also a
function of ICMP.
NOTE: If you were to run a packet sniffer on your LAN and catch a "ping" packet to see what it
looks like, you would get more than I am showing here. There will be an extra header, the
datalink header, which is not shown here because that header will change (or more likely be
removed) as the packet moves from your LAN to the Internet, but the 2 headers you see in this
picture will certainly remain the same until they reach their destination.
So, that now leaves us to analyse a few of the selected ICMP messages !
The table below shows all the ICMP messages the protocol supports. The messages that are in the
green colour are the ones covered. Please click on the ICMP message you wish to read about:
ICMP - Echo / Echo Reply (Ping) Message
Introduction
As mentioned in the previous page, an Echo is simply what most people call a 'ping'. The Echo
Reply is the 'ping reply'. ICMP Echos are used mostly for troubleshooting. When there are 2 hosts
which have communication problems, a few simple ICMP Echo requests will show if the 2 hosts
have their TCP/IP stacks configured correctly and if there are any problems with the routes
packets are taking in order to get to the other side.
The 'ping' command is very well known, but the results of it are very often misunderstood and for
that reason I have chosen to explain all those other parameters next to the ping reply, but we will
have a look at that later on.
Let's have a look at what an ICMP-Echo or Echo Reply packet looks like:
If the above packet was an ICMP Echo (ping), then the Type field takes a value of 8. If it's an
ICMP Echo Reply (ping reply) then it would take a value of 1.
The picture below is a screen shot I took when doing a simple ping from my workstation:
Okay, now looking at the screen shot above, you can see I 'pinged' www.firewall.cx. The first
thing my workstation did was to resolve that URL to an IP address. This was done using DNS.
Once the DNS server returned the IP address of www.firewall.cx, the workstation generated an
ICMP packet with the Type field set to 8.
Here is the proof:
The picture above is a screenshot from my packet sniffer the same time this experement was
taking place. The packet displayed is one of the 4 packets which were sent from my workstation
to the webserver of firewall.cx
Notice the ICMP type = 8 Echo field right under the ICMP Header section. This clearly shows
that this packet is being sent from the workstation and not received. If it was received, it would
have been an 'Echo Reply' and have a value of 1.
The next weird thing, if anyone noticed, is the data field. Look at the screen shot from command
prompt above and notice the value there and the value the packet sniffer is showing on the left.
One says 32 Bytes, and the other 40 Bytes !
The reason for this is that the packet sniffer is taking into account the ICMP header files (ICMP
type, code, checksum and identifier), and I'll prove it to you right now.
Look at the top of this page where we analysed the ICMP headers (the 3d picture), you will notice
that the lengths (in Bits) of the various fields are as follows: 8, 8, 16, 16, 16. These add up to a
total of 64 Bits. Now 8 Bits = 1 Byte, therefore 64 Bits = 8 Bytes. Take the 32 Bytes of data the
workstation's command prompt is showing and add 8 Bytes .... and you have 40 Bytes in total.
If you want to view the full screen shot of the packet sniffer, please click here.
And that just about does it for these two ICMP messages !
ICMP - Destination Unreachable Message
Introduction
This ICMP message is quite interesting, because it doesn't actually contain one message, but six!
This means that the ICMP Destination unreachable futher breaks down into 6 different messages.
We will be looking at them all and analysing a few of them to help you get the idea.
To make sure you don't get confused, keep one thing in mind: The ICMP Destination unreachable
is a generic ICMP message, the different code values or messages which are part of it are there to
clarify the type of "Destination unreachable" message was received. It goes something like this:
ICMP Destination <Code value or message> unreachable.
The ICMP - Destination net unreachable message is one which a user would usually get from the
gateway when it doesn't know how to get to a particular network.
The ICMP - Destination host unreachable message is one which a user would usually get from the
remote gateway when the destination host is unreachable.
If, in the destination host, the IP module cannot deliver the packet because the indicated protocol
module or process port is not active, the destination host may send an ICMP destination protocol /
port unreachable message to the source host.
In another case, when a packet received must be fragmented to be forwarded by a gateway but the
"Don't Fragment" flag (DF) is on, the gateway must discard the packet and send an ICMP
destination fragmentation needed and DF set unreachable message to the source host.
These ICMP messages are most useful when trying to troubleshoot a network. You can check to
see if all routers and gateways are configured properly and have their routing tables updated and
synchronised.
Let's look at the packet structure of an ICMP destination unreachable packet:
Please read on as the following example will help you understand all the above.
The Analysis
When you open a DOS command prompt and type "ping 200.200.200.200", assuming that your
workstation is NOT part of that network, then it would forward the ICMP Echo request to the
gateway that's configured in your TCP/IP properties. At that point, the gateway should be able to
figure out where to forward the ICMP Echo request.
The gateway usually has a "default route" entry, this entry is used when the gateway doesn't know
where the network is. Now, if the gateway has no "default route" you would get an "ICMP
Destination net unreachable" message when you try to get to a network which the gateway doesn't
know about. When you're connected to the Internet via a modem, then your default gateway is the
modem.
In order for me to demonstrate this, I set up my network in a way that should make it easy for you
to see how everything works. I have provided a lot of pictures hoping to make it as easy as
possible to understand.
I will analyse why and how you get an "ICMP - Destination net unreachable" message.
In the example above, I've setup my workstation to use the Linux server as a default gateway,
which has an IP of 192.168.0.5. The Linux server also has a default gateway entry and this is IP:
192.168.0.1 (the Windows 2000 Server).
When my workstation attempts to ping (send an ICMP Echo request) to IP 200.200.200.200, it
realises it's on a different network, so it sends it to the Linux server, which in turn forwards it to
its default gateway (the Win2k server) so it can then be forwarded to the Internet and eventually I
should get a ping reply (ICMP Echo reply) if the host exists and has no firewall blocking ICMP
echo requests.
Here is the packet which I captured:
When looking at the decoded section (picture above) you can see in the ICMP header section that
the ICMP Type is equal to 8, so this confirms that it's an ICMP Echo (ping). As mentioned
earlier, we would expect to receive an ICMP echo reply.
Check out though what happens when I remove the default gateway entry from the Linux server:
Now what I did was to remove the default gateway entry from the Linux server. So when it gets a
packet from my workstation, it wouldn't know what to do with it. This is how you get the
gateway to generate an "ICMP Destination net unreachable" message and send it back to the
source host (my workstation).
Here is a screen shot from the command prompt:
As you can see, the Linux server has returned an "ICMP Destination net unreachable". This is one
of the six possible 'ICMP Destination Unreachable' messages as listed at the beginning of this
page. The Linux server doesn't know what to do with the packet since it has no way of getting to
that 200.200.200.0 network, so it sends the "ICMP Destination net unreachable" message to my
workstation, notifiying it that it doesnt know how to get to that network.
Let's now take a look what the packet sniffer caught :
The decoder on the left shows that the Linux server (192.168.0.5) sent back to my workstation
(192.168.0.100) an ICMP Destination unreachable message (look at the ICMP type field, right
under the ICMP header) but if you also check out the ICMP Code (highlighted field), it's equal to
0, which means "net unreachable". Scrolling right at the top of this page, the first table clearly
shows that when the code field has a value of 0, this is indeed a "net unreachable" message.
It is also worth noticing the "Returned IP header" which exists within the ICMP header. This is
the IP header of the packet my workstation sent to the Linux server when it attempted to ping
200.200.200.200, and following that is 64 bits (8 bytes) of the original data.
This completed our discussion on the ICMP 'Destination Unreachable' generated packets.
ICMP - Source Quench Message
Introduction
The ICMP - Source quench message is one that can be generated by either a gateway or host. You
won't see any such message pop up on your workstation screen unless you're working on a
gateway which will output to the screen all ICMP messages it gets. In short, an ICMP - Source
quench is generated by a gateway or the destination host and tells the sending end to ease up
because it cannot keep up with the speed at which it's receiving the data.
Analysis
Now let's get a bit more technical: A gateway may discard internet datagrams (or packets) if it
does not have the buffer space needed to queue the datagrams for output to the next network on
the route to the destination network. If a gateway discards a datagram, it may send an ICMP Source quench message to the internet source host of the datagram.
Let's have a look at the packet structure of the ICMP - Source quench message:
A destination host may also send an ICMP - Source quench message if datagrams arrive too fast
to be processed. The ICMP - Source quench message is a request to the host to cut back the rate
at which it is sending traffic to the internet destination. The gateway may send an ICMP - Source
quench for every message that it discards. On receipt of an ICMP - Source quench message, the
source host should cut back the rate at which it is sending traffic to the specified destination until
it no longer receives ICMP - Source quench messages from the gateway. The source host can
then gradually increase the rate at which it sends traffic to the destination until it again receives
ICMP - Source quench messages.
The gateway or host may also send the ICMP - Source quench message when it approaches its
capacity limit rather than waiting until the capacity is exceeded. This means that the data
datagram which triggered the ICMP - Source quench message may be delivered.
That pretty much does it for this ICMP message.
ICMP - Redirect Message
Introduction
The ICMP - Redirect message is always sent from a gateway to the host and the example below
will illustrate when this is used.
Putting it simply (before we have a look at the example) the ICMP - Redirect message occurs
when a host sends a datagram (or packet) to its gateway (destination of this datagram is a
different network), which in turn forwards the same datagram to the next gateway (next hop) and
this second gateway is on the same network as the host. The second gateway will generate this
ICMP message and send it to the host from which the datagram originated.
There are 4 different ICMP - Redirect message types and these are:
The format of this ICMP message is as follows: ICMP - Redirect (0, 1, 2, 3 or 4) message.
Our example:
The gateway (Win2k Server) sends a redirect message (arrow No. 3) to the host in the following
situation:
Gateway 1 (the linux server), receives an Internet datagram (arrow No. 1) from a host on the
same network. The gateway checks its routing table and obtains the address of the next gateway
(hop) on the route to the datagram's Internet destination network and sends the datagram to it
(arrow No. 2).
Now, gateway 2 receives the datagram and, if the host identified by the Internet source address of
the datagram (in other words, it checks the source IP of the datagram, which will still be
192.168.0.100), is on the same network, a redirect message (arrow No. 3) is sent to the host. The
redirect message advises the host to send its traffic for the Internet network directly to gateway 2
as this is a shorter path to the destination. The gateway then forwards the original datagram's data
(arrow No. 1) to its Internet destination (arrow No.4).
For datagrams (or packets) with the IP source options and the gateway address in the destination
address field, a redirect message is not sent even if there is a better route to the ultimate
destination than the next address in the source route.
Analysis
Let's have a look at the structure of an ICMP - Redirect message:
That's all about ICMP - Redirect messages !
ICMP - Time Exceeded Message
Introduction
The ICMP - Time exceeded message is one which is usually created by gateways or routers. In
order to fully understand this ICMP message, you must be familiar with the IP header within a
packet. If you like you can go to the Download - Documents section and grab a copy of the
TCP/IP in a Ethernet II Frame file which breaks down the IP header nicely.
When looking at an IP header, you will see the TTL and Fragment Flag fields which play a big
part in how this ICMP message works. Please make sure you check them out before attempting to
continue !
The ICMP - Time exceeded message is generated when the gateway processing the datagram (or
packet, depending on how you look at it) finds the Time To Live field (this field is in the IP
header of all packets) is equal to zero and therefore must be discarded. The same gateway may
also notify the source host via the time exceeded message.
The term 'fragment' means to 'cut to pieces'. When the data is too large to fit into one packet, it is
cut into smaller pieces and sent to the destination. On the other end, the destination host will
receive the fragmented pieces and put them back together to create the original large data packet
which was fragmented at the source.
Analysis
Let's have a look at the structure of an ICMP - Time exceeded message:
If a host reassembling a fragmented datagram (or packet) cannot complete the reassembly due to
missing fragments within its time limit it discards the datagram and it may send an ICMP - time
exceeded message.
If fragment zero is not available then no ICMP - time exceeded message is needed to be sent at
all. Code 0 may be received from a gateway and Code 1 from a host.
So, summing it up, an ICMP - Time exceeded message can be generated because the Time to live
field in the IP header has reached a value of zero (0) or because a host reassembling a fragmented
datagram cannot complete the reassembly within its time limit because there are missing
fragments (Fragment reassembly time exceeded the allocated time).
IPSec - Internet Protocol Security
Introduction
IPSec is one of the new buzz words these days in the networking security area. It's becoming very
popular and also a standard in most operating systems. Windows 2000 fully supports IPSec and
that's most probably where you are likely to find it. Routers these days also support IPSec to
establish secure links and to ensure that no-one can view or read the data they are exchanging.
When the original IP (Internet Protocol) specification was created, it didn't really include much of
a security mechanisim to protect it from potential hackers. There were 2 reasons they didn't give
IP some kind of security. First was because back then (we are talking around 30 years ago) most
people thought that users and administrators would continue to behave fairly well and not make
any serious attempts to compromise other people's traffic. Second reason was because the
cryptographic technology needed to provide adequate security simply wasn't widely available and
in most cases not even known about !
How IPSec works
The Internet Security Agreement/Key Management Protocol and Oakley ( ISAKMP)
ISAKMP provides a way for two computers to agree on security settings and exchange a security
key that they can use to communicate securely. A Security Association (SA) provides all the
information needed for two computers to communicate securely. The SA contains a policy
agreement that controls which algorithms and key lengths the two machines will use, plus the
actual security keys used to securely exchange information.
There are two steps in this process. First, the two computers must agree on the following three
things:
1) The encryption algorithm to be used (DES, triple DES)
2) Which algorithm they'll use for verifying message integrity (MD5 or SHA-1)
3) How connections will be authenticated: using public-key certificate, a shared secret key or
Kerberos.
Once all that has been sorted out, they start another round of negotiations which cover the
following:
1) Whether the Authentication Header (AH) protocol will be used
2) Whether the Encapsulating Security Payload (ESP) protocol will be used
3) Which encryption algorithm will be used for ESP
4) Which authentication protocol will be used for AH
IPSec has 2 mechanisms which work together to give you the end result, which is a secure way to
send data over public networks. Keep in mind that you can use both or just one of these
mechanisms together.
These mechanisms are:
1) Authentication Header
2) Encapsulating Security Payload - ESP
The Authentication Header (AH) Mechanism
The Authentication Header information is added into the packet which is generated by the sender,
right between the Network (Layer 3) and Transport (Layer 4) Layer (see picture below).
Authentication protects your network, and the data it carries, from tampering. Tampering might
be a hacker sitting between the client and server, altering the contents of the packets sent between
the client and server, or someone trying to impersonate either the client or server, thus fooling the
other side and gaining access to sensitive data.
To overcome this problem, IPSec uses an Authentication Header (AH) to digitally sign the entire
contents of each packet. This signature provides 3 benefits:
1) Protects against replay attacks. If an attacker can capture packets, save them and modify them,
and then send them to the destination, then they can impersonate a machine when that machine is
not on the network. This is what we call a replay attack. IPSec will prevent this from happening
by including the sender's signature on all packets.
2) Protection against tampering. The signatures added to each packet by IPSec means that you
can't alter any part of a packet undetected.
3) Protection against spoofing. Each end of a connection (e.g client-server) verifies the other's
identity with the authentication headers used by IPSec.
The AH is computed on the entire packet, including payload (upper layers - 4,5,6,7) and headers
of each layer. The following picture shows us a packet using AH :
On the left you are seeing the analysis of the Authentication Header.
AH Algorithms
For point-to-point communication (e.g client to server), suitable authentication algorithms include
keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g
DES) or on one-way hash functions (e.g MD5 or SHA-1).
For multicast communication (e.g between a group of routers), one-way hash algorithms
combined with asymmetric signature algorithms are usually used, but they are also more cpu
intensive.
The Encapsulating Security Payload - ESP
The Authentication Header (AH) we spoke about will protect your data from tampering, but it
will not stop people from seeing it. For that, IPSec uses an encryption which provides the
Encapsulating Security Payload (ESP). ESP is used to encrypt the entire payload of an IPSec
packet (Payload is the portion of the packet which contains the upper layer data).
ESP is a bit more complex than AH because alone it can provide authentication, replay-proofing
and integrity checking. It acomplishes this by adding 3 separate components:
1) An ESP header
2) An ESP trailer and
3) An ESP authentication block.
Each of these components contains some of the data needed to provide the necessary
authentication and integrity checking. To prevent tampering, an ESP client has to sign the ESP
header, application data, and ESP trailer into one unit, of course ESP is used to encrypt the
application data and the ESP trailer to provide confidentiality. The combination of this
overlapping signature and encryption operation provides good security.
Let's have a look at a packet using IPSec - ESP:
IPSec can get very complicated and messy. I have tried keeping everything as simple as possible,
but you should keep in mind that this topic can be studied in far greater depth than is presented
here!
Introduction To The Internet Protocol
Introduction
Perhaps one of the most important and well known protocols is the Internet Protocol or, if you
like, IP. IP gives us the ability to uniquely identify each computer in a network or on the Internet.
When a computer is connected to a network or the Internet, it is assigned a unique IP address. If
you're connecting to the Internet, chances are you're given an IP automatically by your ISP, if
you're connecting to your LAN then you're either given the IP automatically or you manually
configure the workstation with an assigned IP.
I can't over emphasise the importance of fully understanding IP if you really want to understand
how network communications work, especially when it comes to an IP network, like the Internet.
DNS, FTP, SNMP, SMTP, HTTP and a lot of other protocols and services rely heavily on the IP
protocol in order to function correctly, so you can immediately see that IP is more than just an IP
Address on your workstation.
Now, because IP is a HUGE subject and it's impossible to cover in one or two pages, I decided to
split it into a few different sections in order to make it easy to read and learn about.
Here is a summary of what's covered:

Section 1: Binary and the Internet Protocol. Here we cover a few basic Binary concepts
and get to see how Binary and IP fit together.

Section 2: Internet Protocol Header. Find out how the Internet Protocol fits in the OSI
Model. Also includes a detailed 3d diagram of the IP Header which shows the fields that
exist in the IP Header

Section 3: Internet Protocol Classes. We get to see the 5 different IP Classes and analyse
them in Binary. Also you get to learn about the Network ID and Host ID in an IP
Address.

Section 4: Subnetting. One of the most important things you should know. Detailed
explanation on how subnetting works. Includes simple to complicated examples. You
should be comfortable with the first 3 sections in order to understand this section. For
more information, please see the Subnetting Introduction page.
So, what are you waiting for ? Let's discover and learn all about one of the most important
protocols in the networking world !
Binary & The Internet Protocol
Introduction
To understand the Internet Protocol, we need to learn and understand Binary. It is very important
to know and understand Binary because part of the IP protocol is also the "Subnetting" section
which can only be explained and understood when an IP Address is converted to Binary!
Those who are experienced in Binary can skim this section quickly, but do have a look through.
A lot of people are not aware that computers do not understand words, pictures and sounds, when
we interact with them by playing a game, reading or drawing something on the screen. The truth
is that all computers can understand is zeros (0) and ones (1) !
What we see on the screen is just an interpretation of what the computer understands, so the
information displayed is useful and meaningful to us.
Binary: Bits and Bytes
Everyone who uses the Internet would have, at one stage or another, come across the "Byte" or
"Bit" term, usually when you're downloading, you get the speed indication in bytes or KBytes per
second. We are going to see exactly what a Bit, Byte and KByte is, so you understand the terms.
To put it as simply as possible, a Bit is the smallest unit/value of Binary notation. The same way
we say 1 cent is the smallest amount of money you can have , a Bit is the same thing but not in
cents or dollars, but in Binary.
A Bit can have only one value, either a one (1) or a zero (0). So If I gave you a value of zero: 0,
then you would say that is one Bit. If I gave you two of them: 00, you would say that's two Bits.
Now, if you had 8 zeros or ones together: 0110 1010 (I put a space in between to make it easier
for the eyes) you would say that's 8 Bits or, one Byte ! Yes that is correct, 8 Bits are equal to one
Byte.
The picture below gives you some examples:
It's like saying, if you have 100 cents, that is equal to one Dollar. In the same way, 8 Bits (doesn't
matter if they are all 1s or 0s or a mixture of the two) would equal one Byte.
And to sum this all up, 1024 Bytes equal 1 KByte (Kilobyte). Why 1024 and not 1000 ? Well it's
because of the way Binary works. If you did the maths, you would find the above correct.
So what's Binary got to do with IP ?
Well, just as I explained in the introduction, computers display the zeros and ones in a way that
makes the information useful to us. The Internet Protocol works a bit like this as well, where 98%
of the time we see it in a decimal notation, but the computer understands it in binary. The picture
below gives you an example of how a computer understands an IP Address:
The above example shows an IP address in decimal notation, which we understand more easily,
this IP Address - 192.168.0.1 is then converted to Binary, which is what the computer
understands and you can see how big the number gets ! It's easier for us to remember 4 different
numbers than 32 zeros or ones !
Now, keeping in mind what we said earlier about Bits and Bytes, have you ever heard or read
people saying that an IP Address is a 32 Bit address ? It is, and you can now see why:
So to sum up all the above, we now know what Binary notation is, what a Bit, Byte and KByte is
and how Binary relates to an IP Address which is usally represented in its Decimal notation.
Understanding the conversion between Decimal and Binary
Now we're going to look at how the conversion works between Decimal and Binary. This is an
important step, because you'll probably find yourself in need of such a conversion when dealing
with complex subnets.
The conversion is not that hard once you grasp the concept. The picture below shows an IP
Address that we are going to convert to Binary. Keep in mind that the method I'm going to show
you is the same for all conversions.
We are now going to convert the first octec in the IP Address 192.168.0.1 (Decimal) to Binary, in
other words, we take the "192" and convert it to Binary and we are not going to have to do any
difficult calculations, just simple additions:
If you have read and understood the first section of this page, you should know that we need 8
bits to create one octec or, if you like, the 192 number. Each bit takes a certain value which never
changes, this value is shown in purple, right above the bit, we then select the bits we need in such
a way that the sum of all selected bits gives us the decimal number we need.
If you wanted to explain the conversion in mathematical terms, you would say that each bit is a
power of 2 (2^), for example, bit 8 is actually '2^7' = 128 in decimal, bit 7 is '2^6 = 64 in decimal,
bit 6 is '2^5' = 32 in decimal, bit 5 is '2^4' = 16 in decimal, bit 4 is '2^3' = 8 in decimal, bit 3 is
'2^2' = 4 in decimal, bit 2 is '2^1' = 2 in decimal, bit 1 is '2^0' = 1 in decimal.
Note: When calculating the decimal value of an octec (192 in the example above), the Bit
numbers do NOT represent the power of two value we must use in order to get the decimal value.
This means that Bit 1 does NOT translate to 2^1=1 in decimal.
In our example, we used the 192. As you saw, we needed bits 8 and 7 and this gave us the Binary
number of 11000000 which is 192 in Decimal. You must remember that the values of each bit
never change! For example, bit 8 always has a decimal value of 128, whereas bit 1 always takes
the value of 1. Using this method, you will find it easy to convert Decimal to Binary without the
need for complex mathematical calculations.
So let's have a look at the next octec, which is the decimal number 168:
Here again you can see that we needed to choose bits 8, 6 and 4 (in other words put a "1" in the
bit's position) in order to get a decimal value of 168. So the Binary value of 10101000 is equal to
the decimal value of 168.
Let's now look at all 4 octecs of our IP Address, in Binary:
No matter which way you convert, from Decimal to Binary or Binary to Decimal, the same
method is used so you if you understood the above you should be able to convert either way any
Binary or Decimal number.
That just about does it for this section, you're now ready for the next section !
The Internet Protocol (IP) Header
Introduction
Just like every other protocol, the Internet Protocol has a place in the OSI Model. Because it's
such an important protocol and other protocols depend upon it, it needs to be placed before them,
which is why you will find it in Layer 3 of the OSI model:
When a computer receives a packet from the network, the computer will firstly check the
destination MAC address of the packet at the Datalink layer (2) and if it passes, it's then passed
on to the Network layer
At the Network layer it will check the packet to see if the destination IP Address matches with the
computer's IP Address (if the packet is a broadcast, it will pass the network layer anyway).
From there, the packet is processed as required by the upper layers.
On the other hand, if the computer is generating a packet to send to the network then, as the
packet travels down the OSI model and reaches the Network layer, the destination and source IP
Address of this packet are added in the IP Header.
The IP Header
Now we are going to analyse the Internet Protocol header, so you can see the fields it has and
where they are placed. In here you will find the destination and source IP Address field which is
essential to every packet using the protocol.
It's worth noting that the 9th field, which is the "Protocol" field, contains some important
information that the computer uses to find out where it must pass the datagram once it strips off
the IP header.
If you remember, TCP and UDP exist on layer 4 of the OSI Model, which is the transport layer.
When data arrives at a computer and the packet is processed by each layer, it needs to know
whereabouts above to pass the data. This protocol field tells the computer to give the remaining
data to either the TCP or UDP protocol, which is directly above it.
Also, the Destination IP Address is another important field which contains the IP Address of the
destination machine.
The next section talks about the 5 different classes of IP Address.
Internet Protocol Classes - Network & Host ID
Introduction
Every protocol suite defines some type of addressing that identifies computers and networks. IP
Addresses are no exception to this "rule". There are certain values that an IP Address can take and
these have been defined by the IEEE committee (as most things).
A simple IP Address is a lot more than just a number. It tells us the network that the workstation
is part of and the node ID. If you don't understand what I am talking about, don't let it worry you
too much because we are going to analyse everything here :)
IP Address Classes and Structure
When the IEEE committee sat down to sort out the range of numbers that were going to be used
by all computers, they came out with 5 different ranges or, as we call them, "Classes" of IP
Addresses and when someone applies for IP Addresses they are given a certain range within a
specific "Class" depending on the size of their network.
To keep things as simple as possible, let's first have a look at the 5 different Classes:
In the above table, you can see the 5 Classes. Our first Class is A and our last is E. The first 3
classes ( A, B and C) are used to identify workstations, routers, switches and other devices
whereas the last 2 Classes ( D and E) are reserved for special use.
As you would already know an IP Address consists of 32 Bits, which means it's 4 bytes long. The
first octec (first 8 Bits or first byte) of an IP Address is enough for us to determine the Class to
which it belongs. And, depending on the Class to which the IP Address belongs, we can
determine which portion of the IP Address is the Network ID and which is the Node ID.
For example, if I told you that the first octec of an IP Address is "168" then, using the above
table, you would notice that it falls within the 128-191 range, which makes it a Class B IP
Address.
Understanding the Classes
We are now going to have a closer look at the 5 Classes. If you remember earlier I mentioned that
companies are assigned different IP ranges within these classes, depending on the size of their
network. For instance, if a company required 1000 IP Addresses it would probably be assigned a
range that falls within a Class B network rather than a Class A or C.
The Class A IP Addresses were designed for large networks, Class B for medium size networks
and Class C for smaller networks.
Introducing Network ID and Node ID concepts
We need to understand the Network ID and Node ID concept because it will help us to fully
understand why Classes exist. Putting it as simply as possible, an IP Address gives us 2 pieces of
valuable information:
1) It tells us which network the device is part of (Network ID).
2) It identifies that unique device within the network (Node ID).
Think of the Network ID as the suburb you live in and the Node ID your street in that suburb.
You can tell exactly where someone is if you have their suburb and street name. In the same way,
the Network ID tells us which network a particular computer belongs to and the Node ID
identifies that computer from all the rest that reside in the same network.
The picture below gives you a small example to help you understand the concept:
Explanation:
In the above picture, you can see a small network. We have assigned a Class C IP Range for this
network. Remember that Class C IP Addresses are for small networks. Looking now at Host A,
you will see that its IP Address is 192.168.0.2. The Network ID portion of this IP Address is in
blue, while the Host ID is in orange.
I suppose the next question someone would ask is: How do I figure out which portion of the IP
Address is the Network ID and which is the Host ID ?
That's what we are going to answer next.
The Network and Node ID of each Class
The network Class helps us determine how the 4 byte, or 32 Bit, IP Address is divided between
network and node portions.
The table below shows you (in binary) how the Network ID and Node ID changes depending on
the Class:
Explanation:
The table above might seem confusing at first but it's actually very simple. We will take Class A
as an example and analyse it so you can understand exactly what is happening here:
Any Class A network has a total of 7 bits for the Network ID (bit 8 is always set to 0) and 24 bits
for the Host ID. Now all we need to do is calculate how much 7 bits is:
2 to the power of 7 = 128 Networks and for the hosts : 2 to the power of 24 = 16,777,216 hosts in
each Network, of which 2 cannot be used because one is the Network Address and the other is the
Network Broadcast address (see the table towards the end of this page). This is why when we
calculate the "valid" hosts in a network we always subtract "2". So if I asked you how many
"valid" hosts can you have a on Class A Network, you should answer 16,777,214 and NOT
16,777,216.
Below you can see all this in one picture:
The same story applies for the other 2 Classes we use, that's Class B and Class C, the only
difference is that the number of networks and hosts changes because the bits assigned to them are
different for each class.
Class B networks have 14 bits for the Network ID (Bits 15, 16 are set and can't be changed) and
16 bits for the Host ID, that means you can have up to '2 to the power of 14' = 16,384 Networks
and '2 to the power of 16' = 65,536 Hosts in each Network, of which 2 cannot be used because
one is the Network Address and the other is the Network Broadcast address (see the table towards
the end of this page). So if I asked you how many "valid" hosts can you have a on Class B
Network, you should answer 65,534 and NOT 65,536.
Class C networks have 21 bits for the Network ID (Bits 22, 23, 24 are set and can't be changed)
and 8 bits for the Host ID, that means you can have up to '2 to the power of 21' = 2,097,152
Networks and '2 to the power of 8' = 256 Hosts in each Network, of which 2 cannot be used
because one is the Network Address and the other is the Network Broadcast address (see the table
towards the end of this page). So if I asked you how many "valid" hosts can you have a on Class
C Network, you should answer 254 and NOT 256.
Now, even though we have 3 Classes of IP Addresses that we can use, there are some IP
Addresses that have been reserved for special use. This doesn't mean you can't assign them to a
workstation but in the case that you did, it would create serious problems within your network.
For this reason it's best that you avoid using these IP Addresses.
The following table shows the IP Addresses that you should avoid using:
IP Address
Function
Network 0.0.0.0
Refers to the default route. This route is to simplify routing tables used by IP.
Network 127.0.0.0
Reserved for Loopback. The Address 127.0.0.1 is often used to refer to the local host. Using this
Address, applications can address a local host as if it were a remote host.
IP Address with all host bits set to "0" (Network Address) e.g 192.168.0.0
Refers to the actual network itself. For example, network 192.168.0.0 can be used to identify
network 192.168. This type of notation is often used within routing tables.
IP Address with all node bits set to "1" (Subnet / Network Broadcast) e.g 192.168.255.255
IP Addresses with all node bits set to "1" are local network broadcast addresses and must NOT be
used.
Some examples: 125.255.255.255 (Class A) , 190.30.255.255 (Class B), 203.31.218.255 (Class
C). See "Multicasts" & "Broadcasts" for more info.
IP Address with all bits set to "1" (Network Broadcast) e.g 255.255.255.255
The IP Address with all bits set to "1" is a broadcast address and must NOT be used. These are
destined for all nodes on a network, no matter what IP Address they might have.
Now make sure you keep to the above guidelines because you're going to bump into a lot of
problems if you don't !
IMPORTANT NOTE: It is imperative that every network, regardless of Class and size, has a
Network Address (first IP Address e.g 192.168.0.0 for Class C network) and a Broadcast Address
(last IP Address e.g 192.168.0.255 for Class C network), as mentioned in the table and
explanation diagrams above, which cannot be used.
So when calculating available IP Addresses in a network, always remember to subtract 2 from the
number of IP Addresses within that network.
That all pretty much covers this section.
Next, is the Subnetting section, and before you proceed, make sure you're comfortable with the
new concepts and material we have covered, otherwise subnetting will be very hard to
understand.
Introduction To The Open Systems Interconnect Model (OSI)
Introduction
OSI is a standard description or "reference model" for how messages should be transmitted
between any two points in a telecommunication network. Its purpose is to guide product
implementors so that their products will consistently work with other products.
The Model
The OSI model was created by the IEEE committee so different vendors products would work
with each other. You see the problem was that when HP decided to create a network product, it
would be incompatible with similar products of a different vendor e.g IBM. So when you bought
40 network cards for your company, you would make sure that the rest of the equipment would be
from the same vendor, to ensure compatibility. As you would understand things were quite
messy, until the OSI model came into the picture.
As most would know, the OSI
model consists of 7 layers.
Each layer has been designed to do a specific task. Starting from the top layer (7) we will see how
the data which you type gets converted into segments, the segments into datagrams and the
datagrams into packets, the packets into frames and then the frames are sent down the wire,
usually twisted pair, to the receiving computer.
Please select one of the 7 layers by clicking on it, or simply use the menu :)
The OSI flash below is provided to help you futher understand the functionality of the OSI
model:
The picture below is another quick summary of the OSI model:
When you're finished reading through the OSI model, to understand how data travels through the
layers and clearly see the header which each layer add\removes, visit the Data Encapsulation Decapsulation page.
OSI Layer 1 - Physical Layer
The first four layers define how data is transmitted end-to-end.
There are no protocols which work at the Physical layer. As mentioned, Ethernet, Token Ring and
other topologies are specified here.
Layer 1 - The Physical Layer
The Physical layer has two responsibilities: it sends bits and receives bits. Bits come only in
values of 1 or 0. The Physical layer communicates directly with the various types of actual
communication media. Different kinds of media represent these bit values in different ways.
Specific protocols are needed for each type of media to describe the proper bit patterns to be used,
how data is encoded into media signals and the various qualities of the physical media's
attachment interface.
The Physical layer specifications specify the electrical, mechanical and functional requirements
for activating, maintaining and deactivating a physical link between end systems. At the physical
layer, the interface between the Data Terminal Equipment (DTE) and the Data CircuitTerminating Equipment (DCE) is identified. The Physical layer's connectors (RJ-45, BNC e.c.t)
and different physical topologies (Bus, Star, Hybrid networks) are defined by the OSI as
standards, allowing different systems to communicate.
We talk more about the Physical topologies in the Topologies section. Please refer to it if you
want to read more. You can also find out more about Ethernet at the Ethernet section.
OSI Layer 2 - Datalink Layer
The first four layers define how data is transmitted end-to-end.
Some common protocols which work at the Datalink layer are: ARP, RARP, DCAP.
Layer 2 - The Datalink Layer
The Datalink ensures that messages are delivered to the proper device and translates messages
from the Network layer into bits for the Physical layer to transmit. It formats the message into
data frames (notice how we are not using the term segments) and adds a customized header
containing the hardware destination and source address.
This added information forms a sort of capsule that surrounds the original message (or data),
think of it like grabbing a letter which has information and putting it into an envelope. The
envelope is only used to get the letter to its destination, right? So when it arrives at the addressee,
the envelope is opened and discarded, but the letter isn't because it has the information the
addressee needs.
Data traveling through a network works in a similair manner. Once it gets to the destination, it
will be opened and read (processed). This is illustrated in the Data Encapsulation - Decapsulation
section.
The Datalink layer is subdivided into two other sublayers, the Media Access Control (MAC) and
the Logical Link Control (LLC). The figure below illustrates this:
Media Access Control (MAC) 802.3
This defines how packets are placed on the media (cable). Contention media (Ethernet) access is
first come first served access where everyone shares the same bandwidth. Physical addressing is
defined here. What's Physical addressing? It's simple.
You will come across 2 addressing terms, 1)Logical addressing 2)Physical addressing.
Logical addressing is basically the address which is given by software e.g IP address.When you
get an IP address, this is considered a "logical address" which is provided to you after your
TCP/IP stack is loaded.
Physical addressing is an address which is given not by the software, but the hardware. Every
network card has a "MAC" address which is burnt into the card's eprom (a special memory chip)
and this special address is used to uniquely identify your computer's network card from all the
others on the network.
There is a whole page dedicated to MAC Addressing if you would like to read more about it.
Logical Link Control (LLC) 802.2
This sublayer is responsible for identifying Network layer protocols and then encapsulating them
when they are about to be transmitted onto the network or decapsulate them when it receives a
packet from the network and pass it onto the layer above it, which is the Network layer. An LLC
header tells the Datalink layer what to do with a packet once a frame is received. For example, a
host (computer) will receive a frame and then look in the LLC header to understand that the
packet is destined for the IP protocol at the Network layer. The LLC can also provide flow
control and sequencing of control bits.
If you are finding all this a bit too difficult to understand, I suggest that you read more on the OSI
model and check the Data Encapsulation - Decapsulation page which explains how the data
travels up and down the OSI model and shows how each layer adds or removes its header
information depending on the direction of the data.
OSI Layer 3 - Network Layer
The first four layers define how data is transmitted end-to-end.
Some common protocols which work at the Network layer are: IP, DHCP, ICMP, IGRP, EIGRP,
RIP, RIP2, MARS.
Layer 3 - The Network Layer
The Network layer is responsible for routing through an internetwork and for networking
addressing. This means that the Network layer is responsible for transporting traffic between
devices that are not locally attached. Routers, or other layer-3 devices, are specified at the
Network layer and provide routing services in an internetwork.
In the Open Systems Interconnection (OSI) communications model, the Network layer knows the
address of the neighboring nodes in the network, packages output with the correct network
address information, selects routes and quality of service and recognizes and forwards to the
Transport layer incoming messages for local host domains. Among existing protocol that
generally map to the OSI network layer are the Internet Protocol (IP) part of TCP/IP and NetWare
IPX/SPX. Both IP Version 4 and IP Version 6 (IPv6) map to the OSI network layer.
As mentioned above, the Internet Protocol works on this layer. This means that when you see an
IP address, for example 192.168.0.1, this IP address maps to the Network layer in the OSI model,
in other words only the Network layer deals with or cares about IP addresses in the OSI model.
To keep things simple, IP is analysed under the "Protocols" section.
OSI Layer 4 - Transport Layer
The first four layers define how data is transmitted end-to-end.
Some common protocols which work at the Transport layer are: TCP, UDP.
Layer 4- The Transport Layer
The Transport layer is responsible for providing mechanisms for multiplexing upper-layer
application, session establishment, data transfer and tear down of virtual circuits. It also hides
details of any network-dependent information from the higher layers by providing transparent
data transfer.
Services located in the Transport layer both segment and reassemble data from upper-layer
applications and unite it onto the same data stream. Some of you might already be familiar with
TCP and UDP and know that TCP is a reliable service and UDP is not. Application developers
have their choice of the two protocols when working with TCP/IP protocols.
As mentioned above, the Transport layer provides different mechanisms for the transfer of data
from one computer to another. Below is a brief diagram which tells you a bit about the protocols.
These protocols are also analysed in the Protocols area.
OSI Layer 5 - Session Layer
The last 3 layers of the OSI model are reffered to the "Upper" layers. These layers are
responsible for applications communicating between hosts. None of the upper layers know
anything about networking or network addresses.
Some common protocols which work at the Session layer are: DNS, LDAP, NetBIOS.
Layer 5 - The Session Layer
The Session layer is responsible for setting up, managing and then tearing down sessions between
Presentation layer entities. The Session layer also provides dialog control between devices, or
nodes. It coordinates communication between systems and serves to organise their
communication by offering three different modes: simplex, half-duplex and full-duplex. The
session layer basically keeps one application's data separate from other application's data.
Some examples of Session-layer protocols are:
Network File Systrem (NFS) : Was developed by Sun Microsystems and used with TCP/IP and
Unix workstations to allow transparent access to remote resources.
Structured Query Language (SQL): Was developed by IBM to provide users with a simpler way
to define their information requirements on both local and remote systems.
Remote Procedure Call (RPC): Is a broad client/server redirection tool used for disparate service
environments. Its procedures are created on clients and performed on servers.
X Window: Is widely used by intelligent terminals for communicating with remote Unix
computers, allowing them to operate as though they were locally attached monitors.
OSI Layer 6 - Presentation Layer
The last 3 layers of the OSI model are reffered to the "Upper" layers. These layers are
responsible for applications communicating between hosts. None of the upper layers know
anything about networking or network addresses.
There are no protocols which work specificly at the Presentation layer, but the protocols which
work at the Application layer are said to work on all 3 upper layers.
Layer 6- The Presentation Layer
The Presentation Layer gets its name from its purpose: It presents data to the Application layer.
It's basically a translator and provides coding and conversion functions. A successful data transfer
technique is to adapt the data into a standard format before transmission. Computers are
configured to receive this generically formatted data and then convert the data back into its native
format for reading. By providing translation services, the Presentation layer ensures that data
transferred from the Application layer of one system can be read by the Application layer of
another host.
The OSI has protocol standards that define how standard data should be formatted. Tasks like
data compression, decompression, encryption and decryption are associated with this layer. Some
Presentation layer standards are involved in multimedia operations. The following serve to direct
graphic and visual image presentation :
JPEG: The Joint Photographic Experts Group brings these photo standards to us.
MIDI: The Musical Intrument Digital Interface is used for digitized music.
MPEG: The Moving Pictures Experts Group's standard for the compression and coding of motion
video for CD's is very popular.
QuickTime: This is for use with Machintosh or Power PC programs, it manages audio and video
applications.
OSI Layer 7 - Application Layer
The last 3 layers of the OSI model are reffered to the "Upper" layers. These layers are
responsible for applications communicating between hosts. None of the upper layers know
anything about networking or network addresses.
FTP, TFTP, Telnet, SMTP and other protocols work on the first three layers of the OSI model,
which obviously includes the Application layer.
Layer 7- The Application Layer
The Application layer of the OSI model is where users communicate with the computer. The
Application layer is responsible for identifying and establishing the availability of the intended
communication partner and determining if sufficient resources for the intended communication
exist. The user interfaces with the computer at the application layer.
Although computer applications sometimes require only desktop resources, applications may
unite communicating components from more than one network application, for example, file
transfers, e-mail, remote access, network management activities, client/server processes.
There are various protocols which are used at this layer. Definition of a"Protocol" is a set of rules
by which two computers communicate. In plain English, you can say that a protocol is a
language, for example, English. For me to speak to you and make sense, I need to structure my
sentence in a "standard" way which you will understand. Computer communication works pretty
much the same way. This is why we have so many different protocols, each one for a specific
task.
Data Encapsulation & Decapsulation in the OSI Model
Introduction
Here we are going to explain in detail how data travels through the OSI model. You must keep in
mind that the OSI model is a guideline. It tells the computer what it's supposed to do when data
needs to be sent or when data is received.
In order to make it easier for most, there is a movie file available which will show your exactly
what we are about to analyse. Click here to to obtain the encap-decap movie (1MB). You will
need Windows media player to view it.
Our Study Case
We are going to analyse an example in order to try and understand how data encapsulation and
decapsulation works. This should make it easier for most people.
Try to see it this way :
When a car is built in a factory, one person doesn't do all the jobs, rather it's put into a production
line and as the car moves through, each person will add different parts to it so when it comes to
the end of the production line, it's complete and ready to be sent out to the dealer.
The same story applies for any data which needs to be sent from one computer to another. The
OSI model which was created by the IEEE committee is to ensure that everyone follows these
guidelines (just like the production line above) and therefore each computer will be able to
communicate with every other computer, regardless of whether one computer is a Macintosh and
the other is a PC.
One important piece of information to keep in mind is that data flows 2 ways in the OSI model,
DOWN (data encapsulation) and UP (data decapsulation).
The picture below is an example of a simple data transfer between 2 computers and shows how
the data is encapsulated and decapsulated:
Explanation :
The computer in the above picture needs to send some data to another computer. The Application
layer is where the user interface exists, here the user interacts with the application he or she is
using, then this data is passed to the Presentation layer and then to the Session layer. These three
layer add some extra information to the original data that came from the user and then passes it to
the Transport layer. Here the data is broken into smaller pieces (one piece at a time transmitted)
and the TCP header is a added. At this point, the data at the Transport layer is called a segment.
Each segment is sequenced so the data stream can be put back together on the receiving side
exactly as transmitted. Each segment is then handed to the Network layer for network addressing
(logical addressing) and routing through the internet network. At the Network layer, we call the
data (which includes at this point the transport header and the upper layer information) a packet.
The Network layer add its IP header and then sends it off to the Datalink layer. Here we call the
data (which includes the Network layer header, Transport layer header and upper layer
information) a frame. The Datalink layer is responsible for taking packets from the Network layer
and placing them on the network medium (cable). The Datalink layer encapsulates each packet in
a frame which contains the hardware address (MAC) of the source and destination computer
(host) and the LLC information which identifies to which protocol in the prevoius layer (Network
layer) the packet should be passed when it arrives to its destination. Also, at the end, you will
notice the FCS field which is the Frame Check Sequence. This is used for error checking and is
also added at the end by the Datalink layer.
If the destination computer is on a remote network, then the frame is sent to the router or gateway
to be routed to the desination. To put this frame on the network, it must be put into a digital
signal. Since a frame is really a logical group of 1's and 0's, the Physical layer is responsible for
encapsulating these digits into a digital signal which is read by devices on the same local
network.
There are also a few 1's and 0's put at the begining of the frame, only so the receiving end can
synchronize with the digital signal it will be receiving.
Below is a picture of what happens when the data is received at the destination computer.
Explanation :
The receiving computer will firstly synchronize with the digital signal by reading the few extra
1's and 0's as mentioned above. Once the synchonization is complete and it receives the whole
frame and passes it to the layer above it which is the Datalink layer.
The Datalink layer will do a Cyclic Redundancy Check (CRC) on the frame. This is a
computation which the comupter does and if the result it gets matches the value in the FCS field,
then it assumes that the frame has been received without any errors. Once that's out of the way,
the Datalink layer will strip off any information or header which was put on by the remote
system's Datalink layer and pass the rest (now we are moving from the Datalink layer to the
Network layer, so we call the data a packet) to the above layer which is the Network layer.
At the Network layer the IP address is checked and if it matches (with the machine's own IP
address) then the Network layer header, or IP header if you like, is stripped off from the packet
and the rest is passed to the above layer which is the Transport layer. Here the rest of the data is
now called a segment.
The segment is processed at the Transport layer, which rebuilds the data stream (at this level on
the sender's computer it was actually split into pieces so they can be transferred) and
acknowledges to the transmitting computer that it received each piece. It is obvious that since we
are sending an ACK back to the sender from this layer that we are using TCP and not UDP.
Please refer to the Protocols section for more clarification. After all that, it then happily hands the
data stream to the upper-layer application.
You will find that when analysing the way data travels from one computer to another most people
never analyse in detail any layers above the Transport layer. This is because the whole process of
getting data from one computer to another involves usually layers 1 to 4 (Physical to Transport)
or layer 6 (Session) at the most, depending on the type of data.
Introduction To Routing
Introduction
Routing is one of the most important features in a network that needs to connect with other
networks. In this page we try to explain the difference between Routed and Routing protocols and
explain different methods used to achieve the routing of protocols.The fact is that if routing of
protocols was not possible, then we wouldn't be able to comminucate using computers because
there would be no way of getting the data across to the other end !
Definition
Routing is used for taking a packet (data) from one device and sending it through the network to
another device on a different network. If your network has no routers then you are not routing.
Routers route traffic to all the networks in your internetwork. To be able to route packets, a router
must know the following :

Destination address

Neighbor routers from which it can lean about remote networks

Possible routes to all remote networks

The best route to each remote network

How to maintain and verify routing information
Before we go on, I would like to define 3 networking terms :
Convergence: The process required for all routers in an internetwork to update their routing tables
and create a consistent view of the network, using the best possible paths. No user data is passed
during convergence.
Default Route: A "standard" route entry in a routing table which is used as a first option. Any
packets sent by a device will be sent first to the default route. If that fails, it will try alternative
routes.
Static Route: A permanent route entered manually into a routing table. This route will remain in
the table, even if the link goes down. It can only be erased manually.
Dynamic Route: A route entry which is dynamically (automatically) updated as changes to the
network occur. Dynamic routes are basically the opposite to static routes.
We start off with the explanation of the IP routing process and move onto routed protocols, then
tackle the routing protocols and finally the routing tables. There is plenty to read about, so grab
that tea or coffee and let's start !
Please click on one of the following sections:
The IP Routing Process
Routed Protocols
Routing Protocols
The IP Routing Process
Introduction
We are going to take a look at what happens when routing occurs on a network. When I was new
to the networking area, I thought that all you needed was the IP Address of the machine you
wanted to contact but so little did I know. You actually need a bit more information than just the
IP Address !
The process we are going to explain is fairly simple and doesn't really change, no matter how big
your network is.
The Example:
In our example, we have 2 networks, Network A and Network B. Both networks are connected
via a router (Router A) which has 2 interfaces: E0 and E1. These interfaces are just like the
interface on your network card (RJ-45), but built into the router.
Now, we are going to describe step by step what happens when Host A (Network A) wants to
communicate with Host B (Network B) which is on a different network.
1) Host A opens a command prompt and enters >Ping 200.200.200.5.
2) IP works with the Address Resolution Protocol (ARP) to determine which network this packet
is destined for by looking at the IP address and the subnet mask of the Host A. Since this is a
request for a remote host, which means it is not destined to be sent to a host on the local network,
the packet must be sent to the router (the gateway for Network A) so that it can be routed to the
correct remote network (which is Network B).
3) Now, for Host A to send the packet to the router, it needs to know the hardware address of the
router's interface which is connected to its network (Network A), in case you didn't realise, we are
talking about the MAC (Media Access Control) address of interface E0. To get the hardware
address, Host A looks in its ARP cache - a memory location where these MAC addresses are
stored for a few seconds .
4) If it doesn't find it in there it means that either a long time has passed since it last contacted the
router or it simply hasn't resolved the IP address of the router (192.168.0.1) to a hardware address
(MAC). So it then sends an ARP broadcast. This broadcast contains the following "What is the
hardware (MAC) address for IP 192.168.0.1 ? ". The router identifies that IP address as its own
and must answer, so it sends back to Host A a reply, giving it the MAC address of its E0
interface. This is also one of the reasons why sometimes the first "ping" will timeout. Because it
takes some time for an ARP to be sent and the requested machine to respond with its MAC
address, by the time all that happens, the TTL (Time To Live) of the first ping packet has expired,
so it times out !
5) The router responds with the hardware address of its E0 interface, to which the 192.168.0.1 IP
is bound. Host A now has everything it needs in order to transmit a packet out on the local
network to the router. Now, the Network Layer hands down to the Datalink Layer the packet it
generated with the ping (ICMP echo request), along with the hardware address of the router. This
packet includes the source and destination IP address as well as the ICMP echo request which
was specified in the Network Layer.
6) The Datalink Layer of Host A creates a frame, which encapsulates the packet with the
information needed to transmit on the local network. This includes the source and destination
hardware address (MAC) and the type field which specifies the Network Layer protocol e.g IPv4
(that's the IP version we use), ARP. At the end of the frame, in the FCS portion of the frame, the
Datalink Layer will stick a Cyclic Redundancy Check (CRC) to make sure the receiving machine
(the router) can figure out if the frame it received has been corrupted. To learn more on how the
frame is created, visit the Data Encapsulation - Decapsulation.
7) The Datalink Layer of Host A hands the frame to the Physical layer which encodes the 1s and
0s into a digital signal and transmits this out on the local physical network.
8)The signal is picked up by the router's E0 interface and reads the frame. It will first do a CRC
check and compare it with the CRC value Host A added to this frame, to make sure the frame is
not corrupt.
9)After that, the destination hardware address (MAC) of the received frame is checked. Since this
will be a match, the type field in the frame will be checked to see what the router should do with
the data packet. IP is in the type field, and the router hands the packet to the IP protocol running
on the router. The frame is stripped and the original packet that was generated by Host A is now
in the router's buffer.
10) IP looks at the packet's destination IP address to determine if the packet is for the router.
Since the destination IP address is 200.200.200.5, the router determines from the routing table
that 200.200.200.0 is a directly connected network on interface E1.
11) The router places the packet in the buffer of interface E1. The router needs to create a frame
to send the packet to the destination host. First, the router looks in the ARP cache to determine
whether the hardware address has already been resolved from a prior communication. If it is not
in the ARP cache, the router sends an ARP broadcast out E1 to find the hardware address of
200.200.200.5
12) Host B responds with the hardware address of its network interface card with an ARP reply.
The router's E1 interface now has everything it needs to send the packet to the final destination.
13)The frame generated from the router's E1 interface has the source hardware address of E1
interface and the hardware destination address of Host B's network interface card. However, the
most important thing here is that even though the frame's source and destination hardware address
changed at every interface of the router it was sent to and from, the IP source and destination
addresses never changed. The packet was never modified at all, only the frame changed.
14) Host B receives the frame and runs a CRC. If that checks out, it discards the frame and hands
the packet to IP. IP will then check the destination IP address. Since the IP destination address
matches the IP configuration of Host B, it looks in the protocol field of the packet to determine
the purpose of the packet.
15) Since the packet is an ICMP echo request, Host B generates a new ICMP echo-reply packet
with a source IP address of Host B and a destination IP address of Host A. The process starts all
over again, except that it goes in the opposite direction. However, the hardware address of each
device along the path is already known, so each device only needs to look in its ARP cache to
determine the hardware (MAC) address of each interface.
And that just about covers our routing analysis. If you found it confusing, take a break and come
back later on and give it another shot. Its really simple once you grasp the concept of routing.
Routed Protocols
Introduction
We all understand that TCP/IP, IPX-SPX are protocols which are used in a Local Area Network
(LAN) so computers can communicate between with each other and with other computers on the
Internet.
Chances are that in your LAN you are most probably running TCP/IP. This protocol is what we
call a "routed" protocol. The term "routed" refers to something which can be passed on from one
place (network) to another. In the example of TCP/IP, this is when you construct a data packet
and send it across to another computer on the Internet
This ability to use TCP/IP to send data across networks and the Internet is the main reason it's so
popular and dominant. If you're thinking also of NetBeui and IPx/SPX, then note that NetBeui is
not a routed protocol, but IPX/SPX is! The reason for this is actually in the information a packet
holds when it uses one of the protocols.
Let me explain:
If you looked at a TCP/IP or IPX/SPX packet, you will notice that they both contain a "network"
layer. For TCP/IP, this translates to the IP layer (Layer 3), as for IPX/SPX, it's the IPX layer
(Layer 3). To make it easy to understand, I will use TCP/IP as an example.
In the picture below, you can see a TCP/IP packet within an Ethernet II Frame (The frame is like
an "envelope" which encapsulates the TCP/IP packet):
Looking closely, you will notice that Layer 3 (Network Layer) contains the IP header. It is within
this section the computer puts the Source and Destination IP number. Thanks to the existence of
this IP header, we are able to put a destination IP which can be one that's not on our network, and
the computer will figure it out after completing a simple calculation and know if it needs to send
this data to the router for it to be sent to its destination. You can read more on Layer 3 by visiting
the OSI page.
IPX/SPX contains a similar field which gives it the same ability, which is to send packets over to
different networks.
NetBeui on the other hand has no such information! This means that NetBeui has no information
about the destination network to which it needs to send the data, as it was developed for LAN use
only, or you could say that all hosts are considered to be on the same logical network and all
resources are considered to be local. This classifies NetBeui as a "non routed" protocol.
Routing Protocols
Introduction
Routing protocols were created for routers. These protocols have been designed to allow the
exchange of routing tables, or known networks, between routers. There are a lot of different
routing protocols, each one designed for specific network sizes, so I am not going to be able to
mention and analyse them all, but I will focus on the most popular.
The two main types of routing: Static routing and Dynamic routing
The router learns about remote networks from neighbor routers or from an administrator. The
router then builds a routing table, the creation of which I will explain in detail, that describes how
to find the remote networks. If the network is directly connected then the router already knows
how to get to the network. If the networks are not attached, the router must learn how to get to the
remote network with either static routing (administrator manualy enters the routes in the router's
table) or dynamic routing (happens automaticlly using routing protocols).
The routers then update each other about all the networks they know. If a change occurs e.g a
router goes down, the dynamic routing protocols automatically inform all routers about the
change. If static routing is used, then the administrator has to update all changes into all routers
and therefore no routing protocol is used.
Only Dynamic routing uses routing protocols, which enable routers to:




Dynamically discover and maintain routes
Calculate routes
Distribute routing updates to other routers
Reach agreement with other routers about the network topology
Statically programmed routers are unable to discover routes, or send routing information to other
routers. They send data over routes defined by the network Administrator.
A Stub network is so called because it is a dead end in the network. There is only one route in and
one route out and, because of this, they can be reached using static routing, thus saving valuable
bandwidth.
Dynamic Routing Protocols
There are 3 types of Dynamic routing protocols, these differ mainly in the way that they discover
and make calculations about routes (click to select):
1) Distance Vector
2) Link State
3) Hybrid

Distance Vector routers compute the best path from information passed to them from
neighbors

Link State routers each have a copy of the entire network map

Link State routers compute best routes from this local map
The Table below (clickable) shows the main characteristics of a few different types of dynamic
routing protocols:
You can also clasify the routing protocols in terms of their location on a network. For example,
routing protocols can exist in, or between, autonomous systems.
Exterior Gateway Protocols (EGP's) are found between autonomous systems, whereas
Interior Gateway Protocols (IGP'S) are found Distance Vector Routing Protocols
Introduction
Distance Vector routing protocols use frequent broadcasts (255.255.255.255 or FF:FF:FF:FF) of
their entire routing table every 30 sec. on all their interfaces in order to communicate with their
neighbours. The bigger the routing tables, the more broadcasts. This methodology limits
significantly the size of network on which Distance Vector can be used.
Routing Information Protocol (RIP) and Interior Gateway Routing Protocol (IGRP) are two very
popular Distance Vector routing protocols. You can find links to more information on these
protocols at the bottom of the page. (That's if you haven't had enough by the time you get there !)
Distance Vector protocols view networks in terms of adjacent routers and hop counts, which also
happens to be the metric used. The "hop" count (max of 15 for RIP, 16 is deemed unreachable
and 255 for IGMP), will increase by one every time the packet transits through a router.
So the router makes decisions about the way a packet will travel, based on the amount of hops it
takes to reach the destination and if it had 2 different ways to get there, it will simply send it via
the shortest path, regardless of the connection speed. This is known as pinhole congestion.
Below is a typical routing table of a router which uses Distance Vector routing protocols:
Let's explain what is happening here :
In the above picture, you see 4 routers, each connected with its neighbour via some type of WAN
link e.g ISDN.
Now, when a router is powered on, it will immediately know about the networks to which each
interface is directly connected. In this case Router B knows that interface E0 is connected to the
192.168.0.0 network and the S0 interface is connected to the 192.168.10.0 network.
Looking again at the routing table for Router B, the numbers you see on the right hand side of the
interfaces are the "hop counts" which, as mentioned, is the metric that distance vector protocols
use to keep track on how far away a particular network is. Since these 2 networks are connected
directly to the router's interface, they will have a value of zero (0) in the router's table entry. The
same rule applies for every router in our example.
Remember we have "just turn the routers on", so the network is now converging and that means
that there is no data being passed. When I say "no data" I mean data from any computer or server
that might be on any of the networks. During this "convergence" time, the only type of data being
passed between the routers is that which allows them to populate their routing tables and after
that's done, the routers will pass all other types of data between them. That's why a fast
convergence time is a big advantage.
One of the problems with RIP is that it has a slow convergence time.
Let's explain what we see :
In the above picture, the network is said to have "converged", in other words, all routers on the
network have populated their routing table and are completly aware of the networks they can
contact. Since the network is now converged, computers in any of the above networks can contact
each other.
Again, looking at one of the routing tables, you will notice the network address with the exit
interface on the right and next to that is the hop count to that network. Remember that RIP will
only count up to 15 hops, after which the packet is discarded (on hop 16).
Each router will broadcast its entire routing table every 30 seconds.
Routing based on Distance Vector can cause a lot of problems when links go up and down, this
could result in infinite loops and can also de-synchronise the network.
Routing loops can occur when every router is not updated close to the same time.
Let's have a look at the problem before we look at the various solutions:
Let's explain :
In the above picture you can see 5 routers of which routers A and B are connected with Router C,
and they all end up connecting via routers D and E to Network 5.
Now as the above picture shows, Network 5 fails.
All routers know about Network 5 from Router E. For example, Router A, in its tables, has a path
to Network 5 through routers B,D and E.
When Network 5 fails, Router E knows about it since it's directly connected to it and tells Router
D about it on its next update (when it will broadcast its entire routing table). This will result in
Router D stopping routing data to Network 5 through Router E. But as you can see in the above
picture, routers A B and C don't know about Network 5 yet, so they keep sending out update
information. Router D will eventually send out its update and cause Router B to stop routing to
Network 5, but routers A and C are still not updated. To them, it appear that Network 5 is still
available through Router B with a metric of 3 !
Now Router A sends its regular broadcast of its entire routing table which includes reachability
for Network 5. Routers C and B receive the wonderful news that Network 5 can be reached from
Router A, so they send out the information that Network 5 is now available !
From now on, any packet with a destination of Network 5 will go to Router A then to Router B
and from there back to Router A (remember that Router B got the good news that Network 5 is
available via Router A).
So this is where things get a bit messy and you have that wonderful loop, where data just gets
passed around from one router to another. Seems like they are playing ping pong :)
To deal with these problems we use the following techniques:
Maximum Hop Count
The routing loop we just looked at is called "counting to infinity" and it is caused by gossip and
wrong information being communicated between the routers. Without something to protect
against this type of a loop, the hop count will keep on increasing each time the packet goes
through a router ! One way of solving this problem is to define a maximum hop count. Distance
Vector (RIP) permits a hop count of up to 15, so anything that needs 16 hops is unreachable. So if
a loop occurred, it would go around the network until the packet reached a hop count of 15 and
the next router would simply discard the packet.
Split Horizon
Works on the principle that it's never useful to send information about a router back to the
destination from which the original packet came. So if for example I told you a joke, it's pointless
you telling me that joke again !
In our example it would have prevented Router A from sending the updated information it
received from Router B back to Router B.
Route Poisoning : Alternative to split horizon, when a router receives information about a route
from a particular network, the router advertises the route back to that network with the metric of
16, indicating that the destination is unreachable.
In our example, this means that when Network 5 goes down, Router E initiates router poisoning
by entering a table entry for Network 5 as 16, which basically means it's unreachable. This way,
Router D is not susceptible to any incorrect updates about the route to Network 5. When Router D
receives a router poisoning from Router E, it sends an update called a poison reverse, back to
Router E. This make sure all routes on the segment have received the poisoned route information.
Route poisoning, used with hold-downs (see section below) will certainly speed up convergence
time because the neighboring routers don't have to wait 30 seconds before advertising the
poisoned route.
Hold-Down Timers
Routers keep an entry for the network-down state, allowing time for other routers to recompute
for this topology change, this way, allowing time for either the downed router to come back or the
network to stabilise somewhat before changing to the next best route.
When a router receives an update from a neighbor indicating that a previously accessible network
is not working and is inaccessible, the hold-down timer will start. If a new update arrives from a
neighbor with a better metric than the original network entry, the hold-down is removed and data
is passed. But an update is received from a neighbor router before the hold-down timer expires
and it has a lower metric than the previous route, therefore the update is ignored and the holddown timer keeps ticking. This allows more time for the network to converge.
Hold-down timers use triggered updates, which reset the hold-down timer, to alert the neighbor's
routers of a change in the network. Unlike update messages from neighbor routers, triggered
updates create a new routing table that is sent immediatley to neighbor routers because a change
was detected in the network.
There are three instances when triggered updates will reset the hold-down timer:
1) The hold-down timer expires
2) The router received a processing task proportional to the number of links in the internetwork.
3) Another update is received indicating the network status has changed.
In our example, any update received by Router B from Router A, would not be accepted until the
hold-down timer expires. This will ensure that Router B will not receive a "false" update from
any routers that are not aware that Network 5 is unreachable. Router B will then send a update
and correct the other routers' tables.
Please select the Distance Vector protocol you want to read about:
Routing Information Protocol - RIP
Interior Gateway Routing Protocol - IGRPwithin autonomous systems:
Example of an EGP is the Border Gateway Protocol (BGP) which is also used amongst the
Internet routers, whereas examples of IGP protocols are RIP, IGRP, EIGRP.
Routing Information Protocol - RIP
Introduction
Routing Information Protocol (RIP) is a true Distance-Vector routing protocol. It sends the
complete routing table out to all active interfaces every 30 seconds. RIP only uses hop count to
determine the best way to a remote network, but it has a maximum allowable hop count of 15,
meaning that 16 is deemed unreachable. RIP works well in small networks, but it is inefficient on
large networks with slow WAN links or on networks with large number of routers installed.
RIP comes in two different versions. RIP version 1 uses only classful routing, which means that
all devices in the network must use the same subnet mask. This is because RIP version 1 does not
include the subnet mask when it sends updates. RIP v1 uses broadcasts (255.255.255.255).
RIP version 2 does, however, and this is what we call classless routing (check the Subnetting
section for more details). RIP v2 uses multicasts (224.0.0.9) to update its routing tables.
Route Update Timer: Sets the interval, usually 30 seconds, between periodic routing updates, in
which the router sends a complete copy of its routing table out to all neighbor routers.
Route Invalid Timer: Determines the length of time that must expire, usually 90 seconds, before
the router determines that a route is invalid. It will come to this conclusion if it doesn't hear any
updates about that route for that period. When the timer expires, the router will send out an
update to its neighbors letting them know that the route is invalid.
Route Flush Timer: Sets the time between a route becoming invalid and its removal from the
routing table (240 secs). Before it's removed, the router will notify its neighbors of that route's
impending doom ! The value of the route invalid timer must be less than that of the route flush
timer. This is to provide the router with enough time to tell its neighbors about the invalid route
before the routing table is updated.
Interior Gateway Protocol - IGRP
Introduction
Interior Gateway Routing Protocol (IGRP) is a Cisco proprietary Distance-Vector routing
protocol. This means that all your routers must be Cisco routers in order to use IGRP in your
network, keep in mind that Windows 2000 now supports it as well because they have bought a
licence from Cisco to use the protocol !
Cisco created this routing protocol to overcome the problems associated with RIP.
IGRP has a maximum hop count of 255 with a default of 100. This is helpful in larger networks
and solves the problem of there being only 15 hops maximum possible in a RIP network. IGRP
also uses a different metric from RIP. IGRP uses bandwidth and delay of the line by default as a
metric for determining the best route to an internetwork. This is called a composite metric.
Reliability, load and Maximum Transmission Unit (MTU) can also be used, although they are not
used by default.
IGRP has a set of timers to enhance its performance and functionality:
Update Timer: These specify how frequently routing-update messages should be sent. The default
is 90 seconds.
Invalid Timers: These specify how long a router should wait before declaring a route invalid if it
doesn't receive a specific update about it. The default is three times the update period.
Hold-down Timers: These specify the hold-down period. The default is three times the update
timer period plus 10 seconds.
Route Flush Timer:These indicate how much time should pass before a route should be flushed
from the routing table. The default is seven times the routing period.
Link State Routing Protocols
Introduction
Link State protocols, unlike Distance Vector broadcasts, use multicast.
Multicast is a "broadcast" to a group of hosts, in this case routers (Please see the multicast page
for more information). So if I had 10 router of which 4 where part of a "mutilcast group" then,
when I send out a multicast packet to this group, only these 4 routers will receive the updates,
while the rest of them will simply ignore the data. The multicast address is usually 224.0.0.5 &
224.0.0.6, this address is defined by the IGRP (Interior Gateway Routing Protocol).
Link State routing protocols do not view networks in terms of adjacent routers and hop counts,
but they build a comprehensive view of the overall network which fully describes the all possible
routes along with their costs. Using the SPF (Shortest Path First) algorithm, the router creates a
"topological database" which is a hierarchy reflecting the network routers it knows about. It then
puts it's self on the top of this hierarchy, and has a complete picture from it's own perspective.
When a router using a Link State protocol, such a OSPF (Open Shortest Path First) knows about a
change on the network, it will multicast this change instantly, there for flooding the network with
this information. The information routers require to build their databases is provided in the form
of Link State advertisement packets (LSAP). Routers do not advertise their entire routing tables,
instead each router advertises only its information regarding immediately adjacent routers.
Link State protocols in comparison to Distance Vector protocols have:

Big memory requirements

Shortest path computations require many CPU circles

If network is stable little bandwidth is used; react quickly to topology changes

Announcements cannot be “filtered”. All items in the database must be sent to neighbors

All neighbors must be trusted

Authentication mechanisms can be used to avoid undesired adjacencies

No split horizon techniques are possible
Even though Link State protocols work more efficiently, problem can arise. Usually problems
occur cause of changes in the network topology (links go up-down), and all routers don't get
updated immediately cause they might be on different line speeds, there for, routers connected via
a fast link will receive these changes faster than the others on a slower link.
Different techniques have been developed to deal with these problem and these are :
1) Dampen update frequency
2) Target link-state updates to multicast
3) Use link-state area hierarchy for topology
4) Exchange route summaries at area borders
5) Use Time-stamps Update numbering & counters
6) Manage partitions using a area hierarchy
Please select one of the following Link State routing protocols:
Open Shortest Path First - OSPF
Open Shortest Path First (OSPF) Routing Protocol
Introduction
Open Shortest Path First (OSPF) is a routing protocol developed for Internet Protocol (IP)
networks by the interior gateway protocol (IGP) working group of the Internet Engineering Task
Force (IETF). The working group was formed in 1988 to design an IGP based on the shortest path
first (SPF) algorithm for use in the Internet. Similar to the Interior Gateway Routing Protocol
(IGRP), OSPF was created because in the mid-1980s, the Routing Information Protocol (RIP)
was increasingly unable to serve large, heterogeneous internetworks.
OSPF is a classless routing protocol, which means that in its updates, it includes the subnet of
each route it knows about, thus, enabling variable-length subnet masks. With variable-length
subnet masks, an IP network can be broken into many subnets of various sizes. This provides
network administrators with extra network-configuration flexibility.These updates are multicasts
at specific addresses (224.0.0.5 and 224.0.0.6).
The cool 3D diagram below shows us the information that each field of an OSPF packet contains:
Analysis Of "Type" Field
All OSPF packets begin with a 24-byte header, which is shown right above. There is however one
field I would like to give a bit more attention to, and this is the "Type" field which is 1 byte long.
As illustrated in the diagram, the "Type" field identifies the OSPF packet type as one of the
following:

Hello: Establishes and maintains neighbor relationships.

Database Description: Describes the contents of the topological database. These
messages are exchanged when an adjacency is initialized.

Link-state Request: Requests pieces of the topological database from neighbor routers.
These messages are exchanged after a router discovers (by examining databasedescription packets) that parts of its topological database are out of date.

Link-state Update: Responds to a link-state request packet. These messages also are used
for the regular dispersal of Link-State Acknowledgments (LSA). Several LSAs can be
included within a single link-state update packet.

Link-state Acknowledgment: Acknowledges link-state update packets.
OSPF has two primary characteristics:
1) The protocol is open (non proprietary), which means that its specification is in the public
domain. The OSPF specification is published as Request For Comments (RFC) 1247.
2) The second principal characteristic is that OSPF is based on the SPF algorithm, which
sometimes is referred to as the Dijkstra algorithm, named for the person credited with its creation.
OSPF is a Link State routing protocol that calls for the sending of link-state advertisements
(LSAs) to all other routers within the same hierarchical area. Information on attached interfaces,
metrics used, and other variables is included in OSPF LSAs. As OSPF routers accumulate linkstate information, they use the SPF algorithm to calculate the shortest path to each node.
As a Link State routing protocol, OSPF contrasts with RIP and IGRP, which are Distance Vector
routing protocols. Routers running the Distance Vector algorithm send all or a portion of their
routing tables in routing-update messages to their neighbors.
Additional OSPF features include equal-cost, multipath routing, and routing based on upper-layer
type-of-service (TOS) requests. TOS-based routing supports those upper-layer protocols that can
specify particular types of service. An application, for example, might specify that certain data is
urgent. If OSPF has high-priority links at its disposal, these can be used to transport the urgent
datagram.
OSPF supports one or more metrics. If only one metric is used, it is considered to be arbitrary,
and TOS is not supported. If more than one metric is used, TOS is optionally supported through
the use of a separate metric (and, therefore, a separate routing table) for each of the eight
combinations created by the three IP TOS bits (the delay, throughput, and reliability bits). If, for
example, the IP TOS bits specify low delay, low throughput, and high reliability, OSPF calculates
routes to all destinations based on this TOS designation.
Hybrid Routing Protocols
Introduction
Hybrid routing protocols are something inbetween Distance Vector and Link State routing
protocols.
Please select the Hybrid protocol you want to read about:
Enhanced Interior Gateway Routing Protocol - EIGRP
Enhanced Interior Gateway Routing Protocol - EIGRP
Introduction
Enhanced Interior Gateway Routing Protocol (EIGRP) is another Cisco proprietary, hybrid (has
feature of Distance Vector and Link State protocols), interior gateway protocol (IGP) used by
routers to exchange routing information. EIGRP uses a composite metric composed of
Bandwidth, Delay, Reliability, and Loading to determine the best path between two locations.
EIGRP can route IP, IPX and Appletalk. Along with IS-IS, it is one of the few multi-protocol
routing protocols.
The Diffusing Update Algorithm (DUAL) is the heart of EIGRP. In essence, DUAL always keeps
a backup route in mind, in case the primary route goes down. DUAL also limits how many
routers are affected when a change occurs to the network.
There is no maximum allowable number of hops. In a EIGRP network, each router multi-casts
"hello" packs to discover its adjacent neighbor. This adjcency database is shared with other router
to build a topology database. From the topology database the best route (Successor) and the
second best route (Feasible Successor) is found.
EIGRP is classless, meaning it does include the subnet mask in routing updates. However, by
default 'auto-summary' is enable. You must disable if you want subnet information from other
major networks.
The EIGRP metric is a can be a complex calculation, but by default it only uses bandwidth and
delay to determine the best path.
Hubs & Repeaters
Introduction
Here we will talk about hubs and explain how they work. In the next section we will move to
switches and how they differ from hubs, how they work and the types of switching methods that
are available; we will also compare them.
Before we start there are a few definitions which I need to speak about so you can understand the
terminology we will be using.
Domain: Defined as a geographical area or logical area (in our imagination) where anything in it
becomes part of the domain. In computer land, this means that when something happens in this
domain (area) every computer that's part of it will see or hear everything that happens in it.
Collision Domain: Putting it simple, whenever a collision between two computers occurs, every
other computer within the domain will hear and know about the collision. These computers are
said to be in the same collision domain. As you're going to see later on, when computers connect
together using a hub they become part of the same collision domain. This dosen't happen with
switches.
Broadcast Domain: A domain where every broadcast (a broadcast is a frame or data which is sent
to every comeputer) is seen by all computers within the domain. Hubs and switches do not break
up broadcast domains. You need a router to achieve this.
There are different devices which can break-up collision domains and broadcast domains and
make the network a lot faster and efficient. Switches create separate collision domains but not
broadcast domains. Routers create separate broadcast and collision domains. Hubs are too simple
to do either, can't create separate collision or broadcast domain.
Hubs & Repeaters
Hubs and repeaters are basically the same, so we will be using the term "Hub" to keep things
simple. Hubs are common today in every network. They are the cheapest way to connect two or
more computers together. Hubs are also known as Repeaters and work on the first layer of the
OSI model. They are said to work on the first layer because of the function they perform. They
don't read the data frames at all (like switches and routers do), they only make sure the frame is
repeated out on each port and that's about it.
The Nodes that share an Ethernet or Fast Ethernet LAN using the CSMA/CD rules are said to be
in the same collision domain. In plain English, this means that all nodes connected to a hub are
part of the same collision domain. In a Collision domain, when a collision occurs everyone in that
domain/area will hear it and will be affected. The Ethernet section talks about CSMA/CD and
collision domains since they are part of the rules under which Ethernet functions.
The picture below shows a few hubs : 8 port Netgear and a D-link hub.
The computers (nodes) connect to the hub using Unshielded Twisted Pair cable (UTP). Only one
node can be connected to each port of the hub. The pictured hub has a total of 8 ports, which
means up to 8 computers can be networked.
When hubs were not that common and also expensive, most offices and home networks use to
install coax cable.
The way hubs work is quite simple and straightforward: When a computer on any one of the eight
ports transmits data, this is replicated and sent out to the other seven ports. Check out the below
picture which shows it clearly.
EXPLANATION:
Node 1 is transmitting some data to Node 6 but all nodes are receiving the data as well. This data
will be rejected by the rest of the nodes once they figure out it's not for them.
This is accomplished by the node's network card reading the destination MAC address of the
frame (data) it receives, it examines it and sees that it doesn't match with it's own and therefor
discards the frame. Please see the Datalink layer in the OSI section for more information on MAC
addresses.
Most hubs these days also have a special port which can function as a normal port or as an
"uplink" port. An uplink port allows you to connect another hub to the existing one, increasing
the amount of ports which will be available to you. This is a cheap solution when you need to get
a few more computers networked and it works quite well up to a point.
This is how 2 eight port hubs would look when connected via the uplink port and how the data is
replicated to all 16 ports :
In the above picture you can see that Node 1 is again transmitting data to Node 6 and that every
other node connected to the hub is receiving the information. As we said, this is a pretty good and
cheap solution, but as the network gets busier, you can clearly understand that there is going to be
a lot of unecessary data flowing all over the network. All Nodes here are in the same broastcast
and collision domain since they will hear every broadcast and collision that occurs.
This is the same situation you get when you use coax cable, where every node or computer is
connected onto the same cable and the data that's put onto it travels along the cable and is
received by every computer.
You probably also noticed the two orange boxes labled "50 Ohm". These are called terminating
resistors and are used on both ends of the coax cable so when the signal gets to them, it's
absorbed by them and that way you don't get the signal reflecting back. Think of them as shock
absorbent and the data signal is the shock wave which gets absorbed when it reaches the
terminating resistors. The coax cable can be up to 185 meters and can contain no more than 30
nodes per segment. What you're looking at in the above picture is one segment 25 meters long
with 4 nodes attached to it.
Now coming back to the hubs, there are a few standard features most of them have these include
a link and activity LED for each port, a power LED and collision LED. Some hubs have separate
link lights and activity lights, others combine them into one where the link light will flash when
there is activity, otherwise it remains constantly on. The Netgear hub which is displayed at the
beginning of this page has two separate LEDs for the activity and link but the Compex hub below
has only one.
This little hub also contains a special BNC connection so you can connect a coax cable to
it.
When you do connect it, the BNC light comes on. Notice the label at the top where they have
written "8 port Ethernet Repeater".
As we already have said, hubs are just simple repeaters.
The collision light on the hubs will only light up when a collision is detected. Collision is when 2
computers or nodes try to talk on the network at the same time. When this happens, their frames
will collide and become corrupted. The hubs are smart enough to detect this and will light up the
collision LED for a small amount of time (1/10 of a second for each collision). If you find
yourself wondering why couldn't they make things work so more than two computers can talk on
the network .. then i would ask you to visit the Ethernet section where all this is explained in
detail. Collisions and the fact that only one computer can talk on the network at any given time
along with the cabling rules are all part of the Ethernet rules. Remember that any node connected
to a hub becomes part of the same collision domain.
Switches & Bridges
Introduction
By now you can see the limitations of a simple hub and when you also read about Ethernet, you
start to understand that there are even more limitations. The companies who manufacter hubs saw
the big picture quickly and came out with something more efficient, bridges, and then the
switches came along! Bridges are analysed later on in this section.
Switching Technology
As we mentioned earlier, hubs work at the first layer of the OSI model and simply receive and
transmit information without examining any of it.
Switches (Layer-2 Switching) are a lot smarter than hubs and operate on the second layer of the
OSI model. What this means is that a switch won't simply receive data and transmit it throughout
every port, but it will read the data and find out the packet's destination by checking the MAC
address. The destination MAC address is located always at the beginning of the packet so once
the switch reads it, it is forwarded to the appropriate port so no other node or computer connected
to the switch will see the packet.
Switches use Application Specific Integrated Circuits (ASIC's) to build and maintain filter tables.
Layer-2 switches are alot faster than routers cause they dont look at the Network Layer (thats
Layer-3) header or if you like, information. Instead all they look at is the frame's hardware
address (MAC address) to determine where the frame needs to be forwarded or if it needs to be
dropped. If we had to point a few features of switches we would say:

They provide hardware based bridging (MAC addresses)

They work at wire speed, therefor have low latency

They come in 3 different types: Store & Forward, Cut-Through and Fragment Free
(Analysed later)
Below is a picture of two typical switches. Notice how they looks similair to a hubs, but they
aren't. It's just that the difference is on the inside!
The Three Stages
All switches regardless of the brand and various enhancements they carry, have something in
common, it's the three stages (sometimes 2 stages) they go through when powered up and during
operation. These are as follows:

Address Learning

Forward/Filter decisions

Loop Avoidance (Optional)
Let's have a look at them to get a better understanding!
Address Learning
When a switch is powered on, the MAC filtering table is empty. When a device transmits and an
interface receives a frame, the switch places the source address in the MAC filtering table
remembering the interface the device on which it is located. The switch has no choice but to flood
the network with this frame because it has no idea where the destination device is located.
If a device answers and sends a frame back, then the switch will take the source address from that
frame and place the MAC address in the database, associating this address with the interface that
received the frame.
Since the switch has two MAC addresses in the filtering table, the devices can make a point-topoint connection and the frames will only be forwarded between the two devices. This makes
layer-2 switches better than hubs. As we explained early on this page, in a hub network all frames
are forwarded out to all ports every time. Most desktop switches these days can hold upto 8000
MAC addresses in their table, and once the table is filled, then starting with the very first MAC
entry, the switch will start overwritting the entries. Even tho the number of entries might sound
big .. it only takes a minute or two to fill it up, and if a workstation dosen't talk on the network for
that amount of time, then chances are that its MAC address has been removed from the table and
the switch will forward to all ports the packet which has as a destination this particular
workstation.
And after the first frame has been successfully received by Node 2, Node 2 sends a reply to Node
1, check out what happens:
Notice how the frame is not transmitted to every node on the switch. The switch by now has
already learned that Node 1 is on the first port, so it send it straight there without delay. From
now on, any communication between the two will be a point-to-point connection :
Forward/Filter Decision
When a frame arrives at the switch, the first step is to check the destination hardware address,
which is compaired to the forward/filter MAC database. If the destination hardware address is
known, then it will transmit it out the correct port, but if the destination hardware address is not
known, then it will broadcast the frame out of all ports, except the one which it received it from.
If a device (computer) answers to the broadcast, then the MAC address of that device is added to
the MAC database of the switch.
Loop Avoidance (Optional)
It's always a good idea to have a redundant link between your switches, in case one decides to go
for a holiday. When you setup redundant switches in your network to stop failures, you can create
problems. Have a look at the picture below and I'll explain:
The above picture shows an example of two switches which have been placed in the network to
provide redundancy in case one fails. Both switches have their first port connected to the upper
section of the network, while their port 2 is connected to the lower section of the same network.
This way, if Switch A fails, then Switch B takes over, or vice versa.
Things will work fine until a broadcast come along and causes alot of trouble. For the simplicity
of this example, I am not going to show any workstations, but only the server which is going to
send a broadcast over the network, and keep in mind that this is what happens in real life if your
switch does not support Spanning-Tree Protocol (STP), this is why I stuck the "Optional" near the
"Loop Avoidance" at the start of this section:
It might look a bit messy and crazy at a first glance but let me explain what is going on here.
The Server for one reason or another decides to do a broadcast. This First Round (check arrow)
broadcast is sent down to the network cable and firstly reaches Port 1 on Switch A. As a result,
since Switch A has Port 2 connected to the other side of the lan, it sends the broadcast out to the
lower section of the network, this then is sent down the wire and reaches Port 2 on Switch B
which will send it out Port 1 and back onto the upper part of the network. At this point, as the
arrows indicate (orange colour) the Second Round of this broadcast starts. So again... the
broadcast reaches Port 1 of Switch A and goes out Port 2 back down to the lower section of the
network and back up via Port 2 of Switch B. After it comes out of Port 1 of Switch B, we get the
Third Round, and then the Fourth Round, Fifth Round and keeps on going without stopping.....!
This is what we call a Broadcast Storm.
A Broadcast Storm will repeat constantly, chewing up the valueble bandwidth on the network.
This is a major problem, so they had to solve it one way or another, and they did... with the
Spanning-Tree Protocol or STP in short. What STP does, is to find the redundant links, which this
case would be Port 2 of Switch B and shut it down, thus eliminating the posibility of looping to
occur.
Lan Switch Types
At the begining of this page we said that the switches are fast, therefor have low latency. This
latency does vary and depends on what type of switching mode the switch is operating at. You
might recall seeing these three switching modes at the beginning: Store & Forward, CutThrough and Fragment Free.
The picture below shows how far the different switching modes check the frame:
So what does this all mean ? Switching modes ? I Don't understand !
Let's Explain!
The fact is that switches can operate in one of the three modes. Some advance switches will allow
you to actually pick the mode you would like it to operate in, while others don't give you any
choice. Let's have a quick look at each mode:
Store & Forward mode
This is one of the most popular swtiching methods. In this mode, when the switch receives a
frame from one of it's ports, it will store it in memory, check it for errors and corruption, and if it
passes the test, it will forward the frame out the designated port, otherwise, if it discovers that the
frame has errors or is corrupt, it will discard it. This method is the safest, but also has the highest
latency.
Cut-Through (Real Time)
Cut-Through switching is the second most popular method. In this mode,the switch reads the
frame until it learns the destination MAC address of the frame it's receiving. Once it learns it, it
will forward the frame straight out the designated port without delay. This is why we say it's Real Time-, there is no delay or error checking done to the frame.
Fragment Free
The Fragment free switching method is mainly used to check for frames which have been subject
to a collision. The frame's first 64 bytes are only checked before forwarding the frame out the
designated port. Reason for this is because almost all collisions will happen within the first 64
bytes of a frame. If there is a corruption in the first 64 bytes, it's most likely that that frame was a
victim of a collision.
Just keep one important detail in mind: When you go out to buy a switch, make sure you check
the amount of memory it has. Alot of the cheap switches which support the Store & Forward
mode have very small amounts of memory buffer (256KB- 512KB) per port. The result of this is
that you get a major decrease in performance when you have more than 2 computers
communicating via that switch cause there isn't enough memory to store all incoming packets
(this also depends on th swtiching type your switch supports), and you eventually get packets
being discarded.
The table below is a guide on what amounts of memory you should be looking at for switches of
different configuration :
Bridges
Bridges are really just like switches, but there are a few differences which we will mention, but
not expand upon. These are the following:

Bridges are software based, while switches are hardware based because they use an
ASICs chip to help them make filtering decisions.

Bridges can only have one spanning-tree instance per bridge, while switches can have
many.

Bridges can only have upto 16 ports, while a switch can have hundreds !
That's pretty much as far as we will go with the bridges since they are pretty much old technology
and you probably won't see many around.
Introduction To Routers
Introduction
Welcome to the Routers section. Here we will analyse routers quite some depth; what they do and
how they work. I point out to you that you should have some knowlege on the OSI model and
understand how data is sent across the network medium. If you find the information a bit too
confusing or don't quite understand it, I would suggest you go back to the networking section and
do some reading on the OSI model and Protocols.
You will find information on Cisco routers at the end of this page.
What are they and what do they do ?
Routers are very common today in every network area, this is mainly because every network
these days connect to some other network, whether it's the Internet or some other remote site.
Routers get their name from what they do.... which is route data from one network to another.
For example, if you had a company which had an office in Sydney and another one in Melbourne,
then to connect the two you would use a leased line to which you would connect a router at each
end. Any traffic which needs to travel from one site to another will be routed via the routers,
while all the other unecessary traffic is filtered (blocked), thus saving you valuable bandwidth
and money.
There are two type of routers: 1) Hardware routers 2) Software routers.
So what's the difference ?
When people talk about routers, they usually don't use the terms "hardware" or "software" router
but we are, for the purpose of distinguishing between the two.
Hardware routers are small boxes which run special software created by their vendors to give
them the routing capability and the only thing they do is simply route data from one network to
another. Most companies prefer hardware routers because they are faster and more reliable, even
though their cost is considerably more when compared with a software router.
So what does a hardware router look like? Check the picture below, it displays a Cisco 1600 and
2500 series router along with a Netgear RT338 router. They look like a small box and run special
software as we said.
CISCO 1600 Series Router
CISCO 2500 Series Router
NetGear RT338 Router
Software routers do the same job with the above hardware routers (route data), but they don't
come in small flashy boxes. A software router could be an NT server, NetWare server or Linux
server. All network servers have built-in routing capabilities.
Most people use them for Internet gateways and firewalls but there is one big difference between
the hardware and software routers. You cannot (in most cases) simply replace the hardware router
with a software router.Why? Simply because the hardware router has the necessary hardware
built-in to allow it to connect to the special WAN link (frame relay, ISDN, ATM etc), where your
software router (e.g a NT server) would have a few network cards one of which connects to the
LAN and the other goes to the WAN via the hardware router.
I have seen a few cards in the market which allow you to connect an ISDN line directly into them.
With these special cards, which retail from $5000 to $15000 depending on their capacity, you
don't need the hardware router. But as you can understand, it's a much cheaper solution to buy a
hardware router. Plus, the hardware routers are far more advanced and faster than the software
routers since they don't have to worry about anything else but routing data, and the special
electronic components they have in them are developed with this in mind.
The Flash image below shows us what a router does when it receives packets from the LAN or
the Internet. Depending on the source and destination, it will pass them to the other network or
send them to the Internet. The router is splitting the below network into 2. Each network has a
hub to which all computers on that network connect to. Futher more, the router has one interface
connected to each network and one connected to the Internet, this allows it to pass the packets to
the right destination:
..................................
(You can click on the GO button)
The picture below illustrates a router's place in the Local Area Network (LAN):
In the example shown, the workstations see the router as their "gateway". This means that any
machine on this LAN that wants to send a packet (data) to the Internet or anywhere outside its
Local Area Network (LAN) will send the packet via the gateway. The router (gateway) will know
where it needs to send it from there on so it can arrive at its destination.
This explains the reason you need to add an Internet Protocol (IP) number for a gateway, when
you have a LAN at home or in the office, in your TCP/IP network properties on your windows
workstation.
The above figure shows only one example of how routers connect so the LAN gets Internet
access. Let's have a look how 2 offices would use routers to connect them.
The routers in the above picture connect using a particular WAN protocol, e.g ISDN.
In reality, there would be a cable (provided by your service provider) which connects to the
"WAN" interface of the router and from there the signal goes straight to your service provider's
network and eventually ends up at the other router's WAN interface.
Depending on the type of router you get, it will support one of the most commonly used WAN
protocols: ISDN, Frame Relay, ATM, HDLC, PPP. These protocols are discused in the protocols
section.
It's important to note down and remember a few of the main features of a router:

Routers are Layer 3 devices

Routers will not propagate broadcasts, unless they are programmed to

Most serious routers have their own operating system
Routers use special protocols between them to exchange information about each other (not data)
The above flash shows you how routers on the Internet work. In the example, your computer
which is located on the left is requesting data from a web server and the web server is responding
to your computer by sending it the requested data. The path which is taken for all transactions
will not remain the same, but will change, depending on the traffic and best routes available.
Now that you have a good idea of what a router looks like and what it's purpose is, we are going
to have a good look at one of the most popular router brands - Cisco.
Please choose one of the following sections:
Basics of Cisco routers - Learn the basics for the popular Cisco routers
The Modes in a Cisco router - Learn how to configure Cisco routers
Routing Protocols - Common protocols routers use to communicate and exchange information
Basics Of Cisco Routers
Introduction
Cisco is well known for its routers and switches. I must admit they are very good quality products
and once they are up and running, you can pretty much forget about them because they rarely fail.
We are going to focus on routers here since that's the reason you clicked on this page !
Cisco has a number of different routers, amongst them are the popular 1600 series, 2500 series
and 2600 series. The ranges start from the 600 series and go up to the 12000 series (now we are
talking about a lot of money).
Below are a few of the routers mentioned :
Cisco 7200 Series
Cisco 700 Series
Cisco 800 Series
Cisco 1600 Series
Cisco 2600 Series
All the above equipment runs special software called the Cisco Internetwork Operating System or
IOS. This is the kernel of Cisco routers and most switches. Cisco has created what they call Cisco
Fusion, which is supposed to make all Cisco devices run the same operating system.
We are going to begin with the basic components which make up a Cisco router (and switches)
and I will be explaining what they are used for, so grab that tea or coffee and let's get going !
The basic components of any Cisco router are :
1) Interfaces
2) The Processor (CPU)
3) Internetwork Operating System (IOS)
4) RXBoot Image
5) RAM
6) NVRAM
7) ROM
8) Flash memory
9) Configuration Register
Now I just hope you haven't looked at the list and thought "Stuff this, it looks hard and
complicated" because I assure you, it's less painful than you might think ! In fact, once you read it
a couple of times, you will find all of it easy to remember and understand.
Interfaces
These allow us to use the router ! The interfaces are the various serial ports or ethernet ports
which we use to connect the router to our LAN. There are a number of different interfaces but we
are going to hit the basic stuff only.
Here are some of the names Cisco has given some of the interfaces: E0 (first Ethernet interface),
E1 (second Ethernet interface). S0 (first Serial interface), S1 (second Serial interface), BRI 0
(first B channel for Basic ISDN) and BRI 1 (second B channel for Basic ISDN).
In the picture below you can see the back view of a Cisco router, you can clearly see the various
interfaces it has:(we are only looking at ISDN routers)
You can see that it even has phone sockets ! Yes, that's normal since you have to connect a digital
phone to an ISDN line and since this is an ISDN router, it has this option with the router. I
should, however, explain that you don't normally get routers with ISDN S/T and ISDN U
interfaces together. Any ISDN line requires a Network Terminator (NT) installed at the
customer's premises and you connect your equipment after this terminator. An ISDN S/T
interface doesn't have the NT device built in, so you need an NT device in order to use the router.
On the other hand, an ISDN U interface has the NT device built in to the router.
Check the picture below to see how to connect the router using the different ISDN interfaces:
...........
Apart from the ISDN interfaces, we also have an Ethernet interface that connects to a device in
your LAN, usually a hub or a computer. If connecting to a Hub uplink port, then you set the small
switch to "Hub", but if connecting to a PC, you need to set it to "Node". This switch will simply
convert the cable from a straight through (hub) to a x-over (Node):
..............
The Config or Console port is a Female DB9 connector which you connect, using a special cable,
to your computers serial port and it allows you to directly configure the router.
The Processor (CPU)
All Cisco routers have a main processor that takes care of the main functions of the router. The
CPU generates interrupts (IRQ) in order to communicate with the other electronic components in
the router. The Cisco routers utilise Motorola RISC processors. Usually the CPU utilisation on a
normal router wouldn't exceed 20 %.
The IOS
The IOS is the main operating system on which the router runs. The IOS is loaded upon the
router's bootup. It usually is around 2 to 5MB in size, but can be a lot larger depending on the
router series. The IOS is currently on version 12, and Cisco periodically releases minor versions
every couple of months e.g 12.1 , 12.3 etc. to fix small bugs and also add extra functionality.
The IOS gives the router its various capabilities and can also be updated or downloaded from the
router for backup purposes. On the 1600 series and above, you get the IOS on a PCMCIA Flash
card. This Flash card then plugs into a slot located at the back of the router and the router loads
the IOS "image" (as they call it). Usually this image of the operating system is compressed so the
router must decompress the image in its memory in order to use it.
The IOS is one of the most critical parts of the router, without it the router is pretty much useless.
Just keep in mind that it is not necessary to have a flash card (as described above with the 1600
series router) in order to load the IOS. You can actually configure most Cisco routers to load the
image off a network tftp server or from another router which might hold multiple IOS images for
different routers, in which case it will have a large capacity Flash card to store these images.
The RXBoot Image
The RXBoot image (also known as Bootloader) is nothing more than a "cut-down" version of the
IOS located in the router's ROM (Read Only Memory). If you had no Flash card to load the IOS
from, you can configure the router to load the RXBoot image, which would give you the ability to
perform minor maintenance operations and bring various interfaces up or down.
The RAM
The RAM, or Random Access Memory, is where the router loads the IOS and the configuration
file. It works exactly the same way as your computer's memory, where the operating system loads
along with all the various programs. The amount of RAM your router needs is subject to the size
of the IOS image and configuration file you have. To give you an indication of the amounts of
RAM we are talking about, in most cases, smaller routers (up to the 1600 series) are happy with
12 to 16 MB while the bigger routers with larger IOS images would need around 32 to 64 MB of
memory. Routing tables are also stored in the system's RAM so if you have large and complex
routing tables, you will obviously need more RAM !
When I tried to upgrade the RAM on a Cisco 1600 router, I unscrewed the case and opened it and
was amazed to find a 72 pin SIMM slot where you needed to attach the extra RAM. For those
who don't know what a 72 pin SIMM is, it's basically the type of RAM the older Pentium socket
7 CPUs took, back in '95. This type of memory was replaced by today's standard 168 pin DIMMs
or SDRAM.
The NVRAM (Non-Volatile RAM)
The NVRAM is a special memory place where the router holds its configuration. When you
configure a router and then save the configuration, it is stored in the NVRAM. This memory is
not big at all when compared with the system's RAM. On a Cisco 1600 series, it is only 8 KB
while on bigger routers, like the 2600 series, it is 32 KB. Normally, when a router starts up, after
it loads the IOS image it will look into the NVRAM and load the configuration file in order to
configure the router. The NVRAM is not erased when the router is reloaded or even switched off.
ROM (Read Only Memory)
The ROM is used to start and maintain the router. It contains some code, like the Bootstrap and
POST, which helps the router do some basic tests and bootup when it's powered on or reloaded.
You cannot alter any of the code in this memory as it has been set from the factory and is Read
Only.
Flash Memory
The Flash memory is that card I spoke about in the IOS section. All it is, is an EEPROM
(Electrical Eraseable Programmable Read Only Memory) card. It fits into a special slot normally
located at the back of the router and contains nothing more than the IOS image(s). You can write
to it or delete its contents from the router's console. Usually it comes in sizes of 4MB for the
smaller routers (1600 series) and goes up from there depending on the router model.
Configuration Register
Keeping things simple, the Configuration Register determines if the router is going to boot the
IOS image from its Flash, tftp server or just load the RXBoot image. This register is a 16 Bit
register, in other words has 16 zeros or ones. A sample of it in Hex would be the following:
0x2102 and in binary is : 0010 0001 0000 0010.
Cisco Router Modes
Introduction
From my personal experience, I have noticed that the lower end routers (600-1400) use different
commands than the mid to upper range routers (1600 and above). The commands we are going to
talk about here cover most aspects of the 1600, 1700, 2500, 2600, 3600 series. Most are the same,
but there are always a few variations to these commands depending on the interfaces your router
has, IOS version, and the type of WAN protocols they support.
Because there is such a wide range of interfaces on a router and also alot of different versions of
the Cisco IOS, I decided to stick to an example where our router is running IOS version 12 and
has one IDSN S/T (without NT terminator) interface and one Ethernet interface. That's a total of 2
interfaces. I understand that this is quite a specific example, but it would take an enourmous
amount of time and effort to cover all cases.
Now, when you power up a Cisco router, it will first run a POST test to ensure all hardware is ok,
and then look into the Flash to load the IOS. Once the IOS is loaded, it will then check the
NVRAM for any configuration file. Since this is a new router, it won't find any, so the router will
go into "setup mode".
Setup Mode
The setup mode is a step-by-step process which helps you configure basic aspects of the router.
When using this setup mode, you actually have 2 options:
1) Basic Managment Setup, which configures only enough connectivity for managment to the
system.
2) Extended Setup, which allows you to configure some global parameters and interfaces.
It should be noted that when you are prompted to enter a value at the console prompt, whatever is
between the square brackets [ ] is considered to be a default value. In other words, if you hit enter
without entering anything, the value in those brackets will be set for the specific question.
I'll try to keep this as simple and straightforward as possible.
Cisco routers have different configuration modes (depending on the router model), and by this I
mean there are different modes in which different aspects of the router can be configured.
These are :
1) User Exec Mode ( >) - Click to select
2) Privileged Mode (#) which has as a subset, the Global Configuration mode - Click to select
To be able to get into either User Exec or Privileged mode, you will most likely need a password.
This password is set during the initial configuration of the router or later on. Once in Privileged
Mode, you can then enter Global Configuration Mode (password not needed to enter this mode)
to then futher configure interfaces, routing protocols, access lists and more.
The picture below shows you a quick view of the modes. Notice the red arrow, it's pointing
towards the Global Configuration Mode and Privileged mode meaning that some of the specific
configuration modes can be entered from Global Configuration Mode and other from Privileged
mode:
I have given each mode its own separate page to avoid squezing all the information into one huge
page. This makes it easier for you to read.
Cisco Basics - User Exec Mode
Introduction
Let's see what it looks like to be in each one of these modes. Here I have telneted into our lab
router and I am in User Exec Mode:
The easiest way to keep track of the mode you're in is by looking at the prompt. The ">" means
we are in User Exec Mode. From this mode, we are able to get information like the version of
IOS, contents of the Flash memory and a few others.
Now, let's check out the available commands in this mode. This is done by using the "?"
command and hitting enter:
Wow, see all those commands available ? And just to think that this is considered a small portion
of the total commands available when in Privileged Mode ! Keep in mind that when you're in the
console and configuring your router, you can use some short cuts to save you typing full
command lines. Some of these are :
Tab: By typing the first few letters of a command and then hitting the TAB key, it will
automatically complete the rest of the command. Where there is more than one command starting
with the same characters, when you hit TAB all those commands will be displayed. In the picture
above, if i were to type "lo" and hit TAB, I would get a listing of "lock, login and logout" because
all 3 commands start with "lo".
?: The question mark symbol "?" forces the router to print a list of all available commands. A lot
of the commands have various parameters or interfaces which you can combine. In this case, by
typing the main command e.g "show" and then putting the "?" you will get a list of the
subcommands. This picture shows this clearly:
Other shortcut keys are :
CTRL-A: Positions the cursor at the beginning of the line.
CTRL-E: Positions the cursor at the end of the line.
CTRL-D: Deletes a character.
CTRL-W: Deletes a whole word.
CTRL-B: Moves cursor back by one step.
CTRL-F: Moves cursor forward by one step.
One of the most used commands in this mode is the "Show" command. This will allow you to
gather a lot of information about the router. Here I have executed the "Show version" command,
which displays various information about the router:
The "Show Interface <interface> " command shows us information on a particular interface. This
includes the IP address, encapsulation type, speed, status of the physical and logical aspect of the
interface and various statistics. When issuing the command, you need to replace the <interface>
with the actual interface you want to look at. For example, ethernet 0, which indicates the first
ethernet interface :
Some other generic commands you can use are the show "running-config" and show "startupconfig". These commands show you the configuration of your router.
The running-config refers to the running configuration, which is basically the configuration of the
router loaded into its memory at that time.
Startup-config refers to the configuration file stored in the NVRAM. This, upon bootup of the
router, gets loaded into the router's RAM and then becomes the running-config !
So you can see that User Exec Mode is used mostly to view information on the router, rather than
configuring anything. Just keep in mind that we are touching the surface here and not getting into
any details.
This completes the User Exec Mode section. If you like, you can go back and continue to the
Privileged Mode section.
Cisco Basics - Priveliged Mode
Introduction
To get into Privileged Mode we enter the "Enable" command from User Exec Mode. If set, the
router will prompt you for a password. Once in Privileged Mode, you will notice the prompt
changes from ">" to a "#" to indicate that we are now in Privileged Mode.
The Privileged Mode (and Global Configuration Mode ) is used mainly to configure the router,
enable interfaces, setup security, define dialup interfaces etc.
I have put a screen shot of the router to give you an idea of the commands available in Privileged
Mode in comparison to the User Exec Mode. Remember that these commands have subcommands and can get quite complicated:
As you can see, there is a wider choice of commands in Privileged Mode.
Now, when you want to configure certain services or parts of the router you will need to enter
Global Configuration Mode from within Privileged Mode. If you're confused by now with the
different modes available try to see it this way :
User Exec Mode (distinguished by the ">" prompt) is your first mode, which is used to get
statistics from router, see which version IOS you're running, check memory resources and a few
more things.
Privileged Mode (distingushed by the "#" prompt) is the second mode. Here you can enable or
disable interfaces on the router, get more detailed information on the router, for example, view
the running configuration of the router, copy the configuration, load a new configuration to the
router, backup or delete the configuration, backup or delete the IOS and a lot more.
Global Configuration Mode (distingushed by the " (config)# " prompt) is accessable via
Privileged Mode. In this mode you're able to configure each interface individually, setup banners
and passwords, enable secrets (encrypted passwords), enable and configure routing protocols and
a lot more. I dare say that 70% of the time you want to configure or change something on the
router, you will need to be in this mode.
Getting into Global Configuration
The picture below shows you how to enter Global Configuration Mode:
As you can see, I have telneted into the router and it prompted me for a password. I entered the
password, which is not shown, at this point I am in User Exec Mode and then entered "enable" in
order to get into the Privileged Mode. From here to get into Global Configuration Mode you need
to enter the "configure selection" command.
Now you must be wondering what the various parameters shown in the picture are, under the
"configure" command. These allow you to select how you will configure the router:

Configure Memory means you enter Global Configuration Mode and are configuring the
router in its NVRAM. This command will force the router to load up the startup-config
file stored in the NVRAM and then you can proceed with the configuration. When you're
happy with the configuration, save it to NVRAM by entering "copy running-config
startup-config".

Configure Network means you enter Global Configuration Mode and load a startupconfig file from a remote router (using tftp) into your local router's memory and
configure it. Once you're finished, you need to enter "copy running-config tftp" which
will force the router to copy its memory configuration onto a tftp server. The router will
prompt you for the IP address of the remote tftp server.

Configure Overwrite-network means that you overwrite the NVRAM's configuration with
a configuration stored on a tftp server. Issuing this command will force the router to
prompt for an IP address of the remote tftp server. Personally, I have never needed to use
this command.

Configure Terminal means you enter Global Configuration Mode and work with the
configuration which is already loaded into the router's memory (Cisco calls this the
running-config). This is the most popular command, as in most cases you need to modify
or re-configure the router on the spot and then save your changes.
You will need to save this configuration otherwise everything you configure will be lost upon
power failure or reboot of the router !
Below are the commands you need to enter to save the configuration, depending on your network
setup:

Copy running-config startup-config: Copies the configuration which is running in the
router's RAM in to the NVRAM and gives it a file name of startup-config (default). If
one already exists in the NVRAM, it will be overwritten by the new one.

Copy running-config tftp: Copies the configuration which is running in the router's RAM
in to a tftp server which might be running on your network. You will be asked for the IP
address of the tftp server and given the choice to select a filename for the configuration.
Some advanced routers can also act as tftp servers.
Generic Configuration
There are a few standard things with which you always need to configure the router . For
example, a hostname. This is also used as a login name for the remote router to which your router
needs to authenticate. Before we get stuck into the interface configuration we are going to run
through a few of these commands. The following examples assume no passwords have been set
as yet and that the router has a default hostname of "router":
We connect to the router via the console port using the serial cable and type the following
Router> enable (gets us into Privileged Mode)
Router# configure terminal (This command gets us into the appropriate Global Configuration
Mode as outlined above)
Router(config)# hostname swiftpond (This command sets the router's hostname to swiftpond.
From this moment onwards, swiftpond will appear before the ">" or "#" depending on which
mode we are in)
swiftpond(config)# username router2.isp password firewallcx (Here we are telling the router that
the remote router which we are connecting to, has a username of "router2.isp" and our password
to authenticate to router2.isp is "firewallcx")
This is a standard way of authentication with Cisco routers. Your router's hostname is your login
name and your password (in our case "firewallcx") is entered at the same time you define the
remote router's hostname.
Next we create a static route so the router will pass all packets originating from our network to
the remote router. This is usually the case when you connect to your isp.
swiftpond(config)# ip route 0.0.0.0 0.0.0.0 139.130.34.43 (Here we tell our router to create a
default route where any packet -defined by the first 0.0.0.0- no matter what subnetmask -defined
by the second 0.0.0.0- is to be sent to ip 139.130.34.43 which would be the router we are
connecting to)
In the case where you were not configuring the router to connect to the Internet but to join a small
WAN which connects a few offices, then you probably want to use a routing protocol:
swiftpond(config)# router rip (Enables RIP routing protocol. After this command you enter the
routing protocols configuration section -see below- where you can change timing parameters and
other)
swiftpond(config-router)#
At this prompt you can fine tune RIP or just leave it to the default setting which will work fine.
The "exit" command takes you one step back:
swiftpond(config-router)# exit
swiftpond(config)#
Alternatively, you can use IGRP as a routing protocol, in which case you would have to enter the
following:
swiftpond(config)# router igrp 1 (The "1" defines the Autonomous system number)
swiftpond(config-router)#
Again, the "exit" command will take you back one step:
swiftpond(config-router)# exit
swiftpond(config)#
After that, we need to create a dialer list which our WAN interface BRI (ISDN) will use to make
a call to our ISP.
swiftpond(config)# dialer-list 1 protocol ip permit (Now we are telling the router to create a dialer
list and bind it to group 1. The "protocol ip permit" tells the router to initiate a call for an ip
packet)
I'll give you a quick example to make sure you understand the reason we put this command:
If you launched your web browser, it would send an http request to the server you have set as a
homepage e.g www.firewall.cx. This request which your computer is going to send, is
encapsulated in an ip packet that will cause your router to initiate a connection, as it is now
configured to do so.
The dialup interface for Cisco routers is broken into 2 parts: a Dialer-list and a Dialer-group.
The Dialer-list defines the rules for placing a call. Later on when you configure the WAN
interface, you bind that Dialer-list to the interface by using the Dialer-group command (shown
later on).
Configuring Interfaces
In our example we said we have a router with one Ethernet and one basic ISDN interface (max of
128Kbit). We are going to go through the process of configuring the interfaces. We will start with
the Ethernet Interface.
In order to configure the interface, we need to be in Global Configuration Mode, so we need to
type first "enable" in order to get into Privileged Mode and then "configure terminal" to get into
the appropriate Global Configuration Mode (as explained above). Now we need to select the
interface we want to configure, in this case the first ethernet interface (E0) so we type "interface
e0".
This picture shows clearly all the steps:
Any commands entered here will affect the first ethernet interface only. So we start with the IP
address. It's important to understand that this IP address would be visible to both networks to
which the router is connected. If we were connecting to the Internet then everyone would be able
to see this IP. Futhermore, the IP address would also be the default gateway for our firewall or
machine which would physically connect directly to the router.
The following commands will configure the ethernet interface's IP address::
(config-if)# ip address 192.168.0.1 255.255.255.0
or
(config-if)# ip address 139.130.4.5 255.255.255.0 secondary
Now that we have given e0 its IP address, we need to give the ISDN interface its IP as well, so
we need to move to the correct interface by typing the following:
(config-if)# exit (this exits from the e0 interface configuration)
(config-if)# interface bri0 (this command enters the configuration for the first ISDN interface)
(config-if)# ip address 10.0.0.2 255.255.255.224 (this command sets the IP address for BRI 0
which is also known as the WAN IP address)
Now when it comes to configuring WAN interfaces, you need more than just an IP address (LAN
interfaces such as E0 are a lot easier to configure). You need to set the encapsulation type, the
authentication protocol the router will use to authenticate to the remote router, the phone number
it will need to dial and a few more:
(config-if)# encapsulation ppp (This command sets the packet's encapsulation to ppp which is
100% compatible with all routers no matter what brand)
(config-if)# dialer string 0294883452 (This command tells the router which phone number it
needs to dial in order to establish a connection with our remote router e.g your ISP)
(config-if)# dialer group 1 (This command tells the router to use the dialer list 1 (configured
previously) to initiate a connection)
(config-if)# idle-timeout 2000000 (This command is optional and allows us to set an idle timeout
so if the router is idle for so many seconds, it will disconnect. A value of 2 million seconds means
the router will never disconnect)
(config-if)# isdn switch-type basic-net3 (This command tells the router the type of ISDN
interface we are using. Each country has its own type, so you need to consult your Cisco manual
to figure out which type you need to put here)
(config-if)# dialer load-threshold 125 outbound (This command is optional and allows us to
specify a threshold upon which it will place another call. The value it takes is from 1 to 255. A
value of 125 means bring up the second B channel if either the inbound or outbound traffic load is
50%.
That pretty much does it for our ISDN (WAN) interface. All you need to do now is to SAVE the
configuration !
Well I hope it wasn't too bad for you, since there is a quite a bit of information on this page. I
encourage you to read through it again until you understand what is going on, then you will find it
a breeze to configure a Cisco router yourself !
The Ethernet Datalink
Introduction
"Ethernet" is the term that is casually applied to a number of very different data link
implementations. You will hear people refer to "Ethernet" and they might be referring to the
original DEC, Intel and Xerox implementation of Version 1 or Version 2 Ethernet. This, in a
sense, is the "true" definition of "Ethernet". When the IEEE built the 802.3 standards in 1984 the
term "Ethernet" was broadly applied to them as well. Today we talk about "Fast Ethernet" and,
although this technology bears many similarities to its predecessors, the engineering technology
has changed dramatically.
Whatever you call it, this is a Data Link technology - responsible for delivering a frame of bits
from one network interface to another - perhaps through a repeater, switch or bridge.
Please select one of the following links :
Frame Formats
The four ways that frames may be structured (contains 3D diagrams and analysis of frames).
Media Access
Taking turns accessing the cable using the rules of Carrier Sense Multiple Access with Collision
Detection (CSMA/CD)
Collisions
The results of simultaneous transmissions on the media: Fragments, Runts, CRC Errors
Propagation Delay
The relationship between maximum cable length and minimum frame size is based on the
propagation delay of the signal
Frame Corruption
Troubleshooting coaxial Ethernet networks by examining the types of corruption patterns that
result from specific events
Interframe Gap
The 9.6 microsecond interframe gap and an understanding of its purpose
Signal Encoding
Manchester Encoding for the electrical Ethernet signal
Ethernet Frame Formats
Introduction
An understanding of the basics of the Ethernet Frame Format is crucial to any discussion of
Ethernet technology.
In this section, we will discuss:
1. The four different frame formats used in the Ethernet world; the purpose of each of the
fields in an Ethernet frame; the reasons that there are so many different versions of the
Ethernet Frame Format - Ethernet, Ethernet, Ethernet, or Ethernet?! When somebody tells
me that they are running Ethernet on their network, I inevitably have to ask: "Which
Ethernet?". Currently, there are many versions of the Ethernet Frame Format in the
commercial marketplace, all subtly different and not necessarily compatible with each
other.
2. The explanation for the many types of Ethernet Frame Formats currently on the
marketplace lies in Ethernet's history. In 1972, work on the original version of Ethernet,
Ethernet Version 1, began at the Xerox Palo Alto Research Center. Version 1 Ethernet
was released in 1980 by a consortium of companies comprising DEC, Intel, and Xerox.
In the same year, the IEEE meetings on Ethernet began. In 1982, the DIX
(DEC/Intel/Xerox) consortium released Version II Ethernet and since then it has almost
completely replaced Version I in the marketplace. In 1983 Novell NetWare '86 was
released, with a proprietary frame format based on a preliminary release of the 802.3
spec. Two years later, when the final version of the 802.3 spec was released, it had been
modified to include the 802.2 LLC Header, making NetWare's proprietary format
incompatible. Finally, the 802.3 SNAP format was created to address backwards
compatibility issues between Version 2 and 802.3 Ethernet.
As you can see, the large number of players in the Ethernet world has created a number of
different choices. The bottom line is this: either a particular driver supports a particular frame
format, or it doesn't. Typically, Novell stations can support any of the frame formats, while
TCP/IP stations will support only one although there are no hard and fast rules in Networking.
Ethernet Frame Formats
The following sections will outline the specific fields in the different types of Ethernet frames.
Throughout the section, we will refer to fields by referencing their "offset" or number of bytes
from the start of the frame beginning with zero. Therefore, when we say that the destination
address field is from offset zero through five we are referring to the first six bytes of the frame.
The Preamble
Regardless of the frame type being used, the means of digital signal encoding on an Ethernet
network is the same. While a discussion of Manchester Encoding is beyond the scope of this
page, it is sufficient to say that on an idle Ethernet network, there is no signal. Because each
station has its own oscillating clock, the communicating stations have to have some way to
"synch up" their clocks and thereby agree on how long one bit time is. The preamble facilitates
this. The preamble consists of 8 bytes of alternating ones and zeros, ending in 11.
A station on an Ethernet network detects the change in voltage that occurs when another station
begins to transmit and uses the preamble to "lock on" to the sending station's clock signal.
Because it takes some time for a station to "lock on", it doesn't know how many bits of the
preamble have gone by. For this reason, we say that the preamble is "lost" in the "synching up"
process. No part of the preamble ever enters the adapter's memory buffer. Once locked on, the
receiving station waits for the 11 that signals that the Ethernet frame follows.
Most modern Ethernet adapters are guaranteed to achieve a signal lock within 14 bit-times.
The Different "Flavors" of Ethernet
While the preamble is common to every type of Ethernet, what follows it is certainly not. The
major types of Ethernet Frame Format are:
FRAME TYPE
Novell calls it...
Cisco calls it...
IEEE 802.3
ETHERNET_802.2 LLC
Version II
ETHERNET_II
ARPA
IEEE 802.3
ETHERNET_SNAP SNAP
SNAP
Novell
ETHERNET_802.3 NOVELL
Proprietary
("802.3 Raw")
You can click on the Frame type to get more information about it.
As you examine the table above please note that an IEEE 802.3 frame is referred to as an 802.2
frame by Novell. The frame that Novell refers to as "802.3 Raw" or "Ethernet_802.3" is their own
proprietary frame format.
What is CSMA/CD ?
Introduction
CSMA/CD stands for Carrier Sense Multiple Access with Collision Detection. It refers to the
means of media access, or deciding "who gets to talk" in an Ethernet network.
A more elegant term for "who gets to talk" is to refer to the "media access method", which, in this
case, would be "CSMA/CD".
Carrier Sense means that before a station will "talk" onto an Ethernet wire, it will listen for the
"carrier" that is present when another station is talking. If another station is talking, this station
will wait until there is no carrier present.
Multiple Access refers to the fact that when a station is done transmitting it is allowed to
immediately make another access to the medium (a 'multiple' access). This is as opposed to a
Token-Ring network where a station is required to perform other tasks inbetween accessing the
medium (like releasing a token or sometimes releasing a management frame).
Collision Detection refers to the ability of an Ethernet adapter to detect the resulting "collision" of
electrical signals and react appropriately. In a normally operating Ethernet network, it will
sometimes occur that two stations simultaneously detect no carrier and begin to talk. In this case
the two electrical signals will interfere with each other and result in a collision; an event which is
detected by the Collision Detection circuitry in the transmitting network interface cards.
The process of CSMA/CD is implemented slightly differently in a twisted pair (as opposed to a
coaxial) Ethernet network.
Ethernet Collisions
Introduction
The word "Collision" shouldn't be any new news to people who work with networks everyday. If
it is thought, don't worrie, that's why you are here.
A collision is an event that happens on an Ethernet network when two stations simultaneously
"talk" on the wire. Collisions are a normal part of life in an Ethernet network and under most
circumstances should not be considered a problem.
Even thought alot of people know that collisions do happen on a network, what they don't know
is that there are two different type of collisions ! Yes, thats right, two different type of collissions,
one is the Early Collision and the other, the Late Collision.
We will have a look at two collision examples (one of each) in the next couple of pages, and these
examples have been carefully selected to help you understand the difference between the two
types of collisions. Also, we are going to have a look at the events leading up to and immediately
following a collision.
So, grab that favorite mug of yours, fill it up with something to drink and let's start learning about
collisions !
You can use the cool menu to get to the next pages or simply click on the links below :


Early Ethernet Collisions
Late Ethernet Collisions
Propagation delay & its relationship to max. cable length
Introduction
You may know that the minimum frame size in an Ethernet network is 64 bytes or 512 bits,
including the 32 bit CRC. You may also know that the maximum length of an Ethernet cable
segment is 500 meters for 10BASE5 thick cabling and 185 meters for 10BASE2 thin cabling. It
is, however, a much less well known fact that these two specifications are directly related. In this
essay, we will discuss the relationship between minimum frame size and maximum cable length.
Propagation Delay
Before we discuss frame size and cable length, an understanding of signal propagation in copper
media is necessary. Electrical signals in a copper wire travel at approximately 2/3 the speed of
light. This is referred to as the propagation speed of the signal. Since we know that Ethernet
operates at 10Mbps or 10,000,000 bits per second, we can determine that the length of wire that
one bit occupies is approximately equal to 20 metres or 60 feet via the following maths:

speed of light in a vacuum = 300,000,000 metres/second

speed of electricity in a copper cable = 200,000,000 metres/second

(200,000,000 m/s) / (10,000,000 bits / s) = 20 metres per bit
We can further determine that a minimum size Ethernet frame consisting of 64 bytes or 512 bits
will occupy 10,240 metres of cable.
The Relationship
The only time that an Ethernet controller can detect collisions on the wire is when it is in the
transmit mode. When an Ethernet NIC has finished transmitting and switches to receive mode,
the only thing it listens for is the 64 bit preamble that signals the start of a data frame. The
minimum frame size in Ethernet is specified such that, based on the speed of propagation of
electrical signals in copper media, an Ethernet card is guaranteed to remain in transmit mode and
therefore detecting collisions long enough for a collision to propagate back to it from the farthest
point on the wire from it.
Take, for example, a length of 10BASE5 thick Ethernet cabling exactly 500 meters long (the
maximum that the spec allows) with two stations, Station A and Station B, attached to the farthest
ends of it.
If Station A begins to transmit, it will have transmitted 25 bits by the time the signal reaches
Station B, 500 meters away. If Station B begins to transmit at the last possible instant before
Station A's signal reaches it, the collision will reach Station A 25 bit-times later (the time it takes
for the signal on the wire to travel one bit-length -- 20 metres in copper cable). Station A will
have transmitted only 50 bits when the collision reaches it -- nowhere near the 512 bit boundary
for an early collision.
Upon closer examination, however, a peculiarity arises. If a normal collision happens before the
512 bit boundary, Station A would have to be over 5000 metres away from Station B before a late
collision occurred. Examine the maths for yourself: 512 bits times 20 metres/bit = 10,240 metres.
That's 256 bits or approximately 5000 metres for the signal to propagate from Station A to Station
B and 5000 metres for the collision event to propagate back to and be detected by Station A. It
seems like a late collision would never occur with a maximum cable length of only 500 meters.
What is the reason for the overhead?
The reason for the overhead is twofold. First of all, while the maximum possible cable segment
length in Ethernet is 500 metres, it is possible to extend that length with up to 4 repeaters before
the IEEE 802.3 spec is violated. This means that the signal may have to travel through as much as
2500 metres of cable to reach Station B, or 5000 metres of cable round trip. The second and final
reason for the overhead lies solely in the carefulness of Ethernet's inventors. Generally the spec is
twice as strict as it needs to be, allowing ample room for errors.
Herein lies one of the greatest strengths and weaknesses of Ethernet. It is a strength in that if you
need to, you can probably get away with violating the specs -- an extra length of cable here, an
extra repeater there and your network continues to run normally. It is a weakness in that while
you can get away with violating the specs, there is a very fine line between a network that is
violating the specs and is running and a network that is violating the specs and is crippled by late
collisions and you never know which extra bit of wire or extra repeater is going to cross the line.
Despite this dire warning, there are some general rules for violating specs:

If your vendor tells you you can violate the spec and you're not mixing vendors, it's
probably ok. If you mix vendors, obey the strictest vendor.

If something is wrong with your network and you know that it violates the spec in places,
those places should be the first ones you check. Try segmenting the network with a
bridge and see which side of the bridge the problems are on.
Ethernet Troubleshooting - Physical Frame Corruption
Introduction
When troubleshooting your Ethernet network, the first thing to look for is physical frame
corruption. In this essay, we will discuss the different causes of physical frame corruption and the
characteristics of each one. It is important to remember that the frame corruption being discussed
is SPECIFIC TO COAXIAL ETHERNET. Twisted-pair Ethernet implementation will NOT
manifest these types of corruption patterns!
Let's find the problem !
I am going to discusses troubleshooting with reference to the Network General Expert Sniffer
Network Analyzer. While the tips here are universal, other Analyzers' behavior might differ in
such a way as to make these tips invalid or unusable.
There are four possible causes of physical frame corruption in an Ethernet Network, each one
different in the way it corrupts the frame and therefore recognizable.
The four causes are:

Collisions. Caused by out of spec. cabling or faulty hardware.

Signal Reflections. Caused by un-terminated cables, impedance mismatch and exceeding
the maximum allowable bend radius of the cable.

Electrical Noise. Caused by nearby power grids, fluorescent lighting, X-ray machines,
etc...

Malfunctioning Hardware. Caused by gremlins, helpful users, natural disasters, etc...
At the end of the section there is a troubleshooting flowchart to help you identify the cause of
frame corruption. It is important to remember that these corruption patterns will only be evident
on a coaxial Ethernet (10BASE-2 Thin Ethernet, 10BASE-5 Thick Ethernet). Twisted-Pair
Ethernet networks, where each station is connected to a hub or switch, do not manifest these exact
corruption patterns.
Collisions
Collisions are the most easily recognizable of the four causes of physical frame corruption.
Generally, when a collision occurs, several bytes of the preamble of the colliding frame will be
read into your Sniffer's buffer before the signal is completely destroyed. You will see these bytes
in the hexadecimal decode of the packet as either several bytes of AAs or several bytes of 55s at
the very end of the frame (Remember, AAh=1010b, 55h=0101b. Depending on where the
collision occurred, the preamble could be perceived as either of these).
Because the preamble is only 8 bytes long, ending in 1011, if you see more than 8 bytes of AA or
55, then the corruption was not caused by a collision and more investigation is necessary.
Signal Reflections
Signal reflections are caused by electrons literally "bouncing" back along the wire. One cause of
signal reflection is an un-terminated cable. Electrons travel down the wire until they reach the
cable's end where, with no resistor to absorb the voltage potential, they reflect back from the open
end of the cable.
Another cause of signal reflections is mixing cables with different impedances. Impedance can be
thought of as the "rate of flow" of the wire. When electrons from the higher impedance wire
attempt to travel through the lower impedance wire, some of them can't make it and are reflected
back, destroying the signal.
The final cause of signal reflections is when the maximum allowable bend radius of the cable is
exceeded - the copper media is deformed, causing reflections.
The characteristic of signal reflection is very short frames (typically less than 16-32 bytes), with
no preamble in the frame and with all frames cut short within one or two bytes of the same place
in the frame. Once again, this can be determined by viewing the frames in the Hexadecimal
Decode view of your analyzer. The Expert Sniffer will also probably detect a high number of
short or runt frames, as well as a high rate of physical frame corruption.
Electrical Noise
Physical frame corruption caused by electrical noise is similar in appearance to corruption caused
by reflections in that there is no preamble in the frame -- the frame just seems to stop short, but it
is different in that the frames are generally cut off at random lengths.
Hardware Malfunctions
Frame corruption caused by hardware malfunctions is potentially the hardest to diagnose because
of the large number of ways that hardware can malfunction. Generally, hardware malfunctions
will occur either randomly or constantly, but not regularly. The type of frame corruption is
impossible to predict, generally manifesting as random "garbage" in the frame, but some common
signs are:

A stream of ones or zeros. A transceiver has malfunctioned and is "jabbering" on the
wire. Most transceivers have jabber detection circuitry that prevents the adapter from
transmitting for longer than a certain preset time.

Gigantic frames (greater than 1500 bytes). Same as above.
Troubleshooting Flowchart
REMEMBER: This applies to corruption patterns that would be visible when viewing frames on a
COAXIAL Ethernet.
1. Is a preamble (less than 8 bytes of AA or 55) visible at the very end of the frame?
If yes:
1. Make sure you haven't exceeded the specifications of your cable (maximum cable length,
maximum repeaters in between nodes, etc)
2. Use a "divide and conquer" method to isolate the troublemakers. Separate the network
into halves using a bridge and see which side of the bridge the problems occur on. Now
separate that half into halves, etc....
If no, go on.
2. Are the corrupt frames very short, and consistently the same length?
If yes:
1. Your problem is probably related to signal reflection. First check for un-terminated
cables. If the cable is terminated properly, your job becomes a lot harder. If new cable
has been installed recently, impedance mismatch is probably the problem. Avoid this
problem by buying all your cabling from the
same lot (if possible) and buying cabling all at once and putting extra in storage rather
than ordering as needed. Finally, check for cable deformation due to bending the cable or
placing heavy objects on the cable.
2. A Time Domain Reflectometer can really save you some work when diagnosing this type
of problem. This device can tell you, probably to the foot, how far down the wire the
signal reflection is occurring.
If no, go on.
3. Are the frames random in length, all cut off cleanly with no signs of bit streaming or other
hardware malfunction?
If yes:
1. Your problem is probably electrical noise. Use the "divide and conquer" method outlined
in bullet number 1 to determine where the noise is occurring and then use your intuition.
I've seen problems as bizarre as a dentist's X-ray machine being on the other side of the
wall to the wiring closet and every time the dentist took an X-ray the network would go
down!
If no, go on.
3. If you've arrived at this point, your problem is probably hardware related. Use the "divide
and conquer" method outlined in bullet 1.
The Truth About Interframe Spacing
Introduction
The IEEE 802.3 specification states that before a station can attempt to transmit on the wire, it
must first wait until it has heard 9.6 microseconds of silence. Many popular myths have arisen
surrounding the reasons for the 9.6 microsecond interframe gap. The purpose of this section is to
clarify the true reason for the 9.6 microsecond interframe gap.
The Truth
The sole reason for the 9.6 microsecond interframe gap is to allow the station that last transmitted
to cycle its circuitry from transmit mode to receive mode. Without the interframe gap, it is
possible that a station would miss a frame that was destined for it because it had not yet cycled
back into receive mode.
There is, however, an interesting sidebar to this discussion and that is that most Ethernet cards in
today's market are capable of switching from transmit to receive in much less time than 9.6
microseconds. This is an example of what can happen when 1970's specifications are applied to
1990's technology. In fact, some adapter manufacturers are designing their cards with a smaller
interframe spacing, thereby achieving higher data transfer rates than their competitors.
The problem arises when cards with a smaller interframe spacing are mixed on a network with
cards that meet the specifications. In this case, there is a potential for lost data.
The moral of the story is that a network administrator needs to know what is going on in his or
her network and be aware that not all vendors will stick to the specs. Contact your vendors and
find out what they're doing differently -- it'll pay off!
Manchester Signal Encoding
Introduction
The device driver software receives a frame of IP, IPX, NetBIOS, or other higher-layer protocol
data. From this data, the device driver constructs a frame, with appropriate Ethernet header
information and a frame check sequence at the end.
The circuitry on the adapter card then takes the frame and converts it into an electrical signal. The
voltage transitions in the transmitted bit stream are in accordance to the format called Manchester
Signal Encoding. Manchester encoding describes how a binary ONE and ZERO are to be
represented electrically. Manchester encoding is used in all 10 Megabit per second Ethernets; for
example, 10BASE2 Thin Ethernet, 10BASE5 Thick Ethernet and 10BASE-T Twisted-Pair
Ethernet.
Here we see an example of the signal transitions used to encode the hexadecimal value "0E",
which converts to "00001110" in binary:
Notice that there is a consistent transition in the middle of each bit-time. Sometimes this
transition is from low-to-high and sometimes it's from high-to-low. This is the clock transition.
The receiving adapter circuitry 'locks on' to this constant signal transition and, thereby, identifies
the timing to determine the beginning and end of each bit.
To represent a binary ONE, the first half of the bit-time is a low voltage; the second half of a bit
is always the opposite of the first half, that's how the clock transition is created. To represent a
binary ZERO, the first half of the bit-time is a high voltage. You see that sometimes there is an
additional transition at the beginning of a bit-time (not drawn in the diagram above) where the
signal is pulled either up or down in preparation for the next bit.
Consider what happens if an external electromagnetic field interferes with the Manchester bit
encoding. This external field could be the result of an electric motor, radio transmission or other
source of interference. You should be able to see that if the Manchester signal is disrupted the bits
will be destroyed - because the clock signal will be disrupted.
It would not be reasonably possible for electrical interference to change a binary ONE into a
binary ZERO. Since each bit is symmetrical (second half is always opposite the first half) the
result of electrical noise would be the destruction of the bit, not a change in bit value.
Introduction Of Fast Ethernet
Introduction
Full motion video for video conferencing requires, typically, at least 25 Mb/sec. That means that
a legacy Ethernet, at 10 Mb/sec, can only deliver poor quality real-time video. With 100 Mb/sec,
however, you can be watching a broadcast presentation in one window while you're in conference
with three people in three other windows (for a total of 100 megabits of bandwidth).
Consider a file server that requires 0.6 Mb/sec (6 million bits per second; 60% utilization on a 10
Mb/sec Ethernet). With a 100 Mb/sec Ethernet this server can now utilize interface hardware that
can pump data down the pipe at a greatly increased rate.
It seems clear that the evolution of the industry is moving away from 10 Mb/sec Ethernet and
towards the 100 Mb/sec (or higher) rates of data transfer. This section of the compendium
discusses 100 Mb/sec Ethernet technology
Virtually everyone who uses Ethernet has wished from time to time that their network had a
higher bandwidth. When Ethernet was being designed in the late 1970s, 10Mbps seemed
immense. With today's bandwidth-intensive multimedia applications, or even with just the
departmental server, that number sometimes is barely adequate. Yes, faster network technologies
were available, but they were complicated and expensive. Then came Fast Ethernet.
Anyone who understands classic Ethernet already understands much about Fast Ethernet. Fast
Ethernet uses the same cabling and access method as 10Base-T. With certain exceptions, Fast
Ethernet is simply regular Ethernet - just ten times faster! Whenever possible, the same numbers
used in the design of 10Base-T were used in Fast Ethernet, just multiplied or divided by ten. Fast
Ethernet is defined for three different physical implementations.
The Implementations of Fast Ethernet:

100BASE-TX: Category 5

100BASE-FX: Multimode fibre

100BASE-T4: Category 3
Probably the most popular form of Fast Ethernet is 100BASE-TX. 100BASE-TX runs on
EIA/TIA 568 Category 5 unshielded twisted pair, sometimes called UTP-5. It uses the same pair
and pin configurations as 10Base-T, and is topologically similar in running from a number of
stations to a central hub.
As an upgrade to 10Mbps Ethernet over multimode fibre (10Base-F), 100BASE-FX is Fast
Ethernet over fibre. Single duplex runs are supported up to 400m and full duplex runs are
supported for up to 2km.
Fast Ethernet is possible on Category 3 UTP with 100BASE-T4. There is a popular
misconception that Fast Ethernet will only run on Category 5 cable. That is true only for
100BASE-TX. If you have Category 3 cable with all four pairs (8 wires) connected between
station and hub, you can still use it for Fast Ethernet by running 100BASE-T4. 100BASE-T4
sends 100Mbps over the relatively slow UTP-3 wire by fanning out the signal to three pairs of
wire.
This "demultiplexing" slows down each byte enough that the signal won't overrun the cable.
Category 3 cable has four pairs of wire, eight wires total, running from point to point. 10Base-T
only uses four wires, two pairs. Some cables only have these two pairs connected in the RJ-45
plug. If the category 3 cabling at your site has all four pairs between hub and workstation, you
can use Fast Ethernet by running 100BASE-T4.
Please select on of the following sections:

Differences Between 100 Mb/sec and 10 Mb/sec Ethernet

Integration Of 100 Mb/sec Ethernet Into Existing 10 Mb/sec networks

Migration from 10 Mb/sec to 100 Mb/sec

Fast Ethernet Model

Troubleshooting
Differences Between Classic Ethernet And Fast Ethernet
Introduction
The two primary areas for concern when upgrading the network from 10Mbps to 100Mbps are
cabling and hubs. As discussed on the Fast Ethernet Introduction page, in Fast Ethernet twisted
pair cabling needs either to be category 5 or to be category 3 with proper twist on all four pairs.
The problem with hubs is the number of hubs allowed in a single collision domain. Classic
Ethernet allows hubs to be cascaded up to four deep between any two stations. In Fast Ethernet,
the number of hubs allowed in a collision domain is drastically reduced - to a single hub.
Sometimes it may be possible to have more than one hub in a collision domain, but it will
probably be easier in the long term to design a Fast Ethernet network assuming that only one hub
is allowed.
What the IEEE 802.3 spec does not explicitly state is that this limitation only applies to shared
100BASE-T, not to switched 100BASE-T. Since switches act like bridges in defining a separate
collision domain, installing Fast Ethernet switches will allow you to work around the single-hub
problem. Even if it is not necessary to deliver dedicated switched Fast Ethernet to each desktop,
Fast Ethernet hubs can be connected to switches. Connecting a number of repeaters to a switch
will provide shared Fast Ethernet and allow you to maintain the size of your network.
Intergrating Fast Ethernet into 10MB Ethernet Networks
Introduction
Now that Fast Ethernet is here, the question becomes, "How do I start using it ?" Integrating Fast
Ethernet into existing networks need not be done all at once.
Here are some aspects of 100Mbps implementation that should be considered:

Implementing Switching

Eliminating Bottlenecks

Expand The Topology Outwards and Downwards
Implementing Switching
Implement switching in high-traffic areas to concentrate the bottlenecks on the network. Since
Fast Ethernet provides higher throughput of bits, it makes sense to figure out which network
connections need the most relief. Which segments consistently attempt to pump the most bytes?
Which segments consistently demonstrate the highest average percent bandwidth usage according
to your protocol analyzer?
Installing switches will help you figure out which network segments are moving the most
information due to the effect switches have on your network. Installing switches is like moving
from traffic lights to limited-access highways. The idea works extremely well in isolating crosstown traffic, e.g. peer-to-peer networking, but doesn't necessarily help when all of the traffic
slows down at particular locations, e.g. an enterprise-wide server or the network Internet firewall.
Because there are other ways of isolating network bottlenecks, implementing switches is
primarily useful when installing 10/100 switches in preparation for 100Mbps Ethernet.
Installing switches also gives the added benefit of segmenting collision domains. In classic
Ethernet, there can be up to four hubs or repeaters between any two stations, but in Fast Ethernet
that number is only one or two. Installing switches in place of repeaters spares you having to
segment your network at a later point, allowing the cost of the transition to be spread over a
longer period of time.
Eliminating Bottlenecks
Once bottlenecks have been identified, upgrade those network connections to 100 Mbps. The
primary difficulty in this step is verifying that the existing cabling will be sufficient for Fast
Ethernet. On UTP, the cable either needs to meet Category 5 specifications or have four pairs
with proper twist maintained on Category 3. If you're planning on using 100BASE-TX, your
wiring closet will also need to be certified for a higher speed. There are many devices available
such as wire pair scanners, which will make this job much easier.
Installing the initial Fast Ethernet connections is much easier if the switches installed earlier are
10/100, capable of operating at either classic Ethernet speeds or Fast Ethernet speeds. If the
switches installed were only 10Mbps switches, they could be used as "hand-me-downs,"
replacing hubs in segments where users require more bandwidth.
Expand The Topology Outwards and Downwards
Gradually work the Fast Ethernet out into the rest of the network, as far out and down as desired.
Note that the price of 10/100 cards is not substantially higher than that of 10Mbps cards, so it
may be a wise idea to plan ahead by installing 10/100 cards when installing new machines.
If there comes a point in the future when 100Mbps Ethernet needs to be implemented on that
machine, all that will need to be changed is the connection on the other end. On the other hand,
upgrading a machine from a 10Mbps card to a 100Mbps card will require reconfiguring the user's
machine, installing a new driver, etc. A short-term expenditure can greatly offset the cost in manhours and down-time later on.
Upgrading And Migrating From Ethernet To Fast Ethernet
Introduction
Here we are going to analyse the following aspects of upgrading/migrating from 10Mbit Ethernet
to 100Mbit Ethernet.

Cabling

Incompatible Implementations

Repeaters In Fast Ethernet
o Replacement Of Illegal Byte
o Codes Data Translation
o Error Handling And Partitioning
Cabling
There are two methods of running Fast Ethernet over UTP and one method of running it over
fibre.
IMPLEMENTATION ..........CABLE TYPE............... NUMBER OF PAIRS
..100BASE-TX ................ Category 5 .........................2
..100BASE-T4..................Category 3 or 5................. ..4
..100BASE-FX.................. Fiber....................... (Not Applicable)
Category 3 cabling is not rated to carry the fast signaling of 100BASE-TX, so 100BASE-T4 must
be used. 100BASE-T4 may also be used on Category 5 cabling, but 100BASE-TX is probably a
better choice.
Incompatible Implementations
Fast Ethernet brings a new urgency to an old problem. Many network technologies use RJ-45
connectors. In the past, it was usually not difficult to figure out whether a jack was Ethernet or
token ring: even at a site where both were in use they seldom were found in the same vicinity, so
the network administrator could make an "educated guess". Today, with Fast and classic Ethernet
interspersed and 10/100 cards common, some mechanism is needed to allow quick identification
of the signal that is running across the wire.
Autonegotiation works by having each end of the connection send a series of pulses down the
wire to the other end. These pulses are the same signals used in 10Base-T to test link integrity and
cause the link indicator light to turn on. If a station receives a single pulse, referred to as a
Normal Link Pulse (NLP), it recognizes that the other end is only capable of 10Base-T.
If autonegotiation is being used, a station will transmit a series of these pulses spaced closely
together, referred to as a Fast Link Pulse (FLP). An FLP consists of 17 "clocking" pulses
interspersed with up to 16 "signal" pulses to form a 16-bit code word. If a signal pulse occurs
between two clocking pulses, that bit is a one. Absence of a signal pulse is a zero.
By comparing the 16-bit code words received in the FLP, a station and hub will agree on what
implementation of Ethernet to use. The 16-bit code word describes what implementations of
Ethernet are supported. Both station and hub will compare what it supports to what the other end
supports, then choose which implementation to use for that link according to following priorities,
defined by IEEE 802.3 clause 28B.3:
100BASE-TX full duplex
100BASE-T4
100BASE-TX 1
10BASE-T full duplex
10BASE-T
If the station supports 100BASE-T4, 100BASE-TX, and 10BASE-T and the hub supports full
duplex 100BASE-TX, single-duplex 100BASE-TX, and 10BASE-T, they will each discover that
the Ethernet implementations they have in common are 100BASE-TX and 10BASE-T. Since
100BASE-TX is defined to have a higher priority that 10BASE-T, the station and hub will use
100BASE-TX. This decision takes place independently on each side of the link, but since each
side uses the same decision-making process and priorities, the same decision is reached on each
end. Because each end of the connection agrees on what implementation of Ethernet is being
used, the potential problem of incompatible signaling is averted.
Repeaters In Fast Ethernet
In Fast Ethernet the number of repeaters allowed per network segment is only 1 or 2. Whether
one or two repeaters may be used is determined by what class of repeater will be used on the
segment. Two classes of Fast Ethernet repeater are defined, Class I and Class II. Only one Class I
repeater can be used in a single collision domain. Two Class II repeaters are allowed in a single
collision domain, with up to a 5 metre inter-repeater link between them. The only technical
difference between Class I and Class II repeaters is that Class II repeaters are faster than Class I
repeaters. This allows Class I repeaters to provide other services besides simple repeating, such as
translating between 100BASE-TX and 100BASE-T4. Class II repeaters are primarily used to link
two hubs supporting only a single implementation of Fast Ethernet.
However, with the trade-off in fewer repeaters comes greater intelligence in each repeater. In
addition to implementing the functionality of 10Mbps repeaters, 100Mbps repeaters are
responsible for the following:
Replacement Of Illegal Byte
Unlike classic Ethernet, Fast Ethernet does not send a straightforward representation of the actual
bits across the physical layer. A different representation of the information is sent instead. As a
result, there are possible patterns on the wire which are not defined for use in Fast Ethernet. If a
repeater detects an illegal pattern on the wire, it may replace that pattern (and every remaining
pattern in the frame) with a special symbol identifying that the frame is corrupt.
Codes Data Translation
For repeaters that implement more than one implementation of Ethernet, the repeater will change
the data encoding to be appropriate to the outgoing ports. 100BASE-T4 and 100BASE-TX use
very different representations when sending data across a network. A Class I repeater which
implements both 100BASE-TX and 100BASE-T4 needs to ensure that the signal going across the
wire is the appropriate representation for the Ethernet implementation.
Error handling and partitioning
A Fast Ethernet repeater will monitor the state of each port in order to protect the network from
any faults that might interrupt the flow of information.
If 60 consecutive collisions are detected from any particular port, the repeater will partition that
port: it will stop forwarding information from that port to the rest of the network, but will still
continue to repeat all frames from the network to the port. If the station on that port has broken so
that it no longer is obeying the rules of CSMA/CD, then it needs to be separated from the network
to allow traffic to flow.
However, it is possible that there could be 60 consecutive collisions on an extremely busy
segment, so the repeater still forwards information to that port. If the repeater detects between
450 and 560 bits of information from that port without a collision occurring, the repeater will reactivate that port. A legal frame is received from the partitioned port, so we know that the
hardware is working.
If between 40000 and 75000 consecutive bits are received from a port, the device at the other end
of that cable is assumed to be "jabbering", sending an endless stream of bits, so the output from
the port is cut off from the rest of the network. Such a "jabbering" device could prevent any
traffic from flowing on a network, since there would never be a break for the other stations to
transmit. If the station stops "jabbering", then the repeater will once again activate the port.
In 100BASE-TX and 100BASE-FX, a repeater will further monitor traffic to ensure that only
frames with a valid preamble are passed. If two consecutive "false carrier events" occur, or a
"false carrier event" lasts for 450-500 bits, the repeater will declare that link to be "unstable" and
stop sending information to that port. As a result, faulty links are isolated from the rest of the
network, resulting in improved overall network reliability. The link will be reactivated if between
24814 and 37586 bit-times have passed without any information having been received, or if a
valid carrier is received after between 64 and 86 bit-times of idle have occurred.
802.3 Fast Ethernet (100 Mb/Sec) Model
Introduction
Here we see a logical drawing of the Fast Ethernet Data Link Layer sublayers. Data is passed
down from the upper layers (such as TCP/IP or Novell Netware) to the LLC sublayer. From there
it is passed to the MAC sublayer and then, depending on whether this is a 100BASE-T4 or
100BASE-TX environment, either down the right or left-hand path to the wire.
We will intentionally avoid a detailed discussion of exactly what goes on at each of these layers
here. Some of the layers' functions, such as 8B6T encoding, Fan-out and NRZI signaling are
labeled and will be discussed in this essay.
In 10Mbps Ethernet, the data is handed directly from the MAC layer to the PMA (Physical
Medium Attachment) sublayer and onto the wire. The Reconciliation, PCS and PMD sublayers
do not exist in 10Mbps Ethernet.
Troubleshooting techniques for Fast Ethernet
Introduction
This page will primarily discuss problems unique to Fast Ethernet.

The Collision Domain

Incompatible Ethernet Jabber

Auto-negotiation Priorities And Alternatives

Incompatible Cabling Specifications
The Collision Domain
The single biggest change in network design in Fast Ethernet is the smaller collision domain.
Technically, the size of a collision domain in all flavors of Ethernet is exactly the same - 256 bits.
On the wire, ten times as many 100Mbps bits can occupy the same space as an equal number of
10Mbps bits, so the collision domain in 100Mbps Ethernet can be only physically one tenth the
size of a 10Mbps collision domain.
Effectively this means that whereas up to four hubs can legally be cascaded in 10Base-T between
any two stations, only one (or two) hubs can be used in a single segment in 100BASE-T without
going through an interconnect device that provides link segmentation; such as a store-andforward bridge, switch or bridge, or a router. A separate section of the Compendium discusses
INTERCONNECT DEVICES in detail. If you see signs of corruption on your network that
correspond to propagation delay, check to make sure that you're not cascading too many hubs.
You can make some generalizations regarding the structure of corrupted data frames (as
discussed in the 10 Mbps Ethernet FRAME CORRUPTION section) but remember that these
corruption patterns may be quite misleading, since you have a hub or switch in the network.
Note that many hub vendors sell stackable hubs. Hubs in a single stack connected via a common
backplane are usually considered to be a single hub in terms of propagation delay, but multiple
stacks cascaded externally via 100BASE-TX, 100BASE-T4, or 100BASE-FX could definitely
cause problems. These 100BASE standards are discussed in the INTRODUCTION to this Fast
Ethernet section.
Incompatible Ethernet Jabber
Another potential problem in 100Mbps Ethernet is the use of RJ-45 jacks for more than one
flavor of Ethernet. Since 100BASE-TX and 100BASE-T4 both use RJ-45 jacks, as do 10Base-T
and many other network technologies, the IEEE 802.3 specified an auto-negotiation protocol to
allow stations to figure out the networking technology to use.
Unfortunately, they made its implementation optional. If you're using equipment that does not
implement IEEE-spec auto-negotiation, the incompatible Ethernet signals could prevent one of
your stations from connecting to your network, or even simulate "jabber" by constantly
transmitting a TX idle stream and bringing down the network.
The possibility for this jabber is uncertain, considering that the flavors of Ethernet use different
signal formats in transmission. Even if data is not exchanged, it is still possible that incompatible
Ethernet flavors could assume that they have a proper connection. Ethernets using RJ-45
connections to a hub use a Link Test Pulse to verify link integrity. This pulse is the same in all
flavors of Ethernet if auto-negotiation is not used. The auto-negotiation protocol itself uses a
modified form of these pulses to negotiate a common Ethernet implementation.
If Ethernet incompatibility jabber were to occur between 100BASE-TX and another flavor of
Ethernet, the results could be catastrophic, as 100BASE-TX transmits a continuous idle signal
between frames. Although transparent to 100BASE-TX, this idle signal would completely busy
out a 10Base-T or 100BASE-T4 segment. On the other hand, the 802.3 specifies that a Fast
Ethernet repeater should implement jabber control, automatically partitioning off any port that is
streaming information for more than 40000 to 75000 bits. If the repeater were to partition off the
"jabbering" port, the symptom would be reduced to inability to connect the 100BASE-TX station
to the network.
Auto-negotiation Priorities And Alternatives
If the station and repeater both support 100BASE-TX and 100BASE-T4 and 802.3 autonegotiation, the link will autonegotiate to 100BASE-T4 instead of 100BASE-TX. Since
100BASE-TX requires Category 5 cabling but 100BASE-T4 requires only Category 3,
100BASE-T4 is assumed to be a better default.
If the cabling is known to be UTP-5, then it is probably more efficient to turn off auto-negotiation
and use 100BASE-TX wherever possible. 100BASE-T4 requires more overhead than TX because
it multiplexes and demultiplexes the data stream over three wire pairs. There is also significantly
less overhead in translating between 100BASE-TX and 100BASE-FX than between 100BASET4, as TX and FX both use 4B5B encoding instead of T4's 8B6T. 100BASE-TX and 100BASEFX also leave open the possibility of Full Duplex communication, although full duplex is not yet
part of the 802.3 spec.
On the other hand, 100BASE-TX sends an idle signal whenever it is not transmitting data. The
802.3 spec implies that it may very well be preferable to use 100BASE-T4 for battery-powered
operation, since the card would only be transmitting when there is actual information to be
moved.
Incompatible Cabling Specifications
One final problem with the advent of Fast Ethernet is the different cabling specifications. In
classic Ethernet it was difficult to mistake 10Base-2 for 10Base-5. With Fast Ethernet, special
care must be taken to verify that the entire connection between station and concentrator either
supports TX's 31.25MHz signal or maintains T4's four pairs with proper twist. There are a
number of good cable testers and pair scanners available to assist you in determining this for your
network.
Introduction To Firewalls
Introduction
A firewall is simply a system designed to prevent unauthorised access to or from a private
network. Firewalls can be implemented in both hardware and software, or a combination of both.
Firewalls are frequently used to prevent unauthorised Internet users from accessing private
networks connected to the Internet. All data entering or leaving the Intranet pass through the
firewall, which examines each packet and blocks those that do not meet the specified security
criteria.
Generally, firewalls are configured to protect against unauthenticated interactive logins from the
outside world. This helps prevent "hackers" from logging into machines on your network. More
sophisticated firewalls block traffic from the outside to the inside, but permit users on the inside
to communicate a little more freely with the outside.
Firewalls are also essential since they can provide a single block point where security and audit
can be imposed. Firewalls provide an important logging and auditing function; often they provide
summaries to the admin about what type/volume of traffic that has been processed through it.
This is an important point: providing this block point can serve the same purpose (on your
network) as a armed guard can (for physical premises).
Theoretically, there are two types of firewalls:
1. Network layer
2. Application layer
They are not as different as you may think, as described below.
Which is which depends on what mechanisms the firewall uses to pass traffic from one security
zone to another. The International Standards Organization (ISO) Open Systems Interconnect
(OSI) model for networking defines seven layers, where each layer provides services that higherlevel layers depend on. The important thing to recognize is that the lower-level the forwarding
mechanism, the less examination the firewall can perform.
Network layer firewalls
This type generally makes their decisions based on the source address, destination address and
ports in individual IP packets. A simple router is the traditional network layer firewall, since it is
not able to make particularly complicated decisions about what a packet is actually talking to or
where it actually came from.Modern network layer firewalls have become increasingly more
sophisticated, and now maintain internal information about the state of connections passing
through them at any time.
One thing that's an important difference about many network layer firewalls is that they route
traffic directly though them, so to use one you either need to have a validly assigned IP address
block or to use a private internet address block. The network layer firewalls tend to be very fast
and tend to be mostly transparent to its users.
Application layer firewalls
These generally are hosts running proxy servers, which permit no traffic directly between
networks, and which perform elaborate logging and examination of traffic passing through them.
Since proxy applications are simply software running on the firewall, it is a good place to do lots
of logging and access control. Application layer firewalls can be used as network address
translators, since traffic goes in one side and out the other, after having passed through an
application that effectively masks the origin of the initiating connection.
Having an application in the way in some cases may impact performance and may make the
firewall less transparent. Early application layer firewalls are not particularly transparent to endusers and may require some training. However more modern application layer firewalls are often
totally transparent. Application layer firewalls tend to provide more detailed audit reports and
tend to enforce more conservative security models than network layer firewalls.
The Future of firewalls sits somewhere between both network layer firewalls and application
layer firewalls. It is likely that network layer firewalls will become increasingly aware of the
information going through them, and application layer firewalls will become more and more
transparent. The end result will be kind of a fast packet-screening system that logs and checks
data as it passes through.
Firewall Topologies
Introduction
In this section we are going to talk about the different ways a firewall can be set up. Depending
on your needs, you can have a very simple firewall setup which will provide enough protection
for your personal computer or small network, or you can choose a more complicated setup which
will provide more protection and security.
Let's have a look starting from the simple solutions, and then move on to the more complicated
ones. Just keep in mind we are not talking about a firewall which is only a piece of software
which runs on the same computer you use to connect to the internet and do your work, but we are
talking about a physical computer which is a dedicated firewall.
A Simple Dual-Homed Firewall
The dual-homed firewall is one of the simplest and possibly most common way to use a firewall.
The Internet comes into the firewall directly via a dial-up modem (like me :) ) or through some
other type of connection like an ISDN line or cable modem. You can't have a DMZ (See the
DMZ page for more info) in this type of a configuration.
The firewall takes care of passing packets that pass its filtering rules between the internal network
and the Internet, and vice versa. It may use IP masquerading and that's all it does. This is known
as a dual-homed host. The two "homes" refer to the two networks that the firewall machine is part
of - one interface connected to the outside home, and the other connected to the inside home.
This particular setup has the advantage of simplicity and if your Internet connection is via a
modem and you have only one IP address, it's what you're probably going to have to live with
unless you create a more complex network like the one we are going to talk about.
A Two-Legged Network with a full exposed DMZ
In this more advanced configuration, shown in the picture below, the router that connects to the
outside work is connected to a hub (or switch).
Machines that want direct access to the outside world, unfiltered by the firewall, connect to this
hub. One of the firewall's network adapters also connects to this hub. The other network adapter
connects to the internal hub. Machines that need to be protected by the firewall need to connect to
this hub. Any of these hubs could be replaced with switches for added security and speed, and it
would be more effective to use a switch for the internal hub.
There are good things about the exposed DMZ configuration. The firewall needs only two
network cards. This simplifies the configuration of the firewall. Additionally, if you control the
router you have access to a second set of packet-filtering capabilities. Using these, you can give
your DMZ some limited protection completely separate from your firewall.
On the other hand, if you don't control the router, your DMZ is totally exposed to the Internet.
Hardening a machine enough to live in the DMZ without getting regularly compromised can be
tricky.
The exposed DMZ configuration depends on two things: 1) an external router, and 2) multiple IP
addresses.
If you connect via PPP (modem dial-up), or you don't control your external router, or you want to
masquerade your DMZ, or you have only 1 IP address, you'll need to do something else.There are
two straightforward solutions to this, depending on your particular problem.
One solution is to build a second router/firewall. This is useful if you're connecting via PPP. One
machine is the exterior router/ firewall (Firewall No.1). This machine is responsible for creating
the PPP connection and controls the access to our DMZ zone. The other firewall (Firewall No.2)
is a standard dual-homed host just like the one we spoke about at the beginning of the page, and
its job is to protect the internal network. This is identical to the situation of a dual homed firewall
where your PPP machine is the local exterior router.
The other solution is to create a three-legged firewall, which is what we are going to talk about
next.
The Three-legged firewall
This means you need an additional network adapter in your firewall box for your DMZ. The
firewall is then configured to route packets between the outside world and the DMZ differently
than between the outside world and the internal network. This is a useful configuration, and I
have seen many of our customers using it.
The three-legged setup can also give you the ability to have a DMZ if you're stuck with the
simple topology outlined first (dual homed firewall). Replace "router" with "modem," and you
can see how this is similar to the simple topology (dual homed firewall), but with a third leg stuck
on the side :)
If you're being forced or have chosen to IP masquerade, you can masquerade the machine or
machines in the DMZ too, while keeping them functionally separate from protected internal
machines. People who have cable modems or static PPP connections can use this system to run
various servers within a DMZ as well as an entire internal network off a single IP address. It's a
very economic solution for small businesses or home offices.
The primary disadvantage to the three-legged firewall is the additional complexity. Access to and
from the DMZ and to and from the internal network is controlled by one large set of rules. It's
pretty easy to get these rules wrong if you're not careful !
On the other hand, if you don't have any control over the Internet router, you can exert a lot more
control over traffic to and from the DMZ this way. It's good to prevent access into the DMZ if
you can.
And I think that just about completes our discussion of Firewall Topologies !
The DMZ Zone
Introduction
The De-Militarized Zone, or DMZ, is an expression that comes from the Korean War. There, it
meant a strip of land forcibly kept clear of enemy soldiers. The idea was to accomplish this
without risking your own soldiers' lives, thus mines were scattered throughout the DMZ like
grated Romano on a plate of fettucine :) The term has been assimilated into networking, without
the cheese :)
Network geeks use it to mean: "a portion of your network which, although under your control, is
outside your heaviest security." Compared to the rest of your network, machines you place in the
DMZ are less protected, or flat-out unprotected, from the Internet.
Once a machine has entered the DMZ, it should not be brought back inside the network again.
Assuming that it has been compromised in some way, bringing it back into the network is a big
security hazard.
Use of the DMZ
If you decide to build one, what do you do with it? Machines placed in the DMZ usually offer
services to the general public, like Web services, domain name services (DNS), mail relaying and
FTP services (all these buzzwords will be explained next). Proxy servers can also go in the DMZ.
If you decide to allow your users Web access only via a proxy server, you can put the proxy in
the firewall and set your firewall rules to permit outgoing access only to the proxy server.
As long as you've attended to the following points, your DMZ should be ok:
If you put a machine in the DMZ, it must be for a good reason. Sometimes, companies will set up
a few workstations with full Internet access within the DMZ. Employees can use these machines
for games and other insecure activities. This is a good reason if the internal machines have no
Internet access, or extremely limited access. If your policy is to let employees have moderate
access from their desktops, then creating workstations like this sends the wrong message. Think
about it: The only reason why they would use a DMZ machine is if they were doing something
inappropriate for the workplace !
It should be an isolated island, not a stepping stone. It must not be directly connected to the
internal network. Furthermore, it shouldn't contain information that could help hackers
compromise other parts of the network. This includes user names, passwords, network hardware
configuration information etc.
It must not contain anything you can't bear to lose. Any important files placed on the DMZ
should be read-only copies of originals located within the network. Files created in the DMZ
should not be able to migrate into the network unless an administrator has examined them. If
you're running a news server and would like to archive news, make sure the DMZ has its own
archival system.
What sort of things shouldn't you do? Example: If you're running an FTP server in the DMZ,
don't let users put confidential information on there so they can get it from home later.
It must be as secure a host as you can make it. Just because you're assuming it's secure doesn't
guarantee that it is. Don't make it any easier for a hacker than absolutely necessary. A hacker may
not be able to compromise your internal network from your DMZ, but they may decide to use it
to compromise somebody else's network. Give serious thought to not running Windows on your
DMZ machines; it's inherently insecure and many types of intrusions can't be detected on
Windows. Linux or openbsd can provide most, if not all, the needed functionality along with a
more secure environment.
DoS & DDoS Attacks
Introduction
In this section we are going to have a quick look at DoS and DDoS attacks, how they are
performed and why they attract so much attention ! We won't be getting into much detail as we
are just trying to give everyone a better understanding of the problem.
Denial of Service attacks
Denial of Service (DoS) attacks can be a serious federal crime with penalties that include years of
imprisonment and many countries have laws that attempt to protect against this. At the very least,
offenders routinely lose their Internet Service Provider (ISP) accounts, get suspended if school
resources are involved, etc.
There are two types of DoS attacks:
1) Operating System attacks: Which target bugs in specific operating systems and can be fixed
with patches.
2) Networking attacks: Which exploit inherent limitations of networking and may require firewall
protection.
Operating System Attacks
These attacks exploit bugs in a specific operating system (OS), which is the basic software that
your computer runs, such as Windows 98 or MacOS. In general, when these problems are
identified, the vendor, such as Microsoft, will release an update or bug fix for for them.
So, as a first step, always make sure you have the very latest version of your operating system,
including all bug fixes. All Windows users should regularly visit Microsoft's Windows Update
Site (and I mean at least once a week!) which automatically checks to see if you need any
updates.
Networking Attacks
These attacks exploit inherent limitations of networking to disconnect you from your ISP, but
don't usually cause your computer to crash. Sometimes it doesn't even matter what kind of
operating system you use and you cannot patch or fix the problem directly. The attacks on Yahoo
and Amazon by "mafiaboy" were large scale networking attacks and demonstrated that nobody is
safe against a very determined attacker.
Network attacks include ICMP flood (ping flood) and smurf which are outright floods of data to
overwhelm the capacity of your connection, spoofed unreach/redirect also known as "click"
which tricks your computer into thinking there is a network failure and voluntarily breaking the
connection (this is used to disconnect MIRC users), and a whole new generation of distributed
denial of service attacks (we speak about them later on).
Just because you were disconnected with some unusual error message doesn't mean you were
attacked. Almost all disconnects are due to natural network failures. On the other hand, you
should feel suspicious if you are frequently disconnected.
What can you do about networking attacks? If the attacker is flooding you, essentially you need
to have a better connection than he does. Otherwise your only recourse may be a firewall run by
your ISP.
Distributed Denial-of-Service
A distributed denial-of-service (DDoS) attack is similair to the DoS attack described above, but
involves a multitude of compromised systems which attack a single target, thereby causing denial
of service for users of the targeted system. The flood of incoming messages to the target system
essentially forces it to shut down, thereby denying service to the system to legitimate users.
A hacker (or, if you prefer, cracker) begins a DDoS attack by exploiting a vulnerability in one
computer system and making it the DDoS "master." It is from the master system that the intruder
identifies and communicates with other systems that can be compromised. The intruder loads
cracking tools available on the Internet on multiple -- sometimes thousands of -- compromised
systems. With a single command, the intruder instructs the controlled machines to launch one of
many flood attacks against a specified target. The result of these packets which are sent to the
target causes a denial of service.
While the press tends to focus on the target of DDoS attacks as the victim, in reality there are
many victims in a DDoS attack -- the final target and as well the systems controlled by the
intruder.
Locking Windows
Introduction
Static IPs are part of the persistent-connection problem, but Windows itself is also to blame.
(Consumer editions of Windows, anyway--NT and Windows 2000 are a different game entirely.)
Windows 95 and 98 are full of security gaps. Here are a few things you should do to close them
up.
What To Do
Turn off file sharing if you don't need it. If you're not sharing files with other computers--usually
you would do so over a home network--then disabling this feature closes up plenty of holes. To
ensure file sharing is off, right-click Network Neighborhood and pick Properties. Click the button
labeled "File and Print Sharing" and make certain that both boxes in the
resulting dialog box are unchecked.
Set up file sharing carefully if you need to use it. Right-click Network Neighborhood, choose
Properties, and click "File and Print Sharing." Check the box next to "I want to give others access
to my files." Next, pick or create a specific folder you'll let people access, such as c:\My
Documents\Photos. In Windows Explorer, right-click the folder and pick Sharing from the
context menu. In the dialog box that appears, click the radio button next to Shared As: and enter a
name for the folder in the field to the right. (The name you choose is the name that will appear to
those who browse the folder over the network or the Internet).
If you want people to be able to add, remove, or change documents in the folder, click the Full
radio button under Access Type.
If you want people to be able only to copy or look at the files in the folder, click the Read Only
radio button.
In either case, be sure to enter a password (no fewer than four and no more than eight characters)
in the field at the bottom of the dialog box. The dialog box will allow you to click OK without
your entering a password, but in that case, anybody who browses the folder will get access to the
files inside.
Monitor your shared folders using the Windows Net Watcher utility. The app displays all the
users currently connected to shared folders and lets you disconnect them if necessary. The utility
isn't part of Windows 95 or 98's default installation, but you can install it from your Windows
CD-ROM by following these steps:
1.Click Start, Settings, Control Panel and open Add/Remove Programs.
2.Click the Windows Setup tab. In Windows 98, scroll down the list of setup categories and
double-click System Tools. In Windows 95, find and double-click Accessories.
3.Check the box next to Net Watcher, and click OK twice to exit the dialogs.
4.Windows will install Net Watcher. After your system's rebooted, choose Start, Programs,
Accessories, System Tools, Net Watcher to launch the utility.
Download system patches. Windows 98 users can head to the Windows Update Web site to
automatically download security-related patches for their operating system. If you're still using
Windows 95, you'll have to download each Security Update patch manually at the Windows 95
Downloads page.
Check your shields. After you've taken the steps above, the Shields UP! Web site (run by Gibson
Research Corporation) can look at your connection to the rest of the world and let you know if
any holes remain. Drop by and see if you have any further vulnerabilities. Shields UP! also
contains some extremely in-depth advice regarding Windows networking settings.
Securing Your Home Network
Introduction
Most people who use computers these days have had to deal with a security issue of some kind –
whether they are aware of it or not. Everyone has been infected by one of the many worms or
viruses floating around the Internet, or have had someone use your password. Most home
computer users are victims of attacks that they have no idea about.
For example, certain programs called ‘spyware' come packaged into seemingly friendly programs
you download, this spyware can do any one of a number of things, though most often they send
your personal information (such as name and email address) and information about what sites you
visit to certain companies.
These in turn will sell your personal information to the spammers and email marketers who will
proceed to clog your inbox with junk that they think you might be interested in. To explain how
this works, you download a program – say a video player – from the Internet and install it. In the
background it installs some spyware. Now you start surfing to car sites, soon you can expect your
email inbox to be full of spam offering you great deals on used cars etc.
A lot of people work on the principle that their home computer contains nothing interesting
enough for an attacker, what they don't realise is that while an attacker may not target your
system specifically, it is very common for them to use programs that will scan vast ranges of the
Internet looking for vulnerable systems, if yours happens to be one, it will be automatically taken
over and placed at the attackers command. From here he can do a variety of things, like using
your computer to attack other sites on the Internet or capturing all your passwords.
Worms and email viruses work the same way, they infect one machine, and then spread by trying
to email themselves to everyone in your guest book, or turning your machine into a scanning
system to find other targets. They may even contain a malicious payload that can destroy your
files, or even worse – email your private documents to everyone you know (this was the case with
a worm a few years ago).
Given that the things we use the computer for these days such as online shopping for books or
music, electronic banking etc, these threats have a more serious implication than most people
realise. You may not have anything worthwhile on your computer, but what if an attacker is able
to steal your credit card information when you are buying a book from Amazon.com, or steal the
password to your online banking account ?
Luckily the steps you have to take to secure your own PC are fairly simple and can be
accomplished by non-technical users given the right guidance. If you follow the guidelines we
have given here, you will be safe from most forms of Internet based threats. So here are a few
steps you can take.
Email Security
A lot of viruses these days, such as the recent MyDoom virus, spread by emailing themselves to
people as an attachment, the email can appear to come from anywhere.. most often it will appear
to come from a friend, or an address like [email protected] if you use a yahoo account. The
email will try and convince you to download and run the attachment which may appear to be a
harmless JPG image or SCR screensaver. In fact, the attachment is a malicious program (known
as malware), and once opened, can do any of the nasty things we've listed above. Here are the
rules you should follow when checking your email.
1. Has the email come from someone you know ? If so, were you expecting the email and
its attachment ? If not, try and confirm with the person over the phone or some other
medium.
2. Does the message make sense ? If you receive an email from your computer illiterate
parents saying ‘download this new screensaver', you can be quite sure something is fishy.
3. Does the email appear to come from someone in authority ? If the email comes from what
appears to be the administrator of your email service, you should double check with
them. No email service will ever ask you to reveal your password, or threaten to
terminate your account unless you download the instructions in the attachment. If you are
unsure, always contact their tech-support personnel before opening any attachment.
If you've followed the above steps, and you still think you need to download the attachment,
make sure you scan it before downloading. Most popular email services like Hotmail and Yahoo
offer you the facility of scanning the attachment, use this feature ! Once you've downloaded it, it
never hurts to scan it with your own anti-virus software which you should have installed (we will
talk about this in the next tip). Only after you are completely certain this attachment is safe,
should you download it. If it is a program (ending in .exe, or something like .jpg.exe), then you
should be extra careful. Remember that anti-virus scanners must be up to date to be able to catch
new viruses, and even then, you may encounter a virus before the anti-virus companies have been
able to analyse it.
Install An Anti-virus Software
90% of the threats you will face as a home user will come not from hardcore cyber criminals, but
from automatic spreading viruses known as worms. The best way to guard against virus threats is
to download a good anti-virus scanner. Two of the best ones are Norton AntiVirus and McAfee .
Remember that the anti-virus needs to have its scanning database (known as virus definitions)
regularly updated. You should try and update the definitions once a week. The longer you put it
off for, the larger the new definitions package will be, and the more viruses your system will be
vulnerable to. All the virus scanners offer some form of automatic update system so that you don't
have to remember to keep updating the definitions yourself. Use this feature.
Disable Windows File Sharing
Most people know that Windows allows you to share files with other people on your network.
This is called “Windows File Sharing”, and is what you make use of whenever you open network
neighborhood. What most people don't know is that even if you don't specifically choose folders
to share, Windows automatically shares your entire hard-disk with anyone who knows your
system's Administrator account password. Not just will it share the hard-disk, it will allow the
person full read and write access to the disk. To disable file sharing in Windows XP, go through
the following steps:
1. Go to the Start menu and select the Control Panel.
2. In the Control Panel window, double-click on Network Connections.
3. Right-click on the icon for your network connection in the window that appears. You can
do this for all your network connections (e.g. VSNL, LAN etc)
4. From the menu which appears, choose Properties (use the left mouse button to make your
selection).
5. Under This connection uses the following items, highlight File and Printer Sharing for
Microsoft Networks.
6. Click Uninstall.
7. When you are asked if you are sure you want to uninstall File and Printer Sharing for
Microsoft Networks, click Yes.
8. Click OK or Close to close the Local Area Connection Properties window.
It is also important to understand that most people just press enter when prompted to choose an
Administrator password during the install. This is a very bad idea, as it means that anyone can log
into your system as an administrator (full access) without supplying a password. Thus you should
try and choose a strong password for the administrator account and any other account that you
may create on the system if you share it with other people. Read the tip on choosing strong
passwords later on.
Update the Operating System
From time to time, people discover bugs or vulnerabilities in operating systems. These
vulnerabilities often allow an attacker to exploit something built into your operating system and
take it over. To give you a simple example, a vulnerability may be found in MSN Messenger and
an attacker can exploit it to gain control of your system. Whenever such a vulnerability is found,
the operating system vendors release what are known as ‘patches' which will fix the problem.
If you make sure your system is up to date with the latest patches, an attacker will not be able to
exploit one of these vulnerabilities. To update windows, you have to run the ‘Windows update'
service, either by clicking ‘Start >> Programs >> Windows update”, or by going to
http://windowsupdate.microsoft.com/ . >From there you can scan your system for missing
patches and then download the ones you need. You should try and do this regularly so that the
backlog of patches you need to download is not very large. If you miss out on a lot of patches, the
download could be really huge. This is also the case when you reinstall the operating system.
Install A Personal Firewall
A personal firewall is a piece of software that runs on your machine and lets you decide exactly
what data is allowed to enter or leave your machine over the network. For example, if an attacker
is scanning your system for vulnerabilities, it will alert you. If an attacker is just looking through
ranges of the Internet for targets, your system will not respond to your probes.
In short, your system operates in a stealthy mode – invisible to an attacker. You also need to be
careful about what data leaves your system via the network. Viruses and worms that try and email
themselves to other people or use your machine to scan for more victims, spyware tries to send
data back to an advertiser, and trojan horse programs may try to connect to an attacker. The
personal firewall helps by alerting you every time a program tries to access the network
connection. This can be tricky to novice users because even when legitimate programs such as
Internet Explorer try to access the internet, the firewall will pop-up a warning box.
However, if you are unsure if an alert is malicious or not, most firewalls have a ‘more info' button
on the alert which will take you to their website and tell you whether the program is a legitimate
one or a known offender. A personal firewall is no good if you just keep answering ‘yes' to every
program that wants to access your internet connection.
Take the trouble to understand what programs on your machine need legitimate access and only
allow those. For example if you just downloaded a new screensaver program and the firewall says
it wants to access the internet, you can be pretty sure it is trying to send some data back
somewhere. It may be spyware or a trojan. Soon you will get used to weeding out the suspicious
programs. If you have a permanently on connection like cable-modem or DSL, you should most
definitely install a personal firewall. Some of the good ones you can get are:
ZoneAlarm – Very easy to install and use, there is a free version with a few less features than the
professional version. Gives you very good information about the alerts it generates. Considered
the market leader.
BlackICE – Another very highly rated personal firewall, it is not as user friendly as ZoneAlarm,
but allows for some further configuration options
Sygate Personal Firewall – Also less user friendly, but it allows you to make some very powerful
configuration changes and it contains a rudimentary intrusion detection system to alert you about
common attacks.
If you go to any search engine and search for ‘personal firewall' you will find a whole lot of other
options. If you use Windows XP, it is a good idea to turn on the built in Internet Connection
Firewall by double clicking on your connection icon near the clock, clicking properties >>
advanced >> Protect my computer and network…. This built in firewall is not meant to be a
replacement for a full solution like the ones above. It only filters incoming traffic and will not
alert you if a trojan or worm tries to use your machine for some malicious purpose.
Scan For Spyware
All through this article we have talked about spyware that lets companies customise their
advertising by watching what you do on the net. While spyware may not be destructive, it is one
of the biggest pests around and will result in a mailbox full of spam before you know it. However
there are a number of tools that will scan for well known spyware on your machine and will allow
you to delete it safely.
Note that AntiVirus packages do not usually alert you when you install spyware because it is not
considered harmful to the computer itself. Two of the most popular programs for detecting and
removing spyware are Ad-aware and Spybot Search & Destroy .
Choose Strong Passwords
Most of the time an attacker need not resort to a technical hack to break into a system because he
can simply guess at poorly chosen passwords. Here are some general rules when selecting a
password :
1. Do not use a word which can be found in a dictionary, or a birthdate / name these are
very easy to crack
2. Adding numbers like 123 at the end does not make it more difficult to crack the password
3. Choose at least a 6 character long password.
4. Use different capitalisation for the letters, e.g. “suRViVor” (Don't use this one, its in a
dictionary remember… its just an example)
5. Add some random numbers to the end or in the middle
6. If possible use a few special characters like !(;,$#& etc.
7. When choosing a password hint question, choose one that only you will be able to
answer. “What is my birthdate ?” is something anyone who knows you even remotely
will be able to guess.
A very useful method for choosing an easy to remember random password is to take a line of a
song that you remember and then take the first letter of each word in that line. Now you can
randomise the capitalisation, add a couple of numbers and special characters, and have a very
strong password that is still difficult to crack.
Remember as far as possible to use a different password for different accounts (e.g. one password
for your personal email, one for work email, one for internet banking). This may make things
more difficult to remember, but in the event that one password gets compromised, the attacker
will not have access to all the other accounts.
Introduction To Network Address Translation (NAT)
Introduction
Network Address Translation, defined by RFC 1631, is becoming very popular in today's
networks as it's supported by almost every operating system, firewall appliance and application.
NAT was born thanks to the fast depletion of public IP Addresses, in other words real IP
Addresses that can only exist on the Internet.
As IP Addresses are 32 Bit, in theory we could have upto 4,294,967,296 IP Addresses (that's
2^32) ! In practice though the number is a lot smaller, somewhere around 3.2 billion, because of
the way the IP Addresses are separated into Classes (Class A, B , C e.t.c) and the need to set aside
special addresses for multicasting (also known as Class D), broadcasting and other functions.
You might have heard or read about IPv6. This new addressing scheme has been designed to
make sure we don't face the same problem as IPv4, but its implementation requires the
modification of the entire Internet infustructure, so don't expect anytime soon to deal with IPv6.
Chances are it's going to co-exist with IPv4, since IPv6 isn't the best solution for small to medium
sized companies or small private networks.
This exciting section will show, and explain in detail, what NAT is, its different modes and how
they work. We will also see how NAT helps protect your network and minimise network security
threats.
Oh, and keep in mind...
You should also be up to scratch in your IP Addressing and Subnetting topics. In the following
sections, there are new concepts introduced which will require you to a have basic understanding
on IP Addressing and Subnetting. Please check the relevant sections if you think you need to
brush up on these before proceeding!
There's more to NAT than meets the eye !
When NAT was released, it was created to provide solutions to almost every type of network
configuration. This is achieved by the various modes in which NAT can function. Depending on
your network structure, your available real (public) IP Addresses and the results you need, you
can enable NAT in 3 different modes! Now don't assume it's hard to understand this cool stuff,
cause I'm telling you it's definitely not! Once you get the hang of the NAT Concept, the rest is
easy to digest, even late at night :)
So What's Covered ?
As with most cool networking topics, it's impossible to cover NAT on one page and if you
happen to find another site that covers NAT in one page, I assure you you're missing out on a lot
of important information, so stick to Firewall.cx :)
With all this in mind, I've split NAT into 6 sections. Each section deals with a particular NAT
mode or NAT topic, giving you an in-depth look on how each NAT mode works using a few
examples, and its advantages over the rest available NAT modes. The information provided has
been carefully selected and written to make sure it covers all ranges of user levels, meaning from
intermediate to advanced.
Section 1: NAT Concepts. A good introduction to NAT followed by its basic functions, how it
works and which devices in a network usually implement NAT. Simple, clear and colourful
diagrams will ensure you grasp this concept without any trouble.
Section 2: NAT Table. This section will introduce the NAT Table, which is the heart of NAT.
Here you will learn the purpose of the NAT table, where it's stored along with a lot of other
interesting information.
Section 3: Static NAT Mode. Learn what Static NAT is and how it functions. Two pages of
detailed diagrams, well thought examples and their analysis along with other rich information
ensures you will learn everything there is about Static NAT.
Section 4: Dynamic NAT Mode. Learn what Dynamic NAT is and how it functions. Simple
diagrams are available to help you understand how Dynamic NAT works and what its advantages
are over Static NAT. Dynamic NAT is analysed over two pages using examples and step by step
analysis, ensuring to capture all the required information and answer every question you might
have.
Section 5: NAT Overload Mode. Also known as IP Masquerading (in the Linux world), Port
Address Translation (PAT) or Dynamic NAT with PAT. Discover the most common NAT mode
for small networks. This NAT mode is used by most Internet sharing software. This section will
help you understand how NAT Overload works and what its benefits are over the rest. Again,
simple diagrams have been designed to make sure you grasp all this cool stuff :)
Section 6: Advanced NAT (Coming Soon). This pages deals with more advanced NAT concepts
and analysis. It contains more detailed and technical information about NAT, thus requires a
slightly more advanced level of networking knowledge and TCP/IP. It also outlines security
concerns and using NAT through VPN's and other complex network configurations.
The type of NAT mode you choose to use, depends on your network resources, capabilities of
your NAT-enabled device and, lastly, your needs. Together we will discover the power of NAT
and understand why its become so popular.
NAT is truly a masterpeice and one of my favourites! I've been eager to develop this section to
show you how cool it is! So grab a cuppa and maybe something to munch on and get ready for an
awesome ride! There's nothing better than knowing how your Firewall/router manipulates all
them cool packets so you can 'safely' access the Internet!
Network Address Translation (NAT) Concepts
Introduction
Before we dive into the deep waters of NAT, we need to make sure we understand exactly what
NAT does. So let me give you the background of NAT, why it's here today and how it works.
Even though there are different modes of NAT they are all basically extensions to the original
concept.
NAT has become so popular that almost all small routers, firewall software and operating systems
support at least one NAT mode. This shows how important it is to understand NAT.
The NAT Concept
NOTE: NAT is not only used for networks that connect to the Internet. You can use NAT even
between private networks as we will see in the pages to follow, but because most networks use it
for their Internet connection, we are focusing on that.
The NAT concept is simple: it allows a single device to act as an Internet gateway for internal
LAN clients by translating the clients' internal network IP Addresses into the IP Address on the
NAT-enabled gateway device.
In other words, NAT runs on the device that's connected to the Internet and hides the rest of your
network from the public, thus making your whole network appear as one device (or computer, if
you like) to the rest of the world.
NAT is transparent to your network, meaning all internal network devices are not required to be
reconfigured in order to access the Internet. All that's required is to let your network devices
know that the NAT device is the default gateway to the Internet.
NAT is secure since it hides your network from the Internet. All communications from your
private network are handled by the NAT device, which will ensure all the appropriate translations
are performed and provide a flawless connection between your devices and the Internet.
The diagram below illustrates this:
As you can see, we have a simple network of 4 hosts (computers) and one router that connects
this network to the Internet. All hosts in our network have a private Class C IP Address, including
the router's private interface (192.168.0.1), while the public interface that's connected to the
Internet has a real IP Address (203.31.220.134).
If you're having trouble understanding, the following diagram shows how the Internet would see
the above setup:
As you can see, the idea behind NAT is really simple. Remember that we have mentioned there
are 3 different NAT modes to suit all types of network configurations. If required you can use
NAT to allow the Internet to see specific machines on your internal network !
Such configurations will allow the Internet to access an internal webserver or ftp server you
might have, without directly compromising your network security. Of course special actions need
to be taken to ensure that your visitors are restricted to the resources you want and that's where
the firewall comes into the picture. We'll discover how all this is possible in the next pages, so be
patient and keep reading !
How NAT works
There are 3 different ways in which NAT works. However, the principle is the same for all 3
modes. To help understand it we need a good, simple example and the first one at the beginning
of this page will do the job just fine.
The trick to understanding how NAT works is to realise that only the device (router, firewall or
pc) that connects directly to the Internet performs NAT. For our example this device happens to
be a router, but it could even be a simple PC; it makes no difference for us.
As you already know, all requests the workstations generate are sent to the Internet via the router.
The router will then perform NAT on these packets and send them to their destination. As each
packet arrives into the router's private interface, the router will strip the source IP Address from
the 3rd layer (network layer) e.g 192.168.0.10 and place its own public IP address
(203.31.220.134) before sending it to the Internet.
This is how the packet then seems to have originated from the router itself. In some cases,
depending on the NAT mode, the source and destination port numbers (layer 4) will be changed
as well but we examine that on the pages that follow. For now, we'll just look at the simple IP
translation within the router.
The illustration below shows how the router modifies the packets:
In this illustration, a workstation from our network has generated a packet with a destination IP
Address 135.250.24.10. Logically, this packet is first sent to the gateway, which performs NAT
on this packet and then sends it to the Internet to finally make its way to the destined host.
Looking more closely at the gateway (router) during the initial NAT operation, the original
packet's Source IP is changed from 192.168.0.12 to that of the router's public interface, which is
203.31.220.134, then the router stores this information in a special address within its memory
(also called NAT Table - explained next), so when the expected reply arrives it will know to
which workstation within its network it needs to forward it.
The next page will show you the heart of NAT, the NAT Table, and briefly explain the function
of each NAT mode.
The Network Address Translation Table
Introduction
After that simple and informative introduction to the NAT concept, it's time to find out more
about how it works and this is where the NAT table comes in.
The NAT Table
The NAT table is the heart of the whole NAT operation, which takes place within the router (or
any NAT-enabled device) as packets arrive and leave its interfaces. Each connection from the
internal (private) network to the external (public-Internet) network, and vice versa, is tracked and
a special table is created to help the router determine what to do with all incoming packets on all
of its interfaces; in our example there are two. This table, known as the NAT table, is populated
gradually as connections are created across the router and once these connections are closed the
entries are deleted, making room for new entries.
The NAT table works differently depending on the NAT mode. This is explained in greater detail
on each NAT mode's page. For now, we just need to get the feeling for this table to facilitate
understanding of each NAT mode.
The larger the NAT table (which means the more memory it occupies), the more bi-directional
connections it can track. This means that a NAT-enabled device with a big NAT table is able to
serve more clients on the internal network than other similar devices with smaller NAT tables.
The illustration below shows you a typical table of a NAT-enabled device while internal clients
are trying access resources on the Internet:
Let's explain what's happening here: The above illustration shows two requests from the private
LAN, hosts 192.168.0.5 and 192.168.0.21, arriving at the NAT-enabled device's (router in this
example) private interface. These packets are temporarily stored in a special area in the router's
memory until small changes are made to them. In this example the router will take each packet's
Source IP (which is the PC the packets have come from) value and replace it with its own Public
IP (203.31.220.134).
The packets are then sent out through the Public interface to their destinations, in this case
120.0.0.2 and 124.0.0.1. In addition, before the packets leave the router, an entry is made for each
packet into the router's NAT table. These entries enable the router to behave appropriately when
the reply for each outgoing packet hits its Public interface.
The above example covers only one specific NAT scenario. Depending on your NAT mode, the
router would have dealt with the packets in a different way. This is analysed later in each NAT
mode's page but, for now, you simply need to understand what the NAT table is and the purpose
it serves.
So what happens when replies come back from the Internet ?
Well, strictly speaking, exactly the opposite from when they are received from the internal
network and sent to the Internet:
When the reply comes back, the router will consult the NAT table, locate the correct entries and
perform another change to the incoming (for the Internet) packets by replacing the "destination
IP" value from 203.31.220.134 to 192.168.0.5 for the first packet, and 192.168.0.21 for the
second. The new packets are then sent to their destination, which are hosts 192.168.0.5 and
192.168.0.21 so the router can then delete their NAT table entries.
With most NAT devices, the NAT session limit is bound by the available memory in the device.
Each NAT translation consumes about 160 bytes in the device's memory. As a result, 10,000
translations (a lot more than would normally be handled by a small router) will consume about
1.6 MB of memory. Therefore, a typical routing platform has more than enough memory to
support thousands of NAT translations but in practice the story (as always) is different.
Typically on smaller Cisco routers, e.g 700, 800, 1600 series, that have an IOS with NAT
capabilities, the number of NAT sessions they are able to track is around 2000 without much
trouble but this also depends on the NAT mode being used. Pump that up to something like 3000
to 4000 sessions and you start having major problems as the NAT table gets too big for the
router's CPU to manage. As you see, it's not only a memory issue :) This is when you start to see
big delays in ping replies and eventually an exponential increase in packet loss.
I've actually seen Cisco routers having some problems while handling NAT translations (NAT
Overload mode in particular). I also confirmed this with Mike Sweeney - a good friend of mine
and webmaster of www.packetattack.com, so keep in mind that the Cisco IOS seems sometimes
to behave a bit weird with NAT. Personally I don't like performing NAT on routers that connect
directly to the Internet, but sometimes your options are limited.
To give you the right idea, having a huge NAT table on a small router is like having a Windows
machine and opening 20 CPU and memory intensive applications at once.... Your PC tries to
open all programs together but, because the CPU is processing so much information, they take
hours to finally start and even then the PC is so slow you can't do any work. I'm sure everyone
has experienced something similar !
The larger router models and dedicated gateway/firewall appliances are able to track a lot more
connections simultaneously (8000 to 25000), which makes them ideal for large corporations that
need such capacity.
Static Network Address Translation (Part 1)
Introduction
Static NAT (also called inbound mapping) is the first mode we're going to talk about and also
happens to be the most uncommon between smaller networks.
Static NAT was mainly created to allow hosts on your private network to be direcly accessible via
the Internet using real public IPs; we'll see in great detail how this works and is maintained. Static
NAT is also considered a bit dangerous because a misconfiguration to your firewall or other
NAT-enabled device can result in the full exposure of the machine on your private network to
which the public IP Address maps, and we'll see the security risks later on this page.
What exactly does Static NAT do ?
As mentioned in the introduction, Static NAT allows the mapping of public IP Addresses to hosts
inside the internal network. In simple english, this means you can have a computer on your
private network that exists on the Internet with its own real IP.
The diagram below has been designed to help you understand exactly how Static NAT works:
In this diagram you can see that we have our private network connected to the Internet via our
router, which has been configured for Static NAT mode. In this mode each private host has a
single public IP Address mapped to it, e.g private host 192.168.0.1 has the public IP Address
203.31.218.208 mapped to it. Therefore any packets generated by 192.168.0.1 that need to be
routed to the Internet will have their source IP field replaced with IP Address 203.31.218.208.
All IP translations take place within the router's memory and the whole process is totally
transparent to both internal and external hosts. When hosts from the Internet try to contact the
internal hosts, their packets will either be dropped or forwarded to the internal hosts depending on
the router's & firewall configuration.
But where would Static NAT be used?
Everyone's needs are different and with this in mind Static NAT could be the solution for many
companies that require a host on their internal network to be visible and accessible from the
Internet.
Let's take a close look at a few examples of places where Static NAT could be used.
Implementation of Static NAT - Example 1
We have a development server (192.168.0.20) that needs to be secure, but also allow certain
customers to gain access to various services it offers for development purposes. At the same time,
we need to give the customers access to a special database located on our main file server
(192.168.0.10):
In this case, Static NAT, with a set of complex filters to make sure only authorised IP Addresses
get through, would do the job just fine.
Also, if you wanted a similar setup for the purpose of using only one service, e.g http, then you're
better off using a different NAT mode simply because it offers better security and is more
restrictive.
Let me remind you that Static NAT requires one public IP Address for each mapping to a private
IP Address. This means that you're not able to map a public IP Address to more than one private
IP Address.
Implementation of Static NAT - Example 2
Another good example of using Static NAT is in a DMZ zone. The principle of having a DMZ
zone is when you require certain machines e.g webservers, email servers, to be directly accessible
to the Internet but at the same time, should these machines be compromised, all data can be
restored without much trouble and they won't expose the internal private network to the Internet.
The diagram above might seem very complex, but it's actually extremely simple. Breaking it
down will help you see how simple it is. If we focus on Firewall No.1 we see that it's connected
to 3 networks, first one is the Internet (203.31.218.X), second one the DMZ (192.168.100.X) and
the third is the small private network between our two Firewalls (192.168.200.X)
Firewall No.1 is configured to use Static NAT for 3 different hosts - that's two from the DMZ
zone and one for Firewall No.2. Each interface of the Firewall must be part of a different network
in order to route traffic between them. This explains why we have so many different IP Addresses
in the diagram, resulting in the complex appearance.
With this setup in mind, the Static NAT table of Firewall No.1 would look like this:
Firewall No.1 Static NAT Table
External Public IP Address
Mapped to Internal Private IP Address
203.31.218.2
Firewall No.1 Public Interface
203.31.218.3
192.168.100.2 - Public WebServer in DMZ
203.31.218.4
192.168.100.3 - Public MailServer in DMZ
203.31.218.5
192.168.200.2 - Firewall No.2 of Private Net.
As you can see, this table is a good summary of what is happening in the diagram above. Each
external IP Address is mapped to an internal private IP Address and if we want to restrict access
to particular hosts then we can simply put an access policy (packet filters) on Firewall No.1. This
type of firewall setup is actually one of my favourites :)
Static Network Address Translation (Part 2)
Introduction
The previous page helped us understand what exactly happens with Static NAT and how it works,
and we saw a few examples of how to use it in various network configurations.
This page will deal with the transformations the packets undertake as they pass through the Static
NAT device, which is normally a router or firewall appliance.
So let's get started ! Now would be a good time to fill that cup of yours and reload yourself with
your special edible supplies :)
How NAT translations take place
So what exactly happens to the packet that enters or exits the Static NAT-enabled device ? Well
it's not that complicated once you get the hang of it. The concept is simple and we're going to see
it and analyse it using an example, which is really the best possible approach.
The process of the Static NAT translation is the same for every device that supports it (assuming
the manufacturer has followed the RFCs). This means that whether we use a router or a firewall
appliance to perform Static NAT they'll both follow the same guidelines.
Consider our example network:
As the diagram describes we have Workstation No.1, which sends a request to the Internet. Its
gateway is the router that connects the LAN to the Internet and also performs Static NAT.
The diagram below shows us how the Workstation's packet is altered as it transits the router
before it's sent to the Internet (outgoing packet):
As you can see, the only thing that changes is the Source IP, which was 192.168.0.3 and was
given the value of 203.31.220.135, which is a real IP Address on the Internet. The Destination IP
Address, Source Port and Destination Port are not modified.
Assuming the packet arrives at its destination, we would most likely expect to see a reply. It
would be logical to assume that the reply, or incoming packet, will require some sort of
modification in order to successfully arrive at the originating host located on our private network
(that's Workstation 1).
Here is how the incoming packet is altered as it transits the router:
The diagram above shows the part of the incoming packet that is altered by the router. Only the
destination IP Address is changed, from 203.31.220.135 to 192.168.0.3 so the packet can then be
routed to the internal workstation. Source IP Address, Source Port and Destination Port remain
the same.
And in case you're wondering why the ports have changed in comparison to the original outgoing
packet, this is not because of NAT but the way IP communications work and happens to be way
out of the scope of this topic.
Now, because I understand that even a simple diagram can be very confusing, here's one more
that summarises all the above. The diagram below shows you what the outgoing and incoming
packets looked like before and after transiting the router:
So there you have it, Static NAT should now make sense to you :)
As you've seen, the concept is very simple and it varies slightly depending on the NAT mode
you're working with. So NAT is not that difficult to understand after all ! If there are still a few
things that are unclear to you, please try reading the page again and keep in mind the forum to
which you can post your questions and doubts !
Next up is Dynamic NAT! So sit tight and let's rock and roll.... :)
Dynamic Network Address Translation (Part 1)
Introduction
Dynamic NAT is the second NAT mode we're going to talk about. Dynamic NAT, just like Static
NAT, is not that common in smaller networks but you'll find it used within larger corporations
with complex networks.
The way Dynamic NAT differentiates from Static NAT is that where Static NAT provides a oneto-one internal to public static IP mapping, Dynamic NAT does the same but without making the
mapping to the public IP static and usually uses a group of available public IPs.
Confused ? Don't worry, I would be too :) Let's explain it better...
What exactly does Dynamic NAT do ?
While looking at Static NAT, we understood that for every private IP Address that needs access
to the Internet we would require one static public IP Address. This public IP Address is mapped
to our internal host's IP Address and it is then able to communicate with the rest of the world.
With Dynamic NAT, we also map our internal IP Addresses to real public IP Addresses, but the
mapping is not static, meaning that for each session our internal hosts communicate with the
Internet, their public IP Addresses remain the same, but are likely to change. These IPs are taken
from a pool of public IP Addresses that have been reserved by our ISP for our public network.
With Dynamic NAT, translations don't exist in the NAT table until the router receives traffic that
requires translation. Dynamic translations have a timeout period after which they are purged from
the translation table, thus making them available for other internal hosts.
The diagram below illustrates the way Dynamic NAT works:
The diagram above is our example network and shows our router, which is configured to perform
Dynamic NAT for the network. We requested 4 public IPs from our ISP (203.31.218.210 to
203.31.218.213), which will be dynamically mapped by our router to our internal hosts. In this
particular session our workstation, with IP Address 192.168.0.1, sends a request to the Internet
and is assigned the public IP address 203.31.218.210. This mapping between the workstation's
private and public IP Address will remain until the session finishes.
The router is configured with a special NAT timeout and, after this timeout is reached (no traffic
sent/received during that time), the router will expire the particular mapping and reuse it for a
different internal host.
Let's say that around noon, the users of workstations with IP Address 192.168.0.1 and
192.168.0.3 go to lunch, so they log off and leave their PCs on (even if they switched them off, it
wouldn't make a difference unless they had some program running that was constantly generating
Internet traffic because the NAT timeout would never be reached). While these users went out for
lunch, the user on the workstation with IP Address 192.168.0.2 decided to stay and do some extra
work on the Internet. After 1 hour, the users return and log back on, launch their web browser and
start to search on the net.
The router, as expected, deleted the old mappings once the NAT timeout had been reached for
each mapping and created new ones once the users launched their web browsers, because that
action generated traffic to the Internet and therefore had to transit the router.
Here's how the new mappings look:
By now, I would like to believe that you have understood what Dynamic NAT is all about and
roughly how it works.
But where would Dynamic NAT be used?
Again, everyone's network needs are different, though I must admit that finding a practical
implementation for Dynamic NAT is perhaps more difficult than any other NAT mode :)
Come to think of it, I can't recall ever being required to implement Dynamic NAT for a customer
or my own network, but that doesn't mean it's not used. There are some network setups in which
Dynamic NAT would work perfectly and that's what i'm about to show you.
Implementation of Dynamic NAT
This example is about a company called 'Dynasoft'. Dynasoft deals with the development of high
quality software applications. As a large software firm, it has multiple contractors that help
complete special sections of the software it sells.
Because of the nature of this production model, Dynasoft requires its contractors to have a
permanent link into its private development network, so the source code of all ongoing projects is
available to all contractors:
Now because Dynasoft is concerned about its network security, it purchased a firewall that was
configured to regulate each contractor's access within the development network.
For the rest of this example, we will concentrate on Dynasoft's and Datapro's (green) networks:
Dynasoft has configured its firewall only to allow a particular part of Datapro's internal network
to access the servers and that is network 192.168.50.0/24, which is Datapro's main development
network.
This setup has been working fine, but Datapro is expanding its development network, so a second
separate network (192.168.100.0/24) was created that also needs access to Dynasoft's
development network. All hosts on this new network will be using the new DHCP server, which
means that they'll have a dynamic IP Address.
In order for the new network to access Dynasoft's network, we need to somehow trick Dynasoft's
Firewall into thinking that any workstation from the new network is actually part of the
192.168.50.0 network, that way it won't be denied access.
There was a suggestion to use Static NAT but there are a few problems:
a) All workstations are on DHCP, so Static NAT will not work properly since it requires the
internal hosts in the new network to have static IP Addresses.
b) Datapro's administrator wants maximum security for this new network therefore having
dynamic IPs makes it more difficult for someone to track a particular host from it by using its IP
Address.
So, after taking all this into consideration it was decided to implement Dynamic NAT and here's
what the solution looks like:
A Dynamic NAT router in this situation would do the job just fine. We would place the router
between the existing (192.168.50.0) and new (192.168.100.0) network. Because of the way
Dynamic NAT works, we would need to reserve a few IP Addresses from the 192.168.50.0
network in order to allow the Dynamic NAT router to use them for mapping hosts on the new
network - to the existing network. This way, no matter which IP Address any host in the new
network has, Dynasoft's Firewall device will think it's part of the 192.168.50.0 network !
I should also point out that the number of IP Addresses we'd need to reserve from network
192.168.50.0 would depend on how many simultaneous connections we want to allow from
network 192.168.100.0 to Dynasoft's development network.
For example, if we required 25 workstations from network 192.168.100.0 to have simultaneous
connection to Dynasoft we'd need to reserve at least 25 IP Addresses from the 192.168.50.0
network.
As previously explained, the reserved IP Addresses will be used to map hosts coming from the
192.168.100.0 network and must not be used by any host or workstation within the 192.168.50.0
network. If any were used in this way it would cause IP conflicts between the host in the
192.168.50.0 network and the Dynamic NAT router that's mapping that particular IP Address to
the host from the 192.168.100.0 network.
So a good practice would be to set aside the last 30 IP Addresses from the 192.168.50.0 network,
which would be 192.168.50.224 to 192.168.50.254, and ensure no one is assigned any IP Address
within that range.
All this assumes networks 192.168.50.0 and 192.168.100.0 are using a Class C default
subnetmask (255.255.255.0).
On this page, you need to understand why we're going to introduce the Dynamic NAT router,
how it will solve the problem (by mapping hosts on the new network to the existing one) and the
requirements for the implementation of this solution (to reserve the required IP addreess from the
existing network).
The next page deals with the analysis of the packets that will traverse the Dynamic NAT router. It
will help you understand the changes in the packet and complete your understanding of Dynamic
NAT.
Dynamic Network Address Translation (Part 2)
Introduction
Now that you understand the basic idea of Dynamic Network Address Translation we're going to
take a closer look at the packets as they traverse the Dynamic NAT enabled device, which can be
a router, a firewall appliance or even a PC running special software !
Don't be too troubled about what's to follow, it's really simple and neat to know, so let's get right
into it !
How NAT translations take place
Most of the rules that apply for Static NAT (which we've already covered), also apply for
Dynamic NAT and there are very few changes between the two, making it very easy to
understand and digest :)
The actual process remains the same no matter which device we use, e.g Firewall appliance,
Linux gateway, router etc.
Because we don't want to get confused by using a different example, we'll stick to the previous
page's network between Dynasoft and its contractor - Datapro, but we're now focusing on
Datapro's internal network to learn how the router between its two internal networks
(192.168.50.0 and 192.168.100.0) will deal with the Dynamic NAT required in order for the new
network to gain access to Dynasoft's development network:
Even though the diagram explains everything, I'm just going to point out a few important things
about the Dynamic NAT router. It's very important that you understand that the IP Addresses in
the router's Pool are reserved addresses from the 192.168.50.0 network - this means that no
device or host on that network, apart from the router itself, is allowed to use them.
The dynamic mapping that is created will be in place only for that particular session, meaning
that once the workstation in the new network finishes its work on the Dynasoft network, or
doesn't send any packets across the Dynamic NAT router within a given time period, then the
router will clear the dynamic mapping and make the IP Address available to the next host or
workstation that needs it.
The timeout period is different for each transport protocol (TCP/UDP) and NAT device. The
ability to modify these timeouts depends entirely on the NAT device being used. As always, the
RFCs give some guidelines for these values but not all vendors follow them :) You will find more
interesting information about this subject in the NAT advanced section.
So, after getting all that out of the way, it's now time to have a closer look at the packets as they
traverse the router to either network:
After it is determined that this packet must traverse the router, an IP Address is picked from the
available pool that will be used to map IP Address 192.168.100.5. These entries are then stored
within the router's RAM (NAT Table). As you can see, the Source, Destination ports and
Destination IP are never modified on outgoing packets.
The router will then send the packet on to the 192.168.50.0 network and after a few milliseconds
it receives the reply that our workstation on network 192.168.100.0 is waiting for:
The router finds an entry within its NAT mapping table (don't forget this table is stored in the
router's RAM) and replaces destination IP 192.168.50.200 with destination IP 192.168.100.5 and
then forwards the packet to the new network. The Source, Destination ports and Source IP are not
modified.
In case you're wondering why the ports have changed in comparison to the original outgoing
packet, this is not because of NAT but the way IP communications work and happens to be way
out of the scope of this page.
One important small detail I should bring to your attention is how the packet reply managed to
arrive at the router's interface, which is on the existing network. You should know that to the
existing Datapro network, the router is like a host with multiple IP Addresses.
I explained how the router maps IP Addresses on the existing network to the new network, but if
someone on the existing network tried to send an ARP request for 192.168.50.200, then the router
would immediately answer with its own MAC address. This is done to ensure that all traffic
intended for workstations on the new network finds its way there. The same principle would
apply no matter which NAT mode we used.
To sum up all the above while trying to keep things simple, because sometimes no matter how
much you analyse a diagram it can still confuse you, the next diagram is a summary of how the
packets are modified as they traverse a Dynamic NAT device which, in our example, is a router:
It's very easy to see that the Source IP Address (192.168.100.5) is changed as the packet traverses
the Dynamic NAT router to arrive at Datapro's exist network and then move on to Dynasoft's
network, whereas the reply from Dynasoft's network will enter Datapro's existing network and
traverse the Dynamic NAT router and have its Destination IP Address modified to 192.168.100.5,
thus reaching the workstation its intended to.
Believe it or not, we've come to the end of this page, next page talks about NAT Overload, which
is also known as Network Address Port Translation, Port Address Translation or IP Masquerade
in the Linux/Unix world.
Network Address Translation Overload (Part 1)
Introduction
NAT Overload is the most common NAT method used throughout all networks that connect to
the Internet. This is because of the way it functions and the limitations it can overcome, and we'll
explore all of these in the next two pages.
Whether you use a router, firewall appliance, Microsoft's Internet sharing ability or any 3rd party
program that enables all your home computers to connect to the Internet via one connection,
you're using NAT Overload.
This NAT mode is also know by other names, like NAPT (Network Address Port Translation), IP
Masquerading and NAT with PAT (Port Address Translation). The different names logically
come from the way NAT Overload works, and you'll understand this by the time we're finished
with the topic.
NOTE: You should be familiar with TCP/IP & UDP communications, as well as how they use
various Ports in order to identify the resources/applications they are trying to use. It's very
important you understand them because NAT Overload is based on these Ports in order to
identify sessions between hosts.
The bad news is that this topic is not covered as yet on the site, but be sure I will be analysing it
soon. Until then, there are plenty of other resources on the Internet to learn about the basics.
What exactly does NAT Overload do ?
NAT Overload is a mix of Static & Dynamic NAT with a few enhancements thrown in (PATPort Address Translation) to make it work the way we need. By now you understand how both
Static & Dynamic NAT work so we won't get into the details again. NAT Overload takes a Static
or Dynamic IP Address that is bound to the public interface of the gateway (this could be a PC,
router or firewall appliance) and allows all PCs within the private network to access the Internet.
If you find yourself wondering how this is possible with one only IP Address, you will be happy
to find that the answer lies within PAT.
The diagram below shows you how a single session is handled by a NAT Overload enabled
device:
So we have a host on a private network, its IP Address is 192.168.0.1 and it's sending a packet to
the Internet, more specifically to IP Address 200.0.0.1, which we're assuming is a server. The
Port, which is 23, tells us that it's trying to telnet to 200.0.0.1, since this is the default port telnet
uses.
As the original packet passes through the router, the Source IP Address field is changed by the
router from 192.168.0.1 to 203.31.218.100. However, notice that the ports are not changed.
The reason the Source IP Address is changed is obvious: The router's public IP Address must be
placed in the Source IP Address field of the packet so the server we're trying to telnet to knows
where the request is coming from so it can then send the reply.
That takes care of making sure the packet from the server we're telneting to finds its way back to
the router's public interface. From there, the router needs to know which host on the private
network it must send the reply to. For this, it uses the ports and we will be looking at that closer
very soon.
Some might think that this example is pretty much the way a Static NAT router would behave,
and if you're thinking just that you're totally right! In order to understand how a NAT Overload
enabled router is different from Static NAT, we must add at least one more host in the private
network, which we'll do right now.
With two or more hosts on the private network, in Static NAT mode we would require the
equivalent number of public IP Addresses, right ? One for each private host, because Static NAT
maps one public IP Address to each private host.
NAT Overload overcomes this limitation by using one public IP Address for all private hosts, but
utilising the thousands of ports available in order to identify each private host's session.
Unleashing the true Power of NAT Overload
To help cover all possibilities and questions that might come up from these examples, we're going
to add another two private hosts in our internal network. We'll assume that:
1) The 2nd host in our private network is trying to telnet to the same server as the 1st host
2) The 3rd host in our private network is trying to telnet to a different server on the Internet
So let's see how our example network looks:
Host 1 and 2 are telneting to the same server (203.31.218.100), the only difference between the
two packets is their Source Port Numbers, the router uses these to keep track of which packet
belongs to each host.
Let's examine what happens when Host 1's reply arrives:
A packet arrives on our router's public interface and is accepted. The packet's details are
examined and show that it came from IP Address 200.0.0.1 Port 23 with a destination of
203.31.218.100 Port 3000. The router remembers that Host 1 and 2 just sent a packet to this IP
Address and now, in order to determine to whom this response belongs, it carefully examines its
Destination Port.
It focuses on the Destination Port because in any reply, the Destination Port takes the value of the
initial packet's Source Port. This means that this packet is a reply to one sent previously to IP
Address 200.0.0.1 with Source Port 3000. The router refers to its NAT table and finds a matching
entry for the described initial packet. It recognises that the reply is intended for Host 1 and will
forward it to the host.
The server to which Host 1 and 2 of our example private network are telneting uses the same
logic to distinguish between the two separate sessions.
Because this can also be a bit difficult to imagine, I've included a diagram which shows the server
receiving Host 1's initial packet and then sending a reply:
The example on this page is intended to show you the idea behind NAT Overload and how it
works. We saw our little NAT Overload enabled router doing wonders with one single public IP
Address. If we wanted to use Static or Dynamic NAT in this same example, we would definitely
require 3 public IP Addresses for our 3 private hosts but thanks to NAT Overload, we only need
one IP Address.
The next page will deal with a more detailed analysis of the packets as they traverse the router
and take a look at a few more interesting parts of NAT Overload.
Network Address Translation Overload (Part 2)
Introduction
This page deals with the analysis of the packets that traverse a NAT Overload enabled device.
We'll examine which fields of the packets are modified and how the NAT device, a router in our
example, keeps track of them in its NAT Table.
In order to keep things simple, we're going to use a few simple examples and then deal with a few
more complicated ones, this should help make the complex stuff much easier to understand and
digest.
Time to grab something to drink or munch on, and prepare to download this information into your
head!
- Oh, and don't worry, this information has been virus checked :)
How NAT translations take place
When covering Dynamic and Static NAT, we saw that it was either the Source or Destination IP
Address that had to be modified by the NAT device. No matter which mode was used, the Source
and Destination ports were never altered in any way.
NAT Overload on the other hand will use a single public IP Address for the routing process and
change, in most cases, the Source or Destination port depending on whether it's an incoming or
outgoing packet.
In the next diagram we have two computers that have each sent a packet out to the Internet and
are expecting a reply. We take a look at how the router deals with these packets individually and
where the information required to identify the expected replies is stored:
You've got to agree that that's a very simple setup. To make life easy, I haven't included any
additional information about the generated packets because we'll deal with them individually.
So it's time to take a look at how the router deals with this first packet which belongs to
Workstation 1:
The packet Workstation 1 generated arrives at the router's private interface which has IP Address
192.168.0.1. The router accepts the packet and processes it. Once inside the router, the packet's
Source IP Address, Destination IP Address, Source Port and Destination Port are examined and
the router decides that this is a valid packet so it should be forwarded to the Internet.
NAT is now about to take place (check NAT Table in the above diagram). The router will replace
the Source IP Address (192.168.0.5) with its Public IP Address (200.0.0.1) and keep the rest of
the information intact.
Note that in most cases, the Source Port is not changed unless it has already been used by a
previous packet from the private network but, since this is the first outgoing packet, this cannot be
the case.
Here's how the packet looked once it exited the router's public interface:
Time to check our second packet that will traverse the router, which is generated by Workstation
2 (the router has not yet received the reply to Workstation 1's packet).
We're going to assume that Workstation 2 uses the same Source Port (2400) as Workstation 1's
packet, so you can see how the router will react:
This packet is a very good example to show you how great NAT Overload is because the router
will need to 'do' something to make sure it's able to successfully receive the reply.
Let's look at what happens within the router as the packet arrives at its private interface:
As you can see, our second packet arrives at the router's private interface. It enters the router and
since the packet is valid (it's not corrupt and contains a valid Destination IP Address in its IP
Header) it's routed to the public interface and NAT is performed while a new entry is added into
the router's NAT Table.
Looking at the NAT entries, you will notice that both first and second packets have the same
Source Port, which is 2400. Since the router already used port 2400 as a Source Port for the first
packet's NAT Translation and hasn't yet received a reply, it cannot use it again for the second
packet. If it did use it, when a reply for any of the two packets came back the router wouldn't be
able to distinguish whose it was.
For this reason, the router assigns a new Source Port for the second packet (14500), ensuring that
the reply will get to the internal host for which it is intended:
Usually most NAT Overload enabled devices will assign Source Ports in the range of 1025 to
65500.
Keep in mind that when one host sends a packet to another, the Source Port it used in the packet
will be substituted for the Destination Port in the reply packet.
For example, Host A sends a packet to Host B and this packet has a Source Port of 200, then
when Host B replies to Host A its packet will have a Destination Port of 200. This way, Host A
knows this is a reply to the initial packet it sent.
This is why it's important for the router to keep close track of Source Ports on outgoing packets
and Destination Ports in all incoming packets.
Last Notes
NAT Overload will work perfectly no matter which type of IP Address assignment you have.
Whether it's Dynamic IP or Static, via dial up or a permanent connection, it makes no difference
to the NAT device. You can now see how this particular NAT mode has helped preserve real
(public) IP Addresses, because no matter how many internal hosts any private network has, it
only requires one real IP Address in order to allow all internal hosts to access the Internet.
Now you have a good idea why NAT is so much a favourite subject of mine, simply cause it's
made such a big difference in every network that connects to the Internet.
The next page dives a bit deeper into the NAT function and discusses subjects such as its
performance depending on the transport protocol used, implemented timeouts for TCP and UDP
connections and the effect they have, exact NAT translation procedures depending on the packet's
origin and a lot more.
If you feel your head can take a bit more bashing, then give it a go, otherwise leave it for another
day, as it will still be here waiting for you next time :)
Virtual Local Area Networks (VLANs) - Introduction
Introduction
Virtual Local Area Networks or VLANs are one of the latest and coolest network technologies
developed in the past few years, though have only recently started to gain recognition. The nonstop growth of Local Area Networks (LANs) and the need to minimize the cost for this expensive
equipment, without sacrificing network performance and security, created the necessary soil for
the VLAN seed to surface and grow into most modern networks.
The truth is that VLANs are not as simple as most people peceive it to be. Instead they cover
extensive material to be a whole study in itself as they contain a mixture of protocols, rules, and
guidelines that a network administrator should be well aware of. Unfortunately, most
documentation provided by vendors and other sites is inadequate or very shallow. They lightly
touch upon the VLAN topic and fail to give the reader a good understanding on how VLANs
really work and the wonderful things one can do when implementing them.
Like most topics covered on our site, VLANs have been broken down into a number of pages,
each one focusing on specific areas to help the reader build up their knowledge as preparation for
designing and building their own VLAN network.
Since VLANs is a topic that requires strong background knowledge of certain areas, as they
contain a lot of information at the techincal and protocol level, we believe that the reader should
be familiar and comfortable with the following concepts:




Switches and hubs
Broadcast and collision domains
Internet Protocol (IP)
IP routing
As we cover all the theory behind VLANs and how they are implemented within various network
topologies, we will finally demonstrate the configuration of a Cisco powered network utilising
VLANs!
Protocols such as Spanning Tree Protocol (STP) are essential when implementing VLANs within
a mid to large sized network, so we will briefly touch upon the topic, without thoroughly
analysing it in great detail because STP will be covered as a separate topic.
So What's Covered ?
Before we begin our journey into the VLAN world, let's take a look at what we will be covering:
Section 1: The VLAN Concept. This page explains what a VLAN is and how it differs from a
normal switched environment. Be sure to find our well known diagrams along with illustrations
to help cover your questions. In short, its a great introductory page for the topic.
Section 2: Designing VLANs.
Section 2.1: Designing VLANs - [Subsection 1] A Comparison With Old Networks. This
subsection will give you an insight to the different VLAN implemenations: Static and Dynamic
VLANs. The subsection begins with an introduction page to help you 'see' the actual difference in
the network infrastructure between the old boring networks and VLAN powered networks. This
way, you will be able to appreciate the technology much better!
Section 2.2: Designing VLANs - [Subsection 2]: Static VLANs. Definately the most wide spread
VLAN implementation. The popular Static VLANs are analysed here. We won't be covering any
configuration commands here as this page serves as an introduction to this VLAN
implementation. As always, cool 3D diagrams and examples are included to help you understand
and process the information.
Section 2.3: Designing VLANs - [Subsection 3]: Dynamic VLANs. Dynamic VLANs are less
common to most networks but offer substantial advantages over Static VLANs for certain
requirements. Again, this page serves as an introduction to the specific VLAN implementation.
Section 3: VLAN Links: Access Links & Trunk Links. Access links are used to connect hosts,
while Trunk links connect to the network backbone. Learn how Access & Trunk links operate,
the logic which dictates the type of link and interface used and much more.
Section 4: VLAN Tagging - ISL, 802.1q, LANE and IEEE 802.10. To tag or not to tag!
Understand the VLAN tagging process and find out the different tagging methods available,
which are the most popular and how they diffirentiate from each other. Neat diagrams and
examples are included to ensure no questions are left unanswered!
Section 5: Analysing Popular Tagging Protocols.
Section 5.1: InterSwitch Link Analysis (ISL): Analysis of Cisco's proprietry ISL protocol. We
take a look at how it is implemented and all available fields it contains.
Section 5.2: IEEE 802.1q Analysis: IEEE's 802.1q protocol is the most widely spead trunking
protocol. Again, we take a look at its implementation with an analysis of all its fields.
Section 6: InterVLAN Routing. A very popular topic, routing between VLANs is very important
as it allows VLANs to communicate. We'll examine all possible InterVLAN routing methods and
analyse each one's advantages and disadvantages. Needless to say, our cool diagrams also make
their appearance here!
Section 7: Virtual Trunk Protocol (VTP)
Section 7.1: Introduction To The VTP Protocol. The introductory page deals with understanding
the VTP concept. Why it's required and what are its advantages.
Section 7.2: In-Depth Analysis Of VTP. Diving deeper, this page will analyse the VTP protocol
structure. It includes 3d diagrams explaining each VTP message usage and much more.
Section 7.3: Virtual Trunk Protocol Prunning ( VTP Pruning). VTP Prunning is an essential
service in any large network to avoid broadcast flooding over trunk links. This page will explain
what VTP Prunning does and how it works by reading through our excellent examples. The
diagrams used here have been given extra special attention!
The following sections are yet to be complete as we are still working on them. There will be an
announcement once they are ready for you to read!
Section 8: Special VLAN requirements - Voice over IP (VoIP), Quality Of Service (QOS) &
Spanning Tree Protocol (STP).
Section 9: Troubleshooting VLANs in a Cisco powered network.
Section 10: VLAN Redundancy using redundant links and STP.
Section 11: Building your own VLAN Network.
Section 11.1: Configuring VLANs and Trunks (ISL & 802.1q).
Section 11.2: Configuring InterVLAN Routing.
Section 11.3: Configuring VTP Server, Client, Transparent.
Section 11.4: Configuring VTP Pruning.
Section 11.5: Migrating to a Cisco VLAN oriented network.
Virtual Local Area Networks (VLANs) - The Concept
Introduction
We hear about them everywhere, vendors around the world are constantly trying to push them
into every type of network and as a result, the Local Area Network (LAN) we once knew starts to
take a different shape. And yet, for some of us, the concept of what VLANs are and how they
work might still be a bit blurry.
To help start clearing things up we will define the VLAN concept not only through words, but
through the use of our cool diagrams and at the same time, compare VLANs to our standard flat
switched network.
We will start by taking a quick look at a normal switched network, pointing out it's main
characteristics and then move on to VLANs. So, without any delay, let's get right into this cool
stuff!
The Traditional Switched Network
Almost every network today has a switch interconnecting all network nodes, providing a fast and
reliable way for the nodes to communicate. Switches today are what hubs were a while back - the
most common and necessary equipment in our network, and there is certainly no doubt about that.
While switches might be adequate for most type of networks, they prove inadequate for mid to
large sized networks where things are not as simple as plugging a switch into the power outlet
and hanging a few Pc's from it!
For those of you who have already read our "switches and bridges" section, you will be well
aware that switches are layer 2 devices which create a flat network:
The above network diagram illustrates a switch with 3 workstations connected. These
workstations are able to communicate with each other and are part of the same broadcast domain,
meaning that if one workstation were to send a broadcast, the rest will receive it.
In a small network multiple broadcast might not be too much of a problem, but as the size of the
network increases, so will the broadcasts, up to the point where they start to become a big
problem, flooding the network with garbage (most of the times!) and consuming valuable
bandwidth.
To visually understand the problem, but also the idea of a large flat network, observe the diagram
below:
The problem here starts to become evident as we populate the network with more switches and
workstations. Since most workstations tend to be loaded with the Windows operating system, this
will result in unavoidable broadcasts being sent occasionaly on the network wire - something we
certainly want to avoid.
Another major concern is security. In the above network, all users are able to see all devices. In a
much larger network containing critical file servers, databases and other confidential information,
this would mean that everyone would have network access to these servers and naturally, they
would be more susceptible to an attack.
To effectively protect such systems from your network you would need to restrict access at the
network level by segmenting the exisiting network or simply placing a firewall in front of each
critical system, but the cost and complexity will surely make most administrators think twice
about it. Thankfully there is a solution ..... simply keep reading.
Introducing VLANs
Welcome to the wonderful world of VLANs!
All the above problems, and a lot more, can be forgotten with the creation of VLANs...well, to
some extent at least.
As most of you are already aware, in order to create (and work with) VLANs, you need a layer 2
switch that supports them. A lot of people new to the networking field bring the misconception
that it's a matter of simply installing additional software on the clients or switch, in order to
"enable" VLANs throughout the network - this is totally incorrect!
Because VLANs involve millions of mathematical calculations, they require special hardware
which is built into the switch and your switch must therefore support VLANs at the time of
purchase, otherwise you will not be able to create VLANs on it!
Each VLAN created on a switch is a separate network. This means that a separate broadcast
domain is created for each VLAN that exists. Network broadcasts, by default, are filtered from all
ports on a switch that are not members of the same VLAN and this is why VLANs are very
common in today's large network as they help isolate network segments between each other.
To help create the visual picture on how VLANs differentiate from switches, consider the
following diagram:
What we have here is a small network with 6 workstations attached to a VLAN capable switch.
The switch has been programmed with 2 VLANs, VLAN1 and VLAN2 respectfully, and 3
workstations have been assigned to each VLAN.
VLANs = Separate Broadcast Domains
With the creation of our VLANs, we have also created 2 broadcast domains. This mean that if
any workstation in either VLAN sends a broadcast, it will propagate out the ports which belong to
the same VLAN as the workstation that generated the broadcast:
This is clearly illustrated in the diagram above where Workstation 1, belonging to VLAN1, sends
a network broadcast (FF:FF:FF:FF:FF:FF). The switch receives this broadcast and forwards it to
Workstation 2 and 3, just as it would happen if these three workstations were connected to a
normal switch, while the workstations belonging to VLAN2 are totally unaware of the broadcast
sent in VLAN1 as they do not receive any packets flowing in that network.
To help clear any questions or doubts on how the above setup works, the diagram below shows
the logical equivalent setup of our example network:
By this stage, you should begin seeing the clear advantages offered by the use of VLANs within
your network. Security, cost and network traffic are reduced as more hosts are added to the
network and the number of VLANs are increased.
VLANs Help Reduce The Cost
To briefly touch upon the financial side of things, let's take an example to see exactly how we are
saving money by using VLANs.
Consider you're the network administrator for a large company and you have been asked to split
the existing network infrastructure into 12 seperate networks, but without the possibility of these
new networks to communicate between each other. Since the cabling is already in place, we need
to simply group the ports of each network we create to one physical switch and for the 12
network, a total of 12 switches will be required.
By using VLANs, the above task would be possible with one or more VLAN capable switches
that will cover the number of hosts we need to connect to them, and the cost would surely be a lot
less than that compared to 12 switches.
During the implementation of the above task, you would connect all workstations to the switch
and then assign the appropriate workstations/nodes to their respectful VLAN, creating a total of
12 VLANs. It is worth noting here that most entry level VLAN switches e.g Cisco 2900 series,
are capable of handling up to 64 VLANs, so if we were to use these switches, we would still have
plently of room to create more.
Switch Model
Maximum VLANs Supported
VLAN Trunking Supported
Catalyst 2912 XL, Catalyst 2924 XL &
Catalyst 2924C XL
64
yes
Catalyst 2900 LRE XL
250
yes
Catalyst 2912M and Catalyst 2924M modular
250
yes
Catalyst 3500 XL & 3550
250
yes
There are a lot more examples one can use to show how these new generation switches are able to
solve complex network designs, security issues and at the same time, keep the budget low. Lastly,
the best example is one that is able to solve your own requirements, so take a minute to think
about it and you will surely agree.
Summary
This page introduced the concept of VLANs and indicated the differences existing between them
and normal switched networks. We also briefly examined their efficiency in terms of cost,
security and implementation.
The information here serves as an introduction to the VLAN technology and we will now start
diving deeper into the topic, analysing it in greater detail. Having said that, our next page deals
with the design of VLANs, showing different logical and physical configurations of VLANs
within networks. So, make yourself comfortable and let's continue cause there is still so much to
cover!
Designing VLANs - A Comparison With Old Networks
Introduction
Designing and building a network is not a simple job. VLANs are no exception to this rule, in fact
they require a more sophisticated approach because of the variety of protocols used to maintain
and administer them.
Our aim here is not to tell you how to setup your VLANs and what you should or shouldn't do,
this will be covered later on. For now, we would like to show you different physical VLAN
layouts to help you recognise the benefits offered when introducing this technology into your
network, regardless of its size.
The technology is available and we simply need to figure out how to use it and implement it using
the best possible methods, in order to achieve outstanding performance and reliability.
We understand that every network is unique as far as its resources and requirements are
concerned, which is another reason why we will take a look at a few different VLAN
implementations. However, we will not mention the method used to set them up - this is up to you
to decide once you've read the following pages!
Designing your first VLAN
Most common VLAN setups involve grouping departments together regardless of their physical
placement through the network. This allows us to centralise the administration for these
departments, while also limiting unwanted incidents of unauthorised access to resources of high
importance.
As always, we will be using neat examples and diagrams to help you get a visual on what we are
talking about.
Let's consider the following company: Packet Industries
Packet Industries is a large scale company with over 40 workstations and 5 servers. The company
deals with packet analysis and data recovery and has labs to recover data from different media
that require special treatment due to their sensitivity. As with every other company, there are
quite a few different departments that deal with different aspects of the business and these are:



Management/HR Department
Accounting Department
Data Recovery & IT Department
These five departments are spread throughout 3 floors in the building the company is situated.
Because the IT department takes confidentiality of their own and customer's data seriously, they
have decided to redesign their network and also take a look at the VLAN solutions available, to
see if they are worth the investment.
We are going to provide two different scenarios here, the first one will not include VLANs, while
the second one will. Comparing the two different solutions will help you see the clear advantages
of VLANs and also provide an insight to how you can also apply this wonderful technology with
other similar networks you might be working with.
Solution 1 - Without VLANs!
The IT department decided that the best way to deal with the security issue would be to divide the
existing network by partitioning it. Each department would reside in one broadcast domain and
access lists would be placed between each network's boundaries to ensure access to and from
them are limited according to the access policies.
Since there are three departments, it is important that three new networks had to be created to
accommodate their new design. The budget, as in most cases, had to be controlled so it didn't
exceed the amount granted by the Accounting Department.
With all the above in mind, here's the proposal the IT department created:
As you can see, each department has been assigned a specific network. Each level has a dedicated
switch for every network available. As a result, this will increase the network security since we
have separate physical networks and this solution also seems to be the most logical one. These
switches are then grouped together via the network backbone which, in its turn, connects to the
network's main router.
The router here undertakes the complex role of controlling access and routing between the
networks and servers with the use of access lists as they have been created by the IT Department.
If needed, the router can also be configured to allow certain IP's to be routed between the three
networks, should there be such a requirement.
The above implementation is quite secure as there are physical and logical restrictions placed at
every level. However, it is somewhat restrictive as far as expanding and administering the
network since there is no point of central control. Lastly, if you even consider adding full
redundancy to the above, essentially doubling the amount of equipment required, the cost would
clearly be unreasonable...
So let's now take a look at the second way we could implement the above, without blowing the
budget, without compromising our required security level and also at the same time create a
flexible and easily expandable network backbone.
Solution 2 - With VLANs!
The solution we are about to present here is surely the most preferred and economical. The
reasons should be fairly straight forward: We get the same result as the previous solution, at
almost half the cost and as a bonus, we get the flexibility and expandability we need for the future
growth of our network, which was very limited in our previous example.
By putting the VLAN concept we covered on the previous page into action, you should be able to
visualise the new setup:
As you can see, the results in this example are a lot neater and the most apparent change would be
the presence of a single switch per level, connecting directly to the network backbone. These
switches of course are VLAN capable, and have been configured to support the three separate
logical and physical networks. The router from the previous solution has been replaced by what
we call a 'layer 3 switch'.
These type of switches are very intelligent and understand layer 3 (IP Layer) traffic. With such a
switch, you are able to apply access-lists to restrict access between the networks, just like you
normally would on a router, but more importantly, route packets from one logical network to
another! In simple terms, layer 3 switches are a combination of a powerful switch, with a built-in
router :)
Summary
If the above example was interesting and provided a insight into the field of VLANs, we can
assure you - you haven't seen anything yet. When unleashing the power of VLANs, there are
amazing solutions given for any problem or need that your network requires.
It's now time to start looking at the VLAN technology in a bit more detail, that is, how it's
configured, the postive and negative areas for each type of VLAN configuration and more much.
The next page analyses Static VLANs which are perhaps the most popular implementation of
VLANs around the world. Take a quick break for some fresh air if needed, otherwise, gear up and
let's move!
Designing VLANs - Static VLANs
Introduction
VLANs are usually created by the network administrator, assigning each port of every switch to a
VLAN. Depending on the network infrastructure and security policies, the assignment of VLANs
can be implemented using two different methods: Static or Dynamic memberships - these two
methods are also known as VLAN memberships.
Each of these methods have their advantages and disadvantages and we will be analysing them in
great depth to help you decide which would best suite your network.
Depending on the method used to assign the VLAN membership, the switch may require further
configuration, but in most cases it's a pretty straight forward process. This page deals with Static
VLANs while Dynamic VLANs are covered next.
Static VLANs
Static VLAN membership is perhaps the most widely used method because of the relatively small
administration overhead and security it provides. With Static VLANs, the administrator will
assign each port of the switch to one VLAN. Once this is complete, they can simply connect each
device or workstation to the appropriate port.
The picture below depicts an illustration of the above, where 4 ports have been configured for 4
different VLANs:
The picture shows a Cisco switch (well, half of it :>) where ports 1, 2, 7 and 10 have been
configured and assigned to VLANs 1, 5, 2 and 3 respectively.
At this point, we should remind you that these 4 VLANs are not able to communicate between
each other without the use of a router as they are treated as 4 separate physical networks,
regardless of the network addressing scheme used on each of them. However, we won't provide
further detail on VLAN routing since it's covered later on.
Static VLANs are certainly more secure than traditional switches while also considerably easy to
configure and monitor. As one would expect, all nodes belonging to a VLAN must also be part of
the same logical network in order to communicate with one another. For example, on our switch
above, if we assigned network 192.168.1.0/24 to VLAN 1, then all nodes connecting to ports
assigned to VLAN 1 must use the same network address for them to communicate between each
other, just as if this was an ordinary switch.
In addition, Static VLANs have another strong point - you are able to control where your users
move within a large network. By assigning specific ports on your switches throughout your
network, you are able to control access and limit the network resources to which your users are
able to use.
A good example would be a large network with multiple departments where any network
administrator would want to control where the users can physically connect their workstation or
laptop and which servers they are able to access.
The following diagram shows a VLAN powered network where the switches have been
configured with Static VLAN support.
The network diagram might look slightly complicated at first, but if you pay close attention to
each switch, you will notice that it's quite simple - six switches with 6 VLANs configured- one
VLAN per department, as shown. While each VLAN has one logical network assigned to it, the
IT department has, in addition, placed one workstation in the following departments for support
purposes: Management, R&D, and HR department.
The network administrator has assigned Port 1 (P1) on each department switch to VLAN 5 for the
workstation belonging to the IT department, while the rest of the ports are assigned to the
appropriate VLAN as shown in the diagram.
This setup allows the administrator to place any employee in the IT department, anywhere on the
network, without worrying if the user will be able to connect and access the IT department's
resources.
In addition, if a user in any of the above departments e.g the Management department, decided to
get smart by attempting to gain access to the IT department's network and resources by plugging
his workstation to Port 1 of his department's switch. He surely wouldn't get far because his
workstation would be configured for the 192.168.1.0 network (VLAN 1), while Port 1 requires
him to use a 192.168.5.0 network address (VLAN 5). Logically, he would have to change his IP
address to match the network he is trying to gain access to, and in this case this would be network
192.168.5.0.
Summary
To sum up, with Static VLANs, we assign each individual switch port to a VLAN. The network
addresses are totally up to us to decide. In our example, the switches do not care what network
address is used for each VLAN as they totally ignore this information unless routing is performed
(this is covered in the InterVLAN routing page). As far as the switches are concerned, if you have
two ports assigned to the same VLAN, then these two ports are able to communicate between
each other as it would happen on any normal layer 2 switch.
Designing VLANs - Dynamic VLANs
Introduction
Dynamic VLANs were introduced to grant the flexibility and complexity(!) that Static VLANs
did not provide. Dynamic VLANs are quite rare because of their requirements and initial
administrative overhead. As such, most administrators and network engineers tend to prefer Static
VLANs.
Dynamic VLANs
Dynamic VLANs, as opposed to Static VLANs, do not require the administrator to individually
configure each port, but instead, a central server called the VMPS (VLAN Member Policy
Server). The VMPS is used to handle the on-the-spot port configuration of every switch
participating on the VLAN network.
The VMPS server contains a database of all workstation MAC addresses, along with the
associated VLAN the MAC address belongs to. This way, we essentially have a VLAN-to-MAC
address mapping:
The above diagram works as an aim to help us understand the mapping relationship that exists in
the VMPS server. As shown, each MAC address, which translates to a host on the network, is
mapped to a VLAN, allowing this host to move inside the network, connecting to any switch that
is part of the VMPS network and maintain its VLAN configuration.
You can now start to imagine the initial workload involved when configuring a VMPS server for
a network of over 300 workstations:)
As one would expect, the above model works very well and also requires the switches to be in
constant contact with the VMPS server, requesting configuration information everytime a host
connects to a switch participating in the VLAN network. Of course, there is a lot more
information we can use to configure the VMPS database, but we won't be covering that just as
yet.
Like all network services offered, Cisco has cleverly designed this model to be as flexible as our
network might require. For example, you are able to connect more than one host on one
dynamically configured port, as long as all hosts are part of the same VLAN:
The diagram on the left shows us a VLAN capable switch that has been configured to support
Dynamic VLANs. On port No.5, we have connected a simple switch (not VLAN aware) from
which another 4 workstations are connected.
As mentioned previously, this type of configuration is valid and therefore supported, but it also
has its restrictions and limitations.
One of the restrictions, which by the way can also be considered as a semi-security feature, is that
all workstations connected to the same port, must be configured in the VMPS server as part of the
same VLAN, otherwise the port is
most likely to shut down as a security precaution.
To consider the limitations of this configuration: if the switch detects more than 20 active hosts
(20 MAC addresses) on the port, it will once again shut it down, leaving the workstations without
any network connection. When this happens, the port that shuts down will return into an isolated
state, not belonging to any VLAN.
The fact is that Dynamic VLANs are really not suitable for every network, even though they
allow a great deal of flexibility and security. If you consider the advantage one single feature of
Dynamic VLANs can provide you with, then it might be all you need to implement them.
Because each host connected to the switch is checked against the VMPS database for its VLAN
membership before the port is activated and assigned to a VLAN, this gives the network
administrator the ability to ensure no foreign host is able to walk up to a wall socket and simply
plug their workstation to access the network, if his MAC address is not stored in the VMPS
database. For a large scale network, this could be considered an ACE card under your sleeve.
Choosing Correct Switches
One important factor we haven't yet mentioned is that you cannot run the VMPS server on a
Cisco Catalyst 2900 or 3500 series. The Catalyst 4500 and upwards are able to act as a VMPS,
and at the time of writing, this switch has reached its end of retail life. For those who have dealt
with Cisco Catalyst switches in the past, you would know that a Catalyst 4500 is not the type of
switch you would use in a 20 or 50 node network!
The Catalyst 4500, 6500 series, are switches designed for enterprise networks, as such, they are
built to be modular, easily expandable depending on your needs, and lastly, fully redundant
because you can't have your core backbone switch failing when all other switches and network
equipment are directly connected to it.
We've added a few pictures of the Catalyst 6500 series for you to admire :)
You can clearly see the slots available that allow the Catalyst switches to expand and grow with
your network. In the likely event you require more ports as your network expands, you simply
buy a Fastethernet blade (some people call them 'slices') and insert it into an available slot!
Dynamic VLANs & FallBack VLANs
Another very interesting and smart feature Dynamic VLANs support is the fallback VLAN. This
neat feature allows you to automatically configure a port to a VLAN specially created for
workstations whose MAC address is not in the VMPS server. Consider company visitors or
clients who require specific or restricted access to your network, they can freely connect to the
network and have Internet access, alongside with limited rights on public directories.
In the event the fallback VLAN has not been configured and the MAC address connected to the
switch's port is unknown, the VMPS server will send an 'access-denied' response, blocking access
to the network, but the port will remain active. If the VMPS server is running in 'secure-mode', it
will proceed and shutdown the port as an additional security measure.
The above diagram represents a portion of a large scale network using a Cisco 6500 Catalyst as
the core switch. The switch has been configured to support Dynamic VLANs, therefore a VMPS
server has been configured inside the switch, alongside with a DHCP server for each created
VLAN. The administrator has already assigned the 3 workstations MAC addresses to the VLANs
shown and also created the fallback VLAN for any MAC address that does not exist in the
database.
Now consider this interesting scenario: One morning a visitor arrives in the office and requires
Internet connection so he can demonstate a new product to the management. As an administrator,
you've already configured a fallback VLAN with a DHCP server activated for the VLAN,
pushing the necessary settings to the clients so they may obtain Internet access services.
The visitor finds a free RJ-45 socket on the wall, which connects to a Catalyst 3550 switch
nearby, and plugs in his laptop. Before the user is allowed to access the network, the Cisco 3550
switch checks the laptop's MAC address and reads 4B:63:3F:A2:3E:F9. At this point, the port is
blocked, not allowing the laptop computer to send or receive data. The Cisco 3550 switch sends
the MAC address to the 6500 Catalyst switch which is acting as the VMPS server and it checks
for an entry that matches the specified MAC address but is unable to find one.
Naturally, it determines that this a visitor, so it creates an entry for that MAC address to the
fallback VLAN and sends the information back to the Cisco 3550 switch. The switch will then
enable access to the port our visitor is connected to by configuring the port to the fallback VLAN.
If the visitor's computer is configured to obtain an IP Address automatically, it will do so, once
the operating system has booted. When this happens, the visitor's DHCP request will arrive to the
6500 Catalyst switch and its DHCP server will send the requested information, enabling the client
(our visitor) to configure itself with all the parameters required to access the VLAN. This will
also mean our visitor is now able to access the Internet!
Finishing, if the computer is not configured for DHCP, the client must be advised with the correct
network settings or asked to enable automatic IP configuration in their network properties.
Summary
The past pages could be considered as an 'eye-opener' for people who are new to the VLAN
concept, and at the same time a 'quick-overview' for those who are well aware of their existence!
We hope all your questions to this point have been answered, if not, they are most likely too
advanced and will surely be answered in the pages that follow.
As we complete our Dynamic & Static VLAN overview we are ready to dive in deeper. The next
page begins by examining VLAN interfaces and their properties. There's no turning back now so
click on the lower right link to get started!
VLAN Links: Access & Trunk Links
Introduction
By now we should feel comfortable with terms such as 'VLAN', 'Static & Dynamic VLANs', but
this is just the beginning in this complex world. On this page, we will start to slowly expand on
these terms by introducing new ones!
To begin with, we will take a closer look at the port interfaces on these smart switches and then
start moving towards the interfaces connecting to the network backbone where things become
slightly more complicated, though do not be alarmed since our detailed and easy to read diagrams
are here to ensure the learning process is as enjoyable as possible.
VLAN Links - Interfaces
When inside the world of VLANs there are two types of interfaces, or if you like, links. These
links allow us to connect multiple switches together or just simple network devices e.g PC, that
will access the VLAN network. Depending on their configuration, they are called Access Links,
or Trunk Links.
Access Links
Access Links are the most common type of links on any VLAN switch. All network hosts
connect to the switch's Access Links in order to gain access to the local network. These links are
your ordinary ports found on every switch, but configured in a special way, so you are able to
plug a computer into them and access your network.
Here's a picture of a Cisco Catalyst 3550 series switch, with it's Access Links (ports) marked in
the Green circle:
We must note that the 'Access Link' term describes a configured port - this means that the ports
above can be configured as the second type of VLAN links - Trunk Links. What we are showing
here is what's usually configured as an Access Link port in 95% of all switches. Depending on
your needs, you might require to configure the first port (top left corner) as a Trunk Link, in
which case, it is obviously not called a Access Link port anymore, but a Trunk Link!
When configuring ports on a switch to act as Access Links, we usually configure only one VLAN
per port, that is, the VLAN our device will be allowed to access. If you recall the diagram below
which was also present during the introduction of the VLAN concept, you'll see that each PC is
assigned to a specific port:
In this case, each of the 6 ports used have been configured for a specific VLAN. Ports 1, 2 and 3
have been assigned to VLAN 1 while ports 4, 5 and 6 to VLAN 2.
In the above diagram, this translates to allowing only VLAN 1 traffic in and out of ports 1, 2 and
3, while ports 4, 5 and 6 will carry VLAN 2 traffic. As you would remember, these two VLANs
do not exchange any traffic between each other, unless we are using a layer 3 switch (or router)
and we have explicitly configured the switch to route traffic between the two VLANs.
It is equally important to note at this point that any device connected to an Access Link (port) is
totally unaware of the VLAN assigned to the port. The device simply assumes it is part of a single
broadcast domain, just as it happens with any normal switch. During data transfers, any VLAN
information or data from other VLANs is removed so the recipient has no information about
them.
The following diagram illustrates this to help you get the picture:
As shown, all packets arriving, entering or exiting the port are standard Ethernet II type packets
which are understood by the network device connected to the port. There is nothing special about
these packets, other than the fact that they belong only to the VLAN the port is configured for.
If, for example, we configured the port shown above for VLAN 1, then any packets
entering/exiting this port would be for that VLAN only. In addition, if we decided to use a logical
network such as 192.168.0.0 with a default subnet mask of 255.255.255.0 (/24), then all network
devices connecting to ports assigned to VLAN 1 must be configured with the appropriate network
address so they may communicate with all other hosts in the same VLAN.
Trunk Links
What we've seen so far is a switch port configured to carry only one VLAN, that is, an Access
Link port. There is, however, one more type of port configuration which we mentioned in the
introductory section on this page - the Trunk Link.
A Trunk Link, or 'Trunk' is a port configured to carry packets for any VLAN. These type of ports
are usually found in connections between switches. These links require the ability to carry
packets from all available VLANs because VLANs span over multiple switches.
The diagram below shows multiple switches connected throughout a network and the Trunk
Links are marked in purple colour to help you identify them:
As you can see in our diagram, our switches connect to the network backbone via the Trunk
Links. This allows all VLANs created in our network to propagate throughout the whole network.
Now in the unlikely event of Trunk Link failure on one of our switches, the devices connected to
that switch's ports would be isolated from the rest of the network, allowing only ports on that
switch, belonging to the same VLAN, to communicate with each other.
So now that we have an idea of what Trunk Links are and their purpose, let's take a look at an
actual switch to identify a possible Trunk Link:
As we noted with the explanation of Access Link ports, the term 'Trunk Link' describes a
configured port. In this case, the Gigabit ports are usually configured as Trunk Links, connecting
the switch to the network backbone at the speed of 1 Gigabit, while the Access Link ports connect
at 100Mbits.
In addition, we should note that for a port or link to operate as a Trunk Link, it is imperative that
it runs at speeds of 100Mbit or greater. A port running at speeds of 10Mbit's cannot operate as a
Trunk Link and this is logical because a Trunk Link is always used to connect to the network
backbone, which must operate at speeds greater than most Access Links!
Summary
This page introduced the Access and Trunk links. We will be seeing a lot of both links from now
on, so it's best you get comfortable with them! Configuration of these links is covered later on,
because there is still quite a bit of theory to cover!
Next up is the VLAN Tagging topic where we will see what really runs through those Access and
Trunk links!
VLAN Tagging
Introduction
We mentioned that Trunk Links are designed to pass frames (packets) from all VLANs, allowing
us to connect multiple switches together and independently configure each port to a specific
VLAN. However, we haven't explained how these packets run through the Trunk Links and
network backbone, eventually finding their way to the destination port without getting mixed or
lost with the rest of the packets flowing through the Trunk Links.
This is process belongs to the world of VLAN Tagging!
VLAN Tagging
VLAN Tagging, also known as Frame Tagging, is a method developed by Cisco to help identify
packets travelling through trunk links. When an Ethernet frame traverses a trunk link, a special
VLAN tag is added to the frame and sent across the trunk link.
As it arrives at the end of the trunk link the tag is removed and the frame is sent to the correct
access link port according to the switch's table, so that the receiving end is unaware of any VLAN
information.
The diagram below illustrates the process described above:
Here we see two 3500 series Catalyst switches and one Cisco 3745 router connected via the
Trunk Links. The Trunk Links allow frames from all VLANs to travel throughout the network
backbone and reach their destination regardless of the VLAN the frame belongs to. On the other
side, the workstations are connected directly to Access Links (ports configured for one VLAN
membership only), gaining access to the resources required by VLAN's members.
Again, when we call a port 'Access Link' or 'Trunk Link', we are describing it based on the way it
has been configured. This is because a port can be configured as an Access Link or Trunk Link
(in the case where it's 100Mbits or faster).
This is stressed because a lot of people think that it's the other way around, meaning, a switch's
uplink is always a Trunk Link and any normal port where you would usually connect a
workstation, is an Access Link port!
VLAN Tagging Protocol
We're now familiar with the term 'Trunk Link' and its purpose, that is, to allow frames from
multiple VLANs to run across the network backbone, finding their way to their destination. What
you might not have known though is that there is more than one method to 'tag' these frames as
they run through the Trunk Links or ... the VLAN Highway as we like to call it.
InterSwitch Link (ISL)
ISL is a Cisco propriety protocol used for FastEthernet and Gigabit Ethernet links only. The
protocol can be used in various equipments such as switch ports, router interfaces, server
interface cards to create a trunk to a server and much more. You'll find more information on
VLAN implementations on our last page of the VLAN topic.
Being a propriety protocol, ISL is available and supported naturally on Cisco products only:) You
may also be interested in knowing that ISL is what we call, an 'external tagging process'. This
means that the protocol does not alter the Ethernet frame as shown above in our previous diagram
- placing the VLAN Tag inside the Ethernet frame, but encapsulating the Ethernet frame with a
new 26 byte ISL header and adding an additional 4 byte frame check sequence (FCS) field at the
end of frame, as illustrated below:
Despite this extra overhead, ISL is capable of supporting up to 1000 VLANs and does not
introduce any delays in data transfers between Trunk Links.
In the above diagram we can see an ISL frame encapsulating an Ethernet II frame. This is the
actual frame that runs through a trunk link between two Cisco devices when configured to use
ISL as their trunk tagging protocol.
The encapsulation method mentioned above also happens to be the reason why only ISL-aware
devices are able to read it, and because of the addition of an ISL header and FCS field, the frame
can end up being 1548 bytes long! For those who can't remember, Ethernet's maximum frame
size is 1518 bytes, making an ISL frame of 1548 bytes, what we call a 'giant' or 'jumbo' frame!
Lastly, ISL uses Per VLAN Spanning Tree (PVST) which runs one instance of the Spanning Tree
Protocol (STP) per VLAN. This method allows us to optimise the root switch placement for each
available VLAN while supporting neat features such as VLAN load balancing between multiple
trunks.
Since the ISL's header fields are covered on a separate page, we won't provide further details
here.
IEEE 802.1q
The 802.1q standard was created by the IEEE group to address the problem breaking large
networks into smaller and manageable ones through the use of VLANs. The 802.1q standard is of
course an alternative to Cisco's ISL, and one that all vendors implement on their network
equipment to ensure compatibility and seamless integration with the existing network
infrastructure.
As with all 'open standards' the IEEE 802.1q tagging method is by far the most popular and
commonly used even in Cisco oriented network installations mainly for compatability with other
equipment and future upgrades that might tend towards different vendors.
In addition to the compatability issue, there are several more reasons for which most engineers
prefer this method of tagging. These include:



Support of up to 4096 VLANs
Insertion of a 4-byte VLAN tag with no encapsulation
Smaller final frame sizes when compared with ISL
Amazingly enough, the 802.1q tagging method supports a whopping 4096 VLANs (as opposed to
1000 VLANs ISL supports), a large amount indeed which is merely impossible to deplet in your
local area network.
The 4-byte tag we mentioned is inserted within the existing Ethernet frame, right after the Source
MAC Address as illustrated in the diagram below:
Because of the extra 4-byte tag, the minimum Ethernet II frame size increases from 64 bytes to 68
bytes, while the maximum Ethernet II frame size now becomes 1522 bytes. If you require more
information on the tag's fields, visit our protocol page where further details are given.
As you may have already concluded yourself, the maximum Ethernet frame is considerably
smaller in size (by 26 bytes) when using the IEEE 802.1q tagging method rather than ISL. This
difference in size might also be interpreted by many that the IEEE 802.1q tagging method is
much faster than ISL, but this is not true. In fact, Cisco recommends you use ISL tagging when in
a Cisco native environment, but as outlined earlier, most network engineers and administrators
believe that the IEEE802.1q approach is much safer, ensuring maximum compatability.
And because not everything in this world is perfect, no matter how good the 802.1q tagging
protocol might seem, it does come with its restrictions:

In a Cisco powered network, the switch maintains one instance of the Spanning Tree
Protocol (STP) per VLAN. This means that if you have 10 VLANs in your network, there
will also be 10 instances of STP running amongst the switches. In the case of non-Cisco
switches, then only 1 instance of STP is maintained for all VLANs, which is certainly not
something a network administrator would want.

It is imperative that the VLAN for an IEEE 802.1q trunk is the same for both ends of the
trunk link, otherwise network loops are likely to occur.

Cisco always advises that disabling a STP instance on one 802.1q VLAN trunk without
disabling it on the rest of the available VLANs, is not a good idea because network loops
might be created. It's best to either disable or enable STP on all VLANs.
LAN Emulation (LANE)
LAN Emulation was introduced to solve the need of creating VLANs over WAN links, allowing
network managers to define workgroups based on logical function, rather than physical location.
With this new technology (so to speak - it's actually been around since 1995!), we are now able to
create VLANs between remote offices, regardless of their location and distance.
LANE is not very common and you will most probably never see it implemented in small to midsized networks, however, this is no reason to ignore it. Just keep in mind that we won't be looking
at it in much depth, but briefly covering it so we can grasp the concept.
LANE has been supported by Cisco since 1995 and Cisco's ISO release 11.0. When implemented
between two point-to-point links, the WAN network becomes totally transparent to the end users:
Every LAN or native ATM host, like the switch or router shown in the diagram, connects to the
ATM network via a special software interface called 'LAN Emulation Client'. The LANE Client
works with the LAN Emulation Server (LES) to handle all messages and packets flowing through
the network, ensuring that the end clients are not aware of the WAN network infrastructure and
therefore making it transparent.
The LANE specification defines a LAN Emulation Configuration Server (LECS), a service
running inside an ATM switch or a physical server connected to the ATM switch, that resides
within the ATM network and allows network administrators to control which LANs are combined
to form VLANs.
The LAN Emulation Server with the help of the LANE Client, maps MAC addresses to ATM
addresses, emulating Layer 2 protocols (DataLink layer) and transporting higher layer protocols
such as TCP/IP, IPX/SPX without modification.
802.10 (FDDI)
Tagging VLAN frames on Fiber Distributed Data Interface (FDDI) networks is quite common in
large scale networks. This implementation is usually found on Cisco's high-end switch models
such as the Catalyst 5000 series where special modules are installed inside the switches,
connecting them to an FDDI backbone. This backbone interconnects all major network switches,
providing a fully redundant network.
The various modules available for the Cisco Catalyst switches allow the integration of Ethernet
into the FDDI network. When intalling the appropriate switch modules and with the use of the
802.10 SAID field, a mapping between the Ethernet VLAN and 802.10 network is created, and as
such, all Ethernet VLANs are able to run over the FDDI network.
The diagram above shows two Catalyst switches connected to a FDDI backbone. The links
between the switches and the backbone can either be Access type links (meaning one VLAN
passes through them) or Trunk links (all VLANs are able to pass through them). At both ends, the
switches have an Ethernet port belonging to VLAN 6, and to 'connect' these ports we map each
switch's Ethernet module with its FDDI module.
Lastly, the special FDDI modules mentioned above support both single VLANs (non-trunk) and
multiple VLANs (trunk).
To provide further detail, the diagram below shows the IEEE 802.10 frame, along with the SAID
field in which the VLAN ID is inserted, allowing the frame to transit trunk links as described:
It's okay if your impressed or seem confused with the structure of the above frame, that's normal:)
You'll be suprised to find out that the Cisco switch in the previous diagram must process the
Ethernet II frame and convert it before placing it on the IEEE 802.10 backbone or trunk.
During this stage, the original Ethernet II frame is converted to an Ethernet SNAP frame and then
finally to an IEEE 802.10 frame. This conversion is required to maintain compatability and
reliability between the two different topologies. The most important bit to remember here is the
SAID field and its purpose.
Summary
This page introduced four popular VLAN tagging methods, providing you with the frame
structure and general details of each tagging method. Out of all, the IEEE 802.1q and ISL tagging
methods are the most popular, so make sure you understand them quite well.
The next page provides further detail by analysing the two popular tagging methods mentioned
above. While some readers might find the details unnecessary and time wasting, we feel that they
are required if you want to build a rock solid network library in your head:)
Analysing The InterSwitch Link Protocol
Introduction
Deciding whether to use ISL or IEEE 802.1q to power your trunk links can be quite confusing if
you cannot identify the advantages and disadvantages of each protocol within your network.
This page will cover the ISL protocol in great detail, providing an insight to its secrets and
capabilities which you probably were unaware of. In turn, this will also help you understand the
existence of certain limitations the protocol has, but most importantly allow you to decide if ISL
is the tagging process you require within your network.
InterSwitch Link (ISL)
ISL is Cisco's propriety tagging method and supported only on Cisco's equipment through Fast &
Gigabit Ethernet links. The size of an ISL frame can be expected to start from 94 bytes and
increase up to 1548 bytes due to the overhead (additional fields) the protocol places within the
frame it is tagging.
These fields and their length are also shown on the diagram below:
We will be focusing on the two purple coloured 3D blocks, the ISL header and ISL Frame Check
Sequence (FCS) respectively. The rest of the Ethernet frame shown is a standard Ethernet II
frame as we know it. If you need more information, visit our Ethernet II page.
The ISL Header
The ISL header is 26 byte field containing all the VLAN information required (as one would
expect), to allow a frame traverse over a Trunk Link and find its way to its destination.
Here is a closer look at the header and all the fields it contains:
You can see that the ISL header is made out of quite a few fields, perhaps a lot more than what
you might have expected, but this shouldn't alarm you as only a handful of these fields are
important. As usual, we will start from the left field and work our way to the far right side of the
header. First up...... the DA field:
Destination Address (DA) Field
The 'DA' field is a 40 bit destination address field that contains a multicast address usually set to
"0x01-00-0C-00-00" or "0x03-00-0C-00-00". This address is used to signal to the receiver that
the packet is in ISL format.
Type Field
The 'Type' field is 4 bits long and helps identify the encapsulated original frame. Depending on
the frame type, the ISL 'Type' field can take 4 possible values as outlined in the table below:
Type Value
Encapsulated Frame
0000
Ethernet
0001
Token-Ring
0010
FDDI
0011
ATM
The 4 bits of space assigned to the 'Type Value' field allow a maximum of 2^4=16 different
values. Since all combinations are not used, there is plenty of room for future encapsulations that
might be developed.
User Defined Field
The 'User' field occupying 4 bits serves as an extension to the previous 'Type' field and is mostly
used when the original encapsulated frame is an Ethernet II type frame. When this happens, the
first two bits of the 'User' field act as a prioritisation mechanism, allowing the frames to find their
way to the destination much faster.
Currently, there are 4 different priorities available, as shown in the table below:
Type Value
Frame Priority
XX00
Normal Priority
XX01
Priority 1
XX10
Priority 2
XX11
Highest Priority
We should also note that the use of priorities is optional and not required.
Source Address (SA) Field
The 'SA' field is the source MAC address of the switch port transmitting the frame. This field is as expected- 48 bits long. The receiving device can choose to ignore this field. It is worth noting
that while the Destination Address field located at the beginning of the header contains a
multicast MAC Address, the Source MAC address field we are looking at here contains the MAC
address of the sending device - usually a switch.
Length Field
The 'Length' field is 16 bits long and contains the whole ISL frame's length minus the DA, Type,
User, SA, LEN and FCS fields. If you're good at mathematics, you can easily calculate the total
length of the excluded fields, which is 18 bytes. With this in mind, a quick way to find this field's
value is to take the total frame size and subtract 18 bytes :)
Length fields are used in frames to help the receiving end identify where specific portions of the
frame exist within the frame received.
AAAA03 (SNAP) Field
The SNAP field is a 24 bit long field with a value of "0xAAAA03".
High bits Source Address (HSA) Field
The 'HSA' field is a 24 bit value. This field represents the upper three bytes of the SA field (the
manufacturers ID portion) and must contain the value "0x00-00-0C". Since the SA field is 48 bits
long or 6 bytes, the upper 3 bytes of the SA field would translate to 24 bits, hence the length of
the HSA field.
VLAN - Destination Virtual LAN ID Field
The 'VLAN' field is the Virtual LAN ID of the frame. This is perhaps the most important field of
all as our frame moves between trunk links because it allows all trunk links to identify the VLAN
this frame belongs to. The VLAN ID field is 15 bits long and often referred to as the "color" of
the frame.
Without this field, there would be no way of identifying which VLAN the frame transitting a
trunk link belongs to.
Bridge Protocol Data Unit (BPDU) & Cisco Discovery Protocol (CDP) Indicator
The 'BPDU' field is only 1 bit long but very important as it is set for all BPDU packets
encapsulated by the ISL frame. For those unaware, BPDU's are used by the Spanning Tree
Protocol (STP) to shut down redundant links and avoid network loops. This field is also used for
CDP and Virtual Trunk Protocol (VTP) frames that are encapsulated.
Index Field
The 'Index' field is a 16 bit value and indicates the port index of the source of the packet as it exits
the switch. It is used for diagnostic purposes only and may be set to any value by other devices.
RES Field - Reserved for Token Ring and Fiber Distributed Data Interface (FDDI)
The 'RES' field is a 16 bit value and used when Token Ring or FDDI packets are encapsulated
with an ISL frame. In the case of Token Ring frames, the Access Control (AC) and Frame
Control (FC) fields are placed here whereas in the case of FDDI, the FC field is placed in the
Least Significant Byte (LSB) of this field (as in a FC of "0x12" would have a RES field of
"0x0012"). For Ethernet packets, the RES field should be set to all zeros.
Frame Check Sequence (ISL FCS)
Coming to the end of the ISL protocol analysis, we met the 'FCS' field which consists of four
bytes. The FCS contains a 32-bit CRC value, which is created by the sending MAC (switch) and
is recalculated by the receiving MAC (switch) to check for corrupt frames. In an Ethernet II
frame, the FCS is generated using the Destination MAC, Source MAC, Ethertype, and Data fields
while ISL's FCS is calculated based on the entire ISL frame and added to the end of it.
Summary
This page analysed all fields of the ISL header and FCS. The next page deals with the popular
IEEE 802.1q, an alternative to Cisco's ISL tagging protocol.
If you require, have a quick break to freshen up and when you return, click on the link below to
be transported to the wonderful IEEE 802.1q world!
Analysing The IEEE 802.1q Link Protocol
Introduction
Our VLAN Tagging page briefly covered the IEEE 802.1q protocol and we are about to continue
its analysis here. As mentioned previously, the IEEE 802.1q tagging method is the most popular
as it allows the seemless integration of VLAN capable devices from all vendors who support the
protocol.
So, without any more delay, let's get right into the protocol.
IEEE 802.1q Analysis
The IEEE 802.1q tagging mechanism seems quite simple and efficient thanks to its 4-byte
overhead squeezed between the Source Address and Type/Length field of our Ethernet II frame:
The process of inserting the 802.1q tag into an Ethernet II frame results in the original Frame
Check Sequence (FCS) field to become invalid since we are altering the frame, hence it is
essential that a new FCS is recalculated, based on the new frame now containing the IEEE 802.1q
field. This process is automatically performed by the switch, right before it sends the frame down
a trunk link. Our focus here will be the pink 3D block, labeled as the IEEE 802.1q header.
The IEEE 802.1q Header
As noted, the 802.1q header is only 4 bytes or 32 bits in length while within this space there is all
the necessary information required to successfully identify the frame's VLAN and ensure it
arrived to the correct destination. The diagram below analyses all fields contained in a 802.1q
header:
The structure is quite simple as there are only 4 fields when compared with the 11 ISL has. We
will continue by analysing each of these fields in order to discover what the protocol is all about.
TPID - Tag Protocol IDentifier
The TPID field is 16 bit long with a value of 0x8100. It is used to identify the frame as an IEEE
802.1q tagged frame.
Note: The next three fields, Priority, CFI and VLAN ID are also known as the TCI (Tag Control
Information) field and are often represented as one single field (TCI Field).
Priority
The Priority field is only 3 bits long but used for prioritisation of the data this frame is carrying.
Data Prioritisation is a whole study in itself but we won't be analysing it here since it's well
beyond the scope of our topic. However, for those interested, data prioritisation allows us to give
special priority to time-latency sensitive services, such as Voice Over IP (VoIP), over normal
data. This means that the specified bandwidth is allocated for these critical services to pass them
through the link without any delay.
The IEEE 802.1p priority protocol was developed to provide such services and is utilised by the
IEEE 802.1q tagging protocol.
The Priority field is approximately 3 bits long, allowing a total of 2^3=8 different priorities for
each frame, that is, level zero (0) to seven (7) inclusive.
CFI - Canonical Format Indicator
The CFI field is only 1 bit long. If set to '1', then it means the MAC Address is in non-canonical
format, otherwise '0' means it is canonical format. For Ethernet switches, this field is always set to
zero (0). The CFI field is mainly used for compatibility reasons between Ethernet and Token Ring
networks.
In the case where a frame arrives to an Ethernet port and the CFI flag is set to one (1), then that
frame should not be forwarded as it was received to any untagged port (Access Link port).
VLAN ID - Virtual Local Area Network Identifier
The VLAN ID field is perhaps the most important field out of all because we are able to identify
which VLAN the frame belongs to, allowing the receiving switch to decide which ports the frame
is allowed to exit depending on the switch configuration.
For those who recall our VLAN Tagging page, we mentioned that the IEEE 802.1q tagging
method supports up to 4096 different VLANs. This number derives from the 12 bit VLAN ID
field we are analysing right now and here are the calculations to prove this: 2^12=4096, which
translates from VLAN 0 to VLAN 4095 inclusive.
Summary
That completes our analysis on the IEEE 802.1q protocol. As a last note, you should remember
that this protocol is the most wide spread tagging method used around the world that supports up
to 4096 VLANs!
Next up is the popular InterVLAN Routing topic, which is often a misunderstood and confusing
subject, but we have managed to make it simple and clear. It's now time for a break - go get some
fresh air and we'll see you back in a few moments for the rest of our cool VLAN topic!
InterVLAN Routing
Introduction
Surely most of you network gurus would agree without a doubt that the invention of VLANs for
networks are as good, if not better, as the invention of the mouse for computers!
Being able to create new network segments using the existing backbone and without rewiring is,
for most administrators, a dream come true! Add the ability to move users or deparments between
these networks with a just few keystrokes and you're in paradise.
VLANs have certainly become popular and are very welcomed in every administrator's or
engineer's network. However, they also raised several issues which troubled many of us. One
major issue concerns routing between existing and newly created VLANs.
The Need For Routing
Each network has it's own needs, though whether it's a large or small network, internal routing, in
most cases, is essential - if not critical. The ability to segment your network by creating VLANs,
thus reducing network broadcasts and increasing your security, is a tactic used by most engineers.
Popular setups include a separate broadcast domain for critical services such as File Servers, Print
servers, Domain Controllers e.t.c, serving your users non-stop.
The issue here is how can users from one VLAN (broadcast domain), use services offered by
another VLAN?
Thankfully there's an answer to every problem and in this case, its VLAN routing:
The above diagram is a very simple but effective example to help you get the idea. Two VLANs
consisting of two servers and workstations of which one workstation has been placed along with
the servers in VLAN 1, while the second workstation is placed in VLAN 2.
In this scenario, both workstations require access to the File and Print servers, making it a very
simple task for the workstation residing in VLAN 1, but obviously not for our workstation in
VLAN 2.
As you might have already guessed, we need to somehow route packets between the two VLANs
and the good news is that there is more than one way to achieve this and that's what we'll be
covering on this page.
VLAN Routing Solutions
While the two 2924 Catalyst switches are connected via a trunk link, they are unable to route
packets from one VLAN to another. If we wanted the switch to support routing, we would require
it to be a layer 3 switch with routing capabilities, a service offered by the popular Catalyst 3550
series and above.
Since there are quite a few ways to enable the communcation between VLANs (InterVLAN
Routing being the most popular) there is a good chance that we are able to view all possible
solutions. This follows our standard method of presenting all possible solutions, giving you an indepth view on how VLAN routing can be setup, even if you do not have a layer 3 switch.
Note: The term 'InterVLAN Routing' refers to a specific routing method which we will cover as a
last scenario, however it is advised that you read through all given solutions to ensure you have a
solid understanding on the VLAN routing topic.
VLAN Routing Solution No.1: Using A Router With 2 Ethernet Interfaces
A few years ago, this was one of the preferred and fastest methods to route packets between
VLANs. The setup is quite simple and involves a Cisco router e.g 2500 series with two Ethernet
interfaces as shown in the diagram, connecting to both VLANs with an appropriate IP Address
assigned to each interface. IP Routing is of course enabled on the router and we also have the
option of applying access lists in the case where we need to restrict network access between our
VLANs.
In addition, each host (servers and workstations) must either use the router's interface connected
to their network as a 'default gateway' or a route entry must be created to ensure they use the
router as a gateway to the other VLAN/Network. This scenario is however expensive to
implement because we require a dedicated router to router packets between our VLANs, and is
also limited from an expandability prospective.
In the case where there are more than two VLANs, additional Ethernet interfaces will be required,
so basically, the idea here is that you need one Ethernet interface on your router that will connect
to each VLAN.
To finish this scenario, as the network gets bigger and more VLANs are created, it will very
quickly get messy and expensive, so this solution will prove inadequate to cover our future
growth.
VLAN Routing Solution No.2: Using A Router With One Ethernet (Trunk) Interface
This solution is certainly fancier but requires, as you would have already guessed, a router that
supports trunk links. With this kind of setup, the trunk link is created, using of course the same
type of encapsulation the switches use (ISL or 802.1q), and enabling IP routing on the router side.
The downside here is that not many engineers will sacrifice a router just for routing between
VLANs when there are many cheaper alternatives, as you will soon find out. Nevertheless,
despite the high cost and dedicated hardware, it's still a valid and workable solution and
depending on your needs and available equipment, it might be just what you're looking for!
Closing this scenario, the router will need to be configured with two virtual interfaces, one for
each VLAN, with the appropriate IP Address assigned to each one so routing can be performed.
VLAN Routing Solution No.3: Using A Server With Two Network Cards
We would call this option a "Classic Solution". What we basically do, is configure one of the
servers to perform the routing between the two VLANs, reducing the overal cost as no dedicated
equipment is required.
In order for the server to perform the routing, it requires two network cards - one for each VLAN
and the appropriate IP Addresses assigned, therefore we have configured one with IP Addresses
192.168.1.1 and the other with 192.168.2.1. Once this phase is complete, all we need to do is
enable IP routing on the server and we're done.
Lastly, each workstation must use the server as either a gateway, or a route entry should be
created so they know how to get to the other network. As you see, there's nothing special about
this configuration, it's simple, cheap and it gets the job done.
VLAN Routing Solution No.4: InterVLAN Routing
And at last.... InterVLAN routing! This is without a doubt the best VLAN routing solution out of
all of the above. InterVLAN routing makes use of the latest in technology switches ensuring a
super fast, reliable, and acceptable cost routing solution.
The Cisco Catalyst 3550 series switches used here are layer 3 switches with built-in routing
capabilities, making them the preferred choice at a reasonable cost. Of course, the proposed
solution shown here is only a small part of a large scale network where switches such as the
Catalyst 3550 are usually placed as core switches, connecting all branch switches together (2924's
in this case) via superfast fiber Gigabit or Fast Ethernet links, ensuring a fast and reliable network
backbone.
We should also note that InterVLAN routing on the Catalyst 3550 has certain software
requirements regarding the IOS image loaded on the switch as outlined on the table below:
Image Type & Version
InterVLAN Routing Capability
Enhanced Multilayer Image (EMI) - All Versions
YES
Standard Multilayer Image (SMI) - prior to 12.1(11)EA1
NO
Standard Multilayer Image (SMI) - 12.1(11)EA1 and later
YES
If you happen to have a 3550 Catalyst in hand, you can issue the 'Show version' to reveal your
IOS version and find out if it supports IP routing.
In returning to our example, our 3550 Catalyst will be configured with two virtual interfaces, one
for each VLAN, and of course the appropriate IP Address assigned to them to ensure there is a
logical interface connected to both networks. Lastly, as you might have guessed, we need to issue
the 'IP Routing' command to enable the InterVLAN Routing service!
The diagram above was designed to help you 'visualise' how switches and their interfaces are
configured to specific VLAN, making the InterVLAN routing service possible. The switch above
has been configured with two VLANs, VLAN 1 and 2. The Ethernet interfaces are then assigned
to each VLAN, allowing them to communicate directly with all other interfaces assigned to the
same VLAN and the other VLAN, when the internal routing process is present and enabled.
Access Lists & InterVLAN Routing
Another common addition to the InterVLAN routing service is the application of Access Lists
(packet filtering) on the routing switch,to restrict access to services or hosts as required.
In modern implementations, central file servers and services are usually placed in their own
isolated VLAN, securing them from possible network attacks while controlling access to them.
When you take into consideration that most trojans and viruses perform an initial scan of the
network before attacking, an administrator can smartly disable ICMP echoes and other protocols
used to detect a live host, avoiding possible detection by an attacker host located on a different
VLAN.
Summary
InterVLAN is a terrific service and one that you simply can't live without in a large network. The
topic is a fairly easy one once you get the idea, and this is our aim here, to help you get that idea,
and extend it further by giving you other alternative methods.
The key element to the InterVLAN routing service is that you must have at least one VLAN
interface configured with an IP Address on the InterVLAN capable switch, which will also
dictate the IP network for that VLAN. All hosts participating in that VLAN must also use the
same IP addressing scheme to ensure communication between them. When the above
requirements are met, it's then as simple as enabling the IP Routing service on the switch and you
have the InterVLAN service activated.
Next in line is the Virtual Trunk Protocol (VTP), a protocol that ensures every administrator's and
engineer's life remains nice and easy .... how can this be possible?
Keep reading to find out :)
Introduction To The Virtual Trunk Protocol - VTP
Introduction
The invention of VLANs was very much welcomed by all engineers and administrators, allowing
them to extend, redesign and segment their existing network with minimal costs, while at the
same time making it more secure, faster and reliable!
If you're responsible for a network of up to 4-6 switches that include a few VLANs, then you'll
surely agree that it's usually a low overhead to administer them and periodically make changes most engineers can live with that:)
Ask now an engineer who's in charge of a medium to a large scale network and you will
definately not receive the same answer, simply because these small changes can quickly become
a nightmare and if you add the possibility of human error, then the result could be network
outages and possibly downtime.
Welcome To Virtual Trunk Protocol (VTP)
VTP, a Cisco proprietary protocol, was designed by Cisco with the network engineer and
administrator in mind, reducing the administration overhead and the possibility of error as
described above in any switched network environment.
When a new VLAN is created and configured on a switch without the VTP protocol enabled, this
must be manually replicated to all switches on the network so they are all aware of the newly
created VLAN. This means that the administrator must configure each switch separately, a task
that requires a lot of time and adds a considerable amount of overhead depending on the size of
the network.
The configuration of a VLAN includes the VLAN number, name and a few more parameters
which will be analysed further on. This information is then stored on each switch's NVRAM and
any VLAN changes made to any switch must again be replicated manually on all switches.
If the idea of manually updating all switches within your network doesn't scare you because your
network is small, then imagine updating more than 15-20 switches a few times per week, so your
network can respond to your organisation's needs....have we got you thinking now? :)
With the VTP protocol configured and operating, you can forget about running around making
sure you have updated all switches as you only need to make the changes on the nominated VTP
server switch(es) on your network. This will also ensure these changes are magically propagated
to all other switches regardless of where they are.
Introducing The VTP Modes
The VTP protocol is a fairly complex protocol, but easy to understand and implement once you
get to know it. Currently, 3 different versions of the protocol exist, that is, version 1, 2 (adds
support for Token Ring networks) and 3, with the first version being used in most networks.
Despite the variety of versions, it also operates in 3 different modes: Server, client and
transparent mode, giving us maximum flexibility on how changes in the network effect the rest of
our switches. To help keep things simple and in order to avoid confusion, we will work with the
first version of the VTP protocol - VTP v1, covering more than 90% of networks.
Below you'll find the 3 modes the VTP protocol can operate on any switch throughout the
network:



VTP Server mode
VTP Client mode
VTP Transparent mode
Each mode has been designed to cover specific network setups and needs, as we are about to see,
but for now, we need to understand the purpose of each mode and the following network diagram
will help us do exactly that.
A typical setup involves at least one switch configured as a VTP Server, and multiple switches
configured as VTP Clients. The logic behind this setup is that all information regarding VLANs is
stored only on the VTP Server switch from which all clients are updated. Any change in the
VLAN database will trigger an update from the VTP Server towards all VTP clients so they can
update their database.
Lastly, be informed that these VTP updates will only traverse Trunk links. This means that you
must ensure that all switches connect to the network backbone via Trunk links, otherwise no VTP
updates will get to your switches.
Let's now take a closer look at what each VTP mode does and where it can be used.
VTP Server Mode
By default all switches are configured as VTP Servers when first powered on. All VLAN
information such as VLAN number and VLAN name is stored locally, on a separate NVRAM
from where the 'startup-config' is stored. This happens only when the switch is in VTP Server
mode.
For small networks with a limited number of switches and VLANs, storing all VLAN information
on every switch is usually not a problem, but as the network expands and VLANs increase in
number, it becomes a problem and a decision must be made to select a few powerful switches as
the VTP Servers while configuring all other switches to VTP Client mode.
The diagram above shows a Cisco Catalyst 3550 selected to take the role of the network's VTP
Server since it is the most powerful switch. All other Catalyst switches have been configured as
VTP Clients, obtaining all VLAN information and updates from the 3550 VTP Server.
The method and frequency by which these updates occur is covered in much detail on the pages
that follow, so we won't get into any more detail at this point. However, for those who noticed,
there is a new concept introduced in the above diagram that we haven't spoken about: The VTP
Domain.
The VTP Domain - VLAN Management Domain
The VTP Domain, also known as the VLAN Management Domain, is a VTP parameter
configured on every switch connected to the network and used to define the switches that will
participate in any changes or updates made in the specified VTP domain.
Naturally, the core switch (VTP Server) and all other switches participate in the same domain, e.g
firewall, so when the VTP Server advertises new VLAN information for the VTP firewall
domain, only clients (switches) configured with the same VTP Domain parameter will accept and
process these changes, the rest will simply ignore them.
Lastly, some people tend to relate the VTP Domain with the Internet Domain name space,
however, this is completely incorrect. Even though the acronym 'DNS' contains the word
'Domain', it is not related in any way with the VTP Domain. Here (in VTP land), the word
'Domain' is simply used to describe a logical area in which certain hosts (switches) belong to or
participate in, and are affected by any changes made within it.
We should also note that all Cisco switches default to VTP Server mode but will not transmit any
VLAN information to the network until a VTP Domain is set on the switch.
At this point we are only referencing the VTP Domain concept as this is also analysed in greater
depth further on, so let's continue with the VTP modes!
VTP Client Mode
In Client Mode, a switch will accept and store in its RAM all VLAN information received from
the VTP Server, however, this information is also saved in NVRAM, so if the switch is powered
off, it won't loose its VLAN information.
The VTP Client behaves like a VTP Server, but you are unable to create, modify or delete
VLAN's on it.
In most networks, the clients connect directly to the VTP Server as shown in our previous
diagram. If, for any reason, two clients are cascaded together, then the information will propagate
downwards via the available Trunk links, ensuring it reaches all switches:
The diagram shows a 3550 Catalyst switch configured as a VTP Server and 4 Catalyst 2950
switches configured as VTP Clients and cascaded below our 3550. When the VTP Server sends a
VTP update, this will travel through all trunk links (ISL, 802.1q, 802.10 and ATM LANE), as
shown in the diagram.
The advertised information will firstly reach the two Catalyst 2950 switches directly connected to
the 3550 and will then travel to the cascaded switches below and through the trunk links. If the
link between the cascaded 2950's was not a trunk link but an access link, then the 2nd set of
switches would not receive and VTP updates:
As you can see, the VTP updates will happlily arrive at the first catalyst switches but stop there as
there are no trunk links between them and the 2950's below them. It is very important you keep
this in mind when designing a network or making changes to the existing one.
VTP Transparent Mode
The VTP Transparent mode is something between a VTP Server and a VTP Client but does not
participate in the VTP Domain.
In Transparent mode, you are able to create, modify and delete VLANs on the local switch,
without affecting any other switches regardless of the mode they might be in. Most importantly, if
the transparently configured switch receives an advertisement containing VLAN information, it
will ignore it but at the same time forward it out its trunk ports to any other switches it might be
connected to.
NOTE: A Transparent VTP switch will act as a VTP relay (forward all VTP information it
receives, out its trunk ports) only when VTP version 2 is used in the network. With VTP version
1, the transparent switch will simply ignore and discard any VTP messages received from the rest
of the network.
Lastly, all switches configured to operate in Transparent mode save their configuration in their
NVRAM (just like all the previous two modes) but not to advertise any VLAN information of its
own, even though it will happily forward any VTP information received from the rest of the
network.
This important functionality allows transparently configured switches to be placed anywhere
within the network, without any implications to the rest of the network because as mentioned,
they act as a repeater for any VLAN information received:
Our 3550 Catalyst here is configured as a VTP Server for the domain called "Firewall". In
addition, we have two switches configured in VTP Client mode, obtaining their VLAN
information from the 3550 VTP Server, but between these two VTP Clients, we have placed
another switch configured to run in VTP Transparent mode.
Our Transparent switch has been configured with the domain called "Lab", and as such, the
switch will forward all incoming VTP updates belonging to the "Firewall" domain out its other
trunk link, without processing the information. At the same time, it won't advertise its own
VLAN information to its neighbouring switches.
Closing, the VTP Transparent mode is not often used in live networks, but is well worth
mentioning and learning about.
Summary
This page introduced a few new and very important concepts. The VTP Protocol is considered to
be the heart of VLANs in large scale networks as it completely makes the administration point of
view easy and transparent for every switch on your network.
We briefly spoke about the three different modes offered by the VTP protocol: Server, Client and
Transparent mode. To assist in providing a quick summary, the table below shows the main
characteristics for each mode:
VTP Mode
Description
VTP Server
The default mode for all switches supporting VTP. You can create, modify, and delete VLANs
and
specify other configuration parameters (such as VTP version)
for the entire VTP domain.
VTP servers advertise their VLAN configurations to other switches in the same VTP domain and
synchronize their VLAN configurations with other switches based on advertisements received
over trunk
links. VLAN configurations are saved in NVRAM.
VTP Client
Behaves like a VTP server, but you cannot create, change, or delete VLANs on a VTP client.
VLAN configurations are saved in NVRAM.
VTP Transparent
Does not advertise its VLAN configuration and does not synchronize its VLAN configuration
based on received advertisements. However, they will forward VTP advertisements as they are
received from other switches.
You can create, modify, and delete VLANs on a switch in VTP transparent mode. VLAN
configurations are saved in NVRAM, but they are not advertised to other switches.
All switches by default are configured as VTP Servers but without a domain. At this point we
need to select the 'Core' switch (usually the most powerful) and configure it as a VTP Server,
while reconfiguring all the rest to Client mode. Also, VTP Updates sent by the Server will only
propagate through trunk links configured for ISL, IEEE 802.1q, 802.10 or LANE encapsulation.
NOTE: You should be aware that all VTP Messages are sent through what we call the
"Management VLAN". This specially created VLAN is usually the first one in the network VLAN 1 - and by rule is never used by anyone else other than the switches themselves.
The creation of a Management VLAN ensures all switches have their own network to
communicate between each other without any disruptions.
The next page will analyse the VTP Protocol structure, messages and updates. This will provide a
deep understanding on how VTP works and what information it's messages contain. For those out
there keen on configuring a switch for VTP, it's covered towards the end of the VLAN topic as
shown on the VLAN Introduction page.
In-Depth Analysis Of VTP
Introduction
The previous page introduced the VTP protocol and we saw how it can be used within a network,
to help manage your VLANs and ease the administrative overhead providing a stress-free VLAN
environment, automatically updating all the network switches with the latest VLAN information.
This page extends on the above by delving into the VTP protocol itself and analysing it's structure
and format in order to gain a better understanding and enhance those troubleshooting skills.
The VTP Protocol Structure
We've mentioned that the VTP protocol runs only over trunk links interconnecting switches in the
network. Whether you're using ISL or IEEE 802.1q as your encapsulation protocol, it really
doesn't matter as the VTP structure in both cases remains the same.
Following are the fields which consist the VTP protocol:




VTP Protocol Version (1 or 2)
VTP Message Type (See Below)
Management Domain Length
Management Domain Name
What we need to note here is that because there are a variety of "VTP Message Types", the VTP
Header changes depending on these messages, but the fields we just mentioned above are always
included.
To be more specific, here are the different messages currently supported by the VTP protocol:




Summary Advertisements
Subset Advertisement
Advertisement Requests
VTP Join Messages
It is obvious that all switches use these different messages to request information or advertise the
VLANs they are aware of. These messages are extremely important to understand as they are the
foundations of the VTP protocol.
We'll take each message and analyse them individually, explaining their purpose and usage, but
before we proceed, let's take a quick visual look at the messages and their types to help make all
the above clearer:
First up is the 'Summary Advertisements'.
VTP Protocol - Summary Advertisement Message
The 'Summary Advertisement' message is issued by all VTP Domain Servers in 5 minute
intervals, or every 300 seconds. These advertisements inform nearby Catalyst switches with a
variety of information, including the VTP Domain name, configuration revision number,
timestamp, MD5 encryption hash code, and the number of subset advertisements to follow.
The configuration version number is a value each switch stores to help it identify new changes
made in the VTP domain. For those experienced with DNS, it's pretty much the same as the DNS
serial number. Each time a VTP Server's configuration is changed, the configuration revision
number will automatically increment by one.
When a switch receives a summary advertisement message, it will first compare the VTP domain
name (Mgmt Domain Name field) with its own.
If the Domain Name is found to be different, it will discard the message and forward it out its
trunk links. However, in the likely case that the domain name is found to be the same, it will then
check the configuration revision number (Config Revision No.) and if found to be the same or
lower than it's own, it will ignore the advertisement. If, on the other hand, it is found to be
greater, an advertisement request is sent out.
The Updater Identity field contains the IP Address of the switch that last incremented the
Configuration Revision Number, while the Update Timestamp field gives the time the last update
took place.
The MD5 (Message Digest 5) field contains the VTP password in the case where it is configured
and used to ensure the validation of the VTP Update.
Lastly, summary advertisements are usually followed by Subset Advertisements, this is indicated
by the Followers field and is the next message we'll be closely examining.
VTP Protocol - Subset Advertisement
As mentioned in the previous message, when VLAN changes are made on the Catalyst VTP
Server, it will then issue a Summary Advertisement, followed by a Subset Advertisement.
Depending on how many VLANs are configured in the domain, there might be more than one
Subset Advertisement sent to ensure all VLAN information is updated on the VTP Clients.
Comparing the fields of this message with the previous one, you'll notice most of them are
identical, except for the Sequence No. and VLAN Info. Field.
The Code field for a Subset Advertisement of this type is set to 0x02 while the Sequence No.
field contains the sequence of the packet in the stream of packets following a summary
advertisement. The sequence starts with 1 and increments based on the number of packets in the
stream.
Apart from these fields, we also have the VLAN Info Field, which happens to be the most
important as it contains all the VLAN information the switches are waiting for.
The VLAN Info Field will be presented in segments. Complexity and importance requires us to
break it up further and analyse the subfields it contains:
Each VLAN Info Field contains all the information required for one VLAN. This means that if
our network is powered with 10 VLANs and a Subset Advertisement is triggered, the VTP Server
will send a total of 10 Subset Advertisements since each VLAN Info Field contains data for one
VLAN.
The most important subfields in the VLAN Info Field are the VLAN Name Length, ISL VLAN
ID, MTU Size and VLAN Name. These subfields contain critical information about the VLAN
advertised in the particular Subset Advertisement frame. Some might be suprised to see settings
such as MTU's to be configurable in VLAN's, and this confirms that each VLAN is treated as a
separate network, where even different MTU sizes are possible amongst your network's VLANS.
Advertisement Requests
Turning a switch off will result loosing all its VTP information stored in its memory (RAM).
When the switch is next turned on, all its database information is reset and therefore requires to
be updated with the latest version available from the VTP Server(s).
A switch will also send an Advertisement Request when it hears a VTP summary
advertisement with a higher revision number than what it currently has. Another scenario where a
request would be issued is when the VTP domain membership has changed, even though this is
quite uncommon since the VTP domain name is rarely, if ever, changed after its initial
configuration.
So what happens when a Advertisement Request hits the streets of your network?
As you would already be aware from the message types we have just covered, the VTP Server
will respond with Summary Advertisement, followed by as many Subset Advertisements required
to inform the VTP Clients about the currently configured VLANs.
The diagram below shows the structure of an Advertisement Request sent by a VTP Client
switch:
Most fields as you can see, are similar to the previous messages we've seen, except two: The
Reserved and Starting Advertisement To Request . The Reserved is exactly what it implies reserved and not used in the Advertisement Request messages, while the Starting Advertisement
To Request is the actual request sent by the VTP Client.
VTP Join Messages
VTP Join Messages are similar to the Advertisement Request messages but with a different
Message Type field value and a few more parameters. As indicated by the message name, a VTP
Join Message is sent when the VTP Client first joins a VTP domain, informing the VTP Server(s)
about the new guy in 'town':)
Other VTP Options - VTP Password
The VTP Password is a feature that all security conscious Administrators/Engineers will
welcome. With the password feature, you are able to secure your VTP Domain since only
switches configured with the correct password are able to properly decrypt the VTP messages
advertised in the management VLAN.
By default the VTP Password option is not turned on and therefore most management VLANs are
set to use non-secure advertisements. Once enabled on the VTP Domain Server(s), all switches
participating in the domain must be manually configured with the same password, otherwise it
will fail to decrypt all incoming VTP messages.
Summary
This page analysed the structure of each message the VTP protocol currently supports to maintain
the network's switches in synchronisation with the VTP domain server(s):




Summary Advertisements
Subset Advertisement
Advertisement Requests
VTP Join Messages
We're sure you would agree that VLAN's are in fact a whole study case alone, but surely at the
same time it's quite exciting as new concepts and methods of ensuring stability, speed and
reliability are revealed.
This completes our in-depth discussion on the VTP Protocol messages. Next up is VTP Prunning,
a nice service that ensures our network backbone is not constantly flooded with unnecessary
traffic. We are sure you'll enjoy the page, along with the awesome diagrams we have prepared.
VTP Pruning
Introduction
As you would be aware a switched network creates one broadcast domain, similar to that of a
VLAN powered network where all nodes belonging to the same VLAN are part of the same
broadcast domain, receiving all broadcasts sent on their network.
The Broadcast And Unicast Problem In VLAN Networks
What we are about to see is how these broadcasts can actually create problems by flooding the
VLAN network with unnecessary traffic, and depending on your network setup, this can prove to
be a huge problem. The reason for this is because the trunk links interconecting your network
switches will carry these broadcasts to every switch in the network, regardless of which VLAN
the broadcast is intended for.
As shown and described, a host connected to a port configured for VLAN 2 on Switch 1 (first
switch on the left), generates a network broadcast. Naturally, the switch will forward the
broadcast out all ports assigned to the same VLAN it was received from, that is, VLAN 2.
In addition, the Catalyst switch will forward the broadcast out its trunk link, so it may reach all
ports in the network assigned to VLAN 2. The Root switch receives the broadcast through one of
it's trunks and immediately forwards it out the other two - towards Switch 2 & 3.
Switch 2 is delighted to receive the broadcast as it does in fact have one port assigned to VLAN
2. Switch 3 however, is a different case - it has no ports assigned to VLAN 2 and therefore will
drop the broadcast packet it receives.
In this example, the bandwidth usage was ineffecient because one broadcast packet was sent over
all possible trunk links, and was then dropped by Switch 3.
You might ask yourself 'So what's the big deal?'.
The problem here is small and can easily be ignored... but consider a network of fifteen or more
12 port switches (this translates to at least 210 nodes) and you can start to appreciate how serious
the problem can get. To make things worse (and more realistic), consider you're using 24 port
switches, then you're all of a sudden talking about more than 300 nodes!
To further help you understand how serious the problem gets, take a look at our example network
below:
Here you see a medium sized network powered by Cisco Catalyst switches. The two main
switches up the top are the VTP servers and also perform 3rd layer switching by routing packets
between the VLANs we've created.
Right below them you'll find our 2950's Catalyst switches which are connected to the core
switches via redundant fiber trunk links. Directly below our 2950's are our 2948 Catalyst switches
that connect all workstations to the network.
A workstation connected to a port assigned to VLAN 2 decided to send a network broadcast
looking for a specific network resource. While the workstation is totally unaware of our network
design and complexity, its broadcast is the reason all our trunks will flood with unwanted traffic,
consuming valuable bandwidth!
Take a look at what happens:
We don't think describing the above is actually required as the diagram shows all the information
we need and we're confident you will agree that we dealing with a big problem:)
So how do we fix this mess ?
Keep reading on as you're about to learn........
The Solution: Enabling VTP Pruning
VTP Pruning as you might have already guessed solves the above problem by reducing the
unnecessary flooded traffic described previously. This is done by forwarding broadcasts and
unknown unicast frames on a VLAN over trunk links only if the receiving end of the trunk has
ports in that VLAN.
Looking at the above diagram you will notice that the Root Catalyst 3550 Switch receives a
broadcast from Switch 1, but only forwards it out one of it's trunks. The Root Switch knows that
the broadcast belongs to VLAN 2 and furthermore it's aware no port is assigned to VLAN 2 on
Switch 3, therefore it won't forward it out the trunk that leads to that switch.
Support For VTP Pruning
The VTP Pruning service is supported by both VTP 1 and VTP 2 versions of the VTP protocol.
With VTP 1, VTP pruning is possible with the use of additional VTP message types.
When a Cisco Catalyst switch has ports associated with a VLAN, it will send an advertisement to
its neighboring switches informing them about the ports it has active on that VLAN. This
information is then stored by the neighbors and used to decide if flooded traffic from a VLAN
should be forwarded to the switch via the trunk port or not.
Note: VTP Pruning is disabled by default on all Cisco Catalyst switches and can be enabled by
issuing the "set vtp pruning enable" command.
If this command is issued on the VTP Server(s) of your network, then pruning is enabled for the
entire management domain.
VTP Pruning configuration and commands are covered in section 11.4 as outlined in the VLAN
Introduction page, however, we should inform you that you can actually enable pruning for
specific VLANs in your network.
When you enable VTP Pruning on your network, all VLANs become eligible for pruning on all
trunk links. This default list of pruning eligibility can thankfully be modified to suite your needs
but you must first clear all VLANs from the list using the "clear vtp prune-eligible vlan-range"
command and then set the VLAN range you wish to add in the prune eligible list by issuing the
following command: "set vtp prune-eligible vlan-range" where the 'vlan-range' is the actual
inclusive range of VLANs e.g '2-20'.
By default, VLANs 2–1000 are eligible for pruning. VLAN 1 has a special meaning because it is
normally used as a management VLAN and is never eligible for pruning, while VLANs 1001–
1005 are also never eligible for pruning. If the VLANs are configured as pruning-ineligible, the
flooding continues as illustrated in our examples.
Summary
VTP Pruning can in fact be an administrator's best friend in any Cisco powered network,
increasing available bandwidth by restricting flooded traffic to those trunk links that the traffic
must use to reach the destination devices.
At this point, we have also come to the end of the first part of our VLAN presentation. As we are
still working on the second and final part of the VLAN topic, we hope these pages will keep you
going until it is complete.