EVPN: различия между версиями

Материал из Juniper Exam Wiki
Перейти к навигации Перейти к поиску
 
(не показаны 43 промежуточные версии этого же участника)
Строка 1: Строка 1:
=About EVPN=
{{#description2: Основы EVPN. Конфигурация EVPN. Траблшутинг EVPN. Multi-homing EVPN. L2 процессы внутри EVPN. L3 процессы внутри EVPN. MP-BGP EVPN Route Summary. High Availability в EVPN. Информация для подготовки к экзаменам Juniper.}}
Обеспечивает виртуальную многоточечную связность между разными L2 доменами через IP или MPLS сеть.
 
=Основы EVPN=
Обеспечивает виртуальную многоточечную связность между разными L2 доменами через IP или MPLS сеть. Внедрить можно уже на существующей сети, потому что в ядре уже используются нужные технологии: MPLS или IP.
 
Отлично подходит для соединения data-centers sites.
 
CE, включенный в EVPN видит всю сеть как один бродкаст домен (большой свитч).
 
Control-plane mac-learning => all-active multihoming, traffic load balancing, MAC mobility.
 
Имеет хорошую возможность эффективно роутить вх и исх трафик, даже при миграции хостов в data-centers.
 
Имеет хорошие показатели по сходимости при link failure и node failure.


По аналогии с другими VPN, для EVPN на PE роутера создается отдельный Instance (EVIs), который логически разделяет клиентов.  
По аналогии с другими VPN, для EVPN на PE роутера создается отдельный Instance (EVIs), который логически разделяет клиентов.  
Строка 7: Строка 19:


'''Особенность''': есть mac-learning, который осуществляется на control plane. Новый мак-адрес изученный PE, передается остальным удаленным PE, используя '''MP-BGP MAC route'''. Mac-learning в EVPN намного более тонко работает, чем в VPLS.
'''Особенность''': есть mac-learning, который осуществляется на control plane. Новый мак-адрес изученный PE, передается остальным удаленным PE, используя '''MP-BGP MAC route'''. Mac-learning в EVPN намного более тонко работает, чем в VPLS.
MAC-learning на control-plane позволяет примерять policy и другие опции к MAC, изученными между PE, что делает подобный mac-learning более эффективным и дает возможность обеспечивать защиту на сети.


С использованием EVPN, можно реализовать на сети много разных топологий: E-LINE, E-LAN, E-TREE.
С использованием EVPN, можно реализовать на сети много разных топологий: E-LINE, E-LAN, E-TREE.


MAC-learning на control-plane позволяет примерять policy и другие опции к MAC, изученными между PE, что делает подобный mac-learning более эффективным и дает возможность обеспечивать защиту на сети.
EVPN полезно внедрять ISP, предоставляющим своим клиентам L2VPN, L3VPN, Internet access и которые дополнительно хотели бы для существующих клиентов предоставить облачные сервисы и хранение данных.


EVPN полезно внедрят ISP, предоставляющим своим клиентам L2VPN, L3VPN, Internet access и которые дополнительно хотели бы для существующих клиентов предоставить облачные сервисы и хранение данных.
Также EVPN эффективно использовать для соединения разных data-centers (DC) site.  


Но в основном EVPN полезно использовать дата-центрам, которым требуется l2 связность между дата-центрами. Для внедрения в сеть дата-центров, EVPN обладает такими функиями:
EVPN обладает такими функциями:
*'''Multi-homing между CE-PE''' с поддержанием active-active линков.
*'''Multi-homing между CE-PE''' с поддержанием active-active линков.
Дает возможность подключиться одному CE к нескольким PE, при этом трафик передается по всем активным линкам.
Дает возможность подключиться одному CE к нескольким PE, при этом трафик передается по всем активным линкам.
Строка 20: Строка 34:
'''Aliasing''' дает возможность удаленным PE делать балансировку к multi-homed PE, через core, даже в том случае, когда удаленный PE изучил мак с одного из Multi-homed PE.
'''Aliasing''' дает возможность удаленным PE делать балансировку к multi-homed PE, через core, даже в том случае, когда удаленный PE изучил мак с одного из Multi-homed PE.


Также в EVPN есть механизмы для предотвращения BUM петель.
EVPN есть механизмы для '''предотвращения BUM петель'''.


В случае, когда CE не поддерживает балансировку или PE не имеет средств защиты от BUM петель, тогда можно организовать multi-homing с одним активным линком между PE и CE.  
В случае, когда CE не поддерживает балансировку или PE не имеет средств защиты от BUM петель, тогда можно организовать multi-homing с одним активным линком между PE и CE.  


*Быстрое восстановление сервиса.
*'''Быстрое восстановление сервиса'''.
С помощью multi-homing, обеспечивается быстрое восстановление сервиса, т.к. при падении PE или линка до PE, трафик переходит на другой активный линк.
С помощью multi-homing, обеспечивается быстрое восстановление сервиса, т.к. при падении PE или линка до PE, трафик переходит на другой активный линк.


Трафик с другой стороны: удаленный PE обновляет свою forwarding table и также посылает трфик в сторону оставшихся активных PE.
Трафик с другой стороны: удаленный PE обновляет свою forwarding table и также посылает трафик в сторону оставшихся активных PE.


*Поддержка миграции виртуальных машин или MAC mobility.
*Поддержка '''миграции виртуальных машин или MAC mobility'''.
У PE есть возможность отслеживать перемещение мак-адреса виртуальной машины (VM).
У PE есть возможность отслеживать перемещение мак-адреса виртуальной машины (VM).
При этом, когда VM переместилась, то новый PE, который изучил ее MAC, делает MAC route update. Старый PE, получив таком update, удаляет у себя информацию об этом MAC.  
При этом, когда VM переместилась, то новый PE, который изучил ее MAC, делает MAC route update. Старый PE, получив такой update, удаляет у себя информацию об этом MAC.  


*Интреграция L3 роутинга с оптимальным forwarding.
*'''Интеграция L3 роутинга с оптимальным forwarding'''.
Для L2 домена можно внедрить L3 routing, путем добавления IRB интерфейса для влана в EVPN instance. Хосты будут использовать этот irb как default gateway.
Для 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.
Irb IP и MAC анонсируются остальным удаленным PE EVPN путем ''Default Gateway Synchronization''. Это полезно с той точки зрения, что все PE будут в курсе Def GW и при переезде VM на другой PE, PE будет проксировать arp от имени изученного Def GW и маршрутизировать трафик от VM напрямую к destination.


Таким же образом, через snooping ARP и DHCP пакетов, происходит заучивание ip-адресов хостов EVPN дата-центров. Называется это ''Host MAC/IP Synchronization'''. После этого появляется возможность передавать трафик к PE, ближайшему к хосту дата-центр. Этот метод совместим в MAC migration.  
Таким же образом, через snooping ARP и DHCP пакетов, происходит заучивание ip-адресов хостов EVPN дата-центров. Называется это ''Host MAC/IP Synchronization'''. После этого появляется возможность передавать трафик PE, ближайшему к хосту. Этот метод совместим c MAC migration.  


''Asymmetric IRB Forwarding'': L2 заголовок перезаписывается ingress PE перед отправкой пакета. Это позволяет dest PE обойтись без L3 lookup, когда он производит передачу пакета.
''Asymmetric IRB Forwarding'': L2 заголовок перезаписывает ingress PE перед отправкой пакета. Это позволяет dest PE обойтись без L3 lookup, когда он производит передачу пакета.


*Уменьшение утилизации полосы пропускания для multi-destination трафика между разными частями дата-центра в разных местах.
*Уменьшение утилизации полосы пропускания для multi-destination трафика между разными частями дата-центра в разных местах.
:*PE делают Proxy ARP: изучая ip хостов и def gateway.
:*PE делают Proxy ARP: изучая ip хостов и Def GW.
:*P2MP or MP2MP LSPs между сторонами дата-центров.
:*P2MP or MP2MP LSPs между сторонами дата-центров.
*Поддерживает инкапсуляцию разных данных.
*Поддерживает инкапсуляцию разных данных. Например, GRE tunnels с IPSEC.
Например, GRE tunnels с IPSEC.
 
=Конфигурация EVPN=
Пример конфига разбирается на примере лабы, поднятой в книге: Day One - EVPN
 
[[Файл:EVPN_laba.png|1000px]]


=Configuration=
Для поддержки trio-based FPCs, требуется включение '''enhanced-ip'''
Для поддержки trio-based FPCs, требуется включение '''enhanced-ip'''
  blair# set chassis network-services enhanced-ip     
  blair# set chassis network-services enhanced-ip     


==В ядре==
==В уровне ядра==
*OSPF, на всех интерфейсах. Также включаем TE внутри OSPF.
*OSPF, на всех интерфейсах. Также включаем TE внутри OSPF.
*MPLS с RSVP-TE LSP между всеми PE (full-mesh). LSP будут использоваться как для EVPN, так и для IP VPN.
*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-сессии.
*MP-BGP для EVPN и IP VPN. Конфигурируется сессия с P-роутером, который в свою очередь также является и RR (и советуют настроить bfd-detection). Включаем необходимые family: inet-vpn, evpn.


==На доступе==
==На уровне доступа==
*В сторону CE настраиваем отдельный логический интерфейс для каждого Instance с требуемыми вланами.
*В сторону CE настраиваем отдельный логический интерфейс для каждого instance с требуемыми вланами.


*ESI - Ethernet Segment ID: тербуется для multi-homing. Первый октет = Type, остальные - ID. Вид: ''00:11:11:11:11:11:11:11:11:11''.
*ESI - Ethernet Segment ID: требуется для multi-homing. Первый октет = Type, остальные - ID. Вид: ''00:11:11:11:11:11:11:11:11:11''.


Задаем ''all-active'', что обеспечивает балансировку между линками.
Задаем ''all-active'', что обеспечивает балансировку между линками CE <> PE.
*LACP даже с одним линком имеет смысл: дает возможность определить действительно ли по линку ходит трафик или нет. Если LACP развалится, значит сигнальные сообщения не проходят по физическим линкам внутри LACP. Также при добавлении или исключении линка из LACP не страдает передача трафика.
*LACP даже с одним линком имеет смысл: дает возможность определить действительно ли по линку ходит трафик или нет. Если LACP развалится, значит сигнальные сообщения не проходят по физическим линкам внутри LACP. Также при добавлении или исключении линка из LACP не страдает передача трафика. LACP в лабе настроен между двумя PE и свитчем на стороне CE.


  set interface xe-1/0/0 gither-options 802.3.ad ae0 '''hold-time up 180000 down 0'''  
  set interface xe-1/0/0 gither-options 802.3.ad ae0 '''hold-time up 180000 down 0'''  


*также задается одинаковый system-id для LACP на обоих РЕ. При этом СЕ думает, что LACP установлен с одним устройством.
*Задается одинаковый system-id для LACP на обоих РЕ (Node's System ID, encoded as a MAC address). При этом СЕ свитч думает, что LACP установлен с одним устройством.
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'''; }}


==Сервисы==
==Сервисы==
Строка 93: Строка 120:
Для этого EVPN используется только 1 влан = 100, в данном случае.
Для этого EVPN используется только 1 влан = 100, в данном случае.


mac 00:00:00:01:01:01 - для irb-интерфейсов одного EVPN на разных частях, используют одинаковые ip/mac. Делается для упрощения конфига, уменьшения control plane перезгрузки, и минимизации времени восстановления при падении PE.
mac 00:00:00:01:01:01 - для irb-интерфейсов одного EVPN в разных site, используют одинаковые ip/mac. Делается для упрощения конфига, уменьшения control plane перегрузки, и минимизации времени восстановления при падении PE.


default-gateway do-not-advertise - т.к. для irb указаны одинаковые ip/mac, то можно выключить функцию анонсирования MAC/IP binding между PE.
default-gateway do-not-advertise - т.к. для irb указаны одинаковые ip/mac, то можно выключить функцию анонсирования MAC/IP binding между PE.


*'''EVPN VLAN-aware''': несколько пользователей с независимыми vlan и ip.
*'''EVPN VLAN-aware''': несколько пользователей с независимыми vlan и ip.
Оба сервиса могут использовать vlan translation (настраивается на PE), что дает возможность использовать разные вланы в разных частях.
Оба сервиса могут использовать vlan translation (настраивается на PE), что дает возможность использовать разные вланы в разных site.


Хорошей практикой считается настраивать VLAN-aware, даже используется всего 1 vlan. Так сказать, задел на будущее.
Хорошей практикой считается настраивать VLAN-aware, даже когда используется всего 1 vlan. Так сказать, задел на будущее.


Пример конфига:
Пример конфига:
Строка 162: Строка 189:
             '''translate 222 202'''; }}}}}
             '''translate 222 202'''; }}}}}


*'''IP-VPN''': За маршрутизацию между VLAN отвечает irb-интерфейс, присвоенный с общий IP VPN. Также через него можно осуществлять маршрутизацию и с внешним миром.
*'''IP-VPN''': За маршрутизацию между VLAN отвечает irb-интерфейс, присвоенный в общий IP VPN. Также через него можно осуществлять маршрутизацию и с внешним миром.


Можно добавлять разные irb в разные IP VPN, чтобы разделить L3 трафик.
Можно добавлять разные irb в разные IP VPN, чтобы разделить L3 трафик.
Строка 207: Строка 234:
- vrf-export IpVpnAddCommunities; - добавляет community помимо ipvpn (основное) еще и evpn (дополнительно обозначает evpn subnets and hosts).  
- 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.
- vrf-import IpVpnDiscardEvpnSubnets; - т.к. evpn subnets and hosts уже синхронизируются путем ''Host MAC/IP Synchronization'', то передавать эту информацию через IP VPN - избыточно, поэтому маршруты с таким community будут отброшены, прилетев на PE.
 
==Remote PE==
==Remote PE==
В лабе, удаленный PE31 получает все маршруты от других PE в сети. При этом в RI IP-VPN на нем настроен только vrf-target target:65000:101, который соответствует COMM-IPVPN-1, таким образом, community, соответствующие EVPN маршрутам, будут просто игнорироваться для этого site.
В лабе, удаленный PE31 получает все маршруты от других PE в сети. При этом в RI IP-VPN на нем настроен только vrf-target target:65000:101, который соответствует COMM-IPVPN-1, таким образом, маршруты с community, соответствующие EVPN, будут просто игнорироваться для этого site.


'''Aliasing''':
'''Aliasing''':
Строка 232: Строка 260:
  router-id 31.31.31.31;
  router-id 31.31.31.31;
  autonomous-system 65000;
  autonomous-system 65000;
  forwarding-table {
  '''forwarding-table''' {
  export lb; }}
  '''export lb'''; }}
=Verification=
 
==На ядре==
=Траблшутинг EVPN=
 
==На уровне ядра==
*OSPF adjacencies
*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.
*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
*BFD session: show bfd session
*LSPs to all remote PE - are up.
*LSPs to all remote PE - are up.
==На доступе==
 
==На уровне доступа==
*PE-CE links: interfaces are UP, LACP is ok.
*PE-CE links: interfaces are UP, LACP is ok.
==Multi-homing==
==Multi-homing==
Это важная фитча. Для ее корректной работы требуется настройка одинакового ESI на разных multi-homing PE. Таким образом PE узнают друг о друге.
Несколько PE соединяются с одним CE. Это важная фитча. Обеспечивает надежную работу при link-fail или node-fail. Также обеспечивает балансировку для PE <> CE линков.


ES route имеет Type 4 и имеет несколько других важных полей:
Для ее корректной работы требуется настройка одинакового ESI на разных multi-homing PE. Таким образом PE узнают друг о друге.
 
ES route имеет Type 4 и имеет несколько других важных полей (то, что будет прилетать на удаленный PE):
*Router's IP addr = loopback addr.
*Router's IP addr = loopback addr.
*ESI: 10 октетов. ES route будет принят PE только в том случае, если ESI для двух PE будет полностью совпадать.
*ESI: 10 октетов. ES route будет принят PE только в том случае, если ESI для двух PE будет полностью совпадать.
*ES Import RT community - полученный из ESI. Представляет из себя только 6 октетов. Поэтому для разных ESI, community может быть одинаковым. То есть судя только по community нельзя точно определить подходит ли пришедший route, но такой дополнительный метод проверки тем не менее значительно уменьшает кол-во routes, которое требуется рассмотреть в дальнейшем PE.
*ES Import RT community - полученный из ESI. Представляет из себя только 6 октетов. Поэтому для разных ESI, community может быть одинаковым. То есть судя только по community нельзя точно определить подходит ли пришедший route, но такой дополнительный метод проверки тем не менее значительно уменьшает кол-во routes, которое требуется рассмотреть в дальнейшем PE.


Для проверки и просмотра полученных ES routes можно вывести все доступные варианты след образом:
Для проверки и просмотра полученных ES routes:
  > show route table bgp.evpn.0 detail | '''find "4:/1"'''
  PE11> 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)
  '''4:12.12.12.12:0::111111111111111111:12.12.12.12/304''' (1 entry, 0 announced)
             *BGP    Preference: 170/-101
             *BGP    Preference: 170/-101
Строка 261: Строка 295:
                     Originator ID: 12.12.12.12
                     Originator ID: 12.12.12.12
                     Communities: '''es-import-target:11-11-11-11-11-11'''
                     Communities: '''es-import-target:11-11-11-11-11-11'''
Также в таблице ''default.evpn.evpn.0'' будут хранится все ES route локального PE, в том виде, когда к ним еще не присоединилась community конкретного EVI
Также в таблице ''default.evpn.evpn.0'' будут хранится все ES route локального PE, в том виде, когда к ним еще не присоединилась community конкретного EVI
  cse@PE11> show route table __default_evpn__.evpn.0 | find 4:
  PE11> show route table __default_evpn__.evpn.0 | find 4:
  4:11.11.11.11:0::111111111111111111:11.11.11.11/304
  4:11.11.11.11:0::111111111111111111:11.11.11.11/304
                   *[EVPN/170] 04:40:23
                   *[EVPN/170] 04:40:23
Строка 270: Строка 305:
                       AS path: I, validation-state: unverified
                       AS path: I, validation-state: unverified
                     > to 10.11.12.12 via ae1.0, label-switched-path from-11-to-12
                     > to 10.11.12.12 via ae1.0, label-switched-path from-11-to-12
===Designated forwarder===
===Designated forwarder===
Сразу после установления Multi-homing peering между PE выбирается Designated Forwarder для ES.
Сразу после установления Multi-homing peering между PE выбирается Designated Forwarder для ES.
Строка 280: Строка 316:
#далее производится выбор DF для каждого vlana. V mod N (V = VLAN, N = кол-во PE в multi-homing). Если в EVPN несколько вланов, то берется наименьший vid.  
#далее производится выбор DF для каждого vlana. V mod N (V = VLAN, N = кол-во PE в multi-homing). Если в EVPN несколько вланов, то берется наименьший vid.  


Передачей BUM трафика занимается '''DF PE'''. Backup PE будет отбрасывать такие пакеты.
Передачей BUM трафика занимается '''DF PE'''. Backup PE будет отбрасывать BUM.
  cse@PE11> show evpn instance EVPN-1 esi 00:11:11:11:11:11:11:11:11:11 extensive
  cse@PE11> show evpn instance EVPN-1 esi 00:11:11:11:11:11:11:11:11:11 extensive
  Instance: EVPN-1
  Instance: EVPN-1
Строка 307: Строка 343:


===Auto-Discovery===
===Auto-Discovery===
Multi-homed-PE пересылают всем удаленным PE 2 типа маршрутов:
Multi-homed-PE пересылают всем удаленным PE два типа маршрутов:
====Auto-discovery route for ESI====
====Auto-discovery route for ESI====


Строка 313: Строка 349:


Передаваемые маршруты имеют следующие параметры:
Передаваемые маршруты имеют следующие параметры:
*список RT, соответствующих EVI
*RT, соответствующий EVI
*ESI
*ESI
*ESI label extended community: split horizont label + multi-homing mode (all-active/single-active).  
*ESI label extended community: split horizont label + multi-homing mode (all-active/single-active).  
Строка 326: Строка 362:


====Auto-Discovery route per EVI====
====Auto-Discovery route per EVI====
В all-active multi-homing есть Aliasing (load-balancing). Большиство изученных маков будут передаваться от PE1 из multi-homing, при этом aliasing будет обеспечивать балансировку обратного трафика и второму PE2.  
В all-active multi-homing есть Aliasing (load-balancing). Большинство изученных маков будут передаваться от PE1 из multi-homing, но при этом aliasing будет обеспечивать балансировку обратного трафика и второму PE2.  


Для single-active: функция тоже будет работать в качестве обеспечения ''Backup-path''.  
Для single-active: функция тоже будет работать в качестве обеспечения ''Backup-path''.  
Строка 334: Строка 370:
*ESI
*ESI
*Aliasing Label
*Aliasing Label
Когда PE изучает новый мой, то PE отправляет MAC Advertisment route, который состоит из MAC, MPLS service label, ESI (от ужаленного PE).  
Когда PE изучает новый MAC, то PE отправляет MAC Advertisment route, который состоит из MAC, MPLS service label, ESI (от remote PE).  


Удаленный PE сравнивает полученный ESI с ESI в обоих Auto-Discovery routes и определяет состав multi-homing PEs, которым он сможет направить обратный трафик по MAC.
remote PE сравнивает полученный ESI с ESI в обоих Auto-Discovery routes и определяет состав multi-homing PEs, которым он сможет направить обратный трафик по MAC.


Когда удаленный PE отправляет пакет обратно PE1, отправившего MAC Advertisement route, используется '''service label'''.  
Когда remote PE отправляет пакет обратно PE1, отправившего MAC Advertisement route, используется '''service label'''.  


Когда удаленный PE отправляет пакет обратно пиру PE1 (PE2), используется '''aliasing label'''.
Когда remote PE отправляет пакет обратно пиру PE1 (PE2), используется '''aliasing label'''.


Для каждого EVPN можно увидеть метки от удаленных PE.
Для каждого EVPN можно увидеть метки от remote PE.
  show evpn instance EVPN-1 extensive
  show evpn instance EVPN-1 extensive
===Inclusive multicast===
===Inclusive multicast===
Type = 3
Type = 3
Строка 359: Строка 396:
На удаленном PE: снимается transport label, распознается IM метка и BUM трафик.
На удаленном PE: снимается transport label, распознается IM метка и BUM трафик.


*P2MP LSPs: эффективная утилизация полосы в ядре, но могут быть проблемы с мастабируемостью, т.к. нужно выбирать точку копирования трафика.
*P2MP LSPs: эффективная утилизация полосы в ядре, но могут быть проблемы с масштабируемостью, т.к. нужно выбирать точку копирования трафика.


Чтобы избежать подобных проблем: используем чистый EVPN, где точка копирования трафика уже выбрана - ingress PE.
Чтобы избежать подобных проблем: используем чистый EVPN, где точка копирования трафика уже выбрана - ingress PE.
Строка 368: Строка 405:
                     > to 10.11.1.1 via xe-1/2/0.0, label-switched-path from-11-to-12
                     > to 10.11.1.1 via xe-1/2/0.0, label-switched-path from-11-to-12


Также наличие IM от каждого remote PE можно проверить тут:
Наличие IM от каждого remote PE можно проверить тут:
  PE11> show evpn instance EVPN-1 extensive
  PE11> show evpn instance EVPN-1 extensive


Строка 377: Строка 414:
  Route Distinguisher: 21.21.21.21:1
  Route Distinguisher: 21.21.21.21:1
  PMSI: Flags 0x0: Label 311168: '''Type INGRESS-REPLICATION 21.21.21.21'''
  PMSI: Flags 0x0: Label 311168: '''Type INGRESS-REPLICATION 21.21.21.21'''
==L2 Operations==
 
==L2 процессы внутри EVPN==
===MAC learning===
===MAC learning===
Когда PE находит новый MAC на EVI access interface, он добавляет MAC в соответствующую L2 forwarding table (MAC-VRF). Затем передает MAC Advertisment route остальным PE.  
Когда PE изучает новый MAC на EVI access interface, он добавляет MAC в соответствующую L2 forwarding table (MAC-VRF). Затем передает MAC Advertisment route остальным PE.  


MAC Adv route:
MAC Adv route:
Строка 397: Строка 435:
ESI - для балансировки, при работе multi-homing PE. Multi-homed PEs анонсируют свою связь через одинаковый ESI (в Auto Discovery route). Когда remote PE получает MAC adv route, видит в нем ESI, понимает какие PE относятся к этому ESI и при необходимости послать трафик к MAC, балансирует между PE1 и PE2.
ESI - для балансировки, при работе multi-homing PE. Multi-homed PEs анонсируют свою связь через одинаковый ESI (в Auto Discovery route). Когда remote PE получает MAC adv route, видит в нем ESI, понимает какие PE относятся к этому ESI и при необходимости послать трафик к MAC, балансирует между PE1 и PE2.


Также ESI полезно при передаче MAC между multi-homing пирами. PE1 получил MAC от пира, net-hop = local interface PE1. Локальный интерфейс PE1 будет в приоритете, по сравнению с ядром. Поэтому когда PE1 прилетит MAC adv route от remote PE, то он будет просто отброшен.
Также ESI полезно при передаче MAC между multi-homing пирами. PE1 получил MAC от пира, next-hop = local interface PE1. Локальный интерфейс PE1 будет в приоритете, по сравнению с ядром. Поэтому когда на PE1 прилетит MAC adv route от remote PE, то он будет просто отброшен.


  PE11> show evpn instance EVPN-1 extensive
  PE11> show evpn instance EVPN-1 extensive
  PE11> show evpn mac-table
  PE11> show evpn mac-table
Отображение MAC, ESI, IP (если есть). По сути тоже самое, что и forwarding table
Отображение MAC, ESI, IP (если есть). По сути тоже самое, что и forwarding table
  PE11> show evpn database instance EVPN-1
  PE11> show evpn database instance EVPN-1
Если для MAC есть IP, то его можно посмотреть так:
Если для MAC есть IP, то его можно посмотреть так:
  PE11> show route table EVPN-1.evpn.0 evpn-mac-address 00:50:56:8c:76:67
  PE11> show route table EVPN-1.evpn.0 evpn-mac-address 00:50:56:8c:76:67
Строка 409: Строка 449:
                       AS path: I, validation-state: unverified
                       AS path: I, validation-state: unverified
                     > to 10.11.1.1 via xe-1/2/0.0, label-switched-path from-11-to-22
                     > to 10.11.1.1 via xe-1/2/0.0, label-switched-path from-11-to-22
===L2 forwarding and Aliasing===
 
===L2 forwarding and aliasing===
Сама функция описана выше. Проверка:
Сама функция описана выше. Проверка:
  PE11> show evpn mac-table
  PE11> show evpn mac-table
Строка 443: Строка 484:
         to 10.11.1.1 via xe-1/2/0.0, '''label-switched-path from-11-to-22'''
         to 10.11.1.1 via xe-1/2/0.0, '''label-switched-path from-11-to-22'''


При проверка Aliasing в лабе выявили несколько мест, где балансируется трафик.
При проверке Aliasing в лабе, выявили несколько мест, где балансируется трафик.
*CE к multi homed PE1, PE2.
*CE к multi-homed PE1, PE2.
*PE балансируют при отправке к remote PE - чисто EVPN балансировка! '''Per flow.'''
*PE балансируют при отправке к remote PE - чисто EVPN балансировка! '''Per flow.'''
*Несколько LSP могут также делать балансировку.
*Несколько LSP могут также делать балансировку.
*LAG в разных метах.
*LAG в разных местах.
 
===MAC mobility===
===MAC mobility===
Переместили тачку в новый data-center. Новый PE изучил новый для себя MAC. Старый PE получил MAC Adv route и:
Переместили тачку в новый data-center. Новый PE изучил новый для себя MAC. Старый PE получил MAC Adv route и:
#Обновил свою forwarding table
#Обновил свою forwarding table
#MAC Mobility Extended Community включает в себя порядковый номер, который увеличивается при каждом новом перемещении тачки. Используется для определения MAC-flapping.
#MAC Mobility Extended Community включает в себя порядковый номер, который увеличивается при каждом новом перемещении тачки. Используется для определения MAC-flapping.
===L3 Operations===
 
==L3 процессы внутри EVPN==
===Синхронизация Default Gateway===
Функция для оптимизированного роутинга исходящего трафика от VM к любому адресу назначения и входящего трафика к VM по оптимизированному пути, при миграции VM в другую локацию.
 
#Конфигурируем IRB во VLAN или bridge domain.
#Добавляем IRB в IP VPN.
#Как только IRB начал выступать в качестве Def GW, PE передает MAC/IP Adv route (Def GW Ext Community) остальным PE и VM могут иметь связь с любым адресом назначения.
#Интеграция между IP VPN и EVPN требуется для Aliasing между multi-homed PE.
 
В лабе в примере для всех IRB.100 на всех site специально заданы одинаковые IP/MAC, для упрощения конфига. При таком варианте синхронизация осуществляется как бы статически. + в vrf задано: ''evpn default-gateway do-not-advertise''.
 
В обычном случае при задании разных mac/ip для irb, будем видеть следующее:
PE11> show route table EVPN-2.evpn.0 | match “200.1.1./”
2:22.22.22.22:2::200::00:00:c8:01:01:01::200.1.1.1/304
2:22.22.22.22:2::201::00:00:c9:01:01:02::201.1.1.2/304
2:22.22.22.22:2::202::00:00:ca:01:01:01::202.1.1.1/304
 
PE11> show bridge evpn peer-gateway-macs
Routing instance : EVPN-2
Bridging domain : V201, VLAN : 201
Installed GW MAC addresses:
00:00:c9:01:01:02
 
PE11> show route table EVPN-2.evpn.0 detail evpn-ethernet-tag-id 201 evpn-macaddress 00:00:c9:01:01:02
EVPN-2.evpn.0: 40 destinations, 40 routes (40 active, 0 holddown, 0 hidden)
2:22.22.22.22:2::'''201::00:00:c9:01:01:02::201.1.1.2'''/304 (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 22.22.22.22:2
Next hop type: Indirect
Source: 1.1.1.1
Protocol next hop: 22.22.22.22
AS path: I (Originator)
Cluster list: 1.1.1.1
Originator ID: 22.22.22.22
'''Communities: target:65000:2 evpn-default-gateway'''
Import Accepted
'''Route Label: 300288'''      - service label
ESI: 00:00:00:00:00:00:00:00:00:00
Localpref: 100
Router ID: 1.1.1.1
Primary Routing Table bgp.evpn.0
 
===Inter-VLAN Routing===
Функция ''Asymmetric IRB Forwarding'' - маршрутизация трафика между хостами разных EVPN VLANs, соединенных разными PE.
 
Ingress PE (Def GW) передает пакеты таким образом, который исключает необходимость делать route lookup в IP VPN VRF на egress PE. Вместо этого egress PE делает lookup в MAC-VRF по EVI dest host.
 
Если egress PE является multi-homed, то ingress PE может делать aliasing.
 
Что происходит на PE, когда он изучает новый MAC/IP:
*Появляется запись в IP VPN RVF: protocol '''EVPN''', next-hop IRB.vlan.
*Remote PE добавит полученную запись в IP VPN VRF: protocol '''BGP'''.
 
*PE передаст MAC/IP Adv route всем remote PE. Remote PE добавят полученный route в IP VPN VRF: protocol '''EVPN'''.
 
Т.о. на remote PE будет 2 записи, изученные по разным протоколам. Разница:
*BGP: VPN label + transport label (or tunnel label)
*EVPN: более сложный механизм для передачи пакета: Ingress PE перезаписывает Ethernet header (dest MAC, vlan) на значение, соответствующее хосту назначения. А soucre MAC теперь будет соответствовать local IRB MAC. Затем добавляет service или aliasing label + transport label.
 
BGP route - избыточные, их можно заблочить с помощью policy.
 
Проверяем.
 
В лабе: PE21: irb.200 - 200.1.1.26
 
Local PE:
PE21> show route 200.1.1.26
IPVPN-1.inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
200.1.1.26/32 *[EVPN/7] 00:04:52
> via irb.200
 
Remote PE:
PE11> show route 200.1.1.26
IPVPN-1.inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
200.1.1.26/32 *[EVPN/7] 00:49:50
> to 10.11.1.1 via xe-1/2/0.0, label-switched-path from-11-to-21
to 10.11.1.1 via xe-1/2/0.0, label-switched-path from-11-to-22
 
Layer 2 Ethernet header rewrite
PE11> show route 200.1.1.26 detail
IPVPN-1.inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
200.1.1.26/32 (1 entry, 1 announced)
*EVPN Preference: 7
Next hop type: Indirect
Next-hop reference count: 2
Next hop: 10.11.1.1 via xe-1/2/0.0, selected
'''Label-switched-path from-11-to-21'''
'''Label operation: Push 300256, Push 302448(top)'''
Load balance label: Label 300256: None; Label 302448: None;
Session Id: 0x152
Next hop type: Router, Next hop index: 696
Next hop: 10.11.1.1 via xe-1/2/0.0
'''Label-switched-path from-11-to-22'''
'''Label operation: Push 300320, Push 302464(top)'''
Label TTL action: no-prop-ttl, no-prop-ttl(top)
Load balance label: Label 300320: None; Label 302464: None;
Session Id: 0x152
Protocol next hop: 21.21.21.21
Label operation: Push 300256
Label TTL action: no-prop-ttl
Load balance label: Label 300256: None;
Composite next hop: 0x9569bac 643 INH Session ID: 0x150
Ethernet header rewrite:
'''SMAC: 00:00:c8:01:01:01, DMAC: 00:00:09:c1:b0:d4'''
'''TPID: 0x8100, TCI: 0x00c8, VLAN ID: 200, Ethertype: 0x0800'''
Indirect next hop: 0x96ae310 1048596 INH Session ID: 0x150
Protocol next hop: 22.22.22.22
Label operation: Push 300320
Label TTL action: no-prop-ttl
Load balance label: Label 300320: None;
Composite next hop: 0x9569b50 645 INH Session ID: 0x14f
Ethernet header rewrite:
'''SMAC: 00:00:c8:01:01:01, DMAC: 00:00:09:c1:b0:d4'''
'''TPID: 0x8100, TCI: 0x00c8, VLAN ID: 200, Ethertype: 0x0800'''
 
PE11> show evpn database instance EVPN-2 vlan-id 200
PE11> show evpn database instance EVPN-2 vlan-id 200 extensive
 
PE11> show evpn instance EVPN-2 extensive | find segments
Number of ethernet segments: 2
ESI: 00:22:22:22:22:22:22:22:22:22
Status: Resolved by NH 1048590
Number of remote PEs connected: 2
Remote PE MAC label Aliasing label Mode
22.22.22.22 '''300320 300320''' all-active
21.21.21.21 '''300256 300256''' all-active
 
Для проверки работы Aliasing, смотрим forwarding table:
PE11> show route forwarding-table destination 200.1.1.26 extensive | find IPVPN-1
Routing table: IPVPN-1.inet [Index 7]
Destination: 200.1.1.26/32
Nexthop:
Next-hop type: composite Index: 643 Reference: 2
Next-hop type: indirect Index: 1048596 Reference: 4
Nexthop:
Next-hop type: composite Index: 645 Reference: 2
Next-hop type: indirect Index: 1048597 Reference: 4
PE11> clear mpls lsp statistics
PE11> show mpls lsp statistics ingress
Ingress LSP: 4 sessions
To From State Packets Bytes LSPname
12.12.12.12 11.11.11.11 Up 2 148 from-11-to-12
21.21.21.21 11.11.11.11 Up 9942 2545152 from-11-to-21
22.22.22.22 11.11.11.11 Up 9943 2545408 from-11-to-22
31.31.31.31 11.11.11.11 Up 0 0 from-11-to-31
 
Для L3 балансировка также осуществляется с нескольких местах.
 
===Inbound Routing from IP VPN Site===
Интеграция IP VPN и EVPN положительно сказывается и на оптимизации входящего к хостам трафика, если он с источником находится не на одном site.
 
Egress PE, получив IP/MAC route от ingress PE, добавляет этот маршрут как изученный по BGP в VRF.table. После этого есть возможность смаршрутизировать трафик напрямую к data-center PE, ближайшему к хосту.
 
При миграции хоста, роутинг становился сложнее, т.к. не меняется обновление MAC/IP route и host route занимает некоторое время. Во время переезда у remote PE может сохраниться старая инфа о хосте и он пошлет туда трафик.
 
Учитывая этот небольшой недостаток, Mac mobility для L3 все же работает.
 
=MP-BGP EVPN Route Summary=
*Type 1: '''Ethernet Auto-Discovery''': per ESI, used for fast convergence (MAC Mass Withdrawal) and Split Horizont filtering. For Aliasing. Used only when multi-homing used. ESI Label Extended Community, includes multi-homing mode.
*Type 2: '''MAC Advertisement''': MAC and MAC/IP. Used for MAC learning, MAC Mobility, Aliasing, Def GW Synch., Asymmetric IRB Forwarding. Learned MAC/IP bindings generate EVPN host routes, which added to  IP VPN VRF for optimizing inbound routing to host. Def GW Ext Community - for MAC/IP of RIB. MAC Mobility Ext Community - for MAC flapping.
*Type 3: '''Inclusive Multicast''': Includes IM label, used when forwarding BUM traffic between PEs.
*Type 4: '''Ethernet Segment''': For discovery of multi-homed neigh and DF election. Only used when multi-homing is configured. ES-Import Ext Community - from ESI, used by receiving PE to filter incoming advertisment.
show route table bgp.evpn.0
 
Route Formats:
{| class="wikitable"
|-
! Ресурс !! ссылка !! описание
|-
|1 - Ethernet Auto-Discovery per ESI||1:21.21.21.21:0::222222222222222222::FFFF:FFFF/304||
*Route Type “1”
*RD unique to advertising
*ESI
*Ethernet Tag Id – reserved“0xFFFFFFFF”
|-
|1 - Ethernet Auto-Discovery per EVI || 1:21.21.21.21:1::222222222222222222::0/304 ||
*Route Type “1”
*RD of advertising PE’s EVI
*ESI
*Ethernet Tag Id “0”
|-
|2 - MAC Advertisement||2:21.21.21.21:1::100::00:00:09:c1:b0:d7/304||
*Route Type “2”
*RD of advertising PE’s EVI
*VLAN ID
*MAC Address
|-
|2 - MAC/IP Advertisement||2:21.21.21.21:1::100::00:00:09:c1:b0:d7::100.1.1.29/304||
*Same as MAC Advertisement but includes host’s IP address
|-
|3 - Inclusive Multicast||3:21.21.21.21:1::100::21.21.21.21/304||
*Route Type “3”
*RD of advertising PE’s EVI
*VLAN ID
*Originator PE Loopback IP address
|-
|4 - Ethernet Segment||4:12.12.12.12:0::111111111111111111:12.12.12.12/304||
*Route Type “4”
*RD unique to advertising PE
*ESI
*Originator PE LoopbackIP address
|}
=High Availability=
==Падене линка ==
При падении линка (CE <> multi-homing PE), статус EVI тоже станет - down. И PE уберет все прежде переданные IP VPN и EVPN маршруты, Auto-Discovery per ESI, Auto-Discovery per EVI.
Также, если PE был DF, то эту роль подхватит backup router.
 
==Восстановление линка==
Если сконфигурирован hold-up timer, то ничего не изменится, пока таймер не истечет.
 
Когда таймер истек, LACP между PE <> CE собрался, EVIs на PE стали активными, PE передает ES, IM, Auto-Discovery routes => new DF election. Параллельно с этим PE уже начинает получать трафик от remote PEs и CE.
 
==Падение узла==
Отключили multi-homing PE: LSP, которые на него терминировались - упадут (Path ERr message). У remote PE упавший PE удалится из возможных вариантов маршрутов с next-hop PE - для L2 и L3. Трафик без перерыва просто будет передаваться второму multi-homing PE. Также до PE упадут все протоколы маршрутизации (OSPF, MP-BGP). Второй multi-homed PE станет DF.
 
==Восстановление узла==
Опять же, если настроен hold-timer на интерфейсах, то при восстановлении PE, все процессы восстановятся не сразу. Таймер лучше настроить, т.к. без него при поднятии линков трафик начнет передаваться к PE,  но на PE еще не будут установлены OSPF, BGP, LSP... Трафик полетит в никуда.
 
Наличие LACP между CE и PE значительно уменьшает потерю пакетов.
 
=Дополнительная информация=
*[[DC]]
*[[L2VPN]]
*[[VPLS]]

Текущая версия на 18:23, 25 декабря 2021


Основы EVPN

Обеспечивает виртуальную многоточечную связность между разными L2 доменами через IP или MPLS сеть. Внедрить можно уже на существующей сети, потому что в ядре уже используются нужные технологии: MPLS или IP.

Отлично подходит для соединения data-centers sites.

CE, включенный в EVPN видит всю сеть как один бродкаст домен (большой свитч).

Control-plane mac-learning => all-active multihoming, traffic load balancing, MAC mobility.

Имеет хорошую возможность эффективно роутить вх и исх трафик, даже при миграции хостов в data-centers.

Имеет хорошие показатели по сходимости при link failure и node failure.

По аналогии с другими 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.

MAC-learning на control-plane позволяет примерять policy и другие опции к MAC, изученными между PE, что делает подобный mac-learning более эффективным и дает возможность обеспечивать защиту на сети.

С использованием EVPN, можно реализовать на сети много разных топологий: E-LINE, E-LAN, E-TREE.

EVPN полезно внедрять ISP, предоставляющим своим клиентам L2VPN, L3VPN, Internet access и которые дополнительно хотели бы для существующих клиентов предоставить облачные сервисы и хранение данных.

Также EVPN эффективно использовать для соединения разных data-centers (DC) site.

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 GW и при переезде VM на другой PE, PE будет проксировать arp от имени изученного Def GW и маршрутизировать трафик от VM напрямую к destination.

Таким же образом, через snooping ARP и DHCP пакетов, происходит заучивание ip-адресов хостов EVPN дата-центров. Называется это Host MAC/IP Synchronization'. После этого появляется возможность передавать трафик PE, ближайшему к хосту. Этот метод совместим c MAC migration.

Asymmetric IRB Forwarding: L2 заголовок перезаписывает ingress PE перед отправкой пакета. Это позволяет dest PE обойтись без L3 lookup, когда он производит передачу пакета.

  • Уменьшение утилизации полосы пропускания для multi-destination трафика между разными частями дата-центра в разных местах.
  • PE делают Proxy ARP: изучая ip хостов и Def GW.
  • P2MP or MP2MP LSPs между сторонами дата-центров.
  • Поддерживает инкапсуляцию разных данных. Например, GRE tunnels с IPSEC.

Конфигурация EVPN

Пример конфига разбирается на примере лабы, поднятой в книге: Day One - EVPN

EVPN laba.png

Для поддержки 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.

На уровне доступа

  • В сторону CE настраиваем отдельный логический интерфейс для каждого instance с требуемыми вланами.
  • ESI - Ethernet Segment ID: требуется для multi-homing. Первый октет = Type, остальные - ID. Вид: 00:11:11:11:11:11:11:11:11:11.

Задаем all-active, что обеспечивает балансировку между линками CE <> PE.

  • LACP даже с одним линком имеет смысл: дает возможность определить действительно ли по линку ходит трафик или нет. Если LACP развалится, значит сигнальные сообщения не проходят по физическим линкам внутри LACP. Также при добавлении или исключении линка из LACP не страдает передача трафика. LACP в лабе настроен между двумя PE и свитчем на стороне CE.
set interface xe-1/0/0 gither-options 802.3.ad ae0 hold-time up 180000 down 0 
  • Задается одинаковый system-id для LACP на обоих РЕ (Node's System ID, encoded as a MAC address). При этом СЕ свитч думает, что LACP установлен с одним устройством.
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; }}

Сервисы

  • 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 в разных site, используют одинаковые 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), что дает возможность использовать разные вланы в разных site.

Хорошей практикой считается настраивать 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.

Remote PE

В лабе, удаленный 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; }}

Траблшутинг EVPN

На уровне ядра

  • 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

Несколько PE соединяются с одним CE. Это важная фитча. Обеспечивает надежную работу при link-fail или node-fail. Также обеспечивает балансировку для PE <> CE линков.

Для ее корректной работы требуется настройка одинакового ESI на разных multi-homing PE. Таким образом PE узнают друг о друге.

ES route имеет Type 4 и имеет несколько других важных полей (то, что будет прилетать на удаленный PE):

  • 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:

PE11> 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

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.

Выборы:

  1. сортировка по Lo addr (от меньшего к большему, как я понимаю)
  2. роутерам по-порядку назначаются номера, начиная с 0. Роутер с наименьшим номеров - стал DF.
  3. далее производится выбор DF для каждого vlana. V mod N (V = VLAN, N = кол-во PE в multi-homing). Если в EVPN несколько вланов, то берется наименьший vid.

Передачей BUM трафика занимается DF PE. Backup PE будет отбрасывать BUM.

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 два типа маршрутов:

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 изучает новый MAC, то PE отправляет MAC Advertisment route, который состоит из MAC, MPLS service label, ESI (от remote PE).

remote PE сравнивает полученный ESI с ESI в обоих Auto-Discovery routes и определяет состав multi-homing PEs, которым он сможет направить обратный трафик по MAC.

Когда remote PE отправляет пакет обратно PE1, отправившего MAC Advertisement route, используется service label.

Когда remote PE отправляет пакет обратно пиру PE1 (PE2), используется aliasing label.

Для каждого EVPN можно увидеть метки от remote 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

L2 процессы внутри EVPN

MAC learning

Когда PE изучает новый MAC на EVI access interface, он добавляет MAC в соответствующую L2 forwarding table (MAC-VRF). Затем передает MAC Advertisment route остальным PE.

MAC Adv route:

  • RT
  • MAC
  • Ethernet tag = VLAN ID
  • ESI
  • IP, если известен или если сконфигурирован IRB.
  • MPLS service label / MAC route label
  • Default Gateway Extended Community - что сконфигурировано на IRB.
  • MAC Mobility Extended Community.

Как только изучен MAC, PE передает MAC Adv route без привязки к IP. Как только появилась привязка, PE посылает новый MAC Adv route. Этот процесс - Host Mac/IP Synchronization.

PE также передает MAC/IP локального IRB интерфейса, используя Def Gateway Ext Community, которое сигнализирует удаленному PE, что он должен роутить трафик от имени другого PE. Этот процесс - Default Gateway Synchronization.

ESI - для балансировки, при работе multi-homing PE. Multi-homed PEs анонсируют свою связь через одинаковый ESI (в Auto Discovery route). Когда remote PE получает MAC adv route, видит в нем ESI, понимает какие PE относятся к этому ESI и при необходимости послать трафик к MAC, балансирует между PE1 и PE2.

Также ESI полезно при передаче MAC между multi-homing пирами. PE1 получил MAC от пира, next-hop = local interface PE1. Локальный интерфейс PE1 будет в приоритете, по сравнению с ядром. Поэтому когда на PE1 прилетит MAC adv route от remote PE, то он будет просто отброшен.

PE11> show evpn instance EVPN-1 extensive
PE11> show evpn mac-table

Отображение MAC, ESI, IP (если есть). По сути тоже самое, что и forwarding table

PE11> show evpn database instance EVPN-1

Если для MAC есть IP, то его можно посмотреть так:

PE11> show route table EVPN-1.evpn.0 evpn-mac-address 00:50:56:8c:76:67
2:22.22.22.22:1::100::00:50:56:8c:76:67::100.1.1.10/304
*[BGP/170] 1d 01:03:50, 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-22

L2 forwarding and aliasing

Сама функция описана выше. Проверка:

PE11> show evpn mac-table
Routing instance : EVPN-1
Bridging domain : __EVPN-1__, VLAN : 100
  MAC                 MAC      Logical          NH     RTR
address             flags    interface         Index     ID
00:00:09:c1:b0:d7   DC                     1048609   1048609

Чтобы понять что это за PE, сначала ищем какому ESI принадлежит next-hop:

PE11> show evpn instance EVPN-1 extensive
Instance: EVPN-1
 Route Distinguisher: 11.11.11.11:1
 VLAN ID: 100
 Number of ethernet segments: 2
   ESI: 00:22:22:22:22:22:22:22:22:22
     Status: Resolved by NH 1048609
     Number of remote PEs connected: 2
  Remote PE   MAC label  Aliasing label Mode
  21.21.21.21 300848     300848 all-active
  22.22.22.22 301040     301040 all-active

Затем ищем метку для ESI:

PE11> show route table mpls.0 | match EVPN-1 | match esi
301184      *[EVPN/7] 2d 03:35:55, routing-instance EVPN-1, route-type Egress- MAC, ESI 00:11:11:11:11:11:11:11:11:11
301200      *[EVPN/7] 2d 03:35:55, routing-instance EVPN-1, route-type Egress- MAC, ESI 00:22:22:22:22:22:22:22:22:22

Ищем next-hop для этой метки:

PE11> show route label 301200
301200		*[EVPN/7] 2d 03:44:05, routing-instance EVPN-1, route-type Egress-
MAC, ESI 00:22:22:22:22:22:22:22:22:22
     > to 10.11.1.1 via xe-1/2/0.0, label-switched-path from-11-to-21
        to 10.11.1.1 via xe-1/2/0.0, label-switched-path from-11-to-22

При проверке Aliasing в лабе, выявили несколько мест, где балансируется трафик.

  • CE к multi-homed PE1, PE2.
  • PE балансируют при отправке к remote PE - чисто EVPN балансировка! Per flow.
  • Несколько LSP могут также делать балансировку.
  • LAG в разных местах.

MAC mobility

Переместили тачку в новый data-center. Новый PE изучил новый для себя MAC. Старый PE получил MAC Adv route и:

  1. Обновил свою forwarding table
  2. MAC Mobility Extended Community включает в себя порядковый номер, который увеличивается при каждом новом перемещении тачки. Используется для определения MAC-flapping.

L3 процессы внутри EVPN

Синхронизация Default Gateway

Функция для оптимизированного роутинга исходящего трафика от VM к любому адресу назначения и входящего трафика к VM по оптимизированному пути, при миграции VM в другую локацию.

  1. Конфигурируем IRB во VLAN или bridge domain.
  2. Добавляем IRB в IP VPN.
  3. Как только IRB начал выступать в качестве Def GW, PE передает MAC/IP Adv route (Def GW Ext Community) остальным PE и VM могут иметь связь с любым адресом назначения.
  4. Интеграция между IP VPN и EVPN требуется для Aliasing между multi-homed PE.

В лабе в примере для всех IRB.100 на всех site специально заданы одинаковые IP/MAC, для упрощения конфига. При таком варианте синхронизация осуществляется как бы статически. + в vrf задано: evpn default-gateway do-not-advertise.

В обычном случае при задании разных mac/ip для irb, будем видеть следующее:

PE11> show route table EVPN-2.evpn.0 | match “200.1.1./”
	2:22.22.22.22:2::200::00:00:c8:01:01:01::200.1.1.1/304
	2:22.22.22.22:2::201::00:00:c9:01:01:02::201.1.1.2/304
	2:22.22.22.22:2::202::00:00:ca:01:01:01::202.1.1.1/304
PE11> show bridge evpn peer-gateway-macs
	Routing instance : EVPN-2
	Bridging domain : V201, VLAN : 201
		Installed GW MAC addresses:
		00:00:c9:01:01:02
PE11> show route table EVPN-2.evpn.0 detail evpn-ethernet-tag-id 201 evpn-macaddress 00:00:c9:01:01:02
EVPN-2.evpn.0: 40 destinations, 40 routes (40 active, 0 holddown, 0 hidden)
2:22.22.22.22:2::201::00:00:c9:01:01:02::201.1.1.2/304 (1 entry, 1 announced)
	*BGP Preference: 170/-101
		Route Distinguisher: 22.22.22.22:2
		Next hop type: Indirect
		Source: 1.1.1.1
		Protocol next hop: 22.22.22.22
		AS path: I (Originator)
		Cluster list: 1.1.1.1
		Originator ID: 22.22.22.22
		Communities: target:65000:2 evpn-default-gateway
		Import Accepted
		Route Label: 300288       - service label
		ESI: 00:00:00:00:00:00:00:00:00:00
		Localpref: 100
		Router ID: 1.1.1.1
		Primary Routing Table bgp.evpn.0

Inter-VLAN Routing

Функция Asymmetric IRB Forwarding - маршрутизация трафика между хостами разных EVPN VLANs, соединенных разными PE.

Ingress PE (Def GW) передает пакеты таким образом, который исключает необходимость делать route lookup в IP VPN VRF на egress PE. Вместо этого egress PE делает lookup в MAC-VRF по EVI dest host.

Если egress PE является multi-homed, то ingress PE может делать aliasing.

Что происходит на PE, когда он изучает новый MAC/IP:

  • Появляется запись в IP VPN RVF: protocol EVPN, next-hop IRB.vlan.
  • Remote PE добавит полученную запись в IP VPN VRF: protocol BGP.
  • PE передаст MAC/IP Adv route всем remote PE. Remote PE добавят полученный route в IP VPN VRF: protocol EVPN.

Т.о. на remote PE будет 2 записи, изученные по разным протоколам. Разница:

  • BGP: VPN label + transport label (or tunnel label)
  • EVPN: более сложный механизм для передачи пакета: Ingress PE перезаписывает Ethernet header (dest MAC, vlan) на значение, соответствующее хосту назначения. А soucre MAC теперь будет соответствовать local IRB MAC. Затем добавляет service или aliasing label + transport label.

BGP route - избыточные, их можно заблочить с помощью policy.

Проверяем.

В лабе: PE21: irb.200 - 200.1.1.26

Local PE:
PE21> show route 200.1.1.26
IPVPN-1.inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
200.1.1.26/32 	*[EVPN/7] 00:04:52
		> via irb.200
Remote PE:
PE11> show route 200.1.1.26
IPVPN-1.inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
200.1.1.26/32 *[EVPN/7] 00:49:50
		> to 10.11.1.1 via xe-1/2/0.0, label-switched-path from-11-to-21
		to 10.11.1.1 via xe-1/2/0.0, label-switched-path from-11-to-22
Layer 2 Ethernet header rewrite
PE11> show route 200.1.1.26 detail
IPVPN-1.inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
200.1.1.26/32 (1 entry, 1 announced)
	*EVPN Preference: 7
		Next hop type: Indirect
		Next-hop reference count: 2
		Next hop: 10.11.1.1 via xe-1/2/0.0, selected
			Label-switched-path from-11-to-21
			Label operation: Push 300256, Push 302448(top)
		Load balance label: Label 300256: None; Label 302448: None;
		Session Id: 0x152
		Next hop type: Router, Next hop index: 696
		Next hop: 10.11.1.1 via xe-1/2/0.0
			Label-switched-path from-11-to-22
			Label operation: Push 300320, Push 302464(top)
		Label TTL action: no-prop-ttl, no-prop-ttl(top)
		Load balance label: Label 300320: None; Label 302464: None;
		Session Id: 0x152
		Protocol next hop: 21.21.21.21
		Label operation: Push 300256
		Label TTL action: no-prop-ttl
		Load balance label: Label 300256: None;
		Composite next hop: 0x9569bac 643 INH Session ID: 0x150
		Ethernet header rewrite:
			SMAC: 00:00:c8:01:01:01, DMAC: 00:00:09:c1:b0:d4
			TPID: 0x8100, TCI: 0x00c8, VLAN ID: 200, Ethertype: 0x0800
		Indirect next hop: 0x96ae310 1048596 INH Session ID: 0x150
		Protocol next hop: 22.22.22.22
		Label operation: Push 300320
		Label TTL action: no-prop-ttl
		Load balance label: Label 300320: None;
		Composite next hop: 0x9569b50 645 INH Session ID: 0x14f
		Ethernet header rewrite:
			SMAC: 00:00:c8:01:01:01, DMAC: 00:00:09:c1:b0:d4
			TPID: 0x8100, TCI: 0x00c8, VLAN ID: 200, Ethertype: 0x0800
PE11> show evpn database instance EVPN-2 vlan-id 200
PE11> show evpn database instance EVPN-2 vlan-id 200 extensive
PE11> show evpn instance EVPN-2 extensive | find segments
Number of ethernet segments: 2
ESI: 00:22:22:22:22:22:22:22:22:22
Status: Resolved by NH 1048590
Number of remote PEs connected: 2
	Remote PE 	MAC label	Aliasing label	Mode
	22.22.22.22	300320 		300320 			all-active
	21.21.21.21	300256 		300256			all-active
Для проверки работы Aliasing, смотрим forwarding table:
PE11> show route forwarding-table destination 200.1.1.26 extensive | find IPVPN-1
Routing table: IPVPN-1.inet [Index 7]
Destination: 200.1.1.26/32
Nexthop:
Next-hop type: composite Index: 643 Reference: 2
Next-hop type: indirect Index: 1048596 Reference: 4
Nexthop:
Next-hop type: composite Index: 645 Reference: 2
Next-hop type: indirect Index: 1048597 Reference: 4


PE11> clear mpls lsp statistics
PE11> show mpls lsp statistics ingress
Ingress LSP: 4 sessions
To 			From 		State 	Packets Bytes 	LSPname
12.12.12.12	11.11.11.11 Up 		2 		148 	from-11-to-12
21.21.21.21	11.11.11.11 Up 		9942 	2545152 from-11-to-21
22.22.22.22	11.11.11.11 Up 		9943 	2545408 from-11-to-22
31.31.31.31	11.11.11.11 Up 		0 		0 		from-11-to-31

Для L3 балансировка также осуществляется с нескольких местах.

Inbound Routing from IP VPN Site

Интеграция IP VPN и EVPN положительно сказывается и на оптимизации входящего к хостам трафика, если он с источником находится не на одном site.

Egress PE, получив IP/MAC route от ingress PE, добавляет этот маршрут как изученный по BGP в VRF.table. После этого есть возможность смаршрутизировать трафик напрямую к data-center PE, ближайшему к хосту.

При миграции хоста, роутинг становился сложнее, т.к. не меняется обновление MAC/IP route и host route занимает некоторое время. Во время переезда у remote PE может сохраниться старая инфа о хосте и он пошлет туда трафик.

Учитывая этот небольшой недостаток, Mac mobility для L3 все же работает.

MP-BGP EVPN Route Summary

  • Type 1: Ethernet Auto-Discovery: per ESI, used for fast convergence (MAC Mass Withdrawal) and Split Horizont filtering. For Aliasing. Used only when multi-homing used. ESI Label Extended Community, includes multi-homing mode.
  • Type 2: MAC Advertisement: MAC and MAC/IP. Used for MAC learning, MAC Mobility, Aliasing, Def GW Synch., Asymmetric IRB Forwarding. Learned MAC/IP bindings generate EVPN host routes, which added to IP VPN VRF for optimizing inbound routing to host. Def GW Ext Community - for MAC/IP of RIB. MAC Mobility Ext Community - for MAC flapping.
  • Type 3: Inclusive Multicast: Includes IM label, used when forwarding BUM traffic between PEs.
  • Type 4: Ethernet Segment: For discovery of multi-homed neigh and DF election. Only used when multi-homing is configured. ES-Import Ext Community - from ESI, used by receiving PE to filter incoming advertisment.
show route table bgp.evpn.0

Route Formats:

Ресурс ссылка описание
1 - Ethernet Auto-Discovery per ESI 1:21.21.21.21:0::222222222222222222::FFFF:FFFF/304
  • Route Type “1”
  • RD unique to advertising
  • ESI
  • Ethernet Tag Id – reserved“0xFFFFFFFF”
1 - Ethernet Auto-Discovery per EVI 1:21.21.21.21:1::222222222222222222::0/304
  • Route Type “1”
  • RD of advertising PE’s EVI
  • ESI
  • Ethernet Tag Id “0”
2 - MAC Advertisement 2:21.21.21.21:1::100::00:00:09:c1:b0:d7/304
  • Route Type “2”
  • RD of advertising PE’s EVI
  • VLAN ID
  • MAC Address
2 - MAC/IP Advertisement 2:21.21.21.21:1::100::00:00:09:c1:b0:d7::100.1.1.29/304
  • Same as MAC Advertisement but includes host’s IP address
3 - Inclusive Multicast 3:21.21.21.21:1::100::21.21.21.21/304
  • Route Type “3”
  • RD of advertising PE’s EVI
  • VLAN ID
  • Originator PE Loopback IP address
4 - Ethernet Segment 4:12.12.12.12:0::111111111111111111:12.12.12.12/304
  • Route Type “4”
  • RD unique to advertising PE
  • ESI
  • Originator PE LoopbackIP address

High Availability

Падене линка

При падении линка (CE <> multi-homing PE), статус EVI тоже станет - down. И PE уберет все прежде переданные IP VPN и EVPN маршруты, Auto-Discovery per ESI, Auto-Discovery per EVI. Также, если PE был DF, то эту роль подхватит backup router.

Восстановление линка

Если сконфигурирован hold-up timer, то ничего не изменится, пока таймер не истечет.

Когда таймер истек, LACP между PE <> CE собрался, EVIs на PE стали активными, PE передает ES, IM, Auto-Discovery routes => new DF election. Параллельно с этим PE уже начинает получать трафик от remote PEs и CE.

Падение узла

Отключили multi-homing PE: LSP, которые на него терминировались - упадут (Path ERr message). У remote PE упавший PE удалится из возможных вариантов маршрутов с next-hop PE - для L2 и L3. Трафик без перерыва просто будет передаваться второму multi-homing PE. Также до PE упадут все протоколы маршрутизации (OSPF, MP-BGP). Второй multi-homed PE станет DF.

Восстановление узла

Опять же, если настроен hold-timer на интерфейсах, то при восстановлении PE, все процессы восстановятся не сразу. Таймер лучше настроить, т.к. без него при поднятии линков трафик начнет передаваться к PE, но на PE еще не будут установлены OSPF, BGP, LSP... Трафик полетит в никуда.

Наличие LACP между CE и PE значительно уменьшает потерю пакетов.

Дополнительная информация