Autumn School on software-configured networks and home-based implementation
In September 2012, I was fortunate enough to visit the fall school on software-configurable networks of the Center for Applied Research of Computer Networks . Nick McKeon, one of the founders and ideological inspirers of SDN-networks and OpenFlow in particular, was invited to the main thing.
The basis of the workshop on the equipment was a NEC switch-over switch of an unknown model in Russia and several tp-link 1043 routers with a patched OpenWrt (in fact, just reassembled). Already at home, a router of a similar model was discovered, on which I decided to try OpenFlow in action in the real world. But first about the autumn school itself.
The lecture began with the same presentation pictures that are available on the OpenFlow project at Stanford. However, the semantic load added by Nick significantly refined and supplemented the simple presentation schedules. Then Nick also spoke about new projects, in particular about the automatic verification of SDN, search for rings in a logical topology, checking the applicability of the rules, etc.
During the lecture periodically there were breaks during which students and graduate students bombarded Nika with questions. It was difficult for Nick to ask many questions, as Nick likes to answer thoroughly and extensively, to touch upon related problems. At the end of the lecture, I also tried to get several answers to pressing questions that arose both during the course and before the lecture. Especially interested was the explanation of the experiment of Nick's colleagues with wireless broadcasting and parallel setup of video access points with minimal delays, where one person with a laptop traveled around the Stanford campus on a golf car and broadcast video from a webcam. Nick explained that the OpenWRT distribution kit with a self-written application for interacting with OpenFlow was flashed at access points (now it is available as a package ).
')
Here the idea was born to try to implement this experiment on its own.
Second day of school. We tried the Mininet virtual environment ( OpenFlow tutorial ), which is a topology simulator on virtual hosts. An external OpenFlow controller was connected to the virtually created network. This is where the real fun began.
The POX controller is written in python, which has already been a big problem for many. Well, I had a book on python and the Internet (I hadn’t written anything on it before, only php, perl, cpp, c #, etc.). The most interesting thing is that the cat wept for documentation on the POX controller, there are even fewer examples. The POX object model was clearly written by students in their free time. For example, the src-MAC address is in the property of the packet_in.dl_src object, which itself is the result of the event.parse method, and to get the src-IP address you need to check the packet type on the protocol in a creepy way (a lot of checks on the types and pulling of various properties from left objects), spar the packet to the next header ( ip_hdr = packet_in.next ), and get the ip_hdr.nw_src object (network_layer src) from there . As you can see, the POX and application interaction object model was not written by networkers, but pure programmers. There is no uniformity of the name of the methods, protocols, properties of objects, the python language is quite indifferent, if you make a mistake suddenly in the name of an object or property - it can create a new one.
Further more. The documentation is clearly of a developer nature and is not intended for final use. The correct solutions were found when digging the POX sources for the desired properties and examples after wandering aimlessly through a single manual. For the sake of justice, it is worth noting the presence of fairly tolerable examples in the manual about working with a channel Ethernet layer and sending basic OpenFlow rules to the switch. By the way, during the work (about 5 hours) POX fell off “only” 2 times. This is about the reliability of python applications. When testing its parent NOX (written in c ++), this was not observed.
A small example. The code for setting the rule of channel switching (which ethernet switches almost do not know) will look like this:
it is clearly spelled out here - all that fell on port 3 will go to the 4th. No options.
In fact, this tutorial is most useful in understanding SDN and how it works. Unfortunately at the office. There are no step-by-step examples on the tutorial site, they were successfully voiced and invented by the School’s speakers, for which they thank you very much. Without them, I think, half of the people simply would not understand how it works.
The third day was devoted to the real gland. One Nec ProgrammableFlow switchboard is divided into several VLANs, four of which were managed by OpenFlow, four TP-Link 1043 routers, flashed to OpenWRT with the OpenFlow patch, virtual hosts with controllers, 16 virtual hosts from which the network was assembled. All hosts had two network - one to control us (external network, for ssh), the other for the openflow test network. All were divided into 4 groups, the topology was as follows - each group had 3 hosts connected to the switch in the correct VLAN, fourth to the router to the wired port (by the way, the wireless port looks from the point of view of the controller as well as the wired one).
Detailed topology (without port numbers and other things):
There were several tasks:
FlowVisor is a separate song. The software implementation of this complex is made on a hellish mixture of c ++, python and java, with java being used for configuration. Enter the command - the whole java-machine rises, configuration takes place and that's it - java is no longer needed. One command is executed two seconds. But there are a lot of commands, each command requires entering a password or specifying a file with a password (clear text). First you need to create slices - logically separated parts of the network assigned to a specific controller. Then in each slice you need to add filter rules that fall into the slice and what does not. You can create one default slice where all unclassified traffic will go.
A tplink 741 was found. When exploring the OpenWrt site, it turned out that OpenWrt was not installed on my hardware revision (v2.1). However, the form is said to work. We put Ubuntu on virtualku and libraries (we look on the openwrt site), we pour source codes
Then separately fill in the OpenFlow functionality as a package. A small digression - it took 6 GB to compile a basic Bercia without a web, be careful.
And, most importantly, choose the right brunch for the architecture. My tplink is Atheros 71xx
Then it is highly desirable to update the openwrt port feeds. Go to the backfire directory and
In the menu, select Atheros AR71xx, TP-Link WR741ND v1 (as it turned out, it works v1), in the packages we choose kmod-tun (Kernel Modules-> Network Support), tc and OpenFlow (network). We remain, we leave.
As it turned out later, you need to add HTB QoS to the core, everything is very slow without it.
Enable Hierarchical Token Bucket (HTB) (Networking Support-> Networking options-> QoS and / or fair queuing)
Building takes place in the usual make, taking about an hour and 6 GB of space.
In the bin / ar71xx folder there will be, among other things, the file openwrt-ar71xx-tl-wr741nd-v1-squashfs-sysupgrade.bin (there is also -factory.bin, it is for the initial openwrt firmware)
It is better to make a fill on a device from some openwrt already flashed (for example, for v1) via scp (ssh cp). We go on ssh in OpenWrt and
Oddly enough, it all worked the first time.
Setting up OpenFlow itself takes a little time
We start the network controller (I took POX as the easiest one) -
Everything is connected, you can use it. The only thing that strained - Socket error: Broken pipe. The controller began to fall off regularly (for that he and POX).
The basis of the workshop on the equipment was a NEC switch-over switch of an unknown model in Russia and several tp-link 1043 routers with a patched OpenWrt (in fact, just reassembled). Already at home, a router of a similar model was discovered, on which I decided to try OpenFlow in action in the real world. But first about the autumn school itself.
2 Inspiration and theory
The lecture began with the same presentation pictures that are available on the OpenFlow project at Stanford. However, the semantic load added by Nick significantly refined and supplemented the simple presentation schedules. Then Nick also spoke about new projects, in particular about the automatic verification of SDN, search for rings in a logical topology, checking the applicability of the rules, etc.
During the lecture periodically there were breaks during which students and graduate students bombarded Nika with questions. It was difficult for Nick to ask many questions, as Nick likes to answer thoroughly and extensively, to touch upon related problems. At the end of the lecture, I also tried to get several answers to pressing questions that arose both during the course and before the lecture. Especially interested was the explanation of the experiment of Nick's colleagues with wireless broadcasting and parallel setup of video access points with minimal delays, where one person with a laptop traveled around the Stanford campus on a golf car and broadcast video from a webcam. Nick explained that the OpenWRT distribution kit with a self-written application for interacting with OpenFlow was flashed at access points (now it is available as a package ).
')
Here the idea was born to try to implement this experiment on its own.
3 First practice
Second day of school. We tried the Mininet virtual environment ( OpenFlow tutorial ), which is a topology simulator on virtual hosts. An external OpenFlow controller was connected to the virtually created network. This is where the real fun began.
The POX controller is written in python, which has already been a big problem for many. Well, I had a book on python and the Internet (I hadn’t written anything on it before, only php, perl, cpp, c #, etc.). The most interesting thing is that the cat wept for documentation on the POX controller, there are even fewer examples. The POX object model was clearly written by students in their free time. For example, the src-MAC address is in the property of the packet_in.dl_src object, which itself is the result of the event.parse method, and to get the src-IP address you need to check the packet type on the protocol in a creepy way (a lot of checks on the types and pulling of various properties from left objects), spar the packet to the next header ( ip_hdr = packet_in.next ), and get the ip_hdr.nw_src object (network_layer src) from there . As you can see, the POX and application interaction object model was not written by networkers, but pure programmers. There is no uniformity of the name of the methods, protocols, properties of objects, the python language is quite indifferent, if you make a mistake suddenly in the name of an object or property - it can create a new one.
Further more. The documentation is clearly of a developer nature and is not intended for final use. The correct solutions were found when digging the POX sources for the desired properties and examples after wandering aimlessly through a single manual. For the sake of justice, it is worth noting the presence of fairly tolerable examples in the manual about working with a channel Ethernet layer and sending basic OpenFlow rules to the switch. By the way, during the work (about 5 hours) POX fell off “only” 2 times. This is about the reliability of python applications. When testing its parent NOX (written in c ++), this was not observed.
A small example. The code for setting the rule of channel switching (which ethernet switches almost do not know) will look like this:
fm = of.ofp_flow_mod() fm.match.in_port = 3 // . fm.actions.append(of.ofp_action_output(port = 4)) // , match it is clearly spelled out here - all that fell on port 3 will go to the 4th. No options.
In fact, this tutorial is most useful in understanding SDN and how it works. Unfortunately at the office. There are no step-by-step examples on the tutorial site, they were successfully voiced and invented by the School’s speakers, for which they thank you very much. Without them, I think, half of the people simply would not understand how it works.
4 Equipment
The third day was devoted to the real gland. One Nec ProgrammableFlow switchboard is divided into several VLANs, four of which were managed by OpenFlow, four TP-Link 1043 routers, flashed to OpenWRT with the OpenFlow patch, virtual hosts with controllers, 16 virtual hosts from which the network was assembled. All hosts had two network - one to control us (external network, for ssh), the other for the openflow test network. All were divided into 4 groups, the topology was as follows - each group had 3 hosts connected to the switch in the correct VLAN, fourth to the router to the wired port (by the way, the wireless port looks from the point of view of the controller as well as the wired one).
Detailed topology (without port numbers and other things):
There were several tasks:
- raise the POX controller with the default application (L2_learning) on ​​the desired port (6633) and interface. There were no problems.
root@openflowtutorial:/home/openflow/pox# ./pox.py forwarding.l2_learning POX 0.0.0 / Copyright 2011 James McCauley DEBUG:core:POX 0.0.0 going up... DEBUG:core:Running on CPython (2.7.1+/Apr 11 2011 18:05:24) DEBUG:forwarding.l3_learning:Up... INFO:core:POX 0.0.0 is up. DEBUG:openflow.of_01:Listening for connections on 0.0.0.0:6633 Ready. INFO:openflow.of_01:[Con 4/150867562545] Connected to 00-00-00-00-00-01
inscriptionINFO:openflow.of_01:[Con 1/1] Connected to 00-00-00-00-00-01
indicates successful connection of the controller. - To conduct testing (pairwise pings). Unfortunately, there was no installed iperf, so it was not possible to test the performance. Ping behaved as it should be - with training about 100-200 ms, in normal mode 0.1-10ms (after all, on virtual machines raised).
- Raise the network virtualization system FlowVisor to abstract OpenFlow instances from the physical network. At first, everyone tried to understand how it works. FlowVisor is a bidirectional pseudo-NAT server (addressing spoofing server), which from the point of view of the switch is a complete controller, and from the point of view of the controller is a switch. Several switches are connected to FlowVisor. It has a filtering system, and packets from the switch get only to the controller where the administrator has configured. You can block ports or entire switches from FlowVisor and build an alternative logical network structure.
Each team raised its FlowVizor on port 6633, divided the entire network into 4 segments, set up its own segment and links to neighboring controllers. The controllers now started on a different port (6634) and saw all switches as localhost (natitsiy).
FlowVisor is a separate song. The software implementation of this complex is made on a hellish mixture of c ++, python and java, with java being used for configuration. Enter the command - the whole java-machine rises, configuration takes place and that's it - java is no longer needed. One command is executed two seconds. But there are a lot of commands, each command requires entering a password or specifying a file with a password (clear text). First you need to create slices - logically separated parts of the network assigned to a specific controller. Then in each slice you need to add filter rules that fall into the slice and what does not. You can create one default slice where all unclassified traffic will go.
5 We do at home
A tplink 741 was found. When exploring the OpenWrt site, it turned out that OpenWrt was not installed on my hardware revision (v2.1). However, the form is said to work. We put Ubuntu on virtualku and libraries (we look on the openwrt site), we pour source codes
svn co svn://svn.openwrt.org/openwrt/branches/backfire Then separately fill in the OpenFlow functionality as a package. A small digression - it took 6 GB to compile a basic Bercia without a web, be careful.
cd backfire/package git clone git://gitosis.stanford.edu/openflow-openwrt And, most importantly, choose the right brunch for the architecture. My tplink is Atheros 71xx
cd openflow-openwrt git checkout -b openflow-1.0/ar71 origin/openflow-1.0/tplink Then it is highly desirable to update the openwrt port feeds. Go to the backfire directory and
./scripts/feeds update -a ./scripts/feeds install -a make menuconfig In the menu, select Atheros AR71xx, TP-Link WR741ND v1 (as it turned out, it works v1), in the packages we choose kmod-tun (Kernel Modules-> Network Support), tc and OpenFlow (network). We remain, we leave.
As it turned out later, you need to add HTB QoS to the core, everything is very slow without it.
make kernel_menuconfig Enable Hierarchical Token Bucket (HTB) (Networking Support-> Networking options-> QoS and / or fair queuing)
Building takes place in the usual make, taking about an hour and 6 GB of space.
In the bin / ar71xx folder there will be, among other things, the file openwrt-ar71xx-tl-wr741nd-v1-squashfs-sysupgrade.bin (there is also -factory.bin, it is for the initial openwrt firmware)
It is better to make a fill on a device from some openwrt already flashed (for example, for v1) via scp (ssh cp). We go on ssh in OpenWrt and
scp root@ip_:/__/openwrt-ar71xx-tl-wr741nd-v1-squashfs-sysupgrade.bin /tmp sysupgrade -v /tmp/openwrt-ar71xx-tl-wr741nd-v1-squashfs-sysupgrade.bin Oddly enough, it all worked the first time.
ps aux | grep ofprotocol 976 root 1040 S ofprotocol tcp:127.0.0.1:6634 tcp:192.168.1.10:6633 Setting up OpenFlow itself takes a little time
cd /etc/config vi openflow config 'ofswitch' option 'dp' 'dp0' option 'ofports' 'eth0.0 eth0.1 eth0.2 eth0.3 ' option 'ofctl' 'tcp:192.168.1.102:6633' option 'mode' 'outband' We start the network controller (I took POX as the easiest one) -
root@openflowtutorial:/home/openflow/pox# ./pox.py forwarding.l3_learning POX 0.0.0 / Copyright 2011 James McCauley DEBUG:core:POX 0.0.0 going up... DEBUG:core:Running on CPython (2.7.1+/Apr 11 2011 18:05:24) DEBUG:forwarding.l3_learning:Up... INFO:core:POX 0.0.0 is up. DEBUG:openflow.of_01:Listening for connections on 0.0.0.0:6633 DEBUG:openflow.of_01:[Con 1/None] Socket error: Broken pipe DEBUG:openflow.of_01:[Con 1/None] disconnecting Ready. INFO:openflow.of_01:[Con 4/150867562545] Connected to 00-23-20-68-50-31 Everything is connected, you can use it. The only thing that strained - Socket error: Broken pipe. The controller began to fall off regularly (for that he and POX).
What was used when writing a post
- Center for Applied Research of Computer Networks - PCB School itself
- OpenFlow site - everything is there, both wikis and tutorial
- Wiki openwrt - no way without it
Source: https://habr.com/ru/post/152957/
All Articles