Newsgroup: it.comp.reti.ip-admin
Titolo: Problema con VLAN

Ho una situazione piuttosto ingarbugliata, con tecnici esterni
che fanno da scarica barile.
Io gestisco due firewall connessi ad due switch in gestione
ad altra azienda.
Così:
fw1 --> switch 1 --> fibra --> switch2 --> fw2
i firewall sono miei, switch e fibra di altri.
Ci dovrebbe essere una VLAN taggata su ambo gli switch e di
conseguenza sui firewall ho la vlan configurata:
# ip addr show eth0.100
29: eth0.100@eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
     link/ether 00:04:a7:15:ba:61 brd ff:ff:ff:ff:ff:ff
     inet 
10.100.0.1/24
 brd 10.100.0.255 scope global eth0.100
sul firewall 2 ho una cosa analoga ma con .2 di indirizzo.
Il problema è che non raggiungo nulla oltre il firewall 1, compreso
lo switch1 che mi han detto di essere configurato come 10.100.0.101
sulla vlan100
dicono di aver configurato la vlan 100 come tagged sulle porte 1 e 24
ed idem sullo switch 2, porte 1 e 24
La 1 è quella che guarda i due firewall, la 24 è quella in fibra.
Se pingo 10.100.0.101 dal firewall1 vedo, tramite tcpdump, delle
richieste ARP in uscita ma nulla in ingresso.
Anche ifconfig non segnala alcun traffico in ingresso, ma solo in uscita.
Il firewall è aperto:
iptables -I INPUT -s eth0.10 -j ACCEPT
iptables -I OUTPUT -j ACCEPT
Che probabilità ci sono che la colpa sia dei gestori dello switch
e non mia? Io non so che altro controllare, una volta settata la
vlan, sono a posto e vorrei aver conferma per andarci giù a muso duro.
Sulla stessa nic, in modalità untagged (quindi eth0) c'è del traffico
buono, il problema è solo sulla vlan.
Se fosse un problema di netfilter, a livello di tcpdump dovrei vedere
comunque delle risposte e sopratutto dovrei aver traffico in ingresso
segnalato da ifconfig, dico bene? Non avendo nulla in ingresso, vuol
dire che nulla risponde.
-- 
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.

 ingresso, vuol dire che nulla risponde.
hai modo di piazzare un paio di sniffers ai due estremi e vedere
cosa viene fuori ?

 cosa viene fuori ?
Sinceramente no, perchè il firewall2 è $lontano da dove sono io
e non riesco a raggiungerlo in maniera agevole, se sti beduini
non mi fan funzionare il link.
Ma non cambierebbe nulla, perchè io non riesco a pingare nemmeno
lo switch 1 connesso direttamente al firewall1, mentre il beduino
riesce a pingare, dallo switch1, un apparato connesso dall'altra
parte del link in fibra. Presumo, quindi, sia un problema tra
il firewall1 e lo switch1.


 il firewall1 e lo switch1.
IDEA !!! Fagli un ARP poisoning da strapparsi i capelli :) !!

 buono, il problema è solo sulla vlan.
questo è molto strano (salvo che non sia stato esplicitamente 
richiesto). Personalmente evito di far passare traffico untagged su 
porte tagged, per una semplice motivazione di "pulizia di 
configurazione". Faccio girare tutto tagged e stop.
Addirittura alcuni switch (in realtà pochi) non consentono nemmeno le 
modalità ibride, ma se si dichiara la porta "uplink", quella porta 
accetterà SOLO traffico tagged e scarterà tutto il resto.

 accetterà SOLO traffico tagged e scarterà tutto il resto.
A me invece fa il contrario, accetta solo le untagged ed ignora la
100tag.


 iptables -I OUTPUT -j ACCEPT
perchè non l'if eth0.100?
Daniele

 perchè non l'if eth0.100?
E' un refuso in scrittura sul gruppo.
Ho semplificato la configurazione postata.
Il firewall comunque è aperto, ho anche provato con svuotando
completamente le catene e mettendo come default un ACCEPT.


 nella configurazione dello switch
Ma se dici che non puoi staccare il cavo dal tuo fw tutto quello che
potevi fare l'hai fatto con tcp dump :-) Mi puzza di ACL sugli switch,
o per lo più di L2 non configurato correttamente, trunk encapsulation
tanto per dirne una. La if del tuo fw è connessa direttamente allo
switch in questione o passi fisicamente per altri switch? Nel caso la
vlan passi per un tuo switch, la prova potresti farla da qui
mettendoti con un pc sulla vlan 100.
Diversamente puoi sempre prendere i tizi per le orecchie e organizzare
un intervento congiunto ;-)
Daniele

 tanto per dirne una.
già. su diversi switch taggare le vlan non basta, devi anche dare la 
relativa ACL.
switchport general allowed vlan add 100
...tanto per dirne una alla allied telesis 8000 Series :)

 switch in questione o passi fisicamente per altri switch? 
Connessa direttamente, altrimenti il problema del non
staccare il cavo non si porrebbe.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito č di fare il possibile per la


 ...tanto per dirne una alla allied telesis 8000 Series :)
Mi sa che č un procurve, e se cosě vosse, visto che ne
ho almeno 20 in sede da me, non č necessario settare alcuna
acl e non mi pare nemmeno si debba settare il protocollo.
Supportano (a memoria) solo .1q
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito č di fare il possibile per la


 accetterà SOLO traffico tagged e scarterà tutto il resto.
Mi vien da pensare che sia questo il problema.
Me se così fosse, il traffico accettato sarebbe
quello untagged (e quindi lo switch ignora le vlan tagged)
oppure accetta solo il tagged ignorando l'untagged ?


 oppure accetta solo il tagged ignorando l'untagged ?
Nel caso dei procurve il problema non sussiste:
vlan 100 tagged ethernet 1
veicola tutto il traffico untagged della porta 1 ed anche
il traffico tagged della vlan100, quindi il problema non
è questo, nel caso si trattasse di un procurve.



Se vuoi scoprire che apparato � lo switch puoi provare a usare un tool 
di dicovery CDP sul tuo firewall (linux giusto?)
Es: cdpr - Cisco Discovery Protocol Reporter

 staccare il cavo non si porrebbe.
Se sul fw ci sono i vari L3 si porrebbe e come.

 Se sul fw ci sono i vari L3 si porrebbe e come.
Giuro che non ho capito la frase.



su alcuni switch si può dire alla porta che essa è "access" o 
"uplink/trunk". la prima modalità scarta tutto il traffico tagged, anche 
in caso di vlan dichiarate.


no infatti, su hp devi volontariamente abilitare le acl, non te le 
ritrovi abilitate per opera dello spirito santo.
che poi qualcuno le abbia abilitate ed ora non si ricorda e quindi non 
sta funzionando nulla... bhč... questo č un altro discorso anche 
plausibile :)


[cut]
giusto per fugare qualsiasi dubbio:
non sarà mica che tu esci da fw1 con traffico taggato 100 mentre lo
switch1 è configurato in modo da accettare traffico untagged, e taggarlo
100 solo sul trunk (cioè dove servirebbe effettivamente)?
chi ti ha messo a disposizione il ponte switch1---fibra----switch2 ti ha
per caso anche specificato a quali porte attaccarti sui due switch?

 per caso anche specificato a quali porte attaccarti sui due switch?
I collegamenti sono tutti in trunk, sia quelli tra i due switch, sia
quelli tra switch e firewall.
Il cavo che collega il mio firewall è connesso alla porta XX (boh,
non ricordo) dello switch. Tale porta è in trunk, e veicola sai il
traffico untagged (che funziona correttamente), sia alcune VLAN, che
però, non funzionano.
Domenica i tecnici dello switch van dal cliente, attenderò per sapere
cosa mi dicono.
firewall1 -> trunk -> switch1 -> trunk -> switch2 -> trunk -> firewall2
Io mi stampo tra firewall1 e switch2, non vado più in la di li.


 Io mi stampo tra firewall1 e switch2, non vado più in la di li.
Problema identificato e risolto (con una pezza):
Se creo un bridge usando la eth0, automaticamente tutte
le vlan taggate su tale interfaccia muoiono.
Se rimuovo la eth0 dal bridge, le vlan ripartono.
Ho risolto evitando di usare la eth0 e taggando
anche il traffico che precedentemente era untagged,
in questo modo il bridge vien creato tra eth0.150
e la eth0.100, in un altro bridge, funziona regolarmente.
Non riesco però a spiegarmi il perchè di questo comportamento.
Come mai se metto in bridge una interfaccia intera, anche le
vlan associate ad essa muoiono?


 vlan associate ad essa muoiono?
Perché ogni VLAN necessita di un bridge indipendente.
AFAIK, non esiste un oggetto "bridge di un trunk" nell'implementazione del 
bridging di Linux.
Semmai la domanda che mi viene in mente è... come fai a fare un bridge tra 
il traffico non taggato?
Ciao,
-- 
  Daniele Orlandi					つづく

 il traffico non taggato?
brctl addif br0 eth0
così come faccio questo
brctl addif br1 eth0.100
se attivo la prima, eth0.100 muore.
se stacco la prima, eth0.100 funziona.


 brctl addif br1 eth0.100
Con questa configurazione, ovvero con le vlan
in bridge e nessuna untagged, ci sono problemi
di routing.
Il ping, ad esempio, funziona sempre ed in ogni caso.
Ricevo correttamente risposte.
L'HTTP crea problemi, alcuni siti vanno, altri no.
Altri ancora, magari protetti da autenticazione,
funzionano a metà: viene richiesta l'autenticazione,
ci si autentica, poi la pagina interna carica all'infinito.
Non è un problema di firewall, non ho nulla loggato in DROP
e non ho alcuna regola particolare di forwarding o di
masquerade. Se funziona il ping, funzionano anche gli altri
protolli.
Se rimuovo il bridge delle vlan inserendo l'intera interfaccia
sotto bridge, perdo le vlan taggate ma il routing funziona
perfettamente.
Non so che pesci pigliare. Non ho idea del motivo.


 di routing.
Aggiungo che stando ai log di iptables, sembra
tutto configurato a dovere, questo è quanto
viene loggato cercando di accedere al sito 
ansa.it
Mar 30 17:22:58 gss kernel: USCITA: IN=br40 OUT=fe1 PHYSIN=eth0.40 
SRC=192.168.1.121 DST=194.244.5.206 LEN=48 TOS=0x00 PREC=0x00 TTL=127 
ID=21387 DF PROTO=TCP SPT=1849 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Mar 30 17:22:58 gss kernel: INGRESSO: IN=fe1 OUT=br40 SRC=194.244.5.206 
DST=192.168.1.121 LEN=48 TOS=0x00 PREC=0x00 TTL=53 ID=13506 DF PROTO=TCP 
SPT=80 DPT=1849 WINDOW=64240 RES=0x00 ACK SYN URGP=0
Subito sotto ogni regola che manda in log è presente una ACCEPT
pertanto se viene loggata, viene anche accettata alla riga sottostante.
Uscita significa il traffico in forward dalla lan del cliente verso
internet, ingresso significa il traffico established,related in ingresso
da ovunque verso ovunque.
Eppure la navigazione su alcuni siti, tra cui quello loggato sopra, non
riesce. Nemmeno usando direttamente l'ip (quindi non è un problema di dns)
Il masquarade è configurato così:
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -s $LAN -j MASQUERADE
ed è corretto, altrimenti non vedrei il traffico in ingresso.
Come si può vedere dai log, PHYSIN=eth0.40 indica una delle vlan in 
trunk. Questa volta le vlan funzionano correttamente (riesco a pingare
tutto e tutti) e fan parte del bridge 'br40'
Se invece di mettere in bridge eth0.40 metto eth0, tutto funziona, senza
cambiare una mezza riga sul firewall.


 riesce. Nemmeno usando direttamente l'ip (quindi non è un problema di dns)
Hai escluso che sia un problema di PMTUD ?
Questi siti che vanno "a metà" di solito sono un segnale... però 
bisognerebbe andare un po' più a fondo... e al momento non riesco ad 
aiutarti...



francamente un sito che va "a metà" non riesco proprio a collegarlo ad 
un problema di vlan.
la vlan o funziona o non funziona, non capisco proprio come possa 
rispondere un ping e non funzionare un sito in https...

 aiutarti...
Anche alcuni siti su rete interna, per la precisione le
admin di alcuni apparati wifi, vanno "a metà".
Tutti attraversano il firewall, ma non tutti escono su
internet. I siti esterni si, le admin degli apparati no, vengono
ruotati su un bridge differente composto da vlan differenti (appoggiate
anche sulla stessa interfaccia fisica delle altre)
Per rendere l'idea e semplificando, io ho:
br10: eth0 + eth2.10
br20: eth1 + eth2.20
br30: tap0.30 + eth2.20 + eth3
ho del traffico che deve essere ruotato da br10 a br20 o br30 e così via.


 rispondere un ping e non funzionare un sito in https...
esatto.
tra l'altro, l'HTTPS sembra funzionare bene. l'HTTP invece no.
Il routing o va o non va, dal momento che rispondi ai ping, l'http
deve funzionare, è stateless, o va o non va. Potrei capire l'FTP, che
magari non riesce a riaprire la porta al contrario, l'http proprio no.


 Non ho escluso nulla, brancolo nel buio.
però in effetti spiegherebbe diverse cose. se porti l'MTU a 1450 che 
succede... ?

 succede... ?
Adesso non sono in grado di farlo, perchè quando spostol
le vlan genero un disservizio al cliente.
Aspetto quindi di raccogliere più idee possibili in modo
da minimizzare il disservizio e gli interventi.
Nel frattempo, vedo di studiare un qualche test
fattibile da remoto.
