Услуга l2 vpn что такое
L2VPN
Многие задавались вопросом, что такое L2-VPN, как он работает и зачем он нужен. L2-VPN это сервис виртуальной частной сети (англ. Virtual Private Network — виртуальная частная сеть), предоставляемый операторами связи по типу точка-точка. Сеть провайдера для клиента в данной услуге абсолютно прозрачна.
Где это может понадобиться?
Допустим, вы частный предприниматель, у вас есть офис в г. Урюпинск и г. Воронеж. Вы хотите объединить 2 сети в 1 большую локальную сеть. С точки зрения вас (клиента) данная услуга будет выглядеть так, как показано на рисунке 1.
Т.е. как подключение к одному большому L2-коммутатору. В случае необходимости вы можете самостоятельно устанавливать в своем vpn канале дополнительные сервисы сетевой защиты, шифрования, аутентификации, например IPSec-туннель и т.д.
Здесь будет немного сложнее. Заявив ему, что вы хотите данную услугу, выбранный вами провайдер подключит оба офиса в свои ближайшие коммутаторы, произведет манипуляции на оборудовании, и вы получите заветную услугу. Сеть провайдера может быть огромна. Чтобы вашим пакетикам из Урюпинска дойти до Воронежа и обратно, им придется преодолеть нцать коммутаторов, несколько роутеров и много-много километров пути. Если схематично, то можно представить так, как показано на рисунке 2.
Данную услугу провайдеры предоставляют на основе своей сети IP/MPLS. Стоимость данной услуги, провайдер рассчитывает исходя от расстояния, емкости канала, совокупных затрат на содержание и эксплуатацию оборудования, амортизационных отчислений и тд. Однако, при всем при этом цена является в несколько раз завышена для клиента.
Заключение
Данная услуга является одной из самых популярных среди клиентов провайдеров Она очень проста и не требует настроек на оборудовании клиента.
Преимущества:
Однако есть и недостатки. Т.к. услуга является L2, то операторам связи очень сложно отслеживать проблемы на данной услуге и практически всегда они узнают о проблеме от клиента. По сути, клиент сам берет на себя всю диагностику и работу с провайдером, поэтому если существуют какие-то проблемы то их решение очень затягивается.
Существует и более интересная услуга, позволяющая организовывать соединения точка-многоточка на уровне L2 модели OSI — это VPLS подробнее про нее можно прочитать перейдя по ссылке.
Купить\Заказать услугу L2VPN можно здесь.
Доступ в Интернет через L2VPN
Виртуальный выделенный канал L2VPN – сервис, необходимый для безопасной передачи данных между узлами сети. DataFort предоставляет заказчикам канал связи типа «точка-точка» или «звезда» на втором (канальном) уровне сетевой модели OSI на базе своей инфраструктуры.
Сервис предоставляется круглосуточно, с фиксированной пропускной способностью виртуальных каналов передачи данных (10 Мбит/с, 20 Мбит/с, 100 Мбит/с, 200 Мбит/с, 500 Мбит/с, 1000 Мбит/с) и с использованием технологии виртуальных частных сетей Ethernet 802.1Q. Порт коммутатора, к которому выполнено подключение сети заказчика, включается в соответствующую выделенную частную подсеть 802.1q (VLAN).
Экспертиза IBS DataFort
Профессиональная помощь в выборе наиболее подходящего сервиса с учетом особенностей инфраструктуры и бизнес-задач заказчика
Надежная защита от несанкционированного доступа, спама, запрещенного контента, утечек данных и всех видов кибератак
Уникальная услуга по изучению влияния человеческого фактора на автоматизированные процессы компании. Оценка таких качеств, как коммуникабельность, ответственность, лояльность, стрессоустойчивость, самостоятельность и др. Оптимизация процессов взаимодействия между сотрудниками, выявление потенциальных лидеров.
Опытные специалисты в различных областях: сетевая инфраструктура, создание облачных платформ, резервное копирование, репликация, информационная безопасность, мониторинг сетей, систем и сервисов и др
Быстрое внедрение и сопровождение системного программного обеспечения, оптимизация лицензионных платежей
Круглосуточная поддержка пользователей, быстрое реагирование на запросы
Каналы связи L2 и L3 VPN — Отличия физических и виртуальных каналов разного уровня
С доброй улыбкой теперь вспоминается, как человечество с тревогой ожидало в 2000 году конца света. Тогда этого не случилось, но зато произошло совсем другое событие и тоже очень значимое.
Исторически, в то время мир вошел в настоящую компьютерную революцию v. 3.0. – старт облачных технологий распределенного хранения и обработки данных. Причем, если предыдущей «второй революцией» был массовый переход к технологиям «клиент-сервер» в 80-х годах, то первой можно считать начало одновременной работы пользователей с использованием отдельных терминалов, подключенных к т.н. «мейнфреймам» (в 60-х прошлого столетия). Эти революционные перемены произошли мирно и незаметно для пользователей, но затронули весь мир бизнеса вместе с информационными технологиями.
При переносе IT-инфраструктуры на облачные платформы и удаленные ЦОД (центры обработки данных) ключевым вопросом сразу же становится организация надежных каналов связи от клиента к дата-центрам. В Сети нередко встречаются предложения провайдеров: «физическая выделенная линия, оптоволокно», «канал L2», «VPN» и так далее… Попробуем разобраться, что за этим стоит на практике.
Каналы связи – физические и виртуальные
1. Организацией «физической линии» или «канала второго уровня, L2» принято называть услугу предоставления провайдером выделенного кабеля (медного или оптоволоконного), либо радиоканала между офисами и теми площадками, где развернуто оборудование дата-центров. Заказывая эту услугу, на практике скорее всего вы получите в аренду выделенный оптоволоконный канал. Это решение привлекательно тем, что за надежную связь отвечает провайдер (а в случае повреждения кабеля самостоятельно восстанавливает работоспособность канала). Однако, в реальной жизни кабель на всем протяжении не бывает цельным – он состоит из множества соединенных (сваренных) между собой фрагментов, что несколько снижает его надежность. На пути прокладки оптоволоконного кабеля провайдеру приходится применять усилители, разветвители, а на оконечных точках – модемы.
В маркетинговых материалах к уровню L2 (Data-Link) сетевой модели OSI или TCP/IP это решение относят условно – оно позволяет работать как бы на уровне коммутации фреймов Ethernet в LAN, не заботясь о многих проблемах маршрутизации пакетов на следующем, сетевом уровне IP. Есть, например, возможность продолжать использовать в клиентских виртуальных сетях свои, так называемые «частные», IP-адреса вместо зарегистрированных уникальных публичных адресов. Поскольку использовать частные IP-адреса в локальных сетях очень удобно, пользователям были выделены специальные диапазоны из основных классов адресации:
Примечание: NAT – Network Address Translation (механизм замены сетевых адресов транзитных пакетов в сетях TCP/IP, применяется для маршрутизации пакетов из локальной сети клиента в другие сети/Интернет и в обратном направлении – вовнутрь LAN клиента, к адресату).
У этого подхода (а мы говорим о выделенном канале) есть и очевидный недостаток – в случае переезда офиса клиента, могут быть серьезные сложности с подключением на новом месте и возможна потребность в смене провайдера.
Утверждение, что такой канал значительно безопаснее, лучше защищен от атак злоумышленников и ошибок низкоквалифицированного технического персонала при близком рассмотрении оказывается мифом. На практике проблемы безопасности чаще возникают (или создаются хакером умышленно) прямо на стороне клиента, при участии человеческого фактора.
2. Виртуальные каналы и построенные на них частные сети VPN (Virtual Private Network) распространены широко и позволяют решить большинство задач клиента.
Предоставление провайдером «L2 VPN» предполагает выбор из нескольких возможных услуг «второго уровня», L2:
VLAN – клиент получает виртуальную сеть между своими офисами, филиалами (в действительности, трафик клиента идет через активное оборудование провайдера, что ограничивает скорость);
Соединение «точка-точка» PWE3 (другими словами, «эмуляция сквозного псевдопровода» в сетях с коммутацией пакетов) позволяет передавать фреймы Ethernet между двумя узлами так, как если бы они были соединены кабелем напрямую. Для клиента в такой технологии существенно, что все переданные фреймы доставляются до удалённой точки без изменений. То же самое происходит и в обратном направлении. Это возможно благодаря тому, что фрейм клиента приходя на маршрутизатор провайдера далее инкапсулируется (добавляется) в блок данных вышестоящего уровня (пакет MPLS), а в конечной точке извлекается;
Примечание: PWE3 – Pseudo-Wire Emulation Edge to Edge (механизм, при котором с точки зрения пользователя, он получает выделенное соединение).
MPLS – MultiProtocol Label Switching (технология передачи данных, при которой пакетам присваиваются транспортные/сервисные метки и путь передачи пакетов данных в сетях определяется только на основании значения меток, независимо от среды передачи, используя любой протокол. Во время маршрутизации новые метки могут добавляться (при необходимости) либо удаляться, когда их функция завершилась. Содержимое пакетов при этом не анализируется и не изменяется).
Примечание: VPLS – Virtual Private LAN Service (механизм, при котором с точки зрения пользователя, его разнесенные географически сети соединены виртуальными L2 соединениями).
MAC – Media Access Control (способ управления доступом к среде – уникальный 6-байтовый адрес-идентификатор сетевого устройства (или его интерфейсов) в сетях Ethernet).
3. В случае развертывания «L3 VPN» сеть провайдера в глазах клиента выглядит подобно одному маршрутизатору с несколькими интерфейсами. Поэтому, стык локальной сети клиента с сетью провайдера происходит на уровне L3 сетевой модели OSI или TCP/IP.
Публичные IP-адреса для точек стыка сетей могут определяться по согласованию с провайдером (принадлежать клиенту либо быть полученными от провайдера). IP-адреса настраиваются клиентом на своих маршрутизаторах с обеих сторон (частные – со стороны своей локальной сети, публичные – со стороны провайдера), дальнейшую маршрутизацию пакетов данных обеспечивает провайдер. Технически, для реализации такого решения используется MPLS (см. выше), а также технологии GRE и IPSec.
Примечание: GRE – Generic Routing Encapsulation (протокол тунеллирования, упаковки сетевых пакетов, который позволяет установить защищенное логическое соединение между двумя конечными точками – с помощью инкапсуляции протоколов на сетевом уровне L3).
IPSec – IP Security (набор протоколов защиты данных, которые передаются с помощью IP. Используется подтверждение подлинности, шифрование и проверка целостности пакетов).
Важно понимать, что современная сетевая инфраструктура построена так, что клиент видит только ту ее часть, которая определена договором. Выделенные ресурсы (виртуальные серверы, маршрутизаторы, хранилища оперативных данных и резервного копирования), а также работающие программы и содержимое памяти полностью изолированы от других пользователей. Несколько физических серверов могут согласованно и одновременно работать для одного клиента, с точки зрения которого они будут выглядеть одним мощным серверным пулом. И наоборот, на одном физическом сервере могут быть одновременно созданы множество виртуальных машин (каждая будет выглядеть для пользователя подобно отдельному компьютеру с операционной системой). Кроме стандартных, предлагаются индивидуальные решения, которые также соответствует принятым требованиям относительно безопасности обработки и хранения данных клиента.
При этом, конфигурация развернутой в облаке сети «уровня L3» позволяет масштабирование до практически неограниченных размеров (по такому принципу построен Интернет и крупные дата-центры). Протоколы динамической маршрутизации, например OSPF, и другие в облачных сетях L3, позволяют выбрать кратчайшие пути маршрутизации пакетов данных, отправлять пакеты одновременно несколькими путями для наилучшей загрузки и расширения пропускной способности каналов.
В то же время, есть возможность развернуть виртуальную сеть и на «уровне L2», что типично для небольших дата-центров и устаревших (либо узко-специфических) приложений клиента. В некоторых таких случаях, применяют даже технологию «L2 over L3», чтобы обеспечить совместимость сетей и работоспособность приложений.
Подведем итоги
На сегодняшний день задачи пользователя/клиента в большинстве случаев могут быть эффективно решены путём организации виртуальных частных сетей VPN c использованием технологий GRE и IPSec для безопасности.
Нет особого смысла противопоставлять L2 и L3, равно как нет смысла считать предложение канала L2 лучшим решением для построения надёжной коммуникации в своей сети, панацеей. Современные каналы связи и оборудование провайдеров позволяют пропускать громадное количество информации, а многие выделенные каналы, арендуемые пользователями, на самом деле – даже недогружены. Разумно использовать L2 только в особенных случаях, когда этого требует специфика задачи, учитывать ограничения возможности будущего расширения такой сети и проконсультироваться со специалистом. С другой стороны, виртуальные сети L3 VPN, при прочих равных условиях, более универсальны и просты в эксплуатации.
В этом обзоре кратко перечислены современные типовые решения, которые используют при переносе локальной IT-инфраструктуры в удаленные центры обработки данных. Каждое из них имеет своего потребителя, достоинства и недостатки, правильность выбора решения зависит от конкретной задачи.
В реальной жизни, оба уровня сетевой модели L2 и L3 работают вместе, каждый отвечает за свою задачу и противопоставляя их в рекламе, провайдеры откровенно лукавят.
Сети для самых матёрых. Часть двенадцатая. MPLS L2VPN
Долго ли коротко ли, но шестерни в очередной раз провернулись и linkmeup встал на ступень Tier 2. И несколько достаточной платёжоспособности энтерпрайзов проявили заинтересованность в организации связи между своими филиалами через сети linkmeup.
L3VPN, который мы рассмотрели в прошлом выпуске, покрывает собой огромное количество сценариев, необходимых большинству заказчиков. Огромное, но не все. Он позволяет осуществлять связь только на сетевом уровне и только для одного протокола — IP. Как быть с данными телеметрии, например, или трафиком от базовых станций, работающих через интерфейс E1? Существуют также сервисы, которые используют Ethernet, но тоже требуют связи на канальном уровне. Опять же ЦОДы между собой любят на языке L2 общаться.
Вот и нашим клиентам вынь да положь L2.
Традиционно раньше всё было просто: L2TP, PPTP да и всё по большому счёту. Ну в GRE ещё можно было спрятать Ethernet. Для всего прочего строили отдельные сети, вели выделенные линии ценою в танк (ежемесячно).
Однако в наш век конвергентных сетей, распределённых ЦОДов и международных компаний это не выход, и на рынок выплеснулось некоторое количество масштабируемых технологий випиэнирования на канальном уровне.
Мы же в этот раз сосредоточимся на MPLS L2VPN.
Технологии L2VPN
Прежде чем погрузиться в тёплый MPLS, взглянем на то, какие вообще виды L2VPN существуют.
Например, Е1-кадр приходит на PE, сразу же инкапсулируется в MPLS и уже никто по пути даже не заподозрит, что там внутри — важно только вовремя поменять метку.
А на другой порт приходит Ethernet-кадр и по тому же самому LSP он может пройти по сети, только с другой меткой VPN.
А кроме того MPLS TE позволяет строить каналы с учётом требований трафика к параметрам сети.
В связке же с LDP и BGP становится более просто настраивать VPN и автоматически находить соседей.
Возможность инкапсулировать трафик любого канального уровня в MPLS называется AToM — Any Transport over MPLS.
Вот список поддерживаемых AToM протоколов:
Два мира L2VPN
Для построения любого L2VPN существуют два концептуально разных подхода.
Вы хотите соединить два узла друг с другом. Тогда сеть провайдера для вас будет как один виртуальный кабель — то, что вошло в него на одном конце обязательно выйдет на другом без изменений.
Общее название услуги: VPWS — Virtual Private Wire Service.
Название технологии: VPLS — Virtual Private LAN Service.
Терминология
Традиционно термины будут вводиться по мере необходимости. Но о некоторых сразу.
PE — Provider Edge — граничные маршрутизаторы MPLS-сети провайдера, к которым подключаются клиентские устройства (CE).
CE — Customer Edge — оборудование клиента, непосредственно подключающееся к маршрутизаторам провайдера (PE).
AC — Attached Circuit — интерфейс на PE для подключения клиента.
VC — Virtual Circuit — виртуальное однонаправленное соединение через общую сеть, имитирующее оригинальную среду для клиента. Соединяет между собой AC-интерфейсы разных PE. Вместе они составляют цельный канал: AC→VC→AC.
PW — PseudoWire — виртуальный двунаправленный канал передачи данных между двумя PE — состоит из пары однонаправленных VC. В этом и есть отличие PW от VC.
VPWS. Точка-точка
VPWS — Virtual Private Wire Service.
В основе любого решения MPLS L2VPN лежит идея PW — PseudoWire — виртуальный кабель, прокинутый из одного конца сети в другой. Но для VPWS сам этот PW и является уже сервисом.
Эдакий L2-туннель, по которому можно беззаботно передавать всё, что угодно.
Ну, например, у клиента в Котельниках находится 2G-базовая станция, а контроллер — в Митино. И эта БС может подключаться только по Е1. В стародавние времена пришлось бы протянуть этот Е1 с помощью кабеля, радиорелеек и всяких конвертеров.
Сегодня же одна общая MPLS-сеть может использоваться, как для этого Е1, так и для L3VPN, Интернета, телефонии, телевидения итд.
(Кто-то скажет, что вместо MPLS для PW можно использовать L2TPv3, но кому он нужен с его масштабируемостью и отсутствием Traffic Engineering’а?)
VPWS сравнительно прост, как в части передачи трафика, так и работы служебных протоколов.
VPWS Data Plane или передача пользовательского трафика
Туннельная метка — то же, что и транспортная, просто длинное слово «транспортное» не помещалось в заголовок.
0. Между R1 и R6 уже построен транспортный LSP с помощью протокола LDP или RSVP TE. То есть R1 известна транспортная метка и выходной интерфейс к R6.
1. R1 получает от клиента CE1 некий L2 кадр на AC интерфейс (то может оказаться Ethernet, TDM, ATM итд. — не имеет значения).
2. Этот интерфейс привязан к определённому идентификатору клиента — VC ID — в некотором смысле аналогу VRF в L3VPN. R1 даёт кадру сервисную метку, которая сохранится до конца пути неизменной. VPN-метка является внутренней в стеке.
3. R1 знает точку назначения — IP-адрес удалённого PE-маршрутизатора — R6, выясняет транспортную метку и вставляет её в стек меток MPLS. Это будет внешняя — транспортная метка.
4. Пакет MPLS путешествует по сети оператора через P-маршрутизаторы. Транспортная метка меняется на новую на каждом узле, сервисная остаётся без изменений.
5. На предпоследнем маршрутизаторе снимается транспортная метка — происходит PHP. На R6 пакет приходит с одной сервисной VPN-меткой.
6. PE2, получив пакет, анализирует сервисную метку и определяет, в какой интерфейс нужно передать распакованный кадр.
Если вы читали предыдущий выпуск про L3VPN, то в вопросе передачи пользовательского трафика не увидите ничего нового — пара MPLS-меток и передача по транспортному LSP. Ingress PE проверяет какие метки поставить и в какой интерфейс отправить, P меняет транспортную метку, а Egress PE по метке VPN принимает решение, в какой AC-интерфейс передать полученный кадр.
VPWS Control Plane или работа служебных протоколов
Транспортная метка может назначаться как LDP (см. выпуск про MPLS), так и RSVP-TE (ещё ждёт своего часа).
Для примера, возьмём LDP — по всей сети запускается этот протокол, который для каждого Loopback-адреса каждого MPLS-маршрутизатора распространит по сети метки.
В нашем случае R1 после работы LDP будет, грубо говоря, знать 5 меток: как добраться до каждого из оставшихся маршрутизаторов.
Нас интересует LSP R1→R6 и обратно. Заметьте, что для того, чтобы VC перешёл в состояние UP, должны быть оба LSP — прямой и обратный.
Существует несколько разных способов реализации услуги VPWS. Об этом мы поговорим чуть ниже, а для примера разберём ту, которая наиболее часто сейчас используется.
За распространение сервисных меток отвечает тот же LDP, только генно-модифицированный — Targeted LDP. Теперь он может устанавливать соединение с удалёнными маршрутизаторами и обмениваться с ними метками.
В нашем примере к R1 и R6 подключены клиенты. R1 через LDP сообщит свою метку для этого клиента R6 и наоборот.
На обоих концах вручную мы настраиваем удалённую LDP-сессию. Она никак не привязана к VPN. То есть одна и та же сессия может использоваться для обмена метками любым количеством VPN.
Обычный LDP — это link-local протокол и ищет соседей среди непосредственно подключенных маршрутизаторов, то есть TTL его пакетов — 1. Однако tLDP достаточна IP-связность.
Как только с обеих сторон появятся AC-интерфейсы с одинаковым VC-ID, LDP поможет им сообщить друг другу метки.
В чём отличия tLDP от LDP?
| LDP | tTLDP |
| Соседями могут быть только непосредственно подключенные маршрутизаторы | Соседом может быть любой маршрутизатор в сети, с которым есть IP-связность. |
| Поиск всех возможных соседей | Соседи уже определены конфигурацией |
| Широковещательная рассылка сообщений Discovery | Адресная отправка сообщения Discovery конкретным соседям. |
| В качестве FEC обычно выступает IP-адрес | В качестве FEC обычно выступает VC ID |
Чтобы сильно далеко не убегать, сразу же практика.
Как собрать лабу для MPLS L2VPN?
В качестве тестового стенда использована связка UnetLab + CSR1000V. И то и другое вы можете получить совершенно бесплатно и законно.
UnetLab OVA.
Cisco CSR1000V IOS-XE.
Инструкции по установке UNL и добавлению образов CSR1000V: Тыц.
Соответственно далее все команды по настройке MPLS L2VPN даны в нотации Cisco IOS-XE.
Внимание: для каждой ноды CSR1000V требуется 2,5 ГБ RAM. В противном случае образ либо не запустится, либо будут различные проблемы, вроде того, что порты не поднимаются или наблюдаются потери.
Практика VPWS
Упростим топологию до четырёх магистральных узлов. По клику можете открыть её в новой вкладке, чтобы смотреть на неё Alt+Tab’ом, а не ворочать страницу вверх-вниз.
Наша задача — прокинуть Ethernet от Linkmeup_R1 (порт Gi3) до Linkmeup_R4 (порт Gi3).
На шаге 0 IP-адресация, IGP-маршрутизация и базовый MPLS уже настроены (см. как).
Команда xconect 4.4.4.4 127 encapsulation mpls заставляет LDP поднять удалённую сессию с узлом 4.4.4.4 и создаёт MPLS PW с VC ID 127. Важно, чтобы VC ID совпадали на двух противоположных AC-интерфейсах — это указатель того, что их нужно срастить.
Давайте проследим, что там происходило за кулисами протоколов (дамп снят с интерфейса GE1 Linkmeup_R1). Можно выделить основные вехи:
0) IGP сошёлся, LDP определил соседей, поднял сессию и раздал транспортные метки. Как видите, Linkmeup_R4 выделил транспортную метку 19 для FEC 4.4.4.4.
1) А вот tLDP начал свою работу.
—А. Сначала мы настроили его на Linkmeup_R1 и tLDP начал периодически отправлять свой Hello на адрес 4.4.4.4
Как видите, это юникастовый IP пакет, который отправляется с адреса Loopback-интерфейса 1.1.1.1 на адрес такого же Loopback удалённого PE — 4.4.4.4.
Упакован в UDP и передаётся с одной меткой MPLS — транспортной — 19. Обратите внимание на приоритет — поле EXP — 6 — один из наивысших, поскольку это пакет служебного протокола. Подробнее мы об этом поговорим в выпуске о QoS.
Состояние PW пока в DOWN, потому что с обратной стороны ничего нет.
—Б. После того, как настроили xconnect на стороне Linkmeup_R4 — сразу Hello и установление соединения по TCP.
В этот момент установлено LDP-соседство:
—В. Пошёл обмен метками: 
В самом низу можно видеть, что FEC в случае VPWS — это VC ID, который мы указали в команде xconnect — это идентификатор нашего VPN — 127.
А чуть ниже выделенная ему Linkmeup_R4 метка — 0х16 или 22 в десятичной системе.
То есть этим сообщением Linkmeup_R4 сообщил Linkmeup_R1, мол, если ты хочешь передать кадр в VPN с VCID 127, то используй сервисную метку 22.
Тут же вы можете видеть ещё кучу других сообщений Label Mapping — это LDP делится всем, что нажил — информацией про все FEC. Нас это мало интересует, ну а Lilnkmeup_R1 и подавно.
То же самое делает и Linkmeup_R1 — сообщает Linkmeup_R4 свою метку:
После этого поднимаются VC и мы можем увидеть метки и текущие статусы:
Команды show mpls l2transport vc detail и show l2vpn atom vc detail в целом идентичны для наших примеров.
2) Далее соседи будут только поддерживать контакт:
3) Теперь всё готово для передачи пользовательских данных. В этот момент мы запускаем ping. Всё предсказуемо просто: две метки, которые мы уже видели выше.
Почему-то Wireshark не разобрал внутренности MPLS, но я вам покажу, как прочитать вложение:
Два блока, выделенных, красным — это MAC-адреса. DMAC и SMAC соответственно. Жёлтый блок 0800 — поле Ethertype заголовка Ethernet — значит внутри IP.
Далее чёрный блок 01 — поле Protocol заголовка IP — это номер протокола ICMP. И два зелёных блока — SIP и DIP соответственно.
Теперь вы можете в Wireshark!
Соответственно ICMP-Reply возвращается только с меткой VPN, потому что на Linkmeup_R2 возымел место PHP и транспортная метка была снята.
Если VPWS — это просто провод, то он должен спокойно передать и кадр с меткой VLAN? Да, и нам для этого не придётся ничего перенастраивать. Вот пример кадра с меткой VLAN:
Здесь вы видите Ethertype 8100 — 802.1q и метку VLAN 0x3F, или 63 в десятичной системе.
Если мы перенесём конфигурацию xconnect на сабинтерфейс с указанием VLAN, то он будет терминировать данный VLAN и отправлять в PW кадр без заголовка 802.1q.
Виды VPWS
Рассмотренный пример — это EoMPLS (Ethernet over MPLS). Он является частью технологии PWE3, которая суть развитие VLL Martini Mode. И всё это вместе и есть VPWS. Тут главное не запутаться в определениях. Позвольте мне быть вашим проводником.
Итак, VPWS — общее название решений для L2VPN вида точка-точка.
PW — это виртуальный L2-канал, который лежит в основе любой технологии L2VPN и служит туннелем для передачи данных.
VLL (Virtual Leased Line) — это уже технология, которая позволяет инкапсулировать кадры различных протоколов канального уровня в MPLS и передавать их через сеть провайдера.
VLL CCC — Circuit Cross Connect. В этом случает нет метки VPN, а транспортные назначаются вручную (статический LSP) на каждом узле, включая правила swap. То есть в стеке будет всегда только одна метка, а каждый такой LSP может нести трафик только одного VC. Ни разу не встречал его в жизни. Главное его достоинство — он может обеспечить связность двух узлов, подключенных к одному PE.
VLL TCC — Translational Cross Connect. То же, что CCC, но позволяет с разных концов использовать разные протоколы канального уровня.
Работает это только с IPv4. PE при получении удаляет заголовок канального уровня, а при передаче в AC-интерфейс вставляет новый.
VLL SVC — Static Virtual Circuit. Транспортный LSP строится обычными механизмами (LDP или RSVP-TE), а сервисная метка VPN назначается вручную. tLDP в этом случае не нужен. Не может обеспечить локальную связность (если два узла подключены к одному PE).
Martini VLL — это примерно то, с чем мы имели дело выше. Транспортный LSP строится обычным образом, метки VPN распределяются tLDP. Красота! Не поддерживает локальную связность.
Kompella VLL — Транспортный LSP обычным образом, для распределения меток VPN — BGP (как и полагается, с RD/RT). Уау! Поддерживает локальную связность. Ну и ладно.
PWE3 — Pseudo Wire Emulation Edge to Edge. Строго говоря, область применения этой технология шире, чем только MPLS. Однако в современном мире в 100% случаев они работают в связке. Поэтому PWE3 можно рассматривать как аналог Martini VLL с расширенным функционалом — сигнализацией так же занимаются LDP+tLDP.
Коротко его отличия от Martini VLL можно представить так:
Я тут везде говорю об Ethernet для того, чтобы показать наиболее наглядный пример. Всё, что касается других канальных протоколов, это, пожалуйста, на самостоятельное изучение.
VPLS. Point-to-Multipoint
Мне очень нравится термин точка-многоточка. Есть в нём что-то детское, игривое. И это то, о чём мы поговорим сейчас.
VPLS — Virtual Private LAN Service. По своей сути — это коммутатор. Провайдер подключает несколько точек заказчика к своей сети в разных её концах и обеспечивает L2 связность. И теперь это задача транспортной сети провайдера — заботиться о правильной коммутации кадров, то есть изучении MAC-адресов.
Терминология
VPLS-домен — изолированная виртуальная L2-сеть, то есть, грубо говоря, один отдельный L2VPN. Два разных клиента — два разных VPLS-домена.
VSI — Virtual Switching Instance. Виртуальный коммутатор в пределах одного узла.
Для каждого клиента (или сервиса) он свой. То есть трафик разных VSI не может кочевать из одного в другой.
В терминах Cisco это VFI — Virtual Forwarding Instance. Я позволю себе вольно обращаться с терминами VPLS-домен, VSI и VFI, иногда используя их как синонимы.
VE — VPLS Edge — узел PE, участник VPLS-домена.
VPLS Data Plane
В общих чертах передача пользовательского трафика выглядит, как и для случая VPWS, но добавляется шаг изучения MAC‘ов и проверки MAC-таблицы при передаче трафика.
А) Если MAC-адрес источника пока не известен, вносит его в таблицу. В качестве входного интерфейса будет указан PW к Ingress PE.
Б) Если MAC-адрес назначения ему известен, отсылает кадр в тот порт, за которым он изучен. Отсылается уже чистый Ethernet-кадр, без каких-либо заголовков MPLS.
В) Если этот MAC не удалось найти в таблице? Широковещательная рассылка по всем AC-портам этого VSI. Заметьте, PE не будет рассылать этот кадр в PW данного VSI, потому что все другие PE уже получили копию этого кадра от входного PE. Это всё то же правило расщепления горизонта (Split Horizon), и так достигается отсутствие петель коммутации и широковещательных штормов. (Ах, если бы всё было так просто. )
Есть просто гиф, которая показывает, что происходит. А есть та же гиф, только с голосом.
Как и в обычном коммутаторе записи в MAC-таблице VSI периодически протухают и удаляются.
В вопросе изучения MAC-адресов в VPLS есть один нюанс, который резко отличает его от L3VPN. PE должен не просто знать физический порт, откуда пришёл кадр — важно определить соседа или, точнее PW как виртуальный интерфейс. Дело в том, что клиентский кадр нужно отправить не просто в какой-то физический порт, а именно в правильный PW, иными словами, правильному соседу.
Для этой цели каждому соседу выдаётся личная метка, с которой тот будет отправлять кадр этому PE в данном VPLS-домене. И в дальнейшем по VPN-метке, заглянув в LFIB, PE узнает, от какого соседа пришёл кадр.
Напомню, что L3VPN без разницы, откуда пришёл IP-пакет, поэтому для префикса в VRF всем соседям сообщается одна и та же метка.
Схема доставки пользовательского трафика незамысловата. Но что же с пресловутым Control Plane’ом? Опять придётся поломать мозги или малыми жертвами?
Извините, но дальше начинается трэш и содомия. Не сразу — попозже, но будет. Вы действуете на свой страх и риск.
VPLS Control Plane
Из работы Data Plane уже видно, что для VPLS требуется полносвязная топология PE для каждого VSI. Причём не все PE MPLS-сети провайдера будут соседями, а только те, где есть этот же VSI.
Поэтому один из главных вопросов в VPLS — обнаружение всех PE, куда подключены клиенты данного VSI. Существует здесь два подхода: ручная настройка и автоматическое обнаружение. Первый путь изначально предложила Cisco (драфт Мартини), отцом второго является Juniper (драфт Компелла).
11 выпусков СДСМ пропагандировал упрощение жизни инженера и автоматизацию всего и вся. И вот, настал тот момент, когда нужно забыть всё, чему вас учили. Это первый случай (если не поднимать холивар вокруг VTP), когда решение с ручной настройкой соседей оказывается более популярным.
Стало интересно?
Прежде чем приоткроем кулисы, хочу сделать замечание: независимо от того, что мы вытворяем с VPN-метками, транспортные LSP строятся как обычно LDP или RSVP-TE. Поэтому далее касаться транспорта мы будем только вскользь.
Точно также, независимо от используемого режима, VPLS при более детальном рассмотрении разваливается на point-to-point PW. То есть мы имеем не некое централизованное облако коммутации, а просто набор виртуальных линий между всем соседями. Решение о передаче кадра принимает Ingress PE или, проще говоря, выбирает нужный PW.
Слово «драфт», прочно закрепившееся за этими двумя подходами, уже давно неправомерно и используется по исторической инерции. Драфтом предложение может быть только шесть месяцев.
На данный момент draft-martini переродился в RFC 4447 — Интернет-стандарт про PWE3, а драфт-Компелла устарел и умер.
Если же говорить именно о VPLS, то тут есть два стандарта:
“Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and Signaling”. RFC 4761.
“Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling” RFC 4762.
Историческая справка по методам.
VPLS Martini Mode (LDP)
В начале двухтысячных индустрия усиленно занялась поисками решений для L2VPN в масштабах оператора. Критерии были следующими:
Для сигнализации меток будет использоваться LDP, который уже является частью MPLS. VPLS Martini Mode описан в стандарте RFC4762.
Именно это лаконичное решение и стало стандартом де факто в большинстве сетей по всему миру. С тем, как работает Martini-mode мы уже познакомились в части про VPWS. Ровно то же самое и здесь, только удалённые LDP сессии создаются для каждого VSI не с одним соседом, а с несколькими.
LDP используется для распределения сервисных меток. Удалённые сессии с каждым соседом в VPLS-домене настраиваются вручную. Поскольку заранее известны все участники этого VPLS, каждому из них LDP выделяет индивидуальную метку в сообщении LDP Label Mapping Message.
Если добавляется новый PE в VPLS-домен, необходимо настроить LDP-соседство со всеми существующими PE этого VPLS. После чего с каждым из них новый PE обменятся метками.
В течение всего времени, LDP проверяет доступность своих соседей. Если какой-то из соседей выходит из группы или становится недоступным, сессия разрывается и все изученные MAC’и в PW к этому соседу очищаются.
Если состояние какого-либо из AC-портов VPLS-домена переходит в состояние Down, либо происходит другое событие, заставляющее очистить MAC-адреса с AC-порта, то PE сообщает об этом всем своим соседям, настаивая на удалении MAC-адресов в сообщении LDP MAC Withdraw (К сожалению CSR1000V на тестовом стенде этого не делает).
Известны случаи, когда в случае изменения состояния AC-порта, PE отправляет сообщение LDP MAC withdraw без уточнения, какие именно MAC’и. Это означает, что каждый сосед должен очистить всю таблицу MAC-адресов данного VPLS-домена.
Теперь представьте, что счёт идёт на сотни, возможно, тысячи записей. И по всей сети все PE начинают изучать MAC-адреса. А что они делают с кадром, когда не находят MAC получателя? Рассылают всем. Возникает кратковременный широковещательный шторм без петли коммутации.
Если VPLS-домен не ограничен небольшим участком сети (а обычно это не так) прилечь может всё. Нет повести печальнее на свете, чем шторм в VPLS-сЕти. Пожалуйста, не делайте так.
В конце я расскажу о других неприятных ситуациях, которые могут возникнуть в VPLS сети.
Практика VPLS
Разберём работу VPLS на практике по шагам вот по этой схеме. Это всё та же сеть, но теперь клиент решил, что ему недостаточно двух точек, он хочет четыре и объединить их все в одну сеть.
Забыли о том, что у нас до этого был сервис VPWS — этой конфигурации больше нет. Файл начальной конфигурации.
Итак на шаге 0 у нас готовы необходимые транспортные LSP, а соответственно, и маршрутизация итд.
Режим по умолчанию — LDP signaling. VPN ID — аналог VCID из предыдущего примера — уникальный идентификатор VPN. Он должен совпадать на всех узлах. Следующими двумя командами мы указываем соседей, что мешают спать которые тоже являются членами этого VPLS-домена. По сути это указание LDP установить удалённую сессию с ними, после которого он начинает отправлять LDP Hello настроенным соседям.
В режиме конфигурации интерфейса мы создаём Service Instance — это привязка интерфейса к сервисам. Каким именно — настроим позднее. Номер Service Instance произвольный — он локальнозначимый для интерфейса (как и у классического сабинтерфейса).
encapsulation default означает, что мы хватаем все кадры без разбора (а могли бы выбирать по метке VLAN или по факту наличия двух меток — QinQ, например), то есть весь физический интерфейс привязываем к VFI.
Резонный вопрос от сторонников бритвы Оккамы — зачем какие-то service instance — недостаточно ли просто bridge-domain прописать?
Мысль верная, но service-instance — это «новый» подход к концепции обработки тегированного трафика и называется он EVC — Ethernet Virtual Circuit.
Тут мы на минуту переключимся на Ethernet-коммутаторы, чтобы понять истоки появления этой идеи.
Традиционно метка VLAN использовалась как для разделения трафика в транках, так и для принятия решения о его коммутации в пределах устройства.
То есть если с двух разных интерфейсов пришли два кадра с тегом 802.1q 10, то они оба попадали в один VLAN 10 на коммутаторе, соответственно оказывались в одном широковещательном домене. При этом физически нельзя было принять на устройстве больше 4094 VLAN (если не считать QinQ).
Концепция EVC разделяет эти функции — тег 802.1q по-прежнему служит для разделения трафика в транках, однако решение о коммутации теперь на стороне Service instance.
То есть Service-instance — это удобный способ разделить один физический интерфейс на несколько логических и в зависимости от метки VLAN и других параметров помещать пришедшие кадры в тот или иной сервис.
Например VLAN 10 может быть назначен разным клиентам на разных портах одного коммутатора и далее прокинут через PW на другой конец сети, однако при этом нет необходимости настраивать VLAN 10 глобально на устройстве и тем самым помещать все порты с VLAN 10 в один широковещательный домен.
То есть два кадра с тегом 10, придя на разные порты одного коммутатора сразу передадутся по xconnect и нигде не пересекутся. Таким образом понятие VLAN становится локально значимым для порта.
При этом Service Instance может проверять не только верхний тег VLAN, но и внутренний или оба в случае QinQ или значение приоритета CoS. Можно задать также диапазон VLAN, помещаемых в данный сервис, настроить снятие, добавление или изменение тегов.
Варианты коммутации: передать в xconnect или в bridge-domain.
В случае маршрутизатора классический саб-интерфейс (типа GE1/1.1234) заменяется на Service instance с более широкими возможностями по выбору инкапсуляции.
Учитывая, что до сих пор не всё понятно с этим EVC, отсылаю вас к более пространным объяснениям: на Cisco и на русском.
Цифра 255 в общем-то произвольная (0-4096). Может выбираться в соответствии с клиентским VLAN, например. Строго локальный для устройства и никуда не передаётся.
Команда member позволяет к bridge-domain привязать различные сервисы. Первой командой подключаем VFI, двумя другими AC-интерфейсы — теперь все они в одном широковещательном домене.
На некотором оборудовании существует два способа настройки VPLS Martini Mode. Другой сейчас считается устаревшим, но допустимым. Вместо команды l2vpn vfi context Blue используется l2 vfi Blue. Главным образом разница заключается в том, что member меняется на neighbor, а привязка к Bridge-domain делается не в секции bridge-domain, а в собственно секции vfi или на интерфейсе в режиме настройки Service instance.
1. Сразу после этого устанавливаются соединения LDP и происходит обмен метками. Технически LDP достаточно привязки к bridge-domain — не обязательно, чтобы были AC-интерфейсы (это поведение зависит от производителя.).
Вот обмен между Linkmeup_R1 и Linkmeup_R3:
FEC 63 — номер нашего VPN. Метка выделена 0x18 (или 24).
То есть, когда Linkmeup_R3 будет отправлять кадры в этом VFI AC-интерфейсу, подключенному к Linkmeup_R1, он должен добавить VPN-метку 24. А транспортная при этом — 17.
Заметьте, что разным соседям Linkmeup_R1 выдаёт разные метки — это для того, чтобы можно было корректно изучить MAC-адреса потом.
2. Если запустить пинг с Blue-A, то в дампе (на интерфейсе Gi1 Linkmeup_R1) можно увидеть сначала ARP-запрос:
Поскольку он широковещательный, то следом за ним можно увидеть его точную копию с одной лишь разницей — метки VPN и транспортная:
Один кадр был отправлен на Linkmeup_R3, другой — на Linkmeup_R4.
3. В таблице MACов видим MAC-адрес узла Blue-A (AABB-CC00-0700) — он находится за портом GE3.EFP10 (Ethernet Flow Point и Service instance 10) — и MAC, соответствующий IP-адресу 192.168.0.2 (AABB-CC00-0300) — за интерфейсом Pseudoport Blue.100401a.
К сожалению, установить зависимость между Pseudoport и pseudowire мне так и не удалось. Как инженеру определить, с какого PW изучается MAC-адрес? Например show l2vpn vfi показывает очевидное соответствие, но эти имена никак не перекликаются.
Если кому-то удастся проследить связь между Pseudoport и pseudowire, эта статья станет чуточку полнее.
Естественно, это всё строго локально. Как и обычные коммутаторы — VPLS не сигнализирует MAC’и другим PE, а занимается их изучением исключительно в рамках Data Plane.
Ещё раз шаги настройки:
VPLS Kompella Mode (BGP)
Проблему поиска соседей решил Кирити Компелла — сотрудник Juniper. Он отталкивался от тех же критериев, но решил, что MBGP, опробованный на L3VPN, подойдёт лучше на роль протокола распределения меток.
Схема обмена маршрутной информацией, однажды расширенная до VPNv4 маршрутов, вполне может быть применена и для доставкой меток VPLS. Механизм Route Target поможет с автоопределением соседей. А рут-рефлекторы решат задачу реализации полносвязной топологии, которая остро стоит в Martini Mode.
Другое название VPLS Kompella-mode — VPLS Auto-Discovery, потому что именно это является его качественным отличием от Martini. Также вы можете услышать VPLS BGP Signaling.
Control Plane выполняет здесь две основные функции:
— Обнаружение соседей
— Передача маршрутной информации и обмен метками.
Обнаружение соседей или Auto-Discovery
Ничего нового выдумывать тут не пришлось. Схема обнаружения соседей уже применённая в L3VPN прекрасно работает и здесь.
Route Target, который является Extended Community — главный признак принадлежности к определённому VSI. Грубо говоря — если RT совпадают — значит в одном VSI.
Строго говоря: Если RT полученного анонса совпадает с настроенным в VSI, значит этот VSI хочет знать информацию из анонса.
Как и в L3VPN можно гибко организовать взаимодействие между различными VSI. Но так крайне редко кто делает.
Чуть подробнее
Каждый VSI имеет свой RT.
В секции BGP для VPLS есть своя Address Family: L2VPN AFI (25) и VPLS SAFI (65)
В ней настраивается соседство с абсолютно всеми PE, которые могут участвовать в каком-либо VPLS-домене. Заметьте, здесь без привязки к конкретному VSI.
Если используются RR, то соседство поднимается только с ними.
Когда BGP хочет сообщить L2-префикс всем PE данного VSI, он высылает BGP Update всем настроенным здесь соседям, опять же независимо от того, хотят они получать данный префикс или нет. Здесь всё так же, как в L3VPN — там vpnv4-префиксы тоже рассылаются всем PE.
Когда удалённый PE получает этот BGP Update, он проверяет RT в поле NLRI и сравнивает с теми, которые настроены в его VSI.
Если совпадение найдено, PE импортирует этот префикс в нужный VSI. Если нет — отбрасывает.
Вот так и реализован Auto-Discovery.
То есть это не какая-то отдельная фаза, чтобы выявить всех участников VPLS-домена и составить их список, а просто механизм распознавания свой-чужой по отношению к анонсу.
Передача префиксов
В целом префикс L2VPN — вещь довольно искусственная — PE своим BGP Update, скорее, сообщает сам факт своего участия в VPLS-домене и метку этого факта. Но это не играет большой роли.
Какого-то адреса, тем более MAC’а, в поле NLRI сообщения BGP Update VPLS не передаёт. Помните, что изучение MAC-адресов — это полностью функция Data Plane.
Однако различать анонсы разных VSI всё равно нужно, поэтому знакомый нам Route Distinguisher тоже присутствует. Обычно он составляет автоматически из номера AS и VPN ID.
Однако что-же передаётся в NLRI? Только метка и RD? Не совсем:
Формально, префикс — это RD+порядковый номер узла в VPLS-домене+блок меток.
Распределение меток
Помните фразу «Хочешь накормить человека один раз — дай ему рыбу. Хочешь накормить его на всю жизнь — дай ему удочку«? Для выделения меток в VPLS Kompella mode используется механизм блоков меток. Один PE другому не сообщает точное значение — он даёт ему информацию для её вычисления.
Я по себе я знаю, что пытаться понять что-то пока ты не знаешь, зачем оно нужно — путь к несварению и трата лишнего времени. В конце этой главы я расскажу, зачем нужна такая странная схема, а пока вы разбираетесь, просто поверьте мне и Кирити Компелле — нужна.
Есть мнение, что видео перед текстом помогает лучше разобраться.
Если не вдаваться в конфигурацию, то выглядит это так:
Прежде чем я ударюсь во все тяжкие про формулы и значения, я считаю себя обязанным объяснить на пальцах в общем как это работает, потому что потратил кучу времени и нервов, чтобы разобраться.
Я искренне верю, что RFC является источником безусловной ясности, но порою в том же виде, в каком им является формула эквивалентности массы и энергии для Ньютона.
Когда на PE приходит L2VPN кадр со стороны MPLS сети, нужно точно знать, от какого он соседа — это нужно, чтобы изучить MAC-адрес, поэтому как и в случае с режимом Martini основная идея заключается в том, что PE каждому соседу в конкретном VSI должен сообщить уникальную метку, чтобы видеть, от кого пришёл кадр.
Вот на такой простой картинке посмотрим поподробнее:
Пусть R1 за главного.
0. В Kompella mode R1 не передаёт метку в явном виде своим соседям R2 и R3.
1. Вместо этого он им сообщает из какого диапазона нужно метки выбирать, чтобы идентифицировать данный VC.
2. У каждого РЕ есть свой порядковый номер n в VPLS-домене. Зная свой номер и диапазон меток, соседи вычисляют исходящую сервисную метку: отсчитывают n-ую по счёту с начала. То есть R2 взял вторую (2), а R3 — третью (3).
3. R2 и R3 сообщают свои номера R1, и он тоже вычисляет, какая входящая сервисная метка будет от R2, какая от R3, отсчитывая от начала диапазона 2 и 3.
4. Аналогично свои собственные диапазоны определяют R2 и R3 и сообщают их друг другу и R1. И цикл вычислений повторяется.
5. В конце концов все будут знать и исходящие метки для данного VPLS и входящие.
Теперь вторая итерация: поглубже копнём, какой матан лежит под этой простой идеей.
VE ID настраивается вручную — это идентификатор PE-маршрутизатора в домене VPLS (его порядковый номер). Должен быть уникален в пределах одного VSI.
LB — Label Base — это начало диапазона, первая метка, которая может быть использована.
VBS — VE Block Size — это длина блока меток — или проще, минимальное количество меток в этом VSI. Для Cisco по умолчанию это 10. Для Juniper — 8 (может быть уменьшен до 2 или увеличен).
В целом, схема простая:
VE ID 100-109 взяты от балды для примера
На этой анимации показан процесс распределения меток на PE1: Если PEX хочет отправлять трафик на PE1, он должен использовать соответствующую метку X.
Вот ещё пример для PE5:
Метки выделяются по порядку — первая из блока — соседу с наименьшим VE-ID. Вторая — второму по величине итд.
То есть такая ситуация невозможна:
Однако если выделенного количества меток мало, то поможет параметр VBO — VE Block Offset — смещение блока. Он позволяет создать несколько блоков. И тем соседям, кому не хватило, метки распределяются по тому же принципу, но из нового блока, с новым LB.
Необходимый VBO вычисляется по формуле: VBO = ЦЕЛОЕ(VE-ID/VBS)*VBS.
Хочется заметить, что VBO — это не про смещение меток, это про диапазон, в который попадает порядковый номер VE. Если попал в первый диапазон — берётся первый блок меток, если во второй — то второй итд.
Таким образом в случае использования нескольких блоков, набор меток будет выглядеть так же, как и прежде
То есть имеем строгое соответствие: узлу с VE ID (VBO+n) соответствует метка (LB+n).
Третья итерация — на реальном примере.
Возьмём клиента с десятью сайтами. VBS у нас стандартный — 10. VE-ID соответствуют номеру маршрутизатора: PE1 — 101, PE2-102,… PE 10 — 110. Рассмотрим как будут взаимодействовать PE1 и PE5.
1. PE1 выбирает в качестве Label Base 1000 — то есть 1000-1009 — это блок меток, из которого его соседи смогут взять себе по одной.
2. PE1 вычисляет VBO. VBO=ЦЕЛОЕ(101/10)*10=100.
3. PE1 передаёт собирает все данные в BGP Update всем своим соседям: LB: 1000, VBS:10, VBO:100, VE-ID:101. Ну и всякие RD, RT, которые нам сейчас не интересны. Сам PE1 пока никаких меток не считает — он ждёт Update от соседей.
4. BGP Update от PE1 достигает PE5. Его VE-ID: 105. И сейчас ему нужно вычислить исходящую метку для данного VSI (чей RT указан так же в BGP Update)в сторону PE1.
5. Первое, что делает PE5 — проверяет, а умещается ли он в блок, анонсированный PE1. Вот здесь и понадобится VBO. Должно выполниться неравенство VBO ≤ PE5 VE-ID ≤ VBO+VBS-1. И оно выполняется 100≤105≤109. Поясню. PE1 вычислил, что его ID в диапазоне 100-109 (со смещением 100 и длиной 10) — соответственно все узлы с VE ID из этого набора будут выбирать метку из первого блока.
6. Итак PE5 в пределах анонсируемого диапазона, поэтому он может идти дальше и вычислить свою исходящую метку по формуле (PE1 LB + PE5 VE-ID — VBO) = (1000 + 105 — 100) = 1005. Ещё раз вся эта арифметика, означает, что от LB нужно отсчитать столько меток, каким по счёту идёт VE-ID от VBO. Значит, PE5, чтобы отправить L2 кадр данного VSI на PE1 вставит в MPLS-заголовок VPN-метку 1005. PE1 пока не знает, про метку 1005 — ему предстоит её вычислить, как это сделал PE5. А для этого нужно узнать его VE ID.
7. Теперь PE5 тоже должен отправить BGP Update всем соседям (технически, не надо дожидаться 7 шага — такую последовательность я взял для примера. PE5 отправляет свой BGP Update как только всё было настроено).
(PE5 LB + PE1 VE-ID — VBO) = (5000 + 101 — 100) = 5001. То есть PE1 при отправке кадров в этот VSI к PE5 вставит в них VPN-метку 5001.
10. PE5 вычисляет входящую: (PE5 LB + PE1 VE-ID — VBO) = (5000 + 101 — 100) = 5001.
Вот это я называю взаимовыручкой!
К сожалению, довольно очевидный и в корне своём логичный механизм я могу описать только таким сложным языком.
Если вы ещё не эволюционировали до понимания механизма Label Block, вернитесь к видео четырьмя экранами выше.
Интересна судьба PE10, которая окажет своё влияние на жизни всех других PE. Дело в том, что он не укладывается в блок 100-109 со своим VE ID 110. Его VBO будет 110=ЦЕЛОЕ(110/10)*10. А в качестве LB он выбрал 10000.
Когда PE10 пришлёт результаты своих калькуляций PE5, неравенство не выполнится: 110 ≤ 105 ≤ 119.
В этом случае запускается процесс выделения нового блока.
1. PE5 выбирает новый LB 5030, VBS уже выбран PE10 — 10.
2. Имея уже данные от PE10,
Скрупулёзное объяснение механизма Label Block от виновников: Juniper.
И в этот момент должно стать жутко. Во-первых мы только что потеряли 10 меток на КАЖДОМ PE (9 не использовано из второго блока и одна метка из первого — которая для самого этого PE). Во-вторых, от того, как мы назначим VE-ID, зависит, насколько рационально будут использованы метки. В-третьих, мы должны своими собственными руками настроить VE-ID и VE-range! Вот этими вот руками, которыми мы MPLS поднимали в пару команд!
Должны быть очень веские доводы, почему протокол реализован именно так, а не по аналогии с LDP или MBGP для L3VPN.
Знаете, что по этому поводу, говорит RFC 4761?
Using a distinct BGP Update message to send a demultiplexor to each
remote PE would require the originating PE to send N such messages
for N remote PEs. The solution described in this document allows a
PE to send a single (common) Update message that contains
demultiplexors for all the remote PEs, instead of N individual
messages. Doing this reduces the control plane load both on the
originating PE as well as on the BGP Route Reflectors that may be
involved in distributing this Update to other PEs.
Не очень понятно, какие там нагрузки на Control Plane.
Как это водится в СДСМ, дальше вы читаете эксклюзив. Причём на этот раз, вероятно, не только рунетовского уровня, но и вообще во всём Интернете я не нашёл адекватного пояснения, зачем эта система блоков была изобретена. Не смейтесь сильно, но я даже писал Компелле, когда ни один из окружающих меня CCIE не ответил на этот вопрос.
Всё это из-за столь желанной функции Auto-discovery (про которую уже было выше) и специфики L2, а именно изучения MAC-адресов. И всё будет понятнее в сравнении с L3VPN, где про назначения блока меток никто даже не думал.
Итак, как работает Auto-Discovery в L3VPN? Некоторый PE страждет рассказать всему миру о двух вещах — во-первых, о том, какие префиксы он знает, во-вторых о том, кому они предназначены. И он хочет рассказать об этом всем сразу без разбора — все, кто являются его MBGP соседями получат его Update, а по RT поймут, интересны ли им эти анонсы. На нет — и суда нет — отбросят. А если интересны, то в свою таблицу маршрутизации VPN занесут полученный префикс и его VPN-метку.
Всё то же самое верно и для L2VPN. За исключением одного: изучения MAC-адресов. BGP в L3VPN сообщает всем одну и ту же метку — ему совершенно без разницы, откуда потом придёт пакет с данными, главная его забота — передать его в правильный клиентский интерфейс.
Но не таков VPLS. Чтобы в будущем отправлять данные конкретному соседу, нужно сначала изучить MAC-адреса клиента, подключенного к этому соседу. И сделать это можно только, если от разных соседей приходят кадры с разными метками.
И здесь-то и кроется дьявол. В BGP Auto-Discovery происходит в тот же момент, что и анонс префикса.
И, во-первых, совершенно не в духе BGP будет, если сначала отсылать пустой Update с целью поиска всех участников VPLS-домена, а потом отдельно то же самое, но с конкретными метками каждому из них.
И даже, если вы приемлете «во-первых» (Фуфуфу), появляется, «во-вторых». Во-вторых, анонс конкретных меток найденным соседям. Хорошо, когда нет RR, и один PE может отправить другому Update адресно. Тогда каждый PE получит только своё сообщение и только свою метку. Но реальность такова, что RR стали её (реальности) частью и, имея соседство только с RR, PE шлёт Update ему, а тот рассылает всем своим клиентам. А если PE шлёт несколько Update’ов, то все они разлетятся по всем. Получается, что каждый его сосед получит не только свою метку, но и все остальные, которые ему даром не сдались.
Просто представьте себе дамп в котором вы видите сотню Update’ов для левых устройств.
И вот тут механизм автоматического вычисления меток выходит на первый план, как весьма элегантное решение этой проблемы. Здесь стоит отдать должное гибкости мысли Кирити Компеллы.
И знаете, пока эта концепция блока меток не сформировалась в непротиворечивый набор синапсов в моём мозге, я с пренебрежением относился к ней. Она казалась мне топорной и устаревшей. Примерно, как DVMRP. Но теперь я проникся идеей и даже несколько удивлён тому, что внятного объяснения нигде нет.
Замечу также, что ситуацию с потерянными метками несколько пересмотрели с выпуском RFC 6624 (в котором, кстати, Компелла тоже принял непосредственное участие):
Label blocks and label values are managed by the PEs. As sites get
added and removed, labels are allocated and released. The easiest
way to manage these is to use fixed-size label blocks rather than
variable-size blocks, although the signaling described here supports
either. If an implementation uses fixed-size blocks, then allocating
a label for a new site may requiring allocating a new block;
similarly, freeing a label may require freeing a block.
If the implementation requires fixed-size blocks, there is probably a
default block size, but the implementation SHOULD allow the
administrator to choose a size. Larger label block sizes mean more
potential «wasted» labels but less signaling overhead, a trade-off
that the administrator might want to control.
И более того, режим LDP-Signalling + BGP Auto-Discovery позволяет совместить достоинства обоих методов. Хотя и появляется вот этот самый двухшаговый механизм — сначала изучаем соседей, потом рассылаем метки.
Практика VPLS Kompella (BGP Signalling)
Этот способ позволяет настроить три типа VFI: ручной Martini с настройкой соседей. BGP Autodiscovery + BGP Signalling, либо BGP Autodiscovery + LDP Signalling. В нашем случае мы выбрали оба — BGP.
Опционально мы можем задать количество членов VPLS-домена. В cisco по умолчанию — 10. Командой ve range Х можно увеличить от 11 до 100 (но не уменьшить). Huawei — по умолчанию 10, можно изменять (1-16000). Juniper — по умолчанию 8, можно изменять (2,4,8, 16. )
Route Distinguisher и Route Target мы можем не настраивать — они будут назначены автоматически. Разве что вам хочется странного — объединить в один домен разные VFI.
Далее я даю команду mpls label range 1000 1999. Она глобально задаёт диапазон динамически используемых меток. Вообще говоря этого делать не нужно, поскольку так всем приложениям MPLS (LDP, TE, BGP) мы указываем, какие метки выбирать, а я не люблю кому-то что-то указывать. Но я делаю это для более наглядной иллюстрации вычисления меток.
Предупреждение говорит как раз о том, что распределённые прежде транспортные метки не укладываются в новый диапазон.
Сначала поднимаем базовое соседство с Linkmeup_R3 и Linkmeup_R4.
Потом создаём Address-Family L2VPN VPLS и указываем соседей, которые будут участвовать в L2VPN. Заметьте, не в конкретном VFI Blue, а вообще.
Здесь вы должны помнить, что обычно мы используем Route Reflector’ы — не нужно настраивать всех соседей вручную, иначе смысл Auto-Discovery теряется. То есть если всего PE-устройств в сети MPLS — 100, в данном VPLS-домене — 20, а L2VPN RR — 2, то на каждом PE нужно поднять соседство только с этими двумя RR. Ну вы же не маленькие, чтобы я вам это рассказывал?
send-community extended — как и в L3VPN включаем передачу Extended Community (RT).
suppress-signaling-protocol ldp — и запрещаем сигнализацию LDP.
Вот что BGP знает о VPLS, ещё даже не имея соседей:
Верхняя строка — это RD, выбранный автоматически: AS:VPN ID. Нижняя — это префикс, который будет передаваться соседям.
Аналогичные манипуляции производим на Linkmeup_R3 и Linkmeup_R4.
Для разных устройств я указал разные mpls label range, чтобы более наглядной была разница между локальными и удалённым метками.
На этом конфигурация MPLS Kompella Mode закончена.
Файл конфигурации VPLS Kompella Mode. Альтернативного метода, как в случае с Martini здесь нет.
0. Связность между CE уже появилась
1. BGP установил сессии и разослал свои Update’ы.
А в Update нас интересует NLRI
Это Linkmeup_R1 сообщает Linkmeup_R3, как вычислить VPN-метку для трафика, предназначенного ему для VPLS с RT 65400:63. CE-ID (он же VE ID)=101, VBO=100, VBS=10, LB=1000.
Это уже Linkmeup_R3 сообщает Linkmeup_R1: CE-ID=103, VBO=100,VBS=10, LB=3000
И вот Linkmeup_R4 сообщает Linkmeup_R1: CE-ID=104, VBO=100,VBS=10, LB=4000
Linkmeup_R1 на Linkmeup_R4 передал то же, что и на Linkmeup_R3.
Давайте, не заглядывая в таблицы меток на PE, посчитаем, какие метки будут назначены?
Linkmeup_R3→Linkmeup_R1
Неравенство VBO ≤ Local VE ID ≤ VBO+VBS-1 выполняется: 100≤103≤109.
Метка: LB + Local VE ID — VBO = 1000+103-100=1003.
Метку 1003 вставит Linkmeup_R3 в кадр, который хочет отправить на Linkmeup_R1 в этом VFI.
Linkmeup_R1→Linkmeup_R3
Неравенство VBO ≤ Local VE ID ≤ VBO+VBS-1 выполняется: 100≤101≤109.
Метка: LB + Local VE ID — VBO = 3000+101-100=3001.
Метку 3001 вставит Linkmeup_R1 в кадр, который хочет отправить на Linkmeup_R3 в этом VFI.
Linkmeup_R1→Linkmeup_R4
Неравенство VBO ≤ Local VE ID ≤ VBO+VBS-1 выполняется: 100≤101≤109.
Метка: LB + Local VE ID — VBO = 4000+101-100=4001.
Linkmeup_R4→Linkmeup_R1
Неравенство VBO ≤ Local VE ID ≤ VBO+VBS-1 выполняется: 100≤104≤109.
Метка: LB + Local VE ID — VBO = 1000+104-100=1004.
Осталось вычислить пару Linkmeup_R4→Linkmeup_R3 и Linkmeup_R3→Linkmeup_R4.
Linkmeup_R4→Linkmeup_R3
Неравенство VBO ≤ Local VE ID ≤ VBO+VBS-1 выполняется: 100≤104≤109.
Метка: LB + Local VE ID — VBO = 3000+104-100=3004.
Linkmeup_R3→Linkmeup_R4
Неравенство VBO ≤ Local VE ID ≤ VBO+VBS-1 выполняется: 100≤103≤109.
Метка: LB + Local VE ID — VBO = 4000+103-100=4003.
2. Сверимся с ситуацией на PE.
Ну, вроде, как всё правильно. К сожалению, в реальной жизни таких красивых цифр не увидишь, там будут нагромождения тарабарщины. Но с другой стороны, и вчитываться в них вам особо не придётся — обычно, если метка выделена, то уже не принципиально, какая.
3. Соответственно, если сейчас мы отправим ping с Blue-A на Blue-D, то должны увидеть VPN-метку 3001 в ICMP-Request и 1003 в ICMP-Reply:
А в этот раз Wireshark почему-то распознал ICMP в MPLS
Вы по-прежнему можете использовать команды show mpls l2transport vc detail и show l2vpan atom vc detail для просмотра деталей:
Командой show bgp l2vpn vpls rd X ve-id Y block-offset Z вы можете вывести всю информацию о блоке меток от данного соседа.
А так посмотреть утилизацию блока меток:
Сложность и количество команд настройки выглядит больше, чем для режима Martini, но нужно помнить, что:
1) Это однократная настройка. При добавлении нового PE в VPLS-домен, настраивать нужно только его (в случае использования RR). Для Martini придётся пройтись по всем существующим PE этого VPLS-домена.
2) Конфигурация по большей части одинаковая — меняется только VE ID. Секция BGP вообще берётся копипастом (в случае использования RR).
Ещё раз повторим шаги конфигурации:
Matini vs Kompella
В результате, какие преимущества даёт использование BGP Kompella mode перед Martini Mode?
Междоменные (Inter-AS) VPN не такая уж большая сложность для Martini при организации иерархического VPLS — тогда нет нужды создавать полносвязную топологию PE-устройств в VPLS-домене. Про H-VPLS мы ещё поговорим позже. Можем вычеркнуть это из его слабых сторон.
Что же касается столь активно эксплуатируемого Auto-Discovery в Kompella, то тут есть два замечания:
Во-первых, уже давно для внедрения конфигурации используются внешние средства. И эти внешние средства могут, проводя анализ конфигурации, находить соседей и готовить скрипты для узлов без ручного труда чёрных инженеров.
Многие проприетарные системы управления поддерживают этот функционал. А сети, в которых действительно это требуется обычно моновендорные и управляются такими NMS.
Во-вторых, RFC 4762 вводит механизм Auto-Discovery в режим Martini. Реализован он может быть через RADIUS или через тот же BGP.
Например, оборудование cisco позволяет настроить режим LDP + BGP Autodiscovery командой autodiscovery LDP signaling BGP в секции l2vpn vfi. С одной стороны имеем простой и неизбыточный метод распределения меток, с другой механизм автоматического поиска соседей (правда секцию BGP придётся оставить).
Как бы то ни было у Martini теперь есть решения для задачи обнаружения соседей и ещё одно очко присуждается Гриффиндору.
Вместе с бережным отношением к меткам, простотой конфигурации и отладки, Martini Mode не только не выглядит аутсайдером, но и, вообще-то давно сыскал любовь операторов. И сегодня он занимает подавляющую долю рынка.
Ну и под занавес ещё одна оптимизация VPLS, которая делает жизнь чуточку легче.
Иерархический VPLS (H-VPLS)
Изначально VPLS — это плоская технология — все соседи одного ранга. И если в Kompella mode RR в очередной раз эффективно решают проблему полносвязной топологии, то Martini Mode в операторских сетях может вызвать кризис рабочей силы — все инженеры будут только настраивать удалённые LDP-сессии. Напомню сложность задачи O(n^2): n*(n-1)/2 — где n — число узлов.
Такая топология скрывает и ещё одну проблему — широковещательные кадры Ethernet — каждый пакет будет повторён столько раз, сколько соседей у данного PE.
А не можем ли мы здесь применить что-то вроде BGP-шных Route Reflector’ов?
Можем. Наш путь к спасению — H-VPLS (Hierarchical VPLS), который описан в RFC 4762.
H-VPLS разделяет маршрутизаторы VPLS-домена на два ранга: PE-rs и MTU-s.
PE-rs — PE — routing and switching. Это ядро сети VPLS. Это большие производительные железки, которые функционируют как обычные PE. Другие названия PE-rs: PE-POP, n-PE.
MTU-s — Multi-Tenant Unit — switching. Это могут быть более слабые устройства, которые подключаются к PE-rs с одной стороны. А с другой к ним подключаются CE. Другие названия MTU-s: u-PE, PE-CLE.
MTU-s обычно имеют восходящие интерфейсы к двум PE-rs — для отказоустойчивости. Но может быть и один. Механизмы подключения MTU-s к PE-rs: MPLS PW или QinQ. Поскольку мы тут про MPLS, то будем рассматривать только первый способ.
PE-rs между собой взаимодействуют как обычные PE, образуя полносвязную топологию и используют правило расщепления горизонта.
При взаимодействии PE-rs и MTU-s, PE-rs воспринимает PW от MTU-s как AC-интерфейс, то есть, как рядового клиента. А значит:
— Всё, что PE-rs получил от MTU-s он рассылает всем соседним PE-rs и всем подключенным MTU-s,
— То, что PE-rs получил от соседнего PE-rs он рассылает всем подключенным к нему MTU-s, но не отправляет другим PE-rs.
Таким образом, каждому MTU-s нужно поддерживать связь только с двумя (или одним) соседом, а количество PE-rs достаточно невелико, чтобы организовать между ними полносвязную топологию. При добавлении нового узла нужно настроить только его и вышестоящий PE-rs.
Для организации Inter-AS VPN H-VPLS тоже может сослужить службу. Например, два подключенных друг к другу ASBR могут быть PE-rs более высокого уровня иерархии.
Итак H-VPLS — это решение трёх задач:
Получается, что, введя иерархию на Control Plane мы форсировали создание иерархии и на Data Plane. Справившись с одной проблемой масштабируемости, H-VPLS создал новую. Счёт MAC-адресов в этом случае может идти на тысячи и сотни тысяч, вопрос флудинга встаёт на новом уровне, нагрузка на CPU может значительно возрасти. Но решения для этой ситуации H-VPLS не предлагает.
Впрочем, удешевление устройств уровня доступа, видимо, вполне окупает этот лёгкий дискомфорт.
Ну что, попробуем настроить?
Практика H-VPLS
Мы не будем усложнять себе жизнь резервированиями и Dual-Homing’ом. Вместо этого останемся в рамках нашей же топологии, но Linkmeup_R1 станет MTU-s, а Linkmeup_R2 — PE-rs.
Технически H-VPLS может быть реализован и на базе режима Kompella, но вот такой необходимости там нет, поэтому мы отталкиваемся от режима Martini.
Интерфейсов на Linkmeup_R2 нет, поэтому bridge-domain не нужен.
Первой командой входим в режим настройки xconnect, следующими двумя связываем AC-интерфейс и VC-канал.
ID 6310 произвольный, но должен совпадать с тем, который мы настроим на PE-rs. Здесь я выбрал 63 — как индикатор VPN ID, а 11 — порядковый номер VC на данном MTU-s.
Настройка интерфейса остаётся прежней:
Что произошло? PW поднялись:
VFI на Linkmeup_R2 про них знает:
MAC’и отлично изучает:
С H-VPLS появляется ряд вопросов, которые уже за рамками этой статьи:
А теперь пара историй о коварстве L2 c механизмом широковещательных рассылок.
Случай А
В общем-то даже не случай — а то, как обычно это всё работает.
Большой клиент, много трафика. И вот случается что-то страшное, и таблица MAC-адресов очищается. И сотни дурнопахнущих мегабит устремляются во все концы VPLS-домена. И на линиях, где раньше проходил только трафик данного филиала этого клиента, теперь летит всё-всё-всё.
Коварство этой ситуации заключается в том, что это кратковременные всплески, которые мгновенно забивают очереди QoS, вызывая потери, невзирая на ширину канала. И вы даже не увидите эти всплески в статистике интерфейса, потому что оборудование просто не успело их зафиксировать.
Случай Б
Вообще-то он уже был описан раньше, да и похож немного на Случай А. В этот раз просто дам больше деталей. Вот такая сеть:
Как видите, тут филиал крупного клиента подключен через узкий арендованный канал с полосой пропускания 100 Мб/с. И как бы ему их за глаза.
Но, случается что-то страшное и таблица MAC-адресов очищается. И весь трафик этого VSI, для которого не изучен в данный момент MAC-адрес назначения, будет широковещаться. И если, например, общий трафик этого клиента составлял 400 Мб/с, то это 400 Мб/с флуда по всей сети, которая упрётся в 100 Мб/с арендованного канала. После чего последуют кратковременные потери трафика на время переизучения MAC-ов. А для больших сетей это может занять несколько минут.
Случай В
Расширим случай Б. Теперь у нас на доступе не один клиент, а кольцо коммутаторов. И одна линия между ними выполнена в виде РРЛ-пролёта. Ситуация не такая редкая, учитывая масштабы расстояний в нашей необъятной, а, скорее, даже типичная. 
В целом, происходит всё то же, что и в случае Б, но при этом у нас здесь есть ещё какое-то решение по защите от петель: STP или какой-то проприетарный протокол. Суть их одна — заблокировать лишний порт. А если что-то не так со связностью, о которой они судят по наличию и отсутствию сообщений, разблокировать.
Теперь следующий шаг наших размышлений — флуд, который заваливает узкие линии и ведёт к потерям пакетов. Если в этом трафике большое количество высокоприоритетных пакетов CS6/CS7, то теряться будут и кадры протоколов. И тогда начинается цирк — протокол восстанавливает линк, потому что думает, что топологии хана, и что происходит? В открытый порт устремляется 100 Мб/с трафика, который усугубляет ситуацию.
Это всё может дальше и по нарастающей пойти, цепляя за собой всё большие и большие участки сети.
Случай Г
Буква эта даже немного говорящая. Потому что такой случай не может произойти просто так. Вот такая сеть.
Дизайн в данном случае предполагает, что между двумя PE прокинут дополнительный PW для сигнализации протокола защиты от петель (как и в случае В). Точнее их два — один через прямой линк, другой окольный через MPLS-сеть.
То есть мы получаем физическое кольцо коммутаторов, разделённое одним заблокированным портом.
Да, автор знает, что так сети не строят. Да, автор знает о последствиях. Нет, автор, не принимал участия в разработке дизайна.
И ещё одна деталь — в разных кольцах есть точки подключения одного и того же клиента, соответственно, в них направлен один и тот же VSI.
Теперь представьте себе ситуацию, что приехал огромный такой трактор и начал точечно погружать свой ковш в землю пока не порвал оптику сразу в двух местах. На самом деле достаточно вспомнить про плоские кольца, и ситуация уже не кажется такой невозможной.
Итак, когда обрывают сразу два конца одного кольца, PE оказывается изолированным, соответственно все его PW переходят в состояние Down, в том числе и служебный для протокола защиты от петель. Протокол думает, что кольца сейчас разомкнуты (а они действительно разомкнуты) и восстанавливает заблокированный интерфейс в обоих кольцах. Чувствуете уже засаду? у нас есть две цепочки коммутаторов, которые кончаются на двух PE и подключены к интерфейсам, привязанным к одному и тому же VSI. Два разомкнутых физических кольца срастаются в одно замкнутое логическое кольцо. И если один PE изолирован и не может навредить остальной части сети, то второй вполне себе в бою и начинает злостно рассылать широковещательный трафик.
Случай Д
Имеется сеть VPLS с двумя центральными PE. Например, это сеть DCI. ДЦ1 подключен к двум PE — так называемый Dual-Homing — режиме Active/Active — то есть оба плеча могут принимать и передавать трафик. При этом коммутация внутри не происходит — поэтому петля исключена.
Всё прекрасно, пока трафик в обоих направлениях ходит через одно и то же плечо. Интересное начинается в случае ассиметричного пути. Например, трафик к ДЦ1 приходит по левому плечу, а уходит по правому.
В целом, нормальная ситуация. Но не для L2. PE1 будет изучать MAC-адреса других ДЦ — весь такой молодец, но трафик от ДЦ1 будет приходить на PE2, который ни сном ни духом про MAC-адреса. Соответственно, он будет полученный трафик широковещать и привет ситуации А-В.
Да, часть этих проблем — это непродуманный дизайн. Да, есть те или иные «решения», которые позволяют уменьшить вероятность и серьёзность проблем, но Ethernet — как вода — просочится везде. И главная проблема — в механизме широковещательных рассылок — это ахилесова пята по всём остальном прекрасного протокола, который завоевал мир.
Сейчас, вероятно, вы думаете, что все беды на свете от L2, в том числе прошлогоднее землетрясение в Непале, и надо от него уходить, предоставляя L3VPN. Что ж, где-то вы правы. Никто не мечтает избавиться от него так, как я, который прошёл через все вышеперечисленные ситуации.
Однако это данность, от которой никуда не деться. И если мы не можем убрать корень проблемы в виде механизма широковещательной рассылки в Ethernet, то можно придумать способ с ней бороться.
О нём мы и поговорим в следующий раз — EVPN. Революционное решение, которое переносит функцию изучения MAC-адресов на Control Plane и привлекает для этого BGP.
Полезные ссылки
Аккумулирую все материалы, использовавшиеся в статье в одном месте. Аккуратно: высокая концентрация знаний.
Также напоминаю, что список лучших книг по сетям сейчас тут.
Все аббревиатуры, использованные в статье, вы можете найти в глоссарии linkmeup.
» Дмитрию Фиголю, Александру Клипперу и Дмитрию JDima за вычитку материала и комментарии.
» Антону Клочкову за организацию лабы.
» Дарье Кормановой за иллюстрации.
» Моей жене и детям, что отпустили меня в командировку, где я и сделал всё это.