From: Rahul32 G <rah...@tc...> - 2011-01-19 13:11:55
|
Hi all, I have a multihoming scenario, where Client and server both have two ip's. Association is UP and ACTIVE. Now following path are being BLOCKED P---------------P P---------------S S---------------P It means only S-S path is unblocked. Now, association is going down. Is this expected behaviour? or should the traffic should flow through S-S path? Thanks, Rahul Goyal From: Rahul32 G/MUM/TCS To: Wei Yongjun <yj...@cn...> Cc: Michael Tuxen <Mic...@lu...>, lks...@li... Date: 01/10/2011 03:58 PM Subject: Re: Fw: [Lksctp-developers] SCTP Multihoming: Association Bouncing Hi Wei, Thanks for your reply. Please find the tcp dump attached with this mail. [attachment "TCPDUMP.txt" deleted by Rahul32 G/MUM/TCS] Regards, Rahul Goyal From: Chandan12 K/MUM/TCS To: Rahul32 G/MUM/TCS@TCS Date: 01/10/2011 12:18 PM Subject: Fw: [Lksctp-developers] SCTP Multihoming: Association Bouncing Thanks, Chandan Kumar ----- Forwarded by Chandan12 K/MUM/TCS on 01/10/2011 12:14 PM ----- From: Wei Yongjun <yj...@cn...> To: Rahul32 G <rah...@tc...> Cc: Michael Tü, xen <Mic...@lu...>, lks...@li... Date: 01/10/2011 08:36 AM Subject: Re: [Lksctp-developers] SCTP Multihoming: Association Bouncing > Hi all, > I am having a multihoming scenario. Client has two IP's as well as > server has two IP's(primary and secondary). Following actions are now > happening: > > 1) After Association is established, we block the Secondary to Secondary > path > 2) Now, we block the Server's Secondary to Client's primary path. > > Only REMAINING connections are > Server Client > Prim ----------------------Prim > Prim-----------------------Sec > > It means Server's secondary is isolated, Now, if I deactivate and then > activate the association again, the association is bouncing. Server is > sending ABORT even after association is established. It is very strange. can you offer the tcpdump's output of both Prim and Sec path? > Kindly help us in understanding why this is happening? > > Regards, > Rahul Goyal > > > > > From: Rahul32 G <rah...@tc...> > > To: Wei Yongjun <yj...@cn...> > > Cc: Michael Tüxen <Mic...@lu...>, lks...@li... > > Date: 01/05/2011 04:33 PM > > Subject: Re: [Lksctp-developers] SCTP Multihoming: HeartBeat Query > > > > > > > Hi, > Thanks a lot for your help. I am facing one more problem. I > have a multihoming scenario where client and server both have two ip's > (primary and secondary). and all the paths are blocked by network policy. > Now, when we activate only the secondary(server) to primary(client) path, > it shows the association as active and then association is bouncing. I am > wondering why is it happening? > > Thanks, > Rahul Goyal > > > > > From: Wei Yongjun <yj...@cn...> > > > To: Michael Tüxen <Mic...@lu...> > > > Cc: lks...@li... > > > Date: 01/04/2011 06:50 AM > > > Subject: Re: [Lksctp-developers] SCTP Multihoming: HeartBeat Query > > > > > > > > >> On Dec 31, 2010, at 3:11 PM, Chandan12 K wrote: >> >>> Thanks Christian. I checked the code and found out that the RTO init >>> variable is 3 second by default. >>> >>> It seems that the first heart beat on primary path is set to = default >>> hb_interval (default 30 sec)+ RTO (default 3 sec) and on the secondary >>> path it sends the heart beat immediately. And the funny part is that I > am >>> yet to find it in the code/RFCb :-) >> Maybe it is sent immediately because it is a HB for path verification. >> Not sure about Linux, but FreeBSD sends these path verification HB >> immediately. > Linux also sent immediately because it is a HB for path verification. > In each RTO, a probe HB may be sent on an active UNCONFIRMED > path in an attempt to move it to the CONFIRMED state. > > > >> Best regards >> Michael >>> Thanks, >>> Chandan Kumar >>> >>> >>> >>> From: >>> Christian Schoch <e03...@st...> >>> To: >>> lks...@li... >>> Cc: >>> Chandan12 K <cha...@tc...> >>> Date: >>> 12/31/2010 07:03 PM >>> Subject: >>> Re: [Lksctp-developers] SCTP Multihoming: HeartBeat Query >>> >>> >>> >>> Hi Chandan, >>> >>>> Thanks Bhaskar for the Info. However, we are not able to understand why >>>> the first heart beat on primary path is going after 33 second whereas > in >>>> case of secondary it's going after 2 second (the updated time interval >>>> value). >>>> >>>> Is it an expected behavior that if the default time interval set to 30 >>> (as >>>> per RFC) the very first heart beat will take the default values rather >>>> than the value set by the application. And in case of secondary path it >>>> takes updated time interval ? >>>> >>> Under normal situations, the heartbeat interval for each transport >>> should be calculated as noted and is based on the RTO of the transport >>> (if no DATA is sent). >>> >>> interval = RTO + (+- 50% RTO) + hb_interval; >>> [interval] = [0,5*RTO+hb_interval , 1,5*RTO+hb_interval] >>> >>> BUT, the first interval is depending on the RTO only (see transport.c >>> ~line 600 at 2.6.36). so it calculates (with RTO_initial as RTO): >>> >>> interval = RTO_init +-50% RTO_init >>> >>> >>> So for lowering the first Heartbeat, you should decrease RTO_initial >>> value which can also be adjusted by setsockoption. >>> >>> As an alternative try to the set the SPP_HB_DEMAND flag of spp_flags, >>> which should send you the heartbeat. >>> >>> Regards, >>> Christian >>> >>> >>> >>> >>>> PS: In our case after the association is established the application >>> does >>>> not transmit any data chunks from either side. And we are wondering the >>>> why heart beats are sent differently for primary and secondary paths. >>>> >>>> Thanks, >>>> Chandan Kumar >>>> >>>> >>>> >>>> >>>> Hello, >>>> >>>> We have a sctp multihoming setup where no data is being transferred. > The >>>> set up consists of primary ip at server (PS_ip) and on client side >>>> primary(PC_ip),secondary(SC_ip). >>>> >>>> Once the association establishes the application sets hb_interval > value >>>> to 2000msecs using setsockopt function. >>>> >>>> >>>> After deactivating and activating associations from the server > following >>>> is observed. >>>> >>>> The first heartbeat(HB) is sent from PS_ip to PC_ip around 33secs after >>>> 4-way handshake. However, the first HB is sent from PS_ip to SC_ip >>> almost >>>> immediately after 4-way handshake. >>>> Subsequently the HBs are sent from PS_ip to both PC_ip and SC_ip at >>>> intervals of 2secs. >>>> >>>> Questions:- >>>> >>>> 1. Why would there be such a difference for the 2 paths ("Path1: PS_ip >>> to >>>> PC_ip" and "Path2: PS_ip to SC_ip") for the first HB being sent? >>>> 2. Is this an expected behaviour? >>>> 3. On what parameter does sending of first HB depend? Does it depend on >>>> hb_interval variable? In our case we found that the hb_interval of >>>> sctp_transport structure for both the paths has same value of > 2000msecs. >>>> >>>> Currently we are using Linux kernel 2.6.10 and patched back the >>>> Multi-homing from upstream kernel. >>>> >>>> >>>> Your /proc/sys/net/sctp/hb_interval is still at the default 30 seconds. >>>> Changing it (via sysctl) should decrease the hb interval on the primary >>>> path. >>>> >>>> >>>> >>>> =====-----=====-----===== >>>> Notice: The information contained in this e-mail >>>> message and/or attachments to it may contain >>>> confidential or privileged information. If you are >>>> not the intended recipient, any dissemination, use, >>>> review, distribution, printing or copying of the >>>> information contained in this e-mail message >>>> and/or attachments to it are strictly prohibited. If >>>> you have received this communication in error, >>>> please notify us by reply e-mail or telephone and >>>> immediately and permanently delete the message >>>> and any attachments. Thank you >>>> >>>> >>>> > ------------------------------------------------------------------------------ > > >>>> Learn how Oracle Real Application Clusters (RAC) One Node allows >>> customers >>>> to consolidate database storage, standardize their database > environment, >>> and, >>>> should the need arise, upgrade to a full multi-node Oracle RAC database >>>> without downtime or disruption >>>> http://p.sf.net/sfu/oracle-sfdevnl >>>> _______________________________________________ >>>> Lksctp-developers mailing list >>>> Lks...@li... >>>> https://lists.sourceforge.net/lists/listinfo/lksctp-developers >>>> >>> >>> >>> >>> =====-----=====-----===== >>> Notice: The information contained in this e-mail >>> message and/or attachments to it may contain >>> confidential or privileged information. If you are >>> not the intended recipient, any dissemination, use, >>> review, distribution, printing or copying of the >>> information contained in this e-mail message >>> and/or attachments to it are strictly prohibited. If >>> you have received this communication in error, >>> please notify us by reply e-mail or telephone and >>> immediately and permanently delete the message >>> and any attachments. Thank you >>> >>> >>> > ------------------------------------------------------------------------------ > > >>> Learn how Oracle Real Application Clusters (RAC) One Node allows > customers >>> to consolidate database storage, standardize their database environment, > and, >>> should the need arise, upgrade to a full multi-node Oracle RAC database >>> without downtime or disruption >>> http://p.sf.net/sfu/oracle-sfdevnl >>> _______________________________________________ >>> Lksctp-developers mailing list >>> Lks...@li... >>> https://lists.sourceforge.net/lists/listinfo/lksctp-developers >>> >> > ------------------------------------------------------------------------------ > > >> Learn how Oracle Real Application Clusters (RAC) One Node allows > customers >> to consolidate database storage, standardize their database environment, > and, >> should the need arise, upgrade to a full multi-node Oracle RAC database >> without downtime or disruption >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Lksctp-developers mailing list >> Lks...@li... >> https://lists.sourceforge.net/lists/listinfo/lksctp-developers >> > ------------------------------------------------------------------------------ > > > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, > and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Lksctp-developers mailing list > Lks...@li... > https://lists.sourceforge.net/lists/listinfo/lksctp-developers > > > > =====-----=====-----===== > Notice: The information contained in this e-mail > message and/or attachments to it may contain > confidential or privileged information. If you are > not the intended recipient, any dissemination, use, > review, distribution, printing or copying of the > information contained in this e-mail message > and/or attachments to it are strictly prohibited. If > you have received this communication in error, > please notify us by reply e-mail or telephone and > immediately and permanently delete the message > and any attachments. Thank you > > > > > ------------------------------------------------------------------------------ > > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, > and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Lksctp-developers mailing list > Lks...@li... > https://lists.sourceforge.net/lists/listinfo/lksctp-developers > > > > =====-----=====-----===== > Notice: The information contained in this e-mail > message and/or attachments to it may contain > confidential or privileged information. If you are > not the intended recipient, any dissemination, use, > review, distribution, printing or copying of the > information contained in this e-mail message > and/or attachments to it are strictly prohibited. If > you have received this communication in error, > please notify us by reply e-mail or telephone and > immediately and permanently delete the message > and any attachments. Thank you > > > > ------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Lksctp-developers mailing list Lks...@li... https://lists.sourceforge.net/lists/listinfo/lksctp-developers =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you |