Я готовлю некоторые новые серверы виртуализации, и часть этого состоит в том, чтобы подключить к ним несколько каналов с более высокой пропускной способностью. Конечная цель состоит в том, чтобы связать 4 порта GigE в одну магистраль, несущую маркированный трафик 802.1q. Я могу зайти так далеко, но столкнулся со странной проблемой. Но сначала диаграмма.
---------- ---------- 1GbE trunks
| | 10GbE | | ------------- --------
| SW1 |-------| SW2 | ------------- | VM1 |
| | | | ------------- --------
---------- ----------
| | 1GbE -----------
| 1GbE |--------| client2 |
| -----------
----------
| | 1GbE -----------
| SW3 |------| client1 |
| | -----------
----------
Все коммутаторы являются коммутаторами HP ProCurve 2910al и не сложены. Client2 на диаграмме выше находится в той же VLAN, что и VM1. Клиент1 находится в другой VLAN. Для машины с виртуальной машиной (CentOS 6) iptables и SELinux были отключены.
Моя проблема заключается в том, что при использовании транкинга двусторонний сетевой трафик невозможен при общении с любым клиентским компьютером. TCPDUMP показывает, что они получают эхо-запросы и отправляют пакеты ECHO REPLY, но хост VM их не видит. В то же время, если я пытаюсь пропинговать виртуальную машину с клиентского компьютера, это также не работает. Тот факт, что я не могу пропинговать client2, который находится в той же подсети, предполагает, что что-то не так в сетевом уровне.
Странно, но с хоста VM я могу пинговать IP-адреса шлюза на любом из коммутаторов. Если я использую один интерфейс, все работает отлично как с тегами VLAN, так и без них. Если я просто привязываю один интерфейс и включаю теги VLAN на этом интерфейсе, я могу пойти куда угодно. Построить багажник, и я ограничен коммутационной фабрикой.
Тип ствола не имеет значения. Прямо сейчас они настроены с транками режима 0 (balance-rr), хотя использование LACP / 802.1qa ведет себя так же.
vlan 70
name "Virtualization Subnet"
untagged 35,36,38,40
tagged Trk1-Trk2,Trk5,Trk8
no ip address
jumbo
exit
Это конфигурация VLAN на SW2 там. В определении VLAN 70 в SW1 определен «IP-адрес». Вышеприведенный фрагмент находится в полностью разряженном режиме. Когда я в багажнике:
trunk 35-36,38,40 Trk16 trunk
vlan 70
name "Virtualization Subnet"
tagged Trk1-Trk2,Trk5,Trk8,Trk16
no ip address
jumbo
exit
Версия 802.1qa / LACP меняет определение магистрали, trunk 35-36,38,40 Trk16 lacp
но, как я уже сказал, не меняет представление проблемы.
Клиент2 действительно подключен к SW1, но размещение его там на диаграмме сделало бы форматирование более сложным. В любом случае единственная вещь в разделе Интерфейс - это name
директива; он указан как untagged
порт в разделе VLAN 70 для SW1.
Что мне не хватает?
источник
Ответы:
После долгих дебатов в чате с участием MikeyB , Pauska и ChrisS проблема в итоге оказалась двоякой:
bonding
модуля как частиservice network restart
, поэтому он не отслеживал мои изменения между режимом LACP (4) и roundrobin (0).Однажды я перевел связанный интерфейс в режим LACP / 802.1qa с помощью этой команды:
И сервер, и коммутатор разговаривали. В этот момент, начиная с включения только одного интерфейса на коммутаторе, трафик начал работать нормально. Включение второго, третьего и, наконец, четвертого интерфейсов позволило поддерживать работоспособность трафика.
В конечном счете, LACP-режим - это то, что заставляет вещи работать. Подсказка заключалась в том, что режим циклического перебора работал, когда в магистрали был только один включенный порт коммутатора. Сервер переживает перезагрузку и загружается в правильном режиме. Однако, a
service network restart
не приводит к тому, чтоMODE="4"
частьifcfg-bond0
файла/etc/sysconfig/network-scripts/
вступает в силу. Если этот режим изменится, он останется тем, что было установлено при загрузке (или, что более вероятно, временем загрузкиbonding
модуля).источник
У вас есть в вашей конфигурации:
Не должно ли это быть:
источник
untagged 35-36,38,40
и то иtagged 35-36,38,40...
другое работает, пока я не пытаюсь объединить интерфейсы на сервере Linux.untagged Trk16
иtagged Trk16...
оба не работают.