Що DHCP-клієнт вважає найкращою відповіддю?

У нас є навчальні кімнати, де зазвичай встановлено Windows XP (через PXE). "Нормальною" інфраструктурою DNS / DHCP є сервери Windows. Навчальний зал має власну VLAN (відмінну від серверів Windows), тому найпоширенішим є IP-помічник для DHCP-запитів, активних на маршрутизаторі Cisco, до якого підключені всі ПК із цієї кімнати.

Тепер ми хотіли замість цього перетворити деякі ПК на Linux. Ідея полягала в тому, щоб: розмістити наш власний ноутбук із сервером DHCP у VLAN кімнати та замінити "нормальну" відповідь DHCP. Ідея полягала в тому, що це має працювати, оскільки безпосередньо приєднаний сервер DHCP у цій VLAN повинен мати швидший час реакції, ніж "звичайний" DHCP-сервер, розташований за деякими стрибками від цієї VLAN.

Виявилося, що це не спрацювало. Нам довелося вручну випустити оренду на оригінальному сервері DHCP, щоб працювати.

На ноутбуці ми бачили, як клієнт вимагає IP, і "наш" dhcp надсилав NACK на запит IP-адреси Windows, до цього ми пропонували власну відповідь.

Старе запитання: чому це не вийшло так, як очікувалося? Що змушує ПК повернути собі стару оренду?

Оновити 2012-08-08:

Питання відновлення було роз'яснено в DHCP-RFC. Тепер це пояснює, чому ПК повертає стару оренду.

Тепер ми випускаємо IP з сервера Windows-DHCP, перш ніж спробувати його.

Знову ж таки, Windows-DHCP-сервер виграє.

Я підозрюю, що існує якийсь алгоритм для dhcp-клієнта, який визначає "найкращий" dhcp-відповідь для клієнта. Нове питання:

Як клієнт обирає "найкращу" відповідь?

Це постачальник, навіть прошивка, конкретна, як клієнт реагує на кілька відповідей DHCP.

За ці роки я бачив варіанти:

1) Прийміть перше, незалежно від того, це ACK чи NACK.

2) Візьміть перший ACK, ігноруйте NACK повністю.

3) Візьміть останній отриманий ACK протягом встановленого інтервалу часу (зазвичай 5-10 секунд).

Приклад: Деякі роки тому у нас виникли проблеми з МФП Ricoh.
У нас було 2 сервери DHCP. Один постачав адреси, інший лише додаткові параметри DHCP. 2-й сервер завжди відповідав першим.
Використовуваний варіант Ricoh 1), навіть якщо перша пропозиція містила лише варіанти DHCP. Ricoh змінив його на варіант 2) з оновленням прошивки після того, як ми пояснили їм проблему.

Якщо припустити, що маршрутизатор як і раніше діє як реле DHCP і пересилає запит на ваш початковий сервер, то причиною цього є лише те, що сервер DHCP Windows сказав йому продовжувати та використовувати IP. У цьому випадку DHCPNACK з нового сервера не має значення, оскільки клієнт DHCP розгляне всі відповіді, а оскільки отримав пропозицію від вікна Windows DHCP, він абсолютно радий використовувати його.

ПК: О, привіт, світ, чи можу я використовувати 192.168.1.123?

New-DHCP: Я кажу "ні".

Старий-DHCP: Я кажу так.

ПК: Хтось сказав так! Солодке, я його використаю!

Якщо нічого іншого не допомагає - RTFM (прочитайте чудову інструкцію). У цьому випадку хітом був перший.

RFC 2131 окреслює DHCP-операції.

У розділі 1.6 зазначено, що DHCP повинен :

Зберегти конфігурацію клієнта DHCP через перезавантаження сервера і, коли це можливо, клієнту DHCP слід призначити ті самі параметри конфігурації, незважаючи на перезавантаження механізму DHCP,

Тепер цікавим питанням є те, як така мета дизайну досягається для клієнта, який не знає свого минулого. Розділ 3.2 окреслює:

3.2 Взаємодія клієнт-сервер - повторне використання раніше виділеної мережевої адреси

Якщо клієнт пам’ятає і бажає повторно використовувати раніше виділену
мережеву адресу, клієнт може вирішити опустити деякі етапи,
описані в попередньому розділі. Діаграма часової шкали на рисунку 4
показує часові відносини в типовій взаємодії клієнт-сервер для клієнта, що повторно використовує раніше виділений мережевий адресу.

1. Клієнт транслює повідомлення DHCPREQUEST у своїй локальній підмережі. Повідомлення включає мережеву адресу клієнта в опції "запитувана IP-адреса". Оскільки клієнт не отримав свою мережну адресу, НЕ МОЖЕ НЕ заповнювати поле 'ciaddr'. Реле-агенти BOOTP передають повідомлення на сервери DHCP не в одній підмережі. Якщо клієнт використовував "ідентифікатор клієнта" для отримання його адреси, клієнт ОБОВ'ЯЗКОВО повинен використовувати той самий "ідентифікатор клієнта" у повідомленні DHCPREQUEST.

2. Сервери з знаннями параметрів конфігурації клієнта відповідають на повідомлення клієнта DHCPACK. Сервери НЕ повинні перевіряти, що мережева адреса клієнта вже використовується; в цей момент клієнт може відповісти на повідомлення ICMP Echo Request.

Таким чином, DHCP-сервер, який тримає активну оренду, отримує перевагу за допомогою ярлика в протоколі.

1. Клієнт: DHCREQUEST (MAC-адреса, трансляція, буде передаватися в локальний домен мовлення - тут локальна VLAN та через IP-помічник на сервер Windows-DHCP)
2. Ноутбук-DHCP-сервер: DHCPOFFER
3. Windows-DHCP-сервер: Ей - я вже вас знаю - DHCPACK
4. Клієнт: О - я отримав два відповіді. Той, який мене вже знає. Класно, я візьму це

З цього моменту клієнт ігнорує Laptop-DHCP-сервер.

Тож рішення у нашому випадку, ймовірно, буде (я оновлю це, коли ми його фактично перевіримо):

1. Переконайтесь, що Клієнт вимкнено
2. Вимкніть DHCP-сервер на ноутбуці, підроблений клієнт-MAC на ноутбуці, DHCP-запит
3. Відпустіть IP
4. Відновіть оригінальний IP та MAC, увімкніть DHCP-сервер
5. Увімкніть клієнт і зробіть завантаження PXE ...

Нове запитання, мабуть, має бути в іншому питанні - назва питання зовсім не відповідає більшої частини питання.

У будь-якому випадку, що стосується того, як клієнт вибирає, з якою пропозицією піти, у випадку, коли у нього немає поточної оренди: це залежить від клієнта, але в кожному застосуванні клієнта DHCP, про який я знаю, це проста гонка .

RFC 2131 охоплює це:

Клієнти DHCP вільні використовувати будь-яку стратегію у виборі сервера DHCP серед тих, від яких клієнт отримує повідомлення DHCPOFFER.

Там є проект IETF , який здається мертвим, який би додав настроюваність до процесу вибору, а також згадує про нестабільну реалізацію клієнта (більше десяти років тому, але мало що змінилося):

На практиці реалізація політики більшості постачальників тут є дуже основною (наприклад, перша отримана пропозиція або перша прийнята пропозиція отримана) і є "жорстким кодом" (тобто не конфігурується).

Наявність двох серверів DHCP, що надають сервіс одній мережі з різною конфігурацією, просто призводить до перегонів, що не бажано з точки зору надійності чи передбачуваності. Дійсно немає причин, коли ви не можете отримати свій єдиний сервер DHCP, щоб забезпечити необхідне.