Klaus Steden wrote:
> ... but even then, we're still stuck with the same problem -- we don't know,
> aren't told, and can't predict what the next relay IP will be, or to which
> subnet it will be assigned. What a pisser. :-(
And that is a problem that can’t be solved with technology - except
Hello Simon,
Thank you for demystifying this.
FWIW we are already using MySQL to store lease and reservation data, and we
built an API to manage leases and reservations years ago that is also
integrated with our config management service, which we use to update the
Kea config (e.g.,
Klaus Steden wrote:
> … so it’s been an uphill battle just to push for basic changes like "let's
> use one DHCP server for multiple subnets instead of standing up a separate
> local DHCP server on each subnet because L3 is not actually that complicated".
I guess you can be grateful for the
Klaus,
My suggestion only works if there is a pattern to the way the relay
IPs are chosen. Specifically, if they are grouped together such that
they COULD be subnetted, but are not on the switch side. You would be
pretending (on the Kea side) that they are. Then you could add these
subnets as
Hello Darren,
Could you elaborate a bit on what you mean? We are already using the
shared-networks configuration pattern, although in our use case, relay IPs
are scoped to all subnets, not specifically assigned to each subnet
individually. Here's the relevant section of our Kea config file:
"""
Hello Simon,
Unfortunately, while my team has argued that this is, in fact, bad network
design ... that fell on deaf ears, so we're stuck with this design for the
foreseeable future, and "having to manually configure something" seems to
me to be a feature, not a bug, in the eyes of management. We
Klaus Steden wrote:
> FWIW, my team had no input into the network design process, we just got
> saddled with a bespoke implementation and have been adapting as we go.
Ah, the joys of inheriting someone else’s “bright idea”.
> This is the basic model:
>
> - an instance of Kea behind a single
Klaus,
If your relays fallin a known CIDR per subnet(s) in a shared network,
then you can add a "subnet" to the shared network with no pool that is
just for the relays and dispense with the relays parameter. It
doesn't even have to be a real subnet. example:
Network "A" is 10.1.2.0/24 and
On Fri, Feb 24, 2023, at 07:11, Klaus Steden wrote:
>
> Correct, I am currently listing all relay IPs individually. It seems to be
> the case that by using the shared-network parameter and defining my DHCP
> pools within that context that I only have to include the list of relays
> once, and
Hi Darren,
Correct, I am currently listing all relay IPs individually. It seems to be
the case that by using the shared-network parameter and defining my DHCP
pools within that context that I only have to include the list of relays
once, and then requests from any of these relay IPs are processed
Klaus,
Then my proposed solution will not work (assuming there is only one
subnet for the relay agent source ip). It seems that you will need to
list each address anyway since they could be all over the place?
Hypothetical example:
relay 10.1.2.1 might be a relay source for network "A"
relay
Correct.
Hypothetical networks "A" and "B" do not share a broadcast domain.
cheers,
Klaus
On Thu, Feb 23, 2023 at 2:57 AM Darren Ankney
wrote:
> Hi Klaus,
>
> So to be clear (with a hypothetical example), 192.168.120.16 might
> need to serve distinct network "A" with one or more subnets and
>
Hi Klaus,
So to be clear (with a hypothetical example), 192.168.120.16 might
need to serve distinct network "A" with one or more subnets and
192.168.120.17 might need to serve distinct network "B" with other
subnets. These "distinct" networks do not share the same broadcast
domain?
On Wed, Feb
Hello all,
Thanks for the responses, and sorry for the ambiguity in my original
question, so I'll try to clarify. FWIW, my team had no input into the
network design process, we just got saddled with a bespoke implementation
and have been adapting as we go.
This is the basic model:
- an instance
Darren Ankney wrote:
> In addition to what Peter said, another option would be to use shared
> networks and add the subnet for relays along with the subnet of
> addresses that you wish to allocate to the clients to a shared
> network. See:
>
Hello Klaus,
In addition to what Peter said, another option would be to use shared
networks and add the subnet for relays along with the subnet of
addresses that you wish to allocate to the clients to a shared
network. See:
Hi Klaus,
I don't think I understand your use case, but Kea's
"relay.ip-addresses" list can contain as may IP addresses as you wish.
If you do not wish to fill your configuration file up with long lists of
IP addresses you can use include files, as:
"relay": ,
Kind Regards Peter
Hi there,
In some of our environments, we deal with DHCP relays, and their addresses
seem to proliferate faster than we can update our configs, which leads to
delays with DHCP service.
However, they have reserved an entire /21 for relay IPs, and ideally, I
would like to be able to add that
18 matches
Mail list logo
