2 votes

La connectivité IPv6 est soudainement perdue, l'état du routeur voisin IPv6 devient STALE en même temps. Comment puis-je l'éviter ?

J'ai une VM sur un hôte avec un réseau en pont (par conséquent, avec sa propre adresse MAC). L'hôte et la VM exécutent tous deux CentOS. Leur réseau est géré par des fichiers simples /etc/sysconfig/network-scripts/ifcfg-enpXsY qui contiennent les adresses IP statiques. IPv4 fonctionne très bien.

J'ai attribué une adresse IPv6 à la VM (l'hôte en a également une) qui est routée correctement dans le centre de données. Cependant, la plupart des connexions utilisent IPv4 (pas encore d'entrée DNS AAAA pour la machine, testant encore IPv6).

Lorsque je démarre la VM, elle a une connectivité IPv6 complète. Cependant, après un certain temps, la connectivité IPv6 cesse de fonctionner (magie de l'IPv6 ?). J'ai réduit le problème aux données de voisinage (cache ARP/NDISC) :

IPv6 ne fonctionne pas, impossible de faire un ping ou de se connecter en IPv6 vers l'intérieur ou l'extérieur, ensuite je vois :

# ip -6 neighbour 
fe80::1 dev enp1s2 lladdr 0c:86:72:2e:04:28 routeur STALE

Correction/contournement pour rafraîchir le cache :

# ip -6 neighbour flush dev enp1s2
# ip -6 neighbour
(vide, comme prévu)

Ensuite, faire un ping6 sur l'hôte depuis la VM pour remplir le cache :

# ping6 2912:1375:23:9a6c::2
PING 2912:1375:23:9a6c::2(2912:1375:23:9a6c::2) 56 data bytes
64 octets de 2912:1375:23:9a6c::2: icmp_seq=1 ttl=64 temps=2,35 ms
64 octets de 2912:1375:23:9a6c::2: icmp_seq=2 ttl=64 temps=0,468 ms
^C
# ip -6 neighbour
fe80::1 dev enp1s2 lladdr 0c:86:72:2e:04:28 routeur REACHABLE
2912:1375:23:9a6c::2 dev enp1s2 lladdr 08:21:4b:b7:f8:31 DELAY

Le tableau de voisinage ARP IPv6 est restauré à la validité et la connectivité fonctionne vers l'intérieur et l'extérieur !

Donc mes questions sont :

  1. Pourquoi le cache devient-il obsolète ?
  2. Que puis-je faire pour l'éviter ?
  3. Pourquoi/comment la commande ci-dessus le corrige ?

Évidemment, je pourrais exécuter ces commandes dans une tâche cron (à quelle fréquence ?) mais je suppose que cela ne devrait pas vraiment être nécessaire pour qu'IPv6 fonctionne en général ?

PS : J'ai utilisé un script pour les tests : La pile IPv6 tombe en panne environ toutes les 20 minutes. Est-ce que cela peut s'expliquer par les RFC ?

PPS : Configuration du pare-feu (sortie raccourcie, avec espérons-le, tous les éléments pertinents) :

# ip6tables -nvL
Chaîne INPUT (politique DROP 0 paquets, 0 octets)
 paquets octets cible     prot opt in     out     source               destination         
 9023  709K ACCEPT     icmpv6    !lo    *       ::/0                 ::/0                
Chaîne OUTPUT (politique DROP 0 paquets, 0 octets)
 paquets octets cible     prot opt in     out     source               destination         
 9360  785K ACCEPT     icmpv6    *      !lo     ::/0                 ::/0                

Donc, ICMPv6 accepté en entrée/sortie sur la VM. Dois-je vérifier le filtrage sur l'hôte ?

0 votes

Avez-vous configuré des règles de pare-feu qui bloqueraient l'ICMPv6 (y compris le NDP) ?

0 votes

@HåkanLindqvist Merci, probablement non filtré, ajouté ip6tables sortie.

0 votes

Il manque certains détails : Qui est le centre de données ? Comment est mis en place le réseau ponté dans votre hyperviseur (et qu'est-ce que c'est) ? Quel est l'état complet du pare-feu IPv6 ?

1voto

Omid Estaji Points 93

Généralement, un état de mise en attente est une bonne chose, en fait c'est acceptable d'avoir un état de mise en attente.

Jetons un coup d'œil à la RFC 4861, section 5.1. :

  ATTENTE       Le voisin n'est plus connu comme étant atteignable mais tant que le trafic n'est pas envoyé au voisin, aucune tentative ne doit être faite pour vérifier sa joignabilité.

Le voisin n'est plus connu comme étant atteignable (le minuteur a expiré, aucun trafic récemment, peu importe) et la joignabilité sera 'vérifiée' une fois que le trafic sera renvoyé au voisin.

Il n'y a donc aucun problème si vous pouvez renvoyer du trafic au voisin.

0 votes

Merci. Mon problème est que l'hôte perd la connectivité IPv6 - il cesse de répondre aux demandes entrantes lorsque l'état STALE est affiché. Je suppose que les deux problèmes ont la même cause? Comment exactement les commandes ip r et ping que j'ai détaillées dans ma question restaurent-elles la connectivité?

0 votes

Le problème est que je NE PEUX PAS envoyer de trafic au voisin sans ces étapes supplémentaires et l'hôte ne peut pas être atteint de l'extérieur non plus. Alors: Comment et pourquoi la connectivité est-elle perdue? Comment les commandes ip -6 neighbour et ping rétablissent-elles la connectivité? Est-ce que cela peut être fait sans ces étapes? Est-ce que toutes les machines IPv6 exécutent ces étapes périodiquement, ou pourquoi ne perdent-elles pas la connectivité?

0 votes

L'état périmé est une partie normale de la découverte de voisinage IPv6. Lorsqu'un hôte démarre, il fait quelque chose et envoie également un voisinage gratuit Avertisement mais nous n'accepterons pas une nouvelle entrée tant que nous n'aurons pas vu un NA gratuit. Cela diffère du protocole hérité (IPv4), à chaque fois qu'un ARP gratuit est vu, nous ajoutons réellement une entrée au cache. Ici en IPv6, nous n'ajoutons l'entrée au cache que si nous mettons à jour une entrée existante avec ce NA gratuit. Donc, l'état Périmé signifie qu'il ne communique pas actuellement, en attente du prochain paquet en file d'attente. Ensuite, si nous envoyons un paquet, l'état peut passer en Délai, et attendra que les protocoles de couche supérieure renvoient le trafic.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X