Hola habr. Actualment sóc el responsable del curs de "Enginyer de xarxes" a OTUS.
En previsió de l'inici d'una nova matrícula per al curs , he preparat una sèrie d'articles sobre la tecnologia VxLAN EVPN.
Hi ha una gran quantitat de material sobre el funcionament de VxLAN EVPN, així que vull recollir diverses tasques i pràctiques per resoldre problemes en un centre de dades modern.
A la primera part del cicle de tecnologia VxLAN EVPN, vull considerar una manera d'organitzar la connectivitat L2 entre amfitrions a la part superior d'una fàbrica de xarxa.
Tots els exemples es realitzaran al Cisco Nexus 9000v, muntat en la topologia Spine-Leaf. En aquest article no ens detendrem a configurar la xarxa Underlay.
- xarxa subjacent
- Peering BGP per a la família d'adreces l2vpn evpn
- Configuració NVE
- Suprimir-arp
xarxa subjacent
La topologia utilitzada és la següent:
Establim l'adreça a tots els dispositius:
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.20Comprovem que hi hagi connectivitat IP entre tots els dispositius:
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, intraComprovem que s'ha creat el domini VPC i que els dos commutadors hagin superat la comprovació de coherència i que la configuració dels dos nodes sigui idèntica:
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
Finalment, podem passar a la configuració de la xarxa Overlay.
Com a part de l'article, cal organitzar una xarxa entre amfitrions, tal com es mostra al diagrama següent:
Per configurar una xarxa de superposició, heu d'habilitar BGP als interruptors Spine i Leaf amb suport per a la família l2vpn evpn:
feature bgp
nv overlay evpnA continuació, heu de configurar el peering BGP entre Leaf i Spine. Per simplificar la configuració i optimitzar la distribució de la informació d'encaminament, configurem Spine com a servidor Route-Reflector. Escriurem tot el Leaf a la configuració mitjançant plantilles per tal d'optimitzar la configuració.
Per tant, la configuració de Spine té aquest aspecte:
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 LEAFLa configuració de l'interruptor Leaf és 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 SPINEA l'espina dorsal, comproveu el peering amb tots els interruptors 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 0Com podeu veure, no hi va haver problemes amb BGP. Passem a configurar VxLAN. La configuració addicional només es realitzarà al costat dels interruptors Leaf. La columna vertebral només actua com a nucli de la xarxa i només participa en la transmissió del trànsit. Tot el treball sobre l'encapsulació i la definició del camí només es produeix als interruptors Leaf.
Configuració NVE
NVE - interfície virtual de xarxa
Abans de començar la configuració, introduïm una mica de terminologia:
VTEP - Vitual Tunnel End Point, el dispositiu on comença o acaba el túnel VxLAN. VTEP no és necessàriament cap dispositiu de xarxa. També pot actuar un servidor que admeti la tecnologia VxLAN. A la nostra topologia, tots els interruptors Leaf són VTEP.
VNI - Virtual Network Index - identificador de xarxa dins de VxLAN. Podeu fer una analogia amb la VLAN. Tanmateix, hi ha algunes diferències. Quan s'utilitza un teixit, les VLAN només esdevenen úniques dins d'un commutador Leaf i no es transmeten per la xarxa. Però cada VLAN es pot associar amb un número VNI que ja es transmet per la xarxa. Com es veu i com es pot utilitzar es parlarà a continuació.
Habiliteu la funció perquè la tecnologia VxLAN funcioni i la possibilitat d'associar números de VLAN amb un número VNI:
feature nv overlay
feature vn-segment-vlan-basedConfigurem la interfície NVE, que és responsable del funcionament de VxLAN. Aquesta interfície és responsable d'encapsular fotogrames a les capçaleres VxLAN. Podeu fer una analogia amb la interfície del túnel per a GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0A l'interruptor Leaf-21, tot es crea sense problemes. Tanmateix, si comprovem la sortida de l'ordre show nve peers, llavors estarà buit. Aquí heu de tornar a la configuració del VPC. Veiem que Leaf-11 i Leaf-12 estan aparellats i units per un domini VPC. Això dóna lloc a la situació següent:
L'amfitrió-2 envia una trama a la fulla-21 per ser transmesa a través de la xarxa a l'amfitrió-1. Tanmateix, Leaf-21 veu que l'adreça MAC de l'amfitrió-1 està disponible mitjançant dos VTEP alhora. Què hauria de fer Leaf-21 en aquest cas? Després de tot, això vol dir que podria aparèixer un bucle a la xarxa.
Per resoldre aquesta situació, necessitem que el Leaf-11 i el Leaf-12 també actuïn com un dispositiu dins de la fàbrica. Es resol de manera senzilla. A la interfície Loopback des de la qual estem construint el túnel, afegiu l'adreça secundària. L'adreça secundària ha de ser la mateixa als dos VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryAixí, des del punt de vista d'altres VTEP, obtenim la següent topologia:
És a dir, ara el túnel es construirà entre l'adreça IP del Leaf-21 i la IP virtual entre dos Leaf-11 i Leaf-12. Ara no hi haurà problemes per aprendre l'adreça MAC des de dos dispositius i el trànsit es pot transferir d'un VTEP a un altre. Quin dels dos VTEP processarà el trànsit es decideix mitjançant la taula d'encaminament de 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, intraCom podeu veure més amunt, l'adreça 10.255.1.10 està disponible immediatament mitjançant dos Next-hops.
En aquesta etapa, vam descobrir la connectivitat bàsica. Passem a configurar la interfície NVE:
Habilitarem immediatament Vlan 10 i l'associarem amb VNI 10000 a cada fulla per als amfitrions. Configureu un túnel L2 entre hosts
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPAra comprovem nve peers i la taula per a 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 iA dalt només veiem rutes EVPN de tipus 3. Aquest tipus de rutes parlen de peer (Full), però on són els nostres amfitrions?
I el cas és que la informació sobre els amfitrions MAC es transmet mitjançant el tipus de ruta EVPN 2
Per veure els nostres amfitrions, heu de configurar el tipus de ruta EVPN 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoFem ping des de l'amfitrió-2 fins a l'amfitrió-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 msI a continuació podem veure que el tipus de ruta 2 va aparèixer a la taula BGP amb l'adreça MAC dels amfitrions: 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 iA continuació, podeu veure informació detallada sobre Actualització, en què heu rebut informació sobre l'amfitrió MAC. A continuació no hi ha tota la sortida de l'ordre
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
<........>Vegem com són els marcs quan es passen per la fàbrica:
Suprimir-ARP
Genial, tenim una connexió L2 entre amfitrions i això podria ser el final. Tanmateix, no tot és tan senzill. Mentre tinguem pocs amfitrions, no hi haurà problemes. Però imaginem-nos situacions que tenim centenars i milers d'amfitrions. Quin problema ens podem enfrontar?
Aquest problema és el trànsit BUM (Broadcast, Unknown Unicast, Multicast). En el marc d'aquest article, considerarem l'opció de combatre el trànsit de difusió.
El principal generador de difusió a les xarxes Ethernet són els propis amfitrions mitjançant el protocol ARP.
Nexus implementa el següent mecanisme per tractar les sol·licituds ARP: suppress-arp.
Aquesta característica funciona així:
- L'amfitrió-1 envia una sol·licitud APR a l'adreça de difusió de la seva xarxa.
- La sol·licitud arriba a l'interruptor Leaf i en comptes de passar aquesta sol·licitud a la fàbrica cap a Host-2, el Leaf es contesta i indica l'IP i MAC desitjats.
Així, la petició de Broadcast no va arribar a la fàbrica. Però, com pot funcionar això si Leaf només coneix l'adreça MAC?
Tot és bastant senzill, el tipus de ruta EVPN 2, a més de l'adreça MAC, pot transmetre un paquet MAC / IP. Per fer-ho, el Leaf s'ha de configurar amb una adreça IP a la VLAN. La pregunta sorgeix, quina IP demanar? A Nexus, és possible crear una adreça distribuïda (la mateixa) a tots els commutadors:
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 macAixí, des del punt de vista dels amfitrions, la xarxa es veurà així:
Comproveu 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
<......>A partir de la sortida de l'ordre, es pot veure que a l'EVPN tipus de ruta 2, a més del MAC, ara també veiem l'adreça IP de l'amfitrió.
Tornem a la configuració de suprimir-arp. Aquesta configuració s'habilita per a cada VNI per separat:
interface nve1
member vni 10000
suppress-arpAleshores hi ha alguna dificultat:
- Aquesta funció requereix espai a la memòria TCAM. Donaré un exemple de configuració per a suppress-arp:
hardware access-list tcam region arp-ether 256Aquesta configuració requerirà doble amplada. És a dir, si configureu 256, s'ha d'alliberar a TCAM 512. La configuració de TCAM està fora de l'abast d'aquest article, ja que la configuració de TCAM només depèn de la tasca que se us hagi assignat i pot variar d'una xarxa a una altra.
- La implementació de suppress-arp s'ha de fer a tots els interruptors Leaf. Tanmateix, la complexitat pot sorgir en configurar parells de fulla situats en un domini VPC. Quan es canvia TCAM, la coherència entre els parells es trencarà i un node pot quedar fora de servei. A més, pot ser que calgui un reinici del dispositiu per aplicar la configuració de canvi de TCAM.
Com a resultat, hauríeu de considerar acuradament si val la pena implementar aquesta configuració en una fàbrica que funcioni en la vostra situació.
Així conclou la primera part del cicle. A la següent part, considerarem l'encaminament a través d'una fàbrica VxLAN amb separació de xarxa entre diferents VRF.
I ara convido a tothom , en què parlaré detalladament del curs. Els primers 20 participants que s'inscriguin a aquest seminari web rebran un certificat de descompte per correu electrònic en un termini d'1 a 2 dies després de l'emissió.
Font: www.habr.com