Периодические временные тайм-ауты пинга от некоторых клиентов Wi-Fi.
Я наблюдаю странное поведение, которое пытаюсь изолировать в своей домашней сети. И если этот пост относится к более конкретному разделу производителя, пожалуйста, lmk.
- ASUS ZenWiFi AX XT8s
- один главный маршрутизатор с двумя одинаковыми ячеистыми точками доступа
- выделенный проводной обратный трафик Ethernet
- последняя СТАБИЛЬНАЯ версия прошивки 3.0.0.4.388_21617
Периодически (и часто после обновления прошивки маршрутизатора), когда я пытаюсь выполнить проверку связи с числовым IP-адресом с моего Wi-Fi iPhone, нацеленного на другой локальный беспроводной клиент (в данном случае несколько Raspberry Pi Zero W), я получаю сообщение «Тайм-аут запроса» s ... на какое-то время, но затем он в конечном итоге прояснится и начнет успешно пинговать (Примечание: числовой IP-адрес, а не проблема с разрешением имени хоста). С моими проводными клиентами (например, ноутбуками, серверами Pi и т. д.) такое случается реже, но время от времени все равно случается.
Я не использую «трехдиапазонную» настройку на своем маршрутизаторе (называемую «SmartConnect» от ASUS, управление полосами в другом месте и т. д.). Я использую каждый Wi-Fi SID (2,4 ГГц, 5-1 ГГц, 5-2 ГГц) отдельно, со своими собственными учетными данными для аутентификации... но он должен автоматически маршрутизировать/переключаться между IP-клиентами на этих диапазонах... верно? Они являются частью диапазона IP-адресов DHCP.
Мне кажется, это устаревшая проблема с кешем ARP. Но я думал, что перезагрузка обычно решает эту проблему? Я ошибаюсь? (Примечание: я все перезагрузил, проблема, похоже, в конечном итоге возвращается.) Периодическая проверка связи вручную, похоже, решает ее. Если это поврежденный кэш ARP, то где? На клиенте? На главном маршрутизаторе или ближайшем ячеистом узле точки доступа? Если перезагрузка не решает проблему навсегда, может быть, мне действительно следует отправить команду очистки кэша ARP на клиентах, SSH на маршрутизаторы и сделать то же самое?