каких настроек? имя интерфейса на котором слушает ISC DHCP указывается при его запуске аВам то же самое говорит? IMHO лучше закрыть прямо на свиче да, на свиче ... не удивляйтесь ... DHCP relay работает до ACL, т.е. если закрыть на свиче то в сервер придут только пакеты от свича, а от пользователей - нет ...слово "RADIS" 35-й свич прекрасно знает а вот все остальные слова, включая слово "RADIUS", имеют отношение только либо к кошкаротерам либо к шести/семитонным кошколистам кои имеют такую цену вопроса что юзать их иначе как в ядре просто бессмысленная трата денег, IMO ...

_________________
с уважением, БП

Лана. Это уже флуд не по теме

Проблемма решилась. Если интересно -- скажу как. Появилась другая. Виндовс клиенты не могут получить адрес по DHCP

Рад слышать! Озвучьте пожалуйста. И опишите подробно вторую проблему.

%-)

Всё, что опишу ниже будет казаться бредом, но вам придётся поверить.

Итак, настроек ДХЦП не менял (всё как описано выше). Посмотрел на конфиги виланов на свиче... и подумал: "А какого лешего с вилана под тэгами 100 и 200 приходят Circuit-ID, а с других нет?"

Поправил тэги на 101, 102, 103 и т.д. Поправил классы в dhcpd.conf. Проверяю... Работает! Брр. Ставлю эксперимент 2. Поправил тэги на 2, 3, 4 и т.д., правлю дхцп сервер -- не работает! Ничего не понимая, перевожу всё к виду 101, 102, ... Вуаля! Circuit-ID чудненько нередаются в транк.

Вот так

Сейчас проблемка только в виндовых дхцп-клиентах. Опишу пока вкратце и сумбурно -- сам разбирабсь. В один из портов (влановых) воткнут DES-1026G -- наша локалка. Тонкие клиенты и просто линукс-клиенты работают на ура. При анализе логов dhclient видно, что после DHCPREQUEST приходит два ответа:
1. DHCPNAK от интерфеса той подсети, которой принадлежит вилан (напр., 192.168.1.254)
2. DHCPPACK от свитча (10.90.90.90)

Вот. Линукс-клиент после DHCPPACK берёт себе адрес и опопвещает сервак, а виндовс-клиент -- нет. Что-то типа так...

Так что у вас с виндовс-клиентами? ... разобрались?

У Вас случайно не этот случай:
http://sadnet.ru/index.php?option=com_c ... &Itemid=33

Откровенно говоря я так и не понял ситуацию с giaddr и двумя вланами на коммутаторе.
На всякий случай условная схемка сети
3526 с dhcp relay agent и option 82:
- с клиентами, порты 1-24 untagged в vlan таг 10, скажем подсеть 192.168.1.0/24.
- с dotq транками 25,26 и управляющим vlan таг 20 ip скажем 172.16.0.1/24.
всё это транком упирается в L3 агрегирующий свич откуда далее попадает в сетку где расположен ISC-DHCPD с адресом 10.0.0.1.

Смотрим дампом что попадает на сервер:

dhcp# tcpdump -p -n -vv -s 1500 src host 172.16.0.1
tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 1500 bytes
Gateway IP: 172.16.0.1
Client Ethernet Address: .........
Vendor-rfc1048:.........

Для тестирования используются конфиги выше по теме, адаптированные под мои адреса.

Итак несколько вариантов развития событий, которые удалось установить эксперементально:
1. Если dhcp сервер вообще не знает о существовании сети с железками, то до логирования по условию "if exists agent.remote-id and exists agent.circuit-id" дело вообще никогда не доходит, что в целом довольно логично, и в лог кладётся unknown network segment.
2. Если dhcp сервер знает "понаслышке" об этой сети ( типа subnet 172.16.0.0 netmask 255.255.255.0 {} ), то сервер откладывает в лог запись по условию, и до кучи network 172.16.0.0/24: no free leases.
3. Если пул для класса клиента запихнуть в subnet адресного пространства управляющего vlan свича, то клиенту отлично выдаётся адрес из 172.16.0.*, разумеется ничего при этом не работает.
4. Ну а если пул для класса клиента находится как и положено в subnet 192.168.1.* то клиенту попросту ничего не выдаётся и всё.

Все глаза себе сломал читая форум как этот, так и другие - тема эта поднималась, но в ответ звучало КОНЕЧНО ВСЁ РАБОТАЕТ без конеретного примера КАК.

На всякий случай привожу пример как описан класс (используется комбинация IP:Port коммутатора):

class "test_class" {
match if concat(binary-to-ascii(10, 8, ".", packet(24, 4)), ":", binary-to-ascii(10, 8, "", substring(option agent.circuit-id, 5, 1))) = "172.16.0.1:24";
}

24 порт выбран потому что dhcpdump при выборе порта ниже 10 просто напрочь сносит мозги ssh putty клиенту, он входит в полный ступор и убивается только как процесс тоже одна из непостижимых загадок

Какая у вас версия прошивки?

B26 вроде бы.. последняя какую мне Бигаров Руслан прислал.
Собственно эту проблему я уже решил, если кому интересно могу поделиться путём решения.

В прошедшие выходные в русле этой тематики даже несколько интересных на мой взгляд решений придумал.

Щас вот столкнулся с такой ситуацией:
несколько 3526 в двух параллельных вланах, одном управляющем и одном пользовательском. Все коммутаторы как релей с опцией 82, все настроены на 1 dhcp сервер. К одному из коммутаторов подключен клиент, на нём включен dhcp-клиент.
Смотрим логи и дампы на сервере:
Клиент отправляет запрос, и от КАЖДОГО коммутатора приходит транслированный запрос, причём соотвественно в каждом случае от имени того релея от которого пришёл транслированный запрос и с chaddr соответственно клиента подключенного к одному из коммутаторов.
В целом я конечно понимаю, что остальные коммутаторы просто получают оригинальный запрос клиента через транк в рамках одного vlan, тем не менее не понимаю, почему после приёма dhcp релеем запроса, этот пакет форвардится далее в сетку.
Наверное вопрос сформулирую так: можно ли отключить функцию релея на транк портах ? Ну или обобщая - на произвольных портах ?

Нет, отключать Relay на определённых портах нельзя. Но мы готовим прошивку, в которой при включении Relay, Broadcast DHCP пакеты будут блокировать в клиентских VLAN-ах. Это как раз и избавит от вышеуказанной проблемы.

т.е. свичи не будут реагировать на эти пакеты но продолжать слать будут и больше свичей/клиентов == больше пакетов == больше нагрузка на сеть и т.д. и т.п., так получается?

_________________
с уважением, БП

Нет они будут отсекаться на свитче где подключён клиент.

т.е. пакет входит в порт, CPU свича его перехватывает, релит на сервер и, можно сказать, для сети этот пакет умирает, я правильно все понимаю?

_________________
с уважением, БП

Именно.