NS 🇷🇺
255 влан про что?
Artyom
255 поднят с адресом 10.150.0.102, он же указан как local ip и сделан, чтобы там крутились клиентские vxlan
NS 🇷🇺
ну вот не неси его тогда в провайдер нетворк =)
Artyom
да, мне это тоже странным показалось... куда тогда дальше копать?
J
ну вот не неси его тогда в провайдер нетворк =)
Обожди-ка) У тебя какая схема сети в итоге? Тоже один бонд нарезанный на вланы?
J
да
А у тебя ж не ovs, а линукс бридж, не?)
NS 🇷🇺
с линукс бридж всего одна площадочка
J
В итоге чо получается: В br-provider закинуты тегированные сабинтерфейсы для provider networks, а все остальное нарезано на vlan сабинтерфейсы вне ovs, так?
Artyom
все нарезано на vlan вне ovs
Artyom
есть mgmt vlan10, по нему общается OS, есть vlan1000 с public net, есть vlan255 для vxlan локальных сетей клиентов
Artyom
ovs-vsctl add-br br-provider ovs-vsctl add-port br-provider bond0.1000
Artyom
только это прокинуто в ovs
J
у автора да, у меня нет
А у тебя как?) Раз уж у тебя схема ближе к тому что делает коллега, расскажи)
Artyom
только это прокинуто в ovs
и эта часть работает
Artyom
потому что это flat network я полагаю
NS 🇷🇺
А у тебя как?) Раз уж у тебя схема ближе к тому что делает коллега, расскажи)
ну будем считать что у меня тоже влан называется провайдер в него всунут bond0 целиком
NS 🇷🇺
а не bond.XXX
NS 🇷🇺
на уровне овс наверное отличие кончится
NS 🇷🇺
но тяжело не видя конфигов обсуждать =)
J
да
Короче, в этом и разница. Смотри, у тебя, поскольку трафик с тегированных сабинтерфейсов все равно проходит в итоге через 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. Наверняка я, конечно, не знаю, но на уровне интуиции, как ты говоришь, все для меня именно так выглядит. Хотелось бы знать наверняка, но даже пока и хз откуда начать читать.
NS 🇷🇺
Короче, в этом и разница. Смотри, у тебя, поскольку трафик с тегированных сабинтерфейсов все равно проходит в итоге через 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. Наверняка я, конечно, не знаю, но на уровне интуиции, как ты говоришь, все для меня именно так выглядит. Хотелось бы знать наверняка, но даже пока и хз откуда начать читать.
не я могу вытащить бонд из бриджа и все продолжит работать кроме внешних сетей
NS 🇷🇺
А ну-ка, давай вот чо сделаем. lsmod | grep vxlan сделай.
пожалуйста lsmod | grep vxlan vport_vxlan 12640 1 vxlan 45114 1 vport_vxlan ip6_udp_tunnel 12755 1 vxlan udp_tunnel 13373 1 vxlan openvswitch 106775 326 vport_vxlan
Artyom
# lsmod | grep vxlan vxlan 61440 0 ip6_udp_tunnel 16384 1 vxlan udp_tunnel 16384 1 vxlan
NS 🇷🇺
чет у меня по бодрее =)
Artyom
на убунте у меня та же борода: # lsmod | grep vxlan vxlan 57344 0 ip6_udp_tunnel 16384 1 vxlan udp_tunnel 16384 1 vxlan
NS 🇷🇺
vport_vxlan мож его впилили в vxlan
NS 🇷🇺
у меня овс тут старенький
NS 🇷🇺
тут кста наркоманов с netplan не подвезли?
J
Ну хз. hwe-edge ядро.
NS 🇷🇺
Я.
ubuntu или rpm based?
NS 🇷🇺
бубунта.
а снизу NM или sn
NS 🇷🇺
все ни как у меня =)
J
Да все это куча говна, конечно. Чем свои говняные поделки пилить, космонавт вместе с поттерингом могли б и ifupdown до ума довести.
NS 🇷🇺
сношаюсь натянуть его на NM в 8 центоси
NS 🇷🇺
потому что пидоры networkd деприкейтнули
J
потому что пидоры networkd деприкейтнули
Ну вот тоже, нахуя, я не понимаю. В rhel подобных системах был же, пусть и страшноватый из-за капса, но рабочий способ в одних конфигах сразу и ovs и vlan и всякие tap интерфейсы настраивать.
J
Нет, надо все поломать, сначала позаигрывать с networkd, потом network manager.
Artyom
# lsmod | grep openvswitch openvswitch 131072 14 nsh 16384 1 openvswitch nf_conncount 20480 1 openvswitch nf_nat 40960 3 openvswitch,iptable_nat,xt_REDIRECT nf_conntrack 143360 8 xt_conntrack,nf_nat,openvswitch,nf_conntrack_netlink,xt_connmark,xt_CT,nf_conncount,xt_REDIRECT nf_defrag_ipv6 24576 2 nf_conntrack,openvswitch libcrc32c 16384 4 nf_conntrack,nf_nat,openvswitch,xfs
Artyom
и с убунты: # lsmod | grep openvswitch openvswitch 131072 68 nsh 16384 1 openvswitch nf_nat_ipv6 16384 1 openvswitch nf_nat_ipv4 16384 2 openvswitch,iptable_nat nf_defrag_ipv6 36864 2 nf_conntrack_ipv6,openvswitch nf_nat 32768 5 nf_nat_ipv6,nf_nat_redirect,nf_nat_ipv4,xt_nat,openvswitch nf_conntrack 131072 12 xt_conntrack,nf_conntrack_ipv6,nf_conntrack_ipv4,nf_nat,nf_nat_ipv6,nf_nat_ipv4,xt_nat,openvswitch,nf_conntrack_netlink,xt_connmark,xt_CT,xt_REDIRECT libcrc32c 16384 4 nf_conntrack,nf_nat,openvswitch,raid456
NS 🇷🇺
ядро или ovs не кастомные какие нить?
Artyom
ядро я ml поставил пока
Artyom
на убунте стандартное
Artyom
прочитал, что для работы vxlan надо, чтобы ядро было 3.13+
Artyom
а на центоси стоит 3.10
Artyom
ща найду страничку
NS 🇷🇺
uname -r 3.10.0-514.26.2.el7.x86_64
Artyom
https://docs.openstack.org/liberty/networking-guide/scenario-dvr-ovs.html
NS 🇷🇺
не сравнивай ядра рх сент оса и ванильные
Artyom
Implementing VXLAN networks requires Linux kernel 3.13 or newer.
NS 🇷🇺
Implementing VXLAN networks requires Linux kernel 3.13 or newer.
не сравнивай ядра рх сент оса и ванильные
J
Да прост охуеешь разбираться чо они бекпортировали а чо нет. -_-
Artyom
Короче, в этом и разница. Смотри, у тебя, поскольку трафик с тегированных сабинтерфейсов все равно проходит в итоге через 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. Наверняка я, конечно, не знаю, но на уровне интуиции, как ты говоришь, все для меня именно так выглядит. Хотелось бы знать наверняка, но даже пока и хз откуда начать читать.
получается в убунте и центоси по разному организована сеть и в центоси как раз описанный сценарий случается?..
Artyom
т.е. надо мне сделать проще, прокинуть сразу bond0 в ovs и все vlan нарезать уже там...
Artyom
и должно засвистеть и запердеть)))
Artyom
?
NS 🇷🇺
и должно засвистеть и запердеть)))
должно и без этого свистеть, но я как и проктолог гемор по картинкам еще не очень лечу
Artyom
я тоже наркоман с netplan)
NS 🇷🇺
я тоже наркоман с netplan)
да у тебя тоже убунту
NS 🇷🇺
че с вас спросить 😄
Artyom
только на compute
Artyom
и то я хочу от неё избавиться
Artyom
отсюда и весь сыр-бор
Artyom
Не, мимо.
а что мимо то? не верна моя теория?