Nach einem Upgrade unserer Maschinen von RHEL 6.6 auf RHEL 6.7 haben wir ein Problem festgestellt, bei dem 4 unserer 30 Maschinen Multicast-Verkehr nur über eine ihrer beiden Slave-Schnittstellen empfangen. Es ist unklar, ob das Upgrade damit zusammenhängt oder ob der darin enthaltene Neustart das Problem ausgelöst hat – Neustarts sind selten.
Wir erwarten, viele Multicast-Pakete an die Gruppe 239.0.10.200 auf 4 verschiedenen Ports zu erhalten. Wenn wir die Statistiken auf ethtooleiner der problematischen Maschinen überprüfen, sehen wir die folgende Ausgabe:
Gesunde Schnittstelle:
# 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
Defekte Schnittstelle:
# 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 wird von 10 anderen Maschinen erwartet. Wenn wir prüfen, von welchen Hosts eine defekte Maschine Multicast empfängt (mit tcpdump), empfängt sie nur von einer Teilmenge (3-6) der erwarteten Hosts.
Aufbau
Linux-Version:
# 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
Wennconfig:
# 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)
Netzwerkkonfiguration:
# 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
Treiberinformationen (dasselbe für 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
Adapter:
# 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/bonding0:
$ 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
Andere Informationen
Ein Neustart (
ifconfig down,ifconfig up) der defekten Schnittstelle behebt dieses ProblemGelegentlich wird beim Booten die folgende Meldung in unserem Syslog angezeigt (wir verwenden kein IPv6). Unser Problem tritt jedoch auch dann auf, wenn diese Meldung nicht protokolliert wird
Oct 2 11:27:51 ab30 kernel: bond0: IPv6 duplicate address fe80::4e76:25ff:fe87:9d75 detected!Ausgabe vom Syslog während der Konfiguration:
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 readyDie
bond0Schnittstelle ist der Multicast-Gruppe beigetreten, wie aus folgendem Bild ersichtlich istip maddr:... 4: bond0 inet 239.0.10.200 users 16 ...Auf anderen Rechnern im selben Netzwerk funktioniert alles. Es scheint jedoch (nicht 100% bestätigt), dass die funktionierenden Rechner einen anderen Netzwerkadapter haben:
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)Beim Überprüfen unserer Switch-Statistiken können wir sehen, dass Daten an beide Schnittstellen gesendet werden.
Was wir bisher versucht haben
Wie vorgeschlagen inDer Linux-Kernel lässt Multicast-UDP-Pakete nicht durchWir haben untersucht, ob wir ein
rp_filterProblem haben. Das Ändern dieser Flags hat für uns jedoch nichts geändert.Den Kernel auf den vor dem RedHat-Upgrade verwendeten Kernel heruntergestuft – keine Änderung.
Ich bin für alle Hinweise zur weiteren Fehlerbehebung dankbar. Wenn Sie weitere Informationen benötigen, lassen Sie es mich bitte wissen.
Antwort1
Wir haben Dell Blade-Server verwendet, bei denen dieses Problem auftrat. Nach Rücksprache mit dem Dell-Support scheint es, dass wir IGMPv3 EXCLUDEbeim Beitritt zur Multicast-Gruppe Filter verwenden. Der Ausschlussmodus wird vom Switch im Blade-Server offenbar nicht unterstützt. Es wird empfohlen, in den IGMPv3 INCLUDEFiltermodus zu wechseln.
Da wir Multicast auf unserer Plattform inzwischen nicht mehr verwenden, werden wir wahrscheinlich nicht dazu kommen, diese Änderungen auszuprobieren. Daher kann ich nicht mit Sicherheit sagen, dass dies die Grundursache ist.