![La máquina con interfaz vinculada no recibe paquetes de multidifusión en todas las interfaces esclavas](https://rvso.com/image/668060/La%20m%C3%A1quina%20con%20interfaz%20vinculada%20no%20recibe%20paquetes%20de%20multidifusi%C3%B3n%20en%20todas%20las%20interfaces%20esclavas.png)
Después de una actualización de nuestras máquinas de RHEL 6.6 a RHEL 6.7, observamos un problema en el que 4 de nuestras 30 máquinas solo reciben tráfico de multidifusión en una de sus dos interfaces esclavas. No está claro si la actualización está relacionada o si el reinicio incluido desencadenó el comportamiento; los reinicios son raros.
Esperamos recibir muchos paquetes de multidifusión al grupo 239.0.10.200 en 4 puertos diferentes. Si verificamos las estadísticas de ethtool
una de las máquinas problemáticas, vemos el siguiente resultado:
Interfaz saludable:
# 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
Interfaz rota:
# 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
Se espera multidifusión desde otras 10 máquinas. Si verificamos de qué hosts recibe multidifusión una máquina averiada (usando tcpdump), solo recibe de un subconjunto (3-6) de los hosts esperados.
Configuración
Versión de 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:
# 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)
Configuración de la red:
# 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
Información del conductor (lo mismo para 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
Adaptador:
# 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
Otra información
Reiniciar (
ifconfig down
,ifconfig up
) la interfaz rota soluciona este problemaOcasionalmente, durante el arranque vemos el siguiente mensaje en nuestro syslog (no usamos IPv6), sin embargo, nuestro problema ocurre incluso cuando este mensaje no está registrado
Oct 2 11:27:51 ab30 kernel: bond0: IPv6 duplicate address fe80::4e76:25ff:fe87:9d75 detected!
Salida de syslog durante la configuración:
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
La
bond0
interfaz está unida al grupo de multidifusión, como se ve enip maddr
:... 4: bond0 inet 239.0.10.200 users 16 ...
Todo funciona en otras máquinas de la misma red. Sin embargo, parece (no 100% confirmado) que las máquinas en funcionamiento tienen otro adaptador de red:
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)
Al verificar las estadísticas de nuestro conmutador, podemos ver que los datos se envían a ambas interfaces.
Lo que hemos probado hasta ahora
Como se sugiere enEl kernel de Linux no pasa paquetes UDP de multidifusiónInvestigamos si teníamos algún
rp_filter
problema. Sin embargo, cambiar estas banderas no cambió nada para nosotros.Se bajó la versión del kernel al que se usaba antes de la actualización de RedHat; sin cambios.
Se agradece cualquier sugerencia sobre cómo solucionar más problemas. Si se necesita más información, por favor hágamelo saber.
Respuesta1
Estábamos usando servidores blade Dell donde apareció este problema. Después de trabajar con el soporte de Dell, parece que estamos usando IGMPv3 EXCLUDE
filtrado al unirnos al grupo de multidifusión. Aparentemente, el modo de exclusión no es compatible con el conmutador del servidor Blade. Se recomienda cambiar al IGMPv3 INCLUDE
modo de filtro.
Sin embargo, ahora hemos dejado de usar multidifusión en nuestra plataforma, por lo que probablemente no podamos probar estos cambios. Por lo tanto, no puedo decir con certeza que esta sea la causa principal.