CN105515978A - Method and device for realizing distributed routing and physical host access - Google Patents

Method and device for realizing distributed routing and physical host access Download PDF

Info

Publication number
CN105515978A
CN105515978A CN201610012009.3A CN201610012009A CN105515978A CN 105515978 A CN105515978 A CN 105515978A CN 201610012009 A CN201610012009 A CN 201610012009A CN 105515978 A CN105515978 A CN 105515978A
Authority
CN
China
Prior art keywords
mac
message
described message
local
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
CN201610012009.3A
Other languages
Chinese (zh)
Other versions
CN105515978B (en
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 CN201610012009.3A priority Critical patent/CN105515978B/en
Publication of CN105515978A publication Critical patent/CN105515978A/en
Application granted granted Critical
Publication of CN105515978B publication Critical patent/CN105515978B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/04Interdomain routing, e.g. hierarchical routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery

Landscapes

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

Abstract

The invention discloses a method and a device for realizing distributed routing and physical host access. A distributed routing agent is arranged on each of an openstack network node and a computing node; a multistage flow table is issued for controlling flow forwarding; special MAC is allocated for virtual gateways of each network; an MAC address allocated by openstack for a virtual gateway MAC starts with fa; a special MAC starts with ea, and the rest fields are identical. When local VM and remote VM are in different servers of different network segments, after the flow is subjected to distributed routing finding, a message source MAC is adapted into the special MAC for marking the flow subjected to distributed routing; flow requiring cross-server communication is led to a hardware interchanger to be forwarded. The method and the device have the advantages that the distributed routing is realized on the basis of the OpenFlow multistage flow table; the single node performance bottleneck is avoided; the plug-and-play effect of a physical host is achieved; software and hardware combination is adopted, and the forwarding performance bottleneck during large-scale VM is broken through.

Description

Realize distributed route, physical host access method and device
Technical field
The present invention relates to network communication field, particularly relate to a kind of realize distributed route, physical host access method and device.
Background technology
Along with the development of current network virtualization technology, software defined network (SoftwareDefinedNetwork, SDN) and the application scale that combines of cloud computing constantly expanding, OpenStack is as one of the management platform of virtual cloud main frame, and its attention rate strengthens day by day.Deployment scale along with fictitious host computer is increasing, and OpenStack also highlights day by day as the bottleneck of management platform, such as forwarding performance, single node failure, the demand of the mutual fusion of virtual network and physical network.For solving the problem, each manufacturer provides multiple solution, illustrates below for OpenStackNeutronDVR scheme and OpenStackDragonFlow scheme.
(1) OpenStackNeutronDVR program analysis
On OpenStack existing network framework, for virtual cloud main frame (VirtualMachine, VM) communication requirement of cross-network segment, no matter be East and West direction (East-West, E-W) flow or north-south (North-South, N-S) flow all needs around arriving virtual router (VirtualRouter, VRouter) on, like this, when VM disposes in a large number, forwarding performance on network node (NetworkNode) will sharply decline, the failure rate of single node will cause network and have a strong impact on simultaneously, although OpenStack supports the high availability cluster (HighAvailable of network node, HA) function, but this mode of the increase along with scale is also unfavorable for expansion.
Since OpenStackJuno version is issued, a kind of distributed route (DistributedVirtualRouting is provided for above-mentioned situation, DVR) solution, be deployed on computing node (ComputeNode) by distributed for the virtual router originally only had on the network node, be deployed on each computing node by L3 proxy server (L3Agent), be intended to the impact that reduction single node fault causes, avoid single node forwarding performance decline problem.Realize East and West direction flow completely distributed by DVR virtual router, as for north-south flow, for being assigned with the completely distributed by DVR virtual router of Floating IP address (FloatingIP), the virtual router for the unallocated network node that still detours to Floating IP address realizes shared verification.Wherein East and West direction traffic forwarding only supports vxlan pattern at present.
Here, DVR virtual router rises in linux NameSpace (Namespace), that is a linux NameSpace to be played on each computing node, all like this flows all need to walk the protocol stack of linux NameSpace, take a part of resource, waste is caused to performance, and actualizing technology is complicated, is unfavorable for safeguarding in production environment.
(2) OpenStackDragonFlow program analysis
The technology realized due to OpenStackNeutronDVR is too complicated, and bring unnecessary overhead, DragonFlow scheme is suggested, purport solve on computing node without the need to setting up linux NameSpace, by the form of OpenFlow flow table, realize the completely distributed of East and West direction flow.The program will dispose DragonFlowL3 controller on the network node, simultaneously at computing node deploy DragonFlowL2 proxy server, DragonFlowL3 controller calls Ryu controller by open API (AESTAPI) and carries out issuing of stream table to each node, stream table issue employing passive type, both first packet data message can on deliver on DragonFlowL3 controller, determine by it rule that stream table issues again, the program does not have an impact to north-south flow.
Here, in large-scale situation, data message is delivered on DragonFlowL3 controller by a large amount of, and because high availability cluster scheme do not supported by DragonFlowL3 controller, such DragonFlowL3 controller will become the bottleneck of forwarding performance.
In sum, according to the analysis of prior art, OpenStackNeutronDVR and OpenStackDragonFlow can solve the complete distributed requirement of East and West direction flow, but what OpenStackNeutronDVR adopted is the mode of linux NameSpace, the waste of resource and performance can be produced, and OpenStackDragonFlow can produce the performance bottleneck of single DragonFlowL3 controller, therefore, the problem of first needs solution is: the performance bottleneck solving single component while avoiding adopting too complicated technology to realize East and West direction flow distribution formula.
The scale of disposing along with VM is increasing, also gets more and more for the tunnel that single node is set up (Tunnel) thereupon, and incident is that on server forwarding performance is worse and worse.Therefore, the problem of second needs solution is: forwarding performance bottleneck on server when breakthrough large scale deployment fictitious host computer, realizes data traffic high-performance and forward.
Above two schemes all do not relate to the scheme of virtual network and physical network rapid fusion, and therefore, the problem of the 3rd needs solution is: realize physical host plug and play, make physical network and virtual network conveniently expand fusion.
Summary of the invention
The object of the present invention is to provide a kind of realize distributed route, physical host access method and device.
One of for achieving the above object, an embodiment of the present invention provides a kind of method realizing distributed route, the network node of openstack and computing node are provided with distributed routing agent, forward-path is controlled by issuing multilevel flow table, described multilevel flow table comprises tenant's identification table, two-layer retransmitting table and three layers of routing table, and described method comprises step:
S1: local tenant identifies that table identifies local VM and far-end VM, if identify successfully, then enters step S2, if recognition failures, then abandons;
S2: delivered in local two-layer retransmitting table by message, reads the object MAC of described message, if object MAC is gateway MAC, then enters step S3, if object MAC is the MAC of VM, then enters step S4; If object MAC is broadcast or multicast, then broadcast in map network;
S3: described message is delivered in local three layers of routing table, judge the VM belonging to object IP of message and local VM whether on same server, if same server, object MAC is rewritten into far-end MAC, enters step S5, if different server, source MAC is rewritten into special MAC, object MAC is rewritten into the MAC of far-end VM, special MAC is produced by gateway MAC, enters step S6;
S4: judge the VM belonging to object MAC of message and local VM whether on same server, if same server, then enter step S7, if different server, then enter step S8;
S5: utilize the object IP address of message to mate, if the match is successful, then receive described message, if it fails to match, then abandon described message;
S6: described message is delivered to far-end VM, far-end tenant identifies table identification source MAC, if identify successfully, then enters step S9, if recognition failures, then abandons described message;
S7: utilize the object MAC of message to mate, if the match is successful, then receives described message, if it fails to match, then abandons described message;
S8: described message is delivered to far-end VM, far-end tenant identifies table identification source MAC, if identify successfully, then enters step S10, if recognition failures, then abandons described message;
S9: delivered to by described message in far-end three layers of routing table, utilizes the IP address of message to mate, if the match is successful, then receives described message, if it fails to match, then abandon described message;
S10: delivered in far-end two-layer retransmitting table by described message, utilizes message object MAC to mate, if the match is successful, then receives described message, if it fails to match, then abandons described message.
As the further improvement of an embodiment of the present invention, the parameter of coupling and identifying also comprises network ID and/or vlan, wherein, the local ident of the network ID of two-layer retransmitting table to be distributed routing agent be each network allocation, for isolating two laminar flow amounts in heterogeneous networks, the network ID of three layer retransmitting tables is distributed routing agent is the local ident that each virtual router distributes, for isolating three laminar flow amounts in heterogeneous networks.
As the further improvement of an embodiment of the present invention, step S1 specifically comprises:
Local tenant identifies port information and the source MAC of the local VM message of table coupling, if all the match is successful for port information and source MAC, the ID being this network allocation by distributed for this locality routing agent marks on message, enter step S2, if it fails to match for port information and/or source MAC, then abandon described message.
As the further improvement of an embodiment of the present invention, when local VM and far-end VM be positioned at different server and server corresponding different switch time, described message " is delivered to far-end VM " and is specifically comprised by step: described message is sent to the upper united mouth of the second switch by tunnel style by the upper united mouth of the first switch.
As the further improvement of an embodiment of the present invention, when local VM creates successfully under described first switch, the upper united mouth of described first switch is issued to the mapping relation information of tunnel configuration information and VNI and vlan, described vlan is that local vlan corresponding to tenant, described vlan need to be set up when being sent to switch from server network interface card at message.
One of for achieving the above object, an embodiment of the present invention provides a kind of device realizing distributed route, comprise be installed on openstack network node and computing node on distributed routing agent, forward-path is controlled by issuing multilevel flow table, described multilevel flow table comprises tenant's identification table, two-layer retransmitting table and three layers of routing table, and described distributed routing agent is used for:
S1: local tenant identifies that table identifies local VM and far-end VM, if identify successfully, then enters step S2, if recognition failures, then abandons;
S2: delivered in local two-layer retransmitting table by message, reads the object MAC of described message, if object MAC is gateway MAC, then enters step S3, if object MAC is the MAC of VM, then enters step S4; If object MAC is broadcast or multicast, then broadcast in map network;
S3: described message is delivered in local three layers of routing table, judge the VM belonging to object IP of message and local VM whether on same server, if same server, object MAC is rewritten into far-end MAC, enters step S5, if different server, source MAC is rewritten into special MAC, object MAC is rewritten into the MAC of far-end VM, special MAC is produced by gateway MAC, enters step S6;
S4: judge the VM belonging to object MAC of message and local VM whether on same server, if same server, then enter step S7, if different server, then enter step S8;
S5: utilize the object IP address of message to mate, if the match is successful, then receive described message, if it fails to match, then abandon described message;
S6: described message is delivered to far-end VM, far-end tenant identifies table identification source MAC, if identify successfully, then enters step S9, if recognition failures, then abandons described message;
S7: utilize the object MAC of message to mate, if the match is successful, then receives described message, if it fails to match, then abandons described message;
S8: described message is delivered to far-end VM, far-end tenant identifies table identification source MAC, if identify successfully, then enters step S10, if recognition failures, then abandons described message;
S9: delivered to by described message in far-end three layers of routing table, utilizes the IP address of message to mate, if the match is successful, then receives described message, if it fails to match, then abandon described message;
S10: delivered in far-end two-layer retransmitting table by described message, utilizes message object MAC to mate, if the match is successful, then receives described message, if it fails to match, then abandons described message.
One of for achieving the above object, an embodiment of the present invention provides a kind of method realizing physical host access, the network node of openstack and computing node are provided with distributed routing agent, forward-path is controlled by issuing multilevel flow table, described multilevel flow table comprises tenant's identification table, two-layer retransmitting table and three layers of routing table, and described method comprises step:
S1: tenant identifies that table identifies local VM, if identify successfully, then enters step s2, if recognition failures, then abandons;
S2: delivered to by message in two-layer retransmitting table, reads the object MAC of described message, if object MAC is gateway MAC, then enters step s3, if object MAC is not gateway MAC, mates the two-layer retransmitting table of wildcard in this network, enters step s4;
S3: described message is delivered in three layers of routing table, message is sent to virtual router by coupling default route, is sent the MAC of ARP message request physical host, enter step s4, if it fails to match, then abandon described message by virtual router;
S4: described message is delivered on the switch of physical host access, described switch is by identifying that VNI is mapped to local vlan, and recycling object MAC mates, if the match is successful, then receive described message, realize physical host access, if it fails to match, then abandon described message.
As the further improvement of an embodiment of the present invention, described message is delivered to the upper united mouth of the second switch by tunnel by the upper united mouth of the first switch, described first switch is connected with virtual network service, and described second switch is connected with physical host or virtual router.
As the further improvement of an embodiment of the present invention, when local VM creates successfully under described first switch, the upper united mouth of described first switch is issued to the mapping relation information of tunnel configuration information and VNI and vlan.
One of for achieving the above object, an embodiment of the present invention provides a kind of device realizing physical host access, comprise the distributed routing agent on the network node of the server being installed on openstack and computing node, forward-path is controlled by issuing multilevel flow table, described multilevel flow table comprises tenant's identification table, two-layer retransmitting table and three layers of routing table, and described distributed routing agent is used for:
S1: tenant identifies that table identifies local VM, if identify successfully, then enters step s2, if recognition failures, then abandons;
S2: delivered to by message in two-layer retransmitting table, reads the object MAC of described message, if object MAC is gateway MAC, then enters step s3, if object MAC is not gateway MAC, mates the two-layer retransmitting table of wildcard in this network, enters step s4;
S3: described message is delivered in three layers of routing table, message is sent to virtual router by coupling default route, is sent the MAC of ARP message request physical host, enter step s4, if it fails to match, then abandon described message by virtual router;
S4: described message is delivered on the switch of physical host access, described switch is by identifying that VNI is mapped to local vlan, and recycling object MAC mates, if the match is successful, then receive described message, realize physical host access, if it fails to match, then abandon described message.
Compared with prior art, beneficial effect of the present invention is: the present invention is based on OpenFlow multilevel flow table and realize distributed route, computing node of the present invention and network node are provided with distributed routing agent, avoid single node performance bottleneck, solve the distributed routing function of East and West direction flow, the present invention also realizes physical host plug and play, physical network and virtual network is made conveniently to expand fusion, forwarding performance bottleneck on server when the method breakthrough large scale deployment fictitious host computer adopting software and hardware forwarding chip to be combined with each other, realize data traffic high-performance to forward.
Accompanying drawing explanation
Fig. 1 is the schematic network structure of an embodiment of the present invention;
Fig. 2 is the method flow diagram realizing distributed route of an embodiment of the present invention;
Fig. 3 is an example block diagram of the method for distributed route that realizes of an embodiment of the present invention;
Fig. 4 is the network structure of another execution mode of the present invention;
Fig. 5 is the method flow diagram realizing physical host access of an embodiment of the present invention.
Embodiment
Describe the present invention below with reference to embodiment shown in the drawings.But these execution modes do not limit the present invention, the structure that those of ordinary skill in the art makes according to these execution modes, method or conversion functionally are all included in protection scope of the present invention.
As shown in Figure 1, for the network structure of an embodiment of the present invention, described network mainly includes Neutron plug-in unit (TorPlugin) 3, cloud manager (CloudManager) 5a, switch cloud proxy server (CloudAgent) 6a, distributed routing agent (DVRAgent) 8a.
Plug-in unit 3 is as one of the driving of ML2 plug-in unit 2, be installed on Controlling vertex (ControllerNode), its Main Function is connected by Json-rpc4 and cloud manager 5a, enable cloud manager 5a to OpenStackNeutron database (datebase, DB) data are inquired about, OpenStackNeutron database (datebase simultaneously, also cloud manager 5a can be notified when DB) changing, synchronous data mainly comprise tenant's information (tenant)/network information (network)/subnet information (subnet)/route-map (router)/port information (port).
Cloud manager 5a, as the manager of core supervisor 5, is installed on Controlling vertex.Cloud manager 5a essence is the centralized manager of a miniature switch and server, only has the function of message transparent transmission.Cloud manager 5a is connected by Socket11 and switch cloud proxy server 6a, distributed routing agent 8a, thus the data of Neutron database will be collected by Json-rpc4, be assembled into specific form bag and mail to switch cloud proxy server 6a, distributed routing agent 8a, the unified configuration management of a little global property can be done simultaneously on cloud manager 5a.
Concrete, when network is Overlay network, OpenStack cloud management platform creates a VM in this Overlay network, by searching Neutron database after cloud manager 5a gets the information of this VM, obtain the network information belonging to this VM, just can obtain according to the network information VNI that OpenStack cloud management platform distributes for this Overlay network, VNI can be used as the identifier of this Overlay network.Cloud manager 5a is this VM distribution localvlan (switch and network allocation localvlan, that is same network possibility localvlan on different switch is inconsistent), have mapping relations between this localvlan and this VNI, this mapping relations are distributed to switch cloud proxy server 6a and distributed routing agent 8a by cloud manager 5a.
When network is Vlan network, OpenStack cloud management platform creates a VM in this Vlan network, by searching Neutron database after cloud manager 5a gets the information of this VM, obtain the network information belonging to this VM, just can obtain according to the network information vlan information that OpenStack cloud management platform distributes for this VM, cloud manager 5a by vlan distribution of information to switch cloud proxy server 6a and distributed routing agent 8a.
The succedaneum of switch cloud proxy server 6a in return machine 6, be installed on switch 6, switch cloud proxy server 6a is in charge of the configuration distributing function of respective switch 6.Switch 6 can by server 8 interface of the Lldp protocol discovery second line of a couplet.
When network is Overlay network, OpenStack cloud management platform creates a VM in this Overlay network, switch cloud proxy server 6a gets the mapping relations of VNI and vlan of VM place network on this switch 6 by cloud manager 5a, when VM creates successfully on the server 8 that this switch is hung for 6 times, to photos and sending messages 10 under the upper united mouth of switch 6, comprise the mapping relation information of tunnel configuration information and VNI and Vlan, the configuration information that this vlan allows to pass through is issued to the second line of a couplet mouth of switch 6.
When network is Vlan network, OpenStack cloud management platform creates a VM in this Vlan network, switch cloud proxy server 6a gets the vlan information of VM place network on this switch 6 by cloud manager 5a, when VM creates successfully on the server 8 that this switch 6 times is hung, the configuration information that this vlan allows to pass through all is issued to the second line of a couplet mouth of switch 6.The unified configuration information being configured to allow all vlan to pass through in upper united mouth.
Distributed routing agent 8a, as the succedaneum of server 8, is installed on computing node and network node, and distributed routing agent 8a is in charge of the stream table on each node and controls the function of traffic forwarding.
Concrete, the forwarding flow table that network node and computing node issue all is undertaken calculating and manage by the distributed routing agent 8a on each node, in order to the complexity of alternative linux NameSpace, distributed routing agent 8a adopts the mode of multilevel flow table to realize the distributed of East and West direction flow, because the function of multilevel flow table is distributed on each node, thus the performance bottleneck of single node can be avoided.Distributed routing agent 8a, after the data receiving cloud manager 5a, adopts the active flow of mode to node issuing stream table to manage.
As shown in Figure 2, for the method realizing distributed route of an embodiment of the present invention, the network node of openstack and computing node are provided with distributed routing agent 8a, forward-path is controlled by issuing multilevel flow table, described multilevel flow table comprises tenant's identification table, two-layer retransmitting table and three layers of routing table, and described method comprises step:
S1: local tenant identifies that table identifies local VM and far-end VM, if identify successfully, then enters step S2, if recognition failures, then abandons;
S2: delivered in local two-layer retransmitting table by message, reads the object MAC of described message, if object MAC is gateway MAC, then enters step S3, if object MAC is the MAC of VM, then enters step S4; If object MAC is broadcast or multicast, then broadcast in map network;
S3: described message is delivered in local three layers of routing table, judge the VM belonging to object IP of message and local VM whether on same server, if same server, object MAC is rewritten into far-end MAC, enters step S5, if different server, source MAC is rewritten into special MAC, object MAC is rewritten into the MAC of far-end VM, special MAC is produced by gateway MAC, enters step S6;
S4: judge the VM belonging to object MAC of message and local VM whether on same server, if same server, then enter step S7, if different server, then enter step S8;
S5: utilize the object IP address of message to mate, if the match is successful, then receive described message, if it fails to match, then abandon described message;
S6: described message is delivered to far-end VM, far-end tenant identifies table identification source MAC, if identify successfully, then enters step S9, if recognition failures, then abandons described message;
S7: utilize the object MAC of message to mate, if the match is successful, then receives described message, if it fails to match, then abandons described message;
S8: described message is delivered to far-end VM, far-end tenant identifies table identification source MAC, if identify successfully, then enters step S10, if recognition failures, then abandons described message;
S9: delivered to by described message in far-end three layers of routing table, utilizes the IP address of message to mate, if the match is successful, then receives described message, if it fails to match, then abandon described message;
S10: delivered in far-end two-layer retransmitting table by described message, utilizes message object MAC to mate, if the match is successful, then receives described message, if it fails to match, then abandons described message.
It should be noted that, above-mentioned steps is only the exemplary steps of present embodiment, and order, not as limit, can be determined according to actual conditions.
In the present embodiment, distributed routing agent 8a be the gateway of each network distribute in special MAC, an OpenStack cloud management platform to gateway MAC distribute scope be with fa be beginning one section of MAC Address, here, special MAC starts with ea, and field is identical thereafter.When local VM and far-end VM is in different segment, namely now flow needs switch-spanning to forward, present embodiment utilizes multilevel flow table that source MAC is rewritten into special MAC, the process through virtual router is simulated with this, so, reduce the burden of virtual router, avoid single node performance bottleneck, solve the distributed routing function of East and West direction flow; In addition, gateway MAC the overall situation visible, so for recognize ea start special MAC after, easily can identify the data traffic of different segment.
In the present embodiment, step S1 specifically comprises: local tenant identifies port information and the source MAC of the local VM message of table coupling, if all the match is successful for port information and source MAC, the ID being this network allocation by distributed for this locality routing agent marks on message, enter step S2, if it fails to match for port information and/or source MAC, then abandon described message.Here, tenant's identification table adopts the double-point information of port information and source MAC to identify, can prevent MAC from cheating.
In the present embodiment, continue ginseng Fig. 1, be configured with tunnel between the upper united mouth of multiple switch 6, under Overlay network scenarios, OpenStack cloud management platform can use as identifier for it distributes a VNI, this VNI when each network creation in tunnel.When local VM and far-end VM be positioned at different server and server corresponding different switch time, the original message of local VM carries vlan and sends from server 8 network interface card, the original message sent from server 8 network interface card is sent to connected switch 6, original message to be encrypted encapsulation according to the mapping relations of vlan and VNI and to deliver on another switch 6 by packaged channel message by tunnel by switch 6, and another switch 6 is decrypted by the mapping relations of vlan and VNI and obtains original message.Here, on the one hand, achieved the encrypting and decrypting process of message transmission by the mapping relations of vlan and VNI and the setting in tunnel, improve reliability and the packaging effects of transport process; On the other hand, the substantial amounts of VNI, avoids the quantitative restriction of vlan; Again on the one hand, switch 6 and tunnel are combined, when the method breakthrough large scale deployment VM adopting software and hardware forwarding chip to be combined with each other, forwarding performance bottleneck on server, realizes data traffic high-performance and forwards.
In the present embodiment, the parameter of coupling and identifying also comprises network ID and/or Vlan etc., can determine according to actual flow sheet form.
Illustrate that the present invention realizes the method for distributed route with concrete example below.
Multilevel flow table structure is divided into: first order table=0: identify table for tenant, second level table=1: the NORMAL for the treatment of Flat network shows, third level table=2: for the treatment of transmitting of physical machine access, fourth stage table=7: for the treatment of the two-layer retransmitting table in virtual network, level V table=8: for the treatment of three layer retransmitting tables in virtual network, the 6th grade of table=9: for the treatment of the broadcast table in virtual network.Group stream table is used for the support to broadcast.
The method of distributed route is realized introduce four kinds of application scenarioss below under Overlay network schemer under.
(1) application scenarios analyzes 1: same network segment is with VM communication in server.Specifically comprise:
For local VM, tenant's identification table adopts in_port+src_mac uniquely to identify, can prevent MAC from cheating, and concrete stream sheet form is:
"table=0,priority=1000,dl_vlan=0xffff,in_port=ofport,dl_src=vm_mac,actions=mod_vlan_vid:vid,write_metadata:meta_id,goto_table:7"
Here, the network ID that distributes for this network for distributed routing agent 8a of meta_id.
The flow of the local VM recognized is sent local two-layer retransmitting table table=7 by tenant's identification table.
In the local two-layer retransmitting table of table=7, the process for ARP message: because be same network segment, so object MAC is broadcast address, object IP address is the IP address needing to carry out the far-end VM communicated, and concrete stream sheet form is:
"table=7,priority=100,dl_dst=ff:ff:ff:ff:ff:ff,actions=goto_table:9"
The broadcast traffic recognized is delivered to broadcast table table=9 by two-layer retransmitting table, broadcast table adopts meta_id uniquely to identify, the network ID that this meta_id distributes for this network for distributed routing agent 8a, so broadcast traffic has been limited in a network, concrete stream sheet form has been:
"table=9,priority=100,metadata=meta_id,actions=group:meta_id"
"group_id=meta_id,type=all,bucket=strip_vlan,output:ofport”
In the local two-layer retransmitting table of table=7, process for data message: adopt meta_id+vlan+dst_mac uniquely to identify with the traffic forwarding of the VM in server 8 in same network segment, the network ID that this meta_id distributes for this network for distributed routing agent 8a, can isolate the flow without the network segment.Concrete stream sheet form is:
"table=7,priority=1000,metadata=meta_id,dl_vlan=vid,dl_dst=vm_mac,actions=strip_vlan,output:ofport"
(2) application scenarios analyzes 2: VM communication in same network segment different server.Specifically comprise:
For local VM, tenant's identification table adopts in_port+src_mac uniquely to identify, can prevent MAC from cheating, and concrete stream sheet form is:
"table=0,priority=1000,dl_vlan=0xffff,in_port=ofport,dl_src=vm_mac,actions=mod_vlan_vid:vid,write_metadata:meta_id,goto_table:7"
Here, the network ID that distributes for this network for distributed routing agent 8a of meta_id.
The flow of the local VM recognized is sent local two-layer retransmitting table table=7 by tenant's identification table.
In the local two-layer retransmitting table of table=7, the process for ARP message: because be same network segment, so object MAC is broadcast address, object IP address is the IP address needing to carry out the far-end VM communicated, and concrete stream sheet form is:
"table=7,priority=100,dl_dst=ff:ff:ff:ff:ff:ff,actions=goto_table:9"
The broadcast traffic recognized is delivered to broadcast table table=9 by two-layer retransmitting table, broadcast table adopts meta_id uniquely to identify, the network ID that this meta_id distributes for this network for distributed routing agent 8a, broadcasting packet carries vlan and sends from server 8 network interface card, the message seen off from server 8 network interface card is sent to switch 6, according to the mapping relations of vlan and tunnel VNI on switch 6, encapsulated by message from switch 6 upper united mouth and deliver to far-end, namely message delivers to another switch 6 by a switch 6 by tunnel.Concrete stream sheet form is:
"table=9,priority=100,metadata=meta_id,actions=group:meta_id"
"group_id=meta_id,type=all,bucket=output:external”
In the local two-layer retransmitting table of table=7, process for data message: the traffic forwarding for the VM in same network segment different server adopts meta_id+vlan+dst_mac uniquely to identify, the network ID that this meta_id distributes for this network for distributed routing agent 8a, can isolate the flow without the network segment.Concrete stream sheet form is:
"table=7,priority=1000,metadata=meta_id,dl_vlan=vid,dl_dst=vm_mac,actions=output:external"
For the VM of far-end, owing to being positioned at different server 8, tenant's identification table adopts vlan+src_mac uniquely to identify, concrete stream sheet form is:
"table=0,priority=1000,dl_vlan=vid,dl_src=vm_mac,actions=write_metadata:meta_id,goto_table:7"
Here, the network ID that distributes for this network for distal portion cloth routing agent 8a of meta_id.
When message arrives in the two stage forwarding tables (table=7) of far-end VM, utilize the object MAC in message to mate, if the match is successful, then receive described message, if it fails to match, then abandon described message.
(3) application scenarios analyzes 3: different segment is with VM communication in server.Specifically comprise:
For local VM, tenant's identification table adopts in_port+src_mac uniquely to identify, can prevent MAC from cheating, and concrete stream sheet form is:
"table=0,priority=1000,dl_vlan=0xffff,in_port=ofport,dl_src=vm_mac,actions=mod_vlan_vid:vid,write_metadata:meta_id,goto_table:7"
Here, the network ID that distributes for this network for distributed routing agent 8a of meta_id.
The flow of the local VM recognized is sent local two-layer retransmitting table table=7 by tenant's identification table.
In the local two-layer retransmitting table of table=7, process for ARP message: because be different segment, so object MAC is broadcast address, object IP address is the IP address of this network segment gateway (Gateway), after carrying out ARP proxy to gateway, arp traffic will no longer detour virtual router (VRouter).Concrete stream sheet form is:
"table=7,priority=500,metadata=meta_id,dl_type=0x0806,nw_dst=gateway_ip,
actions=strip_vlan,move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:gateway_mac->dl_src,set_field:2->arp_op,move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],set_field:gateway_mac->arp_sha,move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],set_field:gateway_ip->arp_spa,in_port"
Here, the network ID that distributes for this network for distributed routing agent 8a of meta_id.
In the local two-layer retransmitting table of table=7, the process for data message: the traffic forwarding employing meta_id+vlan+gw_mac of different segment with the VM in server is uniquely identified.Concrete stream sheet form is:
"table=7,priority=2000,metadata=meta_id,ip,dl_vlan=vid,dl_dst=gateway_mac,actions=write_metadata:meta_id,goto_table:8"
Here, meta_id can be rewritten, the network ID that the router that this meta_id is this VM place for distributed routing agent 8a distributes.
The local VM recognized needs the flow doing route to send three local layer retransmitting table table=8 by two-layer retransmitting table.
The traffic forwarding employing meta_id+dst_ip of different segment with the VM in server is uniquely identified, the network ID that the router that this meta_id is this VM place for distributed routing agent 8a distributes.Concrete stream sheet form is:
"table=8,priority=1000,metadata=meta_id,ip,nw_dst=dst_ip,vlan_vid=0x1000/0x1000,actions=strip_vlan,set_field:vm_mac->dl_dst,output:ofport"
(4) application scenarios analyzes 4: VM communication in different segment different server.Specifically comprise:
For local VM, tenant's identification table adopts in_port+src_mac uniquely to identify, can prevent MAC from cheating, and concrete stream sheet form is:
"table=0,priority=1000,dl_vlan=0xffff,in_port=ofport,dl_src=vm_mac,actions=mod_vlan_vid:vid,write_metadata:meta_id,goto_table:7"
Here, the network ID that distributes for this network for distributed routing agent 8a of meta_id.
The flow of the local VM recognized is sent local two-layer retransmitting table table=7 by tenant's identification table.
In the local two-layer retransmitting table of table=7, process for ARP message: because be different segment, so object MAC is broadcast address, object IP address is the IP address of this network segment gateway (Gateway), after carrying out ARP proxy to gateway, arp traffic will no longer detour virtual router (VRouter).Concrete stream sheet form is:
"table=7,priority=500,metadata=meta_id,dl_type=0x0806,nw_dst=gateway_ip,
actions=strip_vlan,move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:gateway_mac->dl_src,set_field:2->arp_op,move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],set_field:gateway_mac->arp_sha,move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],set_field:gateway_ip->arp_spa,in_port"
Here, the network ID that distributes for this network for distributed routing agent 8a of meta_id.
In the local two-layer retransmitting table of table=7, the process for data message: the traffic forwarding for the VM in different segment different server adopts meta_id+vlan+gw_mac uniquely to identify.Concrete stream sheet form is:
"table=7,priority=2000,metadata=meta_id,ip,dl_vlan=vid,dl_dst=gateway_mac,actions=write_metadata:meta_id,goto_table:8"
Here meta_id can be rewritten, the network ID that the router that this meta_id is this VM place for distributed routing agent 8a distributes.
The local VM recognized needs the flow doing route to send three local layer retransmitting table table=8 by two-layer retransmitting table.
Traffic forwarding for the VM in different segment different server adopts meta_id+dst_ip uniquely to identify, the network ID that the router that this meta_id is this VM place for distributed routing agent 8a distributes.Concrete stream sheet form is:
"table=8,priority=1000,metadata=meta_id,ip,nw_dst=dst_ip,vlan_vid=0x1000/0x1000,actions=set_field:router_mac->dl_src,set_field:vm_mac->dl_dst,mod_vlan_vid:vid,output:external"
For the VM of far-end, tenant's identification table adopts vlan+src_mac uniquely to identify, concrete stream sheet form is:
"table=0,priority=1000,dl_vlan=vid,dl_src=router_mac,actions=write_metadata:meta_id,goto_table:8"
Here, the network ID that distributes for router that distributed routing agent 8a is this VM place of this meta_id.
When transmitting in (table=8) for three grades that message arrives far-end VM, utilizing the object IP address in message to mate, if the match is successful, then receiving described message, if it fails to match, then abandoning described message.Here, when the source MAC of matching is special MAC (dl_src=router_mac), judge that now message had done distributed route, object MAC changes, and now enters three layer retransmitting tables and utilizes object IP address to mate.
Wherein ofport is the port numbers of VM carry on open virtual switch (OpenvSwitch), vm_mac is the MAC Address of VM, vid is the Localvlan that this VM belonging network is corresponding, gateway_mac is VM gateway MAC address, meta_id in table=0 divides No. ID that is used in isolation network flow for distributed routing agent 8a is each network, and the meta_id in table=8 divides for distributed routing agent 8a is each router and is used in isolation not at the flow of same virtual router.Router_mac is distributed routing agent 8a is the special MAC Address that each VM gateway distributes, and external is the network interface card of server.
Concrete, as shown in Figure 3, for application scenarios analyzes a concrete example of VM communication in different segment different server in 4.Two servers 8 connect two different switches 6 respectively, for convenience of description, first server 8 connects the first switch 6, second server 8 ' connects the second switch 6 ', in first server 8, the IP address of local VM is 1.1.1.1, in second server 8 ', the IP address of far-end VM is 2.2.2.2, and namely now local VM and far-end VM is in different segment.When local VM needs to send message to far-end VM, information entrained in query message learns that the port information (communication port of first server 8 and the first interchanger 6) of local VM is Port_mac:1.1.1 (source MAC), Port_ip:1.1.1.1, tenant identifies that table identifies successfully, distributed routing agent 8a recognizes far-end VM and local VM is positioned at different segment, namely Dst_ip:2.2.2.2 is recognized, now by multilevel flow table, source MAC is rewritten into special MAC, i.e. Src_mac:route1_mac, so, just simulating need through the process of virtual router when different segment message transmits, revised message is sent in the first corresponding switch 6 by first server 8 gateway by first server 8, first switch 6 delivers to the second switch 6 ' by tunnel after being encapsulated by message, message is delivered in its lower second server 8 ' hung after deciphering by the second switch 6 ', the multilevel flow table of the distributed routing agent 8a ' in second server 8 ' matches the message judged when source MAC is special MAC now, and to have done inflow-rate of water turbine distributed, object MAC changes, need the coupling of carrying out IP address, then in three layer retransmitting tables of multilevel flow table, carry out IP matching addresses, if the match is successful, then receive message, if it fails to match, then dropping packets.Above-mentioned explanation is sent to second server 8 ' for the message in first server 8, certainly, in other embodiments, also first server 8 can be sent to by second server 8 ', similar, now utilize multilevel flow table source MAC can be rewritten into special MAC, i.e. Src_mac:route2_mac, so can analogue flow rate distributed, other steps with reference to above-mentioned explanation, can not repeat them here.
An embodiment of the present invention also provides a kind of device realizing distributed route, comprise be installed on openstack network node and computing node on distributed routing agent 8a, forward-path is controlled by issuing multilevel flow table, described multilevel flow table comprises tenant's identification table, two-layer retransmitting table and three layers of routing table, and described distributed routing agent 8a is used for:
S1: local tenant identifies that table identifies local VM and far-end VM, if identify successfully, then enters step S2, if recognition failures, then abandons;
S2: delivered in local two-layer retransmitting table by message, reads the object MAC of described message, if object MAC is gateway MAC, then enters step S3, if object MAC is the MAC of VM, then enters step S4; If object MAC is broadcast or multicast, then broadcast in map network;
S3: described message is delivered in local three layers of routing table, judge the VM belonging to object IP of message and local VM whether on same server, if same server, object MAC is rewritten into far-end MAC, enters step S5, if different server, source MAC is rewritten into special MAC, object MAC is rewritten into the MAC of far-end VM, special MAC is produced by gateway MAC, enters step S6;
S4: judge the VM belonging to object MAC of message and local VM whether on same server, if same server, then enter step S7, if different server, then enter step S8;
S5: utilize the object IP address of message to mate, if the match is successful, then receive described message, if it fails to match, then abandon described message;
S6: described message is delivered to far-end VM, far-end tenant identifies table identification source MAC, if identify successfully, then enters step S9, if recognition failures, then abandons described message;
S7: utilize the object MAC of message to mate, if the match is successful, then receives described message, if it fails to match, then abandons described message;
S8: described message is delivered to far-end VM, far-end tenant identifies table identification source MAC, if identify successfully, then enters step S10, if recognition failures, then abandons described message;
S9: delivered to by described message in far-end three layers of routing table, utilizes the IP address of message to mate, if the match is successful, then receives described message, if it fails to match, then abandon described message;
S10: delivered in far-end two-layer retransmitting table by described message, utilizes message object MAC to mate, if the match is successful, then receives described message, if it fails to match, then abandons described message.
In the present embodiment, distributed routing agent 8a be the gateway of each network distribute in special MAC, an OpenStack cloud management platform to gateway MAC distribute scope be with fa be beginning one section of MAC Address, here, special MAC starts with ea, and field is identical thereafter.When local VM and far-end VM is in different segment, namely now flow needs switch-spanning to forward, present embodiment utilizes multilevel flow table that source MAC is rewritten into special MAC, the process through virtual router is simulated with this, so, reduce the burden of virtual router, avoid single node performance bottleneck, solve the distributed routing function of East and West direction flow; In addition, gateway MAC the overall situation visible, so for recognize ea start special MAC after, easily can identify the data traffic of different segment.
Other explanations realizing the device of distributed route of present embodiment with reference to the explanation in the above-mentioned method realizing distributed route, can not repeat them here.
Ginseng Fig. 4, be the network structure of another execution mode of the present invention, the network configuration in Fig. 4 and Fig. 1 is similar, and identical parts adopt identical label, and the function of same parts with reference to aforementioned explanation, can not repeat them here.Also comprise physical switches 7 and physical host 9 in Fig. 4, physical host 9 is connected in physical switches 7 times, and physical switches 7 can be carried out with other switches 6 alternately.
It is troublesome problem that the actual situation of virtual network and physical network combines all the time, and the fictitious host computer that OpenStack cloud management platform manages cannot get any information of physical network, and also just cannot automatically set up tunnel completes communication simultaneously.The method of present embodiment and easily physical network tunnel access reliably a kind of in conjunction with the functional realiey of physical switches by the implementation of multilevel flow table.Be configured with tunnel between the upper united mouth of switch 6 and physical switches 7, under Overlay network scenarios, OpenStack cloud management platform can use as identifier for it distributes a VNI, this VNI when each network creation in tunnel.
Composition graphs 5, an embodiment of the present invention realize physical host access method in, the network node of openstack and computing node are provided with distributed routing agent 8a, forward-path is controlled by issuing multilevel flow table, described multilevel flow table comprises tenant's identification table, two-layer retransmitting table and three layers of routing table, and described method comprises step:
S1: tenant identifies that table identifies local VM, if identify successfully, then enters step s2, if recognition failures, then abandons;
S2: delivered to by message in two-layer retransmitting table, reads the object MAC of described message, if object MAC is gateway MAC, then enters step s3, if object MAC is not gateway MAC, mates the two-layer retransmitting table of wildcard in this network, enters step s4;
S3: described message is delivered in three layers of routing table, message is sent to virtual router by coupling default route, is sent the MAC of ARP message request physical host, enter step s4, if it fails to match, then abandon described message by virtual router;
S4: described message is delivered on the switch of physical host access, described switch is by identifying that VNI is mapped to local vlan, and recycling object MAC mates, if the match is successful, then receive described message, realize physical host access, if it fails to match, then abandon described message.
It should be noted that, above-mentioned steps is only the exemplary steps of present embodiment, and order, not as limit, can be determined according to actual conditions.
In the present embodiment, by all arranging distributed routing agent 8a at network node and computing node, utilizing distributed routing agent 8a multilevel flow table, physical host 9 plug and play can be realized, making physical network and virtual network conveniently expand fusion.
Here, it should be noted that, in step s2, owing to not knowing MAC Address and the IP address of any one physical host in physical network in the virtual network of openstack, so in two-layer retransmitting table, mate the two-layer retransmitting table of wildcard in this network.In step s3, owing to not knowing MAC Address and the IP address of any one physical host in physical network in the virtual network of openstack, accurate route querying cannot be carried out, so message is sent to virtual router by coupling default route by multilevel flow table.
Other explanations realizing the method for physical host access of present embodiment with reference to the aforementioned explanation realizing the method for distributed route, such as, also can be connected etc. by tunnel between physical switches 7 with switch 6, illustrate and repeat no more.
With concrete example, the method that physical host of the present invention accesses is described below.
Multilevel flow table structure is divided into: first order table=0: identify table for tenant, second level table=1: the NORMAL for the treatment of Flat network shows, third level table=2: for the treatment of transmitting of physical machine access, fourth stage table=7: for the treatment of the two-layer retransmitting table in virtual network, level V table=8: for the treatment of three layer retransmitting tables in virtual network, the 6th grade of table=9: for the treatment of the broadcast table in virtual network.Group stream table is used for the support to broadcast.
The method of distributed route is realized introduce two kinds of application scenarioss below under Overlay network schemer under.
(1) application scenarios analyzes 1: same network segment physical host and Virtual Server Communication.Specifically comprise:
For local VM, tenant's identification table adopts in_port+src_mac uniquely to identify, can prevent MAC from cheating, and concrete stream sheet form is:
"table=0,priority=1000,dl_vlan=0xffff,in_port=ofport,dl_src=vm_mac,actions=mod_vlan_vid:vid,write_metadata:meta_id,goto_table:7"
The flow of the local VM recognized is sent local two-layer retransmitting table table=7 by tenant's identification table.
In the local two-layer retransmitting table of table=7, the process for ARP message: because be same network segment, so object MAC is broadcast address, object IP address is the IP address needing to carry out communication physical machine, concrete stream sheet form is:
"table=7,priority=100,dl_dst=ff:ff:ff:ff:ff:ff,actions=goto_table:9"
The broadcast traffic recognized is delivered to broadcast table table=9 by two-layer retransmitting table, and broadcast table adopts meta_id uniquely to identify, message carries vlan and sends from server 8 network interface card.The message seen off from server 8 network interface card is sent to switch 6, according to the mapping relations of vlan and tunnel VNI on switch 6, from upper united mouth, message is encapsulated into far-end, namely message is delivered in physical switches 7 by switch 6 by tunnel, and now message is encapsulated on physical network (comprising physical switches 7 and physical host 9).Concrete stream sheet form is:
"table=9,priority=100,metadata=meta_id,actions=group:meta_id"
"group_id=meta_id,type=all,bucket=output:external”
In the local two-layer retransmitting table of table=7, the process for data message: the traffic forwarding for the VM in same network segment different server adopts meta_id+vlan uniquely to identify, can isolate the flow without the network segment.The message that server 8 network interface card is seen off is sent on switch 6, according to the mapping relations of vlan and tunnel VNI on switch 6, from upper united mouth, message is encapsulated into far-end, namely message is delivered in physical switches 7 by switch 6 by tunnel, and now message is encapsulated on physical network (comprising physical switches 7 and physical host 9).Concrete stream sheet form is:
"table=7,priority=10,metadata=meta_id,dl_vlan=vid,actions=output:external"
Physical switches 7 finds the mapping relations with the vlan of physical host 9 after parsing VNI, message is sent back to physical host 9 from second line of a couplet mouth, for the physical host 9 of far-end, VM is because cannot get the MAC Address (because now physical host 9 in still may dispose multiple VM) of corresponding VM in physical host 9, employing vlan uniquely identifies at tenant's identification table for the process of the message postbacked by virtual network, and concrete stream sheet form is:
"table=0,priority=10,dl_vlan=vid,actions=write_metadata:meta_id,goto_table:2"
"table=2,priority=10,dl_vlan=vid,actions=goto_table:7"
Here, the network ID that distributes for this network for distributed routing agent 8a of meta_id.
When message arrives in two stage forwarding tables (table=7), utilize the object MAC in message to mate, if the match is successful, then receive described message, if it fails to match, then abandon described message.
(2) application scenarios analyzes 2: different segment physical host and Virtual Server Communication.Specifically comprise:
For local VM, tenant's identification table adopts in_port+src_mac uniquely to identify, can prevent MAC from cheating, and concrete stream sheet form is:
"table=0,priority=1000,dl_vlan=0xffff,in_port=ofport,dl_src=vm_mac,actions=mod_vlan_vid:vid,write_metadata:meta_id,goto_table:7"
The flow of the local VM recognized is sent local two-layer retransmitting table table=7 by tenant's identification table.
In the local two-layer retransmitting table of table=7, process for ARP message: because be different segment, so object MAC is broadcast address, object IP address is the IP address of this network segment gateway (Gateway), after carrying out ARP proxy to gateway, arp traffic will no longer detour virtual router (VRouter).Concrete stream sheet form is:
"table=7,priority=500,metadata=meta_id,dl_type=0x0806,nw_dst=gateway_ip,actions=strip_vlan,move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:gateway_mac->dl_src,set_field:2->arp_op,move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],set_field:gateway_mac->arp_sha,move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],set_field:gateway_ip->arp_spa,in_port"
In the local two-layer retransmitting table of table=7, the process for data message: the traffic forwarding for the VM in different segment different server adopts meta_id+vlan+gw_mac uniquely to identify.Concrete stream sheet form is:
"table=7,priority=2000,metadata=meta_id,ip,dl_vlan=vid,dl_dst=gateway_mac,actions=write_metadata:meta_id,goto_table:8"
The local VM recognized needs the flow doing route to send three local layer retransmitting table table=8 by two-layer retransmitting table.
Traffic forwarding for the VM in different segment different server adopts meta_id+dst_ip uniquely to identify.Because the IP address of physical host 9 is sightless equally for virtual network, so message is sent to virtual router, concrete stream sheet form is:
"table=8,priority=500,metadata=meta_id,dl_dst=gateway_mac,ip,vlan_vid=0x1000/0x1000,actions=strip_vlan,output:external/ofport”
Here, the MAC Address of ARP message request physical host 9 is sent by virtual server (VRouter), thus message is mail to physical switches 7, physical switches 7 finds the mapping relations with the vlan of physical host 9 after parsing VNI, be sent back to physical host 9 by message from second line of a couplet mouth.That is, the virtual network of cross-network segment is combined with the actual situation of physical network needs the virtual server (VRouter) that detours.
For the physical host 9 of far-end, VM is because cannot get the MAC Address (because now physical host 9 in still may dispose multiple VM) of corresponding VM in physical host 9, so tenant's identification table adopts vlan uniquely to identify, concrete stream sheet form is:
"table=0,priority=10,dl_vlan=vid,actions=write_metadata:meta_id,goto_table:2"
"table=2,priority=500,metadata=meta_id,dl_src=gateway_mac,ip,vlan_vid=0x1000/0x1000,actions=strip_vlan,output:goto_table7"
Here, the network ID that distributes for this network for distributed routing agent 8a of meta_id.
When message arrives in two stage forwarding tables (table=7), utilize the object MAC in message to mate, if the match is successful, then receive described message, if it fails to match, then abandon described message.
Wherein ofport is the port numbers of VM carry on open virtual switch (OpenvSwitch), vm_mac is the MAC Address of VM, vid is the Localvlan that this VM belonging network is corresponding, gateway_mac is VM gateway MAC address, meta_id in table=0 divides No. ID that is used in isolation network flow for distributed routing agent 8a is each network, and the meta_id in table=7 divides for distributed routing agent 8a is each router and is used in isolation not at the flow of same virtual router.Router_mac is distributed routing agent 8a is the special MAC Address that each VM gateway distributes, and external is the network interface card of server.
An embodiment of the present invention also provides a kind of device realizing physical host access, comprise the distributed routing agent 8a on the network node of the server being installed on openstack and computing node, forward-path is controlled by issuing multilevel flow table, described multilevel flow table comprises tenant's identification table, two-layer retransmitting table and three layers of routing table, and described distributed routing agent 8a is used for:
S1: tenant identifies that table identifies local VM, if identify successfully, then enters step s2, if recognition failures, then abandons;
S2: delivered to by message in two-layer retransmitting table, reads the object MAC of described message, if object MAC is gateway MAC, then enters step s3, if object MAC is not gateway MAC, mates the two-layer retransmitting table of wildcard in this network, enters step s4;
S3: described message is delivered in three layers of routing table, message is sent to virtual router by coupling default route, is sent the MAC of ARP message request physical host, enter step s4, if it fails to match, then abandon described message by virtual router;
S4: described message is delivered on the switch of physical host access, described switch is by identifying that VNI is mapped to local vlan, and recycling object MAC mates, if the match is successful, then receive described message, realize physical host access, if it fails to match, then abandon described message.
In the present embodiment, by all arranging distributed routing agent 8a at network node and computing node, utilizing distributed routing agent 8a multilevel flow table, physical host plug and play can be realized, making physical network and virtual network conveniently expand fusion.
Other explanations realizing the device of physical host access of present embodiment with reference to the explanation in the above-mentioned method realizing physical host access, can not repeat them here.
In sum, the network node of openstack of the present invention and computing node are provided with distributed routing agent, pass through logical operation, control openvswitch, to its issue multilevel flow table control traffic forwarding, the present invention be the virtual gateway of each network distribute special MAC, openstack to the scope that virtual gateway MAC distributes be with fa be start MAC Address, special MAC starts with ea, and field is identical thereafter.When local VM and far-end VM is in different segment different server, utilize multilevel flow table after flow did distributed route querying, the source MAC of VM is rewritten into the special MAC that this network distributes, to be used for marking the flow doing distributed route, distributed routing agent can carry out hardware forwarding by needing the flow carrying out cross-server communication to drain in hardware switch.The present invention is based on OpenFlow multilevel flow table and realize distributed route, avoid single node performance bottleneck, solve the distributed routing function of East and West direction flow, realize physical host plug and play, when the method breakthrough large scale deployment VM adopting software and hardware forwarding chip to be combined with each other, server forwarding performance bottleneck, realizes data traffic high-performance and forwards.
Be to be understood that, although this specification is described according to execution mode, but not each execution mode only comprises an independently technical scheme, this narrating mode of specification is only for clarity sake, those skilled in the art should by specification integrally, technical scheme in each execution mode also through appropriately combined, can form other execution modes that it will be appreciated by those skilled in the art that.
A series of detailed description listed is above only illustrating for feasibility execution mode of the present invention; they are also not used to limit the scope of the invention, all do not depart from the skill of the present invention equivalent implementations done of spirit or change all should be included within protection scope of the present invention.

Claims (10)

1. one kind realizes the method for distributed route, it is characterized in that the network node of openstack and computing node are provided with distributed routing agent, forward-path is controlled by issuing multilevel flow table, described multilevel flow table comprises tenant's identification table, two-layer retransmitting table and three layers of routing table, and described method comprises step:
S1: local tenant identifies that table identifies local VM and far-end VM, if identify successfully, then enters step S2, if recognition failures, then abandons;
S2: delivered in local two-layer retransmitting table by message, reads the object MAC of described message, if object MAC is gateway MAC, then enters step S3, if object MAC is the MAC of VM, then enters step S4; If object MAC is broadcast or multicast, then broadcast in map network;
S3: described message is delivered in local three layers of routing table, judge the VM belonging to object IP of message and local VM whether on same server, if same server, object MAC is rewritten into far-end MAC, enters step S5, if different server, source MAC is rewritten into special MAC, object MAC is rewritten into the MAC of far-end VM, special MAC is produced by gateway MAC, enters step S6;
S4: judge the VM belonging to object MAC of message and local VM whether on same server, if same server, then enter step S7, if different server, then enter step S8;
S5: utilize the object IP address of message to mate, if the match is successful, then receive described message, if it fails to match, then abandon described message;
S6: described message is delivered to far-end VM, far-end tenant identifies table identification source MAC, if identify successfully, then enters step S9, if recognition failures, then abandons described message;
S7: utilize the object MAC of message to mate, if the match is successful, then receives described message, if it fails to match, then abandons described message;
S8: described message is delivered to far-end VM, far-end tenant identifies table identification source MAC, if identify successfully, then enters step S10, if recognition failures, then abandons described message;
S9: delivered to by described message in far-end three layers of routing table, utilizes the IP address of message to mate, if the match is successful, then receives described message, if it fails to match, then abandon described message;
S10: delivered in far-end two-layer retransmitting table by described message, utilizes message object MAC to mate, if the match is successful, then receives described message, if it fails to match, then abandons described message.
2. the method realizing distributed route according to claim 1, it is characterized in that, the parameter of coupling and identifying also comprises network ID and/or vlan, wherein, the local ident of the network ID of two-layer retransmitting table to be distributed routing agent be each network allocation, for isolating two laminar flow amounts in heterogeneous networks, the network ID of three layer retransmitting tables is distributed routing agent is the local ident that each virtual router distributes, for isolating three laminar flow amounts in heterogeneous networks.
3. the method realizing distributed route according to claim 1, is characterized in that step S1 specifically comprises:
Local tenant identifies port information and the source MAC of the local VM message of table coupling, if all the match is successful for port information and source MAC, the ID being this network allocation by distributed for this locality routing agent marks on message, enter step S2, if it fails to match for port information and/or source MAC, then abandon described message.
4. the method realizing distributed route according to claim 1, it is characterized in that, when local VM and far-end VM be positioned at different server and server corresponding different switch time, described message " is delivered to far-end VM " and is specifically comprised by step: described message is sent to the upper united mouth of the second switch by tunnel style by the upper united mouth of the first switch.
5. the method realizing distributed route according to claim 4, it is characterized in that, when local VM creates successfully under described first switch, the upper united mouth of described first switch is issued to the mapping relation information of tunnel configuration information and VNI and vlan, described vlan is that local vlan corresponding to tenant, described vlan need to be set up when being sent to switch from server network interface card at message.
6. realize a device for distributed route, it is characterized in that comprising:
Be installed on the distributed routing agent on the network node of openstack and computing node, forward-path is controlled by issuing multilevel flow table, described multilevel flow table comprises tenant's identification table, two-layer retransmitting table and three layers of routing table, and described distributed routing agent is used for:
S1: local tenant identifies that table identifies local VM and far-end VM, if identify successfully, then enters step S2, if recognition failures, then abandons;
S2: delivered in local two-layer retransmitting table by message, reads the object MAC of described message, if object MAC is gateway MAC, then enters step S3, if object MAC is the MAC of VM, then enters step S4; If object MAC is broadcast or multicast, then broadcast in map network;
S3: described message is delivered in local three layers of routing table, judge the VM belonging to object IP of message and local VM whether on same server, if same server, object MAC is rewritten into far-end MAC, enters step S5, if different server, source MAC is rewritten into special MAC, object MAC is rewritten into the MAC of far-end VM, special MAC is produced by gateway MAC, enters step S6;
S4: judge the VM belonging to object MAC of message and local VM whether on same server, if same server, then enter step S7, if different server, then enter step S8;
S5: utilize the object IP address of message to mate, if the match is successful, then receive described message, if it fails to match, then abandon described message;
S6: described message is delivered to far-end VM, far-end tenant identifies table identification source MAC, if identify successfully, then enters step S9, if recognition failures, then abandons described message;
S7: utilize the object MAC of message to mate, if the match is successful, then receives described message, if it fails to match, then abandons described message;
S8: described message is delivered to far-end VM, far-end tenant identifies table identification source MAC, if identify successfully, then enters step S10, if recognition failures, then abandons described message;
S9: delivered to by described message in far-end three layers of routing table, utilizes the IP address of message to mate, if the match is successful, then receives described message, if it fails to match, then abandon described message;
S10: delivered in far-end two-layer retransmitting table by described message, utilizes message object MAC to mate, if the match is successful, then receives described message, if it fails to match, then abandons described message.
7. one kind realizes the method for physical host access, it is characterized in that the network node of openstack and computing node are provided with distributed routing agent, forward-path is controlled by issuing multilevel flow table, described multilevel flow table comprises tenant's identification table, two-layer retransmitting table and three layers of routing table, and described method comprises step:
S1: tenant identifies that table identifies local VM, if identify successfully, then enters step s2, if recognition failures, then abandons;
S2: delivered to by message in two-layer retransmitting table, reads the object MAC of described message, if object MAC is gateway MAC, then enters step s3, if object MAC is not gateway MAC, mates the two-layer retransmitting table of wildcard in this network, enters step s4;
S3: described message is delivered in three layers of routing table, message is sent to virtual router by coupling default route, is sent the MAC of ARP message request physical host, enter step s4, if it fails to match, then abandon described message by virtual router;
S4: described message is delivered on the switch of physical host access, described switch is by identifying that VNI is mapped to local vlan, and recycling object MAC mates, if the match is successful, then receive described message, realize physical host access, if it fails to match, then abandon described message.
8. the method realizing physical host access according to claim 7, it is characterized in that, described message is delivered to the upper united mouth of the second switch by tunnel by the upper united mouth of the first switch, described first switch is connected with virtual network service, and described second switch is connected with physical host or virtual router.
9. the method realizing physical host access according to claim 8, it is characterized in that, when local VM creates successfully under described first switch, the upper united mouth of described first switch is issued to the mapping relation information of tunnel configuration information and VNI and vlan.
10. realize a device for physical host access, it is characterized in that comprising:
Be installed on the distributed routing agent on the network node of the server of openstack and computing node, forward-path is controlled by issuing multilevel flow table, described multilevel flow table comprises tenant's identification table, two-layer retransmitting table and three layers of routing table, and described distributed routing agent is used for:
S1: tenant identifies that table identifies local VM, if identify successfully, then enters step s2, if recognition failures, then abandons;
S2: delivered to by message in two-layer retransmitting table, reads the object MAC of described message, if object MAC is gateway MAC, then enters step s3, if object MAC is not gateway MAC, mates the two-layer retransmitting table of wildcard in this network, enters step s4;
S3: described message is delivered in three layers of routing table, message is sent to virtual router by coupling default route, is sent the MAC of ARP message request physical host, enter step s4, if it fails to match, then abandon described message by virtual router;
S4: described message is delivered on the switch of physical host access, described switch is by identifying that VNI is mapped to local vlan, and recycling object MAC mates, if the match is successful, then receive described message, realize physical host access, if it fails to match, then abandon described message.
CN201610012009.3A 2016-01-08 2016-01-08 Realize the method and device of distributed routing, physical host access Active CN105515978B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610012009.3A CN105515978B (en) 2016-01-08 2016-01-08 Realize the method and device of distributed routing, physical host access

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610012009.3A CN105515978B (en) 2016-01-08 2016-01-08 Realize the method and device of distributed routing, physical host access

Publications (2)

Publication Number Publication Date
CN105515978A true CN105515978A (en) 2016-04-20
CN105515978B CN105515978B (en) 2018-11-02

Family

ID=55723634

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610012009.3A Active CN105515978B (en) 2016-01-08 2016-01-08 Realize the method and device of distributed routing, physical host access

Country Status (1)

Country Link
CN (1) CN105515978B (en)

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105933235A (en) * 2016-07-07 2016-09-07 北京邮电大学 Data communication method and data communication device
CN106292369A (en) * 2016-09-09 2017-01-04 南京玛锶腾智能科技有限公司 The dcs of steering wheel and method
CN106572014A (en) * 2016-10-27 2017-04-19 曙光信息产业(北京)有限公司 Virtual network system
CN106878136A (en) * 2016-12-28 2017-06-20 新华三技术有限公司 A kind of message forwarding method and device
CN107453998A (en) * 2016-05-31 2017-12-08 华为技术有限公司 The method and apparatus of transmitting message
CN107770062A (en) * 2016-08-16 2018-03-06 北京金山云网络技术有限公司 A kind of data packet sending method, device and the network architecture
CN108039968A (en) * 2017-12-12 2018-05-15 深圳市泰信通信息技术有限公司 Network optimized approach, equipment and computer-readable recording medium
CN108123818A (en) * 2016-11-30 2018-06-05 江南大学 A kind of emulation mode of the expansible fusion of actual situation network agile
CN108183862A (en) * 2018-01-24 2018-06-19 上海宽带技术及应用工程研究中心 Communication means/system, readable storage medium storing program for executing and the equipment of software definition switching network
CN108259333A (en) * 2016-12-29 2018-07-06 华为技术有限公司 A kind of BUM flow control methods, relevant apparatus and system
CN108768807A (en) * 2018-06-01 2018-11-06 中国电子信息产业集团有限公司第六研究所 A kind of method and device of cloud platform actual situation interconnection
CN109379267A (en) * 2018-10-18 2019-02-22 郑州云海信息技术有限公司 A kind of method and apparatus that virtual LAN being added for physical machine
CN109547392A (en) * 2017-09-21 2019-03-29 杭州达乎科技有限公司 A kind of encryption cut-in method and system for supporting multi-user's isolation in SDN network
CN110401923A (en) * 2019-04-19 2019-11-01 广州天链通信科技有限公司 A kind of method and VSAT terminal of VSAT terminal bridge and routing mode support simultaneously
CN110650092A (en) * 2019-09-24 2020-01-03 网易(杭州)网络有限公司 Data processing method and device
CN110752989A (en) * 2019-10-18 2020-02-04 苏州浪潮智能科技有限公司 Method and device for forwarding east-west traffic
CN111130939A (en) * 2019-12-26 2020-05-08 深圳前海环融联易信息科技服务有限公司 Flow control method and device, computer equipment and storage medium
CN111756636A (en) * 2019-03-29 2020-10-09 杭州海康威视数字技术股份有限公司 Data packet processing method, device and equipment and storage medium
CN112491710A (en) * 2020-11-09 2021-03-12 锐捷网络股份有限公司 Message forwarding method and device based on Openflow
CN114422471A (en) * 2020-10-10 2022-04-29 中国移动通信有限公司研究院 Data transmission method, flow table configuration method, device, equipment and storage medium
CN114466011A (en) * 2022-01-29 2022-05-10 苏州浪潮智能科技有限公司 Metadata service request method, device, equipment and medium
CN114785733A (en) * 2022-06-20 2022-07-22 中电云数智科技有限公司 Method for realizing session tracing in cross-VPC network flow forwarding
CN115022126A (en) * 2022-05-23 2022-09-06 苏州思萃工业互联网技术研究所有限公司 Method and system for realizing distributed edge gateway
CN115442297A (en) * 2022-09-06 2022-12-06 中电云数智科技有限公司 System and method for realizing EIP intelligent access based on BGP
CN117014371A (en) * 2023-07-05 2023-11-07 曙光云计算集团有限公司 Network traffic processing method and device, electronic equipment and storage medium

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150071053A1 (en) * 2011-05-23 2015-03-12 Telefonaktiebolaget L M Ericsson (Publ) Implementing epc in a cloud computer with openflow data plane
CN104869058A (en) * 2015-06-04 2015-08-26 北京京东尚科信息技术有限公司 Method and device for transmitting data message
CN105099779A (en) * 2015-07-29 2015-11-25 北京京东尚科信息技术有限公司 Multi-tenant cloud platform architecture

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150071053A1 (en) * 2011-05-23 2015-03-12 Telefonaktiebolaget L M Ericsson (Publ) Implementing epc in a cloud computer with openflow data plane
CN104869058A (en) * 2015-06-04 2015-08-26 北京京东尚科信息技术有限公司 Method and device for transmitting data message
CN105099779A (en) * 2015-07-29 2015-11-25 北京京东尚科信息技术有限公司 Multi-tenant cloud platform architecture

Cited By (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107453998A (en) * 2016-05-31 2017-12-08 华为技术有限公司 The method and apparatus of transmitting message
CN107453998B (en) * 2016-05-31 2020-02-14 华为技术有限公司 Method and device for transmitting message
CN105933235B (en) * 2016-07-07 2019-02-19 北京邮电大学 Data communications method and device
CN105933235A (en) * 2016-07-07 2016-09-07 北京邮电大学 Data communication method and data communication device
CN107770062A (en) * 2016-08-16 2018-03-06 北京金山云网络技术有限公司 A kind of data packet sending method, device and the network architecture
CN106292369A (en) * 2016-09-09 2017-01-04 南京玛锶腾智能科技有限公司 The dcs of steering wheel and method
CN106292369B (en) * 2016-09-09 2019-02-15 江苏新辰海智能科技有限公司 The dcs and method of steering engine
CN106572014A (en) * 2016-10-27 2017-04-19 曙光信息产业(北京)有限公司 Virtual network system
CN108123818B (en) * 2016-11-30 2020-10-09 江南大学 Simulation method for flexible and extensible fusion of virtual and actual networks
CN108123818A (en) * 2016-11-30 2018-06-05 江南大学 A kind of emulation mode of the expansible fusion of actual situation network agile
CN106878136A (en) * 2016-12-28 2017-06-20 新华三技术有限公司 A kind of message forwarding method and device
CN106878136B (en) * 2016-12-28 2020-01-03 新华三技术有限公司 Message forwarding method and device
US11245631B2 (en) 2016-12-29 2022-02-08 Huawei Technologies Co., Ltd. Bum traffic control method, related apparatus, and system
CN108259333A (en) * 2016-12-29 2018-07-06 华为技术有限公司 A kind of BUM flow control methods, relevant apparatus and system
CN108259333B (en) * 2016-12-29 2021-07-09 华为技术有限公司 BUM flow control method, related device and system
CN109547392A (en) * 2017-09-21 2019-03-29 杭州达乎科技有限公司 A kind of encryption cut-in method and system for supporting multi-user's isolation in SDN network
CN109547392B (en) * 2017-09-21 2021-06-01 上海层峰网络科技有限公司 Encryption access method and system supporting multi-user isolation in SDN network
CN108039968A (en) * 2017-12-12 2018-05-15 深圳市泰信通信息技术有限公司 Network optimized approach, equipment and computer-readable recording medium
CN108039968B (en) * 2017-12-12 2021-02-23 深圳市泰信通信息技术有限公司 Network optimization method, device and computer readable storage medium
CN108183862A (en) * 2018-01-24 2018-06-19 上海宽带技术及应用工程研究中心 Communication means/system, readable storage medium storing program for executing and the equipment of software definition switching network
CN108768807A (en) * 2018-06-01 2018-11-06 中国电子信息产业集团有限公司第六研究所 A kind of method and device of cloud platform actual situation interconnection
CN109379267A (en) * 2018-10-18 2019-02-22 郑州云海信息技术有限公司 A kind of method and apparatus that virtual LAN being added for physical machine
CN111756636A (en) * 2019-03-29 2020-10-09 杭州海康威视数字技术股份有限公司 Data packet processing method, device and equipment and storage medium
CN110401923A (en) * 2019-04-19 2019-11-01 广州天链通信科技有限公司 A kind of method and VSAT terminal of VSAT terminal bridge and routing mode support simultaneously
CN110401923B (en) * 2019-04-19 2021-08-10 广州天链通信科技有限公司 Method for simultaneously supporting VSAT terminal network bridge and routing mode and VSAT terminal
CN110650092B (en) * 2019-09-24 2022-05-03 网易(杭州)网络有限公司 Data processing method and device
CN110650092A (en) * 2019-09-24 2020-01-03 网易(杭州)网络有限公司 Data processing method and device
CN110752989A (en) * 2019-10-18 2020-02-04 苏州浪潮智能科技有限公司 Method and device for forwarding east-west traffic
CN111130939A (en) * 2019-12-26 2020-05-08 深圳前海环融联易信息科技服务有限公司 Flow control method and device, computer equipment and storage medium
CN114422471A (en) * 2020-10-10 2022-04-29 中国移动通信有限公司研究院 Data transmission method, flow table configuration method, device, equipment and storage medium
CN112491710A (en) * 2020-11-09 2021-03-12 锐捷网络股份有限公司 Message forwarding method and device based on Openflow
CN114466011B (en) * 2022-01-29 2023-08-04 苏州浪潮智能科技有限公司 Metadata service request method, device, equipment and medium
CN114466011A (en) * 2022-01-29 2022-05-10 苏州浪潮智能科技有限公司 Metadata service request method, device, equipment and medium
CN115022126B (en) * 2022-05-23 2023-09-01 苏州思萃工业互联网技术研究所有限公司 Implementation method and system of distributed edge gateway
CN115022126A (en) * 2022-05-23 2022-09-06 苏州思萃工业互联网技术研究所有限公司 Method and system for realizing distributed edge gateway
CN114785733A (en) * 2022-06-20 2022-07-22 中电云数智科技有限公司 Method for realizing session tracing in cross-VPC network flow forwarding
CN114785733B (en) * 2022-06-20 2022-08-26 中电云数智科技有限公司 Method for realizing session tracing in cross-VPC network flow forwarding
CN115442297A (en) * 2022-09-06 2022-12-06 中电云数智科技有限公司 System and method for realizing EIP intelligent access based on BGP
CN115442297B (en) * 2022-09-06 2023-08-22 中电云数智科技有限公司 System and method for realizing EIP intelligent access based on BGP
CN117014371A (en) * 2023-07-05 2023-11-07 曙光云计算集团有限公司 Network traffic processing method and device, electronic equipment and storage medium

Also Published As

Publication number Publication date
CN105515978B (en) 2018-11-02

Similar Documents

Publication Publication Date Title
CN105515978A (en) Method and device for realizing distributed routing and physical host access
CN109660443B (en) SDN-based physical device and virtual network communication method and system
JP5991424B2 (en) Packet rewriting device, control device, communication system, packet transmission method and program
JP5792894B2 (en) Port expansion topology information acquisition method, system, control bridge, and uplink port processing method and system
CN102857416B (en) A kind of realize the method for virtual network, controller and virtual network
US9448821B2 (en) Method and system for realizing virtual machine mobility
ES2565827T3 (en) Layer 3 routing, device and virtual private network system control method
US20160261496A1 (en) Packet forwarding in data center network
CN107947961A (en) Kubernetes Network Management System and method based on SDN
EP3197107B1 (en) Message transmission method and apparatus
EP2843906B1 (en) Method, apparatus, and system for data transmission
CN113411243B (en) Data transmission method and device
TW202037128A (en) Logical router comprising disaggregated network elements
US20150172222A1 (en) Data center ethernet switch fabric
US10572291B2 (en) Virtual network management
CN104937885A (en) Global VLANs for fabric switches
CN105681191A (en) SDN (Software Defined Network) platform based on router virtualization and implementation method
CN105847157B (en) Communication means end to end between mark network based on SDN
CN104081733A (en) Interconnecting data centers for migration of virtual machines
CN104272668A (en) Layer-3 overlay gateways
CN108696370B (en) Method, device and system for binding and unbinding server and service
CN110505095B (en) Method for building large-scale virtual data center by using small number of servers
US8855015B2 (en) Techniques for generic pruning in a trill network
CN105610672B (en) A kind of method and device of information transmission
WO2019134637A1 (en) Method, device, and system for multi-type network virtualization overlay interconnection

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
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: Xinghan Street Industrial Park of Suzhou city in Jiangsu province 215021 B No. 5 Building 4 floor 13/16 unit

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

CP03 Change of name, title or address