Hi again! After rebooting the server an cleaning up everything in /etc/systemd/network/ it does work again (kayobe overcloud host configure) but I am afraid to run “kayobe overcloud service deploy”. Can anyone confirm that the configuration might be correct or has an idea about what happened in the network there? Multicast storm? Broadcast storm? Troubles with STP? Thank you and best wishes Stefan ________________________________ 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.
Hello Stefan, Recently we’ve discovered that NetworkManager stp setting defaults to on (while using network-scripts and networkd on Ubuntu it defaults to off) - which might be the reason of your problems. There is a patch being reviewed in master branch - https://review.opendev.org/c/openstack/kayobe/+/889859 Hope that helps Michal
On 10 Aug 2023, at 15:58, Stefan Pinter <stefan.pinter@bearingpoint.com> wrote:
Hi again!
After rebooting the server an cleaning up everything in /etc/systemd/network/ it does work again (kayobe overcloud host configure) but I am afraid to run “kayobe overcloud service deploy”. Can anyone confirm that the configuration might be correct or has an idea about what happened in the network there? Multicast storm? Broadcast storm? Troubles with STP?
Thank you and best wishes Stefan 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.
For STP on bridges that is, sorry to not add that earlier. Michal
On 10 Aug 2023, at 16:09, Michał Nasiadka <mnasiadka@gmail.com> wrote:
Hello Stefan,
Recently we’ve discovered that NetworkManager stp setting defaults to on (while using network-scripts and networkd on Ubuntu it defaults to off) - which might be the reason of your problems. There is a patch being reviewed in master branch - https://review.opendev.org/c/openstack/kayobe/+/889859
Hope that helps
Michal
On 10 Aug 2023, at 15:58, Stefan Pinter <stefan.pinter@bearingpoint.com> wrote:
Hi again!
After rebooting the server an cleaning up everything in /etc/systemd/network/ it does work again (kayobe overcloud host configure) but I am afraid to run “kayobe overcloud service deploy”. Can anyone confirm that the configuration might be correct or has an idea about what happened in the network there? Multicast storm? Broadcast storm? Troubles with STP?
Thank you and best wishes Stefan 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.
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.
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
On 10 Aug 2023, at 15:24, Stefan Pinter <stefan.pinter@bearingpoint.com> wrote:
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.
participants (3)
-
Michał Nasiadka
-
Stefan Pinter
-
Stig Telfer