> For the complete documentation index, see [llms.txt](https://linkmeup.gitbook.io/sdsm/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://linkmeup.gitbook.io/sdsm/12.1.-mpls-evpn/2.-evpn-lab.md). # Лаборатория для тестов и конфигурации Для тестов я использовал [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 будет просто отбрасывать пакеты с не соответствующим номером влана. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://linkmeup.gitbook.io/sdsm/12.1.-mpls-evpn/2.-evpn-lab.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.