Quando / perché avviare la subnet di una rete?

In quali condizioni si inizia a considerare la subnet di una rete?

Sto cercando alcune regole empiriche generali o trigger basati su metriche misurabili che rendono la subnet qualcosa da considerare.

Domanda interessante

Storicamente, prima dell'avvento di reti completamente commutate, la considerazione principale per spezzare una rete in sottoreti riguardava la limitazione del numero di nodi in un singolo dominio di collisione. Cioè, se avessi troppi nodi, le prestazioni della tua rete raggiungerebbero un picco e alla fine crollerebbero sotto carico pesante a causa di collisioni eccessive. Il numero esatto di nodi che potevano essere distribuiti dipendeva da molti fattori, ma in generale non si poteva caricare regolarmente il dominio di collisione molto oltre il 50% della larghezza di banda totale disponibile e mantenere la rete sempre stabile. 50 nodi sulla rete erano molti nodi a quei tempi. Con utenti di uso intensivo, potresti aver superato 20 o 30 nodi prima di dover iniziare la sottorete.

Naturalmente, con le subnet full-duplex completamente commutate, le collisioni non sono più un problema e supponendo gli utenti di tipo desktop tipico, in genere è possibile distribuire centinaia di nodi in una singola sottorete senza alcun problema. Avere un sacco di traffico di trasmissione, come hanno accennato altre risposte, potrebbe essere un problema a seconda dei protocolli / applicazioni in esecuzione sulla rete. Tuttavia, tieni presente che la sottorete di una rete non ti aiuta necessariamente a risolvere i problemi relativi al traffico di trasmissione. Molti protocolli utilizzano la trasmissione per un motivo, ovvero quando tutti i nodi della rete devono effettivamente vedere tale traffico per implementare le funzionalità a livello di applicazione desiderate. La semplice sottorete della rete in realtà non ti compra nulla se anche il pacchetto trasmesso dovrà essere inoltrato all'altra sottorete e nuovamente trasmesso.

In generale, oggi, le ragioni principali delle sottoreti sono molto più legate a considerazioni sui confini organizzativi, amministrativi e di sicurezza che a qualsiasi altra cosa.

La domanda originale richiede metriche misurabili che innescano considerazioni sulle subnet. Non sono sicuro che ce ne siano in termini di numeri specifici. Questo dipenderà in modo drammatico dalle "applicazioni" coinvolte e non credo che ci siano davvero punti trigger che si applicherebbero in generale.

Relativo alle regole del pollice nella pianificazione di sottoreti:

• Prendi in considerazione le sottoreti per i diversi dipartimenti / divisioni organizzativi, soprattutto perché possono avere dimensioni non banali (oltre 50 nodi !?).
• Prendi in considerazione le subnet per gruppi di nodi / utenti che utilizzano un set di applicazioni comune distinto da altri utenti o tipi di nodo (sviluppatori, dispositivi VoIP, produzione)
• Prendi in considerazione le sottoreti per gruppi di utenti con requisiti di sicurezza diversi (protezione del reparto contabilità, protezione del Wifi)
• Prendi in considerazione le sottoreti da un'epidemia di virus, una violazione della sicurezza e una prospettiva di contenimento dei danni. Quanti nodi vengono scoperti / violati: qual è un livello di esposizione accettabile per la tua organizzazione? Questa considerazione presuppone regole di routing restrittive (firewall) tra le sottoreti.

Detto questo, l'aggiunta di sottoreti aggiunge un certo livello di sovraccarico amministrativo e potenzialmente causa problemi relativi all'esaurimento degli indirizzi dei nodi in una sottorete e alla presenza di troppi in un altro pool, ecc. Le configurazioni di routing e firewall e il posizionamento di server comuni nel rete e simili diventano più coinvolti, quel genere di cose. Certamente, ogni sottorete dovrebbe avere una ragione di esistenza che superi il sovraccarico di mantenere la topologia logica più sofisticata.

Se si tratta di un singolo sito, non preoccuparti a meno che tu non abbia più di una dozzina di sistemi e anche allora probabilmente non è necessario.

In questi giorni con tutti che utilizzano almeno 100 Mbps switch e più spesso 1 Gbps, l'unico motivo legato alle prestazioni per segmentare la tua rete è se stai subendo un traffico di trasmissione in eccesso (cioè> 2%, in cima alla mia testa)

L'altro motivo principale è la sicurezza, ovvero DMZ per i server pubblici, un'altra sottorete per la finanza o una VLAN / sottorete separata per i sistemi VoIP.

Limitare l'ambito per qualsiasi requisito di conformità che potresti avere (ad es. PCI) è un ottimo catalizzatore per segmentare alcune parti della tua rete. La segmentazione dei sistemi di accettazione / elaborazione dei pagamenti e di finanziamento può far risparmiare denaro. Ma in generale la sottorete di una piccola rete non ti farà guadagnare molto in termini di prestazioni.

Un altro motivo sarebbe legato alla qualità del servizio. Eseguiamo i furgoni voce e dati separatamente in modo da poter applicare facilmente QoS al traffico voip.

Sai, ho pensato di più a questa domanda. Esistono molte buone ragioni per progettare una nuova rete usando reti distinte (prestazioni, sicurezza, QoS, limitazione degli ambiti DHCP, limitazione del traffico di trasmissione (che può essere sia correlato alla sicurezza che alle prestazioni)).

Ma quando penso a una metrica per la riprogettazione solo per la sottorete e quando penso alle reti che ho dovuto gestire in passato, tutto ciò a cui riesco a pensare è "wow, dovrei avere una rete davvero incasinata per farmi riprogettare completamente per sottoreti ". Ci sono molte altre ragioni - larghezza di banda, utilizzo della cpu dei dispositivi installati, ecc. Ma il sottotenarsi su una pura rete di dati normalmente non comporterebbe un sacco di prestazioni

Sicurezza e qualità per lo più (purché il segmento di rete in questione possa ovviamente supportare i nodi in questione). Una rete separata per il traffico di stampanti, voce / telefono, reparti isolati come IT Ops e, naturalmente, segmenti di server, segmenti di connessione a Internet (uno per servizio di connessione a Internet è popolare oggi, non solo "un dmz farà") e così via.

Se ti aspetti di ampliare (stai costruendo una rete, non solo 5 server e questo lo faremo) inizia il routing il più presto possibile. Troppe reti sono instabili e difficili da coltivare perché sono cresciute organicamente e hanno troppe cose di livello 2.

Esempi:

• hai due server dei nomi sullo stesso segmento di rete. Ora non puoi spostarne uno in un'altra città, perché dovrai dividere quel simpatico / 24 o rinumerare il DNS. Molto più facile se fossero su reti diverse. Non sto parlando necessariamente di come diventare annunci BGP separati per il mondo. Questo esempio sarebbe per un ISP nazionale. Si noti inoltre che alcune cose nell'area del fornitore di servizi non sono facili come "basta registrare il nuovo DNS presso il registrar".
• Gli anelli di livello 2 succhiano il culo. Come spanning tree (e VTP). Quando lo spanning tree fallisce (e ci sono molti casi in cui lo fa), eliminerà tutto a causa dell'inondazione che prende la CPU switch / router. Quando OSPF o IS-IS falliscono (o altri protocolli di routing) non si arresta in modo anomalo sull'intera rete e puoi riparare un segmento alla volta. Isolamento dei guasti.

Quindi in breve: quando si scala fino a dove pensi di aver bisogno di spanning tree, ti preghiamo di considerare invece il routing.

Personalmente, mi piace portare la segmentazione di livello 3 il più vicino possibile agli switch di accesso, perché

• Non mi piace Spanning Tree (puoi farlo fare cose molto divertenti se sei cattivo)
• Soprattutto sulle reti Windoze, le trasmissioni sono un vero problema.
• Sulle reti private, hai molto spazio IP da perdere :)
• Anche gli switch più economici dispongono ormai di funzionalità di routing wire-speed: perché non utilizzarli?
• Semplifica la vita quando si tratta di sicurezza (ad es. Auth e ACL sull'egde, ecc.)
• Migliori possibilità di QoS per VoIP e roba in tempo reale
• Puoi dire la posizione di un client dal suo IP

Se si tratta di reti di diffusione più grandi / più ampie in cui due switch / router non sono sufficienti, i normali meccanismi di ridondanza come VRRP presentano numerosi inconvenienti (il traffico passa più volte verso l'alto, ...) OSPF non ha.

Probabilmente ci sono molte altre ragioni per supportare l' approccio use-small-broadcast-domains .

Penso che l'ambito dell'organizzazione sia molto importante. Se ci sono 200 host in totale o meno su una rete e il traffico non ha bisogno di essere segmentato per qualsiasi motivo, perché aggiungere la complessità di VLAN e sottoreti? Ma più ampio è il campo di applicazione, più potrebbe avere senso.

Suddividere le reti che normalmente non avrebbero bisogno di essere può rendere alcune cose più semplici. Ad esempio, le nostre PDU che forniscono energia ai server si trovano nella stessa VLAN o sottorete dei server. Ciò significa che il nostro sistema di scansione delle vulnerabilità utilizzato sulla nostra gamma di server esegue anche la scansione delle PDU. Non è un grosso problema, ma non abbiamo bisogno di scansionare PDU. Inoltre sarebbe bello DHCP DHCP le PDU poiché sono una configurazione difficile, ma dato che si trovano nella stessa VLAN dei server in questo momento, non è molto fattibile.

Anche se non abbiamo bisogno di un'altra VLAN per le PDU, può semplificare alcune cose. E questo entra nell'argomento più o meno VLAN che continuerà per sempre.

Io penso solo di avere VLAN dove ha senso. Se per esempio abbiamo dato alle PDU la propria VLAN, ciò non significa che dobbiamo sempre dare a piccoli gruppi di dispositivi la propria VLAN. Ma piuttosto in questo caso potrebbe avere senso. Se un gruppo di dispositivi non ha bisogno di avere la propria VLAN e non ci sono vantaggi nel farlo, allora potresti prendere in considerazione l'idea di lasciare le cose come sono.