N Module1: Introduction to Networking.

This module will introduce students to the general concept of computer networks, the need for
networks, different standards, types and various other standard terminologies and definitions used
in the world of computer networking.

What is Networking or Computer Networks? What is the need for Networks?

In simple terms, a computer network is a group of two ore computers linked together. They can be
connected by various mediums like cables, wireless adapters etc.. Sharing resources like files, data,
printers, etc., was the key objective of starting such a concept years back. Such networks can be
used for several other purposes like communications too. Depending on how the connections
between the computers are spread out there are different terminologies used to identify the types
of networks. A small group of computers within home or office premise talking to each other only is
termed as a Local Area Network or a LAN. The types of networks are also defined based on the
geographical spread of the networked computers or devices.

Servers Printers Scanners

Desktops
Laptops

Figure1: A simple Computer Network

Local Area Networks (LAN)

Like mentioned earlier, the types of the networks are identified based on their geographical
distribution. A Local Area Network, is a network of computers within a limited area such as homes,
schools, colleges etc. They are generally connected to each other using devices like hubs or
switches.

Figure 2: Local Area Network

Printers

Servers Scanners

Ethernet Switch

Desktops Laptops
Wide Area Network (WAN)

A Wide Area Network is a type of network which covers a wider physical locations of computers.
Often they are also referred to as a combinations of a few LANs. Let us take a simple example.
Assume your college has two different branches located in two different cities of India. Each branch
of college has its own setup of LANs. For further more collaboration, we can connect these two LANs
into one network through some communication means, which becomes an example of WANs.
Internet is another good example of a wide area network.

LAN1
LAN2
Printers
Printers
Servers Scanners
Servers Scanners
Branch 1

Comm Link Desktops Laptops

Desktops Laptops Router Router

Branch 1 Branch 2

WAN

Wireless Networking

Any kind of network that does not use any physical media for connection and uses wireless
technology for connecting and communicating two nodes is a Wireless Network.

Wireless Access Point

Network Architecture

Network architecture simply refers to the design of any form of computer networks. It specifies the
network’s physical components and the organization/configuration of the same.

The Institute of Electrical and Electronics Engineers (IEEE) is a professional association dedicated to
advancing technological innovation and excellence. IEEE defines certain network standards. IEEE
802 is a family of standards from IEEE, dealing with networks. Some of the key ones in the 802 family
are:

- IEEE 802.3 – Ethernet Networks: This is a collection of standards defining the Ethernet. This
is generally a local area network technology with some wide area network applications as
well. Physical connections are made between the nodes of the network by various types of
copper or fiber cable.
- IEEE 802.5 – Token Ring Networks: This is a collection of standards defining the Token ring
LAN technology. This comprises of a frame called token that travels around the nodes of the
ring. Possessing the token grans the possessor permission to transmit on the medium. Token
ring frames travel completely around the loop. This also defines the data transmission
process in this topology.
- IEEE 802.11 – Wireless Networks: This is a set of specifications for implementing Wireless
Local Area Network in a specific bandwidth range.
- IEEE 802.16 – Broadband Wireless Networks: This is a set of specifications for implementing
Wireless Broadband standards.

Ethernet

Ethernet is the most common and popular computer networking architecture used today for the
Local Area Networks. Ethernet was standardized as IEEE 802.3.

The Ethernet standards comprise several wiring and signaling variants of the OSI physical layer in use
with Ethernet. The original 10BASE5 Ethernet used coaxial cable as a shared medium. Later the
coaxial cables were replaced with twisted pair and fiber optic links in conjunction with hubs or
switches. Data rates were periodically increased from the original 10 megabits per second to 100
gigabits per second.

Systems communicating over Ethernet divide a stream of data into shorter pieces called frames.
Each frame contains source and destination addresses and error-checking data so that damaged
data can be detected and re-transmitted. As per the OSI model Ethernet provides services up to and
including the data link layer.
Network Components and Terminology

Node: A node is used to denote one of the component in the computer networks. It is generally used
to refer to a device in the network which has a unique address and is capable of sending, receiving,
forwarding or consuming data received over a communication media.

In data communication, a physical network node may either be a device such as a modem, hub,
bridge or switch, or a device such as a digital telephone handset, a printer or a host computer, for
example a router, a workstation or a server.

All of the device connected in the network shown in figure 2, can be referred to as a ‘node’.

Network Adapter / Network Interface Controller (NIC)

This is a hardware device in each of the nodes of the network, which is used to connect to the
network.

MAC Address

Every NIC which is used to connect to the network, and following the IEEE standard, has a unique
serial number called a Media Access Control (MAC) or Physical Address. These addresses are
assigned by the manufacturer of the NIC and stored in the card itself. There is always a unique MAC
address per NIC.

The IEEE 802 standard of printing the MAC address in a format that is easily understood is, six groups
of two hexadecimal digits each, separated by a hypen (-) or colon(:).

Eg:

Physical Address. . . . . . . . . : 00-1F-29-05-1E-A2

This address cannot be changed for a given NIC. The MAC Address is 6 bytes long. The first 3 bytes
identifies the company that manufactured the NIC, and the second 3 bytes is the serial number of
the NIC.

Logical Address

Logical address of a computer represents the address of the computer which are assigned using the
several schemes or protocols. Eg: If TCP/IP is the protocol scheme used on any system, then the
TCP/IP address of the node is the logical address of the system. There can be more than one logical
address, but only one Physical Address to a NIC.

Eg:

IPv4 Address. . . . . . . . . . . : 10.171.120.176

There are various methods to assign a Logical Address to the nodes. These address may change
depending on the location from which you are connecting to a network.

Server / Client

A node is referred to as a server, if it delivers various services to the other nodes in the network. A
client is the node which consumes the service that is offered by the Server.
Eg: A node in the network may be hosting a printer and can allow printing services to be used by
various other nodes in the network. The node offering the print services is referred to as a Server,
while the node which is utilizing the print service is referred to as a client.

Printer

Servers

Ethernet Switch

Client 1
Client 2

Communication/Network Protocol

A communication or network protocol is a set of rules for data exchange between nodes of a
network. To communicate successfully between nodes, both the nodes must use the same protocol.
Networking Hardware

Punch-Down Panels

Punch-Down Panels are used to connect hardware located in wiring closets or server rooms to the
cabling that runs out to the users' workstations.

Figure: A set of patch panels mounted in a standard network rack

Network Interface Card

A network interface card (NIC) is used to connect a computer/device to the network. It includes two
interfaces—one to connect to the network and one to connect to the computer/device itself. The
NIC is the brains of the network connection, containing its own processor chip to help take some of
the load off the computer's central processing unit (CPU).

There are a number of different varieties of NIC cards. The first thing to look at is how the card
interfaces with the computer. There are three types of NIC card interfaces:

 attaching to an external port on the computer such as the parallel port

 installed internally in a Peripheral Component Interconnect Mezzanine/Computer Interface

Adapter (PCIM/CIA) slot, now known simply as a PC slot

 installed internally within the system connecting directly to the computer bus

Figure: A standard internal network card

Media Converters

Media converters are devices used to connect two dissimilar cable types. They are usually palm-size
boxes with mating connectors on either end. Converts are available to connect together twisted
pair, coax, and fiber in any possible combination. Depending on the application, they may or may not
require an external power source.

While it is not always practical to upgrade all network devices when a media change occurs, media
converters can be lifesavers in a pinch.

Repeaters

Repeaters are simple two-port signal amplifiers. They are used in a bus topology to extend the
maximum distance that can be spanned on a cable run. The strength of the signal is boosted as it
travels down the wire. A repeater will receive a digital signal on one of its ports, amplify it, and
transmit it out the other side.

Hubs

Hubs are probably the most common piece of network hardware after network interface cards.
Physically, they are boxes of varying sizes that have multiple female RJ-45 connectors. Each
connector is designed to accept one twisted-pair cable outfitted with a male RJ-45 connector. This
twisted-pair cable is then used to connect a single server or workstation to the hub.
Hubs are essentially multi-port repeaters that support twisted-pair cables in a star typology. Each
node communicates with the hub, which in turn amplifies the signal and transmits it on its remaining
ports. As with a repeater, hubs work at the electrical level. Because hubs have no way to determine
if a frame is good or bad, they should be looked at, when you design your network typology, as
functionally identical to repeaters.

Hubs come in two categories, chassis and stackable.

Chasis Hubs

A chassis hub is a large box (typically one or two feet tall and the width of a network rack) that is
made to mount into a network rack.

Stackable Hubs

Stackable hubs are slim line boxes which usually contain between six and 24 ports. Most have link
and transmit lights to help monitor the health of each port. Stackables are so named because, as
your port requirements grow, you can simply buy another hub and stack it on top of the first.
Stackables can also be rack mounted or flush mounted to a wall.

Backbone Connection

Stackable hubs have two different methods of being connected together—through a backbone
connection (if one is supplied) or through an uplink port. A backbone connection is a separate
connector designed to be attached to hubs; it is usually implemented as a BNC connector in 10 Mbps
hubs and connects the hubs with a short run of thinnet cable.

Note: Some vendors use a proprietary cable to connect their hubs together for management
purposes. In this case, these cables will supply the required network connection between the hubs
as well.

Uplink Port Connection

An uplink port is a special port that reverses the transmit-and-receive pair of a twisted-pair cable. An
uplink port can look like any other hub port, so you should be careful not to use it inadvertently. An
uplink port is required because if you directly wire two hubs together the wire pairs will be
connected transmit-to-transmit and receive-to-receive; wired this way the hubs will be unable to
communicate with each other. Some uplink ports will have a switch next to them to allow you to
select their mode of operation. If you have a small network and do not need to connect your hub to
another, you can usually throw the switch and use it to connect an extra workstation. Note that only
one hub needs to be uplinked. If you use the uplink port on both sides, the hubs will still be unable
to communicate.

Figure : Three stackable hubs of various port densities

Bridges

A bridge looks a lot like a repeater; it is a small box with two network connectors that attach to two
separate portions of the network. A bridge incorporates the functionality of a repeater (signal
amplification), but it actually looks at the frames of data, which is a great benefit. A common bridge
is nearly identical to a repeater except for the indicator lights, as shown in Figure 4.8. A forward light
flashes whenever the bridge needs to pass traffic from one collision domain to another.

Figure: A common bridge

Switches

Switches are the marriage of hub and bridge technology. They resemble stackable hubs in
appearance, having multiple RJ-45 connectors for connecting network systems. Instead of being a
dumb amplifier like a hub, however, switches function as though they have a little miniature bridge
built into each port. A switch will keep track of the MAC addresses attached to each of its ports and
direct traffic destined for a certain address only to the port to which it is attached.

Figure below shows a switched environment in which the device will learn the position of each
station once a single frame transmission occurs (identical to a bridge). Assuming that this has already
happened, we now find that at exactly the same instant station 1 needs to send data to server 1,
station 2 needs to send data to server 2 and station 3 needs to send data to server 3.

Figure: A switch installation showing three workstations and three servers that need to
communicate
Cut Through Mode

Switches have two modes of operation—cut through and store-and-forward. In cut through mode
the switch receives only the first 14 bytes of the frame (just the header) and will immediately begin
to make a decision as to where the frame should be sent. In cut through mode a switch has the
ability to begin transmitting the frame on the destination port before it receives it in its entirety; this
results in extremely fast switching times with a minimal amount of latency added to the circuit. The
greatest benefits of cut through mode are in quiet or full duplex environments where it is unlikely
the switch will need to pause prior to transmission.

The benefits of cut through mode diminish as traffic levels increase. If utilization is high, it is unlikely
that the switch will ever be able to transmit the frame onto a collision domain prior to receiving it in
its entirety anyway. In these cases store-and-forward mode can be just as effective.

Store-and-Forward Mode

Store-and-forward mode requires the switch to read the entire frame into memory prior to
transmission. While reading the entire frame adds a bit of a delay, the store-and-forward mode
definitely has its advantages. Like a bridge, a switch in store-and-forward mode has the ability to
check the FCS field for CRC errors; this ensures that bad frames are not propagated across the
network. Another cool feature is that store-and-forward mode gives the switch the ability to support
multiple topologies. A server could be connected to a 100 Mbps port while all the workstations are
connected to 10 Mbps ports, allowing the server to keep up with data requests easily from multiple
workstations and speeding overall network performance.

Store-and-forward switching is always used with mixed topologies because it ensures that the switch
has the entire frame available prior to attempting a transmission. Because, in cut through mode, a
switch can begin transmitting a frame prior to receiving it in its entirety, problems may arise in a
mixed speed situation. Let's say a frame is received on a 10 Mbps port and it is addressed to a
system on the 100 Mbps port. In cut through mode the switch would immediately begin delivery on
the faster segment. This can be a problem because there is the potential for the switch to transmit
all the frame information it has received on the faster segment and then have to pause and wait for
the delivery of the rest of the frame information. Obviously, this would cause communication
problems on the faster segment.

VLAN Technology

Switching introduces a new technology referred to as the virtual local area network (VLAN). Software
running on the switch allows you to set up connectivity parameters for connected systems by
workgroup instead of by geographical location. The switch's administrator is allowed to organize
port transmissions logically so that connectivity is grouped according to each user's requirements.
The "virtual" part of it is that these workgroups can span over multiple physical network segments.
By assigning all switch ports that connect to PCs used by accounting personnel to the same
workgroup, a virtual accounting network can be created.

Let's take a look at a more detailed example of how this works.

A VLAN Example

Say we have two groups of users who work exclusively with each other and a particular server. We
could create two VLANs, isolating the traffic so that all communications remain within the group.
While a switch will do this anyway for point-to-point communications, the addition of the VLANs will
block broadcast traffic as well. This isolation will help to reduce unnecessary traffic even further. The
added bonus is security, as users from one VLAN will be unable to try and connect to the server in
the other VLAN. This extra security may be useful in a secure environment.

There may be a problem with this setup, however. What if the two servers are running NetWare
4.11 and need to exchange NDS information with each other? The solution is to add a third VLAN
that includes only the servers. VLANs are allowed to overlap as circumstances require. This overlap
allows server broadcasts to reach all members of the workgroup as well as the other server.
Workstations located in the other workgroup would not see these broadcasts and thus be
safeguarded from this additional traffic. Our network would look something like Figure 4.19.

While the true benefits of VLANs may not be apparent immediately, let's increase the scale of our
network and watch what happens. Figure 4.20 shows an organization that occupies a number of
floors in a building. If each department is confined to each floor, then our network design may be
fine as is.

Unfortunately this is rarely the case and work groups can find themselves spread out over a wide
geographical area. If the marketing server is located on the first floor, then any marketing personnel
located on a different floor will find themselves traversing the backbone on a regular basis. Let's
assume this situation is true for other departments as well.

Figure: VLAN implementation in a small networking environment

Routers

A router is a multi-port device that makes decisions on how to handle a frame, based on protocol
and network address. To truly understand what this means we must first look at what a protocol is
and how it works.

Up until now we've been happily communicating using the media access control address assigned to
our networking devices. Our systems have used this number to contact other systems and transmit
information as required.

The problem with this scheme is that it does not scale very well. For example, what if I have 2,000
systems that need to communicate with each other? Even by employing switching and virtual
networking I will eventually reach a point where network performance will degrade and no more
systems can be added. This is where protocols come in.

Protocols

A protocol is a set of communication rules that provide the means for networking systems to be
grouped by geographical area and common wiring. To indicate they are part of a specific group, each
of these systems is assigned an identical protocol network address.

Network Addresses are kind of like zip codes. Let's assume someone mails a letter and the front of
the envelope simply reads: Amber Apple, 7 Spring Road. If this is a very small town, this letter will
probably get through (as if you used a MAC address on a LAN).

If the letter was mailed in a city like Boston or New York, however, the post office where it lands
would have no clue where to send it (although they would probably get a good laugh). Without a zip
code they may not even attempt delivery. The zip code provides a way to specify the general area
where this letter needs to be delivered. The postal worker processing the letter is not required to
know where exactly Spring Road is located. They simply look at the zip code and forward the letter
to the post office responsible for this code. It is up to the local post office to know where Spring
Road is located and use this information to ensure that the letter reaches its destination address.

Protocol network addresses operate in a similar fashion. A protocol-aware device will add the
network address of the device it wishes to reach to the data field of a frame. It will also record its
own network address in case the remote system needs to send a reply.

This is where a router comes in. A router will maintain a table of all known networks. It will use these
tables to help forward information to its final destination. Let's walk through an example to see how
a routed network operates.

Switch Routers

Switch routers are fairly new to the networking world. These devices provide all the functionality of
a switch and include some of the benefits of a router when VLANs are implemented.

As discussed, switches are protocol-stupid. When a VLAN is created it restricts all communications to
within itself. There is no way to tell a VLAN to react differently depending on protocol. Segmentation
is done by port selection or by analyzing the system's MAC address.

When a Switch Router is Useful

Let's assume we have a network of 75 users. These users are broken down into groups of 25, each
with its own NetWare server. The users communicate only with their own server and use the IPX
protocol. So far we have a good application for a regular switch. We could create three VLANs and
segregate traffic as we did in earlier examples.

Now let's throw in a twist and assume that all the workstations are providing file sharing via IP to all
other workstations on the network. With a regular switch, our VLANs would immediately become
useless. This is because every workstation requires the ability to communicate with every other
workstation on the network, and our switch VLANs would block this connectivity.

This is where a switch router comes in handy. In this situation a switch router could be configured to
restrict IPX traffic to the VLANs we defined while allowing IP traffic to flow freely throughout the
network. The switch router provides an additional level of fine tuning when isolating traffic on the
network.
Because switch routing is a new technology, its features and design advantages are still under
development. As people become more familiar with switch routers, expect to see additional features
added and new applications discovered.

Translational Gateways

Translational gateways are used to convert communication of one protocol into another. This
functionality can be extremely useful if you need to provide connectivity to some foreign network or
server and do not wish to support an additional protocol on your network.

For example, let's assume you're administering a very large network which currently supports only
the IPX protocol. Your company decides it needs to connect all of its users to the Internet, which
uses the IP protocol. Instead of dealing with the additional administration and overhead of adding
another protocol to your network you could opt to install a translational gateway instead. Users
would transmit their information destined for the Internet to the gateway via the IPX protocol. The
gateway would then repackage the information into IP packets and forward them along to the
Internet. When a reply returns, the gateway translates the packets from IP back into IPX and
forwards them along to the internal workstation.

Firewalls

Entire books can and have been dedicated to the discussion of firewall technology. While we
obviously cannot cover firewalls at that level of detail, it will be helpful to have a basic
understanding of their functionality.

Firewalls are similar to other network devices in that their purpose is to control the flow of traffic.
Unlike other network devices, however, a firewall must control this traffic, taking into account that
not all the frames it sees are what they appear to be.

As an example, a bridge filters traffic based on the destination MAC address. If a station is incorrectly
labeling the MAC address and the bridge inadvertently passes the packet along, the bridge is not
looked at as being faulty or inadequate. It is expected that the station will follow certain network
rules, and, if it does not, then it is the station that is at fault, not the bridge.

A firewall, however, must assume that a station may try to fool it in order to sneak information past
it. It cannot use communication rules as a crutch but rather should expect that the rules will not be
followed. This places a lot of pressure on the firewall design, as it must plan for every contingency.

A firewall operates under a specific set of filter rules. These rules indicate what type of traffic should
be allowed to pass and what traffic should be blocked. When evaluating these rules, a firewall will
typically look at the following frame information:

 source network address

 destination network address

 type of service being requested

 protocol being used

 type of data frame (Is this a request for data or a reply?)

Packet Filtering
There are three ways to firewall—packet filtering, proxy, and stateful inspection. Packet filters are
the simplest of the three and they are not considered a true firewalling method by some security
experts. Packet filters typically look at some or all of the above listed criteria and use this
information to determine if a packet should be passed or blocked. While packet filters afford some
protection, they are still fallible to a number of attacks. An experienced network engineer would be
able to come up with a few ways to circumvent the security provided by a packet filter. If properly
configured, packet filters are usually sufficient for protecting small environments that do not have
any internal systems offering IP services such as a web or FTP. Most routers are capable of providing
packet filtering functionality. If you absolutely must ensure the integrity of your internal systems,
however, then one of the two other methods should be used.

Proxy

A proxy is a representative of, or surrogate replacement for, some other networked device. As the
name implies, a proxy firewall acts as a delegate for all communications. When an internal system
needs to send data to the Internet, it first sends it to the proxy. The proxy will then repackage the
frame and replace the network address of the original system with its own. This ensures that all
communications on the insecure side of the firewall only take place with the firewall itself. This
means that the network address of the system that initially transmitted the frame is hidden and
does not have to be made known. When the destination system receives the packet, it believes that
the frame originated from the proxy.

If the insecure system needs to respond to the frame it will reply to the source network address,
which points to the proxy firewall. The proxy would then receive the frame, analyze it, and forward it
along to the original system. By acting as a mediator the proxy ensures that the insecure system
never has direct access to the internal system.

Stateful Inspection

The final type of firewall is stateful inspection. A stateful inspection firewall monitors and records all
outbound traffic and uses this information in addition to the filtering rules to determine what traffic
will be let back in.

For example, we mentioned that when a system connects to a resource, concessions must be made
to allow replies to data requests back in. Also mentioned was that this opens up a potential hole
through which a slippery hacker may worm their way in. Stateful inspection helps to plug this hole
by recording who the data request was originally sent to. A stateful inspection firewall will monitor
inbound traffic, only letting in information that originates from the system to which the data request
was sent.

Modem

While most people are familiar with modems, they are worth a brief mention here. The modem is a
device used for converting a digital signal into an analog transmission that is capable of traversing
plain old telephone lines (POTS).

There are two separate measurement terms used when describing modems, bit and baud. A bit is
simply a single digital pulse or transmission. With POTS communications these pulses are in the form
of tones. The term bit is used to refer to the amount of digital information the device is capable of
converting into an analog signal, such as 28800 bits per second (bps).
So why the bit rate is so low compared to a LAN? When POTS was first conceived it was designed to
carry voice communications only. Because the average human voice will only produce sounds
between 300 and 3300 cycles per second, this was all the bandwidth that was supported. Modems
are required to operate within these constraints. They do not have the benefit of being designed
from the ground up to relay digital information. This is sort of like trying to fit a round peg into a
square hole. It will fit, provided you whack it with a hammer a few times.

A baud refers to an individual signal event along the POTS line. This can be any change in frequency,
amplitude or phase of the analog signal being transmitted. Baud and byte are not directly
comparable. The baud rate usually lags behind the bit rate in value as modem manufacturers
attempt to squeeze every bit of bandwidth they can out of the phone lines.

The modem industry can appear at times to be a little bit like Scotty from Star Trek. With each new
release of modem speeds a claim is made that we've reached the maximum bit rate for POTS lines
and "She can't take any more, Captain!" This has been occurring since the 9600 bps modems where
released. At the time of this writing, 56000 bps modems are just hitting the market.

The reason for this is simple—technology is still evolving. Just as computers that used to take up
entire rooms will now fit in your shirt pocket, so too have communication engineers continued to
find new ways to push larger quantities of information through this same tiny pipe.

Codex

A codex is the opposite of a modem. Short for coder/decoder, a codex is used for converting an
analog signal into a digital transmission. Physically, they are small boxes, or computer expansion
cards, with multiple RJ-11 connectors. If it is an external unit, a connector is also provided to connect
a digital device such as a computer.

CSU/DSU n

A CSU/DSU is a device that combines the functionality of a channel service unit (CSU) and a data
service unit (DSU). These devices are used to connect a LAN to a WAN, and they take care of all the
translation required to convert a data stream between these two methods of communication. Figure
4.26 shows a 56K leased-line DSU. The indicator lights on the front of the unit let you monitor its
operational status.

Figure: A 56K leased-line DSU

DSU

A DSU provides all the handshaking and error correction required to maintain a connection across a
wide area link. In this aspect it is similar to a modem or codex in functionality. The DSU will accept a
serial data stream from a device on the LAN and translate this into a useable data stream for the
digital WAN network. For example, if the WAN link is a T1 connection, the DSU would break the
information up into a time division format acceptable for use on this circuit. It would also take care
of converting any inbound data streams from the WAN back to a serial communication.
CSU

A CSU is similar to a DSU except it does not have the ability to provide handshaking or error
correction. It is strictly an interface between the LAN and the WAN and relies on some other device
to provide handshaking and error correction.

The network device of choice to combine with a CSU is a router. While it is possible to use a bridge
or a switch with these devices, a router is more appropriate as it is better able to isolate traffic and
keep unwanted packets from traversing the WAN. Because bandwidth is at a premium over a wide
area link, the more unnecessary traffic that can be kept off it the better. The combination of a CSU
with a router has become so common that there is currently a trend to incorporate the functionality
of the CSU directly into the router itself.

CSU/DSUs differ in the type of wide area links and amount of bandwidth they will support. If you
currently have a digital leased line and you're thinking of upgrading to a full T1, expect to replace
this hardware.

Workstation

A workstation is simply a regular desktop system outfitted with a network card. The system will
contain a central processor unit (CPU), memory, and usually a hard drive. The hardware allows the
system to run programs across the network or off of the local drive as required. Except for the
network card, these systems can be identical to the computers purchased for home use.

Server

A server, simply put, is a networked computer that offers up some kind of service to other
computers on the network. These systems are typically identical to your average workstation except
they may contain more memory, a faster processor, and larger hard drives. For software, they need
to run some form of network operating system (NOS) that provides connectivity for many users.
While a workstation only needs to interface with one user at a time, a server may be expected to
take care of multiple users and offer up multiple services.

Server Types

The three types of servers are:

 file server provide a common area for users to share and use files

 print server provide a common printer that networked users can access

 Application Server provide a software program for common user access.

References:

Networking Hardware - http://technet.microsoft.com/en-us/library/bb726959.aspx#EPAA

Routers and Switches - http://technet.microsoft.com/en-us/library/cc749968.aspx

Module 1 Labs/Assessment

1. Identify the IP Address assigned to your local workstation

2. Identify the MAC Address of your local workstation
3. Write a short note RJ45
4. Write a short note RJ11
Module2: Introduction to the OSI Model

In the early years of networking, sending and receiving data across a network was confusing,
because large companies such as IBM, Honeywell, and Digital Equipment Corporation had individual
standards for connecting computers. It was unlikely that applications operating on different
equipment from different vendors could communicate. Vendors, users, and standards bodies
needed to agree upon and implement a standard architecture that would allow computer systems to
exchange information even though they were using software and equipment from different vendors.

In 1978, the International Standards Organization (ISO) introduced a networking model, called the
Open Systems Interconnection (OSI) model, as a first step toward standardizing data
communications standards to promote multi-vendor network interoperability.

The OSI model consists of layers, each with a specific set of network functions. The model specifies
the set of protocols and interfaces to implement at each layer and provides guidelines for
implementation of the interfaces between layers.

Each layer of the OSI model exists as an independent module. In theory, you can substitute one
protocol for another at any given layer without affecting the operation of layers above or below.

The design of the OSI model is based on the following principles:

 A layer should be created only when an additional level of abstraction is required.

 Each layer should perform a well-defined function.

 The function of each layer should be chosen with the goal of defining internationally
standardized protocols.

 The layer boundaries should be chosen to minimize the information flow across the
interfaces.

 The number of layers should be large enough to enable distinct functions to be separated,
but few enough to keep the architecture from becoming unwieldy.

Figure below shows the layers in the OSI model, beginning with the physical layer, which is closest to
the network media.

Figure: Layers of the OSI Model

Physical Layer

The physical layer is the lowest layer of the OSI model. This layer controls the way unstructured, raw,
bit -stream data is sent and received over a physical medium. This layer is composed of the
electrical, optical, and physical components of the network. The physical layer carries the signals for
all of the higher layers.

To better accommodate the characteristics of the physical medium and to assist in bit and frame
synchronization, data encoding modifies the simple, digital signal pattern (1s and 0s) used by the
computer.

Data encoding determines:

 Which signal pattern represents a binary 0 and a binary 1.

 How the receiving station recognizes when an encoded bit starts.

 How the receiving station delimits a frame.

The physical components (such as wiring, connectors, and pin-outs) determine:

 Whether an external transceiver is used to connect to the medium.

 How many pins the connectors have and what role each pin performs.

The transmission technique determines whether the encoded bits are transmitted by means of
baseband (digital) signaling or broadband (analog) signaling.

The physical means of transmission, such as a network adapter or fiber optic adapter, determines
whether it is appropriate to transmit bits as electrical or optical signals.

Data-Link Layer

The data-link layer provides error-free transfer of data frames from one computer to another over
the physical layer. The layers above this layer can assume virtually error-free transmission over the
network.

The data-link layer provides the following functions:

 Establishment and termination of logical links (virtual-circuit connection) between two

computers identified by their unique network adapter addresses.

 Control of frame flow by instructing the transmitting computer not to transmit frame
buffers.

 Sequential transmission and reception of frames.

 Providing and listening for frame acknowledgment, and detecting and recovering from
errors that occur in the physical layer by retransmitting non-acknowledged frames and
handling duplicate frame receipts.

 Management of media access to determine when the computer is permitted to use the
physical medium.

 Delimiting of frames to create and recognize frame boundaries.

 Error-checking of frames to confirm the integrity of the received frame.

  Inspection of the destination address of each received frame and determination of whether
the frame should be directed to the layer above.

Note

While the services of the data-link layer provide for reliable delivery of data, many routable protocol
suites such as TCP/IP and IPX/SPX do not provide for, nor utilize reliable data-link layer delivery
services. Instead, reliable data delivery is provided by protocols operating at the transport layer.

Network Layer

The network layer controls the operation of the subnet. It determines what physical path the data
takes based on the network conditions, the priority of service, and other factors.

The network layer provides the following functions:

 Transfer of frames to a router if the network address of the destination does not indicate the
network to which the computer is attached.

 Control of subnet traffic to allow an intermediate system to instruct a sending station not to
transmit its frames when the router's buffer fills up. If the router is busy, the network layer
can instruct the sending station to use an alternate router.

 Fragmentation of frames by a router when the size of a link to a downstream router's

maximum transmission unit (MTU) is smaller than the frame size. The frame fragments are
reassembled by the destination station.

 Resolution of the logical computer address (on the network layer) with the physical network
adapter address (on the data-link layer), if necessary.

The network layer at the transmitting computer must build its header in such a way that the network
layers of the subnet's intermediate systems can recognize the header and use it to route the data to
the destination address.

In the network layer and the layers below it, the peer protocols are between each computer and its
immediate neighbor, which is often not the ultimate destination. The source and destination
computers may be separated by many intermediate systems.

The network layer eliminates the need for higher layers to know anything about the data
transmission or intermediate switching technologies used to connect systems. The network layer is
responsible for establishing, maintaining, and terminating the connection to intermediate systems in
the communication subnet.

Transport Layer

The transport layer ensures that messages are delivered in the order in which they are sent and that
there is no loss or duplication.

The size and complexity of a transport protocol depends on the type of service available from the
network and data-link layers. For a reliable network layer or data-link layer with virtual-circuit
capability, such as the LLC layer of NetBEUI, the transport layer is required only to pass the data
through to the next layer. If the network layer or data-link layer is unreliable or supports only
datagrams, like the IP layer of TCP/IP and the IPX layer of IPX/SPX do, the transport layer includes
sequencing and acknowledgment, and associated error detection and recovery.

Functions of the transport layer include the following:

 Accepting messages from the layer above and, if necessary, splitting them into segments.

 Providing reliable, end-to-end message delivery with acknowledgments.

 Instructing the transmitting computer not to transmit when no reception buffers are
available.

 Multiplexing several process-to-process message streams or sessions onto one logical link
and tracking which messages belong to which sessions.

The transport layer can accept large messages, but there are strict size limits imposed by the layers
at the network level and lower. Consequently, the transport layer must break up the messages into
smaller units, called segments, and attach a header to each frame.

If the lower layers do not maintain sequence, the transport header must contain sequence
information, which enables the transport layer on the receiving end to present data in the correct
sequence to the next higher layer.

Unlike the lower layers that have protocols that are concerned with connecting to immediately
adjacent nodes or computers, the transport layer and the layers above it are true source-to-
destination layers, also known as end-to-end layers. These upper layers are not concerned with the
details of the underlying communications facility. Software for these layers communicates with
similar software on the destination computer by using message headers and control messages.

Session Layer

The session layer establishes a communications session between processes running on different
computers and can support message-mode data transfer.

Functions of the session layer include the following tasks:

 Permits application processes to register unique process addresses, such as NetBIOS names.
The session layer uses these stored addresses to help resolve the addresses of network
adapters from process addresses.

 Establishing, monitoring, and terminating a virtual-circuit session between two processes

identified by their unique process addresses. A virtual-circuit session is a direct link that
exists between the sender and receiver.

 Delimiting messages to add header information that indicates where a message starts and
ends. The receiving session layer can then refrain from indicating the presence of any
message data to the overlying application until the entire message is received.

 Performing message synchronization. Message synchronization is the coordination of the

data transfer between the sending session layer and the receiving session layer.
Synchronization prevents the receiving session layer from being overrun with data. This
transfer is coordinated with acknowledgement messages (ACKs). ACKs are sent back and
forth between both ends of the transfer and notify of the state of the receiving buffer to
accept additional data.
  Performing other support functions that allow processes to communicate over the network,
such as user authentication and resource-access security.

Presentation Layer

The presentation layer serves as the data translator for the network. This layer on the sending
computer translates the data sent by the application layer into a common format. At the receiving
computer, the presentation layer translates the common format to a format known to the
application layer.

The presentation layer provides the following functions:

 Character-code translation, such as from ASCII to EBCDIC.

 Data conversion, such as bit order reversal, CR to CR/LF, and integer to floating point.

 Data compression, which reduces the number of bits that need to be transmitted.

 Data encryption and decryption, which secures data for transmission across a potentially
insecure network. One use of encryption is for transmission of a password to a receiving
computer.

Application Layer

The application layer serves as the window for users and application processes to access network
services. The application layer provides the following functions:

 Resource sharing and device redirection

 Remote file access

 Remote printer access

 Interprocess communication support

 Remote procedure call support

 Network management

 Directory services

 Electronic messaging, including e-mail messaging

 Simulation of virtual terminals

Data Flow in the OSI Model

The OSI model presents a standard data flow architecture, with protocols specified in such a way
that the receiving layer at the destination computer receives exactly the same object as sent by the
matching layer at the source computer. Figure A.2 shows the OSI model data flow.

The sending process passes data to the application layer. The application layer attaches an
application header and then passes the frame to the presentation layer.

The presentation layer can transform data in various ways, if necessary, such as by translating it and
adding a header. It gives the result to the session layer. The presentation layer is not aware of which
portion (if any) of the data received from the application layer is the application header and which
portion is actually user data, because that information is irrelevant to the presentation layer's role.

The process of adding headers is repeated from layer to layer until the frame reaches the data link
layer. There, in addition to a data-link header, a data-link trailer is added. The data-link trailer
contains a checksum and padding if needed. This aids in frame synchronization. The frame is passed
down to the physical layer, where it is transmitted to the receiving computer.

On the receiving computer, the various headers and the data trailer are stripped off one by one as
the frame ascends the layers and finally reaches the receiving process.

Although the actual data transmission is vertical, each layer is programmed as if the transmission
were horizontal. For example, when a sending transport layer gets a message from the session layer,
it attaches a transport header and sends it to the receiving transport layer. The fact that the
message actually passes through the network layer on its own computer is unimportant.
Vertical Interface Terminology in the OSI Model

In addition to defining an idealized network architecture and the network functions allocated to
each layer, the OSI model also defines a standard set of rules that govern the interfaces between
layers.

The active protocol elements in each layer are called entities, typically implemented by means of a
software process. Entities in the same layer on different computers are called peer entities. For
example, the TCP/IP protocol suite contains two entities within its transport layer: Transmission
Control Protocol (TCP) and User Datagram Protocol (UDP).

Layer n-1 , the layer directly below the entities of layer n , implements services that are used by layer
n . For data transfer services, OSI defines the terminology for the discrete data components passed
across the interface and between peer entities. Figure A.3 illustrates vertical interface entities.

 The layer- n entity passes an interface data unit (IDU) to the layer-( n – 1) entity.

 The IDU consists of a protocol data unit (PDU) and some interface control information (ICI).
The ICI is information, such as the length of the SDU, and the addressing information that
the layer below needs to perform its function.

 The PDU is the data that the layer- n entity wishes to pass across the network to its peer
entity. It consists of the layer- n header and the data that layer n received from layer (n+1) .

 The layer- n PDU becomes the layer-( n – 1) service data unit (SDU), because it is the data
unit that will be serviced by layer n.

 When layer n – 1 receives the layer- n IDU, it strips off and "considers" the ICI, adds the
header information for its peer entity across the network, adds ICI for the layer below, and
passes the resulting IDU to the layer n – 2 entity.

Problems can occur in the data path between two network stations, including errant, restricted, or
even halted communication.
Resources:

- OSI Model - http://technet.microsoft.com/en-us/library/cc959881.aspx

- OSI Layers - http://technet.microsoft.com/en-us/library/cc977633.aspx
- Data Flow in the OSI Model - http://technet.microsoft.com/en-us/library/cc977591.aspx
- Vertical Interface Terminology in the OSI Model - http://technet.microsoft.com/en-
us/library/cc977591.aspx

Module 2 – Labs / Assessments

Module3: TCP/IP

Overview of TCP/IP

TCP/IP background

Transmission Control Protocol/Internet Protocol (TCP/IP) is an industry-standard suite of protocols

designed for large-scale internetworks that span LAN and WAN environments.

As the following timeline shows, the origins of TCP/IP began in 1969, when the U.S. Department of
Defense (DoD) commissioned the Advanced Research Projects Agency Network (ARPANET).

The ARPANET was the result of a resource-sharing experiment. The purpose was to provide high-
speed network communication links between various supercomputers located at various regional
sites within the United States.

Early protocols such as Telnet (for virtual terminal emulation) and File Transfer Protocol (FTP) were
first developed to specify basic utilities needed for sharing information across the ARPANET. As the
ARPANET grew in size and scope, two other important protocols appeared:

 In 1974, Transmission Control Protocol (TCP) was introduced as a draft specification that
described how to build a reliable, host-to-host data transfer service over a network.

 In 1981, Internet Protocol (IP) was introduced in draft form and described how to implement
an addressing standard and route packets between interconnected networks.

On January 1, 1983, ARPANET began to require standard use of the TCP and IP protocols for all
network traffic and essential communication. From this date forward, ARPANET started to become
more widely known as the Internet and its required protocols started to become more widely known
as the TCP/IP protocol suite.

The TCP/IP protocol suite is implemented in a variety of TCP/IP software offerings available for use
with many computing platforms. Today, TCP/IP software remains widely in use on the Internet and is
used often for building large routed private internetworks.

TCP/IP is:

 Networking software based on industry-standard networking protocols.

 A routable, enterprise networking protocol that supports the connection of your Microsoft®
Windows®-based computer to both LAN and WAN environments.

 Core technologies and utilities for connecting your Windows-based computer with dissimilar
systems and sharing information.

 A foundation for gaining access to global Internet services, such as the World Wide Web and
File Transfer Protocol (FTP) servers.
  A robust, scalable, cross-platform, client/server framework.

The TCP/IP Model:

The TCP/IP model

TCP/IP is based on a four-layer reference model. All protocols that belong to the TCP/IP protocol
suite are located in the top three layers of this model.

As shown in the following illustration, each layer of the TCP/IP model corresponds to one or more
layers of the seven-layer Open Systems Interconnection (OSI) reference model proposed by the
International Standards Organization (ISO).

The types of services performed and protocols used at each layer within the TCP/IP model are
described in more detail in the following table.

Layer Description Protocols

HTTP, Telnet, FTP, TFTP,

Defines TCP/IP application protocols and how host
SNMP, DNS, SMTP,
Application programs interface with transport layer services to use the
X Windows, other
network.
application protocols

Provides communication session management between

Transport host computers. Defines the level of service and status of TCP, UDP, RTP
the connection used when transporting data.

Packages data into IP datagrams, which contain source and

destination address information that is used to forward the
Internet IP, ICMP, ARP, RARP
datagrams between hosts and across networks. Performs
routing of IP datagrams.

Specifies details of how data is physically sent through the

network, including how bits are electrically signaled by Ethernet, Token Ring,
Network
hardware devices that interface directly with a network FDDI, X.25, Frame Relay,
interface
medium, such as coaxial cable, optical fiber, or twisted-pair RS-232, v.35
copper wire.
Note

 The OSI reference model is not specific to TCP/IP. It was developed by the ISO in the late
1970s as a framework for describing all functions required of an open interconnected
network. It is a widely known and accepted reference model in the data communications
field and is used here only for comparison purposes.

Core Protocols of TCP/IP

Address Resolution Protocol (ARP)

Address Resolution Protocol (ARP) is a required TCP/IP standard defined in RFC 826, "Address
Resolution Protocol (ARP)." ARP resolves IP addresses used by TCP/IP-based software to media
access control addresses used by LAN hardware. ARP provides the following protocol services to
hosts located on the same physical network:

 Media access control addresses are obtained by using a network broadcast request in the
form of the question "What is the media access control address for a device that is
configured with the enclosed IP address?"

 When an ARP request is answered, both the sender of the ARP reply and the original ARP
requester record each other's IP address and media access control address as an entry in a
local table called the ARP cache for future reference.

Hardware addressing

Hardware built for use on LANs must contain a unique address programmed into the device by the
manufacturer. For Ethernet and Token Ring LAN hardware, this address is known as a media access
control address.

Each media access control address identifies the device within its own physical network with a 6-
byte number programmed into read-only memory (ROM) on each physical hardware device, such as
a network adapter. Media access control addresses are typically displayed in hexadecimal (for
example, 00-AA-00-3F-89-4A).

Authority and registration of media access control addresses are overseen by the Institute of
Electrical and Electronics Engineers (IEEE). Currently, the IEEE registers and assigns unique numbers
for the first three bytes of the media access control address to individual manufacturers. Each
manufacturer can then assign the last three bytes of the media access control address to individual
network adapters.

How ARP resolves media access control addresses for local traffic

The following illustration shows how ARP resolves IP addresses to hardware addresses for hosts on
the same local network.
In this example, two TCP/IP hosts, Hosts A and B, are both located on the same physical network.
Host A is assigned the IP address of 10.0.0.99 and Host B is assigned the IP address of 10.0.0.100.

When Host A tries to communicate with Host B, the following steps resolve Host B's software-
assigned address (10.0.0.100) to Host B's hardware-assigned media access control address:

1. Based on the contents of the routing table on Host A, IP determines that the forwarding IP
address to be used to reach Host B is 10.0.0.100. Host A then checks its own local ARP cache
for a matching hardware address for Host B.

2. If Host A finds no mapping in the cache, it broadcasts an ARP request frame to all hosts on
the local network with the question "What is the hardware address for 10.0.0.100?" Both
hardware and software addresses for the source, Host A, are included in the ARP request.

Each host on the local network receives the ARP request and checks for a match to its own IP
address. If a host does not find a match, it discards the ARP request.

3. Host B determines that the IP address in the ARP request matches its own IP address and
adds a hardware/software address mapping for Host A to its local ARP cache.

4. Host B sends an ARP reply message containing its hardware address directly back to Host A.

5. When Host A receives the ARP reply message from Host B, it updates its ARP cache with a
hardware/software address mapping for Host B.

Once the media access control address for Host B has been determined, Host A can send IP traffic to
Host B by addressing it to Host B's media access control address.

How ARP resolves media access control addresses for remote traffic

ARP is also used to forward IP datagrams to local routers for destinations that are not on the local
network. In this situation, ARP resolves the media access control address of a router interface on the
local network.

The following illustration shows how ARP resolves IP addresses to hardware addresses for two hosts
on different physical networks connected by a common router.
In this example, Host A is assigned an IP address of 10.0.0.99 and Host B uses an IP address of
192.168.0.99. Router interface 1 is on the same physical network as Host A and uses the IP address
10.0.0.1. Router interface 2 is on the same physical network as Host B and uses the IP address
192.168.0.1.

When Host A tries to communicate with Host B, the following steps resolve Router interface 1's
software-assigned address (10.0.0.1) to its hardware-assigned media access control address:

1. Based on the contents of the routing table on Host A, IP determines that the forwarding IP
address to be used to reach host B is 10.0.0.1, the IP address of its default gateway. Host A
then checks its own local ARP cache for a matching hardware address for 10.0.0.1.

2. If Host A finds no mapping in the cache, it broadcasts an ARP request frame to all hosts on
the local network with the question "What is the hardware address for 10.0.0.1?" Both
hardware and software addresses for the source, Host A, are included in the ARP request.

Each host on the local network receives the ARP request and checks for a match to its own IP
address. If a host does not find a match, it discards the ARP request.

3. The router determines that the IP address in the ARP request matches its own IP address
and adds a hardware/software address mapping for Host A to its local ARP cache.

4. The router then sends an ARP reply message containing its hardware address directly back
to Host A.

5. When Host A receives the ARP reply message from the router, it updates its ARP cache with
a hardware/software address mapping for 10.0.0.1.

Once the media access control address for Router interface 1 has been determined, Host A can send
IP traffic to Router interface 1 by addressing it to the Router interface 1 media access control
address. The router then forwards the traffic to Host B through the same ARP process as discussed in
this section.

The ARP cache

To minimize the number of broadcasts, ARP maintains a cache of IP address-to-media access control
address mappings for future use. The ARP cache can contain both dynamic and static entries.
Dynamic entries are added and removed automatically over time. Static entries remain in the cache
until the computer is restarted.
Each dynamic ARP cache entry has a potential lifetime of 10 minutes. New entries added to the
cache are timestamped. If an entry is not reused within 2 minutes of being added, it expires and is
removed from the ARP cache. If an entry is used, it receives two more minutes of lifetime. If an entry
keeps getting used, it receives an additional two minutes of lifetime up to a maximum lifetime of
10 minutes.

You can view the ARP cache by using the arp command. To view the ARP cache, type arp -a at a
command prompt. To view arp command-line options, type arp /? at a command prompt.

Note

 There is a separate ARP cache for each network adapter.

Internet Protocol (IP)

IP is a required TCP/IP standard defined in RFC 791, "Internet Protocol (IP)." IP is a connectionless,
unreliable datagram protocol primarily responsible for addressing and routing packets between
hosts.

Connectionless means that a session is not established before exchanging data. Unreliable means
that delivery is not guaranteed. IP always makes a best-effort attempt to deliver a packet. An IP
packet might be lost, delivered out of sequence, duplicated, or delayed. IP does not attempt to
recover from these types of errors. The acknowledgment of packets delivered and the recovery of
lost packets is the responsibility of a higher-layer protocol, such as TCP.

An IP packet, also known as an IP datagram, consists of an IP header and an IP payload, as shown in

the following illustration.

The IP header contains the following fields for addressing and routing:

IP header
Function
field

Source IP
The IP address of the original source of the IP datagram.
address

Destination IP
The IP address of the final destination of the IP datagram.
address

Designates the number of network segments on which the datagram is allowed to

Time-to-Live travel before being discarded by a router. The TTL is set by the sending host and is
(TTL) used to prevent packets from endlessly circulating on an IP internetwork. When
forwarding an IP packet, routers are required to decrease the TTL by at least 1.
Internet Control Message Protocol (ICMP)

Internet Control Message Protocol (ICMP) is a required TCP/IP standard defined in RFC 792,
"Internet Control Message Protocol (ICMP)." With ICMP, hosts and routers that use IP
communication can report errors and exchange limited control and status information.

ICMP messages are usually sent automatically in one of the following situations:

 An IP datagram cannot reach its destination.

 An IP router (gateway) cannot forward datagrams at the current rate of transmission.

 An IP router redirects the sending host to use a better route to the destination.

ICMP messages are encapsulated and sent within IP datagrams, as shown in the following
illustration.

Different types of ICMP messages are identified in the ICMP header. Because ICMP messages are
carried in IP datagrams, they are unreliable.

The most common ICMP messages are listed and described in the following table.

ICMP message Description

Determines whether an IP node (a host or a router) is available on the

Echo request
network.

Echo reply Replies to an ICMP echo request.

Destination
Informs the host that a datagram cannot be delivered.
unreachable

Informs the host to lower the rate at which it sends datagrams because of
Source quench
congestion.

Redirect Informs the host of a preferred route.

Time exceeded Indicates that the Time-to-Live (TTL) of an IP datagram has expired.

You can use the ping command to send ICMP echo request messages and record the receipt of ICMP
echo reply messages. With these messages, you can detect network or host communication failures
and troubleshoot common TCP/IP connectivity problems.
Internet Group Management Protocol (IGMP)

The use of IP multicasting in TCP/IP networks is defined as a TCP/IP standard in RFC 1112, "Internet
Group Management Protocol (IGMP)." In addition to defining address and host extensions for how IP
hosts support multicasting, this RFC also defines the Internet Group Management Protocol (IGMP)
version 1. RFC 2236, "Internet Group Management Protocol (IGMP), version 2" defines IGMP
version 2. Both versions of IGMP provide a protocol to exchange and update information about host
membership in specific multicast groups. Additionally, the Windows Server 2003 family supports
IGMP version 3, described in the Internet draft entitled "Internet Group Management Protocol,
version 3." With IGMP version 3, hosts can specify interest in receiving multicast traffic from
specified sources or from all but a specific set of sources.

What is IP multicasting?

Multicast IP traffic is sent to a single address but is processed by multiple hosts. IP multicasting is
similar to a newsletter subscription. When only subscribers receive the newsletter when it is
published, only host computers that belong to the multicast group receive and process IP traffic sent
to the group's reserved IP address. The set of hosts listening on a specific IP multicast address is
called a multicast group.

Other important aspects of IP multicasting include the following:

 Group membership is dynamic, allowing hosts to join and leave the group at any time.

 The ability of hosts to join multicast groups is performed through the sending of IGMP
messages.

 Groups are not limited by size and members can be spread out across multiple IP networks
(if connecting routers support the propagation of IP multicast traffic and group membership
information).

 A host can send IP traffic to the group's IP address without belonging to the corresponding
group.

Multicast addressing

IP multicast addresses are reserved and assigned from within the Class D address range from
224.0.0.0 through 239.255.255.255. The following table is a partial list of well-known Class D
addresses that are reserved for IP multicasting and registered with the Internet Assigned Numbers
Authority (IANA).

IP multicast
Description
address

224.0.0.0 Base address (reserved).

The All Hosts multicast group that contains all systems on the same network
224.0.0.1
segment.

The All Routers multicast group that contains all routers on the same network
224.0.0.2
segment.
 The Open Shortest Path First (OSPF) AllSPFRouters address. Used to send OSPF
224.0.0.5
routing information to all OSPF routers on a network segment.

The OSPF AllDRouters address. Used to send OSPF routing information to OSPF
224.0.0.6
designated routers on a network segment.

The RIP Version 2 group address. Used to send RIP routing information to all RIP v2
224.0.0.9
routers on a network segment.

WINS server group address. Used to support autodiscovery and dynamic

224.0.1.24 configuration of replication for WINS servers. For more information, see WINS
replication overview.

For a full and current listing of additional IP addresses that are reserved for multicasting, see the
Internet Assigned Numbers Authority (IANA) Web site.

A single IP address within the Class D reserved range identifies each multicast group. Each group's
reserved IP address is shared by all host members of the group who listen and receive any IP
messages sent to the group's IP address.

IP multicast addresses are mapped to a reserved set of media access control multicast addresses.

IGMP messages

IGMP is used to exchange membership status information between IP routers that support
multicasting and members of multicast groups. Host membership in a multicast group is reported by
individual member hosts, and membership status is periodically polled by multicast routers.

IGMP message types are described in the following table.

IGMP message
Description
type

Sent when a host joins a multicast group to declare membership in a specific host
group. IGMP host membership report messages are also sent in response to an
Host IGMP host membership query sent by a router. For an IGMP version 3 host
membership membership report message, the host can specify interest in receiving multicast
report traffic from specified sources or from all but a specific set of sources. Source-
specific reporting prevents multicast-enabled routers from delivering multicast
traffic to a subnet where there are no listening hosts.

Host Used by a multicast router to periodically poll a network for group members. For
membership an IGMP version 3 host membership query message, the router can query the
query host's interest in receiving multicast traffic from a specified list of sources.

Sent by a host when they leave a host group and are the last member of that group
Leave group
on the network segment.
IGMP messages are encapsulated and sent within IP datagrams as shown in the following
illustration.

User Datagram Protocol (UDP)

User Datagram Protocol (UDP) is a TCP/IP standard defined in RFC 768, "User Datagram Protocol
(UDP)." UDP is used by some programs instead of TCP for fast, lightweight, unreliable transportation
of data between TCP/IP hosts.

UDP provides a connectionless datagram service that offers best-effort delivery, which means that
UDP does not guarantee delivery or verify sequencing for any datagrams. A source host that needs
reliable communication must use either TCP or a program that provides its own sequencing and
acknowledgment services.

UDP messages are encapsulated and sent within IP datagrams, as shown in the following illustration.

UDP ports

UDP ports provide a location for sending and receiving UDP messages. A UDP port functions as a
single message queue for receiving all datagrams intended for the program specified by each
protocol port number. This means UDP-based programs can receive more than one message at a
time.

The server side of each program that uses UDP listens for messages arriving on their well-known
port number. All UDP server port numbers less than 1,024 (and some higher numbers) are reserved
and registered by the Internet Assigned Numbers Authority (IANA).

Each UDP server port is identified by a reserved or well-known port number. The following table
shows a partial list of well-known UDP server port numbers that are used by standard UDP-based
programs.
UDP port number Description

53 DNS name queries

69 Trivial File Transfer Protocol (TFTP)

137 NetBIOS name service

138 NetBIOS datagram service

161 Simple Network Management Protocol (SNMP)

520 Routing Information Protocol (RIP)

UDP and TCP

In general, differences in how UDP and TCP deliver data are similar to the differences between a
telephone call and a postcard. TCP works like a telephone call by verifying that the destination is
available and ready to communicate. UDP works like a postcard--messages are small and delivery is
likely, but not always assured.

UDP is typically used by programs that transmit small amounts of data at one time or have real-time
requirements. In these situations, the low overhead and multicasting capabilities of UDP (for
example, one datagram, many recipients) are better suited than TCP.

UDP contrasts directly with the services and features provided by TCP. The following table compares
differences in how TCP/IP communication is handled depending on whether UDP or TCP is used for
transporting data.

UDP TCP

Connectionless service; no session is established Connection-oriented service; a session is

between hosts. established between hosts.

TCP guarantees delivery through the use of

UDP does not guarantee or acknowledge delivery,
acknowledgments and sequenced delivery of
or sequence data.
data.

Programs that use UDP are responsible for Programs that use TCP are provided assurance
providing any reliability needed to transport data. of reliable data transport.

UDP is fast, has low overhead requirements, and TCP is slower, has higher overhead
can support point-to-point and point-to-multipoint requirements, and only supports point-to-
communication. point communication.

Both UDP and TCP use ports to identify communications for each TCP/IP program.
Transmission Control Protocol (TCP)

Transmission Control Protocol (TCP) is a required TCP/IP standard defined in RFC 793, "Transmission
Control Protocol (TCP)," that provides a reliable, connection-oriented packet delivery service. The
Transmission Control Protocol:

 Guarantees delivery of IP datagrams.

 Performs segmentation and reassembly of large blocks of data sent by programs.

 Ensures proper sequencing and ordered delivery of segmented data.

 Performs checks on the integrity of transmitted data by using checksum calculations.

 Sends positive messages depending on whether data was received successfully. By using
selective acknowledgments, negative acknowledgments for data not received are also sent.

 Offers a preferred method of transport for programs that must use reliable session-based
data transmission, such as client/server database and e-mail programs.

How TCP works

TCP is based on point-to-point communication between two network hosts. TCP receives data from
programs and processes this data as a stream of bytes. Bytes are grouped into segments that TCP
then numbers and sequences for delivery.

Before two TCP hosts can exchange data, they must first establish a session with each other. A TCP
session is initialized through a process known as a three-way handshake. This process synchronizes
sequence numbers and provides control information that is needed to establish a virtual connection
between both hosts.

Once the initial three-way handshake completes, segments are sent and acknowledged in a
sequential manner between both the sending and receiving hosts. A similar handshake process is
used by TCP before closing a connection to verify that both hosts are finished sending and receiving
all data.

TCP segments are encapsulated and sent within IP datagrams, as shown in the following illustration.

TCP ports

TCP ports use a specific program port for delivery of data sent by using Transmission Control
Protocol (TCP). TCP ports are more complex and operate differently from UDP ports.

While a UDP port operates as a single message queue and the network endpoint for UDP-based
communication, the final endpoint for all TCP communication is a unique connection. Each TCP
connection is uniquely identified by dual endpoints.
Each single TCP server port is capable of offering shared access to multiple connections because all
TCP connections are uniquely identified by two pairs of IP address and TCP ports (one address/port
pairing for each connected host).

TCP programs use reserved or well-known port numbers, as shown in the following illustration.

The server side of each program that uses TCP ports listens for messages arriving on their well-
known port number. All TCP server port numbers less than 1,024 (and some higher numbers) are
reserved and registered by the Internet Assigned Numbers Authority (IANA).

The following table is a partial list of some well-known TCP server ports used by standard TCP-based
programs.

TCP port number Description

20 FTP server (data channel)

21 FTP server (control channel)

23 Telnet server

53 Domain Name System zone transfers

80 Web server (HTTP)

139 NetBIOS session service

Security features

TCP/IP incorporates security features that provide protection of the TCP/IP data as it is sent on the
network and configuration of the types of local host traffic that are processed.

Internet Protocol security

Internet Protocol security (IPSec) is a set of Internet standards that uses cryptographic security
services to provide the following:

 Confidentiality

IPSec traffic is encrypted. Captured IPSec traffic is unintelligible without knowledge of the
encryption key.
  Authentication

IPSec traffic is digitally signed with the shared encryption key so that the receiver can verify
that it was sent by the IPSec peer.

 Data integrity

IPSec traffic contains a cryptographic checksum that incorporates the encryption key. The
receiver can verify that the packet was not modified in transit.

TCP/IP filtering

With TCP/IP filtering, a feature known as TCP/IP Security in Microsoft® Windows NT® 4.0, you can
specify exactly which types of incoming TCP/IP traffic are processed for each IP interface. This
feature is designed to isolate the traffic that is processed by Internet or intranet servers in the
absence of other TCP/IP filtering provided by the Routing and Remote Access service or other TCP/IP
programs or services. TCP/IP filtering is disabled by default.

TCP/IP filtering is a set of filters for inbound local host TCP/IP traffic. Local host traffic is traffic that is
processed by the host because the destination IP address of inbound TCP/IP traffic is addressed to
an assigned interface addresses, appropriate subnet broadcast addresses, or a multicast address.
TCP/IP filtering does not apply to routed traffic that is forwarded between interfaces.

With TCP/IP filtering, you can confine local host inbound TCP/IP traffic based on the:

 Destination TCP port

 Destination UDP port

 IP protocol
IP Addressing and Routing

IP addressing

Each TCP/IP host is identified by a logical IP address. This address is unique for each host that
communicates by using TCP/IP. Each 32-bit IP address identifies a location of a host system on the
network in the same way that a street address identifies a house on a city street.

Just as a street address has a standard two-part format (a street name and a house number), each IP
address is separated internally into two parts--a network ID and a host ID:

 The network ID, also known as a network address, identifies a single network segment
within a larger TCP/IP internetwork (a network of networks). All the systems that attach and
share access to the same network have a common network ID within their full IP address.
This ID is also used to uniquely identify each network within the larger internetwork.

 The host ID, also known as a host address, identifies a TCP/IP node (a workstation, server,
router, or other TCP/IP device) within each network. The host ID for each device identifies a
single system uniquely within its own network.

Here is an example of a 32-bit IP address:

10000011 01101011 00010000 11001000

To make IP addressing easier, IP addresses are expressed in dotted decimal notation. The 32-bit IP
address is segmented into four 8-bit octets. The octets are converted to decimal (base-10 numbering
system) and separated by periods. Therefore, the previous IP address example is 131.107.16.200
when converted to dotted decimal notation.

The following illustration shows a sample view of an IP address (131.107.16.200) as it is divided into
network and host ID sections. The network ID portion (131.107) is indicated by the first two numbers
of the IP address. The host ID portion (16.200) is indicated by the last two numbers of the IP address.

Notes

 Because IP addresses identify devices on a network, a unique IP address must be assigned to

each device on the network.

 In general, most computers have only a single network adapter installed and therefore
require only a single IP address. If a computer has multiple network adapters installed, each
adapter needs its own IP address.
IP address classes

The Internet community has defined five address classes. Class A, B, and C addresses are used for
assignment to TCP/IP nodes.

The class of address defines which bits are used for the network and host ID parts of each address.
The address class also defines how many networks and hosts per network can be supported.

The following table uses w.x.y.z to designate the four octet values in any given IP address. The table
is used to show:

 How the value of the first octet (w) of any given IP address effectively indicates the class of
address.

 How the octets in an address are divided into network ID and host ID.

 The number of possible networks and hosts per network available for each class.

Value of Host Number of Number of hosts per

Class Network ID
w ID networks network

A 1-126 w x.y.z 126 16,777,214

B 128-191 w.x y.z 16,384 65,534

C 192-223 w.x.y z 2,097,152 254

Reserved for multicast

D 224-239 N/A N/A N/A
addressing

Reserved for experimental

E 240-254 N/A N/A N/A
use

Subnet masks

Network IDs and host IDs within an IP address are distinguished by using a subnet mask. Each subnet
mask is a 32-bit number that uses consecutive bit groups of all ones (1) to identify the network ID
and all zeroes (0) to identify the host ID portions of an IP address.

For example, the subnet mask normally used with the IP address 131.107.16.200 is the following 32-
bit binary number:

11111111 11111111 00000000 00000000

This subnet mask number is 16 one-bits followed by 16 zero-bits, indicating that the network ID and
host ID sections of this IP address are both 16 bits in length. Normally, this subnet mask is displayed
in dotted decimal notation as 255.255.0.0.

The following table displays subnet masks for the Internet address classes.
Address class Bits for subnet mask Subnet mask

Class A 11111111 0000 0000 00000000 00000000 255.0.0.0

Class B 11111111 11111111 00000000 00000000 255.255.0.0

Class C 11111111 11111111 11111111 00000000 255.255.255.0

Typically, default subnet mask values (as shown in the previous table) are acceptable for most
networks with no special requirements and where each IP network segment corresponds to a single
physical network.

In some cases, you can use customized subnet masks to implement IP subnetting. With IP
subnetting, you can subdivide the default host ID portion of an IP address to specify subnets, which
are subdivisions of the original class-based network ID.

By customizing the subnet mask length, you can reduce the number of bits that are used for the
actual host ID.

Important

 To prevent addressing and routing problems, you should make sure all TCP/IP computers on
any network segment use the same subnet mask.

IP routing

In general terms, routing is the process of forwarding packets between connected networks. For
TCP/IP-based networks, routing is part of Internet Protocol (IP) and is used in combination with
other network protocol services to provide forwarding capabilities between hosts that are located
on separate network segments within a larger TCP/IP-based network.

IP is the mailroom of the TCP/IP protocol, where IP data sorting and delivery take place. Each
incoming or outgoing packet is called an IP datagram. An IP datagram contains two IP addresses: the
source address of the sending host and the destination address of the receiving host. Unlike
hardware addresses, the IP addresses within a datagram remain the same as it travels across a
TCP/IP network.

Routing is the primary function of IP. IP datagrams are exchanged and processed on each host by
using IP at the Internet layer.

Above the IP layer, transport services on the source host pass data in the form of TCP segments or
UDP messages to the IP layer. The IP layer assembles IP datagrams with source and destination
address information that is used to route the data through the network. The IP layer then passes
datagrams down to the network interface layer. At this layer, data-link services convert IP datagrams
into frames for transmission over network-specific media on a physical network. This process
happens in reverse order on the destination host.

Each IP datagram contains a source and destination IP address. IP layer services on each host
examine the destination address of each datagram, compare this address to a locally maintained
routing table, and then decide what further forwarding action to take. IP routers are attached to two
or more IP network segments that are enabled to forward packets between them. The following
sections discuss IP routers and the use of routing tables in further detail.
IP Routers

TCP/IP network segments are interconnected by IP routers, which are devices that pass IP datagrams
from one network segment to another. This process is known as IP routing and is shown in the
following illustration.

IP routers provide the primary means of joining together two or more physically separated IP
network segments. All IP routers share two essential characteristics:

 IP routers are multihomed hosts.

A multihomed host is a network host that uses two or more network connection interfaces
to connect to each physically separated network segment.

 IP routers provide packet forwarding for other TCP/IP hosts.

IP routers are distinct from other hosts that use multihoming in one important way: an IP
router must be able to forward IP-based communication between networks for other IP
network hosts.

You can implement IP routers by using a variety of possible hardware and software products. Box-
based routers--dedicated hardware devices that run specialized software--are common. In addition,
you can use routing solutions that are based on software, such as the Routing and Remote Access
service.

Regardless of the type of IP routers that you use, all IP routing relies on the use of a routing table to
communicate between network segments.

Routing tables

TCP/IP hosts use a routing table to maintain knowledge about other IP networks and IP hosts.
Networks and hosts are identified by using an IP address and a subnet mask. In addition, routing
tables are important because they provide needed information to each local host regarding how to
communicate with remote networks and hosts.
For each computer on an IP network, you can maintain a routing table with an entry for every other
computer or network that communicates with the local computer. In general, this is not practical,
and a default gateway (IP router) is used instead.

When a computer prepares to send an IP datagram, it inserts its own source IP address and the
destination IP address of the recipient into the IP header. The computer then examines the
destination IP address, compares it to a locally maintained IP routing table, and takes appropriate
action based on what it finds. The computer does one of three things:

 It passes the datagram up to a protocol layer above IP on the local host.

 It forwards the datagram through one of its attached network interfaces.

 It discards the datagram.

IP searches the routing table for the route that is the closest match to the destination IP address.
The most specific to the least specific route is searched for in the following order:

 A route that matches the destination IP address (host route).

 A route that matches the network ID of the destination IP address (network route).

 The default route.

If a matching route is not found, IP discards the datagram.

The IP routing table

Every computer that runs TCP/IP makes routing decisions. These decisions are controlled by the IP
routing table. To display the IP routing table on computers running Windows Server 2003 operating
systems, you can type route print at a command prompt.

The following table shows an example of an IP routing table. This example is for a computer running
Windows Server 2003, Standard Edition with one 10 megabit/second (Mbit/s) network adapter and
the following configuration:

 IP address: 10.0.0.169

 Subnet mask: 255.0.0.0

 Default gateway: 10.0.0.1

Description Network destination Netmask Gateway Interface Metric

Default route 0.0.0.0 0.0.0.0 10.0.0.1 10.0.0.169 30

Loopback network 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1

Local network 10.0.0.0 255.0.0.0 10.0.0.169 10.0.0.169 30

Local IP address 10.0.0.169 255.255.255.255 127.0.0.1 127.0.0.1 30

Multicast addresses 224.0.0.0 240.0.0.0 10.0.0.169 10.0.0.169 30

Limited broadcast address 255.255.255.255 255.255.255.255 10.0.0.169 10.0.0.169 1

Note

 The descriptions in the first column of the preceding table are not actually displayed in the
output of the route print command.

The routing table is built automatically, based on the current TCP/IP configuration of your computer.
Each route occupies a single line in the displayed table. Your computer searches the routing table for
an entry that most closely matches the destination IP address.

Your computer uses the default route if no other host or network route matches the destination
address included in an IP datagram. The default route typically forwards an IP datagram (for which
there is no matching or explicit local route) to a default gateway address for a router on the local
subnet. In the previous example, the default route forwards the datagram to a router with a
gateway address of 10.0.0.1.

Because the router that corresponds to the default gateway contains information about the network
IDs of the other IP subnets within the larger TCP/IP internet, it forwards the datagram to other
routers until the datagram is eventually delivered to an IP router that is connected to the specified
destination host or subnet within the larger network.

The following sections describe each of the columns displayed in the IP routing table: network
destination, netmask, gateway, interface, and metric.

Network destination

The network destination is used with the netmask to match the destination IP address. The network
destination can range from 0.0.0.0 for the default route through 255.255.255.255 for the limited
broadcast, which is a special broadcast address to all hosts on the same network segment.

Netmask

The netmask is the subnet mask that is applied to the destination IP address when matching it to the
value in the network destination. When netmask is written in binary, a "1" must match and a "0"
need not match. For example, a default route uses a 0.0.0.0 netmask that translates to the binary
value 0.0.0.0, so bits need not match. A host route--a route that matches an IP address--uses a
255.255.255.255 netmask that translates to the binary value
11111111.11111111.11111111.11111111, so all of the bits must match.

Gateway

The gateway address is the IP address that the local host uses to forward IP datagrams to other IP
networks. This is either the IP address of a local network adapter or the IP address of an IP router
(such as a default gateway router) on the local network segment.

Interface

The interface is the IP address that is configured on the local computer for the local network adapter
that is used when an IP datagram is forwarded on the network.

Metric

A metric indicates the cost of using a route, which is typically the number of hops to the IP
destination. Anything on the local subnet is one hop, and each router crossed after that is an
additional hop. If there are multiple routes to the same destination with different metrics, the route
with the lowest metric is selected.

Multihomed hosts

The following shows the default routing table for a multihomed Windows Server 2003, Standard
Edition host with this configuration:

 Network adapter 1 (10 MB)

o IP address: 10.0.0.169

o Subnet mask: 255.0.0.0

o Default gateway: 10.0.0.1

 Network adapter 2 (100 MB)

o IP address: 192.168.0.200

o Subnet mask: 255.255.0.0

o Default gateway: 192.168.0.1

Network
Adapter Description Netmask Gateway Interface Metric
destination

1 Default route 0.0.0.0 0.0.0.0 10.0.0.1 10.0.0.169 20

2 Default route 0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.200 30

Loopback
1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
network

1 Local network 10.0.0.0 255.0.0.0 10.0.0.169 10.0.0.169 20

Local IP
1 10.0.0.169 255.255.255.255 127.0.0.1 127.0.0.1 20
address

2 Local network 192.168.0.0 255.255.0.0 192.168.0.200 192.168.0.200 30

Local IP
2 192.168.0.200 255.255.255.255 127.0.0.1 127.0.0.1 30
address

Subnet
2 192.168.0.255 255.255.255.255 192.168.0.200 192.168.0.200 30
broadcast

Multicast
1 224.0.0.0 240.0.0.0 10.0.0.169 10.0.0.169 20
address

Multicast
2 224.0.0.0 240.0.0.0 192.168.0.200 192.168.0.200 30
address
 Limited
1 255.255.255.255 255.255.255.255 10.0.0.169 10.0.0.169 1
broadcast

Limited
2 255.255.255.255 255.255.255.255 192.168.0.200 192.168.0.200 1
broadcast

Note

 The descriptions in the first and second columns of the preceding table are not actually
displayed in the output of the route print command.

Notes

 When you configure a default gateway on each network adapter, you create a 0.0.0.0 route
for each network adapter. However, only one default route is actually used. In the previous
example, the 10.0.0.169 IP address is the first network adapter in the TCP/IP bindings, and
therefore the default route for Network adapter 1 is used. Because only one default gateway
is used, you only need to configure one network adapter with a default gateway. This
reduces confusion and assures the results you intended.

 If the IP router is a server running Windows Server 2003 and does not have an interface on a
given network, it needs a route to get to that network. You can add static routes or use
routing protocols that are provided by the Routing and Remote Access service.

TCP/IP utilities

To assist with the management of TCP/IP, there are three types of TCP/IP-based utilities:

 Connectivity utilities that you can use to interact with and use resources on a variety of
Microsoft® and non-Microsoft hosts, such as UNIX systems.

 Diagnostic utilities that you can use to detect and resolve networking problems.

 TCP/IP server software that provides printing and publishing services to TCP/IP-based
Microsoft Windows® clients.

The following tables describe the TCP/IP-based utilities.

Connectivity utilities

Utility Description

Transfers files of any size between computers running Windows Server 2003 operating
Ftp
systems and any computer running File Transfer protocol (FTP) server software.

Sends print jobs to remote UNIX printers managed by Line Printer Daemon (LPD) print
Lpr
server software.

Copies files between computers running Windows Server 2003 operating systems and
Rcp
computers running Remote Copy protocol (RCP) server software.

Rexec Executes processes on remote computers.

Rsh Runs commands on a computer running Remote Shell (RSH) server software.

Uses terminal-based login to remotely access network devices that are running Telnet
Telnet
server software.

Transfers small files between computers running Windows Server 2003 operating systems
Tftp
and computers running Trivial File Transfer protocol (TFTP) server software.

Diagnostic utilities

Utility Description

Displays and modifies the Address Resolution protocol (ARP) cache. This cache is a local
Arp table used to resolve IP addresses to media access control addresses used on the local
network.

Hostname Returns the host name of the local computer.

Displays the current TCP/IP configuration. Also used to manually release and renew
Ipconfig
TCP/IP configurations assigned by a DHCP server.

Obtains print queue status information from computers running Line Printer Daemon
Lpq
(LPD) print server software.

Displays the local NetBIOS name table, a table of NetBIOS names registered by local
Nbtstat programs, and the NetBIOS name cache, a local cache listing of NetBIOS computer
names that have been resolved to IP addresses.

Displays and administers TCP/IP protocol settings on the local computer or a remote
Netsh
computer.

Netstat Displays TCP/IP protocol session information.

Checks records, domain host aliases, domain host services, and operating system
Nslookup
information by querying DNS servers.

Ping Verifies configurations and tests IP connectivity.

Route Displays or modifies the local routing table.

Tracert Traces the route a packet takes to a destination.

Traces the route a packet takes to a destination and displays information on packet
Pathping losses for each router in the path. Pathping can also be used to troubleshoot Quality of
Service (QoS) connectivity.
IP Subnetting

A Class A, B, or C TCP/IP network can be further divided, or subnetted, by a system administrator.

This becomes necessary as you reconcile the logical address scheme of the Internet (the abstract
world of IP addresses and subnets) with the physical networks in use by the real world.

A system administrator who is allocated a block of IP addresses may be administering networks that
are not organized in a way that easily fits these addresses. For example, you have a wide area
network with 150 hosts on three networks (in different cities) that are connected by a TCP/IP router.
Each of these three networks has 50 hosts. You are allocated the class C network 192.168.123.0. (For
illustration, this address is actually from a range that is not allocated on the Internet.) This means
that you can use the addresses 192.168.123.1 to 192.168.123.254 for your 150 hosts.

Two addresses that cannot be used in your example are 192.168.123.0 and 192.168.123.255
because binary addresses with a host portion of all ones and all zeros are invalid. The zero address is
invalid because it is used to specify a network without specifying a host. The 255 address (in binary
notation, a host address of all ones) is used to broadcast a message to every host on a network. Just
remember that the first and last address in any network or subnet cannot be assigned to any
individual host.

You should now be able to give IP addresses to 254 hosts. This works fine if all 150 computers are on
a single network. However, your 150 computers are on three separate physical networks. Instead of
requesting more address blocks for each network, you divide your network into subnets that enable
you to use one block of addresses on multiple physical networks.

In this case, you divide your network into four subnets by using a subnet mask that makes the
network address larger and the possible range of host addresses smaller. In other words, you are
'borrowing' some of the bits usually used for the host address, and using them for the network
portion of the address. The subnet mask 255.255.255.192 gives you four networks of 62 hosts each.
This works because in binary notation, 255.255.255.192 is the same as
1111111.11111111.1111111.11000000. The first two digits of the last octet become network
addresses, so you get the additional networks 00000000 (0), 01000000 (64), 10000000 (128) and
11000000 (192). (Some administrators will only use two of the subnetworks using 255.255.255.192
as a subnet mask. For more information on this topic, see RFC 1878.) In these four networks, the last
6 binary digits can be used for host addresses.

Using a subnet mask of 255.255.255.192, your 192.168.123.0 network then becomes the four
networks 192.168.123.0, 192.168.123.64, 192.168.123.128 and 192.168.123.192. These four
networks would have as valid host addresses:

192.168.123.1-62

192.168.123.65-126

192.168.123.129-190

192.168.123.193-254
Remember, again, that binary host addresses with all ones or all zeros are invalid, so you cannot use
addresses with the last octet of 0, 63, 64, 127, 128, 191, 192, or 255.

You can see how this works by looking at two host addresses, 192.168.123.71 and 192.168.123.133.
If you used the default Class C subnet mask of 255.255.255.0, both addresses are on the
192.168.123.0 network. However, if you use the subnet mask of 255.255.255.192, they are on
different networks; 192.168.123.71 is on the 192.168.123.64 network, 192.168.123.133 is on the
192.168.123.128 network.

Example:

First, let's do some review.

11111111 11111111 11111111 11111111 Binary

255 255 255 255 Decimal

1st octet 2nd octet 3rd octet 4th octet Octets

4 octets separated by periods, each octet with 8 binary numbers.

An octet breaks down like this: 11111111. To convert it to a decimal, you must work from right to
left, so the first number in the octet from the right is equal to 1, the second is 2, the third is 4, the
fourth is 8, the fifth is 16, the sixth is 32, the seventh is 64, and the eighth, the one on the far left, is
128. So you will have 128-64-32-16-8-4-2-1 as the decimal equivalent to an octet. If you were to add
all these numbers together, they would equal 255.

To begin, get two sheets of paper, including one for practice. (I recommend that you do not use a
calculator. It will really help you to do the math on your scratch paper.) After you try this method a
couple of times, one piece of paper will suffice.

Set up 6 columns with 8 rows (example below).

Beginning Range of
Subnet # of # of hosts per # of hosts per # of hosts per
Network IDs for
mask Subnets subnet Class - C subnet Class - B subnet Class - A
Subnets

128--Invalid Invalid Invalid Invalid Invalid Invalid

64 2

32

16

2 Invalid

1 .255 Invalid
  Row 1 in all columns is invalid, so mark it out.

 Take one octet's decimal numbers, 128-64-32-16-8-4-2-1, and place them in the first column
from high to low. This will now be our beginning range of network IDs for the subnets.

 Take the highest subnet mask number (.255) and place it at the bottom of the subnet mask
column.

 Take the first subnet value, 2, and place it in our first valid subnet location.

 In the Class C column, rows 7 and 8 are invalid. Mark them as such.

We're finished with the hard part; the rest is simple math.

Let's begin with the first two columns. To figure the subnet mask, take the number from the range
column (column 1), and subtract it from the number in the subnet mask column (column 2). Place
the answer in the next row above, and continue until all rows in the subnet mask column are filled.

Example:

255 1= 254, 254 2=252, 252 4= 248, 248 8=240, 240 16= 224, 224 32= 192

Beginning Range of Network IDs for Subnets Subnet mask Math from above Example

128-- Invalid Invalid

64 .192

32 .224 224 – 32 = 192

16 .240 240 – 16 = 224

8 .248 248 - 8 = 240

4 .252 252 - 4 = 248

2 .254 254 - 2 = 252

1 .255 255 - 1 = 254 carry up

You have just figured out your subnet mask.

Now let's work with column 3, the number of subnets per subnet mask. From our chart, we know
that we have 2 subnets next to subnet mask (.192), so that's where we start. Take the number of
subnets times 2, plus 2, and put that answer in the next row down under subnets. Continue until all
rows are filled.
Example:

2x2=4+2=6 6x2=12+2=14 14x2=28+2=30 30x2=60+2=62 62x2=124+2=126 126X2=252+2=254

# of Subnets Math from above example

Invalid Invalid

2 (2x2) +2 = 6 carry down

6 (6x2) +2 = 14

14 (14x2) +2 = 30

30 (30x2) +2 = 62

62 (62x2) +2 = 126

126 (126x2) +2 = 254

254

You have just figured out the number of subnets per subnet mask.

Your table should look like this.

Beginning Range of
Subnets # of # of hosts per # of hosts per # of hosts per
Network IDs for
Mask Subnets subnet Class - C subnet Class - B subnet Class - A
Subnets

128 -- Invalid Invalid Invalid Invalid Invalid Invalid

64 .192 2

32 .224 6

16 .240 14

8 .248 30

4 .252 62

2 .254 126 Invalid

1 .255 254 Invalid

Now we know the number of subnets we can have per subnet mask, and the starting range of that
subnet.

For example, if I have a Class B address with anywhere from 7 to 14 subnets needed, I know I must
use 255.255.240.0 as my subnet mask. I also know my range for subnets will begin at 16, and jump
by 16's (see example).
Subnet Beginning value Ending value

Subnet 1 w.x.16.1 w.x.31.254

Subnet 2 w.x.32.1 w.x.47.254

Subnet 3 w.x.48.1 w.x.63.254

And so on. You would go by 16's until all 14 subnets are set up.

Subnet 14 w.x.224.1 w.x.239.254

To figure out the number of hosts per subnet for Class C addresses, take the number of subnets in
column 3 on your table, and turn them upside down. List them in the valid areas of Class C. Start at
the bottom-most valid area and go up.

Example:

# of hosts per subnet Class – C

Invalid

62

30

14

Invalid

Invalid

That's the number of hosts per subnet in Class C.

Now to go to Class B.

We take 62 (the highest number of hosts we can have in Class C) and multiply it by 4, (the total
number of octets). Then add 6 (the total number of ranges open above the range we are figuring).
This gives us the smallest number of hosts per subnet for a Class B address.

Example: 62 x 4 = 248 + 6 = 254, so 254 is the smallest number we can have in a Class B address.

Put that number at the bottom of your Class B Table. To move up the table from there, we will take
that number times 2, and add 2 to get to the next range.

254 x 2 = 508 + 2 = 510

510 x 2 = 1020 + 2 = 1022

1022 x 2 = 2044 + 2 = 4094
4094 x 2 = 8188 + 2 = 8190
8190 x 2 = 16,380 + 2 = 16,382

# of hosts per subnet Class –

B

Invalid

16,382 (16382 x 4) + 6 = 65,534 (start of Class A)

8190 (8190 x 2) + 2 = 6,382

4094 (4094 x 2) + 2 = 8,190

2046 (2046 x 2) + 2 = 4,094

1022 (1022x2) + 2 = 2,046

510 (510x2) + 2 = 1,022

254 (254x2) + 2 = 510

That's Class B hosts per subnet.

Now we move to Class A.

Take 16,382 x 4 + 6 = 65,534. This is the starting host for Class A, and we go back to the times-2-plus-
2 formula.

# of hosts per subnet Class –

A

Invalid

4,194,302

2,097,150 (2,097,150 x 2) + 2 = 4,194,302

1,048,574 (1,048,574 x 2) + 2 = 2,097,150

524,286 (524,286 x 2) + 2 = 1,048,574

262,142 (262,142 x 2) + 2 = 524,286

131,070 (131,070 x 2)+2 = 262,142

65,534 (65,534 x 2) + 2 = 131,070

Now your subnet mask table should look like this.

Beginning Range of
Subnets # of # of hosts per # of hosts per # of hosts per
Network ID's for
Mask Subnets subnet Class - C subnet Class - B subnet Class - A
Subnets

128 -- Invalid Invalid Invalid Invalid Invalid Invalid

64 .192 2 62 16,382 4,194,302

32 .224 6 30 8,190 2,097,150

16 .240 14 14 4,094 1,048,574

8 .248 30 6 2,046 524,286

4 .252 62 2 1,022 262,142

2 .254 126 Invalid 510 131,070

1 .255 254 Invalid 254 65,534

In a nutshell:

Take one octet and list its decimal numbers down in order. Make the top row of each column invalid
and make the bottom 2 rows of Class C column invalid. Insert .255 at the bottom of the subnet mask
column. Insert 2 at the top of the number of subnets column at the first valid spot.

To figure out the subnet mask column, subtract the number in the range column from the number in
the subnet mask column. This will give you the next subnet mask number. Then you subtract the
number in the range column on its same line from that number to get the next subnet mask number,
and so on.

To figure out the number of subnets, multiply the starting number (2) by 2 and add 2 to get the next
subnet number. Then multiply that number by 2 and add 2 to get the next subnet number. And so
on.

To get the number of hosts, invert the subnet table onto the Class C column starting at the bottom
from low to high in the first valid location.

To jump to Class B, take the highest host number (62) from Class C and multiply it times 4 (the
number of octets). Then add 6 (the number of open ranges above the number you're on): 62 x 4 =
248 + 6 = 254. Take that number and put it at the bottom of Class B, the smallest number of hosts.
To move up the table in Class B, take the number times 2. Add 2 to get the next higher number, and
so on until you reach the top.

To jump to Class A, take the highest number from Class B times 4 and add 6. This will give you the
bottom of Class A: 16,382 x 4 = 65,528 + 6 = 65,534. Then multiply that number times 2, add 2 to
move up the table, then the next number times 2, and add 2 for the next number, and so on.
References:

http://technet.microsoft.com/en-us/library/cc737682(v=ws.10).aspx - The TCP/IP Overview

http://technet.microsoft.com/en-us/library/cc786900(v=WS.10).aspx - The TCP/IP Model

http://technet.microsoft.com/en-us/library/cc751234.aspx - TCP/IP Architecture

http://technet.microsoft.com/en-us/library/cc750854.aspx - TCP/IP from a Security Viewpoint

http://technet.microsoft.com/en-us/library/cc751236.aspx - TCP/IP Subnetting: Creating the 8-bit

Subnetting Table for Class A, B, and C Networks

http://technet.microsoft.com/en-us/library/cc784576(v=ws.10).aspx - Understanding TCP/IP

http://technet.microsoft.com/en-us/library/cc779172(v=ws.10).aspx - TCP/IP Concepts

http://support.microsoft.com/kb/164015 - Understanding TCP/IP addressing and subnetting basics

http://technet.microsoft.com/en-us/library/cc737968(v=ws.10).aspx – TCP/IP RFCs

http://technet.microsoft.com/en-us/library/cc759184(v=ws.10).aspx – TCP/IP Diagnostic Utilities

http://technet.microsoft.com/en-us/library/cc757819(v=ws.10).aspx – TCP/IP Command-line utilities

Module3: Labs/Assessments
Module4: Domain Naming System/Server (DNS)

What is DNS?

Domain Name System (DNS) is one of the industry-standard suite of protocols that comprise TCP/IP.
Microsoft Windows Server 2003. DNS is implemented using two software components: the DNS
server and the DNS client (or resolver). Both components are run as background service applications.

Network resources are identified by numeric IP addresses, but these IP addresses are difficult for
network users to remember. The DNS database contains records that map user-friendly
alphanumeric names for network resources to the IP address used by those resources for
communication. In this way, DNS acts as a mnemonic device, making network resources easier to
remember for network users.

DNS is part of the application layer of the TCP/IP reference model.

DNS in TCP/IP

DNS Architecture

DNS architecture is a hierarchical distributed database and an associated set of protocols that
define:

 A mechanism for querying and updating the database.

 A mechanism for replicating the information in the database among servers.

 A schema of the database.

DNS originated in the early days of the Internet when the Internet was a small network established
by the United States Department of Defense for research purposes. The host names of the
computers in this network were managed through the use of a single HOSTS file located on a
centrally administered server. Each site that needed to resolve host names on the network
downloaded this file. As the number of hosts on the Internet grew, the traffic generated by the
update process increased, as well as the size of the HOSTS file. The need for a new system, which
would offer features such as scalability, decentralized administration, support for various data types,
became more and more obvious.

The Domain Name System introduced in 1984 became this new system. With DNS, the host names
reside in a database that can be distributed among multiple servers, decreasing the load on any one
server and providing the ability to administer this naming system on a per-partition basis. DNS
supports hierarchical names and allows registration of various data types in addition to host name to
IP address mapping used in HOSTS files. Because the DNS database is distributed, its potential size is
unlimited and performance is not degraded when more servers are added.

The original DNS was based on Request for Comment (RFC) 882 (“Domain Names: Concepts and
Facilities”) and RFC 883 (Domain Names–Implementation and Specification), which were superseded
by RFC 1034 (“Domain Names–Concepts and Facilities”), and RFC 1035 (“Domain Names–
Implementation and Specification”). Additional RFCs that describe DNS security, implementation,
and administrative issues later augmented the original design specifications.

The implementation of DNS — Berkeley Internet Name Domain (BIND) — was originally developed
for the 4.3 BSD UNIX Operating System. The Microsoft implementation of DNS became a part of the
operating system in Microsoft Windows NT Server 4.0. The Windows NT 4.0 DNS server, like most
DNS implementations, has its roots in RFCs 1034 and 1035.

DNS Domain Names

The Domain Name System is implemented as a hierarchical and distributed database containing
various types of data, including host names and domain names. The names in a DNS database form a
hierarchical tree structure called the domain namespace. Domain names consist of individual labels
separated by dots, for example: mydomain.microsoft.com.

A Fully Qualified Domain Name (FQDN) uniquely identifies the hosts position within the DNS
hierarchical tree by specifying a list of names separated by dots in the path from the referenced host
to the root. The next figure shows an example of a DNS tree with a host called mydomain within the
microsoft.com. domain. The FQDN for the host would be mydomain.microsoft.com.

Understanding the DNS Domain Namespace

The DNS domain namespace, as shown in the following figure, is based on the concept of a tree of
named domains. Each level of the tree can represent either a branch or a leaf of the tree. A branch is
a level where more than one name is used to identify a collection of named resources. A leaf
represents a single name used once at that level to indicate a specific resource.

DNS Domain Name Hierarchy

The previous figure shows how Microsoft is assigned authority by the Internet root servers for its
own part of the DNS domain namespace tree on the Internet. DNS clients and servers use queries as
the fundamental method of resolving names in the tree to specific types of resource information.
This information is provided by DNS servers in query responses to DNS clients, who then extract the
information and pass it to a requesting program for resolving the queried name. In the process of
resolving a name, keep in mind that DNS servers often function as DNS clients, querying other
servers in order to fully resolve a queried name.

How the DNS Domain Namespace Is Organized

Any DNS domain name used in the tree is technically a domain. Most DNS discussions, however,
identify names in one of five ways, based on the level and the way a name is commonly used. For
example, the DNS domain name registered to Microsoft (microsoft.com.) is known as a second-level
domain. This is because the name has two parts (known as labels) that indicate it is located two
levels below the root or top of the tree. Most DNS domain names have two or more labels, each of
which indicates a new level in the tree. Periods are used in names to separate labels.

The five categories used to describe DNS domain names by their function in the namespace are
described in the following table, along with an example of each name type.

Types of DNS Domain Names

Name Type Description Example

This is the top of the tree, representing an

unnamed level; it is sometimes shown as two
empty quotation marks (""), indicating a null
value. When used in a DNS domain name, it is
stated by a trailing period (.) to designate that A single period (.) or a period used at
Root
the name is located at the root or highest level the end of a name, such as
domain
of the domain hierarchy. In this instance, the “example.microsoft.com.”
DNS domain name is considered to be
complete and points to an exact location in the
tree of names. Names stated this way are called
fully qualified domain names (FQDNs).

““.com”, which indicates a name

Top level A name used to indicate a country/region or
registered to a business for
domain the type of organization using a name.
commercial use on the Internet.

Variable-length names registered to an

individual or organization for use on the ““microsoft.com. ”, which is the
Second
Internet. These names are always based upon second-level domain name
level
an appropriate top-level domain, depending on registered to Microsoft by the
domain
the type of organization or geographic location Internet DNS domain name registrar.
where a name is used.

Additional names that an organization can

Subdomain create that are derived from the registered ““example.microsoft.com. ”, which is
a fictitious subdomain assigned by
second-level domain name. These include
 names added to grow the DNS tree of names in Microsoft for use in documentation
an organization and divide it into departments example names.
or geographic locations.

Names that represent a leaf in the DNS tree of

names and identify a specific resource.
““host-a.example.microsoft.com.”,
Host or Typically, the leftmost label of a DNS domain
where the first label (“host-a”) is the
resource name identifies a specific computer on the
DNS host name for a specific
name network. For example, if a name at this level is
computer on the network.
used in a host (A) RR, it is used to look up the IP
address of computer based on its host name.

DNS and Internet Domains

The Internet Domain Name System is managed by a Name Registration Authority on the Internet,
responsible for maintaining top-level domains that are assigned by organization and by
country/region. These domain names follow the International Standard 3166. Some of the many
existing abbreviations, reserved for use by organizations, as well as two-letter and three-letter
abbreviations used for countries/regions are shown in the following table:

Some DNS Top-level Domain Names (TLDs)

DNS Domain Name Type of Organization

com Commercial organizations

edu Educational institutions

org Non-profit organizations

net Networks (the backbone of the Internet)

gov Non-military government organizations

mil Military government organizations

arpa Reverse DNS

“xx” Two-letter country code (i.e. us, au, ca, fr)

Resource Records

A DNS database consists of resource records (RRs). Each RR identifies a particular resource within
the database. There are various types of RRs in DNS. This section provides information about the
common structure of resource records. RRs are discussed in greater detail in “Resource Records in
DNS” later in this document.

The following table provides detailed information about structure of common RRs.
Common DNS Resource Records

Description Class Time To Live (TTL) Type Data

Owner Name

Primary Name Server DNS

Name, Serial Number
Start of Internet Refresh Interval
Default TTL is 60 minutes SOA
Authority (IN)
Retry Interval

Expire Time

Minimum TTL

Internet Record-specific TTL if present, Owner Name (Host DNS Name)

Host A
(IN) or else zone (SOA) TTL Host IP Address

Internet Record-specific TTL if present, Owner Name

Name Server NS
(IN) or else zone (SOA) TTL Name Server DNS Name

Owner Name
Mail Internet Record-specific TTL if present,
MX Mail Exchange Server DNS
Exchanger (IN) or else zone (SOA) TTL
Name, Preference Number

Canonical
Internet Record-specific TTL if present, Owner Name (Alias Name)
Name CNAME
(IN) or else zone (SOA) TTL Host DNS Name
(an alias)

Distributing the DNS Database: Zone Files and Delegation

A DNS database can be partitioned into multiple zones. A zone is a portion of the DNS database that
contains the resource records with the owner names that belong to the contiguous portion of the
DNS namespace. Zone files are maintained on DNS servers. A single DNS server can be configured to
host zero, one or multiple zones.

Each zone is anchored at a specific domain name referred to as the zone’s root domain. A zone
contains information about all names that end with the zone’s root domain name. A DNS server is
considered authoritative for a name if it loads the zone containing that name. The first record in any
zone file is a Start of Authority (SOA) RR. The SOA RR identifies a primary DNS name server for the
zone as the best source of information for the data within that zone and as an entity processing the
updates for the zone.

A name within a zone can also be delegated to a different zone that is hosted on a different DNS
server. Delegation is a process of assigning responsibility for a portion of a DNS namespace to a DNS
server owned by a separate entity. This separate entity could be another organization, department
or workgroup within your company. Such delegation is represented by the NS resource record that
specifies the delegated zone and the DNS name of the server authoritative for that zone. Delegating
across multiple zones was part of the original design goal of DNS.

The primary reasons to delegate a DNS namespace include:

 A need to delegate management of a DNS domain to a number of organizations or

departments within an organization.

 A need to distribute the load of maintaining one large DNS database among multiple DNS
servers to improve the name resolution performance as well as create a DNS fault tolerant
environment.

 A need to allow for a host’s organizational affiliation by including them in appropriate

domains.

The name server (NS) RRs facilitate delegation by identifying DNS servers for each zone and the NS
RRs appear in all zones. Whenever a DNS server needs to cross a delegation in order to resolve a
name, it will refer to the NS RRs for DNS servers in the target zone.

In the figure below, the management of the microsoft.com. domain is delegated across two zones,
microsoft.com. and mydomain.microsoft.com.

DNS Delegation

Note

 If multiple NS records exist for a delegated zone identifying multiple DNS servers available
for querying, the Windows Server 2003 DNS Server service will be able to select the closest
DNS server based on the round trip intervals measured over time for every DNS server.
Replicating the DNS Database

There could be multiple zones representing the same portion of the namespace. Among these zones
there are three types:

 Primary

 Secondary

 Stub

Primary is a zone to which all updates for the records that belong to that zone are made. A
secondary zone is a read-only copy of the primary zone. A stub zone is a read-only copy of the
primary zone that contains only the resource records that identify the DNS servers that are
authoritative for a DNS domain name. Any changes made to the primary zone file are replicated to
the secondary zone file. DNS servers hosting a primary, secondary or stub zone are said to be
authoritative for the DNS names in the zone.

As mentioned above, a DNS server can host multiple zones. A DNS server can therefore host both a
primary zone (which has the writeable copy of a zone file) and a separate secondary zone (which
obtains a read-only copy of a zone file). A DNS server hosting a primary zone is said to be the primary
DNS server for that zone, and a DNS server hosting a secondary zone is said to be the secondary DNS
server for that zone.

Note

 A secondary or stub zone cannot be hosted on a DNS server that hosts a primary zone for
the same domain name.

Zone Transfer

The process of replicating a zone file to multiple DNS servers is called zone transfer.Zone transfer is
achieved by copying the zone file from one DNS server to a second DNS server. Zone transfers can be
made from both primary and secondary DNS servers.

A master DNS server is the source of the zone information during a transfer. The master DNS server
can be a primary or secondary DNS server. If the master DNS server is a primary DNS server, then the
zone transfer comes directly from the DNS server hosting the primary zone. If the master server is a
secondary DNS server, then the zone file received from the master DNS server by means of a zone
transfer is a copy of the read-only secondary zone file.

The zone transfer is initiated in one of the following ways:

 The master DNS server sends a notification (RFC 1996) to one or more secondary DNS
servers of a change in the zone file.

 When the DNS Server service on the secondary DNS server starts, or the refresh interval of
the zone has expired (by default it is set to 15 minutes in the SOA RR of the zone), the
secondary DNS server will query the master DNS server for the changes.

Types of Zone File Replication

There are two types of zone file replication. The first, a full zone transfer (AXFR), replicates the entire
zone file. The second, an incremental zone transfer (IXFR), replicates only records that have been
modified. Zone transfer is discussed in detail later in this document.
BIND 4.9.3 and earlier DNS server software, as well as Windows NT 4.0 DNS, support full zone
transfer (AXFR) only. There are two types of the AXFR: one requires single record per packet, the
other allows multiple records per packet. The Windows 2000 and Windows Server 2003 DNS Server
service supports both types of zone transfer, but by default uses multiple records per packet. It can
be configured differently for compatibility with servers that do not allow multiple records per
packet, such as BIND servers versions 4.9.4 and earlier.

Querying the Database

DNS queries can be sent from a DNS client (resolver) to a DNS server, or between two DNS servers.

A DNS query is merely a request for DNS resource records of a specified resource record type with a
specified DNS name. For example, a DNS query can request all resource records of type A (host) with
a specified DNS name.

There are two types of DNS queries that may be sent to a DNS server:

 Recursive

 Iterative

A recursivequery forces a DNS server to respond to a request with either a failure or a successful
response. DNS clients (resolvers) typically make recursive queries. With a recursive query, the DNS
server must contact any other DNS servers it needs to resolve the request. When it receives a
successful response from the other DNS server(s), it then sends a response to the DNS client. The
recursive query is the typical query type used by a resolver querying a DNS server and by a DNS
server querying its forwarder, which is another DNS server configured to handle requests forwarded
to it. For more information about forwarders, see “Forwarding” later in this document.

When a DNS server processes a recursive query and the query cannot be resolved from local data
(local zone files or cache of previous queries), the recursive query must be escalated to a root DNS
server. Each standards-based implementation of DNS includes a cache file (or root server hints) that
contains entries for the root DNS servers of the Internet domains. (If the DNS server is configured
with a forwarder, the forwarder is used before a root server is used.)

An iterative query is one in which the DNS server is expected to respond with the best local
information it has, based on what the DNS server knows from local zone files or from caching. This
response is also known as a referral if the DNS server is not authoritative for the name. If a DNS
server does not have any local information that can answer the query, it simply sends a negative
response. A DNS server makes this type of query as it tries to find names outside of its local
domain(s) (when it is not configured with a forwarder). It may have to query a number of outside
DNS servers in an attempt to resolve the name.

The following figure shows an example of both types of queries.

DNS Query Types

As shown in the graphic above, a number of queries were used to determine the IP address for
www.whitehouse.gov. The query sequence is described below:

1. Recursive query for www.whitehouse.gov (A resource record)

2. Iterative query for www.whitehouse.gov (A resource record)

3. Referral to the .gov name server (NS resource records, for .gov); for simplicity, iterative A
queries by the DNS server (on the left) to resolve the IP addresses of the Host names of the
name server’s returned by other DNS servers have been omitted.

4. Iterative query for www.whitehouse.gov (A resource record)

5. Referral to the whitehouse.gov name server (NS resource record, for whitehouse.gov)

6. Iterative query for www.whitehouse.gov (A resource record)

7. Answer to the interative query from whitehouse.gov server (www.whitehouse.gov’s IP

address)

8. Answer to the original recursive query from local DNS server to Resolver
(www.whitehouse.gov’s IP address)

Time to Live for Resource Records

The Time to Live (TTL) value in a resource record indicates a length of time used by other DNS
servers to determine how long to cache information for a record before expiring and discarding it.
For example, most resource records created by the DNS Server service inherit the minimum (default)
TTL of one hour from the start of authority (SOA) resource record, which prevents extended caching
by other DNS servers.

A DNS client resolver caches the responses it receives when it resolves DNS queries. These cached
responses can then be used to answer later queries for the same information. The cached data,
however, has a limited lifetime specified in the TTL parameter returned with the response data. TTL
ensures that the DNS server does not keep information for so long that it becomes out of date. TTL
for the cache can be set on the DNS database (for each individual resource record, by specifying the
TTL field of the record and per zone through the minimum TTL field of the SOA record) as well as on
the DNS client resolver side by specifying the maximum TTL the resolver allows to cache the
resource records.

There are two competing factors to consider when setting the TTL. The first is the accuracy of the
cached information, and the second is the utilization of the DNS servers and the amount of network
traffic. If the TTL is short, then the likelihood of having old information is reduced considerably, but it
increases utilization of DNS servers and network traffic, because the DNS client must query DNS
servers for the expired data the next time it is requested. If the TTL is long, the cached responses
could become outdated, meaning the resolver could give false answers to queries. At the same time,
a long TTL decreases utilization of DNS servers and reduces network traffic because the DNS client
answers queries using its cached data.

If a query is answered with an entry from cache, the TTL of the entry is also passed with the
response. This way the resolvers that receive the response know how long the entry is valid. The
resolvers honor the TTL from the responding server; they do not reset it based on their own TTL.
Consequently, entries truly expire rather than live in perpetuity as they move from DNS server to
DNS server with an updated TTL.

Note

 In general, never configure the TTL to zero. The different between a setting of 0 or 60 is
minimal to the accuracy of the record, but when the TTL is set to 0 there is a major impact
on DNS server performance because the DNS server is constantly querying for the expired
data.

Updating the DNS Database

Since the resource records in the zone files are subjected to changes, they must be updated. The
implementation of DNS in Windows 2000 and Windows Server 2003 supports both static and
dynamic updates of the DNS database. The details of the dynamic update are discussed later in this
document.

Root Hints

Root hints are used to prepare servers authoritative for non-root zones so that they can learn and
discover authoritative servers that manage domains located at a higher level or in other subtrees of
the DNS domain namespace. These hints are essential for servers authoritative at lower levels of the
namespace when locating and finding servers under these conditions.

For example, suppose a DNS server (Server A) has a zone called sub.example.microsoft.com. In the
process of answering a query for a higher-level domain, such as the example.microsoft.com domain,
Server A needs some assistance to locate an authoritative server (such as Server B) for this domain.

In order for Server A to find Server B, or any other servers that are authoritative for the
microsoft.com domain, it needs to be able to query the root servers for the DNS namespace. The
root servers can then refer Server A to the authoritative servers for the com domain. The servers for
the com domain can, in turn, offer referral to Server B or other servers that are authoritative for the
microsoft.com domain.

The root hints used by Server A must have helpful hints to the root servers for this process to locate
Server B (or another authoritative server) as intended.
To configure and use root hints correctly, first determine how the following applies to your DNS
servers:

 Are you using DNS on the Internet or on a private network?

 Is the server used as a root server?

By default, the DNS Server service implements root hints using a file, Cache.dns, stored in the
systemroot\System32\Dns folder on the server computer. This file normally contains the NS and A
resource records for the Internet root servers. If, however, you are using the DNS Server service on a
private network, you can edit or replace this file with similar records that point to your own internal
root DNS servers.

Another server configuration in which root hints are treated differently is one in which a DNS server
is configured to be used by other DNS servers in an internal namespace as a forwarder for any DNS
queries of names managed externally (the Internet, for example). Even though the DNS server used
as a forwarder can be located internally on the same network as servers using it as a forwarder, it
needs hints for the Internet root servers to work properly and resolve external names.

Note

 If you are operating internal root servers, do not use root hints. Instead, delete the
Cache.dns file entirely for any of your root servers.

Common DNS Resource Record Types

Description: Host address (A) resource record. Maps a DNS domain name to an Internet Protocol
(IP) version 4 32-bit address. For more information, see RFC 1035.

Syntax::

owner class ttl A IP_v4_address

Example:

host1.example.microsoft.com. IN A 127.0.0.1

AAAA

Description: IPv6 host address (AAAA) resource record. Maps a DNS domain name to an Internet
Protocol (IP) version 6 128-bit address. For more information, see RFC 1886.

Syntax: owner class ttl AAAA IP_v6_address

Example:

ipv6_host1.example.microsoft.com. IN AAAA 4321:0:1:2:3:4:567:89ab

CNAME

Description: Canonical name (CNAME) resource record. Maps an aliased or alternate DNS domain
name in the owner field to a canonical or primary DNS domain name specified in the
canonical_name field. The canonical or primary DNS domain name used in the data is required and
must resolve to a valid DNS domain name in the namespace.

Syntax: owner ttl class CNAME canonical_name

Example:

aliasname.example.microsoft.com. CNAME truename.example.microsoft.com.

MX

Description: Mail exchanger (MX) resource record. Provides message routing to a mail exchanger
host, as specified in mail_exchanger_host, for mail sent to the domain name specified in the owner
field. A 2-digit preference value indicates preferred ordering if multiple exchanger hosts are
specified. Each exchanger host must have a corresponding host (A) address resource record in a
valid zone. For more information, see RFC 1035.

Syntax: owner ttl class MX preference mail_exchanger_host

Example:

example.microsoft.com. MX 10 mailserver1.example.microsoft.com

NS

Description: Used to map a DNS domain name as specified in owner to the name of hosts
operating DNS servers specified in the name_server_domain_name field.

Syntax: owner ttl IN NS name_server_domain_name

Example:

example.microsoft.com. IN NS nameserver1.example.microsoft.com

PTR

Description: Pointer (PTR) resource record. Points from the name in owner to another location in
the DNS namespace as specified by targeted_domain_name. Often used in special domains such as
the in-addr.arpa domain tree to provide reverse lookups of address-to-name mappings. In most
cases, each record provides information that points to another DNS domain name location, such as
a corresponding host (A) address resource record in a forward lookup zone. For more information,
see RFC 1035.

Syntax: owner ttl class PTR targeted_domain_name

Example:

1.0.0.10.in-addr.arpa. PTR host.example.microsoft.com.

SOA

Description: Start of authority (SOA) resource record. Indicates the name of origin for the zone and
contains the name of the server that is the primary source for information about the zone. It also
indicates other basic properties of the zone. The SOA resource record is always first in any standard
zone. It indicates the DNS server that either originally created it or is now the primary server for the
zone. It is also used to store other properties such as version information and timings that affect
zone renewal or expiration. These properties affect how often transfers of the zone are done
between servers authoritative for the zone.

In the example below, the owner (primary DNS server) is specified as “@” because the domain
name is the same as the origin of all data in the zone (example.microsoft.com.). This is a standard
notation convention for resource records and is most often seen in the SOA record.

Syntax:

owner class SOA name_server responsible_person (serial_number refresh_interval retry_interval

expiration minimum_time_to_live)

Example:

@ IN SOA nameserver.example.microsoft.com.

postmaster.example.microsoft.com. (

1 ; serial number

3600 ; refresh [1h]

600 ; retry [10m]

86400 ; expire [1d]

3600 ) ; min TTL [1h]

SRV

Description: Service locator (SRV) resource record. Allows multiple servers providing a similar
TCP/IP-based service to be located using a single DNS query operation. This record enables you to
maintain a list of servers for a well-known server port and transport protocol type ordered by
preference for a DNS domain name. For example, in Windows Server 2003 DNS, it provides the
means to locate domain controllers that use Lightweight Directory Access Protocol (LDAP) service
over TCP port 389.

The purposes of each of the specialized fields used in an SRV resource record are as follows:

service A symbolic name for the desired service. For well-known services, a reserved universal
symbolic name such as “_telnet” or “_smtp” is defined in RFC 1700. If a well-known service name is
not defined in RFC 1700, a local or user-preferred name can be used instead. Some widely used
TCP/IP services, notably the Post Office Protocol (POP), do not have a single universal symbolic
name. If RFC 1700 assigns a name for a service indicated in this field, the RFC-defined name is the
only name that is legal to use. Only locally defined services can be named locally.
protocol Indicates the transport protocol type. Typically, this is either TCP or UDP, although any
transport protocol named in RFC 1700 can be used.

name The DNS domain name referred to by this resource record. The SRV resource record is unique
among other DNS record types in that it is not used to perform the search or query.

priority Sets the preference for a host specified in the target field. DNS clients that query for SRV
resource records attempt to contact the first reachable host of the lowest numbered preference
listed here. Although target hosts have the same stated preference value, they can be tried in
random order. The range of preference values is 0 to 65535.

weight Can be used in addition to preference to provide a load-balancing mechanism where

multiple servers are specified in the target field and are all set to the same level of preference.
When selecting a target server host among those of equal preference, this value can be used to set
an added level of preference that can be used to determine the exact order or balancing of
selection for the target hosts used in an answered SRV query. When a non-zero value is used,
servers of equal preference are tried in proportion to the weight of this value. The range of values is
1 to 65535. If load balancing is not needed, use a value of 0 in this field to make the record easier to
read.

port The server port on the target host that provides the service indicated in the service field. The
range of port numbers is 0 to 65535, although the number is often a well-known assigned service
port number, as specified in RFC 1700. Unassigned ports can be used as needed.

target Specifies the DNS domain name of the host that provides the type of service being
requested. For each host name used, a corresponding host address (A) resource record in the DNS
namespace is required. A single period (.) can be used in this field to indicate authoritatively that
the requested service specified in this SRV resource record is not available at this DNS domain
name.

For more information, see the Internet draft “A DNS RR for specifying the location of services (DNS
SRV).”

Syntax: service.protocol.name ttl class SRV preference weight port target

Example:

_ldap._tcp._msdcs SRV 0 0 389 dc1.example.microsoft.com

SRV 10 0 389 dc2.example.microsoft.com

TXT

Description: Text (TXT) resource record. Maps a DNS domain name specified in the owner field to a
string of characters in text_string serving as descriptive text. For more information, see RFC 1035.

Syntax:

owner ttl class TXT text_string

Example:

example.microsoft.com. TXT “This is an example of additional domain name information.”

WKS

Description: Well-known service (WKS) resource record. Describes the well-known TCP/IP services
supported by a particular protocol on a specific IP address. WKS records provide TCP and UDP
availability information for TCP/IP servers. If a server either supports both TCP and UDP for a well-
known service or has multiple IP addresses that support a service, then multiple WKS records are
used. For more information, see RFC 1035.

Syntax:

owner ttl class WKS address protocol service_list

Example:

example.microsoft.com. WKS 10.0.0.1 TCP ( telnet smtp ftp )

Tools

Nslookup.exe: Nslookup

Category

This tool is included in all Microsoft Windows server and client operating systems.

Version compatibility

This tool runs on all Windows server and client operating systems.

Nslookup is used to query DNS servers and to obtain detailed responses. The information obtained
using Nslookup can be used to diagnose and solve name resolution problems, verify that resource
records are added or updated correctly in a zone, and debug other server-related problems.

References:

http://technet.microsoft.com/en-us/library/cc787921(v=ws.10).aspx – What is DNS?

http://technet.microsoft.com/en-us/library/cc772774(v=ws.10).aspx – How DNS Works

http://technet.microsoft.com/en-us/library/cc775464(v=ws.10).aspx – DNS Tools and Settings

http://technet.microsoft.com/en-us/library/cc725925.aspx - Install a DNS Server in Windows Server

2008 R2

http://technet.microsoft.com/en-us/library/cc771031.aspx - Configure a new DNS Server

Module4 – Labs /Assessments:

1. Install and Configure a DNS Server in the lab

2. Use nslookup to query a few common records
3. Add different kind of records in the DNS and query them using nslookup
Module5: Dynamic Host Configuration Protocol (DHCP)

What is DHCP?

Dynamic Host Configuration Protocol (DHCP) is a client/server protocol that automatically provides
an Internet Protocol (IP) host with its IP address and other related configuration information such as
the subnet mask and default gateway. RFCs 2131 and 2132 define DHCP as an Internet Engineering
Task Force (IETF) standard based on Bootstrap Protocol (BOOTP), a protocol with which DHCP shares
many implementation details. DHCP allows hosts to obtain necessary TCP/IP configuration
information from a DHCP server.

Benefits of DHCP

The DHCP Server service provides the following benefits:

 Reliable IP address configuration. DHCP minimizes configuration errors caused by manual IP

address configuration, such as typographical errors, or address conflicts caused by the
assignment of an IP address to more than one computer at the same time.

 Reduced network administration. DHCP includes the following features to reduce network
administration:

o Centralized and automated TCP/IP configuration.

o The ability to define TCP/IP configurations from a central location.

o The ability to assign a full range of additional TCP/IP configuration values by means
of DHCP options.

o The efficient handling of IP address changes for clients that must be updated
frequently, such as those for portable computers that move to different locations on
a wireless network.

o The forwarding of initial DHCP messages by using a DHCP relay agent, thus
eliminating the need to have a DHCP server on every subnet.

Why use DHCP

Every device on a TCP/IP-based network must have a unique unicast IP address to access the
network and its resources. Without DHCP, IP addresses must be configured manually for new
computers or computers that are moved from one subnet to another, and manually reclaimed for
computers that are removed from the network.

DHCP enables this entire process to be automated and managed centrally. The DHCP server
maintains a pool of IP addresses and leases an address to any DHCP-enabled client when it starts up
on the network. Because the IP addresses are dynamic (leased) rather than static (permanently
assigned), addresses no longer in use are automatically returned to the pool for reallocation.

The network administrator establishes DHCP servers that maintain TCP/IP configuration information
and provide address configuration to DHCP-enabled clients in the form of a lease offer. The DHCP
server stores the configuration information in a database, which includes:

 Valid TCP/IP configuration parameters for all clients on the network.

  Valid IP addresses, maintained in a pool for assignment to clients, as well as excluded
addresses.

 Reserved IP addresses associated with particular DHCP clients. This allows consistent
assignment of a single IP address to a single DHCP client.

 The lease duration, or the length of time for which the IP address can be used before a lease
renewal is required.

A DHCP-enabled client, upon accepting a lease offer, receives:

 A valid IP address for the subnet to which it is connecting.

 Requested DHCP options, which are additional parameters that a DHCP server is configured
to assign to clients. Some examples of DHCP options are Router (default gateway), DNS
Servers, and DNS Domain Name.

Terms and Definitions

The following table lists common terms associated with DHCP.

DHCP Terms and Definitions

Term Definition

A computer running the DHCP Server service that holds information about
DHCP server available IP addresses and related configuration information as defined by
the DHCP administrator and responds to requests from DHCP clients.

DHCP client A computer that gets its IP configuration information by using DHCP.

A range of IP addresses that are available to be leased to DHCP clients by

Scope
the DHCP Server service.

The process of partitioning a single TCP/IP network into a number of

Subnetting
separate network segments called subnets.

Configuration parameters that a DHCP server assigns to clients. Most DHCP

options are predefined, based on optional parameters defined in Request
DHCP option
for Comments (RFC) 2132, although extended options can be added by
vendors or users.

An additional set of options that can be provided to a DHCP client based on

its computer class membership. The administrator can use option classes
Option class to submanage option values provided to DHCP clients. There are two types
of options classes supported by a DHCP server running Windows
Server 2003: vendor classes and user classes.

The length of time for which a DHCP client can use a DHCP-assigned IP
Lease
address configuration.

Reservation A specific IP address within a scope permanently set aside for leased use by
a specific DHCP client. Client reservations are made in the DHCP database
 using the DHCP snap-in and are based on a unique client device identifier
for each reserved entry.

One or more IP addresses within a DHCP scope that are not allocated by
Exclusion/exclusion the DHCP Server service. Exclusions ensure that the specified IP addresses
range will not be offered to clients by the DHCP server as part of the general
address pool.

Either a host or an IP router that listens for DHCP client messages being
broadcast on a subnet and then forwards those DHCP messages directly to
a configured DHCP server. The DHCP server sends DHCP response
DHCP relay agent messages directly back to the DHCP relay agent, which then forwards them
to the DHCP client. The DHCP administrator uses DHCP relay agents to
centralize DHCP servers, avoiding the need for a DHCP server on each
subnet. Also referred to as a BOOTP relay agent.

A DHCP server that has not explicitly been authorized. Sometimes referred
to as a rogue DHCP server.

In a Windows Server 2003 domain environment, the DHCP Server service

on an unauthorized server running Windows Server 2003 fails to initialize.
Unauthorized DHCP The administrator must explicitly authorize all DHCP servers running
server Windows Server 2003 that operate in an Active Directory service domain
environment. At initialization time, the DHCP Server service in Windows
Server 2003 checks for authorization and stops itself if the server detects
that it is in a domain environment and the server has not been explicitly
authorized.

A TCP/IP feature in Windows XP and Windows Server 2003 that

automatically configures a unique IP address from the range 169.254.0.1
through 169.254.255.254 with a subnet mask of 255.255.0.0 when the
Automatic Private IP TCP/IP protocol is configured for automatic addressing, the Automatic
Addressing (APIPA) private IP address alternate configuration setting is selected, and a DHCP
server is not available. The APIPA range of IP addresses is reserved by the
Internet Assigned Numbers Authority (IANA) for use on a single subnet, and
IP addresses within this range are not used on the Internet.

A configuration that allows a DHCP server to provide leases from more

Superscope
than one scope to clients on a single physical network segment.

Multicast IP addresses allow multiple clients to receive data that is sent to

a single IP address, enabling point-to-multipoint communication. This type
Multicast IP addresses
of transmission is often used for streaming media transmissions, such as
video conferencing.

A range of multicast IP addresses that can be assigned to DHCP clients. A

Multicast Scope multicast scope allows dynamic allocation of multicast IP addresses for use
on the network by using the MADCAP protocol, as defined in RFC 2730.
 An older protocol with similar functionality; DHCP is based on BOOTP.
BOOTP is an established protocol standard used for configuring IP hosts.
BOOTP was originally designed to enable boot configuration for diskless
BOOTP
workstations. Most DHCP servers, including those running Windows
Server 2003, can be configured to respond to both BOOTP requests and
DHCP requests.

How DHCP Works

DHCP provides an automated way to distribute and update IP addresses and other configuration
information on a network. A DHCP server provides this information to a DHCP client through the
exchange of a series of messages, known as the DHCP conversation or the DHCP transaction. If the
DHCP server and DHCP clients are located on different subnets, a DHCP relay agent is used to
facilitate the conversation.

DHCP Architecture

The DHCP architecture consists of DHCP clients, DHCP servers, and DHCP relay agents on a network.
The clients interact with servers using DHCP messages in a DHCP conversation to obtain and renew
IP address leases.

DHCP Client Functionality

A DHCP client is any network-enabled device that supports the ability to communicate with a DHCP
server in compliance with RFC 2131, for the purpose of obtaining dynamic leased IP configuration
and related optional information.

Automatic IP Configuration

DHCP supports Automatic Private IP Addressing (APIPA), which enables computers running
Windows 2000, Windows XP, and Windows Server 2003 to configure an IP address and subnet mask
if a DHCP server is unavailable at system startup and the Automatic private IP address Alternate
Configuration setting is selected. This feature is useful for clients on small private networks, such as
a small-business office or a home office.

The DHCP Client service on a computer running Windows XP and Windows Server 2003 uses the
following process to auto-configure the client:

1. The DHCP client attempts to locate a DHCP server and obtain an IP address and
configuration.

2. If a DHCP server cannot be found or does not respond after one minute, the DHCP client
checks the settings on the Alternate Configuration tab of the properties of the TCP/IP
protocol.

If Automatic private IP address is selected, the DHCP client auto-configures its IP address
and subnet mask by using a selected address from the Microsoft-reserved Class B network,
169.254.0.0, with the subnet mask 255.255.0.0. The DHCP client tests for an address conflict
to ensure that the IP address is not in use on the network. If a conflict is found, the client
selects another IP address. The client retries auto-configuration up to 10 times.
 If User Configured is selected, the DHCP client configures a static IP address configuration.
The DHCP client tests for an address conflict to ensure that the IP address is not already in
use on the network. If a conflict is found, the DHCP client indicates the error condition to the
user.

3. When the DHCP client succeeds in self-selecting an address, it configures its network
interface with the IP address. The client then continues to check for a DHCP server in the
background every five minutes. If a DHCP server responds, the DHCP client abandons its self-
selected IP address and uses the address offered by the DHCP server (and any other DHCP
option information that the server provides) to update its IP configuration settings.

If the DHCP client obtained a lease from a DHCP server on a previous occasion, and the lease is still
valid (not expired) at system startup, the client tries to renew its lease. If, during the renewal
attempt, the client fails to locate any DHCP server, it attempts to ping the default gateway listed in
the lease, and proceeds in one of the following ways:

 If the ping is successful, the DHCP client assumes that it is still located on the same network
where it obtained its current lease, and continues to use the lease as long as the lease is still
valid. By default the client then attempts, in the background, to renew its lease when 50
percent of its assigned lease time has expired.

 If the ping fails, the DHCP client assumes that it has been moved to a network where a DHCP
server is not available. The client then auto-configures its IP address by using the settings on
the Alternate Configuration tab. When the client is auto-configured, it attempts to locate a
DHCP server and obtain a lease every five minutes.

DHCP Server Responsibilities

The DHCP servers maintain scopes, reservations, and options as set by the administrator.

Scopes

A scope must be properly defined and activated before DHCP clients can use the DHCP server for
automatic TCP/IP configuration. A DHCP scope is an administrative collection of IP addresses and
TCP/IP configuration parameters that are available for lease to DHCP clients of a specific subnet. The
network administrator creates a scope for each subnet.

A scope has the following properties:

 A scope name, assigned when the scope is created.

 A range of possible IP addresses from which to include or exclude addresses used in DHCP
lease offers.

 A unique subnet mask, which determines the network ID for an IP address in the scope.

 Lease duration values.

Each DHCP scope can have a single continuous range of IP addresses. To use several address ranges
within a single scope you must first define the entire address range for the scope, and then set
exclusion ranges.
Lease Durations

When a scope is created, the lease duration is set to eight days by default. However there are
situations when the administrator might want to change the lease duration. The following are
examples of adjusting the lease duration due to individual network consideration:

 An organization has a large number of IP addresses available and configurations that rarely
change. The administrator increases the lease duration to reduce the frequency of lease
renewal exchanges between clients and the DHCP server. Because the DHCP clients are
renewing their leases less frequently, DHCP-related network traffic is reduced.

 A limited number of IP addresses are available and client configurations change frequently
or clients move often in or out of the network. The administrator reduces the lease duration.
This increases the rate at which unused addresses are returned to the available address pool
for reassignment.

For example, consider the ratio between connected computers and available IP addresses. If 40
computers share 254 available addresses, the demand for reusing addresses is low. A long lease
time, such as a few months, might be appropriate in such a situation. However, if 230 computers
must share the same address pool, demand for available addresses is greater, and a shorter lease
time, for example a few days, is more appropriate.

Note

 If multiple DHCP servers are each configured with scopes that cover addresses that must be
reserved, the reservations must be specified on each DHCP server. Otherwise, the client
might receive an IP address from one of the DHCP servers that does not contain the
reservation, and therefore might not receive the IP address reserved for the client.

Superscopes

A superscope allows a DHCP server to provide leases from more than one scope to clients on a single
physical subnet. Before you can create a superscope, you must use the DHCP Microsoft
Management Console (MMC) snap-in to define at least one of the scopes to be included in the
superscope. Scopes added to a superscope are called member scopes. Superscopes can resolve
DHCP Server service issues in several different ways; these issues include situations in which:

 Support is needed for DHCP clients on a single physical network segment — such as a single
Ethernet LAN segment — where multiple logical IP networks are used. When more than one
logical IP network is used on a physical network, these configurations are also known as
multinets. In a situation where multinets are used, clients might not be able to communicate
directly with each other, because the clients might be on different logical subnets, even if
they are on the same physical network segment. In this case, routing must be enabled to
allow the clients to communicate with each other. Also, a router or BOOTP/DHCP relay agent
must be configured on the subnet to allow DHCP messages to travel between the logical
subnets.

 Support is needed for DHCP clients that are in a multinet located on the other side of BOOTP
relay agents.

 Clients need to be migrated to a new scope.

Interactions between Client and Server

DHCP servers and DHCP clients communicate through a series of DHCP messages. To obtain a lease,
the DHCP client initiates a conversation with a DHCP server using a series of these DHCP messages.

DHCP Messages

The following list includes the eight types of messages that can be sent between DHCP clients and
servers. For more information about the structure and specifics of each of these packets, see “DHCP
Message Format” later in this section.

DHCPDiscover

Broadcast by a DHCP client when it first attempts to connect to the network. The DHCPDiscover
message requests IP address information from a DHCP server.

DHCPOffer

Broadcast by each DHCP server that receives the client DHCPDiscover message and has an IP address
configuration to offer to the client. The DHCPOffer message contains an unleased IP address and
additional TCP/IP configuration information, such as the subnet mask and default gateway. More
than one DHCP server can respond with a DHCPOffer message. The client accepts the best offer,
which for a Windows DHCP client is the first DHCPOffer message that it receives.

DHCPRequest

Broadcast by a DHCP client after it selects a DHCPOffer. The DHCPRequest message contains the IP
address from the DHCPOffer that it selected. If the client is renewing or rebinding to a previous
lease, this packet might be unicast directly to the server.

DHCPAck

Broadcast by a DHCP server to a DHCP client acknowledging the DHCPRequest message. At this time,
the server also forwards any options. Upon receipt of the DHCPAck, the client can use the leased IP
address to participate in the TCP/IP network and complete its system startup. This message is
typically broadcast, because the DHCP client does not officially have an IP address that it can use at
this point. If the DHCPAck is in response to a DHCPInform, then the message is unicast directly to the
host that sent the DHCPInform message.

DHCPNack

Broadcast by a DHCP server to a DHCP client denying the client’s DHCPRequest message. This might
occur if the requested address is incorrect because the client moved to a new subnet or because the
DHCP client’s lease has expired and cannot be renewed.

DHCPDecline

Broadcast by a DHCP client to a DHCP server, informing the server that the offered IP address is
declined because it appears to be in use by another computer.

DHCPRelease

Sent by a DHCP client to a DHCP server, relinquishing an IP address and canceling the remaining
lease. This is unicast to the server that provided the lease.

DHCPInform
Sent from a DHCP client to a DHCP server, asking only for additional local configuration parameters;
the client already has a configured IP address. This message type is also used by DHCP servers
running Windows Server 2003 to detect unauthorized DHCP servers.

DHCP Lease Process

A DHCP-enabled client obtains a lease for an IP address from a DHCP server. Before the lease
expires, the DHCP client must renew the lease or obtain a new lease. Leases are retained in the
DHCP server database for a period of time after expiration. By default, this grace period is four hours
and cleanup occurs once an hour for a DHCP server running Windows Server 2003. This protects a
clients lease in case the client and server are in different time zones, the internal clocks of the client
and server computers are not synchronized, or the client is off the network when the lease expires.

Obtaining a New Lease

A DHCP client initiates a conversation with a DHCP server when it is seeking a new lease, renewing a
lease, rebinding, or restarting. The DHCP conversation consists of a series of DHCP messages passed
between the DHCP client and DHCP servers. The following figure shows an overview of this process
when the DHCP server and DHCP client are on the same subnet.

DHCP Lease Process Overview

1. The DHCP client requests an IP address by broadcasting a DHCPDiscover message to the

local subnet.

2. The client is offered an address when a DHCP server responds with a DHCPOffer message
containing an IP address and configuration information for lease to the client. If no DHCP
server responds to the client request, the client sends DHCPDiscover messages at intervals
of 0, 4, 8, 16, and 32 seconds, plus a random interval of between -1 second and 1 second. If
there is no response from a DHCP server after one minute, the client can proceed in one of
two ways:

o If the client is using the Automatic Private IP Addressing (APIPA) alternate

configuration, the client self-configures an IP address for its interface.

o If the client does not support alternate configuration, such as APIPA, or if IP auto-
configuration has been disabled, the client network initialization fails.

In both cases, the client begins a new cycle of DHCPDiscover messages in the background every five
minutes, using the same intervals as before (0, 4, 8, 16, and 32 seconds), until it receives a
DHCPOffer message from a DHCP server.
 3. The client indicates acceptance of the offer by selecting the offered address and
broadcasting a DHCPRequest message in response.

4. The client is assigned the address and the DHCP server broadcasts a DHCPAck message in
response, finalizing the terms of the lease.

When the client receives acknowledgment, it configures its TCP/IP properties by using the DHCP
option information in the reply, and completes its initialization of TCP/IP.

In rare cases, a DHCP server might return a negative acknowledgment to the client. This can happen
if a client requests an invalid or duplicate address. If a client receives a negative acknowledgment
(DHCPNack), the client must begin the entire lease process again.

When the DHCP client and the DHCP server are on the same IP broadcast subnet, the DHCPDiscover,
DHCPOffer, DHCPRequest, and DHCPAck messages are sent to identify clients by means of IP-level
broadcasts sent to the limited broadcast address and the media access control (MAC) broadcast
address.

When the DHCP server and DHCP client are not on the same subnet either a router or a host on the
DHCP client’s subnet must act as a DHCP relay agent to support the forwarding of DHCP messages
between the DHCP client and the DHCP server.

Renewing a Lease

The DHCP client first attempts to renew its lease when 50 percent of the original lease time, known
as T1, has passed. At this point the DHCP client sends a unicast DHCPRequest message to the DHCP
server that originally granted its lease. If the server is available, and the lease is still available, the
server responds with a unicast DHCPAck message and the lease is renewed.

If the original DHCP server is available, but the client’s current lease is no longer available, the DHCP
server responds with a DHCPNack message, and the client immediately starts the process to obtain a
new lease. This can happen if the client has changed subnets or if the DHCP server cannot fulfill the
lease request for some other reason.

If there is no response from the DHCP server, the client waits until 87.5 percent of the lease time has
passed (known as T2). At T2, the client enters the rebinding state, and broadcasts a DHCPRequest
message to attempt to renew the lease from any available DHCP server. If no DHCP server is
available by the time the lease expires, the client immediately unbinds itself from the existing lease
and starts the process to obtain a new lease, beginning with a DHCPDiscover message.

Preventing Address Conflicts

Client Conflict Detection

After the DHCP client receives a lease from the DHCP server, the client sends an Address Resolution
Protocol (ARP) request to the address that it has been assigned. If a reply to the ARP request is
received, the client has detected a conflict and sends a DHCPDecline message to the DHCP server.
The DHCP server attaches a BAD_ADDRESS value to the IP address in the scope for the length of the
lease. The client then begins the lease process again, and is offered the next available address in the
scope.
Note

 ARP requests do not traverse routers. Clients use ARP requests rather than pings (ICMP Echo
messages) because pings require the sender to have an IP address.

Server Conflict Detection

If your network includes older DHCP clients that do not perform conflict detection themselves, you
can enable conflict detection on the DHCP server. By default, the Windows Server 2003 DHCP Server
service does not perform any conflict detection.

To detect conflicts, the DHCP server pings (sends an ICMP Echo message to) an IP address before
offering that address to clients in a new lease. The DHCP server only pings addresses that have not
been successfully and previously leased. If a client requests a lease on an IP address that it already
had or is requesting a renewal, the DHCP server does not ping the IP address.

If conflict detection is enabled, an administrator-defined number of pings are sent. The server waits
1 second for a reply. Because the time required for a client to obtain a lease is equal to the number
of pings used, choose this value carefully because it directly impacts the overall performance of the
server. In general, one ping is sufficient.

If a response to the ping is received, a conflict is registered and that address is not offered to clients
requesting a lease from the server. The DHCP server then attaches a BAD_ADDRESS value to that IP
address in the scope. The DHCP server then tries to lease the next available address. If the duplicate
address is removed from the network, the BAD_ADDRESS value attached to the IP address can be
deleted from the scope’s list of active leases, and then the address returns to the pool. Addresses
are marked as BAD_ADDRESS for the length of the lease for which the scope is configured. If the
BAD_ADDRESS entry is not manually removed, it will automatically be removed after a period of
time equal to the lease time for the scope.

Note

 In general, use server conflict detection only as a troubleshooting aid when you suspect that
duplicate IP addresses are in use on your network. Each additional conflict detection
attempt adds to the time needed to negotiate leases for DHCP clients.

DHCP Options

DHCP options are additional configuration parameters that a DHCP server assigns to clients. Options
can also be used for DHCP communication between the server computer and client computers.

The most specific options take precedence over the least specific options. This simplifies DHCP
management and allows a flexible administration that can range from per-server default settings to
common settings for a specific subnet and individualized client settings when needed for special
circumstances. In most cases, the option values are specified in the Options dialog box on the DHCP
server, scope, or reservation.

DHCP options can be configured for specific values and enabled for assignment and distribution to
DHCP clients based on:

 Server options. These options apply globally for all scopes and classes defined at each DHCP
server and any clients that it services. Configured server option values always apply unless
they are overridden by options assigned to other scope, class, or client reservation.
  Scope options. These options apply to any clients that obtain a lease within that particular
scope. Configured scope option values always apply to all computers obtaining a lease in a
given scope unless they are overridden by options assigned to class or client reservation.

 Class options. These options apply to any clients that specify that particular DHCP Class ID
value when obtaining a scope lease. Configured class option values always apply to all
computers configured as members in a specified DHCP option class unless they are
overridden by options assigned to a client reservation.

 Reserved client options. These options apply only to the client corresponding to the
reservation. Reserved client option values override all other server, scope, or class assigned
option values.

Options are typically applied at each DHCP server at the server or scope level. To precisely manage
or customize option settings for a group or class of computers, specify either a user or vendor class
assignment that overrides the broader server or scope option defaults.

For special requirements, such as clients with special functions, assign options for specific reserved
clients.

Options can also be used to separate and distribute appropriate options for clients with similar or
special configuration needs. For example, DHCP clients on the same floor of a building can be
configured with the same DHCP Class ID value to assign them membership in the same option class.
You can then distribute additional or varied option data to that class during the lease process,
overriding any scope or globally provided default options.

Note

 Statically configured values on a client override any DHCP options of any type or level.

Many options are predefined on a DHCP server running Windows Server 2003. Other standard DHCP
options can be added as needed to support any other DHCP client software that recognizes or
requires the use of these additional options. The DHCP Server service running on Windows
Server 2003 supports all options defined in RFC 2132, although most DHCP clients use or support
only a small subset of the available RFC-specified options.

The following table contains a list of default DHCP options requested by DHCP clients running
Windows Server 2003 and Windows XP.

Default DHCP Options

Option Code Option Name

1 Subnet mask

3 Router

6 DNS servers

15 DNS domain name

44 WINS/NBNS servers

46 WINS/NetBT node type

47 NetBIOS scope ID

51 Lease time

58 Renewal (T1) time value

59 Rebinding (T2) time value

31 Perform router discovery

33 Static route

43 Vendor-specific information

249 Classless static routes

DHCP Option Parameters

DHCP servers can be configured to provide optional data that fully configures TCP/IP on a client.
Some of the most common DHCP option types configured and distributed by the DHCP server during
the lease process include parameters for the default gateway, DNS, and WINS.

Clients can be configured with:

 Information options. You can explicitly configure these options and any associated values
provided to clients.

 Protocol options. You can implicitly configure these options used by the DHCP Server service
based on server and scope property settings.

You can use the DHCP snap-in to configure these properties and set them for an entire scope or for a
single, reserved client scope.

Information Options

The following table lists the most common types of DHCP information options that can be
configured for DHCP clients. These options can be enabled and configured for each scope that you
configure on a DHCP server. Depending on your network infrastructure, some of these options can
be configured as server options, such as DNS domain name.

Common Information Options

Code Description

3 Router

6 DNS server
15 DNS domain name

44 WINS/NBNS servers

Clients can request these DHCP options, and can use the values to set their TCP/IP configurations for
the duration of the lease.

Protocol Options

The following table shows protocol options that DHCP clients can be configured to use when
communicating with a DHCP server to obtain or renew a lease.

Common Protocol Options

Code Description

51 Lease time

53 DHCP message type

55 Special option type used to communicate a parameter request list to the DHCP server

58 Renewal time value (T1)

59 Rebind time value (T2)

The values provided to clients for lease time, T1, and T2 are taken from the scope settings on the
DHCP server. The value provided for DHCP message type is automatically set depending on which
packet of the DHCP conversation is being sent.

References:

http://technet.microsoft.com/en-us/library/cc781008(v=ws.10).aspx – What is DHCP?

http://technet.microsoft.com/en-us/library/cc780760(v=ws.10).aspx – How DHCP Technology Works

http://technet.microsoft.com/en-us/library/cc782411(v=ws.10).aspx – DHCP Tools and Settings

Module 5: Labs / Assignments

1. Setup a DHCP Server on Windows Server 2008 R2

Module6: RPC

What Is RPC?

Microsoft Remote Procedure Call (RPC) is a powerful technology for creating distributed
client/server programs. RPC is an interprocess communication technique that allows client and
server software to communicate. The Microsoft RPC facility is compatible with the Open Group’s
Distributed Computing Environment (DCE) specification for remote procedure calls and is
interoperable with other DCE-based RPC systems, such as those for HP-UX and IBM AIX UNIX–based
operating systems.

Computer operating systems and programs have steadily gotten more complex over the years. With
each release, there are more features. The growing intricacy of systems makes it more difficult for
developers to avoid errors during the development process. Often, developers create a solution for
their system or application when a nearly identical solution has already been devised. This
duplication of effort consumes time and money and adds complexity to already complex systems.

RPC is designed to mitigate these issues by providing a common interface between applications. RPC
serves as a go–between for client/server communications. RPC is designed to make client/server
interaction easier and safer by factoring out common tasks, such as security, synchronization, and
data flow handling, into a common library so that developers do not have to dedicate the time and
effort into developing their own solutions.

Microsoft Remote Procedure Call (RPC) is an interprocess communication (IPC) mechanism that
enables data exchange and invocation of functionality residing in a different process. That process
can be on the same computer, on the local area network (LAN), or across the Internet. The Microsoft
RPC mechanism uses other IPC mechanisms, such as named pipes, NetBIOS, or Winsock, to establish
communications between the client and the server. With RPC, essential program logic and related
procedure code can exist on different computers, which is important for distributed applications.

Terms and Definitions

The following terms are associated with RPC.

Client

A process, such as a program or task, that requests a service provided by another program. The
client process uses the requested service without having to “deal” with many working details about
the other program or the service.

Server

A process, such as a program or task, that responds to requests from a client.

Endpoint

The name, port, or group of ports on a host system that is monitored by a server program for
incoming client requests. The endpoint is a network-specific address of a server process for remote
procedure calls. The name of the endpoint depends on the protocol sequence being used.

Endpoint Mapper (EPM)

Part of the RPC subsystem that resolves dynamic endpoints in response to client requests and, in
some configurations, dynamically assigns endpoints to servers.
Client Stub

Module within a client application containing all of the functions necessary for the client to make
remote procedure calls using the model of a traditional function call in a standalone application. The
client stub is responsible for invoking the marshalling engine and some of the RPC application
programming interfaces (APIs).

Server Stub

Module within a server application or service that contains all of the functions necessary for the
server to handle remote requests using local procedure calls.

RPC Dependencies and Interactions

RPC is a client/server technology in the most generic sense. There is a sender and a receiver; data is
transferred between them. This can be classic client/server (for example, Microsoft Outlook
communicating with a server running Microsoft Exchange Server) or system services within the
computer communicating with each other. The latter is especially common. Much of the Windows
architecture is composed of services that communicate with each other to accomplish a task. Most
services built into the Windows architecture use RPC to communicate with each other.

The following table briefly describes the services in Windows Server 2003 that depend on the RPC
system service (RPCSS).

RPC Architecture

By replacing dedicated protocols and communication methods with a robust and standardized
interface, RPC is designed to facilitate communication between client and server processes. The
functions contained within RPC are accessible by any program that must communicate using a
client/server methodology. The following figure shows the RPC architecture.

RPC Architecture
The following table lists and describes the components and functions of the RPC architecture.

RPC Components

Component Description

Client or server
Program or service that initiates or responds to an RPC request.
process

RPC stubs Program subsystems used by a client or server to initiate an RPC request.

Provides a common RPC interface between RPC clients and servers. NDR20 is
Marshalling engine used in a 32-bit architecture and NDR64 is optimized for a 64-bit architecture.

(NDR20 or NDR64) The client and the server negotiate which marshalling engine is used for the
communication.

Provides a direct interface for RPC to clients or servers. RPC clients and servers
typically call the runtime API to initialize RPC and prepare the data structure
Runtime application
that is used to make RPC calls. This runtime API layer also determines if an
programming
RPC request coming from a marshalling engine or directly from a client or
interface (API)
server is going to a local server or a remote server. The runtime API layer then
routes the RPC to the Connection RPC, Datagram RPC, or Local RPC layers.

Used when the RPC requires a connection–oriented protocol. This layer

Connection RPC
designates the connection–oriented protocol to use if the RPC is outgoing or
protocol engine
receives an incoming connection–oriented RPC.

Used when the RPC requires a connectionless protocol. This layer designates
Datagram RPC
the connectionless protocol to use if the RPC is outgoing or receives an
protocol engine
incoming connectionless RPC.

Local RPC protocol

Used when the server and client are located on the same host.
engine

Accessed when the RPC service first loads. Registry keys may specify IP port
Registry ranges and the device names of network cards that RPC should bind to. Unless
APIs force its use, the registry is not used in normal RPC operations.

Kernel32.dll is a Windows NT base API client dynamic-link library (DLL) file that
Win32 APIs provides system services for managing threads, memory, and resources.
(kernel32.dll, Advapi32.dll is an advanced Windows 32 base API DLL file; it is an API services
advapi32.dll, library that supports security and registry calls.
ntdll.dll)
Ntdll.dll is an NT layer DLL file that controls Windows NT system functions.

SSPI Provides a security interface for RPC. Negotiates the use of Kerberos, NTLM,
(secur32.dll) or Secure Sockets Layer (SSL) for authentication and encryption.
 Rpcss.dll primarily provides the infrastructure for COM, but a portion of
Endpoint Mapper rpcss.dll is used for the EPM. An RPC server contacts the EPM to receive
(EPM) dynamic endpoints and register those endpoints in the EPM database. RPC
(rpcss.dll) clients contact the EPM from the protocol-engine level to resolve endpoints
when establishing a connection with an unknown RPC server endpoint.

Used in the RPC client process only when the security interface specifies
Active Directory Kerberos or Negotiate as the security provider or when the server uses NTLM
as the security provider.

Network stack Used to pass RPC requests and replies between a client and a remote server.

Kernel Used to pass RPC requests and replies between a client and a local server.

RPC Processes and Interactions

The RPC components make it easy for clients to call a procedure located in a remote server program.
The client and server each have their own address spaces; that is, each has its own memory resource
allocated to data used by the procedure. The following figure shows the RPC process.

RPC Process

The RPC process starts on the client side. The client application calls a local stub procedure instead
of code implementing the procedure. Stubs are compiled and linked with the client application
during development. Instead of containing code that implements the remote procedure, the client
stub code retrieves the required parameters from the client address space and delivers them to the
client runtime library. The client runtime library then translates the parameters as needed into a
standard Network Data Representation (NDR) format for transmission to the server.

Note

 There are two NDR marshalling engines within the RPC runtime library: NDR20 and NDR64. A
32-bit client initiating the communication uses the NDR20 marshalling engine; a 64-bit client
can use either the NDR20 or the NDR64 marshalling engine. The same marshalling engine is
used on both the client and the server side, regardless of program architecture. There is a
slight decline in performance when either the client or server uses an architecture different
 from the other because the marshalling engine must do additional translation during the
communication.

The client stub then calls functions in the RPC client runtime library (rpcrt4.dll) to send the request
and its parameters to the server. If the server is located on the same host as the client, the runtime
library can use the Local RPC (LRPC) function and pass the RPC request to the Windows kernel for
transport to the server. If the server is located on a remote host, the runtime library specifies an
appropriate transport protocol engine and passes the RPC to the network stack for transport to the
server. RPC can use other IPC mechanisms, such as named pipes and Winsock, to accomplish the
transport. The other IPC mechanisms allow RPC more flexibility in the way in which it completes its
communications tasks. For more information about IPC mechanisms, see “Interprocess
Communications” on MSDN.

The following table lists the network protocols supported by RPC and the type of RPC connection for
which the protocol is used.

RPC-Supported Network Protocols

Protocol RPC Type

Transmission Control Protocol (TCP) Connection–oriented

Sequenced Packet Exchange (SPX) Connection–oriented

Named Pipe Connection–oriented

HTTP Connection–oriented

User Datagram Protocol (UDP) Connectionless

Cluster Datagram Protocol (CDP) Connectionless

When the server receives the RPC, either locally or from a remote client, the server RPC runtime
library functions accept the request and call the server stub procedure. The server stub retrieves the
parameters from the network buffer and, using one of the NDR marshalling engines, converts them
from the network transmission format to the format required by the server. The server stub calls the
actual procedure on the server. The remote procedure then runs, possibly generating output
parameters and a return value. When the remote procedure is complete, a similar sequence of steps
returns the data to the client.

The remote procedure returns its data to the server stub which, using one of the NDR marshalling
engines, converts output parameters to the format required for transmission back to the client and
returns them to the RPC runtime library functions. The server RPC runtime library functions transmit
the data to the client computer using either LRPC or the network.

The client completes the process by accepting the data over the network and returning it to the
calling function. The client RPC runtime library receives the remote-procedure return values,
converts the data from its NDR to the format used by the client computer, and returns them to the
client stub.
For Microsoft Windows, the runtime libraries are provided in two parts: an import library, which is
linked to the application, and the RPC runtime library, which is implemented as a DLL.

The server application contains calls to the server runtime library functions, which register the
server’s interface with the RPC runtime and, optionally, the EPM, and allow the server to accept
remote procedure calls. The server application also contains the application-specific remote
procedures that are called by the client applications.

RPC Security Context Multiplexing

Windows Server 2003 Service Pack 1 (SP1) provides RPC security context multiplexing for
connection-oriented connections, such as those that use Transmission Control Protocol (TCP). This
allows the RPC server to negotiate multiple security contexts over a single connection. For example,
when multiple RPC clients establish a connection to an RPC server and a middle-tier RPC server
resides between the clients and the destination server, the middle-tier server multiplexes the
security context of the additional clients over an already established connection to the destination
server. This eliminates the need for the middle-tier RPC server to use one of the exhaustible TCP
ports to establish a new connection for each RPC client connecting to the RPC server

Network Ports Used by RPC

RPC server programs typically use dynamic port mappings to avoid conflicts with programs and
protocols registered in the range of well-known TCP ports. RPC server programs associate their
universally unique identifier (UUID) with a dynamic port and register the combination with the RPC
EPM. The EPM provides a single point of contact for RPC clients. The RPC clients contact the EPM
and use the server program’s UUID to determine the port being used by the server program. The
following table indicates the network ports normally used by RPC.

Port Assignments for RPC

Service Name UDP TCP

HTTP 80, 443, 593 80, 443, 593

Named Pipes 445 445

RPC Endpoint Mapper 135 135

RPC Server Programs <Dynamically assigned> <Dynamically assigned>

References:

http://technet.microsoft.com/en-us/library/cc787851(v=ws.10).aspx – What is RPC?

http://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx – How RPC Works

Module 6 – Labs / Assessments

Module 7: Introduction to Microsoft Network Monitoring Tool

Microsoft Network Monitor is a protocol analyzer and network capturing tool.

Using the Network Monitor application or NMCap (a command line utility) you can capture network
traffic from multiple network interfaces simultaneously. While capturing live or viewing a previously
saved capture file, you can analyze the traffic using a rich set features to filter, view, and organize
frames.

A complete set of protocol parsers let you see network data with amazing detail, especially when
viewing Windows protocols. The parsers also cover the most common public protocols. We update
our parsers monthly on our site at http://www.codeplex.com/NMParsers.

Network Monitor monitors the network data stream which consists of all information transferred
over a network at any given time. Prior to transmission, this information is divided by the network
software into smaller pieces, called frames or packets. Each frame contains:

 The source address of the computer that sent the message.

 The destination address of the computer that received the frame.

 Headers from each protocol used to send the frame.

 The data or a portion of the information being sent.

The process by which Network Monitor copies frames is referred to as capturing. You can use
Network Monitor to capture all local network traffic or you can single out a subset of frames to be
captured. You can also make a capture respond to events on your network. For example, you can
make the network start an executable file when Network Monitor detects a particular set of
conditions on the network.

After you have captured data, you can view it in the Network Monitor user interface. Network
Monitor does much of the data analysis for you by translating the raw capture data into its logical
frame structure.

For security reasons, Windows 2000 Network Monitor captures only those frames, including
broadcast and multicast frames, sent to or from the local computer. Network Monitor also displays
overall network segment statistics for broadcast frames, multicast frames, network utilization, total
bytes received per second, and total frames received per second.

In addition, to help protect your network from unauthorized use of Network Monitor installations,
Network Monitor can detect other installations of Network Monitor that are running on the local
segment of your network. Network Monitor also detects all instances of the Network Monitor driver
being used remotely (by either Network Monitor from Systems Management Server or the Network
Segment object in System Monitor) to capture data on your network.

When Network Monitor detects other Network Monitor installations running on the network, it
displays the following information:

 The name of the computer

 The name of the user logged on at the computer

 The state of Network Monitor on the remote computer (running, capturing, or transmitting)
  The adapter address of the remote computer

 The version number of Network Monitor on the remote computer

In some instances, your network architecture might prevent one installation of Network Monitor
from detecting another. For example, if an installation is separated from yours by a router that does
not forward multicasts, your installation cannot detect that installation.

Network Monitor uses a network driver interface specification (NDIS) feature to copy all frames it
detects to its capture buffer, a resizable storage area in memory. The default size is 1 MB; you can
adjust the size manually as needed. The buffer is a memory-mapped file and occupies disk space.

More about Netmon through FAQs:

1. What is Network Monitor

Microsoft Network Monitor is a packet analyser. It enables capturing, viewing, and analysing
network data and deciphering network protocols. It can be used to troubleshoot network problems
and applications on the network

2. Where to download Netmon tool

Current version of Netmon "Microsoft Network Monitor 3.4" is available for download at
http://www.microsoft.com/en-in/download/details.aspx?id=4865

3. Installing Netmon tool

Screen-shots of Installing Netmon on my X64 bit OS.

(Please verify that downloaded Netmon version matches the OS version!...Else the initial error
message will be as follows.)

4. Installation Screen-shots.
- First screen where the Netmon is about to install.
After the first stage, installation will continue to install the "Parsers 3.4" on this machine.
5. Few Settings to change/modify Netmon:
- Default UI when Netmon is launched

From the above screen

a. Select Networks:

At the source computer from where Netmon is running, ensure that the correct\valid NIC card is
selected @ this window

1. Temporary capture file size: As Network Monitor captures network frames, it creates
temporary files to store captured data for each running capture session. These files are later
chained together to form a single capture file. The maximum size of these temporary
capture files can be changed. The default is 20 MB.

 Ensure that we are configuring appropriate size during the Netmon capture.
  Based on the reproducibility of the issue and the duration for which Netmon
capture is going to be collected, we need to configure to a higher-value.

2. Parser Profiles:

The current default settings @ the Parser-Profiles windows is as above

For most of the cases, we need to configure/choose "Windows" as the profile

Note:

1. we need to mark "Set As Active" on the Windows to get Windows-profile activated (Refer
below image)

Reason: This will get most of the default communications parsed effectively.

2. In case if we are having any other additional parses, we should be able to see that in this
window.
Example: The below screen has got new/custom parser-profile named as "OA" in this Netmon.

Capture Filter:

If we are working on a BUSY server (or) we need to limit the capture to any particular protocols/IP-
Address

Example: From the problematic server (capture machine) we don’t want to capture all of the
Netmon traffic, rather want to capture traffic against a particular server.
6. Capturing a Netmon Trace:

To Start a Capture Session

1. On the Start page, click New capture tab, or on the File menu, click New and select Capture.

2. At the bottom of the upper-right window, click Select Networks.

3. In the Select Networks window, select the network(s) from which you want to capture
frames.

4. At the bottom of the upper-right window, click Capture Filter.

5. In the Capture Filter window, set up filters that you want to apply during the capture.

6. On the Capture menu, click Start.

Note:

1. Verify that we are having some activities @ the frame-summary window

2. During the above Netmon capture, I've accessed a default page which is on another server.

During a capture, Network Monitor displays the following statistics in the status bar at the bottom of
the window:

 Displayed: The number of displayed frames in the Frame Summary window.

 Dropped: The number of dropped frames.

  Captured: The total number of frames captured for the active tab. It is possible for this
number to keep incrementing even after capturing has stopped because frames in the
capture backlog are analyzed and added to the active tab.

 Pending: The number of frames in the capture buffer that remain to be analyzed for the
active tab.

 Focused: The frame that currently has focus in the Frame Summary window.

 Selected: The total number of selected frames in the Frame Summary window.

7. Parsing Netmon trace:

I. Using the "Time and Date" field, to confirm the start and end time of the Network
Capture. This should be giving the total-number-of frames captured during this time.

11:42:58 27-04-
2014 0.0000000 1 0.0070156 NetmonFilter NetmonFilter:Updated
Capture Filter: None

11:42:58 27-04-
2014 0.0000000 2 0.0070156 NetworkInfoEx NetworkInfoEx:Networ
k info for , Network Adapter Count = 2

…….
11:43:40 27-04-
2014 0.0217040 1592 42.6693590 svchost.exe B10 10.0.0.100 TLS TL
S:TLS Rec Layer-1 SSL Application Data {TLS:5, SSLVersionSelector:4, TCP:3, IPv4:2}

In the above capture, we have 1592 frames captured. The duration of the Netmon trace capture is
from " 11:42:58 27-04-2014" to "11:43:40 27-04-2014"

II. Details from the above Image:

i. Number of "Network Adapter" (In this example 2 NICs)

ii. Ipv4 Address (In this example (10.1.1.22); SubnetMask (255.0.0.0)

iii. MAC Address of the NIC and other details about the NIC Cards.

Parsing the Netmon trace based on the process.

General TCP/IP Communication

1. Establishing a Connection

2. Transmit DATA between machines

3. Terminating a Connection
1. TCP-IP hand-shake (or) Establishing a Connection [From the below Netmon the frames 819,820
and 821]

To initialize a connection, the client and server must synchronize each other's sequence numbers.

1. Client shares its "Initial Sequence Number (ISN)" to server [Server increments this
ISN by 1 and sent it back as its ACK sequence number]

Example: Client shares its Seq # 1490460822 to server

2. Server ACKs the Clients-Sequence Number and also shares its own Sequence
Number to Client.

Example: Server shares the Seq=3088572389, Ack=1490460823

ACK = SEQ+1 [The acknowledgement is just proof to the client that the ACK is specific to the SYN the
client initiated]

SEQ => Server's sequence number.

3. Client is acknowledging the request from the server for synchronization.

Example: Seq=1490460823, Ack=3088572390

ACK ==> SEQ +1

3-way hand-shake:

11:43:29 27-04-
2014 0.0000000 819 30.7488148 B10 b7.ind.in TCP TCP:Flags=......S.,
SrcPort=25627, DstPort=HTTPS(443), PayloadLen=0, Seq=1490460822, Ack=0, Win=8192 ( ) =
8192 {TCP:20, IPv4:19}

11:43:29 27-04-
2014 0.0003331 820 30.7491479 b7.ind.in B10 TCP TCP:Flags=...A..S.
, SrcPort=HTTPS(443), DstPort=25627, PayloadLen=0, Seq=3088572389, Ack=1490460823, Win=8192
( Scale factor not supported ) = 8192 {TCP:20, IPv4:19}

11:43:29 27-04-
2014 0.0000245 821 30.7491724 B10 b7.ind.in TCP TCP:Flags=...A....,
SrcPort=25627, DstPort=HTTPS(443), PayloadLen=0, Seq=1490460823, Ack=3088572390,
Win=64240 (scale factor 0x0) = 64240 {TCP:20, IPv4:19}

Observation:

2. Data Transfer between Systems.

In this Example Frames 822,823,824 and 825

Here, we can see that the Client Machine (B10) negotiates its Certificate with server-machine (b7)
so the SSL communication can happen.
3. Terminating a Connection

Theory:

I. Client sends a FIN packet to Server

when the FIN parameter is set, it will inform the server that it has no more data to send. Second, the
ACK is essential in identifying the specific connection they have established.

Example: Client --> Sends "Seq=1490461259, Ack=3088573301" with FIN flag

II. Server Acknowledge the FIN packet and also RESETs the connection

Example: Server --> sends Seq=3088573301, Ack=1490461260 and also RESETs this connection.

In this Example Frames 826 and 827

11:43:29 27-04-
2014 0.0151018 826 30.7737484 B10 b7.ind.in TCP TCP:Flags=...A...F
, SrcPort=25627, DstPort=HTTPS(443), PayloadLen=0, Seq=1490461259, Ack=3088573301,
Win=63329 (scale factor 0x0) = 63329 {TCP:20, IPv4:19}

11:43:29 27-04-
2014 0.0004757 827 30.7742241 b7.ind.in B10 TCP TCP:Flags=...A.R..
, SrcPort=HTTPS(443), DstPort=25627, PayloadLen=0, Seq=3088573301, Ack=1490461260, Win=0
(scale factor 0x0) = 0 {TCP:20, IPv4:19}
Filtering Netmon based on Process:

When we Expand the appropriate process on the left-hand window….we can see the

1. Source and Destination IP-Address involved (In this Example IP-Address details for the
source is 10.1.1.22 is communicating to 10.1.1.21)

2. Source and Destination Port involved (In this Example; PORT source-port 25628,25629 and
destination-port is 443)

When selecting the Iexplorer.exe, we can see that the Frame-summary starts showing the
communication made by Iexplore.exe process

Parsing the Netmon using the Protocol

 Ensure that the selection is @ the Top-Level "All Traffic" in the left-hand pane to include all
the Netmon traces for the filter/parsing.

 Use the "Display Filter" to filter the current traces with appropriate filters.

Dns, icmp, Kerberosv5 are few valid filters.

 After typing/entering a filter, use the Apply-button to apply this filter

If there is any error, we should get an error message immediately.

DNS Request (Frame #: 815)

Frame: Number = 815, Captured Frame Length = 69, MediaType = ETHERNET

- Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-78-27-3F],SourceAddress:[00-15-

5D-78-27-43]

+ DestinationAddress: Microsoft Corporation 78273F [00-15-5D-78-27-3F]

+ SourceAddress: Microsoft Corporation 782743 [00-15-5D-78-27-43]

EthernetType: Internet IP (IPv4), 2048(0x800)

- Ipv4: Src = 10.1.1.22, Dest = 10.1.1.20, Next Protocol = UDP, Packet ID = 17534, Total IP Length = 55

+ Versions: IPv4, Internet Protocol; Header Length = 20

+ DifferentiatedServicesField: DSCP: 0, ECN: 0

TotalLength: 55 (0x37)

Identification: 17534 (0x447E)

+ FragmentFlags: 0 (0x0)

TimeToLive: 128 (0x80)

NextProtocol: UDP, 17(0x11)

Checksum: 0 (0x0)

SourceAddress: 10.1.1.22

DestinationAddress: 10.1.1.20

- Udp: SrcPort = 63712, DstPort = DNS(53), Length = 35

SrcPort: 63712

DstPort: DNS(53)

TotalLength: 35 (0x23)

Checksum: 42324 (0xA554)

UDPPayload: SourcePort = 63712, DestinationPort = 53

- Dns: QueryId = 0xD7CC, QUERY (Standard query), Query for b7.ind.in of type Host Addr on class
Internet

QueryIdentifier: 55244 (0xD7CC)

+ Flags: Query, Opcode - QUERY (Standard query), RD, Rcode - Success

QuestionCount: 1 (0x1)

AnswerCount: 0 (0x0)

NameServerCount: 0 (0x0)

AdditionalCount: 0 (0x0)

+ QRecord: b7.ind.in of type Host Addr on class Internet

Observation:

 Request is from 10.1.1.22 (This machines, client machine from where Netmon is running);
Destination-ip-Address (10.1.1.20) this is the machine where the DNS service is running

 Source-Port is 63712 and the Destination-port is 53

 Query-ID is 55244 (this is used to match the DNS request and DNS Response)
  Query is: b7.ind.in of type Host Addr on class Internet

DNS Response:

Frame: Number = 816, Captured Frame Length = 85, MediaType = ETHERNET

- Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-78-27-43],SourceAddress:[00-15-

5D-78-27-3F]

+ DestinationAddress: Microsoft Corporation 782743 [00-15-5D-78-27-43]

+ SourceAddress: Microsoft Corporation 78273F [00-15-5D-78-27-3F]

EthernetType: Internet IP (IPv4), 2048(0x800)

- Ipv4: Src = 10.1.1.20, Dest = 10.1.1.22, Next Protocol = UDP, Packet ID = 17790, Total IP Length = 71

+ Versions: IPv4, Internet Protocol; Header Length = 20

+ DifferentiatedServicesField: DSCP: 0, ECN: 0

TotalLength: 71 (0x47)

Identification: 17790 (0x457E)

+ FragmentFlags: 0 (0x0)

TimeToLive: 128 (0x80)

NextProtocol: UDP, 17(0x11)

Checksum: 57084 (0xDEFC)

SourceAddress: 10.1.1.20

DestinationAddress: 10.1.1.22

- Udp: SrcPort = DNS(53), DstPort = 63712, Length = 51

SrcPort: DNS(53)

DstPort: 63712

TotalLength: 51 (0x33)

Checksum: 18403 (0x47E3)

UDPPayload: SourcePort = 53, DestinationPort = 63712

- Dns: QueryId = 0xD7CC, QUERY (Standard query), Response - Success, 10.1.1.21

QueryIdentifier: 55244 (0xD7CC)

+ Flags: Response, Opcode - QUERY (Standard query), AA, RD, RA, Rcode - Success

QuestionCount: 1 (0x1)

AnswerCount: 1 (0x1)
 NameServerCount: 0 (0x0)

AdditionalCount: 0 (0x0)

+ QRecord: b7.ind.in of type Host Addr on class Internet

+ ARecord: b7.ind.in of type Host Addr on class Internet: 10.1.1.21

Observation:

 Request is from 10.1.1.20 (DNS Server); Destination-ip-Address (10.1.1.22 -- the main

machine which is making the DNS Request)

 Source-Port is 53 and the Destination-port is 63712

 Query-ID is 55244 (this is used to match the DNS request and DNS Response)

 Answer: + ARecord: b7.ind.in of type Host Addr on class Internet: 10.1.1.21

(In this case, b7.ind.in is residing @ 10.1.1.21)

Parsing the Netmon traces using the ip-Address:

Display-filter: ipv4.Address==10.1.1.22 and ipv4.Address==10.1.1.20

Observation:

 This filter will display all the communication between the source and destination ip-address.

 We can also see the process-name which is involved in these communication (Example
msexchangerepl.exe)

 We can also see the protocol-name(s) which are TCP,DNS,ICMP

Adding a new parameter to the above filter

To Add the ip-address and the RESET frames alone.

Select the above parameter (TCP Reset-flag) and use the option "Add Selected Value to Display
Filter"

Now the Display-Filter as "ipv4.Address==10.1.1.22 and ipv4.Address==10.1.1.21 And

TCP.Flags.Reset == 0x1"

Using the And OR flags the filters can be modified.

We can use History options to reuse the Netmon Display-filters.

References:

How to use Network Monitor to capture network traffic -- http://support.microsoft.com/kb/812953

Frequently Asked Questions About Network Monitor -- http://support.microsoft.com/kb/294818

The Basics of Reading TCP/IP Traces -- http://support.microsoft.com/kb/169292

Explanation of the Three-way Handshake via TCP/IP - http://support.microsoft.com/kb/172983

Blog - http://blogs.technet.com/b/netmon/

http://channel9.msdn.com/tags/Netmon/- Channel9 Netmon Videos

Module 7: Netmon – Labs/Assignments