Newsgroup: it.comp.os.linux.sys
Titolo: Questione VLAN

In riferimento ad un mio post su icr.ip-admin avrei una semplice domanda (che pongo di qua perchè c'è molta più visibilità):
 
- conviene usare sempre delle VLAN dedicate al posto di quella nativa degli switch anche in caso di singola rete?
 
In teoria, si. A fronte di una leggermente più complessa configurazione iniziale dello switch (cambiare la vlan e forse mettere in access sulla nuova vlan tutte le porte, operazione che si fa con 2 comandi esatti) si dovrebbe avere molta più flessibilità ed in caso di cambi di topologia fisica (come ad esempio il dover collegare due switch in extremis) non ci sarebbe alcun problema a farlo ed una eventuale riconfigurazione si limiterebbe ad un cambio a livello software e non fisico.
 
In sostanza, conviene lasciar perdere la vlan nativa ed usare sempre quelle dedicate anche se inizialmente ne devo fare solo 1 ?

 quelle dedicate anche se inizialmente ne devo fare solo 1 ?
 
In linea di massima, sì. A meno che tu non abbia la certezza assoluta
che la rete non avrà mai bisogno di una seconda vlan (tipo -chessò- la
rete di casa tua).
 
(le ragioni sono di convenienza e flessibilità, ma anche di sicurezza...)
 

 (le ragioni sono di convenienza e flessibilità, ma anche di sicurezza...)
 
Si, esattamente i problemi che devo risolvere.
 
Se avessi lasciato perdere le vlan native a quest'ora non mi sarei ritrovato in questa buffa situazione.
 
Se una delle porte dovesse andare ad un computer fuori dalla mia gestione (internet point) e questo computer dovesse poter accedere a 3 VLAN (e solo quelle 3) la metto in trunk, con le 3 vlan in allowed e sono tutelato da potenziali hopping ?
Devo evitare che un malintenzionato possa cambiarsi la vlan sul proprio computer.
 
AFAIK, non usando la vlan nativa, buona parte degli hopping sono resi impossibili. I restanti si proteggono mettendo la porta in access su una vlan specifica o la porta in trunk forzato (quindi non negoziabile) con le vlan esplicitate. Altre casistiche ?

 negoziabile) con le vlan esplicitate. Altre casistiche ?
 
Direi che hai una buona panoramica :-P
 
 

 Direi che hai una buona panoramica :-P
 
Bene, allora vado ad inginocchiarmi sopra i ceci perchè se avessi usato la vlan sin da subito non mi sarei infilato in un casino da paura.

 
 
Descrivi casino :-P
 

 Descrivi casino :-P
 
bit.ly/10tM3tU
 

 routing non mi va bene, ho bisogno di unire gli apparati a L2.
 
Qui ammetto che m'è calato un velo di nebbia...

 problema lavorando solo su uno switch.
 
Assolutamente s�. Se lo switch ti consente di eseguire il comando su un
gruppo di porte contemporaneamente, nessuno si accorge nemmeno di nulla.
 
Solo, occhio a non tagliarti fuori dallo switch O:-)
 

 Solo, occhio a non tagliarti fuori dallo switch O:-)
 
Vado dritto in console con la seriale.
Quindi la soluzione è spostare tutte le porte attuali dalla vlan1 alla vlanX e poi operare come di consueto tramite trunking ed access, senza fare porcherie varie.

 consueto tramite trunking ed access, senza fare porcherie varie.
 
aye!
 

 Quindi la soluzione è spostare tutte le porte attuali dalla vlan1 alla vlanX e poi operare come di consueto tramite trunking ed access, senza fare porcherie varie.
 
Però, visto che c'è sempre un però, se segmento per vlan tralasciando quella nativa, avrò una vlan di management che utilizzerò io per l'accesso allo switch, più svariate vlan per i vari servizi. Se interrogo tramite snmp passando per una vlan ben precisa (che non è quella di management) riuscirò a vedere le statistiche di tutte le porte o solo della vlan in questione?
 
Perchè cogliendo la palla al balzo, ne approfitto per fare una vlan di monitoraggio separata da quella di management (dato che la vlan di monitoraggio è esposta ad internet e la management non voglio che lo sia), ma devo poter accedere alle statistiche di tutto lo switch, non solo della VLAN.

 Perchč cogliendo la palla al balzo, ne approfitto per fare una vlan di monitoraggio
 
 
 
Su switch "stupidi" non puoi distinguere su quale SVI (e non vlan, dato 
che stai parlando di un servizio L3) mettere in ascolto snmp; quello che 
puoi fare č definire ACL che permettano le query snmp solo ad un certo 
numero di ip sorgenti. Se la query č permessa, vedrai le statistiche di 
tutte le porte; la suddivisione in vlan non c'entra niente.
 
Per fare quello che vorresti fare te si serve un router o uno switch 
multi-layer di livello piů alto che gestisca le VRF e sul quale il 
servizio snmp sia vrf-aware.
 
Ciao,
A.

 servizio snmp sia vrf-aware.
 
Grazie.

 Quindi la soluzione è spostare tutte le porte attuali dalla vlan1 alla vlanX e poi operare come di consueto tramite trunking ed access, senza fare porcherie varie.
 
Dimenticavo un piccolissimo particolare: uno degli switch coinvolti è un Procurve. (per non parlare dell'SMC dall'altro lato mannaggia a me quando l'ho comprato. Maledetto giocattolo.)
*TUTTE* le volte (ma proprio tutte) che provo a configurare una porta in trunk (tagged) su un procurve si formano dei loop da paura e si stende la rete.
 
Tutte le volte.
 
La stessa configurazione fatta su un cisco
 
switchport mode trunk
switchport trunk allowed vlan 1,100
 
funziona perfettamente (ne ho a dozzine configurati in questo modo, tutti senza il minimo problema)
 
Considerato che STP "forse" gira sul procurve (e che da configurazione di default, STP è indipendente dalla vlan, se trova un loop sega tutta la porta) ed anche su tutto il resto della rete (dico forse, perchè la rete si è stesa allegramente dopo una manciata di secondi), cosa sto sbagliando?
 
Una delle macchine che ho provato a connettere nella porta in trunk sul procurve è un nodo Xen con una singola VLAN configurata. Anche in questo caso la configurazione che ho nella rete cisco è identica e funziona, se attacco il procurve si sdraia tutto quanto.
 
Sbaglio certamente qualcosa, ma non so cosa, anche perchè i problemi si sono protratti per un ora e mezza buona-buona anche dopo aver SPENTO l'intero switch (risolvendo di fatto i loop). Può essere che il loop abbia strascichi belli lunghi? I sintomi son semplici: latenza tra due server che attraversano lo switch di 30ms. Solitamente è il loop che fa così.

 Sbaglio certamente qualcosa, ma non so cosa, anche perchè i problemi si sono protratti per un ora e mezza buona-buona anche dopo aver SPENTO l'intero switch (risolvendo di fatto i loop). Può essere che il loop abbia strascichi belli lunghi? I sintomi son semplici: latenza tra due server che attraversano lo switch di 30ms. Solitamente è il loop che fa così.
 
Credo che il problema sia dato da:
 
a) PVTSTP+ in esecuzione sulla rete cisco e non supportato da HP
b) VLAN1 in comune su ambo le reti (ovviamente) connettendo le due reti, la VLAN1 forma un loop.
 
In teoria, però, l'stp sui cisco dovrebbe bloccarlo indipendentemente dal fatto che il procurve lo supporti o pure no.
 
Per ora ho risolto in altro modo, ma prima o poi dovrò interconnettere le due reti, dato che la management degli switch sarà una VLAN in comune ad ambo le reti. Sto seriamente pensando di mantenere due reti distinte e di conseguenza due vlan distinte (ad esempio la VLAN100 su ambo i segmenti che però non si parlano). Il concentratore di vpn (quello al quale mi collego io per accedere alla rete) sarà interconnesso ad entrambe le reti (eth0.100, eth1.100) ma essendo un router e non uno switch, non causa loop.

 *TUTTE* le volte (ma proprio tutte) che provo a configurare una porta in trunk (tagged) su un procurve si formano dei loop da paura e si stende la rete.
 
Se mi permetti l'intrusione, magari può esserti utile:
 
1) in molti modelli di Procurve (tipo i 25xx) lo spanning tree di 
default *non* è abilitato;
 
2) diversamente da Cisco, per HP trunk = aggregazione di link (con o 
senza 802.3ad), non ha a che fare con le vlan e spesso chi è 
Cisco-oriented cade nel tranello;
 
3) sui Procurve è fondamentale disabilitare/disconnettere le porte 
*prima* di configurarle in trunk, pena sbarellamenti imprevedibili.
 
Chiarite le differenze, si può convivere serenamente e trarre ottime 
soddisfazioni anche dai bistrattati Procurve :)
 
-- 
Bye
Gianfranco Bartolini
(gianfranco punto bartolini at tiscali punto it)

 soddisfazioni anche dai bistrattati Procurve :)
 
assolutamente, i procurve sono ottimi prodotti, seri e affidabili e non 
hanno da invidiare nulla anche ai gemelli piů costosi di altri marchi.

 In teoria, però, l'stp sui cisco dovrebbe bloccarlo indipendentemente dal fatto che il procurve lo supporti o pure no.
 
se puoi accedere al procurve dai un semplice "spanning-tree" e si 
abilita anche li.
 
poi con un show spanning-tree vedi lo stato amministrativo stp delle 
porte (block, discard, forward, etc..)
 
 
 

 soddisfazioni anche dai bistrattati Procurve :)
 
A me piacciono i procurve (ne ho 30), ma la situazione è leggermente 
più complessa. Devo far dialogare un PVRSTP+ Cisco con un *STP Procurve. 
Credo non ci sia modo.
 
Più che altro, so che è possibile limitare il traffico della VLAN1 in uscita dai trunk/porte_tagged TRANNE che per il traffico di controllo di alcuni protocolli. Il traffico di controllo, genera comunque dei loop?

 porte (block, discard, forward, etc..)
 
Tutte in forward (anche su tutti i cisco), ci avevo già guardato, per questo dico che l'STP fa a cazzotti con il PVRSTP+. O più semplicemente non c'è alcun loop ma la rete si è stesa comunque per 1 ora.

 Da quel che ho letto, i due protocolli non si parlano, se c'è un loop, il loop resta (non so come sia possibile, in teoria basta che l'stp sia attivo da un solo apparato coinvolto, e non su tutta la rete, per stroncarlo. Boh)
 
Beh, resta eccome. PVSTP opera a livello di VLAN, RSTP a livello di porta.
Se il PVSTP nota un loop dentro una VLAN, l'altro non lo sente, perchè tecnicamente la porta non è in loop ma lo è solo la VLAN.

 hanno da invidiare nulla anche ai gemelli pi� costosi di altri marchi.
 
Anche a me non dispiacciono i Procurve ma l'IOS � sempre l'IOS e per 
fare i dovuti paragoni bisogna partire almeno dai 2900 in su. Sotto sono 
ancora modelli troppo entry level.
 
E comunque metterei quelli che si lamentano dei Procurve a lavorare sui 
Nortel, vedi come si ricredono di corsa ;)


 Pi� che altro, so che � possibile limitare il traffico della VLAN1 in uscita dai trunk/porte_tagged TRANNE che per il traffico di controllo di alcuni protocolli. Il traffico di controllo, genera comunque dei loop?
 
A che traffico di controllo ti riferisci di preciso?


 l'ultimo posto sembra interessante
 
Aggiungo anche questi link che sembrano molto interessanti:
 
http://h30499.www3.hp.com/t5/Switches-Hubs-Modems-Legacy-ITRC/STP-Configuration-Between-Cisco-and-HP/td-p/4777642
 
 
http://www.techdata.com/techsolutions/networking/whitepapers/Feb10/HP%20Procurve%20Migrating%20from%20Cisco%20to%20ProCurve%20Networks.pdf
 


 A che traffico di controllo ti riferisci di preciso?
 
Vado a memoria: CDP, STP e simili.
Molti protocolli funzionano solo su VLAN1. Non chiedermi quali, non ho approfondito, ma si tratta di una manciata di protocolli.

 MSTP va configurato, devi creare una o pi� istanze e ad essere associare le rispettive VLAN.
 
Non entro nel merito della scelta del protocollo, le tue motivazioni 
sono pi� che giuste, ma se decidi di adottare un protocollo proprietario 
Cisco allora devi assicurarti di usare sempre e solo Cisco. E se un 
cliente ha HP o altro, prendi e gli metti un Cisco.
Altrimenti stiamo qui a parlare di nulla, � ovvio che appena esci dal 
recinto della casa madre avrai sempre problemi d'interoperabilit�.
 
I protocolli standard nascono proprio per evitare questi problemi, poi 
che sia pi� o meno complesso implementarli � un altro discorso. 
Personalmente cerco per quanto possibile di usarli, proprio perch� nel 
mondo reale � molto ma molto difficile non avere poi problemi di 
convivenza tra gli n produttori di hardware in commercio.


 convivenza tra gli n produttori di hardware in commercio.
 
Anche io. Ma in questo caso non vi è alternativa standardizzata. (ad esempio uso sempre .1q per le VLAN e LACP per i port-channel, mai i proprietari cisco)
 
Ma MSTP come già detto non mi aiuta, anzi, può solo peggiorare le cose.
L'unico modo sarebbe quello di creare una istanza MSTP per ciascuna VLAN, operazione *assurda* da fare su tutti gli switch di tutta la rete e che vanificherebbe i vantaggi di MSTP stesso rispetto alla controparte Cisco.
Sfido a dover gestire 100 istanze MSTP mono-vlan su circa 30 switch.

 Sfido a dover gestire 100 istanze MSTP mono-vlan su circa 30 switch.
 
Forse MVRP potrebbe aiutare... ma qui mi faccio da parte perch� non ho 
mai provato a far interagire prima MSTP e PVRSTP+. Anche se sarebbe un 
bell'esperimento da lab, quasi quasi rispolvero il mio vecchio Packet 
Tracer e provo a simulare qualche casino tra switch :)


 Tracer e provo a simulare qualche casino tra switch :)
 
Brrrr. Se non hai il controllo su tutte le VLAN (cosa che io non ho) questi automatismi è meglio lasciarli stare dove stanno.

 Brrrr. Se non hai il controllo su tutte le VLAN (cosa che io non ho) questi automatismi � meglio lasciarli stare dove stanno.
 
MVRP funziona bene. Resta da capire se � applicabile in questo contesto
