Newsgroup: it.comp.reti.locali
Titolo: Non passano gli ARP aiuto!

Ciao gente
abbiamo almeno 2 switch unmanaged che hanno parzialmente smesso di 
funzionare (uno � pi� a monte e uno pi� a valle in un albero di switch)
Alcune macchine sono raggiungibili ma altre no. Loggandomi in quelle 
raggiungibili ho notato che certune riescono ad accedere ad altre, ma 
non tutte a tutte, secondo pattern strani.
Quando non si raggiungono/pingano il problema � che il destinatario non 
riceve la richiesta ARP.
Ho fatto ping e arping fra 2 macchine irraggiungibili, facendo tcpdump 
sia sulla destinazione che su una terza macchina e ho notato che la 
richiesta ARP non viene fatta passare attraverso gli switch.
In certi casi in ping A->B, A non si vede risolto l'ARP ma con B->A 
funziona (da quel momento il ping funziona anche a rovescio)
Fra certe coppie di macchine la richiesta o risposta ARP viene fatta 
passare con un ritardo di 2 secondi.
Con tcpdump non vedo particolari flood di pacchetti attraverso quegli 
switch.
Come dicevo gli switch sono unmanaged quindi non ho molte informazioni. 
Li ho riavviati ma anche tenendoli spenti un po' non sembra che ci siano 
stati grossi miglioramenti.
Idee?
Sono un 3com e un HP. Sono rotti??? Come � possibile che abbiano smesso 
di funzionare contemporaneamente?
E' possibile che questi problemi siano dati da un arp poisoning di un 
computer compromesso?
Per quanto ne so l'ARP poisoning potrebbe dare ARP sbagliati al computer 
richiedente ma in questo caso non arriva proprio nessuna risposta ARP al 
computer richiedente.
Non ricordo se le richiesta ARP vanno in broadcast attraverso tutti gli 
switch IN OGNI CASO oppure se uno switch che presume di conoscere il 
destinatario lo girer� solo verso quella porta...? Nel primo caso mi sa 
che debbano essere rotti perch� io non le vedo girare...
Grazie

Qua andiamo male...
abbiamo provato a riavviare quei due switch varie volte con scarsi 
risultati.
Non sono sicuro che sia SOLO un problema di ARP
In uno, quello pi� a valle, si vedono delle porte che lampeggiano al 
massimo della velocit� e tutte in sincrono. Abbiamo allora provato a 
scambiare i cavi, il lampeggiamento folle si � ridotto (ad una porta 
sola o forse dopo era un lampeggiamento normale) ed � cambiata la 
visibilit� di alcuni computer, ma ancora non si vedevano tutti. Poi li 
abbiamo scambiati ancora... ma non siamo ancora arrivati alla visibilit� 
totale.
Ho provato un tcpdump da un computer attaccato allo switch pi� a valle 
ma io evidentemente non lo so fare perch� mi vengono pochissimi 
pacchetti, tipo:
root@macchina# tcpdump >  tcpdump2.out
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
^C1 packets captured
37 packets received by filter
0 packets dropped by kernel
Ma come, se ce ne sono 0 dropped by kernel e il filtro � vuoto perch� me 
ne cattura UNO SOLO su 37??? Su varie macchine ho avuto questo fenomeno, 
sono tutti linux con kernel >= 2.6.24
Comunque anche quelli "received by filter" sono pochi e non fanno 
pensare ad un flood, o almeno non un flood visibile dai computer.
In passato avevamo avuto ancora un paio di volte questo problema, sullo 
switch pi� a valle 3com, cio� che lo switch non funzionava e tutte le 
porte lampeggiavano all'impazzata in sincrono. A quel tempo avevamo 
provato a sostituire lo switch 3com 8 porte gigabit con uno switchino 
casalingo netgear 8 porte fast ethernet, e il risultato � che anche 
questo entro breve (meno di 1 ora) si metteva a lampeggiare 
all'impazzata e smetteva di funzionare. Quelle volte avevamo risolto mi 
pare cambiando la porta nello switch a monte, alla quale lo switch 
piccolo a valle era collegato. Strano eh? A monte a quel tempo c'era un 
grosso Enterasys 10/100 con uplink gigabit fibra, era managed ma non 
eravamo noi ad avere la password di management e non era facile 
comunicare con i gestori, in pratica era usato come unmanaged

 wrote:
Ciao
Due in un colpo mi sembra strano, l'arp è un broadcast quindi se
spegni e riaccendi uno switch e un client cerca di risolvere un ip lo
switch lancia il broadcast a tutte le porte, se una porta è connessa
ad un'altro switch anche questo rilancia a tutte le sue porte o
risponde tramite la sua tabella arp.
Se hai un loop per esempio il broacast si propaga ad anello aumentando
il traffico in maniera esponenziale, ti puoi accorgere perchè tutte le
luci delle porte si accendono fisse, in questo caso gli switch più
intelligenti (ma non Spanning tree) possono anche bloccare tutte le
comunicazioni per interropmere il loop.
Ma le macchine connesse su quei due apparati si vedono? potrebbero
essere gli altri ad essere isolati, hai controllato di non avere
qualche loop? anche se mi sembra che i unmanaged non hanno protezioni
contro il loop, altrimenti potrebbe essere proprio l'ecessivo
broadcast a provocare il blocco per protezione.
Io li proverei a banco o almeno isolandoli dagli altri per vedere se
tra le porte interne funziona tutto ok
Hai verificato con il comando arp -a prima e dopo aver fatto un ping
ad una macchina se nei pc c'è il mac corretto nella tabella arp?
Ciao

 Ma le macchine connesse su quei due apparati si vedono? 
Non tutte. Su ciascuno dei due switch avevamo almeno una coppia di 
macchine che non si parlava.
Novit�! OK!! questa volta mi sa che abbiamo trovato il problema. C'era 
un linux in kernel panic attaccato nello switch 3com a valle. Spento 
quel server, gli switch hanno ricominciato a funzionare. Curioso che 
riusciva ad influenzare anche lo switch HP pi� a monte: come dicevo 
alcune coppie di host attaccati direttamente allo switch pi� a monte NON 
si parlavano.
In passato come dicevo un problema simile era dato con a monte un 
enterasys invece dell'HP. Non so dire se anche a quel tempo era un 
server interno o esterno crashato o misbehaving... a quel tempo 
attribuimmo ad altro ma forse invece i problemi erano spariti ad un 
certo punto perch� qualcuno aveva riavviato qualcosa.
Sono deluso :( ma davvero gli switch sono cos� fragili da impazzire per 
UN solo host che manda un .... qualunque tipo di traffico erroneo?
Se voglio essere sicuro di avere uno switch che sia stabile anche in 
queste situazioni cosa devo prendere? Uno dei due malfunzionanti oggi 
era un HP, cio� la pi� blasonata marca, e sclerava nonostante fosse a 
distanza 2 hop dall'host crashato. Come si chiama la "feature" che 
previene queste cose? (managed? spanning tree? ...?)
Per il discorso del debug arp: s� ho verificato ed era proprio un 
discorso di mancato inoltro broadcast della richiesta. Il mittente 
restava con una "incomplete" e sia il destinatario che gli altri non 
ricevevano la request, inoltre con entry statiche funzionava, anche se 
il traffico era comunque tutto rallentato. Inoltre confermo che c'erano 
due host (attaccati uno su uno switch e uno sull'altro) per cui la 
risoluzione funzionava in una direzione ma non nell'altra (mi SEMBRA che 
funzionasse dall'host sull'HP all'host sul 3com... intesa come direzione 
della request)
Grazie

 UN solo host che manda un .... qualunque tipo di traffico erroneo?
So che nelle versione managed c'è la funzione (che va parametrizzata)
per limitare il broadcast, in pratica se il tasso di broadcast arriva
ad un certo numero di pacchetti al secondo lo switch va in protezione,
lo fa sia 3com sia hp ma non credo nelle versini unmanaged, sei sicuro
che non siano configurabili?
Se sono configurabili ma nessuno gli ha settati è probabile che sia
attiva di default la protezione.
In un post di qualche mese fa in una scuola dopo l'installazione di un
nuovo 3com non funzionava un software tipo vnc perchè superava il
numero di pacchetti mandando in protezione lo switch.
Ciao

 che non siano configurabili?
Eh s� � un baseline 16477
Adesso ho trovato il manuale e leggo questo:
-- Problem solving: --
   All Activity LEDs appear to be lit continually.
There may be
broadcast storms on the network. Remove port connections one
at a time, waiting a few seconds between each port. If the LEDs
go off after removing a port connection, the device that was
connected to that port is introducing an excessive amount of
broadcast frames to the network (some pieces of network
equipment operate by sending out broadcast frames regularly).
Refer to the documentation that accompanies the device for
information on disabling the broadcast operation.
Probabilmente � la *mancanza* della protezione che dici tu che ha 
causato il problema di ieri... cosa ne pensi? Io credo che se avesse 
avuto una protezione con una implementazione non troppo stupida avrebbe 
dovuto disabilitare soltanto la porta dal quale veniva lo storm quindi 
l'unico computer a non comunicare sarebbe stato quello crashato.
Cosa ne pensi, se in futuro acquistiamo switch con "protezione" siamo al 
riparo da questi problemi?
Mi sembra importante che se un computer fa il matto non vada gi� tutto 
il palazzo... mi sembra un comportamento basilare per uno switch serio!
Grazie!