Хоча DHCP полегшує життя адміністратора, іноді клієнтська машина стикається з проблемами при отриманні адреси. У таких ситуаціях інформація часто буває мізерною. Крім того факту, що робоча станція не отримала адреси, більше нічого невідомо. Тут починають відігравати роль знання процесів DHCP і Netmon.

Діалог з DHCP сервером

Перш за все, необхідно перевірити, що машина була зконфігурована для запиту адреси. Якщо у вікні властивостей TСР/ІР відмічена властивість "отримувати IP-адресу з сервера DHCP", то це повинно працювати. Якщо ні, необхідно переривати Netmon і проглянути діалог. У ідеалі повинні бути присутніми чотири кадри, перелічені нижче.

1. Пошук DHCP

2. Пропозиція DHCP

3. Запит DHCP

4. DHCP АСК

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

Аналіз діалогу комп’ютерів у мережі

Перший крок полягає в перегляді трасування і пошуку пропущеного кадру. Кадр запиту DHCP посилається за допомогою багатоадресової розсилки UDP IP з порту 68 (клієнтський порт ВООТР), в порт 67( серверний порт ВООТР). Magic cookie будуть правильними. Це чотирьохбайтна область в пакеті DHCP, яка ідентифікує початок поля, означеного постачальником для спеціальних параметрів. Якщо використовується дане поле параметрів, це наголошується IP-адресою 99.130.83.99, яка показана в трасуванні Netmon як шістнадцяткова 63 82 53 63. Параметри можуть перелічувати ідентифікатор клієнта, запитану адресу, а також інші позиції. У нашому полі параметрів ідентифікатор клієнта рівний адресі MAC комп'ютера, що робить запит - в даному випадку KENNY. Також видно, що машина KENNY запрошує ту ж адресу, якою вона володіла раніше. Якщо ця адреса доступна, то її можна буде використовувати знову.

У трасуванні нижче запитана адреса недоступна, оскільки вона отримує NACK, що є негативним підтвердженням. Якщо розглянути частину IP в кадрі, то можна побачити машину, яка посилає цей NACK на робочу станцію. Це видно в тій частині пакету, що приходить з порту 67 (порту сервера ВООТР), в порт 68 (порт клієнта ВООТР). Коли робоча станція отримує NACK, вона не ініціалізує TСР/ІР, поки не отримає адресу. Якщо TСР/ІР є єдиним протоколом, машина не зможе спілкуватися в мережі, поки не буде виявлений сервер DHCP.

Оскільки клієнтська машина посилає запити DHCP і отримує NACK (відмову) з сервера DHCP, то можна сказати, що вони спілкуються. Факт, що машина посилає запити, є позитивним, оскільки вона робить все, що повинна робити клієнтська машина. Для перевірки можна використовувати команду ipconfig /renew з вікна CMD, що змусить клієнтську машину створити трафік DHCP. Це один із способів виконати передачу, не перезавантажуючи машину. У трасуванні Netmon повинні бути два кадри DHCP: запит DHCP і DHCP АСК (підтвердження).

У даному випадку трасуванням DHCP можна знайти тільки запити і один NACK і жодного іншого трафіку. Наступний крок полягає в переході до сервера і вивчення властивостей DHCP, де можна виявити, що сервер не має вільних адрес, або що область дії була деактивована. Це, дві найбільш поширені причини[2].

Визначення швидкодії мережі

Немає нічого незвичайного, коли користувачі скаржаться на те, що мережа працює поволі. Ці скарги мережеві адміністратори чують достатньо часто. Проте користувачі рідко висловлюють інші думки, крім загального спостереження, що мережа повільна. Раніше адміністратор приходив до користувача, спостерігав за його діями і погоджувався або не погоджувався з точністю спостережень. Це не кращий спосіб для нового тисячоліття. У нас є Netmon як засіб порятунку. Розглянемо приклад нижче, щоб зрозуміти, як Netmon працює в цій ситуації[1].