[ale] dhcpd to multiple vlans from one server

[Michael B. Trausch]

On 01/22/2015 09:41 PM, Robert L. Harris wrote:
> I have multiple projects/products, etc at work we are breaking into
> separate broadcast domains ( currently 11, likely to be closer to 20
> ).  I don't want a different dhcp server per subnet/vlan.  I can put a
> trunk port to the dhcp server so if I can have dhcpd answering on each
> vlan so I have centrally managed dhcp, that's ideal.  So maybe I'm
> stuck doing the eth0.21, etc with an IP on each subnet and one dhcp
> server.

Hrm.

Perhaps another layout would be more fitting.

If the goal is to break things apart into broadcast domains, just use
multicast on a normal network infrastructure.

So:

  * Each project or product is assigned a multicast address from the
    Administratively Scoped region (239.0.0.0/8).  So, you can have
    Project A use 239.0.0.1 for the server(s) and 239.0.0.2 for
    "broadcasts".
  * Each server joins the server group (e.g., 239.0.0.1) and listens for
    UDP packets and sends UDP replies. If the service is TCP, then you'd
    use this to find the "real" address of the server (the UDP reply
    will come from the server's IP unicast address) and then use TCP to
    establish a connection to the server's unicast address.  This allows
    the software to always "latch" onto the server which replied first,
    providing a useful form of load-balancing.
  * Each interested party joins the broadcast group (239.0.0.2) and
    handles any received data.

This would require creating a little utility to add to a project to
listen to the server or broadcast addresses, and forward connection
information to the "real" software, but it doesn't require breaking the
network itself apart into several subnetworks and virtual LAN spaces.
You'd need a method of managing the locally-assigned address space (a
spreadsheet works just fine, honestly) and add the shim to the application.

As an example of an adapter that uses multicast to establish a
connection to a TCP application, imagine you have a fleet of Web
servers.  Of course, they use HTTP, which is on top of TCP.  But you
would not try to connect to a multicast IP address this way.  Instead,
you could have a little C program which listens on port 80, gets the
name of the host from the Host: header, sends a multicast request for
the server responsible for that name, the server answers, and the C
program sends a redirect to http://SERVER-UNICAST-ADDRESS/PATH.  The web
browser need not have any knowledge that multicast is used to handle the
connection in the end, and it doesn't care: it gets the resource it
wanted, and that's really all that matters.

The additional benefit here is that a single node can listen to multiple
groups without being on multiple VLANs and hogging up resources in the
network and packet filtering stacks.  This allows your network to handle
significantly more load with the same amount of resources.

    — Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20150123/0d8df5c8/attachment.html>