This document describes how to use ovs-vtep, VXLAN tunnel endpoint simulator (VXLAN Tunnel EndPoint, VTEP), using Open vSwitch to forward data. VTEPs VXLAN frame processing refers to the entity encapsulation and encapsulated in the network.
Claim
VTEP simulator is a Python script, which triggers calls related tools, such as vtep-ctl
and ovs-vsctl. Only useful only if installed and enabled Open vSwitch daemons (such as ovsdb-server and ovs-vswitchd). To perform this operation is enabled, perform the following steps:
-
According to the document OVS code
/intro/install/general
instructions described (not to start any daemon). -
OVS code according to the document
/intro/install/debian'描述的说明进行操作,然后安装
openvswitch-vtep`` package (based on debian if the operating machine). This will launch the daemon automatically.
design
At the end of this process, you should have the following settings topology:
Architecture
+---------------------------------------------------+
| Host Machine |
| |
| |
| +---------+ +---------+ |
| | | | | |
| | VM1 | | VM2 | |
| | | | | |
| +----o----+ +----o----+ |
| | | |
| br0 +------o-----------o--------------------o--+ |
| p0 p1 br0 |
| |
| |
| +------+ +------+ |
+------------------------------| eth0 |---| eth1 |--+
+------+ +------+
10.1.1.1 10.2.2.1
MANAGEMENT | |
+-----------------o----+ |
|
DATA/TUNNEL |
+-----------------o---+
Some important points.
-
We will use the Open vSwitch to create a "physical" switch:
br0
-
Our "physical" switch
br0
will also have an internal name for the portbr0
as well as two "physical" port, namedp0
andp1
. -
Host may have two external interfaces. We will use
eth0
to carry management traffic,eth1
carry tunnel traffic (also can use an interface to carry two types of traffic). Please note that the IP address them in the figure above. You do not have to use the exact same IP address. Just know the IP address of the label will be used in the following steps. -
You can also connect two physical machines instead of virtual machine image above to switch
br0
this case:-
To ensure that there are two additional physical ports on your host
eth2
andeth3
. -
In the rest of this article, we will
p0
replaceeth2
and bep1
replacedeth3
.
-
-
In addition to
p0
andp1
implemented as an addition to the physical interface, you can also use them as a separate device or analog VM TAP interface. -
Creating and associated virtual machines are not within the scope of this document, included in the chart for reference only.
Open
Following description describes how to run a single instance ovsdb-server, its processing and OVS VTEP schema. If the second step according to a "demand" of the packet Debian installation, can skip steps 1-3.
- Create the initial OVS and VTEP schemas:
$ ovsdb-tool create /etc/openvswitch/ovs.db vswitchd/vswitch.ovsschema
$ ovsdb-tool create /etc/openvswitch/vtep.db vtep/vtep.ovsschema
- Start ovsdb-server and let it handle two databases:
$ ovsdb-server --pidfile --detach --log-file \
--remote punix:/var/run/openvswitch/db.sock \
--remote=db:hardware_vtep,Global,managers \
/etc/openvswitch/ovs.db /etc/openvswitch/vtep.db
- Normal start ovs-vswitchd:
$ ovs-vswitchd --log-file --detach --pidfile \
unix:/var/run/openvswitch/db.sock
- Create a "physical" switch in OVS and add ports:
$ ovs-vsctl add-br br0
$ ovs-vsctl add-port br0 p0
$ ovs-vsctl add-port br0 p1
- Configuration "physical" switch VTEP database:
$ vtep-ctl add-ps br0
$ vtep-ctl set Physical_Switch br0 tunnel_ips=10.2.2.1
- If you've turned on VTEP simulator according to OVS document.
/intro/install/general
Installed components invtep
the following command run directory:
$ ./ovs-vtep --log-file=/var/log/openvswitch/ovs-vtep.log \
--pidfile=/var/run/openvswitch/ovs-vtep.pid \
--detach br0
If you perform the installation when installing openvswitch-vtep package, you can be in the directory /usr/share/openvswitch/scripts
to find ovs-vtep in.
- VTEP configuration database manager pointing NVC:
$ vtep-ctl set-manager tcp:<CONTROLLER IP>:6640
Which <CONTROLLER IP>
is the IP address of your controller, can be accessed through the eth0 port of the host.
Analog NVC
VTEP achieve desired by a network virtualization controller (Network Virtualization
the Controller, NVC) drive. The controller (NVC), e.g. NSX. If not, you can use a simulation vtep-ctl:
- Creating a "logical" switch:
$ vtep-ctl add-ls ls0
- Binding "logical" to a switch port:
$ vtep-ctl bind-ls br0 p0 0 ls0
$ vtep-ctl set Logical_Switch ls0 tunnel_key=33
- Unknown destination address traffic control issued by the tunnel.
Example processes Layer broadcast, multicast and unknown unicast traffic, the packet may be sent to all the member ports "physical" switch referenced "logical" switch. The following "unknown-dst" is used to indicate the address of these packets.
For copy data packets have different modes. The default mode is to copy the message sent to the service node, which can be a hypervisor, server or device, and make the service node processing replicated to other transport nodes (hypervisors or other VTEP physical switch). This mode is called service node replication.
Another copy mode, called source node replication, the source node transmits the transmission packets to all other nodes. Hypervisors are always responsible for implementing its own replication for virtual machines locally connected in two modes. Service node copy mode is the default mode. Service node copying mode is because it only needs to send data to a packet transmission node, it is considered to be a basic requirement. The service node configured to copy mode, because of the unknown "unknown-dst" address, only the specified node of a transmission object:
$ vtep-ctl add-mcast-remote ls0 unknown-dst 10.2.2.2
- Alternatively, modification by the default copy mode is
service_node
tosource_node
be completed in logical level switch:
$ vtep-ctl set-replication-mode ls0 source_node
- Control unicast destination address of the packet sent by a different tunnel:
$ vtep-ctl add-ucast-remote ls0 00:11:22:33:44:55 10.2.2.3