02.11.2023
1 хв
1708
У світі мережевих технологій поняття bridge і switch часто плутають — навіть досвідчені спеціалісти іноді використовують ці терміни як синоніми. Проте в сучасних дата-центрах між ними існує чітка функціональна межа, і саме ця стаття допоможе її зрозуміти.
У матеріалі розглядається, як bridge виконує роль логічного рівня, прозоро об’єднуючи вузли в межах одного сегмента L2, а switch — фізичний пристрій, що реалізує цю функцію та часто працює ще й як роутер на L3-рівні.
Різниця між цими двома мережевими пристроями була для мене нерозв’язною загадкою протягом досить тривалого часу. Якийсь час я використовував слова «міст» і «комутатор» як взаємозамінні. Але глибше занурившись у мережеві технології, я почав помічати, що деякі люди схильні сприймати їх як досить різні пристрої… Тож, можливо, я зовсім помиляюся? Можливо, вислів «міст, також відомий як комутатор» занадто неточний?
Давайте спробуємо розібратися!
Є гарна книга під назвою «Розуміння внутрішньої структури мережі Linux». У ній є цілий розділ про мости. Серед іншого, там стверджується, що міст — це те саме, що й комутатор .
Терміни bridge (міст) і switch (комутатор) можуть використовуватись для позначення одного й того ж пристрою. Однак сьогодні термін bridge переважно застосовується в документації (наприклад, у специфікаціях IEEE, що згадуються наприкінці цього розділу), яка описує поведінку мостів і принцип роботи STP (про який піде мова в наступному розділі). Натомість для позначення реальних пристроїв зазвичай використовується термін switch.
Єдині випадки, коли я бачив використання терміну bridge стосовно пристрою, — це коли він має лише два порти (а такі мости з двома портами сьогодні досить рідкісні). Саме тому я іноді неофіційно визначаю комутатор як багатопортовий міст. Якщо ви не знайомі з офіційною документацією IEEE, то, найімовірніше, будете використовувати слово switch. Особисто я працював із програмним забезпеченням для мостів багато років і, наскільки пригадую, термін bridge я вживав лише в документації — ніколи для позначення пристрою в реальній мережевій конфігурації.
Загалом можна сказати, що насправді немає суттєвої різниці між мостом і комутатором.
Мій висновок з цієї книги був таким:
Кажучи «міст», ми маємо на увазі логічну функцію пристрою.
Кажучи «перемикач», ми маємо на увазі фактичний фізичний пристрій, який виконує цю функцію.
Отже, що це за функція ?
Мости прозоро об’єднують вузли мережі в сегменти другого рівня, створюючи широкомовні домени другого рівня. Вузли одного сегмента можуть обмінюватися кадрами канального рівня один з одним, використовуючи або одноадресні (MAC), або широкомовні адреси.
Мости можуть поєднувати не лише кінцеві вузли, а й підсегменти. Тобто, можна з’єднати міст з мостом, наприклад, подвоївши максимальний розмір сегмента.
Той факт, що мости виконують свою функцію прозоро, означає, що з точки зору учасників мережі мостів не існує. Вузли просто надсилають кадри один одному. Завдання моста полягає в тому, щоб дізнатися, який вузол доступний з якого порту, і відповідно пересилати кадри Ethernet.
Еволюція мережевих пристроїв має довгу історію. Нібито мости спочатку були двопортовими пристроями, що об’єднували два сегменти мережі L2 (чи L1?) у більший сегмент L2. Звідси й назва мости . Потім вони перетворилися на багатопортові пристрої, але назва залишилася. Незалежно від кількості портів, такі пристрої були непомітними з точки зору учасників мережі – мости завжди виконують свою функцію прозоро.
Потім апаратне забезпечення еволюціонувало ще більше, і сьогодні важко знайти чисто апаратні мости, особливо в серйозному контексті використання (див. наступний розділ). Однак потреба у функції логічного мосту залишилася незмінною. У реальному світі цю функцію часто виконують комутатори . У віртуальному світі – віртуальний пристрій Linux bridge .
Зрозуміти різницю мені допомогло те, що я почав думати з точки зору наступних логічних мережевих пристроїв:
Міст — прозорий пристрій другого рівня, що виконує переадресацію кадрів в одному сегменті L2.
Маршрутизатор — непрозорий пристрій 3-го рівня, що виконує пересилання IP-пакетів між кількома сегментами 3-го рівня.
Отже, як можна організувати досить велику локальну мережу? Теоретично, можливо з’єднати кілька мостів між собою, щоб розширити широкомовний домен до сотень (або навіть тисяч) вузлів. Але виявилося, що гігантськими доменами широкомовлення досить важко керувати . Очевидно, що в реальному світі величезні домени часто призводять до величезних збоїв.
Таким чином, замість величезного широкомовного домену, що охоплює весь центр обробки даних, краще мати менші ізольовані сегменти L2, які можуть взаємодіяти один з одним через… маршрутизатори L3! Повертаємося до перемикачів…
Сучасні мережеві комутатори, що використовуються в центрах обробки даних, є досить просунутими пристроями. Вони можуть працювати як мости. Або як маршрутизатори. Або… деякі їхні порти можуть працювати в режимі моста, а деякі інші – в режимі маршрутизатора. Я б трохи поміркував і сказав, що, ймовірно, ми говоримо тут про багаторівневі комутатори.
У конфігурації, з якою я познайомився, всі сервери в одній стійці належать до однієї IP-підмережі /24 та підключені до одного комутатора.
Здається, Facebook має досить схожу архітектуру мережі DC. Я не досліджував багато, але ця стаття про Load Balancer опосередковано це підтверджує.
Такий комутатор називається верхнім розташуванням у стійку (TOR) . Для цих серверів комутатор TOR поводиться як канонічний прозорий багатопортовий міст. Тобто як чистий пристрій другого рівня. А стійка формує сегменти L2 та L3 однакового розміру.
Однак сегменти L3, утворені окремими стійками, необхідно об’єднати в мережу. Для цього один з портів, що залишилися, комутатора TOR налаштовується на роботу в режимі L3. На відміну від портів L2, це означає, що цей порт є адресованим мережевим вузлом з IP-адресою. Потім він підключається до комутатора вищого рівня.
Насправді, кожен комутатор TOR зазвичай підключений щонайменше до двох комутаторів вищого рівня. По-перше, для забезпечення певної резервності у разі збою обладнання. Але також, якщо ці численні фізичні з’єднання об’єднати в одне логічне посилання, це може збільшити результуючу пропускну здатність.
Ці комутатори вищого рівня на діаграмі вище називаються комутаторами розподільчого рівня . У мережі, яку я розглядав, комутатори на цьому рівні працюють як чисті маршрутизатори L3. Отже, кожен порт комутатора розподільчого рівня є повноцінним пристроєм 3-го рівня з призначеною йому IP-адресою.
TOR-комутатори можна розглядати як складні пристрої з мостом (з десятками портів) та маршрутизатором (лише з 2 портами) всередині. Комутатори розподільного рівня можна розглядати як багатопортові маршрутизатори L3. Як справжні багатопортові маршрутизатори на 48 або 64 порти! Маршрутизатор на TOR-комутаторі знає лише два маршрути – до підмережі стійки та маршрутизатор за замовчуванням, що вказує на його комутатор розподільного рівня. І кожен комутатор розподільного рівня знає багато маршрутів. Кожна стійка, підключена до неї, має власну /24 IP-підмережу, і цей комутатор працює як прикордонний маршрутизатор для десятків таких підмереж.
Однак, фізично, між першим і другим типами перемикачів немає жодної різниці! Вони всі виглядають однаково, але просто налаштовані по-різному.
Окрім цих 48 (або 64) портів, комутатори мають один або два позасмугові порти.
Незалежно від режиму інших портів, позасмугові порти завжди працюють у режимі L3. Можна увійти на комутатор, використовуючи IP-адресу позасмугового порту . Це потрібно для керування комутаторами, оскільки налаштування комутаторів через звичайні порти було б просто небезпечним. Уявіть, ви наплутали якісь команди та заблокували себе на комутаторі?
Цікаво, як би це виглядало, якби ви підключилися до комутатора через ssh ? Сюрприз, сюрприз! Це ж Linux! Або FreeBSD. Або ж якась пропрієтарна Unix-подібна ОС. Тобто, можна налаштувати комутатор через традиційний ssh-сеанс, використовуючи широко відомі інструменти iproute2 , такі як ipта/або bridge.
З точки зору управління, кожен порт на комутаторі виглядає як традиційний мережевий пристрій. Можна підключити деякі порти до віртуального мосту Linux , призначити IP-адреси іншим портам, налаштувати пересилання пакетів між портами, встановити таблицю маршрутизації тощо. Отже, ви можете уявити собі комутатор як сервер Linux з багатьма мережевими портами. І тільки вам вирішувати, як їх налаштувати. Усі традиційні можливості Linux у вашому розпорядженні. Але, звичайно, з точки зору обладнання, комутатори є високооптимізованими пристроями обробки пакетів.
Отже, що відбувається з доменами широкомовлення? Чи можемо ми мати домен широкомовлення, що охоплює кілька стійок? Звичайно! VXLAN на допомогу! До цього моменту я описував фізичну мережеву конфігурацію центру обробки даних. Але поверх неї можна налаштувати будь-яку мережу-оверлей, що зробить її адаптованою до потреб кінцевих користувачів.
Попри поширену плутанину між поняттями міст (bridge) та комутатор (switch), суть полягає в наступному: міст — це логічна функція об’єднання вузлів у межах одного сегмента другого рівня (L2), тоді як комутатор — це фізичний пристрій, що виконує цю функцію, часто з розширеними можливостями маршрутизації (L3).
Сучасні мережеві комутатори стали універсальними пристроями, здатними працювати як мости, маршрутизатори або гібриди, залежно від конфігурації. У типовій інфраструктурі дата-центру комутатор TOR (Top-of-Rack) відіграє роль мосту для серверів у межах стійки, а комутатори розподільчого рівня — повноцінних маршрутизаторів для об’єднання різних підмереж.
Кожен порт у таких пристроях — це гнучкий інтерфейс, який можна підключити до Linux-мосту, призначити йому IP, або змінити режим його роботи. Усе це робить сучасні комутатори логічно подібними до багатопортових серверів, оптимізованих для максимальної швидкості обробки трафіку.
І хоча терміни bridge і switch історично перетиналися, сьогодні правильне розуміння їхнього призначення — це не семантика, а основа для грамотного проєктування мереж.
👉 Якщо коротко: міст — це функція. Комутатор — це інструмент, який її виконує. Іноді навіть значно більше.
