Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to deploy instance to OVS Local Network. The content of the article is of high quality, so Xiaobian shares it with you for reference. I hope you have a certain understanding of relevant knowledge after reading this article.

Today we will deploy an instance to the network and analyze the network structure.

launch an instance, select the first_local_net network

instance Deployment successful, assigned IP address is 172.16.1.3

What happened to the underlying network?

For instance "cirros-vm1," Neutron creates a port in the subnet, assigns IP and MAC addresses, and assigns the port to cirros-vm1.

A port "(fc1c6ebb-719d)" has been added to the port list, and the IP is 172.16.1.3. Click the port name to view the MAC information.

Let's start by speculating from what we learned in the linux bridge driver chapter: How would Open vSwitch driver connect cirros-vm1 to first_local_net?

With a similar implementation, neutron-openvswitch-agent creates a tap device tapfc1c6ebb-71 based on the port information and connects it to the br-int bridge. tapfc1c6ebb-71 is the virtual NIC for cirros-vm1.

Let's see if that's true.

cirros-vm1 is deployed to the control node, check the configuration of the bridge through ovs-vsctl show

Unfortunately, there is no tapfc1c6ebb-71 on br-int, but an extra qvofc1c6ebb-71.

We don't know what qvofc1c6ebb-71 is yet, so let's check the linux bridge configuration with brctl show:

Here we see a newly created bridge qbrfc1c6ebb-71 connecting two devices qvbfc1c6ebb-71 and tapfc1c6ebb-71.

From the naming point of view, they should all be related to cirros-vm1 virtual network card.

View configuration of cirros-vm1 via virsh edit

It is true that tapfc1c6ebb-71 is a virtual network card for cirros-vm1. So what is the relationship between qvbfc1c 6 ebb-71 devices on linux bridge qbrfc1c6ebb-71 and qvofc1c6ebb-71 on Open vSwitch br-int?

The following takes a bit of skill. We use ethtool -S to view the statistics of qvbfc1c6ebb-71 and qvofc1c6ebb-71 respectively.

qvbfc1c6ebb-71 and qvofc1c6ebb-71 are veth devices, and the index of veth devices at the other end of qvbfc 1c 6 ebb-71 is 12 and 13 respectively. Use ip a to find devices with index 12 and 13.

Here, I believe some students have seen it: qvbfc1c6ebb-71 and qvofc1c6ebb-71 form a veth pair.

As we mentioned earlier, a veth pair is a special network device that appears in pairs, like a virtual network cable connecting two network devices.

Here qvbfc1c6ebb-71 and qvofc1c6ebb-71 are used to connect bridges qbrfc1c6ebb-71 and br-int.

tapfc1c6ebb-71 is indirectly connected to br-int via qbrfc1c6ebb-71.

So why can't tapfc1c6ebb-71 connect directly to br-int like the DHCP device tap7970 bdcd-f2 on the left?

The reason for this is that Open vSwitch does not currently support placing iptables rules on tap devices directly connected to it.

If this is not done, the Security Group function cannot be implemented. In order to support Security Group, we had to introduce an additional Linux Bridge to support iptables.

The consequence is that the network structure is more complex, with a linux bridge and a veth pair on the path.

How to deploy instance to OVS Local Network is shared here. I hope the above content can help you and learn more. If you think the article is good, you can share it so that more people can see it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.