4. OpenFlow流表下发实战

前几节我们已经理解了SDN的分层结构和OpenFlow协议的基本字段。但真正让流表"动起来"，需要控制器与交换机之间的实际交互。本节我们用一个最小可运行的实验，把"控制器下发流表"这件事从抽象概念变成可观察的现象：用Mininet搭建一个包含一台OpenFlow交换机和两台主机的拓扑，用Ryu编写一个自定义应用，让控制器主动向交换机下发一条精确匹配的流表项，最后通过ping和流表统计验证转发行为。

实验环境与拓扑设计

Mininet通过轻量级虚拟化在一台机器上模拟主机、交换机和链路。我们使用最简单的线性拓扑：h1—s1—h2，其中s1是OpenFlow 1.3交换机，默认连接远程控制器。Ryu运行在本地6653端口，作为s1的控制器。这样数据平面和控制平面分离，s1启动时没有流表，任何数据包都会触发Packet-In消息上报给Ryu。

实验的关键参数如下：控制器监听127.0.0.1:6653；交换机使用OpenFlow 1.3；h1的IP为10.0.0.1/24，h2为10.0.0.2/24；我们计划下发的流表匹配条件是"入端口为1、目的IP为10.0.0.2、以太网类型为IPv4"，动作为"从端口2转发出去"。这条流表一旦安装，h1到h2的流量就不再需要控制器逐包干预。

编写Ryu应用：从Packet-In到Flow-Mod

Ryu应用本质上是一个继承app_manager.RyuApp的Python类，通过装饰器注册事件处理器。我们关注两个事件：交换机连接时的EventOFPSwitchFeatures，以及收到数据包时的EventOFPPacketIn。前者用于确认交换机能力，后者用于触发流表下发。

下面是一个精简但完整的示例应用，逻辑是：当收到目的地址为10.0.0.2的IPv4数据包时，安装一条匹配该目的IP的流表，动作是从入端口以外的端口转发；同时把当前这个包也转发出去，避免首包丢失。

from ryu.base import app_manager
from ryu.controller import ofp_event
from ryu.controller.handler import CONFIG_DISPATCHER, MAIN_DISPATCHER, set_ev_cls
from ryu.ofproto import ofproto_v1_3
from ryu.lib.packet import packet, ethernet, ipv4

class SimpleFlowApp(app_manager.RyuApp):
    OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]

    def __init__(self, *args, **kwargs):
        super(SimpleFlowApp, self).__init__(*args, **kwargs)

    @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)

    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)

    @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']

        pkt = packet.Packet(msg.data)
        eth = pkt.get_protocol(ethernet.ethernet)
        ip = pkt.get_protocol(ipv4.ipv4)
        if ip is None or ip.dst != '10.0.0.2':
            return

        out_port = 2 if in_port == 1 else 1
        match = parser.OFPMatch(eth_type=0x0800, ipv4_dst='10.0.0.2')
        actions = [parser.OFPActionOutput(out_port)]
        self.add_flow(datapath, 100, match, actions)

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

这段代码中有两个关键点值得注意。第一，priority=0的默认流表把所有未匹配流量送到控制器，这是控制器"看到"网络的第一步；第二，priority=100的精确流表优先级更高，一旦安装，后续同类型流量直接命中，不再产生Packet-In。这正是SDN"一次学习、多次转发"的典型模式。

启动与验证流程

先启动Ryu：ryu-manager simple_flow_app.py，看到"installing default flow entry"之类的日志说明交换机已连接。再启动Mininet：sudo mn --topo=linear,2 --controller=remote,ip=127.0.0.1,port=6653 --switch=ovs,protocols=OpenFlow13。进入Mininet命令行后，先执行h1 ping -c 3 h2，观察首次ping的延迟通常略高，因为第一个包触发了Packet-In和流表安装。

随后在Mininet中执行sh ovs-ofctl -O OpenFlow13 dump-flows s1，可以看到类似下面的输出：

cookie=0x0, duration=12.3s, table=0, n_packets=0, n_bytes=0,
priority=0 actions=CONTROLLER:65535
cookie=0x0, duration=8.1s, table=0, n_packets=3, n_bytes=294,
priority=100,ip,in_port=1,nw_dst=10.0.0.2 actions=output:2

这里n_packets=3说明有3个包命中了这条精确流表，与ping的3个请求包对应。如果再次执行ping，n_packets会继续增长，而控制器不再收到Packet-In，说明流表已经稳定生效。这就是连通性验证与流表验证的结合：ping通说明转发正确，计数器增长说明流表被命中，两者缺一不可。

常见问题与排查思路

实验中最容易遇到三类问题。第一，交换机连接不上控制器，通常是端口不一致或Ryu未启动，可用ss -lntp | grep 6653确认监听状态。第二，ping不通但流表已下发，常见原因是out_port计算错误或动作端口写反，此时应检查拓扑中端口编号与ovs-ofctl show s1的输出是否一致。第三，流表存在但n_packets始终为0，说明匹配字段与实际报文不符，例如把ipv4_dst写成了ipv4_src，或者忽略了eth_type导致匹配范围过窄。

通过本节实验，你应该已经能够独立完成"编写Ryu应用—启动Mininet—下发流表—验证转发"的完整链路。这条链路虽然简单，却是后续学习多级流表、组表、计量以及NFV服务链的基础。掌握它，意味着你已经能够用代码直接控制网络转发行为，而不只是停留在概念层面。