Мережі для Самих Маленьких. Микровыпуск №5. FAQ по мережевим технологіям

Поки весь світ із завмиранням чекає 11-го випуску СДСМ, присвяченого MPLS BGP L3VPN, я вирішив зробити вільний переклад непоганий статті Джеремі Зустріч з Packetlife.net.

Це добірка невеликих FAQ для новачків.

#На якому рівні OSI працює протокол Ч?
#Яка різниця між маршрутизатором і багаторівневим комутатором?
#Яка різниця між forwarding і control planes?
#Яка різниця між MTU і MSS?
#Яка різниця між інтерфейсами VLAN і BVI?
#Як працює тунельний інтерфейс?
#Що означають чотири типи адрес NAT?
#чи Можу я використовувати адресу мережі і широкомовна адреса в NAT-пулі?
#Чому нам потрібні IP-адреси? Хіба нам не вистачить MAC-адресації для всього?
#Дозволяє QoS розширити пропускну спроможність?

#На якому рівні OSI працює протокол Ч?
Перша річ, з якою стикається кожний, хто вивчає мережі — це модель OSI (Open Systems Interconnection). Це семирівнева еталонна модель, офіційно визначена в IOS/IEC 7498-1. Ви зустрінете її у будь коли або надрукованою навчальній літературі. Це цілком звичайна справа — посилатися на OSI при обговоренні взаємодії між протоколами. Так, наприклад, TCP — це протокол четвертого рівня, і він сидить на шиї IP — протоколі третього рівня.

Але що це означає насправді? Хто вирішує якого рівня належить протокол? Модель OSI була задумана ще в 70-ті роки, як частина сімейства протоколів OSI, яка на повному серйозі позиціонувалася як суперник стеку TCP/IP (спойлер: TCP/IP таки виграв). Якщо виключити жменьку вижили (напевно, ви чули про протокол динамічної маршрутизації IS-IS), протоколи OSI зараз фактично не використовуються. Однак еталонна модель OSI, що описує, як вони повинні були взаємодіяти, живіший за всіх живих. Що, втім, змушує нас прив'язувати протоколи однієї родини до рівнів, визначених для іншого.

Здебільшого все працює чудово: TCP і UDP їдуть верхи на IP, який в свою чергу пересувається на Ethernet, PPP або що б там не було іншому. Але сорокарічна модель не завжди може задовольнити потрібні сучасних протоколів. Візьмемо для прикладу MPLS. Часто його відносять до рівня 2,5, тому що він працює поверх канального, але нижче мережевого, не здійснюючи при цьому формування фреймів ні наскрізну адресацію (на відміну від IP-адрес, мітки MPLS змінюються на кожному вузлі по мірі просування пакету до точки призначення). Зрозуміло, додавання нового рівня між двома іншими руйнує стандартну модель.

Строго кажучи, ні один протокол з стека TCP/IP не офіційно закріплений за якимось рівнем OSI саме з тієї причини, що це різні сімейства. Яблука і апельсини. Еталонна модель — це еталон (Прим. перекладача: все-таки російська назва трохи не відповідає Reference Model, еталон передбачає свою ідеальність і прагнення йому відповідати). OSI допомагає ілюструвати залежність одних протоколів від інших, і хто ким поганяє, але вона не може диктувати, як їм функціонувати.

Але якщо раптом хтось запитає, відповідайте, що MPLS — це протокол третього рівня.


#Яка різниця між маршрутизатором і багаторівневим комутатором?
У стародавні часи, маршрутизатори служили для того щоб передавати пакети на основі IP-адрес і надавали широкий діапазон інтерфейсів: Ethernet, E1, Serial, OC-3 ітд. У той же час комутатор передавав пакети (кадри, прим. для ліги зануд), грунтуючись на MAC-адресах, і мали тільки порти Ethernet.

Але на початку 2000-х нашому чіткого розуміння цієї різниці прийшов кінець — вимальовувалися дві важливі тенденції. По-перше, з'явилися багаторівневі комутатори, які не просто отримали право передавати пакети, базуючись на ІР-адресах, але і брати участь в протоколах динамічної маршрутизації, як справжні маршрутизатори. По-друге, оператори почали незворотний процес міграції з технологій з комутацією каналів на модерновий Ethernet, надає високі швидкості за низьку плату. Сьогодні абсолютно в порядку речей, якщо маршрутизатор має тільки Ethernet-інтерфейси, як ніби він комутатор.

Де лежить межа між маршрутизатором і багаторівневим комутатором? Існує ще ця межа?
Фактична різниця між ними зводиться до наступних пунктів:

  • Щільність портів. Комутатори рівня Enterprise зазвичай несуть на борту 24 або 48 портів. Іноді вони можуть стекироваться для ще більшого розширення. Основна мета: засунути настільки багато інтерфейсів, наскільки дозволяє передня панель. Маршрутизатор навпроти зазвичай має набагато менше інтерфейсів, можливо, рознесених по різним змінним платам. (Прим. перекладача: якщо мова йде про обладнання операторського класу, то щільність портів на лінійних платах маршрутизатора цілком зрівняється з коммутаторскими).
  • Швидкість. Комутатори створені для того, щоб молотити трафік. Зараз навіть скромні офісні комутатори часто надають пропускну здатність на швидкості лінії. Це досягається за рахунок того, що обробка трафіку відбувається на апаратних чіпсетах без участі CPU. (Прим. перекладача: слід і тут зауважити, що і маршрутизатори зараз переважно використовують для передачі трафіку FPGA і ASIC і в своїй пропускній здатності не поступаються комутаторів).
  • Інтелект. Ключове ж різниця, яка може змусити вас вибрати маршрутизатор — інтелектуальна начинка. Маршрутизатор надає такі функції, як NAT, DPI, Stateful файрвол, шифрування тощо — все це, як правило, не підтримується комутатором.
Як би те ні було, сучасний світ грунтується на обладнанні, виготовленому під конкретні потреби. Однак, якщо зазирнути у завтра з віртуальними эплайнсами, NFV і SDN, ми приходимо до того, що одна і та ж коробочка може виконувати абсолютно різні ролі залежно від свого положення в мережі.


#Яка різниця між forwarding і control planes?
Для новачків це, безсумнівно, джерело плутанини.

Forwarding plane часто називають Data Plane, а по-російськи найвдаліший варіант — площину комутації. Її завдання — доставити пакет з пункту А в пункт Б. Площину комутації комутує.

Control plane — площина управління — обслуговує функції розпорядчі, як повинна працювати площину комутації. Площину управління керує.

Ось наприклад, у вас є маршрутизатор з OSPF. Він обмінюється маршрутною інформацією з сусідніми маршрутизаторами OSPF, становить граф всієї мережі і обчислює маршрути. Коли таблиця маршрутизації (RIB) побудована, маршрутизатор інсталює найкращий маршрут до кожної відомої точки призначення в таблицю комутації (FIB). Це функції control plane.

Коли той же маршрутизатор отримує IP-пакет, він шукає адресу призначення у своїй таблиці комутації, щоб визначити інтерфейс, в який пакет потрібно відправити. Далі пакет передається в буфер вихідного інтерфейсу і потім в кабель. Це функції forwarding plane.

Відчуваєте різницю? Площина комутації відповідає за прийом і передачу пакетів, в той час як площину управління — за те, як саме приймаються рішення про передачу пакета.

Площина комутації реалізована, як правило, в залізі, іншими словами виконується спеціальними чіпсетами (наприклад, Network Processor звертається до TCAM, щоб швидко отримати вихідний інтерфейс з FIB), не вимагаючи звернення до CPU.

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


#Яка різниця між MTU і MSS?
Maximum transmission unit (MTU) говорить про максимальному обсязі даних, який може нести один пакет. Зазвичай ми говоримо про MTU щодо Etherner (хоча інші протоколи, звичайно, теж мають свої MTU). MTU за замовчуванням на більшості платформ — 1500 байтів. Це означає, що вузол може передати кадр, несучий 1500 байтів корисного навантаження. Сюди не включені 14 байтів заголовка Ethernet (18 802.1 q) і 4 байти поля FSC. Підсумковий же розмір кадру 1518 байт (1522 у разі 802.1 q). Багато вузли зараз підтримують джамбофреймы (jumbo), для цього стандартний MTU збільшується до 9000+ байтів.

Maximum segment size (MSS) — це величина характерна для TCP, яка показує максимальну корисну TCP навантаження в пакеті, фактично це MTU для TCP. TCP MSS обчислюється, виходячи із значення Ethernet MTU (а, може, і не Ethernet) на інтерфейсі. Оскільки TCP повинен втиснутися в кадр Ethernet, MSS повинен бути менше, ніж MTU. В ідеалі MSS повинен бути максимально можливим: MTU-розмір заголовка IP-розмір заголовка TCP.

Припустимо MTU 1500 байтів, віднімаємо з нього 20 байтів IPv4 адреси і ще 20 байтів TCP і отримуємо MSS 1460 байтів. IPv6 з його довгим заголовком залишить для MSS всього 1440 байтів.

TCP MSS визначається один раз у ході встановлення з'єднання. Кожен вузол включає свій MSS в опції TCP в перший пакет (той, що з прапором SYN), і обидва вузла вибирають найменше значення з двох MSS сесії. Одного разу встановлений MSS вже не змінюється протягом життя сесії.


#Яка різниця між інтерфейсами VLAN і BVI?
VLAN-інтерфейс, відомий також як SVI (Switch Virtual Interface) або RVI (Routed VLAN Interface) — це віртуальний інтерфейс на багаторівневому комутаторі. Він забезпечує маршрутизацію і часто служить шлюзом за замовчуванням для локального сегмента мережі. VLAN-інтерфейс зазвичай веде себе і налаштовується як фізичний інтерфейс маршрутизатора: на нього можна призначити IP, він бере участь у VRRP, може мати ACL ітд. Ви можете уявити собі, що це фізичний інтерфейс всередині комутатора, а, навпаки, уявити, що це маршрутизирующий інтерфейс поза комутатора, на якому терминируется даний VLAN.

Bridge group Virtual Interface (BVI) служить схожим цілям, але існує на маршрутизаторі, на якому немає концепції VLAN, тому що все його порти зазвичай працюють на L3 (Прим. перекладача: на маршрутизаторах концепція VLAN цілком може бути присутнім). Bridge group змушує два або більше портів працювати на L2, розділяючи між ними широкомовний домен. BVI пов'язує інтерфейси в Bridge Group і служить віртуальними L3-інтерфейсом для всіх сегментів, підключених до нього. Коли маршрутизатор працює одночасно на L2 і L3, його називають Integrated Routing and Bridging (IRB).

В той час, як VLAN-інтерфейс — життєва необхідність багаторівневого комутатора, IRB — нішева річ, яка може використовуватися, наприклад, точки доступу WiFi.


#Як працює тунельний інтерфейс?
Багато людей відчувають труднощі з розумінням концепції тунельних інтерфейсів (Прим. перекладача: справді?). Тунелювання — це просто інкапсуляція одних пакетів всередину інших при передачі їх між двома точками. Тунельний інтерфейс використовується для досягнення такої інкапсуляції для маршрутизуються VPN, які дозволяють захиститися і абстрагуватися від топології нижчою мережі. Існує багато методів інкапсуляції, що включають IPSec, GRE, MPLS ітд.

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


#Що означають чотири типи адрес NAT?
Існує чотири класи IP-адрес в контексті NAT:
  • Inside global
  • Inside local
  • Outside local
  • Outside global
На жаль, ці терміни рідко пояснюються в документації досить зрозуміло.
Кожен з них описує два атрибути: місце розташування (location) і точка зору (perspective).
Розташування повідомляє про якому сайті йде мова. Всередині мережі (до NAT) — Inside; у зовнішній мережі (після NAT) — Outside.
Точка зору повідомляє про те, звідки ми дивимося на цей сайт. Зсередини нашої мережі — Local; із зовнішньої мережі — Global.

Візьмемо для прикладу випадок, коли ви з комп'ютера з приватним адресою 192.168.0.10 хочете зайти по telnet на адресу в Інтернеті 94.142.241.111. З пулу NAT вам виділений IP-адреса 192.0.2.10.
Ось так буде виглядати таблиця трансляцій:

R2# show ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 192.0.2.10:32978 192.168.0.10:32978 94.142.241.111:23 94.142.241.111:23

Розберемося?

Inside Global — як внутрішній вузол виглядає ззовні. Сервер в Інтернеті дійсно бачить адресу з вашого пулу NAT.
Inside Local — як внутрішній адресу виглядає зсередини — приватний адресу комп'ютера
Outside Local — як зовнішній адреса виглядає инзнутри — бачимо його публічний адресу і порт 23.
Outside Global — тут має бути те, як виглядає зовнішній адреса ззовні, але ваш NAT таких трансляцій не вміє, тому адреса збігається з Outside Local.


#чи Можу я використовувати адресу мережі і широкомовна адреса в NAT-пулі?
Так.

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

По-друге адресу мережі і широкомовна адреса визначаються маскою підмережі — без неї вони втрачають сенс. Тому вважати адреса 192.168.0.255 широкомовним адресою, а 192.168.1.0 адресою мережі залежить цілком і повністю від маски: для /23 відповідь ні, для /24 і більше відповідь так, а для /32 знову немає.

Тому адресу 192.168.0.255 ви можете не тільки вказати в пулі, але навіть налаштувати на інтерфейсі з маскою /23.



#Чому нам потрібні IP-адреси? Хіба нам не вистачить MAC-адресації для всього?
Коли новачок починає вивчення MAC-адрес, він бачить, що вони повинні бути глобально унікальними. І виникає закономірне питання, чому б не використовувати MAC-адреси для наскрізної адресації через весь Інтернет, не вдаючись взагалі до IP? Однак існує кілька достатньо вагомих причин залучити IP.

По-перше, не всі мережі мають MAC-адресацію. Взагалі такий тип притаманний тільки сімейства 802. Дуже легко забути про це в світі, де практично все — Ethernet або його варіації (наприклад IEEE 802.11 WiFi). Але у часи юності Ethernet кілька десятиліть тому буйствовало беззаконня у сфері протоколів: Token Ring, Ethernet, Frame Relay, ATM боролися за місце в маршрутизаторі. І забезпечити взаємодію вузлів з Token Ring з вузлами з допомогою ATM MAC-адрес було проблематично — потрібен був протокол мережевого рівня.

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

Але найголовніша причина третя — IP масштабується і може пов'язувати величезні мережі, а Ethernet — доля невеликих сегментів. Простір IP-адрес ієрархічно, MAC-адрес — плоско. 254 вузла однієї локальної мережі можуть бути агреговані в одну підмережа /24. 8 підмереж /24 можуть бути агреговані в одну /21. Це можливо, тому що блоки адрес зазвичай розташовуються поруч в Інтернеті. Все, про що треба дбати в цьому випадку маршрутизатора — як дістатися до підмережі.

MAC-адреси ж кожен сам по собі, так як призначаються псевдовипадковим чином на виробництві, і дві адреси, розрізняються тільки в останньому бите, можуть опинитися в діаметральних кінцях планети. Якщо раптом комусь спаде в голову використовувати MAC-адреси для наскрізної адресації в Інтернеті, він зіткнеться з тим, що маршрутизаторам буде потрібно знати адресу кожного окремо взятого сайту в глобальній мережі. Здрастуй, інтернет речей.

Далі прим. перекладача.
Освітлений в оригінальній статті питання насправді простий — одного відсутності масштабування достатньо для того, щоб відмовитися від цієї ідеї.

Набагато цікавіше зворотне питання: Чому нам потрібні MAC-адреси? Хіба нам не вистачить IP-адресації для всього? Тут все не так однозначно. Чому б, дійсно, в сучасному світі, де скоро назва стека можна міняти на TCP/IP/Ethernet, не зовсім відмовитися від адресації на L2 і дозволити вузлів в сегменті взаємодіяти з IP?

ARP більше не потрібен — пакет комутується по IP (до речі, вже зараз існують комутатори, які дійсно можуть виробляти IP Learning замість MAC Learning). Широкомовлення доступно так само через адреса 255.255.255.255.

При цьому, я не пропоную відмовитися від Ethernet або L2 зовсім, ні — утот необхідний рівень абстракції — мережевий не повинен працювати безпосередньо з фізичним, займатися фреймингом, перевіркою цілісності ітд; ми просто прибираємо адресацію з L2.

Складність починається насправді при передачі пакета з однієї підмережі в іншу через низку маршрутизаторів. Тут дає про себе знати широкомовна природа Ethernet. У заголовку IP адресу призначення фіксований і не змінюється в міру просування пакету. Тому постає питання, як правильно переслати пакет між маршрутизаторами. Зараз як раз для цього використовуються MAC-адреси Next-Hop. Справа в тому, що за Ethernet-інтерфейс маршрутизатора може бути не один сусідній маршрутизатор, а два, три, десять, і тут доведеться додавати ще якийсь ідентифікатор Next-hop.

В реальному світі в 99,9% ми використовуємо P2P лінії між маршрутизаторами і тут немає необхідності в додаванні адреси Next-hop в пакет — більше і слати нікому — просто відправляємо кадр в кабель. Тут можна згадати PPP, де хоч формально полі «адреса» і є, але воно фактично не використовується.

Але концепція Ethernet, який спочатку планувався тільки для локальних сегментів з користувацькими машинами, не передбачає сценарій P2P окремо.

У підсумку адресацію з рівня Ethernet ми не можемо прибрати. Проте тут дотепер залишається питання — навіщо MAC-адреси, адже в заголовку Ethernet ми могли б вказувати ІР-адресу Next-Hop, який змінювався б також на кожному вузлі.

В цілому це правильно, але такий підхід ламає ідеологію стека протоколів, що передбачає незалежність рівнів один від одного. Зараз, наприклад, легко можна викинути Ethernet і замість нього використовувати xDSL або PON або, прости Лейбніц, Frame Relay — складності лише адміністративні і фінансові. Також, поверх Ethernet технічно ви можете пустити власний мережевий протокол ІРЧ — і це все буде працювати з мінімальними змінами (додати новий Ethertype).

Зауважу, що це питання не можна обговорювати у відриві від історичного та адміністративного контексту. Навіть якщо ми візьмемо на себе сміливість припустити, що ми знайшли ідеальне поєднання ідеальних протоколів IP+Ethernet, і найближчі 300 років нам не загрожують глобальні зміни, потрібно пам'ятати, що 20 років тому світ був іншим, як ми вже говорили вище, і Ethernet був лише одним із. Ми не могли так жорстко пов'язувати мережевий і канальний рівні. А тепер мережі, які вже працюють, і нам для цього, як правило, не потрібно докладати титанічних зусиль, ніхто не буде переробляти просто тому, що здається надмірною одночасне використання IP-і MAC-адресації.

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


#Дозволяє QoS розширити пропускну спроможність?
Серед новачків іноді існує оману, що QoS — це чарівна технологія, що дозволяє пропхати через лінію більше пакетів, ніж вона може. Це не так. Наприклад, якщо ваш інтернет-канал обмежений 10Мб/с, ви ніколи не зможете відправити у нього більше. Завдання QoS — віддавати перевагу одним типів трафіку над іншими. Таким чином під час перевантаження на лінії (при спробі відправити більше 10 Мб/с) менш важливий трафік буде відкинутий на користь вільної передачі більш пріоритетного.

Зазвичай QoS застосовується для того, щоб захистити трафік реального часу, як голос або відеоконференції від трафіку, терпимого до затримок і втрат — WEB, пошта, FTP, Torrent ітд. Крім того QoS допоможе уникнути окупації всієї смуги передавання великого обсягу трафіку, типу резервного копіювання серверів.

Розглянемо ситуацію, коли у вас є офіс, підключений через два каналу E1 із загальною пропускною здатністю 4Мб/с. По цій лінії передається і голос і дані. Щоб під час перевантаження голосовий трафік не відчував деградацію, з допомогою QoS можна виділити гарантовану смугу для нього. Решта буде доступна для даних. Однак якщо після цього трафік з даними помітно погіршиться, то QoS вже не допоможе — в цьому випадку доведеться розширювати канал.

Перекладач дозволив собі деякі вільності в російськомовних термінах, які дозволять, як йому здається, краще зрозуміти зміст.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.