Автоматизована настройка TCPIP BOOTP Динамічна налаштування DHCP

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

Міністерство освіти Російської Федерації Тольяттінській Державний Університет Кафедра "Інформатика та ОТ"

Індивідуальне домашнє завдання "Автоматизована налаштування TCP / IP. BOOTP. Динамічна настройка (DHCP)"

Виконала:

Перевірив:

р. о. Тольятті 2009

Зміст

1. Автоматизована налаштування TCP / IP

1.1 Динамічна настройка конфігурації з застосуванням BOOTP

1.2 IP-адреси запитів / відповідей ВООТР

1.3 Втрата повідомлень ВООТР

1.4 Формат повідомлення ВООТР

1.5 Фази ВООТР

1.6 Додаткові дані

2. Динамічна настройка (DHCP)

2.1 Розподіл IP-адрес в DHCP

2.2 Призначення IP-адрес в DHCP

2.3 Формат повідомлення DHCP

2.4 Трасування протоколу DHCP

Література

1. Автоматизована налаштування TCP / IP

Налаштування параметрів TCP / IP для кожної станції у великій мережі зазвичай пов'язана з важкою і довгою роботою, особливо коли виникає необхідність у зміні таких параметрів TCP / IP, як IP-адреси і маски підмереж. Зміни можуть бути обумовлені кардинальної реструктуризацією мережі або наявністю в ній численних мобільних користувачів з портативними комп'ютерами, які можуть підключатися до будь-якого сегменту мережі. Можливі як фізичні, так і бездротові підключення. Оскільки параметри конфігурації TCP / IP комп'ютера залежать від того, до якого сегменту він підключений, перехід комп'ютера в інший сегмент мережі повинен супроводжуватися відповідною зміною параметрів.

Тільки компетентний адміністратор добре розуміє всі наслідки, до яких призводить зміна параметрів TCP / IP. Група IETF розробила для об'єднаних мереж TCP / IP декілька протоколів автоматичної настройки, в тому числі ВООТР (Boot Protocol) і DHCP (Dynamic Host Configuration Protocol).

1.1 Динамічна настройка конфігурації з застосуванням BOOTP

Протокол ВООТР проектувався для того, щоб протоколи IP (Internet Protocol) і UDP (User Datagram Protocol) могли використовуватися для передачі інформації комп'ютерам, охочими налаштувати свою конфігурацію. Комп'ютер, згенерував запит, називається клієнтом ВООТР, а комп'ютер, який відповів на запит клієнта, називається сервером ВООТР (рис.1 "Клієнти і сервери ВООТР").

Метою клієнтського запиту ВООТР є отримання значень параметрів IP для комп'ютера, на якому працює клієнт ВООТР.

Протокол ВООТР описаний в RFC 951. Оновлена ​​інформація міститься в RFC 2132, RFC 1532, RFC 1542 та RFC 1395.

1.2 IP-адреси запитів / відповідей ВООТР

Повідомлення ВООТР інкапсулюються в заголовках UDP, що ідентифікують номер порту, використовуваного процесами ВООТР. Дейтаграмма UDP

инкапсулируется в заголовку IP. Але які адреси відправника і одержувача використовуються в заголовку IP? Цікаве питання, тому що при видачі запиту клієнт ВООТР повинен вказати ці адреси. Як правило, клієнт ВООТР не знає свого IP-адреси і вказує замість нього 0.0.0.0. Якщо ж адреса відома, він використовується в клієнтському запиті ВООТР.

Чи відомий IP-адресу сервера клієнту ВООТР? У загальному випадку невідомий.

Це особливо вірно по відношенню до ситуацій, коли клієнт ВООТР представляє собою бездискових робочих станціях і не має коштів для визначення адреси сервера. Втім, якщо адреса сервера ВООТР може налаштовуватися на рівні робочої станції, він використовується клієнтом ВООР. Якщо клієнт ВООТР не знає IP-адресу сервера ВООТР, він використовує обмежену розсилку IP. В якості адреси обмеженою розсилки використовується таке значення: 255.255.255.255

Пакети, відправлені за адресою обмеженою (локальної) розсилання, приймаються всіма IP-вузлами локального сегмента мережі, включаючи сервери ВООТР.

А якщо сервер ВООТР знаходиться в іншій підмережі IP, за граничним маршрутизатором? Як говорилося вище, обмежена розсилка за маршрутизатор не поширюється. Для таких випадків на маршрутизаторі працює агент-ретранслятор ВООТР (ВООТР relay agent), який перевіряє, чи використовується в дейтаграми обмеженою розсилки приймальний порт UDP з номером 67 (порт зарезервований для BOOTP / DHCP). Якщо умова виконується, обмежена розсилка перенаправляється в мережеві інтерфейси маршрутизатора (рис.2 "Пересилання повідомлень ВООТР через граничний маршрутизатор").

Сервер ВООТР, що знаходиться в локальній мережі, може відповісти на запит клієнта ВООТР. Чи буде в цьому повідомленні використовуватися IP-адресу клієнта?

Інакше кажучи, чи може сервер ВООТР послати спрямований відповідь? Все залежить від реалізації сервера ВООТР.

Сервер знає IP-адресу клієнта, що зберігається в базі даних конфігурації ВООТР. Чому ж він не може використовувати цю адресу для посилки спрямованого відповіді клієнту? Справа в тому, що в момент відправлення сервером запиту ARP на отримання апаратної адреси клієнта ВООТР клієнт відповісти не може. Чому? Тому що він ще не знає свого IP-адреси. Сервер ВООТР отримує апаратний адресу клієнта із заголовка канального рівня в повідомленні клієнта ВООТР. Реалізація сервера ВООТР може додати запис з інформацією про клієнта ВООТР в кеш ARP (рис.3 "Зміна кешу ARP сервером ВООТР"). При наявності такого запису сервер ВООТР може використовувати спрямований відповідь.

Модифікація кешу ARP використовується в реалізації ВООТР для BSD Unix.

Якщо сервер ВООТР не змінює вміст кешу ARP, відповідь розсилається в широкомовному режимі.

1.3 Втрата повідомлень ВООТР

У своїй роботі ВООТР використовує протоколи UDP і IP, не гарантують доставки повідомлень. У результаті можлива втрата, затримка, дублювання або порушення послідовності повідомлень ВООТР. Оскільки контрольна сума IP забезпечує перевірку цілісності тільки заголовка, але не поля даних, реалізація ВООТР може зажадати активізації контрольної суми UDP, що захищає від помилок у всьому повідомленні ВООТР.

При відправці запитів клієнт ВООТР встановлює прапор заборони фрагментації (DF), щоб спростити обробку відповідей ВООТР, а також на випадок нестачі пам'яті для збору фрагментованих дейтаграм.

Для боротьби з втратою повідомлень у ВООТР використовується механізм тайм-ауту з повторною передачею. Відправляючи запит, клієнт ВООТР запускає таймер.

Якщо відповідь ВООТР буде отримано до закінчення інтервалу тайм-ауту, відлік припиняється, в іншому випадку ВООТР передає запит заново.

Одночасний запуск декількох клієнтів ВООТР може призвести до переповнення мережі широкомовними запитами ВООТР. Щоб цього не відбулося, у специфікації ВООТР рекомендується використовувати випадкову затримку, початкова тривалість якої становить від нуля до чотирьох секунд. При кожній наступній повторної відправки інтервал подвоюється до тих пір, поки він не досягне досить великої величини (наприклад, 60 секунд). При досягненні верхньої межі тривалість інтервалу перестає подвоюватися, але випадкова затримка в підсумковому інтервалі продовжує застосовуватися. Внесення випадкової затримки допомагає запобігти одночасне надходження запитів з боку клієнтів ВООТР, підвищують навантаження на сервер і породжують конфлікти пакетів у Ethernet. Подвоєння тривалості випадкового інтервалу запобігає перевантаження мережі численними широкомовними запитами з боку багатьох клієнтів ВООТР.

1.4 Формат повідомлення ВООТР

На рис.4 "Формат повідомлення BOOT" зображена структура повідомлення ВООТР. Окремі поля повідомлення описані в табл.1 "Поля повідомлень ВООТР".

Поле

Довжина у октетах

Опис

ор

1

Тип повідомлення: 1 - запит (BOOTREQUEST), 2 - відповідь (BOOTREPLY)

htype

1

Тип апаратної адреси. Значення збігаються зі значеннями аналогічного поля в пакетах ARP. Наприклад, код 1 відповідає мережі Ethernet 10 Мбіт / с

hlen

1

Довжина адреси апаратури октетах. Апаратні адреси Ethernet і Token Ring мають довжину 6 байт

hops

1

Поле обнуляється клієнтом ВООТР. Може використовуватися агентом-ретранслятором, що працюють на маршрутизаторі, при пересиланні повідомлень ВООТР

xid

1

Код транзакції - випадкове число, що задається клієнтом ВООТР при побудові повідомлення. Сервер ВООТР використовує код транзакції у своїх відповідях клієнту. Наявність коду xid дозволяє клієнтам і серверів ВООТР пов'язати повідомлення ВООТР з відповіддю

se c s

1

Заповнюється клієнтом ВООТР. Містить кількість секунд, що пройшли з початку завантаження клієнта

-

2

Не використовується

ciaddr

4

IP-адреса клієнта ВООТР. Заповнюється клієнтом у повідомленні BOOTREQUEST, призначеному для перевірки використання раніше призначених параметрів конфігурації. Якщо клієнт не знає свій IP-адресу, полю присвоюється 0

yiaddr

4

IP-адреса клієнта ВООТР, що повертається сервером ВООТР

s i addr

4

IP-адресу сервера. Значення присвоюється клієнтом ВООТР, якщо клієнт хоче зв'язатися з конкретним сервером ВООТР. IP-адресу сервера ВООТР може зберігатися в конфігураційної базі даних TCP / IP на клієнті ВООТР. Сервер може повернути адреса наступного сервера, з яким слід зв'язатися в процесі завантаження, - наприклад, адресу сервера, на якому зберігається завантажувальний образ операційної системи

giaddr

4

IP-адреса маршрутизатора, на якому працює агент-ретранслятор ВООТР

chaddr

16

Апаратна адреса клієнта ВООТР.16 октетів зарезервовані для того, щоб дане поле дозволяло представляти різні типи апаратних адрес. У архітектурах Ethernet і Token Ring використовуються тільки 6 октетів

sname

64

Необов'язкове ім'я сервера (якщо воно відоме клієнту ВООТР). Зберігається в форматі рядки, завершеною нуль-символом

file

128

Ім'я завантажувального образу. Зберігається в форматі рядки, завершеною нуль-символом. Якщо клієнт ВООТР хоче завантажити образ операційної системи, прийнятий з мережевого пристрою, він може задати узагальнене ім'я - наприклад, "unix" для завантаження образу Unix

На сервері ВООТР може зберігатися додаткова інформація про конкретної операційної системи, необхідної для цієї робочої станції. Відповідь, отримана від сервера ВООТР, містить повністю певне ім'я файлу

vendor

64

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

1.5 Фази ВООТР

Незважаючи на свою назву, протокол ВООТР не використовується для фактичної пересилання образу операційної системи клієнту ВООТР. Пересилання образу здійснюється окремим протоколом TFTP (Trivial File Transfer Protocol), який використовує в якості транспорту протокол UDP. Бездискові робочі станції завантажують образ операційної системи із сервера; інші станції просто використовують ВООТР для централізованого призначення IP-адрес, без завантаження системи.

На рис.5 "Приклад роботи bootstrap" зображені фази, з яких складається процес завантаження образу операційної системи. На кроці 1 клієнт ВООТР видає запит на отримання даних конфігурації IP. На кроці 2 сервер ВООТР повертає дані конфігурації IP і ім'я файлу, що завантажується з образом операційної системи. На кроці 3 клієнт ВООТР надсилає запит на завантаження образу операційної системи клієнту TFTP. На кроці 4 клієнт TFTP посилає серверу TFTP запит на завантаження образу операційної системи. На кроці 5 сервер TFTP повертає серію пакетів даних, що містять образ операційної системи. Після прийняття образу ВООТР завантажує його в пам'ять і ініціалізується.

Відділення ВООТР від механізму пересилання образу операційної системи володіє тим перевагою, що сервер ВООТР не зобов'язаний працювати на тому комп'ютері, на якому зберігаються образи операційних систем (тобто сервері TFTP). Крім того, це дозволяє використовувати ВООТР в ситуаціях, коли з сервера приймаються тільки дані конфігурації, без пересилання образу операційної системи.

Можлива ситуація, в якій адміністратор налаштовує робочу станцію на завантаження різних операційних систем в залежності від користувача. У цьому випадку запит ВООТР може містити в полі імені файлу узагальнене позначення - наприклад, "unix" для прийняття образу операційної системи Unix, або "default" для завантаження образу операційної системи за замовчуванням.

Зіткнувшись з таким узагальненим запитом, сервер ВООТР звертається до конфігураційної базі даних, знаходить повністю певне ім'я файлу і повертає його у відповіді ВООТР. Клієнт ВООТР може передати повністю певне ім'я локального клієнта TFTP для прийняття образу операційної системи.

1.6 Додаткові дані

У форматі повідомлення ВООТР явно задані стандартні параметри IP. Багато постачальники обладнання передають своїм пристроям додаткові параметри. Для таких випадків у повідомлення ВООТР було включено полі додаткових даних.

У полі vendor повідомлення ВООТР клієнту передаються дані, інтерпретація яких визначається постачальником обладнання. Поле не є обов'язковим, а його застосування залежить від того, яка додаткова інформація потрібна клієнтові ВООТР. Перші чотири октету містять "чарівне число" - ознака формату решти полів. Ці чотири октету задаються в десятковому записі з точковим поділом (не плутайте їх з IP-адресами!). Скажімо, довільно обрана послідовність 99.130.83.99 (у шістнадцятковій запису - 63.82.53.63) є узвичаєним позначенням стандартного формату області додаткових даних. За ознакою формату перераховуються елементи, кожен з яких характеризується наступними атрибутами:

мітка (1 октет)

довжина наступного поля даних (1 октет)

дані (змінна довжина)

Мітки елементів ВООТР описані в RFC 1497, "ВООТР Vendor Information

Extensions ". З появою протоколу DHCP додаткові дані ВООТР і поле параметрів DHCP були приведені до загального формату, описаного в RFC 2132," DHCP Options and BOOTP Vendor Extensions ". Деякі часто використовується значення міток наведені в табл.2" Стандартні мітки додаткових даних ВООТР ".

Мітка

Довжина даних

Інтерпретація

0

-

Використовується тільки з метою вирівнювання, щоб наступні поля починалися з кордону слова

1

4

Маска підмережі

2

4

Зсув географічної зони, в якій знаходиться підмережа клієнта, від стандартного часу UTC (Coordinated Universal Time). Зсув виражається 32-розрядним цілим числом зі знаком

3

N

Список IP-адрес маршрутизаторів в підмережі клієнта.

Маршрутизатори перераховуються в порядку переваги. Мінімальна довжина списку дорівнює 4 октетам, а загальна довжина повинна бути кратна 4

4

N

Маска підмережі

5

N

Список серверів імен (IEN 116), доступних для клієнта. Сервери перераховуються в порядку переваги. Мінімальна довжина списку дорівнює 4 октетам, а загальна довжина повинна бути кратна 4

6

N

Список серверів DNS (STD 13, EFC 1035), доступних для клієнта. Сервери перераховуються в порядку переваги. Мінімальна довжина списку дорівнює 4 октетам, а загальна довжина повинна бути кратна 4

7

N

Список журнальних серверів (MIT-LCS UDP), доступних для клієнта. Сервери перераховуються в порядку переваги. Мінімальна довжина списку дорівнює 4 октетам, а загальна довжина повинна бути кратна 4

8

N

Список серверів cookie (RFC 865), доступних для клієнта.

Сервери перераховуються в порядку переваги.

Мінімальна довжина списку дорівнює 4 октетам, а загальна довжина повинна бути кратна 4

9

N

Список серверів порядкової друку LPR (RFC 1179), доступних для клієнта. Сервери перераховуються в порядку переваги. Мінімальна довжина списку дорівнює 4 октетам, а загальна довжина повинна бути кратна 4

10

N

Список серверів Imagen Impress, доступних для клієнта.

Сервери перераховуються в порядку переваги.

Мінімальна довжина списку дорівнює 4 октетам, а загальна довжина повинна бути кратна 4

11

N

Список серверів місцезнаходження ресурсів (RFC 887), доступних для клієнта. Сервери перераховуються в порядку переваги. Мінімальна довжина списку дорівнює 4 октетам, а загальна довжина повинна бути кратна 4

12

N

Ім'я хоста, відповідне даному клієнту, з можливим уточненням імені локального домену. Допустимі символи описані в RFC 1035. Мінімальна довжина поля даних дорівнює 1 октету

13

N

Розмір завантажувального файлу. Визначає довжину завантажувального образу, використовуваного клієнтом за умовчанням, в 512-кілобайтні блоках. Довжина файлу задається 16-розрядним цілим числом без знака

128-254

Не визначена

Інтерпретація залежить від реалізації

255

-

Ознака кінця інформації в полі додаткових параметрів. Подальші октети повинні бути заповнені нулями

2. Динамічна настройка (DHCP)

Протокол DHCP (Dynamic Host Configuration Protocol) є розширенням протоколу ВООТР і володіє більш гнучкі можливості управління IP-адресами. DHCP може використовуватися для динамічного настроювання основних параметрів TCP / IP хостів (робочих станцій і серверів), що працюють в мережі.

Протокол DHCP складається з двох компонентів:

механізм призначення IP-адрес та інших параметрів TCP / IP

протокол погодження та передачі інформації про хостах Хост, запитувач дані про конфігурацію TCP / IP, називається клієнтом DHCP, а хост TCP / IP, який надає цю інформацію, називається сервером DHCP. Протокол DHCP описаний в RFC 2131, "Dynamic Host Configuration Protocol".

2.1 Розподіл IP-адрес в DHCP

У DHCP використовуються три способи призначення IP-адрес:

ручне призначення автоматичне призначення динамічне призначення При ручному призначення IP-адреса клієнта DHCP вводиться вручну мережевим адміністратором на сервері DHCP, після чого передається клієнту через протокол DHCP.

При автоматичному призначення ручна настроювання адрес не потрібна. Клієнт DHCP одержує IP-адреса при першому зверненні до сервера DHCP. IP-адреси, призначені цим способом, закріплюються за клієнтом DHCP і не використовуються іншими клієнтами DHCP.

При динамічному призначення клієнт одержує IP-адресу на тимчасовій основі або "орендує" його на певний термін. Після закінчення цього терміну IP-адреса відгукується, і клієнт DHCP повинен перестати його використовувати. Якщо клієнт DHCP і раніше, потребує в IP-адресу для виконання своїх функцій, він повинен запросити іншу адресу.

З трьох описаних методів тільки динамічне призначення дозволяє організувати автоматичне повторне використання IP-адрес. Якщо клієнт DHCP перестає використовувати IP-адресу (наприклад, при коректному відключенні комп'ютера), він повертає його серверу DHCP. Після цього сервер DHCP може призначити той же IP-адресу іншому клієнту DHCP, яка звернулася із запитом на отримання адреси.

Метод динамічного призначення адрес особливо зручний для клієнтів DHCP, які потребують IP-адресу для тимчасового підключення до мережі. Для прикладу розглянемо мережа класу С, до якої можуть підключатися до 300 мобільних користувачів з портативними комп'ютерами. Мережа класу С може містити до 253 вузлів B55 - 2 спеціальних адреси = 253). Оскільки комп'ютери, що підключаються до мережі через TCP / IP, повинні володіти унікальними IP-адресами, всі 300 комп'ютерів не можуть підключитися до мережі одночасно. Тим не менш, якщо у будь-який момент часу в мережі можливе не більше 200 фізичних підключень, з'являється можливість перепризначення невикористовуваних адрес класу С за рахунок застосування механізму динамічного призначення адрес DHCP.

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

Який би з трьох способів призначення IP-адрес не був обраний, ви все одно зможете один раз налаштувати параметри IP на центральному сервері DHCP замість того, щоб повторювати настроювання конфігурації TCP / IP для кожного комп'ютера окремо.

2.2 Призначення IP-адрес в DHCP

Звернувшись із запитом до сервера DHCP, клієнт DHCP проходить ряд внутрішніх стадій, під час яких він узгоджує з сервером термін і область використання IP-адреси. Процес отримання IP-адреси клієнтом DHCP найкраще пояснити на діаграмі переходів (тобто кінцевого автомата). На Рис.6 "Діаграма переходів для протоколу DHCP, що пояснює процес взаємодії між клієнтом і сервером" зображена діаграма, яка пояснює процес взаємодії між клієнтом і сервером DHCP.

При першому запуску клієнт DHCP знаходиться в стані ініціалізації. На цій стадії клієнт DHCP ще не знає своїх параметрів IP, тому він розсилає запит DHCPDISCOVER, інкапсульований в пакеті UDP / IP. У пакеті вказаний приймальний порт UDP 67 (десят) - такий же, як у сервера ВООТР, тому що протокол DHCP є розширенням ВООТР. У пакеті DHCPDISCOVER використовується адресу локальної розсилки 255.255.255.255. Якщо сервери DHCP знаходяться за межами локального сегменту, на маршрутизаторі IP повинен працювати агент-ретранслятор, який перешле запит DHCPDISCOVER в інші підмережі. Підтримка агентів-ретрансляторів DHCP розглядається в RFC 1542.

Перш ніж розсилати запит DHCPDISCOVER, клієнт DHCP витримує паузу випадкової тривалості від 1 до 10 секунд. Це робиться для того, щоб запобігти одночасний початок роботи клієнтів DHCP при їх одночасному включенні (як іноді відбувається після збою живлення).

Після розсилки запиту DHCPDISCOVER клієнт DHCP входить в стан ВИБІР. У цьому стані клієнт DHCP отримує повідомлення DHCPOFFER від серверів DHCP, налаштованих для відповіді цьому клієнтові. Період часу, протягом якого клієнт DHCP очікує повідомлення DHCPOFFER, залежить від реалізації. Якщо клієнт отримує відразу кілька відповідей DHCPOFFER, він повинен вибрати один з них. Вибравши повідомлення DHCPOFFER від одного з серверів, клієнт DHCP посилає цього сервера повідомлення DHCPREQUEST. Сервер DHCP відповідає повідомленням DHCPACK.

Додатково клієнт DHCP може перевірити IP-адресу, переданий в повідомленні DHCPACK, і переконатися в тому, що ця адреса не використовується. У мережах з широкомовної розсилкою клієнт DHCP може відправити за вказаною адресою запит ARP і перевірити наявність відповіді ARP. Отримання відповіді ARP означає, що запропонований IP-адреса вже використовується; в цьому випадку відповідь DHCPACK від сервера ігнорується, відправляється відповідь DHCPDECLINE, а клієнт DHCP переходить в початковий стан Ініціалізація і намагається отримати вільний IP-адресу. При розсилці запиту ARP в локальній мережі клієнт вказує в пакеті ARP власний апаратний адресу в полі адреси апаратури відправника, але в полі IP-адреси відправника заноситься нульове значення. Нульовий IP-адреса використовується замість запропонованого IP-адреси, щоб уникнути можливої ​​плутанини з кешами ARP інших хостів TCP / IP (у тому випадку, якщо запропонований IP-адреса вже використовується).

Коли клієнт отримує від сервера DHCP повідомлення DHCPACK, він визначає три тимчасові інтервали і переходить в стан прив'язки. Перший інтервал Т1 визначає термін відновлення оренди, другий інтервал Т2 визначає термін повторної прив'язки; третій інтервал ТЗ визначає тривалість оренди.

З повідомленням DHCPACK завжди повертається значення ТЗ, тобто тривалість оренди. Значення Т1 і Т2 налаштовуються на сервері DHCP, а якщо вони не були задані, використовуються значення за замовчуванням, засновані на тривалості терміну оренди, розраховані за наступними формулами:

Т1 = інтервал відновлення Т2 = інтервал повторної прив'язки ТЗ = тривалість оренди Т1 = 0,5 х ТЗ

Т2 = 0,875 х ТЗ

Моменти часу, в які відбувається тайм-аут, обчислюються додатком інтервалу до часу відправлення повідомлення DHCPREQUEST, за яким було створене підтвердження DHCPACK.

Якщо запит DHCP був відправлений у момент ТО, то моменти тайм-ауту по всіх трьох інтервалах обчислюються за такими формулами:

тайм-аут з Т1 = ТО + Т1

тайм-аут з Т2 - ТО + Т2

тайм-аут по ТЗ в ТЕ + ТЗ

У RFC 2131 рекомендується збільшувати Т1 і Т2 на величину випадкової затримки, щоб запобігти одночасний наступ тайм-ауту на декількох клієнтів DHCP.

У разі закінчення інтервалу Т1 клієнт DHCP переходить зі стану Прив'язка в стан ВІДНОВЛЕННЯ. У цьому стані клієнт DHCP повинен узгодити з сервером DHCP, що видав вихідний IP-адреса, новий термін оренди для призначеного IP-адреси. Якщо вихідний сервер DHCP відмовляється відновити оренду, він посилає повідомлення DHCPNAK; клієнт повертається в стан Ініціалізація і намагається отримати новий IP-адресу. Якщо вихідний сервер DHCP відправляє повідомлення DHCPACK, в цьому повідомленні вказується нова тривалість оренди. Клієнт DHCP знову встановлює інтервали Tl, T2 і ТЗ і переходить в стан прив'язки.

Якщо інтервал Т2 закінчується в той момент, коли клієнт DHCP в стані ВІДНОВЛЕННЯ очікує повідомлення DHCPACK або DHCPNAK від вихідного сервера DHCP, клієнт переходить зі стану ВІДНОВЛЕННЯ в стан повторному скріпленні. Вихідний сервер DHCP може не відповісти через те, що він тимчасово недоступний або через збій в мережевому каналі. З наведених вище формул видно, що Т2> Т1, тому клієнт DHCP додатково чекає відновлення оренди протягом часу Т2-Т1.

У разі закінчення інтервалу Т2 в мережі розсилається широкомовний запит DHCPREQUEST для всіх серверів DHCP, здатних відновити оренду; клієнт DHCP знаходиться в стан повторному скріпленні. Розсилка запиту пояснюється тим, що після очікування Т2-Т1 секунд у стані ВІДНОВЛЕННЯ клієнт DHCP приходить до виходу, що вихідний сервер DHCP недоступний, і намагається зв'язатися з будь-яким сервером DHCP, здатним йому відповісти. Якщо сервер DHCP відповідає повідомленням DHCPACK, клієнт DHCP відновлює оренду (ТЗ), задає інтервали Т1 і Т2 і переходить в стан прив'язки. Якщо жоден сервер DHCP не зможе відновити оренду до закінчення інтервалу ТЗ, оренда стає недійсною і клієнт DHCP переходить в стан ініціалізації. Зверніть увагу: до цього моменту клієнт DHCP вже двічі намагався відновити оренду - спочатку з вихідного сервера DHCP, а потім з будь-якого сервера DHCP в мережі.

У разі закінчення терміну оренди (ТЗ) клієнт DHCP повинен припинити використання IP-адреси і всі мережеві операції з цією IP-адресою.

Щоб припинити використання IP-адреси, клієнт DHCP не зобов'язаний чекати закінчення терміну оренди (ТЗ). Він може навмисно відмовитися від використання IP-адреси, скасувавши оренду. Припустимо, користувач з портативним комп'ютером підключився до мережі для виконання деякої операції. Сервер DHCP в мережі надав йому IP-адреса строком на одну годину. Користувач закінчив свою роботу за 30 хвилин і тепер хоче відключитися від мережі. У процесі коректного відключення комп'ютера клієнт DHCP посилає серверу повідомлення DHCPRELEASE, щоб сервер скасував оренду достроково. Повернений IP-адреса в подальшому може використовуватися іншим клієнтом.

Якщо клієнт DHCP працює на комп'ютері, оснащеному жорстким диском, то IP-адреса може зберігатися на цьому диску і при запуску комп'ютера клієнт може запитати використовувався раніше адресу. На ріс.8.6 цієї ситуації відповідає стан "ПЕРЕЗАВАНТАЖЕННЯ з відомим IP-адресою".

2.3 Формат повідомлення DHCP

Структура повідомлення DHCP зображена на рис.7 "Формат пакету DHCP". У повідомленнях DHCP всі поля мають фіксований формат, крім поля додаткових даних, мінімальний розмір якої дорівнює 312 октетам. Видно, що повідомлення DHCP і ВООТР мають майже однаковий формат, не рахуючи полів прапорів і додаткових параметрів. Більш того, сервер DHCP може бути налаштований на обробку запитів ВООТР (процедура налаштування залежить від операційної системи).

Окремі поля повідомлень протоколу DHCP описані в табл.3 "Поля повідомлень DHCP". У поле прапорів використовується тільки крайній лівий біт (рис.8 "Формат пакету DHCP"), інші біти повинні бути рівні нулю.

Поле

Довжина у октетах

Опис

ор

1

Тип повідомлення: 1 - запит (BOOTREQUEST), 2 - відповідь (BOOTREPLY)

htype

1

Тип апаратної адреси. Значення збігаються зі значеннями аналогічного поля в пакетах ARP. Наприклад, код 1 відповідає мережі Ethernet 10 Мбіт / с

hlen

1

Довжина адреси апаратури октетах. Апаратні адреси Ethernet і Token Ring мають довжину 6 байт

hops

1

Поле обнуляється клієнтом DHCP. Може використовуватися агентом-ретранслятором, що працюють на маршрутизаторі, при пересиланні повідомлень DHCP

xid

1

Код транзакції - випадкове число, що задається клієнтом DHCP при побудові повідомлення. Сервер DHCP використовує код транзакції у своїх відповідях клієнту. Наявність коду xid дозволяє клієнтам і серверів DHCP пов'язати повідомлення DHCP з відповіддю

seсs

1

Заповнюється клієнтом DHCP. Містить кількість секунд, що пройшли з початку завантаження клієнта

flags

2

Якщо крайній лівий біт дорівнює 1, повідомлення є широкомовною. Всі інші біти повинні бути рівні 0

ciaddr

4

IP-адреса клієнта DHCP. Заповнюється клієнтом у повідомленні DHCPREQUEST, призначеному для перевірки використання раніше призначених параметрів конфігурації. Якщо клієнт не знає свій IP-адресу, полю присвоюється 0

yiaddr

4

IP-адреса клієнта DHCP, що повертається сервером DHCP

siaddr

4

IP-адресу сервера. Значення присвоюється клієнтом DHCP, якщо клієнт хоче зв'язатися з конкретним сервером DHCP. IP-адресу сервера DHCP може бути отриманий за допомогою повідомлень DHCPOFER і DHCPACK, раніше повернених сервером. Сервер може повернути адреса наступного сервера, з яким слід зв'язатися в процесі завантаження, - наприклад, адресу сервера, на якому зберігається завантажувальний образ операційної системи

giaddr

4

IP-адреса маршрутизатора, на якому працює агент-рретранслятор DHCP

chaddr

16

Апаратна адреса клієнта DHCP.16 октетів зарезервовані для того, щоб дане поле дозволяло представляти різні типи апаратних адрес. У архітектурах Ethernet і Token Ring використовуються тільки 6 октетів

sname

64

Необов'язкове ім'я сервера (якщо воно відоме клієнту DHCP).

Зберігається в форматі рядки, завершеною нуль-символом

file

128

Ім'я завантажувального образу. Зберігається в форматі рядки, завершеною нуль-символом. Якщо клієнт DHCP хоче завантажити образ операційної системи, прийнятий з мережевого пристрою, він може задати в DHCPDISCOVER узагальнене ім'я - наприклад, "unix" для завантаження образу Unix. На сервері DHCP може зберігатися додаткова інформація про конкретної операційної системи, необхідної для цієї робочої станції. Відповідь сервера DHCP може повертатися у вигляді повного імені файлу в повідомленні DHCPOFFER

options

312

Додаткові параметри

Більшість повідомлень DHCP, переданих сервером DHCP клієнта, є спрямованими (тобто надсилаються на один конкретний IP-адресу). Це пояснюється тим, що сервер DHCP дізнається адресу клієнта DHCP з повідомлень, що відправляються клієнтом серверу. Клієнт DHCP може зажадати, щоб сервер відповідав за адресою широкомовлення, для чого крайній лівий біт поля options встановлюється в 1. Клієнт DHCP надходить подібним чином, якщо він ще не знає свого IP-адреси. Модуль IP на клієнті DHCP відкидає отриману дейтаграму, якщо IP-адресу одержувача, вказану в дейтаграми, не збігається з IP-адресою мережевого інтерфейсу клієнта DHCP. Якщо IP-адресу мережного інтерфейсу невідомий, дейтаграма також відкидається. З іншого боку, модуль IP приймає будь-які дейтаграми DHCP. Отже, щоб модуль IP свідомо брав відповідь сервера DHCP, коли IP-адресу ще не налаштований, клієнт DHCP повинен вимагати, щоб сервер надсилав широкомовні повідомлення замість направлених.

Поле options має змінну довжину. Його мінімальний розмір збільшений до 312 октетів, щоб загальний мінімальний розмір повідомлення DHCP становив 576 октетів - мінімальний розмір дейтаграми IP, прийнятої хостом. Якщо клієнт DHCP повинен використовувати повідомлення більшого розміру, він погоджує максимальний розмір за допомогою спеціального параметра. Оскільки поля sname і file досить великі, але використовуються не завжди, область параметрів можна розширити в ці поля за допомогою параметра Option Overload. Якщо цей параметр присутній, звичайний сенс полів sname і field ігнорується і в цих полях шукаються параметри у форматі TLV (Type, Length, Value).

З рис.9 "Формат параметра в повідомленнях DHCP" видно, що в DHCP параметр представляється полем типу A октет), за яким слідує поле довжини A октет). Значення поля довжини визначає розмір поля значення. Різні повідомлення DHCP представляються спеціальним кодом типу 53. Значення параметрів, що визначають повідомлення DHCP, наведені на рис.10 "Значення параметрів в повідомленнях DHCP".

2.4 Трасування протоколу DHCP

У цьому розділі описано формат повідомлень DHCP для пакетів, які у реально існуючої мережі. Крім зазначених у таблиці 3, вам можуть зустрінуться позначення:

Destination IP Address - IP-адресу одержувача Source IP Address - IP-адреса відправника Ethernet Header - заголовок Ethernet

UDP Header - заголовок UDP

UDP Source Port - UDP-порт відправника UDP Destination Port - UDP-порт одержувача Ethernet type - тип Ethernet

Рис.10 "Значення параметрів в повідомленнях DHCP"

Протокол DHCP і формат його пакетів є розширеннями ВООТР. Клієнти і сервери DHCP використовують ті ж номери портів, що і клієнти і сервери ВООТР, тобто клієнти DHCP використовує порт UDP з номером 68, а сервери DHCP - порт UDP з номером 67. Більшість аналізаторів протоколів розшифровує повідомлення DHCP і BOOT в одному форматі.

Висновок Протоколи ВООТР і DHCP вирішують важливу проблему автоматичної настройки параметрів IP (зокрема, IP-адрес і масок підмережі) для окремих мережних пристроїв. Обидва протоколу засновані на архітектурі "клієнт-сервер" і використовують однакові номери портів UDP. Протокол DHCP проектувався як заміна старого протоколу ВООТР, а його повідомлення представляють собою розширення формату повідомлень ВООТР.

Головна перевага DHCP полягає в тому, що цей протокол дозволяє орендувати IP-адреси на тимчасовій основі. Тим самим забезпечується більш гнучке управління IP-адресами в ситуаціях, коли IP-адреси не зобов'язані жорстко асоціюватися з конкретним комп'ютером по апаратному адресою. Механізм призначення IP-адрес в ВООТР менш гнучким, оскільки IP-адреса зв'язується з апаратним адресою мережевого інтерфейсу.

Література

  1. G. Stump, R. Droms, Y. Gu, R., Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat. The User Class Option for DHCP, RFC-3004, November 2000.

  2. M. Patrick, DHCP Relay Agent Information Option. RFC-3046, January 2001.

  3. S. Alexander, DHCP Options and BOOTP Vendor Extensions, RFC-2132

  4. T. Parker, TCP / IP для професіоналів, May 2000. © 2007 http://www.script-coding. info

  5. http://www.dhcp-handbook.com/dhcp_faq.html

  6. http://ru. wikipedia.org / wiki / DHCP

  7. http://kunegin. narod.ru / nata / tcpip_prof. pdf

  8. http://www.bog. pp.ru / work / bootp.html

Посилання (links):
  • http://www.dhcp-handbook.com/dhcp_faq.html
  • http://kunegin.narod.ru/nata/tcpip_prof.pdf
    Додати в блог або на сайт

    Цей текст може містити помилки.

    Програмування, комп'ютери, інформатика і кібернетика | Контрольна робота
    89.1кб. | скачати


    Схожі роботи:
    Настройка рахунків субконто та інших параметрів в 1С Бухгалтерії
    Динамічна психологія й психосинтез
    Топографічна і динамічна моделі психіки З Фрейда
    TCPIP
    Протоколи TCPIP
    Стек протоколів TCPIP
    Безпека мереж на базі TCPIP
    Розвиток стека TCPIP протокол IPv6
    Протоколи обміну маршрутною інформацією стека TCPIP
  • © Усі права захищені
    написати до нас