PowerScale: Zeitweilige Unterbrechung der Verbindung zu dynamischen IPs des PowerScale-Node
Summary: In diesem Artikel wird die zeitweilige Trennung der dynamischen IP-Adressen von PowerScale Nodes während eines sequenziellen Neustarts oder sequenziellen Upgrades beschrieben. Dies geschieht aufgrund ungültiger (alter) ARP-Einträge (Address Resolution Protocol) auf dem Client. ...
Symptoms
Während eines sequenziellen Neustarts oder Upgrades trennen einige Clients im selben Subnetz wie der PowerScale-Cluster möglicherweise die Verbindung zu den dynamischen IP-Adressen von PowerScale. Nur die Clients im selben Subnetz mit dem Isilon-Cluster haben das Problem. Die Clients können nicht einmal die dynamischen IPs mit dem Problem anpingen. Dies kann auch bei den anderen Nodes im selben Isilon-Cluster der Fall sein. Einige Nodes im Cluster können keine dynamischen IPs auf anderen Nodes anpingen. Wenn Sie die ARP-Tabelle auf einem Clientcomputer überprüfen, der eine dynamische IP-Adresse nicht anpingen kann, wird ein ungültiger Eintrag angezeigt. Die ARP-Tabelle enthält immer noch den alten Eintrag, der die dynamische IP der falschen MAC-Adresse zuordnet.
Beispielsweise wurde Node 11 neu gestartet und die dynamische IP 10.x.x.43 wurde auf Node 10 verschoben, um Ausfallzeiten zu vermeiden. Dann begann Node 1, die IP nicht zu pingen.
Nach Überprüfung der ARP-Tabelle auf Node 1 war der Eintrag für Node 11 ungültig. Es zeigte sich, dass IP 10.x.x.43 immer noch der MAC ec:0d:xx:xx:c5:00 von Node 11 zugeordnet war.
node-1# arp -a ? (10.x.x.43) at ec:0d:xx:xx:c5:00 on mlxen1 expires in 232 seconds [ethernet]
Die MAC-Adresse für Node 11 lautet 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
Wenn Node 11 neu gestartet wird, wurde IP 10.x.x.43 auf Node 10 verschoben.
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
Die MAC-Adresse für Node 10 lautet 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
Der ARP-Eintrag auf Node 1 wurde einer ungültigen (alten) MAC-Adresse zugeordnet. Dies führt dazu, dass alle Clients oder Nodes die IP-Adresse nicht verbinden können, bis sie korrigiert wurden.
Cause
Gemäß den Überlegungen
zum PowerScale-Netzwerkdesign https://infohub.delltechnologies.com/es-es/t/dell-powerscale-network-design-considerations/
"verschiebt eine SmartConnect-Zone mit dynamischer Zuweisung für IP-Adressen die eine IP-Adresse auf dem ausgefallenen Node sofort im laufenden Betrieb auf einen der anderen drei Nodes im Cluster. Er sendet mehrere unentgeltliche ARP-Anforderungen (Address Resolution Protocols) an den angeschlossenen Switch, sodass die Client-I/O ohne Unterbrechung fortgesetzt wird."
Die Hosts im selben Subnetz haben nach der Zuweisung der IP-Adresse keine GARP-Pakete (Gratuitous ARP) von Node 10 empfangen. Daher wurde der ARP-Eintrag auf den Hosts nicht ordnungsgemäß aktualisiert, was zu einem Netzwerkverbindungsproblem führt. Die Ursache dafür ist, dass ARP-Broadcasts entweder verworfen oder auf Netzwerkebene blockiert werden. Cisco Application Centric Infrastructure (ACI) hat aufgrund von Fehlkonfigurationen zu diesen Problemen beigetragen.
Resolution
Lösung:
Als langfristige Lösung muss auf der Switchseite "Gratuitous ARP Flooding" aktiviert werden.
In den folgenden Wissensdatenbank-Artikeln werden kumulative Empfehlungen mit Cisco ACI (im Detail) beschrieben.
- [000032487] Erkennung nicht autorisierter IP-Adressen in Cisco ACI-Netzwerkswitches
- [000028116] Clients werden getrennt, nachdem die IP-Adresse verschoben wurde und Cisco ACI verwendet wird.
Problemumgehung:
Als Workaround könnte der veraltete ARP-Eintrag mit dem Befehl "arp -d" auf den betroffenen Hosts gelöscht werden. Die Hosts senden eine neue ARP-Auflösungsanfrage für die IP und aktualisieren ihre ARP-Tabellen mit der aktualisierten MAC-Adresse.
Additional Information
Dieses Problem kann mit einer Paketerfassung auf allen PowerScale-Nodes und Client-Computern weiter behoben werden. Dies beweist, dass der Node die GARP-Pakete wie vorgesehen empfangen hat. Der Host, auf dem das Problem aufgetreten ist, hat jedoch keine GARP-Pakete empfangen.
Als IP 10.x.x.43 auf Node 10 verschoben wurde, sendete Node 10 tatsächlich GARP-Pakete bezüglich 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)
Die Paketerfassung zeigt, dass Node 1 keine GARP-Pakete bezüglich der Verschiebung von IP 10.x.x.43 empfangen hat.
[~]$ tshark -t ad -r node-1_mlxen1.pcap | grep -i arp | grep Gratuitous | grep 10.x.x.43 [~]$
Die Paketerfassung zeigt, dass der Client die GARP-Pakete ebenfalls nicht empfangen hat.
[~]$ tshark -t ad -r client.pcap | grep ARP | grep Gratuitous | grep 10.x.x.43 [~]$
Wenn die Hosts keine GARP-Pakete empfangen, wurden ihre ARP-Tabelleneinträge für IP 10.x.x.43 nicht aktualisiert. Sie sind immer noch dem falschen MAC ec:0d:xx:xx:c5:00 zugeordnet. Daher konnten sie die IP 10.x.x.43 nicht erreichen.