Replies: 4 comments 3 replies
-
|
I really like the idea, but my knowledge of the code is too limited to comment on the implementation details. The stuff you describe would be enough for providing addresses with DHCP. If you want more realistic client provisioning there are a whole bunch of RA and DHCP options to consider :) |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, we'd need "more IPv6 stuff on interfaces" to do that, maybe "intf.ipv6" plugin sometime in the future. Thinking about that, could you put together a list of things you'd like to see configurable on IPv6 interfaces? |
Beta Was this translation helpful? Give feedback.
-
Trying to merge this with the other topic ;) If we find a proper way for this, this could be applied as well to Linux routing daemons. An idea could be to have some "Linux sub-modules", which in fact can be different config templates called by the main Jinja template. Just as an example, for the DHCP server module you can have the optional param "implementation", which then is used to call the final template. |
Beta Was this translation helpful? Give feedback.
-
|
Love the idea of sub-modules. Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
Another thing to take care of is the default route which may be installed by the DHCP client, which may broke the management path (i.e. on devices without a dedicated mgmt vrf, like Linux hosts ;) ) |
Beta Was this translation helpful? Give feedback.
-
|
Agreed. Something along the lines of dhcp.default which influences what the DHCP client asks to get from the DHCP server? |
Beta Was this translation helpful? Give feedback.
-
|
DHCP clients, servers and relays implemented in a bunch of commits. Linux "sub-modules" implemented as daemons. The dhcp.default parameter is still pending (see #1033). |
Beta Was this translation helpful? Give feedback.
-
I decided to consolidate the gazillion DHCP thingies we did a while ago into a DHCP module. It has to support DHCP clients, DHCP relays, and DHCP servers, and should deal with DHCPv4 and DHCPv6. Ideally, the DHCP relays and DHCP servers would be VRF aware (if that's supported by the devices)
I would suggest the following data model. As always, the feedback is highly appreciated (cc @ssasso @jbemmel @steffann @sdktr)
Client
Set ipv4 or ipv6 interface attribute to dhcp. That would require either significant hackery in
pre_link_transformandpost_link_transformhooks or modification ofaugment/links.pybut I couldn't figure out another way that wouldn't be cumbersome.From the final data model perspective, I think we should remove ipv4 and ipv6 attributes from the DHCP-enabled interfaces (or we'd have to rewrite all configuration templates to deal with this) and:
The ip address dhcp or whatever similar configuration should then be done in the DHCP configuration templates
Needs further study: ipv6 set to True should work flawlessly on most devices (as it enables IPv6 and LLA) and might be needed for Linux-based devices to enable IPv6 forwarding on the interface. Alternatively, we could skip this and deal with whatever needs to be dealt with in the DHCP configuration template(s).
Relay
Set dhcp.relay.server to the server IP address or list of IP addresses. Set dhcp.relay.vrf to the target VRF for inter-VRF DHCP relaying
Server
Set dhcp.server node attribute to True. I'm positive we'll need more nerd knobs; if you already know what you might need, please write a comment
Device features
For further study
It would be nice to support multiple Linux-based DHCP servers. It would be even nicer if we figure out how to do that without creating a bunch of new Linux-derived "devices".
Beta Was this translation helpful? Give feedback.
All reactions