Newsgroup: it.comp.os.linux.sys
Titolo: Blocco Network IPv6

Buongiorno a tutti,
mi succede una cosa strana con 2 server creati in parallelo in cui uno
e' il backup dell'altro: su uno il network IPv6 si "spegne" e non
riparte se non con un riavvio.
 
In pratica, 2 server DNS con Debian 7 hanno la stessa configurazione in
/etc/network/interfaces
 
iface eth0 inet6 static
        address 2001:10:9:8::7
        netmask 64
        gateway 2001:10:9:8:FF:FF:FF:FF
 
(ovviamente cambia l'indirizzo IP)
 
Quando li avvio funzionano alla perfezione ma poi, dopo un tot di tempo,
uno dei due smette di rispondere in IPv6 perche' si perde le rotte
attive:
 
prima:
 
ip -6 route show
2001:10:9:8::/64 dev eth0  proto kernel  metric 256 
2001:10:9:8::/56 dev eth0  proto kernel  metric 256  expires 2592138sec
fe80::/64 dev eth0  proto kernel  metric 256 
ff00::/8 dev eth0  metric 256 
default via fe80::12bd:18ff:fee5:2280 dev eth0  proto kernel  metric
1024  expires 1776sec hoplimit 64
default via fe80::128c:cfff:fe28:3980 dev eth0  proto kernel  metric
1024  expires 1776sec hoplimit 64
 
dopo:
 
ip -6 route show
2001:10:9:8::/64 dev eth0  proto kernel  metric 256 
2001:10:9:8::/56 dev eth0  proto kernel  metric 256  expires 2589035sec
fe80::/64 dev eth0  proto kernel  metric 256 
ff00::/8 dev eth0  metric 256 
 
L'altro invece non ha questo problema eppure sono stati creati e
configurati insieme, fanno le stesse cose, hanno gli stessi paccheti
installati, ecc...
Qualche idea sul perche' uno perda le rotte e l'altro no?
Qualche idea su come potrei ovviare al problema?
Grazie!
-- 
Jey
-- 
Non prendere la vita troppo sul serio... non ne uscirai mai vivo
http://www.joram.it/servizi/consulente.htm
 

 
 
ip6tables? (hint: occhio a non segare NDP e famiglia)

 ip6tables? (hint: occhio a non segare NDP e famiglia)
 
Purtroppo non credo che sia lui il responsabile :'(
 
ip6tables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT


 -P OUTPUT ACCEPT
 
Verifica anche lato gateway, però. ^_^
 
Ciò detto, non è la prima volta che mi riportano problemi di 'sto
genere. "guidando" remotamente chi vi è coinvolto, è certo che il
problema è nel dialogo NDP, ma finora non ho avuto modo di mettere le
mani direttamente su un sistema che manifestasse il problema, quindi non
ho debug di prima mano.
 
La costante dei (due) casi che m'han precedentemente segnalato è il
fatto che sia host che GW sono(erano) linux.
 
E' anche il tuo caso?
 

 fatto che sia host che GW sono(erano) linux.
 
Purtroppo non ho notizie in merito ai gw usati da OVH.
Mi sorge il dubbio, leggendo qua e la' su zio G, che possa essere un
problema di subnet visto che una /64 e' enorme ma in tutta la
documentazione di OVH c'e' scritto che loro hanno una /32 e quindi
assegnano ad ogni server una /64.
Ho provato a scrivere sul loro inutile forum, vediamo se rispondono.


 assegnano ad ogni server una /64.
 
Quella a dire il vero è l'assegnazione standard (e per quanto "enorme",
la /32 che ha OVH è quella che ottiene qualunque LIR quando richiede una
allocazione v6)...
 

 allocazione v6)...
E non è l'unica... Ne ha una per ogni azienda che controlla (quindi una /32 qui in europa, 
una in Canada, una per Kimsufi etc). Anche io son cliente OVH e ti dirò esperienza mia: 
hanno problemi sui router di confine (anche il mio v6 è irraggiungibile), ma solo alcuni server ci cascano.
Affidati al loro supporto (ho trovato tempo fà un thread sul loro forum che lo diceva), 
oppure fai come me e ti fai un tunnel con HE o SIXXS.
 
Ciaps
 

 lo diceva), 
 
Hai idea di come si faccia? Per avere il supporto su kimsufi sembra che
si debba scalare il monte bianco con le racchette da tennis... :-P
 
Grazie comunque :-)


 albori?
 
No, decisamente no. Non hai probabilmente ben chiara la disponibilità di 
indirizzamenti IPv6 e quali sono le politiche di assegnazione.
Nella rcf3177 prima, e nella rfc6177 più recentemente, sono stati 
analizzati i diversi usage case e sono state scritte le regole da 
seguire per l'assegnazione delle classi IPv6. Ne consiglio la lettura.
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

Giusto per completare meglio il quadro...
http://www.ripe.net/ripe/docs/ripe-545
 


 Grazie comunque :-)
 
Posta sul forum .it, lì (se ti và di (_._)) ti rispondono e anche in tempi brevi.
Fai una ricerca, ti ripeto che tempo fa trovai altri thread simili, e per simili 
problematiche, e da quel che sò han sempre risolto... per poi ricascarci 
poco dopo con altri clienti, o gli stessi (network admin o router fallaci?)
 
Saluti
 
 

 brevi.
 
Ho provato ma non mi da il permesso di scrivere. Ho scritto ai
moderatori ma senza risposta.
Per una coppia di server DNS di poche pretese, anche su cloud, che
housing consigli con pieno supporto ad IPv6?


 forse, IPv6 avra' iniziato ad essere usato dai non tecnici piu' evoluti)
 
Ma anche no.
IPv6 è stato *creato* per essere enormemente vasto, al di là dello
scenario ipotizzato.
 
La dimensione fissa di ogni subnet è la /64, il che significa fino a
circa 10^19 indirizzi IP disponibili *in ciascuna rete. Il che è un
numero talmente assurdo da essere semplicemente traducibile in "tutti
quelli che mai ti potranno servire" (visto che i limiti imposti
dall'eccessiva vastità del dominio di broadcast intervengono svariati
ordini di grandezza prima di avvicinarsi all'esaurimento delle risorse IP.
 
A loro volta possono esistere circa 10^19 *reti* distinte. Che, di
nuovo, è un numero mostruosamente alto. Stando a wikipedia, è un numero
equiparabile al numero di insetti sulla terra...
 
Ecco, potremmo dar loro una *subnet* a testa, se mai la chiedessero...
 

 Ecco, potremmo dar loro una *subnet* a testa, se mai la chiedessero...
 
E qui si torna al mio pieno supporto per i Gechi: godono di tutta la mia
stima proprio perche' mangiano gli insetti (in particolare le zanzare) e
quindi, se mai dovessi dare a qualcuno una /32, prima che ad OVH
sarebbero loro ;-)
