DHCP (Define vendor classes).
 

Есть система win 2003 server sp2 на ней поднят DHCP, в сети есть девайсы которые должны получать альтернатиные адресса, можно ли сделать допустим для девайсов CISCO получение определеных адрессов на основе например первой части мак адреса?!
Только не предлогайте резервирование). Заранее всем спасибо.

в DHCP создайте сеточку из 4 адресов, у вас будет ОДИН единственный определённый адрес, который и получит ваш Девайс.
В противном случае без резерва не обойтись.

обойтись! ты правильно написал в теме "классы произодителя\vendor classes" также могут быть и "классы пользователя\user classes". различие между ними в следующем:

клас производителя нельзя изменить административными способами, они прошиты в сетевой карте(здаёться мне что это первые шесть цифр.) какраз то что тебе нужно, возможно я не прав), а класс пользователя изменяеться по усмотрению администратора т.е. вручную для каждого интерфейса с помощью команды ipconfig /setclassid "адаптер" а просматриваеться ipconfig /showclassid "адаптер". на основании пренадлежности к классам ДХСП выдаёт соответствующие настройки.

сам я лично с этим не сталкивался. более подробней сказать не могу. но предпологаю, теоретически то что ты хочеш возможно без резерва. непомню точно но гдето слышал\читал что можно на основании классов пользователя сделать чтоб стационарные ПК получали адреса из одной сети, ноутбуки из другой, а устройства без пользовательского класса с третей.

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

wertyg, все не так хорошо как вы себе представляете. При помощи Define vendor classes - можно только переопределить scoupe options такие как dns, default garway и т.д.

К примеру - машинам которые находятся во внутренней сети вы хотите по dhcp раздать шлюз по умолчанию а которым подключены по vpn - нет. Или на какието машины раздать статические маршруты (выборочно).

А с назначением адресов ничего не выйдет.

Если не секрет для чего это нужно - может можно как то по другому решить?

artem_,
С пользовательскими классами понятно, но если ты говаришь

Получается одно и то же с User define classes? Или я что то непонял?
И еще немного непонятно, какую сеточку?

- да.

А про сеточку я сам не врубил.

И еще если этим устройствам нужны адреса из др. подсети - добавьте на dhcp 2ю сетевуху
и для этой сетевой создайте область.

сеть из 4 адресов к примеру: 192.168.0.32 255.255.255.252 - 32 ID сети, - 33 на шлюзе, - 34 адрес который назначится DHCP клиенту, - 35 broadcast.
Но это не подходит, если больше одного девайса, естественно.

exo,
Все равно получать будет девайс тот который первый затырит, да и девайсов несколько.

artem_,
Зачем тогда два одинаковых класса?
------------------------------------------------



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

так спать хочу только с командировки!
но взглянул поверхностно на ДХСП и увидел следующие:

1 - можно создать свой пользовательский класс.
2 - в своём пользовательском классе можно создать собственный параметр. один из создаваемых параметров может быть "IP address"
3 - можно создать новый вендор класс.
4 - там тоже можно создать свой параметр.

задача: приципить к вендору Cisco специальный IP адрес. ну кто быстрее решит?
я до выходный всё равно не смогу.

решение. создаём вендор класс. для этого надо проанализировать пакет к ДХСП серверу от устройства для которого создаётся класс и выяснить какой ИД вендора он передаёт. для этого нужно знать из чего состоит пакет ДХСП. я думаю выгуглить сроение ДХСП пакета это реально.
определяем для этого вендора на ДХСП опцию содержащюю ИП нам необходимый. номер опции нужно посмотреть в пакете от ДХСП к хосту, с какой опцией он передаёт ИП и маску для хоста.

также необходимо разобраться можно ли выдавать не один ИП(ато получаеться что у нас один вендор будет получать всегда один ИП, а в случае наличия нескольких подобных вендоров конфликта не избежать)

всем кто возмётся за решение гарантирован приз - опыт.)
если кто уже пробовал такое реализовать и знает наверняка чем все закончится просьба не молчать и разрешить проблему.

з.ы. возможно я что то не учёл в решении по пречине первой строки моего сообщения, в таком случае принимають дополнения.

wertyg,
:) уже ближе к делу. сейчас проанализирую пакеты на наличие ID определенного вендора(пусть даже виртуальной вмваре), вот только нетворк монитор незапускается, как что нибудь выясню отпишусь.

Есть подозрения что в пакете Discover строка client class information несет в себе ID, оно выглядит: 4d 53 46 54 20 35 2e 30 в ASCII это MSFT 5.0 тобишь класс вендора софтверного win2k/XP, вот заюзать железяку что б посматреть код запроса немогу((, нет пока возможности, кто нить капнет дальше?

да без резервирования вроде не обойтись.(

для пояснения немного вспомним как работает ДХСП. я не буду подробно обьяснять и рассматривать все возможные варианты развития событиий, всё это можно прочитать в инете, а возьму самый простой.

1 - клиент dhcpdiscovery(органиченно широковещательно) ищет сервер в сети. в этом пакете он передаёт список опций клиента. опция номер 55 перечень запрашиваемых опций. опция номер 77 - пользовательский класс. опция 60 класс производителя.
2 - сервер dhcpoffer(ограниченно широковещательно) сервер отвечаеть клиенту предложением.
3 - клиент dhcpreqvest(ограниченно широковещательно) клиент согласен с предложением просит подтверждения
4 - сервер dhcpack(ограниченно широковещательно) серверу нет причин отказать.
...
5 - клиент dhcpreqvest(серверу) по истечении времени аренды обращаеться к серверу за продлением.
6 - сервер dhcpack(клиенту) серверу нет причин отказать.

анализ пакета dhcpdiscovery показывает что переопределяються\дополняються опции. т.е. любое значение в поле опций пакета ДХСП. в то время как адрес устройствам передаёться не в опциях а в спец. поле ДХСП пакета. изменить\переопределить его с помощью опций невозможно.

вендор класс это опция номер 60. я так понял это производитель программы клиента ДХСП решает быть ей или нет. и соответственно она меняеться в зависимости от операционки(класс разработчика клиента) а не от производителя железа. например клиент ДХСП в голой FreeBSD не передаёт вендор класс в пакете(хотя опция такая всё же есть, только её нужно явно задать. и явно присвоить ей значение). вероятность того что маршрутизатор передаёт эту опцию ещё меньше.( ну а про юзер класс который присваеваеться вручную для маршрутизатора вообще молчу. к сожалению проверить немогу - маршрутизатора нет. но это уже не важно.)

вообщем не получаеться задавать\переопределять получаемые хостом ИП адреса с помощью вендор\юзер классов.(

з.ы. в результате эксперемента было обнаруженно следующие:
1 - FreeBSD клиент передаёт пакет продления аренды(5), на канальном уровне, не серверу у которого он её получил а ограниченно широковещательно, в отличии от MS клиента который пакет продления аренды(5) посылает, на канальном уровне, серверу. на что MS сервер не реагирует.) и соответственно не продлевает аренду пакетом (6).
2 - после истечения времени аренды FreeBSD всё ещё продолжает использовать полученный адрес. я так понял что у неё ввремя аренды отличаеться от предложенного сервером времени.
3 - команда ipconfig /showclassid <имя интерфейса> показывает допустимые классы пользователя определённые на ДХСП сервере(я думал что она должна показывать класс закреплённый за интерфейсом.). а класс закреплённый за интерфейсом она почемуто не показывает.
4 - команда ipconfig /setclassid <имя интерфейса> <имя класса> присваевает интерфейсу любое имя класса. т.е. без проверки есть ли такой на сервере. так на будущее. который передаёться в опции 77 пакета(1).
5 - команда ipconfig /setclassid <имя интерфейса> <без пробела нет ничего> сбрасывает присвоенный класс. опция 77 впредь отсутствует в пакетах(1).

з.з.ы я в никсах новичёк, возможно что то сделал не так(клиента ДХСП не настраевал вообще, просто включил и всё. но обратите внимание что настроек клиента в винде ещё меньше.)) ). если что поправьте.

з.з.з.ы слушай minion, а зачем такая необходимость? изложи задачу. возможно она решаеться ещё кокимто образом? ведь если маршрутизатор получит ИП из другой сети он не может взаимодействовать с хостами этой сети. и чтоже это за маршрутизатор такой, если им нельзя воспользоваться.

*работа ДХСП сервера описана в RFC номер 1541

wertyg,
Задача решима тем же самым резервированием, но мне было инетересно зачем создали тогда вендор класс, а вот client class information все же есть в пакете дхсп, и я почти уверен что он являеться ИД железки, или клиента дхсп как ты говарил. Просто нет железок что бы это все проверить(

minion, ну так я проверил. это таки
о чем и написал
во Freebsd не передаёться по умолчанию ни вендор ни пользовательский классы. пишутся они вручную.

обрати внимание на специфические опции например: адреса серверов Х. это для клиента *никсов и смысла нет передавать их винде. так же как и опции относящиеся к нетбиосу(приимущественно это к виндовому взаимодействию) передпвать кленту на *никсах.
судя по всему это и было сделано чтоб гиганские пакеты с порой ненужной информацией не гуляли по сети. а каждому клииенту передовалась только ему необходимая часть. логично?
почему два класса? ну тот что руками настраевается(пользовательский) это понятно - удобно. сам администратор настраевает вручную. но если сеть большая? очень большая? тут на помощ приходит вендор класс. уверен у разных винд он разный. ну я имею ввиду это самое "5.0" вот и работы уменьшилось.

а теперь вопрос в зрительный зал.) кто нить использовал данную возможность на практике?(если вдруг кто то знающий заглянет в пост)

значит тема остаётся открытой.)