EVPN
EVPN
About EVPN
Обеспечивает виртуальную многоточечную связность между разными L2 доменами через IP или MPLS сеть.
По аналогии с другими VPN, для EVPN на PE роутера создается отдельный Instance (EVIs), который логически разделяет клиентов.
CE имеют соединение с PE. PE обмениваются между собой информацией, использую MP-BGP и инкапсулированный трафик также передают между PE.
Особенность: есть mac-learning, который осуществляется на control plane. Новый мак-адрес изученный PE, передается остальным удаленным PE, используя MP-BGP MAC route. Mac-learning в EVPN намного более тонко работает, чем в VPLS.
С использованием EVPN, можно реализовать на сети много разных топологий: E-LINE, E-LAN, E-TREE.
MAC-learning на control-plane позволяет примерять policy и другие опции к MAC, изученными между PE, что делает подобный mac-learning более эффективным и дает возможность обеспечивать защиту на сети.
EVPN полезно внедрят ISP, предоставляющим своим клиентам L2VPN, L3VPN, Internet access и которые дополнительно хотели бы для существующих клиентов предоставить облачные сервисы и хранение данных.
Но в основном EVPN полезно использовать дата-центрам, которым требуется l2 связность между дата-центрами. Для внедрения в сеть дата-центров, EVPN обладает такими функиями:
- Multi-homing между CE-PE с поддержанием active-active линков.
Дает возможность подключиться одному CE к нескольким PE, при этом трафик передается по всем активным линкам.
Aliasing дает возможность удаленным PE делать балансировку к multi-homed PE, через core, даже в том случае, когда удаленный PE изучил мак с одного из Multi-homed PE.
Также в EVPN есть механизмы для предотвращения BUM петель.
В случае, когда CE не поддерживает балансировку или PE не имеет средств защиты от BUM петель, тогда можно организовать multi-homing с одним активным линком между PE и CE.
- Быстрое восстановление сервиса.
С помощью multi-homing, обеспечивается быстрое восстановление сервиса, т.к. при падении PE или линка до PE, трафик переходит на другой активный линк.
Трафик с другой стороны: удаленный PE обновляет свою forwarding table и также посылает трфик в сторону оставшихся активных PE.
- Поддержка миграции виртуальных машин или MAC mobility.
У PE есть возможность отслеживать перемещение мак-адреса виртуальной машины (VM). При этом, когда VM переместилась, то новый PE, который изучил ее MAC, делает MAC route update. Старый PE, получив таком update, удаляет у себя информацию об этом MAC.
- Интреграция L3 роутинга с оптимальным forwarding.
Для L2 домена можно внедрить L3 routing, путем добавления IRB интерфейса для влана в EVPN instance. Хосты будут использовать этот irb как default gateway.
Irb IP и MAC анонсируются остальным удаленным PE EVPNа путем Default Gateway Synchronization. Это полезно с той точки зрения, что все PE будут в курсе def Gateway и при переезде VM на другой PE, PE будет proxy arp от имени изученного def gateway и маршрутизировать трафик от VM напрямую к destination.
Таким же образом, через snooping ARP и DHCP пакетов, происходит заучивание ip-адресов хостов EVPN дата-центров. Называется это Host MAC/IP Synchronization'. После этого появляется возможность передавать трафик к PE, ближайшему к хосту дата-центр. Этот метод совместим в MAC migration.
Asymmetric IRB Forwarding: L2 заголовок перезаписывается ingress PE перед отправкой пакета. Это позволяет dest PE обойтись без L3 lookup, когда он производит передачу пакета.
- Уменьшение утилизации полосы пропускания для multi-destination трафика между разными частями дата-центра в разных местах.
- PE делают Proxy ARP: изучая ip хостов и def gateway.
- P2MP or MP2MP LSPs между сторонами дата-центров.
- Поддерживает инкапсуляцию разных данных.
Например, GRE tunnels с IPSEC.
Configuration
Для поддержки trio-based FPCs, требуется включение enhanced-ip
blair# set chassis network-services enhanced-ip
В ядре
- OSPF, на всех интерфейсах. Также включаем TE внутри OSPF.
- MPLS с RSVP-TE LSP между всеми PE (full-mesh). LSP будут использоваться как для EVPN, так и для IP VPN.
- MP-BGP для EVPN и IP VPN. Конфигурируется сессия с P-роутером, который в свою очередь также является и RR (и советуют настроить bfd-detection). Включаем необходимые family: inet-vpn, evpn. Также предлагается настроить bfd-сессии.
На доступе
- В сторону CE настраиваем отдельный логический интерфейс для каждого Instance с требуемыми вланами.
- ESI - Ethernet Segment ID: тербуется для multi-homing. Первый октет = Type, остальные - ID. Вид: 00:11:11:11:11:11:11:11:11:11.
Задаем all-active, что обеспечивает балансировку между линками.
- LACP даже с одним линком имеет смысл: дает возможность определить действительно ли по линку ходит трафик или нет. Если LACP развалится, значит сигнальные сообщения не проходят по физическим линкам внутри LACP. Также при добавлении или исключении линка из LACP не страдает передача трафика.
set interface xe-1/0/0 gither-options 802.3.ad ae0 hold-time up 180000 down 0
- также задается одинаковый system-id для LACP на обоих РЕ. При этом СЕ думает, что LACP установлен с одним устройством.
Сервисы
- EVPN VLAN-based: один влан, который принадлежит одному bridge домену.
Пример конфига:
routing-instances {
EVPN-1 {
instance-type evpn;
vlan-id 100;
interface ae0.100;
routing-interface irb.100;
route-distinguisher 11.11.11.11:1;
vrf-target target:65000:1;
protocols {
evpn {
default-gateway do-not-advertise; }}}}
interfaces {
irb {
unit 100 {
family inet {
address 100.1.1.1/24; }
mac 00:00:00:01:01:01; }}}
Для этого EVPN используется только 1 влан = 100, в данном случае.
mac 00:00:00:01:01:01 - для irb-интерфейсов одного EVPN на разных частях, используют одинаковые ip/mac. Делается для упрощения конфига, уменьшения control plane перезгрузки, и минимизации времени восстановления при падении PE.
default-gateway do-not-advertise - т.к. для irb указаны одинаковые ip/mac, то можно выключить функцию анонсирования MAC/IP binding между PE.
- EVPN VLAN-aware: несколько пользователей с независимыми vlan и ip.
Оба сервиса могут использовать vlan translation (настраивается на PE), что дает возможность использовать разные вланы в разных частях.
Хорошей практикой считается настраивать VLAN-aware, даже используется всего 1 vlan. Так сказать, задел на будущее.
Пример конфига:
routing-instances {
EVPN-2 {
instance-type virtual-switch;
interface ae0.200;
route-distinguisher 11.11.11.11:2;
vrf-target target:65000:2;
protocols {
evpn {
extended-vlan-list 200-202;
default-gateway advertise; }}
bridge-domains {
V200 {
vlan-id 200;
routing-interface irb.200; }
V201 {
vlan-id 201;
routing-interface irb.201;}
V202 {
vlan-id 202;
routing-interface irb.202; }}}}
interfaces {
irb {
unit 200 {
family inet {
address 200.1.1.1/24; }
mac 00:00:c8:01:01:01; }
unit 201 {
family inet {
address 201.1.1.1/24; }
mac 00:00:c9:01:01:01; }
unit 202 {
family inet {
address 202.1.1.1/24; }
mac 00:00:ca:01:01:01 }}}
extended-vlan-list 200-202 - определяет список вланов, которые будут передаваться через ядро.
Пример настройки vlan-translation на PE:
interfaces {
ae0 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
esi {
00:22:22:22:22:22:22:22:22:22;
all-active; }
aggregated-ether-options {
lacp {
system-id 00:00:00:00:00:02; }}
unit 100 {
encapsulation vlan-bridge;
vlan-id 100;
family bridge; }
unit 200 {
family bridge {
interface-mode trunk;
vlan-id-list [ 200 201 202 ];
vlan-rewrite {
translate 222 202; }}}}}
- IP-VPN: За маршрутизацию между VLAN отвечает irb-интерфейс, присвоенный с общий IP VPN. Также через него можно осуществлять маршрутизацию и с внешним миром.
Можно добавлять разные irb в разные IP VPN, чтобы разделить L3 трафик.
Пример конфига:
routing-instances {
IPVPN-1 {
instance-type vrf;
interface irb.100;
interface irb.200;
interface irb.201;
interface irb.202;
route-distinguisher 11.11.11.11:111;
vrf-import IpVpnDiscardEvpnSubnets;
vrf-export IpVpnAddCommunities;
vrf-table-label;
policy-options {
prefix-list PL-EVPN {
100.1.1.0/24;
200.1.1.0/24;
201.1.1.0/24;
202.1.1.0/24; }
policy-statement IpVpnAddCommunities {
term 10 {
from {
prefix-list-filter PL-EVPN orlonger; }
then {
community add COMM-EVPN;
community add COMM-IPVPN-1;
accept; }}
term 100 {
then accept;}}
policy-statement IpVpnDiscardEvpnSubnets {
term 10 {
from community COMM-EVPN;
then reject; }
term 100 {
from community COMM-IPVPN-1;
then accept; }}
community COMM-EVPN members 65000:1234;
community COMM-IPVPN-1 members target:65000:101;}
- vrf-export IpVpnAddCommunities; - добавляет community помимо ipvpn (основное) еще и evpn (дополнительно обозначает evpn subnets and hosts).
- vrf-import IpVpnDiscardEvpnSubnets; - т.к. evpn subnets and hosts уже синхронизируются путем Host MAC/IP Synchronization, что передавать эту информацию через IP VPN - избыточно, поэтому маршруты с таким community будут отброшены, прилетев на PE.
PE31
В лабе, удаленный PE31 получает все маршруты от других PE в сети. При этом в RI IP-VPN на нем настроен только vrf-target target:65000:101, который соответствует COMM-IPVPN-1, таким образом, community, соответствующие EVPN маршрутам, будут просто игнорироваться для этого site.
Aliasing:
Также, на данном PE31 будут получены маршруты Data-Center 1 от двух PE, участвующих в multi-homing. Чтобы PE31 мог балансировать между ними нагрузку (балансировка применяется к L2 и L3), требуется настроить BGP особым образом:
bgp {
group Internal {
type internal;
family inet-vpn {
any; }
multipath;
neighbor 1.1.1.1 {
local-address 31.31.31.31;
bfd-liveness-detection {
minimum-interval 200;
multiplier 3;}}}}
policy-options {
policy-statement lb {
then {
load-balance per-packet; }}}
routing-options {
router-id 31.31.31.31;
autonomous-system 65000;
forwarding-table {
export lb; }}
Verification
На ядре
- OSPF adjacencies
- MP-BGP sessions to P. Families: bgp.l3vpn.0, bgp.evpn.0, IPVPN-1.inet.0, EVPN-1.evpn.0, EVPN-2.evpn.0, and__default_evpn__.evpn.0.
- BFD session: show bfd session
- LSPs to all remote PE - are up.
На доступе
- PE-CE links: interfaces are UP, LACP is ok.
Multi-homing
Это важная фитча. Для ее корректной работы требуется настройка одинакового ESI на разных multi-homing PE. Таким образом PE узнают друг о друге.
ES route имеет Type 4 и имеет несколько других важных полей:
- Router's IP addr = loopback addr.
- ESI: 10 октетов. ES route будет принят PE только в том случае, если ESI для двух PE будет полностью совпадать.
- ES Import RT community - полученный из ESI. Представляет из себя только 6 октетов. Поэтому для разных ESI, community может быть одинаковым. То есть судя только по community нельзя точно определить подходит ли пришедший route, но такой дополнительный метод проверки тем не менее значительно уменьшает кол-во routes, которое требуется рассмотреть в дальнейшем PE.
Для проверки и просмотра полученных ES routes можно вывести все доступные варианты след образом:
> show route table bgp.evpn.0 detail | find "4:/1"
4:12.12.12.12:0::111111111111111111:12.12.12.12/304 (1 entry, 0 announced)
*BGP Preference: 170/-101
Route Distinguisher: 12.12.12.12:0
Next hop type: Indirect
Address: 0x95c606c
...
Cluster list: 1.1.1.1
Originator ID: 12.12.12.12
Communities: es-import-target:11-11-11-11-11-11
Также в таблице default.evpn.evpn.0 будут хранится все ES route локального PE, в том виде, когда к ним еще не присоединилась community конкретного EVI
cse@PE11> show route table __default_evpn__.evpn.0 | find 4:
4:11.11.11.11:0::111111111111111111:11.11.11.11/304
*[EVPN/170] 04:40:23
Indirect
4:12.12.12.12:0::111111111111111111:12.12.12.12/304
*[BGP/170] 04:40:04, localpref 100, from 1.1.1.1
AS path: I, validation-state: unverified
> to 10.11.12.12 via ae1.0, label-switched-path from-11-to-12
Designated forwarder
Сразу после установления Multi-homing peering между PE выбирается Designated Forwarder для ES.
Выбор производится для каждого EVI в каждом ESI.
Выборы:
- сортировка по Lo addr (от меньшего к большему, как я понимаю)
- роутерам по-порядку назначаются номера, начиная с 0. Роутер с наименьшим номеров - стал DF.
- далее производится выбор DF для каждого vlana. V mod N (V = VLAN, N = кол-во PE в multi-homing). Если в EVPN несколько вланов, то берется наименьший vid.
Передачей BUM трафика занимается DF PE. Backup PE будет отбрасывать такие пакеты.
cse@PE11> show evpn instance EVPN-1 esi 00:11:11:11:11:11:11:11:11:11 extensive
Instance: EVPN-1
Number of ethernet segments: 2
ESI: 00:11:11:11:11:11:11:11:11:11
Status: Resolved by IFL ae0.100
Local interface: ae0.100, Status: Up/Forwarding
Number of remote PEs connected: 1
Remote PE MAC label Aliasing label Mode
12.12.12.12 300688 300688 all-active
Designated forwarder: 11.11.11.11
Backup forwarder: 12.12.12.12
Advertised MAC label: 300976
Advertised aliasing label: 300976
Advertised split horizon label: 299984
Проверка int на возможность передачи BUM трафика:
cse@PE11> show interfaces ae0.100 detail | find EVPN
EVPN multi-homed status:Forwarding, EVPN multi-homed ESI Split Horizon
Label: 299984
Flags: Is-Primary
cse@PE12> show interfaces ae0.100 detail | find EVPN
EVPN multi-homed status: Blocking BUM Traffic to ESI, EVPN multi-homed ESI Split
Horizon Label: 299888
Flags: Is-Primary
Auto-Discovery
Multi-homed-PE пересылают всем удаленным PE 2 типа маршрутов:
- Auto-discovery route for ESI
Для более быстрого восстановления используется этот механизм auto-discovery routes, также называемый MAC Mass Withdraw. В случае, когда рвется линк между PE-CE, PE сбрасывает route, содержащий пачку маков.
Передаваемые маршруты имеют следующие параметры:
- список RT, соответствующих EVI
- ESI
- ESI label extended community: split horizont label + multi-homing mode (all-active/single-active).
Split horizont label - для исключения петель при получении маршрута, от нескольких CE - Split Horizong filtering. Когда non-DF передает пакеты DF-router'у в этом же EVI, он первым делом добавляет split hor label к этому пакету. DF, видя метку, не передает такой пакет обратно CE.
Label stack
- Transpotr label
- Inclusive Multicast Label
- Split Horizonf Label
- BUM traffic.
- Auto-Discovery route per EVI
В all-active multi-homing есть Aliasing (load-balancing). Большиство изученных маков будут передаваться от PE1 из multi-homing, при этом aliasing будет обеспечивать балансировку обратного трафика и второму PE2.
Для single-active: функция тоже будет работать в качестве обеспечения Backup-path.
Auto-discovery route содержит:
- RT, соответствующий EVI
- ESI
- Aliasing Label
Когда PE изучает новый мой, то PE отправляет MAC Advertisment route, который состоит из MAC, MPLS service label, ESI (от ужаленного PE).
Удаленный PE сравнивает полученный ESI с ESI в обоих Auto-Discovery routes и определяет состав multi-homing PEs, которым он сможет направить обратный трафик по MAC.
Когда удаленный PE отправляет пакет обратно PE1, отправившего MAC Advertisement route, используется service label.
Когда удаленный PE отправляет пакет обратно пиру PE1 (PE2), используется aliasing label.
Для каждого EVPN можно увидеть метки от удаленных PE.
show evpn instance EVPN-1 extensive
Inclusive multicast
Type = 3
Каждый PE передает Inclusive Multicast (IM) route для разрешения передачи BUM трафика.
- RT, сопоставляемый с EVI
- Ethernet tag ID = VLAN ID
- PMSI Tunnel Attribute - обозначение multicast технологии и IM MPLS метки.
PMSI Attr - это атрибут, использующийся для NG BGP Multicast VPN: P2MP, RSVP-TE LSPs, P2MP mLDP LSPs, PIM-SM trees.
PE получил пакет от CE: PE делает копию пакета, соответствующую каждому remote PE. Навешивает на пакет метку: обычно сначала это IM метка + transport метка.
Но в случает с multi-homed non-DF, с начала добавляется Split Horizont Label.
На удаленном PE: снимается transport label, распознается IM метка и BUM трафик.
- P2MP LSPs: эффективная утилизация полосы в ядре, но могут быть проблемы с мастабируемостью, т.к. нужно выбирать точку копирования трафика.
Чтобы избежать подобных проблем: используем чистый EVPN, где точка копирования трафика уже выбрана - ingress PE.
PE11> show route table EVPN-1.evpn.0 | find “3\:12”
3:12.12.12.12:1::100::12.12.12.12/304
*[BGP/170] 1d 17:37:16, localpref 100, from 1.1.1.1
AS path: I, validation-state: unverified
> to 10.11.1.1 via xe-1/2/0.0, label-switched-path from-11-to-12
Также наличие IM от каждого remote PE можно проверить тут:
PE11> show evpn instance EVPN-1 extensive
Проверить PMSI tunnel attribute можно так:
PE11> show route table EVPN-1.evpn.0 detail 3:21.21.21.21:1::100::21.21.21.21/304 (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 21.21.21.21:1 PMSI: Flags 0x0: Label 311168: Type INGRESS-REPLICATION 21.21.21.21
© Наталия Бобкова 2014—2022