Информация
Настройка
Новости
Контакты
Новинка
Распродажа
Оплата
Доставка
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • Changelogs
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    RouterOS
    Зависание PCC и браузера

    Зависание PCC и браузера

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Зависание PCC и браузера, RouterOS
     
    OKNET
    Guest
    #1
    0
    23.06.2016 10:03:00
    Я использую двухканальный PCC «балансировщик нагрузки» (в общем, по этому методу http://mum.mikrotik.com/presentations/US12/steve.pdf). Часто в браузерах на компьютерах подвисает загрузка с сообщением «ожидание ответа от сайта…». Этого не происходит, если отключить один из WAN-интерфейсов (неважно, какой именно). Я знаю, что при использовании метода per-connection-classifier=both-addresses-and-ports бывают проблемы с HTTPS-сайтами, поэтому я добавил в правила **dst-port=!443**, но всё равно зависания случаются и на HTTP-сайтах. Что ещё можно проверить? Спасибо!
     
     
     
    OKNET
    Guest
    #2
    0
    11.07.2016 13:28:00
    Пока никаких хороших новостей, также один пользователь с правилом маршрутизации, которое стоит перед правилами PCC, чтобы обойти механизм PCC, столкнулся с проблемой навигации. Похоже, что звонки, сделанные через WAN, не получают правильный ответ или получают ответ через другой WAN. Вот мои правила mangle:

    **D chain=forward action=change-mss new-mss=1440 passthrough=yes tcp-flags=syn protocol=tcp out-interface=all-ppp tcp-mss=1441-65535**  
    **D chain=forward action=change-mss new-mss=1440 passthrough=yes tcp-flags=syn protocol=tcp in-interface=all-ppp tcp-mss=1441-65535**  

    D comment=special dummy rule to show fasttrack counters chain=prerouting  
    D comment=special dummy rule to show fasttrack counters chain=forward  
    D comment=special dummy rule to show fasttrack counters chain=postrouting  

    chain=prerouting action=accept dst-address=10.0.10.0/24  
    **chain=prerouting action=accept dst-address=10.0.20.0/24**  

    chain=input action=mark-connection new-connection-mark=WAN1_conn passthrough=yes in-interface=ether23  
    **chain=input action=mark-connection new-connection-mark=WAN2_conn passthrough=yes in-interface=ether24**  

    **chain=output action=mark-routing new-routing-mark=to_WAN1 passthrough=no connection-mark=WAN1_conn**  
    **chain=output action=mark-routing new-routing-mark=to_WAN2 passthrough=no connection-mark=WAN2_conn**  

    comment=wan1-pfw chain=forward action=mark-connection new-connection-mark=WAN1_pfw passthrough=no connection-state=new in-interface=ether23  
    **comment=wan2-pfw chain=forward action=mark-connection new-connection-mark=WAN2_pfw passthrough=no connection-state=new in-interface=ether24**  

    **comment=wan1-pfw chain=prerouting action=mark-routing new-routing-mark=to_WAN1 passthrough=no in-interface=ether1 connection-mark=WAN1_pfw**  
    **comment=wan2-pfw chain=prerouting action=mark-routing new-routing-mark=to_WAN2 passthrough=no in-interface=ether1 connection-mark=WAN2_pfw**  

    **comment=Paul_use_wan1 chain=prerouting action=mark-routing new-routing-mark=to_WAN1 passthrough=no src-address=192.168.1.100 dst-address=!192.168.1.0/24**  

    **chain=prerouting action=mark-connection new-connection-mark=WAN1_conn passthrough=yes connection-state=new protocol=tcp dst-address-type=!local in-interface=ether1 dst-port=!443 per-connection-classifier=both-addresses-and-ports:2/0**  
    **chain=prerouting action=mark-connection new-connection-mark=WAN2_conn passthrough=yes connection-state=new protocol=tcp dst-address-type=!local in-interface=ether1 dst-port=!443 per-connection-classifier=both-addresses-and-ports:2/1**  

    **chain=prerouting action=mark-routing new-routing-mark=to_WAN1 passthrough=no in-interface=ether1 connection-mark=WAN1_conn**  
    **chain=prerouting action=mark-routing new-routing-mark=to_WAN2 passthrough=no in-interface=ether1 connection-mark=WAN2_conn**  

    Интерфейсы:  
    Wan1 = 10.0.10.2/24 gw 10.0.10.1 (ether23)  
    Wan2 = 10.0.20.2/24 gw 10.0.20.1 (ether24)  
    LAN = 192.168.1.1/24 (ether1)  

    Машина с адресом 192.168.1.100 должна использовать только WAN1.  

    Есть какие-нибудь идеи? Спасибо!
     
     
     
    Feklar
    Guest
    #3
    0
    11.07.2016 14:08:00
    Это происходит на всех сайтах или только на некоторых? Попробуй переключиться на «both-addresses», если проблема только на нескольких сайтах, тогда можно убрать ограничение dst-port=443.
     
     
     
    OKNET
    Guest
    #4
    0
    14.07.2016 12:12:00
    Это очень случайно... к счастью, это происходит лишь на нескольких процентах посещаемых сайтов, не могу сказать, что какой-то сайт страдает больше другого, похоже, что нет. Сейчас проверяю только с обеими адресами, дам знать. Также собираюсь проверить метод по пропускной способности, как в http://mum.mikrotik.com/presentations/US12/tomas.pdf, и посмотреть, как он себя проявит... (есть у кого-нибудь отзывы по этому поводу??)
     
     
     
    larryhao
    Guest
    #5
    0
    25.07.2016 03:00:00
    Думаю, у нас похожие проблемы. Я в Китае. Здесь у нас есть три интернет-провайдера по всей стране, назовём их Y, L и M. Они обеспечивают хорошее соединение, если и сервер, и клиент находятся внутри их сети. Но при этом они дают ограниченную пропускную способность пользователям, которые хотят получить доступ к серверам в другой сети. И это только начало. Чтобы улучшить скорость для пользователей из разных сетей, почти все важные сайты предоставляют разные серверы для пользователей разных провайдеров. Например, если пользователь подключён к Y, при пинге сайта он получит IP-адрес, который принадлежит серверу внутри сети Y. Вот тут и начинаются настоящие проблемы. Что касается PCC, то соединения распределяются по разным WAN, и может получиться так, что пользователь получает IP сервера из Y, а реальное HTTP-соединение идёт через L или M. Такое соединение будет гораздо медленнее, чем в обычной ситуации. Ещё одна проблема — это DNS. Y, L и M ограничивают доступ к своим DNS только для своих пользователей. То есть, если вы пингуете DNS сервер, который получили от ADSL1, но пинг идёт с ADSL2, ответа не будет. Чтобы решить проблему с DNS, можно указать публичного DNS-провайдера и не использовать тот, что вы получаете от своего провайдера по ADSL или другому способу. А вот с проблемой серверов пока не придумал решения.
     
     
     
    OKNET
    Guest
    #6
    0
    28.07.2016 09:55:00
    Только что понял, что эта проблема связана с использованием функции «fast track», добавленной в правила фильтрации файервола, как я писал в своём недавнем посте http://forum.mikrotik.com/t/navigation-issue-with-fasttrack-in-conjunction-with-pcc/100156/1. К сожалению, пока что нет полезного ответа…
     
     
     
    mrz
    Guest
    #7
    0
    28.07.2016 10:00:00
    Пожалуйста, прочитайте описание того, что такое fasttrack и как он обходит http://wiki.mikrotik.com/wiki/Manual:Wiki/Fasttrack
     
     
     
    OKNET
    Guest
    #8
    0
    28.07.2016 11:29:00
    Mrz, спасибо, согласно вики: Обратите внимание, что не все пакеты в соединении могут проходить через fasttrack, поэтому вполне возможно увидеть некоторые пакеты, идущие по медленному пути, даже если соединение уже помечено для fasttrack. Вот почему правило с action=accept обычно ставится сразу после fasttrack-соединения. Пакеты, прошедшие fasttrack, обходят файрвол, отслеживание соединений, простые очереди, очередь с parent=global, ip traffic-flow (ограничение убрали в версии 6.33), ip accounting, ipsec, универсальный клиент hotspot, назначение vrf, поэтому администратор должен следить, чтобы fasttrack не мешал другой конфигурации.

    Так что это не всегда хорошее решение — всё зависит от рабочей среды. Поскольку нормально, что перечисленные выше настройки обходятся fasttrack, когда же эта функция действительно полезна? Нужно ли считать, что fasttrack с pcc лучше избегать?
     
     
     
    dimm0k
    Guest
    #9
    0
    09.10.2016 01:08:00
    Есть какие-то новости по этому поводу? Я мучаюсь с этой проблемой уже несколько месяцев!! Я много постил тут, на Reddit и в IRC, но это ни к чему не привело, пока я не отключил каждое правило в файрволе по очереди в качестве первой попытки перед полной перенастройкой PCC — и БАЦ, сработало, когда Fast Track был отключён! Несмотря на то, что говорится в ссылке от @mrz, строка сразу после стандартного правила Fast Track accept не влияет на ситуацию и всё равно ломает PCC, если Fast Track включён. Если найдётся решение — буду очень рад, но я наконец-то могу закрыть эту затянувшуюся проблему! П.С. Похоже, боги MikroTik промолвили слово http://forum.mikrotik.com/t/load-balance-pcc-pppoe-same-isp-gateway/100562/1
     
     
     
    soonwai
    Guest
    #10
    0
    04.03.2017 16:48:00
    У меня была такая же проблема, и я нашёл решение, но не уверен, правильно ли я всё сделал. Вот ссылка: http://forum.mikrotik.com/t/navigation-issue-with-fasttrack-in-conjunction-with-pcc/100156/3
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры