RHEL 6.4: Приєднання каналу в режимі 1 не припиняється

11

Я працюю RHEL 6.4, ядро-2.6.32-358.el6.i686, на HP ML 350 G5 з двома вбудованими широкоформатними пристроями Broadcom NetXtreme II BCM5708 1000Base-T. Моя мета - каналізувати зв'язок двох інтерфейсів у mode=1відмовної пари.

Моя проблема полягає в тому, що, незважаючи на всі докази того, що облігація встановлена ​​та прийнята, витягнення кабелю з первинного NIC призводить до припинення зв'язку.

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 addr вихід

Зв’язок закінчився, і я можу отримати доступ до публічних послуг сервера через 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 / class / net

В /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

/ var / log / повідомлення

У файлі журналу нічого не викликає занепокоєння. Насправді все виглядає досить щасливо.

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', BONDING_OPTSщоб дозволити використання йоктилів MII / ETHTOOL. Після перезапуску послуги мережі зміни симптомів не відбулися. Потягнення кабелю з- eth0за припинення всієї мережевої комунікації. Знову ж таки, жодних помилок у /var/log/messagesзбереженні повідомлення про те, що посилання на цьому порті не працює.

linux  redhat  rhel6  bonding 
— Веслі
джерело
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 :

основний = Вказує ім'я інтерфейсу, наприклад, eth0, основного пристрою. Первинний пристрій - це перший з використаних інтерфейсів зв'язку, який не використовується, якщо його не виходить з ладу. Цей параметр особливо корисний, коли один NIC в інтерфейсі зв'язку швидший і, отже, здатний впоратися з більшим навантаженням. Цей параметр дійсний лише тоді, коли інтерфейс зв’язку знаходиться в режимі активного резервного копіювання. Для отримання додаткової інформації зверніться до /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 в мілісеках, який не виконує et після його виявлення як збій, і встановіть первинний ведений на решту. Якщо цього параметра немає у 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.