[ale] dhcpd to multiple vlans from one server

[Robert L. Harris]

  Today it's primarily the broadcast domains.  In the near future it'll
include some firewalling/ACLs blocking certain device communications and
traffic shaping.  One group thinks that since they have 1G to thier devices
they should be able to use all the available bandwidth, others should all
have a full gig also.  I have mutliple stages I want to do to make this a
manageable, sustainable network but breaking them into smaller, controlled
vlans is the first step.


On Fri Jan 23 2015 at 10:53:53 AM Michael B. Trausch <mike at trausch.us>
wrote:

> 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
>  _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20150123/7b024d4c/attachment.html>