CN106302021A - 一种网络流转发异常检测方法 - Google Patents

一种网络流转发异常检测方法 Download PDF

Info

Publication number
CN106302021A
CN106302021A CN201610689064.6A CN201610689064A CN106302021A CN 106302021 A CN106302021 A CN 106302021A CN 201610689064 A CN201610689064 A CN 201610689064A CN 106302021 A CN106302021 A CN 106302021A
Authority
CN
China
Prior art keywords
packet
list item
network flow
stream
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201610689064.6A
Other languages
English (en)
Other versions
CN106302021B (zh
Inventor
李琦
庞春辉
江勇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Graduate School Tsinghua University
Original Assignee
Shenzhen Graduate School Tsinghua University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Graduate School Tsinghua University filed Critical Shenzhen Graduate School Tsinghua University
Priority to CN201610689064.6A priority Critical patent/CN106302021B/zh
Publication of CN106302021A publication Critical patent/CN106302021A/zh
Application granted granted Critical
Publication of CN106302021B publication Critical patent/CN106302021B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种检测网络流转发异常的方法，所述网络流是在动态配置的软件定义网络中的网络流，包括两部分：一部分为基于Packet‑In的异常转发检测机制，控制层收到一个Packet‑In后，通过流表项查找引擎查找产生该Packet‑In的交换机及其前一跳交换机，及所述交换机处理该Packet‑In对应的流的流表项；将查找结果传递给验证逻辑判断该Packet‑In是否由被异常转发的网络流导致；一部分为流表项编辑机制，在基于目的地址转发的网络中，流表项编辑机制在控制层下发的流表项中强制加入对应交换机的端口号的入端口匹配域。本发明具有开销小、实现简单以及不依赖于厂商专有软硬件设备的优点。

Description

一种网络流转发异常检测方法
技术领域
本发明涉及网络控制领域，特别是涉及一种网络流转发异常检测方法。
背景技术
自软件定义网络(Software-Defined Networking,SDN)的概念提出以来，越来越多的实际应用(Google数据中心、Stanford校园网)证明了它在网络配置和管理上的巨大优势。越来越多的数据中心、大学校园以及大型企业都开始在自己的内部网络中部署SDN以提高网络效率、降低运营成本。从网络架构的角度来说，网络可以分为两个层：数据层和控制层。数据层描述交换机如何转发数据包，即如何将一个数据包从一个端口输出到另一个端口，它属于交换机的实现逻辑；而控制层描述的是网络应当如何将网络流交付到目的，即规划网络流的转发路径。在传统的IP网络中，数据层和控制器层都由分布式的交换机实现。这种方式提高了网络的容错能力，但却使得网络配置和网络管理非常复杂。SDN的核心思想在于分离网络的数据层与控制层。这样，SDN将数据层继续留在分布式的交换机上，而将控制层集中到远程的控制器上。
SDN通过流表项来控制网络流的转发。流表项由控制层生成，并配置到相应的交换机上。每一个交换机有一个或多个流表，每一个流表可以包含多条流表项。流表项的格式如图1所示。Match Fields指明如何匹配数据包，它支持匹配数据包的包头，比如MAC源地址(mac_src)、MAC目的地址(mac_dst)、以太网帧类型(eth_type)、IP源地址(ip_src)、IP目的地址(ip_dst)等。同时，它支持按照网络流的入端口(in_port)进行匹配；Priority表示流表项被匹配的优先级，当多条流表项被匹配成功时，优先级最高的流表项被最终匹配；Counters表示被这条流表项匹配的数据包的总数、总字节数；Instructions指明需要对被匹配数据包执行的一些操作，比如修改数据包；Timeouts指明这条流表项的过期时间，一旦流表项过期，交换机会自动删除它；控制层可以利用Cookie存储额外的数据；Flags指明交换机如何管理流表项，比如FPFF_SEND_FLOW_REM表示交换机在删除流表项是必须通知控制器。此外，每一条流表项可以关联一组动作(Actions)，这些动作包括修改数据包包头(包括IP源地址、IP目的地址、区分服务等)、设定数据包输出端口(out_port)等。
当一个数据包到达交换机时，交换机尝试将它与第一张流表中的流表项进行匹配。如果匹配成功，则执行被匹配流表项的Instruction并更新流表项的Counters，如果数据包需要继续匹配剩下的流表，被匹配的流表项需要指定接下来到哪一张流表里去继续匹配。如果第一张流表里没有任何流表项与数据包匹配，交换机为这个数据包执行默认的未找到匹配流表项操作(Table Miss)。这个操作可以是将数据包以Packet-In的方式转发到控制器或者直接丢弃。本申请提供要求默认的Table Miss操作是Packet-In。
SDN支持两种配置方式：静态配置(Proactive Configuration)和动态配置(Reactive Configuration)。在静态配置的环境下，控制器预先为网络中的交换机配置流表项，这些流表项使得交换机能转发可能到达这个交换机的所有网络流。而在动态配置中，控制器仅将交换机未找到匹配流表项的操作(Table Miss)配置为Packet-In。当交换机找不到匹配的流表项时，它会将数据包封装到一个Packet-In消息中，然后发送到控制器。控制器根据这个Packet-In和网络拓扑来计算这个流的转发路径、生成流表项，最后将这些流表项下发到转发路径上的交换机。在这些流表项下发之后，这个流就能够在它的转发路径上的交换机上找到匹配的流表项，进而被正常转发。静态配置适合于拓扑结构设计优良、设备固定的网络中，比如数据中心网络；而动态配置适合于设备随时可能移动的网络中，比如校园网络、企业网络等。
SDN分离了网络的数据层和控制层。数据层由交换机构成，它们根据交换机上的流表项来转发数据包。控制层实现网络转发逻辑，它将转发逻辑转化为流表项，并将流表项配置到相应的交换机上。在多数情况下，交换机上的流表项都是被控制层正确配置的，但当网络设备发生故障或者网络出现配置错误时，交换机上的流表项可能会在控制层不知情的情况下发生改变，比如某些流的输出端口可能被错误更改。在这种情况下，某些网络流就会在交换机上发生转发异常：控制层根据自己下发的流表项认为这个流应从一个端口输出，而交换机根据自己的流表项认为这个流应从另一个不同的端口输出。转发异常导致网络流不按照控制器规定的路径转发，而是偏离到了另一个错误的转发路径。这些网络流可能最后成功到达目的地或者在某个交换机上被丢弃。
转发异常导致网络流沿着错误的转发路径转发，这导致这条错误路径上的交换机可以监听被错误转发的网络流。它们可以从这条网络流中提取用户隐私，比如网络账号、密码等。同时转发异常也给网络增加了不确定性，使得网络难以管理，网络服务提供商(Internet Service Provider,ISP)不得不花费更多的成本来完成网络调度、硬件升级。
目前，检测转发异常的研究工作可以分为两个种类：基于探测包和基于流量统计。基于探测包的方案利用探测包来探测网络中所有的流表项。如果存在转发异常，那么某些探测包就会被错误的转发，在目的设备也就不会收到这些探测包。如果一个探测包没有被收到，则说明负责转发它的流表项存在异常。基于探测包的检测方案包括ATPG、SDNTraceroute等。而基于流量统计的检测方案利用流的转发路径上转发这个流的流表项的流量统计信息，即Counters域的值来判断流是否出现转发异常。如果网络流没有出现转发异常，那么转发路径上的所有流表项转发了同一组数据包，它们的Counters域的值应该相等。如果这些Counters域的值存在很大的差别，则说明这个网络流出现了转发异常。基于流量统计的检测方案包括SPHINX等。接下来，我们以ATPG和SPHINX来说明这两种检测方案。
ATPG是Automatic Test Packet Generation(自动测试数据包生成)的简写。它结合网络拓扑结构分析网络中所有的流表项，进而确定每一条网络流会被哪些流表项转发。然后它寻找一组最少的流，这组流使得网络中任意流表项至少会转发这组流中的某一个。其实这是一个子集覆盖问题：用与流相关的流表项(子集)来覆盖所有的流表项。然后ATPG从每一个选择的流中随机抽取一个数据包作为探测包。ATPG发送这些探测包，并在这些数据包的目的主机上接收这些探测包。如果探测包被正常收到，说明转发这个测试数据包对应的流的流表项正常工作。否则说明转发这个流的流表项存在异常。
SPHINX使用流量统计数据来检测转发异常，它假定流都按照源、目的MAC对进行转发。即网络中每一条流表项都会匹配源MAC地址、目的MAC地址。这样的好处就是不存在流聚合的问题。所以为一条流下发的流表项仅转发这条流，并有着相同的流量统计数据。SPHINX为每一个条构建转发路径，并定期提取转发路径上转发这个流的流表项的流量统计信息，然后比较这些流量统计信息。如果这些流量统计信息大致相同，则说明流表项工作正常；否则认为流表项存在转发异常。
基于探测包的检测方案使用探测包来检测流表项。ATPG由于需要结合拓扑分析流表项之间的关系，它的时间复杂度非常高。同时考虑到注入和接收探测包的开销，它的性能不会很高。同时，探测包仅仅是一条网络流的数据包的一个特例，探测包的正常转发无法保证网络流的正常转发。所以存在漏报。
基于流量统计的方法需要频繁读取流量统计数据，开销大。同时由于控制器到各个交换机的时延不同、各个交换机的时钟也有差异，网络流的流量统计数据只能是估计值，容易带来误差。而且这个误差可能随着时间而累加。出于同样的原因，基于流量统计的机制无法检测小流。因为对于一个小流，无论是否有转发异常，交换机上的流量统计数据都大致相等，因此，提出一种快速检测网络转发异常的方法是亟待解决的问题。
发明内容
本发明目的就是为了解决检测网络转发异常的问题。
在动态配置的SDN网络中，Packet-In的产生和前一跳交换机上处理这条流的流表项的输出端口、当前交换机上的流表项有关。本申请通过验证产生Packet-In的上一跳交换机(BPIS,Before the Packet-In Switch)和产生Packet-In的交换机(PIS,Packet-InSwitch)的流表项来检测网络转发异常。
每一个网络流有其规定的转发路径，网络流仅应该出现在它规定的转发路径上。所以当一个网络流在某个交换机上触发Packet-In时，这两个条件一定能够满足：1)BPIS上转发这个流的流表项将这条网络流输出到PIS上；2)PIS上没有能够转发这条网络流的流表项。如果以上两点中的任意一点不成立，那么说明这个Packet-In是由被错误转发的网络流产生的。也就是说，这个Packet-In对应的网络流出现了转发异常。
尽管上述部分能通过Packet-In检测到被错误转发的网络流。但是，并不是所有被错误转发的网络流都会产生Packet-In。为了保证这点，我们可以编辑控制层下发到数据层的流表项，使得为不同网络流生成的流表项有一定程度的差异，进而保证被错误转发的网络流尽可能的触发Packet-In。本申请结合两个实施例来说明如何在基于源、目的地址转发网络和基于目的地址转发的网络中编辑流表项。
综上，本申请的要点包括：1)一种基于Packet-In的产生位置来判断网络是否发生了转发异常。2)一种流表项编辑机制，在每一条流表项的匹配字段中加入数据包的入端口域来使其匹配网络流的入端口，进而使得被错误转发的网络流一定会产生Packet-In。
本发明的技术问题通过以下的技术方案予以解决：
一种检测网络流转发异常的方法，所述网络流是在动态配置的软件定义网络中的网络流，其特征在于，包括以下两个方面：
A1:基于Packet-In来判断网络流是否被异常转发，用于根据Packet-In发现异常；
A2:一种流表项编辑机制，确保被异常转发的网络流一定会产生Packet-In。
根据本发明的另一个具体方面A1中采用流表项查找引擎和验证逻辑来判断网络流是否被异常转发；控制器将收到的Packet-In发送给所述流表项查找引擎，所述流表项查找引擎查找这个产生这个Packet-In的交换机PIS和产生Packet-In的交换机的前一跳交换机BPIS。所述验证逻辑验证BPIS是否确实将网络流转发到PIS，以及PIS是否确实不存在能够处理这个流的流表项，进而判断网络流是否发生转发错误。
根据本发明的另一个具体方面所述表项查找引擎根据交换机上的流表项，为每一个交换机构建两棵前缀Trie树(正向查找树和反向查找树，所述正向查找树和反向查找树用于根据一个数据包或者Packet-In快速获取所述PIS、BPIS以及它们上转发所述Packet-In对应的数据包的流表项，所述流表项查找引擎会随着所述流表项的下发或者修改而更新。
根据本发明的另一个具体方面，所述验证逻辑包括：
如果所述BPIS不存在，即所述PIS的前一跳设备是主机，PIS上能够转发对应数据包的流表项CFR也不存在，则说明这个Packet-In是一条新流导致，是正常产生的；
如果BPIS不存在，但PIS上存在CFR，则说明CFR可能没有工作；假设控制器在一段时间内(τ)收到N个Packet-In；如果N的值很大，则说明CFR确实没有正常工作；否则只能发出警告，让管理员手动验证这类问题。
如果BPIS存在，但BCFR不存在，则说明这个Packet-In是被错误转发的网络流触发的；
如果BPIS存在，BCFR存在，但是这条流表项不将数据包转发到PIS，则说明这个Packet-In是被错误转发的网络流触发的；
如果BPIS存在，且BCFR存在，且将数据包转发到PIS，CFR也不存在；则说明这个Packet-In是正常的网络流产生的；
如果BPIS存在，BCFR存在，且将数据包转发到PIS，但PIS上存在CFR，则CFR可能没有工作；假设控制器在一段时间内(τ)收到N个Packet-In；如果N的值很大，则说明CFR确实没有正常工作；否则只能发出警告，让管理员手动验证这类问题。
根据本发明的另一个具体方面，A2中，通过编辑控制层下发到数据层的流表项来确保被异常转发的网络流一定会产生Packet-In。
根据本发明的另一个具体方面，在基于目的地址转发的网络中，控制器在它下发的流表项的匹配域中强制加入入端口域，入端口域字段所匹配的值等于所述流表项需要转发的网络流进入目的地址交换机的端口号，当所述入端口域字段与所述交换机端口号不一致时，在所述交换机上，被错误转发的网络流触发Packet-In。
根据本发明的另一个具体方面，在基于源地址、目的地址转发的网络中，控制器不需要做任何其他额外操作。
本发明与现有技术对比的有益效果是：
本发明的检测方法，监测SDN网络中的Packet-In，对它们进行一系列合法性分析，并根据分析结果判断产生Packet-In的交换机是否位于网络流的转发路径上，整个操作所需要的计算资源、内存资源都非常低，具有开销小、不依赖于厂商专有软硬件设备的优点，实现简单。
附图说明
图1是流表项的格式图；
图2本发明检测方法结构示意图；
图3是本发明检测方法逻辑流程图；
图4是基本方法的缺陷图；
图5是本发明技术方案的有效性阐述。
具体实施方式
在检测转发异常的方案中，控制层可以主动探测转发异常，也可以被动监测转发异常。主动探测方案必然要求控制层花费额外的代价来进行探测操作，而被动监测方案仅需要注意到发生转发异常之后的异常事件。本申请提出的是一个被动监测方案，它监测SDN网络中的Packet-In，对它们进行一系列合法性分析，并根据分析结果判断这个Packet-In对应的网络流是否被错误转发。
直观上来看，转发异常存在副作用：一旦网络流离开控制层规定的转发路径，它可能在交换机上找不到匹配的流表项，如果交换机默认Table Miss操作是Packet-In，那么被错误转发的网络流就会触发Packet-In。所以分析Packet-In的产生位置能检测到网络中的转发异常。根据OpenFlow协议的规定：正常情况下，如果一条网络流在某一个交换机上触发Packet-In，那么必须保证两点：
1)产生Packet-In的交换机的前一跳交换机(BPIS)确实将网络流转发到这个交换机(PIS)；
2)这个交换机(PIS)上没有能够处理这条网络流的流表项(CFR)。
如果某个Packet-In使这两点中的任意一点不成立，那么说明这条网络流被错误转发了。本申请基于这个事实，监视SDN网络中的Packet-In消息，然后分析产生Packet-In的交换机的前一跳交换机(BPIS)是否确实将这条网络流转发到产生Packet-In的交换机(PIS)，以及产生Packet-In的交换机(PIS)是否确实不存在能够处理这个流的流表项，进而判断网络流是否发生转发错误。
本申请提出的检测机制可以分为两个部分：流表项查找引擎和验证逻辑。流表项查找引擎根据交换机上的流表项，为每一个交换机构建两棵Trie树：正向查找树、反向查找树。正向查找树能够快速查找匹配一个数据包或者Packet-In的流表项；而反向查找树能够快速查找哪些流表项会输出给定数据包到给定端口。利用这两个能力，我们能够快速获取BPIS、PIS以及这两个交换机上转发一个Packet-In对应的数据包的流表项。由于网络中的流表项会动态地更新，所以流表项查找引擎也会随着流表项更新消息(FlowMod消息)而更新。验证逻辑根据BPIS和PIS上转发Packet-In对应的数据包的流表项来判断这个Packet-In是否是被错误转发的网络流产生的。本检测方法中各个模块的结构示意图如图2所示。其中，实线代表同步逻辑，虚线代表异步逻辑。接下来，将详细介绍整个过程的每一步。
由于网络中的流表项随时在更新，流表项查找引擎也必须随着流表项的更新而更新。这个更新逻辑是异步的，独立于本申请的验证逻辑。为了能够快速查找交换机上能够匹配数据包的流表项，正向查找树根据数据包的所有匹配域建立Trie树。而考虑到流表项可能会更改数据包，反向查找树的索引是流表项的输入数据包的匹配域和输出数据包对应的域。当控制器向某个交换机增加一条流表项时，这个交换机的正向查找树和反向查找树都必须同时插入一条数据。正向查找树的键值为这条流表项匹配的包头空间，而反向查找树的键值为这条流表项匹配的包头空间和输出的数据包包头空间。这里，所谓的包头空间指的是一组数据包的所有包头集合，这个集合可以采用通配符的形式进行合并，进而在正向查找树或反向查找树中仅体现为一个节点。当控制器删除一条流表项时，对应交换机的正向查找树和反向查找树都必须删除对应的流表项。流表项的更新可以使用先删除对应流表项，然后再增加这条流表项来实现。
当控制层收到一个Packet-In后，它将收到的Packet-In交给本申请的检测机制进行分析。本申请首先用这个Packet-In去查询流表项查找引擎，流表项查找引擎根据这个Packet-In返回BPIS、PIS以及这两个交换机上转发对应的数据包的流表项。
验证逻辑根据BPIS是否存在，BPIS上是否存在能够转发对应数据包的流表项(BCFR)，以及PIS上是否存在能够转发对应数据包的流表项(CFR)流表项来判断是否出现转发异常。根据BPIS、BCFR、CFR的存在与否来检测转发异常的检测流程如图3所示，具体分为六种情况：
如果BPIS不存在，即PIS的前一跳设备是主机，CFR也不存在，则说明这个Packet-In是一条新流导致，是正常产生的。
如果BPIS不存在，但PIS上存在CFR，则说明CFR可能没有工作。假设控制器在一段时间内(τ)收到N个Packet-In。如果N的值很大，则说明CFR确实没有正常工作。否则只能发出警告，让管理员手动验证这类问题。
如果BPIS存在，但BCFR不存在，则说明这个Packet-In是被错误转发的网络流触发的。
如果BPIS存在，BCFR存在，但是这条流表项的不将数据包转发到PIS，则说明这个Packet-In是被错误转发的网络流触发的。
如果BPIS存在，且BCFR存在，且将数据包转发到PIS，CFR也不存在。这说明这个Packet-In是正常的网络流产生的。
如果BPIS存在，BCFR存在，且将数据包转发到PIS，但PIS上存在CFR，则CFR可能没有工作。其处理方式与B相同。当然，这里的τ和N是无法直接给出固定值的，不同的网络有着不同的最优值。
本申请提出的触发机制是：通过控制流表项的匹配域来确保被异常转发的网络流一定会产生Packet-In。
上述检测机制保证了本发明能够根据Packet-In精准检测到网络转发异常，但是并不是所有的网络转发异常都会产生Packet-In。本发明通过编辑流表项来保证几乎所有的被错误转发的网络流都会产生Packet-In。具体来说，在基于目的地址转发的网络中，控制器在它下发的流表项的匹配域中强制加入入端口域，入端口域所匹配的值等于所述流表项需要转发的网络流进入目的地址交换机的端口号，当所述入端口域字段与所述交换机端口号不一致时，在所述交换机上，被错误转发的网络流触发Packet-In。而在基于源地址、目的地址转发的网络中，控制器不做任何操作。
具体实施例一
为了保证网络流在被错误转发时能够产生Packet-In，必须保证为不同的网络流生成的流表项要存在一定的差异。这样，当网络流离开由控制器规定的转发路径时，它会在交换机上找不到匹配的流表项，进而产生Packet-In。
本实施例1说明如何在基于源、目的地址转发的网络中使用本技术方案。
基于源、目的地址转发的网络有一个特点：任何被错误转发而离开规定的转发路径的网络流都会触发Packet-In。这使得我们提出的检测机制能够直接应用于这种网络。为了简要说明，本实施例以基于源MAC地址、目的MAC地址进行转发的二层网络为例。在基于源MAC地址、目的MAC地址进行转发的网络中，所有流表项都会同时匹配源MAC地址、目的MAC地址。
网络必须基于源MAC地址和目的MAC地址转发的原因在于：在这样的网络中，被错误转发的网络流在偏离原转发路径一定会找不到与它相匹配的流表项，进而一定会触发Packet-In。被错误转发的网络流在偏离原转发路径后一定找不到与它相匹配的流表项的原因在于：
控制器为这条网络流下发的所有流表项能够转发这条网络流，但是这些流表项仅位于这条控制器为这条网络流规定的转发路径上；
控制器为其他网络流下发的任何流表项都无法转发这条网络流，因为其他网络流要么源MAC地址与这条网络流的源MAC地址不同，要么目的MAC地址与这条网络流的目的MAC地址不同。(假设源MAC地址和目的MAC地址都相同，那么根据网络基于源MAC地址、目的MAC地址转发的假设，这两条网络流应该是同一条流)。
所以在基于源MAC地址、目的MAC地址转发的网络中，被错误转发的网络流在偏离控制器规定的转发路径后一定会触发Packet-In。一旦本技术方案提出的检测方案检测到这个Packet-In，它会根据上述基于Packet-In的转发异常检测机制来完成检测。即根据BPIS是否存在、BCFR是否存在、PIS是否存在、CFR是否存在来判断这个Packet-In是否由于网络流被错误转发是产生。
本实施例开销小，不用更改流表项；但它的适用范围窄，同时存在漏报的问题。
具体实施例二
本实施例解决在基于目的地址转发的网络中，如何修改流表项才能保证被错误转发的网络流一定会产生Packet-In。
比如在一个类似传统IP网络的基于目的地址转发的SDN网络中，如图4所示的网络和表1所示的流表项。网络中最初有两条网络流f1和f2。网络流f1从主机h1流到主机h3，依次经过交换机s1,s2和s4；网络流f2从主机h2流到主机h3，分别流经交换机s3和s4。在某个时间点，交换机s2发生配置错误，导致网络流f1被转发到2号端口。这个被错误转发的网络流接着流到交换机s3。但是在交换机s3上，它并不会触发任何Packet-In，因为原本为网络流f2准备的流表项恰好能够转发这个被错误转发的网络流。所以，实施例1尽管能够部分解决按照源MAC地址、目的MAC地址转发的二层网络中的转发异常问题，但是它并不具有通用性。
表1.图5中的所有流表项
为了解决实施例1产生漏报的问题，本实施例研究如何设计流表项才能使本技术方案提出的转发错误检测方案适用于基于目的地址转发的网络中。
在为每一条网络流下发的每一条流表项中强制匹配这条网络流的入端口(ingress port)便能解决此问题在本实施例中强制每一条控制器下发的流表项使用入端口来匹配网络流。这样，这些流表项仅会匹配来自正确的上一跳交换机的网络流。在这种要求下，本申请提出的转发异常检测机制就能够适用于基于目的地址转发的网络，同时具有很低的漏报率和很高的精确度。
表2.图4所示拓扑中使用的流表项
比如在网络拓扑如图4流表项为表1所示的网络中，实施例1采用的方案并不能检测到转发异常。但是我们可以强制使每一个流表项匹配网络流的入端口，比如交换机s1上处理网络流f1的流表项应当匹配入端口in_port＝1。所以，在图4所示的网络拓扑及网络流f1、f2的场景下，利用本申请提出的技术方案，应当为这两条网络流生成的流表项如表2所示。对比表2和表1可以看出，在本技术方案中，所有流表项都必须使用入端口匹配字段，入端口字段所匹配的值等于这条流表项需要转发的网络流进入本交换机的端口号。在使用表2所示的流表项配置图4所示的交换机后，被错误转发的网络流f1在交换机s3上就无法找到匹配的流表项，因为交换机s3上处理目的IP地址为10.0.0.3的流表项仅处理从2号端口进入交换机的数据包，而被错误转发的网络流从4号端口进入这个交换机。所以在这个交换机上，被错误转发的网络流f1会触发Packet-In。
接下来本申请以形式化方式说明技术方案的有效性。如图5所示，假设有一个网络流f1依次流经两个交换机s1和s2，在这两个交换机上它依次被流表项r11和流表项r21转发。match11和match21分别是流表项r11和流表项r21的匹配字段。假设网络流f1在交换机s1上遇到转发异常，它的输出端口改变，现在将这个网络流输出到交换机s3。假设这个流在被错误转发之后并没有触发Packet-In，那么在交换机s3上，必有流表项能够匹配这条网络流或者它的一部分。假设匹配这个网络流的流表项是r31，它的匹配字段为match31，同时根据本申请技术方案的限制，r31应当仅处理从1号端口进入网络的数据包。这说明交换机s1上本身有一条流转发到交换机s3，这条流在交换机s3上被流表项r31处理，假定这条流在交换机s1上被流表项r12转发。需要注意的是，流表项r12和r11不可能是同一条流表项，否则流表项r11同时将网络流输出到交换机s2和s3(SDN中利用组表实现的组播)，那么这种情况下网络流被转发到交换机s3并不算转发异常。假设流表项r11和流表项r12可能输出的数据包集合分别为out11和out12。由于流表项r11输出的数据包能被流表项r21和流表项r31处理，流表项r21输出的数据包能被流表项r31处理，同时考虑到SDN中流表项不存在聚合问题。那么以下公式成立(其中φ代表空集)：
out11＝match21
out11∩match31≠φ
out12＝match31
根据这三个等式能够推断出out11∩out12≠φ。接下来，本申请根据流表项r11和r12是否修改数据包包头来讨论：
1)不修改包头：这种情况下，流表项能够匹配的数据包也就是它能够输出的数据包，也就是说match11＝out11，match12＝out12。那么match11∩match12≠φ。也就说，流表项r11和流表项r12能够匹配同一组数据包。由于本申请假定了一个没有流表聚合的SDN场景，那么这种情况不可能存在。
2)修改包头：也就是说，流表项r11和r12不能匹配同一组数据包。但是经过修改包头，这两条流表项的输出数据包集合存在交集。从网络流的角度来看，这两条流表项处理不同的网络流，但是它们通过修改网络流的数据包头，使得不同的网络流经过它们的处理后变成了同一条网络流，但是它们又将这同一条网络流转发到两个不同的交换机。这种应用场景在现实网络中非常罕见，甚至没有。
所以根据以上推导，在本申请的不存在地址聚合的前提下，如果一条被错误转发的网络流没有触发Packet-In，那么一定能够推导出网络存在地址聚合或者一种不存在的网络应用场景。所以，使用本申请的技术方案能够使网络中被错误转发的网络流一定会触发Packet-In。
以上内容是结合具体的/优选的实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，其还可以对这些已描述的实施例做出若干替代或变型，而这些替代或变型方式都应当视为属于本发明的保护范围。

Claims (7)

1.一种检测网络流转发异常的方法，所述网络流是在动态配置的软件定义网络中的网络流，其特征在于，包括以下两个方面：
A1:基于Packet-In来判断网络流是否被异常转发，用于根据Packet-In发现异常；
A2:一种流表项编辑机制，确保被异常转发的网络流一定会产生Packet-In。
2.根据权利要求1所述网络流转发异常检测方法，其特征在于：
A1中采用流表项查找引擎和验证逻辑来判断网络流是否被异常转发；控制器将收到的Packet-In发送给所述流表项查找引擎，所述流表项查找引擎查找这个产生这个Packet-In的交换机PIS和产生Packet-In的交换机的前一跳交换机BPIS；所述验证逻辑验证BPIS是否确实将网络流转发到PIS，以及PIS是否确实不存在能够处理这个流的流表项，进而判断网络流是否发生转发错误。
3.根据权利要求2所述网络流转发异常检测方法，其特征在于，所述表项查找引擎根据交换机上的流表项，为每一个交换机构建两棵前缀Trie树，所述前缀Trie树包括正向查找树和反向查找树，所述正向查找树和反向查找树用于根据一个数据包或者Packet-In快速获取所述PIS、BPIS以及它们上转发所述Packet-In对应的数据包的流表项，所述流表项查找引擎会随着所述流表项的下发或者修改而更新。
4.根据权利要求2所述网络流转发异常检测方法，其特征在于，所述验证逻辑包括：
如果所述BPIS不存在，即所述PIS的前一跳设备是主机，PIS上能够转发对应数据包的流表项CFR也不存在，则说明这个Packet-In是一条新流导致，是正常产生的；
如果BPIS不存在，但PIS上存在CFR，则说明CFR可能没有工作；假设控制器在一段时间内(τ)收到N个Packet-In；如果N的值很大，则说明CFR确实没有正常工作；否则只能发出警告，让管理员手动验证这类问题；
如果BPIS存在，但BCFR不存在，则说明这个Packet-In是被错误转发的网络流触发的；
如果BPIS存在，BCFR存在，但是这条流表项不将数据包转发到PIS，则说明这个Packet-In是被错误转发的网络流触发的；
如果BPIS存在，且BCFR存在，且将数据包转发到PIS，CFR也不存在；则说明这个Packet-In是正常的网络流产生的；
如果BPIS存在，BCFR存在，且将数据包转发到PIS，但PIS上存在CFR，则CFR可能没有工作；假设控制器在一段时间内(τ)收到N个Packet-In；如果N的值很大，则说明CFR确实没有正常工作；否则只能发出警告，让管理员手动验证这类问题。
5.根据权利要求1所述网络流转发异常检测方法，其特征在于，A2中，通过编辑控制层下发到数据层的流表项来确保被异常转发的网络流一定会产生Packet-In。
6.根据权利要求5所述网络流转发异常检测方法，其特征在于：在基于目的地址转发的网络中，控制器在它下发的流表项的匹配域中强制加入入端口域，入端口域字段所匹配的值等于所述流表项需要转发的网络流进入目的地址交换机的端口号，当所述入端口域字段与所述交换机端口号不一致时，在所述交换机上，被错误转发的网络流触发Packet-In。
7.根据权利要求5所述网络流转发异常检测方法，其特征在于：在基于源地址、目的地址转发的网络中，控制器不需要做任何其他额外操作。
CN201610689064.6A 2016-08-18 2016-08-18 一种网络流转发异常检测方法 Active CN106302021B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610689064.6A CN106302021B (zh) 2016-08-18 2016-08-18 一种网络流转发异常检测方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610689064.6A CN106302021B (zh) 2016-08-18 2016-08-18 一种网络流转发异常检测方法

Publications (2)

Publication Number Publication Date
CN106302021A true CN106302021A (zh) 2017-01-04
CN106302021B CN106302021B (zh) 2020-03-31

Family

ID=57660613

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610689064.6A Active CN106302021B (zh) 2016-08-18 2016-08-18 一种网络流转发异常检测方法

Country Status (1)

Country Link
CN (1) CN106302021B (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107241359A (zh) * 2017-08-03 2017-10-10 安捷光通科技成都有限公司 一种面向软件定义网络的轻量级网络流量异常检测方法
CN107682377A (zh) * 2017-11-22 2018-02-09 周燕红 一种在线流量异常检测方法及装置
CN109039914A (zh) * 2018-08-23 2018-12-18 迈普通信技术股份有限公司 报文处理方法、装置及电子设备
CN109274673A (zh) * 2018-09-26 2019-01-25 广东工业大学 一种网络流量异常检测和防御方法
CN111865814A (zh) * 2020-07-31 2020-10-30 浙江大学 一种软件定义网络中异常转发流量的自动化过滤方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1894696A (zh) * 2003-12-23 2007-01-10 英特尔公司 检测数据流中的模式的方法和装置
CN104734994A (zh) * 2015-04-13 2015-06-24 上海斐讯数据通信技术有限公司 一种基于sdn框架的流标签控制方法
CN105207950A (zh) * 2015-09-16 2015-12-30 中国科学院信息工程研究所 一种基于sdn技术的通信数据保护方法
CN105337857A (zh) * 2015-11-23 2016-02-17 北京邮电大学 一种基于软件定义网络的多路径传输方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1894696A (zh) * 2003-12-23 2007-01-10 英特尔公司 检测数据流中的模式的方法和装置
CN104734994A (zh) * 2015-04-13 2015-06-24 上海斐讯数据通信技术有限公司 一种基于sdn框架的流标签控制方法
CN105207950A (zh) * 2015-09-16 2015-12-30 中国科学院信息工程研究所 一种基于sdn技术的通信数据保护方法
CN105337857A (zh) * 2015-11-23 2016-02-17 北京邮电大学 一种基于软件定义网络的多路径传输方法

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107241359A (zh) * 2017-08-03 2017-10-10 安捷光通科技成都有限公司 一种面向软件定义网络的轻量级网络流量异常检测方法
CN107241359B (zh) * 2017-08-03 2020-03-17 安捷光通科技成都有限公司 一种面向软件定义网络的轻量级网络流量异常检测方法
CN107682377A (zh) * 2017-11-22 2018-02-09 周燕红 一种在线流量异常检测方法及装置
CN109039914A (zh) * 2018-08-23 2018-12-18 迈普通信技术股份有限公司 报文处理方法、装置及电子设备
CN109039914B (zh) * 2018-08-23 2020-11-27 迈普通信技术股份有限公司 报文处理方法、装置及电子设备
CN109274673A (zh) * 2018-09-26 2019-01-25 广东工业大学 一种网络流量异常检测和防御方法
CN109274673B (zh) * 2018-09-26 2021-02-12 广东工业大学 一种网络流量异常检测和防御方法
CN111865814A (zh) * 2020-07-31 2020-10-30 浙江大学 一种软件定义网络中异常转发流量的自动化过滤方法
CN111865814B (zh) * 2020-07-31 2022-04-29 浙江大学 一种软件定义网络中异常转发流量的自动化过滤方法

Also Published As

Publication number Publication date
CN106302021B (zh) 2020-03-31

Similar Documents

Publication Publication Date Title
CN106302021A (zh) 一种网络流转发异常检测方法
US9929924B2 (en) SDN controller logic-inference network troubleshooter (SDN-LINT) tool
Zhang et al. Mind the gap: Monitoring the control-data plane consistency in software defined networks
US9577905B2 (en) Packet tracing through control and data plane operations
US10862749B1 (en) Systems for and methods of network management and verification using intent inference
CN103004158B (zh) 具有可编程内核的网络设备
US9306819B2 (en) Controller driven OAM for split architecture network
US10560354B2 (en) End-to-end, in situ packet enrichment for network analytics
US8964569B2 (en) Generic monitoring packet handling mechanism for OpenFlow 1.1
Skowyra et al. Verifiably-safe software-defined networks for CPS
CN106605392A (zh) 用于使用控制器在网络上进行操作的系统和方法
CN104509032B (zh) 用于在网络中操作、监管、以及管理(oam)功能的方法、装置和系统
Majumdar et al. Kuai: A model checker for software-defined networks
US9014013B2 (en) Packet tracing through control and data plane operations using SNMP trap commands
US10778545B2 (en) Network verification system
JP2019536331A (ja) 対話型ネットワーク分析プラットフォームのためのシステムおよび方法
CN102868553B (zh) 故障定位方法及相关设备
US9544194B2 (en) Network management service system, control apparatus, method, and program
CN104012052A (zh) 用于软件定义网络中的流管理的系统和方法
CN107113191A (zh) 数据中心结构网络中的内联数据包追踪
CN109547288B (zh) 一种协议无关转发网络可编程流测量方法
Liang et al. On diagnosis of forwarding plane via static forwarding rules in software defined networks
JP6194953B2 (ja) 情報処理装置、構築方法、通信システム及びプログラム
Kozat et al. On optimal topology verification and failure localization for software defined networks
JP6299754B2 (ja) 制御装置、制御方法、通信システム及びプログラム

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant