mirror of
https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git
synced 2025-12-25 04:50:07 +01:00
8caa781270
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> |
||
|---|---|---|
| .. | ||
| 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 | ||