mirror of
https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git
synced 2025-12-20 05:50:06 +01:00
12a4696229
By default, the MPTCP limits have 'add_addr_accepted' set to 0. It means
that when the other peer announces an additional address it can be
reached from, the receiver will not try to establish any new subflows to
this address. If this limit is increased, and without the new 'laminar'
flag, the MPTCP in-kernel path-manager will select the source address by
looking at the routing tables to establish this new subflow.
This is not ideal: very likely, the source address will be the one
linked to the default route and a new subflow from the same interface as
the initial one will be created instead of using another path.
This is especially problematic when the other peer has set the 'C-flag'
in the MPTCP connection request (MP_CAPABLE). This flag can be set to
tell the other side that the peer will not accept extra subflows
requests sent to its initial IP address and port: typically set by a
server using an anycast address, behind a legacy Layer 4 load balancer.
It sounds better to add the 'laminar' flag by default to pick the source
address from well-defined MPTCP endpoints, rather than relying on
routing rules which will likely not pick the most interesting solution.
Note that older kernels will accept unsupported flags, and ignore them.
So it is fine to have the new flag added by default even if it is not
supported.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
(cherry picked from commit
|
||
|---|---|---|
| .. | ||
| common.ent.in | ||
| meson.build | ||
| NetworkManager-dispatcher.xml | ||
| NetworkManager-wait-online.service.xml | ||
| NetworkManager.conf.xml | ||
| NetworkManager.xml | ||
| nm-cloud-setup.xml | ||
| nm-initrd-generator.xml | ||
| nm-online.xml | ||
| nm-openvswitch.xml | ||
| nm-settings-dbus.xsl | ||
| nm-settings-ifcfg-rh.xsl | ||
| nm-settings-keyfile.xsl | ||
| nm-settings-nmcli.xsl | ||
| nmcli-examples.xml | ||
| nmcli.xml | ||
| nmtui.xml | ||