Subject: Re: [tsvwg] sctp multihoming query

From: Lars Eggert <[email-masked]>
Date: Fri, 4 Dec 2009 08:29:41 -1000

Hi,

you really want to be asking this on the TSVWG list. CC and Reply-To set accordingly.

Lars

On 2009-12-4, at 1:57, Sudhanva Mudigere Narayana Gowda wrote:

> Hi,
> I have a query regarding sctp multihoming behavior.
> 
> I have setup a multihomed association and this is my observation
> 
> Host_A (IP a): Local single Homed endpoint
> 
> Host_B (IP b(Primary), IP c(secondary)): Remote multiHomed endpoint
> 
> During Heartbeat I see that even though the Heart beat req is to the secondary ip of Host_B, the Host_B uses its primary ip as source when sending back the Heartbeat Ack.
> Ie  Host_A (IP a) --------HEART_BEAT_REQ-----------> Host_B(IP c)
>     Host_A (IP a)<--------- HEART_BEAT_ACK---------- Host_B(IP b)
> 
> also during data exchange I observed that even when the data is sent to the secondary ip of Host_B, the SACK is being sent back from the primary ip of Host_B.
>  Host_A (IP a) --------DATA_MSG-----------> Host_B(IP c)
>  Host_A (IP a)<--------- SACK------------------- Host_B(IP b)
> 
> Is this the expected behavior, shouldn’t the node use the same ip on which it received the data or Heart_beat_req on while sending back the responses(Heart_beat_ack or SACK).
> Due to this behavior if the primary ip of an endpoint fails the association goes down as the node will not be able to transmit any Heartbeat_Req or Heartbeat_Ack.
> 
> On Host_A I blocked the incoming packets which has Host_B(IP b) as source and I expected Host_B to retry using its secondary ip addr, but I observed that even the retries from Host_B uses its primary ip .
> 
> Does this mean that an endpoint always uses its primary-ip while sending packets, but might receive packets on primary or secondary-ip?
> 
> Thanks
> Sudhanva
> <ATT00001..txt>

---

From: "Kiss, Zoltan (NSN - HU/Budapest)" <[email-masked]>
Date: Fri, 4 Dec 2009 20:06:51 +0100

Hi,

This behaviour is probably because of IP layer routing config. If Host B's routing table says (IP a) is reachable over (IP c) (and over its corresponding interface), then it will send out there, and probably it also overwrites the source IP provided by SCTP layer. Source-based routing can avoid this problem, or if both side is multihomed, simple static routing can also do the job.

Regards,

Zoltán

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Lars Eggert
Sent: Friday, December 04, 2009 7:30 PM
To: Sudhanva Mudigere Narayana Gowda
Cc: [email-masked] Discussion; tsvwg
Subject: Re: [tsvwg] sctp multihoming query

Hi,

Lars

On 2009-12-4, at 1:57, Sudhanva Mudigere Narayana Gowda wrote:

> Is this the expected behavior, shouldn't the node use the same ip on which it received the data or Heart_beat_req on while sending back the responses(Heart_beat_ack or SACK).

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sat, 05 Dec 2009 04:11:45 +0900 (JST)

Hello Shdhanva,

I guess you might be interested in this..
http://tools.ietf.org/html/draft-coene-sctp-multihome-04

Thanks,
--
Yoshifumi Nishida
[email-masked]

From: Lars Eggert <[email-masked]>
Subject: Re: sctp multihoming query
Date: Fri, 4 Dec 2009 08:29:41 -1000
Message-ID: <[email-masked]>

---

From: Randy Stewart <[email-masked]>
Date: Tue, 8 Dec 2009 06:13:45 -0800

Zoltan:

I agree with your assessment but I don't think the IP layer would be  
overwriting the
IP address... At least I know in the FreeBSD stack it would not.. But  
you WOULD see
that behavior. Basically the stack knows which is going to be the  
egress interface
and will always try to set the IP address (if possible) to that  
address. This
is needed to get around ingress filtering.

R

On Dec 4, 2009, at 11:06 AM, Kiss, Zoltan (NSN - HU/Budapest) wrote:

> Hi,
>
> This behaviour is probably because of IP layer routing config. If  
> Host B's routing table says (IP a) is reachable over (IP c) (and  
> over its corresponding interface), then it will send out there, and  
> probably it also overwrites the source IP provided by SCTP layer.  
> Source-based routing can avoid this problem, or if both side is  
> multihomed, simple static routing can also do the job.
>
> Regards,
>
> Zoltán
>
>> During Heartbeat I see that even though the Heart beat req is to  
>> the secondary ip of Host_B, the Host_B uses its primary ip as  
>> source when sending back the Heartbeat Ack.
>> also during data exchange I observed that even when the data is  
>> sent to the secondary ip of Host_B, the SACK is being sent back  
>> from the primary ip of Host_B.
>> Is this the expected behavior, shouldn't the node use the same ip  
>> on which it received the data or Heart_beat_req on while sending  
>> back the responses(Heart_beat_ack or SACK).
>> Due to this behavior if the primary ip of an endpoint fails the  
>> association goes down as the node will not be able to transmit any  
>> Heartbeat_Req or Heartbeat_Ack.
>>
>> On Host_A I blocked the incoming packets which has Host_B(IP b) as  
>> source and I expected Host_B to retry using its secondary ip addr,  
>> but I observed that even the retries from Host_B uses its primary  
>> ip .
>>
>> Does this mean that an endpoint always uses its primary-ip while  
>> sending packets, but might receive packets on primary or secondary- 
>> ip?
>>
>> Thanks
>> Sudhanva
>> <ATT00001..txt>
>

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

---

From: Padmalochan Moharana <[email-masked]>
Date: Thu, 10 Dec 2009 14:58:30 +0530

Hi ,

After testing I found that Kernel does not respond HB_ACK properly even if
after setting rule for source based routing.

Bellow is the kernel and lksctp version.

OS : 2.6.9-55.EL

Lksctp : lksctp-1.0.8

Br,

Padmalochan

On Tue, Dec 8, 2009 at 7:43 PM, Randy Stewart <[email-masked]> wrote:

> IP address... At least I know in the FreeBSD stack it would not.. But you
> WOULD see
> that behavior. Basically the stack knows which is going to be the egress
> interface
> and will always try to set the IP address (if possible) to that address.
> This
>> This behaviour is probably because of IP layer routing config. If Host B's
>> routing table says (IP a) is reachable over (IP c) (and over its
>> corresponding interface), then it will send out there, and probably it also
>> overwrites the source IP provided by SCTP layer. Source-based routing can
>> avoid this problem, or if both side is multihomed, simple static routing can
>> also do the job.
>>
>> Regards,
>>
>> Zoltán
>>
>>> During Heartbeat I see that even though the Heart beat req is to the
>>> secondary ip of Host_B, the Host_B uses its primary ip as source when
>>> sending back the Heartbeat Ack.
>>> also during data exchange I observed that even when the data is sent to
>>> the secondary ip of Host_B, the SACK is being sent back from the primary ip
>>> of Host_B.
>>> Is this the expected behavior, shouldn't the node use the same ip on
>>> which it received the data or Heart_beat_req on while sending back the
>>> responses(Heart_beat_ack or SACK).
>>> On Host_A I blocked the incoming packets which has Host_B(IP b) as source
>>> and I expected Host_B to retry using its secondary ip addr, but I observed
>>> that even the retries from Host_B uses its primary ip .
>>>
>>> Does this mean that an endpoint always uses its primary-ip while sending
>>> packets, but might receive packets on primary or secondary-ip?
>>>
>>> Thanks
>>> Sudhanva
>>> <ATT00001..txt>
>>>
>>
>>
> -----
> Randall Stewart
> [email-masked]
>
>
>
>
>

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 10 Dec 2009 10:27:39 -0500

Padmalochan Moharana wrote:
> Hi ,
> 
> After testing I found that Kernel does not respond HB_ACK properly even
> if after setting rule for source based routing.
> 

For questions regarding linux implementation, please send your queries
to [email-masked].

The problem you are seeing has been fixed, just not in the old version
you are using.

-vlad

> 
> 
> On Tue, Dec 8, 2009 at 7:43 PM, Randy Stewart <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Zoltan:
> 
>     IP address... At least I know in the FreeBSD stack it would not..
>     But you WOULD see
>         This behaviour is probably because of IP layer routing config.
>         If Host B's routing table says (IP a) is reachable over (IP c)
>         (and over its corresponding interface), then it will send out
>         there, and probably it also overwrites the source IP provided by
>         SCTP layer. Source-based routing can avoid this problem, or if
>         both side is multihomed, simple static routing can also do the job.
> 
>         Regards,
> 
>         Zoltán
> 
>         From: [email-masked] <mailto:[email-masked]>
>         [mailto:[email-masked] <mailto:[email-masked]>]
>         On Behalf Of ext Lars Eggert
>         Cc: [email-masked] <mailto:[email-masked]> Discussion; tsvwg
>             During Heartbeat I see that even though the Heart beat req
>             is to the secondary ip of Host_B, the Host_B uses its
>             primary ip as source when sending back the Heartbeat Ack.
>             also during data exchange I observed that even when the data
>             is sent to the secondary ip of Host_B, the SACK is being
>             sent back from the primary ip of Host_B.
>             Is this the expected behavior, shouldn't the node use the
>             same ip on which it received the data or Heart_beat_req on
>             while sending back the responses(Heart_beat_ack or SACK).
>             Due to this behavior if the primary ip of an endpoint fails
>             the association goes down as the node will not be able to
>             transmit any Heartbeat_Req or Heartbeat_Ack.
> 
>             On Host_A I blocked the incoming packets which has Host_B(IP
>             b) as source and I expected Host_B to retry using its
>             secondary ip addr, but I observed that even the retries from
>             Host_B uses its primary ip .
> 
>             Does this mean that an endpoint always uses its primary-ip
>             while sending packets, but might receive packets on primary
>             or secondary-ip?
> 
>             Thanks
>             Sudhanva
>             <ATT00001..txt>
> 
> 
> 
>     -----
>     Randall Stewart
>     [email-masked] <mailto:[email-masked]>
> 
> 
> 
> 
>