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

что требуется несколько таблиц маршрутизации

Да

реализовать не хватает ума.

Вы не описали что уже попробовали.

Были жалкие попытки маршрутизации, потому что в этом ноль С таблицами не пробовал

А цель какая?

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

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

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

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

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

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

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

Есть же openmptcprouter для TCP В моем случае UDP, суммируется для передачи видео

sysctl net.ipv4.conf.all.rp_filter=0
sysctl net.ipv4.conf.ppp0.rp_filter=0
sysctl net.ipv4.conf.ppp1.rp_filter=0

Оба ppp дефолтные, все равно функционирует только один

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

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

Что это значит? Запустите curl --interface ppp1 ifconfig.co, должны увидеть адрес интерфейса ppp1.

Надо использовать один 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, деления нагрузки не будет. Используй несколько разных исходящих портов чтобы было деление нагрузки.

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

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

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

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

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

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

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

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

ОП большой путаник. Речь идёт о доставке видеопотока от «клиента» (ПК с 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Описал как понимаю (как идиот)

To get any benefit over using SRT directly, the sender should have 2 or more network links to the SRT listener (in the typical application, these would be internet-connected 4G modems). The sender needs to have source routing configured, as srtla uses bind() to map UDP sockets to a given connection.

Если curl --interface ppp0 ifconfig.co и curl --interface ppp1 ifconfig.co выдают разные адреса, то поздравляю — с сетевой точки зрения всё настроено корректно.

Разные, но выдают только когда поочередно назначаю дефолтными

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

# 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 маршрут всего один. Потому что нельзя вставить два маршрута с одинаковым префиксом и одинаковой метрикой.

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

Вообще-то можно при определённых условиях. Это, как раз, ECMP и есть.

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

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

Покажи ещё плиз

ip ro get 8.8.8.8
ip ro get 8.8.8.8 dev ppp0
ip ro get 8.8.8.8 dev ppp1
ip ro get 8.8.8.8 from 10.119.***.***
ip ro get 8.8.8.8 from 11.69.***.***

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

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.*.*.

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

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

8.8.8.8 from 11.69.***.*** dev ppp1 table usb2 uid 0

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

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

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