Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: Option 82 problem (Tony Finch)
2. Re: Option 82 problem (Simon Hobson)
----------------------------------------------------------------------
Message: 1
Date: Sat, 18 Apr 2020 18:08:45 +0100
From: Tony Finch <d...@dotat.at>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Option 82 problem
Message-ID: <alpine.deb.2.20.2004181755290.29...@grey.csi.cam.ac.uk>
Content-Type: text/plain; charset="utf-8"
????????? ????????? <alexander.sandet...@gmail.com> wrote:
> But DHCP service offers the relaying technology. 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.
>
> 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.
>
> My idea is to not to configure every vlan on the server.
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.
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.
We also use option 82, but the DHCP servers only use it to log information
about which switch an port number corresponds to which DHCP requests, not
for anything that determines the server's responses. So option 82 is
inserted by our switches, and logically unrelated to relaying.
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...
Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
democracy, participation, and the co-operative principle
------------------------------
Message: 2
Date: Sat, 18 Apr 2020 21:16:11 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Option 82 problem
Message-ID: <27be8ff0-218d-4ec5-b4e6-c18f194bd...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Tony Finch <d...@dotat.at> 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.
????????? ????????? <alexander.sandet...@gmail.com> 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
------------------------------
Subject: Digest Footer
_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 138, Issue 10
*******************************************
