Tony Finch <
[hidden email]> wrote:
> I look after some DHCP servers which handle about 150 subnets, and the
> dhcpd.conf doesn't know anything about VLANs, only the network ranges -
> it's mostly a collection of subnet{} clauses.
Yes, as I was trying to explain to Alexander, Option 82 is not needed at all for DHCP to work.
> Our network configuration is handled by my colleagues, so I'm vague about
> the details. But my understanding is that DHCP relaying is configured on
> the routers. Normal DHCP requests are broadcasts, so they are limited to
> the local subnet, relaying allows the request to be forwarded to a DHCP
> server on a different subnet. So relaying is logically a router function
> rather than a switch function.
Correct - switches play no part in DHCP, the Relay Agents do and they are usually configured in the routers
> What I'm vague about is the more complicated stuff on the switches related
> to MAC security and DHCP snooping, and whether that messes with DHCP more
> than I would expect...
It shouldn't mess with DHCP. The snooping allows the switch to determine the IP address assigned to the attached device and so filter any other addresses and attached device might try to use.
Александр Сандецкий <
[hidden email]> wrote:
> Basic network services topology assumes that DHCP server exist in every network segment. In every VLAN in my case. It can be separate servers in network segments or single server with network interfaces gor every network. Or every VLAN configured on the server. This is a simple and clear idea. But in some cases it's not good (need to configure lot of vlans for ex.). But DHCP service offers the relaying technology.
Correct so far.
> With combination of Option 82 it's common practice to setup single server with single network interface for DHCP. Option 82 can be used to classify clients by the switch (agent IP or MAC), by the switch port, by the vlan, etc.
No, Option 82 plays no part whatsoever in DHCP operations - unless you specifically need a complex setup. Given the problems you are experiencing, I would suggest that such a setup is beyond you at the moment - so get the basics working first, and only then look into more complicated stuff like using Option 82.
> Relaying assumes the dhcp query comes not from original device and original network segment but from some managed switch where client connected. With some additional information for identifying client and swithc.
NO, this is incorrect. Relaying requires a relay agent ANYWHERE in the broadcast domain for a network/subnet - which in this case is all the ports configured to a specific VLAN. As I've written already, this is usually configured in the router for convenience but this is not actually a requirement.
So for each VLAN, you need to configure a Relay agent to service that VLAN and forward the broadcast packets from client to server and back. The Relay Agent does not need to know anything whatsoever about the topology of the network - only have a direct connection and IP appropriate to the client network, and know the IP address(es) of the DHCP server that services the client network. Option 82 is not in any way involved with this.
> My idea is to not to configure every vlan on the server.
As above, you do not need to. Just configure a Relay Agent on any VLAN to which the server is not connected.
So to recap, this is what you need.
Your DHCP server, with a config which is as simple as :
# VLAN 3000
subnet 172.18.0.0 ... {
router 172.18.0.1 ;
range 172.18.0.10 172.18.0.200 ;
}
# VLAN 3010
subnet 172.18.10.0 ... {
router 172.18.10.1 ;
range 172.18.10.10 172.18.10.200 ;
};
and so on for each VLAN/subnet in your network.
For every subnet to which the server is not directly connected, configure a relay agent. The syntax for this varies according to the vendor/OS, for example on Cisco IOS you'd have :
ip helper-address a.b.c.d
But see
https://lists.isc.org/pipermail/dhcp-users/2008-July/006832.html and if you enable a helper-address, you really need to disable a load of other stuff that gets forwarded by default - but be aware that things may have changed since I last dealt with Cisco stuff :
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
And that's it ! DHCP should work across the whole network with just these few ingredients.
Simon
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Locked
