Newsgroup: it.comp.reti.cisco
Titolo: VLAN trunking tra 2960 e 3750

A me le vlan proprio non entrano in testa.
Sto cercando di far dialogare la VLAN 1104 da un
server A ad un server B, con in mezzo un 2960 ed un 3750
server A -> 3750 -> 2960 -> server B
Ho configurato la porta 12 del 2960 in access associandola alla vlan
1104:
int Fa0/12
Switchport mode access
switchport access vlan 1104
Ho configurato la porta giga del 2960 in trunking 802.1q:
int Gi0/1
Switchport mode trunk
Switchport trunk encapsulation dot1q
Stessa cosa sulla porta 1 del 3750 (che connette la porta 12 del 2960):
int Gi1/0/1
Switchport mode trunk
Switchport trunk encapsulation dot1q
Infine la porta 24, che connette il 3750 al server A, l'ho messa sempre
in trunking, perchè su tale server devo veicolare più di una vlan:
int Gi1/0/24
Switchport mode trunk
Switchport trunk encapsulation dot1q
Nonostante ciò, i due apparati non si pingano.
Ho saltato qualche passaggio?
Il VTP deve essere attivato obbligatoriamente?

 Il VTP deve essere attivato obbligatoriamente?
No. Peraltro non funzionerebbe con le VLAN > 1000
Deve essere definita la vlan su entrambi.
Quindi 2960:
vlan 1104
 name pippo
int Fa0/12
 switchport mode access
 switchport access vlan 1104
int Gi0/1
 switchport mode trunk
 switchport trunk encapsulation dot1q
Sul 3750
vlan 1104
 name pippo
int Gi1/0/1
 switchport mode trunk
 switchport trunk encapsulation dot1q
int Gi1/0/24
 switchport mode trunk
 switchport trunk encapsulation dot1q
ovviamente le macchine attaccate così:
                       +----+----+
+----------+    Fa0/12 |         |
| Server 1 +-----------+ SW 2960 +
+----------+           |         |
                       |         |
                       +----+----+
                       G0/1 |
                            |
                            |
                     G1/0/1 |
                       +----+----+
                       |         |
+----------+   F1/0/24 |         |
| Server 2 +-----------+ SW 3750 +
+----------+           |         |
                       +----+----+
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

                        +----+----+
si solo che invece di avere F1/0/24 ho Giga ma
non cambia niente.
a livello di server 2 ho configurato la vlan come
nativa:
vconfig add eth1 1104
ed accedo, ovviamente, come eth1.1104
può dar problemi? (a dire il vero, c'è vyatta, ma
il comando che esegue è quello)

 vconfig add eth1 1104
Così non è nativa, è taggata.


vlanid in autonomo...
Errore, le vlan debbono essere definite su tutti gli switch del percorso 
anche se non hanno porte assegnate.
In realtà le devi creare manualmente solo sugli switch che non hanno porte 
assegnate, visto che sugli altri vengono create automaticamente.
Oppure usi il vtp.
Ciao,
         Tosh. 

 Oppure usi il vtp.
Non posso, ho letto che i VID sopra il 1000 non son supportati.
Piuttosto, su cisco si può usare GVRP ? Come si attiva?

 Così non è nativa, è taggata.
si, è la stanchezza serale, scrivo cose mentre ne penso altre.
Io ho un server con sopra X vlan, una delle quali è la 1104.
La porta a cui è connesso il server è in trunk, quindi sul server
dovrebbero arrivarmi tutte le VLAN che transitano per lo switch 
(o quantomeno le vlan configurate come "trunkabili", scusate il termine)
Temo che allora il problema sia proprio nel 3750, dove non ho definito
la VLAN 1104 (tant'è che show vlan non me la indica, giustamente).
Tra poco provo a definirla anche li, vediamo che succede.
Il problema è che non ho internet finchè non sistemo tutto il routing
pertanto faccio anche fatica a googolare e provare sul campo se non
tramite cellulare.

 assegnate, visto che sugli altri vengono create automaticamente.
Questo articolo non è del tuo stesso parere:
http://www.formortals.com/implementing-vlan-trunking/
configura una porta del router settandola nella VLAN
10, poi su uno switch configura solo il trunk indicando quali
porte far transitare, ma non vi crea la VLAN.

 a prima vista sembra illogico, avendo le porte in trunk?
Spiegazione tecnica non saprei, ma a me non pare affatto strano che lo
switch butti in /dev/null tutto il traffico appartenente a VLAN non
definite...
(e cmq, confermo che sì: AFAIR lo butta in /dev/null)
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 (e cmq, confermo che sì: AFAIR lo butta in /dev/null)
Ok, dopo provo.

 via le vlan non settate su se stesso?
Per la stessa ragione per cui esiste il pruning: se uno switch non deve
gestire una data VLAN, fargli riemettere tutto il traffico di quella
VLAN su tutti i trunk serve solamente a propagare traffico inutile.
Se una VLAN la deve gestire, gliela crei. Se no, no.
Non mi pare una tragedia...


 le vlan sul server
ma scusa allora non devi metterle in trunk sulla porta dove il server è 
attaccato, ossia la gigabit la metti in trunk la fastethernet la metti 
in access definendo le vlan accessibili
a memoria è:
switch 2960
intf fa0/12
switchport mode access
switchport access vlan 1104
intf gi0/1
switchport mode trunk
switchport trunk encapsulation dot1q
switch 3750
intf Gi0/1
switchport mode trunk
switchport trunk encapsulation dot1q
intf fa0/24
switchport mode access
switchport access vlan 1104,n,y,p (con n,y e p altri id di altre vlan 
che vuoi far arrivare al server)

 Non mi pare una tragedia...
Nessuna tragedia, è solo per cercare di capire come funziona.
Comunque, ho notato un altro apparentemente strano comportamento:
se creo un portchannel con LACP
(vado a memoria con i comandi)
int fa0/1
  channel-protocol lacp
  channel-group 1 mode active
int fa0/2
  channel-protocol lacp
  channel-group 1 mode active
se le interfacce sottostanti non sono configurate in
maniera identica su ambo i lati, il portchannel non si
attiva.
Devo obbligatoriamente assegnare le stesse vlan in trunk
su tutte e 4 le porte sottostanti (2 per lato) altrimenti
la porta viene ignorata.
Che senso hanno le vlan con il portchannel? E sopratutto,
perchè devo configurare le porte sottostanti e non il
solo portchannel?

 che vuoi far arrivare al server)
E' appunto questo che mi chiedo:
perchè se faccio un trunk configurato per far veicolare tutte le vlan
devo obbligatoriamente anche configurare ogni singola vlan sullo switch?
Tanto vale mettere la porta in access su più vlan, il risultato
dovrebbe essere lo stesso.
fare
switchport access vlan 1104,1105,1106
dovrebbe aver lo stesso signifiato di
switchport trunk allow vlan 1104,1105,1106

 Nessuna tragedia, è solo per cercare di capire come funziona.
ad onor del vero, non tutti gli switch droppano di default. molti la 
porta in tagging la lasciano passare anche se la vlanid non è definita.


imho no, un "trunk" nella mia testa si configura come un tunnel dove far 
passare tutto per distribuire, un "access" me lo figuro come una porta 
di un patch panel etichettato con l'id della vlan
quindi quando devi trasportare tutte le vlan da uno switch all'altro usi 
il tunnel (il trunk) se devi usare una vlan attacchi il cavo al patch 
(ossia metti in access)
mi pare infatti di ricordare che quando ho voluto che tutti i client 
attaccati ad uno switch stessero su una sola vlan ho messo in access 
direttamente la gigabit dello switch dove i client erano


vado a memoria anche io ma mi pare che quest'operazione l'ho fatta sull 
interfaccia "virtuale" che viene a crearsi col port channel (intf 
Port-channel1)
ad esempio questa è la mia
interface Port-channel1
  description EthChannel con porte 1/1 e 1/2
  switchport
  switchport trunk encapsulation dot1q
  switchport trunk allowed vlan 1,x,y,w,z
  switchport mode trunk

 porta in tagging la lasciano passare anche se la vlanid non è definita.
AFAIK, tutti i procurve.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

  switchport mode trunk
Si, ho fatto anche io lo stesso.
Però ci son due cose che non mi son chiare (io sono abituato con
i procurve, qui in cisco è tutto molto più incasinato):
1) come mai se le due porte che formano l'aggregato non sono identiche,
non vengono inserite nel channel? Ovvero, una porta in trunk e l'altra 
no, oppure due configurazioni trunk differenti. A logica, dovrebbe
sbattersene
2) perchè se anche dall'altra parte del cavo le porte che formano 
l'aggregato non sono identiche (stessa spiegazione del punto 1) non
possono entrare a far parte del channel ed il channel non va su? Mi
resta fisso in shutdown.
Miseriaccia, ma un
   int e 1-2 lacp active
come sui procurve no?


 come sui procurve no?
No, altrimenti non sarebbe Cisco. D'altronde non hai nemmeno tutti i limiti
che hai sui procurve (e qui mi sovvengono tutte le bestemmie contro i vecchi
4104 in cui non potevi attivare contemporaneamente trunking e routing).


 4104 in cui non potevi attivare contemporaneamente trunking e routing).
Era una battuta la mia........

 aggregato, con la stessa configurazione vlan?
scusa ma imho è corretto quello che fa cisco...
se tu vuoi mettere due porte aggregate in modo che formino un unico 
canale devono per forza essere identiche.
in caso contrario (restringendo l'esempio alle vlan) o ti dovrebbe fare 
un merge delle vlan delle due (o più) porte che tu vai ad aggregare, o 
te le resetta e le riconfiguri daccapo sul portchannel o ti fa un diff e 
si tiene solo quelle uguali.
altrimenti se tu invii un pacchetto sulla vlan 10 che fosse presente 
solo su una delle porte dell'aggregazione, il pacchetto transiterebbe 
sempre e solo per quell'unica porta che avrebbe la vlan 10...in questo 
caso che senso avrebbe l'aggregazione?
come dire...unire pere con pere va bene...è mela con pera che esce fuori 
una roba strana

 caso che senso avrebbe l'aggregazione?
E no, io il pacchetto lo invio sul channel, le vlan sottostanti le
dovrebbe ignorare. Se voglio usare le vlan le devo riconfigurare sul
channel indipendentemente dalla loro presenza nelle singole porte.
Se ad esempio, sulla porta 1 avessi vlan 100 e 200 mentre sulla porta
2 avessi vlan 300 e 400, imho potrebbe anche creare ugualmente
l'aggregato ignorando le vlan sottostanti. se mi va, ricreo le vlan
100-400 direttamente sul channel.
questo perchè se è presente un channel, i pacchetti dovrebbero
transitare tramite di lui, ignorando la porta sottostante se non
per un mero discorso fisico.
Altrimenti secondo il tuo ragionamento, anche STP e quant'altro
sarebbe soggetto alle singole porte, invece è soggetto al solo channel.
l'albero vien calcolato in base all'aggregato e non alle singole porte.


quindi pretenderesti che nel caso facesse lui il "reset" automatico 
delle vlan applicate alle porte che tu decidi andranno a formare il port 
channel...
mah...sostanzialmente alla fine non cambia nulla....o le rimuovi tu (se 
non hai intenzione di usarle sul port channel) o vorresti (perchè non mi 
risulta lo faccia) che siano resettate automaticamente, alla fin fine 
però vedi che le porte in questione sono tutte uguali, o con le stesse 
vlan o con nessun, ma uguali

 l'albero vien calcolato in base all'aggregato e non alle singole porte.
Direi che il punto è un altro.
Il portchannel è una cosa che viene *contrattata* dai due capi dei link.
Che accade se la contrattazione *fallisce* e non c'è nessun portchannel?
Se le porte sono identiche (tra loro e con portchannel), il risultato è
che una delle due andrà in block per effetto di STP e si lavorerà con un
canale degradato in quanto a banda passante, ma con le stesse
funzionalità del portchannel, indipendentemente da quale porta resterà
in vita dopo l'intervento di STP.
Se le porte hanno configurazioni tra loro diverse, il risultato (in
termini di configurazione e funzionalità) dipenderà invece da quale
porta sopravvive all'intervento STP, in modo quantomeno poco prevedibile.
E -credimi- tu non *vuoi* questo...


 channel...
Non pretendo niente.
Mi interessava capire il ragionamento fatto dallo switch, ora lo so
e sono a posto.
Però, SECONDO ME, non dovrebbe nemmeno fare il reset, non le dovrebbe
cagare e basta, se creo un channel, a meno di qualche impostazione
particolare, lui dovrebbe considerare un channel come una nuova
interfaccia ignorando quel che ci sta sotto, vlan o non vlan.

 E -credimi- tu non *vuoi* questo...
Guarda, non mi sono spiegato.
Se io creo il port-channel composto da fa0/1 e fa0/2, non mi
deve interessare come sono le configurazioni di tali interfacce
(a L2 o superiore, non a L1 o caratteristiche hardware), perchè 
io userò il channel.
Lui dovrebbe sbattersene di tutto, creare il channel, ed istruire
i protocolli corrispondenti a vederlo come una singola porta, STP
compreso.
A livello STP io vedo l'aggregato, non le porte che lo compongono.
A livello di configurazione ip o vlan, gestisco l'intero aggregato
e solo se voglio, vado a smanettare con le porte singole, rendendo
però vana la configurazione del channel. (creo un channel per modificare
le singole porte? Qualche cosa non quadra, credo)
Per quale motivo per creare l'aggregato deve verificare la
configurazione delle vlan delle porte che ne faranno parte, quando
poi quelle porte, da un certo punto di vista, saranno candidamente
ignorate?
AFAIK se creo un aggregato, le porte che lo compongono non partecipano
al calcolo dello spanning tree, vi partecipa l'intero aggregato, stesso
discorso dovrebbe essere con le VLAN.

ignorate?
La risposta è molto semplice, non è per niente tecnica e l'ha più o meno 
anticipata skull....sai esiste il dtp, che aggrega automaticamente delle 
porte che collegano due switch tra di loro, bene, non è detto che quelle 
porte siano state attaccate volutamente, ma potrebbe essere stato un errore; 
se lo switch a fronte di questo errore ti cambia la configurazione di quello 
che passa tra i due switch potrebbe fare un casino che metà basta, se invece 
le porte sono configurate in modo identico non può fare altro che 
moltiplicare la banda senza nessun effetto collaterale.
Lo stesso dovrebbe più o meno valere a proposito del tuo dubbio amletico 
sulle vlan che non transitano automaticamente per i trunk, si tratta 
semplicemente di un modo per obbligarti ad avere un controllo su quello che 
passa per i tuoi switch, ihmo.
Questa è una delle tante differenze tra cisco e quasi tutti gli altri.
Ciao,
         Tosh. 

 deve interessare come sono le configurazioni di tali interfacce
[...]
No, credo che invece tu non abbia proprio letto la mia risposta.
Riprova ;-)


 Riprova ;-)
L'ho letta, ma Tosh è stato più esaustivo.... :)

 passa per i tuoi switch, ihmo.
Ok, ora mi è chiaro.

 e sono a posto.
il pretendi era inteso in senso benevolo "quindi tu 
pensi/vorresti/immagini" ;)