Лаборатория для тестов и конфигурации

Для тестов я использовал Unetlab, в которой собрал стенд из четырех vMX и трех Cisco IOL (L3). Как вы понимаете vMX-сы используется для эмуляции сети провайдера, а Cisco — как клиентские CE маршрутизаторы. Если кому интересно, то данная лаба была запущена на самом обычном ноутбуке с i5 и 12 Гб ОЗУ (из которых только 6 было занято, а загрузка CPU не превышала 30 процентов) — так что можете запустить у себя и пощупать EVPN.

Наша схема выглядит следующим образом: Как вы поняли, у нас три 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 выглядит вот так:

    [email protected]> 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;
    }
    }
    [email protected]> 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 стоит обратить внимание на такую строчку:

    [email protected]> 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 и RT, так как для сигнализации используется BGP. Все как обычно — RD делает наш маршрут уникальным, а RT используются для фильтрации маршрутов. Политики импорта и экспорта на всех PE-маршрутизаторах одинаковые:

    Конфингурация политик

    [email protected]> show configuration policy-options policy-statement VPN-1-IMPORT
    term DEFAULT-IMPORT {
    from {
    protocol bgp;
    community VPN-1;
    }
    then accept;
    }
    term REJECT {
    then reject;
    }
    [email protected]> show configuration policy-options policy-statement VPN-1-EXPORT
    term DEFAULT {
    then {
    community + VPN-1;
    accept;
    }
    }
    term REJECT {
    then reject;
    }
    [email protected]> 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 имеет примерно такой вид:

    [email protected]> 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;
    }
    }
    [email protected]> 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 будет просто отбрасывать пакеты с не соответствующим номером влана.