Кратко про первый вид сервиса в MPLS L2VPN я уже писал в посте про VLL. Конечно же понятно, что абоненту не всегда нужна труба точка-точка, зачастую абонент хочет развитую сеть точка-многоточка или скорее многоточка-многоточка. В таком случае, на сцену выходит Virtual Private LAN Service (VPLS)
Концепция VPLS умещается в пару строк и в состоянии предоставить клиенту виртуальную Ethernet сеть. В таком случае, сеть провайдера для абонента выглядит как один большой коммутатор. Этот коммутатор, как и любой другой, может понимать теги VLAN, обычно такой коммутатор знает что делать с двумя тегами VLAN (QinQ) или, скажем, умеет VLAN трансляцию. Более того, "большой коммутатор" может даже участвовать в клиентском STP или быть членом Link Aggregation Group. Об этом я напишу в посте про обеспечение отказоустойчивости в MPLS.
Все посты про MPLS VPN можно посмотреть по тегу MPLS или в обобщающем посте.
Рассмотрим базовую архитектуру подробнее. В ней все так же присутствует PSN (созданный LDP, RSPV-TE или GRE). Поверх PSN строятся pseudowire туннели (T-LDP) для каждого сервиса VPLS. В базовом варианте, в ядре провайдера pseudowire туннели должны строиться от каждого PE роутера до каждого, образовывая так называемый full-mesh (соединение по принципу "каждый с каждым"). К каждому PE подключен абонентский роутер (CE). VPLS сервис обеспечивает связность всех CE стройств.
Трафик в MPLS сети проходит ряд довольно очевидных этапов. Рассмотрим простой пример, когда в только что сконфигурированной VPLS сети побежал первый пакет.
По сути, H-VPLS чисто технически отличается от обычного VPLS только введением нового типа pseudowire, который называется "spoke pseudowire". Этот тип отличается от обычного pseudowire туннеля в VPLS лишь отсутствием split horizon правила.
В обычном VPLS, трафик из pseudowire ("mesh pseudowire") не может быть отправлен в другую "mesh pseudowire". В H-VPLS, таковых ограничений нет, трафик из spoke pseudowire может быть отправлен в другую spoke pseudowire, в точку подключения абонента или в mesh pseudowire. В общем, если придерживаться визуализации с коммутатором и проводами, то mesh-pseudowire подключена к этому виртуальному коммутатору обычным проводом в порт, который действует как порт на обычном коммутаторе. А вот порт в который подключен mesh pseudowire туннель имеет на себе ряд ограничений в виде split horizon.
Наверное, на примерах будет понятнее. Рассмотрим сеть, в которой введен иерархический дизайн. Все PE маршрутизаторы теперь не обязаны иметь pseudowire до каждого другого PE.
Теперь среди PE выбрано три hub-PE, которые агрегируют spoke pseudowire туннели с spoke PE. Все hub-PE по прежнему имеют pseudowire-подключения по принципу каждый с каждым. Все pseudowire в ядре настроены как mesh pseudowire, что инструктирует VSI придерживаться правила split horizon в отношении таких туннелей. Трафик пришедший из такого туннеля не может быть отправлен в другой такой же. Это обеспечивает более ровное распределение трафика в ядре, неплохую отказоустойчивость и защиту от колец/петель.
Все spoke-PE теперь подключены всего одним spoke pseudowire к ближайшему hub-PE. Это существенно уменьшает количество туннелей, упрощает настройку, в случае добавления нового spoke-PE, ну и отказоустойчивость, конечно, чуть страдает (об этом как-нибудь в другой раз). Hub-PE имеет spoke pseudowire в сторону абонентов и mesh pseudowire в сторону ядра. Spoke pseudowire направлены в сторону абонентов и VSI не применяет правило split horizon на них. Т.е. трафик пришедший к hub-PE из одной spoke pseudowire вполне может быть отправлен в другую spoke pseudowire. Это штатный случай.
Ясно, что защита от петель тут достигается нормальным дизайном и правильной конфигурацией. Наряду со страдающей отказоустойчивостью, выбор между H-VPLS и обычным VPLS всегда вопрос баланса.
Определение spoke или mesh pseudowire носит локальный характер, по сути это всего лишь соответствуюшая настройка VSI, который выключает split horizon на spoke туннелях. Однако его можно включить назад, объединив несколько spoke pseudowire в группу. Таким образом получится некий аналог Private VLAN. Трафик из одной spoke pseudowire не будет передан в другую spoke pseudowire. Может быть клиент захотел такую топология, в которой его офисы не должны общаться напрямую, а весь трафик должен проходить через его центральный офис, в котором стоит файервол.
Spoke pseudowire используются и в другом случае, когда нужно соединить два VPLS домена с разграничением ответственности. Скажем у нас есть два VPLS домена, которые по каким-то причинам управляются разными отделами/компаниями. В таком случае, выбираются некие "пограничные" PE роутеры, которые соединяются с помощью spoke pseudowire между собой. В итоге из одного VPLS домена не видно топологию другого VPLS домена. Весь трафик приходит через один spoke pseudowire. Если нужно отправить трафик клиенту в другой VPLS домен, то выбор прост и очевиден, отправляем трафик в spoke pseudowire и все.
Вообще, имея сеть с MPLS для каждого клиента можно и, в некоторых случаях, даже нужно выбирать подходящую топологию под каждого абонента. Для кого-то будет лучше строить обычный VPLS (если мало точек подключения и критично "качественное" прохождение трафика), для кого-то нужно строить H-VPLS (точек много, но оптимальность прохождения трафика не так важна).
Пока все.
Хотя нет, не все.
Возможно, читая все эти многобуквы, у вас возникло чувство некоего дискомфорта в душе. И это абсолютно правильно, ведь все приходится настраивать руками... Фу... Сначала нужно настроить PSN туннели (GRE, LDP, RSVP-TE), потом поверх них нужно настроить pseudowire туннели, сконфигурировать на каждой ноде VSI сущность. Все это можно автоматизировать с помощь...
Нода R1 экспортирует из VPLS RT 65000:1 и импортирует в него RT 65000:2, 65000:3, 65000:4
Таким образом, когда по сети разойдутся BGP апдейты, R2 увидит необходимость построить pseudowire до R1, аналогично R2 и R3. А к R1 придут сообщения с RT 65000:2 от R2, 65000:3 от R3 и 65000:4 от R4, что говорит ему построить pseudowire до них.
Тема MP-BGP сложна, многогранна и монструозна. Настоятельно рекомендую к прочтению статью по L3VPN от ребят из linkmeup.ru.
Процесс адаптации PBB для VPLS просто убивает своей терминологией. Весь VPLS домен разделяется на две части. Одна часть смотрит в сторону клиента и носит название Edge Domain или Interface Domain (I-domain), вторая часть ассоциируется с ядром сети и носит название Backbone Domain (B-domain). Граница между доменами обычно проходит по hub-PE устройствам, которые агрегируют pseudowire c spoke-PE, которые уже подключены к клиенту. Такие hub-PE носят название IB-PE. На них настраивается фактически два VPLS инстанса с двумя разными VSI. Один (I-VPLS) подключен к обычной VPLS сети, где ещё бегают клиентские MACи, другой (B-VPLS) подключен в ядро, в котором коммутация происходит по новому заголовку. Все роутеры в ядре изучают только MAC адреса в новом заголовке. Есть и другой принцип, когда I-VPLS и B-VPLS располагаются на разных устройствах, но мы умеренно проигнорируем этот факт.
Трафик по такой сети ходит довольно причудливо.
1. Кадры от PE1 до ближайшего IB-PE1 ходят аналогично H-VPLS. Попадая на IB-PE, трафик сначала передается на VSI на I-VPLS инстанс. Тот изучает MAC клиента, смотрим в FDB и находит там (если ARP уже прошли) MAC адрес клиента, который "светится" со стороны B-VPLS.
2. I-VPLS производит PBB инкапсуляцию. На кадр навешивается ещё один заголовок, в качестве MAC адреса источника используется специальный сконфигурированный MAС, а в качестве назначения такой же специальный MAC со стороны IB-PE2. Далее трафик отправляется на B-VPLS в пределах одного устройства IB-PE1.
3. VSI в B-VPLS изучает тот самый специальный MAC адрес со стороны I-VPLS, смотрит в свою FDB и видит, что адрес источника известен ему через pseudowure до IB-PE2. B-VPLS навешивает MPLS заголовки и отправляет трафик по pseudowire.
4. IB-PE2 получает трафик, отбрасывате MPLS заголовки и передает кадры на B-VPLS. Тот изучает MAC (тот самый специальный), смотрит в FDB, находит там MAC назначения, который светится на I-VPLS и передает ему трафик по внутреннему линку.
5. I-VPLS на IB-PE2 отбрасывает PBB заголовок, смотрит в FDB, находит там MAC адрес назначения (уже клиентский) и понимает, что надо отправить трафик в сторону PE2, уже "чистым" MPLSом.
В итоге, обычный Ethernet-трафик клиента, допустим даже без тегов, проходя через MPLS ядро, претерпевает множество инкапсуляций. На него навешивается новый заголовок PBB, сервисная и транспортная метки, после чего трафик попадает в сеть, в которой на него могут быть навешены ещё метки в случае FRR, например.
В ядре провайдера кадр будет выглядеть например так (часть полей не учитываем). Нарисуем HTML-табличку в стиле Web1.0...
Вот теперь все...
Все посты про MPLS VPN можно посмотреть по тегу MPLS или в обобщающем посте.
Единственный отличием, пожалуй, здесь будет только Virtual Switching Instance (VSI) и некоторый тюнинг T-LDP. Про T-LDP все просто, теперь T-LDP передает сообщение MAC-flush, что приводит к сбросу FDB таблиц на всех VSI в данном VPLS. А вот про VSI ниже.
VSI выполняет все функции по коммутации трафика внутри VPLS сети. А именно:
VPLS не уступает VLL в гибкости точек подключения клиентов. Как и в Epipe, attachment circuit может быть настроен на прием тегированных Ethernet кадров от заказчика (в том числе и несколькими метками), ATM кадров, Frame Relay и, скорее всего, чего-нибудь ещё.
VSI
VSI - это то, что делает VPLS випиэлэсом. Эта виртуальная сущность выполняет роль коммутатора на каждом PE роутере. Для каждого сервиса на роутере создается отдельный VSI. Тут можно проследить некую аналогию с VRF в L3VPN. Можно представить VSI как коммутатор внутри устройства в порты которого воткнуты провода идущие к точками подключения и pseudowire. На картинке выше я попытался это изобразить.VSI выполняет все функции по коммутации трафика внутри VPLS сети. А именно:
- VSI составляет таблицу FDB и оперирует с ней. Добавляет туда новые записи при поступлении первого фрейма, удаляет устаревшие записи и все прочее.
- Основываясь на FDB, VSI принимает решение о том куда отправить тот или иной трафик. Это касается рассылки unknown-unicast кадров, рассылку broadcast и multicast трафика.
VPLS не уступает VLL в гибкости точек подключения клиентов. Как и в Epipe, attachment circuit может быть настроен на прием тегированных Ethernet кадров от заказчика (в том числе и несколькими метками), ATM кадров, Frame Relay и, скорее всего, чего-нибудь ещё.
Трафик в MPLS сети проходит ряд довольно очевидных этапов. Рассмотрим простой пример, когда в только что сконфигурированной VPLS сети побежал первый пакет.
- Клиент A решает отправить Ethernet-кадр клиенту B.
- Клиент А отправляет ARP-запрос на широковещательный адрес сети.
- Этот запрос идет по сети абонента и рано или поздно покидает CE1. Допустим кадр имеет всего одну метку VLAN 30.
- Запрос доходит до PE1 маршрутизатора, который по метке 30 понимает, что это трафик для сервиса VPLS 300.
- PE1 отбрасывает метку 30 и отдает трафик на инспекцию VSI.
- VSI записывает исходящий MAC-адрес в таблицу FDB и осознает, что это broadcast трафик, он должен быть направлен в сторону всех возможных получателей, которые находятся за PE2 и PE3.
- PE1 отправляет трафик через установленные pseudowire в сторону PE2 и PE3, для этого он:
- Сверху трафика (с которого он снял метку VLAN30) лепит pseudowire метку, которую он согласовал с PE2
- Сверху лепит ещё одну транспортную метку, которая используется в ядре (PSN) и отправляет кадр в сторону PE2.
- Тоже самое он делает и для PE3.
- PE2 получив такой кадр, отбрасывает первую транспортную метку (потому что он является выходящей точкой из туннеля), видит ещё метку, отбрасывает вторую метку (потому как PE2 является выходом из pseudowire).
- PE2 отдает трафик VSI.
- VSI изучает MAC адрес компьютера А, понимает, что это broadcast кадр и он должен быть отправлен только в сторону клиента, здесь действует split horizon правило (PE2 не будет отправлять этот трафик в pseudowire до PE3)
- Попадая на порт в сторону CE21, роутер в соответствии с настройками точки подключения вешает на кадр метку 30 и ещё одну метку 300 (абонент так захотел, что сказать).
- Попадая на порт в сторону CE22, роутер отдает трафик нетегированным.
- Аналогичный кадр попадает и на PE3. Он так же снимает все метки, консультируется с VSI и понимает, что трафик должен быть отправлен в сторону клиентов. Таковых, увы, нет на PE3 и трафик просто сбрасывается, обратно в pseudowire туннели он не уйдет.
- Трафик рано или поздно доходит до устройств B и С. Последний просто игнорирует его, а устройство В отвечает ARP-ответом.
Hierarchical VPLS
Везде где есть топология каждый с каждым есть проблема с огромным количеством "линков", посчитать которые можно формулой n(n-1)/2. В итоге была придумана концепция H-VPLS, которая немного сокращала число линков частично избавляя от full mesh топологии.По сути, H-VPLS чисто технически отличается от обычного VPLS только введением нового типа pseudowire, который называется "spoke pseudowire". Этот тип отличается от обычного pseudowire туннеля в VPLS лишь отсутствием split horizon правила.
В обычном VPLS, трафик из pseudowire ("mesh pseudowire") не может быть отправлен в другую "mesh pseudowire". В H-VPLS, таковых ограничений нет, трафик из spoke pseudowire может быть отправлен в другую spoke pseudowire, в точку подключения абонента или в mesh pseudowire. В общем, если придерживаться визуализации с коммутатором и проводами, то mesh-pseudowire подключена к этому виртуальному коммутатору обычным проводом в порт, который действует как порт на обычном коммутаторе. А вот порт в который подключен mesh pseudowire туннель имеет на себе ряд ограничений в виде split horizon.
Теперь среди PE выбрано три hub-PE, которые агрегируют spoke pseudowire туннели с spoke PE. Все hub-PE по прежнему имеют pseudowire-подключения по принципу каждый с каждым. Все pseudowire в ядре настроены как mesh pseudowire, что инструктирует VSI придерживаться правила split horizon в отношении таких туннелей. Трафик пришедший из такого туннеля не может быть отправлен в другой такой же. Это обеспечивает более ровное распределение трафика в ядре, неплохую отказоустойчивость и защиту от колец/петель.
Все spoke-PE теперь подключены всего одним spoke pseudowire к ближайшему hub-PE. Это существенно уменьшает количество туннелей, упрощает настройку, в случае добавления нового spoke-PE, ну и отказоустойчивость, конечно, чуть страдает (об этом как-нибудь в другой раз). Hub-PE имеет spoke pseudowire в сторону абонентов и mesh pseudowire в сторону ядра. Spoke pseudowire направлены в сторону абонентов и VSI не применяет правило split horizon на них. Т.е. трафик пришедший к hub-PE из одной spoke pseudowire вполне может быть отправлен в другую spoke pseudowire. Это штатный случай.
Ясно, что защита от петель тут достигается нормальным дизайном и правильной конфигурацией. Наряду со страдающей отказоустойчивостью, выбор между H-VPLS и обычным VPLS всегда вопрос баланса.
Определение spoke или mesh pseudowire носит локальный характер, по сути это всего лишь соответствуюшая настройка VSI, который выключает split horizon на spoke туннелях. Однако его можно включить назад, объединив несколько spoke pseudowire в группу. Таким образом получится некий аналог Private VLAN. Трафик из одной spoke pseudowire не будет передан в другую spoke pseudowire. Может быть клиент захотел такую топология, в которой его офисы не должны общаться напрямую, а весь трафик должен проходить через его центральный офис, в котором стоит файервол.
Spoke pseudowire используются и в другом случае, когда нужно соединить два VPLS домена с разграничением ответственности. Скажем у нас есть два VPLS домена, которые по каким-то причинам управляются разными отделами/компаниями. В таком случае, выбираются некие "пограничные" PE роутеры, которые соединяются с помощью spoke pseudowire между собой. В итоге из одного VPLS домена не видно топологию другого VPLS домена. Весь трафик приходит через один spoke pseudowire. Если нужно отправить трафик клиенту в другой VPLS домен, то выбор прост и очевиден, отправляем трафик в spoke pseudowire и все.
Пока все.
Хотя нет, не все.
Возможно, читая все эти многобуквы, у вас возникло чувство некоего дискомфорта в душе. И это абсолютно правильно, ведь все приходится настраивать руками... Фу... Сначала нужно настроить PSN туннели (GRE, LDP, RSVP-TE), потом поверх них нужно настроить pseudowire туннели, сконфигурировать на каждой ноде VSI сущность. Все это можно автоматизировать с помощь...
BGP-Auto Discovery (BGP AD)
Принцип использования MG-BGP в L2VPN VPLS примерно такой же как и в L3VPN VPRN. Настроив на каждом PE роутере BGP-AD, мы получаем возможность динамически добавлять в определенный VPLS определенные ноды, поднимать транспортные (PSN) туннели согласно определенным шаблонам и затем сигнализировать по другим шаблонам pseudowire до нужных PE через них. Короче, все круто. Обычно, есть ряд ограничений связанных с использование с BGP-AD. Тот же Алкатель, к примеру, не может сигнализировать PSN использую RSVP-TE, поэтому их главная рекомендация - настраивать необходимые PSN руками, а BGP-AD уже будет создать psewdowire по шаблонам.
BGP AD оперирует двумя сущностями Route Target(RT) и Route Distiguisher(RD). С помощью настроенного импорта/экспорта этих значений в VPLS, мы можем строить различные VPLS топологии.
Если вы хоть раз сталкивались с RT и RD, то вы точно знаете, что тема их различия у многих вызывает конфуз. На столько у многих, что даже в некоторых учебных материалах просто игнорируют эту тему. Было у меня как-то собеседование, на котором я начал хвалится своими рыгалиями, на что интервьювер отреагировал примерно так:"Это все понятно. А вот в чем отличие RT от RD, вы знаете?".
Если очень кратко отвечать на этот вопрос и не вдаваться в технические подробности, например, какое значение передается в extended community, а что в NLRI, то:
Если очень кратко отвечать на этот вопрос и не вдаваться в технические подробности, например, какое значение передается в extended community, а что в NLRI, то:
- Route Distinguisher (RD) - значение, которое использует BGP для того чтобы сделать все маршруты (NLRI) в сети уникальными. Получая NLRI, BGP добавляет к нему RD для того чтобы получить уникальный NLRI. Пример из L3VPN, есть у BGP префикс 192.168.0.0/24, который пришел от клиента. Есть такой же префикс, который пришел от другого клиента. BGP добивает к ним RD в соответствии с тем, из какого VPN пришли префиксы, и получаем две уникальных сущности 65000:1:192.168.0.0/24 и 6500:2:192.168.0.0/24. RD - имеет локальный характер.
- Route Target (RT) - даже из названия понятно, что у RT совсем не локальный характер. Это некая метка для удаленного устройства, с помощью которой он решит в какой VPN засунуть маршрут. Манипулирую с импортом/экспортом различных значений RT, мы можем строить причудливые топологии в L2 и L3 VPN.
Допустим, у нас есть сеть из четырех маршрутизаторов, на каждом настроен BGP-AD c VPLS100. Мы хотим построить типичную hub-and-spoke топологию. R1 должен иметь связность с R2, R3 и R4, которые должны общаться только через центральную ноду R1. Сделать мы это можем с помощью манипулирования с RT, импорта и экспорта его в VPLS инстанс.
Нода R1 экспортирует из VPLS RT 65000:1 и импортирует в него RT 65000:2, 65000:3, 65000:4
Нода R2 экспортирует из VPLS RT 65000:2 и импортирует в него RT 65000:1
Нода R3 экспортирует из VPLS RT 65000:3 и импортирует в него RT 65000:1
Нода R4 экспортирует из VPLS RT 65000:4 и импортирует в него RT 65000:1
Добавляя определенные RT в импорт или экспорт, мы получаем возможность строить различные топологии. Например, добавим ещё один роутер R5. Путь этот роутер должен построить pseudowire до R1 и R2. Ок. Пусть он экспортит RT 65000:5 и импортит RT 65000:1 и 65000:2. На нодах R1 и R2 нужно добавить 65000:5 на импорт и соответсвубщие pseudowire сигнализируются.
Provider Backbone Bridge (PBB) 802.1ah
Мы уже рассмотрели как в VPLS была решена проблема многочисленных pseudowire (H-VPLS) и необходимости ручной настройки (BGP-AD). Пришло время решить ещё одну проблему, которая связана с количеством MAC адресов в VPLS сети. Помним, что VSI на каждом роутере участвующим в VPLS изучает MAC-адреса клиентов. Количество их может быть довольно большим, если не сказать огромным, если провайдер предоставляет несколько сервисов VPLS большим клиентам.
PBB придумывался как средство для уменьшения MAC-адресов в сети и позднее был добавлен в VPLS. В PBB есть два типа устройств:
- Backbone Edge Brindge (BEB) - добавляет к клиентскому трафику ещё один заголовок, в котором содержится:
- Instance TAG - позволяет идентифицировать клиента, по характеру похож на сервисную метку pseudowire в MPLS. В VPLS по I-TAG роутер понимает в какой VPLS инстанс засунуть трафик.
- Backbone VLAN (B-VID) - VLAN тэг, который позволяет разделить PBB сеть на сегменты.
- Backbone Source Address (B-SA) - MAC адрес источника в PBB сети
- Backbone Destination Address (B-DA) - MAC адрес назначения в PBB сети
- Backbone Brindge (BB) - коммутируют трафик глядя только на B-VID, B-SA и B-DA. Это позволяет существенно сократить FDB таблицу на BB устройствах.
PBB - это такая Ethernet сеть для Ethernet сетей. В чем-то есть схожесть с MPLS или TRILL. Сама суть проста - к абонентскому трафику (а это может быть и QinQ, к примеру) добавляем ещё VLAN и пару MAC адресов, дальнейшая обработка трафика будет происходить по ним.
Процесс адаптации PBB для VPLS просто убивает своей терминологией. Весь VPLS домен разделяется на две части. Одна часть смотрит в сторону клиента и носит название Edge Domain или Interface Domain (I-domain), вторая часть ассоциируется с ядром сети и носит название Backbone Domain (B-domain). Граница между доменами обычно проходит по hub-PE устройствам, которые агрегируют pseudowire c spoke-PE, которые уже подключены к клиенту. Такие hub-PE носят название IB-PE. На них настраивается фактически два VPLS инстанса с двумя разными VSI. Один (I-VPLS) подключен к обычной VPLS сети, где ещё бегают клиентские MACи, другой (B-VPLS) подключен в ядро, в котором коммутация происходит по новому заголовку. Все роутеры в ядре изучают только MAC адреса в новом заголовке. Есть и другой принцип, когда I-VPLS и B-VPLS располагаются на разных устройствах, но мы умеренно проигнорируем этот факт.
Трафик по такой сети ходит довольно причудливо.
2. I-VPLS производит PBB инкапсуляцию. На кадр навешивается ещё один заголовок, в качестве MAC адреса источника используется специальный сконфигурированный MAС, а в качестве назначения такой же специальный MAC со стороны IB-PE2. Далее трафик отправляется на B-VPLS в пределах одного устройства IB-PE1.
3. VSI в B-VPLS изучает тот самый специальный MAC адрес со стороны I-VPLS, смотрит в свою FDB и видит, что адрес источника известен ему через pseudowure до IB-PE2. B-VPLS навешивает MPLS заголовки и отправляет трафик по pseudowire.
4. IB-PE2 получает трафик, отбрасывате MPLS заголовки и передает кадры на B-VPLS. Тот изучает MAC (тот самый специальный), смотрит в FDB, находит там MAC назначения, который светится на I-VPLS и передает ему трафик по внутреннему линку.
5. I-VPLS на IB-PE2 отбрасывает PBB заголовок, смотрит в FDB, находит там MAC адрес назначения (уже клиентский) и понимает, что надо отправить трафик в сторону PE2, уже "чистым" MPLSом.
В итоге, обычный Ethernet-трафик клиента, допустим даже без тегов, проходя через MPLS ядро, претерпевает множество инкапсуляций. На него навешивается новый заголовок PBB, сервисная и транспортная метки, после чего трафик попадает в сеть, в которой на него могут быть навешены ещё метки в случае FRR, например.
В ядре провайдера кадр будет выглядеть например так (часть полей не учитываем). Нарисуем HTML-табличку в стиле Web1.0...
| Хвост транспортного заголовка | FCS |
|---|---|
| Оригинальный кадр абонента | Полезная нагрузка |
| С-VID (если есть QinQ) | |
| S-VID (если есть QinQ) | |
| Source MAC address | |
| Destination MAC address | |
| PBB | Instance TAG (I-TAG) |
| Backbone Vlan ID (B-LID) | |
| Backbone Source Address (B-SA) | |
| Backbone Destination Address (B-DA) | |
| MPLS | Service Label |
| Transport Label | |
| FRR | Bypass Tunnel Label |
| Заголовок транспортного уровня | Link Source Address |
| Link Destination Address |
Комментариев нет:
Отправить комментарий