Лаборатория для тестов и конфигурации
Для тестов я использовал 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 выглядит вот так:
    1
    [email protected]> show configuration routing-instances RZN-VPN-1
    2
    instance-type evpn;
    3
    vlan-id 777;
    4
    interface ge-0/0/2.200;
    5
    interface ge-0/0/2.777;
    6
    routing-interface irb.777;
    7
    route-distinguisher 62.0.0.3:1;
    8
    vrf-import VPN-1-IMPORT;
    9
    vrf-export VPN-1-EXPORT;
    10
    protocols {
    11
    evpn {
    12
    interface ge-0/0/2.777;
    13
    }
    14
    }
    15
    16
    [email protected]> show configuration interfaces ge-0/0/2
    17
    description "link to RZN-CE3-SW1";
    18
    flexible-vlan-tagging;
    19
    encapsulation flexible-ethernet-services;
    20
    mac 50:01:00:03:00:04;
    21
    unit 777 {
    22
    encapsulation vlan-bridge;
    23
    vlan-id 777;
    24
    family bridge;
    25
    }
    Copied!
    В конфигурации инстанса с типом EVPN стоит обратить внимание на такую строчку:
    1
    [email protected]> show configuration routing-instances RZN-VPN-1 | match vlan vlan-id 777;
    Copied!
    Это значение определяет, какой тег используется для нормализации. То есть если к данному 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-маршрутизаторах одинаковые:
    Конфингурация политик
    1
    [email protected]> show configuration policy-options policy-statement VPN-1-IMPORT
    2
    term DEFAULT-IMPORT {
    3
    from {
    4
    protocol bgp;
    5
    community VPN-1;
    6
    }
    7
    then accept;
    8
    }
    9
    term REJECT {
    10
    then reject;
    11
    }
    12
    13
    [email protected]> show configuration policy-options policy-statement VPN-1-EXPORT
    14
    term DEFAULT {
    15
    then {
    16
    community + VPN-1;
    17
    accept;
    18
    }
    19
    }
    20
    term REJECT {
    21
    then reject;
    22
    }
    23
    24
    [email protected]> show configuration policy-options community VPN-1
    25
    members target:6262:777;
    Copied!
  • VLAN Aware Service — в этом случае мы делаем только одну routing instance с типом virtual-switch и добавляем в нее bridge-домены. Если у клиента будет 30 вланов, нам не надо городить конфиг на сотни строк, делая instance на каждый влан — достаточно в созданный для клиента instance добавить 30 bridge-доменов. В этом случае наличие vlan тега, согласно RFC, обязательно. Конфигурация instance с типом virtual-switch имеет примерно такой вид:
    1
    [email protected]> show configuration routing-instances RZN-VPN-1
    2
    instance-type virtual-switch;
    3
    interface ge-0/0/2.0;
    4
    route-distinguisher 62.0.0.1:1;
    5
    vrf-import VPN-1-IMPORT;
    6
    vrf-export VPN-1-EXPORT;
    7
    protocols {
    8
    evpn {
    9
    extended-vlan-list 777;
    10
    }
    11
    }
    12
    bridge-domains {
    13
    VLAN-777 {
    14
    vlan-id 777;
    15
    }
    16
    }
    17
    18
    [email protected]> show configuration interfaces ge-0/0/2
    19
    description "link to RZN-CE1-SW1";
    20
    flexible-vlan-tagging;
    21
    encapsulation flexible-ethernet-services;
    22
    mac 50:01:00:01:00:04;
    23
    unit 0 {
    24
    family bridge {
    25
    interface-mode trunk;
    26
    vlan-id-list 777;
    27
    }
    28
    }
    Copied!
Никаких проблем при использовании с одной стороны 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 будет просто отбрасывать пакеты с не соответствующим номером влана.
Copy link