Вот мои наблюдения по последним двум долгосрочным релизам (6.46.7 и 6.46.8): некоторые вещи, которые раньше работали, просто перестали, и это раздражает и выводит из себя.
Ложные срабатывания DFS
Наблюдаются на RB952Ui-5ac2nD, который установлен на первом этаже во внутреннем дворе (точнее, вроде дымохода) здания. Открытие примерно 15x18 метров, сверху над роутером 6 этажей, а снаружи здания в ближайшем направлении как минимум 8 стен (4 железобетонные, 4 — с деревянными рамами), так что никак внешние радары не могут быть приняты в этом месте. Ближайший метеорадар находится километрах в 27 от сюда, и при этом он ниже уровня земли относительно этой точки.
Также с этого AP видно около 60 других точек доступа (из них только 2 на DFS-каналах) и примерно 300 клиентов при сканировании. Регион установлен на «united states», tx-power — по регламенту, режим — только 5 ГГц-AC 20/40/80 МГц, 802.11. U-NII-1 и U-NII-3 настолько шумные, что AP их не выбирает. Обычно после перезагрузки выбирается канал 5500 Сеее. Но раз-два в день радио решает, что поймало радар, хотя физически это невозможно.
Неправильный или невозможный выбор канала
При такой конфигурации после ложного срабатывания радарного обнаружения радио зачастую выбирает каналы, которые отсутствуют в американском плане каналов AC и не должны были выбираться с текущими настройками — например, 5710-eeeC, 5715, 5695 и другие, которые не видны клиентам.
Игнорирование списка сканирования
Если я задаю сканирование с диапазонами 5270–5590 и 5650–5710, ожидая получить каналы 56, 60, 62, 64, 100, 102, 104, 106, 108, 110, 112, 116, 132, 134, 136, 140, то радио показывает совсем другое. Например, оно выдает 5700-eeCe, что соответствует каналу 138 и явно выходит за пределы запрашиваемого диапазона. Если выбирается 5700, то должно работать только в 20 МГц, поскольку это единственный легальный канал на этой частоте в США с заданными ограничениями.
Мосты/объединённые интерфейсы перестают передавать трафик при отключенном QoS
Это наблюдается на нескольких RB750Gr3 с 6.46.8, другая сторона — hap ac lite или похожее устройство. Есть объединённый интерфейс (2 Ethernet-порта) в составе моста, а также другой Ethernet-интерфейс. Под ними — VLAN’ы, которые входят в отдельные мосты. Есть очередь (queue-tree) с несколькими очередями, включая две отдельные для одного и того же маркера трафика — одна с родителем global, другая — с родителем bonding interface. С 6.46.8 словно подочередь для маркера трафика под родителем bonding отключается, и связь с другим роутером пропадает. При просмотре интерфейсов (VLAN’ы под bonding) не видно переданных пакетов, только принятые. Это затрагивает все VLAN-интерфейсы, а не только связанные с маркером трафика. В предыдущих версиях я мог включать и отключать эти две очереди без сбоев.
NV2 перестал передавать трафик
Раньше работало отлично, теперь нет. Было несколько ссылок на 2.4 ГГц с каналами 5 МГц, работавшими на NV2 с фиксированной долей downlink 20%. Эти каналы передавали данные с сенсоров вверх, трафик вниз отсутствовал. После обновления клиента и AP до 6.46.8 (с 6.46.6 или старше) ссылок стало больше, но с удалённых точек данные не текли. На AP видна работоспособность и зарегистрированные станции, но Torch показывает отсутствие входящих пакетов, RX-пакеты на интерфейсе не идут. Несколько перезапусков, я привожу другой AP, заливаю конфиг — та же ситуация. Меняю клиентское радио — станция подключена, но пакеты не идут. Потратил два дня на замену оборудования, пока не решил переключить NV2 на динамический downlink — и о чудо, IP-задания пошли. Возвращаю фиксированный downlink 20% — пакеты прекращаются. Играюсь с процентами — на 26% пакеты опять идут.
Я и мои клиенты вложили немало времени в настройки MikroTik, и сейчас мне просто уже невозможно рекомендовать их, когда ломают то, что раньше работало отлично, особенно когда большая часть объектов расположена удаленно и путь до них занимает от 4 до 24 часов. Пару лет назад эти проблемы случались в «Stable» — тогда я перешёл на «Long-term», но как так — столько всего ломается в самых разных областях в вроде бы стабильном релизе? Что вообще происходит?
С неохотой начал менять некоторые устройства на оборудование других производителей.
Ложные срабатывания DFS
Наблюдаются на RB952Ui-5ac2nD, который установлен на первом этаже во внутреннем дворе (точнее, вроде дымохода) здания. Открытие примерно 15x18 метров, сверху над роутером 6 этажей, а снаружи здания в ближайшем направлении как минимум 8 стен (4 железобетонные, 4 — с деревянными рамами), так что никак внешние радары не могут быть приняты в этом месте. Ближайший метеорадар находится километрах в 27 от сюда, и при этом он ниже уровня земли относительно этой точки.
Также с этого AP видно около 60 других точек доступа (из них только 2 на DFS-каналах) и примерно 300 клиентов при сканировании. Регион установлен на «united states», tx-power — по регламенту, режим — только 5 ГГц-AC 20/40/80 МГц, 802.11. U-NII-1 и U-NII-3 настолько шумные, что AP их не выбирает. Обычно после перезагрузки выбирается канал 5500 Сеее. Но раз-два в день радио решает, что поймало радар, хотя физически это невозможно.
Неправильный или невозможный выбор канала
При такой конфигурации после ложного срабатывания радарного обнаружения радио зачастую выбирает каналы, которые отсутствуют в американском плане каналов AC и не должны были выбираться с текущими настройками — например, 5710-eeeC, 5715, 5695 и другие, которые не видны клиентам.
Игнорирование списка сканирования
Если я задаю сканирование с диапазонами 5270–5590 и 5650–5710, ожидая получить каналы 56, 60, 62, 64, 100, 102, 104, 106, 108, 110, 112, 116, 132, 134, 136, 140, то радио показывает совсем другое. Например, оно выдает 5700-eeCe, что соответствует каналу 138 и явно выходит за пределы запрашиваемого диапазона. Если выбирается 5700, то должно работать только в 20 МГц, поскольку это единственный легальный канал на этой частоте в США с заданными ограничениями.
Мосты/объединённые интерфейсы перестают передавать трафик при отключенном QoS
Это наблюдается на нескольких RB750Gr3 с 6.46.8, другая сторона — hap ac lite или похожее устройство. Есть объединённый интерфейс (2 Ethernet-порта) в составе моста, а также другой Ethernet-интерфейс. Под ними — VLAN’ы, которые входят в отдельные мосты. Есть очередь (queue-tree) с несколькими очередями, включая две отдельные для одного и того же маркера трафика — одна с родителем global, другая — с родителем bonding interface. С 6.46.8 словно подочередь для маркера трафика под родителем bonding отключается, и связь с другим роутером пропадает. При просмотре интерфейсов (VLAN’ы под bonding) не видно переданных пакетов, только принятые. Это затрагивает все VLAN-интерфейсы, а не только связанные с маркером трафика. В предыдущих версиях я мог включать и отключать эти две очереди без сбоев.
NV2 перестал передавать трафик
Раньше работало отлично, теперь нет. Было несколько ссылок на 2.4 ГГц с каналами 5 МГц, работавшими на NV2 с фиксированной долей downlink 20%. Эти каналы передавали данные с сенсоров вверх, трафик вниз отсутствовал. После обновления клиента и AP до 6.46.8 (с 6.46.6 или старше) ссылок стало больше, но с удалённых точек данные не текли. На AP видна работоспособность и зарегистрированные станции, но Torch показывает отсутствие входящих пакетов, RX-пакеты на интерфейсе не идут. Несколько перезапусков, я привожу другой AP, заливаю конфиг — та же ситуация. Меняю клиентское радио — станция подключена, но пакеты не идут. Потратил два дня на замену оборудования, пока не решил переключить NV2 на динамический downlink — и о чудо, IP-задания пошли. Возвращаю фиксированный downlink 20% — пакеты прекращаются. Играюсь с процентами — на 26% пакеты опять идут.
Я и мои клиенты вложили немало времени в настройки MikroTik, и сейчас мне просто уже невозможно рекомендовать их, когда ломают то, что раньше работало отлично, особенно когда большая часть объектов расположена удаленно и путь до них занимает от 4 до 24 часов. Пару лет назад эти проблемы случались в «Stable» — тогда я перешёл на «Long-term», но как так — столько всего ломается в самых разных областях в вроде бы стабильном релизе? Что вообще происходит?
С неохотой начал менять некоторые устройства на оборудование других производителей.
