SDN Basic Course for Programmers 3: Try Making a Switching Hub with Ryu

Ryu environment construction

One of Ryu's strengths is that the developer, NTT Laboratories, provides a wealth of documentation. There are not many documents organized for learning SDN in a Japanese environment, and even if they are, the information is often out of date. The Wiki of Ryu has been translated into Japanese, and the same content has been converted into an e-book. The pdf version is open to the public for free, so it's easy to learn. Also, it is the fate of the framework that runs on Linux, but when trying to prepare the environment of other OpenFlow controllers, the installation does not proceed or the source code does not work due to problems due to version mismatch and dependencies. I had a hard time. However, Ryu has prepared an image file that runs on VirutalBox and has completed Ryu's environment construction. This helps. Download it from Official HP immediately.

When reading the English on the official website during the download, the pronunciation of Ryu seems to be "Ryo". However, the meaning seems to come from the Japanese "flow" (= flow). Once downloaded, import it into Virutal Box. If you execute according to the page of here, the import is completed. The user ID and password can be found at the beginning of the Official Tutorial (https://github.com/osrg/ryu/wiki/OpenFlow_Tutorial).

Make a switching hub with Ryu

The environment is ready. From here, we will study while using the "Ryu SDN Framework" prepared by the official. First, let's make a switching hub to check the operation of Ryu. I explained what a switching hub (switch) is like last time, but I will explain its "specifications" again.

When the power is turned on, nothing is recorded in the MAC address table of the switching hub. Therefore, if the switch receives frames from the first connected host, it will send frames to all connected ports. (The receiving host checks the "destination MAC address" of the sent packet and ignores it if it is different from its own MAC address.) At the same time, "source MAC address (= host)" is added to the MAC address table. And "the port number to which the host with that MAC address is connected" is recorded.

In the future, if a frame whose destination MAC address is recorded in the MAC address table flows to the switching hub, the frame will be sent only to the port listed in the MAC address table.

By the way, before the spread of switching hubs, hubs called "repeater hubs" that transmit data received from one host to all other hosts were the mainstream. Sending to all hosts has caused problems such as an increase in packets flowing on the network, an increase in collisions, and a decrease in network utilization efficiency. In the past, switching hubs were expensive, so it was said that there was a time when they were repeater hubs at home and switching hubs at offices, but nowadays switching hubs can be bought for 1000 yen. Repeater hubs are a thing of the past. As a trivia, this repeater hub was also known as a "stupid hub".

--Transfer the received packet to the controller (Packet-In) --Packet-Out the packet forwarded from the controller from the specified port

If implemented with this basic function of OpenFlow, it seems possible to program the operation of the switching hub.

The source code of the OpenFlow controller that implements the switching hub is under "/ home / ryu / ryu / ryu / app" in the development environment prepared earlier. Let's check it out (the source code is also posted on Web).

Initializing the MAC address table variable mac_to_port in init. And line 32 is important for understanding the Ryu application.

simple_switch_13.py(32,Line 33)

    @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
    def switch_features_handler(self, ev):

The 32nd line is the decorator and the 33rd line is the event handler. "Decorator" is an element that I omitted in the Python basic course I wrote in the past. The following page may be helpful.

-Python --Decorator -About the Python decorator

In Ryu, when an OpenFlow message is received, the event corresponding to the message occurs. The Ryu application implements an event handler for the message you want to receive. You can declare an event handler by writing the decorator set_ev_cls. The first argument of set_ev_cls gives the event that the Ryu application wants to receive. The second argument gives one or a list of states between the OpenFlow switch and the OpenFlow controller.

The first argument of set_ev_cls is EventOFP ** SwitchFeatures **. The event class name is ryu.controller.ofp_event.EventOFP + ** OpenFlow message name **. (For example, in the case of a Packet In message, it will be EventOFPPacketIn.) In this case, we will code in the switch_features_handler as an event when the switch makes a connection. I think that set_ev_cls is already implemented in the Ryu framework, in which some steps such as the handshake required for the OpenFlow switch and controller to communicate with the OpenFlow protocol handle it. I will. Therefore, you can focus only on the application-specific behavior when receiving an event.

simple_switch_13.py(switch_features_handler method)

    @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
    def switch_features_handler(self, ev):
        datapath = ev.msg.datapath
        ofproto = datapath.ofproto
        parser = datapath.ofproto_parser

        match = parser.OFPMatch()
        actions = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
                                          ofproto.OFPCML_NO_BUFFER)]
        self.add_flow(datapath, 0, match, actions)

The ofproto library is a library for creating and parsing messages of the OpenFlow protocol. Is ofproto_parser a message parser by name?

In the switching hub, no event is described when the switch makes a connection. Table-miss Treated as an event to get the timing to add a flow entry. A Table-miss flow entry is an entry that has the lowest priority (0) and matches all packets. Corresponds to default in the case statement.

simple_switch_13.py(Lines 45-48)

        #Matches all packet conditions
        match = parser.OFPMatch() 
        #Send the entire packet to the controller without buffering
        actions = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
                                          ofproto.OFPCML_NO_BUFFER)] 
        #Add flow entry to flow table with priority 0
        self.add_flow(datapath, 0, match, actions)

The condition (match) is blank, that is, all conditions. The action for forwarding to the controller port specifies the controller as the output destination, and OFPCML_NO_BUFFER is specified for max_len to send the entire packet to the controller.

Annotation:The first part of the packet on the controller(Ethernet header)It's better to send only and buffer the rest in the switch for efficiency, but to avoid Open vSwitch bugs, let's send the entire packet here. This bug is Open vSwitch 2.1.Fixed with 0(From Ryu official)

In this description, by specifying the output action to the port of the OpenFlow controller for processing this entry, Packet-In will be issued if the received packet does not match all the normal flow entries. .. The reason why such a description is necessary is that the OpenFlow switch drops or drops packets that do not match the flow entry by default.

Next, create a handler for the Packet In event to accept incoming packets from unknown destinations.

simple_switch_13.py(Lines 61-62)

    @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
    def _packet_in_handler(self, ev):

The first argument of set_ev_cls is EventOFP ** PacketIn **. The second argument is also MAIN_DISPATCHER, which means the normal state.

simple_switch_13.py(Lines 67-81)

    @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
    def _packet_in_handler(self, ev):
        msg = ev.msg
        datapath = msg.datapath
        ofproto = datapath.ofproto
        parser = datapath.ofproto_parser
        in_port = msg.match['in_port'] #Get port number

        pkt = packet.Packet(msg.data)
        eth = pkt.get_protocols(ethernet.ethernet)[0] #Get Ethernet header

        dst = eth.dst #Destination MAC address
        src = eth.src #Source MAC address

        dpid = datapath.id
        self.mac_to_port.setdefault(dpid, {})

        self.logger.info("packet in %s %s %s %s", dpid, src, dst, in_port)

        self.mac_to_port[dpid][src] = in_port 

The array mac_to_port sets the port number corresponding to the "source MAC address" of the Datapath "ID (OpenFlow switch identification ID)". The program does the same thing as recording the MAC address table described at the beginning of this chapter.

simple_switch_13.py(Lines 82-93)

        if dst in self.mac_to_port[dpid]:
            out_port = self.mac_to_port[dpid][dst]
        else:
            out_port = ofproto.OFPP_FLOOD

        actions = [parser.OFPActionOutput(out_port)]

        #If the destination MAC address is found
        if out_port != ofproto.OFPP_FLOOD:
            match = parser.OFPMatch(in_port=in_port, eth_dst=dst)
            #Table-miss Set 1 with higher priority than flow entry
            self.add_flow(datapath, 1, match, actions) 

If the "destination MAC address" corresponding to the Datapath ID of the array mac_to_port exists, specify that port number, and if it does not exist, send a frame to all ports. The process is specified as "Output (port)".

If the destination MAC address is found, add an entry to the flow table of the OpenFlow switch. Unlike the Table-miss flow entry, this time we specify the receive port (in_port) and destination MAC address (eth_dst) in the conditions for OFPMatch.

The method add_flow that adds a flow entry to the flow table is: Instructs the OpenFlow switch to update the flow table with the parser.OFPFlowMod method.

simple_switch_13.py(Lines 50-59)

    def add_flow(self, datapath, priority, match, actions):
        ofproto = datapath.ofproto
        parser = datapath.ofproto_parser

        inst = [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS,
                                             actions)]

        mod = parser.OFPFlowMod(datapath=datapath, priority=priority,
                                match=match, instructions=inst)
        datapath.send_msg(mod)

simple_switch_13.py(Lines 95-101)

        data = None
        if msg.buffer_id == ofproto.OFP_NO_BUFFER:
            data = msg.data

        out = parser.OFPPacketOut(datapath=datapath, buffer_id=msg.buffer_id,
                                  in_port=in_port, actions=actions, data=data)
        datapath.send_msg(out)

Finally, issue a PacketOut message to forward the received packet.

Run Ryu application

Let's make the OpenFlow switch a switching hub by using the created OpenFlow controller. But that requires an OpenFlow switch and a host. Not in a normal person's house. (It seems that some people have a server rack at home, but w) The one prepared for that is "Mininet". Mininet has a function to configure a virtual network using OpenFlow. Mininet is also installed on the officially prepared VM.

Before launching Mininet, try typing ifconfig on the console. ifconfig is a command to check the IP address, netmask, etc. assigned to the network interface of this PC (although it is actually a virtual machine). You will see a network interface for this PC called "eth0" and a special interface called "local loopback" called "lo". After that, use the Mininet (mn) command described below to connect a total of three hosts to each port of one switch. Network topology (in what form a computer is connected on a communication network) Can be emulated.

ryu@ryu-vm:~$ sudo mn --topo single,3 --mac --switch ovsk --controller remote -x
*** Creating network
*** Adding controller
Unable to contact the remote controller at 127.0.0.1:6633
*** Adding hosts:
h1 h2 h3
*** Adding switches:
s1
*** Adding links:
(h1, s1) (h2, s1) (h3, s1)
*** Configuring hosts
h1 h2 h3
Error starting terms: Cannot connect to display ←
*** Starting controller
*** Starting 1 switches
s1
*** Starting CLI:
mininet>

The textbook says "5 xterms will start on your desktop PC" but xterm will not start. I'm getting an error message.

Error starting terms: Cannot connect to display

I couldn't solve this (please help someone >>), so I honestly decided to launch and operate the consoles separately.

Connect to ubuntu with ssh Please refer to here for how to connect to VM on VirtualBox with Teraterm.

From another console, make the bridge created by Mininet compatible with OpenFlow 1.3.

sudo ovs-vsctl set Bridge s1 protocols=OpenFlow13

Then execute the following command.

• Since the source name of the PDF command is incorrect, an import error will occur even if you execute it by copying and pasting as it is. be careful.

ryu-manager --verbose ryu.app.simple_switch_13

It connects to OVS as shown below, has a handshake, added a Table-miss flow entry, and is waiting for Packet In.

connected socket:<eventlet.greenio.GreenSocket object at 0x26aac50> address:('127.0.0.1', 42601)
hello ev <ryu.controller.ofp_event.EventOFPHello object at 0x26aa750>
move onto config mode
EVENT ofp_event->SimpleSwitch13 EventOFPSwitchFeatures
switch features ev version: 0x4 msg_type 0x6 xid 0x50c38af1 OFPSwitchFeatures(auxiliary_id=0,capabilities=71,datapath_id=1,n_buffers=256,n_tables=254)
move onto main mode

Launch yet another console and run the following command: This command is a command to dump the flow table of OpenFlow switch s1.

sudo ovs-ofctl -O openflow13 dump-flows s1

OFPST_FLOW reply (OF1.3) (xid=0x2):
 cookie=0x0, duration=287.127s, table=0, n_packets=0, n_bytes=0, priority=0 actions=CONTROLLER:65535

The flow table defined in switch_features_handler (priority is 0, no condition, CONTROLLER for action, transmission data size 65535 (0xffff = OFPCML_NO_BUFFER)) is specified.

Confirmation of switching hub operation

It is finally confirmation of operation. Ping host 1 to host 2 connected. Even programmers are familiar with ping. You use it to check communication with another machine on the network or a URL on the Internet. First, let's take a brief look at what ping is doing. If you don't know this, you don't know what the flow table should be and whether the dump contents are correct. When pinging from host 1 to host 2, the following processing is performed internally.

The exchange between 3 and 4 is called ping. Hosts and servers with IP addresses have a table called the ARP table inside. It is similar to the MAC address table, but the MAC address table has a combination of "MAC address and port number", while the ARP address table has a combination of "MAC address and IP address". Host 1 needs to know the existence of host 2 in order to process 3 or send an ICMP packet for communication confirmation. Normally, 1 and 2 are executed when the host is connected to the network, and the ARP table is created, so when you hit the ping command from the console, 3 and 4 are executed immediately.

Now that you know ** somehow ** the ping behavior, ** launch three consoles ** and run the tcpdump command so you can see what packets were received by host 1 through host 3. I will. Please note that the host name is also different from the command in the PDF.

Host 1 console

ryu@ryu-vm:~$ sudo tcpdump -en -i s1-eth1
tcpdump: WARNING: s1-eth1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on s1-eth1, link-type EN10MB (Ethernet), capture size 65535 bytes

Host 2 console

ryu@ryu-vm:~$ sudo tcpdump -en -i s1-eth2
tcpdump: WARNING: s1-eth2: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on s1-eth2, link-type EN10MB (Ethernet), capture size 65535 bytes

Host 3 console

tcpdump: WARNING: s1-eth3: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on s1-eth3, link-type EN10MB (Ethernet), capture size 65535 bytes

Now, on the console where you first ran the mn command, run the following command to ping host 1 to host 2.

--- 10.0.0.2 ping statistics --1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 89.463/89.463/89.463/0.000 ms 

One packet was forwarded without loss. Launch a new console and re-enter the command to dump the flow table for OpenFlow switch s1.

ryu@ryu-vm:~$ sudo  ovs-ofctl -O openflow13 dump-flows s1
OFPST_FLOW reply (OF1.3) (xid=0x2):
 cookie=0x0, duration=110.621s, table=0, n_packets=2, n_bytes=140, priority=1,in_port=2,dl_dst=00:00:00:00:00:01 actions=output:1
 cookie=0x0, duration=110.58s, table=0, n_packets=1, n_bytes=42, priority=1,in_port=1,dl_dst=00:00:00:00:00:02 actions=output:2
 cookie=0x0, duration=2752.545s, table=0, n_packets=3, n_bytes=182, priority=0 actions=CONTROLLER:65535

In addition to the Table-miss flow entry, two flow entries have been added.

(1). Incoming port (in_port): 2, Destination MAC address (dl_dst): Host 1 → Actions: Output to port 1 (2). Incoming port (in_port): 1, Destination MAC address (dl_dst): Host 2 → Actions: Output to port 2

The entry in (1) is referenced twice (n_packets), and the entry in (2) is referenced once. Since (1) is a communication from host 2 to host 1, the ARP reply (2 in the previous table) and the ICMP echo reply (4 in the previous table) are matched. (2) is the communication from host 1 to host 2 by ICMP echo request (3 in the above table). The ARP request (1 in the table above) has been sent to all hosts and is not counted.

The contents of tcpdump have been updated, so let's check it.

Host 1 console

22:37:49.681949 00:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, length 28
22:37:49.727635 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, length 28
22:37:49.727666 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo request, id 1907, seq 1, length 64
22:37:49.771373 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 1907, seq 1, length 64
22:37:54.776004 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, length 28
22:37:54.776045 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Reply 10.0.0.1 is-at 00:00:00:00:00:01, length 28

The first line is an ARP request that looks for host 2 from host 1 itself. The second line is the ARP reply from host 2. The third line is an ICMP echo request from host 1 itself to host 2. The fourth line is the ICMP echo reply from host 2. The 5th and 6th lines are like ARP Request and Reply for updating the ARP table.

Host 2 console

22:37:49.684703 00:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, length 28
22:37:49.684727 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, length 28
22:37:49.771102 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo request, id 1907, seq 1, length 64
22:37:49.771171 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 1907, seq 1, length 64
22:37:54.774704 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, length 28
22:37:54.777621 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Reply 10.0.0.1 is-at 00:00:00:00:00:01, length 28

The first line receives the ARP request sent by host 1 throughout. The second line is an ARP reply from host 2 itself. The third line is the ICMP echo request received from host 1. The fourth line is an ICMP echo reply from host 2 itself. The 5th and 6th lines are like ARP Request and Reply for updating the ARP table.

Host 3 console

22:37:49.684694 00:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, length 28

Host 3 only receives the ARP request that Host 1 originally sent to the whole. It is not addressed to itself, so it is not responding.

Summary

Did it! I was able to implement a switching hub using OpenFlow ...! !! So far, I wrote so far, but in OpenFlow, a logical output port called NORMAL port is specified as an option, and if NORMAL is specified for the output port, packets are processed using the original function of the switching hub. It will be like. In other words, you can make it act as a switching hub simply by instructing it to output all packets to the NORMAL port. There is no need to bother to implement a switching hub. That said, it was enough to understand some of the things that the SDN and Ryu frameworks can do. The creation of this switching hub is in line with the contents of the e-book or Wiki prepared by the Ryu official. In the future, the above-mentioned firewall and router implementation methods are also described, and not only emulating physical devices, but also the advantages unique to SDN are introduced. For example, Ryu has a REST linkage function, and flow tables can be added / updated from an external program without going through a controller.

It's been said that SDN eliminates the need for network technicians, but it's an eyebrow. I also hear that programming becomes part of compulsory education. In that case, coding will become a general education, and the time may come when people who know network technology will naturally configure, control, and manage networks with their own programming technology. When I was a programmer, I often heard the term "full stack engineer". [IT Glossary](http://e-words.jp/w/%E3%83%95%E3%83%AB%E3%82%B9%E3%82%BF%E3%83%83%E3 % 82% AF% E3% 82% A8% E3% 83% B3% E3% 82% B8% E3% 83% 8B% E3% 82% A2.html) says as follows.

For example, in the case of building and operating websites and web services, server and network procurement and settings, server-side software environment construction and programming, database design, web design, client-side programming and HTML./Engineers who have knowledge and experience in all related fields such as CSS coding and can build sites, launch services, operate, etc. on their own

I didn't realize it when I knew only the world of software, but the real full-stack engineer may be a three-dimensional engineer who knows the physical layer of the OSI 7 layer, the application layer, and the front and back of the application layer. Absent···. Strange. Computers and IT technology are meant to make us easier, but there are more and more things we need to remember and know.

References

Introducing presentations, dissertations, web pages, etc. that I referred to when writing this article.

paper

SDN Guideline NTT Communications Next-generation network considered by NTT, the largest carrier. SDN presents a future in which network contractor administrators can (to some extent) tweak their network configurations as they please.

presentation

New network control technology OpenFlow and how to use it It's old information, but it explains the concept of SDN and OpenFLow in an easy-to-understand manner with many figures. NEC is a company that has participated in SDN activities from the beginning.

Openflow experiment In addition to the operation of OpenFlow, we are conducting an interconnection experiment of multiple switches.

SDN operational issues and benefits from the experience of developing SDN devices such as OpenFlow Switch SDN, which has many advantages, also has challenges. My article didn't mention it, so please read this slide.

SDN latest trends and application examples There are references to SDN protocols other than OpenFlow and frameworks other than Ryu. Reading this slide, of course, it seems that Ryu's official text does not explain all the features of Ryu.

[Okinawa Open Laboratory Sponsored 1st Hands-on Seminar (RYU, vSwitch)](https://www.okinawaopenlabs.org/wp/wp-content/uploads/%E7%AC%AC1%E5%9B%9E%E3 % 83% 8F% E3% 83% B3% E3% 82% BA% E3% 82% AA% E3% 83% B3% E3% 82% BB% E3% 83% 9F% E3% 83% 8A% E3% 83 % BC.pdf) A hands-on seminar held by NTT Communications, the developer of Ryu, in Okinawa in 2014. I envy you.

SDN Study Group-Current and Future of SDN Technology- Although the explanation is omitted this time, there are "hop-by-hop type" and "overlay type" in SDN. The straightforward method is a hop-by-hop type, but companies are also promoting an overlay type that can utilize the existing infrastructure. This slide describes the current state of SDN from a corporate perspective.

Articles on the internet

SDN (1/5) that you can absolutely understand in 5 minutes I can understand it in 5 minutes (laughs)

The Ideal and Reality of SDN: Thinking about the Realistic Use of SDN in Network Operations A sequel to the above article, it explains the ideals and reality of SDN. The level is higher than other articles.

Aiming for network engineers-What is SDN? A plain article explains SDN. We encourage you to read the entire series.

Ryu SDN Framework-Open Source SDN Platform Software It seems to be an interview with the Ryu developer in a magazine called NTT Technology Journal.

Participating in a seminar about OpenFlow controller Ryu Impressions of Ryu's seminar. There are not so many study sessions for SDN, and there is even less information when it comes to Ryu (however, Ryu studies compared to other OpenFlow frameworks in terms of the quality and quantity of Japanese documents and the ease of preparing a development environment. I think it's easy). I also want to participate in the study session.

Tech-Circle #19 SDN_Trema Hands-on I participated the other day. Ryu wasn't mentioned, but it was interesting, such as the SDN used for business and the current SDDC (Software Defined Datacenter, that is, the fearless idea of virtualizing an entire data center).

SDN Basic Course for Programmers 1: What is SDN SDN Basic Course for Programmers 2: OpenFlow Controllers and Switches SDN Basic Course for Programmers 3: Try Making a Switching Hub with Ryu