Компьютерные сети - простейшие основы принципов работы (часть 5)

Краткие итоги: три уровня модели: физический, канальный, сетевой. Физический - пищание, канальный - определение "кому" и проверка правильности. Оборудование: концнетраторы/повторители - первый уровень, мосты, коммутаторы - второй.

На этом мы заканчиваем с "нормальной" частью второго уровня. Перед началом самой замороченной "ненормальной" части второго уровня, посмотрим, что ещё интересного происходит в компьютерных сетях на втором уровне.

Прошлый урок закончился на вопросе, что произойдёт, если засунуть лампочку в рот соединить два порта одного и того же коммутатора.

Ответ - ничего хорошего. Как только прийдёт пакет на неизвестный MAC-адрес или броадкаст (а в виндовых сетях их мнооого), он будет разослан по всем портам. Пакет дойдёт до коммутатора и будет разослан по всем портам. Пакет дойдёт до коммутатора и будет разослан по всем портам.... (я могу повторить ещё раз 20, чтобы понятно стало что произойдёт, если всё ещё не понятно - поднесите микрофон мегафона к динамику мегафона - оно самое). Коммутатор почти мгновенно станет перегруженным. Если в цикл попадёт броадкаст (а он попадёт!) - перегруженными окажутся все остальные физические сегменты, которые соеденены вместе. Заметим, если у нас в сети несколько коммутаторов, то перегружена окажется вся сеть, так как ей придётся транслировать все броадкасты. Жуть.

Кстати, подобную гадость можно сделать и менее очевидным методом. Пусть у нас есть 10 коммутаторов. Соединим их в кольцо - 1 с 2, 2 с 3, ..., 9 с 10, 10 с 1. Получившееся колечко будет возбуждаться не чуть не хуже "самовозбужающегося коммутатора" (подобное кольцо иногда называют mantrain).

Что можно сделать в такой ситуации? Две вещи: оборвать руки тому, кто воткнул лишний провод, и оборвать провод. Сеть быстро угомонится.

Но... неужели "умная" железка внутри не может сама подумать, что тут что-то не так, и перестать так активно возбуждаться? Может. Если она достаточно умна. Тут проходит сложная грань между коммутаторами управляемыми и неуправляемыми. Неуправляемые коммутаторы реализованы на тупой микросхеме (заметили как мы невинно высшее достижение мысли человека, микросхему, реализующую сложнейшую вычислительную задачу на высочайшей скорости обозвали "тупой"?), так вот, коммутаторы, реализованные на такой микросхеме (или нескольих микросхемах подобного типа), являются неуправляемыми. Они действуют строго по заданному алгоритму и что-либо менять в своём поведении не позволяют. Управляемые коммутаторы позволяют, как понятно из названия, помыкать собой. Так как начинка управляемого коммутатора сложнее, чем неуправляемого, то он может больше "думать" о происходящем. Например, прекращать обработку броадкастов, если их больше 10% от пропускной способности. Это, не выход (броадкасты не просто так вещаются - они нужны для работы некоторых протоколов), но хотя бы всю сетку не положит мгновенно.

Есть более радикальный выход. Появляется такая вещь, как протокол второго уровня, который умеет находить подобные петли и "выключать" лишние соединения. Помимо этого он умеет их включать обратно, если перестаёт работать оставшееся соединение. Этот протокол называется STP (Spanking Toy Porn Spaning Tree Protocol) и в сетях домашнего уровня он не используется.

Полное описание STP скучно, но суть его в том, что в любой конфигурации соединений коммутаторов между собой, он обеспечивает не более одного маршрута из любой точки в любую.

Второй большой и тяжкой нашлёпкой на простой и понятный второй уровень являются виртуальные сети (VLAN). Витруальные сети используются для связи виртуалов пользователей с виртуальными серверами и зарабатывания виртуальных денег для оплаты виртуального секса в виртуальной реальности.

Если же быть не столь серьёзным, то виртуальные сети - это средство искуственного деления существующих канальных сегментов на более мелкие канальные сегменты. Коммутатору объявляется, что порты 1, 2, 3 - это сеть номер один, а порты 4, 5, 6 - это сеть номер два. И кадры из сети номер один не проходят в сеть номер два.

Для чего это нужно? В реальной жизни - для разграничения широковещательных доменов (т.е. канального сегмента, состоящего из скольки-то физических, в пределах которого расходятся широковещательные пакеты). Кроме того, вилан - отличный метод спрятать одну сеть от другой. Например, сделать так, чтобы злоумышленники из состава директоров не могли обнаружить на работе сервер с порнухой. Так как канальные сегменты разделены, то нет возможности обратиться из одного сегмента в другой на канальном уровне (т.е. по MAC-адресу). Заметим, есть ещё непознанный третий уровень (который, по аналогии с схемой взаимодействия физический-канальный, должен таким-то образом связывать канальные сегменты), но о нём потом.

Как всегда в компьютерной области, всё начинается просто. Порты с 1 по 10 - в первой виртуальной сети (VLAN), порты с 11 по 16 во второй, с 16 по 24 - в третьей.

А если у нас больше одного коммутатора? Например, два. И между коммутаторами у нас есть только один шнурок. Как нам сделать так, чтобы можно было сконструировать вилан такого вида: порты 1-2 на первом коммутаторе и порты 11-12 на втором?

Для этого придумывается решение: добавлять номер вилана в фрейм. Для этого мы вводим два основных типа портов: порты, на которые приходят фреймы от пользователей, и порты, которые связывают коммутаторы между собой. При этом, каждый пришедший на "пользовательский" порт кадр получает метку с номером того вилана, на который назначен порт. А если кадр из такого порта выходит, метку с него "срезают". "коммутаторный" же порт метки не снимает и ставит, он передаёт "наверх" те кадры, у которых есть метки нужных номеров (задаются при конфигурировании). Ну и принимает, соответственно. При этом возникает особая проблема, если некое устройство должно присутствовать во всех vlan'ах. Стандартного решения этой проблемы просто не существует. Дилинки предлагают свою хрень в пределах одного коммутатора, циска изобретает проприентарную не-хрень под названием private VLAN (которая не хрень, но стоит дико дорого в результате).

Есть ещё одна интересная вещь на втором уровне. Агрегация портов. Предположим, у нас есть два коммутатора. И в каждом из них куча-куча пользователей. Которые хотят общаться не только друг с другом, но и с пользователями соседнего коммутатора. При этом скорость портов, соединяющих коммутаторы, явно не достаточна для обслуживания всех желающих. Что делать? Положить второй провод? Нельзя, будут бродкасты возбуждать.

Тут приходит другая идея: А почему бы нам не передавать данные по двум проводам, да, так, чтобы при коммутации, неизвестные/широковещательные пакеты по второму (из пары) проводов назад не уходили?

Это и называется link-aggregation. Как легко понять, 4 шнурка по 100Мб дают нам 400Мб. (Обычно в "пачку" можно соединить не больше 4 шнурков).

При этом, возникает проблема: по какому порту передавать заданный фрейм? Казалось бы - по любому (первому свободному). Однако, такое поведение (его, кстати, можно сделать в линухах) может сильно попортить кровь вышестоящим протоколам. Если мы будем отправлять "в первый свободный", последовательность "большой фрейм, маленький фрейм" приведёт к получатению в итоге "маленький фрейм, большой фрейм" (потому что по параллельным линиям маленький фрейм передастся быстрее, чем большой, и раньше него "убежит" в следующий шнурок). Для решения этой проблемы используются алгоритмы "хеширования" данных адреса отправителя/получателя для выбора порта (например, мы можем направлять все данные получателю, у которого чётный последний бит адреса в первый порт, нечётный во второй). Таким образом мы гарантируем сохранение порядка прохождения фреймов от адреса к адресу.

Однако, такая вещь ставит крест на "автоматике". Админ должен сесть и подумать, что именно использовать как хэш - адрес получателя или адрес отправителя (если ошибёшься, то никакого ускорения не будет).

Итог урока: он полностью бесполезен. Ни одна из этих технологий в домашней сети не используется. You've Been Pwned.