Нет, надо все поломать, сначала позаигрывать с networkd, потом network manager.

прочитал, что для работы vxlan надо, чтобы ядро было 3.13+

прочитал, что для работы vxlan надо, чтобы ядро было 3.13+

Implementing VXLAN networks requires Linux kernel 3.13 or newer.

Короче, в этом и разница.

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

А вот если он не добавлен, история другая, как мне кажется.
С исходящим с хоста трафиком все нормально. ovs генерирует vxlan пакет, он tcp\ip стеком ядра оборачивается в нужные заголовки и уходит себе через bond0.255.

Но что будет когда vxlan трафик внутри тегированного ethernet фрейма приходит на хост?
Фрейм приходит через bond0, дальше 8021q модуль парсит влан заголовок и оказывается что трафик предназначен тегированному сабинтерфейсу bond0.255. Фрейм попадает на   bond0.255, обработка переходит к tcp\ip стеку ядра. ip и udp заголовки усешно обработаны и вот у нас остается ethernet фрейм оверлейной сети завернутый в vxlan заголовок. Но в ядре то никаких vxlan интерфейсов не создано, модуль vxlan может быть вообще не подгружен, потому что за обработку vxlan отвечает модуль openvswitch. В итоге этот vxlan пакет дропается не попадая к модулю ovs.

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

получается в убунте и центоси по разному организована сеть и в центоси как раз описанный сценарий случается?..

и должно засвистеть и запердеть)))

я тоже наркоман с netplan)