Давай начнем с:

uname -a
cat /etc/*release

CentOS Linux release 7.8.2003 (Core)

Linux xxx 3.10.0-1127.13.1.el7.x86_64 #1 SMP Tue Jun 23 15:46:38 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Не iptables потому что проверялось все это

Показывай везде где есть мосты(включая основной системный netns) следующее:

iptables -vn -L FORWARD
ip -d link show
sysctl net.bridge.bridge-nf-call-iptables

#iptables -vn -L FORWARD
Chain FORWARD (policy ACCEPT 101M packets, 93G bytes)
 pkts bytes target     prot opt in     out     source               destination

sysctl net.bridge.bridge-nf-call-iptables = 1

Интерфейсов куча, суть в том что на хосте есть куча физ интерфейсов, которые прокинуты в контейнер и вот контейнере уже рулит всем трафиком и не только.

Т.е. в оригинале это все шло именно в него, и на нем уже настроены iptables’ы и прочие, а на хосте вообще у всего этого даже IP нету и iptables пустой, только на одном из мостов IP прокинут в безопасную зону.

И вот для чистоты экспиримента я закинул сам. физ интерфейс на хосте в отдельный netns без моста (а net.bridge.bridge-nf-filter-vlan-tagged вообще везьде 0), и в этом же netns сделал ip link add … eth80.5 Так что родительский iptables влиять на него никак не должен вообще, хотя и он и в этом netns они пустые с полным разрешением. И в мостах интерфейс не состоит.

Более того, как я уже писал, если в том же netns все тоже, просто без vlan напрямую IP на интерфейсе получить выключив тэгирование, то все работает.

И конструкция вида host:vlan - netns - мост - veth - lxc - veth - netns - cont:vlan (netns’ы делал, что бы IP не пересикались) нормально пропускала трафик между host-cont vlan’ами, но выдавали ту же картину для gw.

При этом на другой машине, тоже с lxc, тоже с nf-call…iptables, так же выдавив все в netns в том же vlan на том же свитче, все работает (в смысле тестовая может tcp шлюзу и gw, но server не может tcp к gw и тестовой машине).

Т.е. еще раз: в рамках одного netns iptables пустой все в accept, и нет моста, и route/rule девственно чист кроме шлюза этого самого 192.168.66.1, другие мосты и контейнеры не имеют к нему отношения.

Но на всякий я вообще во всех iptables’а делал accept на все, и маркировку пакетов отключал в контейнере (хотя и не знаю каким боком оно может влиять).

Если бы сервер был не рабочий и можно было бы все погасить остальное вопросов бы не было… Может это вообще глюк, я на как-том из позапрошлогодних ядер центоси ловил странные вещи с netns’ами лечащиеся только ребутом, но пока ищу логическое объяснение.

Попробовал добавить еще один vlan и соединится с заведомо рабочей машины, на проблемную.

tcpdump на vlan интерфейсе выдает кучку syn,ack, с одинаковыми seq, по всему выходит что проблемная машина как собака, все понимает, но ответить не может.

Т.е. до нее syn доходит, она говорит ack, но он недоходит и идут ретрансмиты.

Я правильно понимаю, что на коммутаторе 5-й порт подключен к серверу и vlan5 там тегированный, а роутер подключен к порту 4 на котором vlan5 без тегов?

А какой vlan без тегов на 5-м порту свитча? Не получилось ли так, что native vlan на том порту тоже 5-й?

Если идут разборки с vlan-ами, то tcpdump нужно запускать с ключиком "-е", тогда он покажет наличие/отсутствие заголовков vlan. Смотреть лучше на базовом интерфейсе.

То, что работает dhcp, это не удивительно, т.к. он не роутиться.

Странно, что пинги ходят...

Я бы начал со сравнения sysctl net.ipv4.conf.xxx.arp_{accept,filter,announce} и net.ipv4.conf.xxx.rp_filter на системах где оно работает.

Хорошо бы в том netns (куда vlan5 с eth80 отдан) посмотреть «ip ro» и «ip n» после ping 8.8.8.8

Используются порты 2,4 с pvid=5

• 2й порт с тэгами он какраз на проблемной машине, на которой используется через интерфейс из ip link add ... type vlan id 5
• 4й порт это железка, она не в курсе про vlan, и с ней все ок, так как гругая машина, тем самым выше описанным способом без проблем с ней работает.

На базовом интерфейсе tcpdump ... -e vlan исходящих вообще не показывает, даже для рабочего dhcp.

rp_filter = 0 для других задач

По arp_... имею пробелы в образовании, пошел читать, но в интерфейсе arp регулярно мелькает, и arp -a маки показывает всех соседей по интерфейсу на проблемной машине…

Используются порты 2,4 с pvid=5

2й порт с тэгами он какраз на проблемной машине, на которой используется через интерфейс из ip link add ... type vlan id 5

Гм. в моих понятиях pvid - это «native vlan» который без тегов

У тебя проблемная машина подключена во 2-й порт коммутатора? Какие vlan-ы на этом порту назначены и как?

HP коммуникатор

• там есть термины include/exclude, tagged/untagged
• так вот указанные порты include в указанные vlan’ы, и exclude из всех остальных
• tagged это тут те кто в порт с пометкой о vlan попадают, untagged при exclude, идет чистый трафик, из разрешенных vlan
• как видно на схеме ниже, tester работает по тому же принципу что и server и у него проблемы нету, так что дело не в настройках комуникатора.

• 6 vlan добавлен для тестов между tester и server
• vlan’ы добавлялись по ip link add link eth80 name eth80.5 type vlan id 5 на обоих машинах и контейнере
• если убрать тэгирование и пустить простой трафик, то на eth80 все нормально работает на проблемной машине, проблема только при работе через eth80.5
• заметил что тормозит arp -a (судя по всему есть проблемы и с хождением arp запросов, но при этом после тормозов, таблица маков выдается правильная)
• arp_, rp_filter на проблемной и тестовой машине идентичны
• слушал трафик на eth80, там в принципе tcpdump -e vlan не показывает исходящих пакетов, даже тех что точно проходят (dhcp, ping)
• на eth80.5,6 трафик весь виден нормально, но судя по тому что видно, исходящии с проблемного сервера не уходят в коммуникатор
• на всякий случай еще раз: физ. интерфейс в отдельном netns с пустым iptables, без доп рулей или маршрутов

ping 8.8.8.8 и тестового хоста; ip ro; ip n

• 192.168.66.1 это vlan5 - gw
• 192.168.99.[1,2] это vlan6 - server,tester
• 8.8.8.8 пингуется отлично, как и весь остальной инет, но ничего больше не жоходит
• еще раз, это netns отдельный, с пустым iptables
• 192.168.66.[181,248] ОБЕ машины получили по dhcp от 192.168.66.1

server (проблемный)

default via 192.168.66.1 dev eth80.5 
192.168.66.0/24 dev eth80.5 proto kernel scope link src 192.168.66.248 
192.168.99.0/24 dev eth80.6 proto kernel scope link src 192.168.99.1 
=
192.168.99.2 dev eth80.6 lladdr 9c:5c:8e:86:e4:68 REACHABLE
192.168.66.1 dev eth80.5 lladdr 64:70:02:40:4c:66 REACHABLE

tester

default via 192.168.66.1 dev br0.5 
192.168.66.0/24 dev br0.5 proto kernel scope link src 192.168.66.181 
192.168.99.0/24 dev br0.6 proto kernel scope link src 192.168.99.2 
=
192.168.99.1 dev br0.6 lladdr 50:3e:aa:15:66:f9 REACHABLE
192.168.66.1 dev br0.5 lladdr 64:70:02:40:4c:66 REACHABLE

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

если убрать тэгирование и пустить простой трафик, то на eth80 все нормально работает на проблемной машине, проблема только при работе через eth80.5

Скорее всего это источник проблемы. Если на порту коммутатора этот vlan сконфигурирован как «tagged» и нет нативного vlan, то через eth80 не должен ходить простой трафик.

Похоже, что коммутатор считает vlan5 на 2-м порту - нативным.

Смотри на коммутаторе FDB на 2-м порту.

С HP-шными коммутаторами никогда не имел дела, т.ч. про его настройки подсказать не могу.

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

заметил что тормозит arp -a (судя по всему есть проблемы и с хождением arp запросов, но при этом после тормозов, таблица маков выдается правильная)

«arp -an» - для тех, что не любит тормоза.

слушал трафик на eth80, там в принципе tcpdump -e vlan не показывает исходящих пакетов, даже тех что точно проходят (dhcp, ping)

Это ненормально.

«tcpdump -nei eth80» должен показывать весь трафик.

Скорее всего это источник проблемы. Если на порту коммутатора этот vlan сконфигурирован как «tagged» и нет нативного vlan, то через eth80 не должен ходить простой трафик.

Я специально для тестов делал на порт нетэгированный, просто так он там и не ходит. Специально что бы убедиться, что в принципе как-то трафик с этого хоста ходит, потому что если бы не ходил, то vlan был бы не причем…

Это ненормально. «tcpdump -nei eth80» должен показывать весь трафик.

А вот это уже выглядит очень интересно, щас в таком виде проверил

• tester реально видит так весь трафик
• server видит только входящи, даже исходящих пингов нету, в отличии от тестера

Какие какие еще варианты почему может такое быть, и как тогда ходят icmp/dhcp?

«tcpdump -nei eth80» должен показывать весь трафик.

имеется ввиду весь локальный трафик + широковещательный трафик должен быть виден. Только что убедился, что на хосте видно трафик контейнера, в который отдан vlan.

Странно, что icmp ходит.

A dhcp случайно не через dhcprelay коммутатора ходит?

У тебя совпадающих mac-адресов нет в этой сети?

Как настроен vlan5 на gw? Видно ли на gw исходящий трафик с server на интерфейсе vlan5? А на внешнем интерфейсе?

Про трафик видимый на основном устройстве, я тоже на tester’е уже убедился.

Коммуникатор не имеет IP в этих vlan’ах, и tcpdump показывает dhcp пакеты именно от gw.

Если смотреть на eth80.5 tcpdump’ом, то вообще все выглядит как должно, кроме того факта что по всему кроме dhcp,icmp идут ретрансмиты, как будто исходящих пакетов нету, но в дампе они есть…

Про маки думал, совпадающих нету, но сетевуха раньше была частью другого моста. Я на всякий пробовал менять через ip link set address и на общем и на vlan, толку 0.

Щас вообще бредом занялся, хочу на проблемной машине kvm виртуалку сделать, и посмотреть будет ли на ней норм vlan видеть…

Никак не настроен, gw не знает о vlan, выше в сообщении есть таблица. Туда чистые пакеты без vlan тэгов идут, и там все точно нормально, так как tester видит все остальное с той же конфигурацией…

На gw не могу сомтреть трафик, но для проблемного server, gw и tester выглядят одинаково (icmp есть, остального нет).

И вот на tester’е нету, трафика от server. (не важно server к нему nc, или tester к server)

А вот на server на eth80.5 есть весь трафик. (опять же не ажно кто куда коннектится, выглядит все как буд-то -I OUTPUT -o eth80.5 -j DROP, но его нет…)

На управляемых коммутаторах есть зеркалирование трафика, так что посмотреть трафик не проблема.

Посмоти /proc/net/vlan/config. Нет ли vlan5 на других интерфейсах?

Убери vlan5 с eth80 и запусти «tcpdump -nei eth80»

Если на коммутаторе vlan5 на этом порту сконфигурирован как tagged, то приходящие пакеты будут видны с тегами.

На сервере в это врем запустить «arping -B 192.168.66.xxx» где xxx - несуществующий адрес в этой сети.

А как устроен gw? У него один интерфейс или два?

Что показывает ip route get $tester_ip на server?

На server

[root@coaw3 ~]# arping -b -I eth80.6 192.168.99.2
ARPING 192.168.99.2 from 192.168.99.1 eth80.6
Unicast reply from 192.168.99.2 [9C:5C:8E:86:E4:68]  0.667ms
Unicast reply from 192.168.99.2 [9C:5C:8E:86:E4:68]  0.732ms

Без -I eth80.6 выдавал arping: Suitable device could not be determined. Please, use option -I.

на tester

[root@coaw2 ~]# tcpdump -nei br0.6

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0.6, link-type EN10MB (Ethernet), capture size 262144 bytes
12:42:26.557577 50:3e:aa:15:66:f9 > Broadcast, ethertype ARP (0x0806), length 56: Request who-has 192.168.99.2 (Broadcast) tell 192.168.99.1, length 42
12:42:26.557597 9c:5c:8e:86:e4:68 > 50:3e:aa:15:66:f9, ethertype ARP (0x0806), length 42: Reply 192.168.99.2 is-at 9c:5c:8e:86:e4:68, length 28
12:42:27.557715 50:3e:aa:15:66:f9 > Broadcast, ethertype ARP (0x0806), length 56: Request who-has 192.168.99.2 (Broadcast) tell 192.168.99.1, length 42
12:42:27.557735 9c:5c:8e:86:e4:68 > 50:3e:aa:15:66:f9, ethertype ARP (0x0806), length 42: Reply 192.168.99.2 is-at 9c:5c:8e:86:e4:68, length 28

Не стал убирать vlan ибо и так пакеты видны…

Тестировал на 6 vlan’е так как проблемы те же что на 5м, и на нем статика задана для server,tester

А как устроен gw? У него один интерфейс или два?

У него их более девяти тысяч, и я не могу остальное убрать для теста или перезагрузить его.

Но eth80{,.5,6} выкинуты в тестовый netns с accept везьде iptables. Описывал все это выше.

Что показывает ip route get $tester_ip на server?

[root@coaw3 ~]# ip route get 192.168.99.2
192.168.99.2 dev eth80.6 src 192.168.99.1 
    cache

Без -I eth80.6 выдавал arping: Suitable device could not be determined. Please, use option -I.

У тебя старый arping, новый умеет сам определять интерфейс :)

ты «tcpdump -nei br0» запусти. br0.6 смотреть неинтересно.

Для моста нужно не забыть сделать «sysctl net.bridge.bridge-nf-filter-vlan-tagged=1»

Без этого стандартный мост не пропускает тегированные пакеты.

Возможно еще нужно «sysctl net.bridge.bridge-nf-pass-vlan-input-dev=1»

Если речь о tester, то зачем это все, если трафик от arping’а видно, т.е. он в принципе есть и виден на tester’е…

Не видно исходящего на eth80 на самом server’е, где моста нету.

Если смотреть на мосту, тогда уж не arping’а трафик, а tcp которого как раз не видно.

Запустил kvm виртуалку, картина еще интереснее

Далее речь идет о vlan6 и tcp, icmp и так везде работает

server:netns:temp не соединяется с tester server:kvm:sandbox отлично дружит с tester server:netns:temp отлично дружит с server:kvm:sandbox

При том сам server:kvm:sandbox который видит внешнию физичускую vlan отлично, соединен с ней через

eth1.6-eth1-kvm:sandbox-br95-veth99a-netns:temp-veth99b-br99-eth80-switch-vlan6

Но при этом br99.6-br99-eth80-switch-vlan6 не видит внешнюю сеть

но видит

eth1.6-eth1-kvm:sandbox-br95-veth99a-netns:temp-veth99b-br99-br99.6

Т.е. проблема именно на исходящие пакеты из server:netns:temp через физ интерфейс eth80, так как через тот же мост, но по veth все ходит, и через тот же мост, между veth и физ сетью тоже.

Т.е. eth80 с мостом br99 ТОЧНО пропускает vlan пакеты и работает нормально, так как работает даже виртуалка kvm которая к этому мосту подключена.

Не работает ТОЛЬКО исходящие tcp/udp(кроме dhcp) из хостовой системы, причем не работают только с выходом в физ интерфейс.

Добавил схему https://imgur.com/8Jd1pSN

извините, вставлю пять копеек, все посты внимательно не вычитывал.

1. если icmp ходит а всё остальное нет то дело явно не в vlan, бриджах и т.п., это уже выше уровня IP проблемы.
2. может быть мозги канифолит offload сетевой карты? В icmp он может просто не лезет, а в tcp/udp - завсегда.

2. может быть мозги канифолит offload сетевой карты? В icmp он может просто не лезет, а в tcp/udp - завсегда.

Были мысли про карту, для того и добавил kvm виртуалку на том же хосте.

Но через эту физ. карту через ТОТ же самый мост отлично проходит трафик из kvm виртуалки, но не проходит из vlan этого самого моста (veth’а пробовал докинуть, что бы мак был другой на всякий случай)

1. если icmp ходит а всё остальное нет то дело явно не в vlan, бриджах и т.п., это уже выше уровня IP проблемы.

Согласен, это все выглядит как iptables -I OUTPUT -o ... -j DROP, но его нет, ни на одном мосту/veth’е или еще чем-то. Везьде ACCEPT что на основной таблице сервера, что на netns в которой тестирую.

И да в основной таблице сервера проблема та же, поэтому что бы случайно ничего не задеть и не влияли другие интерфейсы в отдельном netns тестирую…

Я вообще склоняюсь к тому что это глюк ядра, но перезагрузиться в single user mode и вручную поднять только эту сеть в ближайшие время нет возможности.

Гм, а если где-то на глубине правил tc ? Это погружение уровня «между tcpdump и iptables» Если почитать - то tc вообще столько всего может, я был в своё время очень удивлён как можно трафиком манипулировать.

Насколько я помню, он тоже в пределах netns живет.

Ну и о нем как-то даже не думал, так как на этой машине вообще tc ни разу не трогал, ни на хосте, ни в контейнерах.

Ну по этой картинке стало значительно проще понимать ситуацию.

Нужно идти на коммутатор и смотреть fdb.

Искать нужно mac-адрес интерфейса br99.6

Если он не видет на втором порту в 6-м влане, значит косяк в сервере.

Как он может не видеть если идут пинги, и arping’и? (Ну на всякий я проверил, да есть в списке)

И мак виртуальной сетивухи kvm тоже есть.

Там на схеме зеленые и красная линии это относится только к tcp и udp, при это icmp и arp отлично ходят между любыми узлами.

Проблема проявляется ТОЛЬКО на vlan интерфейсах линухи хостовой. Сам vlan трафик ходит без проблем в любых вариантах. Хоть транзитный, хоть из виртуалки, хоть через 3 моста.

Я для прикола сделал еще vxlan туннель. Причем вообще через другие сетевухи, без vlan и тэгирования. Так вот, там та же проблема, ping’и идут, а tcp/udp нет.

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

Причем пофигу на IP адреса, порты и маки.

Но при этом я могу сделать например финт ушами и заправить те же пакеты в kvm который протегировав заправит их в мост, и таким образом все будет работать.

Как буд-то бы все пакеты от vlan,vxlan исходящие кроме icmp,arp маркируются в ядре черной меткой. Которая не дает уйти в физическую сеть. И только в нее и только хостовые vlan/vxlan.

Но fwmark ни рулах ни в iptables’а не назначается, а ничего другого подобного я не знаю.

П.С.: если с vlan’ами еще могли быть вопросы по mac’ам и прочему на уровне коммуникатора, то об vxlan он точно ничего не знает и не может icmp от tcp отличить…

Запрети все аппаратные КС на прием и передачу для eth80, br99, br99.6, и всякие gro,lro,sgo

В линуксячей реализации veth есть замечательные грабли: Интерфейс сообщает системе, что он умеет сам считать и проверять все КС. (посмотри на ethtool -k для любого veth интерфейса)

С точки зрения накладных расходов - все правильно, но это до тех пор, пока пакеты не покидают линк. А вот если veth включить в мост, то у исходящих пакетов (udp и tcp) будут битые КС, что можно посмотреть tcpdump-ом.

ping работает т.к. все КС там считают сами. С dhcp тоже самое.

# ethtool -k eth80 | grep -iP '(gro|lro|sgo)'
rx-gro-hw: off [fixed]

• Не понятно почему тогда пакеты выходящие через тот же интерфейс но с kvm идут норм.
• Когда пробовал vxlan, пакеты шли через другую сетевуху, идентичная которой(модель) на tester’е у которого все ок.

# ethtool -k eth80

Features for eth80:
rx-checksumming: on
tx-checksumming: on
	tx-checksum-ipv4: on
	tx-checksum-ip-generic: off [fixed]
	tx-checksum-ipv6: on
	tx-checksum-fcoe-crc: off [fixed]
	tx-checksum-sctp: off [fixed]
scatter-gather: on
	tx-scatter-gather: on
	tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
	tx-tcp-segmentation: on
	tx-tcp-ecn-segmentation: off [fixed]
	tx-tcp6-segmentation: on
	tx-tcp-mangleid-segmentation: off
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off
tx-vlan-offload: off
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
busy-poll: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-sctp-segmentation: off [fixed]
rx-gro-hw: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]

ну так, на всякий случай, я как-то раньше слышал про такую штуку как ebtables, не пользовался правда.

Я тоже слышал, но увы, она тоже per netns так сказать, и там тоже все по дефолту ACCEPT.

В общем у меня все идеи закончились.

Когда будет возможность, буду грузить в single user и поднимать вручную сеть, а потом смотреть после чего поломается.

Что показывает «tcpdump -nvvei eth1 -с 10» на server:kvm:sandbox если организовать передачу данных по udp/tcp между 99.1 и 99.3 ? (например iperf3 запустить)

tcpdump с "-vv" проверяет КС протоколов!

Хорошо бы еще проверить кто какие МАС-и видит для адресов 99.1 99.2 99.3

Далее, нужно посылать udp пакеты с 99.1 на 99.2 (типа dig @192.168.99.2 a.b) (убедившись, что на netns:temp «arp -an» показывает маc 99.2 и что mac-адрес для 99.2 виден по «brctl showmacs br99» на правильном порту) и по очереди смотреть «tcpdump -nevvi» на br99.6, br99, eth80, veth99b

Если оно уходит в eth80 (с правильными КС), то дальше только port mirroring сможет помочь.

Я бы начал мониторить счетчики ошибок КС хотя бы через «netstat -s» в netns:temp

Жаль, что в центоси ядра левые. Чему соответствует 3.10.0-1127.13.1.el7 в реальности - ХЗ. Это точно не 3.10. Т.к. в 3.10 с netns была полная попа. Только в 3.14 оно стало более или менее вменяемое.

Раз kvm-виртуалка на server работает «хорошо», надо смотреть на то, чем настройки её интерфейса отличаются от тех, что в init netns и netns sandbox.

Из очевидных вещей это MAC-адрес и IP-адрес.

Что будет, если поменять IP-адреса 192.168.99.1 и 192.168.99.3 местами? А если поменять MAC-адрес у br99.6?

Чему равны два младших бита первого октета MAC-адреса у br99.6 и сетевого интерфейса внутри виртуалки? То есть если MAC-адрес имеет вид AB:01:23:45:67:89, то какое значение у hex-цифры B ?

Как сеть спускается в виртуалку? На схеме не вижу tap-интерфейсов. usernet, macvtap, vethtap?

Что пишет ip -d link show dev br99? Особенно интересен параметр vlan_filtering.

Что пишет bridge vlan show dev br99?

Есть ли какие-нибудь правила в ebtables, nftables? ebtables-save, nft -s list ruleset.

Может быть сетевая карта что-то на аппаратном уровне делает с трафиком по некоторому условию. Что-то есть в ethtool -n eth80?

И на всякий случай — на каком именно интерфейсе висит 192.168.99.1? С какой маской добавлен этот IP? Что пишет ip route get 192.168.99.2 на server:netns:temp?

Раз kvm-виртуалка на server работает «хорошо», надо смотреть на то, чем настройки её интерфейса отличаются от тех, что в init netns и netns sandbox.

Из очевидных вещей это MAC-адрес и IP-адрес.

Что будет, если поменять IP-адреса 192.168.99.1 и 192.168.99.3 местами? А если поменять MAC-адрес у br99.6?

Адрес 192.168.99.x родился далеко не сразу, в процессе использовались 100500 разных, в том числе в порядке бреда, тот адрес что в другом netns разрешен для локальной сети.

И смена местами там тоже была, а еще разные порты.

Чему равны два младших бита первого октета MAC-адреса у br99.6 и сетевого интерфейса внутри виртуалки? То есть если MAC-адрес имеет вид AB:01:23:45:67:89, то какое значение у hex-цифры B ?

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

Подмена местами никак не влияет.

Как сеть спускается в виртуалку? На схеме не вижу tap-интерфейсов. usernet, macvtap, vethtap?

На схеме не показан, так как там стандартный veth делаемый libvirt qemu-kvm.

т.е. br95=eth1 следует читать как br95[veth99a, vethXXXXa] <-> vethXXXXb renamed to eth1 by libvirt

Что пишет ip -d link show dev br99? Особенно интересен параметр vlan_filtering.

vlan_filtering 0

8: br99: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 36:86:5b:03:b9:19 brd ff:ff:ff:ff:ff:ff promiscuity 0 
    bridge forward_delay 1500 hello_time 200 max_age 2000 ageing_time 30000 stp_state 0 priority 32768 vlan_filtering 0 vlan_protocol 802.1Q bridge_id 8000.36:86:5b:3:b9:19 designated_root 8000.36:86:5b:3:b9:19 root_port 0 root_path_cost 0 topology_change 0 topology_change_detected 0 hello_timer    0.00 tcn_timer    0.00 topology_change_timer    0.00 gc_timer  111.59 vlan_default_pvid 1 vlan_stats_enabled 0 group_fwd_mask 0 group_address 01:80:c2:00:00:00 mcast_snooping 1 mcast_router 1 mcast_query_use_ifaddr 0 mcast_querier 0 mcast_hash_elasticity 4 mcast_hash_max 512 mcast_last_member_count 2 mcast_startup_query_count 2 mcast_last_member_interval 100 mcast_membership_interval 26000 mcast_querier_interval 25500 mcast_query_interval 12500 mcast_query_response_interval 1000 mcast_startup_query_interval 3125 mcast_stats_enabled 0 mcast_igmp_version 2 mcast_mld_version 1 nf_call_iptables 0 nf_call_ip6tables 0 nf_call_arptables 0 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 64000 gso_max_segs 65535

Что пишет bridge vlan show dev br99?

Такой команды нет у меня.

[root@coaw3 ~]# brctl show
bridge name	bridge id		STP enabled	interfaces
br99		8000.36865b03b919	no		eth80
							veth98a
							veth99b

Есть ли какие-нибудь правила в ebtables, nftables? ebtables-save, nft -s list ruleset.

ebtables ACCEPT все и нет ничего доп, как и iptables, это я проверил еще в первый день.

nft нету

Может быть сетевая карта что-то на аппаратном уровне делает с трафиком по некоторому условию. Что-то есть в ethtool -n eth80?

Тогда почему не работает vxlan, причем опять же только tcp/udp, но проходят icmp, при том что для карты они все udp.

И на всякий случай — на каком именно интерфейсе висит 192.168.99.1? С какой маской добавлен этот IP? Что пишет ip route get 192.168.99.2 на server:netns:temp?

Я уже столько разных IP перепробовал… Там все верно и перепроверенно разными способами.

Саму netns:temp я пересоздавал по меньшей мере 3 раза.

Пробовал настроить 3 разных vlan’а, ip route get где-то выше писал, все там ок.

Префиксы везде 24е, сам в процессе иногда юзал 26 и 30, но щас эти интерфейсы удалены.

Напоминаю, что изначально все началось с проблемы в подсети 192.168.66.1/24 в которой IP вообще по DHCP где есть реальная железка, с другими клиентами в том числе по vlan.

Что показывает «tcpdump -nvvei eth1 -с 10» на server:kvm:sandbox если организовать передачу данных по udp/tcp между 99.1 и 99.3 ? (например iperf3 запустить)

tcpdump с «-vv» проверяет КС протоколов!

Показывает cksum (correct) для всех пакетов

Хорошо бы еще проверить кто какие МАС-и видит для адресов 99.1 99.2 99.3

• netns:temp:br99 192.168.90.1 36:86:5b:03:b9:19
• tester:br:veth 192.168.90.2 1e:af:f4:7b:44:47
• kvm:sandbox:eth1 192.168.90.3 52:54:00:5f:2f:39

netns:temp

? (192.168.90.2) at 1e:af:f4:7b:44:47 [ether] on br99.6
? (192.168.90.3) at 52:54:00:5f:2f:39 [ether] on br99.6

kvm:sandbox

? (192.168.90.1) at 36:86:5b:03:b9:19 [ether] on eth1.6
? (192.168.90.2) at 1e:af:f4:7b:44:47 [ether] on eth1.6

tester

? (192.168.90.1) at 36:86:5b:03:b9:19 [ether] on vlan6
? (192.168.90.3) at 52:54:00:5f:2f:39 [ether] on vlan6

Далее, нужно посылать udp пакеты с 99.1 на 99.2 (типа dig @192.168.99.2 a.b) (убедившись, что на netns:temp «arp -an» показывает маc 99.2 и что mac-адрес для 99.2 виден по «brctl showmacs br99» на правильном порту) и по очереди смотреть «tcpdump -nevvi» на br99.6, br99, eth80, veth99b

Если оно уходит в eth80 (с правильными КС), то дальше только port mirroring сможет помочь.

Я бы начал мониторить счетчики ошибок КС хотя бы через «netstat -s» в netns:temp

Вот такое на примере nc 192.168.90.2 9000 поймал

#tcpdump -nvvei eth80

11:40:03.513411 36:86:5b:03:b9:19 > 1e:af:f4:7b:44:47, ethertype 802.1Q (0x8100), length 78: vlan 6, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 57161, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.90.1.51482 > 192.168.90.2.cslistener: Flags [S], cksum 0x3583 (incorrect -> 0x0cdf), seq 2552582138, win 29200, options [mss 1460,sackOK,TS val 322546720 ecr 0,nop,wscale 7], length 0

Похоже в этом и проблема, но почему так и как это исправить?

Спасибо!!!

Вот это поправило ошибку

ethtool --offload eth80 rx off tx off

Странно что на другой сетевухе где я vxlan гонял, все было ок. Ведь она такая же как на tester’е.

П.С.: Я проверил, после отключения оффлоада в tcpdump’е сумма стали верными.

Получается что до этого на интерфейсе в tcpdump’е не было пакетов, потому что я без -vv запускал. Или я это больше никак объяснить не могу.

На всякий вот причина, если кто из гугла придет.

https://rtfm.co.ua/tcpip-oshibki-cksum-0xe2bc-incorrect-0xc9a0/

Часто в результатах tcpdump видно большое количество ошибок проверки контрольных сумм.

Вызваны они нагрузкой из-за того, что для сетевой карты установлен режим TCP offload engine, в результате чего tcpdump получает данные о контрольных суммах от ядра системы — до того, как контрольная сумма будет установлена самим сетевым интерфейсом.

udp/tcp начали ходить после этого между 99.1 и 99.2?

Да. И в том числе контрольные суммы стали нормальными.

Ну и 192.168.66.0/24 для которой это все и затевалось заработала внутри контейнера.

vxlan не проверял, она там не нужна, я её добавлял просто на пробу, так как тоже виртуальный интерфейс линухи изменяющий пакеты.

Но это ненормально, что отключение аппаратных КС вернуло работоспособность.

IMHO достаточно было «tx off»

А что за железка на этой eth80?

Вот так lspci обзывает, как она по докам не помню.

Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)

Как пишут в инете, проблема в том что карта проверяет сумму, раньше чем пересчитывает ядро, я сам с таким не сталкивался, так что хз насколько это адекватное объяснение.

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

Про TX уже подумал и сделал, просто сразу отписал тогда. Ну и да RX аппаратный не мешает, с ним все норм работает.

хех, видел подобное на другой сетевухе(на драйвере be2net), но там билась только часть пакетов tcp/udp, поэтому я как-то даже не подумал в эту сторону