# Кто нибудь использовал MPTCP на gentoo ?

## orion777

ЗАдача - сделать надёжное сетевое соединение путём резервирования (или даже одновременной пересылки данных по двум сетевым картам). Решил попробовать использовать https://multipath-tcp.org/pmwiki.php/Users/HowToInstallMPTCP?

Применил патч к версии ядра 4.10, пересобрал ядро, вбил настройки как показано тут https://multipath-tcp.org/pmwiki.php/Users/ConfigureRouting

Никакого эффекта не заметил, работает как и раньше через eth0 и всё  :Sad:  Не понимаю как им пользоваться..

Если кто использовал - отзовитесь пожалуйста!

Детально мои действия по настройке я описал здесь https://forums.gentoo.org/viewtopic-t-1076702.html ; но могу, если неободимо, перевести на русский и выложить тут.

----------

## TigerJr

Ну а что тут непонятного? 

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

Другой вопрос - как происходит механизм переключения?

В текущей твоей конфигурации, например если у тебя например упадет интерфейс eth0, будут ли ходить пакеты на адреса 0.0.0.0/0 через другой интерфейс? Или если соединение будет активно, а шлюз не будет доступен - то произойдёт ли что-то?

----------

## orion777

В этом то и весь смысл! Я хочу чтобы: ЛИБО второй интерфейс подключался когда падает первый ЛИБО чтобы он вообще сдал через два интерфейса сразу (такое тоже меня устроит).

Но, после внесения настроек иптаблц, рекомендованных на ихнем сайте, ни одного ни другого не происходит

```
pi64 ~ # # This creates two different routing tables, that we use based on the source-address.

pi64 ~ # ip rule add from 192.168.1.118 table 1

pi64 ~ # ip rule add from 192.168.8.10 table 2

pi64 ~ # # Configure the two different routing tables

pi64 ~ # ip route add 192.168.1.0/24 dev eth0 scope link table 1

pi64 ~ # ip route add default via 192.168.1.1 dev eth0 table 1

pi64 ~ # ip route add 192.168.8.0/24 dev eth3 scope link table 2

pi64 ~ # ip route add default via 192.168.8.1 dev eth3 table 2

pi64 ~ # # default route for the selection process of normal internet-traffic

pi64 ~ # ip route add default scope global nexthop via 192.168.1.1 dev eth0
```

----------

## TigerJr

```
ip route add default scope global nexthop via 192.168.1.1 dev eth0
```

Так если через маршрут default всё ходит, посмотри меняется ли он при недоступности адреса или пропадании линка?

 Если нет, то когда ты в ручную пропишешь

 *Quote:*   

> ip route change default scope global nexthop via 192.168.8.1 dev eth3

  - так будет ли что-то работать?

----------

## orion777

Такс, у меня явные проблемы, связанные с незнанием линукса..

Обнаружил что в ip route назаданно уже много чего, а именно:

```
default via 192.168.1.1 dev eth0

default via 192.168.1.1 dev eth0 src 192.168.1.118 metric 202

default via 192.168.8.1 dev eth3 src 192.168.8.10 metric 204

192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.118 metric 202

192.168.8.0/24 dev eth3 proto kernel scope link src 192.168.8.10 metric 204

```

В этой конфигурации он переходит на eth3 если eth0 падает (т.е. физически отключить), а вот если eth0 кабель оставить, но оборвать соединение где то дальше, то просто передача данных виснет и всё, на eth3 он не переходит.

Как это всё удалить? Команда  clear ip route 192.168.8.0/24 не даёт никакого результата.. 

Так же стоит заметить, что оба интерфейса получают IP по dhcp; так же запущены NetworkManager, dhcpcd, dhclient.

----------

## TigerJr

```
localhost /usr/src/linux # ip route help

Usage: ip route { list | flush } SELECTOR

       ip route save SELECTOR

       ip route restore

       ip route showdump

       ip route get ADDRESS [ from ADDRESS iif STRING ]

                            [ oif STRING ] [ tos TOS ]

                            [ mark NUMBER ]

       ip route { add | del | change | append | replace } ROUTE

SELECTOR := [ root PREFIX ] [ match PREFIX ] [ exact PREFIX ]

            [ table TABLE_ID ] [ proto RTPROTO ]

            [ type TYPE ] [ scope SCOPE ]

ROUTE := NODE_SPEC [ INFO_SPEC ]

NODE_SPEC := [ TYPE ] PREFIX [ tos TOS ]

             [ table TABLE_ID ] [ proto RTPROTO ]

             [ scope SCOPE ] [ metric METRIC ]

INFO_SPEC := NH OPTIONS FLAGS [ nexthop NH ]...

NH := [ encap ENCAPTYPE ENCAPHDR ] [ via [ FAMILY ] ADDRESS ]

       [ dev STRING ] [ weight NUMBER ] NHFLAGS

FAMILY := [ inet | inet6 | ipx | dnet | mpls | bridge | link ]

OPTIONS := FLAGS [ mtu NUMBER ] [ advmss NUMBER ] [ as [ to ] ADDRESS ]

           [ rtt TIME ] [ rttvar TIME ] [ reordering NUMBER ]

           [ window NUMBER] [ cwnd NUMBER ] [ initcwnd NUMBER ]

           [ ssthresh NUMBER ] [ realms REALM ] [ src ADDRESS ]

           [ rto_min TIME ] [ hoplimit NUMBER ] [ initrwnd NUMBER ]

           [ features FEATURES ] [ quickack BOOL ] [ congctl NAME ]

           [ pref PREF ]

TYPE := [ unicast | local | broadcast | multicast | throw |

          unreachable | prohibit | blackhole | nat ]

TABLE_ID := [ local | main | default | all | NUMBER ]

SCOPE := [ host | link | global | NUMBER ]

NHFLAGS := [ onlink | pervasive ]

RTPROTO := [ kernel | boot | static | NUMBER ]

PREF := [ low | medium | high ]

TIME := NUMBER[s|ms]

BOOL := [1|0]

FEATURES := ecn

ENCAPTYPE := [ mpls | ip | ip6 ]

ENCAPHDR := [ MPLSLABEL ]

```

думаю достаточно такой строчки:

ip route del default via 192.168.8.1 dev eth3 src 192.168.8.10

PS

```
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.118 metric 202 

 192.168.8.0/24 dev eth3 proto kernel scope link src 192.168.8.10 metric 204
```

Эти маршруты на сети которые работают напрямую(без шлюза), их удалять не стоит.  Ну а src значит то, с каким адресом будут уходить пакеты. Советую это всё проверять tcpdump и мониторить что происходит с пакетами когда они уходят с интерфейсов. Иначе в слепую как-то не так разбираться...

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

```

tcpdump -vvni eth0

tcpdump -vvni eth3
```

ну и поле src даст нам ясное понимание откуда уходит пакет и что и где нужно изменить чтобы всё работало как надо...

PS\2

Ещё вспомнил что NetworkManager скорее всего не знает о конфигурациях с двумя маршрутами default, рекомендую конфигурировать маршруты без него)

----------

## orion777

Итак, eth3 и eth4 получают IP посредством dhcpcd; NetworkManager удалён из rc (хотя с ним, вроде как, всё работало так же).

Cначала удаляем все дефалтные роуты:

```
ip route del default via 192.168.8.1 dev eth3 src 192.168.8.10

ip route del default via 192.168.9.2 dev eth4 src 192.168.9.20
```

затем вносим настойки, рекомендованные здесь https://multipath-tcp.org/pmwiki.php/Users/ConfigureRouting

```

# This creates two different routing tables, that we use based on the source-address.

ip rule add from 192.168.8.10 table 1

ip rule add from 192.168.9.20 table 2

# Configure the two different routing tables

ip route add 192.168.8.0/24 dev eth3 scope link table 1

ip route add default via 192.168.8.1 dev eth3 table 1

ip route add 192.168.9.0/24 dev eth4 scope link table 2

ip route add default via 192.168.9.2 dev eth4 table 2

# default route for the selection process of normal internet-traffic

ip route add default scope global nexthop via 192.168.8.1 dev eth3
```

Стоит отметить, что поскольку я баловался с http://lartc.org/howto/lartc.rpdb.multiple-links.html , то у меня уже созданы таблицы T1 и T2 с номерами 1 и 2 соответственно. Тоесть, все вышеперечисленные настройкисохранились в таблицы с названиями Т1 и Т2, а НЕ table 1, 2 как показано в примере настройки https://multipath-tcp.org/pmwiki.php/Users/ConfigureRouting

Далее запускаю пинг 8.8.8.8. Он идёт только через eth3. Вынимаем сим-карту чтобы упала связь на eth3 (сам линк с гентоо НЕ падает) и получаем просто Destination Network Unreachable. На работу с eth4 он переходит только если физически уронить eth3 (например командой ifconfig eth3 down или физически вынуть eth3).

Вот логи dcpdump:

eth3

https://paste.pound-python.org/show/UCvXDWhDtXiqhZT4wYuR/

eth4

https://paste.pound-python.org/show/QyfMCgkUos6l6jsNrhbt/

----------

## TigerJr

 *Quote:*   

> 07:32:50.643736 IP (tos 0x0, ttl 64, id 6852, offset 0, flags [DF], proto ICMP (1), length 84)
> 
> 192.168.8.10 > 8.8.8.8: ICMP echo request, id 2416, seq 2, length 64
> 
> 07:33:56.815455 IP (tos 0x0, ttl 64, id 47706, offset 0, flags [DF], proto ICMP (1), length 84)
> ...

 

Вроде настройка верна, переключение происходит при пропадании линка, что надо признать уже круто.

Тогда следуя документации тебе нужно писать скрипт для автоматического переключения дефолтного маршрута в случае если Host Unreachable.

https://multipath-tcp.org/pmwiki.php/Users/ConfigureRouting

Там в самом конце страницы перечисленны ссылки примеров (Automatic Configuration) реализаций скриптов для автоматического переключения дефолтного марашрута. Но если честно пример для gentoo https://gist.github.com/oskar456/7264828 мне не сильно понравился, я бы рекоммендовал писать свой скрипт.

----------

## orion777

Скажу сразу:скрипт для гентоо я уже пытался запустить, там, по моему, на 31 строчке стоит done, поэтому скрипт дальше не идёт: выдаёт сообщение об ошибке на эту строчку и всё. Поскольку в скриптах я не силен, то самостоятельно разрулить не удалось..

----------

## TigerJr

 *Quote:*   

> 31        done <<-EOF

 

Ну да, вроде минус лишний, должен быть: done <<EOF

Такие вот все криворукие)) Гитхаб даже подсветку синтаксиса остановил после этойстрочки,  а скрипт на гитхабе так и неисправлен

----------

## orion777

Итак: если удалить минус перед EOF на строке 31, то получим

```
pi64 ~ # ./prouting.sh

./prouting.sh: line 81: warning: here-document at line 31 delimited by end-of-file (wanted `EOF')

./prouting.sh: line 82: syntax error: unexpected end of file

```

При этом подстветки синтаксиса в том же Notepad++ после 31 строки всё равно нет.

Подсветка синтаксиса появляется если удалить вообще <<-EOF из строк 31 и 42. НО, при этом, если запустить скрипт, то он просто висит, ничего не выдаёт, не завершается и т.п.. если же, при запущенном скрипте, нажать любую клавишу (например g), то получишь 

```

pi64 ~ # ./prouting.sh

g

Error: inet prefix is expected rather than "g".

```

----------

## red_rabbit

Зачем такие сложности? очевидно что в вашей конфигурации multipath tcp не нужен. Вам нужен обычный lacp active backup. MPTCP один из вариантов когда у вас имеется L3 избыточность, у вас ее нет вот вы и занимаетесь костылестроением. Кроме увеличения нагрузки ничего не даст.

----------

## TigerJr

 *red_rabbit wrote:*   

> Зачем такие сложности? очевидно что в вашей конфигурации multipath tcp не нужен. Вам нужен обычный lacp active backup. MPTCP один из вариантов когда у вас имеется L3 избыточность, у вас ее нет вот вы и занимаетесь костылестроением. Кроме увеличения нагрузки ничего не даст.

 

я тоже думал предложить использовать драйвер bonding в режиме round-robin, но в треде конфигурация с двумя шлюзами, LACP и round-robin уже не подойдут, причем стоит незабывать что технология LACP должна поддерживаться со стороны коммутирующего оборудования.

Глупо заявлять про отсутствие L3 избыточности, когда топология сети неизвестна. К тому же не имея топологии сети глупо заявлять что нужно кому-то и как всё должно работать.

 *Quote:*   

> Кроме увеличения нагрузки ничего не даст.

 

Здесь я тоже несогласен, ни про увеличение нагрузки, не про то что MPTCP ни чего не даёт, абсолютно голословно и недальновидно.

----------

## red_rabbit

не всякий lacp должен поддерживаться со стороны свитча. 

С топологией, мне привиделось что адреса с одной подсети как бы  :Very Happy: 

вот распихали вы дефолты в разные таблицы, а как оно будет их использовать? нужно еще правило которое будет распихивать по таблицам и не просто распихивать а реализовывать свой load balance fault tolerance и.т.д если нет - все полетит в первый дефолт который найдет и чуда не случится.

Голословны ваши утверждения о том что это все голословно   :Very Happy:  В l3 происходит больше операций. Не ну если вы несогласны можете посчитать, выписать в столбик, собрать тестовый стенд.Last edited by red_rabbit on Wed Feb 28, 2018 1:14 pm; edited 1 time in total

----------

## TigerJr

 *red_rabbit wrote:*   

> не всякий lacp должен поддерживаться со стороны свитча. 
> 
> С топологией, мне привиделось что адреса с одной подсети как бы 
> 
> вот распихали вы дефолты в разные таблицы, а как оно будет их использовать? нужно еще правило которое будет распихивать по таблицам и не просто распихивать а реализовывать свой load balance fault tolerance и.т.д если нет - все полетит в первый дефолт который найдет и чуда не случится.

 

Всякий LACP должен иметь active инициатора PDU пакетов и passive ответчика на PDU, обычно Актив это коммутатор, а отвечает на PDU уже сервер, без актив-пассив LACP  уже не LACP) 

load balance и fault tolerance это не LACP

 *Quote:*   

> вот распихали вы дефолты в разные таблицы, а как оно будет их использовать?

 

А для чего патч MPTCP был написан?

PS. 

В бородатые времена ваш fault tolerance реализовывался очень просто на баше

```

#!/bin/bash

#

ping -c 1 8.8.8.8

if [[ $? == 0 ]]; then

    echo Ping ok

    else

    echo Ping Error

    /sbin/ip route change default via 192.168.0.1

fi

exit

```

----------

## red_rabbit

 *TigerJr wrote:*   

> А для чего патч MPTCP был написан?

 

Для того чтобы добавить поддержку MPTCP не?   :Laughing: 

из беглого осмотра rfc этот MPTCP вещь всебе. У него там внутри туннели и маршрутизация. А маршрутизацию ядра он не трогает. Поэтому и приходится рисовать эти таблицы с дефолтами. Кстати к ним еще прилагаются конмарки и роутмарки или хотябы роутлукапы.

----------

## TigerJr

 *Quote:*   

> Кстати к ним еще прилагаются конмарки и роутмарки или хотябы роутлукапы.

 

В текущей задаче это вообще зачем?

----------

## red_rabbit

Актив коммутатор - это не маршрутизатор ли часом?   :Very Happy:   :Very Happy: 

Все зависит от того где ты терминируешь свой lacp. Да и пассив lacp не такая уж и редкость для коммутатора. К тому же как я уже говорил есть и другие lacp которым вообще это все побоку. Не всегда это обзывают lacp. tlb slb alb rr ft итд все зависит от того что у тебя за железка и как это называет твой вендор   :Very Happy: Last edited by red_rabbit on Wed Feb 28, 2018 1:56 pm; edited 1 time in total

----------

## red_rabbit

 *TigerJr wrote:*   

>  *Quote:*   Кстати к ним еще прилагаются конмарки и роутмарки или хотябы роутлукапы. 
> 
> В текущей задаче это вообще зачем?

 

чтобы пакеты из одного соединения не бегали с разных интерфейсов

----------

## TigerJr

 *red_rabbit wrote:*   

>  *TigerJr wrote:*    *Quote:*   Кстати к ним еще прилагаются конмарки и роутмарки или хотябы роутлукапы. 
> 
> В текущей задаче это вообще зачем? 
> 
> чтобы пакеты из одного соединения не бегали с разных интерфейсов

 

Ну чтобы ты не нёс ахинею, прошу обратится к первому сообщению треда.

 *Quote:*   

> ЗАдача - сделать надёжное сетевое соединение путём резервирования

 

Также

 *Quote:*   

> Актив коммутатор - это не маршрутизатор ли часом

 

Часом нет. Коммутатор это коммутатор, маршрутизатор это маршрутизатор.

----------

## red_rabbit

 *TigerJr wrote:*   

> Ну чтобы ты не нёс ахинею,

 

 *TigerJr wrote:*   

>  Коммутатор это коммутатор, маршрутизатор это маршрутизатор.

 

а капитан очевидность это капитан очевидность   :Laughing: 

Ты можешь внятно объяснить зачем тебе актив lacp на коммутаторе? И как ты себе это представляешь? Твой "гиперактивный коммутатор" сообщения будет слать откуда? с какого интерфейса с каким адресом. Все так, но устройства такие называют маршрутизаторами. у них есть активные сетевые интерфейсы с которых они шлют свои сообщения окружающим. Для lacp невозможна конфигурация пасив-пасив, все остальное имеет место быть. 

 *Quote:*   

> к ним еще прилагаются конмарки и роутмарки или хотябы роутлукапы.

 

без этого работать не будет, хоть к кому обращайся.

----------

## orion777

К сожалению, внятного объяснения работы и настройки MPTCP, а так же его применений я не нашел (может плохо искал). Но, могу сказать что:

После применения патча ядра (в моём случае это 4.10 64 бит arm) в .config появляются новые подпункты.

В этих подпунктах, помимо включения поддержки самого MPTCP есть так-же и выбор метода, как он будет работать! Это и round-robin и прочее.. а у меня выбран redundancy.

Прошу обратить внимание на конфигурацию ядра, особенно ближе к концу, где

Default MPTCP Scheduler (Redundant)

Default TCP congestion control (Lia)

(хотя там есть и другие варианты)

Так же прошу обратить внимание на то, что обещанный MPTCP COUPLED CONGESTION CONTROL в конфиге так и не появился, соответственно ничего в нём я выбрать не могу.

Для удобства выкладываю весь конфиг здесь ( в самом начале нужно или в ядро ipv6 или вообще отключить его, как модуль не работает):

```
make menuconfig

¦     -> Networking support (NET [=y])                                    ¦

  ¦       -> Networking options                                             ¦

  ¦         -> TCP/IP networking (INET [=y])                                ¦

  ¦ (1)       -> The IPv6 protocol (IPV6 [=m]) to KERNEL (or DISABLE, but my is in kernel..)

then

Networking support (NET [=y])

  Networking options

    TCP/IP networking (INET [=y])

      [*]   IP: advanced router

        [*]     IP: policy routing

      [*]   MPTCP protocol

      [*]     MPTCP: advanced path-manager control  --->

        <*>   MPTCP Full-Mesh Path-Manager

        <*>   MPTCP Linked Increase

    Default MPTCP Path-Manager (Full mesh)  --->  Full mesh

   MPTCP: advanced scheduler control                            x x

         <*>   MPTCP Round-Robin                                          x x

  x x    <*>   MPTCP Redundant                                            x x

  x x          Default MPTCP Scheduler (Redundant)  --->   

and

Networking support (NET [=y])

  Networking options

    TCP/IP networking (INET [=y])

      [*]   TCP: advanced congestion control  --->

        <*>   MPTCP COUPLED CONGESTION CONTROL (!!Can't be found in my menuconfig!!)

        <*>   MPTCP Opportunistic Linked Increase

           Default TCP congestion control (Lia)  ---> Lia
```

И вот только после всей это котовассии уже создаются таблицы роутинга: https://multipath-tcp.org/pmwiki.php/Users/ConfigureRouting либо вручную (manual configuration) либо автоматически ,с помощью скрипта (я делал вручную, тк скрипт не запустился). 

И как бы усё, дальше howto умалчивает что делать.. Типо, всё должно работать? У меня никакой реданданси не наблюдается.Last edited by orion777 on Thu Mar 01, 2018 6:05 am; edited 2 times in total

----------

## orion777

По поводу топологии сети - всё просто: две локальные сетевые карточки, затем два NAT сервера; в общем случае NAT серверы друг друга не видят (хотя и можно сделать так, чтобы NAT сами по себе работали из одной подсети, т.е. если использовать одного провайдера). NAT серверы являются неотделимой частью сетевой карты, т.к. на самом деле это не сетевая карта, а 3G/4G модем, работающий в режиме hilink.

----------

## TigerJr

 *red_rabbit wrote:*   

>  *TigerJr wrote:*   Ну чтобы ты не нёс ахинею, 
> 
>  *TigerJr wrote:*    Коммутатор это коммутатор, маршрутизатор это маршрутизатор. 
> 
> а капитан очевидность это капитан очевидность  
> ...

 

Хочешь задать вопрос - задавай в отдельной теме. Здесь задача, очевидно, другая. LACP тролил ты - но к теме он имеет опосредованное отношение. К тому же прошу привеcти конкретною мою формулировку, ГДЕ Я ПИСАЛ о том что мне нужен LACP? Рекомендую не врать и не нести ахинею, если ты обратился к пользователям форума, то давай по-существу, а не задавай наводящие вопросы не по-теме. 

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

 *orion777 wrote:*   

> И как бы усё, дальше howto умалчивает что делать.. Типо, всё должно работать? У меня никакой реданданси не наблюдается.

 

Учитывая что скрипты на сайте multipath-tcp называют автоматической конфигурацией. А скрипт предоставленный на сайте не работает, нужно либо переписывать скрипт тот который на гитхабе, либо лучше писать свой скрипт переключения в случае если хост шлюза Unreachable.

PS

Если Sсheduler  относится к соединениям, а не к пакетам, то ещё можно попробовать переключить на:

MPTCP Round-Robin  - он должен сбалансировать нагрузку по интерфейсам и если один упадёт то в теории через него соединения не должны будут осздаваться но на правктике скорее всего нужно будет ложить интерфейс автоматическим скриптом

----------

## red_rabbit

 *Quote:*   

> И как бы усё, дальше howto умалчивает что делать.. Типо, всё должно работать? У меня никакой реданданси не наблюдается.

 

Все зависит от того как этот MPTCP взаимодействует системным движком маршрутизации. Вопрос с двумя дефолтами в таблице он не решает это очевидно, за него это нужно сделать другими средствами. Что еще он не может сделать вопрос открытый. TigerJr молчит предпочитает игнорировать. Если бы MPTCP не было, в такой конфигурации еще нужно сделать правило в прероутинге маркконект всего входящего на первый интерфейс, и другой маркконект всего входящего на второй интерфейс - 2 правила, и в output маркроут первого конмарка в таблицу где дефолт повешен на этот интерфейс и со вторым так же - еще 2 правила. И еще должно быть правило балансировщика - нужно раскидывать исходящие соединения\пакеты\байты по разным роут таблицам по какому то принципу, в обычном случае это делается исходя из задачи либо ECMP либо какие то хитрые правила в прероутинге, либо какие то правила в таблице маршрутов и никто не говорил что нельзя все это вместе. Что нужно MPTCP, а что он сделает сам TigerJr не говорит. Кроме всего этого тебе нужно 2 кастом таблицы роута и еще в главной таблице ОБА дефолта с разным приоритетом, либо один ecmp дефолт рекурсивный с nexthop. 

 *Quote:*   

> NAT серверы являются неотделимой частью сетевой карты, т.к. на самом деле это не сетевая карта, а 3G/4G модем, работающий в режиме hilink.

 

Когда NAT является частью сетевой карты это называется аппаратный nat. А у тебя на самом деле просто роутер который подключается по usb. LAN over USB. есть такой драйвер. 

 *Quote:*   

> ГДЕ Я ПИСАЛ о том что мне нужен LACP? Рекомендую не врать и не нести ахинею,

 

это уже истерика. зачем так нервничать?

 *Quote:*   

> Хочешь задать вопрос - задавай

 

зачем тебе актив lacp на коммутаторе? И как ты себе это представляешь? Твой "гиперактивный коммутатор" сообщения будет слать откуда? с какого интерфейса с каким адресом.

Как взаимодействует MPTCP с маршрутизацией ядра что умеет что не умеет что ему нужно?

И да MPTCP у топикстартера так и не заработал вообще то

----------

## TigerJr

 *red_rabbit wrote:*   

>  *Quote:*   ГДЕ Я ПИСАЛ о том что мне нужен LACP? Рекомендую не врать и не нести ахинею, 
> 
> это уже истерика. зачем так нервничать?
> 
>  *Quote:*   Хочешь задать вопрос - задавай 
> ...

 

Я не вижу эмоций в своём вопросе, если ты отвечать на вопросы не хочешь, то не вижу смысла продолжать диалог. 

зачем тебе актив lacp на коммутаторе? 

1. Я не писал про то что мне нужен LACP

как ты себе это представляешь?

2. Я себе это не представляю. 

Твой "гиперактивный коммутатор" сообщения будет слать откуда? 

3. У меня нет гиперактивного коммутатора

с какого интерфейса с каким адресом.

4. вопрос не ясен про какие интерфейсы ты спрашиваешь

Как взаимодействует MPTCP с маршрутизацией ядра что умеет что не умеет что ему нужно?

5. ответ на этот вопрос не поможет реализовать надёжное сетевое соединение путём резервирования через двух операторов связи

Давай разберёмся с соединением а потом займёмся твоими вопросами в других темах форума

 *Quote:*   

> Вопрос с двумя дефолтами в таблице он не решает это очевидно, за него это нужно сделать другими средствами

 

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

Твой бред  *Quote:*   

> Все зависит от того как этот MPTCP взаимодействует системным движком маршрутизации

 

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

Есть программное обеспечение, есть описалово как всё запустить, читаешь описалово - делаешь и всё работает. 

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

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

----------

## orion777

Чтож, стоит заметить что у MPTCP есть ещё какие то системные переменные https://multipath-tcp.org/pmwiki.php/Users/ConfigureMPTCP

По названиям они похожи на те, что я уже задал в ядре, хотя на 100% я за это утверждение не уверен. Попытка давать команды типо sysctl -w net.mptcp.mptcp_scheduler=redundant РАБОТАЮТ, хотя я этот параметр жестко вшил в ядро (в прошлый раз, видимо, толи руки были кривые толи монитор был пыльный, но тогда у меня выдало какой то феил)ю

И тут я заметил вот эту фразу, выше, в описании опции default: 

'default': This scheduler is the default one. It will first send data on subflows with the lowest RTT until their congestion-window is full. Then, it will start transmitting on the subflows with the next higher RTT.

Из моих скромных познаний в области нетворкинга я помню что такое окно есть у TCP соединения, тогда как, вроде, ICMP пакеты (которые шлёт ping) этим окном не пользуются и просто валятся с заданной скоростью и размером. А я же тестировал работоспособность с пингом! Решил попробовать скачать что нибудь через wget (так сказать, задействовать tcp соединение как оно должно быть) и вуаля: ОБЕ сетевые карты засветились активностью! При обрыве соединения (дальше сетевой карты, так чтобы линк на сетевую НЕ упал) скачка продолжается с уменьшенной скоростью - вторая сетевая всё ещё работает! 

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

----------

## TigerJr

Дак а что, значит что net.mptcp.mptcp_scheduler=redundant работают две сетевухи? Я думал что round-robin так должен работать...

И получается что без скриптов этот MPTCP нормально отрабатывает?

----------

## orion777

Из описания  следует, что настройки нужно вносить каждый раз вручную. Это неудобно! Поэтому настройки так же можно вносить автоматически, путём использования скрипта. Судя по всему, MPTCP работает по умолчанию, если внёс настройки сети вручную или скриптом (алгоритм работы по умолчанию задаётся настройками, которые внёс в ядро в момент компиляции, но даже их можно оперативно менять ).

Судя по описанию, redundant работает да, по одной карточке, но как только TCP окно заполняется - так переключается на 2ю карточку; затем, как переполнится TCP окно второй карточки - так он переходит на первую. Я так это понял..

А вот round-robin перекидывает пакеты, типо один туда - второй сюда; при этом, судя по всему, размер TCP окна НЕ смотрит, потому, наверное, и написано что функция только для учёных, а для реального применения работает плохо и НЕ рекомендуется к использованию Configure the scheduler:

----------

## TigerJr

Интересно, а что тогда происходит с TCP CONNECT кода переполнится окно?

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

Вот интересная схема установки соединений

September 1981

                                           Transmission Control Protocol

                                                Functional Specification

```

                              +---------+ ---------\      active OPEN

                              |  CLOSED |            \    -----------

                              +---------+<---------\   \   create TCB

                                |     ^              \   \  snd SYN

                   passive OPEN |     |   CLOSE        \   \

                   ------------ |     | ----------       \   \

                    create TCB  |     | delete TCB         \   \

                                V     |                      \   \

                              +---------+            CLOSE    |    \

                              |  LISTEN |          ---------- |     |

                              +---------+          delete TCB |     |

                   rcv SYN      |     |     SEND              |     |

                  -----------   |     |    -------            |     V

 +---------+      snd SYN,ACK  /       \   snd SYN          +---------+

 |         |<-----------------           ------------------>|         |

 |   SYN   |                    rcv SYN                     |   SYN   |

 |   RCVD  |<-----------------------------------------------|   SENT  |

 |         |                    snd ACK                     |         |

 |         |------------------           -------------------|         |

 +---------+   rcv ACK of SYN  \       /  rcv SYN,ACK       +---------+

   |           --------------   |     |   -----------

   |                  x         |     |     snd ACK

   |                            V     V

   |  CLOSE                   +---------+

   | -------                  |  ESTAB  |

   | snd FIN                  +---------+

   |                   CLOSE    |     |    rcv FIN

   V                  -------   |     |    -------

 +---------+          snd FIN  /       \   snd ACK          +---------+

 |  FIN    |<-----------------           ------------------>|  CLOSE  |

 | WAIT-1  |------------------                              |   WAIT  |

 +---------+          rcv FIN  \                            +---------+

   | rcv ACK of FIN   -------   |                            CLOSE  |

   | --------------   snd ACK   |                           ------- |

   V        x                   V                           snd FIN V

 +---------+                  +---------+                   +---------+

 |FINWAIT-2|                  | CLOSING |                   | LAST-ACK|

 +---------+                  +---------+                   +---------+

   |                rcv ACK of FIN |                 rcv ACK of FIN |

   |  rcv FIN       -------------- |    Timeout=2MSL -------------- |

   |  -------              x       V    ------------        x       V

    \ snd ACK                 +---------+delete TCB         +---------+

     ------------------------>|TIME WAIT|------------------>| CLOSED  |

                              +---------+                   +---------+

                      TCP Connection State Diagram

                               Figure 6.
```

----------

## orion777

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

----------

## TigerJr

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

Если всё устраивает с MPTCP, то тему можно закрыть.

----------

## orion777

Чтобы подытожить: вот результаты работы MPTCP, снятые при помощи netperf, а именно: работа отдельно eth1, затем отдельно eth2, затем с применением MPTCP с соответствующим scheduler:

https://ibb.co/gp3zy8

А здесь - реакция на пропадание связи по eth2 (при этом интерфейс eth2 НЕ падает, а связь нарушается выниманием кабеля уже после рутера, чтобы имитировать потерю пакетов)

https://ibb.co/m1Q7ko

Хочу так же отметить важное замечание: Multipath TCP функции доступны только если принимающая сторона тоже использует MPTCP!! Если же ответного флага mp_capable НЕ приходит, то ваша имплементация MPTCP будет работать как обычный TCP через одну (ту что указали дефаултной при конфигурации) сетевую карточку.

----------

## TigerJr

Мда не плохая конфигурация. При отвале сетевой карты каким-то образом соединения переходят без обрывов сессий....

----------

