Openvswitch Principles and Code Analysis (1): Overall architecture

first, Opevswitch overall structure

Openvswitch's architecture is shown in the following diagram:

Each module has a different function Ovs-vswitchd as the main module, the implementation of the Switch daemon daemon

The following process can be seen on the Openvswitch server where PS aux is located

Root 1008 0.1 0.8 242948 31712? S<ll Aug06 32:17 ovs-vswitchd unix:/var/run/openvswitch/db.sock-vconsole:emer-vsyslog:err-vfile:info--mlockall- -no-chdir--log-file=/var/log/openvswitch/ovs-vswitchd.log--pidfile=/var/run/openvswitch/ovs-vswitchd.pid-- Detach--monitor

Note here that Ovs-vswitchd listens to a native Db.sock file.

Openvswitch.ko is a Linux kernel module that supports the exchange of data streams in the kernel

We use LSMOD to enumerate the modules loaded into the kernel:

~# Lsmod | grep Openvswitch Openvswitch 66901 0 GRE 13808 1 Openvswitch Vxlan 37619 1 Openvswitch LIBCRC32C 12644 2 Btrfs,openvswitch

Both Openvswitch.ko and ovsdb-server Lightweight database server, save configuration information, Ovs-vswitchd get configuration information through this database

The following process can be seen through the PS aux

Root 985 0.0 0.0 21172 2120? s< Aug06 1:20 ovsdb-server/etc/openvswitch/conf.db-vconsole:emer-vsyslog:err-vfile:info--remote=punix:/var/run /openvswitch/db.sock--private-key=db:open_vswitch,ssl,private_key--certificate=db:open_vswitch,ssl,certificate --bootstrap-ca-cert=db:open_vswitch,ssl,ca_cert--no-chdir--log-file=/var/log/openvswitch/ovsdb-server.log-- Pidfile=/var/run/openvswitch/ovsdb-server.pid--detach–monitor

As you can see, Ovsdb-server saves the configuration information in Conf.db and provides the service through Db.sock, Ovs-vswitchd reads the configuration information from this process through this db.sock.

/ETC/OPENVSWITCH/CONF.DB is in JSON format and you can print the database structure by command ovsdb-client dump.

The database structure contains the following table.

The database structure is as follows:

All the network bridges created through OVS-VSCTL, network cards, are stored in the database, OVS-VSWITCHD will be based on the configuration of the database to create a real network bridge, network card.

The OVS-DPCTL is used to configure the switch kernel module.

Ovs-vsctl the configuration of the query and update ovs-vswitchd.

Ovs-appctl sends a command message to run the related daemon.

Ovs-ofctl queries and controls OpenFlow switches and controllers.

Second, the code structure of Openvswitch

The main logic of Openvwitch for data flow Exchange is implemented in Ovs-vswitchd and Openvswitch.ko.

Ovs-vswitchd reads the configuration from the Ovsdb-server and then calls the Ofproto layer for the creation of the virtual network card or the operation of the flow table.

Ofproto is a library that implements the operation of the software switch and the convection table.

The NETDEV layer abstracts the network devices that are connected to the virtual switch.

The DPIF layer implements the operation for the flow table.

For OvS, there are several types of network adapters:

1). Netdev: Universal NIC device eth0 Veth

Receive: A Nedev after L2 received the message back directly through the OVS receive function processing, no longer walk the traditional kernel stack.

Send: A stream in OvS specifies that the network card device is sent from the Netdev

2). Internal: A virtual network card device

Receive: When a message routed from the system is sent through the device, it enters the OvS receive handler function

Send: A stream in the OvS is made from the internal device, the message is re-injected into the kernel protocol stack

3). GRE Device:gre device. No matter how many GRE tunnel are created in the user state, there is only one GRE device in the kernel state

Receive: When the system receives the GRE message, it is passed to the L4 layer to parse the GRE header and then passed to the OvS receive handler function

Send: A stream in the OvS is made from this GRE device, the message will be based on the flow table rules plus the GRE header and the outer packet IP, find routing Sent

In the code structure as above, Vswitchd is the ovs-vswitchd of the entry code, OVSDB is Ovsdb-server code, Ofproto namely the above-mentioned intermediate abstraction layer, lib below the implementation of NETDEV,DPIF, DataPath inside is the kernel module Openvswitch.ko code.

three, Ovs-vswitchd and Openvswitch.ko Interactive way NetLink

The datapath runs in the kernel state, Ovs-vswitchd runs in the user state, and both communicate through NetLink.

NetLink is a flexible and powerful inter-process communication mechanism (socket) that can even communicate user and kernel states.

The NetLink is full-duplex. The address family as Socket,netlink is Af_netlink (the address family of TCP/IP Sockets is af_inet)

There are a large number of communication scenarios that have been applied to netlink, these specific extensions and designs of the NetLink communication bus, which are defined as family. such as Netlink_route, Netlink_firewall, NETLINK_ARPD and so on.

Because a large number of dedicated family will occupy the family ID, and family ID number itself is limited (kernel allow 32), and in order to facilitate user expansion, a common NetLink family is defined, this is generic NetLink Family

To use generic netlink, you need a familiar data structure including genl_family, Genl_ops, and so on.

Write a simple example of generic netlink below

Define family as follows

/* Attributes */enum {doc_exmpl_a_unspec, doc_exmpl_a_msg, __doc_exmpl_a_max,}; #define DOC_EXMPL_A_MAX (__DOC_EXMPL_A_MAX-1)/* Attribute policy */static struct Nla_policy doc_exmpl_genl_policy[doc_ Exmpl_a_max + 1] = {[Doc_exmpl_a_msg] = {. Type = nla_nul_string},}; /* Family definition */static struct genl_family doc_exmpl_gnl_family = {. id = genl_id_generate,. hdrsize = 0,. Name = " Doc_exmpl ",. Version = 1,. maxattr = Doc_exmpl_a_max,};

Define OP as follows

/* Handler */Int doc_exmpl_echo (Struct sk_buff *skb, struct genl_in Fo *info) {/* Message handling code goes here; return 0 in success, negative values on Failure */}/* Commands * ENUM&N Bsp {doc_exmpl_c_unspec, Doc_exmpl_c_echo, __doc_exmpl_c_max,}; #define DOC_EXMPL_C_MAX (__doc_exmpl_c_max-1)/* Operation definition */struct genl_ops Doc_exmpl_gnl_ops_echo = { . cmd = Doc_exmpl_c_echo,. Flags = 0,