Auteur Sujet: Ubuntu serveur utilise l'IPv6 HS du RA à la place de /etc/network/interfaces (Lu 18417 fois)

kgersen · « **Réponse #36 le:** 21 avril 2018 à 15:31:58 »

je crois surtout que ca concerne tellement peu de monde :

- soit les gens n'ont pas IPv6 d'activé
- soit ils font tout en statique et y'a pas de routeur qui balancent des RA
- soit y'a un routeur qui balance des RA et le SLAAC et/ou les RA sont utilisés.

c'est quand meme un peu la philosophie et le plus d'IPv6 de permettre la conf auto sans bidouiller les adresses a la main.

Apres il est vrai que 'théoriquement' ton cas rare devrait marcher aussi mais ce n'est pas vraiment un bug, chaque composant fonctionne normalement c'est juste un problème d'ordre au boot (networking demarrant avant sysctl ?).

En plus c'est difficile a détecter cela il faut que le RA surviennent pendant la période très courte entre le boot et la prise en compte de procps.conf. Des serveurs ne reboot pas souvent et les RA ne sont pas fréquents (intervalle 30 secondes par défaut sur Cisco il me semble).

A mon avis il faut aussi vérifier quand tu fais le sysctl au boot. Sous Systemd y'a des changements d'ordre aussi (par exemple ne rien mettre dans /etc/sysctl.conf sous systemd).

vivien · « **Réponse #37 le:** 23 avril 2018 à 22:29:09 »

Commande tcpdump pour voir si vous avez des "router advertisement" sur vos serveurs : tcpdump -n -i eth0 icmp6 and ip6[40] == 134

Code: [Sélectionner]

# tcpdump -n -i enp1s0f0 icmp6 and ip6[40] == 134
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp1s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:21:30.795827 IP6 fe80::2a52:61ff:fed7:84c2 > ff02::1: ICMP6, router advertisement, length 96
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel

avec l'option -v :

Code: [Sélectionner]

# tcpdump -v -n -i enp1s0f0 icmp6 and ip6[40] == 134
tcpdump: listening on enp1s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:34:16.754662 IP6 (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 96) fe80::2a52:61ff:fed7:84c2 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 96
	hop limit 64, Flags [none], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
	  source link-address option (1), length 8 (1): 28:52:61:d7:84:c2
	  prefix info option (3), length 32 (4): 2001:860:de01:1101::/64, Flags [onlink, auto], valid time 2592000s, pref. time 604800s
	  prefix info option (3), length 32 (4): 2001:860:deff:1001::/64, Flags [onlink, auto], valid time 2592000s, pref. time 604800s
	  mtu option (5), length 8 (1):  1500

wobble · « **Réponse #38 le:** 02 septembre 2021 à 19:48:08 »

Hello, si ça en intéresse certains, ce problème qui est dû à une race condition (le kernel prend une IPv6 et passerelle via autoconf avant ifup) a été corrigé « récemment » dans ifupdown : https://salsa.debian.org/debian/ifupdown/-/commit/3fb794b2dc1f16da09409522826142ef5e226ddc.
Le commit est inclus dans ifupdown v0.8.36 qui n'est arrivé que dans Bullseye.

Le problème avait été à moitié résolu (suppression de l'IPv6 d'autoconf mais pas de la passerelle) dans https://salsa.debian.org/debian/ifupdown/-/commit/fe9fb5882ab5d238122d986454b0d156477bc8d0.

@vivien, pas besoin de mettre accept_ra 0, c'est déjà fait par défaut quand tu spécifies la passerelle: https://salsa.debian.org/debian/ifupdown/-/commit/aa9b12d76a8cc3fb919fc64d624a45f3eca86444
Tu peux d'ailleurs le voir dans la sortie de ifup -v:

Code: [Sélectionner]

/sbin/sysctl -q -e -w net.ipv6.conf.eno0.accept_ra=0
/sbin/sysctl -q -e -w net.ipv6.conf.eno0.autoconf=0

vivien · « **Réponse #39 le:** 02 septembre 2021 à 21:06:00 »

Merci wobble pour le retour.

Les bugs qui ne sont pas reproduits systématiquement, ce sont les plus compliqués à corriger.

Le challenge pour faire un système d'exploitation de zéro est important.
Pourtant certains s'y essayent : https://linuxfr.org/news/haiku-r1-beta-3-haiku-a-20-ans