Re: Linux SCTP multihoming question

[Philipp Stanner <stanner@posteo.de>]

Am Samstag, dem 10.02.2024 um 17:34 +0000 schrieb David Laight:
> From: Philipp Stanner
> > Sent: 10 February 2024 17:09
> > 
> > Am Samstag, dem 10.02.2024 um 17:03 +0000 schrieb David Laight:
> > > From: o.evistel@free.fr
> > > > Sent: 09 February 2024 10:06
> > > > 
> > > > I am using linux-sctp as transport for SIGTRAN M3UA on RHEL 8.4
> > > > with
> > > > multihoming (sctp_bindx(), sctp_connectx() API functions).
> > > > I would like to know, after association setup, if it is
> > > > possible to
> > > > instruct SCTP to use a specific local address from the list of
> > > > bound
> > > > addresses to reach the peer.
> > > 
> > > Unlikely in the extreme.
> > > 
> > > If there are 'n' bound local addresses and 'm' remote addresses
> > > (IIRC from the INIT_ACK - but they come from the far end) then
> > > Linux only verifies a route to each local address and picks an
> > > appropriate local address for each one.
> > > So it only sends heartbeats to 'm' addresses, not on 'n * m'
> > > address pairs.
> > > 
> > > So if anything of this nature did exist it would limit the
> > > remote addresses used, not the local ones.
> > 
> > I've been told once that using the socket option SO_BINDTODEVICE
> > should
> > serve the trick, i.e., it should provoke Linux into choosing the
> > picked
> > device's IP addr as the source IP addr.
> > 
> > I've never tested / verified that, though.
> > I'm also not sure if it would have other negative consequences,
> > such as
> > limiting the reachability through non-bound devices.
> 
> But won't that defeat the entire point of SCTP multihoming?

I guess it defeats the philosophy of the OS with its routing table
being solely responsible for choosing a source address.
I don't see how SCTP would be affected by that, though. SCTP doesn't
demand a certain number of interfaces being available, nor does it make
statements about how the networks behind the interfaces might or might
not be interconnected.

> You need two interfaces in different subnets that use entirely
> separate IP networks to connect to the two addresses the remote
> system gives you.
> (There are really only ever two addresses for each system.)

I assume you're coming from the perspective of a user where SCTP is
utilized with completely redundant and separated networks for
redundancy.
I, however, have only used the protocol in the normal boring Internet –
and there it's definitely possible to reach N endpoints from just 1
outgoing interface. All the endpoints are connected to the Internet,
after all, so the routers will ultimately direct your packages to the
target addr.

> 
> I don't know what the standards people were smoking, but the
> default 'send all my IP addresses to the far end' is so broken.

How else could you implement it?
Only alternative I can think of would be to have some sort of multi-
homing DNS that provides you with several addresses.

P.

> Requiring the application to know which addresses are 'local'
> (typically 192.178.x.x and 10.x.x.x) and pretty much must never
> be sent to a remote system (where they can easily mean something
> else) is just wrong, it ought to be a property of the protocol stack.
> 
> Never mind that the fact that API calls like bindx() were originally
> implemented using socket options being embedded in the standard.
> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes,
> MK1 1PT, UK
> Registration No: 1397386 (Wales)