Maschine mit Bondschnittstelle empfängt keine Multicast-Pakete auf allen Slave-Schnittstellen

Question

Maschine mit Bondschnittstelle empfängt keine Multicast-Pakete auf allen Slave-Schnittstellen

Nach einem Upgrade unserer Maschinen von RHEL 6.6 auf RHEL 6.7 haben wir ein Problem festgestellt, bei dem 4 unserer 30 Maschinen nur Multicast-Verkehr auf einer ihrer beiden Slave-Schnittstellen erhalten. Es ist unklar, ob das Upgrade in Zusammenhang steht oder ob der enthaltene Neustart das Verhalten ausgelöst hat - Neustarts sind selten.

Wir erwarten viele Multicast-Pakete an die Gruppe 239.0.10.200 an vier verschiedenen Ports. Wenn wir die Statistik mit ethtool auf einem der problematischen Maschinen überprüfen, wird folgende Ausgabe angezeigt:

Fehlerfreie 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

Defektes Interface:

# 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 ausgegeben. Wenn wir prüfen, von welchen Hosts eine kaputte Maschine Multicast empfängt (mithilfe von tcpdump), erhält sie nur von einer Teilmenge (3-6) der erwarteten Hosts.

Konfiguration

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

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)

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

Treiberinfo (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/bond/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

Sonstige Informationen

Durch einen Neustart (ifconfig down, ifconfig up) wird das Problem behoben.
Gelegentlich wird während des Systemstarts die folgende Nachricht in unserem Syslog angezeigt (wir verwenden kein IPv6). Unser Problem tritt jedoch auf, selbst wenn diese Nachricht nicht protokolliert wird
```
Oct  2 11:27:51 ab30 kernel: bond0: IPv6 duplicate address fe80::4e76:25ff:fe87:9d75 detected!
```

Ausgabe von 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 ready

Die Schnittstelle bond0 ist mit der Multicast-Gruppe verbunden, wie aus ip maddr:
ersichtlich ist
```
...
4:      bond0
inet  239.0.10.200 users 16
...
```
Alles funktioniert auf anderen Computern im selben Netzwerk. Es scheint jedoch (nicht zu 100% bestätigt), dass die Arbeitsmaschinen über einen anderen Netzwerkadapter verfügen:
```
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)
```
Bei der Überprüfung unserer Switch-Statistiken können Daten an beide Schnittstellen gesendet werden.

Was wir bisher versucht haben

Wie in vorgeschlagen, dass Linux-Kernel keine Multicast-UDP-Pakete durchlaufen, haben wir untersucht, ob wir ein rp_filter -Problem hatten. Das Ändern dieser Flags hat für uns jedoch nichts geändert.
Der Kernel wurde auf den vor der RedHat-Aktualisierung verwendeten Kerngrad heruntergestuft - keine Änderung.

Hinweise zur weiteren Fehlerbehebung sind willkommen. Wenn weitere Informationen benötigt werden, lass es mich wissen.

linux networking troubleshooting bonding multicast

quelle

3 stimmen 1 antworten

fragte K Erlandsson Oct 5 '15 um 11:22

antworten

K Erlandsson · Answer 1 · 2016-05-25T14:16:12+03:00

Wir haben Dell Blade-Server verwendet, bei denen dieses Problem aufgetreten ist. Nach der Arbeit mit der Dell-Unterstützung scheint es, dass wir die IGMPv3 EXCLUDE -Filterung verwenden, wenn wir der Multicast-Gruppe beitreten. Anscheinend wird der Ausschlussmodus vom Switch im Blade-Server nicht unterstützt. Wir empfehlen, in den Filtermodus IGMPv3 INCLUDE zu wechseln.

Wir haben jedoch auf unserer Plattform aufgehört, Multicast zu verwenden, weshalb wir wahrscheinlich nicht dazu kommen werden, diese Änderungen auszuprobieren. Daher kann ich nicht sicher sagen, dass dies die Ursache ist.