Я недавно заметил это на нескольких моих свежих установках. Лучшее решение, которое я нашёл — оставить на интерфейсе DHCP-клиент, но отключить его. Он не будет заново создаваться, а если для вас приемлемо, чтобы он был, но отключён, то больше никаких проблем не возникнет.
Смешно — я отключил его на своих CHR-системах. После перезагрузки появлялся новый включённый dhcp-client, а тот, что я отключил — оставался отключённым. Потом, когда я отключил второй dhcp-client (теперь у меня было два отключённых dhcp-client), следующая перезагрузка автоматически добавляла третий включённый dhcp-client. В качестве временного решения я просто отключил пакет dhcp. Это не самое лучшее решение, но хоть какое-то, пока не починят. North Idaho Tom Jones
mrz, спасибо — спасибо — спасибо за эту информацию/пост. Очень жду v6.42. Кстати, на одном из моих CHR мне нужно, чтобы ether1 был DHCP-сервером — но после перезагрузки, когда автоматически включается DHCP-клиент на ether1, у меня получается статический IP на ether1 и одновременно DHCP-клиент на ether1 — и я подозреваю, что в итоге будет два разных IP на ether1 и, возможно, две разные маршруты по умолчанию. North Idaho Tom Jones
Странно. Я на самом деле писал в поддержку по этому поводу, и мне ответили, что это сделано специально — на ether1 создаётся dhcp-client. Мне посоветовали отключить его и не обращать внимания, если он не нужен.
Вероятно, создание этого клиента при первом запуске с пустой конфигурацией было задумано специально, так же, как при начальной загрузке маленьких роутеров создаётся конфигурация по умолчанию. Однако в последних версиях CHR он создавался даже при уже работающей конфигурации. Я тоже это замечал. Но на моём CHR с версией 6.42rc30 этого больше не происходит: на ether1 и ether2 стоят статические адреса, и никаких спонтанных DHCP-клиентов пока не появляется.
На моём rc30 каждый раз заново добавляется dhcp-client, независимо от того, установлен ли статический адрес на ether1 или отключён ли ранее созданный автоматически dhcp-client. То есть ничего не изменилось по сравнению с тем, как было, когда я месяц назад сообщил об этой ошибке в поддержку.
Привет, могу подтвердить этот баг — DHCP-клиент включается сам по себе и сначала портит мои маршруты. Если я его отключаю, после перезагрузки активируется другая запись. Если удаляю эту запись, после перезагрузки создаётся ещё одна. Похоже, это происходит только если в сети действительно есть DHCP-сервер. Это CHR, почему Mikrotik не исправляет эту серьёзную проблему? И что хуже, первоначальная тема http://forum.mikrotik.com/t/problem-with-mount-point/94/1 была закрыта после выхода версии 6.41.2, но баг так и не исправили. Поэтому кому-то пришлось создавать новый тикет.
Это что-то вроде Ласси на стероидах. У меня есть три CHR для экспериментов (bugfix/current/rc с последними версиями), и проблема возникает на всех них, хотя хотя бы на одном из интерфейсов настроен статический IPv4-адрес. Понимаю, что идея в том, чтобы роутер не позволял остаться без адреса и, соответственно, без доступа в некоторых ситуациях. Но делать это неизбежным — не выход. Должен быть способ отключить такое поведение. Если уж хотите добавить такую функцию, сделайте так, чтобы её можно было выключить:
/ip dhcp-client set chr-hardcore-mode=no-i-do-not-want-automatically-added-dhcp-client-and-i-will-not-blame-mikrotik-if-i-lock-myself-out
DHCP-клиент обязателен на установках CHR, так как большинство облачных сервисов предоставляют доступ только по IP-адресу, а прямого доступа к консоли у вас нет. Чтобы это работало, CHR проверяет, есть ли IP-адрес на интерфейсе ether1 или на мосту, если ether1 входит в его состав. Если IP-адреса или DHCP-клиента нет, то он создаётся автоматически. Если клиент отключён, новый всё равно будет создан на случай, если его выключили случайно. Если на ether1 (или мосту) прописан статический IP-адрес, новый DHCP-клиент добавляться не будет.
Но почему бы не применить эту конфигурацию один раз после начальной загрузки, как это сделано в стандартных настройках недорогих роутеров, и больше к ней не возвращаться, когда пользователь решит убрать этот элемент? Когда я сбрасываю всю конфигурацию на недорогом роутере, он тоже становится недоступным, и конфигурация не меняется для того, чтобы этого избежать. Проблема не в том, что этот клиент автоматически добавляется после начальной загрузки, проблема в том, что он снова применяется после того, как пользователь его удалил. Помните, что пользователь может управлять роутером только через IPv6 и совсем не хочет, чтобы у него был IPv4-адрес. Кроме того, механизм, который вы описываете, очевидно работает некорректно: на моём CHR с ether1 и ether2, оба с фиксированными адресами, клиент DHCP всё равно добавляется на ether2. (в этом CHR порты ether перепутаны между конфигурацией VMware и именами в RouterOS, почему — не знаю, уже сообщалось об этом)
Подход с ether1 звучит разумно, и я бы, наверное, не стал жаловаться, если бы всё работало как описано. Проблема в том, что это вообще не работает. Первая проблема — что такое ether1? У меня есть три CHR в VMware Player. Интерфейсы, указанные в интерфейсе Player, совпадают с порядком в .vmx файле (ethernet0-ethernetX). Но в самих CHR они появляются в разном порядке: CHR1 (6.40.6): ether2, ether3, ether4, ether1 CHR2 (6.41.2): ether2, ether3, ether4, ether1 CHR3 (6.42rc37): ether2, ether4, ether5, ether1, ether3
Я переименовал все интерфейсы, но это параметры с «default-name» из команды «/interface ethernet export verbose», сопоставленные по MAC-адресам.
Вторая проблема — поведение непредсказуемо. Если к default-name=ether1 добавляется DHCP-клиент, можно было бы списать это на порядок интерфейсов. Но после пары перезагрузок с удалением существующего DHCP-клиента перед этим, у меня появляется новый DHCP-клиент не только на ether1, но и на ether2, пустом мосту, отключённом ovpn-out1 и отключённом cap1. Не кажется, что какой-то интерфейс надёжен. Независимо от того, есть ли на ether1 статический адрес или нет — это, похоже, не имеет значения.