Remote notification system and remote notification method

Abstract

A remote notification system (100) notifies a reception device (80) of a notification packet (60) generated by a transmission device (70). A communication tunnel is constructed between the transmission device (70) and the reception device (80). The transmission device (70) generates the notification packet (60) in which a tunnel header for causing setting information that is for improving operation efficiency and that is set in the transmission device (70) to pass through the communication tunnel is encapsulated, and notifies the reception device (80) of the notification packet (60) from the communication tunnel.

Description

Remote notification system and remote notification method

[0001] The present invention relates to a remote notification system and a remote notification method.

[0002] The network model called EVPN (Ethernet (registered trademark) Virtual Private Network) / VXLAN (Virtual Extensible Local Area Network) uses VXLAN described in Non-Patent Document 1 as a data plane and EVPN as a control plane for controlling the data plane.

[0003] VXLAN 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 of a VXLAN, refer to the VNI (VXLAN Network Identifier) ​​of packets passing through the tunnel and forward them to their destination.

[0004] EVPN uses protocols such as MP-BGP (Multi Protocol Border Gateway Protocol), which can exchange information across multiple protocols, to exchange address information (MAC addresses, IP addresses) at tunnel endpoints, making it possible to set up tunnels between VTEPs.

[0005] M. Mahalingam et al., "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks," RFC7348, [online], [Retrieved April 25, 2024], Internet <URL: https: / / www.rfc-editor.org / rfc / rfc7348.txt>

[0006] In overlay network operations, there are two types of tunnel endpoint redundancy methods: EVPN Multihome and MP-BGP. Because these redundancy methods differ in the way routes are maintained, tunnel endpoint administrators must understand which redundancy method each tunnel endpoint uses. Meanwhile, MP-BGP, used in conventional EVPN / VXLAN (see Non-Patent Document 1), exchanges essential information for enabling communication between tunnel endpoints, such as address information set at tunnel endpoints in BGP update packets and the BUM (Broadcast, Unknown Unicast, Multicast) forwarding method. However, conventional MP-BGP does not exchange information (additional information) that is not essential for packet forwarding, such as the redundancy method.

[0007] In addition, existing technologies for exchanging additional information include LLDP (Link Layer Discovery Protocol) and DCBX (Data Center Bridging Capability Exchange protocol). However, both LLDP and DCBX only obtain additional information from adjacent nodes directly connected to the devices, and cannot obtain additional information from non-adjacent (remote) tunnel endpoints.

[0008] Figure 9 shows the configuration of a network system operated using DCBX. A first administrator manages three switches using a switch management device, while a second administrator manages two servers using a server management device. DCBX, which utilizes the LLDP protocol, is used between adjacent devices (between switches and between switches and servers). This allows the switches and servers to exchange additional information, such as DCB (Data Center Bridging) capabilities, and also prevents mismatches between their configurations.

[0009] This allows the second administrator to obtain additional information about the switch via the server without knowing the switch's operating system (the wavy arrow in the figure). Similarly, the first administrator can obtain additional information about the server via the switch without knowing the server's operating system (the wavy arrow in the figure). However, because DCBX cannot be used between non-adjacent devices, additional information cannot be exchanged between them.

[0010] Therefore, a main object of the present invention is to allow information that is not essential for packet forwarding set in a remote device to be exchanged between tunnel endpoints.

[0011] In order to solve the above problems, the remote notification system of the present invention comprises the following means: The present invention is a remote notification system for notifying a receiving device of a notification packet generated by a transmitting device, wherein a communication tunnel is constructed between the transmitting device and the receiving device, the transmitting device generates the notification packet by encapsulating configuration information for improving operational efficiency set in the transmitting device with a tunnel header for passing the notification packet through the communication tunnel, and notifies the receiving device of the notification packet from the communication tunnel.

[0012] According to the present invention, information that is not essential for packet forwarding set in a remote device can be exchanged between tunnel endpoints.

[0013] FIG. 1 is a configuration diagram of a remote notification system according to the present embodiment. FIG. 2 is an explanatory diagram of a notification packet according to the present embodiment. FIG. 3 is a configuration diagram focusing on the transmission and reception of notification packets among the leaves of the remote notification system according to the present embodiment. FIG. 4 is a hardware configuration diagram of each device (leaf, spine, server) of the remote notification system according to the present embodiment. FIG. 5 is a packet diagram showing details of an LLDP frame according to the present embodiment. FIG. 6 is a packet diagram showing details of a notification packet according to the present embodiment. FIG. 7 is a flowchart showing processing of a transmitting device according to the present embodiment. FIG. 8 is a flowchart showing processing of a receiving device according to the present embodiment. FIG. 9 is a configuration diagram of a network system operated using DCBX.

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

[0015] FIG. 1 is a configuration diagram of a remote notification system 100. The remote notification system 100 is configured as a leaf and spine network. The spines, a first spine 11 and a second spine 12, are communication devices that act as the core layer of the network and bundle the leaves together to perform high-capacity communication. The leaves, a first leaf 21, a second leaf 22, a third leaf 23, and a fourth leaf 24, are communication devices that act as the access layer of the network and accommodate various servers (servers 31 to 36). The leaves and spines are mesh-connected, and communication from one leaf to another passes through the spine.

[0016] Here, it is assumed that the access layer 51 including the first leaf 21 and the second leaf 22 is configured with a redundancy scheme of the MC-LAG (Multichassis Link Aggregation Group) method. On the other hand, the access layer 52 including the third leaf 23 and the fourth leaf 24 is configured with a redundancy scheme of the EVPN multihome method. Furthermore, it is assumed that information required for communication is exchanged between the first leaf 21 and the fourth leaf 24 using MP-BGP, and a VXLAN tunnel is set up (indicated by a bold bidirectional arrow in the figure). In other words, the first leaf 21 and the fourth leaf 24 correspond to tunnel endpoints (VTEPs) with each other.

[0017] In this case, when analyzing a problem between the first leaf 21 and the fourth leaf 24, the administrator of the access layer 52 knows the redundancy method (EVPN multihome method) of the fourth leaf 24 that he or she manages, and therefore can analyze the cause. On the other hand, the administrator of the access layer 52 does not know the redundancy method (MC-LAG method) of the opposing first leaf 21, and therefore it may take a long time to analyze the cause. Note that information about the redundancy method is not exchanged between the first leaf 21 and the fourth leaf 24 using MP-BGP.

[0018] Therefore, in the remote notification system 100 of this embodiment, additional information such as a redundancy method indicating that "the first leaf 21 and the second leaf 22 are configured with the MC-LAG method" is transmitted from the first leaf 21 to the fourth leaf 24. This eliminates the need for the administrator of the access layer 52 to remotely log in to the first leaf 21 or the second leaf 22 using a CLI (Command Line Interface) to collect additional information. In other words, the administrator of the access layer 52 can obtain the setting status of the opposing first leaf 21 from the fourth leaf 24, thereby reducing the time required for cause analysis.

[0019] In this way, the remote notification system 100 exchanges the following two types of information between tunnel endpoints. Essential information for conducting traffic through VXLAN includes VTEP address information and the BUM forwarding method, and is exchanged using EVPN protocols such as MP-BGP BGP route Type 3 messages. Additional information for conducting traffic through VXLAN includes information for improving operational efficiency, such as the leaf redundancy method, the maximum number of routes that can be maintained, and DCB capability information, and is exchanged using notification packets 60 shown in FIG. 2.

[0020] 2 is an explanatory diagram of a notification packet 60. The notification packet 60 (details in FIG. 6) transmitted from the first leaf 21 to the fourth leaf 24 includes the following: An LLDP frame 62 (packet of an exchangeable protocol, details in FIG. 5) that stores one or more pieces of additional information; and a VXLAN header (tunnel header) 61 that is a header used when encapsulating the LLDP frame 62.

[0021] 3 is a configuration diagram of the leaves of remote notification system 100, focusing on the transmission and reception of notification packets 60. Transmitting device 70 is a device that generates notification packets 60 and transmits them to receiving device 80, and corresponds to first leaf 21 in FIG. 1. Transmitting device 70 has a tunneling unit 71, a device setting unit 72, and setting data 73. Receiving device 80 is a device that receives notification packets 60 and reads their contents, and corresponds to fourth leaf 24 in FIG. 1. Receiving device 80 has a tunneling unit 81, a device setting unit 82, and setting data 83.

[0022] A communication tunnel 78 is constructed between a tunneling unit 71 of the transmitting device 70 and a tunneling unit 81 of the receiving device 80. The transmitting device 70 generates a notification packet 60 by encapsulating a tunnel header (VXLAN header 61) for passing through the communication tunnel 78 in setting information (LLDP frame 62) for improving operational efficiency that is set for the transmitting device 70. The transmitting device 70 then notifies the receiving device 80 of the notification packet 60 from the communication tunnel.

[0023] Therefore, the device setting unit 72 of the transmitting device 70 generates a notification packet 60 including an LLDP frame 62 that has read and stored additional information from its own setting data 73, and a VXLAN header 61 of a communication tunnel 78 that connects to the receiving device 80. The tunneling unit 71 sets a notification flag in the notification packet 60 to distinguish the notification packet 60 from a normal data packet (a packet that does not include the LLDP frame 62), and then transmits the notification packet 60 to the receiving device 80.

[0024] The tunneling unit 81 of the receiving device 80 recognizes the received notification packet 60 by the notification flag and notifies the device setting unit 82 of the notification packet 60. The device setting unit 82 reads the LLDP frame 62 from the notified notification packet 60 and obtains additional information of the first leaf 21 from the LLDP frame 62. The device setting unit 82 also compares the setting data 83 of the receiving device 80 with the setting data 73 of the transmitting device 70 to prevent mismatches in the configurations of the two devices. In other words, by enabling the exchange of LLDP frames 62 between non-adjacent device setting units 72 and 82, a virtual connection relationship 79 is established. As a result, LLDP, which operates between adjacent devices, can also operate between non-adjacent transmitting devices 70 and receiving devices 80 via the virtual connection relationship 79.

[0025] FIG. 4 is a hardware configuration diagram of each device (leaf, spine, and server) of the remote notification system 100. Each device in the remote notification 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 unit by executing a program (remote notification 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.

[0026] 5 is a packet diagram showing details of the LLDP frame 62. A packet 110 of the LLDP frame 62 contains the following information, starting from the beginning (outside): Preamble [8 bytes] Destination MAC address [6 bytes] Source MAC address [6 bytes] Type = 0x88cc (11dp) [2 bytes] Data [48 to 1500 bytes] FCS (Frame Check Sequence) [4 bytes]

[0027] The data in the packet 110 (data field 120) contains one or more data elements, each consisting of a 7-bit Type, a 9-bit Length, and a variable-length Value. The last data element is followed by a termination data (End of LLDPDU). Each data element has a Type of 127 (a value indicating an organization-specific extension field), a Value representing additional information to be notified, and a Length representing the length of the Value. In this way, the transmitting device 70 generates a protocol packet (LLDP frame 62) capable of exchanging information, including a redundancy method, as configuration information for improving operational efficiency.

[0028] FIG. 6 is a packet diagram showing details of the notification packet 60. The notification packet 60 is an LLDP over VXLAN packet 210 in which an encapsulation header and an FCS are added to an LLDP frame 62, which is the original Ethernet frame. The encapsulation header includes, from the beginning, an external Ethernet header [14 bytes], an external IP header [20 bytes], an external UDP header [8 bytes], and a VXLAN header 220 [8 bytes]. The external Ethernet header [14 bytes] stores a combination of the destination address of the receiving device 80 and the source address of the transmitting device 70. The VXLAN header 220 includes, from the beginning, a flag set 230 [1 byte], a reservation [3 bytes], a VNI [3 bytes], and a reservation [1 byte].

[0029] The flag set 230 is "R, R, R, R, I, R, R, 1" from the beginning, each of which is 1 bit, for a total of 8 bits = 1 byte. "R" is a reserved value and is usually set to "0." While the flag set in Non-Patent Document 1 is "R, R, R, R, I, R, R, R," the 8th bit in the flag set 230 in FIG. 6 has been changed from "R" to "1." This 8th bit is a notification flag for distinguishing between notification packets 60 (8th bit = 1) and normal data packets (8th bit = R = 0). The location of the notification flag within the packet is not limited to the 8th bit of the flag set 230, and it may be located anywhere within the LLDP over VXLAN packet 210.

[0030] In this way, the transmitting device 70 generates a notification packet 60 by encapsulating a tunnel header (encapsulation header in FIG. 6 ) in an LLDP frame 62. Here, the transmitting device 70 generates the notification packet 60 by adding a notification flag to the tunnel header, indicating that the notification packet 60 contains configuration information. Furthermore, the transmitting device 70 generates the notification packet 60 by adding a non-existent destination address to the tunnel header for the notification packet 60 to which the notification flag has been added. This prevents the notification packet 60 from leaking to the outside from the receiving device 80, even if the receiving device 80 does not have the processing function for the notification packet 60. The receiving device 80 recognizes a received packet with a notification flag added to its tunnel header as a notification packet 60 and reads the configuration information for the transmitting device 70 from the notification packet 60.

[0031] FIG. 7 is a flowchart showing the processing of the transmitting device 70. The transmitting device 70 sets information (additional information) for improving operational efficiency, such as the redundancy method of the MC-LAG method, as configuration data 73 in itself (S101). The transmitting device 70 receives a notification packet (BGP update type 3) of essential information from the receiving device 80, which is the opposing VTEP, and registers the address of the receiving device 80 in itself, thereby establishing a tunnel between itself and the receiving device 80 (S102). The transmitting device 70 generates an LLDP frame 62 ( FIG. 5 ) including the information for improving operational efficiency set in S101 (S103). The transmitting device 70 generates a notification packet 60 ( FIG. 6 ) by encapsulating the LLDP frame 62 generated in S103 with a VXLAN header 61, and transmits the notification packet 60 to the receiving device 80 (S104). The VXLAN header 61 includes a notification flag and a VNI (destination address) assigned a value that does not exist in the NW (Network). A value that does not exist in the network is, for example, a value that has been reserved in advance by an administrator so that it will not be used for any other purpose, and is used to prevent the notification packet 60 from leaking out from the receiving device 80 to the outside.

[0032] 8 is a flowchart showing the processing of the receiving device 80. The receiving device 80 receives the notification packet 60 or data packet of S104 (S111). The receiving device 80 determines whether the packet received in S111 includes a notification flag (S112). If the answer is No in S112 (no notification flag), the receiving device 80 processes the packet received in S111 as a data packet addressed to another party (S113). Specifically, the receiving device 80 forwards the received packet to the server 34-36 connected to the receiving device 80 based on the VNI of the received packet. If the answer is Yes in S112 (the notification flag is present), the receiving device 80 processes the packet received in S111 as a self-addressed packet, and proceeds to S114.

[0033] The receiving device 80 determines whether or not it supports the notification packet 60 (S114). If the answer is Yes in S114, the receiving device 80 reads information for operational efficiency from the LLDP frame 62 in the notification packet 60, enters the settings into its own configuration data 83 (S115), and displays the settings on the screen. If the answer is No in S114, the receiving device 80 ignores the notification flag (treating the notification packet 60 as a data packet) and attempts to forward the packet to the servers 34-36 connected from the receiving device 80 based on the VNI, as in S113. However, because the VNI in the notification packet 60 does not exist, the packet is discarded (S116).

[0034] [Effect] The present invention is a remote notification system 100 that notifies a receiving device 80 of a notification packet 60 generated by a transmitting device 70, wherein a communication tunnel is constructed between the transmitting device 70 and the receiving device 80, and the transmitting device 70 generates a notification packet 60 by encapsulating a tunnel header for passing the notification packet through the communication tunnel in configuration information set for itself for operational efficiency, and notifies the receiving device 80 of the notification packet 60 from the communication tunnel.

[0035] As a result, the remote notification system 100 transmits a notification packet 60 from a transmitting device 70 such as the first leaf 21 to a receiving device 80 such as the fourth leaf 24. The transmitting device 70 encapsulates information that is not essential for packet forwarding (configuration information for improving operational efficiency) in a VXLAN header 61 or the like, and can exchange this information between tunnel endpoints on the overlay network. Furthermore, the remote notification system 100 can notify the configuration information for improving operational efficiency without adding any functionality to the spine between the first leaf 21 and the fourth leaf 24.

[0036] The present invention is characterized in that the transmitting device 70 generates a packet of a protocol capable of exchanging information including a redundancy method as configuration information set for itself to improve operational efficiency, and generates a notification packet 60 in which a tunnel header is encapsulated in the packet of the exchangeable protocol.

[0037] This allows the remote notification system 100 to exchange packets (LLDP frames 62) of a protocol (LLDP) that can exchange information, including redundancy methods, between the transmitting device 70 and the receiving device 80. Therefore, existing LLDP implementations, such as processes to prevent mismatches between configurations, can be utilized in remote communications. Furthermore, the administrator of the receiving device 80 can omit logging in to the transmitting device 70 and display configuration information for improving the operational efficiency of the opposing transmitting device 70 from the CLI of the receiving device 80, thereby improving operational efficiency. Therefore, the administrator of the receiving device 80 can log in to the opposing transmitting device 70 from the CLI screen of the receiving device 80 and reduce the effort required to switch between multiple CLI screens.

[0038] The present invention is characterized in that a transmitting device 70 generates a notification packet 60 by adding a notification flag to the tunnel header indicating that the notification packet 60 contains configuration information, and a receiving device 80 recognizes a received packet with a notification flag added to the tunnel header as a notification packet 60 and reads the configuration information of the transmitting device 70 from the notification packet 60.

[0039] This allows the remote notification system 100 to use existing implementations such as a VXLAN reserved header as a tunnel header and embed the notification flag in the notification packet 60, thereby reducing development costs.

[0040] The present invention is characterized in that the transmitting device 70 generates a notification packet 60 with a non-existent destination address added to the tunnel header for the notification packet 60 with the notification flag added.

[0041] As a result, by setting the VNI to a value that does not exist on the network, the remote notification system 100 can prevent the notification packet 60 from leaking out of the receiving device 80, even if the receiving device 80 does not have the functionality to process the notification packet 60.

[0042] 11 First spine 12 Second spine 21 First leaf 22 Second leaf 23 Third leaf 24 Fourth leaf 31 to 36 Server 60 Notification packet 61 VXLAN header (tunnel header) 62 LLDP frame (packet of exchangeable protocol) 70 Transmitting device 71 Tunneling unit 72 Device setting unit 73 Setting data 80 Receiving device 81 Tunneling unit 82 Device setting unit 83 Setting data 100 Remote notification system

Claims

1. A remote notification system for notifying a receiving device of a notification packet generated by a transmitting device, wherein a communication tunnel is constructed between the transmitting device and the receiving device, and the transmitting device generates the notification packet by encapsulating a tunnel header for passing through the communication tunnel in configuration information for improving operational efficiency set in the transmitting device, and notifies the receiving device of the notification packet from the communication tunnel.

2. The remote notification system described in claim 1, characterized in that the transmitting device generates a packet of a protocol that can exchange information including a redundancy method as the configuration information set for itself to improve operational efficiency, and generates the notification packet by encapsulating the tunnel header in the packet of the exchangeable protocol.

3. The remote notification system described in claim 1, characterized in that the transmitting device generates the notification packet by adding a notification flag to the tunnel header indicating that the notification packet contains the setting information, and the receiving device recognizes the received packet with the notification flag added to the tunnel header as the notification packet and reads the setting information of the transmitting device from the notification packet.

4. The remote notification system according to claim 3, wherein the transmitting device generates notification packets with the notification flag added, in which a non-existent destination address is also added to the tunnel header.

5. A remote notification method executed by a remote notification system that notifies a receiving device of a notification packet generated by a transmitting device, characterized in that a communication tunnel is constructed between the transmitting device and the receiving device, and the transmitting device generates the notification packet by encapsulating a tunnel header for passing through the communication tunnel in configuration information for improving operational efficiency that is set for the transmitting device, and notifies the receiving device of the notification packet from the communication tunnel.

Images