PowerScale : Déconnexion intermittente des adresses IP dynamiques du nœud PowerScale
Summary: Cet article décrit la déconnexion intermittente des adresses IP dynamiques des nœuds PowerScale lors d’un redémarrage ou d’une mise à niveau consécutifs. Cela se produit en raison d’entrées ARP (Address Resolution Protocol) non valides sur le client. ...
Symptoms
Lors d’un redémarrage ou d’une mise à niveau consécutive, certains clients situés sur le même sous-réseau que le cluster PowerScale peuvent se déconnecter des adresses IP dynamiques PowerScale. Seuls les clients sur le même sous-réseau avec le cluster Isilon ont le problème. Les clients ne peuvent même pas envoyer un ping aux adresses IP dynamiques présentant le problème. Cela peut également se produire sur les autres nœuds de ce même cluster Isilon. Certains nœuds du cluster ne peuvent pas envoyer de ping à des adresses IP dynamiques sur d’autres nœuds. La vérification de la table ARP sur une machine client qui ne peut pas envoyer de ping à une adresse IP dynamique affiche une entrée non valide. La table ARP contient toujours l’ancienne entrée qui mappe l’adresse IP dynamique à la mauvaise adresse MAC.
Par exemple, le nœud 11 a redémarré et l’adresse IP dynamique 10.x.x.43 a été déplacée vers le nœud 10 pour éviter les interruptions de service. Ensuite, le nœud 1 a commencé à ne pas pouvoir envoyer de ping à l’adresse IP.
Après avoir examiné la table ARP sur le nœud 1, l’entrée pour le nœud 11 n’était pas valide. Il a montré que l’adresse IP 10.x.x.43 était toujours mappée à l’adresse MAC ec :0d :xx :xx :c5:00 du nœud 11.
node-1# arp -a ? (10.x.x.43) at ec:0d:xx:xx:c5:00 on mlxen1 expires in 232 seconds [ethernet]
L’adresse MAC du nœud 11 est ec :0d :xx :xx :c5:00.
node-11: mlxen0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 node-11: options=d07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE> node-11: ether ec:0d:xx:xx:c5:00 node-11: inet 10.x.x.43 netmask 0xffffff00 broadcast 10.x.x.255 zone 1 node-11: nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> node-11: media: Ethernet autoselect (40Gbase-CR4 <full-duplex,rxpause,txpause>) node-11: status: active
Lors du redémarrage du nœud 11, l’adresse IP 10.x.x.43 a été déplacée vers le nœud 10.
2018-11-15T16:06:45+09:00 <3.6> node-1 isi_smartconnect[5222]: Assigned unused IP 10.x.x.43 to { key=10,40gige-1 addr_idx=0 lni=40gige-1 nic=mlxen0[Up] vlan_nic=<NULL> addrs={ 10.x.x.43 } } . 2018-11-15T16:06:45+09:00 <3.6> node-1 isi_smartconnect[5222]: FLXAPI: OP: FLXAPI_OP_CURRENT_STATE Pool[2:1:1:1]: subnet0 zones: filer25.xxx.com IP[18]: 10.x.x.21:up IP[18]: 10.x.x.54:up IP[17]: 10.x.x.32:up IP[17]: 10.x.x.56:up IP[17]: 10.x.x.30:up IP[16]: 10.x.x.37:up IP[16]: 10.x.x.39:up IP[16]: 10.x.x.45:up IP[15]: 10.x.x.29:up IP[15]: 10.x.x.33:up IP[15]: 10.x.x.49:up IP[14]: 10.x.x.31:up IP[14]: 10.x.x.34:up IP[13]: 10.x.x.38:up IP[13]: 10.x.x.40:up IP[13]: 10.x.x.46:up IP[12]: 10.x.x.41:up IP[12]: 10.x.x.36:up IP[10]: 10.x.x.53:up IP[10]: 10.x.x.43:up IP[9]: 10.x.x.44:up IP[9]: 10.x.x.28:up IP[8]: 10.x.x.51:up IP[8]: 10.x.x.26:up IP[7]: 10.x.x.55:up IP[7]: 10.x.x.35:up IP[6]: 10.x.x.42:up IP[6]: 10.x.x.24:up IP[5]: 10.x.x.52:up IP[5]: 10.x.x.25:up IP[4]: 10.x.x.48:up IP[4]: 10.x.x.50:up IP[3]: 10.x.x.22:up IP[3]: 10.x.x.27:up IP[2]: 10.x.x.47:up IP[2]: 10.x.x.23:up
L’adresse MAC du nœud 10 est ec :0d :xx :xx :c0:80.
node-10: mlxen0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 node-10: options=d07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE> node-10: ether ec:0d:xx:xx:c0:80 node-10: inet 10.x.x.43 netmask 0xffffff00 broadcast 10.x.x.255 zone 1 node-10: nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> node-10: media: Ethernet autoselect (40Gbase-CR4 <full-duplex,rxpause,txpause>) node-10: status: active
L’entrée ARP sur le nœud 1 a été mappée à une (ancienne) adresse MAC non valide. Cela empêche tout client ou nœud de connecter l’adresse IP jusqu’à ce qu’elle soit corrigée.
Cause
Selon les « Considérations relatives à la conception du réseau PowerScale https://infohub.delltechnologies.com/es-es/t/dell-powerscale-network-design-considerations/
« Une zone SmartConnect avec allocation dynamique pour les adresses IP déplace immédiatement à chaud l’adresse IP du nœud en échec vers l’un des trois autres nœuds du cluster. Il envoie plusieurs demandes ARP (Address Resolution Protocol) gratuites au commutateur connecté, de sorte que les E/S client se poursuivent sans interruption.
»Les hôtes sur le même sous-réseau n’ont pas reçu de paquets ARP gratuits (GARP) du nœud 10 après l’attribution de l’adresse IP. Par conséquent, l’entrée ARP n’a pas été mise à jour correctement sur les hôtes, ce qui entraîne un problème de connexion réseau. La cause est que les diffusions ARP sont soit abandonnées, soit bloquées au niveau du réseau. L’infrastructure centrée sur les applications (ACI) de Cisco a contribué à ces problèmes en raison d’une mauvaise configuration.
Resolution
Solution :
En tant que solution à long terme, « l’inondation ARP gratuite » doit être activée côté commutateur.
Les articles de la base de connaissances suivants sont destinés à décrire (en détail) les recommandations cumulatives avec Cisco ACI.
- [000032487] Détection des adresses IP non autorisées dans les commutateurs réseau Cisco ACI
- [000028116] Les clients se déconnectent après un changement d’adresse IP et l’utilisation de Cisco ACI
Solution de contournement :
Pour contourner ce problème, l’entrée ARP obsolète peut être supprimée à l’aide de la commande « arp -d » sur les hôtes concernés. Les hôtes diffusent une nouvelle demande de résolution ARP pour l’adresse IP et mettent à jour leurs tables ARP avec l’adresse MAC mise à jour.
Additional Information
Ce problème peut être résolu plus avant avec une capture de paquets sur tous les nœuds PowerScale et toutes les machines clientes. Cela prouve que le nœud a reçu les paquets GARP comme prévu. Toutefois, l’hôte rencontrant le problème n’a pas reçu les paquets GARP.
Lorsque l’adresse IP 10.x.x.43 a été déplacée vers le nœud 10, le nœud 10 a effectivement envoyé des paquets GARP concernant l’adresse IP 10.x.x.43.
[~]$ tshark -t ad -r node-10_mlxen0.pcap | grep ARP | grep Gratui 3781 2018-11-15 16:06:47.711230 ec:0d:xx:xx:c0:80 Broadcast ARP 42 Gratuitous ARP for 10.x.x.43 (Request) 3783 2018-11-15 16:06:47.753820 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3784 2018-11-15 16:06:47.753841 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3791 2018-11-15 16:06:48.823611 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3792 2018-11-15 16:06:48.823633 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3799 2018-11-15 16:06:49.835902 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3800 2018-11-15 16:06:49.835926 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3807 2018-11-15 16:06:50.933966 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3808 2018-11-15 16:06:50.934000 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3815 2018-11-15 16:06:52.034005 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3816 2018-11-15 16:06:52.034048 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3824 2018-11-15 16:06:53.084292 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3825 2018-11-15 16:06:53.084343 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3832 2018-11-15 16:06:54.134719 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3833 2018-11-15 16:06:54.134764 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3840 2018-11-15 16:06:55.222125 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3841 2018-11-15 16:06:55.222171 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3848 2018-11-15 16:06:56.283997 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3849 2018-11-15 16:06:56.284023 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3856 2018-11-15 16:06:57.370114 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request) 3857 2018-11-15 16:06:57.370142 ec:0d:xx:xx:c0:80 Broadcast ARP 60 Gratuitous ARP for 10.x.x.43 (Request)
La capture de paquets montre que le nœud 1 n’a reçu aucun paquet GARP en ce qui concerne le mouvement de l’adresse IP 10.x.x.43.
[~]$ tshark -t ad -r node-1_mlxen1.pcap | grep -i arp | grep Gratuitous | grep 10.x.x.43 [~]$
La capture de paquets montre que le client n’a pas non plus reçu les paquets GARP.
[~]$ tshark -t ad -r client.pcap | grep ARP | grep Gratuitous | grep 10.x.x.43 [~]$
Lorsque les hôtes ne reçoivent pas de paquets GARP, leurs entrées de table ARP pour l’adresse IP 10.x.x.43 ne sont pas mises à jour. Ils sont toujours mappés vers le mauvais MAC ec :0d :xx :xx :c5:00. Par conséquent, ils n’ont pas pu atteindre l’adresse IP 10.x.x.43.