Questo articolo è il secondo di una serie di articoli su "Come prendere il controllo della tua infrastruttura di rete". Puoi 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 il necessario pacchetto di documenti e una rete configurata di conseguenza.
Ora non parleremo dell'audit di sicurezza – questo sarà il tema del terzo articolo.
La complessità dell'attività da svolgere in questa fase varia notevolmente da azienda a azienda.
La situazione ideale è quando
- la tua rete è stata realizzata secondo il progetto e hai un completo pacchetto di documenti
- nella tua azienda è stato implementato per la rete
- secondo questo processo, disponi di documenti (compresi tutti i diagrammi necessari) che forniscono informazioni complete sulla situazione attuale
In tal caso, il tuo compito è relativamente semplice. Devi esaminare i documenti e rivedere tutte le modifiche effettuate.
Nella situazione peggiore, avrai
- una rete creata senza progetto, senza piano, senza approvazione, da ingegneri che non hanno un livello di qualificazione adeguato,
- con modifiche caotiche e non documentate, con una grande quantità di "spazzatura" e soluzioni subottimali
È chiaro che la tua situazione si troverà in una posizione intermedia, ma purtroppo, su questa scala da migliore a peggiore, è molto probabile che tu ti trovi più vicino al lato peggiore.
In questo caso, ti sarà richiesta anche la capacità di leggere nella mente, perché dovrai imparare a capire cosa volevano fare i "progettisti", ricostruire la loro logica, completare ciò che non era stato terminato e rimuovere la "spazzatura".
E, naturalmente, dovrai correggere i loro errori, modificare (in questa fase, se possibile, il meno possibile) il design e modificare o creare nuovamente i diagrammi.
Questo articolo non pretende in alcun modo di essere completo. Qui descriverò solo i principi generali e mi soffermerò su alcuni problemi comuni che si presentano.
Set di documenti
Iniziamo con un esempio.
Di seguito sono riportati alcuni documenti che si consiglia di creare presso Cisco Systems durante la progettazione.
CR – Customer Requirements, requisiti del cliente (specifica tecnica).
Creato in collaborazione con il cliente e determina i requisiti per la rete.HLD – High Level Design, progettazione ad alto livello basata sui requisiti di rete (CR). Questo documento spiega e giustifica le decisioni architettoniche adottate (topologia, protocolli, scelta dell'hardware,…). L'HLD non contiene dettagli di progettazione, come le interfacce utilizzate e gli indirizzi IP. Inoltre, non si discute la configurazione specifica dell'hardware. Questo documento è piuttosto destinato a spiegare al management tecnico del cliente i concetti chiave del design.
LLD – Low Level Design, design a basso livello basato su quello ad alto livello (HLD).
Deve contenere tutti i dettagli necessari per l'implementazione del progetto, come informazioni su come collegare e configurare l'hardware. Questo è un completo manuale di implementazione del design. Questo documento deve fornire informazioni sufficienti per la sua realizzazione anche a personale non molto qualificato.Alcune informazioni, come gli indirizzi IP, i numeri AS, lo schema di cablaggio, possono essere "estratte" in documenti separati, come NIP (Network Implementation Plan).
La costruzione della rete inizia dopo la creazione di questi documenti e avviene rigorosamente in conformità a essi, per poi essere verificata dal cliente (test) per la conformità al design.
Naturalmente, le esigenze della documentazione progettuale possono variare tra integratori diversi, clienti diversi e paesi diversi. Tuttavia, sarebbe utile evitare formalismi e affrontare la questione nel merito. Questo passo non riguarda la progettazione, ma il mettere ordine, e ci serve un pacchetto di documenti sufficiente per svolgere i nostri compiti (schemi, tabelle, descrizioni …).
E secondo il mio parere, esiste un certo minimo assoluto, senza il quale non è possibile controllare efficacemente la rete.
Questi documenti sono i seguenti:
- schema (registro) di cablaggio
- schema o schemi della rete con informazioni sostanziali L2/L3
Schema di commutazione fisica
In alcune piccole aziende, i lavori relativi all'installazione dell'hardware e al cablaggio sono di responsabilità degli ingegneri di rete.
In questo caso, il compito viene parzialmente risolto con il seguente approccio.
- utilizza la descrizione sull'interfaccia per descrivere cosa è collegato ad essa
- disattiva amministrativamente (shutdown) tutte le porte non collegate dell'hardware di rete
Questo ti permetterà, anche in caso di problemi con il collegamento (quando CDP o LLDP non funzionano su questa interfaccia), di identificare rapidamente cosa è connesso a questa porta.
Inoltre, potrai facilmente vedere quali porte sono occupate e quali sono libere, il che è necessario per pianificare le connessioni di nuovi dispositivi di rete, server o workstation.
È chiaro che se perdi l'accesso all'hardware, perderai anche l'accesso a queste informazioni. Inoltre, in questo modo non potrai registrare informazioni importanti come quale hardware è presente, con quale potenza assorbita, quante porte ha, in quale rack si trova, quali patch panel ci sono e a quali rack/patch panel sono collegati. Pertanto, una documentazione aggiuntiva (non solo le etichette sull'hardware) è molto utile.
La soluzione ideale è utilizzare applicazioni progettate per gestire questo tipo di informazioni. Ma si può anche limitare a semplici tabelle (ad esempio, in Excel) o visualizzare le informazioni che ritieni necessarie negli schemi L1/L2.
Attenzione!
Un ingegnere di rete potrebbe conoscere abbastanza bene le peculiarità e gli standard del cablaggio strutturato, i tipi di rack, i tipi di alimentatori, cosa sia un corridoio freddo e uno caldo, eseguire una corretta messa a terra, così come in linea di principio potrebbe sapere fisica delle particelle elementari o C++. Ma è importante capire che tutto ciò non fa parte della sua area di competenza.
Pertanto, è buona prassi avere dipartimenti o persone dedicate per risolvere problemi legati all'installazione, connessione, manutenzione del funzionamento dell'hardware e realizzazione fisica dei cablaggi. Di solito, per i data center ci sono ingegneri del data center, mentre per gli uffici esiste il help-desk.
Se nella tua azienda sono previsti tali reparti, le questioni legate alla registrazione dei cablaggi fisici non sono un tuo compito, e puoi limitarti a riportare solo la descrizione sull'interfaccia e disattivare amministrativamente le porte non utilizzate.
Schema di rete
Non esiste un approccio universale per disegnare schemi.
La cosa più importante è che gli schemi devono fornire una comprensione di come si muoverà il traffico, attraverso quali elementi logici e fisici della tua rete.
Per elementi fisici intendiamo
- hardware attivo
- interfacce/porte dell'hardware attivo
Per elementi logici intendiamo
- dispositivi logici (N7K VDC, Palo Alto VSYS, ...)
- VRF
- VLAN
- subinterfacce
- tunnel
- zone
- …
Inoltre, se la tua rete non è affatto elementare, sarà composta da diversi segmenti.
Ad esempio
- data center
- Internet
- WAN
- accesso remoto
- LAN dell'ufficio
- DMZ
- …
Sarebbe saggio avere diversi schemi che forniscano sia una visione generale (di come il traffico si muove tra tutti questi segmenti) sia una spiegazione dettagliata di ciascun segmento specifico.
Poiché nelle reti moderne possono esserci molti livelli logici, un buon (ma non obbligatorio) approccio è fare schemi diversi per i vari livelli, ad esempio, nel caso di un approccio di overlay, potrebbero esserci i seguenti schemi:
- overlay
- L1/L2 underlay
- L3 underlay
Certo, lo schema più importante, senza il quale non è possibile comprendere l'idea del tuo design, è lo schema di routing.
Schema di routing
Almeno in questo schema devono essere indicati
- quali protocolli di routing e dove vengono utilizzati
- informazioni di base sulle impostazioni del protocollo di routing (area/AS number/router-id/...)
- su quali dispositivi avviene la redistribuzione
- dove avviene la filtrazione e l'aggregazione delle rotte
- informazioni sulla rotta predefinita
Inoltre, spesso è utile avere uno schema L2 (OSI).
Schema L2 (OSI)
In questo schema possono essere riportate le seguenti informazioni:
- quali VLAN
- quali porte sono trunk
- quali porte sono aggregate in EtherChannel (port channel), virtual port channel
- quali protocolli STP e su quali dispositivi vengono utilizzati
- impostazioni di base dello STP: root/root backup, costo STP, priorità della porta
- ulteriori impostazioni STP: BPDU guardia/filtraggio, guardia radice…
Errori tipici nella progettazione
Esempio di un cattivo approccio nella costruzione di una rete.
Prendiamo un semplice esempio di costruzione di una rete locale per uffici.
Avendo insegnato telecomunicazioni agli studenti, posso dire che praticamente ogni studente a metà del secondo semestre possiede le conoscenze necessarie (nell'ambito del corso che ho tenuto) per configurare una semplice LAN per uffici.
Cosa c'è di difficile nel collegare insieme gli switch, configurare le VLAN, gli interfacce SVI (nel caso di switch L3) e scrivere un routing statico?
Tutto funzionerà.
Ma rimangono in sospeso questioni relative a
- sicurezza
- riserva
- scalabilità della rete
- prestazioni
- larghezza di banda
- all'affidabilità
- …
A volte sento l'affermazione che una LAN d'ufficio sia qualcosa di molto semplice e spesso la sento da ingegneri (e manager) che si occupano di tutto tranne che di reti. E lo dicono con tale sicurezza che non sorprende se la LAN viene realizzata da persone con insufficienti esperienze e conoscenze, e viene realizzata con gli errori che descriverò di seguito.
Errori tipici nel design di livello L1 (OSI)
- Se sei anche responsabile della cablatura strutturata, uno degli erediti più sgradevoli che potresti ricevere è la commutazione trascurata e poco studiata.
Appartengono al tipo L1 anche errori legati alle risorse dell'attrezzatura utilizzata, ad esempio,
- larghezza di banda insufficiente
- insufficiente TCAM sull'hardware (o utilizzo inefficiente)
- prestazioni insufficienti (spesso riguardano i firewall)
Errori tipici nel design di livello L2 (OSI)
Spesso, quando non c'è una buona comprensione di come funziona STP e quali problemi potenziali porta con sé, gli switch vengono collegati in modo caotico, con impostazioni predefinite, senza ulteriori ottimizzazioni STP.
Il risultato è spesso il seguente:
- un grande diametro STP della rete, che può portare a tempeste di broadcast
- il root STP sarà determinato casualmente (sulla base dell'indirizzo MAC) e il percorso del traffico sarà subottimale
- le porte collegate agli host non saranno configurate come edge (portfast), il che porterà a un ricalcolo dello STP all'accensione/spegnimento delle stazioni finali
- la rete non sarà segmentata a livello L1/L2, il che farà sì che qualsiasi problema con uno switch (ad esempio, sovraccarico energetico) porterà a un ricalcolo della topologia STP e all'arresto del traffico in tutte le VLAN su tutti gli switch (compresa una delle sezioni critiche per la continuità del servizio)
Esempi di errori nella progettazione L3 (OSI)
Alcuni errori caratteristici dei principianti nelle reti:
- uso frequente (o uso esclusivo) del routing statico
- utilizzo di protocolli di routing non ottimali per questo design
- segmentazione logica subottimale della rete
- utilizzo subottimale dello spazio degli indirizzi, che non consente l'aggregazione delle rotte
- assenza di rotte di backup
- assenza di riservatezza per il gateway predefinito
- routing asimmetrico durante la ristrutturazione delle rotte (può essere critico in caso di NAT/PAT, firewall stateful)
- problemi con MTU
- durante la ristrutturazione delle rotte, il traffico passa attraverso altre zone di sicurezza o anche altri firewall, il che porta al drop di questo traffico
- scarsa scalabilità della topologia
Criteri di valutazione della qualità del design
Quando parliamo di ottimalità/non ottimalità, dobbiamo capire secondo quali criteri possiamo valutarlo. Secondo me, i criteri più significativi (ma non tutti) sono:
- scalabilità (scalability)
Ad esempio, hai deciso di aggiungere un altro data center. Quanto è facile farlo? - facilità di gestione (manageability)
Quanto sono facili e sicuri i cambiamenti operativi, ad esempio, l'annuncio di una nuova rete o la filtrazione delle rotte - disponibilità (availability)
Quale percentuale di tempo il tuo sistema fornisce il livello di servizio richiesto - sicurezza (security)
Quanto sono protetti i dati trasmessi - il prezzo
Modifiche
Il principio fondamentale in questa fase può essere espresso con la formula "non nuocere".
Pertanto, anche se non sei completamente d'accordo con il design e con l'implementazione scelta (configurazione), non sempre è opportuno apportare modifiche. Un approccio sensato è classificare tutti i problemi identificati in base a due parametri:
- quanto è facile risolvere questo problema
- quanto grande è il rischio che comporta
Prima di tutto, è necessario risolvere ciò che attualmente degrada il livello di servizio fornito sotto la soglia accettabile, ad esempio, problemi causanti perdita di pacchetti. Poi, correggi ciò che è più facile e più sicuro correggere in ordine di gravità del rischio (da problemi di design o configurazione che comportano rischi elevati a minori).
Il perfezionismo in questa fase può essere dannoso. Porta il design a uno stato soddisfacente e sincronizza la configurazione della rete in base ad esso.
Fonte: habr.com
