Virtual interface что это
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Cisco SVI – теория и настройка
Поговорим сегодня про Cisco SVI – Switch VLAN Interface и о том, как его настроить. Для начала вспомним основы – для связи между оконечными устройствами в локальной сети (LAN) требуется коммутаторы, а для связи между различными локальными сетями требуется маршрутизатор.
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
VLAN 2 уровня также создает новый широковещательный домен, то есть если отправить бродкаст в этой подсети – все устройства, подключенные к этому VLAN’у получат его (не важно, к какому или каким коммутаторам они подключены). Причем все устройства в этом VLAN’е могут общаться между собой без какого-либо устройства 3 уровня. Однако, если требуется связаться с другим VLAN’ом, то будет необходима маршрутизация в том или ином виде.
Для сегментации и связи между VLAN’ами необходим либо маршрутизатор, либо коммутатор 3 уровня. Если мы используем роутер для сегментации, то это означает, что каждый интерфейс на маршрутизаторе являет собой отдельный широковещательный домен, то есть отдельный сегмент.
В случае использования коммутатора 3 уровня, мы предварительно создаем несколько обычных VLAN’ов на коммутаторе, то есть несколько широковещательных доменов. Затем для каждого VLAN’а необходимо создать соответствующий интерфейс на коммутаторе, который будет отвечать за маршрутизацию. Этот интерфейс и есть SVI.
Таким образом, порядок действий следующий – создается обычный VLAN, и затем назначается сетевой адрес на этом VLAN’е. Главная особенность в том, что SVI – виртуальный интерфейс, то есть все клиенты в данном VLAN’е будут использовать SVI как шлюз по умолчанию. По умолчанию, SVI создан на свитчах Cisco 3 уровня на VLAN 1 для целей управления устройством.
Настройка
А теперь мы покажем пример настройки двух SVI на коммутаторе 3 уровня, в соответствии со схемой выше. Сначала – VLAN 10:
Мы создали VLAN, назначили сетевой адрес и поставили описание. Теперь повторим тоже самое для VLAN 20:
Еще раз – зачем это все нужно?
Вы спросите, зачем это нужно и почему бы не использовать вариант с физическими интерфейсами маршрутизатора или «роутер-на-палке» (router on a stick)? Использовать SVI проще и чаще всего дешевле – банально поэтому.
Кроме того, использование SVI на коммутаторе 3 уровня также является более эффективным с точки зрения сходимости и управления – так как весь функционал 2 и 3 уровня управляется на одном коммутаторе 3 уровня.
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
SVI (Switch Virtual Interface)
VLAN-интерфейс, известный как SVI (Switch Virtual Interface) или RVI (Routed VLAN Interface) — это виртуальный интерфейс на многоуровневом коммутаторе. Он обеспечивает маршрутизацию и часто служит шлюзом по умолчанию для локального сегмента сети. VLAN-интерфейс обычно ведёт себя и настраивается как физический интерфейс маршрутизатора: на него можно назначить IP, он участвует в VRRP, может иметь ACL и т.д. Вы можете представить себе, что это физический интерфейс внутри коммутатора, или, наоборот, что это маршрутизирующий интерфейс вне коммутатора, на котором терминируется данный VLAN.
Содержание
Основные сведения:
SVI-интерфейс представляет VLAN и принадлежащие ему порты, как один интерфейс для функций маршрутизации и коммутации в системе, он создается при создании interface vlan и поддерживает протоколы маршрутизации. Присутствует однозначное соотношение между SVI и VLAN. Любому VLAN соответствует только один SVI.
SVI конфигурируется для VLAN’ов по следующим причинам:
SVI на примере Cisco Switch
Состояние UP
SVI-интерфейс находится в состоянии up, если выполняются условия:
Создание SVI
SVI autostate
По умолчанию SVI-интерфейс переходит в состояние «down», если все интерфейсы этого VLAN’а переходят в состояние «down». Порт можно исключить из проверки доступности SVI-интерфейса. Для этого используется команда « switchport autostate exclude ». После включения команда применяется ко всем VLAN, которые включены на интерфейсе. Эта возможность может пригодиться для случаев, когда к порту коммутатора подключен анализатор трафика или IDS.
Интерфейсы 3го уровня
Перевести порт коммутатора в режим работы Layer 3: switch(-if)# no switchport
Полезные команды в Cisco Switch
switchport host
sw(config-if)# switchport host
Команда switchport host:
switchport block
Запретить передавать на порт unknown unicast пакеты: sw(config-if)# switchport block unicast
Запретить передавать на порт unknown multicast пакеты: sw(config-if)# switchport block multicast
mac address-table
Изменить время хранения адресов в таблице коммутации (по умолчанию 300 секунд): sw(config)# mac address-table aging-time [vlan ]
Создать статическую запись: sw(config)# mac address-table static vlan interface
Команда mac address-table static drop позволяет настроить фильтрацию по unicast MAC-адресу. После указания MAC-адреса, коммутатор будет отбрасывать трафик, в котором указан адрес об отправителе или получателе.
Проверка: sw# show mac address-table static
Пример настройки SVI
Итак, два компьютера в сети VLAN 10 и SVI:
Если отключить один интерфейс, SVI все равно будет отображаться «up/up», потому что интерфейс fa0/2 все ещё активен.
Как только закроются оба интерфейса, VLAN 10 станет неактивным. В результате SVI перейдет в состояние «up/down».
Теперь можно исключить интерфейс из состояния SVI. Для этого надо убедиться, что все, что происходит с интерфейсом fa0/2, не влияет на состояние SVI:
Ещё один виртуальный интерфейс
В предыдущей заметке был показан набросок кода модуля ядра Linux для создания дополнительного виртуального сетевого интерфейса. Это был упрощённый фрагмент из реального проекта, отработавшего несколько лет без сбоев и рекламаций, так что он вполне может служить шаблоном для дальнейшего улучшения, исправления и развития.
Но такой подход к реализации, во-первых, не единственный, а, во-вторых, в некоторых ситуациях он может быть и неприемлемым (например, во встраиваемой системе с ядром младше 2.6.36, где ещё нет вызова netdev_rx_handler_register()). Ниже будет рассмотрен альтернативный вариант с той же функциональностью, но реализующий её на совсем другом слое сетевого стека TCP/IP.
Протоколы сетевого уровня
Достаточно много, чтобы не повторяться, написано о том, что уровни (слои) сетевого стека TCP/IP не соответствуют однозначно 7-ми уровням модели взаимодействия открытых систем OSI/ISO (или, если честнее, модель OSI, близкая сердцу академических кругов, оказалась неадекватной реально развивающейся сети TCP/IP). Создание виртуального интерфейса, в предыдущей обсуждавшейся реализации, выполнялось на уровне интерфейсов (L2, Level 2 — очень примерно соответствующий канальному уровню OSI). Нынешняя реализация использует возможности сетевого уровня (L3).
Фактически, в протокольных модулях ядра мы должны добавить фильтр, через который проходят буфера сокетов из входящего потока интерфейса (исходящий поток реализуется проще, как было показано в предыдущей реализации). Функция dev_add_pack() добавляет ещё один новый обработчик для пакетов заданного типа, реализуемый функцией func(). Функция добавляет, но не замещает существующий обработчик (в том числе и обработчик по умолчанию сетевой системы Linux). На обработку в функцию отбираются (попадают) те буфера сокетов, которые удовлетворяют критерием, заложенным в структуре struct packet_type (по типу протокола type и сетевому интерфейсу dev).
Примечание: По той же схеме (установка функции-фильтра) происходит добавление новых протоколов и на более высоком, транспортном уровне сетевого стека (на котором обрабатываются, например, протоколы UDP, TCP, SCTP). Все более высокие уровни (более-менее аналогичные уровням модели OSI) в ядре не представлены, и обслуживаются в пространстве пользователя техникой программирования BSD сокетов. Но все эти, относящиеся к более высоким уровням, детали более не будут рассматриваться в тексте.
Если мы хотели бы добавить новый протокол (проприетарный), то должны были бы переопределить его тип:
Проблему при этом составило бы то, что стандартный IP-стек не знает такого протокола, и всю его обработку нам придётся взять на себя. Но в наши цели входит только переопределить обработку некоторых пакетов, то для этого используем константу ETH_P_ALL, указывающую, что через фильтр должны проходить все протоколы (а если поле dev равно NULL — то и все сетевые интерфейсы).
В данном случае поле type — это не абстрактное числовое значение в программном коде, это значение в бинарном виде будет вписано в заголовок Ethernet кадра, физически отправляемого в среду распространения:
(Это же описание нам понадобится в коде при заполнении структуры struct packet_type в модуле).
Сама функция фильтра (поле func), которую нам ещё предстоит написать, может быть, в простейшем варианте, нечто подобное:
Функция показана здесь, главным образом, из-за обязательного вызова kfree_skb(). Он, в отличие от, казалось бы, близкого по смыслу dev_kfree_skb() в передающем канале, не уничтожает сокетный буфер, а только декрементирует его счётчик использования (поле users). При установке каждого дополнительного фильтра протокола вызовом dev_add_pack() это поле сокетных буферов будет инкрементировано. Вы можете установить несколько фильтров сетевого уровня (в одном и том же, или нескольких загружаемых модулях) и они будут срабатывать все в порядке обратному их установке, но каждый из них должен выполнить kfree_skb(). В противном случае вы будете иметь медленную, но неуклонную утечку памяти в сетевом стеке, так что её результат, как крах системы, обнаружится только через несколько часов непрерывной работы.
Это достаточно интересное и не очевидное место, настолько, что есть смысл отвлечься и посмотреть исходный код реализации kfree_skb() (файл net/core/skbuff.c):
Вызов kfree_skb() будет реально освобождать буфер сокета только в случае skb->users == 1, при всех остальных значениях он будет только декрементировать skb->users (счётчик использования).
Теперь у нас есть достаточно деталей для того, чтобы организовать работу виртуального интерфейса, но используя, на этот раз, сетевой уровень IP-стека.
Модуль виртуального интерфейса
Расширяем возможности
Теперь коротко, в два слова, о том, как сделать полновесный виртуальный интерфейс, работающий только со своим трафиком, и не нарушающий работу родительского интерфейса (то, что делает полная версия модуля в архиве). Для этого необходимо:
Последняя показанная команда (who) выполняется уже в сессии SSH, то есть на том самом удалённом хосте, к которому и фиксируется два независимых подключения из двух различных подсетей (последние две строки вывода), которые на самом деле представляют один хост, но с точки зрения различных его сетевых интерфейсов.
Дальнейшие уточнения
При подготовке и отладке примеров модулей, для уточнения деталей, активно использовалась вот эта (достаточно свежая) книга: Rami Rosen: «Linux Kernel Networking: Implementation and Theory», Apress, 650 pages, 2014, ISBN-13: 978-1-4302-6196-4. 
Автор любезно предоставил её для свободного скачивания ещё до выхода книги в продажу (2013-12-22). Скачать её можно на этой странице.
Все, кого интересуют вопросы, подобные обсуждавшимся в этой статье, смогут найти в этом издании много идей для дальнейшего развития техники собственного использования сетевых интерфейсов.
Архив кодов, упоминаемых в тексте, для экспериментов и дальнейшего развития, можно взять здесь или здесь.
СОДЕРЖАНИЕ
Уровень операционной системы
Ядро операционной системы обычно поддерживает таблицу виртуальных сетевых интерфейсов в памяти. Это может позволить системе хранить такую информацию и работать с ней независимо от задействованного физического интерфейса (или даже от того, является ли это прямым физическим интерфейсом или, например, туннелем или мостовым интерфейсом). Это также может позволить процессам в системе взаимодействовать в отношении сетевых подключений более детально, чем просто предполагать единый аморфный «Интернет» (с неизвестной емкостью или производительностью).
Помимо разрешения приложениям пользовательского пространства ссылаться на соединения абстрактного сетевого интерфейса, в некоторых системах структура виртуального интерфейса может позволить процессам лучше координировать совместное использование данного физического интерфейса (помимо поведения операционной системы по умолчанию) путем иерархического разделения его на абстрактные интерфейсы. с указанными ограничениями полосы пропускания и моделями очередей. Это может означать ограничение процесса, например, путем наследования ограниченной ветви такой иерархии, от которой он не может отклоняться.
Этот дополнительный уровень сетевой абстракции часто не нужен и может иметь незначительное снижение производительности. Однако можно также использовать такой уровень абстракции, чтобы обойти узкое место в производительности, даже чтобы обойти ядро в целях оптимизации.
Уровень приложения
Термин VIF также применяется, когда приложение виртуализирует или абстрагирует сетевые интерфейсы. Поскольку для большей части программного обеспечения нет необходимости заботиться о деталях сетевых интерфейсов и поскольку желаемая абстракция уже может быть доступна через операционную систему, такое использование встречается редко.
Сети для Самых Маленьких. Микровыпуск №5. FAQ по сетевым технологиям
Пока весь мир с замиранием ждёт 11-го выпуска СДСМ, посвящённого MPLS BGP L3VPN, я решил сделать вольный перевод неплохой статьи Джереми Стреча с Packetlife.net.
Это подборка небольших FAQ для новичков.
#На каком уровне 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-х нашему чёткому пониманию этой разницы пришёл конец — вырисовывались две важные тенденции. Во-первых, появились многоуровневые коммутаторы, которые не просто получили право передавать пакеты, основываясь на IP-адресах, но и участвовать в протоколах динамической маршрутизации, как самые настоящие маршрутизаторы. Во-вторых, операторы начали необратимый процесс миграции с технологий с коммутацией каналов на модерновый Ethernet, предоставляющий высокие скорости за низкую плату. Сегодня совершенно в порядке вещей, если маршрутизатор имеет только Ethernet-интерфейсы, как будто бы он коммутатор.
Где лежит граница между маршрутизатором и многоуровневым коммутатором? Существует ли ещё эта граница?
Фактическая разница между ними сводится к следующим нескольким пунктам:
#Какая разница между 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.1q) и 4 байта поля FSC. Итоговый же размер кадра 1518 байтов (1522 в случае 802.1q). Многие узлы сейчас поддерживают джамбофреймы (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?
Возьмём для примера случай, когда вы с компьютера с приватным адресом 192.168.0.10 хотите зайти по telnet на адрес в Интернете 94.142.241.111. Из пула NAT вам выделен IP-адрес 192.0.2.10.
Вот так будет выглядеть таблица трансляций:
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 мы могли бы указывать IP-адрес Next-Hop, который менялся бы также на каждом узле.
В целом это верно, но такой подход ломает идеологию стека протоколов, предполагающую независимость уровней друг от друга. Сейчас, например, легко можно выкинуть Ethernet и вместо него использовать xDSL или PON или, прости Лейбниц, Frame Relay — сложности лишь административные и финансовые. Также, поверх Ethernet технически вы можете пустить собственный сетевой протокол IPЧ — и это всё будет работать с минимальными изменениями (добавить новый 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 уже не поможет — в этом случае придётся расширять канал.
Переводчик позволил себе некоторые вольности в русскоязычных терминах, которые позволят, как ему кажется, лучше понять смысл.