Есть замороченная, специфичная и нетривиальная проблема, об которую я (и не только я) сломал свой мосх. Надежды на решение почти нет... точнее, последняя надежда - это светлый коллективный разум...
На VMware vSphere живёт виртуалка:
Код: Выделить всё
FreeBSD test.example.com 10.3-RELEASE-p2 FreeBSD 10.3-RELEASE-p2 #0: Wed May 4 06:03:51 UTC 2016 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64Код: Выделить всё
ifconfig_vmx3f0="inet 172.16.220.27/24 descr vlan7"
ifconfig_vmx3f1="inet 192.168.100.100/24 descr vlan6"
ifconfig_vmx3f2="inet 192.168.200.200/24 descr vlan11"
defaultrouter="172.16.220.1"
static_routes="multicast1 multicast2 multicast3"
route_multicast1="234.5.2.0/24 -interface vmx3f2"
route_multicast2="235.5.2.0/24 -interface vmx3f1"
route_multicast3="239.13.2.0/24 -interface vmx3f2"
Код: Выделить всё
$ ifconfig
vmx3f0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: vlan7
options=403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO>
ether 00:50:56:ab:e1:98
inet 172.16.220.27 netmask 0xffffff00 broadcast 172.16.220.255
nd6 options=9<PERFORMNUD,IFDISABLED>
media: Ethernet 10Gbase-T
status: active
vmx3f1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: vlan6
options=403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO>
ether 00:50:56:ab:10:08
inet 192.168.100.100 netmask 0xffffff00 broadcast 192.168.100.255
nd6 options=9<PERFORMNUD,IFDISABLED>
media: Ethernet 10Gbase-T
status: active
vmx3f2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: vlan11
options=403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO>
ether 00:50:56:ab:1c:a4
inet 192.168.200.200 netmask 0xffffff00 broadcast 192.168.200.255
nd6 options=9<PERFORMNUD,IFDISABLED>
media: Ethernet 10Gbase-T
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>Маршрутизация:
Код: Выделить всё
$ netstat -rn
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 172.16.220.1 UGS vmx3f0
127.0.0.1 link#4 UH lo0
172.16.220.0/24 link#1 U vmx3f0
172.16.220.27 link#1 UHS lo0
192.168.100.0/24 link#2 U vmx3f1
192.168.100.100 link#2 UHS lo0
192.168.200.0/24 link#3 U vmx3f2
192.168.200.200 link#3 UHS lo0
234.5.2.0/24 00:50:56:ab:1c:a4 US vmx3f2
235.5.2.0/24 00:50:56:ab:10:08 US vmx3f1Некоторое время тому назад я заметил следующую проблему. При попытке получить какой-либо мультикаст происходит неприемлемая задержка. Для мультикастов из vlan11, например, она составляет 10-20 минут. То есть, программа, которая работает с мультикастом, висит это время и лишь после этого начинает работать. Я пробовал обе упомянутые программы.
Заметив проблему, я попеременно продёргал несколько адресов из vlan6 и vlan11. Команды и выдача представлены ниже. (Для большей наглядности выдачу самого ffprobe убрал, оставил лишь временные метки.)
Код: Выделить всё
$ date; ffprobe udp://235.5.2.89:1234; date
четверг, 12 мая 2016 г. 14:54:46 (MSK)
четверг, 12 мая 2016 г. 14:55:12 (MSK)
$ date; ffprobe udp://234.5.2.89:1234; date
четверг, 12 мая 2016 г. 14:56:17 (MSK)
четверг, 12 мая 2016 г. 15:09:12 (MSK)
$ date; ffprobe udp://235.5.2.16:1234; date
четверг, 12 мая 2016 г. 15:10:50 (MSK)
четверг, 12 мая 2016 г. 15:11:22 (MSK)
$ date; ffprobe udp://234.5.2.16:1234; date
четверг, 12 мая 2016 г. 15:11:58 (MSK)
четверг, 12 мая 2016 г. 15:24:12 (MSK)
$ date; ffprobe udp://235.5.2.125:1234; date
четверг, 12 мая 2016 г. 15:27:41 (MSK)
четверг, 12 мая 2016 г. 15:28:21 (MSK)
$ date; ffprobe udp://234.5.2.125:1234; date
четверг, 12 мая 2016 г. 15:32:51 (MSK)
четверг, 12 мая 2016 г. 15:44:12 (MSK)Сперва я подумал было, что заметил разницу в поведении сетей. Но мои ожидания не оправдались. Потом и во vlan6 я стал ловить адовы задержки.
Пытался снять сетевой дамп:
Код: Выделить всё
sudo tcpdump -n -i vmxN multicastПо нему было видно, что прога долго-долго ждёт, ждёт, ждёт... никаких запросов по сети не отправляет... а спустя 10-20 минут вдруг:
Код: Выделить всё
...
15:09:07.249432 IP 192.168.200.200 > 234.5.2.89: igmp v2 report 234.5.2.89
15:09:07.284278 IP 77.94.170.2.37266 > 234.5.2.89.1234: UDP, length 1316
15:09:07.288049 IP 77.94.170.2.37266 > 234.5.2.89.1234: UDP, length 1316
...
15:24:06.797326 IP 192.168.200.200 > 234.5.2.16: igmp v2 report 234.5.2.16
15:24:06.835062 IP 77.94.170.2.37266 > 234.5.2.16.1234: UDP, length 1316
15:24:06.838520 IP 77.94.170.2.37266 > 234.5.2.16.1234: UDP, length 1316
15:24:06.841954 IP 77.94.170.2.37266 > 234.5.2.16.1234: UDP, length 1316
...
14:55:07.425228 IP 192.168.100.100 > 235.5.2.89: igmp v2 report 235.5.2.89
14:55:07.471305 IP 192.168.80.38.1000 > 235.5.2.89.1234: UDP, length 1316
14:55:07.475151 IP 192.168.80.38.1000 > 235.5.2.89.1234: UDP, length 1316
14:55:07.478524 IP 192.168.80.38.1000 > 235.5.2.89.1234: UDP, length 1316
14:55:07.482486 IP 192.168.80.38.1000 > 235.5.2.89.1234: UDP, length 1316
...Я продолжил копать. Запустил ещё раз ffprobe в трассировке (truss, аналог strace). Вот самые интересные куски из лога:
Код: Выделить всё
...
4339: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0) = 4 (0x4)
4339: close(4) = 0 (0x0)
4339: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0) = 4 (0x4)
4339: setsockopt(0x4,0xffff,0x800,0x7fffffffd38c,0x4) = 0 (0x0)
4339: setsockopt(0x4,0xffff,0x4,0x80a862028,0x4) = 0 (0x0)
4339: bind(4,{ AF_INET 234.5.2.125:1234 },16) = 0 (0x0)
4339: getsockname(4,{ AF_INET 234.5.2.125:1234 },0x7fffffffd6fc) = 0 (0x0)
4339: setsockopt(0x4,0x0,0xc,0x7fffffffd7a8,0x8) = 0 (0x0)
4339: setsockopt(0x4,0xffff,0x1002,0x7fffffffd784,0x4) = 0 (0x0)
4339: getsockopt(0x4,0xffff,0x1002,0x7fffffffd784,0x7fffffffd6fc) = 0 (0x0)
4339: fcntl(4,F_GETFL,) = 2 (0x2)
4339: fcntl(4,F_SETFL,O_NONBLOCK|0x2) = 0 (0x0)
4339: mmap(0x0,8388608,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34540093440 (0x80ac00000)
4339: mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366316544 (0x800646000)
4339: mmap(0x7fffdfdfd000,2101248,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_STACK,-1,0x0) = 140736949374976 (0x7fffdfdfd000)
4339: mprotect(0x7fffdfdfd000,4096,PROT_NONE) = 0 (0x0)
4339: thr_new(0x7fffffffd400,0x68) = 0 (0x0)
4339: fcntl(4,F_GETFL,) = 6 (0x6)
4339: fcntl(4,F_SETFL,0x2) = 0 (0x0)
4339: _umtx_op(0x80a817330,UMTX_OP_MUTEX_WAIT,0x0,0x0,0x0) = 0 (0x0)
4339: gettimeofday({ 1463131661.716110 },0x0) = 0 (0x0)
4339: _umtx_op(0x803373750,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x18,0x7fffffffdf68) ERR#60 'Operation timed out'
4339: gettimeofday({ 1463131661.823203 },0x0) = 0 (0x0)
4339: _umtx_op(0x803373750,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x18,0x7fffffffdf68) ERR#60 'Operation timed out'
4339: gettimeofday({ 1463131661.930169 },0x0) = 0 (0x0)
4339: _umtx_op(0x803373750,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x18,0x7fffffffdf68) ERR#60 'Operation timed out'
4339: gettimeofday({ 1463131662.037174 },0x0) = 0 (0x0)
4339: _umtx_op(0x803373750,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x18,0x7fffffffdf68) ERR#60 'Operation timed out'
4339: gettimeofday({ 1463131662.144199 },0x0) = 0 (0x0)
...Кончается это вот так:
Код: Выделить всё
...
4339: nanosleep({ 0.001000000 }) = 0 (0x0)
4339: gettimeofday({ 1463133045.812361 },0x0) = 0 (0x0)
4339: _umtx_op(0x803373750,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x18,0x7fffffffdf68) ERR#60 'Operation timed out'
4339: nanosleep({ 0.001000000 }) = 0 (0x0)
4339: gettimeofday({ 1463133045.921438 },0x0) = 0 (0x0)
4339: _umtx_op(0x803373750,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x18,0x7fffffffdf68) ERR#60 'Operation timed out'
4339: nanosleep({ 0.001000000 }) = 0 (0x0)
4339: gettimeofday({ 1463133046.030375 },0x0) = 0 (0x0)
4339: _umtx_op(0x803373750,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x18,0x7fffffffdf68) ERR#60 'Operation timed out'
4339: nanosleep({ 0.001000000 }) = 0 (0x0)
4339: gettimeofday({ 1463133046.139466 },0x0) = 0 (0x0)
4339: recvfrom(4,''G\^D\M-c\^P\0\0\0\^A\a:?\M^TF''...,65536,0x0,NULL,0x0) = 1316 (0x524)
4339: _umtx_op(0x803373750,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x18,0x7fffffffdf68) = 0 (0x0)
4339: _umtx_op(0x80a806e58,UMTX_OP_NWAKE_PRIVATE,0x1,0x0,0x0) = 0 (0x0)
4339: gettimeofday({ 1463133046.180207 },0x0) = 0 (0x0)
4339: recvfrom(4,''G\^D\M-c\^[\M-V\M-?\^W\^N\M^_''...,65536,0x0,NULL,0x0) = 1316 (0x524)
4339: _umtx_op(0x803373750,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x18,0x7fffffffdf68) = 0 (0x0)
4339: _umtx_op(0x80a806e58,UMTX_OP_NWAKE_PRIVATE,0x1,0x0,0x0) = 0 (0x0)
4339: mmap(0x0,8388608,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34548482048 (0x80b400000)
4339: madvise(0x80a861000,0x1000,0x5) = 0 (0x0)
4339: madvise(0x80a883000,0x10000,0x5) = 0 (0x0)
4339: madvise(0x80a8c4000,0x10000,0x5) = 0 (0x0)
4339: gettimeofday({ 1463133046.186198 },0x0) = 0 (0x0)
4339: recvfrom(4,''G\^D\M-k\^YNZ\M^R\M-j\M-g6\M^N''...,65536,0x0,NULL,0x0) = 1316 (0x524)
4339: _umtx_op(0x803373750,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x18,0x7fffffffbb88) = 0 (0x0)
4339: _umtx_op(0x80a806e58,UMTX_OP_NWAKE_PRIVATE,0x1,0x0,0x0) = 0 (0x0)
...Для эксперимента собрал такую же виртуалку с теми же vlan'ами на, свят-свят, Windows 7. После того, как прописал на ней конкретные маршруты для 234.0.0.0 и 235.0.0.0, виндовый ffprobe стал хватать мультикасты довольно шустро. С Linux'ом ещё не пробовали, но предполагаю, что он тоже будет вести себя адекватно. И вот только Фря подводит...
Гуглёж ничего не дал. Фантазия исчерпана
Если не починим, придётся переползать на какой-нибудь Debian или CentOS. Надежда лишь на сообщество.
