DHCP design guidance

Simon Hobson dhcp1 at thehobsons.co.uk
Mon May 21 22:19:38 UTC 2012


Jason Lixfeld wrote:

>As near as I can tell, on the server side, I 
>need a subnet declaration that matches the 
>subnet of the pool from which I want to assign 
>these clients their addresses.  In order to 
>achieve this, and have the DHCP server start, I 
>need an interface in that same subnet on the 
>DHCP server.

No. You need a subnet definition for the local 
network, and a subnet definition for the remote 
network. They must not overlap.

>! Cisco side:
>!
>interface Vlan4000
>  description Client facing
>  ip vrf forwarding Inetv4
>  ip address 10.0.0.1 255.255.255.0
>  ip helper-address vrf management 10.219.51.135
>!

Be aware that adding an ip helper-address also 
turns on a load of other undesirable stuff. So 
you need to turn those off (unless you actually 
want them).

From https://lists.isc.org/pipermail/dhcp-users/2008-July/006832.html
>"By default, the ip forward-protocol udp command enables forwarding for
>ports associated with the following protocols: Trivial File Transfer
>Protocol, Domain Name System, Time service, NetBIOS Name Server, NetBIOS
>Datagram Server, Boot Protocol, and Terminal Access Controller Access
>Control System."
>
>To disable forwarding those protocols that are normally routed:
>no ip forward-protocol udp netbios-ns
>no ip forward-protocol udp netbios-dgm
>no ip forward-protocol udp tacacs
>no ip forward-protocol udp tftp




>[root at dhcp01 ~]# ifconfig | egrep "encap|inet "
>eth0      Link encap:Ethernet  HWaddr 00:0C:29:46:FE:E9
>           inet addr:10.219.51.135  Bcast:10.219.51.159  Mask:255.255.255.224
>eth0:0    Link encap:Ethernet  HWaddr 00:0C:29:46:FE:E9 
>           inet addr:10.0.0.2  Bcast:255.255.255.255  Mask:0.0.0.0
>lo        Link encap:Local Loopback 
>           inet addr:127.0.0.1  Mask:255.0.0.0
>[root at dhcp01 ~]#
>
>
>When I run the server with -d -f:
>
>DHCPDISCOVER from 00:02:71:17:58:bb via 10.0.0.1
>DHCPOFFER on 10.0.0.3 to 00:02:71:17:58:bb via 10.0.0.1
>DHCPDISCOVER from 00:02:71:17:58:bb via 10.0.0.1
>DHCPOFFER on 10.0.0.3 to 00:02:71:17:58:bb via 10.0.0.1
>DHCPDISCOVER from 00:02:71:17:58:bb via 10.0.0.1
>DHCPOFFER on 10.0.0.3 to 00:02:71:17:58:bb via 10.0.0.1
>Š
>Š
>Š
>
>And herein, from my likely ignoramus 
>perspective, lies the problem.  The local 
>interface that I'm using to allow dhcpd to start 
>without it complaining about not having an 
>interface within a configured address range is 
>also the interface that is receiving the 
>discover and sending the offer.  The problem is 
>that this interface actually goes nowhere and is 
>actually just an alias acting as an anchor. 
>Offers directed out this interface will get sent 
>out on the wire which has no knowledge of how to 
>actually reach 10.0.0.0/24.
>
>My impression was that the ip helper-address 
>would write the discovery in such a way where it 
>would send the offer back out the same interface 
>it was received on, but alas..
>
>So I'm left with two conclusions.
>
>1.  I'm ignorant and don't actually understand how this is supposed to work.

What should happen is that the relay agent adds a 
Gateway Interface Address (GIAddr) to the packets 
before forwarding them to the server. The server 
will respond via the gateway.
Because you have configured a bogus local 
interface, packets sent out to 10.0.0.1 are not 
routed via whatever route there is from the 
server (on 10.219.51.135) to the remote switch - 
but instead an attempt is made to deliver them on 
the locally attached network. The packets are 
never received by the switch, so don't get 
forwarded to the client.


Remove eth0:0 and it should work. If not, post 
the full DHCP config and the error message(s) you 
get.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.


More information about the dhcp-users mailing list