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

This article mainly shows you "what is the computing node link in Openstack", which is easy to understand and clear. I hope it can help you solve your doubts. Let me lead you to study and learn this article "what is the computing node link in Openstack".

The compute node virtual machine instance information is as follows:

NAME NETWORK (fixed_ip Floating_ip) fixed_ip_mac device hyp-vm1 net-hyp=192.168.66.2 122.114.124.21 fa:16:3e:23:91:7b tap156d4a84-8fhyp-vm2 net-hyp=192.168.66.4-fa:16:3e:61:d8:b7 tap9b3f4311-42liyang-vm net-liyang0993=192.168.100.3 122.114.124.45 fa:16:3e:6c:c9:bb tap0620d5f8-02

(virtual machine ip and Nic information can be collected from dashboard and virsh management tools of compute nodes.)

[root@compute home] # brctl showbridge name bridge id STP enabled interfacesqbr0620d5f8-02 8000.e2ac0a53cb2b no qvb0620d5f8-02 tap0620d5f8-02qbr156d4a84-8f 8000.62f2e45acb48 no qvb156d4a84-8f tap156d4a84-8fqbr9b3f4311-42 8000.9ea9c59ddd0b no qvb9b3f4311-42 tap9b3f4311-42

Virtual machines are directly connected to linux bridge, and each virtual machine has an independent qbr.

Qbr is the specific implementation of the neutron security group, which will be left to the special description.

The qvb device of each qbr is directly connected to a corresponding qvo device on the br-int as a peer device, as shown below:

[root@compute home] # ovs-vsctl show1db94f48-8307-4bad-b109-30897062c4e4 "" br-tun Information outline "" Bridge br-int fail_mode: secure Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port br-int Interface br-int type: internal Port " Qvo156d4a84-8f "tag: 2 Interface" qvo156d4a84-8f "Port" qvo9b3f4311-42 "tag: 1 Interface" qvo9b3f4311-42 "Port" qvo0620d5f8-02 "tag: 2 Interface" qvo0620d5f8-02 "ovs_version:" 2.4.0 "

Here is an example of how to create a peer, linux bridge, enable and set the promiscuous mode of the peer interface, and set the add-port/addif to ovs/bridge

Ip link add qvb0620d5f8-02 type veth peer name qvob0620d5f8-02brctl add-br qbr0620d5f8-02ifconfig qvb0620d5f8-02 promisc up ifconfig qvob0620d5f8-02 promisc upovs-vsctl add-port br-int qvob0620d5f8-02-- set Port qvob0620d5f8-02 tag=2ovs-vsctl add-port qbr0620d5f8-02 qvb0620d5f8-02

In this way, the link interworking between ovs virtual switch br-int and linux bridge-qbr is realized.

After the establishment of linux bridge (Security Group Bridge), br-int switch, and the link between them, we focus on br-int 's processing of virtual machine (liyang-vm,tap0620d5f8-02 network card owner) inbound/outbound traffic.

We already know that on br-int:

Port "qvo0620d5f8-02"

Tag: 2

Interface "qvo0620d5f8-02"

So how do you explain this information? What is tag=2? Tag refers to vlan tag, traffic passing through this port, outbound mod_vlan_vid, incoming strip_vlan. But why is VLAN ID 2?

Here vlan tag is the local vlan (on the current compute node), not global (that is, the entire cluster).

Liyang-vm is connected to VPC net-liyang0993.

[root@controller ~ (keystone_admin)] # neutron net-list | grep liyang | 6a169cca-282d-4bea-a99e-d725ac1721b9 | net-liyang0993 | 1a7ed44b-e61d-4f98-aa47-d9123827acc2 192.168.100.0 keystone_admin 24 | [root@controller ~ (keystone_admin)] # neutron net-show 6a169ccamuri 282dMel 4bealua99eMuid725ac1721b9 "Muhammad"- -+ | Field | Value | +-- +-- + | admin_state_up | | True | | id | 6a169cca-282d-4bea-a99e-d725ac1721b9 | | name | net-liyang0993 | | provider:network_type | vxlan | | provider:physical_network | | | provider:segmentation_id | 10 | | router:external | False | | shared | False | | status | ACTIVE | | subnets | | | 1a7ed44b-e61d-4f98-aa47-d9123827acc2 | | tenant_id | c9baab896503480b80919a4f0762dcf8 | +-- +--

We know that the VPC VLAN Tag is the smallest available value based on the configured VNI range (see / etc/neutron/plugin.ini: vni_ranges = 10 etc/neutron/plugin.ini 100).

Then I guess there must be vlan-tag of br-int port and the conversion between br-tun tunnel_id and provider:segmentation_id in the link, which will be explored later.

Continuing to explore br-int above, let's take a look at flow rules on br-int:

[root@compute] # ovs-ofctl dump-flows br-intNXST_FLOW reply (xid=0x4): cookie=0x0, duration=145733.004s, table=0, n_packets=238070, n_bytes=37626893, idle_age=0, hard_age=65534, priority=1 actions=NORMALcookie=0x0, duration=145732.923s, table=22, n_packets=0, n_bytes=0, idle_age=65534,hard_age=65534, priority=0 actions=drop

Two common flow table rules:

(1) priority is given to Normal forwarding of traffic according to priority.

(2) different values of table indicate that the current rules belong to different flow tables and deal with different traffic [traffic classification, batch processing according to table]

Then we look at the patch-int port on patch-tun,br-tun on br-int.

The connection between ovs virtual switches is realized through patch-ports. Here is an example of how to realize link interworking between br-int and br-tun.

[root@compute ~] # ovs-vsctl-if-exists del-port patch-tun-- add-port br-int\ patch-tun-- set Interface patch-tun type=patch options:peer=patch-int [root@compute ~] # ovs-vsctl-if-exists del-port patch-int-- add-port br-tun\ patch-int-- set Interface patch-int type=patch options:peer=patch-tun

Reference: http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-patch-ports/

Here two statements that add patch port to each other connect br-int and br-tun together

Then go on to look down at the port and flow rules on br-tun (see the flow table rules below), and sort it out first and then talk about it in detail:

First of all, the ofport information on br-tun is as follows:

[root@compute home] # ovs-ofctl show br-tunOFPT_FEATURES_REPLY (xid=0x2): dpid:000056bb20081443n_tables:254 N_buffers:256capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IPactions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst 1 (patch-int): addr:12:cc:14:b8:9a:67 config: 0 state: 0 speed: 0 Mbps now 0 Mbps max 2 (vxlan-0aa0006b): addr:42:9e:52:f8:0c:9a config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max LOCAL (br-tun): addr:56:bb:20:08:14:43 config: PORT_DOWN state: LINK_DOWN speed: 0 Mbps now, 0 Mbps maxOFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0

Secondly, it is important to understand that different table numbers in br-tun flow table rules represent the tables to which the current rules belong and represent different functions.

For more information, please see the source code (neutron/plugins/openvswitch/common/constants.py):

PATCH_LV_TO_TUN = 1GRE_TUN_TO_LV = 2VXLAN_TUN_TO_LV = 3LEARN_FROM_TUN = 10UCAST_TO_TUN = 20FLOOD_TO_TUN = 21CANARY_TABLE = 22

Then we start the analysis of the flow table rules on br-tun.

Let's analyze the flow table rules one by one:

Table=0,priority=1,in_port=1 actions=resubmit (, 1)

If it is priority=1,table 0, and the traffic coming in from the port of ofport=1 is resubmitted to table 1 for processing

Table=0,priority=1,in_port=2 actions=resubmit (3)

If it is priority=1,table 0, and the traffic coming in from the port of ofport=1 is resubmitted to table 3 for processing

Table=0,priority=0 actions=drop

Set the default flow table rule for table 0: DROP

Table=1,priority=1,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit (20)

If it is priority=1 unicast (unicast) traffic, then resubmit it to table 20 for processing.

Dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 matches Multicast (including broadcast) Ethernet Fram

Dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 matches unicast Ethernet frame

Table=1,priority=1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit (21)

If it is broadcast traffic, then resubmit it to table 21 for processing

Table=2,priority=0 actions=drop

Set the default flow table rule for table 2: DROP

Table=3,priority=1,tun_id=0xa actions=mod_vlan_vid:1,resubmit (10)

If the traffic is transmitted from the network node to the current computing node through the vxlan tunnel (tunnel number 0xa), the vlan is modified to 1 and returned to table 10 for processing.

Special note: the conversion relationship between tunnel_id and local vlan is established here, that is, tunnel 0xa corresponds to local vlan (LV) 1.

Table=3,priority=1,tun_id=0xb actions=mod_vlan_vid:2,resubmit (10)

Same as above

Table=3,priority=0 actions=drop

Set the default flow table rule for table 3: DROP

Table=10,priority=1 actions=learn (table=20,hard_timeout=300,priority=1,NXM_OF_VLAN_ TCI [0.11], NXM_OF_ETH_DST [] = NXM_OF_ETH_SRC [], load:0- > NXM_OF_VLAN_TCI [], load:NXM_NX_TUN_ID []-> NXM_NX_TUN_ID [], output:NXM_OF_IN_PORT []), output:1

Here is a space to explain ovs's `learn` action:

The ovs-ofctl man manual says that the * * in learn (*) is added / modified as a flow rule.

Personal opinion: used to imitate the learning function of the physical switch, the physical switch knows how to deal with the traffic with specific characteristics; and the corresponding ovs

The virtual switch is a flow table rule (matching traffic with specific characteristics and specifying a processing action); therefore * * some parameters contain at least one matching rule and one action

Example of matching rule description in learn:

NXM_OF_VLAN_ TCI [0.. 11] represents the lower 12 bits of matching TCI information, that is, the VLAN ID domain.

NXM_OF_ETH_DST [] = NXM_OF_ETH_SRC [] means to learn the mac address of the current packet.

Output:NXM_OF_IN_PORT [] indicates the outbound operation of the new flow table rule (return it again from the entry `ovs port`)

Load:NXM_NX_TUN_ID []-> NXM_NX_TUN_ID [] means that when a new flow table rule processes outgoing traffic, its tunnel id will be modified to the tunnel id of the current flow table.

Hard_timeout indicates the entry expiration time of the switch. Generally, learn must add an option to ensure that the entry is updated regularly.

As shown earlier, learn dynamically adds flow to table 20 (mac learning table), so in all flows of table=20, flow tables in the format "table=20,hard_timeout=300, priority=1,vlan_tci= {tci} / {mask}, dl_dst= {mac} actions=load:0- > NXM_OF_VLAN_TCI [], load:0xa- > NXM_NX_TUN_ID [], output: {port}" are dynamically added by learning flow table rules. The flow table that does not conform to this format is the initial flow table added at the beginning of the creation of br-tun/table-20, which needs to be noted.

Reference:

Http://www.tuicool.com/articles/am6n2iB

Http://www.cnblogs.com/CasonChan/p/4754486.html

Http://www.cnblogs.com/popsuper1982/p/3810271.html

Http://blog.csdn.net/gaopeiliang/article/details/45720785

Http://m.blog.csdn.net/blog/canxinghen/46761591

Table=20,priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c3:23:47 actions=load:0- > NXM_OF_VLAN_TCI [], load:0xa- > NXM_NX_TUN_ID [], output:2table=20,priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:11:3f:0f actions=load:0- > NXM_OF_VLAN_TCI [], load:0xb- > NXM_NX_TUN_ID [], output:2

Traffic that matches table=20,priority=1,vlan id=2 and accesses VPC gateway (private gateway qr-f7f87f9f-54 mac fa:16:3e:11:3f:0f under virtual route qrouter-e0014375-0cb7-44b1-84cb-f7f49dd59344).

What is the processing of `load`? Load:src [start:end]-> dst [start:end] or load:value- > dst [start:end]

The function is to load the first parameter after load (- > before) or the part taken out by the (start1:end1) bit into the start2:end2 of the second parameter (assignment operation)

Here are the special fields in two Ethernet frames:

The TCI field of the NXM_OF_VLAN_TCI:VLAN frame, 2 bytes, see below; here load:0- > NXM_OF_VLAN_TCI [] indicates priority,cfi,vlan-id, or strip_vlan

NXM_NX_TUN_ID: tunnel-id domain of Ethernet network frame; here load:0xb- > NXM_NX_TUN_ID [] means that tunnel id is set to 0xb. Like the following set_tunnel:0xb, the personal guess is that the two forms coexist due to the historical change of ovs version.

Here is a brief account of vlan_tci:

First of all, what is vlan tci? (quoted from http://blog.csdn.net/kulung/article/details/6442804)

VLAN-TAG contains 2 bytes of TPID (label protocol identification) and 2 bytes of TCI (label control information)

TPID identifies the IEEE type. The common format is: 802.1Q, 802. {N} {A.. Z}

The TCI information also contains subdomain information:

Priority: 3bit, indicating 0-7 priority

Cfi, that is, Canonical Format Indicator accounts for 1bit. 0 means standard, 1 means non-standard.

Vlan id: account for 12bit means 04095, which is why the maximum number of vlan is 4096.

Looking back here, vlan_tci represents the {tci} / {mask} format, so what does that mean? The ovs-ofctl man manual explains: tci and mask digits

The matching mechanism used when each bit control flow table of mask matches tci corresponding bit with the same (16bit): precise matching or fuzzy matching (wildcast, equal to *)

So here 0x0002/0x0fff represents an vlan frame that exactly matches vlan id=2 (0x0fff: last 12-bit fff) and unrestricted format (0x0fff: the middle bit is 0 for unlimited format, 0x0fff has a high 3-bit all-0, indicating that all frames with priority 0-7 can be matched)

Continue:

Table=20,priority=0 actions=resubmit (21)

Set default flow table rules for table 20: resubmit to table 21 for processing

Table=21,dl_vlan=1 actions=strip_vlan,set_tunnel:0xa,output:2

If the traffic is sent to br-tun from br-int, vlan tag=1 then go to vlan-tag and set the tunnel_id 0xa output to the end of ofport=2

Port (that is, tunnel port)

Table=21,dl_vlan=2 actions=strip_vlan,set_tunnel:0xb,output:2

If the traffic is sent to br-tun from br-int, vlan tag=2 then go to vlan-tag and set the tunnel_id 0xb output to the end of ofport=2

Port (that is, tunnel port)

Table=21,priority=0 actions=drop

Set the default flow table rule for table 21: DROP

At this point, the br-tun flow table is explained, so what kind of data processing system is expressed by the flow table rules of br-tun? You can refer to the following figure:

Here we will explain the establishment of vxlan tunnels between computing nodes and network nodes:

[root@compute neutron] # ovs-vsctl-if-exists del-port vxlan-0aa0006b-- add-port\ br-tun vxlan-0aa0006b-- set Interface vxlan-0aa0006b type=vxlan\ options:remote_ip=10.160.0.107 options:in_key=flow\ options:out_key=flow options:local_ip= 10.160.0.106 [root @ network Neutron] # ovs-vsctl-if-exists del-port vxlan-0aa0006a-- add-port\ br-tun vxlan-0aa0006a-- set Interface vxlan-0aa0006a type=vxlan\ options:remote_ip=10.160.0.106 options:in_key=flow\ options:out_key=flow options:local_ip=

Among them: compute/10.160.0.106 network/10.160.0.107 is the management ip of related nodes.

These are all the contents of the article "calculating what a Node Link is in Openstack". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

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.