Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?
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 perhaps some very ancient technology known as a piece of clue-by-four (http://www.catb.org/jargon/html/C/clue-by-four.html) :D So many times one’s mind is quietly saying “if only we could and get away with it ...” Simon -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?
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., adding/changing/removing pools), so it's already a pretty
closed loop.
I could modify the API code to include the address of the relay in each
subnet declaration (I did some experiments with this several weeks ago,
when we were initially exploring solutions to the problem, and that worked
fine), 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. :-(
It sounds like I will have to circle back with the network team and hammer
out something better; one bright spot is that they're at least using an
IPAM that has an API, and it *may* be possible to codify some kind of
association between subnets and their relays. Then it becomes less of a
management problem, and more of a programming one.
thanks!
Klaus
On Thu, Mar 2, 2023 at 8:59 AM Simon wrote:
> 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 little wins !
>
> > To answer your questions:
> >
> > 1. yes, each distinct subnet has a distinct relay IP that is not reused
> by the other subnets
> > 2. yes, all of the relay IPs are part of a specific subnet (iirc it's a
> /21 or /22), although I don't know if there's a pattern to how relay IPs
> are chosen (sequentially? randomly? stepwise? etc.) from this subnet
>
> OK, so some good news then.
>
> > And yes, there have been a lot of "interesting times" so far.
>
> I bet :-(
>
> > FWIW, this is the relevant section of my Kea4 config file:
> >
> > """
> > "shared-networks": [
> > {
> > "name": "iad1",
> > "relay": {
> > "ip-addresses":
> > },
> > "subnet4": [
> >
> > ]
> > }
> > ],
> > """
>
> That’s not going to work. That says “all of the subnets, and all of the
> relay addresses, are in one big shared network. As I understand KEA config,
> you need :
> "shared-networks": [
> {
> "name": “VLAN57",
> "subnet4": [
> {
> "subnet": “192.168.120.66/32",
> },
> {
> "subnet": "192.0.57.0/24",
> "pools": [ { "pool": "192.0.57.100 - 192.0.57.199" } ]
> "option-data": [
> {
> "name": "routers",
> "data": "192.0.57.1"
> } ]
> }
> ]
> },
> {
> "name": “VLAN123",
> "subnet4": [
> {
> "subnet": “192.168.120.250/32",
> },
> {
> "subnet": "192.0.123.0/24",
> "pools": [ { "pool": "192.0.123.100 - 192.0.123.199" } ]
> {
> "name": "routers",
> "data": "192.0.123.1"
> } ]
>
> }
> ]
> }
>
> ],
>
> Yes, it’s going to be one right p.i.t.a. to manage.
> What that says is that if you receive a relayed packet from the subnet
> 192.168.120.66/32 then treat it as including clients from subnet
> 192.0.57.0/24 as well. Since there is no pool for the 192.168.120.66/32
> subnet, then only addresses from the 192.0.57.0/24 subnet will get
> considered for offering to the client. In the general case you can have
> multiple subnets for clients within the shared network - and the server
> will consider them as all equal in terms of what can be handed out to
> clients.
>
> From memory, I think you mentioned that all devices have static address
> reservations, in which case you’ll need to adapt the subnet declarations,
> so :
> {
> "subnet": "192.0.57.0/24",
> "pools": [ { "pool": "192.0.57.100 - 192.0.57.199" } ]
> "option-data": [
> {
> "name": "routers",
> "data": "192.0.57.1"
> } ]
> }
>
> becomes :
> {
> "subnet": "192.0.57.0/24",
> "pools": [ { "pool": "192.0.57.100 - 192.0.57.199" } ]
> "option-data": [
> {
> "name": "routers",
> "data": "192.0.57.1"
> } ]
> "reservations": [
> {
> "hw-address": "1a:1b:1c:1d:1e:1f",
> "ip-address": “192.0.57.17"
> },
> {
> ... more reservations
> } ]
>}
> And if there’s no dynamic clients at all, then you could delete the pool
> section altogether. It’s a matter for you and the rest of the business to
> determine if there’s a case for keeping a very small pool (with suitably
> short lease times) - allowing newly added devices to get an address (which
> I suspect you could spot in the logs with
Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?
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 little wins !
> To answer your questions:
>
> 1. yes, each distinct subnet has a distinct relay IP that is not reused by
> the other subnets
> 2. yes, all of the relay IPs are part of a specific subnet (iirc it's a /21
> or /22), although I don't know if there's a pattern to how relay IPs are
> chosen (sequentially? randomly? stepwise? etc.) from this subnet
OK, so some good news then.
> And yes, there have been a lot of "interesting times" so far.
I bet :-(
> FWIW, this is the relevant section of my Kea4 config file:
>
> """
> "shared-networks": [
> {
> "name": "iad1",
> "relay": {
> "ip-addresses":
> },
> "subnet4": [
>
> ]
> }
> ],
> """
That’s not going to work. That says “all of the subnets, and all of the relay
addresses, are in one big shared network. As I understand KEA config, you need :
"shared-networks": [
{
"name": “VLAN57",
"subnet4": [
{
"subnet": “192.168.120.66/32",
},
{
"subnet": "192.0.57.0/24",
"pools": [ { "pool": "192.0.57.100 - 192.0.57.199" } ]
"option-data": [
{
"name": "routers",
"data": "192.0.57.1"
} ]
}
]
},
{
"name": “VLAN123",
"subnet4": [
{
"subnet": “192.168.120.250/32",
},
{
"subnet": "192.0.123.0/24",
"pools": [ { "pool": "192.0.123.100 - 192.0.123.199" } ]
{
"name": "routers",
"data": "192.0.123.1"
} ]
}
]
}
],
Yes, it’s going to be one right p.i.t.a. to manage.
What that says is that if you receive a relayed packet from the subnet
192.168.120.66/32 then treat it as including clients from subnet 192.0.57.0/24
as well. Since there is no pool for the 192.168.120.66/32 subnet, then only
addresses from the 192.0.57.0/24 subnet will get considered for offering to the
client. In the general case you can have multiple subnets for clients within
the shared network - and the server will consider them as all equal in terms of
what can be handed out to clients.
From memory, I think you mentioned that all devices have static address
reservations, in which case you’ll need to adapt the subnet declarations, so :
{
"subnet": "192.0.57.0/24",
"pools": [ { "pool": "192.0.57.100 - 192.0.57.199" } ]
"option-data": [
{
"name": "routers",
"data": "192.0.57.1"
} ]
}
becomes :
{
"subnet": "192.0.57.0/24",
"pools": [ { "pool": "192.0.57.100 - 192.0.57.199" } ]
"option-data": [
{
"name": "routers",
"data": "192.0.57.1"
} ]
"reservations": [
{
"hw-address": "1a:1b:1c:1d:1e:1f",
"ip-address": “192.0.57.17"
},
{
... more reservations
} ]
}
And if there’s no dynamic clients at all, then you could delete the pool
section altogether. It’s a matter for you and the rest of the business to
determine if there’s a case for keeping a very small pool (with suitably short
lease times) - allowing newly added devices to get an address (which I suspect
you could spot in the logs with suitable filtering) prior to you actually being
told about it and configuring the correct reservation.
By the time you get to this level of complexity, it may be time to consider a
database backend for config - or store your config elsewhere and use scripts to
build the KEA config. The latter is quite common with DHCPD for large configs.
Simon
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?
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 part of the appropriate shared-networks { } statements.
You would not need relay { } statements at all. BUT, it would not
work with randomly chosen IP addresses for the relay agents as some
would almost certainly be too far apart to group together in a
"subnet". Also, if you have little influence on the people choosing
the relay IP addresses, then you couldn't be sure they wouldn't do
something in the future to break your entire plan anyway. In
conclusion, I'd say ignore my suggestion as it won't work in your
situation probably, or if it would be ok to do now, it might not
continue to work in the future.
On Thu, Mar 2, 2023 at 1:45 AM Klaus Steden wrote:
>
>
> 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:
>
> """
> "shared-networks": [
> {
> "name": "iad1",
> "relay": {
> "ip-addresses":
> },
> "subnet4": [
>
> ]
> }
> ],
> """
>
> and the kea-relay4.json file is just a JSON list of /32 IPs that are used to
> forward DHCPREQUEST packets from prospective client machines, and the
> kea-pool4.json file looks something like this:
>
> """
> ...
> {
> "id": ,
> "option-data": [{"data": "192.168.167.129", "name": "routers"}],
> "pools": [{"pool": "192.168.167.139-192.168.167.254"}],
> "subnet": "192.168.167.128/25"
> },
> {
> "id": ,
> "option-data": [{"data": "192.168.164.1", "name": "routers"}],
> "pools": [{"pool": "192.168.164.11-192.168.164.254"}],
> "subnet": "192.168.164.0/24"
> },
> {
> "id": ,
> "option-data": [{"data": "192.168.182.1", "name": "routers"}],
> "pools": [{"pool": "192.168.182.11-192.168.183.254"}],
> "subnet": "192.168.182.0/23"
> },
> ...
>
>
> I'm hoping that's a bit more informative than what I fear may have involved a
> bit of word salad from me.
>
> cheers,
> Klaus
>
> On Fri, Feb 24, 2023 at 4:49 AM Darren Ankney wrote:
>>
>> 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 10.1.3.0/24 and relays will be between
>> 192.0.2.1 - 192.0.2.254 even though the relay subnet is actually
>> 192.0.0.0/21
>>
>> You could add a "subnet" in your shared network for Network "A" that
>> has 192.0.2.0/24 even though that is not really a subnet configured on
>> your network.
>>
>> That assumes some rhyme or reason to the allocation of relay IP
>> addresses by your network people.
>>
>> On Fri, Feb 24, 2023 at 7:12 AM Klaus Steden wrote:
>> >
>> >
>> > 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
>> > correctly for every pool.
>> >
>> > But ... it's still a static list of relays that requires making updates
>> > that we're not always informed of -- hence the desire to use range or CIDR
>> > prefix notation -- as the only thing that is known for sure is that future
>> > relay IPs will always be found only on specific subnets within our network.
>> >
>> > I think I should also mention as additional context that each device is
>> > given a static IP which is unchanged over the lifetime of the hardware;
>> > it's a large data center environment where dynamic address assignments
>> > would wreak havoc, so IPs in the pool are never offered to more than one
>> > MAC address.
>> >
>> > cheers,
>> > Klaus
>> >
>> >
>> > On Thu, Feb 23, 2023 at 2:38 PM Darren Ankney
>> > wrote:
>> >>
>> >> 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 10.1.2.2 might be a relay source for network "B"
>> >> relay 10.1.2.3 might be a relay source for network "A"
>> >>
>> >> On Thu, Feb 23, 2023 at 5:24 PM Klaus Steden wrote:
>> >> >
>> >> >
>> >> > Correct.
>> >> >
>> >> > Hypothetical networks "A" and "B"
Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?
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:
"""
"shared-networks": [
{
"name": "iad1",
"relay": {
"ip-addresses":
},
"subnet4": [
]
}
],
"""
and the kea-relay4.json file is just a JSON list of /32 IPs that are used
to forward DHCPREQUEST packets from prospective client machines, and the
kea-pool4.json file looks something like this:
"""
...
{
"id": ,
"option-data": [{"data": "192.168.167.129", "name": "routers"}],
"pools": [{"pool": "192.168.167.139-192.168.167.254"}],
"subnet": "192.168.167.128/25"
},
{
"id": ,
"option-data": [{"data": "192.168.164.1", "name": "routers"}],
"pools": [{"pool": "192.168.164.11-192.168.164.254"}],
"subnet": "192.168.164.0/24"
},
{
"id": ,
"option-data": [{"data": "192.168.182.1", "name": "routers"}],
"pools": [{"pool": "192.168.182.11-192.168.183.254"}],
"subnet": "192.168.182.0/23"
},
...
I'm hoping that's a bit more informative than what I fear may have involved
a bit of word salad from me.
cheers,
Klaus
On Fri, Feb 24, 2023 at 4:49 AM Darren Ankney
wrote:
> 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 10.1.3.0/24 and relays will be between
> 192.0.2.1 - 192.0.2.254 even though the relay subnet is actually
> 192.0.0.0/21
>
> You could add a "subnet" in your shared network for Network "A" that
> has 192.0.2.0/24 even though that is not really a subnet configured on
> your network.
>
> That assumes some rhyme or reason to the allocation of relay IP
> addresses by your network people.
>
> On Fri, Feb 24, 2023 at 7:12 AM Klaus Steden wrote:
> >
> >
> > 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 correctly
> for every pool.
> >
> > But ... it's still a static list of relays that requires making updates
> that we're not always informed of -- hence the desire to use range or CIDR
> prefix notation -- as the only thing that is known for sure is that future
> relay IPs will always be found only on specific subnets within our network.
> >
> > I think I should also mention as additional context that each device is
> given a static IP which is unchanged over the lifetime of the hardware;
> it's a large data center environment where dynamic address assignments
> would wreak havoc, so IPs in the pool are never offered to more than one
> MAC address.
> >
> > cheers,
> > Klaus
> >
> >
> > On Thu, Feb 23, 2023 at 2:38 PM Darren Ankney
> wrote:
> >>
> >> 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 10.1.2.2 might be a relay source for network "B"
> >> relay 10.1.2.3 might be a relay source for network "A"
> >>
> >> On Thu, Feb 23, 2023 at 5:24 PM Klaus Steden
> wrote:
> >> >
> >> >
> >> > 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 <
> darren.ank...@gmail.com> 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
> >> >> 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 22, 2023 at 8:07 PM Klaus Steden
> wrote:
> >> >> >
> >> >> >
> >> >> > 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 of Kea behind a single unicast IP handles all DHCP
> for the entire physical site
> >> >> > - each switch is configured to use this same unicast IP as its
> DHCP helper address
> >> >> > - the site has
Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?
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 got rolled up
into a larger org as the result of a merger, 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". But I digress.
To answer your questions:
1. yes, each distinct subnet has a distinct relay IP that is not reused by
the other subnets
2. yes, all of the relay IPs are part of a specific subnet (iirc it's a /21
or /22), although I don't know if there's a pattern to how relay IPs are
chosen (sequentially? randomly? stepwise? etc.) from this subnet
And yes, there have been a lot of "interesting times" so far.
FWIW, this is the relevant section of my Kea4 config file:
"""
"shared-networks": [
{
"name": "iad1",
"relay": {
"ip-addresses":
},
"subnet4": [
]
}
],
"""
The kea-relay4.json file is just a JSON list of unicast (/32) IPs that are
used to relay DHCP requests (I posted it up-thread a few back), and the
kea-pool4.json file contains only a series of bog-standard scope
definitions like these:
"""
...
{
"id": ,
"option-data": [{"data": "192.168.167.129", "name": "routers"}],
"pools": [{"pool": "192.168.167.139-192.168.167.254"}],
"subnet": "192.168.167.128/25"
},
{
"id": ,
"option-data": [{"data": "192.168.164.1", "name": "routers"}],
"pools": [{"pool": "192.168.164.11-192.168.164.254"}],
"subnet": "192.168.164.0/24"
},
{
"id": ,
"option-data": [{"data": "192.168.182.1", "name": "routers"}],
"pools": [{"pool": "192.168.182.11-192.168.183.254"}],
"subnet": "192.168.182.0/23"
},
...
"""
I'll cop to not entirely understanding all of the nuances of the
shared-networks approach yet -- this is what we were able to make work in
the time we had available to make it work -- but I'm completely on board
with any suggestions or recommendations for improvement.
cheers,
Klaus
On Mon, Feb 27, 2023 at 11:26 AM Simon wrote:
> 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 unicast IP handles all DHCP for the
> entire physical site
> > - each switch is configured to use this same unicast IP as its DHCP
> helper address
> > - the site has multiple distinct networks distributed across multiple
> switches via VXLAN
>
> So far, so good.
>
> > - each VXLAN uses a distinct relay address to forward DHCP requests to
> the helper IP
> > - each relay address is in a subnet reserved specifically just for relay
> addresses
>
> At this point I would argue that the network design is broken.
> The expectation is that each relay agent should use a unicast address from
> a subnet in which the served clients reside. If this is done, then
> allocation happens “automagically” as the server will automatically
> associate the relay address with the subnet(s) served (or more accurately,
> the broadcast domain containing those subnets).
> The way they’ve done it, you need to “do something” manually with the
> config in order to associate relay address with client network.
>
> Questions:
> Are distinct IP addresses associated with each client network ? I.e., each
> relay address is used for only one client network, and there is no
> duplication ?
> Is there a pattern to this, e.g. a /27 range used for each client network,
> or are random single addresses used ?
>
> What I’m thinking is that you could define a shared-network containing the
> client subnet(s) and the allowed relay addresses for each of the VLANs.
> That will automatically associate clients to the correct network for
> picking up network specific options (e.g. router address(es)). That’s going
> to be simpler if you can use (e.g.) 192.168.120.16/28 than if you need to
> use multiple /32 subnets in the shared network.
>
> > The driver here is that it's been difficult to maintain the list of
> individual IPs because we're not kept in the loop when a new relay IP gets
> allocated, and the only solid info I can squeeze out of our network team is
> the subnets they've set aside specifically for relay IP addresses.
>
> So not only have you inherited a “poor” network design, but you have a
> network team that doesn’t like to co-operate for the benefit of the
> business. That’s going to be a never ending source of “interesting times”.
>
>
> Simon
>
>
> --
> ISC funds the development of this software with paid support
>
Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?
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 unicast IP handles all DHCP for the > entire physical site > - each switch is configured to use this same unicast IP as its DHCP helper > address > - the site has multiple distinct networks distributed across multiple > switches via VXLAN So far, so good. > - each VXLAN uses a distinct relay address to forward DHCP requests to the > helper IP > - each relay address is in a subnet reserved specifically just for relay > addresses At this point I would argue that the network design is broken. The expectation is that each relay agent should use a unicast address from a subnet in which the served clients reside. If this is done, then allocation happens “automagically” as the server will automatically associate the relay address with the subnet(s) served (or more accurately, the broadcast domain containing those subnets). The way they’ve done it, you need to “do something” manually with the config in order to associate relay address with client network. Questions: Are distinct IP addresses associated with each client network ? I.e., each relay address is used for only one client network, and there is no duplication ? Is there a pattern to this, e.g. a /27 range used for each client network, or are random single addresses used ? What I’m thinking is that you could define a shared-network containing the client subnet(s) and the allowed relay addresses for each of the VLANs. That will automatically associate clients to the correct network for picking up network specific options (e.g. router address(es)). That’s going to be simpler if you can use (e.g.) 192.168.120.16/28 than if you need to use multiple /32 subnets in the shared network. > The driver here is that it's been difficult to maintain the list of > individual IPs because we're not kept in the loop when a new relay IP gets > allocated, and the only solid info I can squeeze out of our network team is > the subnets they've set aside specifically for relay IP addresses. So not only have you inherited a “poor” network design, but you have a network team that doesn’t like to co-operate for the benefit of the business. That’s going to be a never ending source of “interesting times”. Simon -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?
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 10.1.3.0/24 and relays will be between 192.0.2.1 - 192.0.2.254 even though the relay subnet is actually 192.0.0.0/21 You could add a "subnet" in your shared network for Network "A" that has 192.0.2.0/24 even though that is not really a subnet configured on your network. That assumes some rhyme or reason to the allocation of relay IP addresses by your network people. On Fri, Feb 24, 2023 at 7:12 AM Klaus Steden wrote: > > > 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 correctly > for every pool. > > But ... it's still a static list of relays that requires making updates that > we're not always informed of -- hence the desire to use range or CIDR prefix > notation -- as the only thing that is known for sure is that future relay IPs > will always be found only on specific subnets within our network. > > I think I should also mention as additional context that each device is given > a static IP which is unchanged over the lifetime of the hardware; it's a > large data center environment where dynamic address assignments would wreak > havoc, so IPs in the pool are never offered to more than one MAC address. > > cheers, > Klaus > > > On Thu, Feb 23, 2023 at 2:38 PM Darren Ankney wrote: >> >> 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 10.1.2.2 might be a relay source for network "B" >> relay 10.1.2.3 might be a relay source for network "A" >> >> On Thu, Feb 23, 2023 at 5:24 PM Klaus Steden wrote: >> > >> > >> > 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 >> >> 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 22, 2023 at 8:07 PM Klaus Steden wrote: >> >> > >> >> > >> >> > 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 of Kea behind a single unicast IP handles all DHCP for >> >> > the entire physical site >> >> > - each switch is configured to use this same unicast IP as its DHCP >> >> > helper address >> >> > - the site has multiple distinct networks distributed across multiple >> >> > switches via VXLAN >> >> > - each VXLAN uses a distinct relay address to forward DHCP requests to >> >> > the helper IP >> >> > - each relay address is in a subnet reserved specifically just for >> >> > relay addresses >> >> > >> >> > We're already using the macro to manage the existing (and >> >> > growing) list of relay IPs, but what I'm really looking for is to be >> >> > able to use CIDR notation or Kea range notation instead of using >> >> > individual IPs, e.g., this is what the relays list looks like right now: >> >> > >> >> > """ >> >> > ["192.168.120.16", "192.168.120.17", "192.168.120.18", >> >> > "192.168.120.19", "192.168.120.20", "192.168.120.21", "192.168.120.22", >> >> > "192.168.120.23", "192.168.120.232", "192.168.120.233", >> >> > "192.168.120.234", "192.168.120.235", "192.168.120.236", >> >> > "192.168.120.237", "192.168.120.238", "192.168.120.239", >> >> > "192.168.120.240", "192.168.120.241", "192.168.120.242", >> >> > "192.168.120.243", "192.168.120.244", "192.168.120.245", >> >> > "192.168.120.246", "192.168.152.18", "192.168.152.19", >> >> > "192.168.152.20", "192.168.152.21", "192.168.152.22", "192.168.152.23", >> >> > "192.168.152.24", "192.168.152.25", "192.168.152.26", "192.168.152.27", >> >> > "192.168.152.28", "192.168.152.29", "192.168.184.18", "192.168.184.19", >> >> > "192.168.184.20", "192.168.184.21", "192.168.184.22", "192.168.184.23", >> >> > "192.168.216.16", "192.168.216.17",
Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?
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 then requests from any of these relay IPs are processed correctly > for every pool. > > But ... it's still a static list of relays that requires making updates that > we're not always informed of -- hence the desire to use range or CIDR prefix > notation -- as the only thing that is known for sure is that future relay IPs > will always be found only on specific subnets within our network. Sounds like it might be time for an official feature request :-) -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?
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 correctly for every pool. But ... it's still a static list of relays that requires making updates that we're not always informed of -- hence the desire to use range or CIDR prefix notation -- as the only thing that is known for sure is that future relay IPs will always be found only on specific subnets within our network. I think I should also mention as additional context that each device is given a static IP which is unchanged over the lifetime of the hardware; it's a large data center environment where dynamic address assignments would wreak havoc, so IPs in the pool are never offered to more than one MAC address. cheers, Klaus On Thu, Feb 23, 2023 at 2:38 PM Darren Ankney wrote: > 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 10.1.2.2 might be a relay source for network "B" > relay 10.1.2.3 might be a relay source for network "A" > > On Thu, Feb 23, 2023 at 5:24 PM Klaus Steden wrote: > > > > > > 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 > >> 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 22, 2023 at 8:07 PM Klaus Steden > wrote: > >> > > >> > > >> > 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 of Kea behind a single unicast IP handles all DHCP for > the entire physical site > >> > - each switch is configured to use this same unicast IP as its DHCP > helper address > >> > - the site has multiple distinct networks distributed across multiple > switches via VXLAN > >> > - each VXLAN uses a distinct relay address to forward DHCP requests > to the helper IP > >> > - each relay address is in a subnet reserved specifically just for > relay addresses > >> > > >> > We're already using the macro to manage the existing > (and growing) list of relay IPs, but what I'm really looking for is to be > able to use CIDR notation or Kea range notation instead of using individual > IPs, e.g., this is what the relays list looks like right now: > >> > > >> > """ > >> > ["192.168.120.16", "192.168.120.17", "192.168.120.18", > "192.168.120.19", "192.168.120.20", "192.168.120.21", "192.168.120.22", > "192.168.120.23", "192.168.120.232", "192.168.120.233", "192.168.120.234", > "192.168.120.235", "192.168.120.236", "192.168.120.237", "192.168.120.238", > "192.168.120.239", "192.168.120.240", "192.168.120.241", "192.168.120.242", > "192.168.120.243", "192.168.120.244", "192.168.120.245", "192.168.120.246", > "192.168.152.18", "192.168.152.19", "192.168.152.20", "192.168.152.21", > "192.168.152.22", "192.168.152.23", "192.168.152.24", "192.168.152.25", > "192.168.152.26", "192.168.152.27", "192.168.152.28", "192.168.152.29", > "192.168.184.18", "192.168.184.19", "192.168.184.20", "192.168.184.21", > "192.168.184.22", "192.168.184.23", "192.168.216.16", "192.168.216.17", > "192.168.216.18", "192.168.216.19", "192.168.216.20", "192.168.216.21", > "192.168.252.16", "192.168.252.17", "192.168.88.18", "192.168.88.19", > "192.168.88.20", "192.168.88.21", "192.168.88.22", "192.168.88.23", > "192.168.88.24", "192.168.88.25", "192.168.88.26", "192.168.88.27", > "192.168.88.28", "192.168.88.29", "192.168.88.30", "192.168.88.31", > "192.168.88.32", "192.168.88.33", "192.168.88.34", "192.168.88.35", > "192.168.88.36", "192.168.88.37", "192.168.88.38", "192.168.88.39", > "192.168.88.40", "192.168.88.41", "192.168.88.42", "192.168.88.43", > "192.168.88.44"] > >> > """ > >> > > >> > and what I would love to do instead is write that as this: > >> > > >> > """ > >> > ["192.168.120.0/24", "192.168.152.0/26", "192.168.184.0/26", " > 192.168.216.0/25", "192.168.252.0/25", "192.168.88.0/24"] > >> > """ > >> > > >> > or perhaps more accurately as this: > >> > > >> > """ > >> > ["192.168.120.10-192.168.120.253", "192.168.152.10-192.168.152.62", > "192.168.184.10-192.168.152.62",
Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?
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 10.1.2.2 might be a relay source for network "B" relay 10.1.2.3 might be a relay source for network "A" On Thu, Feb 23, 2023 at 5:24 PM Klaus Steden wrote: > > > 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 >> 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 22, 2023 at 8:07 PM Klaus Steden wrote: >> > >> > >> > 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 of Kea behind a single unicast IP handles all DHCP for the >> > entire physical site >> > - each switch is configured to use this same unicast IP as its DHCP helper >> > address >> > - the site has multiple distinct networks distributed across multiple >> > switches via VXLAN >> > - each VXLAN uses a distinct relay address to forward DHCP requests to the >> > helper IP >> > - each relay address is in a subnet reserved specifically just for relay >> > addresses >> > >> > We're already using the macro to manage the existing (and >> > growing) list of relay IPs, but what I'm really looking for is to be able >> > to use CIDR notation or Kea range notation instead of using individual >> > IPs, e.g., this is what the relays list looks like right now: >> > >> > """ >> > ["192.168.120.16", "192.168.120.17", "192.168.120.18", "192.168.120.19", >> > "192.168.120.20", "192.168.120.21", "192.168.120.22", "192.168.120.23", >> > "192.168.120.232", "192.168.120.233", "192.168.120.234", >> > "192.168.120.235", "192.168.120.236", "192.168.120.237", >> > "192.168.120.238", "192.168.120.239", "192.168.120.240", >> > "192.168.120.241", "192.168.120.242", "192.168.120.243", >> > "192.168.120.244", "192.168.120.245", "192.168.120.246", "192.168.152.18", >> > "192.168.152.19", "192.168.152.20", "192.168.152.21", "192.168.152.22", >> > "192.168.152.23", "192.168.152.24", "192.168.152.25", "192.168.152.26", >> > "192.168.152.27", "192.168.152.28", "192.168.152.29", "192.168.184.18", >> > "192.168.184.19", "192.168.184.20", "192.168.184.21", "192.168.184.22", >> > "192.168.184.23", "192.168.216.16", "192.168.216.17", "192.168.216.18", >> > "192.168.216.19", "192.168.216.20", "192.168.216.21", "192.168.252.16", >> > "192.168.252.17", "192.168.88.18", "192.168.88.19", "192.168.88.20", >> > "192.168.88.21", "192.168.88.22", "192.168.88.23", "192.168.88.24", >> > "192.168.88.25", "192.168.88.26", "192.168.88.27", "192.168.88.28", >> > "192.168.88.29", "192.168.88.30", "192.168.88.31", "192.168.88.32", >> > "192.168.88.33", "192.168.88.34", "192.168.88.35", "192.168.88.36", >> > "192.168.88.37", "192.168.88.38", "192.168.88.39", "192.168.88.40", >> > "192.168.88.41", "192.168.88.42", "192.168.88.43", "192.168.88.44"] >> > """ >> > >> > and what I would love to do instead is write that as this: >> > >> > """ >> > ["192.168.120.0/24", "192.168.152.0/26", "192.168.184.0/26", >> > "192.168.216.0/25", "192.168.252.0/25", "192.168.88.0/24"] >> > """ >> > >> > or perhaps more accurately as this: >> > >> > """ >> > ["192.168.120.10-192.168.120.253", "192.168.152.10-192.168.152.62", >> > "192.168.184.10-192.168.152.62", "192.168.216.10-192.168.216.126", >> > "192.168.252.10-192.168.252.62", "192.168.88.10-192.168.88.253"] >> > """ >> > >> > The driver here is that it's been difficult to maintain the list of >> > individual IPs because we're not kept in the loop when a new relay IP gets >> > allocated, and the only solid info I can squeeze out of our network team >> > is the subnets they've set aside specifically for relay IP addresses. >> > >> > So I figured that if I could use address ranges in the relays list instead >> > of individual IPs then I don't have to update the relays file as >> > frequently and DHCP is less likely to not offer an IP because the incoming >> > relay address is currently unknown. >> > >> > I hope this adds a bit more context to my original question! >> > >> > thanks, >> > Klaus >> > >> > >> > On Wed, Feb 22, 2023 at 6:32 AM Simon wrote: >> >> >> >> Darren Ankney wrote: >> >> >> >> > In addition to what Peter said, another option would be to use shared >> >> >
Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?
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
> 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 22, 2023 at 8:07 PM Klaus Steden wrote:
> >
> >
> > 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 of Kea behind a single unicast IP handles all DHCP for the
> entire physical site
> > - each switch is configured to use this same unicast IP as its DHCP
> helper address
> > - the site has multiple distinct networks distributed across multiple
> switches via VXLAN
> > - each VXLAN uses a distinct relay address to forward DHCP requests to
> the helper IP
> > - each relay address is in a subnet reserved specifically just for relay
> addresses
> >
> > We're already using the macro to manage the existing (and
> growing) list of relay IPs, but what I'm really looking for is to be able
> to use CIDR notation or Kea range notation instead of using individual IPs,
> e.g., this is what the relays list looks like right now:
> >
> > """
> > ["192.168.120.16", "192.168.120.17", "192.168.120.18", "192.168.120.19",
> "192.168.120.20", "192.168.120.21", "192.168.120.22", "192.168.120.23",
> "192.168.120.232", "192.168.120.233", "192.168.120.234", "192.168.120.235",
> "192.168.120.236", "192.168.120.237", "192.168.120.238", "192.168.120.239",
> "192.168.120.240", "192.168.120.241", "192.168.120.242", "192.168.120.243",
> "192.168.120.244", "192.168.120.245", "192.168.120.246", "192.168.152.18",
> "192.168.152.19", "192.168.152.20", "192.168.152.21", "192.168.152.22",
> "192.168.152.23", "192.168.152.24", "192.168.152.25", "192.168.152.26",
> "192.168.152.27", "192.168.152.28", "192.168.152.29", "192.168.184.18",
> "192.168.184.19", "192.168.184.20", "192.168.184.21", "192.168.184.22",
> "192.168.184.23", "192.168.216.16", "192.168.216.17", "192.168.216.18",
> "192.168.216.19", "192.168.216.20", "192.168.216.21", "192.168.252.16",
> "192.168.252.17", "192.168.88.18", "192.168.88.19", "192.168.88.20",
> "192.168.88.21", "192.168.88.22", "192.168.88.23", "192.168.88.24",
> "192.168.88.25", "192.168.88.26", "192.168.88.27", "192.168.88.28",
> "192.168.88.29", "192.168.88.30", "192.168.88.31", "192.168.88.32",
> "192.168.88.33", "192.168.88.34", "192.168.88.35", "192.168.88.36",
> "192.168.88.37", "192.168.88.38", "192.168.88.39", "192.168.88.40",
> "192.168.88.41", "192.168.88.42", "192.168.88.43", "192.168.88.44"]
> > """
> >
> > and what I would love to do instead is write that as this:
> >
> > """
> > ["192.168.120.0/24", "192.168.152.0/26", "192.168.184.0/26", "
> 192.168.216.0/25", "192.168.252.0/25", "192.168.88.0/24"]
> > """
> >
> > or perhaps more accurately as this:
> >
> > """
> > ["192.168.120.10-192.168.120.253", "192.168.152.10-192.168.152.62",
> "192.168.184.10-192.168.152.62", "192.168.216.10-192.168.216.126",
> "192.168.252.10-192.168.252.62", "192.168.88.10-192.168.88.253"]
> > """
> >
> > The driver here is that it's been difficult to maintain the list of
> individual IPs because we're not kept in the loop when a new relay IP gets
> allocated, and the only solid info I can squeeze out of our network team is
> the subnets they've set aside specifically for relay IP addresses.
> >
> > So I figured that if I could use address ranges in the relays list
> instead of individual IPs then I don't have to update the relays file as
> frequently and DHCP is less likely to not offer an IP because the incoming
> relay address is currently unknown.
> >
> > I hope this adds a bit more context to my original question!
> >
> > thanks,
> > Klaus
> >
> >
> > On Wed, Feb 22, 2023 at 6:32 AM Simon wrote:
> >>
> >> 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:
> https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#shared-networks-in-dhcpv4
> >> >
> >> > Example:
> >> >
> >> > {
> >> > "Dhcp4": {
> >> >"shared-networks": [
> >> >{
> >> > "subnet4": [
> >> >{
> >> >// relays
> >> >"subnet": "10.1.0.0/21"
> >> >},
> >> >{
> >> >// client subnet
> >> >"subnet": "192.0.2.0/24",
> >> >"pools": [ { "pool":
Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?
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 22, 2023 at 8:07 PM Klaus Steden wrote:
>
>
> 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 of Kea behind a single unicast IP handles all DHCP for the
> entire physical site
> - each switch is configured to use this same unicast IP as its DHCP helper
> address
> - the site has multiple distinct networks distributed across multiple
> switches via VXLAN
> - each VXLAN uses a distinct relay address to forward DHCP requests to the
> helper IP
> - each relay address is in a subnet reserved specifically just for relay
> addresses
>
> We're already using the macro to manage the existing (and
> growing) list of relay IPs, but what I'm really looking for is to be able to
> use CIDR notation or Kea range notation instead of using individual IPs,
> e.g., this is what the relays list looks like right now:
>
> """
> ["192.168.120.16", "192.168.120.17", "192.168.120.18", "192.168.120.19",
> "192.168.120.20", "192.168.120.21", "192.168.120.22", "192.168.120.23",
> "192.168.120.232", "192.168.120.233", "192.168.120.234", "192.168.120.235",
> "192.168.120.236", "192.168.120.237", "192.168.120.238", "192.168.120.239",
> "192.168.120.240", "192.168.120.241", "192.168.120.242", "192.168.120.243",
> "192.168.120.244", "192.168.120.245", "192.168.120.246", "192.168.152.18",
> "192.168.152.19", "192.168.152.20", "192.168.152.21", "192.168.152.22",
> "192.168.152.23", "192.168.152.24", "192.168.152.25", "192.168.152.26",
> "192.168.152.27", "192.168.152.28", "192.168.152.29", "192.168.184.18",
> "192.168.184.19", "192.168.184.20", "192.168.184.21", "192.168.184.22",
> "192.168.184.23", "192.168.216.16", "192.168.216.17", "192.168.216.18",
> "192.168.216.19", "192.168.216.20", "192.168.216.21", "192.168.252.16",
> "192.168.252.17", "192.168.88.18", "192.168.88.19", "192.168.88.20",
> "192.168.88.21", "192.168.88.22", "192.168.88.23", "192.168.88.24",
> "192.168.88.25", "192.168.88.26", "192.168.88.27", "192.168.88.28",
> "192.168.88.29", "192.168.88.30", "192.168.88.31", "192.168.88.32",
> "192.168.88.33", "192.168.88.34", "192.168.88.35", "192.168.88.36",
> "192.168.88.37", "192.168.88.38", "192.168.88.39", "192.168.88.40",
> "192.168.88.41", "192.168.88.42", "192.168.88.43", "192.168.88.44"]
> """
>
> and what I would love to do instead is write that as this:
>
> """
> ["192.168.120.0/24", "192.168.152.0/26", "192.168.184.0/26",
> "192.168.216.0/25", "192.168.252.0/25", "192.168.88.0/24"]
> """
>
> or perhaps more accurately as this:
>
> """
> ["192.168.120.10-192.168.120.253", "192.168.152.10-192.168.152.62",
> "192.168.184.10-192.168.152.62", "192.168.216.10-192.168.216.126",
> "192.168.252.10-192.168.252.62", "192.168.88.10-192.168.88.253"]
> """
>
> The driver here is that it's been difficult to maintain the list of
> individual IPs because we're not kept in the loop when a new relay IP gets
> allocated, and the only solid info I can squeeze out of our network team is
> the subnets they've set aside specifically for relay IP addresses.
>
> So I figured that if I could use address ranges in the relays list instead of
> individual IPs then I don't have to update the relays file as frequently and
> DHCP is less likely to not offer an IP because the incoming relay address is
> currently unknown.
>
> I hope this adds a bit more context to my original question!
>
> thanks,
> Klaus
>
>
> On Wed, Feb 22, 2023 at 6:32 AM Simon wrote:
>>
>> 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:
>> > https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#shared-networks-in-dhcpv4
>> >
>> > Example:
>> >
>> > {
>> > "Dhcp4": {
>> >"shared-networks": [
>> >{
>> > "subnet4": [
>> >{
>> >// relays
>> >"subnet": "10.1.0.0/21"
>> >},
>> >{
>> >// client subnet
>> >"subnet": "192.0.2.0/24",
>> >"pools": [ { "pool": "192.0.2.100 - 192.0.2.199" } ]
>> >}
>> >]
>> >}
>> > ]
>> > }
>> > }
>>
>> That won’t work in the sort of situation I think the OP is referring to -
>> but I admit it’s not completely clear.
>> You can only associate the
Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?
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 of Kea behind a single unicast IP handles all DHCP for the
entire physical site
- each switch is configured to use this same unicast IP as its DHCP helper
address
- the site has multiple distinct networks distributed across multiple
switches via VXLAN
- each VXLAN uses a distinct relay address to forward DHCP requests to the
helper IP
- each relay address is in a subnet reserved specifically just for relay
addresses
We're already using the macro to manage the existing (and
growing) list of relay IPs, but what I'm really looking for is to be able
to use CIDR notation or Kea range notation instead of using individual IPs,
e.g., this is what the relays list looks like right now:
"""
["192.168.120.16", "192.168.120.17", "192.168.120.18", "192.168.120.19",
"192.168.120.20", "192.168.120.21", "192.168.120.22", "192.168.120.23",
"192.168.120.232", "192.168.120.233", "192.168.120.234", "192.168.120.235",
"192.168.120.236", "192.168.120.237", "192.168.120.238", "192.168.120.239",
"192.168.120.240", "192.168.120.241", "192.168.120.242", "192.168.120.243",
"192.168.120.244", "192.168.120.245", "192.168.120.246", "192.168.152.18",
"192.168.152.19", "192.168.152.20", "192.168.152.21", "192.168.152.22",
"192.168.152.23", "192.168.152.24", "192.168.152.25", "192.168.152.26",
"192.168.152.27", "192.168.152.28", "192.168.152.29", "192.168.184.18",
"192.168.184.19", "192.168.184.20", "192.168.184.21", "192.168.184.22",
"192.168.184.23", "192.168.216.16", "192.168.216.17", "192.168.216.18",
"192.168.216.19", "192.168.216.20", "192.168.216.21", "192.168.252.16",
"192.168.252.17", "192.168.88.18", "192.168.88.19", "192.168.88.20",
"192.168.88.21", "192.168.88.22", "192.168.88.23", "192.168.88.24",
"192.168.88.25", "192.168.88.26", "192.168.88.27", "192.168.88.28",
"192.168.88.29", "192.168.88.30", "192.168.88.31", "192.168.88.32",
"192.168.88.33", "192.168.88.34", "192.168.88.35", "192.168.88.36",
"192.168.88.37", "192.168.88.38", "192.168.88.39", "192.168.88.40",
"192.168.88.41", "192.168.88.42", "192.168.88.43", "192.168.88.44"]
"""
and what I would love to do instead is write that as this:
"""
["192.168.120.0/24", "192.168.152.0/26", "192.168.184.0/26", "
192.168.216.0/25", "192.168.252.0/25", "192.168.88.0/24"]
"""
or perhaps more accurately as this:
"""
["192.168.120.10-192.168.120.253", "192.168.152.10-192.168.152.62",
"192.168.184.10-192.168.152.62", "192.168.216.10-192.168.216.126",
"192.168.252.10-192.168.252.62", "192.168.88.10-192.168.88.253"]
"""
The driver here is that it's been difficult to maintain the list of
individual IPs because we're not kept in the loop when a new relay IP gets
allocated, and the only solid info I can squeeze out of our network team is
the subnets they've set aside specifically for relay IP addresses.
So I figured that if I could use address ranges in the relays list instead
of individual IPs then I don't have to update the relays file as frequently
and DHCP is less likely to not offer an IP because the incoming relay
address is currently unknown.
I hope this adds a bit more context to my original question!
thanks,
Klaus
On Wed, Feb 22, 2023 at 6:32 AM Simon wrote:
> 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:
> https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#shared-networks-in-dhcpv4
> >
> > Example:
> >
> > {
> > "Dhcp4": {
> >"shared-networks": [
> >{
> > "subnet4": [
> >{
> >// relays
> >"subnet": "10.1.0.0/21"
> >},
> >{
> >// client subnet
> >"subnet": "192.0.2.0/24",
> >"pools": [ { "pool": "192.0.2.100 - 192.0.2.199" } ]
> >}
> >]
> >}
> > ]
> > }
> > }
>
> That won’t work in the sort of situation I think the OP is referring to -
> but I admit it’s not completely clear.
> You can only associate the relays subnet with one client subnet. So once
> you introduce more than one client subnet, it breaks.
>
>
> PM Klaus Steden wrote:
>
> >> 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 entire network as a relay instead of what
> I'm currently doing, which is adding individual IPs when I notice them
> reported
Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?
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:
> https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#shared-networks-in-dhcpv4
>
> Example:
>
> {
> "Dhcp4": {
>"shared-networks": [
>{
> "subnet4": [
>{
>// relays
>"subnet": "10.1.0.0/21"
>},
>{
>// client subnet
>"subnet": "192.0.2.0/24",
>"pools": [ { "pool": "192.0.2.100 - 192.0.2.199" } ]
>}
>]
>}
> ]
> }
> }
That won’t work in the sort of situation I think the OP is referring to - but I
admit it’s not completely clear.
You can only associate the relays subnet with one client subnet. So once you
introduce more than one client subnet, it breaks.
PM Klaus Steden wrote:
>> 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 entire network as a relay instead of what
>> I'm currently doing, which is adding individual IPs when I notice them
>> reported in the log.
Can you clarify exactly what’s going on here ?
Is it that there is a client network with “many” relays on it; or many client
networks with one or two relays on each, but the relay addresses are not part
of the client subnet ?
If it’s the latter, then this is a “very poor” network config and not compliant
with how things are supposed to work.
Some more clarity of the network topology and config would enable a better
answer.
Simon
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?
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:
https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#shared-networks-in-dhcpv4
Example:
{
"Dhcp4": {
"shared-networks": [
{
"subnet4": [
{
// relays
"subnet": "10.1.0.0/21"
},
{
// client subnet
"subnet": "192.0.2.0/24",
"pools": [ { "pool": "192.0.2.100 - 192.0.2.199" } ]
}
]
}
]
}
}
On Tue, Feb 21, 2023 at 9:45 PM Klaus Steden wrote:
>
>
> 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 entire network as a relay instead of what I'm
> currently doing, which is adding individual IPs when I notice them reported
> in the log.
>
> Is this even possible? The examples in the Kea documentation only mention
> single addresses, but for big networks with lots of relays like ours, it
> would be very helpful to be able to just add an entire range of IPs and have
> Kea figure it out automatically.
>
> thanks,
> Klaus
> --
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?
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 On 22/02/2023 03.44, Klaus Steden wrote: 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 entire network as a relay instead of what I'm currently doing, which is adding individual IPs when I notice them reported in the log. Is this even possible? The examples in the Kea documentation only mention single addresses, but for big networks with lots of relays like ours, it would be very helpful to be able to just add an entire range of IPs and have Kea figure it out automatically. thanks, Klaus -- Peter Davies -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
[Kea-users] CIDR or range notation in relay lists when using shared-networks?
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 entire network as a relay instead of what I'm currently doing, which is adding individual IPs when I notice them reported in the log. Is this even possible? The examples in the Kea documentation only mention single addresses, but for big networks with lots of relays like ours, it would be very helpful to be able to just add an entire range of IPs and have Kea figure it out automatically. thanks, Klaus -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
