ISC-DHCPD advanced practices

[dadv]

В ISC-DHCPD с версии 4.2 появилась есть возможность делать такое:

shared-network HotSpot {
 subnet 10.45.50.0 netmask 255.255.255.0 {
    option routers 10.45.50.1;
 } 
 class "AP1-vlan1096" {
    match if binary-to-ascii(16, 8, ":", hardware) = "1:0:27:22:52:8a:85"
         and binary-to-ascii(16, 8, ".", option agent.circuit-id) = "0.4.4.48.0.5";
 }
 pool {
    allow members of "AP1-vlan1096";
    range 10.45.50.11;
 }
 pool {
    deny members of "AP1-vlan1096";
    range x.x.x.x x.x.x.y;
 }
}

То есть, если AP1 (определяемая по её MAC 0:27:22:52:8a:85) запросила адрес в vlan 1096 (0x448) на шестом порту каталиста (который и вставил в запрос option 82 с этими данными), то выдаётся статический адрес 10.45.50.11. А если из другого, то на общих основаниях, из отдельного пула.

Тут же кучка заботливо разложенных граблей: функция binary-to-ascii() отрезает ведущие нули в каждом октете (буквы делает нижнего регистра); внутренная реализация классов в версии 4.2 имеет вычислительную сложность O(n*n) от количества описанных классов, так что масштабируется это решение не очень.

Comments

[dadv.livejournal.com]

Да, чуть попутал. Это "host-identifier option agent.circuit-id" появилось с 4.2, а сам agent.circuit-id раньше.
Насчет автоматизма в обработке option 82, в случае с классами можно наворачивать любую логику по проверке дополнительных атрибутов запроса.

[http://users.livejournal.com/_slw/]

но не нужно. поскольку на разные vlanы и так будут идти разные диапазоны, то все автоматом будет работать в виде

subnet 10.200.69.0 netmask 255.255.255.0 {
бла-бла-бла.
}

а если кому-то хочется дать индивидуальных извращений то прямо в можно писать

if binary-to-ascii(16, 8, ":", hardware) = "1:0:50:56:89:58:cf" {
default-lease-time 300;
}

без всяких классов.

[dadv.livejournal.com]

> поскольку на разные vlanы и так будут идти разные диапазоны, то все автоматом будет работать в виде

А вот не факт. У нас в сети реализован RFC3069, один диапазон /19 на тысячи vlan-ов, два домена vlan-ов, соединённых L3-линком между роутерами, каждому юзеру выдаётся по DHCP один из двух адресов шлюза, константная маска и собственный IP, независимый от IP соседей по vlan-у. DHCP-запрос проходит через роутер, являющийся DHCP-релейем, который берет из DHCPACK адрес юзера и создаёт static route /32 в юзеровский vlan, после чего ip verify unicast source reachable-via rx на interface Vlan начинает пропускать пакеты от этого юзера в мир. А если он аренду не продлил, то роутер этот /32 удаляет.

[coctic]

А какой роутер умеет создавать static route при пролете DHCPACK?

[dadv.livejournal.com]

Cisco

[coctic]

Видимо, это фишка именно роутеров. Вроде как про Cat3560 говорят, что он RC3069 умеет, и называется там это Private VLAN, и Ip source guard и DHCP snooping там есть, но как все это скрутить, чтоб он еще и маршруты проставлял - я из докментаци не понял. Может, L3 свитч такого и не умеет.

[dadv.livejournal.com]

У нас 7606 :-)
Причём никакой особой команды чтобы он роуты проставлял я не ставил, "оно само" стало это делать после того, как включен был DHCP Relay и проставлен ip unnumbered Loopback2 на interface Vlan и в DHCPACK стали выдаваться адреса с адресом шлюза, равным адресу на Loopback2.

[dadv.livejournal.com]

Да, на самом роутере на каждом vlan стоит ip unnumbered Loopback2, где собственно адрес шлюза, выдаваемый клиентам, и прописан.

[http://users.livejournal.com/_slw/]

ну вот по этому ip они и будут попадать в нужные субнеты.
так что не вижу противоречия

[dadv.livejournal.com]

В описанном случае сабнет один, /19.