Saluton habr. Nuntempe mi estas la kursgvidanto por "Reto-Inĝeniero" ĉe OTUS.
Antaŭĝoje de la komenco de nova aliĝo por la kurso , Mi preparis serion da artikoloj pri VxLAN EVPN-teknologio.
Estas grandega kvanto da materialo pri la funkciado de VxLAN EVPN, do mi volas kolekti diversajn taskojn kaj praktikojn por solvi problemojn en moderna datumcentro.
En la unua parto de la VxLAN EVPN-teknologia ciklo, mi volas konsideri manieron organizi L2-konektecon inter gastigantoj supre de reto-fabriko.
Ĉiuj ekzemploj estos faritaj sur Cisco Nexus 9000v, kunvenita en la Spine-Leaf-topologio. Ni ne traktos starigi la Underlay-reton en ĉi tiu artikolo.
- submeta reto
- BGP peering por adreso-familio l2vpn evpn
- NVE-aranĝo
- Subpremi-arp
submeta reto
La topologio uzita estas kiel sekvas:
Ni agordu adresadon en ĉiuj aparatoj:
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.20Ni kontrolu, ke ekzistas IP-konekto inter ĉiuj aparatoj:
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, intraNi kontrolu, ke la VPC-domajno estas kreita kaj ambaŭ ŝaltiloj trapasis la konsekvencan kontrolon kaj la agordoj sur ambaŭ nodoj estas identaj:
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 1BGP peering
Fine, ni povas pluiri al agordo de la Overlay-reto.
Kiel parto de la artikolo, necesas organizi reton inter gastigantoj, kiel montrite en la suba diagramo:
Por agordi Overlay-reton, vi devas ebligi BGP sur la Spine kaj Leaf-ŝaltiloj kun subteno por la l2vpn evpn-familio:
feature bgp
nv overlay evpnPoste, vi devas agordi BGP peering inter Folio kaj Spine. Por simpligi la agordon kaj optimumigi la distribuadon de vojaj informoj, ni agordas Spine kiel Route-Reflector-servilo. Ni skribos ĉiujn Folion en la agordo per ŝablonoj por optimumigi la agordon.
Do la agordoj sur Spine aspektas jene:
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 aranĝo sur la Leaf-ŝaltilo aspektas simila:
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 SPINESur Spine, kontrolu peering per ĉiuj Leaf-ŝaltiloj:
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 0Kiel vi povas vidi, ne estis problemoj kun BGP. Ni pluiru al agordo de VxLAN. Plia agordo estos farita nur flanke de la Leaf-ŝaltiloj. Spino funkcias nur kiel la kerno de la reto kaj estas nur implikita en la transdono de trafiko. Ĉiuj laboroj pri enkapsuligo kaj padodifino okazas nur ĉe Folio-ŝaltiloj.
NVE-aranĝo
NVE - reto virtuala interfaco
Antaŭ ol komenci la aranĝon, ni enkonduku iom da terminologio:
VTEP - Vitual Tunnel End Point, la aparato sur kiu la VxLAN-tunelo komenciĝas aŭ finiĝas. VTEP ne estas nepre ia reta aparato. Servilo subtenanta VxLAN-teknologion ankaŭ povas agi. En nia topologio, ĉiuj Leaf-ŝaltiloj estas VTEP-oj.
VNI - Virtual Network Index - retidentigilo ene de VxLAN. Vi povas desegni analogion kun VLAN. Tamen, estas iuj diferencoj. Dum uzado de ŝtofo, VLANoj iĝas unikaj nur ene de unu Folio-ŝaltilo kaj ne estas elsenditaj tra la reto. Sed ĉiu VLAN povas esti asociita kun VNI-numero kiu jam estas elsendita tra la reto. Kiel ĝi aspektas kaj kiel ĝi povas esti uzata, estos diskutitaj sube.
Ebligu la funkcion por ke VxLAN-teknologio funkciu kaj la kapablon asocii VLAN-nombrojn kun VNI-numero:
feature nv overlay
feature vn-segment-vlan-basedNi agordu la NVE-interfacon, kiu respondecas pri la funkciado de VxLAN. Ĉi tiu interfaco respondecas pri enkapsuligado de kadroj en VxLAN-titoloj. Vi povas desegni analogion kun la Tunela interfaco por GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0Sur la ŝaltilo Leaf-21, ĉio estas kreita sen problemoj. Tamen, se ni kontrolas la eligon de la komando show nve peers, tiam ĝi estos malplena. Ĉi tie vi devas reveni al la agordo de VPC. Ni vidas, ke Leaf-11 kaj Leaf-12 estas parigitaj kaj kunigitaj per VPC-domajno. Ĉi tio rezultigas la sekvan situacion:
Gastiganto-2 sendas unu kadron al Folio-21 por esti elsendita tra la reto al Host-1. Tamen, Folio-21 vidas, ke la MAC-adreso de Host-1 disponeblas per du VTEP-oj samtempe. Kion devus fari Leaf-21 en ĉi tiu kazo? Post ĉio, ĉi tio signifas, ke buklo povus aperi en la reto.
Por solvi ĉi tiun situacion, ni bezonas Leaf-11 kaj Leaf-12 ankaŭ funkcii kiel unu aparato ene de la fabriko. Ĝi estas solvita tute simple. Sur la Loopback-interfaco de kiu ni konstruas la tunelon, aldonu la malĉefan adreson. Malĉefa adreso devas esti la sama ĉe ambaŭ VTEPoj.
interface loopback0
ip add 10.255.1.10/32 secondaryTiel, de la perspektivo de aliaj VTEP-oj, ni ricevas la sekvan topologion:
Tio estas, nun la tunelo estos konstruita inter la IP-adreso de Leaf-21 kaj la virtuala IP inter du Leaf-11 kaj Leaf-12. Nun ne estos problemoj pri lernado de la MAC-adreso de du aparatoj, kaj trafiko povas esti translokigita de unu VTEP al alia. Kiu el la du VTEP-oj prilaboros la trafikon, oni decidas per la vojtabelo sur 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, intraKiel vi povas vidi supre, la adreso 10.255.1.10 disponeblas tuj per du Next-hops.
En ĉi tiu etapo, ni eltrovis la bazan konekteblecon. Ni pluiru al agordo de la NVE-interfaco:
Ni tuj ebligos Vlan 10 kaj asocios ĝin kun VNI 10000 sur ĉiu Folio por gastigantoj. Agordu L2-tunelon inter gastigantoj
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPNun ni kontrolu nve samulojn kaj tabelon por 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 iSupre ni vidas itinerojn nur EVPN itinero-tipo 3. Ĉi tiu speco de itineroj parolas pri samulo (Folio), sed kie estas niaj gastigantoj?
Kaj la afero estas, ke informoj pri MAC-gastigantoj estas transdonitaj per EVPN-itinero-tipo 2
Por vidi niajn gastigantojn, vi devas agordi EVPN-itineran tipon 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoNi pingu de Gastiganto-2 al Gastiganto-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 msKaj sube ni povas vidi, ke itinero-tipo 2 aperis en la BGP-tabelo kun la MAC-adreso de la gastigantoj - 5001.0007.0007 kaj 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 iPoste, vi povas vidi detalajn informojn pri Ĝisdatigo, en kiu vi ricevis informojn pri la MAC-Gastiganto. Malsupre ne estas la tuta eligo de la komando
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
<........>Ni vidu kiel aspektas la kadroj kiam ili estas trapasitaj tra la fabriko:
Subpremi-ARP
Bonege, ni havas L2-konekton inter gastigantoj kaj ĉi tio povus esti la fino de ĝi. Tamen, ne ĉio estas tiel simpla. Dum ni havas malmultajn gastigantojn, ne estos problemoj. Sed ni imagu situaciojn, kiujn ni havas centojn kaj milojn da gastigantoj. Kian problemon ni povas alfronti?
Ĉi tiu problemo estas trafiko BUM (Broadcast, Nekonata Unicast, Multicast). En la kadro de ĉi tiu artikolo, ni konsideros la opcion batali elsendan trafikon.
La ĉefa Broadcast-generatoro en Eterretaj retoj estas la gastigantoj mem per la ARP-protokolo.
Nexus efektivigas la sekvan mekanismon por trakti ARP-petojn - suppress-arp.
Ĉi tiu funkcio funkcias jene:
- Gastiganto-1 sendas APR-peton al la Broadcast-adreso de sia reto.
- La peto atingas la Folio-ŝaltilon kaj anstataŭ pasi ĉi tiun peton plu al la fabriko al Host-2, la Folio respondas sin kaj indikas la deziratajn IP kaj MAC.
Tiel, la Broadcast-peto ne iris al la fabriko. Sed kiel tio povas funkcii se Leaf nur scias la MAC-adreson?
Ĉio estas sufiĉe simpla, EVPN-itinero-tipo 2, krom la MAC-adreso, povas transdoni MAC / IP-pakaĵon. Por fari tion, la Folio devas esti agordita kun IP-adreso en la VLAN. La demando ŝprucas, kian IP demandi? Sur nexus, eblas krei distribuitan (saman) adreson sur ĉiuj ŝaltiloj:
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 macTiel, el la vidpunkto de gastigantoj, la reto aspektos jene:
Kontrolu 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
<......>De la eligo de la komando, oni povas vidi, ke en EVPN-itinero-tipo 2, krom la MAC, ni nun ankaŭ vidas la IP-adreson de la gastiganto.
Ni revenu al la agordo subpremo-arp. Ĉi tiu agordo estas ebligita por ĉiu VNI aparte:
interface nve1
member vni 10000
suppress-arpTiam estas iom da malfacilaĵo:
- Ĉi tiu funkcio postulas spacon en TCAM-memoro. Mi donos ekzemplon de agordo por subpress-arp:
hardware access-list tcam region arp-ether 256Ĉi tiu aranĝo postulos duoble larĝan. Tio estas, se vi agordas 256, tiam 512 devas esti liberigita en TCAM.Agordo de TCAM estas ekster la amplekso de ĉi tiu artikolo, ĉar agordo de TCAM dependas nur de la tasko asignita al vi kaj povas diferenci de unu reto al alia.
- La efektivigo de subpremo-arp devas esti farita sur ĉiuj Leaf-ŝaltiloj. Tamen, komplekseco povas ekesti dum agordado sur Foliaj paroj situantaj en VPC-domajno. Ŝanĝante TCAM, la konsistenco inter la paroj estos rompita kaj unu nodo povas esti forigita. Aldone, rekomenco de aparato povas esti necesa por apliki la TCAM-ŝanĝan agordon.
Kiel rezulto, vi zorge pripensu ĉu indas efektivigi ĉi tiun agordon en funkcianta fabriko en via situacio.
Ĉi tio finas la unuan parton de la ciklo. En la sekva parto, ni konsideros vojigon tra VxLAN-fabriko kun reto-disigo tra malsamaj VRF-oj.
Kaj nun mi invitas ĉiujn , en kiu mi detale parolos pri la kurso. La unuaj 20 partoprenantoj, kiuj registriĝas por ĉi tiu retseminario, ricevos Rabat-Atestilon retpoŝte ene de 1-2 tagoj post la elsendo.
fonto: www.habr.com