KR101969304B1 - Method and computer program for handling trouble using packet-out message in software defined networking environment - Google Patents

Abstract

The present invention relates to a method for processing faults generated when a network interface is bound in a software-defined networking environment, and a computer program. According to the present invention, a method for fault recovery of a controller managing a host having a network interface bound thereto in a software-defined networking environment, comprises the steps of: when the host transmits a first ARP request packet containing a predetermined first logical address to any network device, receiving a packet-in message for the ARP request packet from the network device; generating an ARP packet containing a first physical address corresponding to the first logical address or using the first ARP request packet to generate a second ARP request packet; and transmitting a packet-out message containing the ARP packet or the second ARP request packet to the network device. According to the present invention, when a network interface of a terminal is bound in a software-defined networking environment, a fault generated between network devices and a controller can be easily detected.

Description

METHODS AND COMPUTER PROGRAM FOR HANDLING TROUBLE USING PACKET-OUT MESSAGE IN SOFTWARE DEFINED NETWORKING ENVIRONMENT}

The present invention relates to a failure handling method in a software defined networking environment, and more particularly, a method and a computer for handling a network failure that may occur when bonding a network interface using a packet-out message generated by a controller in a software defined networking environment. It's about the program.

Software Defined Networking (hereinafter referred to as SDN) refers to a technology for managing all network equipment of a network by an intelligent central management system. In the SDN technology, a controller provided in software forms a control operation related to packet processing performed by an existing hardware network device on its behalf, so that various functions can be developed and assigned than an existing network structure. The SDN system generally includes a controller server controlling the entire network, a plurality of open flow switches controlled by the controller server and processing packets, and a host corresponding to a lower layer of the open flow switch. In this case, the open flow switch is in charge of the transmission / reception of packets only, and the routing, management, and control of the packets are all performed at the controller server. In other words, it is a basic structure of the SDN system that separates the data plane and control plane constituting the network equipment.

On the other hand, network bonding is a technology for preparing a network interface failure or link disconnection by tying several network interfaces together, and implementing a fault tolerant system or load balancing of a network in a legacy network. It is being used for

When bonding is made to one or more network interfaces configured in an arbitrary terminal, the corresponding computer periodically sends an ARP request to a predetermined IP (hereinafter, referred to as a target IP). If the ARP packet related to the target IP is not received within a certain time, the unused interface is set as the bonding interface to overcome the failure situation. (See Figure 1)

However, in a software defined networking environment (hereinafter referred to as an SDN environment), there is a limit in detecting a failure by a conventional method. This is because in SDN environments, not only link or switch failures, but also management network failures between the controller and network equipment must be detected. When the link between the switch and the controller connected to the activating bonding interface of the server is broken as shown in FIG. 2, according to the conventional method, such a link disconnection is not detected and a problem may occur. Therefore, when bonding the network interface of the terminal in the SDN environment, a method for detecting a failure occurring in the network is required.

An object of the present invention is to provide a method for easily detecting a failure occurring between a network device and a controller when bonding a network interface of a terminal in a software defined networking environment. .

It is another object of the present invention to enable a terminal to bond network interfaces in a software defined networking environment, thereby enabling more stable network management.

In order to achieve the above object, the present invention provides a method for handling a failure of a controller managing a host bonded to a network interface in a software defined networking environment, the host including a first ARP request including a preset first logical address. Sending a packet to any network equipment, receiving a packet-in message for the ARP request packet from the network equipment, generating an ARP packet including a first physical address corresponding to the first logical address, or Generating a second ARP request packet by using a first ARP request packet, and transmitting a packet-out message including the ARP packet or the second ARP request packet to the network equipment. .

According to the present invention as described above, when bonding the network interface of the terminal in the software-defined networking environment, it is possible to easily detect a failure occurring between the network equipment and the controller.

In addition, the present invention has the advantage that the terminal can bond the network interface in the software-defined networking environment, more stable network management.

1 is a view illustrating a failure handling method when bonding a network interface in a legacy network;
2 is a view for explaining a limitation of the prior art application in a software defined networking environment;
FIG. 3 is a view for explaining an embodiment of a failure handling method generated when a network interface of a terminal is bonded in a software defined networking environment of the present invention; FIG.
4 is a diagram illustrating a failure processing method using a packet out message according to an embodiment of the present invention.

The above objects, features, and advantages will be described in detail with reference to the accompanying drawings, whereby those skilled in the art may easily implement the technical idea of the present invention. In describing the present invention, when it is determined that the detailed description of the known technology related to the present invention may unnecessarily obscure the gist of the present invention, the detailed description will be omitted. Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings are used to indicate the same or similar components, all combinations described in the specification and claims may be combined in any way. And unless specified otherwise, reference to the singular may include one or more, and reference to the singular may also include the plural expression.

2 is a diagram illustrating a failure occurrence situation in a software defined networking environment. 2, a software defined networking environment may include a controller 100, network equipment 200, and host 300. The network device 200 and the host 300 may be referred to as a node, and a link may mean a connection between two nodes.

The controller 100 functions to manage the network equipment 200, and centrally manages and controls the plurality of network equipment 200. In more detail, the controller 100 is an application (software) for functions such as topology management, path management related to packet processing, link discovery, and flow management as a packet flow. It may be implemented in a mounted form. Unless otherwise specified herein, it may be understood that each step of the failure processing executed by the controller 100 is executed by an application.

The network equipment 200 functions to process packets under the control of the controller 100. The switch 200 illustrated in the drawing may be exchanged with network equipment such as a mobile communication base station, a base station controller, a gateway device, a router, and the like for packet processing. However, for convenience of description, the case in which the network equipment is the switch 200 is illustrated, and the switch 200 according to an embodiment of the present invention will be described based on the case of the open flow switch 200.

In a software defined networking environment, the controller 100 and the open flow switch 200 should exchange information with each other, and an open flow protocol is widely used as a protocol for this. That is, the open flow protocol is a standard standard that can communicate with each other between the controller 100 and the open flow switch 200.

In more detail, the open flow switch 200 is largely divided into a software layer and a hardware layer. The software layer exchanges information with the controller 100 via a secure channel. The secure channel is a communication channel between the open flow switch 200 and the controller 100 located remotely, and information exchanged between the controller 100 and the open flow switch 200 is encrypted.

In the hardware layer, there is a flow table that defines and processes the packet and includes statistical information related to the packet. The flow table is composed of a flow rule for defining packet processing, and the flow rule is generated by a flow mode message generated by the controller 100 and transmitted to the open flow switch 200. It can be added, modified or deleted. The open flow switch 200 processes the packet by referring to the flow table. Each row constituting the flow table is called a flow entry. The flow entry may largely include three pieces of information: packet header information (Rule) defining a flow, action information (Action) defining a packet processing, and statistical information (Stats) for each flow.

The host 300 refers to a terminal corresponding to a lower layer of the open flow switch 200, and may be used to mean a client and a server. The host 300 may generate a packet to be sent to another host in a software defined networking environment, and transmit the packet to the openflow switch 200 through a port of the network interface. In the present specification, a failure handling method when the network interface of the host 300 is bonded is disclosed. Thus, in each embodiment described herein, the host 300 may have one or more network cards, and one or more network cards may be understood to be bonded.

As shown in FIG. 2, in a software-defined networking environment, the host 300 in which the network interface is bonded is configured to periodically open an ARP request packet having a predetermined logical address as a target address. 200). This is for determining whether to maintain the bonding interface, and if the host 300 does not receive a packet corresponding to the ARP request packet, the host 300 switches the activation interface.

For example, the host 300 may periodically transmit the ARP request packet to the target IP (10.0.0.1) using a code such as “bond-arp-ip-target 10.0.0.1”. Assume that NIC 1 and NIC 2 of FIG. 2 are bonded, and a packet is currently transmitted and received through NIC 1. FIG. In this case, if a response corresponding to the ARP request packet continuously transmitted through NIC 1 is not received, the host 300 may change the bonding interface from NIC 1 to NIC 2. Therefore, data transmitted from the host 300 or input to the host 300 is then transmitted and received through the NIC 2.

The ARP request packet is transmitted by targeting the IP address of the node (putting the target address in the Target IP address field) to know the MAC address of the other host or router. Generally, the ARP packet is an Ethernet header field (destination physical). Address, source physical address, type), ARP request or response payload, padding field, and CRC field.ARP request or response payload may include a hardware type and a protocol type. , Hardware address length, protocol address length, operation code, source hardware address, source logical address, source physical address, target physical address (Targer hardware address) and target (destination) target protocol address.

On the other hand, when the open flow switch 200 receives an arbitrary packet, when there is a flow table that defines the processing of the packet, the open flow switch 200 processes the packet as specified. However, if there is no flow table for the packet in the open flow switch 200, the open flow switch 200 transmits a packet-in message informing the controller 100 of the packet inflow. The controller 100 generates a flow table defining the processing of the packet according to an operator's policy or a predetermined algorithm, and transmits the flow table to the open flow switch 200, and the open flow switch 200 receives the flow table and Based on the packet processing.

A packet-out message is a packet received through a message or a packet-in message sent by the controller 100 to the openflow switch 200 so that the openflow switch 200 outputs a packet at a designated port. Message to forward. The packet-out message includes the entire packet or buffer ID, and the OpenFlow switch 200 receiving the packet-out message sends the packet included in the packet-out message to the destination of the packet-out message. To pass.

Hereinafter, when a network interface of a host (terminal) is bonded in a software defined networking environment according to an embodiment of the present invention using FIGS. 3 to 4, a method of handling a failure by using a packet-out message will be described. .

First, referring to FIG. 3, in a software-defined networking environment, when a host bonded to a network interface transmits a first ARP request packet including a preset first logical address to an arbitrary network device, the controller receives the network device from the network device. A packet-in message for the ARP request packet is received (S100). Receiving the packet-in message for the ARP request packet, the controller 100 generates an ARP packet including the first physical address corresponding to the first logical address, or uses the first ARP request packet to generate the second ARP request packet. It may be generated (S200). Next, the controller 100 transmits a packet-out message including the ARP packet or the second ARP request packet to the network equipment (S300).

The kind of the packet generated in step 200 will be described in more detail with reference to FIG. 4 as follows.

(1) the controller 100 generates an ARP response packet

First, when a packet-in message regarding an ARP request packet is received by the controller 100, the controller 100 may generate an ARP response packet destined for a host and transmit the packet-out message.

For example, suppose that an ARP request packet as shown in Table 1 is received at the openflow switch 200, so that a packet-in message indicating a packet inflow from the openflow switch 200 is received at the controller. In each field, ETH_SRC is the source physical address included in the Ethernet header field, ETH_DST is the destination physical address included in the Ethernet header field, ARP_OP is the operation code, ARP_SHA is the source physical address, ARP_SPA is the source logical address, ARP_THA is the destination physical address, ARP_TPA means the destination logical address.

The ARP request packet of Table 1 is transmitted from a host 300 having a logical address of 10.0.0.5 and a physical address of 11: 22: 33: 44: 55: 66, and the destination logical address is 10.0.0.1. In this case, the destination logical address 10.0.0.1 may be an existing host, but may be any logical address previously promised for bonding failure handling in a software defined network environment according to the present invention. Since the ARP request packet is a packet for knowing the physical address of an arbitrary host, the destination physical address is set to a broadcast address such as FF: FF: FF: FF.

The controller 100 receiving the ARP request packet A may generate an ARP response packet B corresponding thereto as shown in [Table 2]. The controller 100 may generate an ARP response packet B by inputting a preset physical address in the source physical address field. ARP_OP means a response packet as 2, and each field is filled with the set address value. The ARP response packet (B) indicates that the physical address of the host having a logical address of 10.0.0.1 is 6c: 3b: e5: 5a: 6c: 1c. Keep it.

(2) the controller 100 generates a GARP packet

In the packet-out message (B), the controller may generate and send a GARP packet. When the ARP request packet as described above is received, the controller 100 may generate a GARP packet as shown in [Table 3].

GARP packets, also called Gratuitous ARP, send an ARP request targeting their IP address. In legacy networks, GARP packets are used to detect IP address collisions, or are used to update the ARP table. However, the present invention uses GARP packets to detect failures when the host 300 is bonded. To be possible.

 The controller 100 may generate and transmit a packet having a form of a GARP packet in response to an ARP request. At this time, the destination logical address becomes 10.0.0.1, the requested logical address, and the destination physical address is a broadcast address. Is set. As a result, the controller 100 broadcasts the GARP packet to the network, and the GARP packet arrives at the host 300 included in the management object of the controller 100. According to an embodiment of the present disclosure, when the GARP packet is received, the host 300 may be configured to check a destination logical address (origin logical address), and if the destination logical address includes a preset logical address, the host ARP request packet may be set. In response, we can maintain the bonding interface.

(3) the controller 100 generates an ARP request packet

In another embodiment, the controller may generate an ARP request packet with a packet-out message (B). In the above-described embodiment, it is assumed that the ARP request packet received by the open flow switch 200 is a first ARP request packet. The controller 100 may generate a second ARP request packet based on the first ARP request packet as shown in [Table 4].

The second ARP request packet changes only the source physical address included in the Ethernet header field in the first ARP request packet received by the openflow switch 200, and the controller 100 changes the Ethernet header field of the first ARP request packet. The second ARP request packet may be generated by setting a source physical address ETH_SRC different from the physical address of the host.

In Table 4, ETH_SRC is described as 00: 00: 00: 00: 00: 01, which is only an example, and the source physical address is irrelevant if it is different from the physical address of the host 300. Do.

The second ARP request packet is transmitted to the host 300. When the host 300 receiving the second ARP request packet confirms that the destination logical address is 10.0.0.1, the host 300 may recognize the response as the response to the first ARP request packet transmitted by the host 300 and maintain the activated bonding interface.

In three embodiments using the above-described packet-out message, the host 300 switches the activated bonding interface if an ARP packet (ARP response packet, GARP packet) or a second ARP request packet is not received within a preset time. It can be set to.

The above-described fault handling method may be implemented in the controller 100 through a fault handling application program stored in a computer readable medium in order to execute any one of the embodiments.

Some embodiments omitted in the present specification may be equally applicable to the same subject matter. In addition, the above-described present invention can be variously substituted, modified, and changed within the scope without departing from the spirit of the present invention for those skilled in the art to which the present invention pertains to the above-described embodiments and attached It is not limited by the drawings.

100: controller
200: switch
300: host (terminal)

Claims (6)

In a failure handling method of a controller managing a host in which a network interface is bonded in a software defined networking environment,
When the host transmits a first ARP request packet having a preset first logical address as a destination logical address to any network equipment, the controller receives a packet-in message for the first ARP request packet from the network equipment. Doing;
When the controller receives the first ARP request packet, the controller generates an ARP packet including a first physical address corresponding to the first logical address, or only the source physical address included in the Ethernet header field in the first ARP request packet. Generating a second ARP request packet by setting a different address from the physical address of the host;
The controller sending a packet-out message including the ARP packet or the second ARP request packet to the network equipment;
The host receives the ARP packet or the second ARP request packet and responds to the first ARP request packet if the destination logical address of the ARP packet or the second ARP request packet includes the first logical address. And maintaining the bonding interface.
The method of claim 1, wherein the destination physical address included in the Ethernet header field of the ARP packet is a broadcast address, and the destination logical address of the ARP packet is a GARP packet set to the first logical address.
The method of claim 1,
And the host is configured to switch an activated bonding interface if the ARP packet or the second ARP request packet is not received within a preset time.
A controller application program stored on a computer readable medium for executing any one of the methods of claims 1 to 3.
delete delete

Images