Не удается подключиться к демону Docker по адресу unix:// /var/run/docker.sock

Я только что протестировал smcrouteс двумя сетевыми пространствами имен и двумя парами veth. Настройка:

ns1         <-- main namespace -->    ns2
10.0.0.1 -- 10.0.0.254  10.0.1.254 -- 10.0.1.1
veth0b      veth0a          veth1a    veth1b

Пакет Debian smcrouteимеет версию 2.0.0 и, похоже, не поддерживает виртуальный eth, поэтому я установил версию 2.3.1 с домашней страницы smcroute .руководство по многоадресному маршруту из smcrouteтакже очень полезно.

Я использовал пакет ssmpingдля тестирования многоадресной рассылки. Я запускал ssmpingdв ns2, пингуя с помощью ssmping -4 -I veth0b 10.0.1.1из ns1. Это исходные -многоадресные рассылки (SSM )с использованием группы 232.43.211.234. ​​Вы также можете протестировать любые -исходные многоадресные рассылки (ASM )с помощью asmping. Я не знаю, что использует LAN messenger.

Я включил переадресацию в основном пространстве имен, чтобы обеспечить прохождение одноадресных ping-запросов, а затем

smcroutectl add veth1a 10.0.1.1 232.43.211.234 veth0a

и все работало нормально. Я ожидаю, что он также будет работать с учетом ваших настроек, хотя вам также может потребоваться smcroutectl join, чтобы сообщить своим коммутаторам, что они должны правильно пересылать многоадресные рассылки. Несколько окон терминала tcpdumpна всех соответствующих интерфейсах очень помогают при отладке.

Следующая информация показалась мне интересной:

To be able to setup multicast routes a program must connect to the multicast routing socket in the kernel, when that socket is closed, which is done automatically when a UNIX program ends, the kernel cleans up all routes.

Это означает, что если вы намерены использовать функцию многоадресной маршрутизации ядра, вы должны использовать демон, а не инструмент командной строки.

Для статической и динамической маршрутизации говорится:

The intended purpose of smcroute is to aid in situations where dynamic multicast routing does not work properly. However, a dynamic multicast routing protocol is in nearly all cases the preferred solution. The reason for this is their ability to translate Layer-3 signalling to Layer-2 and vice versa (IGMP or MLD).

Наконец, обратите особое внимание на значение TTL, выдаваемое вашим мессенджером в локальной сети, см. часто задаваемые вопросы по многоадресной рассылке в конце.