英文:
Trouble creating a bridge device for OpenStack Rocky Linux 9.2 networking
问题
在创建网络桥时遇到的问题(OpenStack)
我当前正在根据官方OpenStack Ansible文档构建OpenStack,文档链接在这里:https://docs.openstack.org/project-deploy-guide/openstack-ansible/zed/targethosts.html
因此,我正在Rocky Linux 9.2上构建一个桥接。由于在设置测试时使用虚拟机,我的虚拟机连接的外部网络已经进入了VLAN,所以现在我只需要在每个节点主机内创建一个桥接设备(或多个),并使用桥接从网络接口(在我的情况下是ens160)连接这个桥接设备,以便可以访问互联网。
因此,我执行了以下命令:
nmcli c add type bridge autoconnect yes ifname br-mgmt con-name br-mgmt
nmcli c
有以下输出:
名称 UUID 类型 设备
br-mgmt 2b4c8058-f6ab-471f-afdb-e110cfdcc550 桥接 br-mgmt
ens160 ce68d146-f671-3eec-b26f-de540af181a1 以太网 ens160
lo 5d8a90ae-138c-4544-a415-dd0e3c23050f 回环 lo
这表明创建成功。然后,运行以下命令创建桥接从属:
nmcli con add type bridge-slave ifname ens160 master br-mgmt
如果继续执行nmcli c
,我们得到以下输出:
名称 UUID 类型 设备
br-mgmt 2b4c8058-f6ab-471f-afdb-e110cfdcc550 桥接 br-mgmt
ens160 ce68d146-f671-3eec-b26f-de540af181a1 以太网 ens160
lo 5d8a90ae-138c-4544-a415-dd0e3c23050f 回环 lo
bridge-slave-ens160 5f3fc816-406c-4cc0-8d6d-1d68841a6d55 以太网 --
当执行命令nmcli c up br-mgmt
时,您会得到以下输出:
连接成功激活(主等待从)(D-Bus活动路径:/org/freedesktop/NetworkManager/ActiveConnection/22)
然后,我们可以使用ip addr
命令检查网络状态:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:0c:29:62:bb:02 brd ff:ff:ff:ff:ff:ff
altname enp3s0
inet 192.168.75.141/24 brd 192.168.75.255 scope global dynamic noprefixroute ens160
valid_lft 1006sec preferred_lft 1006sec
inet6 fe80::20c:29ff:fe62:bb02/64 scope link noprefixroute
valid_lft forever preferred_lft forever
16: br-mgmt: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether c2:51:e9:6f:47:f4 brd ff:ff:ff:ff:ff:ff
inet 192.168.48.1/24 brd 192.168.48.255 scope global noprefixroute br-mgmt
valid_lft forever preferred_lft forever
这表明桥接设备br-mgmt仍处于停止状态,即使使用nmcli c up
命令也无法启动。
检查文件/etc/NetworkManager/system-connections/br-mgmt.nmconnection
:
(以下内容为文件中的配置信息,不再翻译)
英文:
Problems encountered when create the network bridge (OpenStack)
I'm currently building openstack according to the official Openstack-ansible documentation, which can be found here: https://docs.openstack.org/project-deploy-guide/openstack-ansible/zed/targethosts.html
So, I'm building a bridge in Rocky Linux 9.2. Due to the use of virtual machines for setup tests, the external network to which my virtual machine is connected has already entered the vlan, so now I just need to create a bridge device (or several) inside each node host and use bridge-slave to connect this bridge device with a network interface (ens160 in my case) that can access the Internet.
So, I executed the following command:
nmcli c add type bridge autoconnect yes ifname br-mgmt con-name br-mgmt
nmcli c
There are the following echoes:
NAME UUID TYPE DEVICE
br-mgmt 2b4c8058-f6ab-471f-afdb-e110cfdcc550 bridge br-mgmt
ens160 ce68d146-f671-3eec-b26f-de540af181a1 ethernet ens160
lo 5d8a90ae-138c-4544-a415-dd0e3c23050f loopback lo
This indicates that the creation was successful. Then, run the following command to create the bridge slave:
nmcli con add type bridge-slave ifname ens160 master br-mgmt
If continue executing nmcli c
, we get the following echo:
NAME UUID TYPE DEVICE
br-mgmt 2b4c8058-f6ab-471f-afdb-e110cfdcc550 bridge br-mgmt
ens160 ce68d146-f671-3eec-b26f-de540af181a1 ethernet ens160
lo 5d8a90ae-138c-4544-a415-dd0e3c23050f loopback lo
bridge-slave-ens160 5f3fc816-406c-4cc0-8d6d-1d68841a6d55 ethernet --
When you execute the command nmcli c up br-mgmt, you get the following echo:
Connection successfully activated (master waiting for slaves) (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/22)
Then, we can check the network status using the ip addr command:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:0c:29:62:bb:02 brd ff:ff:ff:ff:ff:ff
altname enp3s0
inet 192.168.75.141/24 brd 192.168.75.255 scope global dynamic noprefixroute ens160
valid_lft 1006sec preferred_lft 1006sec
inet6 fe80::20c:29ff:fe62:bb02/64 scope link noprefixroute
valid_lft forever preferred_lft forever
16: br-mgmt: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether c2:51:e9:6f:47:f4 brd ff:ff:ff:ff:ff:ff
inet 192.168.48.1/24 brd 192.168.48.255 scope global noprefixroute br-mgmt
valid_lft forever preferred_lft forever
This indicates that the bridge device br-mgmt is still in the down state and cannot be started. Even if you use the nmcli c up
command to start.
Check the file /etc/NetworkManager/system-connections/br-mgmt.nmconnection
:
connection.id: br-mgmt
connection.id: br-mgmt
connection.uuid: 2b4c8058-f6ab-471f-afdb-e110cfdcc550
connection.stable-id: --
connection.type: bridge
connection.interface-name: br-mgmt
connection.autoconnect: yes
connection.autoconnect-priority: 0
connection.autoconnect-retries: -1 (default)
connection.multi-connect: 0 (default)
connection.auth-retries: -1
connection.timestamp: 1685948786
connection.read-only: no
connection.permissions: --
connection.zone: --
connection.master: --
connection.slave-type: --
connection.autoconnect-slaves: -1 (default)
connection.secondaries: --
connection.gateway-ping-timeout: 0
connection.metered: unknown
connection.lldp: default
connection.mdns: -1 (default)
connection.llmnr: -1 (default)
connection.dns-over-tls: -1 (default)
connection.mptcp-flags: 0x0 (default)
connection.wait-device-timeout: -1
connection.wait-activation-delay: -1
802-3-ethernet.port: --
802-3-ethernet.speed: 0
802-3-ethernet.duplex: --
802-3-ethernet.auto-negotiate: no
802-3-ethernet.mac-address: --
802-3-ethernet.cloned-mac-address: --
802-3-ethernet.generate-mac-address-mask:--
802-3-ethernet.mac-address-blacklist: --
802-3-ethernet.mtu: auto
802-3-ethernet.s390-subchannels: --
802-3-ethernet.s390-nettype: --
802-3-ethernet.s390-options: --
802-3-ethernet.wake-on-lan: default
802-3-ethernet.wake-on-lan-password: --
802-3-ethernet.accept-all-mac-addresses:-1 (default)
ipv4.method: manual
ipv4.dns: 223.5.5.5
ipv4.dns-search: --
ipv4.dns-options: --
ipv4.dns-priority: 0
ipv4.addresses: 192.168.48.1/24
ipv4.gateway: 192.168.48.1
ipv4.routes: --
ipv4.route-metric: -1
ipv4.route-table: 0 (unspec)
ipv4.routing-rules: --
ipv4.replace-local-rule: -1 (default)
ipv4.ignore-auto-routes: no
ipv4.ignore-auto-dns: no
ipv4.dhcp-client-id: --
ipv4.dhcp-iaid: --
ipv4.dhcp-timeout: 0 (default)
ipv4.dhcp-send-hostname: yes
ipv4.dhcp-hostname: --
ipv4.dhcp-fqdn: --
ipv4.dhcp-hostname-flags: 0x0 (none)
ipv4.never-default: no
ipv4.may-fail: yes
ipv4.required-timeout: -1 (default)
ipv4.dad-timeout: -1 (default)
ipv4.dhcp-vendor-class-identifier: --
ipv4.link-local: 0 (default)
ipv4.dhcp-reject-servers: --
ipv4.auto-route-ext-gw: -1 (default)
ipv6.method: auto
ipv6.dns: --
ipv6.dns-search: --
ipv6.dns-options: --
ipv6.dns-priority: 0
ipv6.addresses: --
ipv6.gateway: --
ipv6.routes: --
ipv6.route-metric: -1
ipv6.route-table: 0 (unspec)
ipv6.routing-rules: --
ipv6.replace-local-rule: -1 (default)
ipv6.ignore-auto-routes: no
ipv6.ignore-auto-dns: no
ipv6.never-default: no
ipv6.may-fail: yes
ipv6.required-timeout: -1 (default)
ipv6.ip6-privacy: -1 (unknown)
ipv6.addr-gen-mode: default
ipv6.ra-timeout: 0 (default)
ipv6.mtu: auto
ipv6.dhcp-duid: --
ipv6.dhcp-iaid: --
ipv6.dhcp-timeout: 0 (default)
ipv6.dhcp-send-hostname: yes
ipv6.dhcp-hostname: --
ipv6.dhcp-hostname-flags: 0x0 (none)
ipv6.auto-route-ext-gw: -1 (default)
ipv6.token: --
bridge.mac-address: --
bridge.stp: yes
bridge.priority: 32768
bridge.forward-delay: 15
bridge.hello-time: 2
bridge.max-age: 20
bridge.ageing-time: 300
bridge.group-forward-mask: 0
bridge.multicast-snooping: yes
bridge.vlan-filtering: no
bridge.vlan-default-pvid: 1
bridge.vlans: --
proxy.method: none
proxy.browser-only: no
proxy.pac-url: --
proxy.pac-script: --
GENERAL.NAME: br-mgmt
GENERAL.UUID: 2b4c8058-f6ab-471f-afdb-e110cfdcc550
GENERAL.DEVICES: br-mgmt
GENERAL.IP-IFACE: br-mgmt
GENERAL.STATE: activated
GENERAL.DEFAULT: no
GENERAL.DEFAULT6: no
GENERAL.SPEC-OBJECT: --
GENERAL.VPN: no
GENERAL.DBUS-PATH: /org/freedesktop/NetworkManager/ActiveConnection/22
GENERAL.CON-PATH: /org/freedesktop/NetworkManager/Settings/14
GENERAL.ZONE: --
GENERAL.MASTER-PATH: --
IP4.ADDRESS[1]: 192.168.48.1/24
IP4.GATEWAY: 192.168.48.1
IP4.ROUTE[1]: dst = 192.168.48.0/24, nh = 0.0.0.0, mt = 425
IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 192.168.48.1, mt = 425
IP4.DNS[1]: 223.5.5.5
IP6.GATEWAY: --
答案1
得分: 0
你好 我是OpenStack-Ansible项目的一部分,并协助在项目中维护Rocky Linux。
首先,如果您还没有尝试设置“All-In-One”,我强烈建议您首先在虚拟机上尝试。这将为您提供对项目以及所有组件如何配合的很好的介绍。OpenStack-Ansible(OSA)是OpenStack的部署模型,本身就很复杂,因此在尝试执行多节点安装之前,熟悉组件可能是有好处的。值得注意的是,也可以使用多节点的“All-In-One”(AIO),这对学习也有好处。我们在CI测试中使用它来验证需要存在于多个节点上的组件。有关更多信息,请参阅openstack-ansible-ops存储库,以及许多更多的示例和信息。
关于您的桥接问题:从Zed版本开始,有两种方法可以做到这一点。在Zed中,默认的Neutron插件从LinuxBridge切换到了OVN - Open Virtual Network,可以使用它来将主机网络的配置委派给OpenStack-Ansible。无论如何,OSA不强制要求配置接口的任何特定方法,只要它们在目标主机上配置并正常工作即可。
在您的具体情况中,似乎您的桥接已经关闭,因为另一个NetworkManager接口已经抢占了物理设备:
名称 UUID 类型 设备
br-mgmt 2b4c8058-f6ab-471f-afdb-e110cfdcc550 桥接 br-mgmt
ens160 ce68d146-f671-3eec-b26f-de540af181a1 以太网 ens160
lo 5d8a90ae-138c-4544-a415-dd0e3c23050f 回环 lo
bridge-slave-ens160 5f3fc816-406c-4cc0-8d6d-1d68841a6d55 以太网 --
在这里,我们看到ens160
连接已经占用了ens160设备,这意味着bridge-slave-ens160
连接无法附属到br-mgmt。
关于我如何在我的环境中设置桥接和绑定的示例,您可以查看Ansible Playbook和相关的变量文件,尽管这还在进行中,因为我正在迁移到OSA管理的接口。
如果您有更多问题,请随时在IRC上评论或联系。OpenStack-Ansible位于ofct.net上的#openstack-ansible频道。
英文:
Hey there I'm part of the OpenStack-Ansible project and help maintain Rocky Linux in the project.
Firstly, if you have not yet tried setting up an 'All-In-One', I would strongly suggest you try that out on a virtual machine first. This will give you a great introduction to the project and how all the pieces fit together. OpenStack-Ansible (OSA) is a deployment model for OpenStack, which is complex in and of itself, so it can be good to get comfortable with the components before trying to perform a multi-node installation. Of note, it's also possible to have a multi-node 'All-In-One' (AIO) which can also be beneficial for learning. We use this in our CI testing to validating components which need to exist on multiple nodes. More info about this can be found in the openstack-ansible-ops repository, along with many more examples and information.
For your question about bridges: As of the Zed release, there are two ways to do this. In Zed, the default Neutron plugin switched from LinuxBridge to OVN--Open Virtual Network, which can be used to delegate the configuration of the host networking to OpenStack-Ansible. In any case, OSA does not mandate any specific method to configure the interfaces, as long as they are configured and functional on the target hosts.
In your specific instance, it appears that your bridge is down because another NetworkManager interface has already preempted the physical device:
NAME UUID TYPE DEVICE
br-mgmt 2b4c8058-f6ab-471f-afdb-e110cfdcc550 bridge br-mgmt
ens160 ce68d146-f671-3eec-b26f-de540af181a1 ethernet ens160
lo 5d8a90ae-138c-4544-a415-dd0e3c23050f loopback lo
bridge-slave-ens160 5f3fc816-406c-4cc0-8d6d-1d68841a6d55 ethernet --
Here we see the ens160
Connection has already taken the ens160 device, meaning the bridge-slave-ens160 Connection cannot enslave to br-mgmt.
For an example of how I setup the bridges and bonds in my environment, you can checkout the Ansible Playbook and associated vars file, though this is a work in progress as I am migrating to OSA-Managed interfaces.
If you have any more questions, please feel free to comment and/or reach out on IRC. OpenStack-Ansible is in the #openstack-ansible channel on ofct.net
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论