Re: [Lksctp-developers] Fw: SCTP Multihoming: Association Bouncing

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi Wei,
            Thanks for your reply. Please find the tcp dump attached with
this mail.

(See attached file: TCPDUMP.txt)

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