Automatizācija paŔiem mazākajiem. Otrā daļa. Tīkla dizains

Pirmajos divos rakstos es izvirzÄ«ju jautājumu par automatizāciju un ieskicēju tās ietvaru, otrajā es pievērsos tÄ«kla virtualizācijai, kas ir pirmā pieeja pakalpojumu konfigurācijas automatizÄ“Å”anai.
Tagad ir pienācis laiks uzzīmēt fiziskā tīkla diagrammu.

Ja neesat pazīstams ar datu centru tīklu iestatīŔanu, es ļoti iesaku sākt ar raksti par tiem.

Visas problēmas:

Å ajā sērijā aprakstÄ«tajai praksei ir jāattiecas uz jebkura veida tÄ«kliem, jebkura izmēra un dažādiem pārdevējiem (nevis). Tomēr nav iespējams aprakstÄ«t universālu piemēru Å”o pieeju pielietoÅ”anai. Tāpēc es koncentrÄ“Å”os uz lÄ«dzstrāvas tÄ«kla moderno arhitektÅ«ru: Kloza rÅ«pnÄ«ca.
Mēs veiksim DCI uz MPLS L3VPN.

Pārklājuma tÄ«kls darbojas virs resursdatora fiziskā tÄ«kla (tas varētu bÅ«t OpenStack VXLAN vai Tungsten Fabric vai jebkas cits, kam nepiecieÅ”ams tikai pamata IP savienojums no tÄ«kla).

Automatizācija paŔiem mazākajiem. Otrā daļa. Tīkla dizains

Å ajā gadÄ«jumā mēs iegÅ«stam salÄ«dzinoÅ”i vienkārÅ”u automatizācijas scenāriju, jo mums ir daudz aprÄ«kojuma, kas ir konfigurēts vienādi.

Mēs izvēlēsimies sfērisku līdzstrāvu vakuumā:

  • Visur viena dizaina versija.
  • Divi pārdevēji, kas veido divas tÄ«kla plaknes.
  • Viens DC ir kā otrs kā divi zirņi pākstÄ«.

saturs

  • Fiziskā topoloÄ£ija
  • MarÅ”rutÄ“Å”ana
  • IP plāns
  • Laba
  • Secinājums
  • NoderÄ«gas saites

Ä»aujiet mÅ«su pakalpojumu sniedzējam LAN_DC, piemēram, uzņemt mācÄ«bu video par izdzÄ«voÅ”anu iestrēguÅ”os liftos.

Megapilsētās tas ir ļoti populārs, tāpēc jums ir nepiecieÅ”ams daudz fizisko iekārtu.

Vispirms es aprakstÄ«Å”u tÄ«klu aptuveni tādu, kādu es to vēlētos. Un tad es to vienkārÅ”oÅ”u laboratorijai.

Fiziskā topoloģija

AtraŔanās vietas

LAN_DC būs 6 DC:

  • Krievija (RU):
    • Maskava (MSK)
    • Kazaņa (kzn)

  • Spānija (SP):
    • Barselona (bcn)
    • Malaga (MLG)

  • Ķīna (CN):
    • Å anhaja (sha)
    • Siaņa (abi)

Automatizācija paŔiem mazākajiem. Otrā daļa. Tīkla dizains

Inside DC (Intra-DC)

Visiem DC ir identiski iekŔējie savienojamÄ«bas tÄ«kli, kuru pamatā ir Clos topoloÄ£ija.
Kas tie ir par Clos tÄ«kliem un kāpēc tie ir atseviŔķi raksts.

Katrā DC ir 10 plaukti ar maŔīnām, tie tiks numurēti kā A, B, C Un tā tālāk.

Katrā plauktā ir 30 maŔīnas. Viņi mÅ«s neinteresēs.

ArÄ« katrā plauktā ir slēdzis, kuram ir pievienotas visas maŔīnas - tas ir Slēdža augÅ”daļa ā€” ToR vai kā citādi, runājot par Clos rÅ«pnÄ«cu, mēs to sauksim Lapa.

Automatizācija paŔiem mazākajiem. Otrā daļa. Tīkla dizains
Rūpnīcas vispārējā shēma.

Mēs viņiem piezvanīsim XXX- lapaYKur XXX - trīs burtu saīsinājums DC un Y - sērijas numurs. Piemēram, kzn-lapa11.

Savos rakstos es atļauÅ”os lietot terminus Leaf un ToR diezgan vieglprātÄ«gi kā sinonÄ«mus. Tomēr mums jāatceras, ka tas tā nav.
ToR ir plauktā uzstādÄ«ts slēdzis, kuram ir pievienotas maŔīnas.
Leaf ir ierīces loma fiziskajā tīklā vai pirmā līmeņa slēdzis Cloes topoloģijas ziņā.
Tas ir, Lapa != ToR.
Tātad Leaf var būt, piemēram, EndofRaw slēdzis.
Tomēr Ŕī raksta ietvaros mēs tos joprojām traktēsim kā sinonÄ«mus.

Katrs ToR slēdzis savukārt ir savienots ar četriem augstāka lÄ«meņa apkopoÅ”anas slēdžiem - Mugurkauls. Viens statÄ«vs DC ir atvēlēts Spines. Mēs to nosauksim lÄ«dzÄ«gi: XXX- mugurkaulsY.

Tajā paŔā plauktā bÅ«s tÄ«kla aprÄ«kojums savienojumam starp DC-2 marÅ”rutētājiem ar MPLS. Bet kopumā tie ir tie paÅ”i ToR. Tas ir, no Spine slēdžu viedokļa parastajam ToR ar pievienotajām maŔīnām vai marÅ”rutētāju DCI nav nozÄ«mes - tikai pārsÅ«tÄ«Å”ana.

Tādus Ä«paÅ”os ToR sauc Mala-lapa. Mēs viņiem piezvanÄ«sim XXX-maluY.

Tas izskatīsies Ŕādi.

Automatizācija paŔiem mazākajiem. Otrā daļa. Tīkla dizains

IepriekÅ” redzamajā diagrammā es faktiski novietoju malu un lapu vienā lÄ«menÄ«. Klasiskie trÄ«sslāņu tÄ«kli Viņi mācÄ«ja uzskatÄ«t augÅ”upsaiti (tātad Å”is termins) kā augÅ”upsaites. Un Å”eit izrādās, ka DCI ā€œaugÅ”upsaiteā€ atkal nolaižas, kas dažiem nedaudz pārkāpj ierasto loÄ£iku. Lielu tÄ«klu gadÄ«jumā, kad datu centri tiek sadalÄ«ti vēl mazākās vienÄ«bās - POD's (Piegādes punkts), iezÄ«mējiet atseviŔķu Edge-POD's DCI un piekļuvei ārējiem tÄ«kliem.

Lai atvieglotu uztveri nākotnē, es joprojām zÄ«mÄ“Å”u Edge over Spine, vienlaikus paturot prātā, ka uz Spine nav inteliÄ£ences un nav atŔķirÄ«bu, strādājot ar parasto Leaf un Edge-leaf (lai gan Å”eit var bÅ«t nianses , bet kopumā Tā ir taisnÄ«ba).

Automatizācija paŔiem mazākajiem. Otrā daļa. Tīkla dizains
Rūpnīcas shēma ar malām.

Lapu, mugurkaula un malas trīsvienība veido apakŔklājuma tīklu vai rūpnīcu.

TÄ«kla rÅ«pnÄ«cas uzdevums (lasiet Underlay), kā mēs jau esam definējuÅ”i pēdējais numurs, ļoti, ļoti vienkārÅ”i - nodroÅ”ināt IP savienojumu starp maŔīnām gan vienā lÄ«dzstrāvas ietvaros, gan starp tām.
Tāpēc tīkls tiek saukts par rūpnīcu, tāpat kā, piemēram, komutācijas rūpnīca modulāro tīkla kastēs, par ko vairāk varat lasīt SDSM14.

Kopumā Ŕādu topoloÄ£iju sauc par rÅ«pnÄ«cu, jo audums tulkojumā nozÄ«mē audums. Un ir grÅ«ti nepiekrist:
Automatizācija paŔiem mazākajiem. Otrā daļa. Tīkla dizains

RÅ«pnÄ«ca ir pilnÄ«bā L3. Nav VLAN, nav apraides ā€” mums LAN_DC ir tik brÄ«niŔķīgi programmētāji, viņi zina, kā rakstÄ«t lietojumprogrammas, kas dzÄ«vo L3 paradigmā, un virtuālajām maŔīnām nav nepiecieÅ”ama tieÅ”raides migrācija ar IP adreses saglabāŔanu.

Un vēlreiz: atbilde uz jautājumu, kāpēc rÅ«pnÄ«ca un kāpēc L3 ir atseviŔķā raksts.

DCI ā€” datu centra starpsavienojums (Inter-DC)

DCI tiks organizēta, izmantojot Edge-Leaf, tas ir, tie ir mÅ«su izejas punkts uz Å”oseju.
VienkārŔības labad mēs pieņemam, ka DC ir savienoti viens ar otru ar tieŔām saitēm.
Izslēgsim ārējo savienojumu no apsvērumiem.

Es apzinos, ka katru reizi, kad es noņemu komponentu, es ievērojami vienkārÅ”oju tÄ«klu. Un kad mēs automatizēsim savu abstrakto tÄ«klu, viss bÅ«s kārtÄ«bā, bet uz Ä«stā bÅ«s kruÄ·i.
Tā ir patiesÄ«ba. Tomēr Ŕīs sērijas jēga ir domāt un strādāt pie pieejām, nevis varonÄ«gi risināt iedomātas problēmas.

Edge-Leafs apakŔklājs tiek ievietots VPN un tiek pārraidīts caur MPLS mugurkaulu (tā pati tieŔā saite).

Šī ir augstākā līmeņa diagramma, ko mēs iegūstam.

Automatizācija paŔiem mazākajiem. Otrā daļa. Tīkla dizains

MarŔrutēŔana

MarÅ”rutÄ“Å”anai lÄ«dzstrāvas ietvaros mēs izmantosim BGP.
Uz MPLS maģistrāles OSPF+LDP.
DCI, tas ir, savienojamÄ«bas organizÄ“Å”ana pazemē - BGP L3VPN, izmantojot MPLS.

Automatizācija paŔiem mazākajiem. Otrā daļa. Tīkla dizains
Vispārējā marÅ”rutÄ“Å”anas shēma

RÅ«pnÄ«cā nav OSPF vai ISIS (Krievijas Federācijā aizliegts marÅ”rutÄ“Å”anas protokols).

Tas nozÄ«mē, ka nebÅ«s automātiskas atklāŔanas vai Ä«sāko ceļu aprēķinu ā€” tikai manuāli (faktiski automātiski ā€” mēs Å”eit runājam par automatizāciju), iestatot protokolu, apkārtni un politikas.

Automatizācija paŔiem mazākajiem. Otrā daļa. Tīkla dizains
BGP marÅ”rutÄ“Å”anas shēma lÄ«dzstrāvas ietvaros

Kāpēc BGP?

Par Å”o tēmu ir viss RFC nosaukts Facebook un Arista vārdā, kas stāsta, kā bÅ«vēt ļoti liels datu centru tÄ«kli, izmantojot BGP. Tas skan gandrÄ«z kā daiļliteratÅ«ra, es ļoti iesaku to nogurdinoÅ”am vakaram.

Un manā rakstā ir arī vesela sadaļa tam veltīta. Kur es tevi vedu un Es sūtu.

Bet tomēr, Ä«si sakot, neviens IGP nav piemērots lielu datu centru tÄ«kliem, kur tÄ«kla ierīču skaits sniedzas tÅ«kstoÅ”os.

Turklāt BGP izmantoÅ”ana visur ļaus jums netērēt laiku vairāku dažādu protokolu atbalstam un sinhronizācijai starp tiem.

Roku uz sirds, mūsu rūpnīcā, kas ar lielu varbūtības pakāpi strauji neaugs, acīm pietiktu ar OSPF. Tās patiesībā ir megaskaleru un mākoņu titānu problēmas. Bet iedomāsimies, ka mums tas ir vajadzīgs tikai dažiem laidieniem, un mēs izmantosim BGP, kā to novēlēja Pjotrs Lapuhovs.

MarŔrutēŔanas politikas

Leaf slēdžos mēs importējam prefiksus no Underlay tīkla saskarnēm BGP.
Starp mums bÅ«s BGP sesija katrs lapu un mugurkaula pāris, kurā Å”ie apakÅ”klājuma prefiksi tiks paziņoti tÄ«klā Å”ur tur.

Automatizācija paŔiem mazākajiem. Otrā daļa. Tīkla dizains

Viena datu centra ietvaros mēs izplatÄ«sim specifikācijas, kuras importējām ToRe. Edge-Leafs mēs tos apkoposim un paziņosim attālajiem DC un nosÅ«tÄ«sim uz TOR. Tas nozÄ«mē, ka katrs ToR precÄ«zi zinās, kā nokļūt citā ToR tajā paŔā DC un kur ir ieejas punkts, lai nokļūtu citā DC.

DCI marŔruti tiks pārsūtīti kā VPNv4. Lai to izdarītu, Edge-Leaf saskarne ar rūpnīcu tiks ievietota VRF, sauksim to UNDERLAY, un apkārtne ar Spine on Edge-Leaf palielināsies VRF un starp Edge-Leaf VPNv4-. ģimene.

Automatizācija paŔiem mazākajiem. Otrā daļa. Tīkla dizains

Tāpat aizliegsim atkārtoti izziņot marÅ”rutus, kas saņemti no muguriņiem atpakaļ uz tiem.

Automatizācija paŔiem mazākajiem. Otrā daļa. Tīkla dizains

Lapā un Spine mēs neimportēsim cilpas. Mums tie ir nepiecieÅ”ami tikai marÅ”rutētāja ID noteikÅ”anai.

Bet Edge-Leafs mēs to importējam globālajā BGP. Starp Loopback adresēm Edge-Leafs savā starpā izveido BGP sesiju IPv4 VPN saimē.

Mums bÅ«s OSPF+LDP mugurkauls starp EDGE ierÄ«cēm. Viss ir vienā zonā. ĀrkārtÄ«gi vienkārÅ”a konfigurācija.

Å is ir attēls ar marÅ”rutÄ“Å”anu.

BGP ASN

Edge-Leaf ASN

Edge-Leafs visos DC būs viens ASN. Ir svarīgi, lai starp Edge-Leafs būtu iBGP, un mēs neaizķeramies eBGP niansēs. Lai tas būtu 65535. Reāli tas varētu būt publiskas AS numurs.

Mugurkaula ASN

Uz Spine mums būs viens ASN katram DC. Sāksim Ŕeit ar paŔu pirmo numuru no privātā AS diapazona - 64512, 64513 Un tā tālāk.

Kāpēc ASN uz DC?

Sadalīsim Ŕo jautājumu divās daļās:

  • Kāpēc ASN ir vienādi uz visiem viena lÄ«dzstrāvas muguriņiem?
  • Kāpēc tie atŔķiras dažādos DC?

Kāpēc uz visiem viena līdzstrāvas muguriņiem ir vienādi ASN?

Šādi izskatīsies apakŔklājuma marŔruta AS-ceļŔ uz Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Mēģinot to reklamēt atpakaļ pakalpojumā Spine, tas tiks atmests, jo tā AS (Spine_AS) jau ir sarakstā.

Tomēr DC ietvaros mēs esam pilnÄ«bā apmierināti, ka Underlay marÅ”ruti, kas paceļas uz Edge, nevarēs nolaisties. Visai saziņai starp saimniekiem lÄ«dzstrāvas ietvaros jānotiek mugurkaula lÄ«menÄ«.

Automatizācija paŔiem mazākajiem. Otrā daļa. Tīkla dizains

Å ajā gadÄ«jumā citu DC apkopotie marÅ”ruti jebkurā gadÄ«jumā viegli sasniegs ToR - viņu AS-Path bÅ«s tikai ASN 65535 - AS Edge-Leafs skaits, jo tieÅ”i tur tie tika izveidoti.

Kāpēc tie atŔķiras dažādos DC?

Teorētiski mums, iespējams, vajadzēs vilkt Loopback un dažas pakalpojumu virtuālās maŔīnas starp DC.

Piemēram, resursdatorā mēs darbosim Route Reflector vai tas pats VNGW (Virtual Network Gateway), kas tiks bloķēta ar TopR, izmantojot BGP, un paziņos par savu atgriezenisko cilpu, kurai vajadzētu būt pieejamai no visiem DC.

Tātad tā izskatīsies tā AS-Path:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Un nekur nevajadzētu būt ASN dublikātiem.

Automatizācija paŔiem mazākajiem. Otrā daļa. Tīkla dizains

Tas ir, Spine_DC1 un Spine_DC2 ir jābÅ«t atŔķirÄ«giem, tāpat kā leafX_DC1 un leafY_DC2, kas ir tieÅ”i tas, ko mēs tuvojam.

Kā jÅ«s droÅ”i vien zināt, pastāv uzlauzumi, kas ļauj pieņemt marÅ”rutus ar dublētiem ASN, neskatoties uz cilpas novērÅ”anas mehānismu (atļauja Cisco). Un tam pat ir likumÄ«gs lietojums. Taču tā ir potenciāla plaisa tÄ«kla stabilitātē. Un es personÄ«gi tajā iekritu pāris reizes.

Un, ja mums būs iespēja neizmantot bīstamas lietas, mēs to izmantosim.

Lapa ASN

Mums bÅ«s atseviŔķs ASN uz katra Leaf slēdža visā tÄ«klā.
Mēs to darām iepriekÅ” minēto iemeslu dēļ: AS-Path bez cilpām, BGP konfigurācija bez grāmatzÄ«mēm.

Lai marÅ”ruti starp Leafs noritētu vienmērÄ«gi, AS-Path vajadzētu izskatÄ«ties Ŕādi:
[leafX_ASN, spine_ASN, leafY_ASN]
kur leafX_ASN un leafY_ASN būtu jauki atŔķirties.

Tas ir nepiecieÅ”ams arÄ« situācijā, kad tiek paziņots par VNF atgriezenisko saiti starp DC:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Mēs izmantosim 4 baitu ASN un Ä£enerēsim to, pamatojoties uz Spine's ASN un Leaf slēdža numuru, proti, Ŕādi: Mugurkauls_ASN.0000X.

Šis ir attēls ar ASN.
Automatizācija paŔiem mazākajiem. Otrā daļa. Tīkla dizains

IP plāns

Būtībā mums ir jāpieŔķir adreses Ŕādiem savienojumiem:

  1. Novietojiet tÄ«kla adreses starp ToR un iekārtu. Tiem jābÅ«t unikāliem visā tÄ«klā, lai jebkura iekārta varētu sazināties ar jebkuru citu. Lieliski piemērots 10/8. Katram plauktam ir /26 ar rezervi. Mēs pieŔķirsim /19 uz DC un /17 katram reÄ£ionam.
  2. Saistiet adreses starp Leaf/Tor un Spine.

    Es vēlētos tos pieŔķirt algoritmiski, tas ir, aprēķināt tos no to ierīču nosaukumiem, kuras ir jāpievieno.

    Lai ir... 169.254.0.0/16.
    Proti 169.254.00X.Y/31Kur X - mugurkaula numurs, Y ā€” P2P tÄ«kls /31.
    Tas ļaus jums palaist līdz 128 statīviem un līdz 10 muguriņiem līdzstrāvas sistēmā. Saites adreses var (un tiks) atkārtotas no līdzstrāvas uz līdzstrāvu.

  3. Mēs organizējam krustojumu Spine-Edge-Leaf apakÅ”tÄ«klos 169.254.10X.Y/31, kur tieÅ”i tas pats X - mugurkaula numurs, Y ā€” P2P tÄ«kls /31.
  4. Saistiet adreses no Edge-Leaf uz MPLS mugurkaulu. Å eit situācija ir nedaudz atŔķirÄ«ga - vieta, kur visi gabali ir savienoti vienā pÄ«rāgā, tāpēc to paÅ”u adreÅ”u atkārtota izmantoÅ”ana nedarbosies - jums ir jāizvēlas nākamais bezmaksas apakÅ”tÄ«kls. Tāpēc ņemsim par pamatu 192.168.0.0/16 un mēs no tā izgrābsim brÄ«vos.
  5. Cilpas adreses. Mēs viņiem piedāvāsim visu klāstu 172.16.0.0/12.
    • Lapa - /25 uz DC - tie paÅ”i 128 statÄ«vi. Katram reÄ£ionam pieŔķirsim /23.
    • Mugurkauls - /28 uz DC - lÄ«dz 16 Mugurkauls. Novadam izdalÄ«sim /26.
    • Edge-Leaf - /29 uz DC - lÄ«dz 8 kastēm. Novadam izdalÄ«sim /27.

Ja mums nav pietiekami daudz pieŔķirto diapazonu DC (un tādu nebÅ«s ā€” mēs apgalvojam, ka esam hiperskalori), mēs vienkārÅ”i atlasām nākamo bloku.

Å is ir attēls ar IP adresÄ“Å”anu.

Automatizācija paŔiem mazākajiem. Otrā daļa. Tīkla dizains

Atpakaļcilpas:

Prefikss
Ierīces loma
Apgabals
DC

172.16.0.0/23
mala
 
 

172.16.0.0/27
ru
 

172.16.0.0/29
MSK

172.16.0.8/29
kzn

172.16.0.32/27
sp
 

172.16.0.32/29
bcn

172.16.0.40/29
MLG

172.16.0.64/27
cn
 

172.16.0.64/29
sha

172.16.0.72/29
abi

172.16.2.0/23
mugurkauls
 
 

172.16.2.0/26
ru
 

172.16.2.0/28
MSK

172.16.2.16/28
kzn

172.16.2.64/26
sp
 

172.16.2.64/28
bcn

172.16.2.80/28
MLG

172.16.2.128/26
cn
 

172.16.2.128/28
sha

172.16.2.144/28
abi

172.16.8.0/21
lapa
 
 

172.16.8.0/23
ru
 

172.16.8.0/25
MSK

172.16.8.128/25
kzn

172.16.10.0/23
sp
 

172.16.10.0/25
bcn

172.16.10.128/25
MLG

172.16.12.0/23
cn
 

172.16.12.0/25
sha

172.16.12.128/25
abi

ApakŔklājs:

Prefikss
Apgabals
DC

10.0.0.0/17
ru
 

10.0.0.0/19
MSK

10.0.32.0/19
kzn

10.0.128.0/17
sp
 

10.0.128.0/19
bcn

10.0.160.0/19
MLG

10.1.0.0/17
cn
 

10.1.0.0/19
sha

10.1.32.0/19
abi

Laba

Divi pārdevēji. Viens tīkls. ADSM.

Kadiķis + Arista. Ubuntu. Vecā labā Ieva.

Resursu apjoms mÅ«su virtuālajā serverÄ« Miranā joprojām ir ierobežots, tāpēc praksei izmantosim lÄ«dz ierobežojumam vienkārÅ”otu tÄ«klu.

Automatizācija paŔiem mazākajiem. Otrā daļa. Tīkla dizains

Divi datu centri: Kazaņa un Barselona.

  • Divi muguriņas katrs: KadiÄ·is un Arista.
  • Viens torus (lapa) katrā - Juniper un Arista, ar vienu savienotu saimniekdatoru (paņemsim vieglo Cisco IOL).
  • Katrs Edge-Leaf mezgls (pagaidām tikai Juniper).
  • Viens Cisco slēdzis, lai pārvaldÄ«tu tos visus.
  • Papildus tÄ«kla kastēm darbojas virtuālā vadÄ«bas iekārta. Darbojas Ubuntu.
    Tam ir piekļuve visām ierÄ«cēm, tas darbinās IPAM/DCIM sistēmas, daudz Python skriptu, Ansible un jebko citu, kas mums varētu bÅ«t nepiecieÅ”ams.

Pilna konfigurācija no visām tīkla ierīcēm, kuras mēģināsim reproducēt, izmantojot automatizāciju.

Secinājums

Vai tas arī ir pieņemts? Vai man zem katra raksta jāraksta īss secinājums?

Tāpēc mēs izvēlējāmies trÄ«s lÄ«meņu Kloz tÄ«kls lÄ«dzstrāvas iekÅ”ienē, jo mēs sagaidām lielu austrumu-rietumu trafiku un vēlamies ECMP.

TÄ«kls tika sadalÄ«ts fiziskajā (apakŔā) un virtuālajā (pārklājums). Tajā paŔā laikā pārklājums sākas no saimniekdatora, tādējādi vienkārÅ”ojot prasÄ«bas apakÅ”klājam.

Mēs izvēlējāmies BGP kā tÄ«kla tÄ«klu marÅ”rutÄ“Å”anas protokolu tā mērogojamÄ«bas un politikas elastÄ«bas dēļ.

Mums bÅ«s atseviŔķi mezgli DCI organizÄ“Å”anai - Edge-leaf.
Mugurkaulā būs OSPF+LDP.
DCI tiks ieviests, pamatojoties uz MPLS L3VPN.
P2P saitēm mēs aprēķināsim IP adreses algoritmiski, pamatojoties uz ierīču nosaukumiem.
Mēs pieŔķirsim cilpas pēc ierīču lomas un to atraÅ”anās vietas secÄ«gi.
ApakÅ”klājuma prefiksi ā€” tikai uz Leaf slēdžiem secÄ«gi, pamatojoties uz to atraÅ”anās vietu.

Pieņemsim, ka Å”obrÄ«d mums vēl nav uzstādÄ«ts aprÄ«kojums.
Tāpēc mÅ«su nākamie soļi bÅ«s to pievienoÅ”ana sistēmām (IPAM, inventārs), piekļuves organizÄ“Å”ana, konfigurācijas Ä£enerÄ“Å”ana un izvietoÅ”ana.

Nākamajā rakstā mēs aplūkosim Netbox - IP vietas uzskaites un pārvaldības sistēmu līdzstrāvas tīklā.

Paldies

  • Andrejs Glazkovs aka @glazgoo par korektÅ«ru un labojumiem
  • Aleksandrs Kļimenko aka @v00lk par korektÅ«ru un labojumiem
  • Artjoms Černobajs KDPV

Avots: www.habr.com

Pievieno komentāru