RHEL 6.4: соединение каналов в режиме 1 не прекращается


11

Я использую 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сохранении для уведомления о том, что ссылка на этот порт не работает.


1
Можете ли вы добавить дополнительную информацию, такую ​​как коммутатор make / model, к которому подключен, любая настройка VLAN на коммутаторе, состояния подчиненного соединения и / var / log / messages после отсоединения кабеля к eth0?
Энди Шинн

@AndyShinn Коммутатор, к которому он напрямую подключен, - это ProCurve 1800-8G. В сети нет VLAN. Это простая одна подсеть, одна сеть VLAN.
Уэсли

@AndyShinn Ах, а также рабовладельческие государства, о которых сообщают, как up. Хвост /var/log/messagesво время отключения eth0 только показывает, что медное соединение было отключено. Нет сообщений от модуля склеивания.
Уэсли

Ответы:


21

ЧИТАТЬ. ВАШ. Конфиги.

И когда это не удается ...

ЧИТАТЬ. ВСЕ. ВЫХОДЫ.

Вы видите, что внутри ifcfg-bond0? Нет, ты понимаешь, что в ifcfg-bond0?
Что в мире скользких пингвинов есть miimmon=100?
О, прости, ты имел в виду miimon=100?

Да, я думаю, что вы имели в виду miimonи нет miimmon.

Кроме того, большое преимущество заключается в том, что при перезапуске сетевого сервиса вы видите это:

service network restart
Shutting down interface bond0:                             [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface bond0:  ./network-functions: line 446: /sys/class/net/bond0/bonding/miimmon: No such file or directory
./network-functions: line 446: /sys/class/net/bond0/bonding/miimmon: No such file or directory
                                                           [  OK  ]

Обратите особое внимание на все, что вы печатаете, и когда вы совершаете неизбежную ошибку при наборе текста, обращайте особое внимание на каждый вывод, который вы видите.

Вы плохой человек, и вы должны чувствовать себя плохо.


8
ПЛОХАЯ КОШКА! брызги со шлангом
voretaq7

2

Попробуйте указать один из NICS в качестве основного ведомого.

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 primary=eth0"

Больше документации от 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Спасибо за предложение!
Уэсли

попробуйте добавить use_carrier = 0? см. выше документацию RH для подробностей
dmourati

Готово - добавил информацию к вопросу. Не было никаких изменений в поведении, но это хороший вариант, чтобы знать о.
Уэсли

2

Добавьте следующий параметр связывания downdelay = xxxx в milisec, который завершается с ошибкой eth после того, как он был обнаружен как сбой, и установите основной ведомый на оставшийся. Если этот параметр отсутствует в bonding_opt, связь обнаруживает ошибку (потому что вы включаете miimom = yyyy), но она никогда не завершается ошибкой eth0. Вы можете увидеть это, посмотрев файл / proc / net / bonding / bondX.

В любом случае, с RHEL 6.3 (почти той же версией, что и у вас) у нас возникло несколько других проблем со связыванием, связанных с откатом дублированного mac addr, видимого с коммутатора.

удачи.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.