<div dir="ltr"><br><div>Hello Simon,</div><div><br></div><div>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.</div><div><br></div><div>To answer your questions:</div><div><br></div><div>1. yes, each distinct subnet has a distinct relay IP that is not reused by the other subnets</div><div>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</div><div><br></div><div>And yes, there have been a lot of "interesting times" so far.</div><div><br></div><div>FWIW, this is the relevant section of my Kea4 config file:</div><div><br></div><div>"""</div><div><font face="monospace"> "shared-networks": [<br> {<br> "name": "iad1",<br> "relay": {<br> "ip-addresses": <?include "/etc/kea/kea-relay4.json"?><br> },<br> "subnet4": [<br> <?include "/etc/kea/kea-pool4.json"?><br> ]<br> }<br> ],</font><br></div><div>"""</div><div><br></div><div>The <font face="monospace">kea-relay4.json</font> 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 <font face="monospace">kea-pool4.json</font> file contains only a series of bog-standard scope definitions like these:</div><div><br></div><div>"""</div><div><font face="monospace">...</font></div><div><font face="monospace">{<br> "id": <redacted>,<br> "option-data": [{"data": "192.168.167.129", "name": "routers"}],<br> "pools": [{"pool": "192.168.167.139-192.168.167.254"}],<br> "subnet": "<a href="http://192.168.167.128/25">192.168.167.128/25</a>"<br>},<br>{<br> "id": <redacted>,<br> "option-data": [{"data": "192.168.164.1", "name": "routers"}],<br> "pools": [{"pool": "192.168.164.11-192.168.164.254"}],<br> "subnet": "<a href="http://192.168.164.0/24">192.168.164.0/24</a>"<br>},<br>{<br> "id": <redacted>,<br> "option-data": [{"data": "192.168.182.1", "name": "routers"}],<br> "pools": [{"pool": "192.168.182.11-192.168.183.254"}],<br> "subnet": "<a href="http://192.168.182.0/23">192.168.182.0/23</a>"<br>},</font><br></div><div><font face="monospace">...</font></div><div><font face="arial, sans-serif">"""</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">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.<br></font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">cheers,</font></div><div><font face="arial, sans-serif">Klaus</font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 27, 2023 at 11:26 AM Simon <<a href="mailto:dhcp1@thehobsons.co.uk">dhcp1@thehobsons.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Klaus Steden <<a href="mailto:klausfiend@gmail.com" target="_blank">klausfiend@gmail.com</a>> wrote:<br>
<br>
> 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.<br>
<br>
Ah, the joys of inheriting someone else’s “bright idea”.<br>
<br>
> This is the basic model: <br>
> <br>
> - an instance of Kea behind a single unicast IP handles all DHCP for the entire physical site<br>
> - each switch is configured to use this same unicast IP as its DHCP helper address<br>
> - the site has multiple distinct networks distributed across multiple switches via VXLAN<br>
<br>
So far, so good.<br>
<br>
> - each VXLAN uses a distinct relay address to forward DHCP requests to the helper IP<br>
> - each relay address is in a subnet reserved specifically just for relay addresses<br>
<br>
At this point I would argue that the network design is broken.<br>
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).<br>
The way they’ve done it, you need to “do something” manually with the config in order to associate relay address with client network.<br>
<br>
Questions:<br>
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 ?<br>
Is there a pattern to this, e.g. a /27 range used for each client network, or are random single addresses used ?<br>
<br>
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.) <a href="http://192.168.120.16/28" rel="noreferrer" target="_blank">192.168.120.16/28</a> than if you need to use multiple /32 subnets in the shared network.<br>
<br>
> 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.<br>
<br>
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”.<br>
<br>
<br>
Simon<br>
<br>
<br>
-- <br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
To unsubscribe visit <a href="https://lists.isc.org/mailman/listinfo/kea-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/kea-users</a>.<br>
<br>
Kea-users mailing list<br>
<a href="mailto:Kea-users@lists.isc.org" target="_blank">Kea-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/kea-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/kea-users</a><br>
</blockquote></div>