Multiple WAN routing policy

[Kozlov_Sergey]

Предлагаю добавить возможность в маршрутизаторах Keenetic использовать маршрут по умолчанию на несколько интерфейсов (для 2 подключений интернета одновременно).

[Roman_Petrov]

P.S. У меня одного такое ощущение, что я велик изобретаю заново ?

Товарищ! С Вашим рвением и усердием цены Вам нет! Рад бы тож поковыряться, времени пока нет Пока морально поддерживаю

Спасибо!! Вот тоже времени не особо, чуть почитал, маленько попробовал, снова убегаю. Просим всех по чуть ручку приложить, на всех глядишь и осилим ))))

[Le ecureuil]

Я смотрю тема актуальна и животрепещуща.

Товарищ ndm натолкнул меня на кое-какие идеи, напишите на каких девайсах вы точно сможете проверить Multilink WAN, а я кое-что попробую изобразить.

[Roman_Petrov]

Я смотрю тема актуальна и животрепещуща.

Товарищ ndm натолкнул меня на кое-какие идеи, напишите на каких девайсах вы точно сможете проверить Multilink WAN, а я кое-что попробую изобразить.

Да, тема актуальна, не спорю. Но маловато познаний, можно было бы потихоньку курить, но есть серьёзный недостаток времени. Я смогу на Ultra и Ultra II, единственное у меня 2 небольших нюанса:

1) на обоих я смогу проверить, подключив к одному вышестоящему рутеру (т.е. оба подключения будут в одной подсети типа первый от роутера 192.168.1.1 и другой от одного провайдера от одного его шлюза, тоже 2 кабеля LAN). Но с другой стороны, такое подключение тоже имеет место ведь быть, для увеличения скорости, не только же к разным провайдерам подключаться. Или одно из подключений может быть через LTE модем.

2) у меня установлена альтернативная версия entware, не keenopt. Связано это с тем, что на момент необходимости в keenopt не оказалось lighttpd, а он мне очень нужен для работы. Сейчас максимум могу снести систему на ULTRA и поставить keenopt для экспериментов.

[yrzorg]

напишите на каких девайсах вы точно сможете проверить Multilink WAN, а я кое-что попробую изобразить.

есть возможность проверить работу нескольких белых ip на одном порту WAN, девайс U2

[Leksey118]

Я смотрю тема актуальна и животрепещуща.

Товарищ ndm натолкнул меня на кое-какие идеи, напишите на каких девайсах вы точно сможете проверить Multilink WAN, а я кое-что попробую изобразить.

Ultra II

[Le ecureuil]

Превосходно, что у всех Ultra II. Значит на ней и будем испытывать.

[Roman_Petrov]

Превосходно, что у всех Ultra II. Значит на ней и будем испытывать.

Честно говоря, мне даже важнее на Ultra. Но если будет на Ultra2, то и на Ultra подпилить недолго, если не заработает сразу

[Roman_Petrov]

Превосходно, что у всех Ultra II. Значит на ней и будем испытывать.

Понять бы, как он, этот дефолтный маршрут маршрут меняеться при переходе на резервный канал, например, c помощью pingcheck , какой алгоритм там, то это можно было бы использовать для скрипта. Можно, конечно смотреть через командную строку, как происходит процесс дефолтирования наверно, только есть одна мозгокипучка по поводу того, как оба активных соединения дефолтировать-то. Идея как то не очень понятна.

1) Разве что дефолтировать, что бы загрузка по одному WAN а закачка по другому WAN. А Если WAN-ов три, четыре?

2) Или дефолтировать определенные пакеты или в зависимости от порта на определенный WAN.

3) Чтобы использовать несколько подключений одновременно в качестве бустера скорости, такое решение явно не подойдет. Ведь при этом решении вероятно придется файл при загрузке по пакету хватать то с одного интерфейса то с другого, чтобы суммарно его выкачивать с большей скоростью. Как интересно это отразиться на ресурсах роутера, если это делать софтверно? Как здесь заставить работать аппаратную часть, которая присутствует, чтобы не убивать софтверные ресурсы? Опять же - а если WAN-ов три, четыре?

Задачка явно для специалистов высокого уровня которые отлично знают все особенности железки и свой софт. Не для чайников в общем

[Le ecureuil]

Превосходно, что у всех Ultra II. Значит на ней и будем испытывать.

Понять бы, как он, этот дефолтный маршрут маршрут меняеться при переходе на резервный канал, например, c помощью pingcheck , какой алгоритм там, то это можно было бы использовать для скрипта. Можно, конечно смотреть через командную строку, как происходит процесс дефолтирования наверно, только есть одна мозгокипучка по поводу того, как оба активных соединения дефолтировать-то. Идея как то не очень понятна.

1) Разве что дефолтировать, что бы загрузка по одному WAN а закачка по другому WAN. А Если WAN-ов три, четыре?

2) Или дефолтировать определенные пакеты или в зависимости от порта на определенный WAN.

3) Чтобы использовать несколько подключений одновременно в качестве бустера скорости, такое решение явно не подойдет. Ведь при этом решении вероятно придется файл при загрузке по пакету хватать то с одного интерфейса то с другого, чтобы суммарно его выкачивать с большей скоростью. Как интересно это отразиться на ресурсах роутера, если это делать софтверно? Как здесь заставить работать аппаратную часть, которая присутствует, чтобы не убивать софтверные ресурсы? Опять же - а если WAN-ов три, четыре?

Задачка явно для специалистов высокого уровня которые отлично знают все особенности железки и свой софт. Не для чайников в общем

Вообще на эту тему есть прекрасный документ под названием LARTC, но использовать его нужно с умом.

Linux поддерживает множественные таблицы маршрутизации и source-based policy routing, потому дефолтных маршрутов может быть несколько, причем столько, сколько вашей душеньке угодно.

Насчет распределения нагрузки между каналами: в ядре 2.6.36 используется route cache, поэтому при первом обращении к удаленному адресу будет выбран один из маршрутов по умолчанию, и до конца жизни кэша (определяется динамически ядром) весь трафик на этот адрес будет идти по нему. Поэтому сразу хочу сказать во избежание недоразумений: при двух одновременно поднятых аплинках на 100 Мбит/с качать с одного удаленного адреса по HTTP или FTP со скоростью выше скорости 100 Мбит/сек не выйдет. А вот для торрента и подобной нагрузки ситуация идеальна: качать будет 200 Мбит/сек, также как и при любых загрузках сразу с нескольких адресов.

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

[Roman_Petrov]

Вообще на эту тему есть прекрасный документ под названием LARTC, но использовать его нужно с умом.

Linux поддерживает множественные таблицы маршрутизации и source-based policy routing, потому дефолтных маршрутов может быть несколько, причем столько, сколько вашей душеньке угодно.

Насчет распределения нагрузки между каналами: в ядре 2.6.36 используется route cache, поэтому при первом обращении к удаленному адресу будет выбран один из маршрутов по умолчанию, и до конца жизни кэша (определяется динамически ядром) весь трафик на этот адрес будет идти по нему. Поэтому сразу хочу сказать во избежание недоразумений: при двух одновременно поднятых аплинках на 100 Мбит/с качать с одного удаленного адреса по HTTP или FTP со скоростью выше скорости 100 Мбит/сек не выйдет. А вот для торрента и подобной нагрузки ситуация идеальна: качать будет 200 Мбит/сек, также как и при любых загрузках сразу с нескольких адресов.

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

Спасибо за разъяснения, почитаю, это интересно. Конечно, как у вас будет время, ждем и будем рады.

[dexter]

Поднял второй интерфейс eth3.9

Прописал такие команды

ip route add 192.168.105.0/24 dev eth2 src 192.168.105.5 table 101
ip route add default via 192.168.105.254 table 101
ip route add 192.168.106.0/24 dev eth3.9 src 192.168.106.3 table 102
ip route add default via 192.168.106.254 table 102


ip route add 192.168.105.0/24 dev eth2 src 192.168.105.5
ip route add 192.168.106.0/24 dev eth3.9 src 192.168.106.3
ip route add default via 192.168.105.254
ip rule add from 192.168.105.5 table 101
ip rule add from 192.168.106.3 table 102


ip route add 192.168.1.0/24    dev br0 table 101
ip route add 192.168.106.0/24     dev eth3.9 table 101
ip route add 127.0.0.0/8 dev lo   table 101
ip route add 192.168.1.0/24     dev br0 table 102
ip route add 192.168.105.0/24     dev eth2 table 102
ip route add 127.0.0.0/8 dev lo   table 102 	  


ip route add default scope global nexthop via 192.168.105.5 dev eth2 weight 1 \
nexthop via 192.168.106.3 dev eth3.9 weight 1

Вывод таблиц "101" и "102"

~ # ip route show table 101
192.168.1.0/24 dev br0  scope link
192.168.105.0/24 dev eth2  scope link  src 192.168.105.5
192.168.106.0/24 dev eth3.9  scope link
127.0.0.0/8 dev lo  scope link
default via 192.168.105.254 dev eth2
~ # ip route show table 102
192.168.1.0/24 dev br0  scope link
192.168.105.0/24 dev eth2  scope link
192.168.106.0/24 dev eth3.9  scope link  src 192.168.106.3
127.0.0.0/8 dev lo  scope link
default via 192.168.106.254 dev eth3.9

Вот вывод ip route

~ # ip route
192.168.100.254 via 192.168.105.254 dev eth2
192.168.101.1 via 192.168.105.254 dev eth2
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
192.168.105.0/24 dev eth2  proto kernel  scope link  src 192.168.105.5
192.168.106.0/24 dev eth3.9  proto kernel  scope link  src 192.168.106.3
default via 192.168.105.254 dev eth2

И все пакеты бегают через eth2

Есть у кого какие мысли как допилить?

[Le ecureuil]

Активно занимаюсь проблемой, и по факту выяснилось, что вот так сразу удовлетворительно работать не будет.

В ядре по умолчанию не включен multipath для advanced routing, потому балансировка между двумя каналами через несколько nexthop не заработает.

Плюс для полностью автоматической работы скриптов не хватает данных, которые может предоставить ndm - а значит все нужно вбивать руками, что недопустимо.

Как только эти рабочие вопросы будут улажены - будет создана тема с подробным описанием как и что сделать.

[dexter]

Всё понятно. Будем ждать, а потом активно участвовать. Стенд собран. Ultra 2 ждет своего часа.

[Le ecureuil]

Всё понятно. Будем ждать, а потом активно участвовать. Стенд собран. Ultra 2 ждет своего часа.

Если у вас есть реально два провайдера (или хотя бы два подключения к одному провайдеру) - то это просто прекрасно, то что нужно для теста.

[dexter]

Провайдеров у меня 1. Но для теста собрана виртуальная машина с двумя физическими интерфейсами.

[Roman_Petrov]

Всё понятно. Будем ждать, а потом активно участвовать. Стенд собран. Ultra 2 ждет своего часа.

Если у вас есть реально два провайдера (или хотя бы два подключения к одному провайдеру) - то это просто прекрасно, то что нужно для теста.

Здравствуйте. У меня есть:

1. Ultra 2 - ее могу подключить только к одному вышестоящему роутеру двумя кабелями (IP адреса по dhpc из одного сегмента) + есть мобильный 4g модем от того же провайдера, но сегмент отличный.

2. Ultra - может быть подключена к 2 портам оптического switch от одного провайдера 2+мя кабелями (2 адреса IP по dhpc из одного сегмента) + есть мобильный 4g модем от другого провайдера.

Вот на этом могу я потестить.

P.S. Спасибо за труды. Знал, что не просто это будет.

[Le ecureuil]

адреса IP по dhpc из одного сегмента

Такое к сожалению вообще не годится (и работать врядли будет, расчет идет на то, что nexthop у каждого аплинка уникален и подсети разные), здесь вам нужен не multiwan, а link aggregation скорее - это фича другого уровня.

[Roman_Petrov]

адреса IP по dhpc из одного сегмента

Такое к сожалению вообще не годится (и работать врядли будет, расчет идет на то, что nexthop у каждого аплинка уникален и подсети разные), здесь вам нужен не multiwan, а link aggregation скорее - это фича другого уровня.

Да, я примерно уже понял Можно конечно изображать на одном порту wan что то вроде роутера со своим dhpc (но тогда IP серый уже) чтобы получить это. Или тогда уже мой вариант модем + кабель как multiwan, как то так. Так тоже можно будет сделать? Могу конечно просить еще провайдера, может он мне может что-то предложить по разным подсетям, но это не факт ...

Кстати моя мысль в том, что это имеет место быть link aggregation тоже, если бы допустим просто изменением параметра выбрать при настройке то или другое (link aggregation или multiwan). Глубоко не копался, но сейчас на роутере не работает даже как резервирование по такой схеме, это понятно, никто даже не думал, что кто то так додумается подключать. В моем случае смысл в этом имеется явный. Были бы два аплинка а как их пристроить уже точно найдется *)

[Le ecureuil]

Просто если подсети на разных WAN совпадают, то это любой роутер одуреет и не сможет их сразу вдвоем использовать

[Roman_Petrov]

Просто если подсети на разных WAN совпадают, то это любой роутер одуреет и не сможет их сразу вдвоем использовать

Ну есть маленько, да. Было б конечно круто если бы мог Единственное могу еще на один wan подкинуть рутер с мобильным модемом тогда, если не сможем использовать встроенную фичу Keneetica При любом варианте изобразить то можно, главное - есть из чего

[yrzorg]

Пул ip адресов на одном порту wan тоже не годится для тестов?

[Leksey118]

Есть разные подсети, но правайдер один. Т.е. есть Ethernet и VDSL от одного провайдера на разных роутерах.

[KorDen]

Просто если подсети на разных WAN совпадают, то это любой роутер одуреет и не сможет их сразу вдвоем использовать

Хм, а если на двух интерфейсах гейтом железка с одним MAC но с разными IP? Т.е. к примеру провайдерский магистральник который шлюз по-умолчанию для серых IP идет шлюзом как 10.x.x.1, а для белых a.b.c.1, таким образом это два разных сегмента на L3, но один на L2. Не сойдет ли с ума?

PS: у меня есть возможность протестировать на Giga 2 с вариантом IPoE+4G, вполне возможно что будет и IPoE+IPoE от разных провайдеров (либо IPoE+L2TP), но последнее не в ближайшие пару недель однозначно.

[Le ecureuil]

Просто если подсети на разных WAN совпадают, то это любой роутер одуреет и не сможет их сразу вдвоем использовать

Хм, а если на двух интерфейсах гейтом железка с одним MAC но с разными IP?

Если подсети не пересекаются, то все должно быть нормально.

[yrzorg]

опробовал необходимое мне (пул ip на wan-порту) на pfsense 2.2.6

там это настраиватся буквально в несколько кликов ... жаль, что на кинетике так нельзя

[komsomolec]

Господа, я как админ организаций SMB и продвинутый home user поддерживаю идею в топике.

Не силен в программировании, но могу предложить подсмотреть реализацию балансировки нагрузки и MultiWAN у железок компании Draytek. Пару устройств (SMB и корпоративного сегмента) у меня есть, если интересно, могу предоставить на изучение.

[Roman_Petrov]

Господа, я как админ организаций SMB и продвинутый home user поддерживаю идею в топике.

Не силен в программировании, но могу предложить подсмотреть реализацию балансировки нагрузки и MultiWAN у железок компании Draytek. Пару устройств (SMB и корпоративного сегмента) у меня есть, если интересно, могу предоставить на изучение.

Идея оказалась сложная в реализации в виду отсутствия необходимой информации и отчасти необходимости на массовом уровне, а также ограничений, что это обязательно должны быть разные подсети если не разные провайдеры.. Если нельзя объединить несколько LAN чтобы вытянуть максимум по разным кабелям из одного провайдера с одной подсетью то имхо это не очень интересно, т.к. обычные юзеры редко имеют два скоростных подключения по LAN от разных провайдеров.. Интересно, если можно было бы впрячь несколько LAN как WANы с одного провайдера по нескольким кабелям, чтобы выкачать больше скорость, через один отправлять данные, через другой получать, привязывать к одному с одним IP ftp, к другому с другим IP web, упал один все проходит через второй и т.д. Как то так...

[r13]

Волею судеб с пятницы будет 2 провайдера по 100 Mbit на месяц, так что если будет что, потестирую.

[colimp]

Сделать псевдо multiwan довольно просто. По крайней мере торренты будут качаться сразу со всех интерфейсов. В #broadband.globals на вкладке "Дополнительно" можно задавать статические маршруты через интерфейсы, находящиеся в резерве. И мы там видим, что можно задать маршрут как до узла, так и до сети. Смотрим маски и находим 240.0.0.0. То есть весь диапазон IPv4 можно разбить на 16 участков с помощью этой маски. Итого надо внести всего 8 записей с такой маской и указать интерфейс резервного канала, через который пойдёт трафик.

Диапазоны с такой маской нарезаются подобным образом:

Первый 0.0.0.0-15.255.255.255,

второй 16.0.0.0-31.255.255.255

и т.д.

Я бы сразу исключил диапазоны, в которых встречаются IP, зарезервированные для локальных сетей во избежание накладок:

10.0.0.0 — 10.255.255.255

172.16.0.0 — 172.31.255.255

192.168.0.0 — 192.168.255.255

Перенаправляем трафик через резервное подключение, к примеру:

64.0.0.0 mask 240.0.0.0

80.0.0.0 mask 240.0.0.0

и т.п.

P2p-подключения более менее равномерно распределены по всему диапазону IPv4: одна часть пойдёт по умолчанию через основное подключение, другая часть попадёт под ваши правила и отправится в резервный канал.

[dexter]

Есть какие продвижения по данному вопросу на новом ядре?