svi интерфейс что это
Svi интерфейс что это
Существует два способа организации L3 звязи между двумя L3 коммутаторами. Первый способ состоит в создании VLAN для L3 связности вместе с SVI интерфейсами (Interface VLAN) на обоих устройствах. Конфигурация выглядит примерно следующим образом:
Другим способом является настройка порта коммутатора в качестве L3 (Routed) порта и назначение на него ip адреса:
Оба решения являются верными. Разница между ними заключается только во времени сходимости сети в случае отказа линии связи.
Согласно рекомендаций компании Cisco Multilayer Campus Architecture and Design Principles (Слайд 24) врямя сходимости физического L3 интерфейса порядка 8 msec, в случае SVI ожидаемое время сходимости находится между 150 и 200 msec. Такие расхождения являются достаточнго существенными в случае передачи чувствительного к задержкам трафика. Давайте проведем эксперимент, чтобы проверить эти значения.
Тестирование будет проводится с использованием коммутатора Catalyst 3560-24, подключенного к Catalyst 3550-24. Все интерфейсы, кроме тестируемого будут выключены. Отказ линии связи будет симулирован путем отключения порта на коммутаторе 3550. При помощи команды debug ip routing будет включено логирование изменений таблицы маршрутизации. Задержка будет установлена путем подсчета разницы во времени между событиями. Для достижения необходимой точности, аргумент msec применен к командам timestamp service.
Сконфигурируем устройства и вычислим время между отключением линии связи и изменением в таблице паршрутизации. Проведем тест три раза и вычислим среднее время сходимости.
Тестирование SVI
Ниже приведен лог теста SVI. Нас интересует разница во времени между отключением line protocol на интерфейсе и удалением маршрута из таблицы маршрутизации.
Результаты:
Средняя задержка: 9 msec
Тестирование Routed Interface
Результаты
Среднее время: 998 msec
Что это значит?
Наши результаты противоположны результатам Cisco. Задержка SVI порядка 9 msec, задержка routed port порядка секунды.
Проводим тест еще раз — результаты сильно меняются:
После изменения carrier delay, физический интерфейс отключается моментально после исчезновения несущей и таблица маршрутизации обновляется моментально. Через миллисекунду отключается line protocol.
Изменение carrier-delay для SVI не будет иметь эффекта.
Виртуальные локальные сети
7.5. Маршрутизация между виртуальными локальными сетями
Такая схема не является оптимальной, поскольку требует большого количества ( по числу VLAN ) интерфейсов и соединений между маршрутизатором и коммутатором.
При транковом соединении коммутатора и маршрутизатора три физических канала между ними ( рис. 7.12) заменяются одним транковым каналом ( рис. 7.13). Такая схема организации маршрутизации получила название «router-on-a stick«.
Конфигурирование коммутатора будет следующим:
По команде showing f0/10 switchport можно посмотреть состояние интерфейса:
Результат конфигурирования проверяется по команде show ip route :
Из недостатков виртуальных локальных сетей с маршрутизацией «router-on-astick» можно отметить плохую масштабируемость при количестве VLAN больше 50. Поскольку на физическом интерфейсе сформировано несколько субинтерфейсов, то будет конкуренция трафика разных сетей VLAN через транковый канал.
Многоуровневые коммутаторы характеризуются более высокой скоростью обработки пакетов по сравнению с маршрутизаторами, поэтому широко используются в сетях различного назначения. Однако их стоимость высока по сравнению с решением «router-on-a stick«.
Коммутаторы серии Catalyst 2960 реализуют функции только статической маршрутизации при ограниченном количестве маршрутов. Более производительные коммутаторы Catalyst 3560 и Catalyst 4500 поддерживают как статическую, так и динамическую маршрутизацию. Они используют по умолчанию интерфейсы 2-го уровня. Высокопроизводительные коммутаторы Catalyst6500 поддерживают практически все функции маршрутизаторов, используя по умолчанию интерфейсы 3-го уровня.
Использование многоуровневых коммутаторов повышает скорость маршрутизации, поскольку трафик 2-го и 3-го уровня обрабатывается внутри коммутатора и нет внешних соединений между коммутатором и маршрутизатором. Следовательно, нет задержек на интерфейсах.
Перечисленные коммутаторы могут поддерживать следующие интерфейсы 3-го уровня:
Маршрутизируемые порты, которые являются аналогом интерфейсов маршрутизатора, обычно устанавливаются между коммутаторами уровня распределения и ядра. Протокол STP на них не работает, и на них нельзя конфигурировать субинтерфейсы. На коммутаторах Catalyst 2960, которые используются, как правило, на уровне доступа, маршрутизируемые порты не поддерживаются.
При исходной конфигурации на коммутаторе настроен шаблон по умолчанию. Для реализации статической маршрутизации необходимо изменить шаблон по следующей команде:
Текущий шаблон можно посмотреть по команде:
Маршрутизация на коммутаторе включается по команде:
После этого можно сконфигурировать статический маршрут или маршрут по умолчанию.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора 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 уровня.
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Национальная библиотека им. Н. Э. Баумана
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:
Сети для Самых Маленьких. Микровыпуск №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 уже не поможет — в этом случае придётся расширять канал.
Переводчик позволил себе некоторые вольности в русскоязычных терминах, которые позволят, как ему кажется, лучше понять смысл.