绑定无法正常工作(CentOS 5.4,Intel 10G,802.3ad)

绑定无法正常工作(CentOS 5.4,Intel 10G,802.3ad)

我们使用具有两个端口的 Intel 网络适配器 X540 配置了网络绑定。两个端口都连接到配置了 LACP 中继的 Brocade 交换机。一切似乎都运行正常;但是当我们物理断开两个端口时,绑定接口的状态仍然为开启!链路状态应该为关闭,不是吗?我们无法 ping 或连接到此接口;连接一个或两个从属端口后,一切正常。

有任何想法吗?

[root@er ~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.4.0 (October 7, 2008)

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
Active Aggregator Info:
    Aggregator ID: 1
    Number of ports: 2
    Actor Key: 0
    Partner Key: 1
    Partner Mac Address: 00:00:00:00:00:00

Slave Interface: eth2
MII Status: down
Link Failure Count: 1
Permanent HW addr: 90:e2:ba:37:41:28
Aggregator ID: 1

Slave Interface: eth3
MII Status: down
Link Failure Count: 1
Permanent HW addr: 90:e2:ba:37:41:29
Aggregator ID: 1

[root@er ~]# ethtool bond0
Settings for bond0:
    Link detected: yes

[root@er ~]# ethtool eth2
Settings for eth2:
    Supported ports: [ FIBRE ]
    Supported link modes:   1000baseT/Full
    Supports auto-negotiation: Yes
    Advertised link modes:  1000baseT/Full
                            10000baseT/Full
    Advertised auto-negotiation: Yes
    Speed: Unknown! (65535)
    Duplex: Unknown! (255)
    Port: FIBRE
    PHYAD: 0
    Transceiver: external
    Auto-negotiation: on
    Supports Wake-on: d
    Wake-on: d
    Current message level: 0x00000007 (7)
    Link detected: no

[root@er ~]# ethtool eth3
Settings for eth3:
    Supported ports: [ FIBRE ]
    Supported link modes:   1000baseT/Full
    Supports auto-negotiation: Yes
    Advertised link modes:  1000baseT/Full
                            10000baseT/Full
    Advertised auto-negotiation: Yes
    Speed: Unknown! (65535)
    Duplex: Unknown! (255)
    Port: FIBRE
    PHYAD: 0
    Transceiver: external
    Auto-negotiation: on
    Supports Wake-on: d
    Wake-on: d
    Current message level: 0x00000007 (7)
    Link detected: no

[root@er ~]# cat /etc/modprobe.conf
...
alias eth2 ixgbe
alias eth3 ixgbe
alias bond0 bonding
options bond0 mode=4 miimon=100

[root@er ~]# modinfo ixgbe
filename:       /lib/modules/2.6.18-164.el5/kernel/drivers/net/ixgbe/ixgbe.ko
version:        3.11.33
license:        GPL
description:    Intel(R) 10 Gigabit PCI Express Network Driver
author:         Intel Corporation, <[email protected]>
srcversion:     739E88C99BF8038F878AE91
...

[root@er ~]# cat /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
IPADDR=192.168.100.23
NETMASK=255.255.255.0
NETWORK=192.168.100.0
GATEWAY=192.168.100.1
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
IPV6INIT=no
[root@er ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth2
DEVICE=eth2
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
HWADDR=90:e2:ba:37:41:28
[root@er ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth3
DEVICE=eth3
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
HWADDR=90:e2:ba:37:41:29

[root@er ~]# uname -a
Linux er.dve.intern 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

[root@er ~]# tail /var/log/messages
Feb 25 18:11:42 er kernel: ixgbe 0000:0a:00.0: eth2: NIC Link is Down
Feb 25 18:11:42 er kernel: bonding: bond0: link status definitely down for interface eth2, disabling it
Feb 25 18:11:43 er kernel: ixgbe 0000:0a:00.1: eth3: NIC Link is Down
Feb 25 18:11:43 er kernel: bonding: bond0: link status definitely down for interface eth3, disabling it
Feb 25 18:11:43 er kernel: bonding: bond0: Warning: No 802.3ad response from the link partner for any adapters in the bond

答案1

您的输出显示 ethtool 认为您的两个接口都已关闭(bonding 模块也是如此)。Google 搜索“bonding.txt”并阅读内核的绑定文档,特别是关于链路监控的第 7 节(和 7.3 节)。由于 ethtool 似乎无法确定您的接口是否真的已启动,因此绑定驱动程序也无法确定,也许尝试使用“use_carrier=0”会有所帮助?或者尝试使用 arp 监控模式而不是 miimon?

编辑:抱歉,我想我读错了你的问题……你的命令输出似乎是在你拔掉网卡的时间段内,你想知道为什么 bond0 仍然显示它已启动?我不知道有什么可以立即解决此问题的东西。不过,我仍然建议将 bonds.txt 作为“linux+bonding”的圣经 :)

答案2

你是对的,当两个从属服务器都关闭时,ethtool bond0应该报告Link detected: no

尝试最新的内核。自 2009 年发布以来bonding,已经进行了无数次更新。像这样的基本链路状态更正现在可能已经修复。ixgbe2.6.18-164

我还建议坚持使用内核驱动程序而不是编译上游驱动程序,除非您确实有特殊的理由这样做。

相关内容