The Ultimate CCNA Study Package - ICND 1

Chris Bryant, CCIE #12933 http://www.thebryantadvantage.com

Back To Index

ARP, DNS, and DHCP

Overview
One Transmission, Two Destination Addresses

Domain Name System (DNS)

Introduction To ipconfig /all

Address Resolution Protocol (ARP)

Proxy ARP

Dynamic Host Configuration Protocol (DHCP)

Configuring DHCP On Cisco Routers

One Transmission, Two Destination Addresses

As network admins, we spend a lot of time concerning ourselves with IP

addresses - assigning them, filtering them, etc. We don't think about MAC
addresses that often, but data going from Host A to Host B must have a
destination IP address for Host B and a destination MAC address as well.

To get these two required destination addresses, Host A will use two
separate protocols:

 Domain Name System (DNS) for the IP address

 Address Resolution Protocol (ARP) for the MAC address

Host A will require the IP address first, since it must know the IP address
of the remote host in order for the ARP process to work properly. Let's
take a quick look at the DNS process.

Domain Name System

Host A will know the computer name of Host B - for this discussion we'll
assume that name to be "hostb". Now it needs an IP address and a MAC
address for that hostname, and DNS will help it get that IP address. The
DNS process is very simple. Each host will have the IP address of a DNS
server, and a host needing the IP address of another host will send a DNS
Request to the DNS server.

Note that all devices in the following example are on the same network
segment. There are no routers involved.

The natural question is "How does Host A know the IP address of the
DNS server in the first place?" That happens in one of two ways:

 The DNS server address is hard-coded on Host A

 The DNS server address was learned via DHCP

We're going to take a look at DHCP later in this section, but here's the
partial output of ipconfig /all on a Windows PC using DHCP. The DNS
server IP addresses are in bold.
C:\>ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : your-4dacd0ea75

Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : hsd1.va.comcast.net.

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Intel(R) 82562V 10/100 Network Conne
ction
Physical Address. . . . . . . . . : 00-17-31-F7-03-B2
Dhcp Enabled. . . . . . . . . . . : Yes
 Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.1.100
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 68.87.73.242
68.87.71.226
Lease Obtained. . . . . . . . . . : Monday, October 08, 7:23:17 AM
Lease Expires . . . . . . . . . . : Tuesday, October 09, 7:23:17 AM

You'll notice there's no "ARP Server" listed there. That's because we

don't have an ARP server! Now that Host A has the IP address of Host B,
we're halfway home, but now Host A needs that MAC address to send
data successfully to Host B -- and that's where the Address Resolution
Protocol (ARP) comes in.

The Address Resolution Protocol

In our current network, we have a DNS server that took care of the
hostname-IP address resolution, but now we need the MAC address of
Host B, and there is no ARP server on the network. Instead, the ARP
process uses a series of broadcasts and replies.

Host A is the host needing a MAC address of a remote device, so it'll be

Host A that sends out the initial ARP Request. This request is a Layer 2
broadcast, meaning....

 The source MAC address will be that of Host A

 The destination MAC address will be ff-ff-ff-ff-ff-ff
 The source IP address will be that of Host A
 The destination IP address will be that of Host B (learned via DNS)
In this particular topology, all of the other three devices will see the
request. Host C and the DNS server will see the destination IP address of
10.1.1.2, see that it's not theirs, and will simply ignore the ARP Request.
Host B will see that it is an ARP Request and that it does match its IP
address, so Host B will send an ARP Response containing its MAC
address.

Thanks to DNS and ARP, Host A now has the IP and MAC address of
Host B, and can successfully send data to that host.

As network admins, we're always interested in limiting the number of

broadcasts on our network. Along those lines, hosts build ARP caches
that they consult before sending out ARP Requests. These caches
contain an IP address - MAC address mapping table such as the one
shown here on a Windows PC with the command arp -a :
C:\>arp -a

Internet Address Physical Address Type

10.1.1.2 bb-bb-bb-bb-bb-bb dynamic

After learning Host B's IP and MAC addresses (MAC addresses are also
called "physical addresses" because they physically exist on the network
card), Host A would enter them into its ARP cache. The next time Host A
needs to send data to Host B, the information needed to do so is right
there in the ARP cache and no ARP Request needs to be sent.

In that example, all of the devices were on the same physical cable.
That's good for an example, but more likely we're going to have something
like this:

The switch does not impact the ARP process at all. Why? Because
switches forward broadcasts, and that's just what the ARP Request is as
indicated by its destination MAC address of ff-ff-ff-ff-ff-ff. The switch will
send a copy of that ARP Request out every single port except the one it
came in on.

As in the previous example, only the host with the IP address contained in
the ARP Request will send an ARP Response back. The ARP Response
is *not* a broadcast, so the switch will send that Response only out the
appropriate switch port.
Switches do not affect the ARP process, but routers do - because routers
do not forward broadcasts. If we have the following network topology, we
just might have a problem.

If Host A sends an ARP Request for Host B's MAC address, we know the
switch will forward it, because switches forward broadcasts. The problem
comes in with the router, because routers do not forward broadcasts.
Instead, the router will use proxy ARP to answer the ARP Request with the
MAC address of the router interface that received the original Request.

Interestingly enough, Host A has no idea that the MAC address it received
in the ARP Response is actually not that of Host B, but rather that of the
Ethernet0 interface of the router. All Host A knows is that it sent an ARP
Request and got a Response. Now when Host A sends data to Host B,
the data will have the following destinations:
  IP destination address is Host B's IP address
 MAC destination address is the one assigned to the router's E0
interface

Proxy ARP is a little odd to work with at first, and can result in some
unexpected source and destination MAC addresses at different points in
your network. If you're not aware of these changes in MAC addresses
when you use a network traffic analysis tool, you may wonder where those
addresses are coming from!

Let's walk through an example of how and if MAC and IP addresses

change as a result of Proxy ARP.

Two simple rules to remember:

 The source and destination MAC addresses will only change when
routers are involved, since that's when Proxy ARP has to step in.
 The source and destination IP addresses do not change, period.

For this example, we'll use the same network, but with MAC and IP
address assigned to the hosts and the router's ethernet interfaces.

Host A sends an ARP Request for the MAC address of Host B, and that
request is forwarded by the switch. The router receives the Request on its
E0 interface, and sends a Proxy ARP response back to Host A. This
request tells Host A that the MAC address of the device at 10.3.1.2 is 11-
11-11-11-11-11, which is actually the MAC address on the router's E0
interface.
As a result, when Host A sends data to Host B...

 The source IP and MAC addresses are that of Host A

 The destination IP address is that of Host B
 BUT...the destination MAC is that of R1's E0 interface!

Now the router will forward that data to Host B. The destination IP and
MAC will be that of Host B, but the source MAC address will be that of the
router's E1 interface - the interface that's forwarding the data.

As a result, Host A's ARP cache will look like this:

C:\>arp -a

Internet Address Physical Address Type

10.3.1.2 11-11-11-11-11-11 dynamic

Again, the IP address never changes in this scenario, but the MAC
address does as a result of Proxy ARP.

Dynamic Host Configuration Protocol

A host's ability to send data to all the required destinations requires quite a
bit of information. The host needs to know the following at a minimum...

 What's my IP address?
 What's my network mask?
 What are the IP addresses of the DNS servers?
 What's my default gateway?

How do we get all of this information to and on our network hosts? We've
got two options:

 Visit each workstation and configure the information manually

 Enable each workstation for DHCP

And sooner or later, some of that information is going to change and the
hosts will need to know about these changes.

If you previously hardcoded the information on all of the hosts, you'll now
have to go out and visit every workstation again and change the
information manually.

If you used DHCP to begin with, you now just have to change the
information on the DHCP server.

DHCP is starting to sound pretty good! When the choice is visiting the
hundreds or thousands of hosts on a typical network manually or using
DHCP to dynamically handle IP address assignment information, there
really is no choice.

There are four basic steps that allow a host (the DHCP Client) to acquire
all of this information from a DHCP Server. The Client begins the
process by sending a DHCP Discover message out. This message is a
broadcast, so it will not be forwarded by routers.

Any DHCP Server that receives that message will respond with a DHCP
Offer. The Offer contains the following:

 The IP address the DHCP Server is offering to the Client

 The network mask the DHCP Server is offering to the Client
 The amount of time the Client can keep this information if the Offer is
accepted (the lease)
 The IP address of the DHCP Server that is making the offer
Since the original DHCP Discovery sent by the host is a broadcast, more
than one DHCP Server may see it and respond with an Offer, as shown
above. In this case, the host will respond to the first Offer it receives with
a DHCP Request.

The Request has the IP address of the DHCP Server that sent the
accepted Offer. When the other DHCP Server(s) see that their Offer was
not accepted, they put the offered IP address back into their address
pools. This DHCP Request is also a broadcast.

Finally, the DHCP Server whose offer was accepted sends a DHCP
Acknowledgement back to the client with any other information the Client
needs. The process is now complete.
You can see the IP address a host has been assigned, along with the
lease length and other information, with ipconfig /all. You can verify that
the host is running DHCP with this command as well.
C:\>ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . :
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . :

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : Description . . . . .

. . . . . . : Intel(R) 82562V 10/100 Network Conne
ction
Physical Address. . . . . . . . . : 00-17-31-F7-03-B2
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.1.100
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 68.87.73.24
68.87.71.22
Lease Obtained. . . . . .. : Monday, October 08, 200x 7:23:17 AM
Lease Expires . . . .. . . : Tuesday, October 09, 200x 7:23:17 AM

Configuring DHCP With Cisco Routers

Many Cisco router models can be configured to operate as DHCP

servers. On some models, we're limited to using the command-line
interface to write the DHCP config, and I'll be the first to say that can be
little tricky. Cisco is making a big push toward GUI-based tools, and the
GUI we'll look at here is the Security Device Manager (SDM). This tool
makes DHCP configurations a breeze!

In this lab, we'll use SDM to configure a Cisco router as a DHCP server,
and then test that configuration.
SDM has quite a few capabilities, so I'm going to show you only the part of
the GUI relevant to a DHCP deployment. Here's just a bit of the opening
screen, and you can see that we're working on a Cisco 2811 server.

To begin the DHCP configuration, click configure.

The left-hand side of the GUI is going to have about 15 buttons, and the
one we want is the very last one down - "Additional Tasks". I clicked on
that and you see the DHCP folder appear along with some other protocols
and tools.
Clicking "Add" brings up the "Add DHCP Pool" window.
We'll use the following pool with a 1-day lease.
When you click "OK", you'll get a window like this one. Note that our
simple little GUI config resulted in seven different commands to be
submitted to the router. Having configured DHCP on more than one
router, I can tell you that this method is much easier than the CLI!

The new DHCP Pool appears in the window, and the details of that pool
appear in the lower window.
Now let's visit the PC and change the IP address requisition method to
DHCP.

A minute or so later, I checked the status of the interface and you can see
the new IP address does indeed fall in the range of addresses we
configured on the Cisco router, and the acquisition method is now DHCP.
Just to verify that the address did come from the Cisco router, we'll go
back to SDM and click on "DHCP Pool Status".

Doing so shows you the IP addresses the router has leased, and there's
the PC's 10.1.1.150 address!
A Word Of Advice On Cisco GUIs

I enjoy working at the command line, but I'll be the first to admit that
Cisco's GUIs do make life easier.

There's always the chance that you'll be asked to perform a task during
your CCENT and CCNA exams - really, any Cisco exam - and that task
could be at the CLI or in a GUI such as the one we've just used.

Cisco GUIs are highly intuitive, so even if you have no hands-on

experience with one and you see one on the exam, the key is to stay calm
and start clicking on buttons to see where things are. For example, in this
lab the DHCP Config was under "Additional Tasks", and everything from
there was very intuitive.

Again, the key is to remain calm and just take a look around. If Cisco
asks you to do something on an exam, they're not trying to trick you.
Whatever they're asking can be done - and you can do it!

Recommended Video Viewing:

CCNA Video Boot Camp on OSPF (Hosted By Udemy.com - free course)

http://www.udemy.com/ccna-boot-camp/

My Full CCNA Video Boot Camp - Over 22 Hours Of Video - And A Secret
Discount Link!

See the course here, and watch an hour of the OSPF section for free!

http://www.udemy.com/ccna-on-demand-video-boot-camp/

Get a $10 discount by enrolling at the following link - it's like getting this
ebook for free!

http://www.thebryantadvantage.com/CCNAStudyPackageUpgrade.htm

Join us on my YouTube channel today - subscribers never miss a video,

and you can't beat the cost! ;)

http://www.youtube.com/user/ccie12933
 Back To Index

Copyright © 2012 The Bryant Advantage. All Rights Reserved.