Subject: Re: [tsvwg] Multihoming and source address selection

From: "Kiss, Zoltan (NSN - HU/Budapest)" <[email-masked]>
Date: Fri, 4 Sep 2009 16:44:36 +0200

Hi,

I understand that routing decides based on destination addres, and
basicly doesn't take care of source address, but if the SCTP layer
specifies the src, how could it happened that IP rewrites it? E.g. when
I send ICMP echoes with ping and force the source IP, it doesn't rewrite
it. Is this a feature or a bug? :)
And another question about source address specification in SCTP layer:
can we say that it's an implementation decision?

Regards:

Zoltan

------------------------------------------------------------------------
-----------------------------------

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

On Aug 31, 2009, at 11:17 AM, Kiss, Zoltan (NSN - HU/Budapest) wrote:

    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

-----
Randall Stewart
randall at lakerest.net

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 4 Sep 2009 17:23:58 +0200

> it. Is this a feature or a bug? :)
It could happen that the IP layer handles a given src address as
a hint and might think that it knows better... But I'm not an
expert on the Linux IP layer, so I do not know. I also do not know
how raw sockets are handled. When you send an ICMP echo request,
no ICMP layer in the host might be involved. The application may
provide the ICMP packet. Only the reception of the ICMP echo request
and sending of the corresponding ICMP echo reply is handled by
the ICMP layer.
> can we say that it's an implementation decision?
Yes.

---

From: Randy Stewart <[email-masked]>
Date: Fri, 4 Sep 2009 11:32:53 -0400

> it. Is this a feature or a bug? :)

I doubt that linux would re-write the source address. If the src
address was provided then it should remain (minus nat's etc).. but
you can have a packet with a different src address go out an interface
not assigned with that IP address on a host. This is all I was saying.

And yes, it truly is an implementation decision as to if they
wish to fill in the src address. I know way back in 4.x FreeBSD
we could put a 0 in the src address and let IP pick the src address
for us. After a bit of playing we quickly realized that that would not
work for our implementation and instead started setting the src address.

I am completely unfamiliar with the internal workings of Linux's IP
stack and its SCTP stack. what Vlad and company decided to do is
not something I know (in this decision).. and for that matter the
IP stack itself COULD be doing this, I rather doubt it, but it
could... I have no knowledge of what linux does... some of the linux
mailing lists could answer that question I am sure ;-)

R

> can we say that it's an implementation decision?

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

---

From: Vlad Yasevich <[email-masked]>
Date: Fri, 04 Sep 2009 12:40:03 -0400

> not assigned with that IP address on a host. This is all I was saying.

Exactly.  Linux uses a weak host model and will easily route packet
with src A out of interface B if told to do so.  Some people consider
this a bug and some consider it a feature and thus there is no end to
the confusion.

> mailing lists could answer that question I am sure ;-)

What linux does is let the routing table decide on the best way to
get a packet to the destination.  If the route we get back has a source
that matches something that belongs to the association, all is well and
we use it. If it source doesn't belong, the we look-up again and again
specifying the source address that belongs to the association.

Since linux's routing logic is really loose, we typically succeed with the
very first address we try.  That's legal as far as linux is concerned, but
may not necessarily be what the user wants.

Now, there was work that tried match the interface to the source, but some
people didn't want that.

Back to the question that sparked the thread.  SCTP in linux does, in fact,
pass the source address to the IP layer.  It, however, may not be the source
you may have expected.

-vlad

-vlad