Здравей, Хабр. В момента съм ръководител на курса "Мрежов инженер" в OTUS.
В навечерието на старта на новия набор курс , подготвих цикъл статии по технологията VxLAN EVPN.
Съществуват огромно множество материали по работа с VxLAN EVPN, затова искам да събера различни задачи и практики за решаване в съвременен ЦОД.
В първата част от цикъла по технологията VxLAN EVPN искам да разгледам как да организираме L2 свързаност между хостовете върху мрежовата фабрика.
Всички примери ще изпълняваме на Cisco Nexus 9000v, разположени в топология Spine-Leaf. Няма да се спираме на настройката на Underlay мрежата в рамките на тази статия.
- Underlay мрежа
- BGP пиринг за address-family l2vpn evpn
- Настройка на NVE
- Supress-arp
Underlay мрежа
Използваната топология изглежда по следния начин:
Нека зададем адресацията на всички устройства:
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 статус
----------------------------------------------------------------------------
Id Port Status Consistency Reason Active vlans
-- ------------ ------ ----------- ------ ---------------
5 Po5 up success success 1BGP пиринг
Накрая можем да преминем към настройка на Overlay мрежата.
В рамките на статията е необходимо да организираме мрежа между хостовете, както е показано на схемата по-долу:
За да настроим Overlay мрежата, е необходимо да включим BGP с поддръжка на семейството l2vpn evpn на комутаторите Spine и Leaf:
feature bgp
nv overlay evpnСлед това е необходимо да настроим BGP пиъринг между Leaf и Spine. За улесняване на настройката и оптимизиране на разпространението на маршрутната информация, Spine конфигурираме като Route-Reflector server. Всички 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 ще проверим пиъринга с всички 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 играе роля само на основа на мрежата и се занимава само с предаването на трафика. Цялата работа по инкапсулацията и определяне на пътя се реализира само на Leaf комутаторите.
Настройка на NVE
NVE — мрежов виртуален интерфейс
Преди да започнем настройката, нека въведем малко терминология:
VTEP — Виртуална Тунелна Крайна Точка, устройство, на което започва или завършва VxLAN тунел. VTEP не е задължително да бъде мрежово устройство. Може също да бъде и сървър с поддръжка на технологията VxLAN. В нашата топология всички Leaf комутатори са VTEP.
VNI — Виртуален Мрежов Идентификатор — идентификатор на мрежата в рамките на VxLAN. Може да се направи аналогия с VLAN. Въпреки това, има някои разлики. При използване на фабрикат, VLAN стават уникални само в рамките на един Leaf комутатор и не се предават по мрежата. Но с всеки VLAN може да бъде асоцииран номер VNI, който вече се предава по мрежата. Както изглежда това и как може да бъде използвано, ще бъде разгледано по-нататък.
Нека включим feature за работа с технологията VxLAN и възможността за асоцииране на номера VLAN с номера VNI:
feature nv overlay
feature vn-segment-vlan-basedНастройваме интерфейса NVE, който отговаря за работата на VxLAN. Този интерфейс всъщност е отговорен за инкапсулирането на кадри в заглавията на VxLAN. Може да се направи аналогия с интерфейса Tunnel за работа с 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 домейн. Оттук произлиза следната ситуация:
Host-2 изпраща един кадър към Leaf-21, за да го предаде по мрежата към Host-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-hop.
На този етап разгледахме основната свързаност. Прехвърляме се към настройката на интерфейса NVE:
Веднага активираме Vlan 10 и го асоциираме с VNI 10000 на всеки Leaf за хостовете. Настройваме 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 peers и таблицата за 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 е достъпен с вторичен адрес
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 route-type 2.
За да видим нашите хостове, е необходимо да настроим EVPN route-type 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И по-долу можем да видим, че в таблицата BGP се появиха route-type 2 с 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След това можем да разгледаме подробна информация за Update, в който получихме информация за MAC Host. По-долу е представено не всичкото изходно съдържание на командата
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
BGP маршрутизираща таблица информация за VRF default, адресно семейство L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777 ! изпратено Update с MAC Host. Не виртуален адрес VPC, а адрес Leaf
BGP маршрутизираща таблица вход за [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216,
версия 1507
Paths: (2 налични, най-добрият е #2)
Flags: (0x000202) (high32 00000000) на xmit-list, не е в l2rib\/evpn, не е в HW
Тип на пътя: вътрешен, пътят е валиден, не най-добър причина: адрес на съсед, без етикетирана следваща стъпка
AS-Path: НЯМА, пътят е източен вътрешно за AS
10.255.1.10 (метрика 81) от 10.255.1.102 (10.255.1.102) ! с кого точно изграждаме VxLAN тунел
Произход IGP, MED не е зададен, localpref 100, тегло 0
Получен етикет 10000 ! Номер VNI, който е асоцииран с VLAN, в който се намира Host
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Тук е видно, че RT е образуван автоматично на базата на номера на AS и VNI
Произходител: 10.255.1.11 Списък на клъстера: 10.255.1.102Нека видим как изглеждат пакетите, когато се предават през фабриката:
Suppress-ARP
Отлично, L2 свързаност между хостовете вече имаме и на това може да се приключи. Въпреки това не всичко е толкова просто. Докато имаме малко хостове, проблеми няма да възникнат. Но нека си представим ситуации, в които хостовете са стотици и хиляди. С каква проблематика можем да се сблъскаме?
Тази проблематика е BUM (Broadcast, Unknown Unicast, Multicast) трафик. В рамките на тази статия ще разгледаме вариант за справяне с broadcast трафика.
Основният генератор на Broadcast в Ethernet мрежи са самите хостове, чрез протокол ARP.
На nexus е реализиран следният механизъм за борба с ARP заявките — suppress-arp.
Работата на тази функция изглежда по следния начин:
- Host-1 изпраща ARP заявка на Broadcast адреса на своята мрежа.
- Заявката достига до Leaf комутатора и вместо да предаде тази заявка по-нататък в фабриката към Host-2 — Leaf отговаря сам и указва нужния IP и MAC.
По този начин Broadcast заявката не е стигнала до фабриката. Но как може да работи това, ако 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 ! задаваме виртуален mac за създаване на разпределен шлюз между всички комутатори
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! на всички Leaf задаваме еднакъв IP
fabric forwarding mode anycast-gateway ! казваме да използва виртуален 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За тази настройка ще е необходим double-wide. Тоест, ако зададете 256, то в TCAM е необходимо да освободите 512. Настройката на TCAM излиза извън обхвата на тази статия, тъй като настройката на TCAM зависи единствено от задачата, поставена пред Вас и може да варира от една мрежа до друга.
- Внедряването на suppress-arp е необходимо да се извърши на всички Leaf комутатори. Въпреки това, сложността може да възникне при настройването на парите Leaf, находящи се в домейна VPC. При промяна на TCAM, консистенцията между парите ще бъде нарушена и един от възлите може да спре да работи. Освен това, за прилагане на настройката, свързана с промените в TCAM, може да е необходима перезагрузка на устройството.
В резултат на това, трябва сериозно да се помисли дали в вашата ситуация да се внедри тази настройка на работеща фабрика.
С това завършваме първата част от цикъла. В следващата част ще разгледаме маршрутизацията през VxLAN фабрика с разделение на мрежите по различни VRF.
А сега каня всички на , в рамките на което подробно ще разкажа за курса. Първите 20 участници, регистрирали се за уебинара, ще получат сертификат за отстъпка на електронната си поща в течение на 1-2 дни след трансляцията.
Източник: habr.com
