Господа, есть кто сведующий в xen (xapi, xcp1.1, если важно), openvswitch и проброске таггированного трафика внутрь виртуалок?

Если коротко, на 1 сервере всё работает, на 2 — нет. Настройки на циске, на dom0 и domU одинаковые. Интересно, где ещё рыть и в чём может быть беда (специфичные баги для openvswitch, например).

Tagged with →  

25 Responses to Вопрос по xen (xapi, xcp1.1) и openvswitch

  1. Avhenko:

    Два сервера с xcp1.1. Есть vlan, во влане 192.168 на 2х интерфейсах, для контрольных доменов созданы vif и приаттачены, пингуют друг друга успешно.

    37: [email protected]: mtu 1500 qdisc noqueue
    link/ether 46:62:87:71:d8:6c brd ff:ff:ff:ff:ff:ff
    inet 192.168.32.7/20 brd 192.168.47.255 scope global vlan42

    16: [email protected]: mtu 1500 qdisc noqueue
    link/ether 6e:25:f0:2e:59:fa brd ff:ff:ff:ff:ff:ff
    inet 192.168.32.14/20 brd 192.168.47.255 scope global vlan42

    На обоих серверах для виртуальных машин на 2 интерфейсе так же созданы vif и внутри самих машин на интерфейсах добавлен vlan 42. На 1 сервере проблем нет, на другом получаю что-то непонятное: tcpdump пакеты входящие видит, на arp-запросы шлёт ответы, на порту свитча все маки видно, но icmp/tcp/etc остаются безответны.

  2. SnuMilk:

    петля может где. или STP не настроено. vlan 42 на свичте в тэге?

  3. Avhenko:

    да, маки на свитче появляются с 42 вланом и всё ок. Как проверить петлю? И мне казалось, что STP — немного не то, пойду читать.

  4. NuSbad:

    ну так если tcpdump видит входящие пакеты — значит дело в iptablesroute — уже неважно что там у тебя снаружи.

  5. Avhenko:

    iptables -F не спасает, iptables на control domain и сбрасывал и выставлял одинаковые. Я грешу на openvswitch, если честно, но не знаю, куда его копать. sysctl.conf одинаков. Изначально мой xenbr1 для 2 интерфейса вел себя очень странно, пакеты шли на ip, который на нем поднят, но шли через eth0, а не eth1, на циске же даже порт не светился. Поборол, теперь дальнейшие страдания.

  6. Roded:

    ip route show; ip rule show

  7. KsiWin7:

    На хосте:
    # brctl show

    В гостях:
    # ifconfig -a
    # ls /proc/net/vlan

  8. Roded:

    ifconfig? Может лучше ip addr show?

  9. KsiWin7:

    разница-то какая для данного случая? Нет, ты, конечно, прав, что надо переучиваться, тем более что с маршрутами все равно через ip приходится возиться.

  10. Roded:

    ifconfig не покажет, если на одном интерфейсе навешано более одного ip-адреса.

  11. KsiWin7:

    Слушай, ну вот вроде it блог. Вроде разумные все, с естественно-научным складом ума. Вот объясни мне, почему все равно читают не тот вопрос, который задан? Вот я тебя спрашиваю «разница-то для данного случая?». Если разница есть — я с удовольствием послушаю какая (насколько я вижу у него проблемы с VLAN’ами, а не с адресацией), а если нет — ну вот нахуя вот это все?

  12. Roded:

    Для данного конкретного — небольшая. Но можно же немного пофлудить, пока автор поста не отвечает?

  13. KsiWin7:

    Добро. Хотя автор поста излагает все несколько непонятно. Я такое раза 3-4 делал и вроде там ничего сложного. Кстати я совсем не понимаю зачем ему навешивать вланы внутри гостей. Я делал бриджи под каждый влан.

    То есть как-то так (если парсер не сожрет pre — не серчайте):
    Cisco (Gix/y — access 42) — — (eth0.42) — xenbr-vlan42 — (vif1|vif2)

    ИМХО так получше и попроще. Но мнее гибче, да.

  14. Avhenko:

    bridge name bridge id STP enabled interfaces
    xenbr0 0000.00259029e500 no vif1.0
    vif2.0
    eth0
    vif3.0
    vif4.0
    vif5.0
    vif7.0
    vif11.0
    xenbr1 0000.00259029e005 no eth1
    vif7.2
    vif0.2
    vif1.1
    vif2.1
    vif11.1
    vif7.1
    vif3.1
    vif4.1
    vif5.1

    надеюсь, парсер не подвел. Сейчас добавлю тестовый влан и к вечеру отвечу предметно

  15. Avhenko:

    глупо было надеяться http://paste.org.ru/?m6732r так например. В общем, там всё ок.

  16. Avhenko:

    создать влан средствами xapi, а внутри виртуалок ничего не делать?

  17. KsiWin7:

    как-то мутно это все, честное слово. Давай проясним.

    Вот смотри, у тебя 2 бриджа (xenbr(1|2)) и 2 физических интерфейса (eth(0|1)). Они не тагированы и тупо воткнуты в разные бриджи.

    Соответственно у тебя физические интерфейсы воткнуты в циску. Порты на циске, в которые воткнуты интерфейсы, по идее, должны быть транковые. Иначе смысл как-то теряется, потому что access порт будет отрезать таг.

    У тебя физические интерфейсы работают как транки. То есть им пофигу на влан таги и они просто суют кадры в бриджи.

    Я все правильно понимаю?

    Если все правильно — то если у тебя интерфейсы обоих гостей воткнуты в один и тот же бридж — должны пинговаться между собой. Однако за пределы хоста вылетать не должны. Потому что eth0 и eth1, воткнутые в бридж будут передавать только нетагированные кадры.

  18. KsiWin7:

    насчет xapi я не уверен. Мне оно для работы с сетью никогда не нравилось, поэтому я обычно просто руками бриджи поднимал в инитскриптах и распихивал их по вланам.

    Вообщем идея такая (не моя и далеко не новая, но стопудов рабочая): http://renial.net/weblog/2007/02/27/xen-

    То есть у тебя с циски приходит транк. Для allowed VLANs ты создаешь а) бриджи и б) влан-интерфейсы на eth’ах и втыкаешь их в соответствующие бриджи. Ну а дальше пихаешь DomU в тот бридж, в каком влане он должен быть.

    Ну да на картиночке по ссылке все прям так и нарисовано.

  19. KsiWin7:

    А, да, соответственно внутри DomU никакие вланы не нужны. Для DomU у них как бы обычный интерфейс без вланов.

  20. Avhenko:

    eth0 — access, eth1 — trunk, так для всех серверов, всё верно. Так, я идею твою уловил, не уловил правда почему eth1 будет передавать нетаггированный кадр. Точнее умом понять могу, не понимаю, почему на другом сервере такая схема ок работает.

    Доступа на циску нет, продолжу экзекуции завтра и отпишусь. Спасибо.

  21. KsiWin7:

    а можно те же командочки на рабочей машине сделать?

  22. KsiWin7:

    Кстати, у тебя офлоад выключен на интерфейсах в бриджах? Который ethtool -K eth0 tx off

  23. Avhenko:

    завтра, всё будет завтра. Может в жаббер?

  24. Avhenko:

    да, выключил.

  25. KsiWin7:

    Да я не спешу. Лучше скайпом. постнешь тогда.

    Но вообще у меня вот какое есть соображение, что у тебя попросту тагированные кадры никуда не шлются.

    Я тут почитал всякого. Нигде прямого указания не нашел, но по ходу дело происходит так:
    1) из транк-порта свича выходит кадр (тагированный Х)
    2) по проводу или оптике он прилетает в порт сервера (пусть eth0)
    3) если на eth0 нет сабинтерфейса eth0.X — кадр принимается (ну чисто позырить), но дропается

    Теперь если у нас есть бридж в который воткнут eth0. Те же яйца вид сбоку. То есть бридж уже зырит — ага, Х… Ну а я не сконфигурён — ну его нахуй.

    В другую сторону. Когда у тебя из ДомУ прилетает кадр с тагом Х он не может никуда за пределы бриджа вылезти, потому что, как я понимаю eth0 — это untagged порт, а не транк.

    Ну вот как-то так приблизительно.

Добавить комментарий