Newsgroup: it.comp.os.linux.sys
Titolo: IPv6: Link Local

In riferimento a questo: 
https://groups.google.com/forum/#!topic/it.comp.reti.ip-admin/PHY66qWvKSk
 (scrivo di qua perchè icr.ip-admin è mezzo morto come gruppo e le macchine in questione sono tutte linux), ho notato questa strana situazione (router vyatta):
 
$ show ipv6 route connected | grep fe80
C * fe80::/64 is directly connected, bond1.101
C * fe80::/64 is directly connected, bond1.102
C * fe80::/64 is directly connected, bond1
C * fe80::/64 is directly connected, bond1.103
C>* fe80::/64 is directly connected, bond0
 
Secondo me qualcosa non torna. Come fa la stessa subnet "fe80::/64" a poter essere ruotata su 5 interfacce differenti (considerando anche le 3 VLAN) ?
 
Dico male ?
C'è un link-local per ciascuna NIC coinvolta, il che va bene, ma il routing non dovrebbe essere differente ? Se lo stesso range è raggiungibile da 5 nic differenti, come fa a ruotare nel posto giusto ?

 Secondo me qualcosa non torna. Come fa la stessa subnet "fe80::/64" a poter essere ruotata su 5 interfacce differenti (considerando anche le 3 VLAN) ?
 
Facile: per definizione, fe80::/64 non è routata.
 

 Facile: per definizione, fe80::/64 non è routata.
 
Mi sono espresso male. 
Avendo la stessa /64 su 5 nic differenti, il mio caro router come fa a sapere che fe80::210:18ff:fe34:dcf0 è raggiungibile da bond0 e non da bond1 piuttosto che su una delle sue VLAN ?
 
Il mio problema è che i vari neighbours fanno questi cambi di status:
 FAILED -> INCOMPLETE -> FAILED -> INCOMPLETE -> FAILED -> INCOMPLETE -> PROBE (lladdr rilevato) -> DELAY (llrilevato) per poi ricominciare il giro da FAILED dopo qualche secondo avendo perso il link-local
 
Ci sono 3 mandate di "FAILED -> INCOMPLETE" poi misteriosamente viene rilevato il link-local del server, entra in DELAY (ed in questa precisa fase il server è pingabile in v6) e, senza motivo, torna in failed.
 
Sento puzza di firewall, ma ho lo stesso problema anche staccando tutto e mettendo come ACCEPT la action di default di tutte le chain (sia in v4 che in v6, tanto per essere sicuri)

 Ci sono 3 mandate di "FAILED -> INCOMPLETE" poi misteriosamente viene rilevato il link-local del server, entra in DELAY (ed in questa precisa fase il server è pingabile in v6) e, senza motivo, torna in failed.
 
Per precisione: pinga esattamente 7 secondi, per poi tornare in FAILED per ulteriori 30 secondi e ricomincia a pingare altri 7. E così via...

 Per precisione: pinga esattamente 7 secondi, per poi tornare in FAILED per ulteriori 30 secondi e ricomincia a pingare altri 7. E così via...
 
Output tcpdump, fatto da dentro il gateway sulla interfaccia che guarda il server, con un ping6 verso 
ipv6.google.com
 in esecuzione perenne sul server: 
http://pastebin.com/raw.php?i=cuAfgmP9
 
 
Inizialmente non c'è risposta agli echo (o meglio, non c'è sulla interfaccia che guarda il server perchè, IMHO, il gateway non ha idea di dove si l'ip in questione quindi non instrada), poi, non capisco il motivo, il server invia richieste di "neighbor solicitation", il gateway risponde, ed il ping va a buon fine.
 
Poi buio, dopo pochi secondi il gateway perde nuovamente la visibilità del gateway e tutto si blocca.

 Sento puzza di firewall, ma ho lo stesso problema anche staccando tutto e mettendo come ACCEPT la action di default di tutte le chain (sia in v4 che in v6, tanto per essere sicuri)
 
 
Se stai segando traffico ICMPv6 senza avere dimestichezza con il
funzionamento dei vari discovery protocol, hai esattamente quel genere
di comportamento (discovery funziona quando iniziato da un lato, ma non
dall'altro).
 
Vale per entrambi "i lati".

 Vale per entrambi "i lati".
 
Non sto segando nulla, come scritto sopra, ho provato anche mettendo tutto in ACCEPT quindi con firewall non attivo.
 
In passato mi avevi già detto, infatti, che l'icmp funziona diversamente su v6 rispetto a v4, quindi in v6 accetto tutto (come icmp), ma in questo caso, accetto tutto di tutto, ho il firewall spento.

 dall'altro).
 
gw: 
 # ip6tables -I INPUT -j ACCEPT
 # ip6tables -I OUTPUT -j ACCEPT
 
server:
 # ip6tables -I INPUT -j ACCEPT
 # ip6tables -I OUTPUT -j ACCEPT
 
non cambia niente.


Difficile fare ipotesi su cosa stia accadendo senza conoscere il resto
della rete.
 
Controlla che il MAC address di destinazione dei frame che lasciano il
tuo server prima dell'avvenuto "handshake" di NA con il gateway "vero"
sia realmente quello del router.
 
Se non lo è, potrebbe essere che un apparato su una delle subnet cui si
affaccia il tuo server stia annunciando RA e il tuo server le stia
accettando, con il risultato di cercare di uscire attraverso un IP che
non gli consente routing (ad esempio droppando i pacchetti del caso).
 
Potrebbero esserci almeno un altro paio di casistiche con effetti
simili: vedi la sessione di debug come un modo per imparare di più su IPv6.
 
Come consiglio generale, disabilita (via sysctl) tutti gli automatismi
che ti tolgono controllo sul comportamento del tuo sistema...

 simili: vedi la sessione di debug come un modo per imparare di più su IPv6.
 
Casistiche del tipo ? E' da settimana scorsa che ci sbatto la testa senza vederne una uscita. Mi sto avvilendo.

 non gli consente routing (ad esempio droppando i pacchetti del caso).
 
Non ci sono RA anomali.
Ciò che vedo è il seguente:
 
- server (tramite il proprio link-local) invia "neighbor solicitation" per conoscere il link-local del router
- router risponde con un "neighbor advertisement" indicando il suo ip:
 
fe80::1c8c:47ff:fe9f:5839 > x::254: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has x::254
  source link-address option (1), length 8 (1): 1e:8c:47:9f:58:39
    0x0000:  1e8c 479f 5839
 
x::254 > fe80::1c8c:47ff:fe9f:5839: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is x::254, Flags [router, solicited]
 
 
Non so perchè, ma il server ignora la richiesta e la ripete identica, ignorando anche la seconda.
 
Poi fa la stessa richiesta verso "ff02::1:ff00:254" (che dovrebbe essere un multicast), il router risponde ed il server accetta il link-local:
 
x::254 > server: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is x::254, Flags [router, solicited, override]
  destination link-address option (2), length 8 (1): 00:26:55:de:bf:91
    0x0000:  0026 55de bf91
 
 
Da qui, il ping inizia a funzionare per 7 secondi poi smette.

 Da qui, il ping inizia a funzionare per 7 secondi poi smette.
 
Secondo me il problema non è sul ND, che a quanto pare funziona bene, quando parte, trova l'host e lo "rende raggiungibile" bensì sulla tabella dei neighbour.
e' come se venisse svuotata automaticamente e/o il neighbour non venisse salvato a dovere.
 
Ho già controllato eventuali errori di tabella piena, ma non è questo il caso.
Nonostante ciò, altri host in v6 restano correttamente nella tabella ma sono tutti instradati staticamente.
Ho quindi provato a settare una rotta statica per uno dei server problematici senza alcun beneficio.
 
Non so più dove sbattere la testa. Ogni suggerimento è be accetto.

 Secondo me il problema non è sul ND, che a quanto pare funziona bene, quando parte, trova l'host e lo "rende raggiungibile" bensì sulla tabella dei neighbour.
 
 
Rettifico, il problema è nel ND, in quanto settando manualmente il neighbour:
 
# ip -6 neigh add <ipv6> lladdr <lladdr> dev bond1
 
tutto funziona, riesco a pingare il mondo senza alcuna complicazione.
 
Quindi la problematica risiede nel ND, il più è capire cosa causa l'errato inserimento in tabella e/o cosa ne causa la rimozione di una entry valida.
 
Tipico malfunzionamento causato da firewall ma io non ho un firewall attivo in questo momento (devo usare solo "ip6tables", trattandosi di ipv6, no?)
 

 ipv6, no?)
 
 
Da firewall o, in generale, da cose che rompano multicast per IPv6.

 Da firewall o, in generale, da cose che rompano multicast per IPv6.
 
Il firewall non c'è, ho verificato quelle 80 volte.
Cos'altro potrebbe rompere il multicast v6?
 
I server in questione sono virtualizzati su Xen, ma dubito possa avere qualche importanza.
In mezzo ci sono dei cisco 3750G e 2960 che però non hanno alcun tipo di filtro, solo vlan ed etherchannel

 Da firewall o, in generale, da cose che rompano multicast per IPv6.
 
Ulteriore stranezza, se faccio un bel
 
 sudo ping6 ff02::1 -I bond1
 
ricevo risposte da tutti gli host ipv6 connessi a bond1