【《IP-SDN混合网络路由管理系统设计与实现案例分析》9700字】

IP-SDN混合网络路由管理系统设计与实现案例分析目录TOC\o"1-2"\h\u5863IP-SDN混合网络路由管理系统设计与实现案例分析 1154321.1系统总体设计 1109031.2系统整体框架 384591.3系统模块实现 5本章首先介绍了IP-SDN混合网络路由管理系统的开发环境，而后给出系统的总体架构（包括静态路由管理模块等五大模块）。接下来，本章说明了IP-SDN混合网络路由管理系统的整个处理流程，以及作为系统核心的OpenFlow协议与传统设备配置命令之间的转换关系。本章最后给出了系统实现的具体细节。1.1系统总体设计本研究设计的IP-SDN混合网络路由管理系统在Ubuntu18.4环境下，系统的整体框架使用了PyCharmIDE/pycharm/进行编写，网络拓扑发现图使用Gephi工具/gephi/gephi/，SDN控制器使用Ryu，动态路由引擎使用RouteFlow方案，传统网络设备使用CiscoWS-C3560-48TS（固件版本号C3560-IPSERVICESK9-M,Version12.2(55)SE12）和华为eNSP网络模拟软件，OpenFlow网络使用Mininet模拟，OpenFlow协议使用1.0版。/pycharm//gephi/gephi/其中，动态路由处理部分使用RouteFlow路由引擎框架，RouteFlow框架将动态路由协议引入OpenFlow网络，使OpenFlow设备具有同传统设备一样处理动态路由协议的能力，使得传统设备可以毫无感知地与OpenFlow设备进行动态路由交换，实现动态路由转发。RouteFlow框架实现原理是将动态路由协议生成的路由表，转换成OpenFlow协议流表，进而下发到OpenFlow设备实现路由转发，RouteFlow框架路由引擎控制层面则使用了基于Linux网络虚拟化以及LXC容器技术。RouterFlow框架的实现已有专门论述，本论文引用这一路由引擎框架，目的是对IP-SDN混合网络管理系统功能进行增强与完善，同时借鉴RouteFlow框架思想，研究基于OSPF协议的实时网络拓扑发现技术。本研究设计的IP-SDN混合网络路由管理系统总体方案如图X所示。整体系统包括五个组成部分，即静态路由管理模块、静态路由处理模块、动态路由处理模块、拓扑生成模块、OpenFlow协议代理模块。各个模块的主要功能为：静态路由管理模块：下发静态路由信息，获取设备流表。静态路由处理模块：处理网络基础协议和静态路由信息，生成OpenFlow静态路由流表。动态路由处理模块：使用RouteFlow动态路由引擎，处理OSPF动态路由协议，生成OpenFlow动态路由流表，旁路OSPF协议报文。拓扑生成模块：分析OSFP协议报文，构建实时网络拓扑图。OpenFlow协议代理模块：代理OpenFlow协议报文，处理OpenFlow协议与传统设备控制命令之间的转换。图SEQ图\*ARABIC8IP-SDN混合网络管理系统功能架构图如图14所示，IP-SDN混合网络管理系统可以划分为三层功能架构，分别是：应用层，负责接受用户对静态路由的控制，OSPF网络实时拓扑显示，包括静态路由管理模块、拓扑生成模块控制层，实现SDN控制器集中控制，负责静态路由与动态路由功能、流表信息下发与拓扑生成，包括静态路由处理模块、动态路由处理模块、拓扑生成模块代理层，负责OpenFlow协议代理与转换工作，包括OpenFlow协议代理模块IP-SDN混合网络管理系统初始化阶段，通过静态路由处理模块处理本地接口地址信息，建立本地路由表，生成默认流表项以满足非路由数据包基本转发要求。而后，静态路由与动态路由处理模块开始各自处理路由信息，静态路由处理模块通过静态路由管理模块接收静态路由设置，判断路由信息有效性，添加至本地路由表，生成对应的路由转发流表项；动态路由处理模块接收OSPF协议握手报文，通过路由引擎进行路由计算，生成动态路由表，生成对应路由转发流表项。之后流表项通过OpenFlow协议代理模块对流表项内容进行分析转换，发送至对应网络设备。通过三者的结合，IP-SDN混合网络管理系统可以无差别的管理传统网络设备和OpenFlow网络设备，并且对于组网方式没有要求。1.2系统整体框架1.1.1系统框架设计图15给出了IP-SDN混合网络管理系统总体架构，并对各部分模块内部进行功能划分，指出系统内部主要数据交互过程。图SEQ图\*ARABIC9IP-SDN混合网络管理系统总体架构图下一节内容将对这些模块做出进一步的解释。1.1.2系统模块设计本节具体描述各模块功能划分及作用。（1）静态路由管理模块静态路由管理模块是系统的应用级模块，通过提供RESTAPI接口，实现路由管理，流表显示等功能。（2）静态路由处理模块静态路由处理模块包括，指令接收处理：执行路由管理指令；ICMP代理：处理目的地址是本地接口地址的非路由ICMP协议以及其它IP协议数据包，发送ICMP回复报文，丢弃其它IP协议数据包；ARP协议代理：处理ARP协议，发送ARP请求、回复等报文；流表项生成：根据协议处理结果和静态路由信息，生成本地路由表并生成对应流表项下发。（3）动态路由处理模块动态路由处理模块包括，RouteFlow路由引擎：基于Quagga的OpenFlow路由实现方案，提供了基于OSPF协议的动态路由支持；路由协议报文旁路：对OSFP协议LSU报文进行拦截、复制、旁路，上送拓扑生成模块处理。（4）拓扑生成模块拓扑生成模块包括，路由协议报文分析：分析OSPF协议LSU报文，提取并构建链路状态数据库；GephiRESTAPI调用：调用Gephi软件的RESTAPI接口，绘制网络拓扑图。（5）OpenFlow协议代理模块OpenFlow协议代理模块包括，控制器通信通道：模拟OpenFlow协议与控制器通信规范，提取OpenFlow协议消息内容；传统设备控制通道：通过Telnet方式登陆设备，发送配置命令；OpenFlow协议流表项处理：分析OpenFlow协议流表项内容，执行传统设备配置命令转换；OpenFlow协议消息处理：负责处理与路由机制相关的OpenFlow消息，包括PacketIN与PacketOUT等；Trunk接口数据包处理：负责VLAN接口号与OpenFlow虚拟设备接口号的转换，对数据包实施VLANtag打标签或去标签服务。1.3系统模块实现本节依据系统总体设计与整体框架结构，对系统各功能模块以及子模块实现进行阐述。1.3.1静态路由处理模块静态处理模块主要由ARP代理模块、ICMP代理模块、RESTAPI模块以及流表项生成模块组成，我们将以图16所示拓扑结构对静态路由处理模块的流程与实现进行阐述。图SEQ图\*ARABIC10静态路由处理场景图模块工作流程主要可以分为初始化阶段、本地通信处理阶段和路由转发阶段，下面对这三个阶段处理流程进行详细描述。（1）初始化阶段初始化阶段，模块会向3台OpenFlow设备下发基础路由表，包括将ARP协议报文上送控制器，对其它数据包进行丢弃动作等默认流表项，对于ARP协议报文的上送是进行后续路由转发的基础。这个阶段还没有为设备配置接口IP地址信息，暂时不能对上送的ARP协议报文进行处理。静态路由管理模块通过RESTAPI发送接口地址设置指令，分别为3台OpenFlow设备指定虚拟接口IP地址，由于设备本身没有处理IP数据包的能力，需要将目的地址为设备本身的数据包交由控制器处理，对于与接口地址相同网段内主机间通信，如H1与H4之间的通信，根据第二章中有关论述，将交由设备进行二层处理，流表项生成子模块会根据接口地址信息，下发对应的流表项。以S1设备为例，对应虚拟接口IP地址的流表项与设备默认流表项如表6所示。表SEQ表\*ARABIC2S1基础路由表项表dpidMatch域Actionethtypenw_srcnw_dst10x0800*/32ToController10x0800*/32ToController10x0800/24/24NORMAL10x0800/24/24NORMAL10x0806**ToController1***DROP（2）本地通信阶段此时对于目的地址是本地地址的数据报文，OpenFlow设备可依据初始流表项进行处理，以H1向其网关发送ICMP报文为例，H1首先发送ARP请求报文询问网关的MAC地址，S1根据初始流表项将ARP报文送控制器，ARP代理子模块对报文进行解析，将源报文链路层中的源MAC地址11:11:11:11:11:12，替换回复报文的目的MAC地址，将接口MAC地址01:01:01:01:01:02，替换回复报文的源MAC地址，构建内容为接口MAC地址的回复报文，进行单播发送。这里设备S1有两个接口，如何确定回复报文中使用的MAC地址，运用了第二章提到的关于通过PacketIN消息改进虚拟接口IP地址与物理接口号的方法，H1发送的ARP报文通过PacketIN上送到控制器后，ARP代理子模块利用控制器提供的函数，获取到ARP报文的入接口号，进而建立虚拟接口与物理接口的绑定关系。至此，ARP代理子模块获取了H1主机的地址信息，H1主机同时具有设备虚拟接口的地址信息，H1主机与网关地址之间可以正常通信。结合路由转发机制，网关进行路由转发的底层操作是MAC地址的逐跳转换，作为网关的S1设备，已经获取其接口下的主机H1的地址信息，便可通过MAC地址转换来实现到H1主机的路由转发机制。因此，ARP处理子模块不仅处理了正常ARP请求过程，还获取了接口连接主机的可达信息，通过下发流表项指导S1对目的地址是H1的主机进行路由转发。由此可知，同接口同网段内的主机，只要发送ARP请求，就会被ARP代理模块捕获，从而下发对应的路由转发流表项。H1获取到网关的MAC地址以后，发送目的地址是的ICMP报文，S1根据流表匹配第1条，通过PacketIN上送到控制器，ICMP处理子模块构建ICMP报文，将ICMP报文从入接口发送出去，完成了本次ICMP通信。同一网段下两主机通信的情况，与上述情况类似，区别在于需要ARP代理子模块将ARP报文进行一次转发。H1发送ARP请求同一网段H4主机MAC地址，ARP代理子模块判断是同一网段内两主机通信，将ARP报文通过PacketOUT消息转发，H4主机回复ARP报文，ARP代理子模块获取到H4主机的地址信息，后续步骤与上述一致。此后主机间通信通过OpenFlow设备的Normal动作进行转发以图X所示拓扑结构为例，设备S1的本地路由流表项如表7所示。表SEQ表\*ARABIC3S1本地路由表项表dpidMatch域Actionethtypenw_dst10x0800/32TTL--SetSrc_MAC：01:01:01:01:01:01SetDst_MAC：11:11:11:11:11:12Ouput：110x0800/32TTL--SetSrc_MAC：01:01:01:01:01:01SetDst_MAC：11:11:11:11:11:13Ouput：1（3）路由转发阶段指令接收处理模块接收路由添加指令，首先对添加的路由信息进行有效性判断，包括路由信息的下一跳地址是否与设备虚拟接口属于同一网段，以及下一跳地址是否与虚拟接口地址重复等。路由有效性验证成功后，指令接收处理模块将路由信息添加路由表，此时路由表中的路由信息缺少下一跳的MAC地址。根据路由转发机制，此路由信息可以被正常转发的前提是对下一跳MAC地址的学习，因此指令接收处理模块将构建ARP请求，从设备所有接口发送ARP查询下一跳MAC地址。ARP请求的处理将回归ARP代理子模块完成，下一跳设备虚拟接口回复ARP请求，将获取的MAC地址更新到路由表中下一跳的MAC地址。使用完整的路由信息，ARP代理子模块便可生成静态路由转发流表。这里存在另一种情景，即下一跳地址不存在，无法回复ARP请求。虽然无法获取下一跳的MAC地址，但是路由设置是合理的，路由表中应当保存此路由条目。对于没有下一跳MAC地址的路由，指令接收处理子模块会将此路由转换成PacketIN形式的流表项，对于发往此路由的数据包，由PacketIN处理子模块做出判定，触发ARP代理子模块对于路由下一跳MAC地址的ARP查询，直到下一跳地址可达并回复ARP请求，由ARP代理子模块依照上述正常流程下发更新的路由流表项，覆盖此PacketIN流表项。下面通过实例进行阐述。对于设备S1，设置两条路由信息分别为：目的地址/24，下一跳为；目的地址/24，下一跳地址为00（此地址不存在）；对于设备S2，设置一条路由信息为：目的地址/24，下一跳为。S1验证两条路由有效性，并添加路由表，由于第2条路由下一跳地址不存在，将产生不同的路由流表项。S2执行同样流程。具体流表项内容如表X所示。表SEQ表\*ARABIC4S1转发路由表项表dpidMatch域Actionethtypenw_dst10x0800/32TTL--SetSrc_MAC：01:01:01:01:01:02SetDst_MAC：03:03:03:03:03:02Ouput：210x0800/24同上10x0800/24ToController20x0800/32TTL--SetSrc_MAC：03:03:03:03:03:02SetDst_MAC：02:02:02:02:02:02Ouput：320x0800/24同上综上所述，静态路由处理模块整体工作流程如图17所示。图SEQ图\*ARABIC11静态路由处理模块整体工作流程图其中指令接收处理子模块流程和ARP代理子模块流程分别如图18和图19所示。图SEQ图\*ARABIC12指令处理接收模块工作流程图图SEQ图\*ARABIC13ARP代理模块工作流程图静态路由处理模块围绕路由机制中MAC地址转换核心思想，通过将路由流程分为三个阶段进行功能构建，各子模块之间相互关联，实现路由转发功能。1.3.2OpenFlow协议代理模块OpenFlow协议代理模块是IP-SDN混合网络管理系统中连接底层物理设备的核心组件，负责维护传统设备与OpenFlow设备的控制通道、与控制器的通信通道，将OpenFlow协议消息与路由流表项内容转换成传统设备配置命令以及对Trunk接口数据包进行封装与解封装等工作。本小节将对模块具体实现进行详细阐述。1.控制器通信通道子模块为了实现与SDN控制器的通信，代理模块首先需要模拟自身为一个支持OpenFlow协议的网络设备。根据OpenFlow协议规范描述，OpenFlow交换机和控制器的通信过程使用TCP或者TLS进行，端口号默认为6633。连接建立后OpenFlow设备发送Hello消息协商OpenFlow协议版本，之后控制器向OpenFlow设备发送FeaturesRequest消息，获取交换机的ID、缓冲区数量、端口信息等特性，OpenFlow设备回复FeaturesReply，至此双方握手完成。控制器通信通道子模块的实现采用了sdnpwn2开源项目中对于OpenFlow设备的模拟方法。该项目是模拟对SDN控制器的攻击以测试控制器的安全性，其内部实现了简单OpenFlow设备，可以通过该设备对OpenFlow协议消息与流表项进行捕获，满足OpenFlow协议代理模块要求。具体实现过程如下所述。（1）使用配置文件配置OpenFlow虚拟设备的基本物理信息，包括设备型号、设备描述、特性以及接口等信息，用于响应控制器与OpenFlow虚拟设备的握手请求。（2）通过使用socket类，建立代理程序到控制器的TCP连接，实现OpenFlow协议消息在控制器与代理程序之间的收发。（3）建立对应的OpenFlow协议消息处理函数，并将函数映射到对应的OpenFlow协议消息代码。由于OpenFlow协议消息具有固定8字节长的报文头，因此，通过socket.recv获取数据包的前8个字节长度，即可取得OpenFlow协议的报文头，通过对报文类型字段的解析，得到具体的OpenFlow协议消息类型，将消息分发到对应的处理函数进行处理。（4）完成控制器与虚拟OpenFlow设备的握手过程，分发后续OpenFlow消息到对应处理函数。2.OpenFlow流表项处理子模块OpenFlow流表项处理子模块主要负责处理控制器流表项下发消息，包括流表项的添加与删除消息（FlowMod），以及流表信息的查询与上报（StatsRequest/StatsResponse）。同时依据流表项匹配域内容，负责传统设备配置命令的生成。（1）流表项处理OpenFlow流表项处理子模块通过使用字典来保存控制器下发的流表项，字典键值使用流表项cookie字段，cookie字段相同的路由流表项，表示关联的是同一虚拟接口地址，通过cookie字段，建立起流表项有效性与接口有效的联系。流表信息上报实现，需要对StatsResponse消息构建，使用的是开源项目pyof，它是Kytos项目中关于OpenFlow协议的实现库。构建过程通过将字典中保存的流表项内容，转换成StatsResponse消息格式。由于字典中的流表项内容，是由FlowMod消息下发的，通过对比两种消息格式，重新计算StatsResponse消息长度，填充字段内容，使用pyof提供的StatsReply类构建StatsResponse消息。（2）传统设备配置命令生成根据OpenFlow路由机制流程，初始流表项和本地流表项仅和本地接口与网段有关，无需进行路由转发。由于传统网络设备自身具有基础网络处理能力，因此，对于本地相关的流表项，无需生成传统设备配置命令，传统设备会自行对本地相关的数据包进行本地转发处理。传统设备命令生成主要针对路由转发流表项进行，首先对路由转发流表项进行判定。路由转发流表项匹配域中的目的IP地址，必然是不同于网络设备本地接口网段的外部地址，因此，通过对流表项匹配域目的IP地址范围的判断，可以获取路由目的地址。路由信息下一跳的获取，可以通过两种方法：一是如果流表项的动作字段，存在出接口号，则可根据出接口获取下一跳地址；二是通过流表项动作字段中对目的MAC地址的改写，可以获得下一跳接口的MAC地址，根据此地址信息获取下一跳接口的IP地址。通过上述路由信息的获取，便可以生成传统设备的策略路由配置命令。依据路由信息目的网段，生成传统设备的ACL配置命令；依据下一跳地址，生成传统设备的RouteMap配置命令；根据下一跳地址所属网段，得知设备的接口号，进而生成基于PBR的策略路由配置命令。具体实现流程如图20所示。图SEQ图\*ARABIC14传统设备配置命令生成流程图3.OpenFlow协议消息处理子模块OpenFlow协议消息处理子模块主要负责处理与路由机制相关的OpenFlow消息，包括PacketIN与PacketOUT等。对于静态路由应用场景，PacketIN消息主要用于发送邻接网络设备对本地接口的ARP请求；PacketOUT消息主要用于发送对路由信息下一跳MAC地址的ARP请求，以及对邻接网络设备的ARP回复。对于动态路由应用场景，除了与静态路由应用场景相同的情况外，PacketIN消息还负责发送邻接网络设备动态路由协议数据报文，PacketOUT消息还负责发送本地动态路由协议数据报文。PacketIN与PacketOUT消息的构建，同样使用pyof库，通过将需要上送的数据包序列化为网络字节序，并将其完整装入PacketIN实例的data属性，指定入接口号，通过控制器通信通道进行发送；对PacketOUT实例调用unpack方法，得到实例的data属性和outport属性，进而获取需要发送的数据包和出接口信息。1.Trunk接口数据包处理子模块Trunk接口数据包处理子模块主要负责VLAN接口号与OpenFlow虚拟设备接口号的转换，负责对通过Trunk接口的数据包进行分类过滤，对需要进行处理的数据包实施VLANtag打标签或去标签服务。对于数据包的处理，使用的是开源Scapy项目，该项目提供了大量不同类型数据包的类库，提供了构建任意数据包的方法，以及通过网络接口直接发送数据包的能力，同时该项目还支持对网络接口进行异步监听，并支持回调函数对监听到的数据包进行处理。（1）数据包过滤传统网络设备设置与虚拟OpenFlow设备相同的接口配置。由于传统设备1号VLAN通常具有特殊的作用，因此，我们将虚拟设备的接口号增加10后，与传统设备的VLAN号对应。每个VLAN绑定一个物理接口，实现了虚拟接口与物理接口的对应。子模块与传统网络设备的Trunk接口直接相连，能够接收到所有来自传统设备通过Trunk接口转发的数据包，其中包括传统设备自身产生的数据包。根据路由机制与路由场景的描述，在实际路由转发过程中发挥作用的数据包，主要包括ARP协议报文以及动态路由协议交互报文。子模块使用Scapy项目中的AsyncSniffer方法创建对Trunk接口的异步监听，使用Scapy中的Ether类、ARP类以及路由协议相关报文类（如OspfHdr类）来对Trunk接口报文进行过滤；使用Dot1Q类获取数据包所属的VLAN号，并与虚拟设备的接口号对应，同时对数据包VLANTag进行处理。（2）VLAN标签处理对Trunk接口数据包去标签的过程主要包括：1）遍历数据包中包含的各层协议头部数据；2）判断协议头部数据是否存在校验字段，并对检验字段进行删除；3）判断当前协议层是否是Ether，是否存在Dot1Q协议层，并提取其后续数据包载荷；4）从当前协议层删除所有数据载荷（包括Dot1Q协议层），将保存的数据包载荷添加到当前协议层；5）更改数据包类型（将0x8100改为0x0800或0x0806等）；6）重复步骤1）对数据包载荷各层协议遍历，直至数据包结尾。具体流程如图X所示。图SEQ图\*ARABIC15Trunk接口数据包去VLANTag流程图对Trunk接口数据包打标签的过程，有两种方法，第一种方法与上述去标签过程基本一致，需将删除Dot1Q协议层改为添加Dot1Q协议层；第二种方法是使用Linux系统提供的8021q模块，该模块为网络接口提供支持VLAN子网的能力。具体配置如下：1）sudomodprobe8021q2）sudoiplinkaddlinkens39nameens39.11typevlan113）sudoiplinksetdevens39.11up其中第1条配置命令表示加载8021q模块，以实现Linux系统支持VLAN子网；第2条配置命令为物理网络接口ens39，创建一个VLAN号为11的子接口，名字为ens39.11，该子接口将仅收发父接口ens39中VLANtag为11的数据包，并自动对数据包进行打标签与去标签处理；第3条配置命令表示将子接口使能。我们可以使用Scapy项目sendp方法向VLAN子接口直接发送数据包，而不用关心打标签的问题，打标签的过程由Linux系统自行完成。虽然此方法同样可以用于对数据包进行去标签操作，但是，如果使用此方法进行去标签，需要Scapy对所有VLAN子接口进行监听，如果子接口数量较大，监听过程将占用大量系统资源，大大降低监听效率。Trunk接口数据包处理子模块功能包括Trunk数据包过滤与VLAN标签的处理，具体实现如图X所示。图SEQ图\*ARABIC16Trunk接口数据包处理子模块工作示意图5.传统设备控制通道传统设备控制通道负责建立与传统设备的连接，下发配置命令。具体实现使用Python的telnetlib模块，建立到传统设备的telnet命令。由于与传统设备建立telnet远程连接，是基于交互模式，因此，需要对传统设备的回显内容进行判断，满足条件才能进行命令输入。传统设备的交互模式都有固定的回显格式，我们通过使用正则表达式进行匹配，以Cisco传统设备为例，需要判断的内容如表X所示。表SEQ表\*ARABIC5传统设备配置状态处理对照表传统设备回显状态正则表达式可进行操作登陆用户名输入username:输入用户名登陆密码输入password:输入密码视图模式\w+>$视图命令特权模式\w+#$全部命令配置模式\)#$配置命令1.3.3拓扑生成模块拓扑生成模块负责通过OSPF动态路由协议报文交互信息，生成实时拓扑。其主要作用是为路由管理系统提供可视化网络结构，方便查找网络路由故障。该模块由路由协议报文分析组件与GephiRESTAPI调用组件组成。1.路由协议报文分析组件路由协议报文组件主要负责网络拓扑生成，其实现原理依托SDN控制器网络全局控制能力，通过对RouteFlow路由框架quagga路由引擎中，OSPF协议交互报文的实时截取，分析处理OSPF协议交互消息，进而得出网络拓扑结构。对于OSPF协议报文的截取，使用的是RouteFlow路由框架中的POX控制器的事件机制。POX是一个由Python编写的控制器，仅支持OpenFlow1.0。POX的事件机制处理符合发布/订阅模式（publish/subscribe），主要原理是使用revent类，当某个对象发布事件时，其他的对象可以在这个对象上订阅指定的事件。POX控制器会发布PacketIN事件，当POX收到OpenFlow设备通过PacketIN消息上送的OSFP协议报文时，会触发PacketIN事件。POX控制器中应用程序以组件的方式运行，我们需要将拓扑发现模块编写成Python类的形式，然后向POX的core进行注册，使用core.registerNew方法。同时，拓扑发现模块订阅POX的PacketIN事件，以便旁路接收OSPF协议报文。2.GephiRESTAPI调用组件GephiRESTAPI调用组件主要负责网络实时拓扑的绘制，使用的是Gephi开源软件，该软件提供了基于RESTAPI的画图接口。为了达到拓扑实时性，需要对每次OSPF协议交互数据进行分析，发现拓扑变化情况，并实时调用GephiAPI对网络拓扑进行重新绘制。因此，路由协议报文分析组件使用POX的事件机制，通过revent.Event类，自定义了拓扑变化事件，并将事件进行发布；GephiRESTAPI调用组件订阅该事件，连接GephiRESTAPI用来进行拓扑绘制，确保了一旦拓扑发生变化，Gephi就重新绘制网络拓扑。OSPF协议的交互过程由RouteFlow路由框架中Quagga引擎处理，包括OSPF协议的握手过程等，我们只关心OSPF协议成功建立邻接关系以后的消息交换，即LSA消息的交互，因为这些消息包含了网络设备节点与节点链路的信息。OSPF包括了5种常用类型的LSA，通过分析可知，RouterLSA（类型1）与NetworkLSA（类型2）中分别包含网络设备信息、设备接口信息与接口连接信息。因此，在拓扑生成的实现过程中，我们对PacketIN上送的OSPF协议报文进行了筛选，只需要分析RouterLSA和NetworkLSA即可。我们通过研究OSPF协议规范，总结出OSPF协议LSA交互过程中的几点约定：（1）只有始发这条LSA的路由器有权利提前发送LSAAGE=3600的LSA过期消息，从而使其它路由器删除这条LSA。例如一个DR突然离线，则其它路由器收不到任何这个DR发送的数据包，超时重新选举DR，后原DR上线，可能是DRother，或又被重选为DR，这时其它路由器会把当时DR的netlsa通过DD报文发送给它，由于是遗留LSA，DR会主动发一个Age3600让其它路由器删除。（2）所有重启后的路由器都会通过DD报文来向邻居获取自己以前的序列号，并加1发送新的LSA。如果路由器收到了一个比自己的LSDB里存储的LSA小的序列号，证明邻居发送的是错误LSA（可能是邻居问题或网络问题），则断开与它的邻接关系或者拒绝与它建立邻接。（3）当一个LSDB中LSAAGE=3600时，所有路由器会在一个时间段随机发送过期这条LSA，只要有一个路由器发送，其它路由器收到后就不用再发，减少洪泛。这几条约定是拓扑实现正确性的依据。结合对OSPF协议的分析，我们得出网络拓扑生成模块的主要流程，分别如图21与图22所示。图SEQ图\*ARABIC17OSPF路由器LSA处理流程图图SEQ图\*ARABIC18OSPF网络LSA处理流程图1.3.4静态路由管理模块静态路由管理模块负责系统静态路由的添加以及删除等工作。实现原理为，通过使用PythonWSGI（WebServerGatewayInterface，网页服务器网关接口）规范，建立WSGI服务器与应用程序，将静态路由管理指令内容，映射到RESTAPI中，再将RESTAPI映射到目标处理函数。其中服务器负责接收RESTAPI形式的指令内容，应用程