Hi Stefan -
I noticed you have these two definitions:
ext_net_bridge_ports:
- "bond0.{{ ext_net_vlan }}"
ext_net_vlan: 705
In the first statement, the network interface for ext_net is defined as a linuxbridge, and the second implicitly indicates it is a VLAN device. This is going to cause some ambiguity in the networking. Another possible issue could be a loop created by OVS, brmgmt and brbond705 (this may depend on other config).
I'm guessing ext_net is for Neutron external networking, in which case you can drop the ext_net VLAN definition in Kayobe config - you'll need to define it in Neutron instead. For Kayobe, listing ext_net in external_net_names should be enough to ensure it gets an OVS bridge attached to it.
With the two networks you have defined (mgmt_net and ext_net), the minimal setup would be:
- remove the VLAN definition for ext_net_vlan
- define ext_net as bond0.
- mgmt_net as a VLAN device tapped off bond0, eg "{{ ext_net_interface }}.{{ mgmt_net_vlan }}"
With ext_net listed in external_net_names, this will set Kayobe to attach bond0 as the external OVS port.
Note, we normally configure more logical networks than this. What do you have for the provision_oc network, for example?
Best wishes,
Stig
Ah, thank you for your response! I’ve seen this Bug from your link, but I use systemd-networkd (Ubuntu 22.04)
BearingPoint GmbH
Sitz: Wien
Firmenbuchgericht: Handelsgericht Wien
Firmenbuchnummer: FN 175524z The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.