dvlad666

Добрый день! Присоединяюсь к дискуссии по данной ошибке. Viva kn-1910, прошивка 4.3.6.3. Сразу скажу, тестами смог ОПРОВЕРГНУТЬ теорию ув. автора, это НЕ про ошибки и потери на линии. Вероятнее всего идёт гонка между двумя ядрами проца. Сетап следующий: Симпотомы при этом: На этом исследование закончил, ситуация последних трёх шагов многократно воспроизводима - локальный L2TP Интерент под любой нагрузкой, удаленный телефон с любой нагрузкой И EOIP-over-IKEv2 туннель без нагрузки могут висеть одновременно включенными сколько угодно долго. Но стоит подать в EOIP-over-IKEv2 туннель пинг 50000+ байт! Сразу же возникает эта ошибка. При этом на пингах менее 40000 байт словить её трудно, если EOIP не нагружен. Далее перезагружаем EOIP туннель, ждём - тихо, шлём первый большой пинг - снова ловим. Выводы: Ошибка присутствует как минимум на МТ7621, и она НЕ связана ни с потерями пакетов на локальном WAN линке, ни с его скоростью. Т.к. при всех внешних линках в данном тесте их скорость - это 300, 500Мбит, скорость туннелей при этом 30-40Мбит, и она стабильна. Внешние линки физически показывают способность передавать нагрузку 200+ даже вместе с туннелями, а это выше чем 30-40, и уж точно выше, чем один несчастный пинг на 50кбайт. Вероятнее всего, ошибка связана с какой-то внутренней Race condition на двух ядрах MT7621 процессоров при наличии более чем одного туннеля в UDP пространстве. Или в случае с L2TP WAN - получается, более чем двух, по числу обрабатывающих UDP пакеты ядер. Если появляется третий туннель (в моём случае втрой IKEv2+eoip) и пакет третьего туннеля падает не на то ядро, то оно его может быть и откидывает, как не соответствующий ожиданиям канала шифрования. Добавление Openconnect во всей этой ситуации видимо является протсо усугубляющим фактором, когда запускается механизм DTLS (т.е. UDP). Почему порог 40000 vs 50000 байт показал такую четкую корреляцию, не знаю... Возможно, есть некий порог 48кБайт/MTU1460_l2tp_wan = 33 пакета, т.е. где-то прилетает более чем 16 пакетов на каждое ядро проца, и они начинают чудить. Благодарю всех за внимание к данной теме

Сегодня после обновления с 4.3.0 на 4.3.1 на kn-1012 клиент получил иную установку Tunneling Mode - Split Tunneling вместо Tunnel All traffic (подчеркнута на рисунке ниже). Т.к. бэкап не сделал, пришлось откатываться срочно на 4.2.6.3, т.к. туннель свою функцию выполнять перестал(( Все настройки стоковые через веб-морду, галочка NAT на сервере была включена и не менялась, маршрут 0.0.0.0/0 в клиенте внизу светился, но трафик весь шёл мимо. Клиент актуальный на сегодня на андройд

Добрый день! Не могу получить адекватное поведение шейпера основного интернет-канала на моделях с процессором MT7621, а именно kn-1910 и kn-1011. Поведение этих моделей одинаковое, при этом на более старых моделях (1112, 2010) и на более новых kn-1012 поведение шейпера при тех же настройках нормальное. Суть проблемы: На процессорах MT7621 шейпер, особенно входящий, просто срывает сверх лимита, и его как будто нет. Поведение исходящего шейпера тоже странное - то встречается четкое ограничение 216Мбит вне зависимости от настройки, то до 300 доходит. Ошибок в журнале нет никаких. В зависимости от прошивок на 4.2.6.3 аплинк без HWNAT при настройках 300 и выше, режется всегда на 216 мбит, на 4.3.0 режется на порядка 309, а с HWNAT есть ощущение, что он вообще то работает, то нет. Так же есть ощущение, что указание двух лимитов сразу в крупных числах >90 Мбит иногда приводит к тому, что остаётся работать только один из лимитов ,а второй не применяется вообще (подробности ниже в пункте Г) Дано: А) Имеем интернет-канал 333/333 мбит/с реальной скорости по спидтесту (браузер, много потоков). Всё везде тестируем строго по кабелю. Изначально канал L2TP Билайн, сначала тестировался в таком виде, но затем для исключения влияния L2TP он теперь терминируется на другом роутере, делается первичный NAT, и далее для тестов остается ванильный DHCP. Скорость спидтестов за ним сохраняется. Б) Берем 1910/1011 роутер на MT7621, далее вся речь про него, сбрасываем его до заводских, втыкаем в WAN кабель с ванильным DHCP из LAN первичного роутера и в режиме роутера подключаем один клиент. Имеем те же скорости. В) Создfём вторую Connection Policy, ради скорости, её назначаем для Home Segment. В ней выбираем своё WAN подключение и назначаем ему какие-нибудь скорости, вот так: Г) Запускаем спидтест, видим, что в первую секунду входящая скорость может упереться в этот предел, а потом её срывает, и она улетает в зону 200+-333. Д) Далее пробуем пляски с бубном, включаем-выключаем HWNAT, меням прошивки, оставляем только один из лимитов, меняем сами лимиты. Результат получаем непредсказуемый. Что особенно интересно, замечено: 1) Опытным путём за несколько суток испытаний были обнаружены некие очень уж символичные пороги входящей скорости - 32, 36 и 72 Мб/с. Это такие значения, при переходе через которые шейпер перестаёт и начинает срываться. Т.е. если выставить 31500 кбит/с, то у меня не получилось сорвать ни разу. В зоне 32-36 - то срывается, то нет. 72 это тоже как-то встретился порог срыва такой. Но числа как-то уж очень похожи - как будто где-то там числа нацело не делятся или между ядрами процессора сбоят регистры... Чисто догадка. Включение-выключение HWNAT в целом всё равно крутится вокруг этих же порогов, с выключенным сорвать чуть сложнее. 2) Также заметил, что срыв зависит от количества одновременных потоков спидтеста, чем больше потоков - тем больше вероятность сорвать. К примеру, запустили при пороге 35мбит спидтест в браузере (обычно там 8 потоков), он не сорвался, идёт скачка. В параллель запускаем speedtest cli, там обычно 3-5, и сразу оба срываются в зону 100-300мбит 3) Килобиты-мегабиты в интерфейсе, но тут уже совсем из разряда "могло показаться", как-то странно коррелируют с мегабитами. Т.е. бывало такое что ставишь 32мбит, срывается, а ставишь 32005кбит - нет, хотя формально интерфейс пересчитывает через ровные тысячи, вроде бы. Помогите, пожалуйста, починить шейпер на MT7621