Bună, habr. În prezent sunt liderul cursului pentru cursul de Inginer de rețea de la OTUS.
În așteptarea începerii unei noi înscrieri la curs , am pregătit o serie de articole despre tehnologia VxLAN EVPN.
Există o cantitate imensă de material despre cum funcționează VxLAN EVPN, așa că vreau să colectez diverse sarcini și practici pentru rezolvarea problemelor într-un centru de date modern.
În prima parte a seriei despre tehnologia VxLAN EVPN, vreau să analizez o modalitate de a organiza conectivitatea L2 între gazde pe partea de sus a unei structuri de rețea.
Toate exemplele vor fi realizate pe un Cisco Nexus 9000v, asamblat în topologia Spine-Leaf. Nu ne vom opri asupra configurarii unei rețele Underlay în acest articol.
- Rețea de bază
- Peering BGP pentru adresa-familie l2vpn evpn
- Configurarea NVE
- Suprima-arp
Rețea de bază
Topologia utilizată este următoarea:
Să setăm adresa pe toate dispozitivele:
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.20Să verificăm dacă există conectivitate IP între toate dispozitivele:
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, intraSă verificăm dacă domeniul VPC a fost creat și că ambele comutatoare au trecut de verificarea coerenței, iar setările de pe ambele noduri sunt identice:
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 1Peering BGP
În cele din urmă, puteți trece la configurarea rețelei Overlay.
Ca parte a articolului, este necesar să se organizeze o rețea între gazde, așa cum se arată în diagrama de mai jos:
Pentru a configura o rețea Overlay, trebuie să activați BGP pe comutatoarele Spine și Leaf cu suport pentru familia l2vpn evpn:
feature bgp
nv overlay evpnApoi, trebuie să configurați interogarea BGP între Leaf și Spine. Pentru a simplifica configurarea și optimizarea distribuției informațiilor de rutare, configurăm Spine ca server Route-Reflector. Vom scrie toate Leaf în configurație folosind șabloane pentru a optimiza configurarea.
Deci setările de pe Spine arată astfel:
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 LEAFConfigurarea comutatorului Leaf arată similară:
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 SPINEPe Spine, să verificăm peering-ul cu toate comutatoarele 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 0După cum puteți vedea, nu au fost probleme cu BGP. Să trecem la configurarea VxLAN. Configurarea ulterioară se va face numai pe partea frunză a comutatoarelor. Spine acționează doar ca nucleu al rețelei și este implicat doar în transmiterea traficului. Toate lucrările de încapsulare și de determinare a căii au loc numai pe comutatoarele Leaf.
Configurarea NVE
NVE - interfață virtuală de rețea
Înainte de a începe configurarea, să introducem câteva terminologii:
VTEP - Vitual Tunnel End Point, dispozitivul pe care începe sau se termină tunelul VxLAN. VTEP nu este neapărat un dispozitiv de rețea. Un server care acceptă tehnologia VxLAN poate acționa și ca server. În topologia noastră, toate comutatoarele Leaf sunt VTEP.
VNI - Virtual Network Index - identificator de rețea în VxLAN. Se poate face o analogie cu VLAN. Cu toate acestea, există unele diferențe. Când se utilizează un fabric, VLAN-urile devin unice doar într-un comutator Leaf și nu sunt transmise prin rețea. Dar fiecare VLAN poate avea asociat un număr VNI, care este deja transmis prin rețea. Cum arată și cum poate fi folosit va fi discutat în continuare.
Să activăm funcția pentru ca tehnologia VxLAN să funcționeze și capacitatea de a asocia numerele VLAN cu un număr VNI:
feature nv overlay
feature vn-segment-vlan-basedSă configuram interfața NVE, care este responsabilă pentru funcționarea VxLAN. Această interfață este responsabilă pentru încapsularea cadrelor în anteturile VxLAN. Puteți face o analogie cu interfața Tunnel pentru GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0Pe comutatorul Leaf-21 totul este creat fără probleme. Totuși, dacă verificăm rezultatul comenzii show nve peers, atunci va fi gol. Aici trebuie să reveniți la configurația VPC. Vedem că Leaf-11 și Leaf-12 funcționează în perechi și sunt unite printr-un domeniu VPC. Aceasta ne dă următoarea situație:
Host-2 trimite un cadru către Leaf-21, astfel încât să îl transmită prin rețea către Host-1. Cu toate acestea, Leaf-21 vede că adresa MAC a Host-1 este accesibilă prin două VTEP-uri simultan. Ce ar trebui să facă Leaf-21 în acest caz? La urma urmei, asta înseamnă că o buclă ar putea apărea în rețea.
Pentru a rezolva această situație, avem nevoie de Leaf-11 și Leaf-12 să acționeze ca un singur dispozitiv în fabrică. Soluția este destul de simplă. Pe interfața Loopback din care construim tunelul, adăugați o adresă secundară. Adresa secundară trebuie să fie aceeași pe ambele VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryAstfel, din punctul de vedere al altor VTEP-uri, obținem următoarea topologie:
Adică acum tunelul va fi construit între adresa IP a lui Leaf-21 și IP-ul virtual între două Leaf-11 și Leaf-12. Acum nu vor fi probleme de învățare a adresei MAC de pe două dispozitive, iar traficul se poate muta de la un VTEP la altul. Care dintre cele două VTEP-uri va procesa traficul este decis folosind tabelul de rutare de pe 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, intraDupă cum puteți vedea mai sus, adresa 10.255.1.10 este disponibilă imediat prin două Next-hop-uri.
În această etapă, ne-am ocupat de conectivitatea de bază. Să trecem la configurarea interfeței NVE:
Să activăm imediat Vlan 10 și să îl asociem cu VNI 10000 pe fiecare Leaf pentru gazde. Să instalăm un tunel L2 între gazde
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPAcum să verificăm nve peers și tabelul pentru 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 iMai sus vedem doar rute EVPN de tip 3. Acest tip de rută vorbește despre peer(Leaf), dar unde sunt gazdele noastre?
Chestia este că informațiile despre gazdele MAC sunt transmise prin ruta EVPN tip 2
Pentru a vedea gazdele noastre, trebuie să configurați ruta EVPN tip 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoSă dăm ping de la Host-2 la 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Și mai jos putem vedea că ruta-tip 2 cu adresa MAC gazdă a apărut în tabelul BGP - 5001.0007.0007 și 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În continuare, puteți vedea informații detaliate despre Update, în care ați primit informații despre MAC Host. Mai jos nu sunt toate rezultatele comenzii.
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
<........>Să vedem cum arată cadrele când sunt trecute prin fabrică:
Suprima-ARP
Super, avem acum comunicare L2 între gazde și am putea termina acolo. Cu toate acestea, nu toate sunt atât de simple. Atâta timp cât avem puține gazde nu vor fi probleme. Dar să ne imaginăm o situație în care avem sute și mii de gazde. Ce problemă ne-am putea confrunta?
Această problemă este traficul BUM (Broadcast, Unknown Unicast, Multicast). În acest articol, vom lua în considerare opțiunea de a trata traficul de difuzare.
Principalul generator de difuzare în rețelele Ethernet sunt gazdele prin intermediul protocolului ARP.
Nexus implementează următorul mecanism pentru a combate solicitările ARP - suppress-arp.
Această caracteristică funcționează după cum urmează:
- Host-1 trimite o cerere APR la adresa de difuzare a rețelei sale.
- Solicitarea ajunge la comutatorul Leaf și, în loc să transmită această solicitare mai departe fabricii către Host-2, Leaf răspunde singur și indică IP-ul și MAC-ul necesar.
Astfel, cererea Broadcast nu a mers la fabrică. Dar cum poate funcționa asta dacă Leaf știe doar adresa MAC?
Totul este destul de simplu, EVPN ruta-tip 2, pe lângă adresa MAC, poate transmite o combinație MAC/IP. Pentru a face acest lucru, trebuie să configurați o adresă IP în VLAN-ul pe Leaf. Apare întrebarea, ce IP ar trebui să setez? Pe nexus este posibil să creați o adresă distribuită (aceeași) pe toate comutatoarele:
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 macAstfel, din punctul de vedere al gazdelor, rețeaua va arăta astfel:
Să verificăm 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
<......>Din rezultatul comenzii puteți vedea că în EVPN ruta-tip 2, pe lângă MAC, acum vedem și adresa IP a gazdei.
Să revenim la setarea suppress-arp. Această setare este activată pentru fiecare VNI separat:
interface nve1
member vni 10000
suppress-arpApoi apare o oarecare complexitate:
- Pentru ca această caracteristică să funcționeze, este necesar spațiu în memoria TCAM. Iată un exemplu de setări pentru suppress-arp:
hardware access-list tcam region arp-ether 256Această setare va necesita o lățime dublă. Adică, dacă setați 256, atunci trebuie să eliberați 512 în TCAM. Configurarea TCAM depășește domeniul de aplicare al acestui articol, deoarece configurarea TCAM depinde doar de sarcina care ți-a fost atribuită și poate diferi de la o rețea la alta.
- Implementarea suppress-arp trebuie făcută pe toate comutatoarele Leaf. Cu toate acestea, complexitatea poate apărea la configurarea perechilor Leaf care locuiesc într-un domeniu VPC. Dacă TCAM este schimbat, consistența dintre perechi va fi ruptă și un nod poate fi scos din funcțiune. În plus, poate fi necesară o repornire a dispozitivului pentru a aplica setarea de modificare a TCAM.
În consecință, trebuie să vă gândiți cu atenție dacă, în situația dvs., merită să implementați această setare într-o fabrică în funcțiune.
Aceasta se încheie prima parte a seriei. În următoarea parte, vom analiza rutarea printr-o țesătură VxLAN cu separarea rețelelor în diferite VRF-uri.
Și acum îi invit pe toți , în cadrul căruia vă voi povesti în detaliu despre curs. Primii 20 de participanți care se înregistrează la acest webinar vor primi un certificat de reducere prin e-mail în termen de 1-2 zile de la difuzare.
Sursa: www.habr.com