{"id":66,"date":"2013-09-16T22:05:49","date_gmt":"2013-09-16T20:05:49","guid":{"rendered":"http:\/\/www.opencloudblog.com\/?p=66"},"modified":"2014-05-18T10:56:29","modified_gmt":"2014-05-18T08:56:29","slug":"linux-switching-interconnecting-namespaces","status":"publish","type":"post","link":"https:\/\/www.opencloudblog.com\/?p=66","title":{"rendered":"Linux Switching – Interconnecting Namespaces"},"content":{"rendered":"

Switching in software on Linux is one of the important parts when using virtualization technologies like KVM or LXC. Typical hosts do not provide one or more physical adapters for each NIC of a virtual machine in KVM or per container when using LXC. Something else must take the part to interconnect the virtual network interfaces.<\/p>\n

The software switching classical tool is the linuxbridge, which is available in the Linux kernel for a long time. The frontend to manage the linuxbridge is brctl<\/strong>. The newer tool is the Openvswitch (at\u00a0http:\/\/openvswitch.org\/<\/a>). The main frontend is ovs-vsctl<\/strong>.<\/p>\n

In this post I will show multiple solutions to interconnect Linux namespaces using a software based switch. A performance analysis of these solutions will be discussed in another article later. Starting with network namespaces helps to understand the more complex situations when using KVM or LXC.<\/p>\n

tap interfaces<\/h1>\n

Linux tap interfaces created with ip tuntap cannot be used to attach network namespaces to linuxbridges or the openvswitch.<\/p>\n

veth pair<\/h1>\n

The simple solution to connect two network namespaces is the usage of one veth pair. This has been discussed in a previous artice.<\/p>\n

\"veth<\/a>

Connecting namespaces using a veth pair<\/p><\/div>\n

The command sequence has been discussed in a previous article, but we show the commands here again<\/p>\n

# add the namespaces\r\nip netns add ns1\r\nip netns add ns2\r\n# create the veth pair\r\nip link add tap1 type veth peer name tap2\r\n# move the interfaces to the namespaces\r\nip link set tap1 netns ns1\r\nip link set tap2 netns ns2\r\n# bring up the links\r\nip netns exec ns1 ip link set dev tap1 up\r\nip netns exec ns2 ip link set dev tap2 up\r\n# now assign the ip addresses<\/pre>\n
\u00a0linux bridge and two veth pairs<\/h1>\n
When more than two network namespaces (or KVM or LXC instances) must be connected a switch should be used. Linux offers as one solution the well known linux bridge.<\/p>\n
\"Connecting<\/a>
Connecting namespaces using a linux bridge and two veth pairs<\/p><\/div>\n
We need for this setup one switch, and two connectors. In this setup we use a linuxbridge and two veth pairs.<\/p>\n
The commands to create this setup are:<\/p>\n
# add the namespaces\r\nip netns add ns1\r\nip netns add ns2\r\n# create the switch\r\nBRIDGE=br-test\r\nbrctl addbr $BRIDGE\r\nbrctl stp   $BRIDGE off\r\nip link set dev $BRIDGE up\r\n#\r\n#### PORT 1\r\n# create a port pair\r\nip link add tap1 type veth peer name br-tap1\r\n# attach one side to linuxbridge\r\nbrctl addif br-test br-tap1 \r\n# attach the other side to namespace\r\nip link set tap1 netns ns1\r\n# set the ports to up\r\nip netns exec ns1 ip link set dev tap1 up\r\nip link set dev br-tap1 up\r\n#\r\n#### PORT 2\r\n# create a port pair\r\nip link add tap2 type veth peer name br-tap2\r\n# attach one side to linuxbridge\r\nbrctl addif br-test br-tap2\r\n# attach the other side to namespace\r\nip link set tap2 netns ns2\r\n# set the ports to up\r\nip netns exec ns2 ip link set dev tap2 up\r\nip link set dev br-tap2 up\r\n#<\/pre>\n
 <\/p>\n
openvswitch and two veth pairs<\/h1>\n
Another solution is to use the openvswitch instead of the „old“ linuxbrige. The configuration is nearly the same as for the linuxbridge.<\/p>\n
\"Connecting<\/a>
Connecting namespaces using the openvswitch and two veth pairs<\/p><\/div>\n
We need for this setup one switch, and two connectors. In this setup we use an openvswitch and two veth pairs.<\/p>\n
The commands to create this setup are:<\/p>\n
# add the namespaces\r\nip netns add ns1\r\nip netns add ns2\r\n# create the switch\r\nBRIDGE=ovs-test\r\novs-vsctl add-br $BRIDGE\r\n#\r\n#### PORT 1\r\n# create a port pair\r\nip link add tap1 type veth peer name ovs-tap1\r\n# attach one side to ovs\r\novs-vsctl add-port $BRIDGE ovs-tap1 \r\n# attach the other side to namespace\r\nip link set tap1 netns ns1\r\n# set the ports to up\r\nip netns exec ns1 ip link set dev tap1 up\r\nip link set dev ovs-tap1 up\r\n#\r\n#### PORT 2\r\n# create a port pair\r\nip link add tap2 type veth peer name ovs-tap2\r\n# attach one side to ovs\r\novs-vsctl add-port $BRIDGE ovs-tap2 \r\n# attach the other side to namespace\r\nip link set tap2 netns ns2\r\n# set the ports to up\r\nip netns exec ns2 ip link set dev tap2 up\r\nip link set dev ovs-tap2 up\r\n#<\/pre>\n
 <\/p>\n
openvswitch and two openvswitch ports<\/h1>\n
Another solution is to use the openvswitch and make use of the openvswitch internal ports. This avoids the usage of the veth pairs, which must be used in all other solutions.<\/p>\n
\"Connecting<\/a>
Connecting namespaces using the openvswitch and two openvswitch ports<\/p><\/div>\n
We need for this setup one switch, and two connectors. In this setup we use an openvswitch and two openvswitch ports.<\/p>\n
The commands to create this setup are:<\/p>\n
# add the namespaces\r\nip netns add ns1\r\nip netns add ns2\r\n# create the switch\r\nBRIDGE=ovs-test\r\novs-vsctl add-br $BRIDGE\r\n#\r\n#### PORT 1\r\n# create an internal ovs port\r\novs-vsctl add-port $BRIDGE tap1 -- set Interface tap1 type=internal\r\n# attach it to namespace\r\nip link set tap1 netns ns1\r\n# set the ports to up\r\nip netns exec ns1 ip link set dev tap1 up\r\n#\r\n#### PORT 2\r\n# create an internal ovs port\r\novs-vsctl add-port $BRIDGE tap2 -- set Interface tap2 type=internal\r\n# attach it to namespace\r\nip link set tap2 netns ns2\r\n# set the ports to up\r\nip netns exec ns2 ip link set dev tap2 up<\/pre>\n
\u00a0Performance<\/h1>\n
In another article I will show some performance numbers for the four presented solutions. There are noticeable differences with respect to throughput and CPU usage.<\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
Switching in software on Linux is one of the important parts when using virtualization technologies like KVM or LXC. Typical hosts do not provide one or more physical adapters for each NIC of a virtual machine in KVM or per container when using LXC. Something else must take the part to interconnect the virtual network […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,4],"tags":[],"_links":{"self":[{"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=\/wp\/v2\/posts\/66"}],"collection":[{"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=66"}],"version-history":[{"count":13,"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=\/wp\/v2\/posts\/66\/revisions"}],"predecessor-version":[{"id":371,"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=\/wp\/v2\/posts\/66\/revisions\/371"}],"wp:attachment":[{"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=66"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=66"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=66"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}