KR100664715B1 - Gre based virtual private network supplying gateway multiplication - Google Patents

Abstract

A GRE(Generic Routing Encapsulation)-based VPN(Virtual Private Network) for providing gateway multiplexing is provided to offer a substantial broadband service by grouping and managing a plurality of GRE tunnels and transmitting a series of packets through many tunnels in an associated group and to make a backup gateway provide a seamless service even though a fault occurs at a gateway in operation. A GRE-based VPN comprises the first gateway(310) and the second gateway(320). The first gateway(310) creates one or more GRE tunnels connected with a remote gateway, forms a line multiplexing group composed of the created tunnels, and distributively transmits packets through one or more GRE tunnels of the line multiplexing group. The second gateway(320) receives information about the line multiplexing group from the first gateway(310) and shares it with the first gateway(310). In case that the first gateway(310) works abnormally, the second gateway(320) executes the functions of the first gateway(310) by proxy.

Description

GRE based Virtual Private Network Supplying Gateway Multiplication

1 is a diagram illustrating a general VPN configuration.

2 illustrates a preferred embodiment of a GRE tunnel configuration in accordance with the present invention.

3 conceptually illustrates data flow on a GRE tunnel in accordance with the present invention;

4 is a block diagram of a circuit multiplexing gateway according to the present invention;

5 illustrates one preferred embodiment of a multiplexed group configuration in accordance with the present invention.

Figure 6 illustrates a preferred embodiment of the tunnel information according to the present invention.

7 illustrates a method for redundant gateways sharing circuit multiplexing information in accordance with the present invention.

8 is a diagram illustrating a redundant inter-gateway circuit multiplexing operation flow according to the present invention.

* Description of the symbols for the main parts of the drawings *

100: gateway 110: circuit multiplexing information management module

120: GRE device management module 130: IP address management module

140: line state detection module 150: scheduler

160: tunnel information storage unit

The present invention relates to a GRE-based virtual private network that provides gateway multiplexing.

A virtual private network (hereinafter referred to as "VPN") is to provide broadband leased line services at low cost and to create a private link in a public network such as the Internet. In general, this is the idea of making a shared network look like a private link using encryption and tunneling techniques. VPNs can be implemented relatively easily in ATM (Asynchronous Transfer Mode), frame relay networks, etc., because they can configure virtual circuits that provide customers with dedicated bandwidth and path control.

1 is a general VPN configuration diagram.

As shown in FIG. 1, a VPN forms a virtual tunnel in which a third party cannot recognize a packet through a public network such as an ADSL or a cable for communication with a branch located at a remote place in each enterprise or institution, and a dedicated line. It provides high stability and security.

As the technology for implementing tunneling, IPSec (IP Security Protocol), Layer 2 Tunneling Protocol (L2TP), etc., which have been standardized, are most commonly used. In addition, Point to Point Tunneling Protocol (PPTP) and Layer 2 Forwarding Protocol (L2F) are used. ), VTP (Virtual Tunneling Protocol), and the like are used. Commonly used encryption technologies for providing VPN services include authentication, encryption, and encryption. Examples of encryption methods include data encryption standard (DES) used for IPSec and RC4 used for PPTP.

In such a VPN, the VPN circuits between the two gateways can be multiplexed to properly distribute the traffic between the gateways (Load Balancing), and if a part of the circuit fails, the traffic that used the faulty circuit can use the normal circuit to create a seamless network environment. This is called VPN line multiplexing. In addition, in addition to circuit multiplexing, arranging one or more gateways locally or remotely, and providing a service by one side when a failure occurs in one side is called gateway multiplexing.

In order to implement multiplexing in a VPN, it is necessary to set up multiple routes to the same destination and to select one of several routes properly whenever a routing decision is made.

However, in the case of VPN multiplexing using the commonly used IPSec protocol, a preferred method for circuit multiplexing and gateway multiplexing has not been provided, and thus an easy solution for VPN circuit multiplexing has not been proposed.

In order to solve the above problem, the present invention provides a gateway multiplexing scheme in which a gateway operating in a GRE-based virtual private network that transmits a packet through a multiplexed circuit in at least one GRE tunnel causes another gateway to perform its role in case of a failure. Its purpose is to provide a GRE-based virtual private network.

GRE-based virtual private network according to an aspect of the present invention for achieving the above object, generating at least one GRE (Generic Routing Encapsulation) tunnel connected to a remote gateway, and consists of the generated at least one GRE tunnel A circuit multiplexing group is configured to receive and share information about the circuit multiplexing group from the first gateway and the first gateway for distributed transmission of a packet to be transmitted to a remote location through at least one GRE tunnel in the circuit multiplexing group. And when the first gateway does not operate normally, at least one second local gateway serving as the first gateway instead.

The first gateway may include a GRE device management module that generates or deletes a Generic Routing Encapsulation (GRE) tunnel connected to a remote gateway, and updates information about the generated GRE tunnel; A circuit multiplexing information management module that manages information about a circuit multiplexing group consisting of at least one GRE tunnel generated by the GRE device management module; And a gateway multiplexing module configured to forward an IP address change message received from a local subnet or a remote subnet to the at least one second gateway.

The information on the circuit multiplexing group includes a pair of IP addresses forming a tunnel, a pair of subnet addresses, information on a circuit multiplexed into one group, and information on the number of multiplexing circuits.

The gateway multiplexing module operates based on at least one multiplexing technique of L4 or VRRP.

The gateway multiplexing module updates circuit multiplexing group information and information of a related GRE device according to an IP address change message received from a local subnet or a remote subnet, and sets a real IP address of a message receiving gateway and a multiplexing group of a message receiving gateway. If the two addresses are the same, the IP address change message is received from the local subnet or the remote subnet, and the IP address change message is transmitted to the at least one second gateway.

The at least one second gateway receives the IP address change message from the first gateway, and updates the circuit multiplexing group information and the information of the associated GRE device according to the information included in the received IP address change message.

The first gateway may include a tunnel information storage unit configured to store state information on the generated GRE tunnel; An IP address management module for updating a GRE device associated with the corresponding IP address when notifying a change of an IP address of the local gateway and notifying the remote gateway of the IP address change so as to update the related GRE device; Circuit detection / routing management that transmits a circuit failure detection packet to detect a failure with a remote gateway, determines a circuit failure according to a response state from the remote gateway, and changes routing to a corresponding channel multiplexing group when a circuit failure occurs. module; And controlling the circuit detection / routing management module to periodically transmit a circuit detection packet for each circuit multiplexing group, and periodically controlling the IP address management module to check whether the IP address of the local gateway is changed. It may further include a scheduler.

The state information for the GRE tunnel includes a circuit multiplexing group ID, a load balancing policy, an external interface IP address of a local gateway, an external interface device name of a local gateway, an external interface IP address of a remote gateway, and a line corresponding to each GRE tunnel. It contains information about the status, the subnet address of the local gateway, the subnet address of the remote gateway, the internal interface IP address of the local gateway, and the internal interface IP address of the remote gateway.

Hereinafter, a preferred embodiment according to the present invention will be described in detail with reference to the drawings.

More scalable tunneling tools are being developed to handle the migration of various networks, such as integrating new IPv6 network components into existing IPv4 networks. Even in service provider environments, multicast virtual private networks (VPNs) can replace the use of full mesh GRE tunneling to transport multicast traffic between multiprotocol label switching (MPLS) VPN sites.

One of the tunneling techniques, Generic Routing Encapsulation (GRE), takes packets or frames from one network system and places them in a peer-to-peer (P2P) configuration. Enterprises use GRE to transport legacy Layer 3 protocols over the IP backbone. GRE consists of a packet header with components that allow you to identify data for a process when it reaches the relevant party. These components include IPv4 tunneling or transport headers, tunnel keys and checksums, and a series of fields (payload or tunneled Layer 3 packets).

Several technical elements are required to implement VPN circuit multiplexing. The first is a routing decision mechanism that can load balance multiplexed circuits, the second is a tunneling protocol that enables communication between subnets using private IPs, and the third is an encryption protocol that can protect traffic between gateways.

In the present invention, circuit multiplexing is implemented by adopting a GRE (Generic Routing Encapsulation) protocol as a tunneling protocol.

2 shows an embodiment of a GRE tunnel configuration according to the present invention.

Referring to FIG. 2, a GRE tunnel having a path of "A (subnet-eth2-vgre0-eth0)-B (eth0-vgre0-eth2-subnet)" is created between the gateway A 100 and the gateway B 200. It can be seen that. From the gateway A 100 side, the subnet is 192.168.1.0/24, the local eth2 is 192.168.1.1, and the local eth0 is 211.41.160.15. Also, from the gateway B 200 side, the subnet is 192.168.2.0/24, the local eth0 is 211.41.160.17, and the local eth2 is 192.168.2.1.

3 is a diagram conceptually illustrating a data flow on a GRE tunnel according to the present invention.

3 illustrates a basic concept of the present invention in which at least one GRE tunnel is formed between two gateways, and the formed multiple GRE tunnel is used as one circuit. That is, at least one GRE tunnel (101, 102, 103) is formed between the gateway A and the gateway B as shown in FIG. 2, and the packet flow in the case of transmitting a packet is shown.

FIG. 3 assumes a case of transmitting a packet of [1, 2, 3, 4, 5, 6] from gateway A to gateway B, and distributes packets using three GRE tunnels formed between gateway A and gateway B. , Sending. The three tunnels of FIG. 3 are three GRE devices, ie separate tunnels that differ in network ports, but are logically grouped into one multiplex group. That is, several tunnels are included in one group in the order of Tunnel0-0 (101), Tunnel0-1 (102), and Tunnel0-2 (103).

The packet [1, 2, 3, 4, 5, 6] to be transmitted is transmitted through three tunnels included in one multiplexing group instead of one tunnel. Packets [1] and [4] are transmitted through Tunnel0-0. Through 101, it can be seen that packets [2] and [3] are distributed and transmitted through Tunnel0-1 102, and packets [3] and [6] through Tunnel0-2 (103).

4 shows a block configuration of a circuit multiplexing gateway according to the present invention.

The circuit multiplexing gateway according to the present invention includes a circuit multiplexing information management module 110, a GRE device management module 120, an IP address management module 130, a line state sensing module 140, and a scheduler 150. .

The circuit multiplexing information management module 110 manages information about a multiplexing group in which at least one GRE tunnel is collected. The multiplexed group managed by the circuit multiplexing information management module 110 may be represented as shown in FIG. 5.

5 shows one preferred embodiment of a multiplexing group configuration according to the present invention.

One multiplexing group is distinguished from other circuit multiplexing groups by the "name" field and the "groupid" field. The "name" field is literally the name of a circuit multiplexing group and an official identifier, while the "groupid" field is a random identifier assigned in ascending order from zero each time it is initialized according to the circuit multiplexing group registration order. The "groupid" field is also used when the scheduler, which will be described later, transmits a circuit failure detection packet and is used to construct a name of a GRE tunnel. X appearing in the GRE tunnel names "greX-0", "greX-1", etc. of FIG. 5 is a groupid of the circuit multiplexing group.

In FIG. 5, devices represented by eth0, eth1, eth2, eth3, eth4, and eth5 should be different devices having different IP addresses, but devices represented by ethY may or may not be one device. This can be set to an IP address that does not exist on the local host.

The GRE device management module 120 is responsible for managing information about the GRE tunnel generated between the gateways. To this end, the GRE device management module 120 updates the GRE device information when the IP address of the local gateway is changed or when an IP address change message is received from the remote gateway.

The GRE device management module 120 creates and removes GRE devices belonging to one circuit multiplexing group. The GRE tunnel according to the present invention is managed with the following naming scheme.

gre <Group ID>-<GRE Pair Index>

The GRE device management module 120 may generate or remove GRE devices according to the number of required GRE devices. GRE devices are managed by multiplexing groups, which will be described in detail later. The removal of the GRE device does not rely on line multiplexing information, but instead removes a list of GRE tunnels with names in the format greX-Y, via IP address commands. For this reason, even if there are some problems with circuit multiplexing information, the entire GRE tunnel can be safely removed.

The GRE device management module 120 also updates the information held by the GRE device when the IP address of the local gateway is changed or when an IP address change message is received from the remote gateway.

The IP address management module 130 of FIG. 4 is a module for checking suitability of the GRE tunnel configuration and adapting to a dynamic IP environment. Since the GRE device is a device with an IP address, when the interface IP address of one gateway is changed, it is necessary to update the GRE device information of both gateways. When the IP address management module 130 detects a change in the IP address of the local gateway, the IP address management module 130 updates the GRE device associated with the corresponding IP address, and notifies the counterpart gateway of the IP address change so as to update the related GRE device.

The IP address management module 130 may be implemented by dividing its roles into a local address management module 131 and a remote address change processing module 132. The local address management module 131 is a module that manages the entire IP address of the local gateway, and takes necessary measures when there is a change in the local gateway IP address.

The local address management module 131 receives a report from the scheduler 150 and compares IP addresses existing in the local host with local host IP addresses stored by the gateway in order to list new or missing IP addresses in the list. If the IP address of a device with a dynamic IP address, such as ADSL or DHCP, is changed, the local IP address of the GRE device is modified, and the IP address change message is sent to the remote gateways forming the circuit multiplexing group. .

On the other hand, the remote address change processing module 132, Receives IP address change message from remote gateway and synchronizes multiplexing information.

The IP address change message sent by the remote gateway includes the circuit multiplexing group name, the actual IP address of the gateway that receives the message, and the address on the multiplex group configuration of the gateway that will receive the message. In general, the actual IP address of the gateway that receives the message and the address in the multiplex group configuration of the gateway that will receive the message have the same value, but may be different in the case of a gateway multiplexing environment using L4 or VRRP. The IP address change message also includes information such as the remote gateway IP address before the change, the remote gateway IP address after the change, the index number of the multiplexed line, that is, the number indicating the number of the multiplexed lines.

Upon receiving the IP address change message from the remote gateway, the remote address change processing module 132 checks the size of the IP address change message, and selects the line multiplexing group requiring IP information change from the line multiplexing group name included in the IP address change message. Find out. In addition, the remote gateway IP address information before the change included in the message is compared with the remote gateway IP addresses registered in the circuit multiplexing group, and the index number of the circuit requiring the IP information change is retrieved. Then, the remote gateway IP address corresponding to the retrieved multiplex circuit index number is replaced with the remote gateway IP address after the change included in the IP address change message. Also, modify the remote IP address of the GRE device related to the changed IP address to the value of the remote gateway IP address after the change.

If the local gateway is multiplexed using L4 or VRRP, it can send IP address change messages to other multiplexed gateways and synchronize line multiplexing information.

The circuit detection / routing management module 140 plays a role of exchanging UDP request / reply packets with each other to detect a gateway located at a remote location and a failure. At this time, the packet transmitted and received for circuit failure detection is represented by a structure called "DETECT_PACKET", and the DETECT_PACKET structure includes packet type and serial number information of the circuit failure detection packet.

The packet type indicates whether it is a request packet or a reply packet. The "seq" field represents the serial number of the circuit failure detection packet. Since the same type of Request packet and Reply packet are transmitted periodically, it is used to distinguish packets corresponding to each period from packets corresponding to other periods.

The circuit detection / routing management module 140 uses a UDP DETECT_PACKET_PORT (No. 2003) port. This port is also used to send a circuit failure detection request packet and receive a reply packet. It is also used as an echo server that sends a reply packet when a request packet is received from another gateway. The circuit detection module that receives the circuit failure detection packet through this port first checks whether the type of the DETECT_PACKET structure is DETECT_REQUEST or DETECT_REPLY. In the case of DETECT_REQUEST, simply change the value of the type field of the DETECT_PACKET structure to DETECT_REPLY, and use it as information for determining the line failure in case of DETECT_REPLY.

The circuit detection / routing management module 140 transmits a request packet for determining a circuit failure at a predetermined cycle. The circuit detection / routing management module 140 transmits the packet failure detection request packet for the entire circuit multiplexing group at the same time, and distributes it as much as possible.

The circuit detection / routing management module 140 also checks whether a Reply packet for a request packet sent in the last cycle for the same circuit multiplexing group has arrived before sending a circuit failure detection request packet corresponding to one circuit multiplexing group. . If a Reply packet arrives on a circuit that was in a failed state, the circuit is considered normal again. If the reply packet does not arrive on the circuit in a normal state, the circuit is regarded as a failure circuit. However, even if a UDP packet has not been delivered once, it may be difficult to consider the circuit as a faulty line. If a reply packet does not arrive more than a predetermined number of times in a row, the circuit is considered as a faulty line.

In this way, it detects a circuit failure and changes the routing for that circuit multiplexing group if a change in line condition is detected. That is, the existing routing entry for the circuit multiplexing group is deleted, and the routing entry is generated again only with information currently in a normal state.

The scheduler 150 processes tasks to be performed at regular intervals. Tasks to be performed at regular intervals include sending a line detection packet for each circuit multiplexing group and checking whether the local gateway IP address is changed. That is, the scheduler transmits a circuit detection packet periodically in association with the IP address management module and the circuit detection / routing management module and checks whether the IP address of the local gateway is changed.

Failure detection check cycle for how many cycles to perform the circuit failure detection according to the check cycle that the scheduler 150 determines how many seconds to perform the above operations, or local gateway in the unit of several check cycles An IP address checking interval may be set whether or not to check for an IP address change.

Meanwhile, the tunnel information storage unit 160 stores state information about the generated GRE tunnel.

6 shows an exemplary embodiment of tunnel information according to the present invention.

Referring to FIG. 6, it can be seen that the GRE tunnel stored by the tunnel information storage unit 160 is managed for each multiplex group.

One line represents one GRE tunnel, and one paragraph, separated by a blank line, represents one circuit multiplexing group. The meaning of each item of information in the tunnel information file is indicated on the first line of the file.

GID is the circuit multiplexing group ID and the circuit index number, TLBGROUP_NAME is the circuit multiplexing group name, POLICY is the load balancing policy, LOCAL_EXT_IP local gateway's external interface IP address, and LOCAL_EXT_DEV is the local interface's external interface device name. In this case, the external interface device name of the local gateway is displayed in the case of a fixed IP device and a fixed IP device, and in the case of a dynamic IP device.

In addition, REMOTE_EXT_IP represents the external interface IP address of the remote gateway, WGT represents the weight value used in ECMP load balancing, STATE represents the circuit state, and if the circuit state is normal, it is displayed as active and inactive if the failure occurs. LOCAL_SUBNET represents the subnet address of the local gateway. If the subnets are multiplexed, only the representative subnet (the first subnet) is displayed. REMOTE_SUBNET represents the subnet address of the remote gateway, and if the subnets are multiplexed, only the representative subnet (the first subnet) is displayed. LOCAL_INT_IP represents the internal interface IP address of the local gateway, and REMOTE_INT_IP represents the internal interface IP address of the remote gateway. The GRE tunnel information stored by the tunnel information storage unit 160 is updated whenever a change in the line state occurs.

 Finally, the gateway redundancy module 170 controls the other gateways to take over the role of the failed hosts even if some of one gateway fails in the redundant gateway structure. That is, gateway multiplexing is performed to maintain the GRE tunnel, packet forwarding, etc. as described above even if another redundant gateway fails. In this case, although redundancy is expressed, depending on the implementation, two or more gateways may be used. In this case, it is more preferable to express a gateway multiplexing module rather than a gateway redundancy module. To this end, the gateway redundancy module 170 forwards the IP address change message received from the local subnet or the remote subnet to the at least one second gateway.

The gateway duplication module 170 may be configured to operate based on L4 or VRRP. Both L4 and VRRP are host multiplexing methods that allow other hosts to take over the role of a failed host even if some of the hosts fail.

L4 uses a virtual interface that has a virtual IP address shared by two gateways, and Virtual Router Redundancy Protocol (VRRP) is designed to eliminate single point of failure (SPOF) that inevitably occurs in a static default routing environment. VRRP solves the problem of static configuration resiliency by configuring a group of gateways into a single virtual gateway. Each gateway belonging to a group to form a virtual gateway is called a VRRP gateway. As such, a virtual gateway is composed of one or more VRRP gateways. The VRRP router, which currently controls the virtual gateway IP address, is called the master, and the master forwards packets sent to these virtual IP addresses. The other VRRP gateways in the group act as backups, and if a master fails, one of the backup routers becomes a new master through a selection process. VRRP not only provides redundancy, but also allows for load sharing.

7 illustrates a method in which redundant gateways share circuit multiplexing information according to the present invention.

In FIG. 7, eth0 311 and 321 of each of the first gateway 310 and the second gateway 320 represent an external interface having a real IP, and eth1 312 and 322 represent an internal interface having a real IP. eth2 (313, 323) represents a DMZ interface to which two gateways are directly connected, and may or may not exist in some cases.

When using L4, ethX (314, 324) means a virtual interface that is bound to eth0 (311, 321) and has a virtual IP address shared by both gateways.When using VRRP, it exists only in the master gateway of the two gateways. Alias IP address.

Here, the L2 / L4 switch may be an L2 switch that controls the path of the packet in the Layer 2 category (srouce MAC and destination MAC on the Ethernet Protocol) of the OSI reference model, classifies the packet in the Layer 4 category and controls the path, It may be a layer 4 switch that manages sessions occurring at layer 4 and manipulates packets for session management.

8 illustrates a multiplexing operation flow between redundant gateways according to the present invention.

FIG. 8 is a flowchart of operation when assuming the same configuration as that of the configuration of FIG. 7. First, an IP address change message arrives at one of the gateways. In the case of FIG. 8, the first gateway 310 arrives (S701). The first gateway 310 first takes action in response to the IP address change of the remote gateway. That is, the circuit multiplexing group information is updated and the information of the associated GRE device is updated (S702). The first gateway 310 compares the receiver_real field and the receiver_tlb_list field among the fields included in the IP address change message (S703). Here, the receiver_real field indicates the actual IP address of the gateway that will receive the message, and the receiver_tlb_list field indicates the address on the multiplex group configuration of the gateway that will receive the message. The first gateway 310 will confirm that the values of the two fields are the same. This is because when the remote gateway detects an IP address change and configures and sends an IP address change message, it sets both fields to the same value. Since the first gateway 310 has the same value in both fields, it recognizes that the first gateway 310 receives the IP address change message directly from the remote gateway.

The first gateway 310 checks whether there is a synchronization server to which the IP address change message should be shared. Here, the synchronization server will be the second gateway 320. After confirming the existence of the synchronization server, the first gateway 310 reconfigures the IP address change message and transmits the IP address change message to the synchronization server (S704). At this time, the first gateway 310 transmits the IP address change message by including a mark indicating that the IP address change message is not from the remote gateway but from the multiplexed synchronization server.

When the second gateway 320 receives the IP address change message transmitted by the first gateway 310 (S710), as the first gateway 310 does, the second gateway 320 also firstly performs the IP address of the remote gateway. Take action as necessary. That is, the circuit multiplexing group information is updated and the information of the associated GRE device is updated (S711).

The second gateway 320 compares the actual IP address field of the gateway to receive the message among the fields included in the IP address change message with the address field on the multiplex group configuration of the gateway to receive the message (S712). Since the reconfigured IP address change message is received from the first gateway, as a result of comparing the two fields, the second gateway 320 confirms that the values of the two fields are different (No in S713), and the IP address change message is multiplexed. It is sent from the server. This terminates the routine associated with changing the remote gateway IP address because it means that no synchronization server exists to share the IP address change message. If the second gateway 320 first receives an IP address change message from a remote location, since the two fields have the same address as a result of the comparison (Yes in S713), the reconfigured IP address change message is transmitted to the first gateway. (S714)

On the other hand, the address of the synchronization server to which the IP address change message should be shared may be any routable IP address of the synchronization server, but it is best to select the most stable line. If there is a DMZ line to which the security policy is not applied as in the case of FIG. 7, it is recommended to use this line, otherwise it is recommended to use a local subnet interface line.

The present invention provides a substantial broadband service by grouping and managing a plurality of GRE tunnels and transmitting a series of packets through several tunnels in a group. -up) Has the effect of enabling the gateway to provide uninterrupted service.

Claims (8)

Create at least one Generic Routing Encapsulation (GRE) tunnel connected to a remote gateway, configure a circuit multiplexing group consisting of the generated at least one GRE tunnel, and transmit a packet to be transmitted to a remote site at least in the circuit multiplexing group. A first gateway for distributed transmission over one GRE tunnel; Wow GRE-based including at least one second gateway to receive and share the information on the circuit multiplexing group from the first gateway, and to perform the role of the first gateway when the first gateway does not operate normally Virtual private network. The method of claim 1, The first gateway, A GRE device management module that creates or deletes a Generic Routing Encapsulation (GRE) tunnel connected to a remote gateway and updates information about the generated GRE tunnel; A circuit multiplexing information management module that manages information about a circuit multiplexing group consisting of at least one GRE tunnel generated by the GRE device management module; And A GRE-based virtual private network comprising a gateway multiplexing module for forwarding an IP address change message received from a local subnet or a remote subnet to the at least one second gateway. The method of claim 1, The information about the circuit multiplexing group, GRE-based virtual private network that includes information about pairs of IP addresses forming a tunnel, pairs of subnet addresses, circuits multiplexed into a group, and the number of multiplexed circuits. The method of claim 2, The gateway multiplexing module, GRE-based virtual private network operating based on at least one multiplexing technique, either L4 or VRRP. The method of claim 2, The gateway multiplexing module, Update the line multiplexing group information and the information of the associated GRE device according to the IP address change message received from the local subnet or the remote subnet, and compare the actual IP address of the message receiving gateway with the address in the multiplex group setting of the message receiving gateway. If the two values are the same, the GRE-based virtual private network, characterized in that it receives the IP address change message directly from the local subnet or a remote subnet, and transmits the IP address change message to the at least one second gateway. The method of claim 5, The at least one second gateway, Receiving an IP address change message from the first gateway, and updating circuit multiplexing group information and information of a related GRE device according to the information included in the received IP address change message. The method of claim 2, The first gateway, A tunnel information storage unit for storing state information on the generated GRE tunnel; An IP address management module for updating a GRE device associated with the corresponding IP address and notifying the remote gateway of the IP address change if the local gateway detects a change in the IP address of the local gateway; Circuit detection / routing management that transmits a circuit failure detection packet to detect a failure with a remote gateway, determines a circuit failure according to a response state from the remote gateway, and changes routing to a corresponding channel multiplexing group when a circuit failure occurs. module; And A scheduler for controlling the circuit detection / routing management module to transmit a circuit detection packet for each circuit multiplexing group periodically and for checking whether the IP address of the local gateway is changed periodically. GRE-based virtual private network that includes more. The method of claim 7, wherein The state information for the GRE tunnel is For each GRE tunnel, the circuit multiplexing group ID, load balancing policy, external interface IP address of the local gateway, external interface device name of the local gateway, external interface IP address of the remote gateway, line status, subnet address of the local gateway, remote A GRE-based virtual private network including at least one of a subnet address of a gateway, an internal interface IP address of a local gateway, and an internal interface IP address of a remote gateway.

Images