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) от количества описанных классов, так что масштабируется это решение не очень.
ВНЕЗАПНО осознал, что в протоколе RADIUS идентификатор запроса/ответа - 8-битное поле. Поэтому идея транслировать DHCP-запросы в RADIUS-запросы для крупных сетей порочна изначально - более чем 256 одновременных запросов от одного DHCP-сервера к одному RADIUS-серверу независимо от мощностей оборудования делать нельзя без какого-нибудь хитрого мультиплексирования (типа тысячи IP-алиасов на DHCP-сервере), что тоже криво само по себе.
Интересно, насколько хорошо работает FreeRADIUS в роли транслятора между DHCP-протоколом и базой MS SQL. И бывают ли другие трансляторы такого сорта.