/ 12.1.-mpls-evpn / 2.-evpn-lab.md
2.-evpn-lab.md
1 # Лаборатория для тестов и конфигурации 2 3 Для тестов я использовал [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. 4 5 Наша схема выглядит следующим образом: 6  7 Как вы поняли, у нас три PE маршрутизатора, один P-маршрутизатор, он же и роутрефлектор, и три CE маршрутизатора. Вся адресация для удобства приведена на схеме. 8 9 Juniper позволяет нам сконфигурировать routing-instance для EVPN двумя способами — первый это instance с типом EVPN \(VLAN Based Service\) — самый простой, и второй, instance с типом virtual-switch \(VLAN Aware Service\). Лично мне больше нравится второй вариант, так как он более гибок, но для наглядности в нашей лабе мы будем использовать оба способа. Однако различия этих двух способов не только в конфигурации. 10 11 * **VLAN Based Service** — данный тип использования EVPN хорош тем, что bridge-домены полностью изолированы друг от друга. Но на каждый влан придется делать новую routing instance. В таком сценарии трафик между PE маршрутизаторами может идти как с влан тегом так и не тегированным. JunOS по умолчанию отправляет тегированный трафик с оригинальным тегом \(если, конечно, не настроены какие-либо правила перезаписи тега на интерфейсе\). 12 Конфигурация routing instance с типом EVPN выглядит вот так: 13 ```text 14 bormoglotx@RZN-PE-3> show configuration routing-instances RZN-VPN-1 15 instance-type evpn; 16 vlan-id 777; 17 interface ge-0/0/2.200; 18 interface ge-0/0/2.777; 19 routing-interface irb.777; 20 route-distinguisher 62.0.0.3:1; 21 vrf-import VPN-1-IMPORT; 22 vrf-export VPN-1-EXPORT; 23 protocols { 24 evpn { 25 interface ge-0/0/2.777; 26 } 27 } 28 29 bormoglotx@RZN-PE-3> show configuration interfaces ge-0/0/2 30 description "link to RZN-CE3-SW1"; 31 flexible-vlan-tagging; 32 encapsulation flexible-ethernet-services; 33 mac 50:01:00:03:00:04; 34 unit 777 { 35 encapsulation vlan-bridge; 36 vlan-id 777; 37 family bridge; 38 } 39 ``` 40 41 В конфигурации инстанса с типом EVPN стоит обратить внимание на такую строчку: 42 ```text 43 bormoglotx@RZN-PE-3> show configuration routing-instances RZN-VPN-1 | match vlan vlan-id 777; 44 ``` 45 Это значение определяет, какой тег используется для нормализации. То есть если к данному EVPN инстансу будет подключен помимо влана 777 еще и влан 200 (как в показанном выше конфиге), то при получении пакета с тегом 200, PE маршрутизатор будет снимать данный тег (тег 200) и навешивать новый — 777. На прием PE-ка будет действовать в обратной последовательности — сниматься тег 777 и навешивать тег 200 при отправке в интерфейс в сторону CE-маршрутизатора, в нашем случае в интерфейс ge-0/0/2.200 (см конфигурацию выше, на схемах данный CE маршрутизатор не показан). 46 47 Это минимальная конфигурация, которая позволит EVPN работать (не забываем про базовую настройку сети — IGP, MPLS и т.д., которая тут не представлена). Как видите, мы указываем [RD](https://en.wikipedia.org/wiki/Route_distinguisher) и [RT](https://habr.com/en/sandbox/99255/), так как для сигнализации используется BGP. Все как обычно — RD делает наш маршрут уникальным, а RT используются для фильтрации маршрутов. Политики импорта и экспорта на всех PE-маршрутизаторах одинаковые: 48 49 **Конфингурация политик** 50 ```text 51 bormoglotx@RZN-PE-3> show configuration policy-options policy-statement VPN-1-IMPORT 52 term DEFAULT-IMPORT { 53 from { 54 protocol bgp; 55 community VPN-1; 56 } 57 then accept; 58 } 59 term REJECT { 60 then reject; 61 } 62 63 bormoglotx@RZN-PE-3> show configuration policy-options policy-statement VPN-1-EXPORT 64 term DEFAULT { 65 then { 66 community + VPN-1; 67 accept; 68 } 69 } 70 term REJECT { 71 then reject; 72 } 73 74 bormoglotx@RZN-PE-3> show configuration policy-options community VPN-1 75 members target:6262:777; 76 ``` 77 78 * **VLAN Aware Service** — в этом случае мы делаем только одну routing instance с типом virtual-switch и добавляем в нее bridge-домены. Если у клиента будет 30 вланов, нам не надо городить конфиг на сотни строк, делая instance на каждый влан — достаточно в созданный для клиента instance добавить 30 bridge-доменов. В этом случае наличие vlan тега, согласно RFC, обязательно. 79 Конфигурация instance с типом virtual-switch имеет примерно такой вид: 80 81 ```text 82 bormoglotx@RZN-PE-1> show configuration routing-instances RZN-VPN-1 83 instance-type virtual-switch; 84 interface ge-0/0/2.0; 85 route-distinguisher 62.0.0.1:1; 86 vrf-import VPN-1-IMPORT; 87 vrf-export VPN-1-EXPORT; 88 protocols { 89 evpn { 90 extended-vlan-list 777; 91 } 92 } 93 bridge-domains { 94 VLAN-777 { 95 vlan-id 777; 96 } 97 } 98 99 bormoglotx@RZN-PE-1> show configuration interfaces ge-0/0/2 100 description "link to RZN-CE1-SW1"; 101 flexible-vlan-tagging; 102 encapsulation flexible-ethernet-services; 103 mac 50:01:00:01:00:04; 104 unit 0 { 105 family bridge { 106 interface-mode trunk; 107 vlan-id-list 777; 108 } 109 } 110 ``` 111 112 Никаких проблем при использовании с одной стороны 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 будет просто отбрасывать пакеты с не соответствующим номером влана. 113