<div><br></div>  Today it&#39;s primarily the broadcast domains.  In the near future it&#39;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.  <br><div><br></div><br><div class="gmail_quote">On Fri Jan 23 2015 at 10:53:53 AM Michael B. Trausch &lt;<a href="mailto:mike@trausch.us">mike@trausch.us</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <div>On 01/22/2015 09:41 PM, Robert L.
      Harris wrote:<br>
    </div>
    <blockquote type="cite">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&#39;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&#39;s ideal.  So maybe I&#39;m stuck doing the eth0.21, etc
      with an IP on each subnet and one dhcp server.</blockquote>
    <br></div><div bgcolor="#FFFFFF" text="#000000">
    Hrm.<br>
    <br>
    Perhaps another layout would be more fitting.<br>
    <br>
    If the goal is to break things apart into broadcast domains, just
    use multicast on a normal network infrastructure.<br>
    <br>
    So:<br>
    <ul>
      <li>Each project or product is assigned a multicast address from
        the Administratively Scoped region (<a href="http://239.0.0.0/8" target="_blank">239.0.0.0/8</a>).  So, you can
        have Project A use 239.0.0.1 for the server(s) and 239.0.0.2 for
        &quot;broadcasts&quot;.</li>
      <li>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&#39;d use this to find the &quot;real&quot; address of the
        server (the UDP reply will come from the server&#39;s IP unicast
        address) and then use TCP to establish a connection to the
        server&#39;s unicast address.  This allows the software to always
        &quot;latch&quot; onto the server which replied first, providing a useful
        form of load-balancing.</li>
      <li>Each interested party joins the broadcast group (239.0.0.2)
        and handles any received data.</li>
    </ul>
    <p>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 &quot;real&quot; software, but it doesn&#39;t
      require breaking the network itself apart into several subnetworks
      and virtual LAN spaces. You&#39;d need a method of managing the
      locally-assigned address space (a spreadsheet works just fine,
      honestly) and add the shim to the application.<br>
    </p>
    <p>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
      <a href="http://SERVER-UNICAST-ADDRESS/PATH" target="_blank">http://SERVER-UNICAST-ADDRESS/PATH</a>.  The web browser need not have
      any knowledge that multicast is used to handle the connection in
      the end, and it doesn&#39;t care: it gets the resource it wanted, and
      that&#39;s really all that matters.<br>
    </p>
    <p>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.<br>
    </p>
    <p>    — Mike<br>
    </p>
  </div>

______________________________<u></u>_________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/<u></u>listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/<u></u>listinfo</a><br>
</blockquote></div>