У меня проблемы с правильной работой транка LACP в Ubuntu 12.04.2 LTS.
Моя установка - это один хост, соединенный с двумя интерфейсами 10 Gbe с двумя отдельными коммутаторами Nexus 5548, с vPC, настроенным для включения LACP с несколькими шасси. Конфигурация Nexus соответствует рекомендациям Cisco, а конфигурация Ubuntu - https://help.ubuntu.com/community/UbuntuBonding
Сервер подключен к порту Ethernet1 / 7 на каждом коммутаторе Nexus, порты которого настроены одинаково и помещены в порт-канал 15. Порт-канал 15 настроен как VPC 15, и выход VPC выглядит хорошо. Это простые порты доступа, т. Е. Без использования транкинга 801.1q.
Диаграмма:
+----------+ +----------+ +----------+ +----------+
| client 1 |------| nexus 1 |------| nexus 2 |------| client 2 |
+----------+ +----------+ +----------+ +----------+
| |
| +--------+ |
+----| server |----+
eth4 +--------+ eth5
Когда какое-либо соединение не работает, оба клиента 1 и 2 могут связаться с сервером. Однако, когда я подключаю вторичный канал, клиент, подключенный к коммутатору по вновь включенному каналу, не может связаться с сервером. См. Следующую таблицу для переходов между состояниями и результатов:
port states (down by means of "shutdown")
nexus 1 eth1/7 up up down up
nexus 2 eth1/7 down up up up
connectivity
client 1 - server OK OK OK FAIL
client 2 - server OK FAIL OK OK
Теперь я полагаю, что изолировал проблему от Linux. В активном состоянии каждая нексус использует локальную ссылку на сервер для доставки пакетов, что подтверждается просмотром таблицы MAC-адресов. Что я могу видеть на сервере, так это то, что пакеты от каждого клиента принимаются на интерфейсе ethX (пакеты от клиента 1 на eth4, пакеты от клиента 2 на eth4) с помощью tcpdump -i ethX, но когда я запускаю tcpdump -i bond0 Я могу передавать трафик только с любого из хостов (в соответствии с тем, что я сказал выше).
Я наблюдаю такое же поведение для трафика ARP и ICMP (IP); ARP не работает от клиента, когда обе ссылки работают, работает (вместе с ping), когда одна из них не работает, ping не работает, когда я снова включаю ссылку (пакеты все еще принимаются на интерфейсе eth, но не на bond0).
Чтобы уточнить, я настраиваю несколько серверов в этой конфигурации, и все они показывают одинаковые симптомы, поэтому, похоже, это не связано с оборудованием.
Итак - выяснение того, как это исправить - вот с чем я имею дело; мой поиск в Google пока не принес мне удачи.
Любые указатели приветствуются.
/ и т.д. / сеть / интерфейсы
auto eth4
iface eth4 inet manual
bond-master bond0
auto eth5
iface eth5 inet manual
bond-master bond0
auto bond0
iface bond0 inet static
address 10.0.11.5
netmask 255.255.0.0
gateway 10.0.0.3
mtu 9216
dns-nameservers 8.8.8.8 8.8.4.4
bond-mode 4
bond-miimon 100
bond-lacp-rate 1
#bond-slaves eth4
bond-slaves eth4 eth5
/ proc / net / bonding / bond0
A little further information:
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: fast
Min links: 0
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
Aggregator ID: 1
Number of ports: 1
Actor Key: 33
Partner Key: 1
Partner Mac Address: 00:00:00:00:00:00
Slave Interface: eth4
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 8
Permanent HW addr: 90:e2:ba:3f:d1:8c
Aggregator ID: 1
Slave queue ID: 0
Slave Interface: eth5
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 13
Permanent HW addr: 90:e2:ba:3f:d1:8d
Aggregator ID: 2
Slave queue ID: 0
РЕДАКТИРОВАТЬ: добавлен конфиг из Nexus
vpc domain 100
role priority 4000
system-priority 4000
peer-keepalive destination 10.141.10.17 source 10.141.10.12
peer-gateway
auto-recovery
interface port-channel15
description server5
switchport access vlan 11
spanning-tree port type edge
speed 10000
vpc 15
interface Ethernet1/7
description server5 internal eth4
no cdp enable
switchport access vlan 11
channel-group 15
РЕДАКТИРОВАТЬ: добавлены результаты из порта-канала без VPC на nexus1 для одного и того же сервера до и после изменения IP (измененный IP-адрес влияет на алгоритм балансировки нагрузки). На сервере все еще используются те же настройки.
port states (down by means of "shutdown")
nexus 1 eth1/7 up up down up
nexus 1 eth1/14 down up up up <= port moved from nexus 2 eth1/7
connectivity (sever at 10.0.11.5, hashing uses Eth1/14)
client 1 - server OK OK OK FAIL
client 2 - server OK OK OK FAIL
Результаты после смены IP соответствуют прогнозам; Неиспользуемый интерфейс вызывает сбои.
connectivity (sever at 10.0.11.15, hashing uses Eth1/7)
client 1 - server OK FAIL OK OK
client 2 - server OK FAIL OK OK
Единственная конфигурация LACP, которую мне удалось заставить работать в Ubuntu, такова:
auto bond0
iface bond0 inet dhcp
bond-mode 4
bond-slaves none
bond-miimon 100
bond-lacp-rate 1
bond-updelay 200
bond-downdelay 200
auto eth0
iface eth0 inet manual
bond-master bond0
auto eth1
iface eth1 inet manual
bond-master bond0
то есть я использую не подчиненных-рабов, а бонд-хозяина. Я не уверен, в чем разница, но я обнаружил, что эта конфигурация у меня работает.
У меня нет проблем с LACP при моей настройке, хотя это с сетью 1Gbe.
Кроме того, если проблемы все еще возникают, попробуйте подключить оба кабеля к одному коммутатору и настроить порты для LACP. Просто чтобы исключить возможность проблем с LACP с несколькими шасси.
проблема не на стороне Linux, а на стороне нексуса и как это работает в конфигурации vPC.
чтобы сначала настроить vPC на нексусе, вам необходимо подключить два коммутатора нексуса и настроить эту ссылку как «одноранговую».
в нормальной ситуации, когда оба канала от коммутатора к серверу находятся в состоянии UP, трафик в vlan 11, настроенном на vPC, отбрасывается на одноранговом канале.
только когда один из интерфейсов, входящих в vPC, не работает - трафик в vlan 11 разрешен по одноранговой ссылке.
вот как vPC работает на коммутаторах Nexus.
для решения этой проблемы вы можете запустить Fabric-path и установить другое соединение между коммутаторами nexus-1 и nexus-2.