Client classification based on device name. It is possible?

[Simon Hobson]

ÄÎÂÍÒÂÈ è•ÓÍÓÔ—ÛÍ wrote:

>Here is simplified configuration example:
>
>eth0 - don't used by dhcpd
>
>eth1 (no IP address, master for 802.1Q VLANs)
>
>eth1.21 10.0.0.0/16; 192.168.0.0/26
>eth1.22 10.1.0.0/16; 192.168.0.64/26
>eth1.23 10.2.0.0/16; 192.168.128.0/26
>eth1.24 10.3.0.0/16; 192.168.192.0/26
>
>And also, I don't have subinterfaces like eth.21:0 etc. I use multiple
>IP addresses for same interface.
>Like that:
># ip addr show dev eth1.21
>eth1.21 at eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP
>     link/ether 00:1b:21:4f:25:85 brd ff:ff:ff:ff:ff:ff
>     inet 10.0.0.0/16 brd 10.0.255.255 scope global eth1.21
>     inet 192.168.0.1/26 brd 192.168.0.63 scope global eth1.21
>
>And dhcpd.conf:
>
>shared-network alexpro
>{
>  #VLAN21 unknown MAC-addresses
>  subnet 192.168.0.0 255.255.255.192
>  {
>    pool
>   {
>    allow unknown-clients;
>    range 192.168.0.2 192.168.0.62;
>   }
>  }
>
>  #VLAN22 unknown MAC-addresses
>  subnet 192.168.0.64 255.255.255.192
>  {
>    pool
>   {
>    allow unknown-clients;
>    range 192.168.0.66 192.168.0.126;
>   }
>  }
>...

That is your problem - I guessed it probably was, 
but wanted to clarify your setup first. That's 
also why it's important to post your actual 
config, not some edited part of it that (in this 
case) had a vital information removed.


Different VLANs are **NOT** a shared network. 
Specifically, a shared network relates to having 
multiple subnets in the same broadcast domain.

So 10.0.0.0/16 and 192.168.0.1/26 are one shared network (in VLAN 21).
And 10.1.0.0/16 and 192.168.0.64/26 are in a 
**DIFFERENT** shared network (in VLAN 22).
And so on.

Why your config doesn't work is that a 
shared-network statement tell the DHCP server 
that all addresses in all ranges defined in 
subnets in that shared network are to be 
considered equally valid for that shared subnet. 
Thus, as you have it, the server has been told 
that (for example) 192.168.0.2 and 192.168.0.66 
are equal and can be allocated to any client in 
that shared subnet.

So what you need is :
shared-network vlan-21 {
  #VLAN21 unknown MAC-addresses
  subnet 192.168.0.0 255.255.255.192
  {
    pool
   {
    allow unknown-clients;
    range 192.168.0.2 192.168.0.62;
   }
  }
  #VLAN21 known MAC-addresses
  subnet 10.0.0.0 255.255.0.0
  {
    deny unknown-clients;
  }
}

shared-network vlan-22 {
  #VLAN22 unknown MAC-addresses
  subnet 192.168.0.64 255.255.255.192
  {
    pool
   {
    allow unknown-clients;
    range 192.168.0.66 192.168.0.126;
   }
  }
  #VLAN22 known MAC-addresses
  subnet 10.1.0.0 255.255.0.0
  {
    deny unknown-clients;
  }
}
and so on.


One other thing you've done that is a common mistake ...
>  subnet 10.0.0.0 255.255.0.0
>  {
>    deny unknown-clients;
>
>    host m1
>    {
>      hardware ethernet 00:01:02:03:04:05;
>      fixed-address 10.0.0.5;
>    }
>  }

Now, no matter where they are declared, host 
statements are global in scope. So this host 
declaration is valid **anywhere** in your 
network, not just in VLAN 21. Where it gets 
interesting is what happens if you plug it into 
VLAN 22.

It will (depending on any restrictions applied) 
get an address from a range in VLAN 22 - though 
in the config snippet you've posted, there won't 
(I don't think) be a dynamic address it's allowed 
to use.
Were it to get an address, then it would inherit 
options from the subnet where it's defined - 
including the router !
So you could have a device that got (say) 
192.168.0.66/26, but had a router of 192.168.0.1 
which isn't in the same subnet. We have had at 
least one query here where that was happening and 
it did take a little while to realise why.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.