Questo articolo è il secondo di una serie di articoli "Come assumere il controllo della propria infrastruttura di rete". È possibile trovare il contenuto di tutti gli articoli della serie e i collegamenti .
Il nostro obiettivo in questa fase è mettere ordine nella documentazione e nella configurazione.
Alla fine di questo processo, dovresti avere la serie necessaria di documenti e una rete configurata in conformità con essi.
Ora non parleremo dei controlli di sicurezza: questo sarà oggetto della terza parte.
La difficoltà di portare a termine il compito assegnato in questa fase, ovviamente, varia molto da azienda ad azienda.
La situazione ideale è quando
- la tua rete è stata creata in conformità con il progetto e hai un set completo di documenti
- è stato implementato nella tua azienda per rete
- in conformità con questo processo, si dispone di documenti (compresi tutti i diagrammi necessari) che forniscono informazioni complete sullo stato attuale delle cose
In questo caso, il tuo compito è abbastanza semplice. Dovresti studiare i documenti e rivedere tutte le modifiche che sono state apportate.
Nel peggiore dei casi, lo avrai
- una rete creata senza progetto, senza piano, senza approvazione, da ingegneri che non hanno un livello di qualificazione sufficiente,
- con cambiamenti caotici e non documentati, con molta “spazzatura” e soluzioni non ottimali
È chiaro che la tua situazione è da qualche parte nel mezzo, ma sfortunatamente, su questa scala di meglio - peggio, c'è un'alta probabilità che sarai più vicino alla fine peggiore.
In questo caso servirà anche la capacità di leggere nel pensiero, perché bisognerà imparare a capire cosa volevano fare i “progettisti”, ripristinare la loro logica, finire ciò che non era finito e rimuovere la “spazzatura”.
E, naturalmente, dovrai correggere i tuoi errori, cambiare (in questa fase il minimo possibile) il design e cambiare o ricreare gli schemi.
Questo articolo non pretende in alcun modo di essere completo. Qui descriverò solo i principi generali e mi concentrerò su alcuni problemi comuni che devono essere risolti.
Insieme di documenti
Cominciamo con un esempio.
Di seguito sono riportati alcuni documenti che normalmente vengono creati presso Cisco Systems durante la progettazione.
CR – Requisiti del cliente, requisiti del cliente (specifiche tecniche).
Viene creato insieme al cliente e determina i requisiti di rete.HLD – High Level Design, progettazione di alto livello basata sui requisiti di rete (CR). Il documento spiega e giustifica le decisioni architetturali prese (topologia, protocolli, selezione dell'hardware,...). HLD non contiene dettagli di progettazione, come le interfacce e gli indirizzi IP utilizzati. Inoltre, la configurazione hardware specifica non viene discussa qui. Piuttosto, questo documento ha lo scopo di spiegare i concetti chiave della progettazione alla direzione tecnica del cliente.
LLD – Low Level Design, progettazione di basso livello basata sulla progettazione di alto livello (HLD).
Dovrebbe contenere tutti i dettagli necessari per implementare il progetto, come informazioni su come collegare e configurare l'apparecchiatura. Questa è una guida completa per implementare il progetto. Questo documento dovrebbe fornire informazioni sufficienti per la sua attuazione anche da parte di personale meno qualificato.Qualcosa, ad esempio, indirizzi IP, numeri AS, schema di commutazione fisica (cablaggio), può essere "pubblicato" in documenti separati, come NIP (Piano di Realizzazione della Rete).
La costruzione della rete inizia dopo la creazione di questi documenti e avviene in stretta conformità con gli stessi e viene poi verificata dal cliente (prove) per la conformità al progetto.
Naturalmente, integratori diversi, clienti diversi e paesi diversi possono avere requisiti diversi per la documentazione di progetto. Ma vorrei evitare le formalità e considerare la questione nel merito. Questa fase non riguarda la progettazione, ma la messa in ordine e abbiamo bisogno di una serie di documenti sufficiente (diagrammi, tabelle, descrizioni...) per completare i nostri compiti.
E secondo me esiste un minimo assoluto, senza il quale è impossibile controllare efficacemente la rete.
Si tratta dei seguenti documenti:
- diagramma (log) della commutazione fisica (cablaggio)
- diagramma di rete o diagrammi con informazioni essenziali L2/L3
Schema di commutazione fisica
In alcune piccole aziende, il lavoro relativo all'installazione delle apparecchiature e alla commutazione fisica (cablaggio) è responsabilità degli ingegneri di rete.
In questo caso il problema è in parte risolto con il seguente approccio.
- utilizzare una descrizione sull'interfaccia per descrivere cosa è collegato ad essa
- arrestare amministrativamente tutte le porte delle apparecchiature di rete non connesse
Questo ti darà l'opportunità, anche in caso di problemi con il collegamento (quando cdp o lldp non funzionano su questa interfaccia), di determinare rapidamente cosa è collegato a questa porta.
Puoi anche vedere facilmente quali porte sono occupate e quali sono libere, cosa necessaria per pianificare le connessioni di nuove apparecchiature di rete, server o workstation.
Ma è chiaro che se si perde l’accesso all’attrezzatura, si perderà anche l’accesso a queste informazioni. Inoltre in questo modo non potrete registrare informazioni importanti come che tipo di apparecchiatura, che consumo energetico, quante porte, in che rack si trova, quali patch panel ci sono e dove (in quale rack/patch panel ) sono collegati. Pertanto, la documentazione aggiuntiva (non solo la descrizione dell'apparecchiatura) è comunque molto utile.
L'opzione ideale è utilizzare applicazioni progettate per funzionare con questo tipo di informazioni. Ma puoi limitarti a semplici tabelle (ad esempio in Excel) o visualizzare le informazioni che ritieni necessarie nei diagrammi L1/L2.
Importante!
Un ingegnere di rete, ovviamente, può conoscere abbastanza bene le complessità e gli standard di SCS, i tipi di rack, i tipi di gruppi di continuità, cos'è un corridoio freddo e caldo, come eseguire una corretta messa a terra... proprio come in linea di principio può conoscere la fisica delle particelle elementari o il C++. Ma bisogna ancora capire che tutto questo non è il suo campo di conoscenza.
Pertanto, è buona norma disporre di reparti dedicati o di persone dedicate per risolvere i problemi relativi all'installazione, al collegamento, alla manutenzione delle apparecchiature, nonché alla commutazione fisica. Di solito per i data center si tratta di ingegneri del data center e per un ufficio è l'help desk.
Se nella tua azienda sono previste tali divisioni, i problemi relativi alla registrazione del passaggio fisico non sono un tuo compito e puoi limitarti solo alla descrizione sull'interfaccia e alla chiusura amministrativa delle porte inutilizzate.
Diagrammi di rete
Non esiste un approccio universale per disegnare diagrammi.
La cosa più importante è che i diagrammi forniscano una comprensione di come fluirà il traffico, attraverso quali elementi logici e fisici della tua rete.
Per elementi fisici intendiamo
- apparecchiature attive
- interfacce/porte delle apparecchiature attive
Sotto logica -
- dispositivi logici (N7K VDC, Palo Alto VSYS, ...)
- VRF
- Vilans
- sottointerfacce
- tunnel
- zona
- ...
Inoltre, se la tua rete non è del tutto elementare, sarà composta da diversi segmenti.
Per esempio
- Banca dati
- Internet
- WAN
- accesso remoto
- LAN dell'ufficio
- DMZ
- ...
È consigliabile disporre di diversi diagrammi che forniscano sia il quadro generale (come il traffico scorre tra tutti questi segmenti) sia una spiegazione dettagliata di ogni singolo segmento.
Poiché nelle reti moderne possono esserci molti livelli logici, forse è un buon approccio (ma non necessario) creare circuiti diversi per livelli diversi, ad esempio, nel caso di un approccio overlay potrebbero essere i seguenti circuiti:
- copertura
- Sottofondo L1/L2
- Sottofondo L3
Naturalmente, lo schema più importante, senza il quale è impossibile comprendere l'idea del tuo progetto, è il diagramma di instradamento.
Schema di percorso
Come minimo, questo diagramma dovrebbe riflettere
- quali protocolli di routing vengono utilizzati e dove
- informazioni di base sulle impostazioni del protocollo di routing (area/numero AS/ID router/...)
- su quali dispositivi avviene la ridistribuzione?
- dove avviene il filtraggio e l'aggregazione del percorso
- informazioni sul percorso predefinito
Inoltre, lo schema L2 (OSI) è spesso utile.
Schema L2 (OSI)
Questo diagramma può mostrare le seguenti informazioni:
- quali VLAN
- quali porte sono porte trunk
- quali porte sono aggregate in ether-channel (port channel), port channel virtuale
- quali protocolli STP vengono utilizzati e su quali dispositivi
- impostazioni STP di base: backup root/root, costo STP, priorità porta
- impostazioni STP aggiuntive: protezione/filtro BPDU, protezione anti-radice...
Errori tipici di progettazione
Un esempio di un cattivo approccio alla costruzione di una rete.
Facciamo un semplice esempio di creazione di una semplice LAN da ufficio.
Avendo esperienza nell'insegnamento delle telecomunicazioni agli studenti, posso dire che praticamente ogni studente entro la metà del secondo semestre possiede le conoscenze necessarie (come parte del corso che ho insegnato) per configurare una semplice LAN da ufficio.
Cosa c'è di così difficile nel collegare gli switch tra loro, impostare VLAN, interfacce SVI (nel caso degli switch L3) e impostare il routing statico?
Tutto funzionerà.
Ma allo stesso tempo, domande relative a
- sicurezza
- prenotazione
- ridimensionamento della rete
- prestazione
- portata
- affidabilità
- ...
Di tanto in tanto sento affermare che una LAN da ufficio è qualcosa di molto semplice e di solito lo sento da ingegneri (e manager) che fanno tutto tranne le reti, e lo dicono con tanta sicurezza che non stupitevi se la LAN sarà fatto da persone con pratica e conoscenza insufficienti e sarà fatto approssimativamente con gli stessi errori che descriverò di seguito.
Errori comuni di progettazione L1 (OSI).
- Se, tuttavia, sei anche responsabile di SCS, una delle eredità più spiacevoli che potresti ricevere è un cambiamento negligente e sconsiderato.
Classificherei come tipo L1 anche gli errori relativi alle risorse delle attrezzature utilizzate, ad esempio,
- larghezza di banda insufficiente
- TCAM insufficiente sull'attrezzatura (o suo utilizzo inefficace)
- prestazioni insufficienti (spesso legate ai firewall)
Errori comuni di progettazione L2 (OSI).
Spesso, quando non si ha una buona comprensione di come funziona STP e quali potenziali problemi comporta, gli switch vengono collegati in modo caotico, con impostazioni predefinite, senza ulteriore regolazione STP.
Di conseguenza, spesso abbiamo quanto segue
- grande diametro della rete STP, che può portare a tempeste di trasmissione
- La root STP verrà determinata in modo casuale (in base all'indirizzo mac) e il percorso del traffico non sarà ottimale
- le porte connesse agli host non verranno configurate come edge (portfast), il che porterà al ricalcolo STP all'accensione/spegnimento delle stazioni finali
- la rete non verrà segmentata a livello L1/L2, per cui problemi con qualsiasi switch (ad esempio, sovraccarico di potenza) porteranno a un ricalcolo della topologia STP e all'interruzione del traffico in tutte le VLAN su tutti gli switch (compresi quelli uno critico dal punto di vista del segmento del servizio di continuità)
Esempi di errori nella progettazione L3 (OSI).
Alcuni errori tipici dei networker alle prime armi:
- Uso frequente (o uso solo) del routing statico
- utilizzo di protocolli di routing non ottimali per un dato progetto
- segmentazione logica della rete non ottimale
- uso non ottimale dello spazio degli indirizzi, che non consente l'aggregazione dei percorsi
- nessun percorso di backup
- nessuna prenotazione per il gateway predefinito
- routing asimmetrico durante la ricostruzione dei percorsi (può essere fondamentale nel caso di NAT/PAT, firewall statefull)
- problemi con MTU
- quando i percorsi vengono ricostruiti, il traffico passa attraverso altre zone di sicurezza o anche altri firewall, il che porta alla caduta di questo traffico
- scarsa scalabilità della topologia
Criteri per valutare la qualità della progettazione
Quando parliamo di ottimalità/non ottimalità dobbiamo capire dal punto di vista di quali criteri possiamo valutare questa cosa. Ecco, dal mio punto di vista, i criteri più significativi (ma non tutti) (e la spiegazione in relazione ai protocolli di routing):
- scalabilità
Ad esempio, decidi di aggiungere un altro data center. Quanto è facile farlo? - facilità d'uso (gestibilità)
Quanto sono facili e sicuri i cambiamenti operativi, come l'annuncio di una nuova griglia o il filtraggio dei percorsi? - disponibilità
In quale percentuale di tempo il vostro sistema fornisce il livello di servizio richiesto? - sicurezza
Quanto sono sicuri i dati trasmessi? - prezzo
Cambiamenti
Il principio fondamentale in questa fase può essere espresso con la formula “non nuocere”.
Pertanto, anche se non si è completamente d'accordo con il design e l'implementazione (configurazione) scelta, non è sempre consigliabile apportare modifiche. Un approccio ragionevole consiste nel classificare tutti i problemi identificati in base a due parametri:
- quanto facilmente è possibile risolvere questo problema
- quanto rischio corre?
Innanzitutto è necessario eliminare ciò che attualmente riduce il livello di servizio fornito al di sotto del livello accettabile, ad esempio i problemi che portano alla perdita di pacchetti. Quindi correggere ciò che è più semplice e sicuro da risolvere in ordine decrescente di gravità del rischio (dai problemi di progettazione o configurazione ad alto rischio a quelli a basso rischio).
Il perfezionismo in questa fase può essere dannoso. Portare il progetto a uno stato soddisfacente e sincronizzare di conseguenza la configurazione di rete.
Fonte: habr.com