Как пробросить vlan к роутеру на гостевой ОС KVM

[AlKov]

Дано: 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

Интерфейсы все поднимаются, но трафик не ходит.

Перелопатил тонны гугля - результата нет... :(

[Danila]

Если память не изменяет делается немного по другому.

На хост машине создаете vlan'ы. Добавляете их в бридж.

И дальше уже эти бриджы добавляете в кач-ве интерфейсов в гостевую ОС.

В итоге на хост машине получится портянка интерфейсов аля vlan и br, а в госте будет портянка eth интерфейсов.

Поправьте, если ошибся. Но других способов я пока не нашел. :)

Edited June 17, 2014 by Danila

[Abram]

Хм.

Я всегда поднимал VLAN-ы тупо внутри виртуальной машины, Linux bridge у меня пропускает тегированный трафик.

А на сетевой карте часом не включен hw vlan filter?

[AlKov]

Если память не изменяет делается немного по другому.

На хост машине создаете vlan'ы. Добавляете их в бридж.

И дальше уже эти бриджы добавляете в кач-ве интерфейсов в гостевую ОС.

Да вроде и так уже делал. Чего только и не пробовал от безысходности, уже забыл что.

Проверил еще раз. Результат аналогичный.

Кстати, обнаружил такую штуку - назначил IP vlan интерфейсу на хост-машине для проверки.

Так вот - стОит добавить интерфейс vlan в бридж, трафик перестаёт ходить до хост-машины.

Ну и также не ходит и в гостевую.

 

Я всегда поднимал VLAN-ы тупо внутри виртуальной машины, Linux bridge у меня пропускает тегированный трафик.

Тоже так считал до недавнего времени. Ан нет..

А на сетевой карте часом не включен hw vlan filter?

А где находится этот параметр, как глянуть?

Edited June 18, 2014 by AlKov

[Tem]

на хосте (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

Edited June 18, 2014 by Tem

[Abram]

А где находится этот параметр, как глянуть?

ethtool -k eth0|grep vlan
dmesg | grep -i VLAN

[AlKov]

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...

[Abram]

AlKov,

Ну попробуйте отключить offload-ы.

Драйвер igb с сайта Intel?

[AlKov]

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?

Edited June 18, 2014 by AlKov

[Abram]

P.S. А не может быть проблема из-за того, что на бридже, в который я пытаюсь "пристроить" vlan, назначен IP?

Не.

По теме - хрен его знает. :)

Попробуйте запустить на интерфейсе tcpdump - посмотрите, ловит ли он тегированный трафик. Ещё может оказаться, что при запущенном tcpdump бридж вдруг станет всё пропускать :).

[agr]

На хост-машине -

 

vconfig add br0 1000

vconfig add br1 2000

ifconfig vlan1000 up

ifconfig vlan2000 up

А физические интерфейсы хост-машины к бриджу то приписаны?

[AlKov]

А физические интерфейсы хост-машины к бриджу то приписаны?

Естественно. Не до такой уж степени я отупел! :)

# 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 от "хоста" проходит, а от "гостя" сбрасывается.. Или наоборот??

Вообщем, крыша потихоньку съезжает.. :)

[AlKov]

Нагуглил на каком-то буржуйском форуме следующее -

...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, у Вас какая версия ядра?

[Abram]

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]

[AlKov]

Плохо.. Очень плохо, если проблема в ядре.. :(

Обновить ооочень проблематично.

А есть другие варианты? Имеется ввиду без бриджей.

[Abram]

А есть другие варианты? Имеется ввиду без бриджей.

Разве что сетевую карту полностью пробросить внутрь как PCI-устройство. Но там очень много условий. Ядро обновить будет проще.

[AlKov]

Ядро обновить будет проще.

Ой-ли? На CentOS ванильное ядро? Есть очень много шансов поиметь гемор в чём-нибудь другом..

Проще наверное будет организовать "железный" рутер, не на виртуалке, а на каком-нибудь недорогом железе.

Благо место в стойке еще позволяет это сделать.

[Abram]

Ой-ли? На CentOS ванильное ядро?

Я эти ваши центоси не знаю, но разве нет репозиториев со всякими бекпортами, или как там у вас принято? elrepo какие-то.

[AlKov]

Ой-ли? На 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

[Tem]

А не пробовали в гостевом центосе на влане сделать сначала ifdown, а потом ifup ?

[AlKov]

А не пробовали в гостевом центосе на влане сделать сначала ifdown, а потом ifup ?

Какой смысл? Гостевую машину после манипуляций на хосте, я ребутал.

А вот на хосте пробовал поднимать/опускать ВСЕ связанные с "гостем" интерфейсы, включая бридж.

Результат нулевой..

[Tem]

А не пробовали в гостевом центосе на влане сделать сначала ifdown, а потом ifup ?

Какой смысл? Гостевую машину после манипуляций на хосте, я ребутал.

А вот на хосте пробовал поднимать/опускать ВСЕ связанные с "гостем" интерфейсы, включая бридж.

Результат нулевой..

А вот было такое и как раз на центосе, после ребута трафик не шел, а после ручного down/up начинал.

[AlKov]

В любом случае, понятно, что в данном случае требуемое не осуществимо..

Придётся реализовывать "железный вариант" (не на виртуалке).

[agr]

Попробуйте из хост машины вообще удалить всю связнную с 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 нельзя на горячую интерфейсы добавлять)

[AlKov]

Попробуйте из хост машины вообще удалить всю связнную с vlan конфигурацию.

Именно с этого я и начинал, результат - выше..

У меня на более древнем ядре бриджинг тегов работает, правда у меня двойное тегирование применяется,

Возможно именно поэтому и работает, т.к. в результате многочасового секса с сабж, было выяснено, что бридж "снимает" метку тега с пакета. Но походу только одну (в вашем случае).

Как вариант, можно конечно попробовать поизвращаться с Q-in-Q, учитывая то, что мне необходимо протащить на гостя в перспективе до 50-70 vlan.

Еще как вариант, если очень не хочется использовать стороннее железное решение, то можно под каждый влан делать бридж, в который включать тегированный интерфейс в хост-машине и _отдельный_ физический интерфейс в гостевой машине. Минус в том, что при добавлении вланов придется перезапускать виртуалку(если конечно в kvm нельзя на горячую интерфейсы добавлять)

Учитывая требуемое кол-во vlan, уж очень коряво и геморно получается..

Но попробовать на будущее надо. :)

 

P.S. Вообще-то вопрос с "железным вариантом" уже практически решен в его пользу, но обе предложенные идеи заинтересовали, особенно вариант с Q-in-Q.

Обязательно попробую реализовать. А вдруг когда-то и пригодится? ;)