0

I have a query regarding SCTP multihoming heartbeat behavior. Consider below example -

Host_A (IP a(Primary), IP b(secondary)) : Local MultiHomed endpoint
Host_B (IP c(Primary), IP d(secondary)) : Remote multiHomed endpoint

Will there be heartbeat communication between primary-secondary i.e a<->d & c<->b? If not then can we make such settings?

In my case, I'm only seeing HB SEND/ACK messages between the 2 primaries & 2 secondaries but not between primary & secondary.

Edit :-

I did a small test. I ran sctp_darn on two systems connected with each other.

Host A : Primary IP 172.29.11.43; Secondary IP 172.29.11.75 Host B : Primary IP 172.29.11.40; Secondary IP 172.29.11.72

On Host A, I ran --> sctp_darn -s -p 4445 -h 172.29.11.40 -P 4444 -H 172.29.11.43 -B 172.29.11.75 On Host B, I ran --> sctp_darn -l -P 4445 -H 172.29.11.40 -B 172.29.11.72

I didn't send any data from A->B to monitor HB behavior. This is what i got from tcpdump output.

root@base0-0-0-4-0-11-1:/root> tcpdump -ni bond1 sctp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond1, link-type EN10MB (Ethernet), capture size 65535 bytes


17:09:23.856688 IP 172.29.11.43.4444 > 172.29.11.40.4445: sctp (1) [INIT] [init tag:    368944998] [rwnd: 63488] [OS: 10] [MIS: 65535] [init TSN: 2410047720]
17:09:23.856893 IP 172.29.11.40.4445 > 172.29.11.43.4444: sctp (1) [INIT ACK] [init tag: 797255774] [rwnd: 63488] [OS: 10] [MIS: 10] [init TSN: 659191795]
17:09:23.856988 IP 172.29.11.43.4444 > 172.29.11.40.4445: sctp (1) [COOKIE ECHO] , (2) [DATA] (B)(E) [TSN: 2410047720] [SID: 0] [SSEQ 0] [PPID 0x0]
17:09:23.857410 IP 172.29.11.40.4445 > 172.29.11.43.4444: sctp (1) [COOKIE ACK] , (2) [SACK] [cum ack 2410047720] [a_rwnd 63486] [#gap acks 0] [#dup tsns 0]
17:09:25.880280 IP 172.29.11.75.4444 > 172.29.11.72.4445: sctp (1) [HB REQ]
17:09:25.880519 IP 172.29.11.72.4445 > 172.29.11.75.4444: sctp (1) [HB ACK]
17:09:27.951827 IP 172.29.11.72.4445 > 172.29.11.75.4444: sctp (1) [HB REQ]
17:09:27.951868 IP 172.29.11.75.4444 > 172.29.11.72.4445: sctp (1) [HB ACK]
17:09:56.520282 IP 172.29.11.75.4444 > 172.29.11.72.4445: sctp (1) [HB REQ]
17:09:56.520526 IP 172.29.11.72.4445 > 172.29.11.75.4444: sctp (1) [HB ACK]
17:09:56.534773 IP 172.29.11.40.4445 > 172.29.11.43.4444: sctp (1) [HB REQ]
17:09:56.534797 IP 172.29.11.43.4444 > 172.29.11.40.4445: sctp (1) [HB ACK]
17:09:57.748715 IP 172.29.11.43.4444 > 172.29.11.40.4445: sctp (1) [HB REQ]
17:09:57.749006 IP 172.29.11.40.4445 > 172.29.11.43.4444: sctp (1) [HB ACK]
17:09:59.026986 IP 172.29.11.72.4445 > 172.29.11.75.4444: sctp (1) [HB REQ]
17:09:59.027013 IP 172.29.11.75.4444 > 172.29.11.72.4445: sctp (1) [HB ACK]
17:10:27.129950 IP 172.29.11.40.4445 > 172.29.11.43.4444: sctp (1) [HB REQ]
17:10:27.129982 IP 172.29.11.43.4444 > 172.29.11.40.4445: sctp (1) [HB ACK]
17:10:27.220294 IP 172.29.11.75.4444 > 172.29.11.72.4445: sctp (1) [HB REQ]
17:10:27.220576 IP 172.29.11.72.4445 > 172.29.11.75.4444: sctp (1) [HB ACK]
17:10:29.076286 IP 172.29.11.43.4444 > 172.29.11.40.4445: sctp (1) [HB REQ]
17:10:29.076582 IP 172.29.11.40.4445 > 172.29.11.43.4444: sctp (1) [HB ACK]
17:10:30.402389 IP 172.29.11.72.4445 > 172.29.11.75.4444: sctp (1) [HB REQ]
17:10:30.402430 IP 172.29.11.75.4444 > 172.29.11.72.4445: sctp (1) [HB ACK]
^C
24 packets captured
24 packets received by filter
0 packets dropped by kernel
root@base0-0-0-4-0-11-1:/root>

As you can see, HBs are going from primary-primary & secondary-secondary but not from primary to secondary and vice-versa.

Thanks.

tshah06
  • 2,625
  • 3
  • 19
  • 23

1 Answers1

1

Quoting RFC 4960:

A destination transport address is considered "idle" if no new chunk that can be used for updating path RTT (usually including first transmission DATA, INIT, COOKIE ECHO, HEARTBEAT, etc.) and no HEARTBEAT has been sent to it within the current heartbeat period of that address.

In other words, heartbeats are not necessary, as long as there are other chunks that can be used to determine the RTT.

So in your case, could it be that the active connections were a->d and c->b, which have enough traffic to make heartbeats on them redundant?

Edit in response to more details from author

According to the figure 1 in Experimental studies of SCTP multi-homing, with 2 NICs each you'd get 4 possibly independent paths for each direction if the routing is configured in such a way that these IP addresses are accessible through different paths. And I assume they'd have to be heart beating in order to determine the performance of each path.

Looking at the pairing of your primary paths and the heart beats, which is always

172.29.11.x? <-> 172.29.11.x?

i.e. a .7? never pairs with a .4?, is this perhaps an issue with the route configuration and/or subnets (and the SCTP implementation is considering that information in its pairing decision?). Just a guess.

Community
  • 1
  • 1
Evgeniy Berezovsky
  • 18,571
  • 13
  • 82
  • 156
  • Thanks for your reply. wasn't aware of this. i'll verify if any traffic is running on a<->d c<->b which is making HB redundant for them.. – tshah06 Apr 22 '14 at 09:15
  • I have edited my question to include output of a small test done with help of sctp_darn tool. Can you please check & give me your inputs? Thanks. – tshah06 Apr 22 '14 at 14:59
  • Your tcpdump output doesn't give the full picture. It shows an excerpt of only `HB REQ`s and `HB ACK`s. So it's hard for me to tell if you aren't filtering out `DATA` chunks, for example. A full dump of a complete session would at a minimum include various `INIT` and `COOKIE` chunks, as part of the initial handshake. – Evgeniy Berezovsky Apr 24 '14 at 01:02
  • @tshah06 (I didn't mention your alias in the last comment, so you weren't notified by stackoverflow about it) – Evgeniy Berezovsky Apr 25 '14 at 02:29
  • I have edited my question to include complete output of tcpdump. Thanks. – tshah06 Apr 25 '14 at 10:03
  • @tshah06 Extended my answer. But this is as far as my purely theoretical SCTP knowledge goes... – Evgeniy Berezovsky Apr 28 '14 at 00:34