Newsgroup: it.comp.os.linux.sys
Titolo: [URGENTE] Problema rete

Chiesto scusa per il tag [URGENTE].
Ho uno strano problema: ogni 15-20 minuti la rete composta da 5 pc
windows ed un firewall linux collassa improvvisamente.
Sul gw, facendo un tcpdump sulla eth connessa alla rete locale non
vedo alcun pacchetto in arrivo.
In drop su iptables non ho nulla.
Dai pc windows riesco a raggiungere correttamente gli altri server
(che non devono attraversare il gateway).
Il gateway è pingabile correttamente.
Credo sia un problema di windows giusto? (adesso faccio un post nel
gruppo appropriato) ma a voi non è mai capitato niente di simile?
Poi misteriosamente, dopo 10 minuti di down tutto riparte.
L'unico problema da me riscontrato è un numero di pacchetti superiori
a 0 in overrun, ma lato wan del firewall quindi non dovrei avere
problemi. O per lo meno dovrei comunque riuscire a vedere i pacchetti
in ingresso lato lan con tcpdump.
Tnx.

 
down?
ma se i server in lan sono pingabili...
e se il firewall è pingabile...
cosa non funziona?
la navigazione in internet?
pacchetti in overrun dove?
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 
Se è il collegamento internet che collassa allora è capitato anche a 
me... avevo un router 3Com e quando abbiamo installato un programma per 
P2P l'enorme (per il router) mole di connessioni attive contemporanee 
faceva andare in palla il router che tornava vivo dopo circa 15 minuti 
di down. Disinstallato il P2P tutto è tornato normale.
Mauro

 pacchetti in overrun dove?
Sul firewall, lato wan.
La rete è composta da 1 firewall connesso lato wan ad una sorta di
"core switch" e lato lan ad uno switch
quando collassa il tutto, windows non instrada più le richieste al
gateway.
mettendomi in ascolto con tcpdump sul firewall sulla eth lato lan, non
vedo alcuna richiesta.
Esempio:
# tcpdump -i eth1 host 192.168.0.144 and not port 22
facendo, dal mio pc (.144) un ping di sto tipo
ping 
www.google.it
sul firewall non compare niente.
NON è un problema di dns, in quanto nemmeno usando l'ip vedo traffico.
Improvvisamente, dopo un po, tutto riparte.
In sostanza i sintomi sono come se disattivassi manualmente il default
gw di windows.
Inizilamente pensavo ad un problema di un singolo computer e gli ho
cambiato la scheda di rete ma oggi il problema si ripresenta su tutti
e 10 i pc.
Ho cambiato lo switch, non è cambiato niente.
Però ho notato che cambiando switch, oppure spegnendo e riaccendendo
quello attuale, tutto riparte.
Ho pensato quindi ad un problema di switch, magari si saturano le
tabelle. Possibile? Una soluzione quale può essere?
10 pc connessi ad uno switch da 24 porte gigabit mi sembrano 'pochi'
per poter saturare tutte le tabelle e nessuno fa P2P o utilizza
protocolli invasivi.


Non collassa internet, è il windows che non instrada le richieste al
gateway.
O meglio, è quello che credo io, perchè sul gateway, lato lan, non
arriva nulla.
potrebbe essere lo switch, ma ho appena sostituito quello attuale con
uno simile e fa uguale.

 
verifica se hai qualche scheda di rete rognata, magari che 'dopo un pò' 
comincia a sparare pacchetti corrotti che smandruppano le tabelle arp 
dello switch.
se lo switch è managed, t permette d vedere gli arp noti e verificare se 
qualcuno è invalid o 'strano'.
in teoria, poter lasciare spento a turno uno dei pc, fino al 
ripresentarsi del problema, aiuterebbe a capire se la colpa è di uno di 
loro, ma non penso sia fattibile...
:-)
verificati gli event log dei pc?


 verificati gli event log dei pc?
Sotto win dove vado per verificare ciò? (comunque, no problem, me lo
trovo io da solo)
Non so usare windows, giusto come 'utente base' che utilizza
dreamweaver per lavoro e putty. :)

 Comunque al prossimo collasso proverò.
Si, tcpdump mi rileva il ping.

 qualcuno è invalid o 'strano'.
Identificato il problema.
Sui pc con la rete collassata (non collassa in simultanea su tutti),
il mac address del firewall non corrisponde al vero.
Il firewall ha 3 schede di rete
eth0 wan
eth1 lan interna
eth2 lan backup
quando la rete collassa, il windows vede il firewall con il mac
address della scheda di rete collegata alla lan del backup (cosa
inverosimile, dato che tale lan non è collegata allo switch della rete
interna).
Ma come è possibile?
eth1      Link encap:Ethernet  HWaddr 00:0C:76:9E:08:48
          inet addr:192.168.0.50  Bcast:192.168.0.255  Mask:
255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1379253 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1586448 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:178253358 (169.9 Mb)  TX bytes:591485665 (564.0 Mb)
          Interrupt:22
eth2      Link encap:Ethernet  HWaddr 00:48:54:6F:00:CA
          inet addr:172.16.7.254  Bcast:172.16.7.255  Mask:
255.255.248.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:33574 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13446 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6232784 (5.9 Mb)  TX bytes:1686578 (1.6 Mb)
          Interrupt:18 Base address:0xa400
il problema è eth2.
La netmask è corretta, una /21 che dovrebbe consentirmi di accedere
agli host da 172.16.0.0 a 172.16.7.255.
Quindi non vedo come mai la eth2 mi 'scavalca' la eth1 e tra l'altro
lo fa saltuariamente.

 Ma come è possibile?
Diccelo tu, disegnandoci la topologia della rete, prima dici che gli
switch sono due, adesso dovrebbero essere tre, se ci metti la lan di
backup.
Come e' fatta, quella rete?
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 Come e' fatta, quella rete?
Ho detto 2 switch?
Comunque, credo cambi poco, dato che gli switch sono attaccati a delle
reti non in condivisione tra loro.
In sostanza, lato wan (con il suo rispettivo switch) va tutto in drop
quindi eventuali problemi su quello switch non intaccano la rete
locale.
Il firewall ha 3 schede di rete:
eth0: wan (ed il suo switch)
eth1: lan (ed il suo switch)
eth2: backup (ed il suo switch)
a volte capita che eth2 'scavalchi' eth1 e la lan locale vede il mac
address della eth2 al posto di eth1.
Cosa che ho sempre reputato impossibile fino poco fa.
Come è possibile che dalla lan locale vedano il mac di una scheda su
una lan differente?

 "core switch" e lato lan ad uno switch
-------------
Poi, avevi detto anche 5 pc e un firewall, poi dieci e due server,
domani saranno cinquemila su tre sedi, un router a vapore per la
vpn locale e uno diesel per quella geografica, tre DMZ, ...
Ora, per me, al 99,9% sono stati i puffi.
E' tutto quello che posso dire, con le nulle info che hai dato.
Sono switch separati?
O sono "virtual lan" di un grosso switch?
Il cablaggio e' "sicuramente" separato?
Sei sicuro che nessuno abbia fatto pasticci con le prese di rete?
Non saresti l'unico a cui la donna delle pulizie trova un cavo di rete
staccato, crede di averlo staccato spazzando, e lo infila nella prima
presa a muro in cui entra, mettendo cosi' in comunicazione due tronconi
di rete che da progetto dovevano restare ben separati. <vbeg>
Le tre schede sono TRE o e' una scheda multipla, o e' uno di quegli
oggettini multiethgernet simil-appliance?


 oggettini multiethgernet simil-appliance?
sono TRE.
Tre schede distinte su tre PCI distinte.

 diverse.
E' l'unico caso che conosco in cui una tabella arp possa venir sporcata
a cavallo di DUE RETI che dovrebbero essere fisicamente separate.


 a cavallo di DUE RETI che dovrebbero essere fisicamente separate.
Mmm.
Anche se mettessi in collegamento i due switch tra loro, le tabelle
arp non dovrebbero andare in crisi.
eth0 = mac1, ip1, subnet1
eth1 = mac2, ip2, subnet2
unendo le due reti, mi dovrei ritrovare con due subnet nello stesso
switch senza troppi problemi dato che non ci sono IP in comune.
Quindi l'ip1 avrà sempre il mac1 e l'ip2 avrà sempre il mac2 anche se
sono sempre nello stesso switch.
Vabbe, aspetterò di metter mano alle 2 reti per indagare più a fondo.
Domandina: nel caso i due switch fossero collegati tra loro (metti
caso che mi sia sfuggito un cavo di interconnessione)
1) come mai si presenta questo problema?
2) come si risolve?

 windows ed un firewall linux collassa improvvisamente.
Anch'io ho un problema simile. La rete da me e` cosi` composta:
-----------   -----------   -----------
| switch1 |   | switch2 |   | switch3 |
-----------   -----------   -----------
     |             |             |
     |        -----------        |
     +--------| switch4 |--------+
              -----------
                   |
                   |
              ------------
              |  router  |
              ------------
                |      |
                |      |
          +-----+      +-----+
          |                  |
     ------------      -------------
     |   adsl1  |      |   adsl2   |
     ------------      -------------
In pratica, ho quattro switch (uno per i server, due per i client e uno
di
raccordo) che finiscono sul router/firewall, che mette in comunicazione
la
rete con l'esterno attraverso le due linee ADSL. Nel mio caso il problema
dovrebbe essere localizzato sullo switch di raccordo, in quanto si trova
costretto a reggere il traffico generato dagli altri tre switch (di pari
potenza), anche se come spiegazione non mi convince molto (le
connessioni tra client sono ottime e prive di problemi, inoltre le
connessioni stabilite non hanno problemi). Personalmente, per risolvere
provero` ad agire in due punti:
1) eliminando lo switch di raccordo (cosa che attualmente non mi e`
possibile, in quanto il router/firewall ha solo tre porte ethernet);
2) sostituendo gli switch (dei Linksys SR224 non managed).
Enrico
P.S. la rete e` unica fino a livello del router, dopodiche` le ADSL
hanno degli indirizzamenti differenti. Inoltre il DHCP e` gestito
direttamente dal router, mentre il DNS e` un server agganciato
direttamente sullo switch di raccordo
P.P.S. si, lo so, fa schifo

 2) come si risolve?
Mettendo una regola in iptables, non ricordo quale tabella, che dice 
sostanzialmente: se la scheda di rete 0 riceve un pacchetto arp diretto 
all'ip di rete 1 o rete 2, cestinalo; se la scheda di rete 1 riceve un 
pacchetto arp diretto alla'ip di rete 0 o rete 2, cestinalo; se la scheda di 
rete 2 eccetera eccetera, ecceteralo.
Se le reti sono separate come IP, dovrebbe essere abbastanza facile.
Ci sono dei difetti in questo approccio, in realta' sarebbe meglio dire 
"rispondi sempre col mac giusto" (si puo' fare). Io ai tempi implementai 
quest'ultimo approccio e funziono' ttto perfettamente... Ma cosi' violi il 
protocollo.
Ciaotutti,
* 

 Perche' il protocollo ARP e' scritto col culo.
Col culo o meno, non capisco come mai si presenta il problema.
Se io prendo 1 switch e gli collego 4 pc, 2 appartenenti ad 1 subnet e
2 ad una differente a meno che non ci sia conflitto di IP
(impossibile, dato che sono 2 subnet differenti)
l'arp non presenta alcun problema. O per lo meno non presenta questo
tipo di problema.
La mia rete è composta in maniera simile a quella di Enrico, con la
differenza che i 3 switch sono connessi ad altrettante porte ethernet
sul firewall.
non è presente alcun switch di raccordo e nessuna adsl.
3 switch, 3 subnet diverse (niente problemi di 'accavallamento'
causati da netmask errate), 3 eth distinte.
Ho notato, proprio ora, che lo switch di backup è collegato anche alla
lan interna, ma non dovrebbe essere ugualmente un problema dato che le
subnet sono diverse.
(comunque, adesso rimuovo il collegamento)

 reti non in condivisione tra loro.
Non mi è chiaro se sui tuoi switch a subnet differenti corrispondono
vlan differenti.
A me pare che potremmo essere nella situazione di arp flux.
Prova un po' ad impostare ad 1 /proc/sys/net/ipv4/conf/*/arp_filter

 subnet sono diverse.
CVD.


 Prova un po' ad impostare ad 1 /proc/sys/net/ipv4/conf/*/arp_filter
Non ci sono vlan sugli switch. sono degli orribili switch unmanaged
dove l'unica cosa che devo fare è attaccare il cavo.

 CVD.
E ok, ma vorrei capire il perchè si presenta questo problema.

 E ok, ma vorrei capire il perchč si presenta questo problema.
Perche' il protocollo ARP e' scritto col culo, l'ho detto un migliaio di 
volte e la gente non mi crede.
In pratica, se una scheda di rete riceve una chiamata che dice "hai tu $(ip 
che quella scheda non ha ma un'altra scheda sulla stessa macchina si)?" 
DEVE, da protocollo, rispondere: "si', l'ho io".
Ho detto che il protocollo ARP e' scritto col culo?
Ciaotutti,
* 


Beh, per dare a Cesare quel che e' di Antonio (che gia' si e' preso 
Cleopatra): in realta' da protocollo deve rispondere, punto. COME risponda 
e' lasciato un po' nel vago...
Pero' di solito a una richiesta ARP una scheda risponde col proprio MAC, non 
con quello di qualcun'altro...
Ciaotutti,
* 

 volte e la gente non mi crede.
Guarda che è un comporamento tipico di *linux* quello di rispondere su
qualsiasi interfaccia, di default...

 E ok, ma vorrei capire il perch� si presenta questo problema.
Perchè lo stack di linux di default fa così, ho provato a suggerirtelo
quando ti ho parlato di arp_filter.
Consentimi di dire, comunque, che il tuo layer 2 è *male*.
Il subnetting, il firewall et cetera servono davvero a poco se poi tutto
si muove, a layer 2, su un'unica vlan.


Eh, non volevano credermi, quando con i miei poteri dicevo cha avevano
le subnet intercomunicanti.


 si muove, a layer 2, su un'unica vlan.
Questo è sicuro, quel cavo non doveva stare li.
Altrimenti non avrebbe senso un firewall per separare i tronconi, se
poi essi sono già uniti con un bel cavetto che bypassa il firewall.
Comunque adesso ho le 2 lan incriminate completamente separate e
sembra funzionare.
(da questa mattina nemmeno un blocco).

 qualsiasi interfaccia, di default...
Suggerirei una ricerca su "arp problem" in relazione a LVS, c'è della
roba illuminante... :-D

 typed:

Si' ma prima della 2.4 o giu' di li' non lo faceva. Ad un certo punto i
kernel developer hanno deciso che DOVEVANO conformarsi allo standard (nb:
secondo me potevano farne a meno), quindi si sono messi a rispondere secondo
protocollo.
Senonche' il protocollo e' scritto in modo quantomeno discutibile, ed i 
risultati si vedono...
Ciaotutti,
*

 risultati si vedono...
Se intendi il fatto di rispondere alle ARP request per un IP locale
indipendentemente dall'interfaccia sulla quale la query č stata
ricevuta, non č una questione tanto di protocollo o standard.
O, meglio, ARP č definito in una maniera che, su quel punto, puņ essere
soggetta ad interpretazioni, e Linux (dal 2.4 in poi, ma mi pare anche
le ultime versioni del 2.2 se ben ricordo) ne adotta una specifica, che
gli sviluppatori ritengono quella corretta per una serie di motivi.
Oltri OS *non* si comportano alla stessa maniera, pur aderendo allo
stesso standard, per via di "interpretazioni" diverse della definizione.


Quando avevo letto l'RFC ne avevo cavato che il computer che ha un IP deve 
comunque rispondere ad una richiesta "lo hai tu?" (anche se arriva su 
un'interfaccia che non e' quella che, poi, puo' effettivamente rispondere 
via IP), "si', l'ho io".
Poi, la definizione di "io" (MAC address con cui rispondere) era lasciata 
nel vago, ma una volta che rispondi stai rispondendo sbagliato, perche' su 
quel trunk nessuna interfaccia sta ascoltando per quell'ip.
Ciaotutti,
* 

 per quell'ip.
Il che mi costringe a rivedere una mia risposta: ricevuta una chiamata ARP 
su un'interfaccia, verso un IP che quell'interfaccia non ha, la regola di 
iptables da adottare e' DROP.
Ciaotutti,
*