# Лаборатория для тестов и конфигурации Для тестов я использовал [Unetlab](http://www.unetlab.com/), в которой собрал стенд из четырех [vMX](http://www.juniper.net/us/en/products-services/routing/mx-series/vmx/) и трех Cisco IOL (L3). Как вы понимаете vMX-сы используется для эмуляции сети провайдера, а Cisco — как клиентские CE маршрутизаторы. Если кому интересно, то данная лаба была запущена на самом обычном ноутбуке с i5 и 12 Гб ОЗУ (из которых только 6 было занято, а загрузка CPU не превышала 30 процентов) — так что можете запустить у себя и пощупать EVPN. Наша схема выглядит следующим образом:\ ![](https://habrastorage.org/files/3b1/9ae/ec8/3b19aeec87ac413ca55797acec6184c6.png)\ Как вы поняли, у нас три PE маршрутизатора, один P-маршрутизатор, он же и роутрефлектор, и три CE маршрутизатора. Вся адресация для удобства приведена на схеме. Juniper позволяет нам сконфигурировать routing-instance для EVPN двумя способами — первый это instance с типом EVPN (VLAN Based Service) — самый простой, и второй, instance с типом virtual-switch (VLAN Aware Service). Лично мне больше нравится второй вариант, так как он более гибок, но для наглядности в нашей лабе мы будем использовать оба способа. Однако различия этих двух способов не только в конфигурации. * **VLAN Based Service** — данный тип использования EVPN хорош тем, что bridge-домены полностью изолированы друг от друга. Но на каждый влан придется делать новую routing instance. В таком сценарии трафик между PE маршрутизаторами может идти как с влан тегом так и не тегированным. JunOS по умолчанию отправляет тегированный трафик с оригинальным тегом (если, конечно, не настроены какие-либо правила перезаписи тега на интерфейсе).\ Конфигурация routing instance с типом EVPN выглядит вот так: ``` bormoglotx@RZN-PE-3> show configuration routing-instances RZN-VPN-1 instance-type evpn; vlan-id 777; interface ge-0/0/2.200; interface ge-0/0/2.777; routing-interface irb.777; route-distinguisher 62.0.0.3:1; vrf-import VPN-1-IMPORT; vrf-export VPN-1-EXPORT; protocols { evpn { interface ge-0/0/2.777; } } bormoglotx@RZN-PE-3> show configuration interfaces ge-0/0/2 description "link to RZN-CE3-SW1"; flexible-vlan-tagging; encapsulation flexible-ethernet-services; mac 50:01:00:03:00:04; unit 777 { encapsulation vlan-bridge; vlan-id 777; family bridge; } ``` В конфигурации инстанса с типом EVPN стоит обратить внимание на такую строчку: ``` bormoglotx@RZN-PE-3> show configuration routing-instances RZN-VPN-1 | match vlan vlan-id 777; ``` Это значение определяет, какой тег используется для нормализации. То есть если к данному EVPN инстансу будет подключен помимо влана 777 еще и влан 200 (как в показанном выше конфиге), то при получении пакета с тегом 200, PE маршрутизатор будет снимать данный тег (тег 200) и навешивать новый — 777. На прием PE-ка будет действовать в обратной последовательности — сниматься тег 777 и навешивать тег 200 при отправке в интерфейс в сторону CE-маршрутизатора, в нашем случае в интерфейс ge-0/0/2.200 (см конфигурацию выше, на схемах данный CE маршрутизатор не показан). Это минимальная конфигурация, которая позволит EVPN работать (не забываем про базовую настройку сети — IGP, MPLS и т.д., которая тут не представлена). Как видите, мы указываем [RD](https://en.wikipedia.org/wiki/Route_distinguisher) и [RT](https://habr.com/en/sandbox/99255/), так как для сигнализации используется BGP. Все как обычно — RD делает наш маршрут уникальным, а RT используются для фильтрации маршрутов. Политики импорта и экспорта на всех PE-маршрутизаторах одинаковые: **Конфингурация политик** ``` bormoglotx@RZN-PE-3> show configuration policy-options policy-statement VPN-1-IMPORT term DEFAULT-IMPORT { from { protocol bgp; community VPN-1; } then accept; } term REJECT { then reject; } bormoglotx@RZN-PE-3> show configuration policy-options policy-statement VPN-1-EXPORT term DEFAULT { then { community + VPN-1; accept; } } term REJECT { then reject; } bormoglotx@RZN-PE-3> show configuration policy-options community VPN-1 members target:6262:777; ``` * **VLAN Aware Service** — в этом случае мы делаем только одну routing instance с типом virtual-switch и добавляем в нее bridge-домены. Если у клиента будет 30 вланов, нам не надо городить конфиг на сотни строк, делая instance на каждый влан — достаточно в созданный для клиента instance добавить 30 bridge-доменов. В этом случае наличие vlan тега, согласно RFC, обязательно.\ Конфигурация instance с типом virtual-switch имеет примерно такой вид: ``` bormoglotx@RZN-PE-1> show configuration routing-instances RZN-VPN-1 instance-type virtual-switch; interface ge-0/0/2.0; route-distinguisher 62.0.0.1:1; vrf-import VPN-1-IMPORT; vrf-export VPN-1-EXPORT; protocols { evpn { extended-vlan-list 777; } } bridge-domains { VLAN-777 { vlan-id 777; } } bormoglotx@RZN-PE-1> show configuration interfaces ge-0/0/2 description "link to RZN-CE1-SW1"; flexible-vlan-tagging; encapsulation flexible-ethernet-services; mac 50:01:00:01:00:04; unit 0 { family bridge { interface-mode trunk; vlan-id-list 777; } } ``` Никаких проблем при использовании с одной стороны EVPN, с другой virtual switch быть не должно (если вы все делаете как положено), так как JunOS из инстанса EVPN отправляет тегированный трафик с оригинальным тегом. Во всяком случае в ходе тестирования я проблем не обнаружил. Но есть один нюанс. Стоит учитывать, что нормализация может сыграть с вами злую шутку, если вы начнете в одном и том же EVPN домене использовать разные типа инстансов не разделяя вланы по bridge-доменам. К примеру на одном PE-маршрутизаторе в инстанс с типом EVPN вы добавляете два влана: 777 и 1777, а для нормализации используете влан 777. С другого конца у вас будет virtual switch с двумя bridge доменами — vlan 777 и vlan 1777. В итоге что получаем: пакет прилетает от CE во влане 1777, происходит нормализация влана на 777 и в инстанс virtual switch пакет прилетает во влан 777. А хост назначения то во влане 1777, то есть в другом bridge домене. В итоге — у вас нет связности между хостами в одном влане. Либо другой вариант развития событий — в одном и том же bridge домене вы сконфигурировали разные теги, предназначенные для нормализации. В таком сценарии у вас тоже не будет связности (вообще не будет), так как с PE1 пакет будет улетать например с нормальным тегом 777, а на PE2 нормальный тег — 1777. В итоге PE2 будет просто отбрасывать пакеты с не соответствующим номером влана.