Newsgroup: it.comp.os.linux.sys
Titolo: Problemi di ARP?

Ciao.
Ho 3 server: server1, server2, server3
Fino a qualche giorno fa, per un errore dello script di installazione, server2 e server3 avevano lo stesso indirizzo IP.
 
Server1, deve comunicare con 2 e 3 ed ovviamente non riusciva.
Ho cambiato gli IP, svuotato la cache arp ed ora server1 comunica con server3 ma non con server2.
 
se su server2 faccio un bel tcpdump, vedo le richieste ARP arrivare, ma non torna indietro nulla. Ho già svuotato tutto lo svuotabile, down/up della scheda di rete su ambo i server, ma i due non ne vogliono sapere di comunicare.
 
Su server2:
# ip neigh | grep 172
172.17.0.1 dev eth1  FAILED
# arp -v | grep 172
172.17.0.1                       (incomplete)                              eth1
 
 
Su server1 l'ip di server2 (172.17.0.61) non è presente nella tabella arp.
 
Anche forzandolo (arp -s 172.17.0.61 <mac>) lui continua a non raggiungere server2
 
Dove mi sto perdendo?
 
Server2 e server3 sono VPS gestite dallo stesso XenServer pertanto anche gli apparati di rete coinvolti son sempre gli stessi.
 

 Dove mi sto perdendo?
 
Da perfetto ignorante:
 
Indirizzo IP  = livello 3
 
Tabella ARP = luvello 2
 
Hai un un conflitto di IP, quindi un publema a livello 3
e tu giustamente:
 
passo 1: cambia indirizzi IP agendo a livello 3
 
Ma poi: 
 
Passo 2: Svuota cache ARP agendo a livello 2
 
A che scopo? L'errore sta al livello 3.
 
Le tabelle ARP hanno una scadenza, una volta corretto l'arrore
a livello 3 basta aspettare un poco e la tabella ARP si sistema 
da sola. Ma poi:
 
passo 3: arp -s 172.17.0.61 <mac>
 
Agisci ancora a livello 2. Non sarebbe meglio vedere le tabelle
di routing a livello 3?
 
 
 
 

 gli apparati di rete coinvolti son sempre gli stessi.
 
Xen...
Mi � capitato una cosa simile: server con indirizzo ip, lo cambio perch� ne 
doveva subentrare un altro, metto il vecchio ip sul sevrer nuovo e.. 
segnalazione di ip duplicato.
Ho dovuto fare lo shut down del server virtuale vecchio.
 
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
 
www.robyt.eu
 
 

Il 12/11/12 15.23, mallin.shetland ha scritto:

Se parti dal presupposto che non sappia cambiare da solo un indirizzo IP..
 
Senza sapere se quel Xen è Bridged, NAT'd o Routed.. auguri!
 
Non sappiamo nemmeno se server1 è la macchina fisica su cui girano 
server2 e server3 o se è una macchina esterna dietro l'iptable del 
server fisico ecc.. come cercare un ago in un pagliaio.
 
 
 
 

 Se parti dal presupposto che non sappia cambiare da solo un indirizzo IP..
 
Effettivamente mi era sfuggito un piccolo particolare: VPS
Scusami per  la banda sprecata.
 
 

 Server2 e server3 sono VPS gestite dallo stesso XenServer pertanto anche gli apparati di rete coinvolti son sempre gli stessi.
 
Ricapitoliamo: server2 e server3 avevano lo stesso ip, giusto?
Lo hai cambiato a quale server, server2 o server3?
Non so come funzionino i virtual switch di Xen e se siano "manageable", ma forse c'è qualche problema a quel livello lì, magari
sulle mac address table, oppure c'è qualche impostazione di security per cui avendo visto due ip diversi su una stessa virtual
port la manda in blocco (feature realmente esistente su molto switch reali).

 A che scopo? L'errore sta al livello 3.
 
Su uno stesso segmento ethernet, per parlare a livello 3 devi prima effettuare una risoluzione
a layer 2.

 port la manda in blocco (feature realmente esistente su molto switch reali).
 
 
il port security sugli switch lavora sempre e comunque a livello 2, 
agisce sul learn della mac-table, non sull'ip. Se fai riferimento al 
port security. Altrimenti a cosa ti riferisci?
 
 

 port la manda in blocco (feature realmente esistente su molto switch reali).
 
Ok. Ma il mio ragionamento era: se server3 ha iniziato a funzionare, la collisione non è più presente, quindi server2 dovrebbe iniziare a rispondere.
Anche perchè su server2 io vedo le richieste arp in arrivo (banale tcpdump con un ping in esecuzione da server1->server2), ma server2 non risponde.
Se ne sbatte allegramente, la domanda è: perchè ?
 
Penso che il problema sia su server2, se fosse sullo switch o su server1, non arriverebbero le richieste, mentre invece arrivano, son le risposte che non partono.

 partono.
 
Concordo.
iptables (o altro firewall)?
 
-- 
************** (.)_(.) *******************
Un amico è uno che sa tutto di te e,
nonostante questo, gli piaci
(E. Hobbard)
http://www.youtube.com/user/Nameci65
 
 
 

Addì  lunedì 12 novembre 2012 16:05 whiplash scrisse:

Si, ok, quindi dopo aver cambiato *entrambi* gli indirizzi IP, azzero
le tabelle ARP sui nodi e sui router, azzero le tabelle di routing 
sul router per velocizzare il riconoscimento altrimenti tutto 
dovrebbe avvenire automaticamente dopo un certo periodo.
 
Questo è quanto so, a meno che qualcosa (tipo VPN e Xen)
interferisca. E qui alzo le mani e mi arrendo. Però, anche se è utile 
controllare che le cose a livello 2 funzionino, perché azzerare
le tabelle ARP? Non è meglio ascoltare il traffico? Non è meglio 
concentrarsi su Xen, che mi pare l'indiziato principale?
 
 
 

 iptables (o altro firewall)?
 
Riavviati decine di volte (giusto per stare sul sicuro) senza successo.
Inoltre, la stessa configurazione funziona su centinaia di altri server senza problemi e nessuno l'ha mai toccata per quanto riguarda server1 e server2

 concentrarsi su Xen, che mi pare l'indiziato principale?
 
Di cose migliori da fare ce ne sono a bizzeffe, ma con i se e con i ma non si va da nessuna parte.
 
Se sapessi cosa fare di migliore rispetto a resettare tutto ciò che ho a portata di tastiera, non avrei aperto il post ed il problema non sussisterebbe.
 
Il problema è che io non so cosa fare oltre ad un reset del mondo intero. (che ho già fatto e che non ha funzionato)

On 12/11/2012 22:04, 
gandalf.co...@gmail.com
 wrote:

arping che dice?

 il port security sugli switch lavora sempre e comunque a livello 2
 
Cisco
ip verify source port-security
 
Juniper
ip-source-guard
 
eccetera.
 
Lo snooping a layer superiori c'è da un bel pezzo, su switch di un certo livello.

 Se ne sbatte allegramente, la domanda è: perchè ?
 
Bella domanda.
Se fosse un'infrastruttura fisica potrebbe assomigliare a qualche casino su vlan tagged e untagged.
Provato arping dal server2?
Su server1 e server3 vedi qualcosa?

 Su server1 e server3 vedi qualcosa?
 
arping server1->server2 non pinga
 
su server2:
23:16:18.628424 ARP, Request who-has 172.17.0.61 tell 172.17.0.1, length 46
ma nessuna risposta (è questo che mi fa strano, molto strano)
 
arping server2->server1 non pinga
 
server1->server3 funziona tutto senza problemi.
 
sempre su server2:
 
# ip addr show eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 82:33:a6:98:f0:df brd ff:ff:ff:ff:ff:ff
    inet 
172.17.0.61/24
 brd 172.17.0.255 scope global eth1
    inet6 fe80::8033:a6ff:fe98:f0df/64 scope link 
       valid_lft forever preferred_lft forever
 
# route -nC | grep 172.17.0.
172.17.0.1      172.17.0.61     172.17.0.61     il    0      0      273 lo
172.17.0.61     172.17.0.1      172.17.0.1            0      0        0 eth1
 
# route -n | grep 172.17.0.
172.17.0.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
 
# iptables -L OUTPUT -n       
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
#
 
Si, il cavo di rete è collegato, ho controllato persino quello ;)
# ethtool eth0
Settings for eth0:
	Link detected: yes
 
 
Boh, sembra tutto ok.
 
Tornando a Xen, sul dom0 (ammetto che non l'ho mai fatto prima) non vedo nulla nella arp ne come route, quindi escludo possa esserci qualche coinvolgimento, tale ip non compare da nessuna parte nel dom0


 
non lo metto in dubbio, era per capire a cosa ti riferivi nello 
specifico. anche perchè man mano che ci si allontana dalle funzionalità 
puramente switching, ognuno le chiama in maniera differente :)
 
ad esempio alcuni produttori fanno snooping solo per i server dhcp o con 
funzionalità molto limitate (anche su fasce enterprise). Anche se, a 
pensarci bene, il dhcp snooping rimane in effetti sul layer 2..

 (che ho già fatto e che non ha funzionato)
 
È ovvio. Io avevo consigliato di vedere le tabelle di routing, poi è stato
osservato che il problema era comunque dovuto ad un firewall e quindi
a livello 2 perché questo agisce tra i livelli 2 e 3.
in ogni caso arping e arpd aiutano molto. 
 


 
Hai la possibilit� di cambiare IP a server2?

 in ogni caso arping e arpd aiutano molto.
 
Le ho postate. Ma il problema non è il routing, perchè se così fosse, le risposte partirebbero ma non arriverebbero a destinazione.
secondo me il problema è che server2 non risponde alle richieste arp, e non riesco a capirne il motivo.

 Hai la possibilità di cambiare IP a server2?
 
Fatto ora senza risultato. arrivano le richieste ma il server non risponde.

 secondo me il problema è che server2 non risponde alle richieste arp, e non riesco a capirne il motivo.
 
Per caso nel tuo guardare le impostazioni di firewall hai dato un'occhiata anche ad arptables?
 
Le opzioni arp dentro /proc/sys/net/ipv4/conf/ethX ?
 (vedi 
http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP
 )
 
my 2c
stefano

 Le opzioni arp dentro /proc/sys/net/ipv4/conf/ethX ?
 
Tutto a zero, come è di default e come ho su tutti gli altri server.
 
E' come se server2 non 'riconoscesse' l'ip, e non lo sentisse suo e quindi non risponde alle richieste arp. Ma ho già fatto down/up della scheda più volte e cambiato IP. Inoltre si autopinga correttamente:
 
# ping 172.17.0.61 -c2
PING 172.17.0.61 (172.17.0.61) 56(84) bytes of data.
64 bytes from 
172.17.0.61
: icmp_req=1 ttl=64 time=0.040 ms
64 bytes from 
172.17.0.61
: icmp_req=2 ttl=64 time=0.028 ms
 
--- 172.17.0.61 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.028/0.034/0.040/0.006 ms


 
IPV6 disabilitato?

 IPV6 disabilitato?
 
Non ci sono IPv6, ma che centra?
 
# ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 fe80::c88:a1ff:fef8:c9a4/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000


 # ping 172.17.0.61 -c2
 
hai provato a cambiare l'IP su server2?
magari lui pensa che quell'IP sia ancora duplicato e si "autocensura"
per evitare casini sulla rete.
 
Ciao Jack
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

 per evitare casini sulla rete.
 
Già fatto questa mattina, c'è scritto da qualche parte più su.
Esito negativo.


ah ok, scusa non avevo letto...


 ma nessuna risposta (è questo che mi fa strano, molto strano)
 
Puoi piuttosto provare con arping -A e arping -U da server2 e vedere se da
server1 e server3 vedi gli unsolicited arp con tcpdump (e lancia il tcpdump -e, così
vediamo anche i mac)?
 
arping -A 172.17.0.61
e
arping -U 172.17.0.61

 arping -A 172.17.0.61
 
Come sempre, solo who-has
 
# tcpdump -ei eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
16:25:00.488032 00:1e:c9:e4:d1:93 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 172.17.0.61 tell 172.17.0.1, length 46
 
 

 16:25:00.488032 00:1e:c9:e4:d1:93 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 172.17.0.61 tell 172.17.0.1, length 46
 
C'è qualcosa che non mi torna.
Con arping -A 172.17.0.61 lanciato su server2, da server1 e server3 dovresti vedere una cosa del genere:
 
82:33:a6:98:f0:df > Broadcast, ethertype ARP (0x0806), length 60: Reply 172.17.0.61 is-at 82:33:a6:98:f0:df , length 4
 
visto che in un precedente post affermavi che
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sempre su server2:
 
# ip addr show eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 82:33:a6:98:f0:df brd ff:ff:ff:ff:ff:ff
    inet 
172.17.0.61/24
 brd 172.17.0.255 scope global eth1
    inet6 fe80::8033:a6ff:fe98:f0df/64 scope link
       valid_lft forever preferred_lft forever
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 # tcpdump -ei eth1
 
Perï¿œ qualche post piï¿œ riferivi:
 
"ethtool *eth0*"
 
Non ï¿œ che per caso hai fatto confusione con l'ordine delle interfacce 
di rete? Spieghrebbe perche non vedi nulla con tcpdump?
 
 

 82:33:a6:98:f0:df > Broadcast, ethertype ARP (0x0806), length 60: Reply 172.17.0.61 is-at 82:33:a6:98:f0:df , length 4
 
Scusa, sto facendo una gran confusione.
Su *server2* (172.17.0.61), devo lanciare arping -A e pingare se stesso, quindi 172.17.0.61? In tal caso, ho provato ora: nessuno vede nulla, a parte un warning:
 
# arping -A 172.17.0.61
arping: Um.. lo looks like the wrong interface to use. Is it? (-i switch)
arping: using it anyway this time
ARPING 172.17.0.61
 
 
Se su *server2* pingo l'ip di server1 (172.17.0.1):
# arping -A 172.17.0.1
ARPING 172.17.0.1
arping: libnet_write(): libnet_write_link(): only -1 bytes written (No buffer space available)
 
E' come se le richieste arp non uscissero da server2.
 
Neanche dire che si è incriccata la porta dello switch, è una VPS, e lo stesso switch, sulla stessa porta, gestisce altri 15-20 server, tra l'altro, nemmeno in vlan, quindi la subnet è sempre quella.

 di rete? Spieghrebbe perche non vedi nulla con tcpdump?
 
Ho fatto confusione io a scrivere.
l'interfaccia è eth1, eth0 è tutt'altro.

 Non esiste come parametro e la manpage non dice nulla in merito.
 
Stiamo usando arping diversi, io quello di iputils

 Stiamo usando arping diversi, io quello di iputils
 
Ok, ma non cambia nulla, se faccio sia -A che -U dal server2, su server1 non arriva nulla.

 Ok, ma non cambia nulla, se faccio sia -A che -U dal server2, su server1 non arriva nulla.
 
Hai usato arping di iputils, stavolta?

 problemi e nessuno l'ha mai toccata per quanto riguarda server1 e server2
 
arp_ignore = 1 in sysctl ?
 
-- 
************** (.)_(.) *******************
Un amico ï¿œ uno che sa tutto di te e,
nonostante questo, gli piaci
(E. Hobbard)
http://www.youtube.com/user/Nameci65
 
 
 

 arp_ignore = 1 in sysctl ?
 
scusa, 8


 Hai usato arping di iputils, stavolta?
 
Eh si, l'avevo dato per scontato.

 arp_ignore = 1 in sysctl ?
 
No.
 
# sysctl -a | grep arp_ignore
net.ipv4.conf.all.arp_ignore = 0
net.ipv4.conf.default.arp_ignore = 0
net.ipv4.conf.lo.arp_ignore = 0
net.ipv4.conf.eth0.arp_ignore = 0
net.ipv4.conf.eth1.arp_ignore = 0

On 13/11/2012 10:39, 
gandalf.co...@gmail.com
 wrote:

Ok. Una curiosit� ma se spegni server3 cambia qualcosa?

 Ok. Una curiositï¿½ ma se spegni server3 cambia qualcosa?
 
Non ho provato e preferirei evitare.
Ho provato, però, ad abbattere la nic della rete di backup di server3 (il backup è la rete che da problemi) ed in questo caso non cambia nulla.
 


 
Mah...
Hai provato anche a cambiare il MAC address di server2 oltre che l'IP?
 

 Hai provato anche a cambiare il MAC address di server2 oltre che l'IP?
 
Sinceramente no, domani provo.
 

 Hai provato anche a cambiare il MAC address di server2 oltre che l'IP?
 
Ora va. Ho rimosso la NIC e reinserita con un nuovo MAC ed ha ripreso a funzionare.
 
Questo significa che il problema non è lato software su server2 ma probabilmente lato hardware (nel mio caso, virtualizzato) sul dom0.
 
Sarebbe interessante sapere come mai sia stata possibile una cosa del genere.

 Eh si, l'avevo dato per scontato.
 
Sicuro sicuro che quell'interfaccia sia sulla vlan giusta (o qualcosa di simile, ripeto che non conosco affatto
Xen)? Il fatto che ti mandi pacchetti arp da server2 e che tali pacchetti non siano visibili su server1 e server3
sembrerebbe indicare un problema del genere o di filtraggio a layer 2.
Vedo di dare un'occhiata a qualche doc sul networking di Xen...


 
Non vorrei avesse avuto lo stesso mac di server3...

 Il fatto che ti mandi pacchetti arp da server2 e che tali pacchetti non siano visibili su server1 e server3 sembrerebbe indicare un problema del genere o di filtraggio a layer 2.
 
No, aspetta.
server1 manda pacchetti arp, server2 li riceve.
server2 non risponde, come se non fosse a conoscenza del proprio mac, pertanto non risponde ai broadcast perchè, secondo lui, non sono diretti a lui.
 
cambiando mac, ha ripreso a funzionare.

 Non vorrei avesse avuto lo stesso mac di server3...
 
In tal caso sarebbe un bug di xen.
I mac vengono assegnati da Xen quando crea la VM, dovrebbe gestire l'univocità.

 Sarebbe interessante sapere come mai sia stata possibile una cosa del genere.
 
Non centra nulla, ma mi fa venire in mente una cosa simile che mi �
capitata con vmware server installato su un win2k3 (mi serviva per far
girare una piccola vm e non aveva senso avere un server apposito).
 
Non ricordo tutti i dettagli in quanto � passato un po' di tempo.
Ogni tanto, la vm si disconnetteva dalla rete. Anche riavviandola non
c'era verso che comunicasse n� con l'host n� con il resto della rete.
Anche qui si vedevano arp request, ma le arp reply generate dalla vm non
raggiungevano il server sottostante.
L'unica soluzione era riavviare l'host. Rimuovere e aggiungere la nic
virtuale non serviva a nulla.
Ad un certo punto � saltata la corrente mentre ero nei paraggi di quel
server. Il server � rimasto su, lo switch invece no.
Quando � ritornata la corrente, la vm era di nuovo isolata.
Mi sono rimesso a fare le prove, ad un certo punto ho buttato l'occhio
sulla tabella arp o le tabelle di routing (non ricordo) e avevo notato
che era comparso un indirizzo 192.168.x.y che non aveva nulla a che
vedere con la rete in questione. Un controllo, ed era la rete nat o
host-only di vmware. La vm invece risultava collegata alla rete bridged.
Disattivato le nic virtuali per la rete nat/host-only e la vm ha ripreso
a comunicare perfettamente.