Всем привет!
Уже замучался в край и хочу зареквестить помощи сообщества по одному вопросу:
Имеем Mikrotik hAP lite (6.36.2 прошивка) + PPPoE к провайдеру. И не открывающейся ни в какую dropbox.com, на лицо классическая проблема с размером окна и гугл уже наверняка утомился отвечать на данный вопрос.
В данный момент в профиле PPP соединения включен Change TCP MSS = yes, при этом в mangle — forward исправно появляются автоматически генерируемые правила:
А MTU pppoe-out интрефейса останавливается на значении — MTU 1480;
Конфиг pppoe соединения:
Т.е. казалось бы всё логично (по карйней мере с моей точки зрения) 1480 на прова и 1440 к внутренней сети, но сайтик то не открывается.
Если убрать Change TCP MSS из профиля PPP, и добавить в мангл аналогичные правила но руками и даже с использованием меньшего значения MTU, картина не изменяется. В связи с чем возникает логичный вопрос, что пошло не так и как это победить. Так же есть 3011 c аналогичными симптомами и тем же самым провайдером.
Наверняка все знают о мощной ОС Mikrotik предназначенной для работы на маршрутизаторах RouterBoard(собственное оборудование компании Mikrotik), а так же на любых x86 машинах с минимально необходимым железом.
Зачастую многие ISP используют Mikrotik для User-End оборудования, а именно PPPoE или PPPTP сервера.
1. Изменение MSS
Чаще всего системные администраторы, создают PPPoE сервер следующим образом:
И в целом они правы, что изменяют MSS, что бы все сайты нормально открывались. Однако Mikrotik в версии до 5.24 создает кучу динамических правил (по 2-а на каждое клиентское соединение) в таблице Firewall Mangle, что существенно увеличивает нагрузку на центральный процессор. Лучше поступать так:
Это одно правило будет изменять MSS для всей подсети — pppoe_addrs
2. Скорости больше 6 Mbit/s
По умолчанию новое клиентское соединение с сервером в Mikrotik, порождает динамическую очередь Queue Simple, с типом очереди default-small, которое имеет настройки PFIFO c емкостью очереди в 10 пакетов. Естественно такое положение вещей не устраивает, меняем таки образом:
Не буду останавливаться на возможностях Mikrotik в плане управления скоростью, однако можете прочитать об этом здесь.
3. Lost-Carrier что это такое и с чем его едят
Как часто бывает оборудование провайдера (NAS) и клиентское оборудование соединено не только оптическими и медными линиями но и какого либо радио оборудованием(того же Mikrotik). В связи с чем иногда можно наблюдать в причинах отсоединения Lost-Carrier. Данная ошибка возникает потому что Mikrotik не получает за отведенное время запросы на свои пакеты Echo(в PPPoE/PPTP существует протокол проверки «жизнеспособности» ppp соединения, которые через определенные интервалы времени (lcp-echo-interval) посылает пакеты, схожие по своей цели с icmp ping, но реализованы специально для тунельных соединений и называемые LCP-пакетами).
За это отвечает параметр KeepAlive, определяется он в секундах(по умолчанию 10) и работает след. образом.
Mikrotik начинает отправлять пакеты Echo клиенту в течении 10(по умолчанию) секунд, если в течении следующих 10 секунд не получит ни одного ответа, то разорвет соединение с такой ошибкой KeepAlive.
Таким образом Mikrotik будет ждать 2*10 секунд пока не разорвет соединение.
Я рекомендую ставить его в пределах от 10-20 до секунд, при плохом качестве линии 20 секунд. Помните что чем выше этот параметр то тем выше время ожидания завершения сбойного соединения и установки нового.
Жду Ваших комментариев о полезности статьи.
Возможно напишу свой опыт о работе с PPPoE далее а именно:
- Использование CoA для PPPoE Mikrotik
- Классификация трафика в PPPoE и динамическое ограничение скорости определенного из них
Т.к. вы неавторизованы на сайте. Войти.
Т.к. тема является архивной.
— Знатоки! Внимание на экран!
Есть несколько конфигураций сети
1.Интернет шлюз Ubuntu свитч Клиент
2.Интернет шлюз Mikrotik свитч Клиент
-Интернет радиоканал 2 мегабита
-MikroTik RB951G-2HnD
-свитч N-way 8-port
В 1 случае всё работает без нареканий, за исключением полудохлого железа.
Интернет, VPN и почта работают хорошо.
Поскольку этот шлюз из себя ничего особенного не представлял, приобрёл ему на замену MikroTik
Конфигурация стандартна
WAN-порт 1, 2-5 бридж
Flow Control — выключен
Фаервол основные дефолтные правила
Во 2й конфигурации вроде бы всё хорошо работает, но выяснилось,
что почтовый клиент TheBat получает почту c pop.yandex.ru значительно медленнее 1й конфигурации, примерно в 10-15 раз с обрывами сессии на больших письмах.
Размышлениями дошел до того, что дело в MTU.
Бился с провайдером, докапываясь в чём дело, те ли настройки и точно ли для радиоканала значения MTU-1500
пробовал разные значения — результат 0
Стрельнуло мне попробовать клиента на прямую подключить к микротику.
Тут зафунциклировало как надо, даже лучше!
Получилось как обычно — зря мучил техподдержку, сам дурак.
Логично было заключить, что что-то не так работает со свитчём.
Методом подбора было выявлено, что если на микротике понизить значение mtu, на порту
подключения свитча до 1444 (и в целом бриджа), то почта начинает просто летать.
Вот оно счастье! но. не долгое
Далее выясняется, что при значении MTU-1444 на компьютерах с WindowsXP перестают открываться ряд сайтов.
Например, менеджерами любимая, главная страница yandex.ru
На Windows7 и Ubuntu 14.04 работает
Опять методом подбора MTU на порту, выяснилось, что yandex начинает работать только со значением не ниже 1450
И получается, что почта не работает при MTU выше 1444, а яндекс ниже 1450.
т.е. в золотую середину мы не попадаем вообще никак, печаль.
Как быть и что за ерунда такая?
Почему всё работает в первой конфигурации при значениях MTU на eth0,eth1 -1500?
Свитч пока нет возможности поменять, всех запитать на микротик тоже.