|
0:00:13
|
In our next section here for IP services, we're going to
|
|
0:00:16
|
look at the DHCP and DNS features on the router
|
|
0:00:21
|
where DHCP is an extension to the BOOTP protocol
|
|
0:00:24
|
that's used for automatic host configuration for
|
|
0:00:27
|
things like the addresses, subnet mask, default gateway etc,
|
|
0:00:33
|
Now one of the key points to remember about DHCP
|
|
0:00:35
|
is that it does use broadcast UDP packets which means that
|
|
0:00:40
|
when the DHCP client and the DHCP server
|
|
0:00:42
|
are not on the same subnet we need some sort of way to
|
|
0:00:45
|
relay the BOOTP client broadcasts to the server
|
|
0:00:50
|
then the BOOTP server replies back to the client.
|
|
0:00:54
|
Now specifically in the IOS we support a number of different
|
|
0:00:58
|
operations for DHCP not only the DHCP server
|
|
0:01:02
|
and the DHCP client where we can lease out addresses
|
|
0:01:06
|
and we can be leased an address
|
|
0:01:08
|
but IOS also support the DHCP proxy and the DHCP
|
|
0:01:12
|
relay where the difference between them the DHCP
|
|
0:01:16
|
proxy would be used on PPP interfaces in order to
|
|
0:01:20
|
translate from an IPCP request
|
|
0:01:23
|
which again is the IP control protocol for PPP
|
|
0:01:26
|
into a DHCP request
|
|
0:01:29
|
where the DHCP relay is what we configure
|
|
0:01:32
|
with the ip helper address. Now when the DHCP server
|
|
0:01:35
|
receives the request from the client, we can have
|
|
0:01:40
|
multiple pools that are going to define the individual subnet
|
|
0:01:44
|
allocation and the different attributes that the clients
|
|
0:01:47
|
are going to get. Things again like the DNS server, the default
|
|
0:01:51
|
gateway etc.
|
|
0:01:54
|
IOS also supports host pooling where we can specify
|
|
0:01:58
|
essentially static assignments through DHCP
|
|
0:02:02
|
by defining a particular host pool with just one particular
|
|
0:02:06
|
address, but we'll see that there are some caveats with
|
|
0:02:09
|
doing that configuration depending on whether the
|
|
0:02:11
|
client is using the DHCP client identifier versus the
|
|
0:02:15
|
hardware address when it is requesting a lease.
|
|
0:02:19
|
Now specifically the DHCP server is going to go through a couple
|
|
0:02:23
|
different options when it is trying to figure out what is the
|
|
0:02:25
|
particular address pool that I'm going to use for this
|
|
0:02:29
|
individual client.
|
|
0:02:31
|
The first is going to be based on the DHCP client identifier.
|
|
0:02:36
|
Now the key point to understand is that the client ID is different
|
|
0:02:39
|
from the Mac address of the interface
|
|
0:02:43
|
where typically the client identifier is derived from the
|
|
0:02:46
|
Mac address, but it could be any string that we're
|
|
0:02:50
|
assigning inside of the DHCP request.
|
|
0:02:53
|
Essentially the -- the actually the DHCP discover message.
|
|
0:02:58
|
In the case of Windows clients there is going to be a client
|
|
0:03:02
|
ID that is automatically in the packet, but not
|
|
0:03:05
|
all operating systems do this so when you're looking at your
|
|
0:03:09
|
individual host that are requesting addresses
|
|
0:03:11
|
you do need to understand the difference between
|
|
0:03:13
|
the client identifier being used and the hardware
|
|
0:03:16
|
address. The reason that this is significant again is that if you're
|
|
0:03:21
|
trying to bind a specific address to an individual host, the host
|
|
0:03:26
|
pool is going to work different if they're using the client identifier
|
|
0:03:28
|
versus the hardware address. Specifically in IOS, you can see
|
|
0:03:33
|
which one the client is using. If you look at the low-level
|
|
0:03:36
|
debug for DHCP or if you look at the show ip dhcp bindings
|
|
0:03:41
|
we can see for that particular IP address who is the device
|
|
0:03:45
|
that requested this. Now, if there's no client identifier
|
|
0:03:48
|
or hardware address that we're binding a host pool to
|
|
0:03:53
|
the server is going to look at the relaying gateway's address
|
|
0:03:57
|
which is a field that is inserted during the DHCP relay
|
|
0:04:03
|
which essentially identifies which particular router or
|
|
0:04:06
|
device is relaying the broadcast request
|
|
0:04:10
|
from the client to the DHCP server.
|
|
0:04:16
|
Now in the case that none of these options are
|
|
0:04:18
|
present, the client identifier, the hardware address or
|
|
0:04:21
|
the relaying gateway's address
|
|
0:04:23
|
then we're going to use the attached subnet
|
|
0:04:27
|
for the particular pool, so if we're receiving the
|
|
0:04:29
|
DHCP request on a LAN interface that is 10.0.0.0/24
|
|
0:04:35
|
we would then look for the pool that is specific to that
|
|
0:04:37
|
address that includes the network 10.0.0.0/24
|
|
0:04:41
|
Specifically for the DHCP relay configuration we're going to
|
|
0:04:44
|
use the IP helper address which is similar in theory to
|
|
0:04:48
|
the IP multicast helper address
|
|
0:04:51
|
where in the case of IP helper we are translating
|
|
0:04:53
|
a broadcast to a unicast
|
|
0:04:57
|
with the multicast helper address, we would be
|
|
0:04:59
|
translating a multicast to a unicast.
|
|
0:05:02
|
So you can think of this kind of like a network address
|
|
0:05:04
|
translation where we are modifying the Layer 3
|
|
0:05:07
|
destination in the IP packet header, but we're not modifying
|
|
0:05:12
|
any of the rest of the payload.
|
|
0:05:14
|
The only one exception to this is the GI address where the
|
|
0:05:19
|
gateway address that is inside the DHCP discover
|
|
0:05:22
|
payload where the relaying router is going to put their own
|
|
0:05:26
|
address inside there. Additionally this could
|
|
0:05:29
|
include the DHCP information option which is known as
|
|
0:05:32
|
DHCP option 82
|
|
0:05:35
|
which essentially is the gateway address for Layer 2 devices
|
|
0:05:40
|
that are not running IP.
|
|
0:05:43
|
So when you look at larger scale DHCP deployments
|
|
0:05:47
|
and you have the DHCP request that is going to
|
|
0:05:49
|
like a Layer 2 switch and the Layer 2
|
|
0:05:52
|
switches forwarding that onto the DHCP server.
|
|
0:05:55
|
If the switch is running Layer 2 only, it's not going to have an
|
|
0:05:59
|
IP address to insert inside of the gateway address field.
|
|
0:06:05
|
So the information option can tell the DHCP server
|
|
0:06:08
|
who the particular device is that is relaying
|
|
0:06:12
|
which would essentially let them know what particular
|
|
0:06:15
|
pool that I need to do the allocation from.
|
|
0:06:17
|
Now again, the Catalyst 3560 switches are going to do
|
|
0:06:20
|
this whenever we're doing any DHCP snooping
|
|
0:06:23
|
they're going to add the information option
|
|
0:06:25
|
which is DHCP option 82
|
|
0:06:28
|
and if you are combining the IOS DHCP server
|
|
0:06:31
|
implementation with the switch doing DHCP snooping
|
|
0:06:37
|
by default, the DHCP server will deny this request
|
|
0:06:40
|
because it doesn't support the information option that
|
|
0:06:44
|
the switch is inserting.
|
|
0:06:46
|
So when you're doing this, you have to make sure that
|
|
0:06:48
|
there's a compatibility between the device that's doing the
|
|
0:06:51
|
relay and the actual server and ultimately it's going to
|
|
0:06:55
|
depend on what is the particular implementation of the server.
|
|
0:06:58
|
Is it Microsoft Windows DHCP server, or IOS, or some other
|
|
0:07:03
|
implementation?
|
|
0:07:05
|
So typically the server is going to match the pool
|
|
0:07:08
|
based on this gateway address, but if it is a zero value
|
|
0:07:13
|
then potentially it could have problems associating
|
|
0:07:16
|
the pool with it.
|
|
0:07:19
|
Now, in general the configuration of this is going to be fairly
|
|
0:07:22
|
straightforward for DHCP. We're not going to go through
|
|
0:07:25
|
a lot of the examples for this because if you go to the
|
|
0:07:28
|
configuration guide which in this case is going to be under
|
|
0:07:31
|
IP addressing services for DHCP
|
|
0:07:36
|
there's the DHCP server
|
|
0:07:38
|
the DHCP relay and the DHCP client.
|
|
0:07:44
|
For any of these documents
|
|
0:07:47
|
essentially you should know what is DHCP to begin with, so
|
|
0:07:50
|
we don't really need to spend a lot of time looking at what is
|
|
0:07:53
|
the DHCP server, what is it designed to do
|
|
0:07:57
|
instead, you simply want to look at the section that
|
|
0:07:59
|
says how to configure this particular feature
|
|
0:08:02
|
where in case of the DHCP server, we could see it gives us
|
|
0:08:06
|
the individual task list of what we need to do
|
|
0:08:10
|
it says we need to configure the database agent
|
|
0:08:13
|
or disable conflict logging
|
|
0:08:16
|
so this is to make sure that when the router leases
|
|
0:08:18
|
an address out, if it doesn't know that particular binding
|
|
0:08:22
|
so let's say it does a lease and then it reloads
|
|
0:08:26
|
when it goes to lease a new address
|
|
0:08:28
|
the database agent is basically going to keep track
|
|
0:08:31
|
of what are the current leases that are active.
|
|
0:08:34
|
Now technically, you don't even really need this
|
|
0:08:36
|
because when the DHCP server does its allocation
|
|
0:08:39
|
it's going to send an icmp ping
|
|
0:08:42
|
to the address it's trying to lease out, then if it receives
|
|
0:08:46
|
a response back in, it knows not to lease that address.
|
|
0:08:51
|
So typically you would want to exclude the addresses
|
|
0:08:55
|
that you don't want to allocate with the ip dhcp exclude address
|
|
0:08:59
|
so this would be things like the router's address on
|
|
0:09:01
|
the segment or any static servers that you have on that link
|
|
0:09:04
|
but even if you don't do the exclusion, the server
|
|
0:09:09
|
automatically is going to figure out not to assign
|
|
0:09:11
|
those addresses and that's based on the
|
|
0:09:14
|
icmp ping being sent out.
|
|
0:09:18
|
So type of -- options you can modify on the server
|
|
0:09:24
|
also it says, 'Configuring the dhcp allocation using option number 82'
|
|
0:09:28
|
which again is the information option
|
|
0:09:34
|
specifically in this case
|
|
0:09:39
|
it says the relay information and then the actual value
|
|
0:09:44
|
in hex, so we would need to know what is essentially
|
|
0:09:48
|
the Layer 2 device that is doing the relay towards us
|
|
0:09:53
|
which is not really going to be a value that you can
|
|
0:09:55
|
predict, so you'll see some examples of the volume 1 workbook
|
|
0:09:59
|
of this being used on the Layer 2 Catalyst IOS and
|
|
0:10:03
|
the router server together.
|
|
0:10:05
|
There are some ways you can figure this out by
|
|
0:10:07
|
looking at the low-level debugs, but I highly
|
|
0:10:10
|
doubt that they're really going to get this detailed
|
|
0:10:12
|
with the DHCP implementations in the exam.
|
|
0:10:16
|
As long as you understand the basic procedure
|
|
0:10:19
|
of how to configure the server which again, you can
|
|
0:10:22
|
see just from this task list of what you are required to
|
|
0:10:24
|
do essentially just define the pool
|
|
0:10:28
|
then what are the optional things that you can change.
|
|
0:10:33
|
You should be able to just take their configuration example
|
|
0:10:36
|
and then modify it in order to meet your particular needs.
|
|
0:10:41
|
For either the DHCP relay or the DHCP client
|
|
0:10:44
|
these are essentially just going to be single commands
|
|
0:10:47
|
where the DHCP relay is going to be with the
|
|
0:10:49
|
IP helper address, the DHCP client is simply going to be
|
|
0:10:52
|
the ip address dhcp command at the link level.
|
|
0:10:59
|
So let's look at on a basic example of this here
|
|
0:11:05
|
where we will have switch 2
|
|
0:11:08
|
asking for its IP address
|
|
0:11:12
|
through DHCP
|
|
0:11:17
|
and Router 5 is then going to relay this to the server.
|
|
0:11:20
|
We'll say that the server is going to be Router 6
|
|
0:11:26
|
but we essentially have all three features together.
|
|
0:11:28
|
Switch 2 is going to be the DHCP client, Router 5
|
|
0:11:31
|
is going to be the DHCP relay
|
|
0:11:33
|
and Router 6 is going to be the DHCP server.
|
|
0:11:38
|
Now just like our previous NAT configurations that we looked at
|
|
0:11:42
|
keep in mind that the address allocation is separate from
|
|
0:11:44
|
the routing process.
|
|
0:11:47
|
So if the relay doesn't have a route to the server
|
|
0:11:49
|
or the server doesn't have a route back to the pool
|
|
0:11:52
|
that it's trying to allocate or the device that is actually
|
|
0:11:55
|
doing the relay, then we will not be able to unicast
|
|
0:11:59
|
the DHCP discover
|
|
0:12:02
|
which again is going to be the translation from the
|
|
0:12:06
|
broadcast BOOTP request coming from the client
|
|
0:12:09
|
to the unicast relay
|
|
0:12:14
|
then when the server actually sends the DHCP offer
|
|
0:12:17
|
this is going to be a unicast reply.
|
|
0:12:21
|
So routing is going to be separate outside of the scope
|
|
0:12:24
|
of DHCP, we need to make sure we solve that
|
|
0:12:26
|
first before we get into any of the address allocation.
|
|
0:12:29
|
So let's take a look at Router 6 here
|
|
0:12:32
|
and in global config, the first thing that we're going to do for
|
|
0:12:34
|
the server is make sure that the service DHCP is on
|
|
0:12:41
|
which by default, this will be on
|
|
0:12:44
|
but technically it could be disabled which means
|
|
0:12:46
|
that the router is not going to listen for any DHCP discover messages.
|
|
0:12:53
|
Once the service is enabled then we can define the ip dhcp pool
|
|
0:12:58
|
I'll say this is the VLAN 58 pool
|
|
0:13:03
|
and then we specify the individual options.
|
|
0:13:06
|
In general here pretty much the only thing that you would
|
|
0:13:08
|
need is the network
|
|
0:13:10
|
which is the IP address range that the pool is
|
|
0:13:13
|
going to use. In this case, I want the VLAN 58 subnet
|
|
0:13:19
|
which is 155.28.58.0/24
|
|
0:13:28
|
You would typically also want the default gateway address
|
|
0:13:32
|
which in this case they're calling it their default router.
|
|
0:13:34
|
I'll say is Router 5
|
|
0:13:38
|
and whatever our DNS server is.
|
|
0:13:41
|
I'll say that Router 1's loopback is going to be the
|
|
0:13:44
|
DNS server. For any other option like if we were doing
|
|
0:13:49
|
Voice over IP using call manager we can send
|
|
0:13:52
|
the call manager's address to them as the TFTP option
|
|
0:13:57
|
but for these type of configurations you'd have to actually know what the
|
|
0:14:00
|
option number is.
|
|
0:14:03
|
So again, I highly doubt that they're going to
|
|
0:14:06
|
test you on this stuff that you would have to memorize.
|
|
0:14:08
|
If there's any questions on DHCP, you should be able to use
|
|
0:14:12
|
the configuration guide in order to piece together exactly what you need.
|
|
0:14:17
|
Other typical changes here would be what's the amount of the
|
|
0:14:21
|
lease that we can use, so how long is the address going to be
|
|
0:14:24
|
valid for.
|
|
0:14:28
|
There's also an option to say if we are going to ping
|
|
0:14:37
|
the address that we are allocating here
|
|
0:14:42
|
where these would be under the command reference
|
|
0:14:46
|
these are all going to be part of the IP addressing
|
|
0:14:49
|
command reference under DHCP
|
|
0:14:52
|
so if you do get tested on some of these weird options that you
|
|
0:14:55
|
don't know off the top of your head exactly what they are
|
|
0:14:58
|
then just reference the documentation. You should
|
|
0:15:00
|
fairly straightforwardly be able to piece it together from there.
|
|
0:15:04
|
So now Router 6 is listening for that particular allocation
|
|
0:15:07
|
if we look at the routing table, I would need to make sure
|
|
0:15:11
|
I actually have a route back to that 58.0 network
|
|
0:15:15
|
which in this case I do.
|
|
0:15:19
|
On Router 5 I'm going to configure it on its LAN interface
|
|
0:15:23
|
Fast Ethernet 0/0 so that it will relay the DHCP discover
|
|
0:15:30
|
message from switch 2 out to Router 6
|
|
0:15:35
|
So this is simply at the link level the ip helper address
|
|
0:15:41
|
ip helper address is 155.28.146.6
|
|
0:15:47
|
Now technically it doesn't matter what address of the
|
|
0:15:50
|
server this is, I could use Router 6's loopback
|
|
0:15:54
|
I could use any of the interface addresses
|
|
0:15:57
|
because the service DHCP is on which essentially means that
|
|
0:16:01
|
Router 6 is going to be listening for all of its
|
|
0:16:04
|
addresses at that particular port.
|
|
0:16:07
|
Then last thing on switch 2
|
|
0:16:09
|
I'll say on the VLAN interface VLAN 58
|
|
0:16:12
|
my IP address is going to come from DHCP
|
|
0:16:20
|
We could also specify what is the particular
|
|
0:16:21
|
client identifier.
|
|
0:16:25
|
If we leave this as the default
|
|
0:16:29
|
we'll see that it's going to be partially based on the
|
|
0:16:31
|
Mac address, but also a vendor code that goes
|
|
0:16:36
|
into the DHCP discover message.
|
|
0:16:38
|
We see then the logging message comes up
|
|
0:16:41
|
it says the DHCP address was assigned. In this case we've got 58.1
|
|
0:16:45
|
because that's the first address in the pool.
|
|
0:16:48
|
If we look at the show ip interface brief
|
|
0:16:51
|
it should tell us that the method of assignment for the
|
|
0:16:54
|
address is DHCP which is what we want to see.
|
|
0:16:59
|
If we were to look at the low-level debug
|
|
0:17:01
|
we could go to Router 6 who is the server
|
|
0:17:04
|
and debug DHCP detail.
|
|
0:17:09
|
This would be for the client's request.
|
|
0:17:13
|
Since we are the server, I would say debug ip dhcp server events
|
|
0:17:22
|
or packets
|
|
0:17:24
|
Packet is going to be the low-level debug.
|
|
0:17:27
|
On switch 2 I will shut the interface down
|
|
0:17:32
|
and then bring it back up.
|
|
0:17:35
|
On Router 6 additionally I'm going to clear out the
|
|
0:17:37
|
the previous entry.
|
|
0:17:39
|
Actually the client did a DHCP release first.
|
|
0:17:48
|
So we should see once switch 2's interface comes up
|
|
0:17:52
|
Router 6 is going to receive the relay.
|
|
0:17:54
|
We can see it says the relay came from 58.8
|
|
0:17:57
|
or excuse me, 58.5 which is Router 5
|
|
0:18:02
|
The first portion of this is the DHCP discover
|
|
0:18:06
|
where this string here this is the client identifier.
|
|
0:18:11
|
So again, the client identifier is going to be used if you're
|
|
0:18:14
|
using a host pool
|
|
0:18:16
|
to try to give the client a particular address.
|
|
0:18:20
|
But you can see from the format of it, it's not
|
|
0:18:23
|
really obvious as to what this is going to be to begin with.
|
|
0:18:27
|
If we look at the show ip dhcp bindings
|
|
0:18:32
|
we can see either what is the client identifier or the
|
|
0:18:36
|
hardware address
|
|
0:18:38
|
where in this case the switch is using the client ID by default.
|
|
0:18:44
|
So if I were to try to give a specific host allocation
|
|
0:18:47
|
to switch 2, it means that knowing its Mac address is not
|
|
0:18:52
|
really going to help me. I have to know exactly what this client
|
|
0:18:54
|
identifier is.
|
|
0:18:56
|
Now I can't change this and we can see that from switch 2's
|
|
0:19:01
|
command at the interface level which is ip address dhcp
|
|
0:19:04
|
we could specify what the client identifier is
|
|
0:19:08
|
or if not, we can use whatever its default value is.
|
|
0:19:12
|
So on Router 6 I'm going to take this string out
|
|
0:19:17
|
and it essentially needs to be one line
|
|
0:19:24
|
then I'm going to configure a host specific pool
|
|
0:19:28
|
that is for this individual client ID
|
|
0:19:34
|
so we'll have another ip dhcp pool this is
|
|
0:19:37
|
the switch 2 client pool
|
|
0:19:44
|
that is allocating for the host, not for the network
|
|
0:19:47
|
we'll say the host address is 155.28.58.100
|
|
0:19:54
|
but only if they have this specific client identifier.
|
|
0:20:01
|
A binding for this client already exists. I need to
|
|
0:20:03
|
say clear ip dhcp bindings
|
|
0:20:12
|
then if we show run section ip dhcp
|
|
0:20:24
|
since the client pool is part of this VLAN 58 pool
|
|
0:20:28
|
we can configure to import the other options like
|
|
0:20:31
|
the default gateway in the DNS server down to the client pool.
|
|
0:20:36
|
Otherwise, we could specify them separately on a per
|
|
0:20:38
|
client basis, but typically you would specify
|
|
0:20:40
|
all of the global options for that segment under
|
|
0:20:43
|
the global pool
|
|
0:20:46
|
then the individual client are just going to get the
|
|
0:20:48
|
address allocations.
|
|
0:20:56
|
So on switch 2 now let's shut that interface down
|
|
0:21:05
|
then re-enable it. We should see also that log message on
|
|
0:21:08
|
Router 6 that the DHCP release was received from
|
|
0:21:13
|
the client. Basically they're saying I don't need this address
|
|
0:21:16
|
anymore, so you can put it back into the pool.
|
|
0:21:21
|
Then once the DHCP discover message comes in
|
|
0:21:25
|
this particular client identifier matched the host pool that we had
|
|
0:21:31
|
so now we're going to allocate them that .100 address.
|
|
0:21:36
|
On switch 2 we can see that from the log message or
|
|
0:21:38
|
if we look at the show ip interface brief
|
|
0:21:43
|
so again, this depends on who the actual client is
|
|
0:21:46
|
what operating system they're using. Some of them
|
|
0:21:49
|
use the client identifier, some of them use just the hardware address.
|
|
0:21:54
|
And it's a lot easier to figure out what the hardware
|
|
0:21:56
|
address is because that's simply the Mac address of the interface
|
|
0:21:59
|
where the client identifier is going to be the combination
|
|
0:22:02
|
of the Mac address plus some sort of vendor code
|
|
0:22:07
|
then like we saw on Router 6, when you look at the actual
|
|
0:22:09
|
result of this in hex
|
|
0:22:12
|
it's not very easy to read.
|
|
0:22:16
|
So we could manually define it on the client, otherwise,
|
|
0:22:20
|
we could look at what they're dynamically allocating
|
|
0:22:24
|
and then work backwards from there.
|
|
0:22:27
|
So again, any of the other advanced options you
|
|
0:22:29
|
may want to try this out once or twice, but within the
|
|
0:22:32
|
scope of the lab exam, they're not going to expect you to be
|
|
0:22:34
|
an expert of this, so as long as you know
|
|
0:22:36
|
that this is located under the configuring addressing services
|
|
0:22:40
|
then you should be fine. The same is going to be true
|
|
0:22:45
|
of the DNS services
|
|
0:22:48
|
where the router is going to support the DNS client,
|
|
0:22:51
|
the DNS server or a DNS proxy
|
|
0:22:54
|
where the DNS client is enabled by default
|
|
0:22:59
|
but it doesn't have an actual server configured.
|
|
0:23:02
|
So this is why when you mistype a command on the IOS
|
|
0:23:06
|
it's going to send the broadcast request. We can either disable this
|
|
0:23:12
|
with the no ip domain lookup
|
|
0:23:13
|
or actually give it a particular server in order to do the
|
|
0:23:17
|
lookup from.
|
|
0:23:21
|
So let's say in this particular case, we want to configure
|
|
0:23:23
|
Router 1 as the DNS server.
|
|
0:23:27
|
We want the requests to go to Router 1
|
|
0:23:31
|
and then it to have a mapping for let's say Router 3's
|
|
0:23:35
|
loopback, so on Router 1 we simply need to turn the
|
|
0:23:38
|
DNS service on.
|
|
0:23:41
|
We'll say ip dns server
|
|
0:23:47
|
Then the actual bindings are going to be based on the
|
|
0:23:49
|
ip host command, so this would be the fully
|
|
0:23:52
|
qualified domain name in this case, I'll just say r3
|
|
0:23:56
|
has an address of 150.28.3.3
|
|
0:24:04
|
So as you can see in this particular version it basically
|
|
0:24:07
|
supports a full implementation of DNS server where you could put
|
|
0:24:11
|
your mail records, your ns records, so you could use
|
|
0:24:16
|
this as your actual public DNS server.
|
|
0:24:20
|
Another use for this in a small office environment
|
|
0:24:24
|
would be the router on the edge. You can essentially use it
|
|
0:24:27
|
for DNS caching where the router on the edge is
|
|
0:24:31
|
pointing to the public DNS servers, then your internal
|
|
0:24:35
|
clients point at the router.
|
|
0:24:38
|
Then when the request is sent to the router if it doesn't
|
|
0:24:41
|
already have it in the local table, it's going to
|
|
0:24:43
|
query the remote server
|
|
0:24:45
|
and then keep that information cached.
|
|
0:24:48
|
And you would be able to see this when you look at the show ip host
|
|
0:24:52
|
or actually show -- not show ip host, show host.
|
|
0:24:58
|
These are essentially our DNS mappings.
|
|
0:25:03
|
So again, configuration wise it's essentially only two
|
|
0:25:06
|
commands here on Router 1 we simply need to turn the DNS
|
|
0:25:09
|
server on, then specify the host entries.
|
|
0:25:15
|
If we're using this just for DNS caching, the only other thing
|
|
0:25:19
|
we would need on Router 1 is to forward to who the actual
|
|
0:25:22
|
DNS server is, so we would say ip name server and then the destination.
|
|
0:25:29
|
If we were to say this on any of the other routers
|
|
0:25:32
|
let's say on Router 6
|
|
0:25:34
|
that the ip name server is Router 1's loopback
|
|
0:25:44
|
then assuming that the IP domain lookup is on
|
|
0:25:48
|
if I were now to ping R3
|
|
0:25:53
|
we see we get the resolution in from Router 1
|
|
0:25:59
|
Now let's see on switch 2 if it actually learnt this
|
|
0:26:01
|
through DHCP if we ping Router 3
|
|
0:26:09
|
Unrecognized host or protocol not running
|
|
0:26:11
|
this means that DNS lookup is off, so let's say ip domain lookup
|
|
0:26:21
|
then we will ping Router 3 so we could see on switch 2
|
|
0:26:25
|
it did learn the DNS server from the DHCP request
|
|
0:26:33
|
where this is typical in an environment where on your
|
|
0:26:35
|
network edge, the Router is connecting with either
|
|
0:26:39
|
DSL or a cable modem
|
|
0:26:42
|
and it's leasing an address from the service provider
|
|
0:26:45
|
but then hosting it on a local DHCP pool
|
|
0:26:48
|
for the rest of the internal network.
|
|
0:26:51
|
So you can configure the DHCP client to import
|
|
0:26:55
|
those options into the DHCP server service.
|
|
0:27:01
|
This would be under the actual pool if I said
|
|
0:27:03
|
ip dhcp pool then the VLAN 58 pool
|
|
0:27:11
|
I could import what options that I was assigned.
|
|
0:27:17
|
So in the case that I'm both a DHCP client and server
|
|
0:27:20
|
at the same time, whatever options come from my server
|
|
0:27:23
|
I can then forward them down to my clients
|
|
0:27:26
|
and one of those could be the DNS server.
|
|
0:27:29
|
So just like the DHCP, the DNS configuration
|
|
0:27:32
|
should be fairly straightforward. This is documented here under the
|
|
0:27:35
|
IP addressing services, then under DNS
|
|
0:27:39
|
There's also an option for split DNS which would basically
|
|
0:27:43
|
allow you to have entries for your own internal addresses.
|
|
0:27:50
|
But while from the internet they're referenced from their
|
|
0:27:52
|
public addresses.
|
|
0:27:56
|
Then for the regular DNS configuration
|
|
0:28:02
|
essentially you could look at these examples and then just
|
|
0:28:04
|
change them around to match whatever you need.
|
|
0:28:08
|
So here we have the domain name that it's specifying.
|
|
0:28:13
|
IP domain lookup is on.
|
|
0:28:16
|
These are the different servers.
|
|
0:28:22
|
That's our domain name cisco.com
|
|
0:28:27
|
This one is saying doing load balancing through DNS
|
|
0:28:32
|
where when I get a request for company.example.com
|
|
0:28:35
|
there's essentially three servers that are mirrors of each other.
|
|
0:28:39
|
So this is a way that you can do basic load balancing just based
|
|
0:28:41
|
on DNS where when the first request comes in, I'm going to
|
|
0:28:45
|
respond with 10.0.0.1
|
|
0:28:47
|
then I'll respond with 10.1.0.1 and 10.2.0.1
|
|
0:28:50
|
So again, a lot of these configurations for these
|
|
0:28:52
|
minor addressing services DHCP, DNS, the network address translation
|
|
0:28:59
|
make sure you spend some time reading through the
|
|
0:29:02
|
documentation because you don't need to be an expert in this.
|
|
0:29:05
|
You just need to know how to piece the basic configurations
|
|
0:29:08
|
together based on the documentation.
|