一個簡單的SDN實驗-有解無憂

使用Ryu控制器和Mininet做的SDN仿真實驗

安裝Ryu控制器和Mininet軟體部分包括搭建軟體實驗環境網上已有許多教程，可以參考其他的資源，

本次實驗的實驗內容：

使用ryu控制器自帶的app案例中的simple_switch.py進行創建SDN控制器
使用mininet圖形化用戶界面創建網路拓撲并保存為py檔案；
使用wireshark抓包來查看openflow協議的基本資料包型別以及查看SDN控制器的作業流程
使用pingall命令查看主機的連通性
使用mininet相關命令查看創建網路拓撲的各個埠并標注到拓撲結構上
使用mininet的查看流表和添加drop流表等查看SDN控制器的作業流程
斷開某條鏈路，啟用pingall命令查看流表和網路連通性，

mininet創建網路拓撲一共有三種方式，分別是命令列式、圖形化用戶界面方式還有python腳本代碼，由于編者需要比較創建比較復雜的網路拓撲結構，所以使用命令列的形式創建網路拓撲結構達不到本次實驗的要求，再加上圖形化用戶界面創建網路拓撲更加方便和隨意，能夠很方便的通過圖形化用戶界面生成python腳本，如果圖形化用戶界面生成的腳本不符合要求，也可以很方便的對腳本進行修改，可以減少很多作業量，因此本文采用了mininet圖形化用戶界面進行創建網路拓撲結構，

本次通過mininet創建的網路拓撲結構圖

圖中包含一個SDN控制器和5個支持Openflow協議的交換機以及8臺主機

mininet創建上述網路拓撲的python代碼：

#!/usr/bin/python

from mininet.net import Mininet
from mininet.node import Controller, RemoteController, OVSController
from mininet.node import CPULimitedHost, Host, Node
from mininet.node import OVSKernelSwitch, UserSwitch
from mininet.node import IVSSwitch
from mininet.cli import CLI
from mininet.log import setLogLevel, info
from mininet.link import TCLink, Intf
from subprocess import call

def myNetwork():

    net = Mininet( topo=None,
                   build=False,
                   ipBase='10.0.0.0/8')

    info( '*** Adding controller\n' )
    c0=net.addController(name='c0',
                      controller=RemoteController,
                      ip='127.0.0.1',
                      protocol='tcp',
                      port=6633)

    info( '*** Add switches\n')
    s4 = net.addSwitch('s4', cls=OVSKernelSwitch, dpid='0000000000000004')
    s2 = net.addSwitch('s2', cls=OVSKernelSwitch, dpid='0000000000000002')
    s3 = net.addSwitch('s3', cls=OVSKernelSwitch, dpid='0000000000000003')
    s1 = net.addSwitch('s1', cls=OVSKernelSwitch, dpid='0000000000000001')
    s5 = net.addSwitch('s5', cls=OVSKernelSwitch, dpid='0000000000000005')

    info( '*** Add hosts\n')
    h7 = net.addHost('h7', cls=Host, ip='10.0.0.7', defaultRoute=None)
    h3 = net.addHost('h3', cls=Host, ip='10.0.0.3', defaultRoute=None)
    h2 = net.addHost('h2', cls=Host, ip='10.0.0.2', defaultRoute=None)
    h8 = net.addHost('h8', cls=Host, ip='10.0.0.8', defaultRoute=None)
    h5 = net.addHost('h5', cls=Host, ip='10.0.0.5', defaultRoute=None)
    h6 = net.addHost('h6', cls=Host, ip='10.0.0.6', defaultRoute=None)
    h1 = net.addHost('h1', cls=Host, ip='10.0.0.1', defaultRoute=None)
    h4 = net.addHost('h4', cls=Host, ip='10.0.0.4', defaultRoute=None)

    info( '*** Add links\n')
    net.addLink(s1, s2)
    net.addLink(s2, s3)
    net.addLink(s3, s4)
    net.addLink(s4, s5)
    net.addLink(s1, h1)
    net.addLink(s1, h2)
    net.addLink(s2, h3)
    net.addLink(s3, h4)
    net.addLink(s3, h5)
    net.addLink(s4, h6)
    net.addLink(s4, h7)
    net.addLink(s5, h8)

    info( '*** Starting network\n')
    net.build()
    info( '*** Starting controllers\n')
    for controller in net.controllers:
        controller.start()

    info( '*** Starting switches\n')
    net.get('s4').start([c0])
    net.get('s2').start([c0])
    net.get('s3').start([c0])
    net.get('s1').start([c0])
    net.get('s5').start([c0])

    info( '*** Post configure switches and hosts\n')

    CLI(net)
    net.stop()

if __name__ == '__main__':
    setLogLevel( 'info' )
    myNetwork()

由于編者水平有限，對于Ryu控制器端的代碼并不清楚，只知道一點基礎的內容，所以本文的實驗內容講解的是使用安裝好Ryu控制器后App目錄下的自帶的支持openflow協議1.0版本的simple_switch.py檔案實作了SDN控制器對于交換機流表的下發操作，

simple_switch.py檔案的代碼


"""
An OpenFlow 1.0 L2 learning switch implementation.
"""


from ryu.base import app_manager
from ryu.controller import ofp_event
from ryu.controller.handler import MAIN_DISPATCHER
from ryu.controller.handler import set_ev_cls
from ryu.ofproto import ofproto_v1_0
from ryu.lib.mac import haddr_to_bin
from ryu.lib.packet import packet
from ryu.lib.packet import ethernet
from ryu.lib.packet import ether_types


class SimpleSwitch(app_manager.RyuApp):
    OFP_VERSIONS = [ofproto_v1_0.OFP_VERSION]

    def __init__(self, *args, **kwargs):
        super(SimpleSwitch, self).__init__(*args, **kwargs)
        self.mac_to_port = {}

    def add_flow(self, datapath, in_port, dst, src, actions):
        ofproto = datapath.ofproto

        match = datapath.ofproto_parser.OFPMatch(
            in_port=in_port,
            dl_dst=haddr_to_bin(dst), dl_src=haddr_to_bin(src))

        mod = datapath.ofproto_parser.OFPFlowMod(
            datapath=datapath, match=match, cookie=0,
            command=ofproto.OFPFC_ADD, idle_timeout=0, hard_timeout=0,
            priority=ofproto.OFP_DEFAULT_PRIORITY,
            flags=ofproto.OFPFF_SEND_FLOW_REM, actions=actions)
        datapath.send_msg(mod)

    @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
    def _packet_in_handler(self, ev):
        msg = ev.msg
        datapath = msg.datapath
        ofproto = datapath.ofproto

        pkt = packet.Packet(msg.data)
        eth = pkt.get_protocol(ethernet.ethernet)

        if eth.ethertype == ether_types.ETH_TYPE_LLDP:
            # ignore lldp packet
            return
        dst = eth.dst
        src = eth.src

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

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

        # learn a mac address to avoid FLOOD next time.
        self.mac_to_port[dpid][src] = msg.in_port

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

        actions = [datapath.ofproto_parser.OFPActionOutput(out_port)]

        # install a flow to avoid packet_in next time
        if out_port != ofproto.OFPP_FLOOD:
            self.add_flow(datapath, msg.in_port, dst, src, actions)

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

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

    @set_ev_cls(ofp_event.EventOFPPortStatus, MAIN_DISPATCHER)
    def _port_status_handler(self, ev):
        msg = ev.msg
        reason = msg.reason
        port_no = msg.desc.port_no

        ofproto = msg.datapath.ofproto
        if reason == ofproto.OFPPR_ADD:
            self.logger.info("port added %s", port_no)
        elif reason == ofproto.OFPPR_DELETE:
            self.logger.info("port deleted %s", port_no)
        elif reason == ofproto.OFPPR_MODIFY:
            self.logger.info("port modified %s", port_no)
        else:
            self.logger.info("Illeagal port state %s %s", port_no, reason)

實驗步驟和現象

首先啟動Ryu控制器，使用ryu-manager simple_switch.py命令啟動Ryu控制器

注意：在使用mininet進行網路拓撲創建之前，一定要首先船艦Ryu遠程控制器，否則mininet會自動創建一個控制器，

啟動Ryu控制器之后，等待創建網路拓撲；

啟動已經創建好的mininet網路拓撲腳本

可以看到Ryu控制器端進行了回應，包括了packet in的埠等資訊

創建完成之后，馬上使用dpctl dump-flows 命令查看交換機中的流表，由于是剛創建的，所以SDN控制器并沒有下發流表，因此各個交換機中的流表應該是空的才對

執行pingall命令測驗連通性，可以看到，所有的主機之間都能進行資料傳輸，整個網路都是連接的，

由于執行了pingall命令，所以當交換機查找內部沒有流表匹配項的時候，就會向SDN控制器請求流表的下發，以讓自己能夠知道應該怎樣將資料通過哪個埠和哪個交換機傳輸出去，因此本次使用dpctl dump-flows命令查看流表的時候，每個交換機都應該有流表，且流表資料項很多，包括了到每個主機的通信需要走的道路，

再執行pingall命令之前，使用命令wireshark，可以開啟wireshark軟體（編者是最開始安裝了wires hark抓包軟體的），然后通過抓包獲取查看openflow協議的資料包，和整個資料包的分析，

可以看到，本次實驗中，支持的是openflow協議1.0版本，同時包括了許多的資料包型別，包括Packet_in和Packet_out資料包、Request和Reply資料包等，下面進行簡單的解釋，

主機①想要向主機②發送資料，即執行pingair h1 h2時，資料通過某埠到達交換機；
左邊的交換機查找內部的流表，沒有發現流表匹配項，所以向控制器發送了Packet_in資料包，請求下發流表；
控制器接收到資料包之后，發送Request資料包給交換機，請求交換機的Mac地址、IP地址，支持的協議版本的資訊，然后交換機發送reply資料包給控制器；控制器知道了之后，就發送Packet_out資料包給交換機
交換機接收到流表之后就匹配，知道自己要怎么才能發送資料給主機②了，然后就發送資料給右邊的交換機了，
左邊的交換機接收到資料包之后，也沒有找到流表項應該怎么發送給主機②，所以它也向控制器發送請求，請求下發流表
控制器下發流表
交換機②知道流表之后，就按照流表的轉發規則發送給了主機②，自此主機②與主機①進行了資料傳輸，以后再次從主機一到主機二傳輸就不需要這樣了，因為交換機內部已經有了流表，

接下來洗掉交換機中的流表，使之變為空表，然后進行接下來的實驗，使用dpctl del-flows 洗掉所有交換機中的流表，然后使用dpctl dump-flows查看是否洗掉流表成功

現在看到上面的網路拓撲結構，然后添加Drop流表，Drop流表的意思是，交換機查詢到這個流表項之后，就將從那個埠接收到的資料包直接扔掉，不轉發，命令是 dpctl add-flow in_port=3,action=drop

現在可以再次執行pingall命令查看各個主機之間的連通性，可以看到只有主機h8、h7、h5、h1才能夠進行資料通信，其它的主機不能進行通信

解釋：可以再次看到前面的拓撲圖

其中主機2、主機3、主機4、主機6分別連接了交換機s1的埠3、交換機s2的埠3、交換機s3的埠3、交換機s4的埠3，所以當資料發送到這個埠的時候，交換機查到了流表匹配項，然后將資料包直接洗掉，所以這四個主機不能與其他主機之間進行資料通信，

再次使用命令dpctl dump-flows查看交換機中的流表，可以看到交換機1內部的流表除了有我們之前添加的drop流表之外，還有許多的其它流表，這就是因為沒有在交換機內部匹配到流表項，所以主動向控制器發送請求，控制器下發了流表，

接下來洗掉所有的流表，并斷開s3與h5，s4與h7之間的連接，并洗掉交換機中的所有流表，并查看流表，

拓撲圖示為：
先使用link s3 h5 down；link s4 h7 down 斷開物理連接，然后使用dpctl del-flows洗掉前面的所有流表

再次執行pingall命令，測驗網路的連通性并查看交換機中的流表項，

可以看到，h5、h7不能與其他主機進行連接，因為直接將物理連接就關閉了，所以控制器也沒有辦法解決，

然后使用link s3 h5 up，啟用s3與h5之間的連接，再洗掉所有流表，測驗連通性

其網路拓撲如圖所示：

洗掉所有流表，并查看是否洗掉成功；

再次執行pingall命令，查看網路的連通性，可以看到除了h7不能通信，其余的都可以，

再啟用s4與h7之間的鏈路連接，然后不洗掉流表項，直接pingall查看連通性，可以看到全部都可以進行通信，

通過本次實驗，驗證了SDN的可編程性，同時驗證了SDN控制器自適應下發流表，對網路有很好的適應性，同時能夠看到有openflow協議在SDN南向介面中的具體應用，由于編者能力有限，有錯誤和解釋錯誤的請批評指正，另外關于資料包解釋的圖片來源于網路，侵權私信聯系洗掉，謝謝！

資料附（mininet基本命令和基本知識）

mn --controller=remote

如果controller沒有指定則使用mininet自帶的控制器，那樣就只是模擬了傳統的網路架構，沒有使用SDN的架構，同時在使用mn --controller-remote的時候，如果沒有開啟ryuSDN控制器，那么路由器之間由于沒有流表也是不能相互通信的，即不能ping通的，

Mininet部分命令

help獲取幫助串列

nodes查看網路拓撲中節點的狀態

links顯示鏈路健壯性資訊

net顯示網路拓撲

dump顯示每個節點的介面設定和表示每個節點的行程PID

pingall測驗網路中所有節點的連通性

pingpair只測驗前兩個主機間的連通性

iperf兩個節點之間進行iperftcp帶框測驗

link 禁用或啟用節點間的鏈路如（link s1 s2 up 啟用，link s1 s2 down禁用）

h1 ping h2 主機h1和h2節點之間進行ping測驗

h1 ifconfig 查看host1的終端

xterm h1 打開host1的終端

mininet創建網路拓撲的三種方式：

命令列創建：

? 單一拓撲：整個網路只有一個交換機，這個交換機下可以下掛1-n個交換機

? 命令：mn --topo=single,3

? 線性拓撲：交換機呈線性排列，且每個交換機所連接的主機數目只有一個

? 命令：mn --topo=linear,3

? 樹形拓撲：交換機呈樹形排列，其中depth代表深度，交換機的深度，fanout代表廣度，即每個交換機連接的數目，

? 命令：mn --topo=tree,depth=2,fanout=3

python代碼檔案創建：

圖形化用戶界面創建：

openflow協議作業原理

openflow流表常用配置命令

查看流表：dpctl dump-flows

添加流表：dpctl add-flow in_port=1,actions=output:2

添加丟棄資料包流表：dpctl add-flow in_port=2,actions=drop

洗掉所有交換機的所有流表：dpctl del-flows

洗掉所有交換機的特定流表項：dpctl del-flows in_port=2

洗掉某個交換機的流表：sh ovs_ofctl del-flows s1 in_port=2

度，即每個交換機連接的數目，