sergeyk

Сообщение "... 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 не помогает?

Отдыхайте. Пока недельку, а там посмотрим.

По вашей ссылке написано "Discontinued", при этом новых модулей GPON в каталоге не видно.

@pavloffs ваш провайдер иногда отказывает в продлении аренды IP-адреса (received NAK): [I] Oct 16 17:32:26 ndhcpc: GigabitEthernet1: recieved NAK. [W] Oct 16 17:32:26 ndm: Dhcp::Client: unable to configure interface "ISP". [I] Oct 16 17:32:26 ndm: Network::Interface::Ip: "GigabitEthernet1": IP address cleared. [I] Oct 16 17:32:26 nimproxy: NDM IGMP/Multicast proxy stopped (exit status: 0). [I] Oct 16 17:32:26 ndm: Network::InternetChecker: Internet access lost (status: 0x0000). [I] Oct 16 17:32:28 nimproxy: NDM IGMP/Multicast Proxy, v0.0.35. [I] Oct 16 17:32:28 upnp: shutting down MiniUPnPd [I] Oct 16 17:32:28 ndm: Core::Session: client disconnected. [E] Oct 16 17:32:30 coalagent: [SecLayer_OnSend] Coala_Send: Network unreachable. [E] Oct 16 17:32:35 coalagent: [SecLayer_OnSend] Coala_Send: Network unreachable. Для нормально работающей сети ответ NAK — крайне редкая ситуация, она не должна появляться постоянно.

Хеш пароля пользователя и хеш конфигурационного файла никак между собой не связаны, это разные значения. Если вы хотите поменять содержимое startup-config, можете просто удалить строку с "Md5 checksum".

Доступ снаружи разрешен?

А как вы поняли, что он именно балансирует, а не просто молча игнорирует одно из соединений?

Да, разные. Группа команд называется ntp, но управляет SNTP.