Path information management device and path information management method for overlay network

Abstract

The present invention makes it possible to reduce the number of pieces of information required when managing path information for a plurality of VPNs superimposed on a network in an EVPN-VXLAN network or the like. Registration information pertaining to a path is created on the basis of the result of aggregating, between devices having the same configuration, a plurality of pieces of path information representing a VPN. In cases where a VLAN environment is in a VLAN-based mode, common path registration information representing VPN paths having the same configuration and path registration information representing a correspondence relationship between the network ID and one piece of the common path registration information are created. When all VPNs are detected to be in a full-mesh connection state in cases where the VLAN environment is in a VLAN recognition mode, a VRF table is created in which there is registered a list of transfer destination VXLAN tunnel end points aggregated into one set without distinction of network IDs.

Description

Overlay network routing information management device and routing information management method The present invention relates to a routing information management device and a routing information management method for an overlay network, and in particular to a technique for reducing the amount of information required for management. For example, Non-Patent Document 1 discloses VXLAN (Virtual eXtensible Local Area Network), which is a general network virtualization overlay protocol. In addition, Ethernet Virtual Private Network (EVPN) is used as an overlay control plane to realize virtual connectivity between different Layer 2 / 3 domains over IP or MPLS networks. EVPN-VXLAN, which combines the above-mentioned Ethernet Virtual Private Network and network virtualization overlay protocols, is an open, standardized technology that enables connection between geographically dispersed locations via Layer 2 virtual bridges. It also creates a network fabric that extends Layer 2 connectivity as a network overlay on an existing physical network, eliminating the limitations of typical VLAN-based networks. Furthermore, EVPN-VXLAN can achieve the scale required by cloud service providers, and is therefore often used as an interconnection technology for multiple networks in data centers and other locations. Mahalingam, et al., "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, August 2014. Figure 1 shows an example of the configuration of an EVPN-VXLAN network 10 that employs a spine-leaf architecture, which is one of the common network topologies in data centers. In such a spine-leaf architecture, there are two switching layers: a spine and a leaf. 1, the spine layer 11 includes a plurality of spine switches 11a and 11b, and the leaf layer 12 includes a plurality of leaf switches 12a, 12b, and so on. Furthermore, a plurality of virtual machines (VMs) 13 are connected to the leaf switches 12a, and a plurality of virtual machines 14 are connected to the leaf switches 12b. Furthermore, a plurality of virtual machines 15 are connected to the leaf switches 12c, and a plurality of virtual machines 16 are connected to the leaf switches 12d. Each of the spine switches 11a and 11b in the spine layer 11 is connected to each of the leaf switches 12a, 12b, ... in the leaf layer 12 via a physical transmission path 17. In addition, a plurality of L2 virtual tunnels 18 constituting a virtual private network (VPN) are formed in an overlapping state on the communication network that uses the physical transmission path 17. 1, all L2 virtual tunnels 18 are connected in a full mesh configuration between the leaf switches 12a to 12d. Also, in the example of Fig. 1, there are multiple L2 virtual tunnels 18 that connect the same leaf switches via a common route. As shown in Fig. 1, it is considered that there are relatively many usage patterns in which multiple L2 virtual tunnels 18 with the same route are independently constructed on the same EVPN-VXLAN network 10. Each L2 virtual tunnel 18 on such an EVPN-VXLAN network 10 is expected to transfer BUM (Broadcast / Unknown unicast / Multicast) frames, which are general traffic. When BUM frames are forwarded using the "head end replication" method, signal frames are copied at the tunnel entrance of a VXLAN tunnel endpoint called a VTEP. Therefore, each leaf switch 12a to 12d, etc., needs to hold the address of the VXLAN tunnel endpoint at the tunnel exit in order to manage the route of each L2 virtual tunnel 18. Furthermore, when BUM frames are forwarded using the multicast method, they need to hold the destination multicast address in order to manage the route of the L2 virtual tunnel 18. There are two generally assumed methods for managing the routes of the L2 virtual tunnel 18: a VLAN-based method and a VLAN-aware method. The VLAN-based method is a method in which a MAC VRF is separated for each VPN. In this VLAN-based method, multiple routing tables (routing instances) can be held on a router or switch as VRFs (Virtual Routing and Forwarding). The VLAN-aware method is a method in which all VPNs are maintained in a single VRF. In the case of the VLAN-aware method, all VPNs are managed in a single routing table. In the case of the VLAN-based method, a plurality of VRF tables 21A and 21B shown in FIG. 2 are created to manage the paths of the L2 virtual tunnel 18, for example. 2, each of the VRF tables 21A and 21B holds one or more registration information (entries) that indicate the correspondence between the virtual network identifier 21a and the MAC address of the forwarding destination VXLAN tunnel endpoint 21b. The two VRF tables 21A and 21B correspond to different VPNs. The first VRF table 21A has the virtual network identifier 21a.

[10001] The second VRF table 21B manages the VPN of the virtual network identifier 21a.

[10002] We manage the VPN. For example, according to the contents of the VRF table 21A in FIG. The BUM frame input to the VPN of

[10001] is forwarded to each of the destination VXLAN tunnel endpoints [31.31.31.31], [32.32.32.32], [33.33.33.33], and [34.34.34.34]. On the other hand, in the case of the VLAN recognition method, a VRF table 22 shown in FIG. 3, for example, is created to manage the route of the L2 virtual tunnel 18 . 3 holds one or more pieces of registration information that indicate the correspondence between a virtual network identifier 22 a and a forwarding destination VXLAN tunnel endpoint 22 b. This VRF table 22 holds and manages information on multiple VPNs with different virtual network identifiers 22 a in the same table. For example, from the contents of each VRF table 22 in FIG. 3, the virtual network identifier 21a is The BUM frame input to the VPN of

[10001] is forwarded to each of the destination VXLAN tunnel endpoints [31.31.31.31], [32.32.32.32], [33.33.33.33], and [34.34.34.34]. However, in the example shown in Fig. 2, the contents of the four forwarding destination VXLAN tunnel endpoints 21b in the first VRF table 21A and the contents of the four forwarding destination VXLAN tunnel endpoints 21b in the second VRF table 21B have the same values. VPN of

[10001] and virtual network identifier 21a Although the VPNs of

[10002] share a common route, the VRF tables 21A and 21B hold two sets of registration information as independent information in order to manage them. Also in the example shown in FIG. 3, the virtual net identifier 22a The value of the route in the management data 22c of the VPN of

[10001] and the virtual network identifier 22a are The value of the route in the management data 22d of the VPN of

[10002] is the same as that of the virtual network identifier 22a. VPN of

[10001] and virtual network identifier 22a Although the VPNs

[10002] share a common route, the registration information is stored separately in a single VRF table 22 as two sets of independent information in order to manage them. As mentioned above, existing technologies have the problem of having to maintain the same information for each VPN because they manage the routes for each VPN. Therefore, even in situations where no MAC addresses of devices connecting to the VPN are learned, entries must be maintained for the number of VPNs multiplied by the number of opposing VLAN tunnel endpoints to build a VXLAN tunnel. High-speed signal processing is particularly necessary for computer networks used in data centers, and technology that reduces the amount of data required to manage routes for multiple VPNs is extremely important in order to simplify hardware configuration. The present invention has been made in consideration of the above-mentioned circumstances, and aims to provide a route information management device and a route information management method for an overlay network that can reduce the amount of information required to manage VPN routes. (1) The overlay network routing information management device of the present invention is a routing information management device that manages routing information of a plurality of virtual networks superimposed on a predetermined computer network as an overlay network, a route information management unit that creates route registration information based on a result of aggregating a plurality of route information representing the virtual network with the same configuration; The present invention is characterized by comprising: (2) A method for managing routing information for an overlay network according to the present invention is a method for managing routing information for a plurality of virtual networks superimposed on a predetermined computer network as an overlay network, the method comprising: The method is characterized in that route registration information is created based on the result of aggregating a plurality of route information representing the virtual network with the same configuration. The overlay network route information management device and route information management method of the present invention can reduce the amount of information required to manage VPN routes. That is, since route registration information is created based on the result of aggregating multiple route information with the same configuration, the data volume of the registration information can be reduced when multiple VPNs with common routes are handled simultaneously. 1 is a block diagram showing an example of the configuration of an EVPN-VXLAN network. FIG. 2 is a schematic diagram showing an example of the configuration of a plurality of VRF tables created in a VLAN-based environment. FIG. 3 is a schematic diagram showing an example of the configuration of a VRF table created in a VLAN-aware environment. FIG. 4 is a block diagram showing an example of the configuration of a leaf switch. FIG. 5 is a schematic diagram showing an example of the configuration of a plurality of VRF tables created in a VLAN-based environment. FIG. 6 is a schematic diagram showing an example of the configuration of route registration information and common route registration information created in a VLAN-based environment in an embodiment of the present invention. FIG. 7 is a schematic diagram showing an example of the configuration of a VRF table created in a VLAN-aware environment. FIG. 8 is a flowchart showing an example of characteristic processing in a route information management unit inside a leaf switch or the like. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to the accompanying drawings. <Examples of environments to which the present invention is applied> The overlay network routing information management device and routing information management method of the present invention can be applied to a computer network having a configuration similar to that of the EVPN-VXLAN network 10 of FIG. 1, which has already been described. Each of the leaf switches 12a to 12d in Fig. 1 is configured, for example, as shown in Fig. 4. That is, each of the leaf switches 12a to 12d is provided with interfaces 31, 32, a switch unit 33, a route information management unit 34, and a data holding unit 35. The interface 31 has a plurality of communication ports. Each communication port of the interface 31 is connected to a plurality of spine switches 11a and 11b via a physical transmission path 17. The interface 32 has a plurality of communication ports. Each communication port of the interface 32 is connected to a plurality of virtual machines 13. The switch unit 33 can perform switching of a BUM frame contained in a signal frame input / output via each communication port of the interfaces 31 and 32 according to the transfer path of the corresponding L2 virtual tunnel 18 . The data storage unit 35 stores data such as a routing table required for managing the route of each L2 virtual tunnel 18. The switch unit 33 controls the route of each BUM frame to be transferred in accordance with the contents of the routing table stored in the data storage unit 35. The route information management unit 34 performs management such as updating each L2 virtual tunnel 18 according to messages received from each route, etc. The route information management unit 34 reflects the information of the updated L2 virtual tunnel 18 in the contents of the routing table in the data holding unit 35. <Example of routing table configuration> - <For VLAN-based method> --<Generally configured VRF table> FIG. 5 shows an example of the configuration of multiple VRF tables created in a VLAN-based environment. In the example shown in Figure 5, a situation is assumed in which a VRF table is created to manage the routes of each of four L2 virtual tunnels 18. Therefore, four VRF tables 23A, 23B, 23C, and 23D are created as shown in Figure 5. That is, the first VRF table 23A has a virtual network identifier 23a The second VRF table 23B holds data on multiple forwarding destination VXLAN tunnel endpoints 23b in the L2 virtual tunnel 18 of

[10001] . The third VRF table 23C holds data on a plurality of forwarding destination VXLAN tunnel endpoints 23b in the L2 virtual tunnel 18 of

[10002] .

[10003] The fourth VRF table 23D holds data of a plurality of forwarding destination VXLAN tunnel endpoints 23b in the L2 virtual tunnel 18.

[10004] The L2 virtual tunnel 18 stores data on a plurality of destination VXLAN tunnel endpoints 23b. 5, the VRF tables 23A, 23B, 23C, and 23D hold four, four, two, and two pieces of registration information (entries), respectively. That is, in order to manage the routes of four L2 virtual tunnels 18 with the same configuration, a total of 12 pieces of registration information must be held in the data holding unit 35. --<VRF table created in this embodiment> FIG. 6 shows an example of the configuration of route registration information and common route registration information created in a VLAN-based environment in an embodiment of the present invention. 6, similar to the case of Fig. 5, it is assumed that a VRF table is created in a situation where the routes of four L2 virtual tunnels 18 are managed. However, the example shown in Fig. 6 corresponds to the result of performing special processing, as will be described later. Therefore, as shown in FIG. 6, modified VRF tables 24A, 24B, 24C, and 24D are created as the route registration information 24, and two common route tables 25A and 25B are created as the common route registration information 25. Each of the modified VRF tables 24A to 24D holds one or more sets of information that represent the relationship between a virtual network identifier 24a, a forwarding destination VXLAN tunnel endpoint 24b, and referenced table information 24c. Here, "0.0.0.0" shown in the forwarding destination VXLAN tunnel endpoint 24b means that the forwarding destination information exists in the referenced table shown in the following referenced table information 24c. Furthermore, "VRF90001" shown in the referenced table information 24c means that the referenced table name is "VRF90001." In FIG. 6, each of the four modified VRF tables 24A to 24D holds only one set of information representing the respective paths of the four L2 virtual tunnels 18. The common route table 25A is created with the table name "VRF90001" and holds one or more sets of registered information indicating the correspondence between the "VRF90001" of the common tunnel ID 25a and the forwarding destination VXLAN tunnel endpoint 25b. The common route table 25B is created with the table name "VRF90002" and holds one or more sets of registered information indicating the correspondence between the "VRF90002" of the common tunnel ID 25a and the forwarding destination VXLAN tunnel endpoint 25b. When the routing information shown in FIG. 6 is used, for example, the virtual network identifier 24a is The modified VRF table 24C and the common route table 25B are used when controlling the BUM frame forwarding of the L2 virtual tunnel 18 of

[10003] . That is, the contents of the common route table 25B are referenced according to "VRF90002" indicated in the reference destination table information 24c in the modified VRF table 24C, and the forwarding destination of the corresponding BUM frame can be determined to be [31.31.31.31] and [32.32.32.32] of the forwarding destination VXLAN tunnel endpoints 25b. 6, the modified VRF tables 24A, 24B, 24C, and 24D and the common route tables 25A and 25B hold 1, 1, 1, 1, 4, and 2 pieces of information, respectively. That is, the total number of registered information items required to manage the routes of the four L2 virtual tunnels 18 is 10, which is a reduction of two pieces of data compared to the "12" in the example shown in FIG. - <For VLAN recognition method> --<Generally configured VRF table> FIG. 7 shows an example of the structure of a VRF table created in a VLAN-aware environment. In the example shown in Figure 7, it is assumed that a VRF table is created in a situation where the routes of four L2 virtual tunnels 18 are managed. Therefore, as shown in Figure 7, four pieces of management data 26a, 26b, 26c, and 26d for each VPN are registered as registration information in a single VRF table 26. In the example shown in FIG. 7, the management data 26a includes a virtual network identifier The management data 26b holds four sets of data, [31.31.31.31], [32.32.32.32], [33.33.33.33], and [34.34.34.34], as the forwarding destination VXLAN tunnel endpoints of the L2 virtual tunnel 18 of

[10001] . Four sets of data, [31.31.31.31], [32.32.32.32], [33.33.33.33], and [34.34.34.34], are stored as the destination VXLAN tunnel endpoints of the L2 virtual tunnel 18 of

[10002] . In addition, the management data 26c includes a virtual network identifier The management data 26c holds two sets of data, [31.31.31.31] and [32.32.32.32], as the forwarding destination VXLAN tunnel endpoints of the L2 virtual tunnel 18 of

[10003] . Two sets of data, [31.31.31.31] and [32.32.32.32], are held as the destination VXLAN tunnel endpoints of the L2 virtual tunnel 18 of

[10004] . That is, in the example of FIG. 7, in order to manage the routes of four L2 virtual tunnels 18 with the same configuration, a total of 12 pieces of registration information must be held in the VRF table 26. --<VRF table created in this embodiment> FIG. 8 shows an example of the structure of a modified VRF table created in a VLAN-aware environment in an embodiment of the present invention. In the example shown in Fig. 8, as in the case of Fig. 7, it is assumed that a VRF table is created in a situation where the routes of four L2 virtual tunnels 18 are managed. However, the example shown in Fig. 8 corresponds to the result of performing special processing, as will be described later. In addition, it is assumed that the tunnel configuration is a full-mesh connection between all leaves for all VPNs under management. 8, the modified VRF table 27 holds four sets of registered information indicating the correspondence between the virtual network identifier 27a and the forwarding destination VXLAN tunnel endpoint 27b. In addition, to indicate that all VPNs have the same tunnel configuration, [0] is registered for all virtual network identifiers 27a. Therefore, when the contents of the modified VRF table 27 shown in Figure 8 are used, the destination VXLAN tunnel endpoints of the BUM frames forwarded by each of all VPNs will be the four shown in the destination VXLAN tunnel endpoint 27b: [31.31.31.31], [32.32.32.32], [33.33.33.33], and [34.34.34.34]. Furthermore, when the modified VRF table 27 shown in Figure 8 is used, the total number of pieces of registered information required to manage the routes of the four L2 virtual tunnels 18 is four, which is significantly reduced compared to the total number of pieces of registered information (12 pieces) when the VRF table 26 shown in Figure 7 is used. In a VLAN-aware environment, multiple L2 virtual tunnels 18 are managed by a single VRF table, so the coexistence of L2 virtual tunnels 18 with different tunnel configurations will cause unnecessary flooding. Therefore, it is necessary to avoid the coexistence of L2 virtual tunnels 18 with different tunnel configurations. <Operation of Route Information Management Unit in the Embodiment> FIG. 9 shows an example of characteristic processing in the routing information management unit 34 inside the leaf switch. In the EVPN-VXLAN network 10 configured as shown in Figures 1 and 4, the leaf switches 12a to 12d send each other messages called "BGP update type 3" to exchange information necessary for managing the L2 virtual tunnel 18 created between the multiple leaf switches 12a to 12d. Specifically, the method for forwarding BUM frames is exchanged using a "BGP update type 3" message. BUM frames must be forwarded to all of the opposing leaf switches. When "head-end replication," one of the forwarding methods, is used, each leaf switch 12a to 12d copies the input BUM frame and transmits it to all of the opposing leaf switches. Also, if a multicast network has been constructed in advance within the leaf-spine, each spine switch 11a, 11b copies the received BUM frame and transmits it to each of the opposing leaf switches 12a to 12d. In this embodiment, the route information management unit 34 in each of the leaf switches 12a to 12d executes the process shown in Fig. 9 in accordance with the received "BGP update type 3" message, and updates the data in the routing table in the data storage unit 35. As a result of this process, the contents of the route registration information 24 and common route registration information 25 shown in Fig. 6 and the modified VRF table 27 shown in Fig. 8 are created in the data storage unit 35. The process of the route information management unit 34 shown in FIG. 9 will be described below. In step S11, the route information management unit 34 identifies the type of environment for managing each VPN, i.e., the route of the L2 virtual tunnel 18. If the type of environment is the VLAN-based method, the process proceeds from step S11 to S12, and if the type is the VLAN-aware method, the process proceeds from step S11 to S18. In fact, the route information management unit 34 can distinguish between the VLAN-based method and the VLAN-aware method, for example, based on the on / off state of a specified manual switch that can be operated by the administrator operating the EVPN-VXLAN network 10, or the state of specific unique data that can be updated by the administrator. The routing information management unit 34 receives a "BGP update type 3" message instructing the addition of a new VPN (step S12). The routing information management unit 34 then compares the new VPN with information on other VPNs already registered in the routing table of the data storage unit 35, and determines whether a VPN with the same combination of the new VPN and destination VLAN tunnel endpoint address already exists (step S13). If a VPN already exists, the process proceeds to step S14; if a VPN does not already exist, the process proceeds to step S16. In step S14, the route information management unit 34 identifies whether or not a VRF table to be used when forwarding a BUM frame exists for the VPN. If a VRF table exists, the process proceeds to step S15, and if not, the process proceeds to step S17. For example, in FIG. 5, the virtual net identifier 23a is In a state where the VRF corresponding to the VPN of

[10001] , i.e., the routing information of the VRF table 23A, already exists, the virtual network identifier 23a is 5, the combination of the forwarding destination VXLAN tunnel endpoint 23b in the VRF table 23A is the same as the combination of the forwarding destination VXLAN tunnel endpoint 23b in the VRF table 23B, so the process proceeds from step S13 to step S14. If a VRF table to be used when transferring a BUM frame for the VPN exists, the routing information management unit 34 adds the destination VLAN tunnel endpoint address to the VRF table (step S15). After that, the process returns to step S12. If there is no VRF table to be used when forwarding a BUM frame for the VPN, the route information management unit 34 creates a new VRF table and registers the "destination VLAN tunnel endpoint list" (step S17). For example, in FIG. 5, assume that a new VPN is added when the VRF table 23A already exists. Then, if there is no VRF table 23B yet in step S17, route information corresponding to this VRF table 23B is added. In step S17, the route information management unit 34 actually creates, for example, the modified VRF table 24B shown in Fig. 6. The route information management unit 34 also creates, for example, the common route table 25A shown in Fig. 6 as this "destination VLAN tunnel endpoint list." Furthermore, the route information management unit 34 adds an entry so that the "destination VLAN tunnel endpoint list" of the common route table 25A can be referenced from the modified VRF table 24B (step S18). Then, the process returns to step S12. In step S18, the route information management unit 34 specifically registers "VRF90001" indicating the common route table 25A as the reference table information 24c of the modified VRF table 24B. The route information management unit 34 also sets the content of the forwarding destination VXLAN tunnel endpoint 24b in the modified VRF table 24B to "0.0.0.0." Here, since both of the two modified VRF tables 24A and 24B can identify the "destination VLAN tunnel endpoint list" by referring to the contents of the same common route table 25A, there is no need to include the contents of the "destination VLAN tunnel endpoint list" in each modified VRF table 24A and 24B. On the other hand, if a VRF table for a VPN with the same combination of the VPN to be added and the destination VLAN tunnel endpoint address does not yet exist, the route information management unit 34 registers the opposite VLAN tunnel endpoint address in the VRF of the VPN in step S16. For example, after registering the two modified VRF tables 24A and 24B and the common route table 25A shown in FIG. 6, if the virtual network identifier 24a is

[20003] 5, or the modified VRF table 24C and the common route table 25B in FIG. 6. On the other hand, if the VLAN environment is a VLAN-aware environment, the routing information management unit 34 determines whether the tunnel configurations of all VPNs conform to predetermined constraints in step S18. Specifically, it determines whether the tunnel configurations of all VPNs are in a state where all leaf switches are connected in a full mesh. In practice, the route information management unit 34 can determine in step S18 whether or not a full-mesh connection is in effect based on, for example, the on / off state of a predetermined manual switch that can be operated by the administrator who operates the EVPN-VXLAN network 10, or the state of specific unique data that can be updated by the administrator. If a full-mesh connection is in effect, the process proceeds from step S18 to S19, and if a full-mesh connection is not in effect, the process proceeds to step S21. When the route information management unit 34 receives the message "BGP update type 3" instructing the addition of a new VPN in step S19, the process proceeds to the next step S20, where the address is added to the modified VRF table 27 used when forwarding the BUM frame. In this case, all VPNs are fully meshed and there is no difference in configuration between VPNs, so the content of the virtual net identifier 27a in the modified VRF table 27 is set to [0]. Furthermore, the content of the destination VXLAN tunnel endpoint 27b is common to all VPNs, so only one set is registered as registered information. Therefore, for example, the four sets of management data 26a, 26b, 26c, and 26d for each VPN in the VRF table 26 shown in FIG. 7 are aggregated into one set of information for the destination VXLAN tunnel endpoint 27b in the modified VRF table 27 in FIG. 8. If the full-mesh connection condition is not met, the route information management unit 34 performs standard processing in step S21. In this case, registration information such as the VRF table 26 shown in FIG. 7 is created. <Features of the present invention> The characteristics of the overlay network routing information management device and routing information management method of the present invention are listed in the following [1] to [4]. [1] A routing information management device that manages routing information of a plurality of virtual networks superimposed on a predetermined computer network as an overlay network, a route information management unit (34) that creates route registration information based on the result of aggregating a plurality of route information representing the virtual network with the same configuration; A routing information management device for an overlay network comprising: According to the overlay network routing information management device configured as described above in [1], VPNs with the same tunnel configuration are consolidated and managed as a single unit, which makes it possible to significantly reduce the amount of data to be registered in routing tables that manage VPN routes. This simplifies the hardware configuration of network switches that require high-speed signal processing. [2] When the route information management unit detects a plurality of pieces of route information having a common configuration representing the virtual network, the route information management unit aggregates the plurality of pieces of common route information into one piece of route information; Common route registration information (25) created for each common route; Create route registration information (24) that indicates a correspondence between the network identification information of the virtual network and one of the common route registration information (step S17). The routing information management device for an overlay network according to [1] above. According to the overlay network route information management device having the configuration [2] above, even when managing multiple VPNs with different tunnel configurations, information can be aggregated for each VPN with a common configuration, making it possible to significantly reduce the amount of data to be registered in routing tables that manage VPN routes. [3] When the route information management unit detects that the inputs and outputs of the virtual network are connected in a full mesh configuration, it aggregates multiple pieces of route information into one piece of route registration information, and when it detects an update to the virtual network, it adds a destination address of the new virtual network to the route registration information (step S20). The routing information management device for an overlay network according to [1] above. According to the overlay network route information management device having the configuration [3] above, information on multiple VPNs is aggregated on the assumption that the tunnel configurations of all VPNs handled are the same, so it is possible to significantly reduce the amount of data to be registered in routing tables that manage VPN routes. [4] A route information management method for managing route information of a plurality of virtual networks superimposed on a predetermined computer network as an overlay network, comprising: Based on the result of aggregating multiple pieces of route information representing the virtual network with the same configuration, route registration information is created (steps S13 to S17, S18 to S20). A method for managing routing information in an overlay network. According to the overlay network routing information management method described in [4] above, VPNs with the same tunnel configuration are consolidated and managed as a single unit. This makes it possible to significantly reduce the amount of data to be registered in routing tables that manage VPN routes. Furthermore, it is possible to simplify the hardware configuration of network switches that require high-speed signal processing. 10 EVPN-VXLAN Network 11 Spine layer 11a, 11b spine switch 12 Leaf layer 12a, 12b, 12c, 12d leaf switches 13, 14, 15, 16 Virtual Machine 17 Physical Transmission Path 18 L2 Virtual Tunnels 21A, 21B, 22 VRF tables 21a, 22a Virtual network identifier 21b, 22b Destination VXLAN tunnel endpoint 22c, 22d Management data 23A, 23B, 23C, 23D VRF tables 23a Virtual Net Identifier 23b Destination VXLAN tunnel endpoint 24 Route registration information 24A, 24B, 24C, 24D Modified VRF Tables 24a Virtual Net Identifier 24b Destination VXLAN tunnel endpoint 24c Reference table information 25 Common Route Registration Information 25A, 25B Common Route Table 25a Common Tunnel ID 25b Destination VXLAN tunnel endpoint 26 VRF Table 27 Transformed VRF Table 26a, 26b, 26c Management data 27a Virtual Net Identifier 27b Destination VXLAN tunnel endpoint 31, 32 Interface 33 Switch section 34 Route information management unit 35 Data storage unit

Claims

1. A route information management device for an overlay network that manages route information for multiple virtual networks superimposed on a specified computer network as an overlay network, comprising: a route information management unit that creates route registration information based on the result of aggregating multiple route information representing the virtual networks with the same configuration.

2. The overlay network route information management device of claim 1, wherein when the route information management unit detects multiple pieces of route information with a common configuration representing the virtual network, it aggregates the multiple pieces of common route information into one, and creates common route registration information created for each common route, and route registration information representing the correspondence between network identification information of the virtual network and one of the pieces of common route registration information.

3. The route information management device for an overlay network described in claim 1, wherein the route information management unit aggregates multiple pieces of route information into one piece of route registration information when it detects that the inputs and outputs of the virtual network are connected in a full mesh form, and adds the destination address of the new virtual network to the route registration information when it detects an update to the virtual network.

4. A route information management method for managing route information for multiple virtual networks superimposed on a specified computer network as an overlay network, which creates route registration information based on the result of aggregating multiple route information representing the virtual networks with the same configuration.

Images