CODEWITHSUNDEEP
sctp
tshah06
tshah06

Reputation: 2755

SCTP Multihoming Heartbeat Behavior

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.

Upvotes: 0

Views: 5228

Answers (1)

Evgeniy Berezovsky
Evgeniy Berezovsky

Reputation: 19248

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.

Upvotes: 1

Related Questions