<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<tt>On 9/13/17 8:47 AM, itay cohen wrote:</tt><tt><br>
</tt>
<blockquote type="cite"
cite="mid:CAKvjZfjqdH=GbJvGzkiMjstV29a0WXwr0wrjZL_EriRnj_n3mQ@mail.gmail.com">
<div dir="ltr"><tt>are you using "ip helper" to relay the dhcp
requests ?</tt>
<div><tt><br>
</tt></div>
</div>
<div class="gmail_extra"><tt><br>
</tt>
<div class="gmail_quote"><tt>On Wed, Sep 13, 2017 at 4:33 AM,
Jeff Kletsky</tt><tt> wrote:</tt><tt><br>
</tt>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><tt>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.</tt><tt><br>
</tt> <tt><br>
</tt><tt>
I'm trying to configure it now so that it only responds to
relayed DHCP through my Cisco SG300-series switches.</tt><tt><br>
</tt> <tt><br>
</tt><tt>
"dhcp-socket-type": "udp"</tt><tt><br>
</tt> <tt><br>
</tt><tt>
is already set.</tt><br>
</blockquote>
</div>
</div>
</blockquote>
<tt>[...]</tt><tt><tt><br>
<br>
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. </tt><tt>Each VLAN that
needs DHCP service can then enabled in the "interface vlan NNNN"
configuration. </tt></tt><tt><tt><tt>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.</tt></tt><tt><br>
<br>
</tt>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.<br>
</tt><tt><br>
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.<br>
<br>
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.<br>
<br>
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. <br>
<br>
<br>
Jeff<br>
<br>
</tt><tt> </tt><tt><br>
</tt><tt><br>
</tt><br>
</body>
</html>