<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFCC" text="#000000">
    In the full config there is a CLASS declaration in EACH subnet. This
    adds to the confusion as the clients get matched against both class
    declarations and inheritance is even less clear as the classes have
    the SAME name.<br>
    <br>
    @John<br>
    There are some places in the man pages that are not perfectly clear
    and I believe not entirely correct, except in the latest version(s).<br>
    <br>
    <div class="moz-cite-prefix">On 10/12/13 16.11, John Wobus wrote:<br>
    </div>
    <blockquote
      cite="mid:A8C3AB0E-B9BE-41AE-A552-9EBB1853A508@cornell.edu"
      type="cite">So if I understand correctly, like a host declaration,
      <br>
      a class declaration inherits the directives (e.g. option
      declarations)
      <br>
      from the surrounding configuration, but is applied to
      <br>
      clients based upon its own matching rules, even if the
      <br>
      client is on a different subnet.  Seems that analogous to hosts,
      <br>
      classes can be confusing when declared inside a subnet
      declaration.
      <br>
      <br>
      My copy of the DHCP book says classes are more specific than
      ranges and
      <br>
      subnets but less specific than hosts.
      <br>
      <br>
      I recall in the past there were folks on this list who insisted on
      seeing
      <br>
      the entire configuration (without ellipses or hiding edits) when
      trying
      <br>
      to explain reported behavior.
      <br>
      <br>
      John Wobus
      <br>
      Cornell IT
      <br>
      <br>
      On Dec 10, 2013, at 8:45 AM, Glenn Satchell wrote:
      <br>
      <br>
      <blockquote type="cite">Ah, I think I see it now that we have the
        full config. If these clients
        <br>
        boot using PXE (and the early packet trace looked like they
        might) then
        <br>
        they will be members of the at least the first pxeclients class
        as they
        <br>
        match the match statement. Because the class is defined inside
        the subnet,
        <br>
        it inherits values from that subnet. This is the same logic that
        arises
        <br>
        from moving the host definitions into the subnet scope.
        <br>
        <br>
        Apart from the next-server setting, these two classes look the
        same. So
        <br>
        define the class once, outside the shared-network, and in each
        subnet or
        <br>
        host or group add a next-server statement pointing to the
        specific tftp
        <br>
        server. That option shouldn't make any difference in non-PXE
        boots.
        <br>
        <br>
        class "pxeclients" {
        <br>
         ...
        <br>
        }
        <br>
        shared-network ... {
        <br>
         subnet ... {
        <br>
           next-server ...;
        <br>
         }
        <br>
         subnet ... {
        <br>
           next-server ...;
        <br>
         }
        <br>
        }
        <br>
        # or like this
        <br>
        group {
        <br>
         next server ...;
        <br>
         host1 { ... }
        <br>
         host2 { ... }
        <br>
        }
        <br>
        host3 { ... }
        <br>
        <br>
        regards,
        <br>
        -glenn
        <br>
        <br>
        On Wed, December 11, 2013 12:02 am, Brian J. Murrell wrote:
        <br>
        <blockquote type="cite">
          <br>
          On Mon, 2013-12-09 at 17:18 -0500, John Wobus wrote:
          <br>
          <blockquote type="cite">
            <br>
            It sounds wrong to me.   Where did you move the host
            declaration from?
            <br>
          </blockquote>
          <br>
          Basically changing from a:
          <br>
          <br>
          shared-network ... {
          <br>
           subnet ... {
          <br>
           }
          <br>
           subnet ... {
          <br>
           }
          <br>
          }
          <br>
          host1 { ... }
          <br>
          host2 { ... }
          <br>
          host3 { ... }
          <br>
          <br>
          type structure to a:
          <br>
          <br>
          shared-network ... {
          <br>
           subnet ... {
          <br>
           }
          <br>
           subnet ... {
          <br>
             host1 { ... }
          <br>
             host2 { ... }
          <br>
             host3 { ... }
          <br>
           }
          <br>
          }
          <br>
          <br>
          type structure, which as I understand is not necessary nor
          encouraged.
          <br>
          <br>
          <blockquote type="cite">Was it within some other scope that
            had these 'wrong option values'
            <br>
            defined?
            <br>
          </blockquote>
          <br>
          It shouldn't have been.  When it was structured like the first
          example
          <br>
          above, my clients would get an ip address from the second
          defined subnet
          <br>
          (the only one with a range, btw -- the first subnet had no
          range defined
          <br>
          because all hosts in it had fixed-address specifications) and
          their
          <br>
          options (netmask, router, etc.) from the first subnet
          definition.
          <br>
          <br>
          <blockquote type="cite">The matching host declaration is the
            "most specific" declaration for a
            <br>
            matching host and overrides other declarations such as
            subnet.
            <br>
          </blockquote>
          <br>
          Right.  But when that host gets it's lease it should get
          options from
          <br>
          either the host declaration or the subnet from which it's IP
          address was
          <br>
          assigned, not other subnets in the same shared-network
          declaration.
          <br>
          <br>
          <blockquote type="cite">This
            <br>
            includes option declarations/values inherited from the scope
            that
            <br>
            surrounds the host declaration.
            <br>
          </blockquote>
          <br>
          And the subnet declaration from where it's IP address was
          assigned, yes?
          <br>
          <br>
          <blockquote type="cite">If an option is defined globally, then
            a host declaration in global
            <br>
            space
            <br>
            will pick it up, i.e., it's as if you put that option
            definition in
            <br>
            that host declaration.  If the host declaration resides
            within a group
            <br>
            declaration, then the host declaration will pick up an
            option defined
            <br>
            in that group, or if the group does not override a global
            declaration
            <br>
            for the option, from the globally-defined option.
            <br>
          </blockquote>
          <br>
          This is a good explanation but you fail to mention the options
          defined
          <br>
          in the subnet declaration from where the host's IP address was
          assigned.
          <br>
          <br>
          <blockquote type="cite">Thus, what you got could result from
            parts of the configuration you
            <br>
            haven't shown us.
            <br>
          </blockquote>
          <br>
          There is no other parts.  Here's my total configuration,
          obviously not
          <br>
          including every single host declaration, but they are all the
          same:
          <br>
          <br>
          authoritative;
          <br>
          ddns-update-style interim;
          <br>
          ddns-domainname "foo.example.com";
          <br>
          ddns-updates on;
          <br>
          update-optimization false;
          <br>
          deny duplicates;
          <br>
          <br>
          allow booting;
          <br>
          allow bootp;
          <br>
          <br>
          ignore client-updates;
          <br>
          set vendorclass = option vendor-class-identifier;
          <br>
          <br>
          option pxe-system-type code 93 = unsigned integer 16;
          <br>
          <br>
          shared-network foo {
          <br>
             subnet 192.168.0.0 netmask 255.255.255.0 {
          <br>
                  option routers             192.168.0.1;
          <br>
                  server-identifier          192.168.0.1;
          <br>
                  option domain-name         "foo.example.com";
          <br>
                  option domain-name-servers 192.168.0.4;
          <br>
                  option subnet-mask         255.255.255.0;
          <br>
                  default-lease-time         21600;
          <br>
                  max-lease-time             43200;
          <br>
                  class "pxeclients" {
          <br>
                       match if substring (option
          vendor-class-identifier, 0, 9) =
          <br>
          "PXEClient";
          <br>
                       max-lease-time 10;
          <br>
                       if option pxe-system-type = 00:02 {
          <br>
                               filename "ia64/elilo.efi";
          <br>
                       } else if option pxe-system-type = 00:06 {
          <br>
                               filename "grub/grub-x86.efi";
          <br>
                       } else if option pxe-system-type = 00:07 {
          <br>
                               filename "grub/grub-x86_64.efi";
          <br>
                       } else {
          <br>
                               filename "pxelinux.0";
          <br>
                       }
          <br>
                  }
          <br>
             }
          <br>
             subnet 172.1.10.0 netmask 255.255.248.0 {
          <br>
                  option routers             172.1.10.1;
          <br>
                  server-identifier          172.1.10.1;
          <br>
                  option domain-name         "foo.example.com";
          <br>
                  option domain-name-servers 172.1.10.8, 172.1.10.9,
          172.1.10.6;
          <br>
                  option subnet-mask         255.255.248.0;
          <br>
                  range dynamic-bootp        172.1.10.100 172.1.13.254;
          <br>
                  default-lease-time         21600;
          <br>
                  max-lease-time             43200;
          <br>
                  class "pxeclients" {
          <br>
                       match if substring (option
          vendor-class-identifier, 0, 9) =
          <br>
          "PXEClient";
          <br>
                       max-lease-time 10;
          <br>
                       next-server 172.1.10.6;
          <br>
                       if option pxe-system-type = 00:02 {
          <br>
                               filename "ia64/elilo.efi";
          <br>
                       } else if option pxe-system-type = 00:06 {
          <br>
                               filename "grub/grub-x86.efi";
          <br>
                       } else if option pxe-system-type = 00:07 {
          <br>
                               filename "grub/grub-x86_64.efi";
          <br>
                       } else {
          <br>
                               filename "pxelinux.0";
          <br>
                       }
          <br>
                  }
          <br>
             }
          <br>
          }
          <br>
          <br>
          zone foo.example.com {
          <br>
             primary 127.0.0.1;
          <br>
          }
          <br>
          <br>
          zone 10.1.172.in-addr.arpa {
          <br>
             primary 127.0.0.1;
          <br>
          }
          <br>
          <br>
          zone 11.1.172.in-addr.arpa {
          <br>
             primary 127.0.0.1;
          <br>
          }
          <br>
          <br>
          zone 12.1.172.in-addr.arpa {
          <br>
             primary 127.0.0.1;
          <br>
          }
          <br>
          <br>
          zone 13.1.172.in-addr.arpa {
          <br>
             primary 127.0.0.1;
          <br>
          }
          <br>
          <br>
          zone 0.168.192.in-addr.arpa {
          <br>
             primary 127.0.0.1;
          <br>
          }
          <br>
          <br>
          <br>
          # Record static assignments for infrastructure here.  Even if
          the machines
          <br>
          # are not using DHCP, we should centralize the mac/ip
          mappings.
          <br>
          host host-1.foo.example.com {
          <br>
             hardware ethernet 00:1e:67:6d:37:17;
          <br>
             fixed-address 172.1.10.4;
          <br>
          }
          <br>
          ...
          <br>
          <br>
          group {
          <br>
             host host-4vm2 {
          <br>
                 hardware ethernet 52:54:00:04:D9:02;
          <br>
                 option host-name="host-4vm2";
          <br>
                 ddns-hostname "host-4vm2";
          <br>
             }
          <br>
             host host-4vm3 {
          <br>
                 hardware ethernet 52:54:00:04:D9:03;
          <br>
                 option host-name="host-4vm3";
          <br>
                 ddns-hostname "host-4vm3";
          <br>
             }
          <br>
          ...
          <br>
          }
          <br>
          <br>
          In any case, having since looked at this problem a little more
          closely,
          <br>
          I have noticed that because my dhcpd is on a RHEL6[.4] system,
          compared
          <br>
          to the current release stream, it's quite old and fairly
          heavily
          <br>
          patched.  So it's entirely possible that this is an already
          fixed (i.e.
          <br>
          upstream) bug or one of the patches has introduced it, so I
          really
          <br>
          should take my concern back to RH and not really bother you
          folks here
          <br>
          with such old software.
          <br>
          <br>
          Cheers,
          <br>
          b.
          <br>
          <br>
          <br>
          _______________________________________________
          <br>
          dhcp-users mailing list
          <br>
          <a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a>
          <br>
          <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a>
          <br>
        </blockquote>
        <br>
        <br>
        _______________________________________________
        <br>
        dhcp-users mailing list
        <br>
        <a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a>
        <br>
        <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a>
        <br>
      </blockquote>
      <br>
      _______________________________________________
      <br>
      dhcp-users mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a>
      <br>
      <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a>
      <br>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 
</pre>
  </body>
</html>