PowerScale: Періодичне відключення від динамічних IP вузлів PowerScale

Під час постійного перезавантаження або оновлення деякі клієнти в тій же підмережі, що й кластер PowerScale, можуть відключатися від динамічних IP PowerScale. Проблему мають лише клієнти в тій самій підмережі, що й кластер Isilon. Клієнти навіть не можуть пінгувати динамічні IP з цією проблемою. Це також може трапитися з іншими вузлами того ж кластера Isilon. Деякі вузли кластера не можуть пінгувати жодних динамічних IP на інших вузлах. Перевірка таблиці ARP на клієнтському комп'ютері, який не може пінгувати динамічну IP-адресу, показує недійсний запис. У таблиці ARP досі є старий запис, який відображає динамічну IP на неправильну MAC-адресу.

Наприклад, вузол 11 перезавантажився, і динамічний IP 10.x.x.43 був переміщений до вузла 10, щоб уникнути простою. Потім вузол 1 почав не пінгувати IP.

Після перегляду таблиці ARP на вузлі 1 запис для вузла 11 виявився недійсним. Він показав, що IP 10.x.x.43 все ще прив'язаний до MAC вузла 11 ec:0d:xx:xx:c5:00.

node-1# arp -a

? (10.x.x.43) at ec:0d:xx:xx:c5:00 on mlxen1 expires in 232 seconds [ethernet]

MAC-адреса вузла 11 — 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

Після перезавантаження вузла 11 IP 10.x.x.43 було переміщено до вузла 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

MAC-адреса вузла 10 — 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

Запис ARP на вузлі 1 був відображений на недійсну (стару) MAC-адресу. Це призводить до того, що будь-який клієнт або вузол не можуть підключити IP-адресу до виправлення.

Відповідно до «PowerScale Network Design Considerations»
https://infohub.delltechnologies.com/es-es/t/dell-powerscale-network-design-considerations/

«Зона SmartConnect з динамічним виділенням IP-адрес негайно переносить одну IP-адресу на несправному вузлі до одного з трьох інших вузлів кластера. Він надсилає кілька зайвих запитів на протоколи розв'язання адрес (ARP) підключеному комутатору, щоб клієнтський ввод/вивід працював безперервно.

»Хости в тій самій підмережі не отримували безкоштовних ARP (GARP) пакетів від вузла 10 після призначення IP-адреси. Таким чином, запис ARP не оновлювався належним чином на хостах, що призвело до проблеми мережевого з'єднання. Причина в тому, що трансляції ARP або припиняються, або блокуються на рівні мережі. Cisco Application Centric Infrastructure (ACI) сприяла цим проблемам через неправильну конфігурацію.

Рішення:

Як довгострокове рішення, на стороні комутатора має бути увімкнено «Безпідставне затоплення ARP».

Наступна стаття з знань має на меті описати кумулятивні рекомендації з Cisco ACI.

• [000028116] Клієнти відключаються після переміщення IP-адреси і використання Cisco ACI

Обхідний шлях:

Як обхідний шлях, застарілий запис ARP можна було видалити за допомогою команди "arp -d " на постраждалих хостах. Хости транслюють новий запит на роздільну здатність ARP для IP і оновлюють свої таблиці ARP оновленою MAC-адресою.

Цю проблему можна додатково усунути за допомогою захоплення пакетів на всіх вузлах PowerScale і клієнтських машинах. Це доводить, що вузол отримав GARP-пакети за задумом. Однак хост, який зіткнувся з проблемою, не отримав пакети GARP.

Коли IP 10.x.x.43 було перенесено на вузол 10, вузол 10 дійсно надсилав пакети GARP на 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)

Захоплення пакетів показує, що вузол 1 не отримав жодних GARP-пакетів щодо переміщення IP 10.x.x.43.

[~]$ tshark -t ad -r node-1_mlxen1.pcap | grep -i arp | grep Gratuitous | grep 10.x.x.43
[~]$

Захоплення пакетів показує, що клієнт також не отримав пакети GARP.

[~]$ tshark -t ad -r client.pcap | grep ARP | grep Gratuitous | grep 10.x.x.43
[~]$

Коли хости не отримують GARP-пакети, їхні записи в таблиці ARP для IP 10.x.x.43 не оновлюються. Вони все одно мають неправильний MAC ec:0d:xx:xx:c5:00. Отже, вони не могли отримати доступ до IP 10.x.x.43.