Проблема с http-загрузками через линии балансировки нагрузки.

Какие у тебя настройки таймаута для отслеживания соединений? Как выглядит твоя конфигурация балансировки нагрузки? Ты говоришь о политике маршрутизации – ты заставляешь трафик идти по конкретной линии или как-то иначе, или используешь ECMP? Сэм.

У меня тоже большие скачивания прерываются. Настройки отслеживания: enabled: yes, tcp-syn-sent-timeout: 10s, tcp-syn-received-timeout: 10s, tcp-established-timeout: 1d, tcp-fin-wait-timeout: 20s, tcp-close-wait-timeout: 20s, tcp-last-ack-timeout: 20s, tcp-time-wait-timeout: 20s, tcp-close-timeout: 20s, udp-timeout: 20s, udp-stream-timeout: 3m, icmp-timeout: 20s, generic-timeout: 10m, tcp-syncookie: no, max-entries: 552240, total-entries: 3259.

Если вы не используете NAT, ECMP работает отлично. У нас есть 2 канала на 100 Мбит/с, которые работают по ECMP для исходящего трафика, и проблем никогда не возникает. Думаю, проблема в том, что ECMP не может сопоставлять по источнику, если все источники одинаковые, то есть адреса, находящиеся за NAT. Думаю, можно решить проблему, используя политический маршрутизатор и действие 'same' для NAT, кажется... Сэм.

Да, ты прав, но как мне использовать политический маршрутизатор, если моя исходная машина – веб-прокси?

Звучит хорошо, я жду этого, но не веб-прокси на самом MT, полагаю?

Я потратил около трех месяцев, чтобы ECMP заработал с 8 DSL-линиями (NAT'ed на DSL-модемах) и MT в качестве веб-прокси. В конце концов, после многих недель исследований, разочарований и потери довольно большого количества клиентов, я отказался от этой идеи. ECMP просто не кажется работающим должным образом для этого приложения. У меня получалось что-то вроде работы, путем source-routing определенных протоколов, таких как IM и SSH и так далее, но ECMP на порту 80 постоянно ломался, что было своеобразной проблемой. Не было никакой конкретной закономерности или времени, когда он ломался, но он всегда ломался. Я даже несколько раз публиковал на этом форуме, указывая свою конфигурацию и надеясь на адекватный ответ от Mikrotik. Но ничего не произошло. Недавно я попытался сделать это по-другому, используя mangle на цепочке входящих данных и затем пытаясь source route на цепочке исходящих данных... но, видимо, это работает только с connection marks в версии 2.8, а в версии 2.9 policy routing не распознает connection marks, но только routing marks. Мне все еще нужно понизить версию роутера, чтобы проверить эту теорию. Вот моя недавняя публикация на эту тему: http://forum.mikrotik.com/t/how-do-i-source-route-packets-originating-from-the-proxy/5825/1 Вот некоторые старые публикации: http://forum.mikrotik.com/t/does-load-balancing-actually-work-in-2-9/2779/1 Мой совет — прекратите использовать ECMP и используйте policy routing, пока не начнете терять клиентов. И забудьте об использовании прокси-сервера, если не решите проксировать только одну из ваших линий. Думаю, ребята из Mikrotik просто устали от этой проблемы и больше не отвечают. Возможно, кто-нибудь должен поднять этот вопрос на конференции в Далласе, потому что там есть презентация по балансировке нагрузки. Многие люди на самом деле пытаются сделать это, используя несколько дешевых DSL-линий, а bonding пока не широко доступен.

ECMP будет распределять исходящий трафик. Если вы используете NAT и веб-прокси, то может потребоваться дополнительная настройка. Возможно, вам потребуется маршрутизация по политике. Маршрутизация по политике не так проста, как кажется, вам даже понадобятся маршруты для локальных сетей. Ещё несколько провайдеров с разными IP-пространствами? Тогда вам придётся заниматься маркировкой пакетов, которые должны выходить через тот же интерфейс, через который они пришли. У нас это работает отлично. Мы веб-прокси не используем. Если у вас возникла конкретная проблема или вы застряли — напишите об этом (с конкретикой). Сэм.

Да, говорят, есть ECMP routing как опция, и в инструкции сказано, что это хорошее решение, потому что это балансировка "по сессии" round-robin, так что не страдает от проблем балансировки по пакетам. Работало у нас в 2.7, но спустя год-два наш Cache drive начал выдавать ошибки, из-за которых пришлось раз в неделю или около того очищать и перестраивать кэш. Нам советовали обновиться до 2.8.x, и с тех пор мы вообще не можем заставить ECMP routing работать с Transparent proxy.

Обязательно проверю роутер DLink, потому что мне действительно нужен вариант, который сможет распределять нагрузку по нескольким линиям и работать с прокси. Думаю, с Mikrotik, скорее всего, произошло изменение архитектуры продукта, из-за чего это перестало работать. Вместо того, чтобы признать проблему перед клиентами и сказать, что это сложно исправить, они просто молчат. Ну и позор. Так 90-е.