AlKov Опубликовано 17 июня, 2014 · Жалоба Дано: KVM (libvirt) на CentOS 6.4. Необходимо прозрачно (без IP на vlan интерфейсах хост-машины) пробросить около сотни vlan в гостевую ОС (тоже CentOS). На хост-машине два интерфейса (Intel 82575EB). Пытался реализовать, как обычно, с помощью бриджей - не катит, трафик не ходит.. <interface type='bridge'> <mac address='52:54:00:d4:3b:2b'/> <source bridge='br0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <interface type='bridge'> <source bridge='br1'/> <mac address='52:54:00:d4:3b:2c'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </interface> На хост-машине - vconfig add br0 1000 vconfig add br1 2000 ifconfig vlan1000 up ifconfig vlan2000 up На гостевой - vconfig eth0 1000 vconfig eth1 2000 ifconfig vlan1000 192.168.1.1/24 up ifconfig vlan2000 192.168.2.1/24 up Интерфейсы все поднимаются, но трафик не ходит. Перелопатил тонны гугля - результата нет... :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Danila Опубликовано 17 июня, 2014 (изменено) · Жалоба Если память не изменяет делается немного по другому. На хост машине создаете vlan'ы. Добавляете их в бридж. И дальше уже эти бриджы добавляете в кач-ве интерфейсов в гостевую ОС. В итоге на хост машине получится портянка интерфейсов аля vlan и br, а в госте будет портянка eth интерфейсов. Поправьте, если ошибся. Но других способов я пока не нашел. :) Изменено 17 июня, 2014 пользователем Danila Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 17 июня, 2014 · Жалоба Хм. Я всегда поднимал VLAN-ы тупо внутри виртуальной машины, Linux bridge у меня пропускает тегированный трафик. А на сетевой карте часом не включен hw vlan filter? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 18 июня, 2014 (изменено) · Жалоба Если память не изменяет делается немного по другому. На хост машине создаете vlan'ы. Добавляете их в бридж. И дальше уже эти бриджы добавляете в кач-ве интерфейсов в гостевую ОС. Да вроде и так уже делал. Чего только и не пробовал от безысходности, уже забыл что. Проверил еще раз. Результат аналогичный. Кстати, обнаружил такую штуку - назначил IP vlan интерфейсу на хост-машине для проверки. Так вот - стОит добавить интерфейс vlan в бридж, трафик перестаёт ходить до хост-машины. Ну и также не ходит и в гостевую. Я всегда поднимал VLAN-ы тупо внутри виртуальной машины, Linux bridge у меня пропускает тегированный трафик. Тоже так считал до недавнего времени. Ан нет.. А на сетевой карте часом не включен hw vlan filter? А где находится этот параметр, как глянуть? Изменено 18 июня, 2014 пользователем AlKov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tem Опубликовано 18 июня, 2014 (изменено) · Жалоба на хосте (CentOs 6.5) cat ifcfg-br0 DEVICE=br0 TYPE=Bridge ONBOOT=yes BOOTPROTO=none cat ifcfg-eth0 DEVICE=eth0 HWADDR=00:25:90:D8:64:1E TYPE=Ethernet UUID=71a7fc85-7d24-4ef8-beb7-3f2bf52221e9 ONBOOT=yes NM_CONTROLLED=yes BOOTPROTO=none BRIDGE=br0 на гостевой (убунта) cat /etc/network/interfaces # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet manual auto vlan500 iface vlan500 inet static address 172.18.0.232 netmask 255.255.255.0 vlan-raw_device eth0 auto vlan99 iface vlan99 inet static address 1.9.7.5 netmask 255.255.255.240 vlan-raw_device eth0 gateway 1.9.7.1 dns-nameservers 8.8.8.8 auto vlan900 iface vlan900 inet static address 172.21.0.4 netmask 255.255.255.0 vlan-raw_device eth0 Изменено 18 июня, 2014 пользователем Tem Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 18 июня, 2014 · Жалоба А где находится этот параметр, как глянуть? ethtool -k eth0|grep vlan dmesg | grep -i VLAN Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 18 июня, 2014 · Жалоба ethtool -k eth0|grep vlan dmesg | grep -i VLAN ethtool -k eth0|grep vlan rx-vlan-offload: on tx-vlan-offload: on В dmesg вообще ничего нет по теме, только журналирование моих потугов. br1: port 3(vlan1000) entering disabled state vlan1000: no IPv6 routers present device vlan1000 entered promiscuous mode br1: port 3(vlan1000) entering forwarding state device vlan1000 left promiscuous mode br1: port 3(vlan1000) entering disabled state device vlan1000 entered promiscuous mode br1: port 4(vlan1000) entering forwarding state ...etc... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 18 июня, 2014 · Жалоба AlKov, Ну попробуйте отключить offload-ы. Драйвер igb с сайта Intel? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 18 июня, 2014 (изменено) · Жалоба AlKov, Ну попробуйте отключить offload-ы. Драйвер igb с сайта Intel? А проблема, однако... ethtool не даёт на ходу отключать vlan offload-ы. #ethtool -K eth1 rxvlan off Could not change any device features По-видимому, только при загрузке можно, но ребут хост машины в ближайшем обозримом невозможен.. :( Драйвер igb, но вот откуда, уже не помню. Скорее всего ядерный (2.6.32-358.6.2.el6.x86_64). P.S. А не может быть проблема из-за того, что на бридже, в который я пытаюсь "пристроить" vlan, назначен IP? Изменено 18 июня, 2014 пользователем AlKov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 18 июня, 2014 · Жалоба P.S. А не может быть проблема из-за того, что на бридже, в который я пытаюсь "пристроить" vlan, назначен IP? Не. По теме - хрен его знает. :) Попробуйте запустить на интерфейсе tcpdump - посмотрите, ловит ли он тегированный трафик. Ещё может оказаться, что при запущенном tcpdump бридж вдруг станет всё пропускать :). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 18 июня, 2014 · Жалоба На хост-машине - vconfig add br0 1000 vconfig add br1 2000 ifconfig vlan1000 up ifconfig vlan2000 up А физические интерфейсы хост-машины к бриджу то приписаны? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 18 июня, 2014 · Жалоба А физические интерфейсы хост-машины к бриджу то приписаны? Естественно. Не до такой уж степени я отупел! :) # brctl show br1 bridge name bridge id STP enabled interfaces br1 8000.001e671f757d no eth1 vnet1 Вообще, чертовщина какая-то творится с vlan-ами на виртуализации.. Попробовал на другой гостевой машине с FreeBSD, подключенной к этому же бриджу хостовой, перевести её интерфейс в тегированный vlan. Получил наистраннейший результат - трафик ходит только тогда, когда хост машина подключена к НЕтегированному интерфейсу коммутатора.. Стоит перевести порт коммутатора в тегированный vlan (что логично), трафик исчезает. Удалил vlan интерфейс (на FreeBSD), назначил IP на "обычный" интерфейс (re1) - трафик снова заходил. Получается, что на бридже vlan id от "хоста" проходит, а от "гостя" сбрасывается.. Или наоборот?? Вообщем, крыша потихоньку съезжает.. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 19 июня, 2014 · Жалоба Нагуглил на каком-то буржуйском форуме следующее - ...Bridging tagged packets works only since 2.6.37, or if you have a network card which does not have hardware support for 802.1Q. А у меня 2.6.32. Может в этом всё и дело? Abram, у Вас какая версия ядра? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 19 июня, 2014 · Жалоба AlKov, Во, вполне может быть. У меня 3.13. Intel 80003ES2LAN, e1000e. rx-vlan-offload: on tx-vlan-offload: on rx-vlan-filter: on [fixed] vlan-challenged: off [fixed] tx-vlan-stag-hw-insert: off [fixed] rx-vlan-stag-hw-parse: off [fixed] rx-vlan-stag-filter: off [fixed] Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 19 июня, 2014 · Жалоба Плохо.. Очень плохо, если проблема в ядре.. :( Обновить ооочень проблематично. А есть другие варианты? Имеется ввиду без бриджей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 19 июня, 2014 · Жалоба А есть другие варианты? Имеется ввиду без бриджей. Разве что сетевую карту полностью пробросить внутрь как PCI-устройство. Но там очень много условий. Ядро обновить будет проще. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 19 июня, 2014 · Жалоба Ядро обновить будет проще. Ой-ли? На CentOS ванильное ядро? Есть очень много шансов поиметь гемор в чём-нибудь другом.. Проще наверное будет организовать "железный" рутер, не на виртуалке, а на каком-нибудь недорогом железе. Благо место в стойке еще позволяет это сделать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 19 июня, 2014 · Жалоба Ой-ли? На CentOS ванильное ядро? Я эти ваши центоси не знаю, но разве нет репозиториев со всякими бекпортами, или как там у вас принято? elrepo какие-то. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 19 июня, 2014 · Жалоба Ой-ли? На CentOS ванильное ядро? Я эти ваши центоси не знаю, но разве нет репозиториев со всякими бекпортами, или как там у вас принято? elrepo какие-то. Есть, но там всё то же 6.32 ============================================================================================================================================================= Package Arch Version Repository Size ============================================================================================================================================================= Installing: kernel x86_64 2.6.32-431.17.1.el6 updates 28 M Updating: bfa-firmware noarch 3.2.21.1-2.el6 base 2.6 M Updating for dependencies: kernel-firmware noarch 2.6.32-431.17.1.el6 updates 13 M Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tem Опубликовано 19 июня, 2014 · Жалоба А не пробовали в гостевом центосе на влане сделать сначала ifdown, а потом ifup ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 19 июня, 2014 · Жалоба А не пробовали в гостевом центосе на влане сделать сначала ifdown, а потом ifup ? Какой смысл? Гостевую машину после манипуляций на хосте, я ребутал. А вот на хосте пробовал поднимать/опускать ВСЕ связанные с "гостем" интерфейсы, включая бридж. Результат нулевой.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tem Опубликовано 20 июня, 2014 · Жалоба А не пробовали в гостевом центосе на влане сделать сначала ifdown, а потом ifup ? Какой смысл? Гостевую машину после манипуляций на хосте, я ребутал. А вот на хосте пробовал поднимать/опускать ВСЕ связанные с "гостем" интерфейсы, включая бридж. Результат нулевой.. А вот было такое и как раз на центосе, после ребута трафик не шел, а после ручного down/up начинал. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 20 июня, 2014 · Жалоба В любом случае, понятно, что в данном случае требуемое не осуществимо.. Придётся реализовывать "железный вариант" (не на виртуалке). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 20 июня, 2014 · Жалоба Попробуйте из хост машины вообще удалить всю связнную с vlan конфигурацию. У меня на более древнем ядре бриджинг тегов работает, правда у меня двойное тегирование применяется, выглядит примерно так: 2900 - это s-vlan, он отдается с порта коммутатора как обычный тегированный влан(switchport trunk allowed vlan add 2900). C-vlan'ы упаковываются в s-vlan еще на вышестоящем оборудовании. На хост машине есть бридж куда приписан тегированный интерфейс с s-vlan'ом и интерфейс гостевой машины [root@host-node ~]# brctl show bridge name bridge id STP enabled interfaces br1 8000.003048d671d9 no vif1.1 eth1.2900 На хост-машине никакой конфигурации связанной с клиентскими c-vlan'ами вланами нет, она о них ничего не знает. На гостевой машине c-vlan'ы добавляются vconfig'ом и про s-vlan гостевая машина ничего не знает. При такой настройке пакеты ушедшие с порта коммутатора с двойным тегом успешно прилетают в гостевую ОС с единичным тегом и наоборот. Еще как вариант, если очень не хочется использовать стороннее железное решение, то можно под каждый влан делать бридж, в который включать тегированный интерфейс в хост-машине и _отдельный_ физический интерфейс в гостевой машине. Минус в том, что при добавлении вланов придется перезапускать виртуалку(если конечно в kvm нельзя на горячую интерфейсы добавлять) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 20 июня, 2014 · Жалоба Попробуйте из хост машины вообще удалить всю связнную с vlan конфигурацию. Именно с этого я и начинал, результат - выше.. У меня на более древнем ядре бриджинг тегов работает, правда у меня двойное тегирование применяется, Возможно именно поэтому и работает, т.к. в результате многочасового секса с сабж, было выяснено, что бридж "снимает" метку тега с пакета. Но походу только одну (в вашем случае). Как вариант, можно конечно попробовать поизвращаться с Q-in-Q, учитывая то, что мне необходимо протащить на гостя в перспективе до 50-70 vlan. Еще как вариант, если очень не хочется использовать стороннее железное решение, то можно под каждый влан делать бридж, в который включать тегированный интерфейс в хост-машине и _отдельный_ физический интерфейс в гостевой машине. Минус в том, что при добавлении вланов придется перезапускать виртуалку(если конечно в kvm нельзя на горячую интерфейсы добавлять) Учитывая требуемое кол-во vlan, уж очень коряво и геморно получается.. Но попробовать на будущее надо. :) P.S. Вообще-то вопрос с "железным вариантом" уже практически решен в его пользу, но обе предложенные идеи заинтересовали, особенно вариант с Q-in-Q. Обязательно попробую реализовать. А вдруг когда-то и пригодится? ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...