Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Routeur IPv6

20 réponses
Avatar
JKB
Bonjour à tous,

J'ai un petit souci de routage IPv6 sur une connexion Wimax.

Je m'explique. Ma connexion Wimax n'est que IPv4, ce qui me pose un
certain nombre de problèmes. Pour obtenir une connectivité IPv6, je
tape donc sur un relais (qui est connecté à internet au travers
d'une connexion ADSL2+ et d'une seconde VDSL2).

WIMAX(IPV4)-----------routeur Netbsd----+-----LAN0
| +-----LAN1
OpenVPN IPv4+IPv6
|
ADSL(IPV4)---------+--routeur Linux-----------LAN2
VDSL2(IPV4+IPV6)---+

J'espère que le schéma est clair. Le lien entre les deux routeurs
est un OpenVPN des familles en UDP et en niveau 2 (tap). Il
fonctionne très bien, il me faut 40 ms pour un ping entre les deux
machines distantes de plus de 500 bornes.

Côté Linux, j'ai :
tap1 Link encap:Ethernet HWaddr 2e:3c:d2:18:9e:53
...
adr inet6: fe80::2c3c:d2ff:fe18:9e53/64 Scope:Lien
adr inet6: 2001:7a8:a8ed:1::1/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1418 Metric:1

Côté NetBSD ,ifconfig renvoie :
tap0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1414
...
inet6 fe80::f00b:a4ff:fe0c:5476%tap0 prefixlen 64 scopeid 0x8
inet6 2001:7a8:a8ed:1::2 prefixlen 64

Je ne sais pas pourquoi la MTU est différente des deux côtés, les
mêmes paramètres sont envoyés au fichier de conf d'OpenVPN. Je ne
pense pas que le résultat soit un souci de MTU.

À partir d'une machine sur le LAN0 (ou LAN1 voire du routeur NetBSD
lui-même), j'arrive toujours à faire un ping sur le routeur Linux en
IPv6. En revanche, lorsque je tape un ping par exemple sur google.fr en
IPv6, cela commence par fonctionner, puis ça s'arrête (host unreachable),
puis cela revient... Et ça part en boucle, trente secondes de
fonctionnement, puis un 'network unreachable' et ceci continuellement.
D'une machine du LAN2, en revanche, la résolution IPv6 semble toujours
fonctionnelle.

Depuis les LAN0 et 1, lorsqu'un ping vers l'extérieure me renvoie
'unreachable', j'arrive toujours à pinger l'adresse IPv6 du routeur
Linux. OpenVPN ne semble donc pas responsable. Mais dans ce cas, je
ne vois pas bien la différence entre la configuration du LAN2 et des
LAN0/1 vis à vis de l'extérieur. Le modem semble enfin hors de cause
depuis la dernière mise à jour de ZyXEL (il y a encore des
problèmes, mais plus de souci de stabilité de la liaison IPv6).

Je dois préciser que toutes les adresses IPv6 sont déclarées en
statique.

Sur le routeur Linux, j'ai installé radvd et son fichier de
configuration est le suivant :

interface eth0
{
AdvSendAdvert on;
AdvLinkMTU 1446;

prefix 2001:7a8:a8ed::/64
{
};

RDNSS 2001:7a8:a8ed::128
{
};
};

interface tap1
{
AdvSendAdvert on;
AdvLinkMTU 1364;

prefix 2001:7a8:a8ed:1::/64
{
};

RDNSS 2001:7a8:a8ed:1::1
{
};
};

Sur le routeur NetBSD, rien de tout cela.

J'avoue que ce fonctionnement me dépasse.

Une idée ?

Bien cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

10 réponses

1 2
Avatar
Pascal Hambourg
Salut,

JKB a écrit :

À partir d'une machine sur le LAN0 (ou LAN1 voire du routeur NetBSD
lui-même), j'arrive toujours à faire un ping sur le routeur Linux en
IPv6. En revanche, lorsque je tape un ping par exemple sur google.fr en
IPv6, cela commence par fonctionner, puis ça s'arrête (host unreachable),
puis cela revient... Et ça part en boucle, trente secondes de
fonctionnement, puis un 'network unreachable' et ceci continuellement.
D'une machine du LAN2, en revanche, la résolution IPv6 semble toujours
fonctionnelle.



"Host unreachable" ou "network unreachable" ?
Host unreachable = problème de résolution d'adresse.
Network unreachable = problème de route.

Emis par quelle adresse/machine/interface ?

Sur le routeur NetBSD, rien de tout cela.



C'est-à-dire ?
Avatar
JKB
Le Mon, 31 Aug 2015 21:58:08 +0200,
Pascal Hambourg écrivait :
Salut,

JKB a écrit :

À partir d'une machine sur le LAN0 (ou LAN1 voire du routeur NetBSD
lui-même), j'arrive toujours à faire un ping sur le routeur Linux en
IPv6. En revanche, lorsque je tape un ping par exemple sur google.fr en
IPv6, cela commence par fonctionner, puis ça s'arrête (host unreachable),
puis cela revient... Et ça part en boucle, trente secondes de
fonctionnement, puis un 'network unreachable' et ceci continuellement.
D'une machine du LAN2, en revanche, la résolution IPv6 semble toujours
fonctionnelle.



"Host unreachable" ou "network unreachable" ?
Host unreachable = problème de résolution d'adresse.
Network unreachable = problème de route.



Typiquement, cela donne ceci :
legendre:[~] > /sbin/ping6 www.nerim.net
PING6(56@+8+8 bytes) 2001:7a8:a8ed:1::2 --> 2001:7a8:2:2001::122
16 bytes from 2001:7a8:2:2001::122, icmp_seq=7 hlimT timef.290 ms
16 bytes from 2001:7a8:2:2001::122, icmp_seq=8 hlimT timee.241 ms
16 bytes from 2001:7a8:2:2001::122, icmp_seq=9 hlimT timee.607 ms
16 bytes from 2001:7a8:2:2001::122, icmp_seq hlimT timed.686 ms
16 bytes from 2001:7a8:2:2001::122, icmp_seq hlimT timef.067 ms
16 bytes from 2001:7a8:2:2001::122, icmp_seq hlimT timep.873 ms
16 bytes from 2001:7a8:2:2001::122, icmp_seq hlimT timee.364 ms
^C

J'ai lancé le ping6 lorsqu'un autre vers www.google.fr était planté :
16 bytes from 2a00:1450:4007:80d::2003, icmp_seqi0 hlimS timed.261 ms
16 bytes from 2a00:1450:4007:80d::2003, icmp_seqi1 hlimS timef.457 ms
16 bytes from 2a00:1450:4007:80d::2003, icmp_seqi2 hlimS timed.402 ms
16 bytes from 2a00:1450:4007:80d::2003, icmp_seqi3 hlimS timee.824 ms
16 bytes from 2a00:1450:4007:80d::2003, icmp_seqt2 hlimS timee.735 ms
^^^
Plus de 45 secondes sans ping.

La résolution de nom a été immédiate, mais la connexion ne s'est
faite qu'après quelques secondes. J'ai pensé un moment que le VPN
tombait puis remontait (les routes sont forcées dans un script lors
du montage de tap0) mais j'ai toujours une connexion IPv4 active et
je peux continuer à pinguer le routeur NetBSD deuyis le routeur
Linux au travers du VPN en IPv6.

J'ai d'autres phénomèmes comme ceci :

16 bytes from 2a00:1450:4007:807::101f, icmp_seq"0 hlimS timed.785 ms
16 bytes from 2a00:1450:4007:807::101f, icmp_seq"1 hlimS timef.246 ms
16 bytes from 2a00:1450:4007:807::101f, icmp_seq"2 hlimS timef.254 ms
16 bytes from 2a00:1450:4007:807::101f, icmp_seq"3 hlimS timee.588 ms
16 bytes from 2a00:1450:4007:807::101f, icmp_seq#0 hlimS time65.945 ms
...
16 bytes from 2a00:1450:4007:807::101f, icmp_seq'0 hlimS timee.619 ms
16 bytes from 2a00:1450:4007:807::101f, icmp_seq'1 hlimS timed.564 ms
16 bytes from 2a00:1450:4007:807::101f, icmp_seq'2 hlimS timee.943 ms
16 bytes from 2a00:1450:4007:807::101f, icmp_seq'3 hlimS timec.940 ms
16 bytes from 2a00:1450:4007:807::101f, icmp_seq'4 hlimS timef.471 ms
16 bytes from 2a00:1450:4007:807::101f, icmp_seq'5 hlimS timee.448 ms
16 bytes from 2a00:1450:4007:807::101f, icmp_seq(2 hlimS time65.082 ms
...
16 bytes from 2a00:1450:4007:807::101f, icmp_seq73 hlimS timee.748 ms
16 bytes from 2a00:1450:4007:807::101f, icmp_seq74 hlimS timef.012 ms
16 bytes from 2a00:1450:4007:807::101f, icmp_seq75 hlimS timef.023 ms
16 bytes from 2a00:1450:4007:807::101f, icmp_seq76 hlimS timee.271 ms
16 bytes from 2a00:1450:4007:807::101f, icmp_seq77 hlimS timed.083 ms
16 bytes from 2a00:1450:4007:807::101f, icmp_seq78 hlimS timed.605 ms
16 bytes from 2a00:1450:4007:807::101f, icmp_seq79 hlimS timef.128 ms
16 bytes from 2a00:1450:4007:807::101f, icmp_seq80 hlimS timed.808 ms
16 bytes from 2a00:1450:4007:807::101f, icmp_seq84 hlimS time67.231 ms

La période d'apparition des 'trous' varie entre 30 secondes et une
minute. Côté VDSL2, lors des interruptions, je vois passer ceci :

23:36:16.984931 IP6 2001:7a8:a8ed:1::2 > par10s09-in-x1f.1e100.net:
ICMP6, echo request, seq 484, length 16
23:36:17.010772 IP6 par10s09-in-x1f.1e100.net > 2001:7a8:a8ed:1::2:
ICMP6, echo reply, seq 484, length 16
23:36:21.982969 IP6 2001:7a8:a8ed:1::2 > par10s09-in-x1f.1e100.net:
ICMP6, echo request, seq 488, length 16

Où sont passées les resques 485, 486 et 487 ? Si je regarde sur le
tap1, elles sont bien envoyées. Mais le routeur Linux répond :

Root rayleigh:[~] > tcpdump -i tap1 -p icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on tap1, link-type EN10MB (Ethernet), capture size 262144
bytes
23:39:30.981680 IP6 2001:7a8:a8ed:1::2 > par10s09-in-x1f.1e100.net:
ICMP6, echo request, seq 678, length 16
23:39:31.980952 IP6 2001:7a8:a8ed:1::2 > par10s09-in-x1f.1e100.net:
ICMP6, echo request, seq 679, length 16
23:39:32.978382 IP6 2001:7a8:a8ed:1::1 > 2001:7a8:a8ed:1::2: ICMP6,
destination unreachable, unreachable address par10s09-in-x1f.1e100.net,
length 64
23:39:32.978424 IP6 2001:7a8:a8ed:1::1 > 2001:7a8:a8ed:1::2: ICMP6,
destination unreachable, unreachable address par10s09-in-x1f.1e100.net,
length 64
23:39:32.978437 IP6 2001:7a8:a8ed:1::1 > 2001:7a8:a8ed:1::2: ICMP6,
destination unreachable, unreachable address par10s09-in-x1f.1e100.net,
length 64
23:39:32.981981 IP6 2001:7a8:a8ed:1::2 > par10s09-in-x1f.1e100.net:
ICMP6, echo request, seq 680, length 16
23:39:33.981433 IP6 2001:7a8:a8ed:1::2 > par10s09-in-x1f.1e100.net:
ICMP6, echo request, seq 681, length 16
23:39:34.980936 IP6 2001:7a8:a8ed:1::2 > par10s09-in-x1f.1e100.net:
ICMP6, echo request, seq 682, length 16
23:39:35.978381 IP6 2001:7a8:a8ed:1::1 > 2001:7a8:a8ed:1::2: ICMP6,
destination unreachable, unreachable address par10s09-in-x1f.1e100.net,
length 64
23:39:35.978423 IP6 2001:7a8:a8ed:1::1 > 2001:7a8:a8ed:1::2: ICMP6,
destination unreachable, unreachable address par10s09-in-x1f.1e100.net,
length 64
23:39:35.978439 IP6 2001:7a8:a8ed:1::1 > 2001:7a8:a8ed:1::2: ICMP6,
destination unreachable, unreachable address par10s09-in-x1f.1e100.net,
length 64
23:39:35.982234 IP6 2001:7a8:a8ed:1::2 > par10s09-in-x1f.1e100.net:
ICMP6, echo request, seq 683, length 16
23:39:36.980943 IP6 2001:7a8:a8ed:1::2 > par10s09-in-x1f.1e100.net:
ICMP6, echo request, seq 684, length 16
23:39:37.006400 IP6 par10s09-in-x1f.1e100.net > 2001:7a8:a8ed:1::2:
ICMP6, echo reply, seq 683, length 16
23:39:37.007554 IP6 par10s09-in-x1f.1e100.net > 2001:7a8:a8ed:1::2:
ICMP6, echo reply, seq 684, length 16

2001:7a8:a8ed:1::2 est l'adresse du routeur NetBSD.

Emis par quelle adresse/machine/interface ?



Je teste depuis le routeur NetBSD, avec la route par défaut au
travers du VPN et sortant par la liaison VDSL2.

Sur le routeur NetBSD, rien de tout cela.



C'est-à-dire ?



Pas de radvd actif.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Avatar
JKB
Le Mon, 31 Aug 2015 21:58:08 +0200,
Pascal Hambourg écrivait :
Salut,

JKB a écrit :

À partir d'une machine sur le LAN0 (ou LAN1 voire du routeur NetBSD
lui-même), j'arrive toujours à faire un ping sur le routeur Linux en
IPv6. En revanche, lorsque je tape un ping par exemple sur google.fr en
IPv6, cela commence par fonctionner, puis ça s'arrête (host unreachable),
puis cela revient... Et ça part en boucle, trente secondes de
fonctionnement, puis un 'network unreachable' et ceci continuellement.
D'une machine du LAN2, en revanche, la résolution IPv6 semble toujours
fonctionnelle.





Rectification : depuis le LAN2, j'observe aussi la même chose, mais
plus rarement :

16 bytes from 2a00:1450:400c:c04::5e, icmp_seq=2 hlimQ time0.844 ms
16 bytes from 2a00:1450:400c:c04::5e, icmp_seq=3 hlimQ time0.678 ms
16 bytes from 2a00:1450:400c:c04::5e, icmp_seq=4 hlimQ time).880 ms
16 bytes from 2a00:1450:400c:c04::5e, icmp_seq=5 hlimQ time1.367 ms
16 bytes from 2a00:1450:400c:c04::5e, icmp_seq=6 hlimQ time1.423 ms
16 bytes from 2a00:1450:400c:c04::5e, icmp_seq=7 hlimQ time0.374 ms
16 bytes from 2a00:1450:400c:c04::5e, icmp_seq=8 hlimQ time0.835 ms
16 bytes from 2a00:1450:400c:c04::5e, icmp_seq=9 hlimQ time0.852 ms
16 bytes from 2a00:1450:400c:c04::5e, icmp_seq hlimQ time1.220 ms
16 bytes from 2a00:1450:400c:c04::5e, icmp_seq hlimQ time0.444 ms
16 bytes from 2a00:1450:400c:c04::5e, icmp_seq hlimQ time0.635 ms
16 bytes from 2a00:1450:400c:c04::5e, icmp_seq hlimQ time30.619 ms
16 bytes from 2a00:1450:400c:c04::5e, icmp_seq hlimQ time7.288 ms
16 bytes from 2a00:1450:400c:c04::5e, icmp_seq hlimQ time1.377 ms
16 bytes from 2a00:1450:400c:c04::5e, icmp_seq hlimQ time1.890 ms
16 bytes from 2a00:1450:400c:c04::5e, icmp_seq hlimQ time0.641 ms
16 bytes from 2a00:1450:400c:c04::5e, icmp_seq! hlimQ time).807 ms
...

Les paquets sont en erreur sur :
ICMP6, destination unreachable, unreachable address
lhr08s06-in-x03.1e100.net, length 64

Le VPN n'est donc pas fautif mais semble accentuer le problème.

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Avatar
Pascal Hambourg
JKB a écrit :
Où sont passées les resques 485, 486 et 487 ? Si je regarde sur le
tap1, elles sont bien envoyées. Mais le routeur Linux répond :


(...)
23:39:32.978382 IP6 2001:7a8:a8ed:1::1 > 2001:7a8:a8ed:1::2: ICMP6,
destination unreachable, unreachable address par10s09-in-x1f.1e100.net,
length 64



Si le routeur Linux répond avec un message d'erreur ICMPv6, c'est qu'il
a bien reçu le paquet dont le traitement a provoqué cette erreur, mais
n'a pas pu le faire suivre vers sa destination. Donc a priori le VPN
n'est pas en cause.

La seule cause d'envoi de l'erreur "Unreachable address" en IPv6 que je
connaisse et qui est mentionnée dans la RFC 2463 est l'échec de
résolution NDP de l'adresse link layer du next-hop pour la route de la
destination considérée, qui est je suppose le routeur VDSL. Mais je ne
vois pas comment cela pourrait être le cas ici si en même temps les
paquets émis par d'autres machines continuent à être routés vers
l'extérieur. As-tu regardé le trafic NDP entre le routeur Linux et le
routeur VDSL ? Eventuellement vérifier aussi l'état du cache NDP du
routeur Linux avec "ip -6 neigh" lorsque cela se produit.
Avatar
JKB
Le Thu, 03 Sep 2015 18:09:55 +0200,
Pascal Hambourg écrivait :
JKB a écrit :
Où sont passées les resques 485, 486 et 487 ? Si je regarde sur le
tap1, elles sont bien envoyées. Mais le routeur Linux répond :


(...)
23:39:32.978382 IP6 2001:7a8:a8ed:1::1 > 2001:7a8:a8ed:1::2: ICMP6,
destination unreachable, unreachable address par10s09-in-x1f.1e100.net,
length 64



Si le routeur Linux répond avec un message d'erreur ICMPv6, c'est qu'il
a bien reçu le paquet dont le traitement a provoqué cette erreur, mais
n'a pas pu le faire suivre vers sa destination. Donc a priori le VPN
n'est pas en cause.

La seule cause d'envoi de l'erreur "Unreachable address" en IPv6 que je
connaisse et qui est mentionnée dans la RFC 2463 est l'échec de
résolution NDP de l'adresse link layer du next-hop pour la route de la
destination considérée, qui est je suppose le routeur VDSL. Mais je ne
vois pas comment cela pourrait être le cas ici si en même temps les
paquets émis par d'autres machines continuent à être routés vers
l'extérieur. As-tu regardé le trafic NDP entre le routeur Linux et le
routeur VDSL ? Eventuellement vérifier aussi l'état du cache NDP du
routeur Linux avec "ip -6 neigh" lorsque cela se produit.



De temps en temps, je me prendsun truc comme ceci dans la figure :

2001:7a8:a8ed:253::254 dev eth2 lladdr 28:28:5d:11:bf:23 router
REACHABLE
fe80::7833:6dff:fe47:18f4 dev tap1 lladdr 7a:33:6d:47:18:f4 router STALE
fe80::f00b:a4ff:fefc:e30d dev tap1 lladdr f2:0b:a4:fc:e3:0d router STALE
fe80::f00b:a4ff:fecb:d704 dev tap1 lladdr f2:0b:a4:cb:d7:04 router STALE
2001:7a8:a8ed:1::2 dev tap1 lladdr f2:0b:a4:bc:b8:33 router REACHABLE
fe80::222:15ff:fed9:d2b7 dev eth0 lladdr 00:22:15:d9:d2:b7 router STALE
fe80::f00b:a4ff:febc:b833 dev tap1 lladdr f2:0b:a4:bc:b8:33 router REACHABLE
fe80::2a28:5dff:fe11:bf23 dev eth2 router FAILED

Le modem IPv6 est directement connecté à eth2 (pas de switch, rien).
Je me demande si ce n'est pas la source de mes problèmes.

Remarque : j'ai fait un apt-get dist-upgrade sur le routeur Linux
(debian/testing) et le noyau est passé de 4.0 à 4.1. Depuis,
j'essaie de reproduire les problèmes évoqués ici depuis une machine
derrière mon routeur NetBSD et si j'observe encore quelques lenteurs
inexplicables par moment (correspondant sivielemtn aux FAILED sur
l'adresse locale fe80::2a28:5dff:fe11:bf23 qui est justement mon
modem routeur), je n'ai plus perdu un paquet. Pourvu que ça dure !

--- www.google.fr ping statistics ---
513 packets transmitted, 512 received, 0% packet loss, time 513912ms
rtt min/avg/max/mdev = 64.020/84.054/792.274/81.924 ms

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Avatar
Pascal Hambourg
JKB a écrit :

De temps en temps, je me prendsun truc comme ceci dans la figure :

2001:7a8:a8ed:253::254 dev eth2 lladdr 28:28:5d:11:bf:23 router REACHABLE


(...)
fe80::2a28:5dff:fe11:bf23 dev eth2 router FAILED

Le modem IPv6 est directement connecté à eth2 (pas de switch, rien).
Je me demande si ce n'est pas la source de mes problèmes.



C'est quand même surprenant qu'en même temps la résolution ait réussi
pour l'adresse globale du routeur mais pas pour son adresse link local.

Par curiosité, comment est configurée la route par défaut sur le routeur
Linux ? Automatiquement par RA, statiquement avec l'adresse globale du
routeur VDSL, statiquement avec l'adresse link local, autre ?
Avatar
JKB
Le Sun, 06 Sep 2015 21:24:14 +0200,
Pascal Hambourg écrivait :
JKB a écrit :

De temps en temps, je me prendsun truc comme ceci dans la figure :

2001:7a8:a8ed:253::254 dev eth2 lladdr 28:28:5d:11:bf:23 router REACHABLE


(...)
fe80::2a28:5dff:fe11:bf23 dev eth2 router FAILED

Le modem IPv6 est directement connecté à eth2 (pas de switch, rien).
Je me demande si ce n'est pas la source de mes problèmes.



C'est quand même surprenant qu'en même temps la résolution ait réussi
pour l'adresse globale du routeur mais pas pour son adresse link local.



N'est-ce pas ?

Par curiosité, comment est configurée la route par défaut sur le routeur
Linux ? Automatiquement par RA, statiquement avec l'adresse globale du
routeur VDSL, statiquement avec l'adresse link local, autre ?



Tout est déclaré statiquement. Dans le fichier
/etc/network/interfaces, j'ai mis :

iface eth2 inet6 static
address 2001:7a8:a8ed:253::1
netmask 64
gateway 2001:7a8:a8ed:253::254
mtu 1492
post-up /sbin/ip -6 route add unreachable 2001:7a8:a8ed::/48
pre-down /sbin/ip -6 route del unreachable 2001:7a8:a8ed::/48

Les deux dernières lignes ayant été rajoutées conformément à notre
dernière discussion ici.

La table de routage complète est :
Root rayleigh:[/etc/network] > route -A inet6
Table de routage IPv6 du noyau
Destination Next Hop Flag Met Ref
Use If
2001:7a8:a8ed::/64 :: U 256 0 0 eth0
2001:7a8:a8ed:1::/64 :: U 256 0 1 tap1
2001:7a8:a8ed:10::/64 2001:7a8:a8ed:1::2 UG 1 0 0 tap1
2001:7a8:a8ed:253::/64 :: U 256 0 1 eth2
2001:7a8:a8ed::/48 :: !n 1024 0 0 lo
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth1
fe80::/64 :: U 256 0 0 eth2
fe80::/64 :: U 256 0 0 tap0
fe80::/64 :: U 256 0 0 tap1
::/0 2001:7a8:a8ed:253::254 UG 1024 5 0 eth2
::/0 :: !n -1 1509597 lo
::1/128 :: Un 0 7 11729 lo
2001:7a8:a8ed::/128 :: Un 0 1 0 lo
2001:7a8:a8ed::128/128 :: Un 0 1 0 lo
2001:7a8:a8ed:1::/128 :: Un 0 1 0 lo
2001:7a8:a8ed:1::1/128 :: Un 0 1 1366 lo
2001:7a8:a8ed:253::/128 :: Un 0 1 0 lo
2001:7a8:a8ed:253::1/128 :: Un 0 4 86430 lo
fe80::/128 :: Un 0 1 0 lo
fe80::/128 :: Un 0 1 0 lo
fe80::/128 :: Un 0 1 0 lo
fe80::/128 :: Un 0 1 0 lo
fe80::/128 :: Un 0 1 0 lo
fe80::208:2ff:feaf:da70/128 :: Un 0 1 0 lo
fe80::208:2ff:feaf:da71/128 :: Un 0 1 0 lo
fe80::222:15ff:fed9:d2b7/128 :: Un 0 1 0 lo
fe80::7833:6dff:fe47:18f4/128 :: Un 0 1 3935 lo
fe80::d0dd:60ff:fe3c:2b6f/128 :: Un 0 1 0 lo
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 eth1
ff00::/8 :: U 256 1 0 eth2
ff00::/8 :: U 256 0 0 tap0
ff00::/8 :: U 256 0 0 tap1
::/0 :: !n -1 1509597 lo
Root rayleigh:[/etc/network] >

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Avatar
Pascal Hambourg
JKB a écrit :
Pascal Hambourg écrivait :
JKB a écrit :
De temps en temps, je me prendsun truc comme ceci dans la figure :

2001:7a8:a8ed:253::254 dev eth2 lladdr 28:28:5d:11:bf:23 router REACHABLE


(...)
fe80::2a28:5dff:fe11:bf23 dev eth2 router FAILED






(...)
Tout est déclaré statiquement. Dans le fichier
/etc/network/interfaces, j'ai mis :

iface eth2 inet6 static
address 2001:7a8:a8ed:253::1
netmask 64
gateway 2001:7a8:a8ed:253::254



Dans ce cas pourquoi la machine a-t-elle besoin de résoudre l'adresse
link local du routeur ?
Avatar
JKB
Le Mon, 07 Sep 2015 09:14:50 +0200,
Pascal Hambourg écrivait :
JKB a écrit :
Pascal Hambourg écrivait :
JKB a écrit :
De temps en temps, je me prendsun truc comme ceci dans la figure :

2001:7a8:a8ed:253::254 dev eth2 lladdr 28:28:5d:11:bf:23 router REACHABLE


(...)
fe80::2a28:5dff:fe11:bf23 dev eth2 router FAILED






(...)
Tout est déclaré statiquement. Dans le fichier
/etc/network/interfaces, j'ai mis :

iface eth2 inet6 static
address 2001:7a8:a8ed:253::1
netmask 64
gateway 2001:7a8:a8ed:253::254



Dans ce cas pourquoi la machine a-t-elle besoin de résoudre l'adresse
link local du routeur ?



Que veux-tu que je te dises ? Un mystère linuxien de plus :-)

De mémoire (mais je ne peux pas vérifier présentement), le modem
s'annonce par défaut en radvd. Mais je ne vois pas pourquoi le
routeur Linux s'en servirait puisque toute la configuration est
statique.

Je ne peux virer radvd côté modem (sauf à le remplacer par dhcpd en
IPv6). Je ne vais pas remonter le bug à ZyXEL vu le mal que j'ai eu
pour leur faire corriger des bugs dédhibitoires. Pour info, le
firmware 1.01 du SBG3300N est enfin stable en IPv6 (mais il reste
des bugs dans l'interface).

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Avatar
Pascal Hambourg
JKB a écrit :
Dans ce cas pourquoi la machine a-t-elle besoin de résoudre l'adresse
link local du routeur ?



Que veux-tu que je te dises ? Un mystère linuxien de plus :-)



Une capture des paquets IPv6 avec cette adresse pourrait peut-être en
apprendre plus.

De mémoire (mais je ne peux pas vérifier présentement), le modem
s'annonce par défaut en radvd. Mais je ne vois pas pourquoi le
routeur Linux s'en servirait puisque toute la configuration est
statique.



Par défaut, même avec une configuration statique le noyau Linux utilise
les RA si le fonctionnement en routeur IPv6
(/proc/net/ipv6/conf/<interface>/formwarding) n'est pas activé. Les
adresses et routes IPv6 transmises par RA s'ajouteraient juste à celles
configurées en statique. Il y a dans les noyaux assez récents un réglage
qui permet de prendre en compte les RA même en mode routeur, mais je
suppose que tu n'es pas assez pervers pour l'avoir activé. Ça se verrait
dans la table de routage.
1 2