Где то год назад или раньше я писал статью, посвященную routing-instance в JunOS, где описал основные виды routing инстансов, за исключением virtual switch и evpn. О последней вы можете прочитать в статье о EVPN, а вот virtual-switch пока что остался без внимания. Многие недооценивают возможности данной routing instance — а ведь функционал приличен. В данной небольшой статье мы рассмотрим — что такое virtual-switch, с чем его едят и нужен ли он вам.
Перед тем, как перейти непосредственно к обсуждению и конфигурированию виртуального свича, нам надо осветить два очень важных вопроса:
1. Метод (стиль) конфигурирования тегированного интерфейса в JunOS;
2. Что такое bridge-домен.
JunOS предоставляет нам два метода конфигурирования тегированного интерфейса, предназначенного для использования в bridge-домене:
1. Service Provider
2. Enterprise
Остановимся на них по подробнее.
Примечание: во всех примерах использованы интерфейсы с инкапсуляцией flexible-ethernet-services и тегированием flexible-vlan-tagging, что дает максимальную свободу в конфигурировании интерфейсов:
bormoglotx@RZN-PE1> show configuration interfaces ae3 apply-groups-except CORE; description "to RZN-CE1 | ae0"; flexible-vlan-tagging; encapsulation flexible-ethernet-services; aggregated-ether-options { minimum-links 1; link-speed 1g; lacp { active; periodic fast;
Service Provider.
Данный метод конфигурирования интерфейса дает нам полную свободу в манипуляциях с влан тегами, для чего используются операции pop (снятие), push (добавление), swap (замена) тега, а также операции с двумя тегами, например pop-swap производит снятие верхнего тега и замену нижнего при использовании двойного тегирования. Самый простой вариант использования данного метода создания тегированного интерфейса выглядит так:
[edit]
bormoglotx@RZN-PE1# show interfaces ae3.10
encapsulation vlan-bridge;
vlan-id 10;
Это простой тегированный интерфейс, на котором разрешен только 10 влан.
При добавлении интерфейсов, сконфигурированных таким методом в bridge-домен, в конфигурации самого bridge-домена необходимо явно указать данный интерфейс:
[edit]
bormoglotx@RZN-PE1# show bridge-domains BRIDGE-10
domain-type bridge;
vlan-id 10;
interface ae3.10;
Для манипуляции с влан тегами можно использовать vlan-maps: input-vlan-map и output-vlan-map. Для примера перепишем тег 10 на тег 20:
[edit]
bormoglotx@RZN-PE1# show interfaces ae3.10
encapsulation vlan-bridge;
vlan-id 10;
input-vlan-map {
swap;
vlan-id 20;
}
output-vlan-map swap;
При использовании vlan-map не забывайте добавлять обратное действие — то есть если вы укажете только input-vlan-map и забудете про output-vlan-map, то получите, что на прием тег будет переписываться, а на передачу нет.
Примечание: при использовании в bridge-доменах интерфейсов, сконфигурированные в Service Provider стиле с переписыванием тегов нельзя указать vlan-id, вы получите ошибку:
[edit] bormoglotx@RZN-PE1# show bridge-domains BRIDGE-10 { domain-type bridge; vlan-id 10; ## ## Warning: interface with input/output vlan-maps cannot be added to a routing-instance with a vlan-id/vlan-tags configured ## interface ae3.10;
Если вы решили применять vlan-map вам придется удалить vlan-id из bridge-домена и управлять номерами тегов на каждом интерфейсе, входящим в данный bridge-домен вручную. Но есть и более простой способ переписывания тегов, который мы рассмотрим чуть позже.
Enterprise:
Данный метод намного проще предыдущего. При конфигурировании интерфейса мы указываем что это транковый или акссесный интерфейс. Исходя из этого мы можем указать несколько тегов (если интерфейс транковый) или один (если интерфейс акссесный). Но за простоту придется заплатить например следующими недостатками — отсутствует возможность произвести перезапись внутреннего тега при QinQ — вам доступны операции только над внешним тегом или например обязательное ручное переписывание тега, если он не соответствует vlan-id в bridge-домене, в отличи от Service Provider модели. Конфигурация выглядит так:
[edit]
bormoglotx@RZN-PE1# show interfaces ae0.10
encapsulation vlan-bridge;
family bridge {
interface-mode trunk;
vlan-id-list 10;
}
В списке вланов vlan-id-list может быть указано больше одного номера влана — вплоть до 4094. Данный интерфейс не надо добавлять в bridge-домен — он будет добавлен в него автоматически, если совпадет номер влана в bridge-домене и на сконфигурированном интерфейсе. Вот например конфигурация bridge-домена с vlan-id 10:
bormoglotx@RZN-PE1> show configuration bridge-domains BRIDGE-10
domain-type bridge;
vlan-id 10;
interface ae3.10;
Интерфейс ae0.10 суда не добавлен (если вы попытаетесь это сделать — JunOS выдаст вам ошибку). А теперь посмотрим состояние нашего bridge-домена:
bormoglotx@RZN-PE1> show bridge domain BRIDGE-10
Routing instance Bridge domain VLAN ID Interfaces
default-switch BRIDGE-10 10
ae0.10
ae3.10
Интерфейс был автоматически добавлен в bridge-домен, так как его номер влана равен сконфигурированному vlan-id в bridge-домене BRIDGE-10. Если во vlan-id-list будет несколько вланов, то интерфейс тоже будет добавлен в несколько bridge-доменов
Данный метод конфигурирования интерфейса тоже позволяет манипулировать влан тегами, правда конфигурация на первый взгляд может показаться несколько запутанной.
Сделаем тоже, что и с интерфейсом ae3.10 — перепишем тег с 10 на 20:
[edit]
bormoglotx@RZN-PE1# show interfaces ae0.10
encapsulation vlan-bridge;
family bridge {
interface-mode trunk;
vlan-id-list 20;
vlan-rewrite {
translate 10 20;
}
}
Обратите внимание, что номер влана, с которым пакет будет прилетать от клиента во vlan-id-list не указывается (если укажите, JunOS выдаст ошибку). Но важнее всего запомнить, что теперь это интерфейс с vlan-id 20 а не 10, и добавляться он будет в bridge-домен с vlan-id 20, а не 10. Если у вас будет несколько вланов на одном интерфейсе (это все таки транковый интерфейс), то вы можете написать несколько правил трансляции — для каждого влана отдельно. Для тех вланов, для которых правило трансляции отсутствует — тег будет оставаться тот, с каким он прилетел от клиента (естественно если данный влан разрешен на данном интерфейсе).
Выше я показал, что данный интерфейс был автоматически прикреплен к bridge-домену BRIDGE-10 так как их номера вланов совпали. Давайте проверим теперь — остался ли данный интерфейс в данном bridge-домене или же был перемещен:
bormoglotx@RZN-PE1> show bridge domain BRIDGE-10
Routing instance Bridge domain VLAN ID Interfaces
default-switch BRIDGE-10 10
ae3.10
Интерфейс был удален из bridge-домена BRIDGE-10, так как теперь у них не соответствуют номера вланов. Давайте сменим номер влана в данном bridge-домене на 20 и проверим еще раз, добавится ли теперь ae0.10:
bormoglotx@RZN-PE1> show bridge domain BRIDGE-10
Routing instance Bridge domain VLAN ID Interfaces
default-switch BRIDGE-10 20
ae0.10
ae3.10
Как и положено, интерфейс попал в данный bridge-домен.
Примечание: мы сменили номер влана в самом bridge-домене, но вот на ae3.10 номер влана не менялся, а он все так же в bridge-домене. Это нормально и как это работает мы рассмотрим чуть позже.
Bridge-domain
Так как с методами конфигурирования интерфейсов мы разобрались, теперь перейдем непосредственно к bridge-доменам.
Bridge-домен — это совокупность логических интерфейсов, которые имеют одинаковые характеристики изучения MAC-адресов и флудинга. Bridge-домен является синонимом слова широковещательный домен. Для примера представим, что мы создали bridge-домен, состоящий из 3-х интерфейсов. При получении широковещательного кадра маршрутизатор будет флудить его во все интерфейсы, кроме того, из которого этот кадр получен (как вы понимаете это функция split-horizon), то есть в нашем случае если пакет получен из интерфейса А, то он будет отправлен в интерфейс В и С. Больше никуда маршрутизатор пакет не отправит, что и обеспечивает изоляцию одного bridge-домена от другого. В итоге мы и получаем то определение, которое написано в начале данного абзаца — изучение MAC адресов и флуд ограничены только набором интерфейсов, которые прикреплены к данному bridge-домену. При определенных обстоятельствах влан будет являться синонимом bridge-домена, но это скорее исключение нежели правило.
Создадим простой bridge-домен — по сути прокинем влан 100 между RZN-PE1 и RZN-PE2, как это изображено на схеме ниже:
Так как в данном случае конфигурация bridge-домена на обеих РЕ-ках идентична, то выводы буду приводить только с первой коробки. Для начала проверим, что сейчас у нас нет связности между RZN-CE1 и RZN-CE2 во влане 100:
bormoglotx@RZN-CE1> show configuration interfaces ae0.100
vlan-id 100;
family inet {
address 10.0.0.1/24;
}
bormoglotx@RZN-CE1> ping rapid routing-instance VR1 source 10.0.0.1 10.0.0.2
PING 10.0.0.2 (10.0.0.2): 56 data bytes
.....
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
Теперь перейдем на RZN-PE1 и добавим нужные нам интерфейсы и объединим их в bridge-домен:
[edit]
bormoglotx@RZN-PE1# show | compare
[edit interfaces ae0]
+ unit 100 {
+ description "L2 for BRIDGE100";
+ encapsulation vlan-bridge;
+ vlan-id 100;
+ }
[edit interfaces ae3]
+ unit 100 {
+ description "to VR1";
+ encapsulation vlan-bridge;
+ vlan-id 100;
+ }
[edit]
+ bridge-domains {
+ BRIDGE-100 {
+ domain-type bridge;
+ vlan-id 100;
+ interface ae0.100;
+ interface ae3.100;
+ }
+ }
Как вы помните, на RZN-PE1 интерфейс ae0 смотрит в своего брата RZN-PE2, а ae3 в сторону RZN-CE1. Аналогичный конфиг применяется и на RZN-PE2. Теперь проверим состояние нашего bridge-домена:
bormoglotx@RZN-PE1> show bridge domain BRIDGE-100 detail
Routing instance: default-switch
Bridge domain: BRIDGE-100 State: Active
Bridge VLAN ID: 100
Interfaces:
ae0.100
ae3.100
Total MAC count: 0
Все как мы планировали — в нашем домене два интерфейса и 100-й номер влана. Пока что ни одного MAC-адреса не изучено, так как между RZN-CE1/2 еще не было обмена трафиком. Исправим эту оплошность, запустив пинг между нужными нам адресами:
bormoglotx@RZN-CE1> ping rapid routing-instance VR1 source 10.0.0.1 10.0.0.2
PING 10.0.0.2 (10.0.0.2): 56 data bytes
!!!!!
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.451/6.046/13.350/3.674 ms
Теперь можем проверить, появились ли MAC-и в таблице форвардинга:
bormoglotx@RZN-PE1> show bridge domain BRIDGE-100 detail | match mac
Total MAC count: 2
bormoglotx@RZN-PE1> show bridge mac-table bridge-domain BRIDGE-100
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : default-switch
Bridging domain : BRIDGE-100, VLAN : 100
MAC MAC Logical NH RTR
address flags interface Index ID
00:05:86:71:1c:c0 D ae0.100
00:05:86:71:e5:c0 D ae3.100
Маки изучены, связность есть — все что надо — мы сделали. Хотелось бы сказать пару слов о том, что подобного результата можно было бы добиться и с помощью L2CKT. Но во-первых, L2CKT — это совершенно другой сервис, использующий MPLS как транспорт и не производящий изучение MAC-адресов (по сути труба от порта А до порта В), а во вторых, в L2CKT вы не сможете добавить третий интерфейс (придется делать VPLS), и самое главное вы не сможете прикрутить к L2CKT роутинговый интерфейс (irb) и выпустить хосты из вашего bridge-домена во внешнюю сеть. Для наглядности добавим irb интерфейс в наш bridge-домен, как это изображено на схеме:
bormoglotx@RZN-PE1# show | compare
[edit interfaces]
+ irb {
+ unit 100 {
+ description "L3 for BRIDGE-100";
+ family inet {
+ address 10.0.0.254/24;
+ }
+ }
+ }
[edit routing-instances]
+ VIRTUAL-ROUTER {
+ instance-type virtual-router;
+ interface irb.100;
+ }
[edit bridge-domains BRIDGE-100]
+ routing-interface irb.100;
Так как внутри лабы между MX-сами тоже сеть 10.0.0.0/24, то я переместил irb интерфейс в виртуальный роутер. Если бы адресация у нас не пересекалась, то можно было бы оставить данный интерфейс в GRT и тем самым выпустить хосты из нашего L2 домена во внешний мир.
Примечание: irb интерфейс не является тегированный, номер юнита выставлен в 100 для удобства администрирования. При отправке трафика в роутинговый интерфейс, с пакета снимается влан тег, если таковой присутствует.
Примечание: irb интерфейс будет активен только тогда, когда будет добавлен в bridge-домен с хотя бы одним логическим интерфейсом, находящимся в состоянии up.
Примечание: в один bridge-домен можно добавить только один роутинговый интерфейс.
Теперь запустим пинг например с RZN-CE2 на 10.0.0.254 и проверим работоспособность нашей конфигурации:
bormoglotx@RZN-CE2> ping routing-instance VR1 rapid source 10.0.0.2 10.0.0.254
PING 10.0.0.254 (10.0.0.254): 56 data bytes
!!!!!
--- 10.0.0.254 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.385/19.526/79.125/29.821 ms
Теперь немного усложним себе задачу и соберем вот такую схему:
В новом сценарии нам надо снова прокинуть L2 между нашими РЕ-ками, но вот проблема в том, что на RZN-PE1 терминируются 101 влан, а вот на RZN-PE2 — 1001 влан. Когда я писал, что при определенных условиях bridge-домен будет синонимом слова влан, то я имел ввиду случай, представленный выше (с 100-м вланом). Рассматриваемый же сейчас случай докажет вам то, что не всегда влан и bridge-домен одно и то же. Первое, о чем вы наверно подумали — что надо на каком то из интерфейсов настроить переписывание тегов, например из 1001 в 101 на RZN-PE2. Но сейчас я вам покажу, что JunOS позволит сделать нам это намного проще. Добавим на RZN-PE1 следующий конфиг:
[edit]
bormoglotx@RZN-PE1# show | compare
[edit interfaces ae0]
+ unit 101 {
+ encapsulation vlan-bridge;
+ vlan-id 101;
+ }
[edit interfaces ae3]
+ unit 101 {
+ encapsulation vlan-bridge;
+ vlan-id 101;
+ }
[edit bridge-domains]
+ BRIDGE-101 {
+ domain-type bridge;
+ vlan-id 101;
+ interface ae0.101;
+ interface ae3.101;
+ }
Как результат применение данного конфига будет появление на RZN-PE1 bridge-домена BRIDGE-101:
bormoglotx@RZN-PE1> show bridge domain BRIDGE-101
Routing instance Bridge domain VLAN ID Interfaces
default-switch BRIDGE-101 101
ae0.101
ae3.101
Теперь перейдем к конфигурации со стороны RZN-PE2:
[edit]
bormoglotx@RZN-PE2# show | compare
[edit interfaces ae0]
+ unit 101 {
+ encapsulation vlan-bridge;
+ vlan-id 101;
+ }
[edit interfaces ae3]
+ unit 1001 {
+ encapsulation vlan-bridge;
+ vlan-id 1001;
+ }
[edit bridge-domains]
+ BRIDGE-101 {
+ domain-type bridge;
+ vlan-id 101;
+ interface ae3.1001;
+ interface ae0.101;
+ }
В конфигурации никаких переписываний тегов нет, если посмотреть состояние bridge-домена, то четко видно, что интерфейс ae3.1001 находится в bridge-домене BRIDGE-101:
bormoglotx@RZN-PE2> show bridge domain BRIDGE-101
Routing instance Bridge domain VLAN ID Interfaces
default-switch BRIDGE-101 101
ae0.101
ae3.1001
По хорошему, так как у нас не сконфигрено переписывание тега, то ничего не заработает. А давайте проверим:
bormoglotx@RZN-CE1> ping rapid routing-instance VR1 source 11.0.0.1 11.0.0.2
PING 11.0.0.2 (11.0.0.2): 56 data bytes
!!!!!
--- 11.0.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.033/7.733/13.904/3.206 ms
Уже интересно — связность есть, давайте проверим таблицу форвардинга на наличие MAC адресов:
bormoglotx@RZN-PE2> show bridge mac-table bridge-domain BRIDGE-101
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : default-switch
Bridging domain : BRIDGE-101, VLAN : 101
MAC MAC Logical NH RTR
address flags interface Index ID
00:05:86:71:1c:c0 D ae3.1001
00:05:86:71:e5:c0 D ae0.101
С MAC-ми в таблице форвардинга все в порядке. Но почему появилась связность между разными вланами без конфигурирования переписывания тега? Дело в том, что это дефолтное поведение JunOS. Вернемся к конфигурации самого bridge-домена BRIDGE-101 на RZN-PE2:
bormoglotx@RZN-PE2> show configuration bridge-domains BRIDGE-101
domain-type bridge;
vlan-id 101;
interface ae3.1001;
interface ae0.101;
Все дело в указанном нами номере влана: vlan-id 101. Это работает так: для пакетов, полученных в данном bridge-домене с тегом, не соответствующим тегу 101, JunOS автоматически производит перезапись тега. Это легко увидеть на самом интерфейсе:
bormoglotx@RZN-PE2> show interfaces ae3.1001
Logical interface ae3.1001 (Index 339) (SNMP ifIndex 580)
Flags: Up SNMP-Traps 0x20004000
VLAN-Tag [ 0x8100.1001 ] In(swap .101) Out(swap .1001)
Encapsulation: VLAN-Bridge
Statistics Packets pps Bytes bps
Bundle:
Input : 6 0 556 0
Output: 6 0 570 0
Adaptive Statistics:
Adaptive Adjusts: 0
Adaptive Scans : 0
Adaptive Updates: 0
Protocol bridge, MTU: 1522
Обращаю ваше внимание на строку со следующим содержанием:
VLAN-Tag [ 0x8100.1001 ] In(swap .101) Out(swap .1001)
Эта строка указывает нам на то, какие действия будут производится с тегом на приеме из данного интерфейса ( In(swap .101) — тег меняется на 101) и при передаче в данный интерфейс ( Out(swap .1001) — тег меняется на 1001). Для примера изменю конфиг bridge-домена:
[edit]
bormoglotx@RZN-PE2# show bridge-domains BRIDGE-101
domain-type bridge;
vlan-id none;
interface ae3.1001;
interface ae0.101;
И снова посмотрим, что будет производиться с тегом на ae3.1001:
bormoglotx@RZN-PE2> show interfaces ae3.1001 | match vlan-tag
VLAN-Tag [ 0x8100.1001 ] In(pop) Out(push 0x0000.1001)
Теперь на прием тег снимается (а не переписывается), а на передачу добавляется тег 1001. Но так как интерфейс в сторону RZN-PE1 у нас тоже тегированный, то манипуляции с номерами вланов в данном случае будут и на нем (только номер влана 101):
bormoglotx@RZN-PE2> show interfaces ae0.101 | match vlan-tag
VLAN-Tag [ 0x8100.101 ] In(pop) Out(push 0x0000.101)
Думаю, что немного в bridge-доменах разобрались. Давайте теперь попробуем создать на RZN-PE1 еще один bridge-домен с влан тегом 100:
[edit]
bormoglotx@RZN-PE1# show bridge-domains
BRIDGE-100 {
domain-type bridge;
vlan-id 100;
interface ae0.100;
interface ae3.100;
}
BRIDGE-101 {
domain-type bridge;
vlan-id 101;
interface ae0.101;
interface ae3.101;
}
VLAN100 {
vlan-id 100;
}
Проверим, будет ли коммит-скрипт ругаться на новую конфигурацию:
[edit]
bormoglotx@RZN-PE1# commit check
[edit bridge-domains]
'VLAN100'
l2ald: Duplicate vlan-id exists for bridge domain BRIDGE-100
[edit bridge-domains]
Failed to parse bridge domain hierarchy completely
error: configuration check-out failed
При коммите мы получаем ошибку — данный влан уже используется в другом bridge домене. Как быть в такой ситуации?? Да, можно поставить none и все полетит, но это не решение проблемы, а костыль (хотя весь транспорт держится на костылях и затычках, но все же хочется более жизнеспособное решение). Есть более изящный способ — мы просто создадим еще одно пространство вланов, которое будет полностью изолировано от уже имеющегося. В этом то нам и поможет виртуальный свич.
Разберемся детальнее. У нас есть 4094 влана на один маршрутизатор. То есть по факту вы ограничены в создании bridge-доменов — максимум 4094 домена с номером влана. Сделать два домена с одним и тем же номером влана вам не позволит JunOS. Когда я показывал вам вывод о состоянии bridge-домена, вы наверняка заметили в этом выводе название routing-instance:
bormoglotx@RZN-PE1> show bridge domain BRIDGE-100 detail
Routing instance: default-switch
Bridge domain: BRIDGE-100 State: Active
Bridge VLAN ID: 100
Interfaces:
ae0.100
ae3.100
Total MAC count: 0
Нам интересна эта строка Routing instance: default-switch. То есть даже если вы не создавали ни одной routing-instance с типом virtual-switch, то у вас все равно будет одна такая routing-instance, которая называется default-switch. Все bridge-домены, которые я сконфигурировал раннее добавлялись именно в эту instance. Когда вы создаете routing-instance с типом virtual-switch, то вы добавляете еще одно пространство из 4094 вланов, которые никак не пересекаются и не влияют на уже используемые номера вланов. То есть делая например два виртуальных свича вы делаете возможным в пределах одного маршрутизатора создать три bridge-домена с одним и тем же номером влана, причем все эти bridge-домены будут абсолютно изолированы друг от друга. Помимо этого, если ваша топология предусматривает наличие резервных путей, которые могут привести к образованию петель, то виртуальный свич позволяет вам запускать протоколы семейства stp, правда есть ограничение — добавить вы можете только сам интерфейс, а не его юниты. И если у вас будет два виртуальных свича, в которые вы захотите добавите один и тот же интерфейс но разные юниты, то JunOS вернет вам ошибку при добавлении интерфейса в stp. Чтобы воспользоваться stp в этом случае придется использовать routing-instance layer2-control и протокол mstp.
Но на этом возможности виртуального свича не заканчиваются. В предыдущих вариантах создания bridge-домена мы использовали прямой линк между RZN-PE1 и RZN-PE2, как L2 линк и организовывали связность с помощью него. Но это не очень хорошо сказывается на отказоустойчивости, так как обрыв указанного линка разобьет наш растянутый L2 домен на две части. Чтобы этого избежать, можно воспользоваться VPLS или EVPN, причем нам не придется делать отдельную routing-instance с типом vpls или evpn — в иерархии виртуального свича можно настроить порт VPLS/EVPN и использовать его как транковый порт для организации L2 связности с удаленной PE-кой. Далее мы сконфигурируем виртуальный свич и будем использовать исключительно VPLS для связности между PE-маршрутизаторами.
Теперь мы можем перейти к созданию routing-instance с типом виртуальный свич. Мы соберем три схемы, которые будут отличаться друг от друга и покажут основные возможности bridge-доменов.
1. Bridge-домен BRIDGE-2000
2. Bridge-домен BRIDGE-2001
3. Bridge-домены BRIDGE-302 и BRIDGE-502
В первой схеме будем использовать два влана: 200 и 2000 (на RZN-PE1 будем переписывать тег 200 на 2000), во второй схеме тоже два влана: 201 и 2001 (но тут воспользуемся Service Provider методом конфигурирования интерфейса и ничего переписывать не будем — JunOS это сделает за нас), ну а в третьей схеме будем использовать три влана, вручную перепишем теги и сконфигурируем разные bridge-домены между RZN-PE1 и RZN-PE2 (один в виртуальном свиче, второй в дефолтном).
BRIDGE-2000
Схема сервиcа представлена ниже.
Сконфигрируем интерфейс на стороне RZN-PE1:
bormoglotx@RZN-PE1# show interfaces ae3.200
description "to VR2";
encapsulation vlan-bridge;
family bridge {
interface-mode trunk;
vlan-id-list 2000;
vlan-rewrite {
translate 200 2000;
}
}
Как указано на схеме, мы делаем перезапись тега с 200 на 2000. На стороне RZN-PE2 конфигурация интерфейса выглядит проще:
[edit]
bormoglotx@RZN-PE2# show interfaces ae3.2000
description "to VR2";
encapsulation vlan-bridge;
family bridge {
interface-mode trunk;
vlan-id-list 2000;
}
Теперь перейдем к созданию виртуального свича. Конфигурация будет примерна одинакова и на RZN-PE1 и на RZN-PE2, поэтому конфиг приведу только с первой РЕ-ки:
bormoglotx@RZN-PE1> show configuration routing-instances vSwitch-1
instance-type virtual-switch;
interface ae3.200;
route-distinguisher 62.0.0.1:1;
vrf-target {
import target:1:1;
export target:1:1;
}
protocols {
vpls {
site-range 2;
no-tunnel-services;
site SITE1 {
site-identifier 1;
}
}
}
bridge-domains {
BRIDGE-2000 {
vlan-id 2000;
}
}
Примечание: в конфигурации routing-instance присутствуют значения RD и RT. Это не обязательный атрибут данной routing-instance, но я использовал vpls Kompella, поэтому RD/RT мне необходимы для того, чтобы VPLS работал. Если использовать например Мартини без автодискаверинга, то указывать RT/RD указывать не надо.
Теперь проверим состояние bridge-домена BRIDGE-2000:
bormoglotx@RZN-PE1> show bridge domain instance vSwitch-1 BRIDGE-2000
Routing instance Bridge domain VLAN ID Interfaces
vSwitch-1 BRIDGE-2000 2000
ae3.200
lsi.1048832
Помимо того, что в bridge-домен автоматически был добавлен интерфейс ae3.200, сюда же был добавлен и lsi интерфейс, который и есть наш vpls порт:
Instance: vSwitch-1
Local site: SITE1 (1)
connection-site Type St Time last up # Up trans
2 rmt Up Feb 23 12:20:38 2017 1
Remote PE: 62.0.0.2, Negotiated control-word: No
Incoming label: 262146, Outgoing label: 262145
Local interface: lsi.1048832, Status: Up, Encapsulation: VPLS
Description: Intf - vpls vSwitch-1 local site 1 remote site 2
Теперь RZN-PE2 в данном bridge-домене нам доступен через VPLS порт, а не как было раннее через прямой линк. Проверим есть ли связность между нашими хостами и как обстоят дела с таблицей форвардинга:
bormoglotx@RZN-CE1> ping rapid routing-instance VR2 source 20.0.0.1 20.0.0.2
PING 20.0.0.2 (20.0.0.2): 56 data bytes
!!!!!
--- 20.0.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.571/11.609/37.058/12.731 ms
bormoglotx@RZN-PE1> show bridge mac-table instance vSwitch-1 vlan-id 2000
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : vSwitch-1
Bridging domain : BRIDGE-2000, VLAN : 2000
MAC MAC Logical NH RTR
address flags interface Index ID
00:05:86:71:1c:c0 D lsi.1048832
00:05:86:71:e5:c0 D ae3.200
Все в порядке — схема работает. Обратите внимание, что как и в дефолтном свиче в сам bridge-домен интерфейсы не добавлены — их автоматически добавит JunOS, когда будет парсить конфигурацию (так как мы использовали Enterprise стиль конфигурирования). Наше дело в данном сценарии — верно указать какие именно интерфейсы относятся к виртуальному свичу и верно указать vlan-id в bridge-домене (ну или vlan-id-range).
BRIDGE-2001
Теперь соберем схему для влана 201 и 2001.
Еще один виртуальный свич я делать не буду — просто добавлю еще один bridge-домен в vSwitch-1.Как я и сказал, будем использовать Service Provider стиль в конфигурировании интерфейсов без переписывания тегов.
Примечание: внутри виртуального свича, а так же внутри bridge-домена вам никто не запрещает использовать интерфейсы, сконфигурированные с использованием разных методов — как вам проще — так и делайте, главное потом самому не запутаться в конфигурации.
Конфигурации интерфейсов выглядят очень просто. На RZN-PE1:
[edit]
bormoglotx@RZN-PE1# show interfaces ae3.201
description "to VR2";
encapsulation vlan-bridge;
vlan-id 201;
Встречный интерфейс на стороне RZN-PE2:
[edit]
bormoglotx@RZN-PE2# show interfaces ae3.2001
description "to VR2";
encapsulation vlan-bridge;
vlan-id 2001;
Теперь добавим интерфейсы в наш виртуальный свич:
[edit]
bormoglotx@RZN-PE2# show routing-instances vSwitch-1
instance-type virtual-switch;
interface ae3.2000;
##
## Warning: Only interface with 'interface-mode' is allowed in a virtual-switch
##
interface ae3.2001;
Получили ошибку. Дело в том, что в виртуальный свич в иерархию интерфейсов (сейчас и далее имеется ввиду иерархия [edit routing-instances vSwitch-1 interface]) можно добавить только интерфейсы в режиме транка или акссеса, то есть интерфейс должен быть сконфигурирован в стиле Enterprise. Это еще одно отличие этих двух методов конфигурирования интерфейсов. Если у нас интерфейс сконфигурирован в стиле Enterprise, то мы его не можем указать в иерархии bridge-домена — интерфейс будет добавлять в bridge-домен по номеру влана. Поэтому при конфигурировании виртуального свича нам необходимо добавить в него все наши интерфейсы, которые находятся в режиме транка или аксесса — далее JunOS автоматически добавит их в нужный bridge-домен. А вот интерфейсы, сконфигурированные в стиле Service Provider необходимо указать в bridge-домене вручную. Поэтому, при конфигурировании виртуального свича такие интерфейсы в виртуальный свич в иерархию интерфейсов добавлять не надо — мы их сразу добавляем в нужный нам bridge-домен, после чего интерфейс автоматически будет привязан к виртуальному свичу, в котором находится этот bridge-домен.
[edit]
bormoglotx@RZN-PE2# show routing-instances vSwitch-1
instance-type virtual-switch;
interface ae3.2000;
route-distinguisher 62.0.0.2:1;
vrf-target {
import target:1:1;
export target:1:1;
}
protocols {
vpls {
site-range 2;
no-tunnel-services;
site SITE2 {
site-identifier 2;
}
}
}
bridge-domains {
BRIDGE-2000 {
vlan-id 2000;
}
BRIDGE-2001 {
vlan-id 2001;
interface ae3.2001;
}
}
Примечание: VPLS или EVPN порт является транковым портом и пропускает все вланы и будет добавлен во все bridge домены автоматически.
Конфигурация на RZN-PE1 аналогична RZN-PE2 (только другой интерфейс добавлен в bridge-домен), поэтому показывать ее я не буду. Проверим состояние bridge-доменов на обеих РЕ-ках:
bormoglotx@RZN-PE1> show bridge domain instance vSwitch-1 BRIDGE-2001 detail
Routing instance: vSwitch-1
Bridge domain: BRIDGE-2001 State: Active
Bridge VLAN ID: 2001
Interfaces:
ae3.201
lsi.1048832
Total MAC count: 0
bormoglotx@RZN-PE2> show bridge domain instance vSwitch-1 BRIDGE-2001 detail
Routing instance: vSwitch-1
Bridge domain: BRIDGE-2001 State: Active
Bridge VLAN ID: 2001
Interfaces:
ae3.2001
lsi.1048832
Total MAC count: 0
Проверим, что на ae3.201 происходит перезапись тегов:
bormoglotx@RZN-PE1> show interfaces ae3.201 | match vlan-tag
VLAN-Tag [ 0x8100.201 ] In(swap .2001) Out(swap .201)
И для проверки запустим пинг между нашими хостами и проверим таблицу форвардинга:
bormoglotx@RZN-CE1> ping rapid routing-instance VR2 source 21.0.0.1 21.0.0.2
PING 21.0.0.2 (21.0.0.2): 56 data bytes
!!!!!
--- 21.0.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 7.026/9.563/15.398/3.000 ms
bormoglotx@RZN-PE1> show bridge mac-table instance vSwitch-1 vlan-id 2001
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : vSwitch-1
Bridging domain : BRIDGE-2001, VLAN : 2001
MAC MAC Logical NH RTR
address flags interface Index ID
00:05:86:71:1c:c0 D lsi.1048832
00:05:86:71:e5:c0 D ae3.201
Ну и для полноты картины добавим в наш виртуальный свич роутинговый интерфейс:
[edit]
bormoglotx@RZN-PE1# show | compare
[edit interfaces irb]
+ unit 2001 {
+ description "L3 for BRIDGE-2001 | vSwitch-1";
+ family inet {
+ address 21.0.0.254/24;
+ }
+ }
[edit routing-instances vSwitch-1 bridge-domains BRIDGE-2001]
+ routing-interface irb.2001;
Примечание: роутинговый интерфейс добавляется сразу в нужный нам bridge-домен виртуального свича, в иерархию интерфейсов виртуального свича данный интерфейс добавлять не надо.
Теперь проверим доступность irb интерфеса с RZN-CE2:
bormoglotx@RZN-CE2> ping routing-instance VR2 rapid source 21.0.0.2 21.0.0.254
PING 21.0.0.254 (21.0.0.254): 56 data bytes
!!!!!
--- 21.0.0.254 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.369/10.704/36.307/12.813 ms
Связность есть, а в таблице форвардинга на RZN-PE2 появился MAC адрес irb интерфейса, который логично виден через VPLS порт:
bormoglotx@RZN-PE2> show bridge mac-table instance vSwitch-1
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : vSwitch-1
Bridging domain : BRIDGE-2001, VLAN : 2001
MAC MAC Logical NH RTR
address flags interface Index ID
00:05:86:71:17:c0 D ae3.2001
00:05:86:71:26:c0 D lsi.1048576
00:05:86:71:8d:f0 D lsi.1048576
Для справки приведу MAC-адрес irb интерфейса с RZN-PE1:
bormoglotx@RZN-PE1> show interfaces irb | match current
Current address: 00:05:86:71:8d:f0, Hardware address: 00:05:86:71:8d:f0
BRIDGE-302>>>BRIDGE-502
И в заключении соберем схему, в которой будем производить перезапись тегов вручную:
Со стороны RZN-PE1 у нас bridge-домен DOMAIN-302, который находится в виртуальном свиче vSwitch-2:
[edit]
bormoglotx@RZN-PE1# show | compare
[edit interfaces ae0]
+ unit 900 {
+ encapsulation vlan-bridge;
+ vlan-id 900;
+ input-vlan-map pop;
+ output-vlan-map push;
+ }
[edit interfaces ae3]
+ unit 302 {
+ encapsulation vlan-bridge;
+ vlan-id 302;
+ input-vlan-map pop;
+ output-vlan-map push;
+ }
[edit routing-instances]
+ vSwitch-2 {
+ instance-type virtual-switch;
+ bridge-domains {
+ DOMAIN-302 {
+ interface ae3.302;
+ interface ae0.900;
+ }
+ }
+ }
Из конфигурации видно, что на приеме будет производиться снятие тега, и, что логично, на передачу — навешивание тега — ничего сложного.
Со стороны RZN-PE2 у нас будет просто bridge-домен BRIDGE-502 без создания виртуального свича (то есть будет находиться в дефолтном свиче):
bormoglotx@RZN-PE2# show | compare
[edit interfaces ae0]
+ unit 900 {
+ encapsulation vlan-bridge;
+ vlan-id 900;
+ input-vlan-map pop;
+ output-vlan-map push;
+ }
[edit interfaces ae3]
+ unit 502 {
+ encapsulation vlan-bridge;
+ vlan-id 502;
+ input-vlan-map pop;
+ output-vlan-map push;
+ }
[edit bridge-domains]
+ BRIDGE-502 {
+ domain-type bridge;
+ interface ae3.502;
+ interface ae0.900;
+ }
Естественно и тут мы снимаем при приеме, и навешиваем при передаче влан теги.
В конечном счете наши bridge-домены на PE1/2 имеют такое состояние:
bormoglotx@RZN-PE1> show bridge domain instance vSwitch-2
Routing instance Bridge domain VLAN ID Interfaces
vSwitch-2 DOMAIN-302 NA
ae0.900
ae3.302
bormoglotx@RZN-PE2> show bridge domain BRIDGE-502
Routing instance Bridge domain VLAN ID Interfaces
default-switch BRIDGE-502 NA
ae0.900
ae3.502
Вместо vlan-id у нас стоит NA — так как vlan-id не мной определен, так как я вручную перисываю теги на интерфейсах и задать это значение не могу. Для примера информация о произведении манипуляций с влан тегами с RZN-PE1:
bormoglotx@RZN-PE1> show interfaces ae3.302 | match vlan-tag
VLAN-Tag [ 0x8100.302 ] In(pop) Out(push 0x0000.302)
bormoglotx@RZN-PE1> show interfaces ae0.900 | match vlan-tag
VLAN-Tag [ 0x8100.900 ] In(pop) Out(push 0x0000.900)
Теперь запустим пинг между хостами и проверим, есть ли у нас связность:
bormoglotx@RZN-CE1> ping routing-instance VR3 source 32.0.0.1 32.0.0.2 rapid
PING 32.0.0.2 (32.0.0.2): 56 data bytes
!!!!!
--- 32.0.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.982/6.443/7.162/0.432 ms
В таблицах форвардинга появились MAC-адреса:
bormoglotx@RZN-PE1> show bridge mac-table instance vSwitch-2
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : vSwitch-2
Bridging domain : DOMAIN-302, VLAN : NA
MAC MAC Logical NH RTR
address flags interface Index ID
00:05:86:71:56:c0 D ae3.302
00:05:86:71:ed:c0 D ae0.900
Правда в таком bridge-домене (без указания vlan-id) есть очень важное ограничение — в данный bridge-домен нельзя добавить роутинговый интерфейс. При попытке это сделать вы получите ошибку:
[edit]
bormoglotx@RZN-PE1# commit
[edit routing-instances vSwitch-2 bridge-domains DOMAIN-302 routing-interface]
'routing-interface irb.302'
routing-interface can be configured only under bridge-domain with 'vlan-id' or 'vlan-tags'
error: commit failed: (statements constraint check failed)
Это может стать очень большой проблемой если L2 домен сильно разрастется и вдруг понадобится его выпустить во внешний мир — слишком много конфига придется в таком случае переписать. Поэтому использовать последнюю модель не рекомендуется, я же ее собрал только для демонстрации возможности bridge-домена в JunOS.
Вот собственно и все, что я хотел рассказать. Пытался объяснить все как можно проще, надеюсь, что читателю все понятно. Если есть какие то дополнения/замечания — пишите поправим/добавим. Спасибо за внимание!
P.S> В статье не стал затрагивать некоторые важные темы, такие как несколько learning-доменов в одном bridge-домене (для неподготовленного человека это будет взрыв мозга), указание диапазона вланов для bridge-домена и тд. Эти темы хорошо описаны в книге Juniper MX-Series-Trio (книга на английском) — если вам интересна эта тема — то данная книга будет отличным учебным пособием.
Комментарии (0)