Я использую RHEL 6.4, kernel-2.6.32-358.el6.i686, на HP ML 350 G5 с двумя встроенными сетевыми платами Broadcom NetXtreme II BCM5708 1000Base-T. Моя цель - объединить два интерфейса в mode=1
пару аварийного переключения.
Моя проблема заключается в том, что, несмотря на все доказательства того, что связь установлена и принята, отсоединение кабеля от основного сетевого адаптера приводит к прекращению всей связи.
ifcfg-etho и ifcfg-eth1
Во-первых, ifcfg-eth0:
DEVICE=eth0
HWADDR=00:22:64:F8:EF:60
TYPE=Ethernet
UUID=99ea681d-831b-42a7-81be-02f71d1f7aa0
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=none
MASTER=bond0
SLAVE=yes
Далее ifcfg-eth1:
DEVICE=eth1
HWADDR=00:22:64:F8:EF:62
TYPE=Ethernet
UUID=92d46872-eb4a-4eef-bea5-825e914a5ad6
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=none
MASTER=bond0
SLAVE=yes
ifcfg-bond0
Конфигурационный файл моей облигации:
DEVICE=bond0
IPADDR=192.168.11.222
GATEWAY=192.168.11.1
NETMASK=255.255.255.0
DNS1=192.168.11.1
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
BONDING_OPTS="mode=1 miimmon=100"
/etc/modprobe.d/bonding.conf
У меня есть /etc/modprobe.d/bonding.conf
файл, который заполняется таким образом:
alias bond0 bonding
IP-адрес вывода
Связь установлена, и я могу получить доступ к общедоступным службам сервера через IP-адрес связи:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000
link/ether 00:22:64:f8:ef:60 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000
link/ether 00:22:64:f8:ef:60 brd ff:ff:ff:ff:ff:ff
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:22:64:f8:ef:60 brd ff:ff:ff:ff:ff:ff
inet 192.168.11.222/24 brd 192.168.11.255 scope global bond0
inet6 fe80::222:64ff:fef8:ef60/64 scope link
valid_lft forever preferred_lft forever
Модуль связующего ядра
... загружен:
# cat /proc/modules | grep bond
bonding 111135 0 - Live 0xf9cdc000
/ SYS / класс / нетто
В /sys/class/net
файловой показывает хорошие вещи:
cat /sys/class/net/bonding_masters
bond0
cat /sys/class/net/bond0/operstate
up
cat /sys/class/net/bond0/slave_eth0/operstate
up
cat /sys/class/net/bond0/slave_eth1/operstate
up
cat /sys/class/net/bond0/type
1
/ вар / Журнал / сообщения
Ничего вызывающего беспокойство не появляется в файле журнала. На самом деле все выглядит довольно счастливым.
Jun 15 15:47:28 rhsandbox2 kernel: Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: setting mode to active-backup (1).
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: setting mode to active-backup (1).
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: setting mode to active-backup (1).
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: setting mode to active-backup (1).
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: Adding slave eth0.
Jun 15 15:47:28 rhsandbox2 kernel: bnx2 0000:03:00.0: eth0: using MSI
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: making interface eth0 the new active one.
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: first active interface up!
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: enslaving eth0 as an active interface with an up link.
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: Adding slave eth1.
Jun 15 15:47:28 rhsandbox2 kernel: bnx2 0000:05:00.0: eth1: using MSI
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: enslaving eth1 as a backup interface with an up link.
Jun 15 15:47:28 rhsandbox2 kernel: 8021q: adding VLAN 0 to HW filter on device bond0
Jun 15 15:47:28 rhsandbox2 kernel: bnx2 0000:03:00.0: eth0: NIC Copper Link is Up, 1000 Mbps full duplex
Jun 15 15:47:28 rhsandbox2 kernel: bnx2 0000:05:00.0: eth1: NIC Copper Link is Up, 1000 Mbps full duplex
Так в чем проблема?!
Отключение сетевого кабеля от eth0 приводит к потере связи. В чем может быть проблема и какие дальнейшие шаги я должен предпринять, чтобы устранить это?
РЕДАКТИРОВАТЬ:
Дальнейшее устранение неисправностей:
Сеть представляет собой одну подсеть, одну VLAN, предоставляемую коммутатором ProCurve 1800-8G. Я добавил primary=eth0
к ifcfg-bond0
и рестарт сетевые сервисы, но это не изменило любое поведение. Я проверил /sys/class/net/bond0/bonding/primary
как до, так и после добавления, primary=eth1
и оно имеет нулевое значение, которое я не уверен, хорошо это или плохо.
Хвост, /var/log/messages
когда eth1
его кабель удален, не показывает ничего, кроме:
Jun 15 16:51:16 rhsandbox2 kernel: bnx2 0000:03:00.0: eth0: NIC Copper Link is Down
Jun 15 16:51:24 rhsandbox2 kernel: bnx2 0000:03:00.0: eth0: NIC Copper Link is Up, 1000 Mbps full duplex
Я добавил use_carrier=0
к ifcfg-bond0
«s BONDING_OPTS
разделу позволяет использовать MII / Ethtool IOCTLs. После перезапуска сетевой службы симптомы не изменились. При отсоединении кабеля eth0
все сетевые коммуникации прекращаются. Еще раз, нет ошибок в /var/log/messages
сохранении для уведомления о том, что ссылка на этот порт не работает.
up
. Хвост/var/log/messages
во время отключения eth0 только показывает, что медное соединение было отключено. Нет сообщений от модуля склеивания.Ответы:
ЧИТАТЬ. ВАШ. Конфиги.
И когда это не удается ...
ЧИТАТЬ. ВСЕ. ВЫХОДЫ.
Вы видите, что внутри
ifcfg-bond0
? Нет, ты понимаешь, что вifcfg-bond0
?Что в мире скользких пингвинов есть
miimmon=100
?О, прости, ты имел в виду
miimon=100
?Да, я думаю, что вы имели в виду
miimon
и нетmiimmon
.Кроме того, большое преимущество заключается в том, что при перезапуске сетевого сервиса вы видите это:
Обратите особое внимание на все, что вы печатаете, и когда вы совершаете неизбежную ошибку при наборе текста, обращайте особое внимание на каждый вывод, который вы видите.
Вы плохой человек, и вы должны чувствовать себя плохо.
источник
Попробуйте указать один из NICS в качестве основного ведомого.
Больше документации от RH :
primary = указывает имя интерфейса, например eth0, основного устройства. Основное устройство - это первый из используемых интерфейсов связывания, и оно не покидается, если оно не выходит из строя. Этот параметр особенно полезен, когда один сетевой адаптер в интерфейсе соединения работает быстрее и, следовательно, способен выдерживать большую нагрузку. Этот параметр действителен, только если интерфейс соединения находится в режиме активного резервного копирования. Обратитесь к /usr/share/doc/kernel-doc-/Documentation/networking/bonding.txt для получения дополнительной информации.
источник
ifcfg-bond0
я проверил,/sys/class/net/bond0/bonding/primary
и ответ пуст. Я добавилprimary=eth0
кifcfg-bond0
и перезапустить службу сети. Нет никаких изменений в симптоме и никаких изменений./sys/class/net/bond0/bonding/primary
Спасибо за предложение!Добавьте следующий параметр связывания downdelay = xxxx в milisec, который завершается с ошибкой eth после того, как он был обнаружен как сбой, и установите основной ведомый на оставшийся. Если этот параметр отсутствует в bonding_opt, связь обнаруживает ошибку (потому что вы включаете miimom = yyyy), но она никогда не завершается ошибкой eth0. Вы можете увидеть это, посмотрев файл / proc / net / bonding / bondX.
В любом случае, с RHEL 6.3 (почти той же версией, что и у вас) у нас возникло несколько других проблем со связыванием, связанных с откатом дублированного mac addr, видимого с коммутатора.
удачи.
источник