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