Поведение SCTP Multihoming Heartbeat

У меня есть вопрос, касающийся поведения SCTP при множественной адресации. Рассмотрим пример ниже -

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

Будет ли связь между первичным и вторичным, т.е. a‹->d и c‹->b? Если нет, то можем ли мы сделать такие настройки?

В моем случае я вижу только сообщения HB SEND/ACK между 2 первичными и 2 вторичными, но не между первичным и вторичным.

Редактировать :-

Я провел небольшой тест. Я запускал sctp_darn на двух системах, связанных друг с другом.

Хост A: основной IP-адрес 172.29.11.43; Дополнительный IP-адрес 172.29.11.75 Хост B: основной IP-адрес 172.29.11.40; Дополнительный IP-адрес 172.29.11.72

На хосте A я запустил --> sctp_darn -s -p 4445 -h 172.29.11.40 -P 4444 -H 172.29.11.43 -B 172.29.11.75 На хосте B я запустил --> sctp_darn -l -P 4445 -H 172.29.11.40 -Б 172.29.11.72

Я не отправлял никаких данных из A-> B для мониторинга поведения HB. Это то, что я получил из вывода tcpdump.

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>

Как видите, HB переходят от первичного к первичному и вторичному к вторичному, но не от первичного к вторичному и наоборот.

Спасибо.


sctp
person tshah06    schedule 21.04.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Цитирование RFC 4960:

Транспортный адрес назначения считается «свободным», если в течение текущего такта на него не было отправлено ни одного нового фрагмента, который можно использовать для обновления RTT пути (обычно включая первую передачу DATA, INIT, COOKIE ECHO, HEARTBEAT и т. д.). период этого адреса.

Другими словами, тактовые импульсы не нужны, пока есть другие фрагменты, которые можно использовать для определения RTT.

Итак, в вашем случае могло ли быть так, что активными соединениями были a-> d и c-> b, которые имеют достаточно трафика, чтобы сделать пульсации на них избыточными?

Изменить в ответ на дополнительную информацию от автора

Согласно рисунку 1 в Экспериментальные исследования множественной адресации SCTP, с По 2 сетевых адаптера каждый вы получите 4 possibly independent paths для каждого направления if the routing is configured in such a way that these IP addresses are accessible through different paths. И я предполагаю, что они должны были бы биться сердцем, чтобы определить производительность каждого пути.

Глядя на сочетание ваших основных путей и биения сердца, которое всегда

172.29.11.x? <-> 172.29.11.x?

то есть .7? никогда не соединяется с .4? Возможно, это проблема с конфигурацией маршрута и/или подсетями (и реализация SCTP учитывает эту информацию при принятии решения о сопряжении?). Просто предположение.

person Evgeniy Berezovsky    schedule 22.04.2014
comment
Спасибо за ответ. не знал об этом. я проверю, работает ли какой-либо трафик на a‹-›d c‹-›b, что делает HB избыточным для них.. - person tshah06; 22.04.2014
comment
Я отредактировал свой вопрос, включив в него результаты небольшого теста, выполненного с помощью инструмента sctp_darn. Не могли бы вы проверить и дать мне свои данные? Спасибо. - person tshah06; 22.04.2014
comment
Ваш вывод tcpdump не дает полной картины. Он показывает отрывок только из HB REQs и HB ACKs. Поэтому мне трудно сказать, не отфильтровываете ли вы, например, DATA кусков. Полный дамп всего сеанса будет как минимум включать различные фрагменты INIT и COOKIE как часть начального рукопожатия. - person Evgeniy Berezovsky; 24.04.2014
comment
@ tshah06 (я не упомянул ваш псевдоним в последнем комментарии, поэтому stackoverflow не уведомил вас об этом) - person Evgeniy Berezovsky; 25.04.2014
comment
Я отредактировал свой вопрос, включив в него полный вывод tcpdump. Спасибо. - person tshah06; 25.04.2014
comment
@ tshah06 Расширил мой ответ. Но это все, что касается моих чисто теоретических знаний о SCTP... - person Evgeniy Berezovsky; 28.04.2014