LINUX.ORG.RU
решено ФорумAdmin

Openvswitch

 ,


0

1

Добрый день всем! Есть проблема по работе 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

То есть я создал бридж 22, создал проброс по vxlan c меткой 22, для проброса пакетов в LAN я повесил бридж22 на интерфейс, который смотрит во внутреннюю сеть... Но вот пытаясь пинговать с PC1 PC2 и наоборот у меня ничего не выходит...! Как я уж не пробовал... хотя маки этих компьютеров в таблице на компьютерах появляется (то есть на с PC1 есть мас с PC2 и наоборот) Пробовал развернуть на Debian та же самая история... Подскажите где я ошибаюсь?

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



Последнее исправление: sesan7 (всего исправлений: 1)

Подскажите где я ошибаюсь?

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

Интерфейсы ens224 подняты?
В логах ovs-vswitchd есть ошибки?
Почему для проверки внешние компы, а не добавлены в бридж виртуальные интерфейсы vi0?
rp_filter отключен?

mky ★★★★★
()
Ответ на: комментарий от mky

Сорян за формат… Первый раз тут задавал вопрос, по невнимательности вышло … что-то пошло к сожалению не так. Постарался подправить. Поэтому огромное спасибо Вам что обратили внимание на сии каракули… Важное дополнение, которое я забыл упомянуть… Это тестовая лаба собиралась на двух площадках с VMware Sphera 6.0

  1. интерфейсы подняты;
  2. ошибки в логах OVS отсутствуют;
  3. Внешние компы исходя из целей, которые надо достигнуть. А именно: Есть две территориально разнесенных площадки А и В, на каждой по железному серверу на которых VMware Sphera, в этих VMwarах крутятся виртуальные машины. На площадках А и В есть ВМ, которые из одной сети (в тестовой лабе описанной в первом моём сообщении это сеть 192.168.21.0/24). Вот задача состоит в том чтобы ВМ из сети 192.168.21.0/24 площадки А видила (пингала и пр.) ВМ с площадки В из той же 192.168.21.0/24 сети. В конечном итоге это должно позволять миграцию и запуск ВМ с одной площадки на территориально удалённую другую. Вот для этого на каждой площадке создаются ещё по одной ВМ ( а это Serv1 для площадки А и Serv2 для площадки В) с установленным Openvswitch, на эти две ВМ (Serv1 и Serv2) и возлагается роль проброса сети с одной площадки на другую…

Пока только вижу проходит ARP запрос с PC1 на PC2 и наоборот, большего ничего не удаётся добиться IP не ходит…

#sysctl net.ipv4.ip_forward

net.ipv4.ip_forward = 1

#sysctl net.ipv4.conf.all.rp_filter

net.ipv4.conf.all.rp_filter = 0

#sysctl net.ipv4.conf.default.rp_filter

net.ipv4.conf.default.rp_filter = 0

sesan7
() автор топика
Ответ на: комментарий от sesan7

ИМХО, сначала добавть ip-адреса на bridge22 и убедится, что Server1 пингует Server2 через vxlan.

Потом брать ″tcpdump″ и ″ovs-tcpdump″ и смотреть, приходят ли ip-пакеты от PC1 ens224 и уходят дальше.

Ещё можно посмотреть ″ovs-ofctl dump-flows bridge22".

Вот для этого на каждой площадке создаются ещё по одной ВМ

Promiscuous Mode включена?

mky ★★★★★
()
Ответ на: комментарий от mky

Сорян пропал, пришлось переключиться на другой прект.

И так я добавил ip адреса на бриджи… Что сказать… они друг-друга не пингуют… Для примера я пингую с Server1 (с bridge22 ip=192.168.21.102/24) Server2 (с bridge22 ip=192.168.21.103/24)

Если посмотреть tcpdump то видим что пакетики завернутые в VXLAN на внешний интерфейс Server2 приходят, на bridge22 Server2 уже приходят распакованые пакетики с ARP запросом, этот бридж отвечает ARP Reply (правда этот ответ содержит такую шнягу как (oui Unknown)) далее этот ответ идёт на внешний интерфейс Server2 и затем попадает и на внешний интерфейс Server1… Но вот на bridge22 Server1 этот ответ не попадает (я его не вижу в tcpdump) …!

Хотел добавить что вышеописанную лабу я собирал на вирт. машинах (в VMware Sphera ), были подозрения что может это VMware вносит какую-то хрень и поэтому не получается достичь необходимого результата, но собрав всё это на отдельных железных компах получил тот же негативный результат…

sesan7
() автор топика
Ответ на: комментарий от sesan7

и затем попадает и на внешний интерфейс Server1

попадает arp reply или транспортный udp пакет на порт 4789?

mky ★★★★★
()
Ответ на: комментарий от mky

Попадает транспортный udp пакет по 4789 порту с завёрнутым в этот транспортный пакет ARP Reply

(напомню ens160 и 192.168.13.19 - это название и ip адрес внешнего интерфейса Server1)

Server1#tcpdump -vv -i ens160 src 192.168.13.19 and port 4789

03:17:56.205861 IP 192.168.13.19.60451 > Server1.localdomain.vxlan: VXLAN, flags [I] (0x08), vni 0

ARP, Reply 192.168.21.103 is-at 00:0c:29:71:f8:04 (oui Unknown), length 28

В это же время

Server1#tcpdump -vv -i bridge22 src 192.168.21.103

Пусто…

то есть на bridge22 ничего не доходит

sesan7
() автор топика
Ответ на: комментарий от sesan7

Так с бриджами получилось…! То есть бриджи Server1 и Server2 видят друг-друга…

Проблема была в том что на одном из серверов (на Server1) была запущена служба firewalld. я её уже останавливал… но видать при перезагрузке она опять поднялась а я не обратил внимание… Ещё раз её остановил и бриджи увидели друг-друга…

Теперь остаётся проблема что PC1 видит bridge22 на Server1 но не видит bridge22 на Server2 тем более не видит PC2. А решение проблемы видимости этих двух ВМ (PC1 и PC2 друг-друга) и есть моя основная задача (мечта)…

Ищем дальше…

sesan7
() автор топика
Ответ на: комментарий от sesan7

Мда!!! На отдельных железных серваках полностью схема заработала!!

(тоже проблема была в firewalld, который надо было остановить на обоих серверах)

Видать всё таки Vmware мутит воду…

Идём дальше

sesan7
() автор топика
Ответ на: комментарий от sesan7

Видать всё таки Vmware мутит воду

Несомненно. Я вам тут писал про promisc. mode, и на opennet.ru вам про это же написали:

перевода в режим hub работает

vmware сама бридж и знает у какой вируталки какой mac-адрес и пускает к ней только пакеты на этот mac-адрес. И, вроде как, нельзя, чтобы одна виртуака получала все пакеты, только переводить всю «сеть» в Promiscuous Mode, но тогда падает производительность, так виртуалки начинают обрабатывать не нужные им пакеты.

mky ★★★★★
()
Ответ на: комментарий от sesan7

ПРОБЛЕМА РЕШЕНА!!! УРА!

Все проблема была в VMware!

Для успешного решения моей задачи необходимо было включить promiscuous mode на виртуальных свичах VMware (а именно на тех вирт. свичах в которые подключены интерфейсы серверов Server1 и Server2)

Ссылка на документацию: https://kb.vmware.com/s/article/1004099

Выражаю свою искреннюю благодарность MKY за поддержку и желание помочь! Спасибо!

sesan7
() автор топика
Ответ на: комментарий от sesan7

Тогда отметьте тему как решённую (вверху есть такая галочка) и в следующий раз при цитировании логов и конфигов используйте тег [code] (для LORCODE) и обратные апострофы ` (для Markdown).

hobbit ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.