Configure MPTCP Endpoints and Limits with ip mptcp

You will configure the in-kernel Multipath TCP path manager with an explicitly chosen local address, check its limits, and remove the endpoint again when the test is over. The examples match iproute2 6.1.0-1ubuntu6.4 installed on this machine. Allow about fifteen minutes, plus time to confirm which interfaces and addresses your host should use.

You need an MPTCP-capable kernel, the iproute2 package, and an IP address already assigned to the host. MPTCP still depends on the peer and the network path: an endpoint entry alone does not create a working multi-path connection. Keep the first change in a maintenance window if it affects a production service.

1. Check the installed command and current limits

Start with read-only commands. The package version and command help are useful because iproute2 releases can differ in small syntax details:

$ ip -Version
ip utility, iproute2-6.1.0, libbpf 1.3.0
$ ip mptcp help
Usage:  ip mptcp endpoint add ADDRESS [ dev NAME ] [ id ID ]
                      [ port NR ] [ FLAG-LIST ]
...
$ ip mptcp limits show
add_addr_accepted 0 subflows 2

The installed command's help uses subflows in the limits syntax. The local manual page describes the same value as SUBFLOW_NR. The output above reports the maximum number of additional subflows as 2, and the maximum number of accepted remote address announcements as 0 on this host.

Checkpoint: save the output of ip mptcp limits show before changing anything. That gives you the values needed for an exact rollback.

2. Confirm the address and device

An endpoint address must be a local IPv4 or IPv6 address. Use ordinary, unprivileged inspection to find candidates:

$ ip -br address
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.0.2.10/24
eth1             UP             198.51.100.20/24

Replace the documentation-only addresses above with an address that really belongs to your host. Record the interface name as well. Do not choose a peer address, a stale address from a configuration file, or an address that routing cannot use.

When the endpoint is intended to be announced to a peer, use the signal flag. When the local path manager should actively create an additional subflow from it, use subflow. These flags have different jobs and can be combined. backup marks a subflow endpoint as lower priority for traffic sent by the peer; it does not change the priority of your outgoing data. fullmesh asks for a subflow to each known peer address, subject to the limit.

3. Add one endpoint

Adding an endpoint changes live kernel state, so this step requires elevated privilege. First make sure the address and device values are correct. The following example announces the address and permits the path manager to use it for an additional subflow:

$ sudo ip mptcp endpoint add 198.51.100.20 dev eth1 id 10 signal subflow

An endpoint ID is a unique numeric identifier for the entry. Choosing an ID yourself makes later inspection and deletion unambiguous. The command normally prints no success message. Check the result with:

$ sudo ip mptcp endpoint show id 10
198.51.100.20 dev eth1 id 10 signal subflow

The exact formatting can vary, but the address, device, ID and flags should be recognisable. On this machine, an unprivileged ip mptcp endpoint show returned RTNETLINK answers: Operation not permitted, so use sudo when the kernel rejects the read.

Do not use an endpoint entry as proof that traffic is using MPTCP. A peer must support MPTCP, and the application must create an MPTCP socket or otherwise be configured to use it. If negotiation falls back to ordinary TCP, the endpoint remains configured but no extra MPTCP subflow will appear.

4. Set limits deliberately

The limits apply per MPTCP connection. subflows controls additional subflows, including ones created after a remote address announcement or initiated by the peer. add_addr_accepted controls how many incoming ADD_ADDR announcements are accepted for a connection. A zero value means further remote address announcements are ignored, not that every local endpoint is disabled.

$ sudo ip mptcp limits set subflows 4 add_addr_accepted 2
$ ip mptcp limits show
add_addr_accepted 2 subflows 4

Use the word shown by the installed command, subflows, in scripts. If the command rejects an option, read ip mptcp help on that host rather than silently substituting a guessed spelling.

To undo this example, restore the values captured in step 1. On this machine that would be:

$ sudo ip mptcp limits set subflows 2 add_addr_accepted 0
$ ip mptcp limits show
add_addr_accepted 0 subflows 2

5. Change or remove the endpoint

Endpoint flags can be changed without replacing the address. For example, this marks endpoint 10 as a backup path and removes its full-mesh setting if it had one:

$ sudo ip mptcp endpoint change id 10 backup nofullmesh
$ sudo ip mptcp endpoint show id 10

The change operation accepts the flag changes listed by the manual: backup, nobackup, fullmesh and nofullmesh. The example does not add a new address. Verify the flags after changing them, then use the inverse option if the result is not what you intended.

$ sudo ip mptcp endpoint delete id 10
$ sudo ip mptcp endpoint show id 10
RTNETLINK answers: No such file or directory

Error text for a missing ID can differ by kernel and iproute2 build. The useful check is that ID 10 is no longer listed. Avoid ip mptcp endpoint flush on a shared or production host: it removes all configured MPTCP endpoints and is much harder to recover from than deleting one known ID.

6. Observe path-manager activity

Use the monitor when you need to see connections, remote address announcements or subflow additions and removals as they happen:

$ sudo ip mptcp monitor
^C

Leave the monitor running in one terminal while an authorised test client creates an MPTCP connection in another. It is a live event stream, not a configuration dump. Press Ctrl-C to stop it. If it stays quiet, check that the application is actually using MPTCP, that the peer supports it, and that the endpoint flags and limits allow the expected path.

Keep separate the three questions that are often confused: is the address configured locally, is the path manager allowed to use or announce it, and did an MPTCP connection create a subflow? ip -br address, ip mptcp endpoint show, and ip mptcp monitor answer different parts of that investigation.