І знову всім привіт! Сьогодні йтиметься про протоколи верхнього рівня. Розберемо, як вони працюють, з чого складаються і де застосовуються теоретично і на практиці.
Зміст
1) Основні мережеві терміни, мережева модель OSI і стек протоколів TCP/IP.
2) Протоколи верхнього рівня.
3) Протоколи нижніх рівнів (транспортного, мережевого та канального).
4) Мережеві пристрої та види застосовуваних кабелів.
5) Поняття IP адресації, масок підмереж та їх розрахунок.
6) Поняття VLAN, Trunk і протоколи VTP і DTP.
7) Протокол зв'язуючого дерева: STP.
8) Протокол агрегування каналів: Etherchannel.
9) Маршрутизація: статична і динамічна на прикладі RIP, OSPF і EIGRP.
P.S. Можливо, з часом список доповниться.
Як ви пам'ятаєте з минулої статті (якщо не читали, то в змісті є посилання на неї), модель OSI в нинішній час служить тільки в якості навчання ролям кожного рівня. Працюють мережі по стеку протоколів TCP/IP. Хоч TCP/IP складається з 4 рівнів, він цілком реалізує всі функціональні можливості, що реалізуються в моделі OSI. Нижче на картинці наведено порівняння рівнів та їх ролей.
Починаємо розмову про протоколи верхнього рівня. Я не просто так назвав тему «Протоколи верхнього рівня», а не «Протоколи верхніх рівнів». Оскільки ми розбираємо цей рівень по стеку TCP/IP, то у нас він «один за трьох».
Взагалі з точки зору мережевика, нам все одно, що відбувається всередині прикладного рівня. Цим, як правило, займаються програмісти. Але важливо знати, як формуються дані та інкапсулюються в нижчі рівні.
У нас на роботі, наприклад, є правило: ми забезпечуємо запуск програми і його безпомилкову передачу по мережі. Якщо проблема полягає у внутрішніх програмних збоях, то ми перемикаємо на розробників, і це стає їх турботою. Але бувають і проблеми, які йдуть по тонкій межі між нами, і ми вирішуємо їх разом.
Отже, протоколи прикладного рівня забезпечують взаємодію між людиною і мережею. Цих протоколів величезна кількість, і виконують вони абсолютно різні ролі. Я наведу приклади часто використовуваних протоколів у мережі і покажу, як вони працюють на практиці: HTTP, DNS, DHCP, SMTP и POP3, Telnet, SSH, FTP, TFTP.
I) Протокол HTTP (англ. hyperText Transport Protocol). Протокол передачі даних, який зазвичай використовується для отримання інформації з веб-сайтів. З кожним роком цей протокол стає все популярнішим, і можливостей для його застосування стає все більше. Використовує він «клієнт-серверну» модель. Тобто існують клієнти, які формують і відправляють запит. І сервери, які слухають запити і, відповідно, на них відповідають.
В якості клієнтів виступають відомі багатьом веб-браузери: Internet Explorer, Mozilla Firefox, Google Chrome и т.д. А в якості серверного ПЗ використовують:Apache, IIS, nginx тощо.
Для того, щоб розібратися глибше в протоколі HTTP, подивимося на HTTP запит від клієнта до сервера.
Нас цікавлять тільки найбільший і найнижчий рядки.
У першому рядку використовується таке поняття, як GET. Це, по суті, ключ запиту. Оскільки після GET стоїть символ «»/«», то це означає, що запитується головна або коренева сторінка за URL (англ. uniform Resource Locator) шляху.
URL - це якийсь ідентифікатор якогось ресурсу в мережі.
Так само в цій сходинці присутній такий запис, як HTTP/1.1. Це версія протоколу. Досить популярна версія. Випустили її в 1999 році, і досі вона служить вірою і правдою. Хоч недавно був анонс версії 2.0, версія 1.1 займає поки лідируюче положення.
Тепер про нижню сходинку. Тут вказується адреса сервера або назва, на якій розташовується потрібний ресурс. Давайте подивимося, як це працює на практиці. Я буду використовувати свою улюблену програму Cisco Packet Tracer 6.2 (надалі CPT). Вона проста в освоєнні і для демонстрації описаного ідеально підходить. Можу сказати з упевненістю, що для підготовки до CCNA R&S, її вистачає цілком. Але тільки для неї.
Відкриваємо програму і додамо туди комп'ютер з сервером (знаходяться вони на вкладці «End Devices»), як на картинці нижче
З'єднуємо комп'ютер з сервером перехресним кабелем (англ. crossover cable). У CPT він знаходиться на вкладці «Connections», позначається пунктиром і називається «Copper Cross-Over».
Тепер займемося налаштуванням комп'ютера і веб-сервера.
1) Відриваємо вкладки «Desktop» на робочому комп'ютері та сервері, далі переходимо у вікно «IP Configuration». Відкриються вікна, як на зображенні вище. Це вікна налаштування вузлів у мережі.
2) Вкажемо IP-адреси у рядки, зазначені цифрою 2. Як пам'ятаємо з попередньої статті, IP-адреси потрібні для ідентифікації вузлів у мережі. Детальніше ми розберемо цю тему пізніше. Зараз головне розуміти, для чого потрібна IP-адреса. Я спеціально вибрав мережу, що починається з «192.168», оскільки вона зустрічається найчастіше в домашніх мережах.
3) У поля, зазначені цифрою 3, вводиться маска підмережі. Вона потрібна для того, щоб вузлу було зрозуміло, в одній підмережі він знаходиться з іншим вузлом чи ні. Але про це пізніше.
Решту значень залишимо порожніми.
Тепер потрібно включити сервіс HTTP на сервері.
1) Переходимо на вкладку «Services».
2) Вибираємо ліворуч HTTP.
3) Відкривається вікно налаштування сервісу і файловий менеджер. Якщо у кого є навички по роботі c HTML, то можете тут створити сторінку. Але у нас вже є готовий шаблон, і ми ним скористаємося. Не забуваємо включити службу HTTP і HTTPS.
Раз вже зайшла мова про HTTPS (HyperText Transfer Protocol Secure), то скажу про нього пару слів. Це, по суті, розширення протоколу HTTP, яке підтримує криптографічні протоколи і передає інформацію не у відкритому вигляді, а в зашифрованому. У CPT дуже поверхово показана його робота, але для розуміння цілком достатньо. Згадуємо і запам'ятовуємо: HTTP використовує 80 порт, а HTTPS 443 порт. Взагалі номерів портів дуже багато, і все запам'ятати важко, але часто зустрічаються краще запам'ятати.
Тепер найцікавіше. Нам треба перевести CPT з режиму «Realtime» в режим «Simulation». Відмінність їх у тому, що в режимі «Realtime» мережа поводиться так, як вона повела б себе в реальному житті і в реальному часі. Режим «Simulation» дозволяє нам спостерігати за поведінкою мережі в різні часові інтервали, а також простежити за кожним пакетом, розкрити його і подивитися, що він в собі несе. Перемикаємо середовище, як показано на малюнку нижче.
Тут відкривається «Simulation Panel», в якій кілька опцій. Є фільтр, в якому можна вказати протоколи, які ви хочете відстежувати, швидкість переміщення пакета і навігаційна панель, де можна спостерігати за мережею вручну, натисканням «Capture/Forward» або автоматично, за допомогою кнопки «Auto Capture/Play».
Залишаємо все, як є, і відкриваємо комп'ютер.
Переходимо на вкладку «Desktop» і відкриваємо «WEB Browser». Перед нами відкривається вікно веб-браузера. У рядку URL пишемо адресу нашого веб-сервера, натискаємо кнопку «Go» і спостерігаємо наступну картину.
З'явилися перші дані на схемі і у вікні «Simulation Panel». Це сегменти TCP, які створять сесію між комп'ютером і сервером. Зараз нам це не цікаво, і ми поговоримо про це в наступній статті. Тому я пропущу їх до часу, коли буде створено HTTP. Робити я це буду за допомогою кнопки «Capture/Forward».
Після встановлення з'єднання комп'ютер формує перші дані HTTP. Надалі я буду називати їх PDU, щоб ви звикали до даних термінів.
1) Дивимося на схему і бачимо, що з'явилося 2 конверти. Це і є наші дані. Нас цікавить фіолетовий конверт. Це і є створений PDU.
2) Тепер дивимося на «Simulation Panel» і бачимо, що в таблиці з'явився запис з типом HTTP. Ці дані нас цікавлять. Також біля запису показано колір, яким пофарбовано ці дані на схемі.
3) Клікаємо за HTTP (фіолетовий конверт), і перед нами відкривається вікно даних. Тут коротко показано всі потрібні відомості по кожному рівню моделі OSI. Можна клікнути за будь-яким рівнем і отримати інформацію про те, що відбувається на ньому.
Якщо вам цікаво повністю розкрити дані і розглянути детально, з яких полів вони полягають і що в них відбувається, є вкладка «Outbound PDU Details». Давайте перейдемо на неї і подивимося, як виглядають HTTP дані.
На цій вкладці буде показано дані на всіх рівнях. Нам поки треба подивитися на HTTP. Вони знаходяться в самому низу, тому тягнемо бігунок вниз. Виглядають вони так само, як я і описував їх раніше.
Тепер нам цікавий етап, коли веб-сервер отримає запит і почне робити якісь дії. Давайте натиснемо на «Capture/Forward» і подивимося, чим веб-сервер відповість. І ось, на малюнку нижче бачимо, що він відправив комп'ютеру якісь дані. Давайте подивимося, як вони виглядають.
1) Я випадково пережив кнопку і він вже почав формувати TCP на закриття сесії. Нічого страшного. Знаходимо PDU, адресовані від веб-сервера до клієнта. Як бачимо, він відразу показує нам на схемі момент часу, в який я клікнув. Вибираємо потрібний конверт.
2) Тут вже бачимо іншу картину. Зверху вказується версія HTTP, код «200 OK», який означає, що надсилається запитувана сторінка, а не повідомлення про помилку. Далі вказується довжина контенту, тип файлу, а також з якого сервера відправляється. І в самому нижньому рядку вказується, що передаються якісь дані. Після того, як дані дійдуть до комп'ютера, можна спостерігати, що веб-браузер комп'ютера відкрив сторінку.
Ось так працює протокол HTTP. Розгляньмо його розширену версію HTTPS. Як ми пам'ятаємо, ця версія підтримує шифрування і не передає дані у відкритому вигляді. На самому початку, ми включили сервіс HTTP і HTTPS. Тому все готово, і можна запитувати сторінку. Відмінність запиту в тому, що перед адресою сторінки замість HTTP, пишемо HTTPS.
Бачимо напис, що дані захищені, і ми їх прочитати не можемо. В принципі це все відмінності, які може показати CPT, але для базового розуміння цього достатньо. Від себе додам, що коли ви переходите на сайт, що працює за HTTPS, у браузері він позначається у вигляді замка. Наприклад
Для тих, хто хоче самостійно поколупати і подивитися, як це працює, можуть завантажити дану лабу тут.
Ми поговорили про HTTP, і тепер час розібрати протокол DNS. Цей протокол тісно пов'язаний з попереднім протоколом, і скоро ви зрозумієте чому.
II) DNS (Domain Name System). Система доменних імен. Якщо говорити в цілому, то вона зберігає інформацію про домени. Наприклад, яка IP адреса відповідає певній назві. Наведу приклад: коли ви відкриваєте свій улюблений сайт, то звертаєтеся до нього по імені. Але в поля Source Address і Destination Address, які працюють на мережевому рівні (це тема наступної статті, але я трохи забіжу вперед), не можна вставити ім'я. Там обов'язково має бути присутня саме IP адреса. Ось DNS якраз цим і займається. Вона повідомляє, яка IP адреса у запитаного імені. Ви, наприклад, звертаєтеся на google.ru. Ваш комп'ютер поняття не має, хто і що це. Він запитує у DNS-сервера: Хто такий google.ru? І сервер відповідає, що google.ru - це 74.125.232.239 (це одна з його адрес). І вже після цього комп'ютер відправляє запит на 74.125.232.239. Для користувача все залишиться як і раніше, і в адресному рядку він також буде бачити google.ru.
Як завжди, покажу це на картинці
Думаю, що вище описане зрозуміло, і рухаємося далі. Служба ця ієрархічна. І часто DNS-сервер (на якому запущена ця служба) працює у зв'язці з іншими DNS-серверами. Давайте розберемо, що це означає. Ієрархічність його полягає в тому, що він працює з доменами рівня. Працює він від молодшого рівня до старшого, зліва направо.
Наприклад, ім'я: ru.wikipedia.org. Найстаршим буде доменне ім'я «org», а молодшим - «ru». Але часто бувають випадки, коли DNS-сервер не може нам розповісти про якесь домене ім'я, і тоді він звертається до старшого DNS-сервера, який відповідає за доменні імена більш високого рівня. Не буду винаходити велосипед і приведу картинку з вікіпедії. Там ця робота проілюстрована добре.
Припустимо, ми набрали в браузері адресу ru.wikipedia.org. Переглядач запитує у сервера DNS: «яка IP-адреса у ru.wikipedia.org»? Однак сервер DNS може нічого не знати не тільки про запитане ім'я, але навіть про весь домен wikipedia.org. У цьому випадку сервер звертається до кореневого сервера - наприклад, 198.41.0.4. Цей сервер повідомляє - «У мене немає інформації про цю адресу, але я знаю, що 204.74.112.1 є відповідальним за зону org». Тоді сервер DNS надсилає свій запит до 204.74.112.1, але той відповідає: «У мене немає інформації про цей сервер, але я знаю, що 207.142.131.234 є відповідальним за зону wikipedia.org.». Нарешті, той же запит надсилається до третього DNS-сервера і отримує відповідь - IP-адреса, яка і передається клієнту - браузеру.
Відкриваю CPT і показую, як це працює. Ця і наступні лабораторні роботи буду ґрунтуватися на попередній. Тому адресація буде такою ж.
Тут додано ще один сервер, який буде виконувати роль DNS-сервера і комутатор. Коли в мережі з'являються 3 і більше пристроїв, то для їх з'єднання використовують комутатор.
Займемося налаштуванням DNS-сервера. Зайдемо в «IP Configuration» і пропишемо IP адресу з маскою.
Тепер зайдемо в сервіси і налаштуємо DNS службу.
1) У вікні Name запишемо ім'я, яке хочемо прив'язати до IP адресу. (я написав ім'я свого майбутнього сайту, над яким йде робота).
2) У вікні Address, відповідно, IP-адреса, яка працюватиме у зв'язці з вище написаним ім'ям. (тут вкажемо ту саму адресу, що і в лабораторній за HTTP - 192.168.1.2).
3) Натискаємо кнопку Add, щоб додати цей запис.
4) Не забуваємо включити саму службу!
Якщо все виконали вірно, то картина повинна бути такою.
Тепер треба в налаштуваннях сервера і комп'ютера вказати адресу DNS-сервера.
Налаштування DNS-сервера і вузлів закінчено, і саме час перевірити, як ця справа працює. Перемикаємо середовище в режим симуляції і спробуємо з комп'ютера зайти на сайт на ім'я «cisadmin.ru».
І бачимо, що створюються 2 конверти. Перший - це DNS, а другий - ARP. Про ARP ми толком не говорили, так як це тема наступної статті. Але раз він показав себе, то коротко розповім, для чого він. Як ми пам'ятаємо, для обміну між вузлами недостатньо IP адреси, оскільки ще використовуються MAC-адреси, що працюють на канальному рівні. Ми вказали комп'ютеру IP адресу DNS-сервера. Але він не знає, яка у вузла з IP-адресою 192.168.1.3 MAC-адреса. Він формує ARP повідомлення і викидає його в мережу. Даний кадр (дані на канальному рівні називаються - кадри) є широкомовним, тобто його отримають всі учасники, що знаходяться в одній локальній мережі (правильно сказати всі учасники в одному широкомовному домені, але поки ми це не зачіпали, і я не буду вантажити вас цим терміном). І той, у кого ця адреса, відправить зворотне повідомлення і повідомить свою MAC-адресу. Всі інші учасники відкинуть цей кадр. Дивимося малюнки.
Ось кадр прийшов на комутатор, і тепер його завдання розіслати цей кадр на всі порти, крім того, звідки він прийшов.
Кадри були розіслані і спостерігаємо наступне. Кадр, який прийшов на веб-сервер був відкинутий, про що говорить перекреслений конверт. Отже, кадр відкидається. А DNS-сервер, навпаки, дізнався свою адресу і повинен сформувати відповідь.
І як бачимо, була створена ARP-відповідь. Давайте трохи розберемо його.
1) MAC-адреси. У Source MAC він записує свою MAC-адресу, а в Destination MAC (Target MAC) адресу комп'ютера.
2) У Source IP своя IP адреса, а в Target IP адреса ПК.
Я думаю, тут все зрозуміло. Якщо незрозуміло, то питайте. У наступній статті я докладніше про нього розповім.
Я натискаю на «Capture/Forward» і дивлюся, що буде далі відбуватися.
І бачу, що комп'ютер успішно отримав ARP від сервера. Тепер він знає MAC-адресу DNS-сервера, а значить, і як з ним зв'язатися. І відразу вирішує дізнатися у нього, хто такий «cisadmin.ru». Ми можемо відкрити ці дані і подивитися, що він там вирішив відправити. Відкриваємо «Outbound PDU Details» і спускаємося в самий низ. Бачимо, що у верхньому полі «NAME» він записав запитуване ім'я. Тиснемо кнопку «Capture/Forward» і дивимося.
DNS-сервер отримує DNS-запит. Він лізе в свою таблицю і бачить, що такий запис у нього присутній, і формує відповідь. Відкриваємо і бачимо, що змінилося поле LENGTH і дорівнює 4. Тобто 4 байти. Стільки займає IP адресу. І, відповідно, записує сам IP-адресу - 192.168.1.2. Це і є адреса веб-сервера. Рухаюся далі.
Бачимо, що комп'ютер отримав повідомлення від DNS-сервера, про що свідчить галочка на коричневому конверті. І тепер він знає IP адресу веб-сервера. Відразу ж він намагається встановити TCP сесію, але виникає проблема. Він не знає MAC-адресу веб-сервера і запускає аналогічний ARP запит, щоб дізнатися. Дивимося.
І тут аналогічно попередньому. DNS-сервер зрозумів, що повідомлення не для нього, і відкидає. А веб-сервер дізнається свою IP адресу і формує ARP відповідь.
Дійшов до комп'ютера ARP відповідь. Тепер він знає MAC-адресу веб-сервера і намагається встановити TCP сесію. Якщо протокол TCP знову дав про себе знати, і в наступних протоколах він теж буде фігурувати, то коротко поясню навіщо він потрібен. Як ви пам «ятаєте з першої статті, я говорив, що він встановлює з» єднання. Так ось тепер кожен блок даних, який буде відправлений від сервера комп'ютеру, буде промаркований. Це потрібно для того, щоб клієнт розумів, чи всі дані він отримав або якісь загубилися. І, якщо якісь дані загубилися, він зможе запросити їх повторно. Втрата блоку даних сайту може призвести до того, що сайт перекосить, і він відобразиться криво. Але зараз головне розуміти, що TCP розташовується на транспортному рівні і працює з портами. Я спеціально відкрив вікно, де це написано, щоб ви поступово звикали до цих полів.
Подивимося, чим відповість комп'ютеру веб-сервер.
Веб-сервер надсилає комп'ютеру повідомлення у відповідь, і встановлюється сесія. І, коли все готово, комп'ютер формує HTTP і відсилає його веб-серверу. Давайте подивимося, що змінилося. А змінилася у нас найостанніша сходинка. Якщо раніше там була записана IP адреса веб-сервера, то тепер там красується доменне ім'я «cisadmin.ru». Але не забувайте, що доменне ім'я тут записано тільки в даних прикладного рівня. IP-адреса нікуди не поділася. Він розташовується на мережевому рівні. Тому давайте відразу покажу IP пакет, де представлені ці адреси.
І як бачите, IP адреси на місці.
Далі процес аналогічний лабораторній за HTTP. Тому наведу фінальний етап, де за назвою «cisadmin.ru» відкриється сторінка, що знаходиться на сервері з IP адресою 192.168.1.2.
Відповідно бачимо, що все прекрасно працює, і сайт відкривається по доменному імені.
І наостанок згадаю про одну дуже важливу утиліту під назвою nslookup. Вона дозволяє звернутися до DNS-сервера і дізнатися у нього інформацію про ім'я або IP-адресу. У CPT ця команда присутня, і я пропоную поглянути на неї.
Клікаємо по комп'ютеру на схемі і на вкладці «Desktop» вибираємо «Command Prompt». Це імітація командного рядка.
Відкривається у нас віконце, подібне cmd в ОС Windows. Можна ввести знак ""? "і натиснути ENTER. Вона покаже список всіх доступних команд. Нам потрібна команда nslookup. Введемо її і натиснемо ENTER.
Відкривається сама утиліта, про що свідчить знак пташки ліворуч. Показується нам адреса DNS-сервера і його ім'я. Оскільки імені немає, то він дублює туди рядок з IP-адресою.
Ну і саме час вписати туди доменне ім'я і дізнатися, що він видасть у відповідь.
Видає він ім'я та адресу, як і передбачалося. В принципі, коли ви звертаєтеся на веб-сайт, він сам виконує цю процедуру. Ви бачили цей запит вище.
Є ще один файл у кожній ОС, який тісно пов'язаний з DNS. Назва у нього «hosts». Стандартне розташування його у Windows системах «windows\system32\drivers\etc\hosts». А в * nix подібних системах: ""/etc/hosts"". Робить він те ж саме, що і DNS-сервера. І контролюється цей файл адміністратором комп'ютера. І найважливіше: він має пріоритет перед DNS-сервером. І, якщо у вас в файлі написано, що сайту habrahabr.ru відповідає IP адреса, яка насправді відповідає google.ru, то, відповідно, відкривати він буде google, а не habrahabr. Цим часто користуються зловмисники, коли вносять виправлення в цей файл. Наведу скрін цього файлу зі свого комп'ютера.
Ось так він виглядає. Можете відкрити його у себе і зрозумієте, що він точно такий же.
Ось така цікава служба і протокол. Також як і з HTTP, наведу посилання на скачування даної лаби.
А ми рухаємося далі і розбираємо протокол DHCP.
III) DHCP (Dynamic Host Configuration Protocol). Протокол динамічного налаштування вузла. Він дозволяє вузлам динамічно отримувати IP адреси та інші параметри для коректної роботи в мережі (основний шлюз, маску підмережі, адреси DNS-серверів). Від себе скажу, що цей протокол рятує життя багатьом сисадмінам по всьому світу. Погодьтеся, що ходити і вручну прописувати IP параметри кожному вузлу, не найприємніше заняття.
За допомогою DHCP можна забезпечити повний контроль над IP адресами: створювати окремі пули для кожної підмережі, видавати адреси в оренду, резервувати адреси та багато іншого.
Робота його дуже важка для нинішнього розуміння. Занадто багато пакетів, даних і кадрів повинно передатися, перш ніж запитана адреса буде присвоєна комп'ютеру.
Давайте подивимося, як він працює на практиці.
І бачимо, що додався новий сервер. Звичайно, можна було віддати всі ролі одному серверу, але, щоб ви розуміли, як ходять дані, нехай для кожної ролі буде окремий сервер.
Налаштуємо сервер.
Присвоюємо вільну адресу і маску. Перейдемо до ролі DHCP.
1) Вибираємо службу DHCP, і тут вже створено стандартний пул. Його видалити не можна. Тільки змінити. Можете самі створити кілька пулів і витворяти з ними, що завгодно, аж до видалення. Але стандартний завжди залишиться. Нам додаткові пули не потрібні, тому переробимо під себе стандартний.
2) Тут можна додати адресу шлюзу, адресу DNS-сервера. Ми поки не торкалися питання шлюзу, тому поки не будемо його чіпати. DNS-сервер у нас є, і його можна вказати. Ну і старт адрес залишимо, як є.
3) Не забуваємо увімкнути сервер!
Перемикаємо середовище в режим симуляції і подивимося, як комп'ютер отримає адресу.
Відповідно переходимо в налаштування конфігурації і перемикаємо на DHCP.
Бачимо, що створився DHCP-запит. Давайте пройдемося по кожному його рівню і поверхово подивимося, що всередині.
1) Протокол канального рівня (Ethernet). У «Source MAC» записується адреса комп'ютера. А в Destination MAC записано широкомовну адресу (тобто всім).
2) Протокол мережевого рівня (IP). У «Source IP» записується адреса «0.0.0.0». Ця адреса вставляється, коли у запитувача немає адреси. А в «Destination IP» вставляється широкомовна адреса «255.255.255.255».
Дивимося далі.
Подивимося на поле UDP. Тут використовуються порти 67 і 68. Це порти UDP, зарезервовані для DHCP.
Тепер дивимося на поле DHCP. Тут все по нулях, і тільки в полі «CLIENT HARDWARE ADDRESS» записано MAC-адресу комп'ютера.
Ми знаємо, як працює широкомовна розсилка, і подивимося, як будуть реагувати на неї учасники мережі.
І бачимо, що всі крім DHCP-сервера відкинули дані.
Далі роботу протоколу розповім на словах, тому що дуже багато пакетів і кадрів буде сформовано, перед тим як DHCP-сервер видасть адресу. Як тільки він отримає запит, він починає шукати вільну адресу в базі. Як тільки адресу знайдено, починається наступний етап - це перевірка адреси. Адже, як ми пам'ятаємо, адресу можна призначити і вручну, в обхід DHCP-сервера. Таке часто відбувається, і навіть у корпоративному середовищі знаходяться розумники, які вручну вписують адресу. Для цього DHCP-сервер пе
