Перейти к содержимому
Калькуляторы

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Изменено пользователем Danila

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Хм.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

 

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

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

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

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

Изменено пользователем AlKov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем Tem

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

AlKov,

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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?

Изменено пользователем AlKov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Не.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

vconfig add br0 1000

vconfig add br1 2000

ifconfig vlan1000 up

ifconfig vlan2000 up

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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]

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.