Padmalochan Moharana wrote: > Hi Vlad, > > Thanks for this information .Can you please the kernel version in which this > issue has been fixed. I think 2.6.30 had the HB stuff fixed up better. -vlad > > Br, > Padmalochan > > > On Thu, Dec 10, 2009 at 8:57 PM, Vlad Yasevich <vladislav.yasevich@xxxxxx>wrote: > >> >> 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. >>> >>> Bellow is the kernel and lksctp version. >>> >>> OS : 2.6.9-55.EL >>> >>> Lksctp : lksctp-1.0.8 >>> >>> Br, >>> >>> Padmalochan >> For questions regarding linux implementation, please send your queries >> to linux-sctp@xxxxxxxxxxxxxxxx >> >> 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 <randall@xxxxxxxxxxxx >>> <mailto:randall@xxxxxxxxxxxx>> wrote: >>> >>> 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 >>> >>> -----Original Message----- >>> From: tsvwg-bounces@xxxxxxxx <mailto:tsvwg-bounces@xxxxxxxx> >>> [mailto:tsvwg-bounces@xxxxxxxx <mailto:tsvwg-bounces@xxxxxxxx>] >>> On Behalf Of ext Lars Eggert >>> Sent: Friday, December 04, 2009 7:30 PM >>> To: Sudhanva Mudigere Narayana Gowda >>> Cc: ietf@xxxxxxxx <mailto:ietf@xxxxxxxx> Discussion; tsvwg >>> Subject: Re: [tsvwg] sctp multihoming query >>> >>> 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> >>> >>> >>> >>> ----- >>> Randall Stewart >>> randall@xxxxxxxxxxxx <mailto:randall@xxxxxxxxxxxx> >>> >>> >>> >>> >>> > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Lksctp-developers mailing list > Lksctp-developers@xxxxxxxxxxxxxxxxxxxxx > https://lists.sourceforge.net/lists/listinfo/lksctp-developers > -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
