The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"OpenvSwitch не работет vxlan"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Др. сетевые сервисы / Linux)
Изначальное сообщение [ Отслеживать ]

"OpenvSwitch не работет vxlan"  +/
Сообщение от sesan7 (ok), 30-Ноя-20, 14:06 
Добрый день всем!
Тестовая лаборатория: Всё представленные здесь машины являются виртуальными и подняты в двух средах VMware Sphera ( то есть PC1 Serv1 это одна VMware Sphera а PC2 Serv2 находятся в другом железном сервере с VMware Spherа).

Есть проблема по работе Openvswitch с vxlan а именно хочу пробросить сеть (L2) с одной локации в другую посредством поднятия на двух локациях по серверу (Server1, Server2) с двумя сетевыми карточками. Одна сетевая карточка у каждого сервера смотрит в WAN другая в LAN (LAN интерфейсы на обоих серверах без IP адресов) ...
Схема такая:
PC1(ip 192.168.21.101)====ens224(без ip) Server1_CentOS8 ens160(ip 192.168.13.19)--------ens160(ip 192.168.13.20) Server2_CentOS8 ens224 (без ip)===== LAN (192.168.21.0/24)  PC2(ip 192.168.21.100)
PC1 и PC2 тестовые машины с которых я пытаюсь пинговать (с PC1 PC2 и наоборот)

Настраиваю Openvswitch vxlan
on Server1 config:
ovs-vsctl add-br bridge22
ovs-vsctl add-port bridge22 vxlan22 -- set interface vxlan22 type=vxlan options:key=22 options:remote_ip=192.168.13.20 options:local_ip=192.168.13.19
ovs-vsctl add-port bridge22 ens224

on Server2 config:
ovs-vsctl add-br bridge22
ovs-vsctl add-port bridge22 vxlan22 -- set interface vxlan22 type=vxlan options:key=22 options:remote_ip=192.168.13.19 options:local_ip=192.168.13.20
ovs-vsctl add-port bridge22 ens224

ovs-vsctl show on Server1
fb64004b-a3b0-4271-b1d8-0e26d099645d
    Bridge "bridge22"
        Port "vxlan22"
            Interface "vxlan22"
                type: vxlan
                options: {key="22", remote_ip="192.168.13.20", local_ip="192.168.13.19"}
        Port "ens224"
            Interface "ens224"
        Port "bridge22"
            Interface "bridge22"
                type: internal

ovs-vsctl show   on Server2
627d17c5-aa79-4dea-8dff-4e93914c3b29
    Bridge "bridge22"
        Port "vxlan22"
            Interface "vxlan22"
                type: vxlan
                options: {key="22", remote_ip="192.168.13.19", remote_ip="192.168.13.20" }
        Port "ens224"
            Interface "ens224"
        Port "bridge22"
            Interface "bridge22"
                type: internal
То есть я создал bridge22, создал проброс по vxlan c меткой 22, для проброса пакетов в LAN я повесил бридж22 на интерфейс, который смотрит во внутреннюю сеть... Но вот пытаясь пинговать с PC1 PC2 и наоборот у меня ничего не выходит...! Как я уж не пробовал... хотя маки этих компьютеров в таблице на компьютерах появляется (то есть на PC1 есть мас с PC2 и наоборот)
Пробовал развернуть єто всё на Debian та же самая история...
Подскажите где я ошибаюсь?

Делал по мануалу https://brezular.com/2020/05/01/virtual-extensible-lans-vxla...
Заранее спасибо!

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от StreSS.t (ok), 01-Дек-20, 21:41   +/
Варя плохо переваривает linux bridge с установленными утилитами вари
https://communities.vmware.com/t5/ESXi-Discussions/Linux-Bri...
После перевода в режим hub работает, но есть шанс сломать варе мозг
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2

2. Сообщение от sesan7 (ok), 02-Дек-20, 17:44   +/
> Варя плохо переваривает linux bridge с установленными утилитами вари
> https://communities.vmware.com/t5/ESXi-Discussions/Linux-Bri...
> После перевода в режим hub работает, но есть шанс сломать варе мозг

По ссылке была статейка, которая гласит:
In speaking with the linux-bridging mailing list, I understand where the issue lays.

The issue is in VMwares vSwitches- when a vSwitch has more than one pNIC in it, the second pNIC (even if standby in an active/passive fail over) replicates back the arp requests, causing the linux bridge to incorrectly update its mac table.

The recourse is one of a couple things:

    Remove the second pNIC from the vSwitch; of course compromising redundancy.

    Replace the built in vSwitch with a Cisco 1000V (unconfirmed, but assumed to work)

    Replace the Linux bridge with an arp proxy / ip forward.

If any one else has suggestions, I'm all ears. My understanding is vmware has stated no intention on changing this behavor (hearsay from the mailing list).

Hopefully this saves someone else a week of their professional career

Насколько я понял в статье которая указана по ссылке, идёт речь (подразумевается)  о том случае когда Vmware имеет несколько физ.интерфейсов (pNIC) и два из них находятся в одной и той же сети (для отказоустойчивости) и при этом возникают проблемы. У меня (в моём случае) нет такого, на один физ. интерфейс Vmware одна сеть... Может я конечно неправильно понял материал?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #3, #4

3. Сообщение от StreSS.t (ok), 03-Дек-20, 13:28   +/
Даже при одно интерфейсе варя считает себя умной и изучает маки внутри вм, а т.к. они талбицу маков держит у себя то получается что трафик не доходит до интерфейса.
Много раз уже натыкались в разных конфигурациях. Переведите бридж в хаб и проверьте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

4. Сообщение от StreSS.t (ok), 03-Дек-20, 13:29   +/
Ну и таблицу роутинга проверьте что там тоже все верно и что пакет идет по тому пути который вы одидаете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #5

5. Сообщение от sesan7 (ok), 17-Дек-20, 16:32   +/
> Ну и таблицу роутинга проверьте что там тоже все верно и что
> пакет идет по тому пути который вы одидаете.

Уже создал всё это хозяйство на отдельных двух старых железных компах у каждого из которых по две сетевухи... К сожалению тот же результат....
По поводу роутинга... то внешние интерфейсы этих двух серверов (на которых порождается VXLAN, а это Server1 и Server2) находятся в одной сети. И я просто убрал на обоих серверах шлюзы по умолчанию...
То есть пакетикам некуда тут деться (в том смысле что они не валят хрен знает куда)... Да я и вижу(tcpdump) что на внешние интерфейсы приходят пакетики завернутые в VXLAN то есть всё идёт куда надо.  на бридж эти пакетики попадают  а вот назад не возвращаются...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #6

6. Сообщение от sesan7 (ok), 17-Дек-20, 18:16   +/
>[оверквотинг удален]
> Уже создал всё это хозяйство на отдельных двух старых железных компах у
> каждого из которых по две сетевухи... К сожалению тот же результат....
> По поводу роутинга... то внешние интерфейсы этих двух серверов (на которых порождается
> VXLAN, а это Server1 и Server2) находятся в одной сети. И
> я просто убрал на обоих серверах шлюзы по умолчанию...
> То есть пакетикам некуда тут деться (в том смысле что они не
> валят хрен знает куда)... Да я и вижу(tcpdump) что на внешние
> интерфейсы приходят пакетики завернутые в VXLAN то есть всё идёт куда
> надо.  на бридж эти пакетики попадают  а вот назад
> не возвращаются...

Уточнение!!!
Пакетики возвращаются на внешний интерфейс сервера с которого они (пакетики) были отправлены, но именно на бридж с которого они изначально исходили нет...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #7

7. Сообщение от sesan7 (ok), 18-Дек-20, 18:01   +/
Всё заработало!!!
Сначала на отдельных железных серверах (без Vmware) - тут было всё банально... Надо было отключить файервол в гостевых операционных системах (на Server1 и Server2). И сразу всё заработало!

Отсюда сразу пали подозрения на Vmware (как и сказал StreSS.t )

Включил на виртуальных свичах Vmwarы к которым подключены сетевые интерфейсы Server1 и Server2 режим promiscuous mode (согласно документации  https://kb.vmware.com/s/article/1004099) и всё заработало!

Огромное спасибо StreSS.t за помощь!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру