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: isc-dhcp 4.4.2-p1 shared-network confusion (Simon)
2. Re: isc-dhcp 4.4.2-p1 shared-network confusion (Philippe Maechler)
----------------------------------------------------------------------
Message: 1
Date: Wed, 6 Jul 2022 19:48:40 +0100
From: Simon <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: isc-dhcp 4.4.2-p1 shared-network confusion
Message-ID: <351701e4-dc96-4059-9d0c-0cbd4a9ac...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Philippe Maechler <plcmaech...@gmail.com> wrote:
> Today we had a little network hiccup which lead me to some confusion about
> our dhcp configs
>
>
> Should a shared-network config, have a subnet section in it?
Generally yes - otherwise it?s a bit redundant !
> how does the dhcpd knows fromm which shared-network the addresses are given
> out? routing-table?
By default, all subnets within a shared network are considered equal. So in
your example, 10.1.1.0/24 and 10.2.1.0/24 are considered equal and a client can
have an address in either subnet. If you need clients to get an address in a
specific subnet/pool then you need to use allow statements to manage that.
If clients have any need to communicate with each other, then you need to
arrange for the router in each subnet to provide a route back out the same
interface back to the other subnet(s) on the network segment.
But in the general case, I?d suggest just making a subnet larger rather than
creating a shared network just to add another subnet for more clients. E.g.
have 10.1.0.0/22 or 10.1.4.0/22 and so on.
> We have to following scenario:
>
> DHCP Server running on a FreeBSD host, which has four network interfaces. On
> the local network there is no dhcpd used, all dhcpd traffic is from
> relay-agents
>
> Networks directly on the server:
> 1.1.1.10/24 for management
> 2.2.2.10/24 for cpe
> 3.3.3.10/24 for voice
> 4.4.4.10/24 for iptv
>
> (I think its easier to talk about 1.1.1.1 and 2.2.2.2 than 10.254.255.0/29
> and so on)
>
> The client networks 6, 7, 10 and 20 are all behind different relay-agents.
>
> renewals from the clients where received on bce2 and the reply went out on
> bce2
> but the discovers from the relay agent arrived on interface bce2 (2.2.2.10)
> and the replies went out on bce3 (3.3.3.10)
> that was not a problem at all until today when a new firewall was deployed
> which had no route/firewalled that traffic.
The server (where clients are relayed rather than directly attached) doesn?t
care which interface the packets arrive on. See below ...
> the problem was solved as soon as we installed the missing route for that
> relay-agent.
>
> but this made me thinking about the pool-selection. in our case, it's mostly
> done by allow-statements
> but for the shared-network part, shouldn't there be at least one physically
> connected interface in the config?
No, the server doesn?t need any subnets or clients directly connected - though
you do need a subnet declaration (can be empty) for all local interfaces the
server listens on (the parser can?t know if you have or haven?t directly
connected clients - so it needs subnet declarations in case you have.
It will probably help to explain how two different types of packets are handled
where a relay is concerned.
Assume a remote client has no lease and connects to the network. It broadcasts
a DHCP-Discover packet which will be picked up by any locally attached DHCP
servers or relay agents. In your case, it?s picked up by a relay agent. So that
the server knows where the client is, the relay agent inserts the IP address
(or, **an** IP address) which is attached to the interface it received the
broadcast packet on into the forwarded packet, in the GI-Addr (Gateway
Interface Address) field. Note that the relay agent does not have to be within
a router - but for convenience they typically are.
The relay agent then sends the modified packet, typically via unicast, to the
server address(es) it?s been configured with. Based on the GI-Addr, the server
picks a suitable subnet/shared network and then applies any rules (such as
allow statements in pools) in order to pick an address to offer the client.
Assuming it was able to allocate an address, the server then sends a response
by unicast to the GI-Addr. The relay agent then broadcasts the packet on it?s
local network where the client will pick it up.
The same process follows for the DHCP-Request, DHCP-Ack exchange.
You will see that the key things here are :
The relay agent has an IP address in the same shared-network as the client -
this is one use for a shared network, allowing the relay agent to use (e.g.)
separate management addresses to those used by the clients.
There must be routing in place that allows packets from the relay agent to the
server(s), and from the servers to the GI-Addr of the relay agent.
Once a client has a working lease, then things change.
When the lease needs renewing (by default, when it?s half way through) then the
client unicast a packet directly to the server address from which it received
the lease. Note that this can be any address the server possesses, and it?s a
configurable option. The server will unicast a response back to the client. The
relay agent is not involved at all.
For this to work, there must be routing in place for unicast packets from the
client to the server and from the server to the client. It sounds like you did
not have this in place when you had the hiccup.
The dhcp server process doesn?t care about packet routing. It simply receives
packets via the OS network stack, and it sends packets out via the network
stack - thus using whatever routing rules the OS has in place.
>
> The configuration dhcpd.conf network part is:
>
> # define local networks and suppress an error/warning at startup
> subnet 1.1.1.0 netmask 255.255.255.0 {
> # no dhcpd service in this subnet
> }
> subnet 2.2.2.0 netmask 255.255.255.0 {
> # no dhcpd service in this subnet
> }
> subnet 3.3.3.0 netmask 255.255.255.0 {
> # no dhcpd service in this subnet
> }
> subnet 4.4.4.0 netmask 255.255.255.0 {
> # no dhcpd service in this subnet
> }
>
> subnet 6.6.6.0 netmask 255.255.255.0 {
> option routers 6.6.6.1;
> option subnet-mask 255.255.255.0;
> pool {
> range 6.6.6.10 6.6.6.254;
> allow members of "cpes";
> deny dynamic bootp clients;
> }
> }
>
> subnet 7.7.7.0 netmask 255.255.255.0 {
> option routers 7.7.7.1;
> option subnet-mask 255.255.255.0;
> pool {
> range 7.7.7.10 7.7.7.254;
> allow members of "voice";
> deny dynamic bootp clients;
> }
> }
>
> shared-network ?abc? {
> subnet 10.1.1.0 netmask 255.255.255.0 {
> option routers 10.1.0.1;
> option subnet-mask 255.255.255.0;
> pool {
> range 10.1.0.10 10.1.0.254;
> allow members of "iptv-group1";
> deny dynamic bootp clients;
> }
> }
> subnet 10.2.1.0 netmask 255.255.255.0 {
> option routers 10.2.0.1;
> option subnet-mask 255.255.255.0;
> pool {
> range 10.2.0.10 10.2.0.254;
> allow members of "iptv-group1";
> deny dynamic bootp clients;
> }
> }
> }
>
> shared-network ?xyz? {
> subnet 20.1.1.0 netmask 255.255.255.0 {
> option routers 20.1.0.1;
> option subnet-mask 255.255.255.0;
> pool {
> range 20.1.0.10 20.1.0.254;
> allow members of "iptv-group2";
> deny dynamic bootp clients;
> }
> }
> subnet 20.2.1.0 netmask 255.255.255.0 {
> option routers 20.2.0.1;
> option subnet-mask 255.255.255.0;
> pool {
> range 20.2.0.10 20.2.0.254;
> allow members of "iptv-group2";
> deny dynamic bootp clients;
> }
> }
> }
Assuming that 10.1.1.0/24 and 10.2.1.0/24 are both on the same network segment
(same bit of wire); and 20.1.1.0/24 and 20.2.1.0/24 are both on the same
network segment - but a different one to the 10.1.1.0 & 10.2.1.0 one; then
things should just work automagically as long as you have the right routing in
place.
Simon
------------------------------
Message: 2
Date: Wed, 6 Jul 2022 21:11:17 +0200
From: Philippe Maechler <plcmaech...@gmail.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: isc-dhcp 4.4.2-p1 shared-network confusion
Message-ID:
<CAPhukgYPPtnSXqNXins+LjD=VC8tkobARo1HTJWP-Wu=5xu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Simon, Hi list
Oh boy.. I shouldn't write messages to the mailing list while under stress
because there is a meeting scheduled. My text somehow got "confusing" :)
But thank you Simon, you mostly understood my right.
The key part of my question is:
> The relay agent then sends the modified packet, typically via unicast, to
the server address(es) it?s been configured with.
> Based on the GI-Addr, the server picks a suitable subnet/shared network
and then applies any rules (such as allow statements in pools) in order to
pick an address to offer the client.
How will the GI-Addr have an impact on the pool selection?
In my example the two shared networks (abc and xyz) are equal. Are they
also equal to the subnets 6.6.6.0/24 and 7.7.7.0/24 ?
Did I got this right? The server picks a suitable subnet/shared-network
(which in my case can be from anything from the defined subnets with a
pool) and then applies the allow- and deny rules?
I guess, when a deny rule applies, the server will just pick the next
subnet/shared-network, applies the rules and so on until there is either an
allow-case or there are no subnet/shared networks left
(For simplicity we ignore that there can be full pools :) )
/BR
Philippe
On Wed, 6 Jul 2022 at 20:48, Simon <dh...@thehobsons.co.uk> wrote:
> Philippe Maechler <plcmaech...@gmail.com> wrote:
>
> > Today we had a little network hiccup which lead me to some confusion
> about our dhcp configs
> >
> >
> > Should a shared-network config, have a subnet section in it?
>
> Generally yes - otherwise it?s a bit redundant !
>
> > how does the dhcpd knows fromm which shared-network the addresses are
> given out? routing-table?
>
> By default, all subnets within a shared network are considered equal. So
> in your example, 10.1.1.0/24 and 10.2.1.0/24 are considered equal and a
> client can have an address in either subnet. If you need clients to get an
> address in a specific subnet/pool then you need to use allow statements to
> manage that.
> If clients have any need to communicate with each other, then you need to
> arrange for the router in each subnet to provide a route back out the same
> interface back to the other subnet(s) on the network segment.
>
> But in the general case, I?d suggest just making a subnet larger rather
> than creating a shared network just to add another subnet for more clients.
> E.g. have 10.1.0.0/22 or 10.1.4.0/22 and so on.
>
> > We have to following scenario:
> >
> > DHCP Server running on a FreeBSD host, which has four network
> interfaces. On the local network there is no dhcpd used, all dhcpd traffic
> is from relay-agents
> >
> > Networks directly on the server:
> > 1.1.1.10/24 for management
> > 2.2.2.10/24 for cpe
> > 3.3.3.10/24 for voice
> > 4.4.4.10/24 for iptv
> >
> > (I think its easier to talk about 1.1.1.1 and 2.2.2.2 than
> 10.254.255.0/29 and so on)
> >
> > The client networks 6, 7, 10 and 20 are all behind different
> relay-agents.
> >
> > renewals from the clients where received on bce2 and the reply went out
> on bce2
> > but the discovers from the relay agent arrived on interface bce2
> (2.2.2.10) and the replies went out on bce3 (3.3.3.10)
> > that was not a problem at all until today when a new firewall was
> deployed which had no route/firewalled that traffic.
>
> The server (where clients are relayed rather than directly attached)
> doesn?t care which interface the packets arrive on. See below ...
>
> > the problem was solved as soon as we installed the missing route for
> that relay-agent.
> >
> > but this made me thinking about the pool-selection. in our case, it's
> mostly done by allow-statements
> > but for the shared-network part, shouldn't there be at least one
> physically connected interface in the config?
>
> No, the server doesn?t need any subnets or clients directly connected -
> though you do need a subnet declaration (can be empty) for all local
> interfaces the server listens on (the parser can?t know if you have or
> haven?t directly connected clients - so it needs subnet declarations in
> case you have.
>
> It will probably help to explain how two different types of packets are
> handled where a relay is concerned.
>
> Assume a remote client has no lease and connects to the network. It
> broadcasts a DHCP-Discover packet which will be picked up by any locally
> attached DHCP servers or relay agents. In your case, it?s picked up by a
> relay agent. So that the server knows where the client is, the relay agent
> inserts the IP address (or, **an** IP address) which is attached to the
> interface it received the broadcast packet on into the forwarded packet, in
> the GI-Addr (Gateway Interface Address) field. Note that the relay agent
> does not have to be within a router - but for convenience they typically
> are.
> The relay agent then sends the modified packet, typically via unicast, to
> the server address(es) it?s been configured with. Based on the GI-Addr,
> the server picks a suitable subnet/shared network and then applies any
> rules (such as allow statements in pools) in order to pick an address to
> offer the client.
> Assuming it was able to allocate an address, the server then sends a
> response by unicast to the GI-Addr. The relay agent then broadcasts the
> packet on it?s local network where the client will pick it up.
> The same process follows for the DHCP-Request, DHCP-Ack exchange.
>
> You will see that the key things here are :
> The relay agent has an IP address in the same shared-network as the client
> - this is one use for a shared network, allowing the relay agent to use
> (e.g.) separate management addresses to those used by the clients.
> There must be routing in place that allows packets from the relay agent to
> the server(s), and from the servers to the GI-Addr of the relay agent.
>
> Once a client has a working lease, then things change.
> When the lease needs renewing (by default, when it?s half way through)
> then the client unicast a packet directly to the server address from which
> it received the lease. Note that this can be any address the server
> possesses, and it?s a configurable option. The server will unicast a
> response back to the client. The relay agent is not involved at all.
> For this to work, there must be routing in place for unicast packets from
> the client to the server and from the server to the client. It sounds like
> you did not have this in place when you had the hiccup.
>
> The dhcp server process doesn?t care about packet routing. It simply
> receives packets via the OS network stack, and it sends packets out via the
> network stack - thus using whatever routing rules the OS has in place.
>
> >
> > The configuration dhcpd.conf network part is:
> >
> > # define local networks and suppress an error/warning at startup
> > subnet 1.1.1.0 netmask 255.255.255.0 {
> > # no dhcpd service in this subnet
> > }
> > subnet 2.2.2.0 netmask 255.255.255.0 {
> > # no dhcpd service in this subnet
> > }
> > subnet 3.3.3.0 netmask 255.255.255.0 {
> > # no dhcpd service in this subnet
> > }
> > subnet 4.4.4.0 netmask 255.255.255.0 {
> > # no dhcpd service in this subnet
> > }
> >
> > subnet 6.6.6.0 netmask 255.255.255.0 {
> > option routers 6.6.6.1;
> > option subnet-mask 255.255.255.0;
> > pool {
> > range 6.6.6.10 6.6.6.254;
> > allow members of "cpes";
> > deny dynamic bootp clients;
> > }
> > }
> >
> > subnet 7.7.7.0 netmask 255.255.255.0 {
> > option routers 7.7.7.1;
> > option subnet-mask 255.255.255.0;
> > pool {
> > range 7.7.7.10 7.7.7.254;
> > allow members of "voice";
> > deny dynamic bootp clients;
> > }
> > }
> >
> > shared-network ?abc? {
> > subnet 10.1.1.0 netmask 255.255.255.0 {
> > option routers 10.1.0.1;
> > option subnet-mask 255.255.255.0;
> > pool {
> > range 10.1.0.10 10.1.0.254;
> > allow members of "iptv-group1";
> > deny dynamic bootp clients;
> > }
> > }
> > subnet 10.2.1.0 netmask 255.255.255.0 {
> > option routers 10.2.0.1;
> > option subnet-mask 255.255.255.0;
> > pool {
> > range 10.2.0.10 10.2.0.254;
> > allow members of "iptv-group1";
> > deny dynamic bootp clients;
> > }
> > }
> > }
> >
> > shared-network ?xyz? {
> > subnet 20.1.1.0 netmask 255.255.255.0 {
> > option routers 20.1.0.1;
> > option subnet-mask 255.255.255.0;
> > pool {
> > range 20.1.0.10 20.1.0.254;
> > allow members of "iptv-group2";
> > deny dynamic bootp clients;
> > }
> > }
> > subnet 20.2.1.0 netmask 255.255.255.0 {
> > option routers 20.2.0.1;
> > option subnet-mask 255.255.255.0;
> > pool {
> > range 20.2.0.10 20.2.0.254;
> > allow members of "iptv-group2";
> > deny dynamic bootp clients;
> > }
> > }
> > }
>
> Assuming that 10.1.1.0/24 and 10.2.1.0/24 are both on the same network
> segment (same bit of wire); and 20.1.1.0/24 and 20.2.1.0/24 are both on
> the same network segment - but a different one to the 10.1.1.0 & 10.2.1.0
> one; then things should just work automagically as long as you have the
> right routing in place.
>
>
> Simon
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20220706/9e124bfd/attachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 165, Issue 3
******************************************
