Я использую двухканальный PCC «балансировщик нагрузки» (в общем, по этому методу http://mum.mikrotik.com/presentations/US12/steve.pdf). Часто в браузерах на компьютерах подвисает загрузка с сообщением «ожидание ответа от сайта…». Этого не происходит, если отключить один из WAN-интерфейсов (неважно, какой именно). Я знаю, что при использовании метода per-connection-classifier=both-addresses-and-ports бывают проблемы с HTTPS-сайтами, поэтому я добавил в правила **dst-port=!443**, но всё равно зависания случаются и на HTTP-сайтах. Что ещё можно проверить? Спасибо!
Пока никаких хороших новостей, также один пользователь с правилом маршрутизации, которое стоит перед правилами PCC, чтобы обойти механизм PCC, столкнулся с проблемой навигации. Похоже, что звонки, сделанные через WAN, не получают правильный ответ или получают ответ через другой WAN. Вот мои правила mangle:
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
Это происходит на всех сайтах или только на некоторых? Попробуй переключиться на «both-addresses», если проблема только на нескольких сайтах, тогда можно убрать ограничение dst-port=443.
Это очень случайно... к счастью, это происходит лишь на нескольких процентах посещаемых сайтов, не могу сказать, что какой-то сайт страдает больше другого, похоже, что нет. Сейчас проверяю только с обеими адресами, дам знать. Также собираюсь проверить метод по пропускной способности, как в http://mum.mikrotik.com/presentations/US12/tomas.pdf, и посмотреть, как он себя проявит... (есть у кого-нибудь отзывы по этому поводу??)
Думаю, у нас похожие проблемы. Я в Китае. Здесь у нас есть три интернет-провайдера по всей стране, назовём их Y, L и M. Они обеспечивают хорошее соединение, если и сервер, и клиент находятся внутри их сети. Но при этом они дают ограниченную пропускную способность пользователям, которые хотят получить доступ к серверам в другой сети. И это только начало. Чтобы улучшить скорость для пользователей из разных сетей, почти все важные сайты предоставляют разные серверы для пользователей разных провайдеров. Например, если пользователь подключён к Y, при пинге сайта он получит IP-адрес, который принадлежит серверу внутри сети Y. Вот тут и начинаются настоящие проблемы. Что касается PCC, то соединения распределяются по разным WAN, и может получиться так, что пользователь получает IP сервера из Y, а реальное HTTP-соединение идёт через L или M. Такое соединение будет гораздо медленнее, чем в обычной ситуации. Ещё одна проблема — это DNS. Y, L и M ограничивают доступ к своим DNS только для своих пользователей. То есть, если вы пингуете DNS сервер, который получили от ADSL1, но пинг идёт с ADSL2, ответа не будет. Чтобы решить проблему с DNS, можно указать публичного DNS-провайдера и не использовать тот, что вы получаете от своего провайдера по ADSL или другому способу. А вот с проблемой серверов пока не придумал решения.
Mrz, спасибо, согласно вики: Обратите внимание, что не все пакеты в соединении могут проходить через fasttrack, поэтому вполне возможно увидеть некоторые пакеты, идущие по медленному пути, даже если соединение уже помечено для fasttrack. Вот почему правило с action=accept обычно ставится сразу после fasttrack-соединения. Пакеты, прошедшие fasttrack, обходят файрвол, отслеживание соединений, простые очереди, очередь с parent=global, ip traffic-flow (ограничение убрали в версии 6.33), ip accounting, ipsec, универсальный клиент hotspot, назначение vrf, поэтому администратор должен следить, чтобы fasttrack не мешал другой конфигурации.
Так что это не всегда хорошее решение — всё зависит от рабочей среды. Поскольку нормально, что перечисленные выше настройки обходятся fasttrack, когда же эта функция действительно полезна? Нужно ли считать, что fasttrack с pcc лучше избегать?
Есть какие-то новости по этому поводу? Я мучаюсь с этой проблемой уже несколько месяцев!! Я много постил тут, на 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