VxLAN фабрика. Част 1

Здравейте habr. В момента съм ръководител на курса за "Мрежов инженер" в OTUS.
В очакване на началото на ново записване за курса "Системен инженер", подготвих поредица от статии за технологията VxLAN EVPN.

Има огромно количество материали за работата на VxLAN EVPN, така че искам да събера различни задачи и практики за решаване на проблеми в модерен център за данни.

В първата част от VxLAN EVPN технологичния цикъл искам да обмисля начин за организиране на L2 свързаност между хостове на върха на мрежова фабрика.

Всички примери ще бъдат изпълнени на Cisco Nexus 9000v, сглобен в топологията Spine-Leaf. В тази статия няма да се спираме на настройката на мрежата Underlay.

1. подложна мрежа
2. BGP пиъринг за фамилия адреси l2vpn evpn
3. NVE настройка
4. Потискане на arp

подложна мрежа

Използваната топология е следната:

Нека зададем адресиране на всички устройства:

Spine-1 - 10.255.1.101
Spine-2 - 10.255.1.102

Leaf-11 - 10.255.1.11
Leaf-12 - 10.255.1.12
Leaf-21 - 10.255.1.21

Host-1 - 192.168.10.10
Host-2 - 192.168.10.20

Нека проверим дали има IP свързаност между всички устройства:

Leaf21# sh ip route
<........>
10.255.1.11/32, ubest/mbest: 2/0                      ! Leaf-11 доступен чеерз два Spine
    *via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
    *via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 2/0                      ! Leaf-12 доступен чеерз два Spine
    *via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
    *via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.21/32, ubest/mbest: 2/0, attached
    *via 10.255.1.22, Lo0, [0/0], 00:02:20, local
    *via 10.255.1.22, Lo0, [0/0], 00:02:20, direct
10.255.1.101/32, ubest/mbest: 1/0
    *via 10.255.1.101, Eth1/4, [110/41], 00:00:06, ospf-UNDERLAY, intra
10.255.1.102/32, ubest/mbest: 1/0
    *via 10.255.1.102, Eth1/3, [110/41], 00:00:03, ospf-UNDERLAY, intra

Нека проверим дали VPC домейнът е създаден и двата комутатора са преминали проверката за съгласуваност и настройките на двата възела са идентични:

Leaf11# show vpc 

vPC domain id                     : 1
Peer status                       : peer adjacency formed ok
vPC keep-alive status             : peer is alive
Configuration consistency status  : success
Per-vlan consistency status       : success
Type-2 consistency status         : success
vPC role                          : primary
Number of vPCs configured         : 0
Peer Gateway                      : Disabled
Dual-active excluded VLANs        : -
Graceful Consistency Check        : Enabled
Auto-recovery status              : Disabled
Delay-restore status              : Timer is off.(timeout = 30s)
Delay-restore SVI status          : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router    : Disabled

vPC status
----------------------------------------------------------------------------
Id    Port          Status Consistency Reason                Active vlans
--    ------------  ------ ----------- ------                ---------------
5     Po5           up     success     success               1

BGP peering

Накрая можем да преминем към конфигуриране на мрежата Overlay.

Като част от статията е необходимо да се организира мрежа между хостове, както е показано на диаграмата по-долу:

За да конфигурирате мрежа с наслагване, трябва да активирате BGP на превключвателите Spine и Leaf с поддръжка за семейството l2vpn evpn:

feature bgp
nv overlay evpn

След това трябва да конфигурирате BGP peering между Leaf и Spine. За да опростим конфигурацията и да оптимизираме разпространението на информация за маршрутизиране, ние конфигурираме Spine като Route-Reflector сървър. Ще напишем всички Leaf в конфигурацията чрез шаблони, за да оптимизираме настройката.

Така че настройките на Spine изглеждат така:

router bgp 65001
  template peer LEAF 
    remote-as 65001
    update-source loopback0
    address-family l2vpn evpn
      send-community
      send-community extended
      route-reflector-client
  neighbor 10.255.1.11
    inherit peer LEAF
  neighbor 10.255.1.12
    inherit peer LEAF
  neighbor 10.255.1.21
    inherit peer LEAF

Настройката на превключвателя Leaf изглежда подобно:

router bgp 65001
  template peer SPINE
    remote-as 65001
    update-source loopback0
    address-family l2vpn evpn
      send-community
      send-community extended
  neighbor 10.255.1.101
    inherit peer SPINE
  neighbor 10.255.1.102
    inherit peer SPINE

На Spine проверете peering с всички Leaf ключове:

Spine1# sh bgp l2vpn evpn summary
<.....>
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.255.1.11     4 65001       7       8        6    0    0 00:01:45 0
10.255.1.12     4 65001       7       7        6    0    0 00:01:16 0
10.255.1.21     4 65001       7       7        6    0    0 00:01:01 0

Както можете да видите, нямаше проблеми с BGP. Нека да преминем към настройката на VxLAN. Допълнителна конфигурация ще бъде извършена само от страната на превключвателите Leaf. Spine действа само като ядро ​​на мрежата и участва само в предаването на трафик. Цялата работа по капсулирането и дефинирането на пътя се извършва само на листови превключватели.

NVE настройка

NVE - мрежов виртуален интерфейс

Преди да започнем настройката, нека въведем малко терминология:

VTEP - Витуална крайна точка на тунела, устройството, на което VxLAN тунелът започва или завършва. VTEP не е непременно мрежово устройство. Сървър, поддържащ технологията VxLAN, също може да действа. В нашата топология всички превключватели Leaf са VTEP.

VNI - Virtual Network Index - мрежов идентификатор в рамките на VxLAN. Можете да направите аналогия с VLAN. Все пак има някои разлики. Когато използвате тъкан, VLAN стават уникални само в рамките на един Leaf суич и не се предават по мрежата. Но всяка VLAN може да бъде свързана с VNI номер, който вече се предава по мрежата. Как изглежда и как може да се използва, ще разгледаме по-долу.

Активирайте функцията за работа на технологията VxLAN и възможността за свързване на VLAN номера с VNI номер:

feature nv overlay
feature vn-segment-vlan-based

Нека конфигурираме интерфейса NVE, който отговаря за работата на VxLAN. Този интерфейс е отговорен за капсулирането на рамки в заглавките на VxLAN. Можете да направите аналогия с тунелния интерфейс за GRE:

interface nve1
  no shutdown
  host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
  source-interface loopback0    ! интерфейс  с которого отправляем пакеты loopback0

На превключвателя Leaf-21 всичко се създава без проблеми. Въпреки това, ако проверим изхода на командата show nve peers, тогава ще бъде празен. Тук трябва да се върнете към настройката на VPC. Виждаме, че Leaf-11 и Leaf-12 са сдвоени и обединени от VPC домейн. Това води до следната ситуация:

Хост-2 изпраща един кадър до Leaf-21, който да бъде изпратен по мрежата до Хост-1. Leaf-21 обаче вижда, че MAC адресът на Host-1 е достъпен чрез два VTEP наведнъж. Какво трябва да направи Leaf-21 в този случай? В крайна сметка това означава, че в мрежата може да се появи цикъл.

За да разрешим тази ситуация, имаме нужда Leaf-11 и Leaf-12 също да действат като едно устройство във фабриката. Решава се съвсем просто. В интерфейса Loopback, от който изграждаме тунела, добавете вторичния адрес. Вторичният адрес трябва да е един и същ и на двата VTEP.

interface loopback0
 ip add 10.255.1.10/32 secondary

Така, от гледна точка на други VTEP, получаваме следната топология:

Тоест, сега тунелът ще бъде изграден между IP адреса на Leaf-21 и виртуалния IP между два Leaf-11 и Leaf-12. Сега няма да има проблеми с изучаването на MAC адреса от две устройства и трафикът може да се прехвърля от един VTEP към друг. Кой от двата VTEP ще обработва трафика се решава с помощта на таблицата за маршрутизиране на Spine:

Spine1# sh ip route
<.....>
10.255.1.10/32, ubest/mbest: 2/0
    *via 10.255.1.11, Eth1/1, [110/41], 1d01h, ospf-UNDERLAY, intra
    *via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra
10.255.1.11/32, ubest/mbest: 1/0
    *via 10.255.1.11, Eth1/1, [110/41], 1d22h, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 1/0
    *via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra

Както можете да видите по-горе, адресът 10.255.1.10 е достъпен веднага чрез два Next-hops.

На този етап разбрахме основната свързаност. Нека да преминем към настройката на NVE интерфейса:
Веднага ще активираме Vlan 10 и ще го свържем с VNI 10000 на всеки лист за хостове. Настройте L2 тунел между хостове

vlan 10                 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
  vn-segment 10000      ! Ассоциируем VLAN с номер VNI 

interface nve1
  member vni 10000      ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
    ingress-replication protocol bgp    ! указываем, что для распространения информации о хосте используем BGP

Сега нека проверим nve партньори и таблица за BGP EVPN:

Leaf21# sh nve peers
Interface Peer-IP          State LearnType Uptime   Router-Mac
--------- ---------------  ----- --------- -------- -----------------
nve1      10.255.1.10      Up    CP        00:00:41 n/a                 ! Видим что peer доступен с secondary адреса

Leaf11# sh bgp l2vpn evpn

   Network            Next Hop            Metric     LocPrf     Weight Path
Route Distinguisher: 10.255.1.11:32777    (L2VNI 10000)        ! От кого именно пришел этот l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]/88                                   ! EVPN route-type 3 - показывает нашего соседа, который так же знает об l2VNI10000
                      10.255.1.10                       100      32768 i
*>i[3]:[0]:[32]:[10.255.1.20]/88
                      10.255.1.20                       100          0 i
* i                   10.255.1.20                       100          0 i

Route Distinguisher: 10.255.1.21:32777
* i[3]:[0]:[32]:[10.255.1.20]/88
                      10.255.1.20                       100          0 i
*>i                   10.255.1.20                       100          0 i

По-горе виждаме маршрути само EVPN route-type 3. Този тип маршрути говорят за peer (Leaf), но къде са нашите хостове?
Работата е там, че информацията за MAC хостове се предава чрез EVPN маршрут тип 2

За да видите нашите хостове, трябва да конфигурирате EVPN тип маршрут 2:

evpn
  vni 10000 l2
    route-target import auto   ! в рамках данной статьи используем автоматический номер для route-target
    route-target export auto

Нека изпратим ping Host-2 към Host-1:

Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
36 bytes from 192.168.10.2: Destination Host Unreachable
Request 0 timed out
64 bytes from 192.168.10.1: icmp_seq=1 ttl=254 time=215.555 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=254 time=38.756 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=254 time=42.484 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=254 time=40.983 ms

И по-долу можем да видим, че route-type 2 се появи в BGP таблицата с MAC адреса на хостовете - 5001.0007.0007 и 5001.0008.0007

Leaf11# sh bgp l2vpn evpn
<......>

   Network            Next Hop            Metric     LocPrf     Weight Path
Route Distinguisher: 10.255.1.11:32777    (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216                      !  evpn route-type 2 и mac адрес хоста 1
                      10.255.1.10                       100      32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216                      ! evpn route-type 2 и mac адрес хоста 2
* i                   10.255.1.20                       100          0 i
*>l[3]:[0]:[32]:[10.255.1.10]/88
                      10.255.1.10                       100      32768 i
Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
                      10.255.1.20                       100          0 i
*>i                   10.255.1.20                       100          0 i

След това можете да видите подробна информация за Актуализация, в която сте получили информация за MAC хоста. По-долу не е целият резултат от командата

Leaf21# sh bgp l2vpn evpn 5001.0007.0007

BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777        !  отправил Update с MAC Host. Не виртуальный адрес VPC, а адрес Leaf
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216,
 version 1507
Paths: (2 available, best #2)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not i
n HW

  Path type: internal, path is valid, not best reason: Neighbor Address, no labe
led nexthop
  AS-Path: NONE, path sourced internal to AS
    10.255.1.10 (metric 81) from 10.255.1.102 (10.255.1.102)    ! с кем именно строим VxLAN тоннель
      Origin IGP, MED not set, localpref 100, weight 0
      Received label 10000         ! Номер VNI, который ассоциирован с VLAN, в котором находится Host
      Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8        ! Тут видно, что RT сформировался автоматически на основе номеров AS и VNI
      Originator: 10.255.1.11 Cluster list: 10.255.1.102
<........>

Нека да видим как изглеждат рамките, когато преминат през завода:

Потискане на ARP

Страхотно, имаме L2 връзка между хостовете и това може да е краят. Въпреки това, не всичко е толкова просто. Докато имаме малко домакини, няма да има проблеми. Но нека си представим ситуации, в които имаме стотици и хиляди хостове. С какъв проблем можем да се сблъскаме?

Този проблем е BUM(Broadcast, Unknown Unicast, Multicast) трафик. В рамките на тази статия ще разгледаме варианта за борба с излъчвания трафик.
Основният генератор на излъчване в Ethernet мрежите са самите хостове чрез ARP протокола.

Nexus прилага следния механизъм за работа с ARP заявки - suppress-arp.
Тази функция работи по следния начин:

1. Host-1 изпраща APR заявка до Broadcast адреса на своята мрежа.
2. Заявката достига до превключвателя на Leaf и вместо да предаде тази заявка към фабриката към Host-2, Leaf отговаря сам и посочва желаните IP и MAC.

По този начин заявката за излъчване не отиде във фабриката. Но как може да работи това, ако Leaf знае само MAC адреса?

Всичко е съвсем просто, EVPN route-type 2, в допълнение към MAC адреса, може да предава MAC / IP пакет. За да направите това, Leaf трябва да бъде конфигуриран с IP адрес във VLAN. Възниква въпросът какво IP да задам? На nexus е възможно да се създаде разпределен (един и същ) адрес на всички комутатори:

feature interface-vlan

fabric forwarding anycast-gateway-mac 0001.0001.0001    ! задаем virtual mac для создания распределенного шлюза между всеми коммутаторами

interface Vlan10
  no shutdown
  ip address 192.168.10.254/24          ! на всех Leaf задаем одинаковый IP
  fabric forwarding mode anycast-gateway    ! говорим использовать Virtual mac

Така от гледна точка на хостовете мрежата ще изглежда така:

Проверете BGP l2route evpn

Leaf11# sh bgp l2vpn evpn
<......>

   Network            Next Hop            Metric     LocPrf     Weight Path
Route Distinguisher: 10.255.1.11:32777    (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216
                      10.255.1.21                       100      32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
                      10.255.1.10                       100          0 i
* i                   10.255.1.10                       100          0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
                      10.255.1.10                       100          0 i
*>i                   10.255.1.10                       100          0 i

<......>

Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
                      10.255.1.20                       100          0 i
*>i                   10.255.1.20                       100          0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
*>i                   10.255.1.20                       100          0 i

<......>

От изхода на командата може да се види, че в EVPN route-type 2, в допълнение към MAC, сега виждаме и IP адреса на хоста.

Да се ​​върнем към настройката suppress-arp. Тази настройка е активирана за всеки VNI поотделно:

interface nve1
  member vni 10000   
    suppress-arp

Тогава има известна трудност:

• Тази функция изисква място в TCAM паметта. Ще дам пример за настройка за suppress-arp:

hardware access-list tcam region arp-ether 256

Тази настройка ще изисква двойна ширина. Тоест, ако зададете 256, тогава в TCAM трябва да бъде пуснат 512. Настройката на TCAM е извън обхвата на тази статия, тъй като настройката на TCAM зависи само от възложената ви задача и може да се различава от една мрежа в друга.

• Внедряването на suppress-arp трябва да се извърши на всички листови превключватели. Въпреки това може да възникне сложност при конфигуриране върху Leaf двойки, разположени във VPC домейн. При промяна на TCAM съгласуваността между двойките ще бъде нарушена и един възел може да бъде изваден от обслужване. Освен това може да се наложи рестартиране на устройството, за да се приложи настройката за промяна на TCAM.

В резултат на това трябва внимателно да обмислите дали си струва да приложите тази настройка на работеща фабрика във вашата ситуация.

С това приключва първата част от цикъла. В следващата част ще разгледаме маршрутизиране през VxLAN фабрика с разделяне на мрежата между различни VRF.

И сега каня всички безплатен уеб семинар, в който ще говоря подробно за курса. Първите 20 участници, които се регистрират за този уебинар, ще получат сертификат за отстъпка по имейл в рамките на 1-2 дни след излъчването.

Източник: www.habr.com