Sveiki, habr. Pašlaik esmu kursa "Tīkla inženieris" vadītājs OTUS.
Pirms jaunā kursa uzsākšanas , es esmu sagatavojis rakstu ciklu par VxLAN EVPN tehnoloģiju.
Ir pieejami milzīgi materiāli par VxLAN EVPN darbību, tādēļ vēlos apkopot dažādas uzdevumu un to risinājumu prakses mūsdienu datu centros.
Pirmajā cikla daļā par VxLAN EVPN tehnoloģiju vēlos apsvērt, kā organizēt L2 savienojamību starp hostiem virs tīkla fabrikas.
Visus piemērus veiksim uz Cisco Nexus 9000v, kas būs savākti Spine-Leaf topoloģijā. Šajā rakstā neapspriedīsim Underlay tīkla konfigurāciju.
- Underlay tīkls
- BGP piesaiste address-family l2vpn evpn
- NVE konfigurācija
- Supress-arp
Underlay tīkls
Izmantotā topoloģija izskatās šādi:
Norādīsim adresāciju visiem ierīcēm:
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.20Pārbaudīsim, vai starp visām ierīcēm pastāv IP savienojamība:
Leaf21# sh ip route
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 ir pieejams caur diviem Spine
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intran
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intran
10.255.1.12/32, ubest/mbest: 2/0 ! Leaf-12 ir pieejams caur diviem Spine
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intran
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intran
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, intran
10.255.1.102/32, ubest/mbest: 1/0
*via 10.255.1.102, Eth1/3, [110/41], 00:00:03, ospf-UNDERLAY, intranPārbaudīsim, vai VPC domēns ir izveidots un vai abi slēdži ir izturējuši konsekvences pārbaudi un iestatījumi abās mezglos ir identiski:
Leaf11# show vpc
vPC domēna id : 1
Partnera statuss : partnera adjacence izveidota ok
vPC saglabāšanas statuss : partneris ir dzīvs
Konfigurācijas konsekvences statuss : panākts
Per-vlan konsekvences statuss : panākts
Type-2 konsekvences statuss : panākts
vPC loma : primārais
Konfigurēto vPC skaits : 0
Partnera vārti : Izslēgts
Divu aktīvo izslēgto VLANs : -
Lēni konsekvences pārbaude : Iespējots
Automātiskās atjaunošanas statuss : Izslēgts
Lēna atjaunošanas statuss : Taimeris ir izslēgts (laiks = 30s)
Lēna atjaunošanas SVI statuss : Taimeris ir izslēgts (laiks = 10s)
Darba Layer3 partneru maršrutētājs : Izslēgts
vPC statuss
----------------------------------------------------------------------------
Id Ports Statuss Konsekvences iemesls Aktīvie VLANs
-- ------------ ------ ----------- ------ ---------------
5 Po5 augšā panākts panākts 1BGP piesaiste
Visfinally varam pāriet pie Overlay tīkla konfigurācijas.
Raksta ietvaros ir jāorganizē tīkls starp hostiem, kā parādīts zemākajā shēmā:
Lai konfigurētu Overlay tīklu, ir nepieciešams aktivizēt BGP Spine un Leaf slēdžos ar atbalstu l2vpn evpn ģimenei:
feature bgp
nv overlay evpnTālāk ir jāuzstāda BGP peering starp Leaf un Spine. Lai vienkāršotu konfigurāciju un optimizētu maršrutu informācijas izplatīšanu, Spine konfigurējam kā Route-Reflector serveri. Visas Leaf ierakstīsim konfigurācijā caur veidnēm, lai optimizētu iestatījumus.
Tādējādi iestatījumi uz Spine izskatās šādi:
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 LEAFIestatījumi uz Leaf slēdža izskatās līdzīgi:
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 SPINEUz Spine pārbaudīsim peeringu ar visiem Leaf slēdžiem:
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 0Kā redzam, ar BGP nav radušās nekādas problēmas. Pāriesim pie VxLAN konfigurācijas. Tālākā konfigurācija tiks veikta tikai Leaf slēdzēju pusē. Spine darbojas tikai kā tīkla kodols un nodarbojas tikai ar datu pārvadi. Visa marķēšanas un ceļa noteikšana notiek tikai Leaf slēdžos.
NVE konfigurācija
NVE — tīkla virtuālais interfeiss
Pirms uzsākt konfigurāciju, iepazīsimies ar dažiem terminiem:
VTEP — virtuālais tuneļa beigu punkts, ierīce, kurā sākas vai beidzas VxLAN tuneļa. VTEP nav obligāti kāda tīkla ierīce. Tas var būt arī serveris ar atbalstu VxLAN tehnoloģijai. Mūsu topoloģijā visi Leaf slēdži ir VTEP.
VNI — virtuālās tīkla indekss — tīkla identifikators VxLAN ietvaros. To var salīdzināt ar VLAN. Tomēr ir dažas atšķirības. Izmantojot ražotni, VLAN ir unikāli tikai viena Leaf slēdža ietvaros un netiek pārsūtīti pa tīklu. Taču katram VLAN var tikt piesaistīts VNI numurs, kas tiek pārsūtīts pa tīklu. Kā tas izskatās un kā to var izmantot, tiks aplūkots turpmāk.
Ieslēgsim funkciju VxLAN tehnoloģijas darbībai un iespēju piesaistīt VLAN numurus ar VNI numuru:
feature nv overlay
feature vn-segment-vlan-basedIestatīsim NVE interfeisu, kas atbild par VxLAN darbību. Šis interfeiss tieši nodrošina kadru iepakošanu VxLAN virsrakstos. Var veikt analoģiju ar Tunnel interfeisu GRE darbībai:
interface nve1
no shutdown
host-reachability protocol bgp ! izmantojam BGP maršrutu informācijas pārsūtīšanai
source-interface loopback0 ! interfeiss, no kura sūtām paketes loopback0Leaf-21 slēdžā viss tiek izveidots bez problēmām. Tomēr, ja pārbaudām komandas izpildes rezultātu show nve peers, tas izrādīsies tukšs. Šeit ir jāatgriežas pie VPC konfigurācijas. Mēs redzam, ka Leaf-11 un Leaf-12 strādā pārinā un ir apvienoti VPC domēnā. No šejienes izriet sekojoša situācija:
Host-2 sūta vienu kadru uz Leaf-21, lai tas pārsūta to pa tīklu uz Host-1. Tomēr Leaf-21 redz, ka Host-1 MAC adrese ir pieejama caur diviem VTEP. Kā šajā gadījumā rīkoties Leaf-21? Tas nozīmē, ka tīklā varētu būt veidojusies cilpa.
Lai atrisinātu šo situāciju, mums nepieciešams, lai Leaf-11 un Leaf-12 rūpnīcā izskatītos kā viens ierīce. To var diezgan viegli atrisināt. Uz Loopback interfeisa, no kura būvējam tuneli, pievienojam sekundāro adresi. Sekundārā adrese jābūt vienādai abiem VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryTādējādi citu VTEP acīs mēs iegūstam sekojošu topoloģiju:
Tātad tagad tunelis tiks būvēts starp Leaf-21 IP adresi un virtuālo IP starp diviem Leaf-11 un Leaf-12. Tagad problēmas ar MAC adreses izpēti no divām ierīcēm vairs nebūs, un satiksme varēs pāriet no viena VTEP uz otru. Kurš no diviem VTEP apstrādās satiksmi, tiek izlemts, izmantojot maršrutēšanas tabulu uz 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, intraKā redzams iepriekš, adrese 10.255.1.10 ir pieejama caur diviem Next-hop.
Šajā posmā esam izpratuši pamata savienojamību. Pārslēgsimies pie NVE interfeisa konfigurācijas:
Uzreiz ieslēgsim Vlan 10 un sasaistīsim to ar VNI 10000 katrā Leaf, kur ir hosti. Iestatīsim L2 tuneli starp hostiem.
vlan 10 ! Iespējam VLAN visiem VTEP, kas pieslēgti nepieciešamajiem hostiem
vn-segment 10000 ! Saistām VLAN ar VNI numuru
interface nve1
member vni 10000 ! Pievienojam VNI 10000, lai tas darbotos caur NVE interfeisu, lai inkapsulētu VxLAN
ingress-replication protocol bgp ! norādām, ka informācijas izplatīšanai par hostu izmantojam BGPTagad pārbaudīsim nve peers un tabulu 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 ! Redzam, ka peers ir pieejams no sekundārā adrešu
Leaf11# sh bgp l2vpn evpn
Tīkls Nākamā saite Metriķis LocPrf Svars Ceļš
Maršruta atšķirētājs: 10.255.1.11:32777 (L2VNI 10000) ! No kā tieši nāk šis l2VNI
*>l[3]:[0]:[32]:[10.255.1.10] / 88 ! EVPN maršruta tips 3 - parāda mūsu kaimiņu, kurš arī zina par 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
Maršruta atšķirētājs: 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 iAugstākā redzam maršrutus tikai EVPN maršruta tips 3. Šis maršrutu tips stāsta par peers (Leaf), tomēr kur ir mūsu hosti?
Un viss ir tajā, ka informācija par MAC hostiem tiek nodota caur EVPN maršruta tipu 2.
Lai redzētu mūsu hostus, ir nepieciešams konfigurēt EVPN maršruta tipu 2:
evpn
vni 10000 l2
route-target import auto ! šī raksta ietvaros izmantojam automātisko numuru maršruta mērķim
route-target export autoVeiksim ping no Host-2 uz Host-1:
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 dati baitos
36 baitus no 192.168.10.2: Mērķa hosti nav pieejami
Pieprasījums 0 izbeigts
64 baitus no 192.168.10.1: icmp_seq=1 ttl=254 laiks=215.555 ms
64 baitus no 192.168.10.1: icmp_seq=2 ttl=254 laiks=38.756 ms
64 baitus no 192.168.10.1: icmp_seq=3 ttl=254 laiks=42.484 ms
64 baitus no 192.168.10.1: icmp_seq=4 ttl=254 laiks=40.983 msUn zemāk mēs varam redzēt, ka BGP tabulā parādījušies maršruti ar tipu 2 ar MAC adresēm hostiem — 5001.0007.0007 un 5001.0008.0007
Leaf11# sh bgp l2vpn evpn
Tīkla adrese Nākamais lēciens Metri LocPrf Svars Ceļš
Maršruta diferenciators: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216 ! evpn maršruta tips 2 un hosta 1 MAC adrese
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]\/216 ! evpn maršruta tips 2 un hosta 2 MAC adrese
* i 10.255.1.20 100 0 i
*>l[3]:[0]:[32]:[10.255.1.10]\/88
10.255.1.10 100 32768 i
Maršruta diferenciators: 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 iTālāk varam apskatīt sīkāku informāciju par atjauninājumu, kurā saņēmām informāciju par MAC hostu. Zemāk ir norādīts nevis viss komandas izsniegums
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
BGP maršrutu tabulas informācija VRF noklusējums, adreses ģimene L2VPN EVPN
Maršruta diferenciators: 10.255.1.11:32777 ! nosūtīts atjauninājums ar MAC hostu. Nevis VPC virtuālā adrese, bet Leaf adrese
BGP maršrutu tabulas ieraksts [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216,
versija 1507
Ceļi: (2 pieejami, labākais #2)
Karogiem: (0x000202) (high32 00000000) uz xmit-list, nav l2rib\/evpn, nav HW
Ceļa tips: iekšējs, ceļš ir derīgs, nav labākais iemesls: Kaimiņa adrese, nav marķēta nākamā lēciens
AS-Ceļš: NAV, ceļš iegūts iekš AS
10.255.1.10 (metri 81) no 10.255.1.102 (10.255.1.102) ! ar kuru tieši veidojam VxLAN tuneli
Izcelsme IGP, MED nav iestatīts, lokālpriekšroka 100, svars 0
Saņemtā etiķete 10000 ! VNI numurs, kas asociēts ar VLAN, kurā atrodas Host
Ekstra kopiena: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Šeit redzams, ka RT izveidojās automātiski, pamatojoties uz AS numuriem un VNI
Izcelsmes dalībnieks: 10.255.1.11 Klastera saraksts: 10.255.1.102Apskatīsim, kā izskatās kadri, kad tie tiek pārsūtīti caur fabriku:
Suppress-ARP
Lieliski, L2 savienojums starp hostiem ir izveidots, un uz šo varētu beigt. Tomēr viss nav tik vienkārši. Kamēr mums ir maz hostu, problēmas neradīsies. Bet apskatīsim situācijas, kad hostu ir simti un tūkstoši. Ar kādām problēmām mēs varam saskarties?
Šī problēma ir BUM (Broadcast, Unknown Unicast, Multicast) datplūsma. Šajā rakstā apskatīsim variantu, kā cīnīties ar broadcast datplūsmu.
Galvenais broadcast ģenerators Ethernet tīklos ir paši hosti, izmantojot ARP protokolu.
Uz Nexus ir ieviests šāds mehānisms cīņai ar ARP pieprasījumiem — suppress-arp.
Šīs funkcijas darbs izskatās šādi:
- Host-1 nosūta ARP pieprasījumu uz broadcast adresi savā tīklā.
- Pieprasījums nonāk Leaf slēdzī un, nevis nosūtot šo pieprasījumu tālāk uz fabriku uz Host-2 — Leaf atbild pats un norāda vajadzīgo IP un MAC.
Tādējādi Broadcast pieprasījums netika nosūtīts uz audumu. Bet kā tas var darboties, ja Leaf zina tikai MAC adresi?
Viss ir diezgan vienkārši, EVPN route-type 2 papildus MAC adresei var nodot saistību MAC/IP. Tādēļ uz Leaf ir nepieciešams iestatīt IP adresi VLAN. Rodas jautājums, kādu IP iestatīt? Nexus ir iespēja izveidot sadalītu (vienādu) adresi visiem slēdžiem:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! iestatām virtuālo MAC, lai izveidotu sadalītu vārteju starp visiem slēdžiem
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! visiem Leaf iestata vienādu IP
fabric forwarding mode anycast-gateway ! sakām izmantot virtuālo MACTādējādi no viesdatoru viedokļa tīkls izskatīsies šādi:
Pārbaudīsim BGP l2route evpn
Leaf11# sh bgp l2vpn evpn
Tīkls Nākamā adrese Metriķis LocPrf Svars Ceļš
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 iNo komandas izvadīšanas redzams, ka EVPN route-type 2 papildus MAC tagad redzam arī viesdatora IP adresi.
Atgriežamies pie suppress-arp konfigurācijas. Šī iestatījuma noteikšana tiek veikta katram VNI atsevišķi:
interface nve1
member vni 10000
suppress-arpTālāk rodas noteiktas grūtības:
- Šīs funkcijas darbībai ir nepieciešama vieta TCAM atmiņā. Sniedzu piemēru konfigurācijai suppress-arp:
hardware access-list tcam region arp-ether 256Šai konfigurācijai būs nepieciešama dubultplatuma. Tas nozīmē, ja iestatāt 256, tad TCAM jāatbrīvo 512. TCAM konfigurēšana pārsniedz šī raksta robežas, jo TCAM iestatījumi ir atkarīgi tikai no uzdevuma, kas jums ir izvirzīts, un var atšķirties no vienas tīkla uz otru.
- Vnese supress-arp ir jāīsteno visos Leaf slēdžos. Taču var rasties grūtības, konfigurējot pāros Leaf, kas atrodas VPC domēnā. Mainot TCAM, saderība starp pāriem tiks izjaukta, un viens mezgls var iziet no darbstāvokļa. Papildus, lai piemērotu konfigurāciju TCAM izmaiņām, iekārtai var būt nepieciešama restartēšana.
Līdz ar to jāizvērtē, vai jūsu gadījumā ir prātīgi ieviest šo iestatījumu strādājošā fabrikā.
Šeit noslēdzam pirmo cikla daļu. Nākamajā daļā apskatīsim maršrutēšanu caur VxLAN fabriku ar tīklu sadalījumu dažādās VRF.
Un tagad aicinu visus uz , kurā es detalizēti pastāstīšu par kursu. Pirmie 20 dalībnieki, kas reģistrējas šim vebināram, saņems sertifikātu ar atlaidi pa e-pastu 1-2 dienu laikā pēc pārraides.
Avots: habr.com
