Shulou(Shulou.com)05/31 Report--

Today, the editor will take you to understand how to deeply understand the Basic Use Cases in the openstack network rack. The knowledge points in the article are introduced in great detail. Friends who feel helpful can browse the content of the article with the editor, hoping to help more friends who want to solve this problem to find the answer to the problem. Let's follow the editor to learn more about "how to understand Basic Use Cases in the openstack network frame".

We will use three simple use case to show how these basic network components work to implement openstack's SDN scheme.

In these use case, we will learn about the entire network configuration and how they work together. Use case is as follows:

Create a network-what happens when we create a network. How to create multiple isolated networks.

Create a virtual machine-once we have a network, we can create a virtual machine and connect it to the network.

DHCP request for the virtual machine-opensack can automatically configure IP for the virtual machine. This is done through a DHCP service controlled by openstack neutron. Let's take a look at how the service works and what DHCP requests and responses look like.

In this article, we will show the principle of network connection, and we will learn how network packets go from A to B. Let's first understand what the completed network configuration looks like. Then we discuss how and when these network configurations were created? Personally, I think it is very valuable to see how real network interfaces work and connect them through examples and concrete practices. Then, the truth comes out, and we know how network connectivity works, and in a later article, I'll further explain how neutron configures these components to provide such network connectivity.

I recommend trying these examples or using Oracle Openstack Tech Preview in your own environment. A full understanding of these network scenarios is very helpful for us to investigate network problems in the openstack environment.

Use case # 1: Create Network

Creating a network is very simple. We can do this using GUI or the command line. Openstack's network is for use only by the tenant who created it. Of course, if the network is "shared", it can also be used by all other tenants. A network can have multiple subnets, but for demonstration purposes and simplicity, we only create one subnet for each network. Create a network from the command line:

# neutron net-create net1Created a new network:+--+--+ | Field | Value | +- -+-+ | admin_state_up | True | | id | 5f833617-6179-4797-b7c0-7d420d84040c | | name | net1 | | provider:network_type | vlan | | provider:physical_network | default | | provider:segmentation_id | 1000 | | shared | False | | status | | ACTIVE | | subnets | tenant_id | 9796e5145ee546508939cd49ad59d51f | + -+

Create a subnet:: for this network

# neutron subnet-create net1 10.10.10.0/24Created a new subnet:+-+---+ | Field | Value | +-- -+-+ | allocation_pools | {"start": "10.10.10.2" "end": "10.10.10.254"} | | cidr | 10.10.10.and24 | | dns_nameservers | | enable_dhcp | True | | gateway_ip | 10.10.10 | .1 | | host_routes | id | 2d7a0a58-0674-439a-ad23-d6471aaae9bc | | ip_version | 4 | | name | | | network_id | 5f833617-6179-4797-b7c0-7d420d84040c | | tenant_id | 9796e5145ee546508939cd49ad59d51f | +-+-+ |

Now we have a network and subnet, and the network topology looks like this:

Now let's take a closer look at what happened. At the control node, a new namespace is created:

# ip netns listqdhcp-5f833617-6179-4797-b7c0-7d420d84040c

The name of this namespace is qdhcp- (see above), so let's dig into the namespace and see what there is.

# ip netns exec qdhcp-5f833617-6179-4797-b7c0-7d420d84040c ip addr1: lo: mtu 65536 qdisc noqueue state UNKNOWN link/loopback 0000 lo 00100 brd 000000 brd 0000000000 inet 127.0.0.1 8 scope host lo inet6:: 1 scope host valid_lft forever preferred_lft forever12 128 scope host valid_lft forever preferred_lft forever12: tap26c9b807-7c: mtu 1500 qdisc noqueue state UNKNOWN link/ether fa:16:3e:1d:5c:81 brd ff:ff: Ff:ff:ff:ff inet 10.10.10.3 ff:ff:ff:ff inet 24 brd 10.10.10.255 scope global tap26c9b807-7c inet6 fe80::f816:3eff:fe1d:5c81/64 scope link valid_lft forever preferred_lft forever

We send that there are two network interfaces under namespace, one is a loop device, and the other is called "tap26c9b807-7c". This interface is set to the IP address 10.10.10.3, which will receive dhcp requests (I'll talk about it later). Next, let's track the network connectivity of "tap26c9b807-7c". Let's take a look at the OVS bridge "br-int" connected to this interface from OVS.

# ovs-vsctl show8a069c7c-ea05-4375-93e2-b9fc9e4b3ca1 Bridge "br-eth3" Port "br-eth3" Interface "br-eth3" type: internal Port "eth3" Interface "eth3" Port "phy-br-eth3" Interface "phy-br-eth3" Bridge br-ex Port br-ex Interface br-ex Type: internal Bridge br-int Port "int-br-eth3" Interface "int-br-eth3" Port "tap26c9b807-7c" tag: 1 Interface "tap26c9b807-7c" type: internal Port br-int Interface br-int type: internal ovs_version: "1.11.0"

As can be seen from the above, the two ends of veth pair are "int-br-eth3" and "phy-br-eth3", and this veth pari connects two OVS bridges "br-eth3" and "br-int". In the previous article, we explained how to view both ends of the veth pairs through the ethtool command. Such as the following example:

# ethtool-S int-br-eth3NIC statistics: peer_ifindex: 10.9. # ip link..10: phy-br-eth3: mtu 1500 qdisc pfifo_fast state UP qlen 1000..

Notice that "phy-br-eth3" is connected to the bridge "br-eth3". One of the ports of this bridge is the physical network card eth3. This means that the network we created created a namespace connected to the physical network card eth3. The virtual machine network where eth3 is located will connect all virtual machines.

About network isolation:

Openstack supports the creation of multiple isolated networks, and multiple mechanisms can be used to isolate networks from each other. These isolation mechanisms include VLANs/VxLANs/GRE tunnels, which is configured when we deploy the openstack environment. In this article, we chose VLANs. When using the VLAN tag as the isolation mechanism, Neutron selects a VLAN tag from the predefined VLAN pool and assigns it to a newly created network. Multiple isolated networks are allowed to be created on one physical network card by assigning a VLAN tag to the network,Neutron. The biggest difference from other platforms is that users are not responsible for managing how VLAN is assigned to networks. Neutron is responsible for managing the allocation of VLAN tags and for recycling. In our example, net1 uses the VLAN tag 1000, which means that the virtual machine connected to the network will send the packet with the VLAN tag 1000 and send it to the physical network. The same is true for namespace, if we want namespace to connect to a particular network, we need to make sure that packets sent / received by that namespace are correctly tagged.

In the above example, the network interface "tap26c9b807-7c" in namespace is assigned the VLAN label 1. If we look at it from OVS, we will see that VLAN1 will be changed to VLAN1000 when the packet enters the uxniji network where eth3 is located. And vice versa. Through the dump-flows command of OVS, we can see that the network packets entering the virtual machine network have modified the VLAN tag on the br-eth3:

# ovs-ofctl dump-flows br-eth3NXST_FLOW reply (xid=0x4): cookie=0x0, duration=18669.401s, table=0, n_packets=857, n_bytes=163350, idle_age=25, priority=4,in_port=2,dl_vlan=1 actions=mod_vlan_vid:1000,NORMAL cookie=0x0, duration=165108.226s, table=0, n_packets=14, n_bytes=1000, idle_age=5343, hard_age=65534, priority=2,in_port=2 actions=drop cookie=0x0, duration=165109.813s, table=0, n_packets=1671, n_bytes=213304, idle_age=25, hard_age=65534, priority=1 actions=NORMAL

From the network interface to namespace, we can see that the VLAN tag has been modified as follows:

# ovs-ofctl dump-flows br-intNXST_FLOW reply (xid=0x4): cookie=0x0, duration=18690.876s, table=0, n_packets=1610, n_bytes=210752, idle_age=1, priority=3,in_port=1,dl_vlan=1000 actions=mod_vlan_vid:1,NORMAL cookie=0x0, duration=165130.01s, table=0, n_packets=75, n_bytes=3686, idle_age=4212, hard_age=65534, priority=2,in_port=1 actions=drop cookie=0x0, duration=165131.96s, table=0, n_packets=863, n_bytes=160727, idle_age=1, hard_age=65534, priority=1 actions=NORMAL

In summary, when the user creates a network,neutrong, a namespace is created, and the namespace is connected to the virtual machine network through the OVS. OVS is also responsible for the modification of VLAN tags between namespace and virtual machine networks. Now, let's take a look at what happens when a virtual machine is created. How are virtual machines connected to the virtual machine network?

Use case # 2: Launch a VM

Create and start a virtual machine from Horizon or the command line. The following is an example of creating a virtual machine from Horzion:

Mount the network and start the virtual machine:

Once the virtual machine is up and running, we issue nova support to bind IP to the virtual machine:

# nova list+--+-+ | ID | | Name | Status | Task State | Power State | Networks | +-- -+ | 3707ac87-4f5d-4349-b7ed-3a673f55e5e1 | Oracle Linux | ACTIVE | None | Running | net1=10.10.10.2 | +-+- -+

The nova list command shows that the virtual machine is running and is assigned IP 10.10.10.2. Let's look at the connectivity between the virtual machine and the virtual machine network through the virtual machine definition file. The configuration file for the virtual machine can be found in the directory / var/lib/nova/instances//. By looking at the virtual machine definition file, libvirt.xml, we can see that the virtual machine is connected to the network interface "tap53903a95-82", which is connected to the Linux bridge "qbr53903a95-82":

View the bridge information through brctl as follows:

# brctl showbridge name bridge id STP enabled interfacesqbr53903a95-82 8000.7e7f3282b836 no qvb53903a95-82 tap53903a95-82

The bridge has two network interfaces, one connected to the virtual machine ("tap53903a95-82") and the other ("qvb53903a95-82") connected to the OVS bridge "br-int".

# ovs-vsctl show83c42f80-77e9-46c8-8560-7697d76de51c Bridge "br-eth3" Port "br-eth3" Interface "br-eth3" type: internal Port "eth3" Interface "eth3" Port "phy-br-eth3" Interface "phy-br-eth3" Bridge br-int Port br-int Interface br-int Type: internal Port "int-br-eth3" Interface "int-br-eth3" Port "qvb53903a95-82" tag: 3 Interface "qvb53903a95-82" ovs_version: "1.11.0"

As we have seen before, the OVS bridge "br-int" is connected to "br-eth3" and through veth pair (int-br-eth3,phy-br-eth3), br-eth3 is connected to the physical network card eth3. The whole inflow is as follows:

VM-> tap53903a95-82 (virtual interface)-> qbr53903a95-82 (Linux bridge)-> qvb53903a95-82 (interface connected from Linux bridge to OVS bridge br-int)-> int-br-eth3 (veth one end)-> phy-br-eth3 (veth the other end)-> eth3 physical interface.

The Linux bridage connected to the virtual machine is mainly used for Iptables-based security group settings. The security group is used to enhance the network isolation of virtual machines, and since iptables cannot be used for OVS bridges, we used Linux bridges. We will see the rule settings for the Linux bridge later.

VLAN tags: we mentioned in the first use case that net1 uses VLAN tag 1000, and through OVS we see that qvo41f1ebcf-7c uses VLAN tag 3. The conversion of VLAN tags from 3 to 1000 is done in OVS and implemented in br-eth3. To sum up, the virtual machine is connected to the virtual machine network through a set of network devices. Between the virtual machine and the network, the VLAN tag is modified.

Use case # 3: Serving a DHCP request coming from the virtual machine

In the previous use case, we saw a namespace and a virtual machine called dhcp-, which were eventually connected to the physical network eth3. They will all be labeled with the VLAN tag 1000. We see that the network interface in this namespace uses IP 10.10.10.3. Because the virtual machine and namespace are connected to each other and on the same subnet, it is possible to ping to each other. In the following figure, the network interface in the virtual machine is assigned IP 10.10.10.2. We try the IP of the network interface in ping namespace:

Namespace is connected to the virtual machine and can ping each other, which is very useful for positioning problems. We can ping namespace from the virtual machine, and we can use tcpdump or other tools to locate the network outage problem.

In response to dhcp requests from virtual machines, Neutron uses the Linux tool of "dnsmasq", which is a lightweight DNS and DHCP service. For more information, please see (http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html). We can see this through the PS command at the control node:

Dnsmasq-no-hosts-no-resolv-strict-order-bind-interfaces-interface=tap26c9b807 7c except-interface=lo-pid-file=/var/lib/neutron/dhcp/5f833617 6179 4797-b7c0 7d420d84040c/pid dhcp-hostsfile=/var/lib/neutron/dhcp/5f833617 6179 4797-b7c0 7d420d84040c/host dhcp-optsfile=/var/lib/neutron/dhcp/5f833617 6179 4797-b7c0 7d420d84040c/opts leasefile-ro dhcp-range=tag0,10.10.10.0,static 120s-dhcp-lease-max=256-conf-file=-domain=openstacklocal

The DHCP service connects to a tap interface ("--interface=tap26c9b807-7c") in namespace, as we can see from the hosts file:

# cat / var/lib/neutron/dhcp/5f833617-6179-4797-b7c0-7d420d84040c Red Hostfav 16V 3eVesque fev Vele c7L 87L Hostlich 10-10-10-2.openstacklocalMagne 10.10.10.2

From the previous console output, you can see that the virtual machine MAC is fa:16:3e:fe:c7:87. This mac address is associated with IP 10.10.10.2, and when the DHCP request containing the MAC arrives, dnsmasq returns 10.10.10.2. In this initial process (which can be triggered by restarting the network service), you can see the following DHCP request from namespace:

# ip netns exec qdhcp-5f833617-6179-4797-b7c0-7d420d84040c tcpdump-n19 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:fe:c7:87, length 31019 Velcro 27 7d420d84040c tcpdump 12.191666 IP 10.10.10.3.bootps > 10.10.10.2.bootpc: BOOTP/DHCP, Reply, length

In short, the DHCP service is provided by dnsmasq, which is configured by Neutron and listens on the network interface in DHCP namespace. Neutron also configures the MAC/IP mapping relationship in dnsmasq, so when a DHCP request is made, it is subject to the IP assigned to it.

Thank you for your reading. The above is the whole content of "how to deeply understand Basic Use Cases in openstack Network frame". Friends who learn to learn to do it quickly. I believe that the editor will certainly bring you better quality articles. Thank you for your support to the website!

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.