+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

LHG LTE6 нужно перезагружать два раза в день, чтобы он работал.

LHG LTE6 нужно перезагружать два раза в день, чтобы он работал., RouterOS

migro

Guest

17.09.2024 12:14:00

Привет, у меня странная проблема с моим комплектом LHG LTE6. Сначала все работает нормально несколько часов, а потом скорость всё медленнее и медленнее, пока я не перезагружу интерфейс lte1. После перезагрузки всё возвращается к норме. Недавно обновил ОС до версии 7.12.1 и интерфейс до MikroTik_CP_2.160.000_v021, но это не помогло. Кто-нибудь сталкивался с такой же проблемой? Спасибо, Михал.

migro

Guest

14.10.2024 19:01:00

Привет — всё то же самое. Я заметил, что весь роутер стал невероятно медленным, а потом и интернет тоже стал тормозить. После перезапуска интерфейса всё возвращается в норму. Я даже не могу работать с терминалом, пока не перезапущу интерфейс lte1. Вот скриншот пингов (до и после перезапуска). Кто-нибудь сталкивался с такой же проблемой? Это просто бесит…

Larsa

Guest

14.10.2024 19:35:00

Вы можете терять Carrier Aggregation (CA), когда LTE-модем (UE) отключает вторичную несущую для экономии энергии, потому что полное объединение не нужно при низком трафике и устройству не требуется вся пропускная способность. Такое же может происходить и на базовой станции по тем же причинам — в зависимости от местоположения, производительности сети и загрузки ресурсов. При установке или снижении уровня CA часто возникают задержки в несколько секунд, прежде чем связь полностью настроится. С этим можно бороться, отправляя пакеты с полезной нагрузкой с регулярным интервалом после полного установления CA, используя BDF или аналогичные потоки пакетов для поддержания всех каналов.

Проверьте текущие каналы CA в использовании через WinBox: Interfaces → LTE → Cellular → Primary Band + CA Bands.

Стоит отметить, что при использовании RoS Netwatch с LTE Carrier Aggregation (CA) могут возникать проблемы. Это происходит, если тестовый зонд Netwatch повторно включает CA, вызывая длинную задержку до первого ответа и, соответственно, срабатывание скрипта на отключение. В этом плане RoS Netwatch несовершенен, поскольку ему нужен предварительный скрипт, который отправляет данные с полезной нагрузкой перед самим тестированием.

migro Guest	#4 0 15.10.2024 07:59:00 Привет, я установил Band на 7 (потому что это дало лучшие результаты) и не использую агрегацию. Я что-то упустил?

Larsa Guest	#5 0 15.10.2024 08:25:00 Прежде чем вносить эти изменения, вы точно проверили, что именно CA — корень проблемы? Просто чтобы вы знали, если отключить CA, скорость передачи значительно упадёт.

holvoetn Guest	#6 0 15.10.2024 08:31:00 Моё предположение тоже в том, чтобы сначала снять блокировку на диапазон 7. Пусть сеть сама решит. Иногда диапазон с худшими, на первый взгляд, параметрами может работать лучше.

migro Guest	#7 0 15.10.2024 11:57:00 Спасибо — проверю и отпишусь.

Amm0

Guest

15.10.2024 13:16:00

Да, вот такая вот проблема с «жёсткой привязкой к диапазону»… Когда ставишь, например, Band 7, устройство не переключается автоматически на другой диапазон. А вышка может «перенаправлять трафик» на другой диапазон, если Band 7 или любой другой начинает сильно грузиться.

Что можно сделать — добавить в /tool/netwatch тип ICMP, который пингует Google или что-то похожее. Это поддерживает хоть какой-то (пусть и минимальный) трафик по LTE-соединению. Насчёт того, насколько это помогает вышке не отключать ресурсы для CA/пропускной способности — не уверен, но просто сделать и точно не повредит.

Кроме того, /tool/netwatch даёт статистику по задержкам и прочему, что зачастую отлично показывает состояние LTE-вышки (задержки обычно растут, когда свободная пропускная способность падает).

Larsa

Guest

15.10.2024 13:49:00

Мы управляем кучей LTE/NR CPE и выяснили, что для стабильной работы CA нужно минимум два полезных пакета в секунду. Некоторые операторы при этом игнорируют ICMP-трафик. Пока что у нас лучше всего получается отправлять BFD Hello-пакеты (с полезной нагрузкой 24 байта) каждые 300 мс, то есть примерно три пакета в секунду.

eabs

Guest

#10

15.10.2024 17:12:00

У меня была похожая проблема с настройкой LTE. Похоже, это может быть утечка памяти или что-то связанное с интерфейсом, из-за чего происходит торможение. Ты проверял системные логи, чтобы понять, что именно происходит, до перезапуска? Иногда помогает просто полный сброс устройства, а не только перезапуск LTE-интерфейса.

Amm0

Guest

#11

15.10.2024 17:28:00

Проблема с блокировкой диапазона кажется мне более вероятной. LTE-диапазон в интерфейсе — это не просто «предпочтение диапазона», он фильтрует использование других диапазонов. Но если бы это была утечка памяти, это было бы легко проверить в /system/resource перед перезагрузкой. Поскольку такое происходит регулярно, скорее всего, это связано с сетью. Полезная информация.

Кстати, в совсем свежих версиях V7 в /tool/netwatch тоже есть проверка DNS, которая генерирует UDP. Я использую разные типы netwatch, но идея с BGP hello хорошая. Это такая игра в кошки-мышки с этими вышками и так далее. А поскольку часть CA — помимо увеличения пропускной способности — это перераспределение нагрузки на другие диапазоны, отключение одного диапазона, чтобы заставить оборудование типа LHG действительно использовать CA, — вполне может быть тем, что LTE-сеть делает, чтобы по возможности держать основные диапазоны свободными.

Larsa

Guest

#12

15.10.2024 19:11:00

Да, но на самом деле у нас всё было довольно стабильно последние пару лет, с максимум парой случайных изменений CA-каналов, скорее всего из-за обслуживания базовых станций. Три NMOs, которые мы используем сейчас, ведут себя практически одинаково в плане выделения и освобождения каналов для CA. Что касается CPE от Mikrotik, сначала у нас были серьёзные проблемы с Netwatch, но они полностью исчезли после перехода на OOB-управление с использованием BGP и BFD, настроенных на 300 мс интервал передачи.

migro Guest	#13 0 17.10.2024 19:37:00 Я отключил блокировку на диапазоне, и вот что получилось: до перезагрузки — диапазон 7, после перезагрузки — тоже диапазон 7, параметры подключения почти не изменились. Та же вышка… и лог-файл.

holvoetn Guest	#14 0 17.10.2024 20:24:00 Ты используешь Detect Internet? Многие советуют его отключить.

fifrak

Guest

#15

21.10.2024 08:55:00

Помимо обновления RouterOS до последней версии, также обновите прошивку модема. Раньше у меня тоже были проблемы с нестабильным соединением из-за старой прошивки. Но лучшее, что можно сделать — заменить LHG LTE6 на LHGG или ATL LTE18. Я заметил значительное улучшение стабильности связи и скорости.

Amm0 Guest	#16 0 21.10.2024 15:34:00 И RouterBOOT в /system/routerboard — не уверен, что там что-то меняется... Но мой твердокаменный совет начать с последней версии LTE и выровнять все три версии (LTE, RouterOS и RouterBOOT) на стабильной. Обычно я ставлю «auto-update=yes» в /system/routerboard — тогда после обновления RouterOS и второго перезагрузки автоматически применяется фаервол, чтобы ты не забыл. В США наличие Band 66 реально кардинально меняет скорость... Но так как ATL вообще не поддерживает американские частоты, LHG LTE6, иронично, может оказаться даже лучшим вариантом, потому что он ловит часть Band 66 (Band 4). В большинстве же регионов Европы и мира LHGG или ATL будут заметным улучшением, так как они могут использовать расширенные диапазоны. Думаю, автор знает, где стоит вышка, но обычно полезно немного покопаться на cellmapper.net, чтобы понять, какие диапазоны доступны в твоём районе. Есть и другие сайты, а некоторые страны даже публикуют данные о вышках и частотах, так что немного гугла по частотам твоего оператора реально помогает при выборе нового устройства. Может быть, есть вторая вышка, на которую стоит направить антенну — иногда она более стабильная? Также можно включить более подробные логи, если ещё не сделал этого — это может дать больше подсказок. Это добавит новую группу памяти для логов «lte» с отладочной информацией (всё в памяти, но не засоряет главные логи): /system/logging/action add name=lte-memory memory-lines=5000 target=memory /system/logging/add topics=lte,!packet action=lte-memory Если это продолжится, и при том, что все три версии LTE, RouterOS и RouterBOOT у тебя выровнены на 7.16.1 (текущая стабильная), я бы открыл тикет в поддержку и обязательно приложил supout.rif ДО перезагрузки модема. А если вышеописанные логи включены — отладочные данные тоже будут в supout.rif.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры