LINUX.ORG.RU
Форум — Admin  

Маршрутизация сети с несколькими интерфейсами

 , , ,


0

1

Здравствуйте! Имеется система Ubuntu c несколькими модемами, работающие по протоколу ppp. При подключении к сети (например через wvdial), отдает и получает трафик только один модем при назначении route add default ppp0 (1,2). Подскажите, пожалуйста, как настроить маршрутизацию таким образом, чтобы могли функционировать сразу все модемы (ppp0, ppp1, ppp2 etc.). Бьюсь над этой задачей, понимаю только в общих чертах, что требуется несколько таблиц маршрутизации (не уверен), реализовать не хватает ума.

У модемов нет DHCP на борту, IP выдается при звонке


← Как забриджить разноскоростные интерфейсы?
Почему пиры wireguard не видят друг друг без sysctl -w net.ipv4.ip_forward=1? →
Ответ на: комментарий от Anoxemian

Цель в агрегации интерфейсов для увеличения пропускной способности

Клиент раскидывает по доступным интерфейсам пакеты, сервер принимает и собирает в кучу

Соответственно, с данными модемами у меня возникли проблемы, коих не было с простыми модемами, типа Хуавея, которые работают с тычка, имея DHCP, автоподключение и тд.

vvomew
() автор топика

Достаточно выбрать интерфейс (сделать bind к интерфейсу, именно интерфейсу, а не только к IP-адресу) и отправить пакет. Также необходимо либо добавить маршруты по умолчанию через все интерфейсы (метрика не имеет значения), либо отключить reverse path filtering sysctl net.ipv4.conf.all.rp_filter=0, net.ipv4.conf.pppX.rp_filter=0.

ValdikSS ★★★★★
()
Ответ на: комментарий от vvomew

В рамках tcp сессии будет работать один модем, round-robin наверно как-то p2p вытянет, но в общем случае модель использования не увеличит пропускную способность.

Клиент раскидывает по доступным интерфейсам пакеты, сервер принимает и собирает в кучу

Вот да. Кто такие, признавайся/делись.

Anoxemian ★★★★★
()

Возможно и скорее всего я чего-то не понимаю, формулирую проблему не достаточно четко, не правильно изъясняюсь, о чем - не достаточности ума я сразу и сообщил. Извиняюсь.

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

vvomew
() автор топика
Ответ на: комментарий от vvomew

Надо использовать один multipath маршрут вместо нескольких обычных маршрутов:

ip route del default
ip route del default
ip route add default nexthop dev ppp0 weight 1 nexthop dev ppp1 weight 1

Однако уже довольно давно nexthop выбирается не случайным образом, и не по кругу, а по хешу от некоторых полей IPv4 пакета. Какие поля используются задаёт sysctl net.ipv4.fib_multipath_hash_policy и sysctl net.ipv4.fib_multipath_hash_fields https://www.kernel.org/doc/Documentation/networking/ip-sysctl.rst.

Если у тебя все UDP пакеты одинаковые (0.0.0.0:5432->80.70.60.50:1234), то использоваться будет один и тот же nexthop, деления нагрузки не будет. Используй несколько разных исходящих портов чтобы было деление нагрузки.

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

У ОПа есть некий промежуточный сервер, см. сообщение Маршрутизация сети с несколькими интерфейсами (комментарий)

Клиент раскидывает по доступным интерфейсам пакеты, сервер принимает и собирает в кучу

Вряд ли ему нужна балансировка отдельных пакетов на уровне маршрутов. Она не поможет в общем случае.

ValdikSS ★★★★★
()
Ответ на: комментарий от vvomew

Цель в агрегации интерфейсов для увеличения пропускной способности

Нельзя просто так взять и объединить каналы к разным провайдерам. Балансировка возможна только в случае, если эти каналы ведут в одно место. Вариантов два: ECMP (Equal-Cost Multi-Path) или Multi-Link PPP.

Всё остальное - не балансировка, а ручное, либо полуручное (если с BGP) разруливание.

AS ★★★★★
()
Ответ на: комментарий от ValdikSS

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

Конкретно эти модемы функционируют только по одному и только когда я назначаю конкретный модем дефолтным

vvomew
() автор топика
Ответ на: комментарий от ValdikSS

ОП большой путаник. Речь идёт о доставке видеопотока от «клиента» (ПК с Ubuntu, подключённый к интернету несколькими PPP линками) на «сервер» (со статическим белым адресом). ОП хочет, чтобы линукс на «клиенте» использовал все PPP линки для транспортировки (одного) видеопотока.

Во времена ядра с 3.6 до 4.3 это было возможно, multipath маршруты выбирали nexthop случайным образом. Но начиная с 4.4 multipath маршруты используют по сути flow based routing. Поэтому хочешь деления нагрузки – дели трафик сам на несколько flow.

Можно наколхозить выбор маршрута по кругу с помощью iptables и ip rule. Маркируем чётные пакеты маркой 101, нечётные маркой 102:

iptables -t mangle -A OUTPUT -m statistic --mode nth --every 2 --packet 0 -j MARK --set-mark 101
iptables -t mangle -A OUTPUT -m statistic --mode nth --every 2 --packet 1 -j MARK --set-mark 102

Выбираем таблицу маршрутизации исходя из марки:

ip rule add fwmark 101 table 101
ip rule add fwmark 102 table 102

Сами таблицы:

ip route add default dev ppp0 table 101
ip route add default dev ppp1 table 102
iliyap ★★★★★
()
Ответ на: комментарий от vvomew

Конкретно эти модемы функционируют только по одному и только когда я назначаю конкретный модем дефолтным

Ну как ещё-то должно работать?

Вместо дефолта можно для части интернета использовать один модем, для части другой:

ip r add 0.0.0.0/1 via ppp0
ip r add 128.0.0.0/1 via ppp1

Ну и стоит учесть диапазоны, которых в Интернет не бывает, чтобы марсианские пакеты не плодить (RFC 6890).

AS ★★★★★
()
Ответ на: комментарий от AS

С обычными модемами, проводными интерфейсами и wifi работает

Пример c пятью интерфейсами, два обычных модема (не проблемных): https://imgur.com/eouX5Xv

Пример с тремя интерфейсами, два модема (проблемных, о которых идет речь): https://imgur.com/xKCxQYo

vvomew
() автор топика
Ответ на: комментарий от vvomew

Пример c пятью интерфейсами, два обычных модема (не проблемных): https://imgur.com/eouX5Xv

Пример с тремя интерфейсами, два модема (проблемных, о которых идет речь): https://imgur.com/xKCxQYo

Даже то, что это не открывается, не важно. Чтобы пакет пришёл на заданный IP, надо, чтобы его кто-то на него отправил. Запрос заданного IP можно выполнить, а вот просто так на заданный IP послать пакет нельзя без того, что я назвал.

AS ★★★★★
()
Ответ на: комментарий от vvomew

Мне не хватает знаний чтобы объяснить реализацию Вот пример с документацией https://github.com/BELABOX/srtla

Ну так это всё равно нечто, что работает снаружи и «знает» про доступ к нужному устройству. Так да, можно нагородить. Но это никак не попадает под исходное сообщение.

AS ★★★★★
()
Ответ на: комментарий от vvomew

Ты бы показал свою сетевую конфигурацию, чтобы не гадать. Например:

# ip -4 a
2: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 1.2.3.4/32 scope global dummy0
       valid_lft forever preferred_lft forever
3: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 5.6.7.8/32 scope global dummy1
       valid_lft forever preferred_lft forever

# ip ro
default dev dummy0 scope link metric 1 
default dev dummy1 scope link metric 2 

# ip ru
0:	from all lookup local
1:	from all oif dummy0 lookup 101
2:	from all oif dummy1 lookup 102
3:	from 1.2.3.4 lookup 101
4:	from 5.6.7.8 lookup 102
32766:	from all lookup main
32767:	from all lookup default

# ip ro ls table 101
default dev dummy0 scope link 

# ip ro ls table 102
default dev dummy1 scope link

Может у тебя проблема в том, что default маршрут всего один. Потому что нельзя вставить два маршрута с одинаковым префиксом и одинаковой метрикой.

iliyap ★★★★★
()
Ответ на: комментарий от AS

ECMP в линуксе настраивается добавлением одного multipath маршрута, а не добавлением нескольких маршрутов с одинаковыми префиксом и метрикой. Разве нет?

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

ip -4 a:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.31.21/24 brd 192.168.31.255 scope global eth0
       valid_lft forever preferred_lft forever
49: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 3
    inet 10.119.***.***/32 scope global ppp0
       valid_lft forever preferred_lft forever
50: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 3
    inet 11.69.***.***/32 scope global ppp1
       valid_lft forever preferred_lft forever

ip ro:

default dev ppp0 scope link
default dev ppp1 scope link
default via 192.168.31.1 dev eth0
192.168.31.0/24 dev eth0 proto kernel scope link src 192.168.31.21

ip ru:

0:      from all lookup local
32765:  from 192.168.31.21 lookup eth0
32766:  from all lookup main
32767:  from all lookup default
vvomew
() автор топика
Ответ на: комментарий от iliyap

ip ro get 8.8.8.8:

8.8.8.8 dev ppp0 src 10.119.***.*** uid 0
    cache

ip ro get 8.8.8.8 dev ppp0:

8.8.8.8 dev ppp0 src 10.119.***.*** uid 0
    cache

ip ro get 8.8.8.8 dev ppp1:

8.8.8.8 dev ppp1 src 11.69.***.*** uid 0
    cache

ip ro get 8.8.8.8 from 10.119.***.***:

8.8.8.8 from 10.119.***.*** dev ppp0 uid 0
    cache

ip ro get 8.8.8.8 from 11.69.***.***:

8.8.8.8 from 11.69.***.*** dev ppp0 uid 0
    cache
vvomew
() автор топика
Ответ на: комментарий от vvomew

ip ro get 8.8.8.8 – приложение не биндит свой сокет ни к адресу, ни к интерфейсу – пакет пойдет через ppp0 с src 10.119.. – ок.

ip ro get 8.8.8.8 dev ppp0 – приложение биндит свой сокет к интерфейсу ppp0 – пакет пойдёт через ppp0 с src 10.119.. – ок.

ip ro get 8.8.8.8 dev ppp1 – приложение биндит свой сокет к интерфейсу ppp1 – пакет пойдёт через ppp1 с src 11.69.. – ок.

ip ro get 8.8.8.8 from 10.119.*.* – приложение биндит свой сокет к адресу 10.119.*.* – пакет пойдёт через ppp0 – ок.

ip ro get 8.8.8.8 from 11.69.*.* – приложение биндит свой сокет к адресу 11.69.*.* – пакет пойдёт через ppp0 – не ок.

Чтобы исправить последний кейс, надо добавить:

ip route add default dev ppp1 table 102
ip rule add prio 1 from 11.69.*.* table 102

И после этого снова проверить ip ro get 8.8.8.8 from 11.69.*.*.

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

Вроде как сработало в первый раз, начало грузить по всем интерфейсам, но вылетает модем (буду разбираться почему) Только при подключении каждый раз IP новый, следовательно правило работать не будет

vvomew
() автор топика
Ответ на: комментарий от vvomew

Ну дак правило должно прописываться скриптом, как и маршруты. Скрипт, в общем то, простой, главное чтобы он был расчтан на удаление/замену старого правила, от предыдущей ppp-сесии, чтобы со временем число правил не росло до упора.

pppd при подклчении вызывает скрипт ″/etc/ppp/ip-up″ , которому передаёт параметрами интерфейс, адрес и т.д. В большинстве дистрибутивов этот скрипт назначает переданые значения параметров переменным с читаемым именем и вызывает скрипты из каталога ″/etc/ppp/ip-up.d″.

Я только не понял, почему с модемами с dhcp всё работало, кто в этом случае прописывал правила и маршруты?

mky ★★★★★
()
← Как забриджить разноскоростные интерфейсы?
Admin
Почему пиры wireguard не видят друг друг без sysctl -w net.ipv4.ip_forward=1? →