оверлейные сети что это

Оверлейная сеть

Оверлейная сеть (от англ. Overlay Network ) — общий случай логической сети, создаваемой поверх другой сети. Узлы оверлейной сети могут быть связаны либо физическим соединением, либо логическим, для которого в основной сети существуют один или несколько соответствующих маршрутов из физических соединений. Примерами оверлеев являются сети VPN и одноранговые сети, которые работают на основе интернета и представляют из себя «надстройки» над классическими сетевыми протоколами, предоставляя широкие возможности, изначально не предусмотренные разработчиками основных протоколов. Коммутируемый доступ в интернет фактически осуществляется через оверлей (например, по протоколу PPP), который работает «поверх» обычной телефонной сети.

Применение оверлейных сетей

Оверлеи могут применяться в следующих случаях:

Основное преимущество оверлейных сетей заключается в том, что они позволяют разрабатывать и эксплуатировать новые крупномасштабные распределённые сервисы без внесения каких-либо изменений в основные протоколы сети. Распространённым недостатком оверлеев являются повышенные затраты при передаче информации из-за дополнительного уровня обработки пакетов или неоптимальных маршрутов.

См. также

Ссылки

Полезное

Смотреть что такое «Оверлейная сеть» в других словарях:

Виртуальная частная сеть — VPN (англ. Virtual Private Network виртуальная частная сеть) логическая сеть, создаваемая поверх другой сети, например Интернет. Несмотря на то, что коммуникации осуществляются по публичным сетям с использованием небезопасных протоколов, за счёт… … Википедия

Одноранговая сеть — Запрос «P2P» перенаправляется сюда; см. также другие значения. Одноранговая, децентрализованная или пиринговая (от англ. peer to peer, P2P равный к равному) сеть это оверлейная компьютерная сеть, основанная на равноправии участников. В такой … Википедия

I2P — Проверить нейтральность. На странице обсуждения должны быть подробности … Википедия

VPN — технология VPN (англ. Virtual Private Network&# … Википедия

Virtual Private Network — VPN (англ. Virtual Private Network виртуальная частная сеть) логическая сеть, создаваемая поверх другой сети, например Интернет. Несмотря на то, что коммуникации осуществляются по публичным сетям с использованием небезопасных протоколов, за счёт… … Википедия

Kademlia — это реализация распределённой хеш таблицы для одноранговых компьютерных сетей, разработанная Петром Маймунковым и David Mazières. Протокол Kademlia определяет структуру сети, регулирующей связь между узлами, и способ обмена информацией в ней.… … Википедия

DHT — (англ. Distributed Hash Table «распределённая хеш таблица») это класс децентрализованных распределённых систем, которые обеспечивают поисковый сервис, похожий по принципу работы на таблицу хешей, и имеют структуру: (имя, значение),… … Википедия

YaCy — YaCy … Википедия

Распределённая хеш-таблица — Стиль этой статьи неэнциклопедичен или нарушает нормы русского языка. Статью следует исправить согласно стилистическим правилам Википедии. DHT (англ. Distributed Hash Table «распределённая хеш … Википедия

Perfect Dark — Тип Клиент анонимных файлообменных сетей Разработчик Kaichō ( Председатель (яп … Википедия

Источник

Будущее анонимности: Какое оно?

То обладателя форума который стал не угодный чиновнику строительной компании решили засудить на 1.7 миллиона долларов.

Недавно была хорошая попытка проверку волнения публики ошибочная блокировка vk.com

Таких случаев море, как в России так и, например в Латвии, когда был арестован учитель за публикацию в общий доступ книги для своих учеников.

Я не буду рассуждать почему это происходит, хорошая ли или плохая власть, это бессмысленно, все уже давно понимают, что сейчас идет эффект вареной лягушки, я лишь попытаюсь рассказать 2 возможных пути развития свободного направления интернета.

Из-за того, что не все знают значение того или иного программного обеспечения или технологии, я постараюсь приложить ссылки

Какие пути возможны?

Когда интернет стал не анонимным, многие люди начали искать выход, который бы позволил сохранить тайну личности, переписки и свои взгляды, которые бы не смогли быть подвержены цензуре.

Но что бы найти выход, надо знать первопричину и способы блокировок и оперативного розыска неугодных.

Карательная система во всем мире действует с помощью 2 принципов
1 — Закрытие ресурса целиком (возможны варианты, от блокировки IP и домена, до физического изъятия сервера)
2 — Показательная порка пользователей, который вызывает эффект убитого таракана

Объединяет данные способы одно — не анонимность протокола TCP/IP

Таким образом мы получаем 2 условия которые должны соблюдаться для решения проблем анонимности:
1 — Децентрализация сети, ликвидация серверной части — перекладывание ответственности на пользователей
2 — Стирание грани между личностью и IP адресом

Достичь желаемого можно с помощью 3 методов

1) Свой интернет — Проект Netsukuku
2) Децентрализация (DHT, BitTorrent, Bitcoin, Bitmessage)
3) Оверлейные системы (I2P, Tor, Freenet, Perfect Dark)

У каждого из этих методов есть свои преимущества и недостатки, если рассматривать данную проблему в рамках России, то становится ясно, что первый способ нам не подходит, для организации wi-fi mesh outdoor сети требуются разрешения, а мы с вами пытаемся избежать лишнего внимания,

Таким образом все сводится к выбору между оверлейными сетями и децентрализацией.

Оверлейные сети

Оверлейные сети — такие сети, которые работают поверх протокола TCP/IP создавая «свой собственный интернет», вместо IP адресов там обычно используются связка приватных и публичных ключей, в случае с I2P база всех роутеров так же децентрализована с помощью (DHT).

Но у оверлейных сетей есть и недостатки — низкая скорость работы и не рациональный расход трафика.
Один минус следует из другого, из-за того, что оверлейные сети работают по принципу многоуровневых прокси с шифрованием в любой точке, то лишний трафик в сети может составлять до 90%, из-за того, что данные передаются не напрямую — происходит замедление работы сети.

С другой стороны — простота использования текущего ПО — все что сейчас нам привычно — сайтовые движки, CMS — все это может работать практически без изменения в оверлейных сетях.

Децентрализация

В случае с децентрализацией, мы не имеет таких минусов которые есть у оверлейных сетей, из-за того, что ваши данные передаются всем участниках сети единовременно (Bitcoin) или по запросу (Torrent).

Использование децентрализованных решений позволяет полностью ликвидировать серверную часть, такое произошло в сетях Torrent, DHT, Bitcoin, Bitmessage. Таким образом что бы «убить» сеть — недостаточно придти в серверную и забрать сервер, придется либо блокировать сеть на сетевом уровне с помощью DPI либо задержать ВСЕХ участников этой сети.

Если последнее не реально, то с DPI все сложнее, самый популярный метод обхода DPI (если можно это так назвать) заключается в маскировке трафика под ssl / torrent трафик, либо под любой другой.

Если DPI не может определить маркер трафика то он и не может заблокировать только его, что соответственно замечательно.

PS Да, DPI умеет определять трафик I2p \ торрент \ шифрованный торрент \ bitcoin \ DHT

Но не все так плохо, в данный момент, многие проекты работают над изменчивостью протокола и маскировкой его под другой, что в дальнейшей перспективе позволит уходить от взора DPI.

Так каков же выход? что же лучше?
Самым лучшим методом — будет объединение 3 технологий сразу — оверлейности, маскировки и шифрования.
Единственный проект который реализовал данный подход — Osiris Server less portal (Децентрализованный форум работает через модифицированный DHT)

К сожалению, проект Osiris мертв, задумка была хорошая, но на реализацию видно не хватило времени у разработчика.

Источник

Сетевые оверлейные технологии для ЦОД. Часть 1

Последнее время в материалах различных конференций по сетевым технологиям, обзорах, статьях стали всё чаще встречаться такие термины, как TRILL, FabricPath, VXLAN, OTV и LISP, особенно в разрезе построения ЦОДов. Ловишь себя на мысли, а что же это такое? Конечно, многие из них, как звёзды, достаточно далеки от нашей повседневной реальности. Но все-таки, наверное, было бы не плохо понять, хотя бы в общих чертах, а что же это всё значит. Более того, вроде как, все они меняют привычные принципы работы сети: коммутация по каким-то меткам, маршрутизация какая-то не такая, да и адресация хоста совсем уже не та. В общем, предлагаю попробовать со всем этим разобраться.

Статья будет разбита на три части. В первой части рассмотрим, что такое оверлейные технологии. Разберёмся с предпосылками появления новых оверлейных технологий для ЦОД, а также их общей классификацией. Остальные части будут посвящены уже непосредственно технологиям TRILL, FabricPath, VXLAN, OTV и LISP.

Итак, все эти технологии объединяются под общим названием — оверлейные сетевые технологи. Как мы знаем, оверлейные технологи позволяют нам получить новую логику работы сети, используя в качестве основы стандартные протоколы. Т.е. это надстройка, обеспечивающая нас новыми сервисами. Обычно оверлейные технологии используют дополнительные заголовки, которые присоединяются к исходному пакету. Это позволяет абстрагироваться от заголовков изначального пакета и обеспечить дальнейшую передачу по сети на основе оверлейного заголовка.

Примером такой технологии может является VPN (в частности IPSec в туннельном режиме). VPN позволяет нам проложить туннель поверх сети. Далее внутри этого туннеля мы можем передавать любые данные. Транспортная сеть будет маршрутизировать такие данные только на основании заголовка VPN. Таким образом, с помощью технологии VPN мы как бы меняем стандартные правила маршрутизации трафика, обеспечивая передачу нужных нам данных поверх сети. Примеров оверлейных технологий огромное множество. Но давайте остановимся на тех, которые появились и используются в первую очередь для построения ЦОДов.

В цикле данных статей хотелось бы обзорно разобрать предпосылки появления новых оверлейных технологий для ЦОД, попытаться их классифицировать, отметив основные моменты по наиболее распространённым и актуальным на сегодня технологиям. В основном речь пойдёт про технологии, которые поддерживаются оборудованием Cisco, так как мне именно с ним приходится чаще всего иметь дело. Безусловно, у других производителей сетевого оборудования есть схожие технологии, однако их разбор останется вне рамок нашего обзора.

Откуда же возникла потребность в каких-то новых оверлейных технологиях? Ещё недавно трёхуровневая архитектура построения сети обычно не вызывала каких-то вопросов. Количество доступных VLAN’ов равное 4096, воспринималось как достаточно большое число. Стандартные правила коммутации и маршрутизации трафика являлись незыблемыми постулатами, на которых держится Земля сеть. Однако, бурное развитие «облаков» автоматически повлекло за собой такое же активное развитие ЦОДов, где эти облака размещаются. ЦОДы увеличились в размере, стали более ёмкими, возникла необходимость связи между ними. И конечно же, появились новые требования к их работе, так сказать «Citius, Altius, Fortius!» (быстрее, выше, сильнее).

Все мы давно привыкли к традиционной трёхуровневой архитектуре построения сетей: уровень доступа (access), уровень агрегации/распределения (aggregation) и ядро (core). Между ядром сети и уровнем распределения обычно используется маршрутизация (L3), между уровнем доступа и распределения коммутация (L2) или маршрутизация (L3). В ряде случаев ядро сети и уровень распределения могут быть совмещены.

Однако, появление и активное использование виртуализации, а также рост ЦОДов (в размере) выявил целый ряд новых требований к сети:

В частности, требование прозрачной мобильности виртуальных машин заставляет нас «растянуть» широковещательный домен между всеми коммутаторами уровня доступа. А это влечёт за собой дополнительные издержки на его обслуживание. Потребуется использовать протокол STP. А значит часть каналов будет заблокирована или недостаточно утилизирована, не всегда будет оптимальная передача трафика. Также имеем повышенную нагрузку на MAC-таблицы коммутационного оборудования и проблемы с флудингом (широковещательного трафика и пр.).

Модель взаимодействия «все со всеми» также выявляет определённые проблемы: наиболее загруженное место сети – её ядро, плюс мы имеем большое количество хопов при передаче трафика между серверами, подключённые через различные коммутаторы уровня агрегации. А хотелось бы, чтобы количество хопов равнялось одному, при этом все каналы равномерно утилизировались.

Идеально было бы, например, объединить в себе плюсы маршрутизации и коммутации, получив возможность:

В обоих случаях к исходному пакету добавляется специализированный заголовок. Дальнейшая передача пакета происходит уже с использованием нового заголовка. В случае Network-based процесс инкапсуляции и деинкапсуляции происходит на коммутационном оборудовании. Оконечный хост даже не догадывается, что пакет передаётся каким-то специальным образом. В случае Host-based добавление специализированного заголовка выполняет сам хост. При этом коммутационное оборудование теперь ничего не подозревается об использовании оверлейных технологий.

Особенности реализации Network-based и Host-based оверлейных технологий

Примерами оверлейных технологий Network-based являются: TRILL, FabricPath, SPB, OTV, LISP, один из вариантов реализации VXLAN и др. Примеры оверлейных технологий Host-based: VXLAN, NvGRE, STT и др.

Кстати сказать, ещё одним «заказчиком» оверлейных технологий стали программно-определяемые сети (Software-defined Networking — SDN). Так как одна из задач SDN – обеспечение достаточно гибких правил работы сети, добиться этого без новых технологий тяжело. Оверлейные технологии отлично подходят для обеспечения передачи дополнительной информации для каждого пакета (например, для обеспечения функций безопасности или сегментации), быстрой организации связи между хостами (например, организация L2 соединения), обеспечение работы различных клиентских сетевых технологий (их туннелирование) внутри транспортной сети ЦОД и пр. В частности, SDN от компании Cisco (Application Centric Infrastructure — ACI) использует как базовую технологию VXLAN.

Безусловно, нет одной самой лучшей оверлейной технологии, которая бы полностью решала все проблемы, стоящие при построении ЦОД. Более того существуют целые классы таких технологий, реализующие какую-то одну задачу, например, организацию связи ЦОД между собой. Поэтому их зачастую используют совместно друг с другом.

Прежде чем двигаться дальше, хотелось бы отметить, что вместе с новыми оверлейными технологиями, появились и новые архитектуры построения ЦОДов. Например, стала использоваться архитектура Clos, её производная Fat-Tree и пр. Считается, что данные архитектуры более адаптированы к реалиям современных ЦОДов.

Зачем я упомянул о них? Ведь речь у нас про оверлейные технологии. Ответ прост. Некоторые оверлейные технологии в своей работе для получения максимального эффекта опираются на новые архитектуры. В частности, TRILL/FabricPath лучше всего работают поверх Clos сети. Данная архитектура предполагает наличие большого количества связей между устройствами и выполнение простого правила: коммутаторы определённого уровня соединяется лишь с коммутаторами вышестоящего уровня и нижестоящего, не имея связи между собой. На рисунке приведён пример простейшей двух уровневой Clos сети.

Такая архитектура достаточно просто расширяется. Она позволяет получить хорошую суммарную пропускную способность. В ней мы имеем большое количество одинаковых маршрутов между устройствами уровня доступа (Leaf). Также существенно уменьшается влияние отказов коммутационного оборудования на общую производительность сети, так как нет какого-то выраженного центра.

На этом, думаю, введение пора завершать. В следующих статьях мы перейдём уже непосредственно к интересующим нас технологиям, а именно TRILL, FabricPath, VXLAN, OTV и LISP. А в конце подведём некоторые итоги.

Источник

Сетевые оверлейные технологии для ЦОД. Часть 2

Всех приветствую! В предыдущем посте мы постарались разобраться с предпосылками появления новых оверлейных технологий для ЦОД, а также их общей классификацией. В данной части статьи хотелось бы остановиться чуть более подробно на TRILL, FabricPath и VXLAN.

TRILL и FabricPath

TRILL (Transparent Interconnection of Lots of Links) — технология, работающая на канальном уровне модели OSI и обеспечивающая передачу пакетов внутри ЦОД по уникальным идентификаторам. Под словом «пакет» на канальном уровне мы, конечно же, подразумеваем кадр.

Порты на устройствах в сети (обычно это коммутаторы) переключаются в режим работы TRILL. Эти устройства будем называть – коммутаторы TRILL. В данном режиме коммутация пакетов между такими портами внутри устройства происходит уже не классическим образом (как мы это привыкли видеть в Ethernet), а по-новому – по идентификаторам.

Перед тем как обычный пакет попадёт на порт, подключённый к сети TRILL, для него определяется идентификатор коммутатора TRILL, за которым находится хост получателя. Т.е. определяется, куда нужно передать пакет внутри сети TRILL. После этого к нашему пакету добавляется новый заголовок и пакет передаётся по этому заголовку между коммутаторами TRILL, используя кратчайший путь. Таким образом, в сети TRILL коммутация осуществляется по заранее определённым маршрутам. Т.е. можно говорить о маршрутизации на канальном уровне. Попав на нужный коммутатор TRILL, заголовок убирается, и дальнейшая обработка пакета происходит по классике.

Для того чтобы коммутаторы TRILL знали, как добраться до того или иного коммутатора в сети TRILL, они используют протокол динамической маршрутизации. Но вместо привычных нам префиксов (адресов подсетей), обмен осуществляется собственными уникальными идентификаторами. Это позволяет получить дерево кратчайших путей к каждому из коммутаторов TRILL.

Казалось бы, чудо, а не протокол. Но, во-первых, за всё нужно платить – оборудование, поддерживающее TRILL, относительное не дешевое. Во-вторых, не все проблемы L2 данная технология позволяет решить. Например, вопрос флудинга остаётся всё ещё актуальным.

Различные производители сетевого оборудования имеют свои реализации TRILL. В частности, компания Cisco реализовала концепцию TRILL в своей технологии FabricPath. Стоит отметить, что хоть FabricPath и является реализацией стандарта TRILL IETF, в их работе есть определённые отличия. О некоторых из них я приведу информацию ниже.

Как я отметил ранее, TRILL и FabricPath в своей работе для построения кратчайших маршрутов используют протокол динамической маршрутизации. Для этой задачи был выбран протокол IS-IS. Данный протокол, разработанный в далёких 80-х, можно сказать, обрёл вторую жизнь. Почему IS-IS? Он работает поверх канального уровня.

Поддерживает передачу любых данных внутри своих сообщений. Другими словами, в рамках пакетов IS-IS мы можем передавать, например, какие-то имена, метки или любую другую информацию. Т.е. IS-IS очень просто адаптируется для обеспечения работы других сетевых протоколов. Расчёт кратчайшего маршрута происходит по алгоритму Дейкстры (так же как в протоколе OSPF).

Предлагаю чуточку подробнее остановится на вопросе заполнения MAC-таблицы, где содержатся соответствия MAC-адресов хостов и идентификаторов устройств TRILL/FabricPath.

Для технологии FabricPath этот процесс выглядит следующим образом. После «включения» сети, данная таблица на всех коммутаторах пуста. Её заполнение на каждом устройстве происходит по мере прохождения через него пакетов. MAC-адреса локальных устройств запоминаются также, как в обычной сети Ethernet (когда они попадают на порт коммутатора). Для пакетов, пришедших со стороны сети FabricPath, запись вида «MAC-адрес — идентификатор устройства» добавляется только в том случае, если коммутатор уже знает о получателе данного пакета (т.е. у него есть запись о MAC адресе получателя). Если данных о получателе нет, коммутатор ничего не запоминает. Пока нужная запись «MAC-адрес — идентификатор устройства» отсутствует, коммутатор рассылает такие пакеты на все устройства в сети FabricPath.

Такой механизм позволяет минимизировать MAC-таблицу, занося данные только о тех MAC-адресах удалённых хостов (имеются ввиду хосты, которые находятся за другими устройствами FabricPath), которые обмениваются данными с локальными. В такой схеме адреса хостов, полученные в широковещательных пакетах (broadcast), в MAC-таблицу никогда не заносятся. Конечно, это приводит к росту флудинга в начале взаимодействия хостов. Однако экономятся ресурсы коммутаторов в плане MAC-таблицы.

Для TRILL (IETF) описаны несколько вариантов заполнения MAC-таблицы. Самый простой – схема работы обычной сети Ethernet. Как только пришёл пакет, мы заносим соответствие «MAC-адрес – порт» для локальных хостов и «MAC-адрес — идентификатор устройства» для пакетов, пришедших со стороны сети TRILL. Также есть вариант обмена данными о MAC-адресах через специализированный протокол End Station Address Distribution Information (ESADI). В этом случае каждый коммутатор TRILL сообщает всем остальным о MAC-адресах локальных хостов.

Как было отмечено ранее, хоть TRILL (IETF) и FabricPath (Cisco) имеют общие схемы работы, при этом присутствуют существенные различия. Отличаются идентификаторы устройств, заголовки протоколов, схемы «изучения» MAC адресов, а также процесс передачи пакетов внутри сети TRILL/FabricPath.

Где же использовать данные технологии? TRILL и FabricPath работают на канальном уровне (L2). Поэтому, в частности, FabricPath рекомендуется вендором именно для построения сети внутри ЦОД. Технология FabricPath поддерживается на коммутаторах семейства Cisco Nexus (5500, 6000, 7000).

VXLAN (Virtual Extensible LAN) ещё одна оверлейная технология, в первую очередь рассчитанная на мир виртуализации. Над её разработкой трудятся целый ряд компаний (Cisco, Vmware, Citrix и пр.).
Посмотрев на название, сразу приходят мысли, что это что-то близкое к привычным нам VLAN’ам. Так оно и есть. VXLAN, на мой взгляд, можно сравнить с продвинутым VLAN. По факту это его замена. Что же там продвинутого? VXLAN поддерживает до 16 млн. подсетей, против 4096 для VLAN (речь идёт про уникальные идентификаторы). Также VXLAN позволяет обеспечить связность распределённых L2-сегментов через IP-сеть. Как это реализовано и, что это нам даёт, рассмотрим далее.

Работу VXLAN можно частично сравнить с ранее описанными технологиями TRILL/FabricPath. Передача пакета при его коммутации разбивается на этапы. После того как пакет попал на устройство, где запущена технологий VXLAN (далее устройство VXLAN), для данного пакета определяется удалённое устройство VXLAN, через которое подключен получатель. Пакету добавляется заголовок, и он пересылается сначала на интересующее нас устройство VXLAN, а далее уже на хост получателя. На этом сходство заканчивается. VXLAN инкапсулирует изначальный Ethernet-пакет в обычную UDP дейтаграмму. А значит при передаче пакетов между устройствами VXLAN, обработка такого пакета происходит по стандартным правилам маршрутизации и коммутации. Т.е. транспортная сеть (сеть между устройствами VXLAN) может быть полностью маршрутизируемой, и поддержка в ней технологии VXLAN не требуется. А значит нет петель (нет необходимости использоваться STP), можно использовать одновременную передачу пакетов по нескольких путям и т.д. Получаем все блага полноценной маршрутизации для пакетов, которые должны коммутироваться.

Инкапсуляция в UDP позволяет использовать VXLAN в том числе в сети интернет. С помощью VXLAN мы можем соединить распределённые L2-сегменты между двумя и более ЦОДами.

Очень важный момент, на чём мы запускаем VXLAN. Так как изначально VXLAN был рассчитан на виртуализацию, данная технология может быть настроена на виртуальном коммутаторе (Host-based) внутри сервера. Это очень здорово, так как в этом случае к «железкам» в сети вообще нет никаких требований. Также VXLAN может быть запущен на коммутационном оборудовании (Network-based). А в купе с тем, что VXLAN мы можем использовать как внутри ЦОДа, так и между ними, получаем идеальную технологию. Но, как обычно, дьявол кроется в деталях.

В целом идея работы VXLAN достаточно проста. Получили пакет, посмотрели в таблицу MAC-адресов, нашли куда переслать, инкапсулировали в UDP и передали. Уверен, что у многих уже возник вопрос, а как же заполняется таблица MAC-адресов? Как каждое устройство VXLAN узнаёт, где находится нужный MAC-адрес?

И вот тут появляются нюансы работы VXLAN. Самый первый вариант реализации – это использование multicast пакетов. Вспоминаем, что multicast даёт нам возможность передать пакет по сети сразу на несколько получателей (объединённых группу). В VXLAN это решили использовать. Все устройства VXLAN сообщают сети о том, что они хотят получать multicast трафик, адресованный определённой multicast-группе (это делает посредствам протокола IGMP). Далее любое устройство VXLAN, чтобы послать пакет на другие устройства VXLAN, в качестве адреса получателя указывает адрес multicast-групп. А дальше всё просто. Пока таблица MAC-адресов пуста, пакеты просто передаются сразу всем устройствам VXLAN (используем multicast). Получив такой пакет, устройство VXLAN заносит себе в таблицу соответствие MAC-адреса отправителя и IP-адреса устройства VXLAN, передавшего данный пакет. Таким образом, через некоторое время все устройства VXLAN будут знать, где находится тот или иной MAC-адрес. Соответственно, пакеты, адресованные уже на известный MAC-адрес передаются в виде unicast трафика.

Ах незадача, ведь вся сеть должна поддерживать multicast. Более того, если устройства VXLAN находятся в разных подсетях, необходимо поддерживать маршрутизацию multicast трафика. Вот мы и пришли к первой заковырке. Если для внутренней сети мы это можем реализовать, то для сети интернет сложновато. Какой может быть выход? Отказаться от multicast и использовать только unicast трафик.

Если будет использоваться только unicast трафик, как мы сможем заполнить таблицу MAC-адресов? Самый логичный вариант, должна быть какая-то база, где будут храниться данные о всех VXLAN устройствах (их IP-адреса). В этом случае устройства VXLAN смогут работать по тому же принципу, что и в режиме multicast. Единственно, когда нужно будет отправить пакет всем устройствам (например, когда нет ещё данных о MAC-адресе) придётся заглянуть в таблицу и отправить не один multicast-пакет, а несколько unicast-пактов (на каждое VXLAN устройство). Так и было сделано.

Основной минус такой реализации — повышенная нагрузка на устройство VXLAN в случае отправки broadcast, multicast и unknown unicast трафика (т.е. когда нет точного получателя трафика, или мы ещё не знаем, где находится MAC-адрес). Если у нас в сети, например, 20 устройств VXLAN, то нужно будет из одного такого пакета сгенерировать 20 одинаковых VXLAN пакетов и разослать их по сети. Поэтому режим unicast дополнили надстройкой, при которой в базу заносится дополнительно информация о MAC-адресах. Что это нам даёт? Теперь, устройство VXLAN может посмотреть в такую базу и сразу определить, где находится нужный MAC-адрес. Уже не требуется рассылать трафик сразу на все устройства VXLAN.

И снова возник вопрос. Ок, всё здорово, но кто и как будет заполнять базу? Вот тут-то и появляются различные вендорные реализации. Рассмотрим на примере того, что предлагает Cisco.

Первая реализация VXLAN в режиме unicast доступна на виртуальном коммутаторе Cisco Nexus 1000V. В этом случае управляющий модуль (Virtual Supervisor Module — VSM) собирает со всех виртуальных коммутаторов Cisco информацию о MAC-адресах, находящимся за ними. Таким образом, формируется база соответствий устройств VXLAN (виртуальных коммутаторов) и MAC-адресов.

Второй вариант реализации VXLAN в режиме unicast доступен уже на «железе». В этом режиме устройства VXLAN через специализированный протокол обмениваются между собой данными о MAC-адресах. Т.е. база соответствий в этом случае будет хранится отдельно на каждом устройстве VXLAN. В качестве такого протокола был выбран Multiprotocol Border Gateway Protocol Ethernet Virtual Private Network (MP-BGP EVPN). Это расширение протокола BGP, которое позволяет нам в сообщениях BGP передавать нужные нам данные: MAC-адрес хоста, его IP-адрес и IP-адрес VXLAN устройства, через который данный хост доступен.

Я думаю, вы уже обратили внимание на то, что вместе с MAC-адресом передаётся ещё и IP-адрес хоста. Как мы отметили ранее, это позволяет существенно уменьшить unknown unicast трафик. Также оптимизируется работа протокола ARP (чтобы лишний раз не гонять между VXLAN устройствами ARP трафик).

Последний вариант (он правда чуточку вырожденный) – это статическое указание адреса удалённого VXLAN устройства. Причём указать можно всего одно такое устройство, т.е. сделать связь точка-точка.

Поддержка режимов VXLAN на оборудовании Cisco:

Локальные итоги

Как небольшое резюме хотел бы ещё раз отметить основные моменты. TRILL и FabricPath работают на канальном уровне модели OSI. Все оборудование в сети начинает по-новому обрабатывать пакеты. Используется маршрутизация на канальном уровне. Эти технологии рекомендуется использовать для построения сети внутри ЦОД. Технология VXLAN инкапсулирует Ethernet-пакеты в дейтаграммы UDP. Тем самым данная технология позволяет оставить транспортную сеть без изменения, в том числе использовать сеть интернет. Между VXLAN устройствами строятся виртуальные туннели, по которым бегают пакеты между распределёнными сегментами одной L2 сети. VXLAN можно использовать как внутри, так и между ЦОДами.

На этом общее рассмотрение TRILL, FabricPath и VXLAN завершено. Хотелось бы отметить, что для упрощения понимания часть моментов были опущены. В частности, в таблицах MAC-адресов я сознательно опустил поле принадлежности MAC адреса/порта коммутатора тому или иному VLAN (VXLAN). Также не рассмотрел вопросы стыка обычной сети и сети VXLAN, вопросы отказоустойчивого подключения к сети FabricPath (vPC+ и HSRP) и т.д. Всё это нужно, как мне кажется, для более глубокого погружения. А мы тут всё-таки плаваем на небольших глубинах. Подчеркиваю, плаваем на глубинах, а не на поверхности.

В следующей статье мы рассмотрим технологии OTV и LISP, а также подведём общие итоги.

Источник