Failure handling device and failure handling method

Abstract

A failure handling device is used in a redundancy system (100) that operates a routing protocol between IP devices via a VxLAN that connects between switches. The failure handling device records a peer relationship between the IP devices operating the routing protocol, the peer relationship being obtained by snooping control packets of the routing protocol. When a failure occurs, the failure handling device refers to the peer relationship to acquire an IP device on the failure-location side and an IP device on the counterpart side with respect to the failure location, and, by proxy, notifies the IP device on the counterpart side with respect to the detected failure location regarding a message pertaining to failure detection of the routing protocol originally transmitted from the IP device on the failure-location side.

Description

Fault response device and fault response method

[0001] The present invention relates to a failure response device and a failure response method.

[0002] VxLAN (Virtual eXtensible Local Area Network) described in Non-Patent Document 1 is an overlay network model that overlays an L2 network on an IP (L3) network. VTEPs (Virtual Tunnel End Points), which are the tunnel endpoints (tunnel start and end points) of VxLAN, refer to the VxLAN Network Identifier (VNI) of packets passing through the tunnel and forward the packets to their destination.

[0003] M. Mahalingam et al., "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks," [online], IETF RFC7348, [Retrieved August 14, 2024], Internet <URL: https: / / datatracker.ietf.org / doc / html / rfc7348>

[0004] In the event of a failure such as a link disconnection in a network system, a redundant system that switches from a current path to an alternative path can improve fault tolerance. For this path switching, it is desirable to quickly and accurately identify the location of the failure and perform the path switching promptly. Below, we will explain an example in which VxLAN, described in Non-Patent Document 1, is applied to a redundant system.

[0005] FIG. 8 is an explanatory diagram showing a redundancy system 200 using VxLAN Multi-Homing (MH). In MH, user devices (IP devices on the user side, IP-A and IP-B) are each connected to a fault response device (SW-1, SW-2, SW-3, SW-4). This ensures redundancy even if a failure occurs in a path passing through one switch by switching to a path passing through the other switch. For example, if a failure occurs in the path from IP-A to IP-B via SW-1, IP-A receives a notification of the failure and switches to a path from IP-A to IP-B via SW-3. Therefore, each switch in an L2VPN (Layer 2 Virtual Private Network)-0 formed in the telecommunications company network is comprehensively connected (mesh-connected) to the other switches.

[0006] The connection interface (IF) between switches is shown as an LI (LINE interface) and is configured as an optical coherent module called a DCO (Digital Coherent Optics) transceiver. The connection interface between IP devices and switches is shown as a CI (CLI interface, where CLI stands for client). In other words, switches are communications devices that can be equipped with DCO transceivers. For communications between switches, individual wavelengths λ1 to λ4 are assigned to each mesh-connected link. Therefore, mesh connections require a large number of wavelengths and interfaces, resulting in higher costs.

[0007] Fig. 9 is an explanatory diagram showing a redundant system 201 using VxLAN SH (Single Homing). Compared to the redundant system 200 in Fig. 8, the number of VxLANs in the redundant system 201 in Fig. 9 is changed from one (L2VPN-0) to two (L2VPN-1, L2VPN-2). This eliminates the need for mesh connections between all switches, making it possible to reduce the number of wavelengths used and the number of switch interfaces.

[0008] Figure 10 is an explanatory diagram showing a redundant system 202 in which a failure has occurred, as opposed to the redundant system 201 in Figure 9. When SW-2 detects a failure 411 in the link between IP-B, it notifies the opposing device (SW-1) of this fact. Upon receiving the notification, SW-1 cuts off communication on the link toward the opposing device (IP-A) by setting IF disconnection 412, thereby preventing data from flowing into the location of the failure 411.

[0009] 11 is an explanatory diagram showing a redundant system 203 in which a failure has occurred in SW-2, which accommodates multiple IP devices. SW-1 accommodates multiple IP devices (IP-A, IP-C), and SW-2 accommodates multiple IP devices (IP-B, IP-D, IP-E). In this case, similar to FIG. 10, when the redundant system 203 of FIG. 11 detects a failure 411 between SW-2 and IP-B, it sets an IF disconnection 412 on the opposing device side (SW-1).

[0010] On the other hand, the link between SW-2 and IP-D is still alive, so there is a surviving path 413 between IP-A and IP-D. However, if communication between IP-A and SW-1 is cut off due to an IF disconnection 412, communication that is not affected by the failure will also become unavailable.

[0011] 12 is an explanatory diagram showing the state when a failure occurs in the redundant system 202 of FIG. IP-A and IP-B are connected to a BGP peer via L2VPN-1 and a BGP peer via L2VPN-2. Due to a failure 411 between IP-B and SW-2, the interface connecting to that link goes down ("IF DOWN, 10.1.121.2 / 24" in the figure). Due to this failure, IP-B deletes from its own routing table 422 the entry for the route (Next Hop = 10.1.121.1 / 24) heading toward IP-A via the L2VPN-1 route, thereby switching the route from L2VPN-1 to L2VPN-2.

[0012] Since IP-A's own physical IF does not go down ("IF UP, 10.1.121.1 / 24" in the figure), it detects the failure 411 when probe packets bound for IP-B are lost a certain number of times at the location of the failure 411. Upon detecting this failure, IP-A deletes from its own routing table 423 the entry for the route to IP-B via the L2VPN-1 route (Next Hop = 10.1.121.2 / 24), thereby switching the route from L2VPN-1 to L2VPN-2. In this way, route switching using probe packets waits for a certain number of probe packets to be lost, so there is a trade-off between the switching speed, which is determined by the setting of the probe packet transmission frequency, and bandwidth compression.

[0013] FIG. 13 is an explanatory diagram showing the process of identifying a suspected location when a failure occurs in the redundant system 204. Consider the case where the same tenant TA manages IP devices at two locations, C1 and C2. A maintenance person 434 at location C1 receives a notification of a failure from IP-A, which he directly operates (indicated by the upward arrow in the figure). However, although the interface of IP-A is in the UP state (IF UP), the path to IP-B in another location C2 via L2VPN-1 remains disconnected. Therefore, the maintenance person 434 has difficulty identifying the suspected location from the following possible suspected locations: A first suspected location 431: a device failure in the remote IP device (IP-B); a second suspected location 432: a failure in the telecommunications carrier section; and a third suspected location 433: a silent failure of the IF of the local IP device (IP-A).

[0014] 14 is an explanatory diagram showing the issues that arise when each switch in the redundant system 205 holds route information. The redundant system 205 employs a method in which each switch exchanges routes between each IP device it accommodates, rather than using a simple L2VPN like the redundant systems 201 to 204. For example, by exchanging routes, SW-2 holds a route table 441 that stores an entry (R-TA) for IP-B belonging to the tenant TA it accommodates and an entry (R-TA) for IP-D belonging to the tenant TB it accommodates.

[0015] Such a redundant system 205 increases maintenance costs for the following reasons: - It is a multi-tenant environment that accommodates multiple tenants, and the number of routes stored in the route table 441 increases with the number of tenants, so the network system does not scale. - Because each switch and each IP device are directly connected, the number of items that must be set by the maintenance personnel increases, and the connection requirements for the IP devices also increase.

[0016] Therefore, the main object of the present invention is to support appropriate measures according to the location of the failure while suppressing increases in maintenance costs.

[0017] In order to solve the above problems, the failure response device of the present invention comprises the following means: The present invention is a failure response device serving as a relay device used in a network system in which a routing protocol is operated between user devices via a relay network connecting relay devices, comprising: a storage unit that records peer relationships between the user devices operating the routing protocol, acquired by snooping control packets of the routing protocol, and a processing unit that, when a failure occurs, refers to the peer relationships to acquire the user device on the side of the failure location and the user device on the side opposite to the failure location, and notifies, on behalf of the user device on the side opposite to the detected failure location, a failure detection message of the routing protocol, the message originating from the user device on the side of the failure location.

[0018] According to the present invention, it is possible to suppress an increase in maintenance costs and to support appropriate measures depending on the location of the fault that has occurred.

[0019] 10 is a configuration diagram showing setting information of a redundancy system according to the present embodiment. FIG. 11 is a configuration diagram of tables stored in each device of the redundancy system according to the present embodiment. FIG. 12 is a hardware configuration diagram of each device of the redundancy system according to the present embodiment. FIG. 13 is a flowchart showing a process for notifying a failure of the redundancy system of FIG. 1 according to the present embodiment. FIG. 14 is a configuration diagram of a case where a failure occurs outside the L2VPN of the redundancy system according to the present embodiment. FIG. 15 is a configuration diagram of a case where a failure occurs within the L2VPN of the redundancy system according to the present embodiment. FIG. 16 is an explanatory diagram showing details of snooping performed in the redundancy system according to the present embodiment. FIG. 17 is an explanatory diagram showing a redundancy system using VxLAN MH. FIG. 18 is an explanatory diagram showing a redundancy system using VxLAN SH. FIG. 19 is an explanatory diagram showing a redundancy system in which a failure has occurred in the redundancy system of FIG. 9. FIG. 20 is an explanatory diagram showing a redundancy system in which a failure has occurred in a switch accommodating multiple IP devices. FIG. 21 is an explanatory diagram showing a state when a failure has occurred in the redundancy system of FIG. 22. FIG. 23 is an explanatory diagram showing the operation of identifying a suspected location when a failure has occurred in the redundancy system. FIG. 24 is an explanatory diagram showing a problem when each switch in the redundancy system holds route information.

[0020] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

[0021] Figure 1 is a configuration diagram showing the setting information of the redundant system 100. Each switch (SW-1, SW-2, SW-3, SW-4) in the VxLAN (L2VPN-1, L2VPN-2) of the redundant system 100 has the following IFs: ・LI for connecting to other switches. This LI is an optical coherent module called a DCO transceiver, and each switch is a communication device that can be equipped with a DCO transceiver. ・CI for connecting to IP devices (IP-A, IP-B).

[0022] The maintenance personnel prepares the following settings shown in Figure 1 in the steady state before a failure occurs. [First setting] Setting the IP addresses to be assigned to each link. For example, the IPv4 address "10.1.121.1 / 24" is set for the IF of IP-A connected to SW-1. [Second setting] Setting interface information that can distinguish between LI and CI for each IF of each switch. For example, for LI, information starting with "cd" such as cd1, cd2, etc. is used, and for CI, information starting with "xe" such as xe1, xe2, etc. is used. [Third setting] Setting BGP peers between IP devices (for example, between IP-A and IP-B). [Fourth setting] Setting each switch (for example, SW-1, SW-2) to snoop BGP control packets (BGP hello, BGP notification) passing through its own IF (details in Figure 7).

[0023] FIG. 2 is a diagram illustrating the configuration of tables stored in each device of the redundant system 100. The switch-side table 101 stored in SW-1 stores, as BGP peer information, the addresses of both endpoints of the BGP peers established between IP devices (BGP peer 1, BGP peer 2) and the identification information of the IFs (LINE interface, CLI interface) through which packets of the BGP peers pass, in association with each other. In this way, the CI of SW-1 stores the BGP peer information in the switch-side table 101, but does not need to store the route information exchanged by the BGP peers, making it scalable even if the number of tenants increases. Furthermore, because SW-1 does not require a BGP peer connection with IP devices, the connection requirements to IP devices can be reduced.

[0024] Among BGP control packets, BGP hello is a message used to establish and maintain BGP peers, and is periodically exchanged between established BGP peers. Therefore, SW-1 detects new BGP peers by snooping BGP hello on the link between SW-1 and IP-A, and detects a fault (interface disconnection or link disconnection) between SW-1 and IP-A if a BGP hello does not arrive within a specified time. SW-1 then stores the detection results of snooping BGP in its own switch-side table 101.

[0025] Furthermore, BGP notification, a type of BGP control packet, is a message used to notify various information such as error notifications between BGP peers, and is exchanged between BGP peers as needed. SW-1 snoops on BGP notifications indicating the termination of the BGP peer between IP-A and IP-B, and deletes the corresponding BGP peer entry from its own switch-side table 101. Furthermore, when SW-1 notifies the opposite IP-B of the CI disconnection detected between IP-A, it issues a BGP notification on behalf of IP-A.

[0026] The switch-side table 102 stored in SW-2 also stores BGP peer information in the same data format as the switch-side table 101. The IP-device-side table 103 stored in IP-A associates a next hop, a metric, and a path as route information for each destination network. This route information is learned, for example, by BGP. The IP-device-side table 104 stored in IP-B also stores route information in the same data format as the IP-device-side table 103.

[0027] FIG. 3 is a hardware configuration diagram of each device in the redundancy system 100. Each device (each IP device and each switch) in the redundancy system 100 is configured as a computer 900 having a CPU 901, RAM 902, ROM 903, HDD 904, communication I / F 905, input / output I / F 906, and media I / F 907. The communication I / F 905 is connected to an external communication device 915. The input / output I / F 906 is connected to an input / output device 916. The media I / F 907 reads and writes data from a recording medium 917. Furthermore, the CPU 901 controls each processing unit by executing a program (fault response program) loaded into the RAM 902. This program (also called an application, or an app for short) can be distributed via a communication line or recorded on a recording medium 917 such as a USB memory stick.

[0028] The failure response device as a switch is used in a redundancy system 100 that runs a routing protocol between IP devices via a VxLAN that connects the switches. The switch stores peer relationships between IP devices running the routing protocol, acquired by snooping control packets of the routing protocol, in a storage unit (RAM 902 or HDD 904) as switch-side tables 101, 102. When a failure occurs, the switch references the peer relationships to acquire the IP device on the side of the failure location and the IP device on the opposite side of the failure location, and causes a CPU 901 to operate a processing unit that sends a routing protocol failure detection message, with the IP device on the side of the failure location as the sender, to the IP device on the opposite side of the detected failure location on behalf of the IP device.

[0029] 4 is a flowchart showing the process by which SW-2 in the redundant system 100 in FIG. 1 notifies a fault. First, SW-2 snoops BGP messages from peripheral links (links directly connected to SW-2) on the CI side or LI side of its own device, and stores the acquired BGP peer information in the switch-side table 102 (S11). Then, when SW-2 detects a fault in a peripheral link of its own device, it determines whether the fault was detected outside the L2VPN (CI side) (S12).

[0030] If the result in S12 is Yes (detection on the CI side), SW-2 encapsulates a packet (BGP-N[C=9]) with code=9 set in the BGP notification field in a VxLAN header based on the BGP peer information in the switch-side table 102, and notifies the packet on behalf of IP-B within the VxLAN on the opposite side of the detection point (SW-1, the opposing side) (S13, details in Figure 5).

[0031] If the result in S12 is No (detection on the LI side), SW-2 sends a proxy notification (notification on behalf of IP-A) of a packet (BGP-N[C=10]) with BGP notification code set to 10 to the opposite side of the detection point (IP-B on the CI side) based on the BGP peer information in the switch-side table 102 (S14; see details in Figure 6). In this way, SW-2 sets the BGP notification code according to the failure location and notifies it. That is, the processing unit of SW-2 enters different identifiers (codes) in the first failure detection message (BGP-N[C=10]) notifying a failure occurring within the VxLAN and the second failure detection message (BGP-N[C=9]) notifying a failure occurring outside the VxLAN. This allows maintenance personnel to identify the failure location from the notified BGP notification code. Therefore, each IP device can switch routes quickly when a failure occurs without using probe packets.

[0032] Furthermore, the redundant system 100 in Fig. 1 does not use a method for exchanging route information between each switch and each IP device, as in the redundant system 205 in Fig. 14, and thereby achieves the following effects. SW-2 snoops the BGP hello and BGP notification on the CI side of its own device (S11), eliminating the connection between SW-2 and IP-B and reducing the connection requirements for IP devices. SW-2 stores BGP peer information (peer / IF information) on the CI side of its own device in the switch-side table 102 (S11). This allows for scalability even if the number of tenants connected to SW-2 increases.

[0033] 5 is a configuration diagram for when a failure occurs outside the L2VPN of the redundant system 100 (Yes in S12). When SW-2 detects a failure 401 on the IP-B side (CI side) by snooping BGP hellos, it generates a BGP notification packet (BGP-N[C=9] in the figure) on behalf of IP-B, with code=9 set to indicate the location of the failure (CI side). The generated BGP notification packet is a failure notification packet that includes the IP address of the source IP-B and the IP address of the destination IP-A.

[0034] SW-2 encapsulates (encapsulates) the failure notification packet in a VxLAN header and notifies (on behalf of IP-B) the failure notification packet within the VxLAN on the opposite side of the detection point (the LI side toward SW-1, the opposite side). SW-1 removes (decapsulates) the VxLAN header from the received failure notification packet and forwards the BGP notification failure notification packet to IP-A. Upon receiving the received failure notification packet, IP-A quickly switches the route from SW-1 to SW-3. As a result of this switch, IP-A deletes the route on SW-1 side where the failure occurred (the entry for Next Hop = 10.1.121.2 in the IP device side table 103 in Figure 2).

[0035] FIG. 6 is a configuration diagram showing what happens when a failure occurs within the L2VPN of the redundant system 100 (No in S12). When SW-2 detects a failure 402 on the SW-1 side (LI side) by snooping BGP hellos or the like, it generates a BGP notification packet on behalf of IP-A, with code = 10 set to indicate the location of the failure (LI side). The generated BGP notification packet is a failure notification packet containing the source IP address of IP-A and the destination IP address of IP-B. SW-2 notifies the destination IP-B of the failure notification packet on its behalf. Upon receiving the failure notification packet, IP-B quickly switches the route from SW-2 to SW-4. With this switchover, IP-B deletes the route on the SW-2 side where the failure occurred (the entry for Next Hop = 10.1.121.1 in the IP device side table 104 in FIG. 2).

[0036] Similarly, when SW-1 detects a failure 402 on the SW-2 side (LI side) by snooping BGP hellos, it generates a BGP notification packet on behalf of IP-B, with code = 10 set to indicate the location of the failure (LI side). The generated BGP notification packet is a failure notification packet that includes the source IP address of IP-B and the destination IP address of IP-A. SW-1 notifies the destination IP-A of the failure notification packet on its behalf. Upon receiving the failure notification packet, IP-A quickly switches the route from SW-1 to SW-3. As a result of this switch, IP-A deletes the route on SW-1 side where the failure occurred (the entry for Next Hop = 10.1.121.2 in the IP device side table 103 in Figure 2).

[0037] On the other hand, if IP-A detects a failure due to a packet not arriving or the like, but does not receive notification of either BGP-N[C=9] in FIG. 5 or BGP-N[C=10] in FIG. 6, it is determined to be a silent failure on the IP-A side (for example, an IF failure in IP-A). In this way, the administrator of IP-A (maintenance person 434 in FIG. 13) can identify the suspected location of a failure that occurred in the redundant system 100 from the following suspected location candidates. - As the first suspected location, a device failure in the peer IP device (IP-B) (as indicated by the display indicating that BGP-N[C=9] was received in FIG. 5). - As the second suspected location, a failure in the telecommunications carrier section (as indicated by the display indicating that BGP-N[C=10] was received in FIG. 6). - As the third suspected location, a silent failure of the IF in the local IP device (IP-A) (as indicated by the display indicating that BGP-N was not received).

[0038] FIG. 7 is an explanatory diagram showing details of snooping performed in the redundant system 100. In the redundant system 100, BGP peers are running between the IP devices (between IP-A and IP-B) described in FIG. 1. Furthermore, in the redundant system 100, BGP is also used as a BGP underlay for the VxLAN overlay between switches (between SW-1 and SW-2) (for example, the fault notification packet encapsulated in the VxLAN header in FIG. 5). Each switch snoops only BGP messages used by BGP peers between IP devices. In other words, each switch excludes BGP packets encapsulated in the VxLAN header from being snooped. For example, SW-2 snoops the following two types of packets: - CLI ingress packets before encapture. - CLI egress packets after decapture.

[0039] That is, the processing unit of the switch encapsulates the second failure detection message (BGP-N[C=9]) for communication over VxLAN and then transmits it to the switch that is directed to the IP device on the other side (Figure 5).The processing unit of the switch then excludes the encapsulated second failure detection message from being subject to snooping.

[0040] [effect]

[0041] The present invention provides a fault response device (SW-2) as a switch used in a network system (redundant system 100) that runs a routing protocol (BGP) between IP devices via a VxLAN that connects the switches. The fault response device is characterized by having: a storage unit that records peer relationships between IP devices running the routing protocol, acquired by snooping control packets of the routing protocol; and a processing unit that, when a fault occurs, references the peer relationships to acquire the IP device on the fault location side and the IP device opposite the fault location, and notifies the IP device opposite the detected fault location of a fault detection message of the routing protocol, with the IP device on the fault location side as the sender, on behalf of the IP device.

[0042] This eliminates the need for the fault response device to exchange routes with IP devices as a BGP peer endpoint and to maintain its own routing table. As a result, the fault response device can support appropriate responses according to the location of the fault while suppressing increases in maintenance costs.

[0043] The present invention is characterized in that the processing unit of the fault response device enters different identifiers in the first fault detection message that notifies of a fault that has occurred within the VxLAN and the second fault detection message that notifies of a fault that has occurred outside the VxLAN.

[0044] As a result, an IP device that receives a failure detection message can identify the location of the failure by referencing the identifier in the failure detection message.

[0045] The present invention is characterized in that the processing unit of the failure response device encapsulates the second failure detection message for communication over VxLAN and then transmits it to the switch heading toward the opposing IP device, and excludes the encapsulated second failure detection message from being subject to snooping.

[0046] This allows the second failure detection message to be distinguished from a failure detection message of a normal routing protocol, thereby preventing the second failure detection message notified by proxy from being detected as a duplicate failure detection message with a regular failure detection message notified between IP devices.

[0047] 100 Redundant system 101 Switch side table 102 Switch side table 103 IP device side table 104 IP device side table 401 Failure 402 Failure 411 Failure 412 IF disconnection 413 Survival path IP-A to IP-E IP devices (user devices) SW-1 to SW-4 Switches (failure response devices)

Claims

1. A fault response device serving as a relay device used in a network system in which a routing protocol is operated between user devices via a relay network connecting relay devices, the fault response device comprising: a memory unit that records peer relationships between the user devices that operate the routing protocol, acquired by snooping control packets of the routing protocol; and a processing unit that, when a fault occurs, references the peer relationships to acquire the user device on the side of the fault location and the user device on the side opposite the fault location, and notifies the user device on the side opposite the detected fault location of a fault detection message of the routing protocol sent from the user device on the side of the fault location on behalf of the user device.

2. The fault response device described in claim 1, characterized in that the processing unit enters different identifiers in a first fault detection message that notifies of a fault that has occurred within the relay network and a second fault detection message that notifies of a fault that has occurred outside the relay network.

3. The fault response device described in claim 2, characterized in that the processing unit encapsulates the second fault detection message for communication through the relay network and then transmits it to the relay device heading toward the user device on the opposite side, and excludes the encapsulated second fault detection message from being subject to snooping.

4. A fault response device is a relay device used in a network system in which a routing protocol is operated between user devices via a relay network connecting relay devices, the fault response device having a memory unit and a processing unit, the memory unit records peer relationships between the user devices operating the routing protocol obtained by snooping control packets of the routing protocol, and the processing unit, when a fault occurs, refers to the peer relationships to obtain the user device on the side of the fault location and the user device on the side opposite to the fault location, and notifies the user device on the side opposite to the detected fault location of a fault detection message of the routing protocol sent as a sender on behalf of the user device on the side of the fault location.

Images