Subject: [tsvwg] Multihoming and source address selection

From: "Kiss, Zoltan (NSN - HU/Budapest)" <[email-masked]>
Date: Mon, 31 Aug 2009 17:17:18 +0200

Hi folks,

I have some questions about SCTP multihoming. I'm testing SCTP MH
between 2 Linux-based machine, both are connected with 2 NIC to the
network, owning 2 separate IP on them, all from different subnets. When
I set up multihomed associations between them, they agreed about IP
addresses correctly during INIT, and start to use one pair of them as
"primary path". Actually this pair was used on both machines as
interfaces to default gateway. I will call them A and A', and the
secondary addresses as B and B', and I also have to notify, that each
NIC can access both addresses of the other side. It works properly, but
when one side sent a HEARTBEAT to the peer's secondary address, it
received the HB ACK from the primary address, and the HEARTBEATs were
always sent from the primary address. I quickly realized that this is a
problem of IP routing, so I configured it, so now packets to peer's
primary address are always sent from our primary address, and secondary
on secondary, respectively. But in this way I lost some redundancy,
because now primary addresses won't access secondaries and vice versa,
and I have to do additional configuring for static routing.
As I see, the root cause of all of these that SCTP layer doesn't specify
the source IP address when it passes packet to IP, which raised me the
question: is this good or not? I read through the RFC but it doesn't
specify this exactly, and I also couldn't decide it unambiguously. Using
only IP static routing has a disadvantage that we can use only disjunct
pairs of source and destination addresses, a reduced set of possible
paths, and we have to do extra configs, which is an another point of
failure. I think involve SCTP as well by means of specifying source IP
address for packets is better, therefore it could try and find every
possible pairs with HEARTBEAT, and we also don't need static routing.
But as I saw during my research, the opposite way is the trend. Is there
any point of the RFC where is this succeed from? Or is this just common
practice in SCTP implementations, based on real world experiences which
I don't know? Are my assumptions correct?

Regards,

Zoltan Kiss

---

From: Randy Stewart <[email-masked]>
Date: Mon, 31 Aug 2009 16:37:28 -0400

Zoltan:

Actually I would bet that Linux IS specifying the src address.
I know that FreeBSD does.

Just because SCTP places B' in the source address DOES NOT mean
that the packet will go out the B' interface. This goes back to
routing.. as you correctly identify. Routing in host's generally
do not look at src address. Instead only the destination address
is looked at. In fact this is pretty much true in most of the internet
as well ;-)

I actually had in FreeBSD at one time a set of patches that would allow
SCTP to do "alternate routing". Which might be what you want...

This would allow you to enter two default addresses for example and
then when you hit a retransmission you could ask for a new route (or
N retransmissions) so that you could steer the packet out the other
interface (even with the original src address)....

What generally happened with this code (using your descriptions) is:

  Host
      A  --- IP1 Router ------ A'
      B  --- IP2 Router -------B'

You would set in two default routes i.e.

route add default ip1
route add default ip2

And then when SCTP gathered its routes into the routing table
it would get the first route for A' and IP1 would be the gateway.
It would next ask for a route for B' but would indicated it did not
want (if possible) the route via IP1. It would then get back the
route via IP2.

If one started having issues with retransmission, it would ask for
an alternate route and get the opposite...

But of course this code is long dead... I have been meaning to
circle back and resurrect it but alas a shortage or cycles ;-)
Maybe someday... ;-)

R

> I don't know? Are my assumptions correct?

-----
Randall Stewart
[email-masked]