CN108390821A - 一种openflow交换机实现双活的方法及系统 - Google Patents

一种openflow交换机实现双活的方法及系统 Download PDF

Info

Publication number
CN108390821A
CN108390821A CN201810164303.5A CN201810164303A CN108390821A CN 108390821 A CN108390821 A CN 108390821A CN 201810164303 A CN201810164303 A CN 201810164303A CN 108390821 A CN108390821 A CN 108390821A
Authority
CN
China
Prior art keywords
host
controller
interchanger
flow table
mac address
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
CN201810164303.5A
Other languages
English (en)
Other versions
CN108390821B (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.)
Suzhou Centec Communications Co Ltd
Original Assignee
Centec Networks Suzhou Co Ltd
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 Centec Networks Suzhou Co Ltd filed Critical Centec Networks Suzhou Co Ltd
Priority to CN201810164303.5A priority Critical patent/CN108390821B/zh
Publication of CN108390821A publication Critical patent/CN108390821A/zh
Application granted granted Critical
Publication of CN108390821B publication Critical patent/CN108390821B/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
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H04L45/245—Link aggregation, e.g. trunking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types
    • H04L61/103—Mapping addresses of different types across network layers, e.g. resolution of network layer into physical layer addresses or address resolution protocol [ARP]

Landscapes

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

Abstract

本发明揭示了一种openflow交换机实现双活的方法，包括：控制器记录同网段的N个主机分别和至少两个交换机的端口连接信息到一连接信息表内，并在每个交换机上下发N个组表；主机之间进行ARP交互，控制器从所述ARP报文中获得各主机的MAC地址，并更新所述MAC地址到连接信息表内，同时控制器在每个交换机上下发2N条用于匹配发往各主机的报文的流表；主机之间通信时，交换机接收从源主机上发来的报文，并匹配下发的所述流表，根据流表配置的行为执行，将报文转发到目的主机上。本发明利用OpenFlow Spec定义的统一标准的组表和流表，实现同网段主机间双活通信，有效利用带宽，并具备交换机级别和链路级别的失效保护。

Description

一种openflow交换机实现双活的方法及系统
技术领域
本发明涉及一种主机间实现双活通信的技术，尤其是涉及一种openflow交换机实现双活的方法。
背景技术
传统链路聚合(Link Aggregate)的所有成员端口(member port)只能是在一台设备上。MLAG(Multichassis Link Aggregation Group，跨设备链路聚合)将这个限制去掉，可以实现跨交换机的Lag(Link Aggregation Group，链路聚合)功能。
如图1所示，两台交换机之间通过Peer-link(对等链接)建立TCP(TransmissionControl Protocol，传输控制协议)连接，交换MLAG的信息和同步FDB(ForwardingDataBase，MAC地址转发表)信息。
当报文因为故障无法在当前交换机进行转发的话(如MLAG组的member portdown)，数据会通过Peer-Link发给Peer-Switch(对端交换机)，由Peer-Switch来发给MLAG组的另外一个member port。也就是说，如果有一台交换机宕机，依然可以依靠另外一台交换机进行转发。
但是现有MLAG网络协议都是私有的，无法和其它厂商互联互通。
也就是说，现有同网段主机间如果需要实现双活通信的话，交换机设备必须支持类似MLAG这样的双活特性，但是不同厂商的MALG实现和通信协议都是私有的，难以互联互通，且传统网络难以实现统一控制，不方便编程控制。
因此，需要研究一种实现了同网段多主机双活网络通信的技术，以避免现有依赖复杂的MLAG协议来实现。
发明内容
本发明的目的在于克服现有技术的缺陷，提供一种使用OpenFlow技术中规定的流表和组表，实现同网段多主机之间的双活通信的openflow交换机实现双活的方法。
为实现上述目的，本发明提出如下技术方案：一种openflow交换机实现双活的方法，包括：
S1，控制器记录同网段的N个主机分别和至少两个交换机的端口连接信息到一连接信息表内，及根据所述连接信息表，在每个交换机上下发N个组表，一个组表对应一个主机，每个组表内配置其对应主机报文转发的主链路和备链路；
S2，主机之间进行ARP交互，控制器从所述ARP报文中获得各主机的MAC地址，并更新所述MAC地址到所述连接信息表内，且使主机之间学习到彼此的MAC地址，同时控制器在每个交换机上下发2N条用于匹配发往各主机的报文的流表，每个主机对应两条用于匹配发给其自身的报文的第一流表和第二流表；
S3，主机之间通信时，交换机接收从源主机上发来的报文，并匹配下发的所述第一流表或第二流表，根据所述第一流表或第二流表配置的行为执行，将报文转发到目的主机上。
优选地，S1中，首先，所述控制器与两个交换机之间分别建立OpenFlow Channel，不同的OpenFlow Channel由交换机不同的DPID进行区分；所述交换机之间通过Peer-link建立连接；且每台主机都和每台交换机相连。
优选地，所述发往备链路对应的组表内配置：发往备链路的报文，插入vlan_vid的VLAN标签，用于报文通过备链路发到对端交换机，对端交换机可根据所述vlan_vid识别出报文的源主机。
优选地，所述S2包括：
S21，源主机发出ARP Request报文来请求目的主机的MAC地址；
S22，所述ARP Request报文经任意一交换机，以packet-in报文形式上送给控制器；
S23，所述控制器收到所述packet-in报文，解析获得源主机的MAC地址，更新所述源主机的MAC地址到所述连接信息表内，同时，所述控制器在所述源主机上下发所述第一流表和第二流表，用于匹配发给所述源主机的IP报文；
S24，所述控制器将所述ARP Request报文以Packet out报文形式发送给每个交换机，经所述交换机发送给目的主机；
S25，所述目的主机收到所述ARPRequest报文，回复ARP Reply报文通告控制器自身的MAC地址；
S26，所述控制器收到所述ARP Reply报文，解析获得目的主机的MAC地址，更新所述目的主机的MAC地址到所述连接信息表内，同时，所述控制器在所述目的主机上下发所述第一流表和第二流表，用于匹配发给所述目的主机的IP报文；
S27，所述控制器向源主机发送所述ARP Reply报文，至此，所述主机之间学习到彼此的MAC地址。
优选地，S21中，所述ARP Request报文中配置包括：报文的源MAC地址、目的MAC地址和ARP负载信息，所述ARP负载信息中配置包括：源主机的MAC地址、源主机的IP地址，目的主机的MAC地址和目的主机的IP地址，其中，所述目的MAC地址配置为全F的广播地址，所述目的主机的MAC地址为全0的地址。
优选地，S2中，所述第一流表配置从所述备链路传过来的报文的转发路径，所述第二流表配置交换机上除备链路和主链路外的其他链路传过来的报文，发送给对应主机配置的所述组表，根据所述组表的配置处理报文。
优选地，所述第一流表的优先级高于所述第二流表的优先级。
优选地，所述S24中，所述控制器将所述ARP Request报文发送给每个交换机上除了主链路对应的端口和备链路对应的端口外的其他端口上。
优选地，所述S27中，所述控制器直接向源主机和目的主机各自主链路对应的端口发送所述ARP Reply报文。
优选地，所述主机之间通信时，若将源主机换成任意主机HostX，则所述主机HostX与网络中的其它主机通信时，所述控制器需更新所述连接信息表中主机HostX对应的MAC地址，及更新每个交换机上发给主机HostX的所述第二流表。
本发明的有益效果是：利用OpenFlow Spec定义的统一标准的组表和流表，实现同网段主机间双活通信，可有效利用带宽，并具备交换机级别和链路级别的失效保护，且支持主机更换后的组表更新。
附图说明
图1是现有MLAG实现双活网络通信的原理示意图；
图2是本发明openflow交换机实现双活的方法的流程示意图；
图3是本发明实施例openflow交换机实现双活的原理示意图；
图4是本发明步骤S2的流程示意图。
具体实施方式
下面将结合本发明的附图，对本发明实施例的技术方案进行清楚、完整的描述。
本发明所揭示的一种openflow交换机实现双活的方法，利用OpenFlow Spec定义的统一标准的组表和流表，实现同网段主机间双活通信，有效利用带宽，并具备交换机级别和链路级别的失效保护。另外，也可支持主机更换后的组表更新。
结合图2～图4所示，本发明实施例所揭示的一种openflow交换机实现双活的方法，包括以下步骤：
S1，控制器记录同网段的N个主机分别和至少两个交换机的端口连接信息到一连接信息表内，及根据所述连接信息表，在每个交换机上下发N个组表，一个组表对应一个主机，每个组表内配置其对应主机报文转发的主链路和备链路。
具体地，以N(1,2,3……N)台同网段主机之间通过两个交换机通信时为例，首先，控制器与两个交换机之间分别建立OpenFlow Channel(交换机跟控制器之间的连接通道)，不同的OpenFlow Channel由交换机不同的DPID进行区分，如控制器与交换机1、交换机2各建立一OpenFlow Channel，两个OpenFlow Channel由交换机1、交换机2的DPID进行区分。
交换机之间是通过Peer-link建立连接，Peer-link连接两个交换机的聚合端口，聚合端口是由多个物理端口绑定成的一个agg(aggregate port，聚合端口)，对控制器呈现是一个逻辑端口(port)，如交换机1具有一个逻辑端口1-G，交换机2具有一个逻辑端口2-G，交换机1和2之间通过Peer-link建立连接，Peer-link连接端口1-G和端口2-G。
每台主机都和每台交换机相连，为了简化和描述方便，接口顺序都是依次排列的。如这里有N个主机，则每台交换机上设置N个接口(接口1、接口2……接口N)，每个接口按序接一主机，如接口1接主机1，接口2接主机2，依此类推，当然，接口顺序不一定是依次排列的，与主机连接也不一定按接口顺序一一对应连接，只要能实现每台主机都与每台交换机相连即可。
另外，需要说明的是，主机的bond口(聚合端口，就是将几个物理端口聚合起来，逻辑上呈现成一个port)发出的报文，无论从哪条链路发出的报文，源MAC地址(souce mac)都是bond mac。
本发明要求控制器具有数据库记录/提取能力，可以保存主机和交换机之间的端口连接信息。本实施例中，控制器将N个主机(host)和两个交换机(switch)的端口连接信息，保存到一连接信息表内。在该连接信息表内初始状态下，每个主机的源MAC地址未知，后续可以通过ARP(Address Resolution Protocol，是根据IP地址获取物理地址的一个TCP/IP协议)报文来添加主机MAC地址(实际上是上述介绍的主机的bond mac)。
以三台同网段主机(host1、host2和host3)之间通过两台交换机(Switch-A和Switch-B)为例，如图3所示，控制器保存的连接信息表为：
根据上述连接信息表，可以扩展到控制器保存的N台同网段主机与M(即大于两台)台交换机之间端口连接信息的连接信息表。
基于上述连接信息表，控制器需要下发一些组表到各个交换机上，一个组表对应一个主机，每个组表内配置其对应主机报文转发的主链路和备链路。
具体地，以上述三台同网段主机(host1、host2和host3)之间通信为例，控制器在每个交换机上下发3条组表，即控制器总共下发6(2×3)条组表，以与主机host1有关的组表为例：
在Switch-A上添加组表类型为type＝ff的组表(group id为1)，组表1内设置端口A-1与主机host1连接的链路为主链路，聚合端口A-G与对端聚合端口B-G连接的链路为备链路。具体配置为：
ovs-ofctl add-group br0-O openflow13
“group_id＝1,type＝ff,bucket＝watch_port:A-1,output:A-1,bucket＝watch_port:A-G,push_vlan:0x8100,set_field:10->vlan_vid,output:A-G”
在Switch-B上同样添加组表类型为type＝ff的组表(group id也为1)，组表内设置端口B-1与主机host1连接的链路为主链路，聚合端口B-G与对端聚合端口A-G连接的链路为备链路。具体配置为：
ovs-ofctl add-group br0-O openflow13
“group_id＝1,type＝ff,bucket＝watch_port:B-1,output:B-1,bucket＝watch_port:B-G,push_vlan:0x8100,set_field:10->vlan_vid,output:B-G”
两条组表的共同点是发往备链路AGG的报文，会插入vlan_vid为10的VLAN tag(VLAN标签)，这个是为了报文通过备链路AGG发到对端交换机，可以根据vlan_vid识别出报文的来源是主机Host1。
类似的，针对主机Host2的组表group，将端口做相应的修改，插入的vlan_vid＝20；Host3也是修改对应端口，且vlan_vid＝30.
Switch-A上配置的与主机host2有关的组表具体为：
ovs-ofctl add-group br0-O openflow13
“group_id＝2,type＝ff,bucket＝watch_port:A-2,output:A-2,bucket＝watch_port:A-G,push_vlan:0x8100,set_field:20->vlan_vid,output:A-G”。
Switch-A上配置的与主机host3有关的组表具体为：
ovs-ofctl add-group br0-O openflow13
“group_id＝3,type＝ff,bucket＝watch_port:A-3,output:A-3,bucket＝watch_port:A-G,push_vlan:0x8100,set_field:30->vlan_vid,output:A-G”。
Switch-B上配置的与主机host2有关的组表具体为：
ovs-ofctl add-group br0-O openflow13
“group_id＝2,type＝ff,bucket＝watch_port:B-2,output:B-2,bucket＝watch_port:B-G,push_vlan:0x8100,set_field:20->vlan_vid,output:B-G”。
Switch-B上配置的与主机host3有关的组表具体为：
ovs-ofctl add-group br0-O openflow13
“group_id＝3,type＝ff,bucket＝watch_port:B-3,output:B-3,bucket＝watch_port:B-G,push_vlan:0x8100,set_field:30->vlan_vid,output:B-G”
根据以上配置，可以扩展到控制器在每个交换机上下发N个组表时，每个组表的配置，即将端口及插入的vlan_vid做相应的修改。
而在控制器未下发上述组表之前，交换机上只有table-miss流表，用于将所有接收的报文上送给控制器。需要说明的是，table-miss流表：其为优先级priority＝0，匹配域match field为空的流表，可以匹配所有的流量。往往作为默认处理流程，一般是将报文丢弃(drop)或是上送控制器。其它流表因为priority都大于0，因此会都会比table-miss表项优先匹配。
S2，主机之间进行ARP交互，控制器从所述ARP报文中获得各主机的MAC地址，并更新所述MAC地址到所述连接信息表内，且使主机之间学习到彼此的MAC地址，同时控制器在每个交换机上下发2N条用于匹配发往各主机的报文的流表，每个主机对应两条用于匹配发给其自身的报文的第一流表和第二流表，其中，所述第一流表配置从所述备链路传过来的报文转发路径，所述第二流表配置交换机上除备链路和主链路外的其他链路传过来的报文发送给对应主机的所述组表，根据所述组表的配置处理报文，其中，第一流表的优先级高于所述第二流表的优先级。
具体地，主机之间通信时，需要先进行ARP交互，就是知道目标IP，通过ARP获取目标IP对应的MAC地址。
结合图4所示，以上述三台主机间通信时，主机Host1(发起方)和主机Host2通信为例，来具体描述获取MAC地址的过程，其它情况原理相同。
(1)主机Host1要和主机Host2通信，需要发出ARP Request来请求Host2的MAC地址，其中，ARP Request中的配置信息具体包括：
source MAC是Host1_MAC
destMAC是全F，广播
ARPpayload(负载)：
>Sender MAC:Host1_MAC
>Sender IP：192.168.1.10
>TargetMAC:全0
>Target IP:192.168.1.20
(2)ARP Request报文无论发给交换机Switch-A还是发给交换机Switch-B，都会匹配到table-miss流表，以packet-in报文形式上送给控制器。
(3)控制器收到packet-in报文，解析出ARP报文的ARP payload，获取到了Host1的Bond MAC，更新上述连接信息表：
同时控制器还要在交换机Switch-A上下发两条流表，用于匹配发给Host1的IP报文，两条流表的具体配置为：
ovs-ofctl add-flow br0-O openflow13
“priority＝1010,ip,in_port＝A-G,dl_vlan＝10actions＝pop_vlan,output:A-1”<--编号A-f1
Ovs-ofctl add-flow br0-O openflow13
“priority＝1001,ip,dl_dst＝Host1_MAC actions＝group:1”<--编号A-f2
第一条flow优先级高于第二条，用来匹配从A-G传过来的报文，因为已经标示过dl_vlan＝10,所以一定是发给Host1的，直接转发到A-1。第二条流表是匹配Switch-A上，除了端口A-1和A-G外所有的端口收到的发给Host1的报文，发给group1(根据以上组表1配置，优先发到端口A-1，如果端口A-1down了，那么发给端口A-G)。
类似地，在Switch-B上也要下发两条流表：
ovs-ofctl add-flow br0-O openflow13
“priority＝1010,ip,in_port＝B-G,dl_vlan＝10actions＝pop_vlan,output:B-1”<--编号B-f1
Ovs-ofctl add-flow br0-O openflow13
“priority＝1001ip,dl_dst＝Host1_MAC actions＝group:1”<--编号B-f2
同样，第一条flow优先级高于第二条，用来匹配从B-G传过来的报文，因为已经标示过dl_vlan＝10,所以一定是发给Host1的，直接转发到B-1。第二条流表是匹配Switch-B上，除了端口B-1和B-G外所有的端口收到的发给Host1的报文，发给group1(根据以上组表配置，优先发到端口B-1，如果端口B-1down了，那么发给端口B-G)。
(4)控制器在两台交换机上，将刚收上来的ARP Request通过Packetout报文发往“Switch-A上除了A-1和A-G的其它端口”和“Switch-B上除了B-1和B-G的其它端口”。当主机Host2和交换机的连线都没有故障的时候，主机Host2会收到两份ARPRequest；如果主机Host2和交换机的联系有一条有故障，主机Host2还是能够收到一份ARP Request。主机Host3也会收到这个ARP Request，但是不会处理。
(5)主机Host2收到所述ARP Request，发现ARPpayload中的TargetIP是自己，就会回复ARP Reply报文通告控制器自身的MAC地址。ARPReply报文无论发给交换机Switch-A还是发给交换机Switch-B，都会匹配table-miss流表，上送控制器。
(6)控制器收到Host2发出的ARP replay，从ARPpayload中的Sender MAC获得Host2的MAC，更新连接信息表：
类似上述步骤(3)，控制器同时在交换机Switch-A上下发两条流表，用于匹配发给Host2的IP报文，两条流表的具体配置为：
ovs-ofctl add-flow br0-O openflow13
“priority＝1010,ip,in_port＝A-G,dl_vlan＝20actions＝pop_vlan,output:A-2”<--编号A-f3
Ovs-ofctl add-flow br0-O openflow13
“priority＝1001ip,dl_dst＝Host2_MAC actions＝group:2”<--编号A-f4
同样，第一条flow优先级高于第二条，用来匹配从A-G传过来的报文，因为已经标示过dl_vlan＝20,所以一定是发给Host2的，直接转发到A-2。第二条流表是匹配Switch-A上，除了端口A-2和B-G外所有的端口收到的发给Host2的报文，发给group2(根据以上组表配置，优先发到端口A-2，如果端口A-2down了，那么发给端口A-G)。
在交换机Switch-B上下发两条流表，用于匹配发给Host2的IP报文，两条流表的具体配置为：
ovs-ofctl add-flow br0–O openflow13“priority＝1010,ip,in_port＝B-G,dl_vlan＝20actions＝pop_vlan,output:B-2”<--编号B-f3
Ovs-ofctl add-flow br0–O openflow13“priority＝1001ip,dl_dst＝Host2_MAC actions＝group:2”<--编号B-f4
同样，第一条flow优先级高于第二条，用来匹配从B-G传过来的报文，因为已经标示过dl_vlan＝20,所以一定是发给Host2的，直接转发到B-2。第二条流表是匹配Switch-B上，除了端口B-2和B-G外所有的端口收到的发给Host2的报文，发给group2(根据以上组表配置，优先发到端口B-2，如果端口B-2down了，那么发给端口B-G)。
也就是说，当主机Host1要和主机Host2通信时，通过以上步骤，控制器可以获得主机Host1和Host2的Bond-MAC，并将获得的Bond-MAC更新到连接信息表中，且控制器还在交换机Switch-A和Switch-B上针对每台主机各下发了两条流表(即第一流表和第二流表)，用于匹配发给对应主机Host的IP报文。
(7)控制器因为已经有了主机Host1的MAC信息，因此能够解析出这是要发给主机Host1的ARP Request，因此控制器直接向主机Host1的端口A-1和主机Host2的端口B-1发送上述收到的主机Host2发送的ARP Reply。当主机Host1和交换机的连线都没有故障的时候，主机Host1会收到两份ARP Reply。如果主机Host1和交换机的链路有一条有故障，主机Host1还是能够收到一份ARPReply。这样，无论如何，主机Host1和Host2已经学习到了彼此的MAC。
又上述步骤(1)～(7)，可以推论到任意两主机(主机Hostm和Hostn)间通信时，彼此学习MAC地址的过程，以及下发的流表的具体配置信息。
S3，主机之间通信时，交换机接收从源主机上发来的报文，并匹配下发的所述第一流表或第二流表，根据所述第一流表或第二流表配置的行为执行，将报文转发到目的主机上。
具体地，经过上述步骤S2，主机之间已经学习到彼此的MAC地址，如主机host1(发起方)和主机host2之间通信时。
主机Host1发往主机Host2的IP报文为：
source MAC是Host1_MAC
destMAC是Host_MAC
source IP是192.168.1.10
dest IP是192.168.1.20
下面根据不同的场景，来描述主机host1(发起方)和主机host2之间通信的过程：
场景一：单台交换机宕机
例如交换机Switch-A挂掉了，交换机Switch-B还在，则主机Host1的报文一定是发给交换机Switch-B，在交换机Switch-B上匹配发给主机Host2的流表，因报文不是从端口B-G传过来，所以匹配已经下发的上述流表B-f4,根据流表B-f4的配置会转发给交换机Switch-B上的组表group2，根据组表group2的配置，会优先转发报文到端口B-2，由端口B-2发送给主机Host2，这样，主机Host2就收到主机Host1发的IP报文。
如果换成交换机Switch-B挂掉，原理类似。
场景二：主机Host1的一条上联线断了
假如是连接交换机Switch-B的线断了，那么主机Host1发出的报文一定是发给交换机Switch-A的端口A-1，在交换机Switch-A上匹配发给主机Host2的流表，因报文不是从端口A-G传过来，所以匹配已经下发的上述流表A-f4，根据流表A-f4的配置会转发给交换机Switch-A上的组表group2，根据组表group2的配置，会优先转发报文到端口A-2，由端口A-2发送给主机Host2。如果端口A-2是up的，那么主机Host2从端口A-2收到报文；如果端口A-2是down的，那么报文会转发到端口A-G，并加上vlan10，转发到交换机Switch-B以后，匹配交换机Switch-B上下发的流表B-f3，交换机Switch-B剥掉vlan10的tag后，将报文发到端口B-2，，由端口B-2发送给主机Host2，这样，主机Host2就收到主机Host1发的IP报文。
如果换成主机Host1连接交换机Switch-A的上联线断了，原理类似。
场景三：所有设备和端口都是好的
参考场景二，无论Host1发出的报文送到端口A-1还是端口B-1，最后都是只传一份到主机Host2，从而实现了双活。
主机Host2发往Host1的报文，MAC地址和IP地址互换，路径分析同上面的三个场景类似，这里不再赘述。这样，主机Host1和主机Host2的IP报文互相通信正常。
由上面描述的主机Host1和主机Host2通信的过程，主机Host3和Host1/Host2通信也都是类似的，可参照上述描述。这样，也可以拓展到N个主机之间的任意两个主机的通信。
也就是说，要想实现N个主机之间的任意两个主机的通信，总结起来包括：针对每台主机，控制器在每个交换机上预先下发两条组表；主机发出的ARP报文通过控制器处理转发，同时控制器更新流量信息表，并在每台交换机上各下发两条流表，这样就可以完成主机之间的通信了。
一般地，如果网络中有N台主机需要通过两台交换机进行两两通信，那么在每台交换机上，需要添加：2N个类型为ff的组表group，及2N条流表flow,并且不涉及具体的IP配置。
在应用中，还可能将主机Host1换成主机HostX。那么主机HostX如果要和网络中的其它主机通信，必然会发Sender MAC为HostX_MAC，被交换机通过packet_in报文发给控制器。那么控制器需要更新连接信息表：
交换机上下发的组表不需要修改，更新交换机上发给主机HostX流表中对应的一条即可。例如交换机Switch-A上需要更新为：
ovs-ofctl add-flowbr0-O openflow13
“priority＝1001ip,dl_dst＝HostX_MAC actions＝group:1”
其他交换机上流表更新类似。
另外，上面的描述中，并没有考虑lacp(Link Aggregation Control Protocol，链路汇聚控制协议)。如果主机需要lacp，那么控制器需要通过packet-in和packet-out来接收和发送lacp报文，完成与主机端口的lacp协商。上述过程与组表和流表无关。
本发明使用OpenFlow技术的流表flow和组表ff-group，实现同网段多主机之间的双活通信，有效利用带宽，并具备交换机级别和链路级别的失效保护，且可支持主机更换后的组表更新。
本发明的技术内容及技术特征已揭示如上，然而熟悉本领域的技术人员仍可能基于本发明的教示及揭示而作种种不背离本发明精神的替换及修饰，因此，本发明保护范围应不限于实施例所揭示的内容，而应包括各种不背离本发明的替换及修饰，并为本专利申请权利要求所涵盖。

Claims (10)

1.一种openflow交换机实现双活的方法，其特征在于，包括：
S1，控制器记录同网段的N个主机分别和至少两个交换机的端口连接信息到一连接信息表内，及根据所述连接信息表，在每个交换机上下发N个组表，一个组表对应一个主机，每个组表内配置其对应主机报文转发的主链路和备链路；
S2，主机之间进行ARP交互，控制器从所述ARP报文中获得各主机的MAC地址，并更新所述MAC地址到所述连接信息表内，且使主机之间学习到彼此的MAC地址，同时控制器在每个交换机上下发2N条用于匹配发往各主机的报文的流表，每个主机对应两条用于匹配发给其自身的报文的第一流表和第二流表；
S3，主机之间通信时，交换机接收从源主机上发来的报文，并匹配下发的所述第一流表或第二流表，根据所述第一流表或第二流表配置的行为执行，将报文转发到目的主机上；
其中，N为大于等于1的整数。
2.根据权利要求1所述的openflow交换机实现双活的方法，其特征在于，S1中，首先，所述控制器与两个交换机之间分别建立OpenFlow Channel，不同的OpenFlow Channel由交换机不同的DPID进行区分；所述交换机之间通过Peer-link建立连接；且每台主机都和每台交换机相连。
3.根据权利要求1所述的openflow交换机实现双活的方法，其特征在于，所述发往备链路对应的组表内配置：发往备链路的报文，插入vlan_vid的VLAN标签，用于报文通过备链路发到对端交换机，对端交换机可根据所述vlan_vid识别出报文的源主机。
4.根据权利要求1所述的openflow交换机实现双活的方法，其特征在于，所述S2包括：
S21，源主机发出ARPRequest报文来请求目的主机的MAC地址；
S22，所述ARP Request报文经任意一交换机，以packet-in报文形式上送给控制器；
S23，所述控制器收到所述packet-in报文，解析获得源主机的MAC地址，更新所述源主机的MAC地址到所述连接信息表内，同时，所述控制器在所述源主机上下发所述第一流表和第二流表，用于匹配发给所述源主机的IP报文；
S24，所述控制器将所述ARP Request报文以Packet out报文形式发送给每个交换机，经所述交换机发送给目的主机；
S25，所述目的主机收到所述ARP Request报文，回复ARP Reply报文通告控制器自身的MAC地址；
S26，所述控制器收到所述ARP Reply报文，解析获得目的主机的MAC地址，更新所述目的主机的MAC地址到所述连接信息表内，同时，所述控制器在所述目的主机上下发所述第一流表和第二流表，用于匹配发给所述目的主机的IP报文；
S27，所述控制器向源主机发送所述ARP Reply报文，至此，所述主机之间学习到彼此的MAC地址。
5.根据权利要求4所述的openflow交换机实现双活的方法，其特征在于，S21中，所述ARP Request报文中配置包括：报文的源MAC地址、目的MAC地址和ARP负载信息，所述ARP负载信息中配置包括：源主机的MAC地址、源主机的IP地址，目的主机的MAC地址和目的主机的IP地址，其中，所述目的MAC地址配置为全F的广播地址，所述目的主机的MAC地址为全0的地址。
6.根据权利要求1或4所述的openflow交换机实现双活的方法，其特征在于，S2中，所述第一流表配置从所述备链路传过来的报文的转发路径，所述第二流表配置交换机上除备链路和主链路外的其他链路传过来的报文，发送给对应主机配置的所述组表，根据所述组表的配置处理报文。
7.根据权利要求6所述的openflow交换机实现双活的方法，其特征在于，所述第一流表的优先级高于所述第二流表的优先级。
8.根据权利要求4所述的openflow交换机实现双活的方法，其特征在于，所述S24中，所述控制器将所述ARP Request报文发送给每个交换机上除了主链路对应的端口和备链路对应的端口外的其他端口上。
9.根据权利要求4所述的openflow交换机实现双活的方法，其特征在于，所述S27中，所述控制器直接向源主机和目的主机各自主链路对应的端口发送所述ARP Reply报文。
10.根据权利要求1所述的openflow交换机实现双活的方法，其特征在于，所述主机之间通信时，若将源主机换成任意主机HostX，则所述主机HostX与网络中的其它主机通信时，所述控制器需更新所述连接信息表中主机HostX对应的MAC地址，及更新每个交换机上发给主机HostX的所述第二流表。
CN201810164303.5A 2018-02-27 2018-02-27 一种openflow交换机实现双活的方法及系统 Active CN108390821B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810164303.5A CN108390821B (zh) 2018-02-27 2018-02-27 一种openflow交换机实现双活的方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810164303.5A CN108390821B (zh) 2018-02-27 2018-02-27 一种openflow交换机实现双活的方法及系统

Publications (2)

Publication Number Publication Date
CN108390821A true CN108390821A (zh) 2018-08-10
CN108390821B CN108390821B (zh) 2020-11-27

Family

ID=63069343

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810164303.5A Active CN108390821B (zh) 2018-02-27 2018-02-27 一种openflow交换机实现双活的方法及系统

Country Status (1)

Country Link
CN (1) CN108390821B (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110430143A (zh) * 2019-08-23 2019-11-08 锐捷网络股份有限公司 网络设备的负载均衡方法及装置
CN110519410A (zh) * 2019-08-29 2019-11-29 深信服科技股份有限公司 一种通信方法、交换机、存储介质、通信设备及通信系统
CN111385144A (zh) * 2020-03-04 2020-07-07 盛科网络（苏州）有限公司 基于静态链路聚合组的主备优先级控制方法及装置
CN113300952A (zh) * 2021-04-14 2021-08-24 启明星辰信息技术集团股份有限公司 一种用于云安全资源池的分布式引流系统及其引流方法
CN113381931A (zh) * 2021-05-17 2021-09-10 浪潮思科网络科技有限公司 一种在vxlan网络中支持mlag双活接入的方法及装置
WO2022042547A1 (zh) * 2020-08-28 2022-03-03 华为技术有限公司 流量转发处理方法及设备
WO2022077972A1 (zh) * 2020-10-12 2022-04-21 华为技术有限公司 Mlag链路故障切换方法和装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104639464A (zh) * 2015-01-09 2015-05-20 盛科网络（苏州）有限公司 OpenFlow交换机上实现跨交换机链路聚合的系统及方法
CN104917678A (zh) * 2015-06-02 2015-09-16 上海斐讯数据通信技术有限公司 基于sdn的链路聚合方法
CN104937888A (zh) * 2013-01-15 2015-09-23 国际商业机器公司 用于在多个交换机中使用的扩展的链路聚合(lag)
US20150281072A1 (en) * 2014-03-31 2015-10-01 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Link aggregation group (lag) support on a software-defined network (sdn)
CN107615721A (zh) * 2015-05-21 2018-01-19 华为技术有限公司 传输软件定义网络(sdn)‑逻辑链路聚合(lag)成员信令

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104937888A (zh) * 2013-01-15 2015-09-23 国际商业机器公司 用于在多个交换机中使用的扩展的链路聚合(lag)
US20150281072A1 (en) * 2014-03-31 2015-10-01 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Link aggregation group (lag) support on a software-defined network (sdn)
CN104639464A (zh) * 2015-01-09 2015-05-20 盛科网络（苏州）有限公司 OpenFlow交换机上实现跨交换机链路聚合的系统及方法
CN107615721A (zh) * 2015-05-21 2018-01-19 华为技术有限公司 传输软件定义网络(sdn)‑逻辑链路聚合(lag)成员信令
CN104917678A (zh) * 2015-06-02 2015-09-16 上海斐讯数据通信技术有限公司 基于sdn的链路聚合方法

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110430143A (zh) * 2019-08-23 2019-11-08 锐捷网络股份有限公司 网络设备的负载均衡方法及装置
CN110519410A (zh) * 2019-08-29 2019-11-29 深信服科技股份有限公司 一种通信方法、交换机、存储介质、通信设备及通信系统
CN111385144A (zh) * 2020-03-04 2020-07-07 盛科网络（苏州）有限公司 基于静态链路聚合组的主备优先级控制方法及装置
CN111385144B (zh) * 2020-03-04 2022-04-15 苏州盛科通信股份有限公司 基于静态链路聚合组的主备优先级控制方法及装置
WO2022042547A1 (zh) * 2020-08-28 2022-03-03 华为技术有限公司 流量转发处理方法及设备
WO2022077972A1 (zh) * 2020-10-12 2022-04-21 华为技术有限公司 Mlag链路故障切换方法和装置
CN113300952A (zh) * 2021-04-14 2021-08-24 启明星辰信息技术集团股份有限公司 一种用于云安全资源池的分布式引流系统及其引流方法
CN113300952B (zh) * 2021-04-14 2022-08-12 启明星辰信息技术集团股份有限公司 一种用于云安全资源池的分布式引流系统及其引流方法
CN113381931A (zh) * 2021-05-17 2021-09-10 浪潮思科网络科技有限公司 一种在vxlan网络中支持mlag双活接入的方法及装置
CN113381931B (zh) * 2021-05-17 2022-04-12 浪潮思科网络科技有限公司 一种在vxlan网络中支持mlag双活接入的方法及装置

Also Published As

Publication number Publication date
CN108390821B (zh) 2020-11-27

Similar Documents

Publication Publication Date Title
CN108390821A (zh) 一种openflow交换机实现双活的方法及系统
CN105812259B (zh) 一种报文转发方法和设备
US9112817B2 (en) Efficient TRILL forwarding
CN103259728B (zh) 一种ofs带内通信方法及ofs
CN103763207B (zh) 软件定义网络中的带内控制连接建立方法及设备
CN102368727B (zh) 跨ip网络的trill网络通信方法、系统和设备
CN101771618B (zh) 一种分组传送网络接入环中主机路由可达的方法及系统
CN104243270A (zh) 一种建立隧道的方法和装置
CN104735001B (zh) 软件定义网络中的链路发现方法、装置及系统
EP2816772A1 (en) Lacp negotiation processing method, relay node and system
CN104253765B (zh) 一种数据包交换方法、装置以及接入交换机和交换系统
CN104980355B (zh) 一种sdn环境下的源端可控组播数据传输系统
CN103220215B (zh) TRILL网络中FCoE报文的转发方法和装置
CN105450525B (zh) 用于路由交换设备使用的方法和设备
CN108173691A (zh) 一种跨设备聚合的方法及装置
CN102185782A (zh) 多链接透明传输互连网络的数据发送方法及其装置
CN103475583A (zh) 清除媒体接入控制转发表项的方法和设备
US8861339B2 (en) Packet forwarding function of a mobility switch deployed as routed SMLT (RSMLT) node
CN206422787U (zh) 用于通信的设备和系统
CN102857429B (zh) 在trill网络中承载路由的方法和装置
CN102984070B (zh) 一种以太网无编号接口实现数据转发的方法
CN104219149B (zh) 一种基于虚连接的报文传输方法和设备
US9699117B2 (en) Integrated fibre channel support in an ethernet fabric switch
CN104702478B (zh) 虚拟路由转发实例处理方法及装置
WO2012078523A1 (en) Systems and methods for pseudo-link creation

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
CP03 Change of name, title or address
CP03 Change of name, title or address

Address after: 215000 unit 13 / 16, 4th floor, building B, No.5 Xinghan street, Suzhou Industrial Park, Jiangsu Province

Patentee after: Suzhou Shengke Communication Co.,Ltd.

Address before: Unit 13 / 16, floor 4, building B, No. 5, Xinghan street, Suzhou Industrial Park, Suzhou, Jiangsu Province, 215000

Patentee before: CENTEC NETWORKS (SU ZHOU) Co.,Ltd.