2 канала, 2 IP. Балансировка+NAT

Дополнение: ppp0 - это PPTP VPN через eth1, ppp1 - это PPPoE через eth2.

А multipath routing разве по дефолту нормально работает в ванильном ядре? :)

Я уже не помню подробностей, но мне пришлось ставить патчик на ядро,
после чего примерно такая схема работает как часы.

P.S. читать до просветления:

http://www.ssi.bg/~ja/#routes
http://www.ssi.bg/~ja/nano.txt

кстати, тема уже обсасывалась в форуме на моей памяти раза 3 или 4.

Я уже раза 2 кроме этого отвечал то же самое. Можно было и поиском воспользоваться:)

Ядро из Debian.

Описанная схема НЕ работает, если внутренняя сеть активно общается с Internet'ом. Соединения рвутся.

Естесственно, рвутся. Я ж привёл ссылки. Надо читать. Там всё написано.
Внимательнее просто надо читать. 

Вот смотри:

First, this will not work for a single computer with two modem
connections. Load balancing does work reasonably well, but only with a
high number of simultaneous connections to different remote sites.

The tests I'm performing are on a network with 17 client computers
with an daily download (12h) of some 600MB of HTTP traffic in several
hundreds of thousands of connections.

When one connection fails while being used, this connection will be
lost and can't be continued on another line. The user will have to
establish this connection anew. If it was a big download and the
server doesn't support continuation, he'll be out of luck.

А нужно, чтобы не рвались. :)

Я сюда за тем и пришёл.

Ситуация: аська + mldonkey. Второй интенсивно поключается к новым хостам, в результате чего аська отключается через каждые 5-10 минут.

1. ты патч поставил? доку почитал?
2. Должно работать.
3. Нет? см.п.1

А можно узнать какие именно соединения рвутся: транзитные через этот шлюз или соединения с самого шлюза ?
Если транзитные, то они и должны рваться, т.к. пакеты идут "from откуда_попало" и под правила "from $IP_PPP0" и "from $IP_PPP1" естественно не подпадают, поэтому маршрутизируются через default маршрут в таблице main, в котором 2 nexthop-а, т.е. куда попадет - туда и пойдут, вместо того, чтоб идти через прежний канал.

Для предотвращения этого используется CONNMARK (+MARK), которым маркируют соединения, и на основе этих маркировок делают -j ROUTE (или через ip rule) в нужную сторону.

2 RomanU:
> А multipath routing разве по дефолту нормально работает в ванильном ядре? :)
Конечно работает. Вопрос в том, что считать "нормальным" :-)
По-моему балансировка на основе маршрутизации никогда не будет давать нормальную балансировку, что с патчами, что без :-)
Кстати, может расскажете про механизм работы патчей "http://www.ssi.bg/~ja/#routes"; ? Оно раскидывает по каналам пакеты, целые соединения ? Кешируются маршруты, нет ? А то после нескольких прочтений nano.txt я так и не понял :-)

кстати, тема уже обсасывалась в форуме на моей памяти раза 3 или 4.

Я уже раза 2 кроме этого отвечал то же самое. Можно было и поиском воспользоваться:)

RomanU (*) (09.09.2005 10:01:54)

Не в упрёк будет сказано, но поиском по форуму АБСОЛЮТНО невозможно пользоваться. Если будет доделан поиск - будет меньше повторений.

И еще я давно советовал в раздел форума linux.org.ru, что б ввели какую-то систему автовсплытия тем из архива. Например, если я таки нашел каким-то чудом интересующую меня тему, увидел неясность и добавил новый пост, то она переносилась бы вверх по списку. Даже если топик был создан в 2002 году.

2spirit:
В том документе подводится итог того, что выполняют патчи. Подробнее
можно узнать из самих патчей. Например, патч помогает определить 
маршрут для пакета, чтобы NAT корректно обрабатывал схему
с несколькими маршрутами (что по умолчанию он не может делать).

2seb:
поиск действительно работает не очень, но когда я только что ввёл
фразу "2 канала", то нашёл несколько ссылок, из которых более-менее
можно что-то подчерпнуть. :)

> А можно узнать какие именно соединения рвутся: транзитные через этот шлюз или соединения с самого шлюза ?

Транзитные.

> т.е. куда попадет - туда и пойдут, вместо того, чтоб идти через прежний канал.

Не-е-е.
Ядро кеширует маршруты и в следующий раз для того же самого dst_ip использует тот же самый GW.
Поэтому-то вся конструкция работает.

На самом деле сейчас
net/ipv4/route/gc_thresh=1048576
net/ipv4/route/secret_interval=8192
net/ipv4/route/gc_interval=86400
временно помогли, но хочется более "прямого" решения

> Для предотвращения этого используется CONNMARK (+MARK), которым маркируют соединения, и на основе этих маркировок делают -j ROUTE (или через ip rule) в нужную сторону.

А вот за это огромное спасибо! :)
man iptables читал, но этот кусок просмотрел.
Бум пробовать.

> Не-е-е.
> Ядро кеширует маршруты и в следующий раз для того же самого dst_ip использует тот же самый GW.
> Поэтому-то вся конструкция работает.
Так это и ежу понятно :-) Оно ж потому у вас и работает некоторое время (5-10 мин), пока маршрут живет в кеше. А когда кеш переполянется или запись устаревает, ядро заново просматривает default маршрут с несколькими nexthop-ами, вот в этот момент как раз и может определиться другой GW, не такой, как раньше, поэтому соединения и рвутся.

Рекомендую еще посмотреть вот это:
http://routeskeeper.sourceforge.net/Routeskeeper/MultihomingWithLinux.html

> Так это и ежу понятно :-) Оно ж потому у вас и работает некоторое время (5-10 мин), пока маршрут живет в кеше. А когда кеш переполянется или запись устаревает, ядро заново просматривает default маршрут с несколькими nexthop-ами, вот в этот момент как раз и может определиться другой GW, не такой, как раньше, поэтому соединения и рвутся.

"Так это и ежу понятно" (c) ;)

Описанные выше параметры позволяют кэшу жить намного дольше этих 5-10 минут.

Но с MARK/CONNMARK решение, конечно же, более правильное. Будем внедрять его.