Quante VLAN sono troppo poche e troppe?


23

Attualmente stiamo eseguendo una rete di oltre 800 PC e 20+ server, l'infrastruttura di rete è sulla linea di Core Switch 10Gb-> Area Switch 2GB-> Local Switch 1GB-> Desktop. Tutte le apparecchiature 3Com in esecuzione (1).

Abbiamo 3 interruttori di area per quattro aree (A, B, C, D si fondono con il core), ogni interruttore di area avrà tra 10 e 20 interruttori locali collegati a questi. C'è anche un interruttore principale di backup, meno alimentato ma collegato come l'interruttore principale principale.

Abbiamo anche un sistema telefonico IP. I computer / server e gli swicthes sono su un intervallo ip 10.x, i telefoni su un intervallo 192.168.x. I computer in genere non devono parlare tra loro tranne che nei laboratori informatici, ma devono essere in grado di parlare con la maggior parte dei nostri server (AD, DNS, Exchange, archiviazione dei file, ecc.)

Al momento dell'installazione, è stato deciso di disporre di 3 VLAN, una per switch e computer, una per i telefoni e una per la replica dei server (contrariamente ai consigli degli ingegneri di 3Com). La rete è stata stabile e funzionante da questo punto (2), ma ora abbiamo iniziato a passare all'ambiente SAN e alla virtualizzazione. Ora è sensato suddividere questa nuova infrastruttura in VLAN separate e rivedere il modo in cui i nostri VLAN sono configurati sembra ragionevole.

Viene ora proposto che le VLAN debbano essere configurate stanza per stanza, ovvero un laboratorio informatico con 5+ PC dovrebbe essere la propria VLAN, ma se seguiamo questo modello vedremo almeno 25 "nuovi" VLAN , oltre ai VLANS per server SAN / Virtual. Il che mi sembra aggiungerà una quantità eccessiva di amministrazione, anche se sono felice di essere smentito.

Quali sarebbero le migliori pratiche che sembrano suggerire? Esiste un certo numero di PC che è consigliabile non andare sopra / sotto in una VLAN.

(1) Gli switch 3Com (3870 e 8800) instradano tra le VLAN in modo diverso da come lo fanno alcuni altri, non richiede un router separato in quanto sono layer3.

(2) A volte otteniamo alte percentuali di scarto, o modifiche STP, e al momento 3Com Network Director riporta che gli switch sono sottocarichi e rallentano per rispondere ai ping, o che uno switch fallito riesce a smantellare la rete (tutti i VLANS per telefono e computer! , una volta, non ho idea del perché)

Risposte:


36

Sembra che qualcuno nella tua organizzazione voglia creare VLAN senza capire i motivi per cui lo faresti e i pro / contro ad esso associati. Sembra che tu debba fare delle misurazioni e trovare alcune vere ragioni per farlo prima di andare avanti, almeno con la folle "VLAN per una stanza".

Non dovresti iniziare a suddividere una LAN Ethernet in VLAN a meno che tu non abbia buoni motivi per farlo. I due motivi migliori sono:

  • Mitigare i problemi di prestazioni. Le LAN Ethernet non possono ridimensionarsi indefinitamente. Trasmissioni eccessive o allagamenti di frame verso destinazioni sconosciute limiteranno la loro portata. Ognuna di queste condizioni può essere causata dal rendere un singolo dominio di trasmissione in una LAN Ethernet troppo grande. Il traffico di trasmissione è facile da capire, ma l'inondazione di frame verso destinazioni sconosciute è un po 'più oscuro ( tanto che nessuno degli altri poster qui lo menziona nemmeno!). Se ottieni così tanti dispositivi che le tue tabelle MAC dello switch sono straripanti, gli switch saranno costretti a inondare i frame non broadcast fuori da tutte le porte se la destinazione del frame non corrisponde ad alcuna voce nella tabella MAC. Se si dispone di un dominio di trasmissione singolo sufficientemente grande in una LAN Ethernet con un profilo di traffico che ospita gli host che parlano di rado (ovvero, abbastanza raramente che le loro voci sono invecchiate rispetto alle tabelle MAC sugli switch), è anche possibile ottenere un inondazione eccessiva di frame .

  • Il desiderio di limitare / controllare il traffico in movimento tra host a livello 3 o superiore. Puoi fare un po 'di hacking esaminando il traffico al livello 2 (ala Linux ebtables) ma questo è difficile da gestire (perché le regole sono legate agli indirizzi MAC e cambiare le schede di rete richiede modifiche alle regole) può causare comportamenti che sembrano davvero strani il proxy trasparente dell'HTTP al livello 2, ad esempio, è strano e divertente, ma è assolutamente non naturale e può essere molto intuitivo per la risoluzione dei problemi), ed è generalmente difficile da eseguire ai livelli inferiori (perché gli strumenti del livello 2 sono come stick e rocce nel gestire le preoccupazioni di livello 3+). Se si desidera controllare il traffico IP (o TCP, o UDP, ecc.) Tra host, anziché attaccare il problema al livello 2, è necessario eseguire la sottorete e attaccare firewall / router con ACL tra le sottoreti.

I problemi di esaurimento della larghezza di banda (a meno che non siano causati da pacchetti di trasmissione o inondazioni di frame) in genere non vengono risolti con le VLAN. Si verificano a causa della mancanza di connettività fisica (troppe NIC su un server, troppe porte in un gruppo di aggregazione, necessità di passare a una velocità della porta più veloce) e non possono essere risolte subnet o distribuzione di VLAN da quando ha vinto aumenta la quantità di larghezza di banda disponibile.

Se non hai nemmeno qualcosa di semplice come MRTG che esegue la rappresentazione grafica delle statistiche del traffico per porta sui tuoi switch, questo è davvero il tuo primo ordine di attività prima di iniziare a introdurre potenziali colli di bottiglia con segmentazione VLAN ben intenzionata ma non informata. Il conteggio dei byte non elaborati è un buon inizio, ma dovresti seguirlo con uno sniffing mirato per ottenere maggiori dettagli sui profili di traffico.

Una volta che sai come si sposta il traffico sulla tua LAN, puoi iniziare a pensare di segmentare la LAN per motivi di prestazioni.

Se hai davvero intenzione di provare a abbattere i pacchetti e l'accesso a livello di flusso tra le VLAN, preparati a fare un sacco di legwork con il software applicativo e apprendere / retroingegnerizzare il modo in cui dialoga sul filo. La limitazione dell'accesso degli host ai server può essere spesso ottenuta con la funzionalità di filtro sui server. Limitare l'accesso sul filo può fornire un falso senso di sicurezza e gli amministratori indolenti in un compiacimento in cui pensano "Beh, non ho bisogno di configurare l'app. In modo sicuro perché gli host che possono parlare con l'app sono limitati da" Rete'." Ti incoraggio a controllare la sicurezza della configurazione del tuo server prima di iniziare a limitare la comunicazione da host a host sulla rete.

In genere si creano VLAN in Ethernet e si mappano le sottoreti IP da 1 a 1 su di esse. Avrai bisogno di MOLTE subnet IP per ciò che stai descrivendo e potenzialmente molte voci della tabella di routing. Pianifica meglio quelle sottoreti con VLSM per riassumere le voci della tabella di routing, eh?

(Sì, sì-- ci sono modi per non utilizzare una sottorete separata per ogni VLAN, ma attaccando un mondo strettamente "semplice vaniglia" si creerebbe una VLAN, si pensi a una sottorete IP da usare nella VLAN, si assegnano alcuni router un indirizzo IP in quella VLAN, collegare quel router alla VLAN, con un'interfaccia fisica o un'interfaccia virtuale virtuale sul router, connettere alcuni host alla VLAN e assegnare loro gli indirizzi IP nella sottorete definita e instradare il loro traffico e fuori dalla VLAN.)


2
Questa è una spiegazione eccellente. Aggiungo solo che, con la maggior parte dell'hardware moderno, la segmentazione non è così complicata fintanto che ti rendi conto che le VLAN dovranno essere instradate tra. Non ti gioverà molto avere una configurazione VLAN super efficiente che utilizza un router pesantemente sovrastampato su uno stick per passare il traffico tra i segmenti.
Greeblesnort,

2

Le VLAN sono davvero utili solo per limitare il traffico di trasmissione. Se qualcosa sta per fare molte trasmissioni, poi separalo nella sua VLAN, altrimenti non mi preoccuperei. Potresti voler avere una duplicazione virtualizzata di un sistema live sulla stessa rete e utilizzare lo stesso intervallo di indirizzi, quindi, che potrebbe valere una VLAN separata.


Al momento stiamo eseguendo XP senza WINS - fare un nbtstat -r sembra suggerire che stiamo ricevendo una quantità di traffico di trasmissione.
Vasche

1
Misuralo con qualcosa come Wireshark e vedi cosa sta succedendo. VINCE non è una cosa orribile. Se riscontri che stai ricevendo molte richieste di ricerca di nomi NetBIOS, prova a ottenere i nomi giusti in DNS per impedire le richieste o semplicemente eseguire WINS.
Evan Anderson,

2

Le VLAN sono buone come livello di sicurezza aggiuntivo. Non so come 3Com lo gestisca, ma di solito è possibile segmentare diversi gruppi funzionali in diverse VLAN (ad es. Contabilità, WLAN, ecc.). È quindi possibile controllare chi ha accesso a una particolare VLAN.

Non credo che ci siano perdite di prestazioni significative se ci sono molti computer nella stessa VLAN. Trovo poco pratico segmentare la LAN in una stanza in base alla stanza, ma ancora una volta, non so come 3Com la gestisca. Di solito la linea guida non è la dimensione, ma piuttosto la sicurezza o il funzionamento.

In effetti non vedo alcun motivo per segmentare anche la LAN in VLAN diverse se non ci sono guadagni di sicurezza o operativi.


1

A meno che non si disponga di 25 gruppi di test e sviluppo che uccidono regolarmente la rete con inondazioni di trasmissione, 25 VLAN per camera sono 24 in numero eccessivo.

Ovviamente la tua SAN ha bisogno della propria VLAN e non della stessa VLAN dei sistemi virtuali LAN e accesso a Internet! Tutto ciò può essere fatto attraverso un'unica porta Ethernet sul sistema host, quindi non preoccuparti della divisione di tali funzioni.

Se si verificano cali di prestazioni, considerare di mettere il telefono e la SAN su un hardware di rete separato, non solo su VLAN.


0

Ci sarà sempre traffico di trasmissione, che si tratti di trasmissioni di risoluzione dei nomi, trasmissioni ARP, ecc. L'importante è monitorare la quantità di traffico di trasmissione. Se supera il 3 - 5% del traffico totale, allora è un problema.

Le VLAN sono utili per ridurre le dimensioni dei domini di trasmissione (come ha affermato David) o per motivi di sicurezza o per creare reti di backup dedicate. Non sono realmente intesi come domini "gestionali". Inoltre, aggiungerai complessità di routing e sovraccarico alla tua rete implementando VLAN.


Ero con te fino a quando non hai menzionato il routing ambientale. Ci sono costi per l'instradamento, ma in genere l'hardware che esegue L2 / L3 inoltra i pacchetti da un vlan all'altro (e da una porta all'altra) alle stesse velocità come se si stesse inoltrando via L2.
chris,

È vero, non ho colto la parte nel post originale sugli switch 3COM in grado di instradare il traffico tra le VLAN senza la necessità di router (quindi suppongo che siano switch L3). Grazie.
joeqwerty,

Possono funzionare alla velocità del filo, ma sono comunque router da configurare e gestire, anche se sono solo entità di livello 3 all'interno degli switch. Se "cambiano" i pacchetti al livello 3 sono router.
Evan Anderson,

0

In generale, si desidera prendere in considerazione l'uso delle VLAN solo quando è necessario mettere in quarantena i dispositivi (come un'area in cui gli utenti possono portare i propri laptop o quando si dispone di un'infrastruttura server critica che deve essere protetta) o se il dominio di trasmissione è troppo alto.

I domini di trasmissione in genere possono avere una dimensione di circa 1000 dispositivi prima di iniziare a vedere problemi su reti a 100 Mbit, anche se lo farei scendere a 250 dispositivi se hai a che fare con aree Windows relativamente rumorose.

Per la maggior parte, le reti moderne non hanno bisogno di VLAN a meno che tu non stia eseguendo questa quarantena (con il firewalling appropriato utilizzando ACL, ovviamente) o la limitazione della trasmissione.


1
Sono utili per impedire alla pepita in contabilità di impostare una webcam con l'IP del server di posta ...
chris

0

Sono anche utili per prevenire le trasmissioni DHCP per raggiungere dispositivi di rete indesiderati.


1
Mitigazione dei problemi di prestazioni è già stata menzionata, grazie.
Chris S,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.