WO2013147193A1 - ネットワークアプライアンス冗長化システム、制御装置、ネットワークアプライアンス冗長化方法及びプログラム - Google Patents

ネットワークアプライアンス冗長化システム、制御装置、ネットワークアプライアンス冗長化方法及びプログラム Download PDF

Info

Publication number
WO2013147193A1
WO2013147193A1 PCT/JP2013/059605 JP2013059605W WO2013147193A1 WO 2013147193 A1 WO2013147193 A1 WO 2013147193A1 JP 2013059605 W JP2013059605 W JP 2013059605W WO 2013147193 A1 WO2013147193 A1 WO 2013147193A1
Authority
WO
WIPO (PCT)
Prior art keywords
switch
header
packet
network appliance
control device
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.)
Ceased
Application number
PCT/JP2013/059605
Other languages
English (en)
French (fr)
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.)
NEC Corp
Original Assignee
NEC Corp
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 NEC Corp filed Critical NEC Corp
Priority to US14/389,337 priority Critical patent/US9401865B2/en
Priority to JP2014508106A priority patent/JP5861772B2/ja
Priority to CN201380017998.XA priority patent/CN104247342A/zh
Priority to EP13767523.7A priority patent/EP2833583A4/en
Publication of WO2013147193A1 publication Critical patent/WO2013147193A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

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/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/403—Bus networks with centralised control, e.g. polling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/30—Peripheral units, e.g. input or output ports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/55—Prevention, detection or correction of errors
    • H04L49/552—Prevention, detection or correction of errors by ensuring the integrity of packets received through redundant connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • 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/28—Routing or path finding of packets in data switching networks using route fault recovery
    • 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/72—Routing based on the source address
    • 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]

Definitions

  • the present invention is based on the priority claim of Japanese patent application: Japanese Patent Application No. 2012-079953 (filed on March 30, 2012), the entire description of which is incorporated herein by reference. Shall.
  • the present invention relates to a network appliance redundancy system, a control device, a network appliance redundancy method, and a program, and in particular, a network appliance redundancy system, a control device, and a network appliance redundancy method in which two different types of network appliances are arranged. And the program.
  • Patent Document 1 discloses a configuration in which a master router and a backup router are arranged in parallel. According to the publication, a packet is duplicated at the shared hub in front of the routers arranged in parallel, sent to both the master router and the backup router, the master router forwards the packet, and the backup router discards the packet. It is described that the state can be synchronized without performing communication between the master router and the backup router.
  • Patent Document 2 a packet is duplicated in the apparatus, transferred to both the active and standby path control modules to execute the path control process, and from the reception of the internal control packet from the standby system module, A packet transfer apparatus having a mechanism for determining a module state is disclosed.
  • Non-Patent Document 1 proposes a method in which the overhead of state exchange can be reduced by duplicating packets to make the state redundant.
  • Non-Patent Documents 2 and 3 are documents related to a centralized control type network called OpenFlow.
  • JP 2007-208502 A JP-A-2005-303501
  • packet headers such as NAT (Network Address Translation), NAPT (Network Address Port Translation), and LB (Load Balancer) (hereinafter referred to as “header conversion”).
  • appliance appliance switching
  • SBY standby system
  • the failover is such that those sessions can continue.
  • post-conversion headers the conversion results of the headers (hereinafter referred to as “post-conversion headers”) performed by these appliances differ from device to device, so it is necessary to exchange and share conversion information between ACT and SBY. This is because the sharing method differs for each manufacturer or device. As a result, this restriction impairs the flexibility of network configuration and physical resource allocation.
  • Patent Documents 1 and 2 and Non-Patent Document 1 each require modification of the router, and there is a problem that what is sold by each vendor cannot be used as it is.
  • An object of the present invention is to provide a network appliance redundancy system, a control device, a network appliance redundancy method, and a program that can contribute to realizing a stateful failover using two different types of network appliances.
  • the first switch arranged in the front stage of the two different types of network appliances operated by switching between the active system and the standby system, and the latter stage of the two different types of network appliances.
  • a second switch to be arranged; header information of a packet transmitted from the first switch; and header information of a packet received by the second switch via the active network appliance.
  • a conversion rule management unit that learns a header conversion rule by the active network appliance, and when switching to the backup network appliance, based on the header conversion rule, the second switch Output packets similar to those of the current network appliance Yo and a control device which instructs the header rewriting, a network appliance redundant system including provided.
  • the first switch arranged in the front stage of the two different types of network appliances operated by switching between the active system and the standby system, and the rear stage of the two different types of network appliances. And a header of a packet received by the second switch via the working network appliance and connected to the second switch arranged and transmitted from the first switch. And a conversion rule management unit that learns a header conversion rule by the active network appliance based on the information, and when switching to the backup network appliance, the second The same output as the current network appliance Control device is provided for indicating a header rewriting to the socket.
  • the first switch disposed in the front stage of the two different types of network appliances operated by switching between the active system and the standby system, and the second stage of the network appliances of the two different models.
  • the second switch to be arranged and the connected control device receive the header information of the packet transmitted from the first switch and the second switch via the working network appliance. Learning the header conversion rule by the active network appliance based on the header information of the packet, and when switching from the active network appliance to the standby network appliance, the header conversion rule Based on the first switch with respect to the second switch.
  • a control unit and a step of instructing the same header rewriting and pitch, network appliances redundancy method comprising is provided. The method is tied to a specific machine, the control device that controls the switch.
  • the first switch disposed in the front stage of the two different types of network appliances operated by switching between the active system and the standby system, and the second stage of the network appliances of the two different models.
  • a second switch arranged, and a computer mounted on a connected control device, the header information of the packet transmitted from the first switch, and the second network via the working network appliance.
  • the process of learning the header conversion rule by the active network appliance, and when switching from the active network appliance to the standby network appliance Based on the header conversion rule, the second switch.
  • Program for executing the processing for instructing the same header rewriting said first switch is provided to.
  • This program can be recorded on a computer-readable (non-transient) storage medium. That is, the present invention can be embodied as a computer program product.
  • a redundant configuration using two different types of network appliances can contribute to the realization of stateful failover.
  • FIG. 2 It is a figure which shows the structure of one Embodiment of this invention. It is a figure which shows the structure of the network appliance redundancy system of the 1st Embodiment of this invention.
  • 3 is a correspondence table between MAC addresses and IP addresses of the respective devices in FIG. 2. It is an example of the redundant structure management table hold
  • FIG. 6 is a sequence diagram showing a series of operations (from ARP to ARP response of CL1) of the first exemplary embodiment of the present invention.
  • FIG. 5 is a sequence diagram illustrating a series of operations (from CL1 packet transmission to SV1 arrival) according to the first exemplary embodiment of the present invention.
  • FIG. 5 is a sequence diagram illustrating a series of operations (from SV1 ARP to ARP response) according to the first exemplary embodiment of the present invention.
  • FIG. 5 is a sequence diagram illustrating a series of operations (from SV1 packet transmission to CL1 arrival) according to the first exemplary embodiment of the present invention.
  • It is a flowchart showing the operation
  • the first switch 30 is arranged in front of two different types of network appliances 20 and 21 that are operated by switching between the active system and the standby system. And a second switch 31 arranged at the subsequent stage of the two different types of network appliances 20 and 21, and a control device 40 for controlling the first and second switches 30 and 31. it can.
  • control device 40 includes the header information of the packet transmitted from the first switch 30 and the header information of the packet received by the second switch 31 via the active network appliance. And a conversion rule management unit that learns a header conversion rule by the active network appliance 20. Then, when the control device 40 is switched from the active system to the standby network appliance 21, an output packet similar to that of the active network appliance 20 is sent to the second switch 31 based on the header conversion rule. The header rewrite is instructed so that
  • FIG. 2 is a diagram showing a configuration of the network appliance redundancy system according to the first embodiment of this invention.
  • appliances (AP) 120 and 121 arranged in parallel, a first switch 110 arranged in front of these APs 120 and 121, and a second switch 111 arranged in the subsequent stage of these APs 120 and 121.
  • a control device 140 that controls the first and second switches 110 and 111 are shown.
  • the client CL1 is connected to the port p0 of the first switch 110.
  • An appliance (AP) 120 operating in the active system in the initial state is connected to the port p1 of the first switch 110, and an appliance (AP) 121 operating in the standby system in the initial state is connected to the port p2. .
  • the appliance (AP1) 120 operating in the active system in the initial state is connected to the port p1 of the second switch 111, and the appliance (AP2) 121 operating in the standby system in the initial state is connected to the port p2.
  • the servers SV1 to SV3 are connected to the port p0 of the second switch 111 via the switch 112.
  • the appliances (AP) 120 and 121 each have a NAT table (corresponding to an address conversion table) inside.
  • the control device 140 has a function of learning a relationship between a MAC (Media Access Control) address and a port and a function of learning a relationship between an IP (Internet Protocol) address and a MAC address as shown in FIG.
  • a path control unit 141 having a function of setting a flow entry (control information) and a conversion rule management unit 142.
  • the conversion rule management unit 142 of the control device 140 includes a redundant configuration management table for managing the configuration and state of the redundant appliances, and header conversion contents that each system that forms the redundant configuration performs in units of flows. It holds a header conversion table for management.
  • the conversion rule management unit 142 of the control device 140 refers to the header conversion table when the active appliance 121 is switched to the standby appliance 121 and refers to the second switch 111 arranged at the subsequent stage of these appliances. The header rewriting is instructed so that the output packet is the same as that of the system appliance 120.
  • FIG. 4 is an example of a redundant configuration management table held in the conversion rule management unit 142.
  • the appliance and switch connection information (sw1 is the first information) that is set in the redundant configuration in association with the cluster ID (hereinafter referred to as “CLID”) for identifying the appliance having the redundant configuration.
  • CLID cluster ID
  • the switch ID, sw2 indicates the ID of the second switch.
  • the information of the system operating as the active system, the type information of the appliance, and the header before conversion after the header conversion rules for both ACT and SBY are prepared.
  • the continuation flag indicating whether to continue the process to be assigned and the header before conversion, it is possible to store a key field for managing a field to be a key necessary for regarding a certain packet sequence as the same flow.
  • FIG. 5 is an example of a header conversion table held in the conversion rule management unit 142.
  • the header information before conversion that is, the header information of the packet transmitted from the first switch 110 obtained via the second switch 111) in association with the CLID, and the appliances 120 and 121
  • Each converted header information after conversion that is, header information of a packet received by the second switch 111) can be stored.
  • dl_type indicates a higher layer protocol type
  • dl_src indicates a source MAC address
  • dl_dst indicates a destination MAC address
  • Nw_src indicates a transmission source IP address
  • nw_dst indicates a transmission destination IP address.
  • tp_src indicates a transmission source L4 port number
  • tp_dst indicates a transmission destination L4 port number.
  • the first and second switches 110 and 111 include packet processing units 130 and 131 that operate according to the flow entry (control information) set from the path control unit 141 of the control device 140 described above.
  • the first and second switches 110 and 111 each include a control information storage unit (not shown) that stores a flow entry (control information).
  • FIG. 6 is an example of a flow entry (control information) set in the first switch 110.
  • the flow entry (the value of the No. field is larger) stored in the upper level is handled as a flow entry with a higher priority.
  • the flow entry (control information) is configured in association with a match condition (match) for identifying a flow and an action (action) to be performed on the flow.
  • the flow entry 103 receives an IP packet from port p1, that is, from the appliance 120, the source IP address is VIP_L (virtual IP address on the input side of the appliance) and the destination IP address is IP_CL1 (IP address of the client CL1). This indicates that the data should be transferred to the port p0, that is, the client CL1.
  • “*” in FIG. 6 indicates a wild card. For example, in FIG. “*” Is set for all the flow entries of 0. For this reason, when the first switch 110 receives a packet having a header that does not match any of the upper flow entries, the first switch 110 transmits the packet to the control device 140. When the path control unit 141 of the control device 140 receives the packet, it analyzes the contents, performs path calculation, etc., and assigns an appropriate flow entry to the first switch 110 (also to the second switch 112 if necessary). Set to.
  • FIG. 7 is an example of a flow entry (control information) set in the second switch 111.
  • the flow entry 104 is an IP packet from the port p0, that is, a packet whose source IP address is VIP_L (virtual IP address on the input side of the appliance) and whose destination IP address is IP_CL1 (IP address of the client CL1).
  • VIP_L virtual IP address on the input side of the appliance
  • IP_CL1 IP address of the client CL1
  • the header before conversion is added by the first switch 110, and the flow entry transferred to the switch 111 after removing the header before conversion for the packet that has passed through the appliance 120. Is set (see the flow entry No. 101).
  • a flow entry instructing discarding is set for the packet that has been added with the pre-conversion header by the first switch 110 and has passed through the standby appliance 121 (see No. 100 flow entry). 7 also includes flow entries in which all wildcards “*” are set, as in FIG. 6 (see No. 0 flow entry). For this reason, when the second switch 111 also receives a packet having a header that does not match any of the upper flow entries, the second switch 111 transmits the packet to the control device 140.
  • the packet processing units 130 and l31 as described above may be implemented as a program that operates on a CPU (Central Processing Unit) on each switch 110 or 111, or may be realized as an ASIC (Application Specific Integrated Circuit) that performs specific processing. You can also Further, since the basic operation is the same as that of the open flow switch of Non-Patent Documents 1 and 2, a switch configured according to the specification of Non-Patent Document 2 can be used.
  • a switch configured according to the specification of Non-Patent Document 2 can be used.
  • the first method is a method of encapsulating a packet header with the same packet header as shown in FIG.
  • a flag indicating that the pre-conversion header is added is provided in the option field (Options) of the IP header. .
  • the second method is a method of storing the header in the option field (Options) of the IP header as shown in FIG. Also in the example of FIG. 9, a grant flag for identifying whether or not a pre-conversion header is given is provided. 8 and 9, the option field (Options) of the IP header is used, but the option field (Options) of the TCP header may be used. In the examples of FIGS. 8 and 9, the headers L2 to L4 are stored. However, it is not necessary to store all the headers, and only necessary fields in the headers may be stored.
  • FIG. 10 is a flowchart showing the operation (initial setting) of the first exemplary embodiment of the present invention.
  • the first switch 110 is referred to as a front switch
  • the second switch 111 is referred to as a rear switch.
  • the operator enters a cluster ID (CLID) in the redundant configuration management table, connection information between the appliances for which the redundant configuration is set and the upstream and downstream switches, information on the system operating as the active system, and appliance type. Information, a continuation flag, and a key field are registered (step S100).
  • CLID cluster ID
  • connection information between the appliances for which the redundant configuration is set and the upstream and downstream switches information on the system operating as the active system
  • appliance type information on the system operating as the active system
  • a continuation flag, and a key field are registered (step S100).
  • the continuation flag and key field may be entered manually or automatically.
  • the appliance type is Half-NAT (DNAT)
  • the system may automatically determine that the continuation flag is No and the key field is nw_src.
  • the continuation flag must be set to Yes whenever flow information cannot be uniquely identified before and after the appliance due to packet header conversion performed by the appliance.
  • the appliance type is Full-NAT instead of Half-NAT as shown in FIG. 4
  • the source IP address and the destination IP address are converted, so that the flow cannot be identified before and after the appliance. .
  • the continuation flag Yes the pre-conversion header information is added by the preceding switch (first switch 110) and the pre-conversion header information is removed by the succeeding switch (second switch 111).
  • control device can identify the flow.
  • the key fields are nw_src and nw_dst, and in the case of NAPT, tp_src and tp_dst are added to the conditions.
  • the control device 140 instructs the packet processing unit 130 to stop adding the pre-conversion header when both the ACT and SBY post-conversion header information are prepared in the header conversion table. (Deletion of the flow entry of No. 102 in FIG. 6 may be instructed.)
  • the pre-switch first switch 110
  • the pre-assignment flag see FIGS. 8 and 9
  • the post-switch second switch 111
  • the control device 140 discards the packet from the SBY in the flow table of the upstream switch (first switch 110) based on the information. No. Set to 1. Further, the control device 140 discards the ARP packet from the SBY in the flow table of the subsequent switch (second switch 111). 1 is set.
  • the front and rear switch No. Assume that the flow entry of 0 is set when the control device and these switches are connected.
  • Packet transfer 11 to 14 are sequence diagrams showing a series of operations according to the first embodiment of the present invention.
  • the client CL1 transmits an ARP request packet addressed to VIP_L (virtual IP address on the input side of the appliance) at the start of communication (step s11).
  • VIP_L virtual IP address on the input side of the appliance
  • the pre-stage switch searches the flow table in the packet processing unit 130 (hereinafter simply referred to as “flow table”) for an entry having a matching condition that matches the received ARP request packet.
  • flow table the packet processing unit 130
  • the upstream switch transfers the ARP packet to the control device 140 according to the action (hereinafter, packet transfer processing from the switch to the control device (the flow entry The setting request process) is referred to as “packet-in”) (step s12).
  • the control device 140 determines that the packet is an ARP request for the VIP_L of the appliance, and sends a flow entry that transmits the ARP packet to the AP 120 and the AP 121 (first switch) Switch 110).
  • flow entries are set.
  • the control device 140 sends a packet transmission request to the appliances AP120 and AP121 from the ports p1 and p2 of the upstream switch (first switch 110), respectively, and causes the upstream switch (first switch 110) to transmit a packet (hereinafter, referred to as “switching”). This process is called “packet out”) (step s13).
  • Appliance AP 120, AP 121 receives the ARP packet and returns the MAC address for VIP_L as an ARP response packet (step s14).
  • the pre-stage switch (first switch 110) sends the ARP response received from the AP 121 to No. 1 in FIG. Discard according to the flow entry 1 (step s15).
  • the upstream switch (first switch 110) sends the ARP response received from the AP 120 to No. 1 in FIG. According to the flow entry of 0, it is transmitted to the control device 140 (step s16).
  • the path control unit 141 of the control device 140 determines that the received packet is an ARP response from the appliance, and sets a flow entry that is output to the port of the upstream switch (first switch 110) that is the transmission destination.
  • the transmission destination is CL1
  • the output destination port is p0. 101 flow entries are set.
  • the control device 140 packet-outs from the port p0 of the preceding switch (first switch 110) (step s17).
  • the client CL1 receives the ARP response (step s18).
  • the client CL1 Upon receiving the ARP response, the client CL1 transmits an IP packet to VIP_L as shown in FIG. 12 (step s19).
  • Pre-stage switch (first switch 110) is No. According to the flow entry of 0, the received IP packet is transmitted to the control device 140 (step s20).
  • the control device 140 determines that the received packet is an IP packet to the appliance, adds a pre-conversion header, converts the destination MAC address for each appliance, and transmits a flow entry that is transmitted to the AP 120 and the AP 121 to the upstream switch. Set to (first switch 110). Further, the control device 140 adds a pre-conversion header to the packet to the upstream switch (first switch 110), and causes the packet to be output from the ports p1 and p2 (step s21). Since the continuation flag in the redundant configuration management table is Yes, No. in FIG. Like the flow entry 102, a flow entry for adding a pre-conversion header adding process to the action is set. Since the continuation flag is Yes, the grant flag in the IP header is not used.
  • Appliance AP120 and AP121 each convert and output the received packet based on its own NAT table (step s22).
  • the post-stage switch (second switch 111) searches the flow table in the packet processing unit 131 for an entry having a matching condition that matches the received packet.
  • the subsequent switch (second switch 111) transfers the received packet to the control device 140 according to the action (steps s23a and s23s).
  • the control device 140 refers to the redundant configuration management table and determines from the input port information (import) of the received packet whether the received packet from the subsequent switch (second switch 111) is from ACT or SBY. Based on this, an entry of the header conversion table is registered.
  • control device 140 When the control device 140 registers an entry in the header conversion table with the received packet from the ACT, the control device 140 sets a flow entry that causes the subsequent switch (second switch 111) to output the subsequent packet from the port p0. At this time, if the continuation flag in the redundant configuration management table is Yes, the control device 140 determines that the No. in FIG. As shown in the flow entry 101, a pre-conversion header removal action is added. Thereafter, the control device 140 removes the pre-conversion header and causes the subsequent switch (second switch 111) to packet out from the port p0 (step s24a).
  • control device 140 sets a flow entry for discarding the subsequent packet and discards the packet (step s24s).
  • the packet transferred via the AP 120 is received by SV1 (step s25a).
  • the SV 1 that has received the packet transmits an ARP request packet to the VIP_R, which is the default GW, when transmitting a response packet to the IP_CL 1 (step s30).
  • the post-stage switch (second switch 111) searches the flow table in the packet processing unit 131 for an entry having a matching condition that matches the received ARP packet.
  • the subsequent switch (second switch 111) transfers the ARP packet to the control device 140 according to the action (step s31).
  • the control device 140 determines that the packet is an ARP request for the VIP_R of the appliance, and sends a flow entry that transmits the ARP packet to the AP 120 and the AP 121 (second switch). Switch 111). Here, in FIG. 102 flow entries are set. Subsequently, the control device 140 causes the appliances AP120 and AP121 to transmit packets from the ports p1 and p2 of the subsequent switch (second switch 111) (step s32).
  • Appliance AP 120, AP 121 receives the ARP packet and returns the MAC address for VIP_R as an ARP response packet (step s33).
  • the subsequent switch (second switch 111) sends the ARP response received from the AP 121 to No. 1 in FIG. Discard according to the flow entry of 1 (step s34).
  • the post-stage switch (second switch 111) sends the ARP response received from the AP 120 to No. 1 in FIG. According to the flow entry of 0, it transmits to the control apparatus 140 (step s35).
  • the path control unit 141 of the control device 140 determines that the received packet is an ARP response from the appliance to the SV1, and sets a flow entry that is output to the port of the subsequent switch (second switch 111) serving as the transmission destination. .
  • the output destination port is p0. 103 flow entries are set.
  • the control device 140 packet-outs from the port p0 of the subsequent switch (second switch 111) (step s36).
  • SV1 receives the ARP response.
  • the SV 1 that has received the ARP response transmits an IP packet to VIP_R as shown in FIG. 14 (step s37).
  • the rear switch (second switch 111) is No. According to the flow entry of 0, the received IP packet is transmitted to the control device 140 (step s38).
  • the control device 140 determines that the received packet is an IP packet to CL1, converts the destination MAC address (dl_dst) to transmit the IP packet to the AP 120, and converts the destination MAC address (dl_dst) to transmit to the AP 121.
  • the flow entry is set so that the source MAC address (dl_src) and the source IP address (nw_src) are converted and transmitted.
  • flow entries are set.
  • the control device 140 causes the subsequent switch (second switch 111) to perform the same process on the received packet, and then packet-outs from the ports p1 and p2 (step s39).
  • the reason for performing the conversion at the time of transmission to the AP 121 is that it is necessary to show it as a return packet from the SV 2 with which the AP 121 communicated. Such information can be acquired from the route control unit 141.
  • Appliances AP120 and AP121 each receive an IP packet, convert the packet header based on its own NAT table, and output the packet header to the upstream switch (first switch 110) (step s40).
  • the pre-stage switch searches the flow table in the packet processing unit 130 for an entry having a matching condition that matches the received packet.
  • the packet from the AP 121 is No. in FIG. Discarded according to the flow entry of 1 (step s41).
  • the packet from AP 120 is No. in FIG. According to the flow entry of 0, it is transferred to the control device 140 (step s42).
  • the control device 140 determines that the received packet is a return packet from the AP 120, and sets a flow entry for outputting the packet from the output port p0 in the upstream switch (first switch 110). Here, in FIG. 103 flow entries are set. The control device 140 instructs the upstream switch (first switch 110) to packet out (step s43).
  • the response packet transferred via the AP 120 is received by CL1 (step s44).
  • FIG. 15 is a flowchart showing the operation (NAT table conversion) of the first exemplary embodiment of the present invention.
  • the header of the packet that has passed through those appliances is the No. of the upstream switch (first switch 110) or the downstream switch (second switch 111). It is captured by a flow entry of 0 and transmitted to the control device 140.
  • the NAT table of the AP 120 of the system 1 that is the current ACT is updated, and nw_dst is rewritten from IP_SV1 to IP_SV3.
  • the packet is transmitted to the control device 140 (step S201).
  • the control device 140 refers to the redundant configuration management table and identifies which appliance the received packet is output from.
  • the SWID of the subsequent switch is sw2
  • the input port information (import) is p1
  • the entry with the CLID of 1 in the redundant configuration management table is applicable.
  • the key field information of this entry is nw_src
  • the value of the nw_src field in the header of the received packet is IP_CL1. From these results, the control device 140 confirms the No. of the header conversion table. 1 entry is specified. Next, the control device 140 determines the No. of the header conversion table.
  • nw_dst is rewritten to IP_SV3 acquired from the header of the received packet (step S202).
  • nw_dst which is the reverse of nw_src, is the key information. Since the continuation flag is Yes, the header conversion table entry may be specified based on the pre-conversion header.
  • the control device 140 rewrites the flow entry of the subsequent switch (second switch 111) based on the information before and after rewriting the post-conversion header of the system 1.
  • the match condition nw_dst of the flow entry is rewritten from IP_SV1 to IP_SV3.
  • nw_src of the match condition of the flow entry 104 is rewritten from IP_SV1 to IP_SV3.
  • the control device 140 causes the subsequent switch (second switch 111) to packet out from the port p0 (step S203).
  • the control device 140 refers to the redundant configuration management table from the received notification, refers to the entry whose CLID is 1, changes the current ACT (active system) to the system 2, and connects the connection port and key field information of the system 1 Nw_src is obtained.
  • the control device 140 refers to the header conversion table, and obtains a list of nw_src having a CLID of 1 and an active system field of system 1.
  • the header conversion table No. 1 entry corresponds.
  • FIG. 16 is a diagram showing the updated redundant configuration management table, and the broken lines indicate the changed locations.
  • the control device 140 discards the ARP packet for the connection port p2 of the system 2 that was the previous SBY No.
  • the input port information (import) of the match condition is changed to the connection port p1 of the new SBY.
  • the input port information (import) of the match condition is changed to the connection port p2 of the new ACT.
  • the rear-stage switch (second switch 111) transfers the communication packet with the AP 121 that is the new ACT (while converting the packet header), and discards the communication packet of the AP 120 that is the previous ACT.
  • FIG. 18 is a diagram showing a flow entry of the post-update switch (second switch 111) after the update, and a broken line shows a changed part.
  • the control device 140 rewrites related ones of the flow entries of the upstream switch (first switch 110) (see FIG. 7). Specifically, the control device 140 transfers the ARP packet No. for transferring the ARP packet with respect to the connection port p1 of the system 1 that was the former ACT. For the flow entry 101, the input port information (import) of the match condition is changed to the connection port p2 of the new ACT. Next, the control device 140 discards the ARP packet for the connection port p2 of the system 2 that has been SBY. For one flow entry, the input port information (import) of the match condition is changed to the connection port p1 of the new SBY. Furthermore, the control device 140 transfers the reply packet from the previous ACT to CL1. For the flow entry 103, the input port information (import) of the match condition is changed to p2.
  • FIG. 17 is a diagram showing the flow entry of the previous-stage switch (first switch 110) after the update, and the broken line shows the changed part.
  • the upstream switch (first switch 110) transfers the communication packet with the new ACT AP 121 (while converting the packet header), and discards the communication packet of the previous ACT AP 120.
  • the difference in header conversion between the AP 120 system and the AP 121 system is absorbed by the post-stage switch (second switch 111).
  • the post-stage switch (second switch 111) As a result, even if the ACT and SBY appliances are different models, stateful failover can be realized.
  • the appliance to be made redundant is sandwiched between the front switch (first switch 110) and the rear switch (second switch 111), stateful failover between different models can be realized. The degree of freedom is increased and the flexibility of physical resource allocation is improved.
  • the present invention is not limited to the above-described embodiments, and further modifications, substitutions, and adjustments may be made without departing from the basic technical idea of the present invention. Can be added.
  • the client CL1 is connected to the upstream switch (first switch 110), and the servers SV1 to SV3 are connected to the downstream switch (second switch 111) via the switch 112.
  • first switch 110 the upstream switch
  • second switch 111 the downstream switch
  • Control device 110 First switch 111 Second switch 112 Switch 120, 121 Appliance (AP) 130, 131 Packet processing unit 140 Control device 141 Route control unit 142 Conversion rule management unit p0, p1, p2 Port CL1 Client SV1 to SV3 server

Landscapes

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

Description

ネットワークアプライアンス冗長化システム、制御装置、ネットワークアプライアンス冗長化方法及びプログラム
　［関連出願についての記載］
　本発明は、日本国特許出願：特願２０１２－０７９９５３号（２０１２年　３月３０日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
　本発明は、ネットワークアプライアンス冗長化システム、制御装置、ネットワークアプライアンス冗長化方法及びプログラムに関し、特に、２つの異なる機種のネットワークアプライアンスが配置されているネットワークアプライアンス冗長化システム、制御装置、ネットワークアプライアンス冗長化方法及びプログラムに関する。
　特許文献１にマスタルータとバックアップルータを並列に配置した構成が開示されている。同公報によると、並列に配置したルータの前段のシェアードハブにてパケットを複製し、マスタルータとバックアップルータの両方に送信し、マスタルータがパケットを転送し、バックアップルータがパケットを廃棄することで、マスタルータとバックアップルータ間で通信を行うことなく状態を同期できると記載されている。
　特許文献２には、装置内でパケットを複製し、現用系と待機系の双方の経路制御モジュールに転送して経路制御処理を実行させ、待機系モジュールからの内部制御パケットの受信から、待機系モジュールの状態を判定する仕組みを持ったパケット転送装置が開示されている。
　非特許文献１には、パケットを二重処理して状態を冗長化することにより、状態交換のオーバーヘッドを低減できるようにした方式が提案されている。
　非特許文献２、３は、オープンフローと呼ばれる集中制御型のネットワークに関する文献である。
特開２００７－２０８５０２号公報 特開２００５－３０３５０１号公報
狩野秀一、鈴木一哉、地引昌弘、「ルータクラスタにおける二重パケット処理冗長方式（インターネット及び一般）」、電子情報通信学会技術研究報告、ＩＡ、インターネットアーキテクチャ、１０４（３７７）、２１-２６、２００４－１０－２１ Ｎｉｃｋ　ＭｃＫｅｏｗｎほか７名、"ＯｐｅｎＦｌｏｗ：　Ｅｎａｂｌｉｎｇ　Ｉｎｎｏｖａｔｉｏｎ　ｉｎ　Ｃａｍｐｕｓ　Ｎｅｔｗｏｒｋｓ"、［ｏｎｌｉｎｅ］、［平成２４（２０１２）年２月１４日検索］、インターネット〈URL: http://www.openflow.org/documents/openflow-wp-latest.pdf〉 "ＯｐｅｎＦｌｏｗ　Ｓｗｉｔｃｈ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ"　Ｖｅｒｓｉｏｎ　１．１．０　Ｉｍｐｌｅｍｅｎｔｅｄ　（Ｗｉｒｅ　Ｐｒｏｔｏｃｏｌ　０ｘ０２）、［ｏｎｌｉｎｅ］、［平成２４（２０１２）年２月１４日検索］、インターネット〈URL:http://www.openflow.org/documents/openflow-spec-v1.1.0.pdf〉
　以下の分析は、本発明によって与えられたものである。複数の仮想ネットワークで物理ネットワーク資源を共有している場合、１つのネットワークの故障が複数の仮想ネットワークに影響を与えてしまう。このような事態に備え、通常はあらゆるネットワーク機器を現用系と予備系の２つ以上の系を用意し冗長化を行っておく必要がある。
　しかしながら、ＮＡＴ（Ｎｅｔｗｏｒｋ　Ａｄｄｒｅｓｓ　Ｔｒａｎｓｌａｔｉｏｎ）やＮＡＰＴ（Ｎｅｔｗｏｒｋ　Ａｄｄｒｅｓｓ　Ｐｏｒｔ　Ｔｒａｎｓｌａｔｉｏｎ）、ＬＢ（Ｌｏａｄ　Ｂａｌａｎｃｅｒ）といった、パケットヘッダ（以降、単に「ヘッダ」と称する）の変換（以降、「ヘッダ変換」と称する。）を伴うネットワークアプライアンス（以降、単に「アプライアンス」または「ＡＰ」と称する。）を冗長化する場合、サービスによっては、ステートフルなフェールオーバを実現する必要がある。ここで、ステートフルなフェールオーバとは、セッションが存在するうちに現用系（または、「ＡＣＴ」と称する。逆に、予備系は、「ＳＢＹ」と称する。）なアプライアンスの切り替え（以降、「系切り替え」と称する）が発生しても、それらのセッションが継続できるようなフェールオーバである。その場合、ユーザはステートフルな冗長化機能を持った同機種のアプライアンスを２台以上用意し、かつ、それらを密に接続しなければならない。その理由は、これらのアプライアンスが行うヘッダの変換結果（以降、「変換後ヘッダ」と称する。）が、装置ごとに異なるため、ＡＣＴとＳＢＹで変換情報を交換して共有する必要があり、その共有手法がメーカや装置毎に異なるからである。結果、この制約がネットワーク構成や物理資源の割り当ての柔軟性を損なうことになってしまう。
　この点、特許文献１、２及び非特許文献１の技術では、それぞれルータの改造が必要であり、各ベンダで販売されているものをそのまま用いることができないという問題点がある。
　本発明の目的は、２つの異なる機種のネットワークアプライアンスを用いたステートフルなフェールオーバの実現に貢献することのできるネットワークアプライアンス冗長化システム、制御装置、ネットワークアプライアンス冗長化方法及びプログラムを提供することにある。
　第１の視点によれば、現用系と予備系とに切り替えて運用される２つの異なる機種のネットワークアプライアンスの前段に配置される第１のスイッチと、前記２つの異なる機種のネットワークアプライアンスの後段に配置される第２のスイッチと、前記第１のスイッチから送信されたパケットのヘッダ情報と、前記現用系のネットワークアプライアンスを経由して前記第２のスイッチにて受信したパケットのヘッダ情報と、に基づいて、前記現用系のネットワークアプライアンスによるヘッダ変換ルールを学習する変換ルール管理部を備え、前記予備系のネットワークアプライアンスに切り替わった際に、前記ヘッダ変換ルールに基づいて、前記第２のスイッチに対し、前記現用系のネットワークアプライアンスと同様の出力パケットとなるようヘッダ書き換えを指示する制御装置と、を含むネットワークアプライアンス冗長化システムが提供される。
　第２の視点によれば、現用系と予備系とに切り替えて運用される２つの異なる機種のネットワークアプライアンスの前段に配置される第１のスイッチと、前記２つの異なる機種のネットワークアプライアンスの後段に配置される第２のスイッチと、に接続され、前記第１のスイッチから送信されたパケットのヘッダ情報と、前記現用系のネットワークアプライアンスを経由して前記第２のスイッチにて受信したパケットのヘッダ情報と、に基づいて、前記現用系のネットワークアプライアンスによるヘッダ変換ルールを学習する変換ルール管理部を備え、前記予備系のネットワークアプライアンスに切り替わった際に、前記ヘッダ変換ルールに基づいて、前記第２のスイッチに対し、前記現用系のネットワークアプライアンスと同様の出力パケットとなるようヘッダ書き換えを指示する制御装置が提供される。
　第３の視点によれば、現用系と予備系とに切り替えて運用される２つの異なる機種のネットワークアプライアンスの前段に配置される第１のスイッチと、前記２つの異なる機種のネットワークアプライアンスの後段に配置される第２のスイッチと、接続された制御装置が、前記第１のスイッチから送信されたパケットのヘッダ情報と、前記現用系のネットワークアプライアンスを経由して前記第２のスイッチにて受信したパケットのヘッダ情報と、に基づいて、前記現用系のネットワークアプライアンスによるヘッダ変換ルールを学習するステップと、前記現用系のネットワークアプライアンスから前記予備系のネットワークアプライアンスに切り替わった際に、前記ヘッダ変換ルールに基づいて、前記第２のスイッチに対し前記第１のスイッチと同様のヘッダ書き換えを指示するステップとを含む制御装置と、を含むネットワークアプライアンス冗長化方法が提供される。本方法は、スイッチを制御する制御装置という、特定の機械に結びつけられている。
　第４の視点によれば、現用系と予備系とに切り替えて運用される２つの異なる機種のネットワークアプライアンスの前段に配置される第１のスイッチと、前記２つの異なる機種のネットワークアプライアンスの後段に配置される第２のスイッチと、接続された制御装置に搭載されたコンピュータに、前記第１のスイッチから送信されたパケットのヘッダ情報と、前記現用系のネットワークアプライアンスを経由して前記第２のスイッチにて受信したパケットのヘッダ情報と、に基づいて、前記現用系のネットワークアプライアンスによるヘッダ変換ルールを学習する処理と、前記現用系のネットワークアプライアンスから前記予備系のネットワークアプライアンスに切り替わった際に、前記ヘッダ変換ルールに基づいて、前記第２のスイッチに対し前記第１のスイッチと同様のヘッダ書き換えを指示する処理とを実行させるプログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な（非トランジエントな）記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。
　本発明によれば、２つの異なる機種のネットワークアプライアンスを用いた冗長構成で、ステートフルなフェールオーバの実現に貢献することが可能となる。
本発明の一実施形態の構成を示す図である。 本発明の第１の実施形態のネットワークアプライアンス冗長化システムの構成を示す図である。 図２の各装置のＭＡＣアドレスとＩＰアドレスの対応表である。 本発明の第１の実施形態の制御装置に保持される冗長構成管理テーブルの例である。 本発明の第１の実施形態の制御装置に保持されるヘッダ変換テーブルの例である。 本発明の第１の実施形態の第１スイッチ（前段スイッチ）に設定されるフローエントリ（制御情報）の例である。 本発明の第１の実施形態の第２スイッチ（後段スイッチ）に設定されるフローエントリ（制御情報）の例である。 本発明の第１の実施形態におけるパケット変換の一例（カプセル化）である。 本発明の第１の実施形態におけるパケット変換の別の一例（ヘッダ埋め込み）である。 本発明の第１の実施形態の動作（初期設定）を表した流れ図である。 本発明の第１の実施形態の一連の動作（ＣＬ１のＡＲＰ～ＡＲＰ応答まで）を表したシーケンス図である。 本発明の第１の実施形態の一連の動作（ＣＬ１のパケット送信～ＳＶ１到達まで）を表したシーケンス図である。 本発明の第１の実施形態の一連の動作（ＳＶ１のＡＲＰ～ＡＲＰ応答まで）を表したシーケンス図である。 本発明の第１の実施形態の一連の動作（ＳＶ１のパケット送信～ＣＬ１到達まで）を表したシーケンス図である。 本発明の第１の実施形態の動作（ＮＡＴテーブル変換）を表した流れ図である。 ＡＰ２（系２）が現用系で動作している状態の冗長構成管理テーブルの例である。 ＡＰ２（系２）が現用系で動作している状態において第１スイッチ（前段スイッチ）に設定されるフローエントリ（制御情報）の例である。 ＡＰ２（系２）が現用系で動作している状態において第２スイッチ（後段スイッチ）に設定されるフローエントリ（制御情報）の例である。
　はじめに本発明の一実施形態の概要について図面を参照して説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、本発明を図示の態様に限定することを意図するものではない。
　本発明は、図１に示すように、その一実施形態において、現用系と予備系とに切り替えて運用される２つの異なる機種のネットワークアプライアンス２０、２１の前段に配置される第１のスイッチ３０と、前記２つの異なる機種のネットワークアプライアンス２０、２１の後段に配置される第２のスイッチ３１と、前記第１、第２のスイッチ３０、３１を制御する制御装置４０とを含む構成にて実現できる。
　より具体的には、制御装置４０は、第１のスイッチ３０から送信されたパケットのヘッダ情報と、前記現用系のネットワークアプライアンスを経由して第２のスイッチ３１にて受信したパケットのヘッダ情報と、に基づいて、前記現用系のネットワークアプライアンス２０によるヘッダ変換ルールを学習する変換ルール管理部を備える。そして、制御装置４０は、現用系から予備系のネットワークアプライアンス２１に切り替わった際に、前記ヘッダ変換ルールに基づいて、第２のスイッチ３１に対し、前記現用系のネットワークアプライアンス２０と同様の出力パケットとなるようヘッダ書き換えを指示する。
　以上により、異なるアプライアンス間でのステートフルなフェールオーバが実現できる。なお、上記構成によれば、アプライアンスに対する改造は不要であり、また、アプライアンス２０、２１は、それぞれ同種のヘッダ変換の機能を有していればよく、メーカや機種が異なっていてもよい。
［第１の実施形態］
　続いて、本発明の第１の実施形態について図面を参照して詳細に説明する。以下、アプライアンスとしてＨａｌｆ－ＮＡＴを行うロードバランサ（以降、「ＬＢ」と称する。）を冗長化する例を取り上げる。なお、本発明はこの実施形態に限定されるものではなく、その他ヘッダ変換を伴うアプライアンスの冗長化を行う際に適用可能である。
　図２は、本発明の第１の実施形態のネットワークアプライアンス冗長化システムの構成を示す図である。図２を参照すると、並列に配置されたアプライアンス（ＡＰ）１２０、１２１と、これらＡＰ１２０、１２１の前段に配置された第１スイッチ１１０と、これらＡＰ１２０、１２１の後段に配置された第２スイッチ１１１と、第１、第２スイッチ１１０、１１１を制御する制御装置１４０とを含む構成が示されている。
　第１スイッチ１１０のポートｐ０には、クライアントＣＬ１が接続されている。第１スイッチ１１０のポートｐ１には、初期状態において現用系で動作するアプライアンス（ＡＰ）１２０が接続され、ポートｐ２には、初期状態において予備系で動作するアプライアンス（ＡＰ）１２１が接続されている。同様に、第２スイッチ１１１のポートｐ１には、初期状態において現用系で動作するアプライアンス（ＡＰ１）１２０が接続され、ポートｐ２には、初期状態において予備系で動作するアプライアンス（ＡＰ２）１２１が接続されている。また、第２スイッチ１１１のポートｐ０には、スイッチ１１２を介して、サーバＳＶ１～ＳＶ３が接続されている。なお、アプライアンス（ＡＰ）１２０、１２１はそれぞれＮＡＴテーブル（アドレス変換テーブルに相当）を内部に持っている。
　制御装置１４０は、ＭＡＣ（Ｍｅｄｉａ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）アドレスとポートの関係を学習する機能と、図３に示すようにＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）アドレスとＭＡＣアドレスの関係を学習する機能や第１、第２スイッチにフローエントリ（制御情報）を設定する機能を持った経路制御部１４１と、変換ルール管理部１４２とを備えている。
　また、制御装置１４０の変換ルール管理部１４２は、冗長化されたアプライアンスの構成及び状態を管理するための冗長構成管理テーブルと、冗長構成を組んだ各系がフロー単位に行ったヘッダ変換内容を管理するためのヘッダ変換テーブルとを保持している。制御装置１４０の変換ルール管理部１４２は、現用系から予備系のアプライアンス１２１に切り替わった際に、前記ヘッダ変換テーブルを参照して、これらアプライアンスの後段に配置された第２スイッチ１１１に対し、現用系のアプライアンス１２０と同様の出力パケットとなるようヘッダ書き換えを指示する。
　図４は、変換ルール管理部１４２に保持されている冗長構成管理テーブルの例である。図４の例では、冗長構成を組んだアプライアンスを特定するためのクラスタＩＤ（以降、「ＣＬＩＤ」と称する。）と対応づけて、冗長構成を設定したアプライアンスとスイッチの接続情報（ｓｗ１は第１スイッチのＩＤ、ｓｗ２は第２スイッチのＩＤを示す。）、現用系として動作している系の情報、アプライアンスの種別情報、ＡＣＴとＳＢＹの両方のヘッダ変換ルールが揃った後も変換前ヘッダを付与する処理を継続するかどうかを示す継続フラグ、変換前ヘッダにおいて、あるパケット列を同じフローとみなすために必要なキーとなるフィールドを管理するキーフィールドを格納可能となっている。
　図５は、変換ルール管理部１４２に保持されているヘッダ変換テーブルの例である。図５の例では、ＣＬＩＤと対応づけて、変換前のヘッダの情報（即ち、第２スイッチ１１１経由で入手される第１スイッチ１１０から送信されたパケットのヘッダ情報）と、アプライアンス１２０、１２１でそれぞれ変換された変換後のヘッダ情報（即ち、第２スイッチ１１１が受信したパケットのヘッダ情報）とを格納可能となっている。なお、図４、図５を含む以下の説明において、ｄｌ＿ｔｙｐｅは、上位層のプロトコルタイプを示し、ｄｌ＿ｓｒｃは、送信元ＭＡＣアドレスを示し、ｄｌ＿ｄｓｔは、送信先ＭＡＣアドレスを示す。また、ｎｗ＿ｓｒｃは、送信元ＩＰアドレスを示し、ｎｗ＿ｄｓｔは、送信先ＩＰアドレスを示す。また、ｔｐ＿ｓｒｃは、送信元Ｌ４ポート番号を示す、ｔｐ＿ｄｓｔは、送信先Ｌ４ポート番号を示すものとする。
　第１、第２スイッチ１１０、１１１は、それぞれ上記した制御装置１４０の経路制御部１４１から設定されたフローエントリ（制御情報）に従って動作するパケット処理部１３０、１３１を備える。また、第１、第２スイッチ１１０、１１１は、フローエントリ（制御情報）を記憶する制御情報記憶部（図示省略）を備えている。
　図６は、第１スイッチ１１０に設定されるフローエントリ（制御情報）の例である。図６の例では、上位に格納されたフローエントリ（Ｎｏ．フィールドの値が大きい）程、優先度の高いフローエントリとして取り扱われる。フローエントリ（制御情報）は、フローを識別するマッチ条件（ｍａｔｃｈ）と、そのフローに対して行うアクション（ａｃｔｉｏｎ）と対応付けて構成される。例えば、図６のＮｏ．１０３のフローエントリは、ポートｐ１、即ち、アプライアンス１２０から送信元ＩＰアドレスがＶＩＰ＿Ｌ（アプライアンスの入力側の仮想ＩＰアドレス）、宛先ＩＰアドレスがＩＰ＿ＣＬ１（クライアントＣＬ１のＩＰアドレス）であるＩＰパケットを受信した場合、ポートｐ０、即ち、クライアントＣＬ１に転送すべきことを示している。なお、図６中の「＊」は、ワイルドカードを示している。例えば、図６のＮｏ．０のフローエントリは、すべて「＊」が設定されている。このため、第１スイッチ１１０は、上位のフローエントリのいずれにも適合しないヘッダを持つパケットを受信した場合、制御装置１４０にパケットを送信する。制御装置１４０の経路制御部１４１は、前記パケットを受信すると、その内容を解析して、経路の計算等を行って、適切なフローエントリを第１スイッチ１１０（必要なら第２スイッチ１１２にも）に設定する。
　また、図６の例では、ポートｐ０、即ち、クライアントＣＬ１から宛先ＩＰアドレスがＩＰ＿ＣＬ１（クライアントＣＬ１のＩＰアドレス）、送信元ＩＰアドレスがＩＰ＿ＳＶ１（サーバＳＶ１のＩＰアドレス）であるＩＰパケットを受信した場合、その宛先ＭＡＣアドレス等を書き換えたものを、それぞれポートｐ１、ｐ２から送信するフローエントリが設定されている（Ｎｏ．１０４のフローエントリ参照）。また、クライアントＣＬ１からＡＲＰ（Ａｄｄｒｅｓｓ　Ｒｅｓｏｌｕｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）パケットを受信した場合も、それぞれポートｐ１、ｐ２から送信するフローエントリが設定されている（Ｎｏ．１００のフローエントリ参照）。
　図７は、第２スイッチ１１１に設定されるフローエントリ（制御情報）の例である。例えば、図７のＮｏ．１０４のフローエントリは、ポートｐ０、即ち、スイッチ１１２からＩＰパケットで送信元ＩＰアドレスがＶＩＰ＿Ｌ（アプライアンスの入力側の仮想ＩＰアドレス）、宛先ＩＰアドレスがＩＰ＿ＣＬ１（クライアントＣＬ１のＩＰアドレス）であるパケットを受信した場合、それぞれヘッダの宛先ＭＡＣアドレスをアプライアンスの接続ポートのＭＡＣアドレスに書き換えた上で、ポートｐ１、ｐ２から送信するフローエントリが設定されている（Ｎｏ．１０４のフローエントリ参照；アプライアンス１２１に送信するパケットについては送信元ＭＡＣアドレス、送信元ＩＰアドレスも書き換え。）。また、図７の例では、前記のように、第１スイッチ１１０で変換前ヘッダが付加され、アプライアンス１２０を経由してきたパケットについて、変換前ヘッダを除去した上で、スイッチ１１１に転送するフローエントリが設定されている（Ｎｏ．１０１のフローエントリ参照）。一方、第１スイッチ１１０で変換前ヘッダが付加され、予備系のアプライアンス１２１を経由してきたパケットについては、廃棄を指示するフローエントリが設定されている（Ｎｏ．１００のフローエントリ参照）。また、図７にも図６と同様にすべてワイルドカード「＊」が設定されたフローエントリが設定されている（Ｎｏ．０のフローエントリ参照）。このため、第２スイッチ１１１も、上位のフローエントリのいずれにも適合しないヘッダを持つパケットを受信した場合、制御装置１４０にパケットを送信する。
　上記のようなパケット処理部１３０、ｌ３１は、各スイッチ１１０、１１１上のＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）で動作するプログラムとして実装したり、特定の処理を行うＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ　Ｓｐｅｃｉｆｉｃ　Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）として実現したりすることもできる。また、上記基本動作は、非特許文献１、２のオープンフロースイッチと同様であるので、非特許文献２の仕様に従って構成されたスイッチを用いることもできる。
　ここで、図６、図７におけるアクションとしてヘッダ付与、ヘッダ削除が設定されている場合の具体的なヘッダ付与（削除）の方法について説明する。このようなヘッダ付与（削除）の方法には、例えば、次のような方式が挙げられる。一つ目の方式は、図８のように、パケットヘッダを同じパケットヘッダでカプセル化する方式である。図８の例では、パケットに変換前ヘッダが付与されているかどうかを識別するために、ＩＰヘッダのオプションフィールド（Ｏｐｔｉｏｎｓ）に、変換前ヘッダを付加していることを示すフラグを設けられている。
　２つ目の方式は、図９のように、ＩＰヘッダのオプションフィールド（Ｏｐｔｉｏｎｓ）内に、ヘッダを格納する方式である。図９の例においても、変換前ヘッダが付与されているかどうかを識別するための付与フラグが設けられている。なお、図８、図９の例では、ＩＰヘッダのオプションフィールド（Ｏｐｔｉｏｎｓ）を利用しているが、ＴＣＰヘッダのオプションフィールド（Ｏｐｔｉｏｎｓ）を利用してもよい。また、図８、図９の例では、Ｌ２～Ｌ４のヘッダを保存しているが、すべてのヘッダを保存する必要もなく、ヘッダのうち必要なフィールドのみを保存してもよい。
　続いて、本実施形態の動作について図面を参照して詳細に説明する。
　［初期設定］
　はじめに、図２に示した制御装置１４０や第１、第２スイッチ１１０、１１１に対して行われる初期設定について説明する。図１０は、本発明の第１の実施形態の動作（初期設定）を表した流れ図である。以下、第１スイッチ１１０を前段スイッチと呼び、第２スイッチ１１１を後段スイッチと呼んで説明する。
　図１０に示すとおり、オペレータは、冗長構成管理テーブルに、クラスタＩＤ（ＣＬＩＤ）、冗長構成を設定したアプライアンスと前後段のスイッチの接続情報、現用系として動作している系の情報、アプライアンスの種別情報、継続フラグ、キーフィールドを登録する（ステップＳ１００）。
　その際に、継続フラグやキーフィールドは手動で入力するようにしてもよいし、自動入力としてもよい。例えば、アプライアンス種別がＨａｌｆ－ＮＡＴ（ＤＮＡＴ）ということから、例えば、システムが継続フラグはＮｏ、キーフィールドはｎｗ＿ｓｒｃである、というように自動的に判定してもよい。ここで、継続フラグは、アプライアンスが行うパケットヘッダの変換により、アプライアンスの前後でフロー情報が一意に識別できなくなる場合は必ずＹｅｓにする必要がある。例えば、アプライアンスの種別が図４のようにＨａｌｆ－ＮＡＴではなくＦｕｌｌ－ＮＡＴである場合、送信元ＩＰアドレスも宛先ＩＰアドレスも変換されてしまうため、アプライアンスの前後でフローの識別が不可能になる。そのような場合、継続フラグＹｅｓに設定することで、前段スイッチ（第１スイッチ１１０）での変換前ヘッダ情報の付与と、後段スイッチ（第２スイッチ１１１）での変換前ヘッダ情報の除去が継続され、制御装置がフローを識別できるようになる。なお、Ｆｕｌｌ－ＮＡＴの場合のキーフィールドはｎｗ＿ｓｒｃ、ｎｗ＿ｄｓｔとなり、ＮＡＰＴの場合はｔｐ＿ｓｒｃ、ｔｐ＿ｄｓｔも条件に加わる。
　以下、本実施形態では、オペレータが、継続フラグとしてＹｅｓ、キーフィールドをｎｗ＿ｓｒｃに手動で設定したとする。なお、継続フラグがＮｏの場合、ヘッダ変換テーブルに、ＡＣＴとＳＢＹの両方の変換後ヘッダ情報が揃った時点で、制御装置１４０は、パケット処理部１３０に変換前ヘッダの付与の停止を指示する（図６のＮｏ．１０２のフローエントリの削除を指示すればよい。）。変換前ヘッダの付与中は、前段スイッチ（第１スイッチ１１０）は前述したＩＰヘッダ内にある付与フラグ（図８、図９参照）をＯＮにしておき、後段スイッチ（第２スイッチ１１１）ではＯＮの場合に変換前ヘッダ情報を除去する処理を行う。
　次に、冗長構成管理テーブルにエントリが登録された段階で、制御装置１４０は、それらの情報をもとに、前段スイッチ（第１スイッチ１１０）のフローテーブルにＳＢＹからのパケットを廃棄するフローエントリＮｏ．１と設定する。また、制御装置１４０は、後段スイッチ（第２スイッチ１１１）のフローテーブルにＳＢＹからのＡＲＰパケットを廃棄するフローエントリＮｏ．１を設定する。なお、前後段スイッチのＮｏ．０のフローエントリは、制御装置と、これらのスイッチが接続された段階で設定されているとする。
　続いて、上記初期設定の完了後に実施可能となるパケット転送処理について説明する。
　［パケット転送］
　図１１～図１４は、本発明の第１の実施形態の一連の動作を表したシーケンス図である。図１１に示すように、クライアントＣＬ１は、通信開始に当たって、ＶＩＰ＿Ｌ（アプライアンスの入力側の仮想ＩＰアドレス）宛てにＡＲＰ要求パケットを送信する（ステップｓ１１）。
　前段スイッチ（第１スイッチ１１０）は、パケット処理部１３０内のフローテーブル（以降、単に「フローテーブル」と呼ぶ）から、受信したＡＲＰ要求パケットに適合するマッチ条件を持つエントリを検索する。ここでは、図６のＮｏ．０のフローエントリがヒットするため、前段スイッチ（第１スイッチ１１０）は、そのアクションに従って、制御装置１４０に対してＡＲＰパケットを転送する（以下、スイッチから制御装置へのパケット転送処理（フローエントリの設定要求処理）を「パケットイン」と呼ぶ。）（ステップｓ１２）。
　制御装置１４０は、冗長構成管理テーブルの接続情報と受信パケットのヘッダから、パケットがアプライアンスのＶＩＰ＿Ｌに対するＡＲＰ要求と判定し、ＡＲＰパケットをＡＰ１２０とＡＰ１２１へ送信するようなフローエントリを前段スイッチ（第１スイッチ１１０）に設定する。ここでは、図６のＮｏ．１００のフローエントリが設定される。続いて、制御装置１４０は、前段スイッチ（第１スイッチ１１０）のポートｐ１、ｐ２からそれぞれアプライアンスＡＰ１２０とＡＰ１２１にパケット送信要求を行い、前段スイッチ（第１スイッチ１１０）にパケットを送信させる（以下、この処理を「パケットアウト」と呼ぶ。）（ステップｓ１３）。
　アプライアンスＡＰ１２０、ＡＰ１２１は、ＡＲＰパケットを受け取り、ＶＩＰ＿Ｌに対するＭＡＣアドレスをＡＲＰ応答パケットで返信する（ステップｓ１４）。
　前段スイッチ（第１スイッチ１１０）は、ＡＰ１２１から受け取ったＡＲＰ応答を、図６のＮｏ．１のフローエントリに従って廃棄する（ステップｓ１５）。
　一方、前段スイッチ（第１スイッチ１１０）は、ＡＰ１２０から受け取ったＡＲＰ応答を、図６のＮｏ．０のフローエントリに従って、制御装置１４０に送信する（ステップｓ１６）。
　制御装置１４０の経路制御部１４１は、受信したパケットがアプライアンスからのＡＲＰ応答と判定し、その送信先となる前段スイッチ（第１スイッチ１１０）のポートに出力するようなフローエントリを設定する。ここでは、送信先はＣＬ１であるため、出力先ポートはｐ０となり、図６のＮｏ．１０１のフローエントリが設定される。そして、制御装置１４０は、前段スイッチ（第１スイッチ１１０）のポートｐ０からパケットアウトさせる（ステップｓ１７）。クライアントＣＬ１はＡＲＰ応答を受け取る（ステップｓ１８）。
　前記ＡＲＰ応答を受け取ったクライアントＣＬ１は、図１２に示すように、ＶＩＰ＿Ｌ宛てにＩＰパケットを送信する（ステップｓ１９）。
　前段スイッチ（第１スイッチ１１０）は、Ｎｏ．０のフローエントリに従って、制御装置１４０に対して受信したＩＰパケットを送信する（ステップｓ２０）。
　制御装置１４０は、受信したパケットがアプライアンスへのＩＰパケットと判定し、変換前ヘッダを付与し、宛先ＭＡＣアドレスをそれぞれのアプライアンス用に変換し、ＡＰ１２０とＡＰ１２１へ送信するようなフローエントリを前段スイッチ（第１スイッチ１１０）に設定する。さらに、制御装置１４０は、前段スイッチ（第１スイッチ１１０）に、パケットに対して変換前ヘッダを付与し、ポートｐ１、ｐ２からパケットアウトさせる（ステップｓ２１）。なお、冗長構成管理テーブルの継続フラグがＹｅｓのため、図６のＮｏ．１０２のフローエントリのように、アクションに変換前ヘッダ付与処理を追加するフローエントリが設定される。また、継続フラグがＹｅｓのため、ＩＰヘッダ中の付与フラグは利用しないことにする。
　アプライアンスＡＰ１２０、ＡＰ１２１は、それぞれ自身のＮＡＴテーブルに基づいて受信パケットを変換し出力する（ステップｓ２２）。
　後段スイッチ（第２スイッチ１１１）は、パケット処理部１３１内のフローテーブルから、受信したパケットに適合するマッチ条件を持つエントリを検索する。ここでは、図７のＮｏ．０のフローエントリがヒットするため、後段スイッチ（第２スイッチ１１１）は、そのアクションに従って、制御装置１４０に対して受信パケットを転送する（ステップｓ２３ａ、ｓ２３ｓ）。
　制御装置１４０は、冗長構成管理テーブルを参照し、受信パケットの入力ポート情報（ｉｎｐｏｒｔ）から、後段スイッチ（第２スイッチ１１１）からの受信パケットがＡＣＴからのものか、ＳＢＹからのものかを判定し、それに基づいて、ヘッダ変換テーブルのエントリを登録する。
　制御装置１４０は、ＡＣＴからの受信パケットでヘッダ変換テーブルにエントリを登録した場合、後段スイッチ（第２スイッチ１１１）に対し、ポートｐ０から後続パケットを出力させるフローエントリを設定する。なおこの時、冗長構成管理テーブルの継続フラグがＹｅｓの場合、制御装置１４０は、図７のＮｏ．１０１のフローエントリに示すように、変換前ヘッダの除去アクションを追加する。その後、制御装置１４０は変換前ヘッダの除去を行い、後段スイッチ（第２スイッチ１１１）にポートｐ０からパケットアウトさせる（ステップｓ２４ａ）。
　一方、ＳＢＹからの受信パケットでヘッダ変換ルールにエントリを登録した場合、制御装置１４０は、後続パケットを廃棄させるフローエントリを設定するとともに、当該パケットを廃棄する（ステップｓ２４ｓ）。
　以上の結果、ＡＰ１２０経由で転送されたパケットが、ＳＶ１にて受信される（ステップｓ２５ａ）。
　次に、前記パケットを受信したＳＶ１は、図１３に示すように、ＩＰ＿ＣＬ１への応答パケットの送信にあたり、デフォルトＧＷであるＶＩＰ＿Ｒに対してＡＲＰ要求パケットを送信する（ステップｓ３０）。
　後段スイッチ（第２スイッチ１１１）は、パケット処理部１３１内のフローテーブルから、受信したＡＲＰパケットに適合するマッチ条件を持つエントリを検索する。ここでは、図７のＮｏ．０のフローエントリがヒットするため、後段スイッチ（第２スイッチ１１１）は、そのアクションに従って、制御装置１４０に対してＡＲＰパケットを転送する（ステップｓ３１）。
　制御装置１４０は、冗長構成管理テーブルの接続情報と受信パケットのヘッダから、パケットがアプライアンスのＶＩＰ＿Ｒに対するＡＲＰ要求と判定し、ＡＲＰパケットをＡＰ１２０とＡＰ１２１へ送信するようなフローエントリを後段スイッチ（第２スイッチ１１１）に設定する。ここでは、図７のＮｏ．１０２のフローエントリが設定される。続いて、制御装置１４０は、後段スイッチ（第２スイッチ１１１）のポートｐ１、ｐ２からそれぞれアプライアンスＡＰ１２０とＡＰ１２１にパケットを送信させる（ステップｓ３２）。
　アプライアンスＡＰ１２０、ＡＰ１２１は、ＡＲＰパケットを受け取り、ＶＩＰ＿Ｒに対するＭＡＣアドレスをＡＲＰ応答パケットで返信する（ステップｓ３３）。
　後段スイッチ（第２スイッチ１１１）は、ＡＰ１２１から受け取ったＡＲＰ応答を、図７のＮｏ．１のフローエントリに従って廃棄する（ステップｓ３４）。
　一方、後段スイッチ（第２スイッチ１１１）は、ＡＰ１２０から受け取ったＡＲＰ応答を、図７のＮｏ．０のフローエントリに従って、制御装置１４０に送信する（ステップｓ３５）。
　制御装置１４０の経路制御部１４１は、受信したパケットがアプライアンスからＳＶ１へのＡＲＰ応答と判定し、その送信先となる後段スイッチ（第２スイッチ１１１）のポートに出力するようなフローエントリを設定する。ここでは、送信先はＳＶ１であるため出力先ポートはｐ０となり、図７のＮｏ．１０３のフローエントリが設定される。そして、制御装置１４０は、後段スイッチ（第２スイッチ１１１）のポートｐ０からパケットアウトさせる（ステップｓ３６）。ＳＶ１はＡＲＰ応答を受け取る。
　前記ＡＲＰ応答を受け取ったＳＶ１は、図１４に示すように、ＶＩＰ＿Ｒ宛てにＩＰパケットを送信する（ステップｓ３７）。
　後段スイッチ（第２スイッチ１１１）は、Ｎｏ．０のフローエントリに従って、制御装置１４０に対して受信したＩＰパケットを送信する（ステップｓ３８）。
　制御装置１４０は、受信したパケットがＣＬ１へのＩＰパケットと判定し、当該ＩＰパケットをＡＰ１２０へ送信するために宛先ＭＡＣアドレス（ｄｌ＿ｄｓｔ）を変換し、ＡＰ１２１へ送信するために宛先ＭＡＣアドレス（ｄｌ＿ｄｓｔ）、送信元ＭＡＣアドレス（ｄｌ＿ｓｒｃ）、送信元ＩＰアドレス（ｎｗ＿ｓｒｃ）を変換して送信するようなフローエントリを設定する。ここでは、図７のＮｏ．１０４のフローエントリが設定される。さらに、制御装置１４０は、後段スイッチ（第２スイッチ１１１）に、受信パケットに同様の処理を行った後、ポートｐ１、ｐ２からパケットアウトさせる（ステップｓ３９）。このようなＡＰ１２１への送信時の変換を行う理由は、ＡＰ１２１が通信したＳＶ２からの戻りのパケットと見せる必要があるからである。これらの情報は経路制御部１４１から取得できる。
　アプライアンスＡＰ１２０、ＡＰ１２１は、それぞれＩＰパケットを受信し、自身のＮＡＴテーブルに基づいてパケットヘッダを変換してから、前段スイッチ（第１スイッチ１１０）に出力する（ステップｓ４０）。
　前段スイッチ（第１スイッチ１１０）は、パケット処理部１３０内のフローテーブルから、受信したパケットに適合するマッチ条件を持つエントリを検索する。ＡＰ１２１からのパケットは、図６のＮｏ．１のフローエントリに従って、廃棄される（ステップｓ４１）。
　一方、ＡＰ１２０からのパケットは、図６のＮｏ．０のフローエントリに従って、制御装置１４０に転送される（ステップｓ４２）。
　制御装置１４０は、受信パケットが、ＡＰ１２０からの折り返しパケットと判定し、前段スイッチ（第１スイッチ１１０）に、出力ポートｐ０からパケットを出力するフローエントリを設定する。ここでは、図６のＮｏ．１０３のフローエントリが設定される。制御装置１４０は、前段スイッチ（第１スイッチ１１０）にパケットアウトを指示する（ステップｓ４３）。
　以上の結果、ＡＰ１２０経由で転送された応答パケットが、ＣＬ１にて受信される（ステップｓ４４）。
［ＮＡＴテーブルの更新］
　続いて、アプライアンスＡＰ１２０、ＡＰ１２１において、ＮＡＴテーブルの更新が行われた場合の処理について説明する。図１５は、本発明の第１の実施形態の動作（ＮＡＴテーブル変換）を表した流れ図である。
　ＮＡＴテーブルの更新が行われた場合、それらのアプライアンスを通過したパケットのヘッダは、前段スイッチ（第１スイッチ１１０）、もしくは、後段スイッチ（第２スイッチ１１１）のＮｏ．０のフローエントリにて捕捉され、制御装置１４０に送信されることになる。
　ここで、例として、ＣＬ１からＶＩＰ＿Ｌ宛てに送信しているパケットについて、現在ＡＣＴである系１のＡＰ１２０のＮＡＴテーブルが更新され、ｎｗ＿ｄｓｔがＩＰ＿ＳＶ１からＩＰ＿ＳＶ３に書き変わったものとして説明する。
　この場合、後段スイッチ（第２スイッチ１１１）は、新しいＮＡＴテーブルの情報に従ってヘッダ変換されたパケットを受信すると、Ｎｏ．０のフローエントリに従って、制御装置１４０に対し、当該パケットを送信する（ステップＳ２０１）。
　制御装置１４０は、冗長構成管理テーブルを参照して受信パケットがどのアプライアンスが出力したパケットかを特定する。この例では、後段スイッチ（第２スイッチ１１１）のＳＷＩＤがｓｗ２、入力ポート情報（ｉｎｐｏｒｔ）がｐ１であるため、冗長構成管理テーブルのＣＬＩＤが１のエントリが該当する。また、このエントリのキーフィールド情報はｎｗ＿ｓｒｃあり、受信パケットのヘッダのｎｗ＿ｓｒｃフィールドの値はＩＰ＿ＣＬ１となっている。これらの結果から、制御装置１４０は、ヘッダ変換テーブルのＮｏ．１のエントリであると特定する。次に、制御装置１４０は、ヘッダ変換テーブルのＮｏ．１の系１の変換後ヘッダ情報のうち、ｎｗ＿ｄｓｔを、受信パケットのヘッダから取得したＩＰ＿ＳＶ３へ書き換える（ステップＳ２０２）。なお、逆向きから送信されたパケットの場合は、ｎｗ＿ｓｒｃの逆であるｎｗ＿ｄｓｔがキー情報となる。また、継続フラグがＹｅｓのため、変換前ヘッダをもとにヘッダ変換テーブルのエントリを特定してもよい。
　次に、制御装置１４０は、系１の変換後ヘッダの書き換え前後の情報をもとに、後段スイッチ（第２スイッチ１１１）のフローエントリを書き換える。まず、図７のＮｏ．１０１のフローエントリのマッチ条件のｎｗ＿ｄｓｔをＩＰ＿ＳＶ１からＩＰ＿ＳＶ３に書き換え、Ｎｏ．１０４のフローエントリのマッチ条件のｎｗ＿ｓｒｃを ＩＰ＿ＳＶ１からＩＰ＿ＳＶ３に書き換える。その後、制御装置１４０は、後段スイッチ（第２スイッチ１１１）にポートｐ０からパケットアウトさせる（ステップＳ２０３）。
　なお、上記の例は、アプライアンス種別がＨａｌｆ－ＮＡＴで、ＣＬ１からＳＶ１へのパケットについての一例にすぎず、実施の形態について限定するものではない。
［系切り替え］
　続いて、ＡＰ１２０とＡＰ１２１のＡＣＴとＳＢＹの切り替えが行われた場合の動作について説明する。冗長構成を組むＡＰ１２０とＡＰ１２１のアプライアンスのうち、ＡＰ１２０に障害が発生した場合、制御装置１４０は、その通知を受け取る。この方法には、ＳＮＭＰ（Ｓｉｍｐｌｅ　Ｎｅｔｗｏｒｋ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）のＴｒａｐやアプライアンスから情報を受ける、アプライアンスを経由するパケットを監視する、または、ハートビートによる生存確認、などの方法があるが、特にこれらに限定するものではない。
　制御装置１４０は、受け取った通知から、冗長構成管理テーブルを参照し、ＣＬＩＤが１のエントリを参照し、現在のＡＣＴ（現用系）を系２に変更し、系１の接続ポートとキーフィールド情報のｎｗ＿ｓｒｃを取得する。次に、制御装置１４０は、ヘッダ変換テーブルを参照し、ＣＬＩＤが１、現用系フィールドが系１のｎｗ＿ｓｒｃの一覧を取得する。この例ではヘッダ変換テーブルのＮｏ．１のエントリが該当する。図１６は、上記更新後の冗長構成管理テーブルを示す図であり、破線は変更された箇所を示す。
　次に、制御装置１４０は、取得したｎｗ＿ｓｒｃ（この例ではＩＰ＿ＣＬ１）について、関連する後段スイッチ（第２スイッチ１１１）のフローエントリを書き換える。具体的には、制御装置１４０は、後段スイッチ（第２スイッチ１１１）のフローエントリのうち、マッチ条件のｎｗ＿ｓｒｃがＩＰ＿ＣＬ１のＮｏ．１００とＮｏ．１０１フローエントリを特定し（図７参照）、Ｎｏ．１００のフローエントリのアクションをｒｅｗｒｉｔｅ　ｄｌ＿ｄｓｔ＝ＭＡＣ＿ＳＶ１、ｒｅｗｒｉｔｅ　ｎｗ＿ｄｓｔ＝ＩＰ＿ＳＶ１、ｏｕｔｐｕｔ　ｐ０に変更する。また、制御装置１４０は、Ｎｏ．１０１のフローエントリのアクションを廃棄（ｄｒｏｐ）に変更する。
　次に、制御装置１４０は、従前ＳＢＹであった系２の接続ポートｐ２に関してＡＲＰ パケットを廃棄するＮｏ．１のフローエントリについて、マッチ 条件の入力ポート情報（ｉｎｐｏｒｔ）を新ＳＢＹの接続ポートｐ１に変更する。また、Ｎｏ．１０３のフローエントリについて、マッチ条件の入力ポート情報（ｉｎｐｏｒｔ）を新ＡＣＴの接続ポートｐ２に変更する。以上で、後段スイッチ（第２スイッチ１１１）は、新ＡＣＴであるＡＰ１２１との通信パケットを（パケットヘッダを変換しながら）転送し、従前のＡＣＴであるＡＰ１２０の通信パケットを廃棄するようになる。図１８は、上記更新後の後段スイッチ（第２スイッチ１１１）のフローエントリを示す図であり、破線は変更された箇所を示す。
　次に、制御装置１４０は、前段スイッチ（第１スイッチ１１０）のフローエントリのうち関連するものを書き換える（図７参照）。具体的には、制御装置１４０は、従前ＡＣＴであった系１の接続ポートｐ１に関してＡＲＰパケットを転送するＮｏ．１０１のフローエントリについて、マッチ条件の入力ポート情報（ｉｎｐｏｒｔ）を新ＡＣＴの接続ポートｐ２に変更する。次に、制御装置１４０は、従前ＳＢＹであった系２の接続ポートｐ２に関してＡＲＰパケットを廃棄するＮｏ．１のフローエントリについて、マッチ条件の入力ポート情報（ｉｎｐｏｒｔ）を新ＳＢＹの接続ポートｐ１に変更する。さらに、制御装置１４０は、従前ＡＣＴからＣＬ１へ返信パケットを転送するＮｏ．１０３のフローエントリについて、マッチ条件の入力ポート情報（ｉｎｐｏｒｔ）をｐ２に変更する。図１７は、上記更新後の前段スイッチ（第１スイッチ１１０）のフローエントリを示す図であり、破線は変更された箇所を示す。
　以上で、前段スイッチ（第１スイッチ１１０）は、新ＡＣＴであるＡＰ１２１との通信パケットを（パケットヘッダを変換しながら）転送し、従前ＡＣＴであるＡＰ１２０の通信パケットを廃棄するようになる。
　なお、系切り替え後に、系を切り戻す場合は、上記の手順を逆に戻せばよい。
　以上のように、本実施形態によれば、後段スイッチ（第２スイッチ１１１）にて、ＡＰ１２０系とＡＰ１２１系のヘッダ変換の差分が吸収される。その結果、ＡＣＴとＳＢＹのアプライアンスが異機種であっても、ステートフルなフェールオーバが実現できる。本実施形態のように、冗長化したいアプライアンスを前段スイッチ（第１スイッチ１１０）と後段スイッチ（第２スイッチ１１１）で挟み込むことで異機種間のステートフルフェールオーバが実現できるため、アプライアンス機種選択や配置に関する自由度が増し、物理資源の割り当ての柔軟性が向上する。
　以上、本発明の実施形態を説明したが、本発明は、上記した実施形態に限定されるものではなく、本発明の基本的技術的思想を逸脱しない範囲で、更なる変形・置換・調整を加えることができる。例えば、上記した実施形態では、前段スイッチ（第１スイッチ１１０）にクライアントＣＬ１が接続され、後段スイッチ（第２スイッチ１１１）にスイッチ１１２を介してサーバＳＶ１～ＳＶ３が接続されているものとして説明したが、これらは、本発明の理解を助けるための一例であり、例示した態様に限定されるものではない。
　なお、上記の特許文献および非特許文献の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。
　また日本語は単複同形であり、単数で記載された用語は複数も代表する。
　２０、２１　ネットワークアプライアンス
　３０　第１のスイッチ
　３１　第２のスイッチ
　４０　制御装置
　１１０　第１スイッチ
　１１１　第２スイッチ
　１１２　スイッチ
　１２０、１２１　アプライアンス（ＡＰ）
　１３０、１３１　パケット処理部
　１４０　制御装置
　１４１　経路制御部
　１４２　変換ルール管理部
　ｐ０、ｐ１、ｐ２　ポート
　ＣＬ１　クライアント
　ＳＶ１～ＳＶ３　サーバ

Claims (9)

  1. 　現用系と予備系とに切り替えて運用される２つの異なる機種のネットワークアプライアンスの前段に配置される第１のスイッチと、
    　前記２つの異なる機種のネットワークアプライアンスの後段に配置される第２のスイッチと、
    　前記第１のスイッチから送信されたパケットのヘッダ情報と、前記現用系のネットワークアプライアンスを経由して前記第２のスイッチにて受信したパケットのヘッダ情報と、に基づいて、前記現用系のネットワークアプライアンスによるヘッダ変換ルールを学習する変換ルール管理部を備え、前記予備系のネットワークアプライアンスに切り替わった際に、前記ヘッダ変換ルールに基づいて、前記第２のスイッチに対し、前記現用系のネットワークアプライアンスと同様の出力パケットとなるようヘッダ書き換えを指示する制御装置と、を含むネットワークアプライアンス冗長化システム。
  2. 　前記第１、２のスイッチは、
    　受信パケットと照合するためのマッチング条件と、処理内容とを対応付けた制御情報を記憶する制御情報記憶部と、
    　前記制御情報記憶部に記憶された制御情報の中から、受信パケットに適合するマッチング条件を持つ制御情報に定められた処理内容を実行するパケット処理部とを備え、
    　前記制御装置は、前記第１、２のスイッチの制御情報記憶部の制御情報を書き換えることにより、前記第１のスイッチから送信されたパケットのヘッダ情報と、前記第２のスイッチにて受信したパケットのヘッダ情報と、を受け取るネットワークアプライアンス冗長化システム。
  3. 　前記制御装置は、
    　前記第１のスイッチに、前記現用系のネットワークアプライアンスによる変更前後のヘッダ情報を格納可能なパケットを送信させる制御情報を設定し、
    　前記第２のスイッチに、前記現用系のネットワークアプライアンスによってヘッダ情報が書き換えられたパケットを転送させる制御情報を設定することにより、
    　前記現用系のネットワークアプライアンスによるヘッダ変換ルールを学習する請求項２のネットワークアプライアンス冗長化システム。
  4. 　前記制御装置は、
    　前記制御情報を用いて、前記第１、第２のスイッチに対して、ヘッダ書き換えを指示する請求項２又は３のネットワークアプライアンス冗長化システム。
  5. 　前記制御装置は、
    　前記第２のスイッチからの通知に基づいて、アドレス変換テーブルの更新有無を検出し、前記変換ルール管理部に保持されているヘッダ変換ルールを更新するとともに、前記第２のスイッチに対し、前記現用系のネットワークアプライアンスと同様の出力パケットとなるようヘッダ書き換えを指示する請求項１から４いずれか一のネットワークアプライアンス冗長化システム。
  6. 　前記ネットワークアプライアンスは、ＮＡＴ装置、ＮＡＰＴ装置、ロードバランサのいずれかである請求項１から５いずれか一のネットワークアプライアンス冗長化システム。
  7. 　現用系と予備系とに切り替えて運用される２つの異なる機種のネットワークアプライアンスの前段に配置される第１のスイッチと、
    　前記２つの異なる機種のネットワークアプライアンスの後段に配置される第２のスイッチと、に接続され、
    　前記第１のスイッチから送信されたパケットと、前記現用系のネットワークアプライアンスを経由して前記第２のスイッチにて受信したパケットと、に基づいて、前記現用系のネットワークアプライアンスによるヘッダ変換ルールを学習する変換ルール管理部を備え、
    　前記予備系のネットワークアプライアンスに切り替わった際に、前記ヘッダ変換ルールに基づいて、前記第２のスイッチに対し、前記現用系のネットワークアプライアンスと同様の出力パケットとなるようヘッダ書き換えを指示する制御装置。
  8. 　現用系と予備系とに切り替えて運用される２つの異なる機種のネットワークアプライアンスの前段に配置される第１のスイッチと、前記２つの異なる機種のネットワークアプライアンスの後段に配置される第２のスイッチと、接続された制御装置が、
    　前記第１のスイッチから送信されたパケットのヘッダ情報と、前記現用系のネットワークアプライアンスを経由して前記第２のスイッチにて受信したパケットのヘッダ情報と、に基づいて、前記現用系のネットワークアプライアンスによるヘッダ変換ルールを学習するステップと、
    　前記現用系のネットワークアプライアンスから前記予備系のネットワークアプライアンスに切り替わった際に、前記ヘッダ変換ルールに基づいて、前記第２のスイッチに対し前記第１のスイッチと同様のヘッダ書き換えを指示するステップとを含む制御装置と、を含むネットワークアプライアンス冗長化方法。
  9. 　現用系と予備系とに切り替えて運用される２つの異なる機種のネットワークアプライアンスの前段に配置される第１のスイッチと、前記２つの異なる機種のネットワークアプライアンスの後段に配置される第２のスイッチと、接続された制御装置に搭載されたコンピュータに、
    　前記第１のスイッチから送信されたパケットのヘッダ情報と、前記現用系のネットワークアプライアンスを経由して前記第２のスイッチにて受信したパケットのヘッダ情報と、に基づいて、前記現用系のネットワークアプライアンスによるヘッダ変換ルールを学習する処理と、
    　前記現用系のネットワークアプライアンスから前記予備系のネットワークアプライアンスに切り替わった際に、前記ヘッダ変換ルールに基づいて、前記第２のスイッチに対し前記第１のスイッチと同様のヘッダ書き換えを指示する処理とを実行させるプログラム。
PCT/JP2013/059605 2012-03-30 2013-03-29 ネットワークアプライアンス冗長化システム、制御装置、ネットワークアプライアンス冗長化方法及びプログラム Ceased WO2013147193A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US14/389,337 US9401865B2 (en) 2012-03-30 2013-03-29 Network appliance redundancy system, control apparatus, network appliance redundancy method and program
JP2014508106A JP5861772B2 (ja) 2012-03-30 2013-03-29 ネットワークアプライアンス冗長化システム、制御装置、ネットワークアプライアンス冗長化方法及びプログラム
CN201380017998.XA CN104247342A (zh) 2012-03-30 2013-03-29 网络设备冗余化系统、控制装置、网络设备冗余化方法及程序
EP13767523.7A EP2833583A4 (en) 2012-03-30 2013-03-29 REDUNDANCY SYSTEM FOR NETWORK DEVICE, CONTROL DEVICE, REDUNDANCY PROCESS FOR NETWORK APPLICATION AND PROGRAM

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2012079953 2012-03-30
JP2012-079953 2012-03-30

Publications (1)

Publication Number Publication Date
WO2013147193A1 true WO2013147193A1 (ja) 2013-10-03

Family

ID=49260434

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/059605 Ceased WO2013147193A1 (ja) 2012-03-30 2013-03-29 ネットワークアプライアンス冗長化システム、制御装置、ネットワークアプライアンス冗長化方法及びプログラム

Country Status (5)

Country Link
US (1) US9401865B2 (ja)
EP (1) EP2833583A4 (ja)
JP (1) JP5861772B2 (ja)
CN (1) CN104247342A (ja)
WO (1) WO2013147193A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015231059A (ja) * 2014-06-03 2015-12-21 富士通株式会社 経路設定装置及び経路設定方法

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6330479B2 (ja) * 2014-05-23 2018-05-30 富士通株式会社 情報処理システム及び情報処理方法
US9929937B2 (en) * 2015-08-27 2018-03-27 Dell Products L.P. Layer 3 routing loop prevention system
CN108574626A (zh) * 2017-03-13 2018-09-25 中兴通讯股份有限公司 一种分布式nat双机热备份流量切换系统和方法
US10581730B2 (en) 2018-07-12 2020-03-03 Vmware, Inc. Packet processing using service chains
US10645201B2 (en) * 2018-07-31 2020-05-05 Vmware, Inc. Packet handling during service virtualized computing instance migration
US11212322B2 (en) * 2018-10-10 2021-12-28 Rockwelll Automation Technologies, Inc. Automated discovery of security policy from design data
JP7099272B2 (ja) * 2018-11-19 2022-07-12 富士通株式会社 情報処理装置、ネットワークシステム及びチーミングプログラム
US20240031292A1 (en) * 2022-07-25 2024-01-25 Vmware, Inc. Network flow based load balancing

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005303501A (ja) 2004-04-08 2005-10-27 Hitachi Ltd パケット転送装置
JP2007208502A (ja) 2006-01-31 2007-08-16 Nec Infrontia Corp 通信システム、バックアップルータ、その冗長化処理プログラムおよびその冗長化処理方法
JP2010114585A (ja) * 2008-11-05 2010-05-20 Mitsubishi Electric Corp Ｎａｔ装置
WO2011093288A1 (ja) * 2010-02-01 2011-08-04 日本電気株式会社 ネットワークシステム、コントローラ、ネットワーク制御方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7280557B1 (en) * 2002-06-28 2007-10-09 Cisco Technology, Inc. Mechanisms for providing stateful NAT support in redundant and asymetric routing environments
US8332464B2 (en) * 2002-12-13 2012-12-11 Anxebusiness Corp. System and method for remote network access
CN101141494B (zh) * 2007-10-12 2011-02-02 杭州华三通信技术有限公司 一种解决负载分担情况下资源分配冲突的方法
CN101834831A (zh) * 2009-03-13 2010-09-15 华为技术有限公司 一种实现nat设备冗余备份的方法、装置和系统
JP5169992B2 (ja) * 2009-05-27 2013-03-27 Ｎｅｃインフロンティア株式会社 ネットワーク、ネットワーク装置及びそれらに用いる負荷分散方法
JP5645139B2 (ja) 2010-01-05 2014-12-24 日本電気株式会社 ネットワークシステム、コントローラ、ネットワーク制御方法
JP5413517B2 (ja) * 2010-08-20 2014-02-12 日本電気株式会社 通信システム、制御装置、通信方法およびプログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005303501A (ja) 2004-04-08 2005-10-27 Hitachi Ltd パケット転送装置
JP2007208502A (ja) 2006-01-31 2007-08-16 Nec Infrontia Corp 通信システム、バックアップルータ、その冗長化処理プログラムおよびその冗長化処理方法
JP2010114585A (ja) * 2008-11-05 2010-05-20 Mitsubishi Electric Corp Ｎａｔ装置
WO2011093288A1 (ja) * 2010-02-01 2011-08-04 日本電気株式会社 ネットワークシステム、コントローラ、ネットワーク制御方法

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"OpenFlow Switch Specification", VERSION 1.1.0 IMPLEMENTED (WIRE PROTOCOL 0X02) [ONLINE, 14 February 2012 (2012-02-14), Retrieved from the Internet <URL:http://www.openflow.org/documents/openflow-spec-vl.I.O.pdf>
KARINO SHUICHI; SUZUKI KAZUYA; JIBIKI MASAHIRO: "Duplicated Redundancy and Packet Processing Method in Router Clusters (Internet and general", IEICE (THE INSTITUTE OF ELECTRONICS, INFORMATION AND COMMUNICATION ENGINEERS) TECHNICAL REPORT, IA, INTERNET ARCHITECTURE, vol. 104, no. 377, 21 October 2004 (2004-10-21), pages 21 - 26
NICK MCKEOWN, OPENFLOW: ENABLING INNOVATION IN CAMPUS NETWORKS, 14 February 2012 (2012-02-14), Retrieved from the Internet <URL:http://www.openflow.org/documents/openflow-wp-latest.pdf>
See also references of EP2833583A4

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015231059A (ja) * 2014-06-03 2015-12-21 富士通株式会社 経路設定装置及び経路設定方法

Also Published As

Publication number Publication date
US9401865B2 (en) 2016-07-26
JPWO2013147193A1 (ja) 2015-12-14
JP5861772B2 (ja) 2016-02-16
EP2833583A4 (en) 2015-12-09
CN104247342A (zh) 2014-12-24
US20150055656A1 (en) 2015-02-26
EP2833583A1 (en) 2015-02-04

Similar Documents

Publication Publication Date Title
JP5861772B2 (ja) ネットワークアプライアンス冗長化システム、制御装置、ネットワークアプライアンス冗長化方法及びプログラム
US9215175B2 (en) Computer system including controller and plurality of switches and communication method in computer system
JP5648926B2 (ja) ネットワークシステム、コントローラ、ネットワーク制御方法
EP3248331B1 (en) Method for controlling switches to capture and monitor network traffic
JP6445015B2 (ja) ミドルウェアおよびアプリケーションの実行のためにエンジニアド・システムにおいてデータサービスを提供するためのシステムおよび方法
JP6004405B2 (ja) コントローラでネットワークパケット転送を管理するシステム及び方法
EP2748992B1 (en) Method for managing network hardware address requests with a controller
JP5585660B2 (ja) 通信システム、制御装置、処理規則の設定方法およびプログラム
US8938521B2 (en) Bi-directional synchronization enabling active-active redundancy for load-balancing switches
US9008080B1 (en) Systems and methods for controlling switches to monitor network traffic
US9787567B1 (en) Systems and methods for network traffic monitoring
WO2011087085A1 (ja) 計算機、ネットワーク接続切替え方法およびプログラム
JP2017506025A (ja) ネットワークサービス挿入を実行するシステム及び方法
JP6070700B2 (ja) パケット転送システム、制御装置、パケット転送方法及びプログラム
WO2014175423A1 (ja) 通信ノード、通信システム、パケット処理方法及びプログラム
JPWO2014126094A1 (ja) 通信システム、通信方法、制御装置、制御装置の制御方法及びプログラム
EP3503474A1 (en) A method for remotely performing a network function on data exchanged with at least one gateway
HK1180494A (en) Computer system and communication method in computer system
JP2016225933A (ja) 制御装置、中継装置の制御方法、プログラム及び通信システム
WO2014142081A1 (ja) 転送ノード、制御装置、通信システム、パケット処理方法及びプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13767523

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2014508106

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14389337

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2013767523

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2013767523

Country of ref document: EP