| Автоматизована настройка TCPIP BOOTP Динамічна налаштування DHCP[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.
скачати
|
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-адреса зв'язується з апаратним адресою мережевого інтерфейсу. Література G. Stump, R. Droms, Y. Gu, R., Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat. The User Class Option for DHCP, RFC-3004, November 2000. M. Patrick, DHCP Relay Agent Information Option. RFC-3046, January 2001. S. Alexander, DHCP Options and BOOTP Vendor Extensions, RFC-2132 T. Parker, TCP / IP для професіоналів, May 2000. © 2007 http://www.script-coding. info http://www.dhcp-handbook.com/dhcp_faq.html http://ru. wikipedia.org / wiki / DHCP http://kunegin. narod.ru / nata / tcpip_prof. pdf 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
|