
<html>

  <head>

    <meta content="text/html; charset=windows-1252"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <div class="moz-cite-prefix">On 01/22/2015 09:41 PM, Robert L.

      Harris wrote:<br>

    </div>

    <blockquote

cite="mid:CAOXayVu7G_ou0T9xuxtM9kJaULnFQSPFG6ycm1Ganhqfdc4CRw@mail.gmail.com"

      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'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.</blockquote>

    <br>

    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 (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".</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'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.</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 "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.<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 class="moz-txt-link-freetext" href="http://SERVER-UNICAST-ADDRESS/PATH">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't care: it gets the resource it wanted, and

      that'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>

  </body>

</html>