Në dy artikujt e parë ngrita çështjen e automatizimit dhe skicova një kornizë të saj, ndërsa në të dytin bëra një shkëputje në virtualizimin e rrjetit, si një qasje fillestare për automatizimin e konfigurimit të shërbimeve.
Tani është koha për të vizatuar skemën e rrjetit fizik.
Nëse nuk jeni të njohur me pajisjet e rrjeteve të datacenterëve, ju rekomandoj fuqishëm që të filloni nga .
TĂ« gjitha numrat:
Praktikat e përshkruara në këtë seri duhet të aplikohen në rrjetin e çdo lloji, çdo shkalle me çdo larmi furnizuesish (jo). Megjithatë, nuk mund të përshkruhet një shembull universall i aplikimit të këtyre qasjeve. Prandaj, do të përqendrohem në arkitekturën moderne të rrjetit të DC: .
DCI do ta realizojmë në MPLS L3VPN.
Përmbi rrjetin fizik punon një rrjet Overlay nga hosti (kjo mund të jetë VXLAN i OpenStack ose Tungsten Fabric ose çfarëdo tjetër që kërkon nga rrjeti vetëm lidhjen bazë IP).
Në këtë rast, do të kemi një skenar të thjeshtë për automatizimin, pasi kemi shumë pajisje që konfigurohen në të njëjtën mënyrë.
Ne do të zgjedhim një Qendër të Dhënash sfugurative në vakuum:
- Një version dizajni kudo.
- Dy furnizues që formojnë dy nivele të rrjetit.
- Një Qendër të Dhënash duket si tjetra si dy pika uji.
PĂ«rmbajtja
- Topologjia fizike
- Routimi
- Plani IP
- Laboratori
- PĂ«rfundimi
- Linqe të dobishme
Le të themi se ofruesi ynë i shërbimeve LAN_DC do të strehojë, për shembull, video trajnuese për mbijetesën në ashensorët e bllokuar.
Në metropolet këtë e shfrytëzojnë shumë, prandaj nevojiten shumë makineri fizike.
Së pari, do të përshkruaj rrjetin përkrah siç do të dëshiroja ta shihja. Pastaj do ta thjeshtoj për laboratorin.
Topologjia fizike
Lokacionet
LAN_DC do të ketë 6 Qendra të Dhënash:
- Rusia (RU):
- Moskë (msk)
- Kazan (kzn)
- Spanja (SP):
- Barcelona (bcn)
- Malaga (mlg)
- Kina (CN):
- Shanghaj (sha)
- Xi'an (sia)
Brenda DC (Intra-DC)
Në të gjitha Qendrat e Dhënash rrjete identike të lidhjes, të bazuara në topologjinë Closer.
ĂfarĂ« janĂ« rrjetet Closer dhe pse ato saktĂ«sisht - nĂ« njĂ« .
Në çdo Qendër të Dhënash ka 10 rafte me pajisje, ato do të numërohen si A, B, C Dhe kështu me radhë.
Në çdo raft ka 30 pajisje. Keto nuk do të na interesojnë.
Gjithashtu, në çdo raft ka një switch, të cilit i janë lidhur të gjitha makinat - kjo është Switch i Sipërm të Raftit - ToR ose ndryshe do ta quajmë në terminologjinë e fabrikës Clos Leaf.
Skema e përgjithshme e fabrikës.
Do t'i emërojmë XXX-leafY, ku XXX - shkurtim tre-shkronjor i DC, dhe Y - numri rresht. Për shembull, kzn-leaf11.
Në artikuj do të lejoj që të flas disi lirshëm me terminat Leaf dhe ToR si sinonime. Megjithatë, është e nevojshme të kujtojmë se kjo nuk është e vërtetë.
ToR është një switch i instaluar në raft, të cilit i lidhen makinat.
Leaf është roli i pajisjes në rrjetin fizik ose switch i nivelit të parë në terminologjinë e topologjisë Clos.
Pra, Leaf != ToR.
Pra, një EndofRaw switch mund të jetë Leaf, për shembull.
Megjithatë, në kuadër të këtij artikulli do t'i trajtojmë ato si sinonime.
Ădo ToR switch nĂ« anĂ«n e tij Ă«shtĂ« i lidhur me katĂ«r switch-e grumbulluese tĂ« larta - Spine. PĂ«r Spine Ă«shtĂ« ndarĂ« njĂ« raft nĂ« DC. Do ta emĂ«rojmĂ« nĂ« mĂ«nyrĂ« tĂ« ngjashme: XXX-spineY.
Në këtë raft do të jetë pajisja rrjetore për lidhshmërinë midis DC-ve - 2 routera me MPLS në bord. Por, në thelb, janë të njëjtat ToR. Kështu që, nga pikëpamja e switch-ave Spine, nuk ka asnjë rëndësi nëse është një ToR i zakonshëm me makina të lidhura ose një router për DCI - në fund të fundit, është gjithsesi një forward.
Të tillë ToR të veçantë quhen Edge-leaf. Ne do t'i emërtojmë XXX-edgeY.
Kjo do të duket kështu.
NĂ« diagramin e mĂ«sipĂ«rm, edge dhe leaf i kam vĂ«rtet vendosur nĂ« tĂ« njĂ«jtin nivel. na kanĂ« mĂ«suar tĂ« shohim uplink-un (nĂ« fakt kĂ«tu vjen edhe termi), si lidhje lart. Por kĂ«tu ka njĂ« 'uplink' DCI qĂ« shkon prapa poshtĂ«, e cila paksa thyhet logjikĂ«n e zakonshme. NĂ« rastet e rrjeteve tĂ« mĂ«dha, kur qendrat e tĂ« dhĂ«nave ndahen edhe nĂ« njĂ«si mĂ« tĂ« vogla - PODâĂ«t (Pika e DorĂ«zimit), krijohen Edge-POD âĂ«t pĂ«r DCI dhe dalje nĂ« rrjete tĂ« jashtme.PĂ«r lehtĂ«si perceptimi nĂ« vazhdim, unĂ« do tĂ« vazhdoj tĂ« vizatoj Edge mbi Spine, megjithatĂ« do tĂ« mbajmĂ« mend se nuk ka asnjĂ« inteligjencĂ« nĂ« Spine dhe dallime nĂ« punĂ«n me Leaf tĂ« zakonshĂ«m dhe Edge-leaf (ndoshta ka nuanca, por nĂ« pĂ«rgjithĂ«si kĂ«tĂ« Ă«shtĂ«).
Diagrami i fabrikës me Edge-leaf.
ĐĄŃ
Đ”ĐŒĐ° ŃабŃĐžĐșĐž Ń Edge-leafâĐ°ĐŒĐž.
Trojca Leaf, Spine dhe Edge formojnë një rrjet Underlay ose fabrikë.
Detyra e fabrikĂ«s sĂ« rrjetit (lexoni Underlay), siç e vendosĂ«m mĂ« parĂ« nĂ« , Ă«shtĂ« shumĂ« e thjeshtĂ« â tĂ« sigurojĂ« lidhshmĂ«rinĂ« IP ndĂ«rmjet makinave si brenda njĂ« DC, ashtu edhe midis tyre.
Prandaj, rrjeti quhet fabrikë, siç është fabrikuar përshembull në kutitë rrjetësore modulare, për të cilat mund të lexoni më shumë në .
NĂ« tĂ« vĂ«rtetĂ«, njĂ« topologji e tillĂ« quhet fabrikĂ«, sepse fjalĂ«n fabric nĂ« pĂ«rkthim â do tĂ« thotĂ« pĂ«lhurĂ«. ĂshtĂ« e vĂ«shtirĂ« tĂ« mos jesh dakord:
Fabrika Ă«shtĂ« plotĂ«sisht L3. AsnjĂ« VLAN, asnjĂ« Broadcast â kemi kĂ«tu programues tĂ« mrekullueshĂ«m nĂ« LAN_DC, qĂ« dinĂ« tĂ« shkruajnĂ« aplikacione qĂ« jetojnĂ« nĂ« paradigmat L3, dhe makinat virtuale nuk kĂ«rkojnĂ« Migrim tĂ« DrejtĂ« me ruajtjen e adresĂ«s IP.
Dhe njĂ« herĂ«: pĂ«rgjigjja nĂ« pyetjen pse fabrike dhe pse L3 â Ă«shtĂ« nĂ« njĂ« diskutim tĂ« veçantĂ«. .
DCI â Data Center Interconnect (Inter-DC)
DCI do të organizohet me ndihmën e Edge-Leaf, domethënë ata janë pika jonë e daljes në magistral.
Për thjeshtësi, le të supozojmë se DC-të janë të lidhura me linjë direkte.
Të përjashtojmë nga shqyrtimi lidhshmërinë e jashtme.
E kuptoj se çdo herë që heq një komponent, unë e thjeshtoj ndjeshëm rrjetin. Dhe kur automatizojmë rrjetin tonë abstrakt, gjithçka do të shkojë mirë, por në atë real do të shfaqen ndihmës.
Kështu është. Megjithatë, detyra e kësaj serie është të mendojmë dhe të punojmë mbi qasjet, e jo të zgjidhim në mënyrë heroike probleme të sajuara.
Në Edge-Leaf, underlay vendoset në VPN dhe transmetohet përmes MPLS-magjistrales (ky link direkt).
Kjo është një skemë e nivelit të lartë.
Routimi
Për rrugëzimin brenda DC do të përdorim BGP.
NĂ« MPLS-magjistrale OSPF+LDP.
PĂ«r DCI, nĂ« kuptimin e organizimit tĂ« lidhjes nĂ« underlay â BGP L3VPN mbi MPLS.
Skema të plotë e rrugëzimit
Në fabrikë nuk ka OSPF dhe ISIS (protokol rrugëzimi i ndaluar në Federatën Ruse).
Dhe kjo do tĂ« thotĂ« se nuk do tĂ« ketĂ« Auto-discovery dhe llogaritje tĂ« rrugĂ«ve mĂ« tĂ« shkurtra â vetĂ«m konfigurim manual (nĂ« fakt automatizuar â ne po flasim pĂ«r automatizim) tĂ« protokollit, fqinjĂ«sisĂ« dhe politikave.
Skema e rrugëzimit BGP brenda DC
Pse BGP?
Për këtë temë ka në emër të Facebook dhe Arista, ku tregohet se si të ndërtohet shumë i madh rrjetet e qendrave të të dhënave, duke përdorur BGP. Lexohet pothuajse si një vepër artistike, e rekomandoj shumë për një mbrëmje të këndshme.
Dhe gjithashtu një seksion të tërë në artikullin tim i kushtohet kësaj. Në të cilin ju .
Por megjithatë, nëse flasim shkurt, asnjë IGP nuk është i përshtatshëm për rrjetet e mëdha të qendrave të të dhënave, ku numri i pajisjeve rrjetërore shkon në mijëra.
Për më tepër, përdorimi i BGP kudo do të lejojë të mos shpërndaheni në mbështetje të disa protokolleve të ndryshme dhe sinkronizimit midis tyre.
Duke e vendosur dorën në zemër, në fabrikën tonë, e cila me një probabilitet të madh nuk do të rritet me shpejtësi, mjaft do të ishte edhe OSPF. Ky është vërtet një problem i megascalerëve dhe titanëve të cloud-it. Por le të fantazojmë vetëm për disa edicione, që na nevojitet kjo, dhe le të përdorim BGP, ashtu siç e la pas Pjotr Lapukhov.
Politikat e routing-ut
Në switch-ët Leaf, ne importojmë në BGP prefikset nga ndërfaqet Underlay me rrjetet.
Ne do të kemi një seancë BGP midis çdo çifti Leaf-Spine, ku këto prefikse Underlay do të shpallen në rrjet.
Brenda një qendër të dhënash do të shpërndajmë specifikat që kemi importuar në ToR. Në Edge-Leaf do t'i agregojmë dhe do t'i shpallim në DC-të e largëta dhe do t'i zbresim deri në ToR. Kështu, çdo ToR do të dijë saktësisht si të arrijë në një tjetër ToR në këtë DC dhe ku është pika e hyrjes për të arritur në ToR-në në DC tjetër.
Në DCI rrugët do të transmetohen si VPNv4. Për këtë, në interfejsin Edge-Leaf në drejtim të fabrikës do të vendoset në VRF, ta quajmë UNDERLAY, dhe fqinjësia me Spine në Edge-Leaf do të ngrihet brenda VRF, ndërsa mes Edge-Leaf-ave do të jetë në familjen VPNv4.
Po ashtu, ne do të ndalojmë riannoncimin e rrugëve të marra nga spajnat, prapa tyre.
Në Leaf dhe Spine nuk do të importojmë Loopback. Ato na nevojiten vetëm për të përcaktuar ID-në e Router-it.
Por në Edge-Leaf do ta importojmë në BGP Global. Mes adresave Loopback, Edge-Leaf do të vendosin sesion BGP në IPv4 VPN-family me njëri-tjetrin.
Ndërmjet pajisjeve EDGE do të kemi një magjistrale të shtrirë mbi OSPF+LDP. Gjithçka në një zonë. Një konfigurim jashtëzakonisht i thjeshtë.
Kjo është pamja e rrugëtimit.
BGP ASN
Edge-Leaf ASN
NĂ« Edge-Leaf do tĂ« ketĂ« njĂ« ASN nĂ« tĂ« gjitha DC-tĂ«. ĂshtĂ« e rĂ«ndĂ«sishme qĂ« mes Edge-Leaf-ve tĂ« ketĂ« iBGP, dhe tĂ« mos bjerĂ« nĂ« nuanca eBGP. Le tĂ« jetĂ« ky 65535. NĂ« realitet, ky mund tĂ« ishte numri i AS publik.
Spine ASN
NĂ« Spine do tĂ« kemi njĂ« ASN pĂ«r DC. TĂ« fillojmĂ« kĂ«tu me numrin e parĂ« nĂ« diapazonin e AS-ve private â 64512, 64513 dhe kĂ«shtu me radhĂ«.
Pse ASN në DC?
Le të dekompozojmë këtë pyetje në dy:
- Pse ASN të njëjta në të gjithë spain-të e një DC?
- Pse të ndryshme në DC të ndryshme?
Pse ASN të njëjta në të gjithë spain-të e një DC
Kjo është si do të duket AS-Path i rrugës Underlay në Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Kur të përpiqet ta anonsi sërish në Spine, do ta refuzojë sepse AS-ja e tij (Spine_AS) është tashmë në listë.
Megjithatë, brenda DC na mjafton plotësisht që rrugët Underlay, që u ngritën deri në Edge, nuk do të mund të zbresin poshtë. Të gjitha komunikimet midis hosteve brenda DC duhet të ndodhin në nivelin e spine-ve.
NĂ« tĂ« njĂ«jtĂ«n kohĂ«, rrugĂ«t e agreguara tĂ« DC-ve tĂ« tjera, nĂ« çdo rast, do tĂ« arrijnĂ« pa pengesĂ« deri te ToR-et â nĂ« AS-Path-in e tyre do tĂ« ketĂ« vetĂ«m ASN 65535 â numrin e AS-eve tĂ« Edge-Leaf-ve, sepse pikĂ«risht atje janĂ« krijuar.
Pse të ndryshme në DC të ndryshme?
Teorikisht, mund të na nevojitet të lidhim Loopback të ndonjë makinash virtuale shërbimi mes DC-ve.
Për shembull, në hostin tonë do të nisë Route Reflector ose (Virtual Network Gateway), i cili do të lidhet me ToR-në përmes BGP dhe do të njoftojë loopback-un e tij, i cili duhet të jetë i aksesueshëm nga të gjitha DC-të.
Ja si do të duket AS-Path-i i tij:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]
Dhe këtu nuk duhet të ketë ASN të përsëritura.
Kështu, Spine_DC1 dhe Spine_DC2 duhet të jenë të ndryshëm, ashtu si leafX_DC1 dhe leafY_DC2, për të cilat ne po e arrijmë.
Siç e dini, ekzistojnë hacks që lejojnë pranim të rrugëve me ASN të përsëritura pavarësisht mekanizmit të parandalimit të cikleve (allowas-in në Cisco). Ka edhe aplikime të ligjshme për këtë. Por, kjo është një dobësi potenciale në qëndrueshmërinë e rrjetit. Edhe unë kam rënë në të dy herë.
Dhe nëse kemi mundësinë të shmangim gjërat e rrezikshme, do ta shfrytëzojmë atë.
Leaf ASN
Do të kemi një ASN individual në çdo Leaf-switch brenda të gjithë rrjetit.
E bëjmë këtë për shkak të arsyeve të përmendura më sipër: AS-Path pa cikle, konfigurimi BGP pa probleme.
Për të lejuar që rrugët mes Leaf-ëve të kalojnë pa pengesa, AS-Path duhet të duket kështu:
[leafX_ASN, spine_ASN, leafY_ASN]
ku leafX_ASN dhe leafY_ASN do ishte mirë që të ishin të ndryshme.
Kjo është e nevojshme edhe për situatën e njoftimit të loopback VNF mes DC-ve:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]
Do ta përdorim ASN 4-byte dhe do ta gjenerojmë atë në bazë të ASN Spine dhe numrit të Switch-it Leaf, saktësisht kështu: Spine_ASN.0000X.
Kjo është pamja me ASN.
Plani IP
Kryesisht, na nevojitet të ndajmë adresat për lidhjet e mëposhtme:
- Adresat e rrjetit Underlay midis ToR dhe makinës. Duhet të jenë unike në të gjithë rrjetin, në mënyrë që çdo makinë të mund të lidhet me një tjetër. Përshtatet më së miri 10/8. Për çdo raft do të kemi /26 me rezervë. Do të ndajmë me /19 për DC dhe /17 për rajonin.
- Adresat lidhëse mes Leaf/Tor dhe Spine.
Do tâi dĂ«shironim tĂ« caktuar algoritmikisht, domethĂ«nĂ« tĂ« llogariten nga emrat e pajisjeve qĂ« duhen lidhur.
Le të jetë⊠169.254.0.0/16.
SaktĂ«sisht 169.254.00X.Y/31, ku X â numri Spine, Y â rrjeti P2P /31.
Kjo do tĂ« lejojĂ« aktivizimin e deri nĂ« 128 rafts, dhe deri nĂ« 10 Spine nĂ« DC. Adresat lidhĂ«se mund (dhe do) tĂ« pĂ«rsĂ«riten nga DC nĂ« DC. - KĂ«ndi Spine â Edge-Leaf do tĂ« organizohet nĂ« subnetet 169.254.10X.Y/31, ku ashtu si edhe X â numri Spine, Y â rrjeti P2P /31.
- Adresat lidhĂ«s nga Edge-Leaf nĂ« magjistralen MPLS. KĂ«tu situata Ă«shtĂ« ndryshe â vendi i lidhjes sĂ« tĂ« gjitha pjesĂ«ve nĂ« njĂ« whole, kĂ«shtu qĂ« nuk do tĂ« mund tĂ« ripĂ«rdorim tĂ« njĂ«jtat adresa â duhet tĂ« zgjedhim subnetin e ardhshĂ«m tĂ« lirĂ«. Pra, do tĂ« marrim si bazĂ« 192.168.0.0/16 dhe do tĂ« nxjerrim adresat e lira nga ajo.
- Adresat Loopback. Do t'i japim të gjithë diapazonin 172.16.0.0/12.
- Leaf â nga /25 pĂ«r QK â tĂ« njĂ«jtat 128 rafte. Do tĂ« ndajmĂ« nga /23 pĂ«r rajonin.
- Spine â nga /28 pĂ«r QK â deri nĂ« 16 Spine. Do tĂ« ndajmĂ« nga /26 pĂ«r rajonin.
- Edge-Leaf â nga /29 pĂ«r QK â deri nĂ« 8 kuti. Do tĂ« ndajmĂ« nga /27 pĂ«r rajonin.
NĂ«se nĂ« QK nuk do tĂ« kemi mjaft diapazone tĂ« dedikuara (dhe nuk do t'i kemi â ne po pretenduojmĂ« pĂ«r hiper-shkallĂ«zim), thjesht ndajmĂ« bllokun e ardhshĂ«m.
Kjo është pamja me adresimin IP.
Loopback'Ă«t:
Prefiksi
Roli i pajisjes
Rajoni
QK
172.16.0.0/23
edge
Â
Â
172.16.0.0/27
sq
Â
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
sia
172.16.2.0/23
spine
Â
Â
172.16.2.0/26
sq
Â
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
sia
172.16.8.0/21
leaf
Â
Â
172.16.8.0/23
sq
Â
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
sia
NĂ«nstruktura:
Prefiksi
Rajoni
QK
10.0.0.0/17
sq
Â
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
sia
Laboratori
Dy furnizues. Një rrjet. ADSM.
Juniper + Arista. Ubuntu. E vjetra Eva.
Numri i burimeve në virtualen tonë në Miran është ende i kufizuar, kështu që për praktika do të përdorim këtë rrjet të thjeshtëzuar deri në maksimum.
Dy data qendra: Kazan dhe Barcelona.
- Dy spine në çdo njësi: Juniper dhe Arista.
- NjĂ« tor (Leaf) nĂ« secilin â Juniper dhe Arista, me njĂ« host tĂ« lidhur (do tĂ« marrim Cisco IOL tĂ« lehta pĂ«r kĂ«tĂ«).
- Një nyjë Edge-Leaf (deri tani vetëm Juniper).
- Një switch Cisco për t'i mbizotëruar të gjithëve.
- Përveç kutive të rrjetit, është aktivizuar një makinë virtuale menaxhuese. Nën menaxhimin e Ubuntu.
Ajo ka qasje në të gjitha pajisjet, do të ekzekutojë sistemet IPAM/DCIM, një grup skriptesh në Python, Ansible dhe gjithçka tjetër që mund të na nevojitet.
i të gjitha pajisjeve rrjetësore, të cilin do të përpiqemi ta riprodhojmë me ndihmën e automatizimit.
PĂ«rfundimi
A është zakoni? Të bëjmë një përmbledhje të shkurtër nën çdo artikull?
Pra, ne zgjodhëm të rrjetit Clos brenda DC-së, pasi presim shumë trafik East-West dhe duam ECMP.
E ndamĂ« rrjetin nĂ« fizik (underlay) dhe virtual (overlay). NdĂ«rsa overlay fillon nga hosti â duke e bĂ«rĂ« mĂ« tĂ« thjeshtĂ« kĂ«rkesĂ«n pĂ«r underlay.
Zgjodhëm BGP si protokollin e routing për rrjetet underlay për shkak të shkallëzueshmërisë dhe fleksibilitetit të politikave.
Do tĂ« kemi nyje tĂ« veçanta pĂ«r organizimin e DCI â Edge-leaf.
Në magji do të jetë OSPF+LDP.
DCI do të realizohet mbi bazën e MPLS L3VPN.
Për lidhjet P2P të adresave IP, ne do t'i llogarisim ato algoritmikisht në bazë të emrave të pajisjeve.
Loopback-ët do të caktohen sipas rolit të pajisjeve dhe pozicionit të tyre një pas një.
Prefiksat nĂ«n-drejtues â vetĂ«m pĂ«r komutatorĂ«t Leaf, njĂ« pas njĂ« nĂ« bazĂ« tĂ« pozicionit tĂ« tyre.
Supozoni se aktualisht nuk kemi pajisje të instaluara.
Prandaj, hapat tanĂ« tĂ« ardhshĂ«m do tĂ« jenĂ« â t'i regjistrojmĂ« ato nĂ« sisteme (IPAM, inventar), tĂ« organizojmĂ« qasjen, tĂ« gjenerojmĂ« konfigurimin dhe ta vendosim atĂ«.
NĂ« artikullin e ardhshĂ«m do tĂ« shqyrtojmĂ« Netbox â sistemin e inventarizimit dhe menaxhimit tĂ« hapĂ«sirĂ«s IP nĂ« DC.
Faleminderit
- Andrey Glazkov aka @glazgoo për rishikim dhe korrigjime
- Aleksandër Klimenko aka @v00lk për rishikim dhe korrigjime
- Artyom Chernobai për KDPV
Burimi: habr.com
