sergeyk

Получилось.

Да, два файла в скрытом сообщении.

Снимите self-test с роутера и ретранслятора, когда всё нормально.

Откуда подключаетесь (WAN/LAN)? Если есть self-test с попытками подключения, выкладывайте.

Я поэтому и пишу, что этот адрес не относится к роутеру, как и сама ошибка.

В Web-интерфейс какого устройства? Такая ошибка появляется, когда ретранслятор (не роутер) с указанным адресом становится временно недоступен.

Если достаточно убрать все сообщения от ndhcpc, используйте (config)> system log suppress ndhcpc Core::Syslog: Added suppression "ndhcpc". (config)> copy running-config startup-config

Сообщение "... network conflict... have the same IPv4 address..." не имеет никакого отношения к DHCP. Компонент Discovery Explorer обнаруживает устройства с одинаковым IP-адресом, опрашивая устройства через рассылку ARP-запросов. Очевидно, что конфликтующие устройства имеют одинаковый вручную настроенный IP-адрес, раз вы утверждаете, что 192.168.1.200 в пул не входит. Единственный способ устранить конфликт — прописать одному из них другой адрес вручную или включить у него DHCP. Если вас беспокоят именно сообщения, вы можете отключить диагностику no ip hotspot auto-scan interface Home copy running-config startup-config Но конфликт в сети, само-собой, от этого не исчезнет.

В таком случае делайте захват обмена DHCP-пакетами, когда обмен кажется неправильным.

Из вашего журнала видно, что он не выдаётся, а запрашивается клиентом. DHCPDISCOVER received from cc:9d:a2:de:38:c0. making OFFER of 192.168.0.60 to cc:9d:a2:de:38:c0. DHCPREQUEST received (STATE_SELECTING) for 0.0.0.242 from cc:9d:a2:de:38:c0. Строки выше означают, что 1. Сервер принял от cc:9d:a2:de:38:c0 широковещательный запрос на новый адрес. 2. Сервер предложил клиенту cc:9d:a2:de:38:c0 адрес 192.168.0.60. 3. Клиент cc:9d:a2:de:38:c0 прислал запрос на продление адреса 0.0.0.242.

Проблема измерения "скорости соединения" заключается в том, что не понятно, что именно измерять. Speedtest выделяется тем, что имеет возможность автоматически выбирать ближайший к тестирующему клиенту сервер. Из-за большой собственной инфраструктуры Speedtest может это сделать и поэтому, как правило, его замеры показывают скорость, близкую к скорости, которую обещает провайдер в договоре, имея в виду скорость в своей локальной сети. Наверняка вы замечали, что от смены сервера значения могут заметно отличаться. Совсем не факт, что именно эта скорость вам нужна, зачастую пользователей интересуют замеры до какого-либо определенного IP-адреса, а они могут отличаться от замеров Speedtest радикально.

Поддержка этого модема есть в актуальной стабильной версии 3.09.

@luneman Это сообщение не является ошибкой. Оно появляется, когда устройство обнаруживает, что предыдущая PPP-сессия не была завершена (по любой причине) отправкой терминирующего пакета PADT. Некоторые провайдеры не позволяют устанавливать новую сессию заново с тем же MAC-адресом, если не была явно разорвана старая. Похоже, в вашем случае можно разобраться, только если сделать захват пакетов на интерфейсе WAN (GigabitEthernet0/Vlan2).

Это не имеет значения. Для начала обратитесь в техподдержку.

В настройках роутера и не надо ничего вводить, достаточно после первого подключения через браузер авторизоваться с любого клиента, чтобы активировать новое подключение с MAC роутера.

@Евгений29 я видел похожую проблему у московского Beeline: ответ на DHCP-запрос не приходит в течение 10 минут, поскольку их оборудование считает, что адрес уже выдан. Если поменять MAC-адрес или подключить, например, ноутбук напрямую к провайдеру (с другим MAC), то IP-адрес тут же выдаётся. https://homenet.beeline.ru/index.php?/topic/327637-не-выдаётся-ip-адрес/ Такая проблема решается только со стороны провайдера.

В таком случае я бы посмотрел на self-test, в котором зафиксированы неудачные попытки восстановить работу модема.

Расскажите, для чего вы его периодически перезагружаете. В каком сценарии использования у устройства возникают проблемы, которые решаются только периодической перезагрузкой?

Только на том, где видна проблема.

@saffe сохраните self-test в момент возникновения проблемы на Extra II.

Проверка с TLS не помогает?

Тогда нужен на неделю.

Самый простой вариант system reboot 3600 system configuration save Перезагрузка раз в час без привязки ко дню недели и есть "каждый день".

@CBLoner переустановка соединения по ping-check не помогает?