DHCP module

[ipspace]

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_transform and post_link_transform hooks or modification of augment/links.py but 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:

• Set dhcp.client.ipv4 to True for interfaces using DHCPv4
• Set dhcp.client.ipv6 and ipv6 to True for interfaces using DHCPv6.

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

• dhcp.client -- supports DHCP client (do we need ipv4/ipv6 flags?)
• dhcp.relay -- supports DHCP relaying
• dhcp.vrf.relay -- supports inter-VRF relaying
• dhcp.server -- supports DHCP server

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".

[steffann]

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 :)

[ipspace]

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?

[ssasso]

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".

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.
The supported sub-modules can be described on device yml file.

[ipspace]

Love the idea of sub-modules. Thank you.

[ssasso]

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 ;) )

[ipspace]

Agreed. Something along the lines of dhcp.default which influences what the DHCP client asks to get from the DHCP server?

[ipspace]

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).