Subject: Re: sctp multihoming heartbeat behavior

From: Randall Stewart <[email-masked]>
Date: Thu, 17 Jun 2010 09:27:21 -0400

In-line

On Jun 17, 2010, at 8:54 AM, Harendra Pratap Singh wrote:

> Hi All,
>
> I have a query regarding sctp multihoming behavior.
>
> I have setup a multi-homed association and this is my observation
>
> Host_A (IP a(Primary), IP b(secondary)):): Local MultiHomed endpoint
>
> Host_B (IP c(Primary), IP d(secondary)): Remote multiHomed endpoint
>
> During Heartbeat I see that even though the Heart beat request is  
> sent to the secondary
> ip of Host_B from primary ip of host_A, the Host_B uses its primary  
> ip as source when sending back the
> Heartbeat Ack.
> I.e. Host_A (IP a) --------HEART_BEAT_REQ-----------> Host_B(IP d)
>      Host_A (IP a)<--------- HEART_BEAT_ACK---------- Host_B(IP c)
>
> 1. Is this the expected behavior, shouldn't the node use the same ip  
> on which it
> received the Heart_beat_req on while sending back the  
> response(Heart_beat_ack)?

The recommended behavior is you SHOULD send back to the destination that
sent you the HB.. i.e. send back to IP a. This does NOT speak to what
the source address is.

Now the source address is recommended as being varied as needed (can't  
remember
the wording) in particular this comes in to play when a host starts  
seeing
duplicate data transmissions, but I doubt there is wording that talks  
about
the HB's.

I would suspect that what is happening here is that Host_B has a  
default route
that points out the interface of IP c. In such a case all packets  
would get
sourced with IP c since it is the surest way to NOT get ingress- 
filtering to
drop your packet.

If this is a private network I would suggest having network level routes
pointing between IPa <-> IPd and IPb <-> IPc (if thats the pairing you  
want).

At all of the past 9 interops this is what we did. We also made it so  
that a
packet could NOT flow between cross networks ...i.e. there would be no  
path
between C and A... But that is a bit drastic and we did that only to  
make
sure endpoints did what we expected ;-)

>
> 2. Can primary ip of host_A send heartbeat to secondary ip of host_B?
>

This is legal.
> 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.
Not if they follow the RFC and vary the destination and/or source in
cases of retransmissions. Of course how the routing is setup will
also come in to play here. Ingress filtering by an ISP can quickly  
chop out
valid path combinations...
>
> 3. Does this mean that an endpoint always uses its primary-ip while  
> sending
> packets, but might receive packets on primary or secondary-ip?

Well ANY packet can come from any of the peer's sources and be addressed
to ANY of the local hosts IP addresses that were listed.  So basically
any combination is legal. That being said one must work at getting
the routing and network layout correct in order to have the most
divergent and fault tolerant network configuration (if thats what
one wants ;-D)...

R

> Thanks,
> Harendra

------------------------------
Randall Stewart
803-317-4952 (cell)

---

From: "Kiss, Zoltan (NSN - HU/Budapest)" <[email-masked]>
Date: Thu, 17 Jun 2010 18:07:34 +0200

Sorry, I didn't noticed, that Harendra sent the message to a wrong email address :)

__________________________________

Hi,

1. This is not the expected behaviour, but happens frequently. The reason for this that Host_B's IP routing table says IP_a is accesible through IP_c, so it overwrites the the SCTP layer's wish about source IP (if any). A solution for this could be policy based routing, under Linux, you can specify source based routing rules there.
2. Yes, it can. But as I see it's a regular practice in the real networks that both endpoint has two IP (a primary and a secondary), and primary IP's and secondary IP's can reach only each other, and a primary-secondary connection is not possible. In your case a failure of IP_a doesn't mean necessarily an association break. If IP_b and IP_d can reach each other, the association will work. But you have to configure on both side the routing properly, so IP_d should be accesible through IP_b in the primary, and vice versa.
3. No, the endpoint could receive packets in every configured IP.

Regards,

Kiss Zoltán 

______________________________

From: ext Harendra Pratap Singh [mailto:[email-masked]] 
Sent: Thursday, June 17, 2010 2:54 PM
To: [email-masked]; Randy Stewart; Kiss, Zoltan (NSN - HU/Budapest)
Subject: sctp multihoming heartbeat behavior

Hi All,

 

During Heartbeat I see that even though the Heart beat request is sent to the secondary 
ip of Host_B from primary ip of host_A, the Host_B uses its primary ip as source when sending back the 
Heartbeat Ack.
I.e. Host_A (IP a) --------HEART_BEAT_REQ-----------> Host_B(IP d)
     Host_A (IP a)<--------- HEART_BEAT_ACK---------- Host_B(IP c)
 
1. Is this the expected behavior, shouldn't the node use the same ip on which it 
received the Heart_beat_req on while sending back the response(Heart_beat_ack)?

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.
 
3. Does this mean that an endpoint always uses its primary-ip while sending 
packets, but might receive packets on primary or secondary-ip?
 
Thanks,
Harendra