[Kea-users] Configuring kea for relayed subnets *not* on its own interface's address

Jeff Kletsky kea-dhcp at allycomm.com
Wed Sep 13 17:32:55 UTC 2017


On 9/13/17 8:47 AM, itay cohen wrote:
> are you using "ip helper" to relay the dhcp requests ?
>
>
> On Wed, Sep 13, 2017 at 4:33 AM, Jeff Kletskywrote:
>
>     I've been able to get kea to run nicely as a DHCP server in
>     "conventional" mode with an interface listening on every one of
>     the VLANs that I need to serve.
>
>     I'm trying to configure it now so that it only responds to relayed
>     DHCP through my Cisco SG300-series switches.
>
>         "dhcp-socket-type": "udp"
>
>     is already set.
>
[...]

The Cisco SG300-series devices have a built-in DHCP relay that attaches 
the Option 82 information, encoding the VLAN and device port on which 
the request was made. Each VLAN that needs DHCP service can then enabled 
in the "interface vlan NNNN" configuration. Using the "ip-helper" 
functionality, at least as I understand it, would lose the 
VLAN/attach-port information that is required to determine the proper 
subnet/pool/address for clients attached to the switch.

I'm intentionally *not* using broadcast to the DHCP server so that I can 
prevent opening any raw/promiscuous socket on a device that is 
potentially exposed to "unfriendly" devices (for example, WiFi 
connections and IoT devices).  Yes, I agree that the switch itself is 
subject to unfriendly traffic, but I consider it less vulnerable than a 
full-on `nix platform, assuming the SG300's firmware is kept up to date 
and that access to its management interfaces is appropriately limited.

As the dedicated management VLAN is distinct from the dedicated DHCP 
VLAN and there are multiple subnets involved for multiple, 
routing-isolated VLANs, each SG300 needs to be in L3 mode ("set system 
mode router") so that more than one IP address can be configured for the 
SG300. This mode potentially allows cross-VLAN traffic unless explicitly 
blocked with a series of "ip route <subnet> reject-route" statements.

The kea "relay" statement within a "subnet" block allows for one of the 
multiple relays to have that subnet checked for the matching 
VLAN-specific client class. As mentioned in an earlier message in this 
thread, that statement appears to only support a single IP address and 
cannot be repeated within a subnet to allow consideration by more than 
one relay.  This is a limitation as there are multiple SG300 units and 
attach-port information would be lost if all VLANs were trunked to a 
single relay.

It is possible in the SG300 to define the target DHCP server(s) by VLAN, 
at least through the CLI.  While it would mean maintaining an address 
alias on the interface of the box running kea for each VLAN served, this 
might be the path I take.


Jeff




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20170913/c05f13cd/attachment.htm>


More information about the Kea-users mailing list