Questu articulu hè u sicondu in una seria di articuli "Cumu piglià u cuntrollu di a vostra infrastruttura di rete". U cuntenutu di tutti l'articuli in a serie è i ligami ponu esse truvati .
U nostru scopu in questa tappa hè di mette in ordine à a documentazione è a cunfigurazione.
À a fine di stu prucessu, duvete avè u settore necessariu di documenti è una reta cunfigurata in cunfurmità cù elli.
Avà ùn parlemu micca di auditu di sicurità - questu serà u sughjettu di a terza parte.
A difficultà di cumpiendu u compitu assignatu in questa tappa, sicuru, varieghja assai da cumpagnia à cumpagnia.
A situazione ideale hè quandu
- a vostra reta hè stata creata in cunfurmità cù u prugettu è avete un inseme cumpletu di documenti
- hè stata implementata in a vostra cumpagnia per a rete
- in cunfurmità cù stu prucessu, avete ducumenti (cumpresi tutti i diagrammi necessarii) chì furnisce infurmazione cumpleta nantu à u statu attuale di l'affari.
In stu casu, u vostru compitu hè abbastanza sèmplice. Duvete studià i ducumenti è rivede tutti i cambiamenti chì sò stati fatti.
In u peghju scenariu, averà
- una reta creata senza prughjettu, senza pianu, senza appruvazioni, da ingegneri chì ùn anu micca un livellu di qualificazione abbastanza,
- cù cambiamenti caòtichi, senza documentu, cù assai "basura" è suluzioni suboptimal
Hè chjaru chì a vostra situazione hè in un locu trà, ma sfurtunatamenti, in questa scala di megliu - peggiu, ci hè una probabilità alta chì sarete più vicinu à u peghju.
In questu casu, averà ancu bisognu di a capacità di leghje mente, perchè avete da amparà à capisce ciò chì i "disegni" vulianu fà, restaurà a so logica, finisce ciò chì ùn era micca finitu è caccià "basura".
E, sicuru, avete bisognu di correggerà i so sbagli, cambià (in questa fase u più minimu pussibule) u disignu è cambià o ricreà i schemi.
Stu articulu ùn pretende micca esse cumpletu. Quì descriveraghju solu i principii generali è fucalizza nantu à certi prublemi cumuni chì anu da esse risolti.
Inseme di documenti
Cuminciamu cù un esempiu.
Eccu alcuni documenti chì sò abitualmente creati in Cisco Systems durante u disignu.
CR - Requisiti di i Clienti, esigenze di i clienti (specificazioni tecniche).
Hè creatu inseme cù u cliente è determina i bisogni di a rete.HLD - Disegnu di altu livellu, cuncepimentu di altu livellu basatu nantu à i requisiti di a rete (CR). U ducumentu spiega è ghjustificà e decisioni architettoniche pigliate (topulugia, protokolli, selezzione di hardware,...). HLD ùn cuntene micca dettagli di disignu, cum'è l'interfaccia è l'indirizzi IP utilizati. Inoltre, a cunfigurazione hardware specifica ùn hè micca discututa quì. Piuttostu, stu documentu hè destinatu à spiegà i cuncetti chjave di u disignu à a gestione tecnica di u cliente.
LLD - Disegnu di livellu bassu, cuncepimentu di livellu bassu basatu nantu à u disignu di altu livellu (HLD).
Duverebbe cuntene tutti i ditaglii necessarii per implementà u prugettu, cum'è infurmazioni nantu à cumu cunnette è cunfigurà l'equipaggiu. Questa hè una guida cumpleta per implementà u disignu. Stu documentu deve furnisce infurmazioni abbastanza per a so implementazione ancu da un persunale menu qualificatu.Qualcosa, per esempiu, indirizzi IP, numeri AS, schema di commutazione fisica (cablatura), pò esse "messu" in documenti separati, cum'è PIN (Piano di Implementazione di a Rete).
A custruzzione di a reta principia dopu à a creazione di sti documenti è si trova in stretta cunfurmità cù elli è hè verificatu da u cliente (testi) per u rispettu di u disignu.
Di sicuru, diversi integratori, diversi clienti è diversi paesi ponu avè esigenze diverse per a documentazione di u prugettu. Ma vogliu evità formalità è cunsiderà u prublema nantu à i so meriti. Sta tappa ùn hè micca di cuncepimentu, ma di mette in ordine, è avemu bisognu di un inseme di ducumenti suffirenzi (schemi, tavule, discrizzioni...) per compie i nostri compiti.
E in my opinion, ci hè un certu minimu assolutu, senza quale hè impussibile di cuntrullà in modu efficace a reta.
Quessi sò i seguenti documenti:
- diagramma (log) di commutazione fisica (cablatura)
- schema di rete o diagrammi cù l'infurmazioni essenziali L2/L3
Schema di cambiamentu fisicu
In certi picculi imprese, u travagliu in relazione à l'installazione di l'equipaggiu è a commutazione fisica (cablatura) hè a responsabilità di l'ingegneri di a rete.
In questu casu, u prublema hè in parte risolta da l'approcciu seguente.
- Aduprate una descrizzione nantu à l'interfaccia per discrive ciò chì hè cunnessu cù questu
- chjude amministrativamente tutti i porti di l'equipaggiu di rete senza cunnessione
Questu vi darà l'uppurtunità, ancu in l'eventu di un prublema cù u ligame (quandu cdp o lldp ùn funziona micca in questa interfaccia), per stabilisce rapidamente ciò chì hè cunnessu à stu portu.
Pudete ancu vede facilmente quali porti sò occupati è chì sò liberi, chì hè necessariu per a pianificazione di cunnessione di novi equipaghji di rete, servitori o stazioni di travagliu.
Ma hè chjaru chì si perde l'accessu à l'equipaggiu, perderà ancu l'accessu à sta informazione. Inoltre, in questu modu ùn puderete micca registrà infurmazione cusì impurtante cum'è chì tipu d'equipaggiu, chì cunsumu d'energia, quanti porti, in quale rack hè, chì patch panels sò quì è induve (in quale rack / patch panel). ) sò cunnessi. Per quessa, a documentazione supplementaria (micca solu descrizzioni nantu à l'equipaggiu) hè sempre assai utile.
L'opzione ideale hè di utilizà l'applicazioni pensate per travaglià cù stu tipu d'infurmazioni. Ma pudete limità à tavule simplici (per esempiu, in Excel) o visualizà l'infurmazioni chì cunsiderà necessariu in diagrammi L1 / L2.
Impurtante!
Un ingegnere di rete, sicuru, pò cunnosce abbastanza bè l'intricacies è i normi di SCS, tippi di rack, tippi di alimentazione senza interruzzione, ciò chì hè un corridore friddu è caldu, cumu fà a terra curretta ... cum'è in principiu pò. cunnosce a fisica di particeddi elementari o C++. Ma unu deve ancu capisce chì tuttu questu ùn hè micca a so area di cunniscenza.
Dunque, hè una bona pratica per avè o dipartimenti dedicati o persone dedicate per risolve i prublemi ligati à a stallazione, a cunnessione, u mantenimentu di l'equipaggiu, è ancu à u cambiamentu fisicu. Di solitu per i centri di dati questu hè ingegneri di centru di dati, è per un uffiziu hè help-desk.
Se tali divisioni sò furnite in a vostra cumpagnia, allora i prublemi di logging switching fisicu ùn sò micca u vostru compitu, è pudete limità solu à a descrizzione di l'interfaccia è l'arrestu amministrativu di i porti inutilizati.
Diagrammi di rete
Ùn ci hè micca un approcciu universale per disegnu diagrammi.
A più impurtante hè chì i diagrammi anu da furnisce una intelligenza di cumu u trafficu scorri, attraversu quale elementi lògichi è fisichi di a vostra reta.
Per elementi fisichi intendemu
- equipamentu attivu
- interfacce / porti di l'equipaggiu attivu
Sottu logica -
- dispusitivi lògichi (N7K VDC, Palo Alto VSYS, ...)
- VRF
- Vilans
- subinterfaces
- tunnel
- zoni
- ...
Inoltre, se a vostra reta ùn hè micca cumplettamente elementare, serà custituita da diversi segmenti.
Per esempiu
- centru di dati
- internet
- WAN
- accessu remoto
- LAN d'uffiziu
- DMZ
- ...
Hè sàviu di avè parechji diagrammi chì dà sia a grande stampa (cumu u trafficu scorri trà tutti questi segmenti) è una spiegazione detallata di ogni segmentu individuale.
Siccomu in i riti muderni ponu esse parechje strati lògichi, hè forse un bonu approcciu (ma micca necessariu) per fà circuiti diffirenti per diverse strati, per esempiu, in u casu di un accostu overlay, questu puderia esse i seguenti circuiti:
- superposizione
- L1/L2 sottu
- L3 underlay
Di sicuru, u diagramma più impurtante, senza quale hè impussibile di capisce l'idea di u vostru disignu, hè u schema di routing.
Schema di routing
À u minimu, stu diagramma deve riflette
- quali protokolli di routing sò usati è induve
- infurmazione basica nantu à i paràmetri di u protocolu di routing (area / numeru AS / router-id / ...)
- nant'à quali dispusitivi si faci a ridistribuzione?
- induve a filtrazione è l'aggregazione di rotte accade
- infurmazione di rotta predeterminata
Inoltre, u schema L2 (OSI) hè spessu utile.
Schema L2 (OSI)
Stu diagramma pò vede l'infurmazioni seguenti:
- quali VLAN
- quali porti sò porti trunk
- quali porti sò aggregati in ether-channel (canale portu), canali portu virtuale
- quali protokolli STP sò utilizati è nantu à quali dispusitivi
- paràmetri di basi STP: salvezza root / root, costu STP, priorità portu
- impostazioni STP supplementari: BPDU guard/filter, root guard...
Errori tipici di disignu
Un esempiu di un malu approcciu à custruisce una reta.
Pigliemu un esempiu simplice di custruisce una LAN d'uffiziu simplice.
Avè sperienza in l'insignamentu di telecomunicazioni à i studienti, possu dì chì quasi ogni studiente à a mità di u secondu semestru hà a cunniscenza necessaria (cum'è parte di u corsu ch'e aghju insignatu) per stabilisce una LAN d'uffiziu simplice.
Chì ci hè cusì difficiule di cunnetta i switch à l'altri, di stabilisce VLAN, interfacce SVI (in u casu di switch L3) è stabilisce un routing staticu?
Tuttu hà da travaglià.
Ma à u listessu tempu, e dumande riguardanti
- sicurità
- riservazione
- scala di rete
- produtividade
- throughput
- affidabilità
- ...
Da u tempu à u tempu aghju intesu a dichjarazione chì una LAN di l'uffiziu hè qualcosa assai simplice è di solitu intesu questu da ingegneri (è amministratori) chì facenu tuttu, ma i rete, è dicenu cusì cun fiducia chì ùn vi maravigliate se a LAN serà. fattu da persone cù pratica è cunniscenze insufficiente è sarà fattu cù apprussimatamente i stessi sbagli chì vi discriverà quì sottu.
Errori cumuni di cuncepimentu L1 (OSI).
- Sè, però, sì ancu rispunsevuli di SCS, allora unu di i legati più sgradevoli chì pudete riceve hè un cambiamentu trascuratu è mal pensatu.
Puderia ancu classificà cum'è errori di tipu L1 ligati à e risorse di l'equipaggiu utilizatu, per esempiu,
- larghezza di banda insufficiente
- TCAM insufficiente nantu à l'equipaggiu (o usu inefficace di questu)
- prestazione insufficiente (spessu ligata à i firewall)
Errori cumuni di cuncepimentu L2 (OSI).
Spessu, quandu ùn ci hè micca una bona cunniscenza di u funziunamentu di u STP è di i prublemi potenziali chì porta cun ellu, i switches sò cunnessi caoticamente, cù paràmetri predeterminati, senza sintonizzazioni STP supplementari.
In u risultatu, avemu spessu i seguenti
- grande diametru di rete STP, chì pò purtà à e timpeste broadcast
- A radica STP serà determinata aleatoriamente (basatu nantu à l'indirizzu mac) è a strada di u trafficu serà subottimale
- i porti cunnessi à l'ospiti ùn saranu micca cunfigurati cum'è edge (portfast), chì portarà à u recalculazione STP quandu si accende / spegne e stazioni finali.
- a reta ùn serà micca segmentata à u nivellu L1 / L2, per via di quale i prublemi cù qualsiasi switch (per esempiu, sopracarga di energia) portanu à un recalculazione di a topologia STP è à frenà u trafficu in tutti i VLAN in tutti i switches (cumpresu i switches). unu criticu da u puntu di vista di u segmentu di serviziu di continuità)
Esempii di sbagli in u disignu L3 (OSI).
Uni pochi errori tipici di i networkers principianti:
- Usu frequente (o usu solu) di routing staticu
- usu di protokolli di routing subottimali per un designu datu
- segmentazione di rete logica subottimale
- usu suboptimal di u spaziu di indirizzu, chì ùn permette micca l'agregazione di rotte
- senza rotte di salvezza
- senza riservazione per u gateway predeterminatu
- routing asimmetricu quandu ricustruisce rotte (pò esse criticu in u casu di NAT / PAT, firewalls statefull)
- prublemi cù MTU
- quandu e rotte sò ricustruite, u trafficu passa per altre zoni di sicurità o ancu altri firewalls, chì porta à stu trafficu esse abbandunatu
- scarsa scalabilità di a topologia
Criterium per a valutazione di a qualità di u disignu
Quandu avemu parlatu di ottimalità / non-optimalità, avemu da capisce da u puntu di vista di quale criteri pudemu evaluà questu. Eccu, da u mo puntu di vista, sò i criterii più significativi (ma micca tutti) (è spiegazione in relazione à i protokolli di routing):
- scalabilità
Per esempiu, decide di aghjunghje un altru centru di dati. Quantu faciule pudete fà? - facilità d'usu (gestionabilità)
Quantu faciuli è sicuri sò i cambiamenti operativi, cum'è annunzià una nova griglia o rotte di filtrazione? - dispunibilità
Chì percentuale di u tempu chì u vostru sistema furnisce u livellu di serviziu necessariu? - sicurità
Quantu hè sicura i dati trasmessi? - u prezzu
Cambiamenti
U principiu di basa in questu stadiu pò esse spressione da a formula "ùn fate micca male".
Dunque, ancu s'ellu ùn hè micca cumplettamente d'accordu cù u disignu è l'implementazione scelta (configurazione), ùn hè micca sempre cunsigliatu per fà cambiamenti. Un approcciu raghjunatu hè di classificà tutti i prublemi identificati secondu dui parametri:
- quantu faciule pò esse risoltu stu prublema
- quantu risicu ella porta ?
Prima di tuttu, hè necessariu eliminà ciò chì attualmente riduce u livellu di serviziu furnitu sottu à u livellu accettabile, per esempiu, i prublemi chì portanu à a perdita di pacchetti. Allora riparà ciò chì hè più faciule è più sicuru per riparà in ordine decrescente di gravità di risicu (da prublemi di cunfigurazione o di cunfigurazione à altu risicu à quelli à pocu risicu).
U perfeccionismu in questa fase pò esse preghjudiziu. Purtate u disignu à un statu satisfactoriu è sincronizà a cunfigurazione di a rete in cunseguenza.
Source: www.habr.com