Answers: Remote DHCP Server 1
Centralized DHCP Server? Check. Remote clients have reachability to the server, and can lease addresses? Check. Are you sure – even if you could not test the function in a lab? Build some configuration confidence, and if you have time, set this one up in lab, and make sure you confirm that DHCP works. Check out the requirements first, as usual!
Answers
Figure 1: Remote DHCP Topology
Example 5: R1 Config
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
ip dhcp excluded-address 172.30.2.1 ip dhcp excluded-address 172.30.1.1 ! ip dhcp pool One network 172.30.1.0 255.255.255.0 default-router 172.30.1.1 domain-name example.com dns-server 172.30.3.8 172.30.3.9 lease 1 2 3 ! ip dhcp pool Two network 172.30.2.0 255.255.255.0 default-router 172.30.2.1 domain-name example.com dns-server 172.30.3.8 172.30.3.9 lease 1 2 3 |
Example 6: R2 Config
|
1 2 3 |
! interface GigabitEthernet0/2 ip helper-address 172.30.3.1 |
Example 7: R3 Config
|
1 2 3 |
! interface GigabitEthernet0/2 ip helper-address 172.30.3.1 |
Commentary
The configuration of DHCP for remote devices is a bit more complex. You must know the interface on the remote router where the DHCP client is connected and know an IP address for the DHCP server. When a router (or switch) is acting as a DHCP server, then any of the IP addresses that are reachable from the remote router can be used. This information is used to configure the ip helper-address command on the remote routers; this command enables the remote router to act as a DHCP proxy and relay all DHCP packets (via unicast) to the DHCP server.
For this lab, you were tasked with configuring R1 to act as a DHCP server for R2 and R3’s LAN networks. The IP subnets for the DHCP server to use are shown in the figure and include the 172.30.1.0/24 (R2 and PC2) and 172.30.2.0/24 (R3 and PC3) networks. The default gateways to use are shown configured on R2 (172.30.1.1) and R3 (172.30.2.1), respectively.
The DHCP server configuration requires two different DHCP pools because two different subnets will each use different default gateway settings. The requirements state that the pools should be called One and Two. The command to create a new or configure an existing DHCP pool is ip dhcp pool pool-name. To create the first DHCP pool, use the ip dhcp pool One command. This will place you into DHCP pool configuration mode; it is in this mode where you configure the options to be issued to the client.
The first subnet (172.30.1.0/24) is connected to R2’s G0/2 interface. To configure this subnet in the DHCP server, use the network 172.30.1.0 255.255.255.0 command. The default-router 172.30.1.1 command then defines the default gateway setting for that pool. Requests from clients that arrive at the DHCP server, from addresses in the range implied by the network command, will be served from this pool.
Similarly, the other subnet (172.30.2.0/24) is connected to R3’s G0/2 interface. To configure this subnet in the DHCP server, use the network 172.30.2.0 255.255.255.0 command. The default-router 172.30.2.1 command then defines the default gateway setting for that pool.
Both pools use the same settings for the domain name, DNS server, and lease time in this case.
Finally, with a centralized DHCP server, the remote routers must enable the DHCP relay agent feature on the interfaces in which DHCP requests will flow. In this case, that means R2’s G0/2 and R3’s G0/2 interfaces. To enable the feature, R2 uses the ip helper-address 172.30.3.1 command under it’s G0/2 interface; the same configuration is used on R3.
Thank you sir!
Thanks a lot Sir!
HI Dear Wendell Odom
I just have question that is the SW1 is a layer2 switch or layer2 switch enabled to forward ipv4 packets?
if it’s just layer2 switch the question is it’s function is just to look at destination mac addresses and then forward them for instance to R1 ?? or we should enable the feature of forwarding ipv4 packets on SW1 to do forwarding to R1(DHCP Server) ?
tnx for your answer
Whenever you see a switch in the context of a CCNA R&S question, if the question gives no clues as to whether it’s a L2 or L3 switch, I’d suggest you can assume that it is an L2 switch. The vast majority of CCNA R&S topics are about L2 switching. That’s certainly the case for this particular post. Hope this helps,
Wendell
Hello,
I am a little bit confused with the command ip helper-address 172.16.3.1 on R2 and R3. Shouldn’t that supposed to be different since 172.16.3.1 is the DNS IP address?
Thanks in advance for your answer
Hello,
Probably this is posted twice. I am a little bit confused with the ip helper-address 172.16.3.1 command on R2 and R3. That is the IP address of the DNS and not the DHCP server, right?
Thanks in advance for your answer.
Hi Apostolos,
Both your posts made it! On a side note, I’m changing the comment feature in the blogs in a few weeks, with a change that should make it quicker for your comments to show up. I don’t let your comments show up immediately because if I do that the site becomes overrun by SPAM, and becomes unusable.
That said…
The helper address points to the IP address of the DHCP server. The router does not need to know the IP address of the DNS server, at least for the purposes of supporting end user traffic.
And to your first post, the helper address would often point to the same IP address. That would be true with a centralized DHCP server that serves multiple subnets, which is frankly the more common implementation as compared to distributed DHCP servers.
Hope this helps.
Wendell
Hello dear Wendell!
I’m sorry to keep bothering you, but I am also confused with your answer!
in this question’s related ‘question’ post, both the Topology and the initial configurations all point to 172.30.x.x networks.
The only time you refer any 172.16.x.x IP is related to the DNS server.
Shouldn’t R1 have excluded addresses of 172.30.1.1 and .2.1 instead of 172.16.2.1 and .3.1?
And, shouldn’t R2 and R3 ip helper-address be 172.30.3.1 instead?
Again, thank you for your time with this topic!
+1
Hi Ruben,
now I understand your question. I just totally ignored the first two octets when reviewing the posts. Yep, I randomly mixed and matched the addresses/subnets between 172.16 and 172.30. i’ve just updated both posts to use 172.30 only. Thanks for the follow up to help me improve the lab!
Wendell
Hello Wendell!
should i make 2 vlan2 on SW, then Make ROAS on R1 ?
Nah. Just put all 3 ports on switch SW1 in the same VLAN, so that all three routers are in the same VLAN. Note that they are all in the same subnet. Then, the router configs in the lab post should be all you need.
In other words, a switch with all defaults, with all three ports in VLAN 1, would work just fine.
Wendell
Thanks Wendell…and thank you again for your interesting book. Its very usefull
🙂
What the
“ip dhcp excluded-address 172.30.3.1”
statement is for?
Why the 172.30.3.1 address is being excluded?
Hi Hector,
Should’ve been 172.30.1.1, rather than 3.1. Point being to exclude the default router IP addresses in the DHCP client subnets. Fixed. Thanks for helping me clean up the labs.
Wendell
Hello Wendell,
I configure this lab on packet tracer and I could not make it work unless I connect the router and the PC via a switch, otherwise I get the up/down error for R2/3’s G0/2 interface. I was wondering what I am missing?
Neg,
Sorry, can’t help with PT issues – maybe ask through whatever support structure might be offered through your Network Academy class.
For some reason this set up just wasn’t working for me me in PT. Scrapped it, started from scratch and got it working. 🙂
Hello Wendell, I was practicing this lab in PT, and everything got OK at the end, but I noticed that the PCs discovery and request messages had a source ip address of 169.254.x.x (local link addresses) instead of 0.0.0.0.
Of course, after the simulation all the PCs obtained their IPs from the router DHCP server.
But I wonder why the PCs initially had this behavior, and also I want to know if that often happens on real gear?
Hi Marcelo,
Couple of points:
DHCP has several options that can be chosen by the client that impact what addresses (layers 2 and 3) are used at the various stages of the DHCP process. It could be that PT, as a simulator, is choosing to use one that say a windows host wouldn’t. I recently had a reader question in this same general discussion area, comparing something they saw in an Academy class. So it could be that the Academy took a different tack. If you’re a legit Academy user of PT, you might inquire through your Academy instructor’s channels.
In my experience, modern clients do use the DHCP broadcast bit, and a source IP of 0.0.0.0 until it starts using the leased address.
Finally, it could be an issue of timing. Normally, the 169.254 address is user after the DHCP attempt times out. So, you might try again if you can power off and then on the PC without doing the same to your DHCP server etc, to see if it uses 0.0.0.0.
Wendell
hello Sir…
I do this lap without ‘routing protoco(RIP)’ configration on three router, so the PCs are failed to leasing an ip address, with all other configration applied and correct, and i test to reach DHCP-SERVER from other two router and successed to reached it ,
SO the point is why we need routing protocol there??
thanks
Raed,
First, let me clarify the details of your comment. In your testing, you:
1) Attempted a DHCP Lease from PC2 and PC3, and those failed.
2) Issued a ping command from the CLI of routers R2 and R3? For… 172.30.3.1? I’m guessing.
Answer back with more detail, and I can try and answer more specifically.
In the mean time, a broad answer:
The routers need routes to forward any of the packets, data packets or for overhead protocols like DHCP. For the PC2/3 DHCP requests, the source IP addresses will be 172.30.1.1 and 172.30.2.1 (the LAN interface IP address in the subnet where the PCs reside.) So R1 needs a route with which to forward packets back to those addresses, and without a routing protocol or static route, it won’t have any. Then, a ping test from R2 and R3, to 172.30.3.1 (the WAN IP address of R1), well all three routers are connected to that same WAN subnet, so they all have a route to that subnet without running a routing protocol. A better test from the R2/R3 CLI would be an extended ping, with source interface G0/2, which makes the ping packets use source addresses 172.16.1.1 and 172.16.2.1, respectively.
Hope this helps…
Wendell