![Машина с объединенным интерфейсом не получает многоадресные пакеты на всех подчиненных интерфейсах](https://rvso.com/image/668060/%D0%9C%D0%B0%D1%88%D0%B8%D0%BD%D0%B0%20%D1%81%20%D0%BE%D0%B1%D1%8A%D0%B5%D0%B4%D0%B8%D0%BD%D0%B5%D0%BD%D0%BD%D1%8B%D0%BC%20%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D0%BE%D0%BC%20%D0%BD%D0%B5%20%D0%BF%D0%BE%D0%BB%D1%83%D1%87%D0%B0%D0%B5%D1%82%20%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE%D0%B0%D0%B4%D1%80%D0%B5%D1%81%D0%BD%D1%8B%D0%B5%20%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D1%8B%20%D0%BD%D0%B0%20%D0%B2%D1%81%D0%B5%D1%85%20%D0%BF%D0%BE%D0%B4%D1%87%D0%B8%D0%BD%D0%B5%D0%BD%D0%BD%D1%8B%D1%85%20%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D0%B0%D1%85.png)
После обновления наших машин с RHEL 6.6 до RHEL 6.7 мы обнаружили проблему, при которой 4 из 30 наших машин получали многоадресный трафик только на одном из двух подчиненных интерфейсов. Неясно, связано ли это с обновлением или включенный перезапуск вызвал такое поведение — перезапуски случаются редко.
Мы ожидаем получить много multicast-пакетов в группу 239.0.10.200 на 4 разных портах. Если мы проверим статистику на ethtool
одной из проблемных машин, то увидим следующий вывод:
Здоровый интерфейс:
# ethtool -S eth0 |grep mcast
[0]: rx_mcast_packets: 294
[0]: tx_mcast_packets: 0
[1]: rx_mcast_packets: 68
[1]: tx_mcast_packets: 0
[2]: rx_mcast_packets: 2612869
[2]: tx_mcast_packets: 305
[3]: rx_mcast_packets: 0
[3]: tx_mcast_packets: 0
[4]: rx_mcast_packets: 2585571
[4]: tx_mcast_packets: 0
[5]: rx_mcast_packets: 2571341
[5]: tx_mcast_packets: 0
[6]: rx_mcast_packets: 0
[6]: tx_mcast_packets: 8
[7]: rx_mcast_packets: 9
[7]: tx_mcast_packets: 0
rx_mcast_packets: 7770152
tx_mcast_packets: 313
Сломанный интерфейс:
# ethtool -S eth1 |grep mcast
[0]: rx_mcast_packets: 451
[0]: tx_mcast_packets: 0
[1]: rx_mcast_packets: 0
[1]: tx_mcast_packets: 0
[2]: rx_mcast_packets: 5
[2]: tx_mcast_packets: 304
[3]: rx_mcast_packets: 0
[3]: tx_mcast_packets: 0
[4]: rx_mcast_packets: 5
[4]: tx_mcast_packets: 145
[5]: rx_mcast_packets: 0
[5]: tx_mcast_packets: 0
[6]: rx_mcast_packets: 5
[6]: tx_mcast_packets: 10
[7]: rx_mcast_packets: 0
[7]: tx_mcast_packets: 0
rx_mcast_packets: 466
tx_mcast_packets: 459
Multicast ожидается от 10 других машин. Если мы проверим, с каких хостов сломанная машина получает multicast (используя tcpdump), то она получает только от подмножества (3-6) ожидаемых хостов.
Конфигурация
Версия для Linux:
# uname -a
Linux ab31 2.6.32-573.3.1.el6.x86_64 #1 SMP Mon Aug 10 09:44:54 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux
Есликонфигурация:
# ifconfig -a
bond0 Link encap:Ethernet HWaddr 4C:76:25:97:B1:75
inet addr:10.91.20.231 Bcast:10.91.255.255 Mask:255.255.0.0
inet6 addr: fe80::4e76:25ff:fe97:b175/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:18005156 errors:0 dropped:0 overruns:0 frame:0
TX packets:11407592 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:10221086569 (9.5 GiB) TX bytes:2574472468 (2.3 GiB)
eth0 Link encap:Ethernet HWaddr 4C:76:25:97:B1:75
inet6 addr: fe80::4e76:25ff:fe97:b175/64 Scope:Link
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:13200915 errors:0 dropped:0 overruns:0 frame:0
TX packets:3514446 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9386669124 (8.7 GiB) TX bytes:339950822 (324.2 MiB)
Interrupt:34 Memory:d9000000-d97fffff
eth1 Link encap:Ethernet HWaddr 4C:76:25:97:B1:75
inet6 addr: fe80::4e76:25ff:fe97:b175/64 Scope:Link
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:4804241 errors:0 dropped:0 overruns:0 frame:0
TX packets:7893146 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:834417445 (795.7 MiB) TX bytes:2234521646 (2.0 GiB)
Interrupt:36 Memory:da000000-da7fffff
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:139908 errors:0 dropped:0 overruns:0 frame:0
TX packets:139908 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:210503939 (200.7 MiB) TX bytes:210503939 (200.7 MiB)
Конфигурация сети:
# cat /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
IPADDR=10.91.20.231
NETMASK=255.255.0.0
GATEWAY=10.91.1.25
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
BONDING_OPTS="miimon=100 mode=802.3ad"
# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
HWADDR="4C:76:25:97:B1:75"
BOOTPROTO=none
ONBOOT="yes"
USERCTL=no
MASTER=bond0
SLAVE=yes
# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE="eth1"
HWADDR="4C:76:25:97:B1:78"
BOOTPROTO=none
ONBOOT="yes"
USERCTL=no
MASTER=bond0
SLAVE=yes
Информация о драйвере (то же самое для eth1):
# ethtool -i eth0
driver: bnx2x
version: 1.710.51-0
firmware-version: FFV7.10.17 bc 7.10.11
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
Адаптер:
# lspci|grep Ether
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet (rev 10)
01:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet (rev 10)
/proc/net/bonding/bond0:
$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
802.3ad info
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
Aggregator ID: 1
Number of ports: 2
Actor Key: 33
Partner Key: 5
Partner Mac Address: 00:01:09:06:09:07
Slave Interface: eth0
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 4c:76:25:97:b1:75
Aggregator ID: 1
Slave queue ID: 0
Slave Interface: eth1
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 4c:76:25:97:b1:78
Aggregator ID: 1
Slave queue ID: 0
Дополнительная информация
Перезапуск (
ifconfig down
,ifconfig up
) сломанного интерфейса исправляет эту проблемуИногда во время загрузки мы видим следующее сообщение в нашем системном журнале (мы не используем IPv6), однако наша проблема возникает даже тогда, когда это сообщение не регистрируется
Oct 2 11:27:51 ab30 kernel: bond0: IPv6 duplicate address fe80::4e76:25ff:fe87:9d75 detected!
Вывод из системного журнала во время настройки:
Oct 5 07:44:31 ab31 kernel: bonding: bond0 is being created... Oct 5 07:44:31 ab31 kernel: bonding: bond0 already exists Oct 5 07:44:31 ab31 kernel: bond0: Setting MII monitoring interval to 100 Oct 5 07:44:31 ab31 kernel: bond0: Setting MII monitoring interval to 100 Oct 5 07:44:31 ab31 kernel: ADDRCONF(NETDEV_UP): bond0: link is not ready Oct 5 07:44:31 ab31 kernel: bond0: Setting MII monitoring interval to 100 Oct 5 07:44:31 ab31 kernel: bond0: Adding slave eth0 Oct 5 07:44:31 ab31 kernel: bnx2x 0000:01:00.0: firmware: requesting bnx2x/bnx2x-e2-7.10.51.0.fw Oct 5 07:44:31 ab31 kernel: bnx2x 0000:01:00.0: eth0: using MSI-X IRQs: sp 120 fp[0] 122 ... fp[7] 129 Oct 5 07:44:31 ab31 kernel: bnx2x 0000:01:00.0: eth0: NIC Link is Up, 10000 Mbps full duplex, Flow control: none Oct 5 07:44:31 ab31 kernel: bond0: Enslaving eth0 as a backup interface with an up link Oct 5 07:44:31 ab31 kernel: bond0: Adding slave eth1 Oct 5 07:44:31 ab31 kernel: bnx2x 0000:01:00.1: firmware: requesting bnx2x/bnx2x-e2-7.10.51.0.fw Oct 5 07:44:31 ab31 kernel: bnx2x 0000:01:00.1: eth1: using MSI-X IRQs: sp 130 fp[0] 132 ... fp[7] 139 Oct 5 07:44:31 ab31 kernel: bnx2x 0000:01:00.1: eth1: NIC Link is Up, 10000 Mbps full duplex, Flow control: none Oct 5 07:44:31 ab31 kernel: bond0: Enslaving eth1 as a backup interface with an up link Oct 5 07:44:31 ab31 kernel: ADDRCONF(NETDEV_UP): bond0: link is not ready Oct 5 07:44:31 ab31 kernel: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
Интерфейс
bond0
присоединен к многоадресной группе, как видно изip maddr
:... 4: bond0 inet 239.0.10.200 users 16 ...
На других машинах в той же сети все работает. Однако, похоже (не подтверждено на 100%), что на рабочих машинах есть другой сетевой адаптер:
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)
Проверяя статистику коммутатора, мы видим, что данные отправляются на оба интерфейса.
Что мы уже пробовали
Как предложено вЯдро Linux не проходит через многоадресные пакеты UDPмы исследовали, была ли у нас
rp_filter
проблема. Однако изменение этих флагов ничего не изменило для нас.Понизил версию ядра до той, которая использовалась до обновления RedHat — никаких изменений.
Буду признателен за любые подсказки по дальнейшему устранению неполадок. Если нужна дополнительная информация, пожалуйста, дайте мне знать.
решение1
Мы использовали блейд-серверы Dell, на которых возникла эта проблема. После работы со службой поддержки Dell выяснилось, что мы используем IGMPv3 EXCLUDE
фильтрацию при присоединении к многоадресной группе. По-видимому, режим исключения не поддерживается коммутатором в блейд-сервере. Нам рекомендуется переключиться в IGMPv3 INCLUDE
режим фильтрации.
Однако теперь мы прекратили использовать multicast на нашей платформе, поэтому мы, вероятно, не сможем опробовать эти изменения. Поэтому я не могу с уверенностью сказать, что это основная причина.