[SOLVED]три подключения через одного провайдера на одном шлюзе

подскажите пожалуйста, есть три подключения через одного провайдера, всем трём выдаётся серый ip вида 10.0.0.0/23, единый шлюз и dns.
хочется "объединить" скорости интерфейсов, сделать на выходе из 3х каналов по 256 один канал с бОльшей пропускной способностью.
имеется машинка с четырьмя сетевыми картами (три на провайдера, один на внутреннюю сеть)
если я сделаю, как нарисовано в этой статье, будет ли оно работать?
смущает то, что шлюз один и тот же.

Ничего хорошего из этого не

Ничего хорошего из этого не выйдет.
В LARTC описана реализация для _сети_с_реальными_ip_, маршруты на которую _есть_у_каждого_из_используемых_провайдеров_.
А у тебя: сети нету - раз, адреса серые - два, значит, у провайдера пакеты "наружу" еще и будут проходить NAT - три.
Поверь, там сразу столько заморочек с протоколом TCP возникнет, что... Не стоит возиться. Хорошего не выйдет ничего. Гарантированно.
Если задача стоит примерно так: "есть внутренняя сетка организации с активными www-серферами, хотелось бы, чтобы они серфили не через один внешний канал, а поравномернее через 3" - то это делается через сквид на этой самой твоей машине с 4 сетевыми. Можно через прозрачный сквид. Несколько через непонятное место - каждый отдельный внутренний ip будет ходить все равно через _один_ канал, просто каналы будут распределяться по разным группам ip внутренней сети, и сделать балансировку типа "работаем через самый незанятый канал" не получится. Только фиксированный для каждого ip. Но вот так уж технологии устроены.
А так, как написано в LARTC... Тебе придется сначала купить себе блок адресов, поднять BGP, договориться минимум с двумя провайдерами о подключении по BGP (я не занимался, но слышал, что это совершенно другие деньги)... а до того еще разобраться, что это я тут за страшные слова тут написал и как оно работает. И конфигурируется ;)
Поверь, для простого полудомашнего пользователя оно абсолютно не нужно...
А не полудомашние пользователи не подключаются к провайдерам, выдающим ip из приватных диапазонов =)

.

спасибо :)
забыл отписАться... оно таки работает...
именно, что это нужно "для трёх пользователей, хотящих побраузить и поВОВкать". расширение скорости закачки через канал до суммарной из предоставленных и не планировалось. понятно, что для этого бондинг нужно использовать или какой нить ppp multilink
просто нужно было свести 3 линии в одну wifi точку.
на сквиде рулить неудобно -- игры
bgp там нафиг не сдалось.
да, побаивался колец на канальном и сетевом уровне, но всё нормально.

?

Taelas написал(а):
спасибо :)
просто нужно было свести 3 линии в одну wifi точку.

Я таки не понял - это все, что было надо? Внешний (ну, серый внешний) IP для каждого пользователя собственный и уникальный? Никакой балансировки каналов не проводится? А зачем тогда вообще LARTC читать было, все решалось без особых сложностей и без iproute2?

описание задачи по телефону не соотвествовало требованиям

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

Avari написал(а):
все решалось без особых сложностей и без iproute2

как?

...

через SNAT в iptables... --to-source нужный IP и фильтр внутренних IP через -s...

.

провайдер отдаёт DHCP, иначе не работает. (могу предположить что это оптион82+снупинг+ИПаннамберед)
SNAT пробовал, в "postup()". эффект есть, но через некоторое время интерфейс отваливается.

не реально в ваших

не реально в ваших условиях.
Максимум баласировка.

глюки...

таки есть глюки:

Feb  3 18:53:12 gate dhcpcd[2919]: eth1: renewing lease of 10.83.15.83
Feb  3 18:53:12 gate dhcpcd[2919]: eth1: acknowledged 10.83.15.83 from 10.80.0.8
Feb  3 18:53:12 gate dhcpcd[2919]: eth1: leased 10.83.15.83 for 10800 seconds
Feb  3 18:53:18 gate dhcpcd[3402]: eth2: renewing lease of 10.83.13.102
Feb  3 18:53:18 gate dhcpcd[3402]: eth2: acknowledged 10.83.13.102 from 10.80.0.8
Feb  3 18:53:18 gate dhcpcd[3402]: eth2: leased 10.83.13.102 for 10800 seconds
Feb  3 18:53:24 gate dhcpcd[3897]: eth3: renewing lease of 10.83.13.79
Feb  3 18:53:24 gate dhcpcd[3897]: eth3: acknowledged 10.83.13.79 from 10.80.0.8
Feb  3 18:53:24 gate dhcpcd[3897]: eth3: leased 10.83.13.79 for 10800 seconds
Feb  3 19:13:39 gate -- MARK --
Feb  3 20:23:12 gate dhcpcd[2919]: eth1: renewing lease of 10.83.15.83
Feb  3 20:23:12 gate dhcpcd[2919]: eth1: acknowledged 10.83.15.83 from 10.80.0.8
Feb  3 20:23:12 gate dhcpcd[2919]: eth1: leased 10.83.15.83 for 10800 seconds
Feb  3 20:23:18 gate dhcpcd[3402]: eth2: renewing lease of 10.83.13.102
Feb  3 20:23:18 gate dhcpcd[3402]: eth2: acknowledged 10.83.13.102 from 10.80.0.8
Feb  3 20:23:18 gate dhcpcd[3402]: eth2: leased 10.83.13.102 for 10800 seconds
Feb  3 20:23:24 gate dhcpcd[3897]: eth3: renewing lease of 10.83.13.79
Feb  3 20:23:24 gate dhcpcd[3897]: eth3: acknowledged 10.83.13.79 from 10.80.0.8
Feb  3 20:23:24 gate dhcpcd[3897]: eth3: leased 10.83.13.79 for 10800 seconds
Feb  3 21:53:12 gate dhcpcd[2919]: eth1: renewing lease of 10.83.15.83
Feb  3 21:53:12 gate dhcpcd[2919]: eth1: acknowledged 10.83.15.83 from 10.80.0.8
Feb  3 21:53:12 gate dhcpcd[2919]: eth1: leased 10.83.15.83 for 10800 seconds
Feb  3 21:53:18 gate dhcpcd[3402]: eth2: renewing lease of 10.83.13.102
Feb  3 21:53:24 gate dhcpcd[3897]: eth3: renewing lease of 10.83.13.79

смущает !первая! повторная выдача адресов через полтора часа, а не через 3, как указано dhcp сервером
и через 3-4 подобных переполучений адреса, интерфейс перестаёт маршрутизироваться. спасает рестарт (но, блин, рвётся сессия), всякие WoW и LA сбиваются.
сетевухи на realtek (RTL-8139/8139C/8139C+)
пробовал различные режимы RX/(PIO||MMIO) в ядре, эффект не пропадает.
masquerade, snat в iptalbes

...

Taelas написал(а):
смущает !первая! повторная выдача адресов через полтора часа, а не через 3, как указано dhcp сервером

Из практики - это нормально. Это не повторная выдача адреса. это обновление lease. Вы же не хотите, чтобы работающему интерфейсу по таймауту адрес отобрали и по запросу другой назначили? Вот оно и обновляет. По большому счету, это просто сброс таймера на dhcp-сервере.

Taelas написал(а):
и через 3-4 подобных переполучений адреса, интерфейс перестаёт маршрутизироваться. спасает рестарт (но, блин, рвётся сессия), всякие WoW и LA сбиваются.

Странно. А dhcp-клиент интерфейс не опускает на долю секунды? Таблицу маршрутизации смотрели? Просто так пакеты ходить не перестают. Точно все маршруты в этот момент на месте? И ВО ВСЕХ ТАБЛИЦАХ??? Я когда-то с размаху наступил на грабли именно с тем, что не в каждой таблице маршрут был прописан... вот вроде бы для пакетов из внутренней подсети в ту же подсеть маршрут не нужен... А винда почему-то пакеты кидала через роутер - идиотизм :(
В общем, я бы копал в направлении маршрутизации. И еще мб dhcp-клиента. Можно сменить, их несколько разных.

Avari написал(а):Из практики

Avari написал(а):
Из практики - это нормально.

таки да. поросто внимания никогда не обращал, пока работает всё.

Avari написал(а):
Это не повторная выдача адреса. это обновление lease.

ну собственно это и имел в виду.

Avari написал(а):
Странно. А dhcp-клиент интерфейс не опускает на долю секунды?

да вот и мне показалось странным...
ни на работе, ни дома dhcpcd не рвал сессию.
маршруты смотрел. всё на месте. это была первая мысль. (а куда оно денется?)
эффект (вроде) пропал, после логической "замены" сетевух (поменял mac адрес первой со второй и шнурки тоже).
блин... странно всё это...
но, временно [SOLVED]

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".