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

Есть две вм, клиент и сервер: Сервер - mac: 02:8b:12:86:c2:f6, ipv4: 10.11.100.60, ipv6: 2001:470::4, порт на гипервизоре - vnet3 Клиент - mac: 02:b3:0d:4c:11:2a, ipv4: 10.11.100.58, ipv6: 2001:470::5, порт на гипервизоре - vnet2

Есть свод ovs-flow правил, для краткости, проблемные правила такие:

ovs-ofctl add-flow ovs-br «cookie=0xa, table=0, priority=1999, dl_dst=02:8b:12:86:c2:f6, tcp action=normal»

ovs-ofctl add-flow ovs-br «cookie=0xa, table=0, priority=1999, dl_src=02:8b:12:86:c2:f6, action=normal»

Следовательно, мы разрешаем весь tcp трафик с dst mac 02:8b:12:86:c2:f6, и все src соединения с 02:8b:12:86:c2:f6.

Перед каждым тестом удалялся arp и nd кеши. Теперь мы подключаемся по ssh к серверу, по ipv4 коннект идет. НО! При подключении к серверу через ipv6 коннект не проходит, при этом icmp6 na и ns ходят между клиентом и сервером, но вот tcp - нет, скрины tcpdump: ipv6: Клиент https://imgur.com/a/1GbYrCb Сервер https://imgur.com/a/hv0FLIo ipv4: Клиент https://imgur.com/a/hv0FLIo Сервер https://imgur.com/a/3CjqXGF Если в первом проблемном правиле убрать уточнение tcp, и пропускать вообще весь трафик, коннект идет успешно, у клиента и сервера успешно появляется запись в arp или nd друг о друге. Если разрешать коннекты не по dst mac, а по ipv6_dst, коннект так же работает. Все правила ovs на гипервизоре: https://imgur.com/a/TFF5Pa3

ovs-appctl ofproto/trace: https://imgur.com/a/KcgORXr

Со мной что-то не так, или это действительно баг? Версия ovs 3.1.0, пакет из офф репы debian 12. Надеюсь обьяснил :/

В качестве маршрутизатора используется коммутатор brocade icx6610, как в ipv4, так и в ipv6, на ipv4 все работает, но в ipv6 при пинговке любого хоста падает ошибка

Time exceeded: Hop limit

НО! mtr трассирует до этого же хоста(как и до любых других) - без каких либо проблем, без loop маршрутов, и тому подобного. Посмотрел трафик через tcpdump, и отлично получаю обратный трафик с пингуемого ip с hlim 62, но между тем так же получаю трафик подобного содержания:

(hlim 255, next-header ICMPv6 (58) payload length: 72) <ip адрес коммутатора> > <ip pc>: [icmp6 sum ok] ICMP6, time exceeded in-transit for <пингуемый хост>

Или есть еще такие сообщения:

(hlim 63, next-header ICMPv6 (58) payload length: 72) <ip адрес коммутатора со стороны дальшестоящего шлюза> > <ip pc> [icmp6 sum ok] ICMP6, time exceeded in-transit for <пингуемый хост>

Причем явных причин такого поведения в конфигурации коммутатора я не нашел. Конфигурация интерфейсов - ve 201 интерфейс с маршрутизатором, ve 800 - проблемный интерфейс(есть acl, но он не влияет, уже отключал) - https://habrastorage.org/webt/66/71/a6/6671a6d359738591673766.png

Конфигурация ipv6 - https://habrastorage.org/webt/66/71/a7/6671a709c1023051954019.png Может быть у кого-нибудь есть идеи в чем проблема?

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

Есть гипервизор, на нем ovs мост, ответная часть интерфейсов vm подключена в мост, и накинут vlan tag, все работает, вот только беда, vm с одним и тем же тегом имеют L2 доступ друг к другу, хотелось бы это избежать. Пришел к идеи использовать ovs flows, и вроде как оно работает, но сложность в том, что правила афектят все vlan в мосту, при использовании опции dl_vlan= в правилах, правила не работают, так как, как я понял, они подразумевают фильтрацию трафика с тегом, а в данном случае это нативный трафик, который только на выходе с ovs обладает тегом. Вызов ovs-appctl ofproto/trace ovs-br "dl_vlan=800, ip, nw_src=10.2.0.0, in_port=10", где dl_vlan - тег для фильтрации, in_port - id интерфейса vm с tag=800 на скрине - https://imgur.com/a/syeYGTW

Собственно вопрос, как убрать доступность вм в одном теге для других вм, соединения за мостом рубит коммутатор с ip acl, нужно разобраться с vm на одном гипере. Возможно для этого можно использовать какой-то другой функционал ovs. Знаю, что можно фильтровать соединения в linux bridge через iptables, но переезд на него не самый желательный итог.

Если что, хост на debian12, виртуалки в libvirt

Имеется коммутатор arista 7050qx-32s, на eos, имеется переходник com to usb «Prolific Technology, Inc. PL2303 Serial Port / Mobile Action MA-8910P» из lsusb. Первое время все работало, но после перезагрузки коммутатора без встроенного usb-dom, serial консоль поломалась, сейчас, если подключится к /dev/ttyUSB0 через screen, с указанием бодов 38400, картина такая: https://imgur.com/a/Ox3g5zE (левая консоль - ssh консоль коммутатора, правая - хоста, к которому подключен переходник)

Пробовал сбрасывать настройки через отключения батарейки в коммутаторе, повторно грузится без usb-dom, пробовал перебирать бод рейт с этими значениями - 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, результата нечего не принесло. Как это дело еще можно траблшутить, и что с этим делать. COM нужен, так как дальше данный коммутатор будут ждать эксперементы c SONiC.

(Не совсем относится к тематики форума, но EOS - по сути линукс:)

Занимаюсь миграцией домашнего zabbix с локальный бд, находящейся на одном хосте с zabbix сервером, на отдельный бд сервер. Инсталяция на psql. Делаю дамп бд вместе с ролями через pg_dumpall, импортирую на новый сервер, все хорошо, все живы, все работают, кроме одного - обновления данных в zabbix, то есть старые данные доступны, но новых нет, при этом если руками подключится к psql с zabbix сервера, естественно с использованием zabbix пользователя, и его пароля, все работает, вызовы select, insert, update, в лог zabbix сыпится ошибка вида:

49573:20240516:034916.555 error reason for "chuk-prom:vfs.dev.util[node_exporter,"sde"]" changed: Cannot perform request: Connection timed out after 3000 milliseconds

В чем может быть проблема? При этом, если вернуть в конфиге сервера обратно локальную бд, все работает(очевидно, но все же).

На досуге занимаюсь изучением NVMEoF, и сейчас споткнулся об ошибку «nvmet_rdma: address family 255 not supported» при добавление subsystem к порту через nvmetcli, выражается это так: При вызове команды create <nqn name> nvmetcli пишет ошибку следующего характера: Could not symlink q in configFS: [Errno 22] Invalid argument: '/sys/kernel/config/nvmet/subsystems/q' -> '/sys/kernel/config/nvmet/ports/3/subsystems/q'

В dmesg в этот момент ошибка nvmet_rdma: address family 255 not supported

Сам nvmetcli выглядит так: (скрин) - https://habrastorage.org/webt/66/3f/23/663f231ae5639863609212.png

При этом, при тупом копировании действий из мануала RHEL - все работает. В чем может быть проблема? Хост на CentOS9, ядро 5.14.0-444.el9.x86_64, накопитель INTEL SSDPF2KX038TZ, модуль nvmet_rdma загружен.

В общем, дома использую shared lun на схд, на луне lvm, и в случае debian-like дистрибутивов все работает без проблем, но вот при подключении того же луна, но к серверам на centos 9, pvs в тупую не видит их, при этом если использовать pvck <блочное устройство> получаю ошибку device is not in devices file., при этом атрибуты selinux совпадают с локальным блочным устройством, на котором так же установлен lvm, проблема точно не в filter, почему еще centos не может увидеть lvm партишен в блочном устройстве? При этом, если собственноручно создать lvm на shared луне, то хост его увидет без каких либо проблем, но если попытаться посмотреть данный лун с другого centos хоста, такая же беда. Почему centos не может увидеть pv?

В общем. Чтобы разобратся с ib, я собрал на домашнем тестовом стенде infiniband среду с коммутатором is5022, и двумя карточками CX2, настроил ipoib, NFSoRDMA, все прекрасно, все работает. Но беда с iser, при добавление iser портала в tgt targetcli выдает ошибку:

Cannot change iser

При этом в dmesg сыпится ошибка

isert: isert_setup_id: rdma_bind_addr() failed: -99

Ясно дело, модуль isert загружен, хост на debian 12, ядро - 6.1.0-18-amd64. При этом такой ошибки небыло при включении NFSoRDMA В чем может быть проблема? Я нашел описание такой же проблемы на форуме sth но там за полгода так и не ответили : /

Я, юный и отважный, для того, чтобы разобратся с infiniband купил 4 карточки mellanox connect x-2 MHQH29B-XSR (PN: 375-3696-01) и коммутатор mellanox is5022 на 8 портов QDR, соединил qsfp28 dac кабелями. Пролема такова: При ibping другого хоста, подключенного к тому же коммутатору, получаю ошибкy

ibwarn: [16744] sa_rpc_call: only lid routes are supported
ibwarn: [16744] ib_path_query_via: sa call path_query failed
ibping: iberror: failed: can't resolve destination port 0x0021280001a124ac (с guid 0x0021280001a135f4 такая же ошибка)

При этом ibhosts на другом хосте выдает следующее:

Ca      : 0x0021280001a135f4 ports 2 "MT25408 ConnectX Mellanox Technologies"
Ca      : 0x0021280001a124ac ports 2 "MT25408 ConnectX Mellanox Technologies"

iblinkinfo выдает это:

CA: MT25408 ConnectX Mellanox Technologies:
      0x0021280001a124ad      0    1[  ] ==( 4X          10.0 Gbps Initialize/  LinkUp)==>       0    1[  ] "Infiniscale-IV Mellanox Technologies" ( )
Switch: 0x0002c902004c98b8 Infiniscale-IV Mellanox Technologies:
           0    1[  ] ==( 4X          10.0 Gbps Initialize/  LinkUp)==>       0    1[  ] "MT25408 ConnectX Mellanox Technologies" ( )
           0    2[  ] ==(                Down/ Polling)==>             [  ] "" ( )
           0    3[  ] ==( 4X          10.0 Gbps Initialize/  LinkUp)==>       0    1[  ] "MT25408 ConnectX Mellanox Technologies" ( )
           0    4[  ] ==(                Down/ Polling)==>             [  ] "" ( )
           0    5[  ] ==(                Down/ Polling)==>             [  ] "" ( )
           0    6[  ] ==(                Down/ Polling)==>             [  ] "" ( )
           0    7[  ] ==(                Down/ Polling)==>             [  ] "" ( )
           0    8[  ] ==(                Down/ Polling)==>             [  ] "" ( )
CA: MT25408 ConnectX Mellanox Technologies:
      0x0021280001a135f5      0    1[  ] ==( 4X          10.0 Gbps Initialize/  LinkUp)==>       0    3[  ] "Infiniscale-IV Mellanox Technologies" ( )

Хосты на debian 12, на карты залита fw-ConnectX2-rel-2_9_1000-MHQH29B-XSR_A1.bin

Что я делаю не так?

Собственно, занимаюсь сборкой собственного iso образа, по инструкции https://habr.com/ru/articles/709528/ благополучно собрал образ с хранением рута файловой системы в initrd, все бы вроде нечего, но во первых, довольно долгая загрузка столь массивного initrd утомляет, во вторых, интересно узнать, как взрослые мальчики типо archlinux или debian пакуют свой root в squashfs образ, а точнее, как с него загружаются. В интернете я не нашел толковых инструкций по сборки своего iso с squashfs, есть ли у кого какие идеи или ссылки на примете?

Есть debian маршрутизатор, на нем мост из 50 vlan тегов, если мы возьмем и поставим один из этих vlan тегов на мост в pve в конфигурации виртуальной машины, то лосс до виртуалки будет >90%, соседство обнаруживается, мы можем пинговать виртуалку, но из 55 пакетов 50 потеряется(условно). При этом, если vlan убрать из конфигураций vm в pve, и создать интерфейс с этим же тегом в самой виртуалке - все работает прекрасно. В чем может быть проблема? У меня разве что были идеи на счет проблем с mtu, но уменьшение mtu до 1400 внутри vm нечего не дало. При этом, если пинговать одновременно из виртуалки маршрутизатор, и с маршрутизатора виртуаку - проблем нет.

Есть debian, на нем сделан мост из 50-ти vlan, он и выполнят роль маршрутизатора, через vlan гоняется трафик виртуалок, виртуалки нормально пингуют интернет и маршрутизатор, но не могут пинговать другие виртуалки, при это iptables этот трафик не блокирует, если посмотреть tcpdump, то мы видем arp реквесты от одной виртуалки другой, и arp ответы виртуалки, вот только их не получает конечная виртуалка. Все виртуалки в одном L3 домене.

( читать дальше... )

Проблема такова - есть debian 12, есть в нем мост, один интерфейс, и 50 vlan интерфейсов, если закинуть 50 vlan в мост, и включить мост, в dmesg начинает сыпатся ошибки подобны этой -

br-servers: received packet on ens18.900 with own address as source address (addr:b6:31:cb:6f:93:db, vlan:0)

При этом mac b6:31:cb:6f:93:db используется только на этом мосте(я пробовал его менять, все равно петля), пробовал включать/выключать stp на мосту - бестолку, пробовал устанавливать уникальные mac на каждый vlan интерфейс - то же бесполезно. Скрипт, через который я создаю мост -

vlanidstart=900
vlanidend=950
vlan=$vlanidstart
ip l s up ens18
brctl addbr br-servers
brctl stp br-servers on
addvlans () {
        if ! [[ $vlan > $vlanidend ]]; then
                ip l a l ens18 name ens18.$vlan type vlan id $vlan
                ip l s ens18.$vlan master br-servers
                ip l s up ens18.$vlan
                vlan=$((vlan+1))
                addvlans
        fi
}
addvlans

Должен отметить, все дело происходит в виртуалке на pve, и порт ens18 добавлен в бридж с raw интерфейсом на самом хосте, хождение vlan по мосту на хосту разрешено.

Что я делаю не так?

В общем, есть openvpn сервер, хочу прописать через клиента определенный маршрут, например 192.168.0.0/24, прописка на сервере ip r a 192.168.0.0/24 via ip client не работает, гугл тоже нечего толкового не дает, спрашивал на qna.habr.com, тоже никто не ответил. Я дурак, или эту темой никто не интересовался? Как можно это сделать?

В общем, раньше стоял pfsense на физической машине, все работало прекрасно, потом решил перекатиться на виртуальную машину, настроил - ipv4 работает корректно, но вот с ipv6 началась какая-то беда, траффик гонялся между двумя локальными хостами и упирался в 30 прышков, при этом это было только, если оставить статический ipv6 устройства, если ip был получен через SLAAC, то проблем нет. Методом проб и ошибок до меня дошло, что траффик гониться между двумя машинами, где стоит докер, и мост с ipv6 для контейнеров. Как я понимаю, проблема состоит в том, что хосты из локальной сети подключаются к этому мосту, из-за того что ip - fe80::1 этого моста доступен каждому хосту в локалке. А теперь собственно вопрос - как запретить доступ к этому мосту из локальной сети. Вариант отключения ipv6 моста докера не принимается. Ну и доп вопрос - почему это произошло только после смены mac маршрутизатора?