Configure MPTCP Endpoints and Limits with ip mptcp

Adding an MPTCP endpoint with ip mptcp does not make a connection use multiple paths on its own. This guide configures the in-kernel Multipath TCP path manager with an explicitly chosen local address, checks its limits, and removes the endpoint again once the test is done.

The examples match iproute2 6.1.0-1ubuntu6.4. Allow about fifteen minutes, plus time to confirm which interfaces and addresses your host should actually use. You need an MPTCP-capable kernel, the iproute2 package, and an address already assigned to the host. Keep the first change in a maintenance window if it affects a production service.

1. Check the installed command and current limits

Start read-only. Package version and command help matter 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 calls it subflows; the local manual page calls the same value SUBFLOW_NR, same thing, different label. This host currently allows a maximum of 2 additional subflows and 0 accepted remote address announcements.

2. Confirm the address and device

An endpoint address must be a real local IPv4 or IPv6 address. Find candidates with an ordinary, unprivileged read:

$ 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

Those documentation-only addresses are placeholders, swap in an address that really belongs to your host and note the interface name too. Never pick a peer address, a stale one from a config file, or one routing cannot reach.

• signal announces the endpoint to the peer.
• subflow lets the local path manager actively create a subflow from it. Combine both when you need to.
• backup marks a subflow endpoint as lower priority for traffic the peer sends, it does not touch your own outgoing priority.
• 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 double-check the address and device first. This example announces the address and lets the path manager use it for an extra subflow:

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

Choosing the endpoint ID yourself, rather than letting it be assigned, keeps later inspection and deletion unambiguous. Success is normally silent, check it directly:

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

Formatting varies, but the address, device, ID and flags should all be recognisable. On this machine, an unprivileged ip mptcp endpoint show returned RTNETLINK answers: Operation not permitted, use sudo when the kernel rejects a read like that.

4. Set limits deliberately

Limits apply per MPTCP connection. subflows controls additional subflows, including ones from a remote address announcement or started by the peer. add_addr_accepted controls how many incoming ADD_ADDR announcements a connection accepts, zero means further remote announcements get 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 the installed command actually shows, subflows, in scripts. If a command rejects an option, check ip mptcp help on that host rather than silently guessing a spelling.

Undo by restoring what you captured in step 1, on this machine that is:

$ 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

Flags can change without replacing the address. This marks endpoint 10 as a backup path and clears any full-mesh setting:

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

The manual lists backup, nobackup, fullmesh and nofullmesh as the changeable flags, nothing here adds a new address. Verify after changing, then use the inverse option if the result is not what you wanted.

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

Error wording for a missing ID varies by kernel and build, what matters is ID 10 no longer being listed. Avoid ip mptcp endpoint flush on a shared or production host, it removes every configured MPTCP endpoint at once and is far harder to walk back than deleting one known ID.

6. Observe path-manager activity

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

$ sudo ip mptcp monitor
^C

Leave it running in one terminal while an authorised test client opens an MPTCP connection in another, this is a live event stream, not a config dump. Ctrl-C stops it. Quiet output means checking whether the application is actually using MPTCP, whether the peer supports it, and whether the endpoint flags and limits allow the expected path.

Three separate questions get confused constantly: is the address configured locally, is the path manager allowed to use or announce it, and did an actual connection create a subflow? ip -br address, ip mptcp endpoint show, and ip mptcp monitor each answer a different one.