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@xxxxxxx > > > > 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)
