Disclosure of Invention
To address at least one or more of the technical problems mentioned above, the present application proposes, in various aspects, monitoring static route changes based on BFD Trap event triggers.
In a first aspect, the application provides a method for monitoring static route change based on BFD Trap event triggering, which comprises the steps of establishing SNMP connection between a server side and a switch configured with BFD, wherein BFD is bound with the static route, monitoring BFD Trap event from the switch, checking BFD state and checking change information of the static route bound with BFD when the BFD Trap event is monitored, and pushing the BFD state and the change information of the static route to a client side for display.
In some embodiments, in listening for BFD Trap events from the switch, the steps of configuring an SNMP listening service to listen for SNMP Trap events, parsing SNMPTrap the OID identifier in the event, and acquiring the BFD Trap event based on SNMPTrap the OID identifier in the event are performed.
In some embodiments, in configuring an SNMP listening service to listen for SNMP Trap events, the steps of creating a transport map instance at a server side and binding an IP address of the server with a designated port, initializing the SNMP instance and associating it with the transport map instance, starting the transport map to listen for the designated port to receive SNMP data packets, creating CommandResponder an interface and registering it with the SNMP instance, decoding the received SNMP data packets as SNMPTrap events by the transport map and sending to the registered CommandResponder interface by a message distributor.
In some embodiments, the designated port is set according to a type of transport map instance.
In some embodiments, when the transport map instance is a UDP-based transport map instance, the designated port is a UDP 162 port.
In some embodiments, in resolving the OID identifier in the SNMP Trap event, the OID identifier in the SNMPTrap event is resolved through the CommandResponder interface.
In some embodiments, in acquiring a BFD Trap event based on an OID identifier in an SNMP Trap event, the SNMPTrap event is considered as a BFD Trap event when the OID identifier in the SNMP Trap event matches an OID identifier associated with a BFD state change.
In some embodiments, before the change information of the BFD state and the static route is pushed to the client for visual presentation, the client establishes a WebSocket connection with the server through handshake.
In some embodiments, in the process of pushing the change information of the BFD state and the static route to the client for visual presentation, the server pushes the change information of the BFD state and the static route to a webpage of the client, and the webpage of the client renders the change information of the BFD state and the static route and displays the rendered information through the client.
In a second aspect, the application provides a system for monitoring static route change based on BFD Trap event triggering, which monitors static route change by adopting the method for monitoring static route change based on BFD Trap event triggering according to any embodiment of the first aspect, wherein the system comprises a server side, a switch configured with BFD and a client side, SNMP connection is established between the server side and the switch configured with BFD, the client side establishes connection with the server side, wherein BFD is bound with the static route, the server side monitors BFD Trap event from the switch, checks BFD state when the BFD Trap event is monitored, checks change information of the static route bound with BFD, and pushes the BFD state and the change information of the static route to the client side for display.
By monitoring the static route change scheme based on BFD Trap event triggering provided by the embodiment of the application, the BFD Trap event triggers the operation of inquiring the BFD state information and the static route change information bound by the BFD Trap event by monitoring the BFD Trap event from the switch, so that the problems that the switch is frequently inquired, the BFD state change and the static route change bound cannot be found in time can be avoided. Meanwhile, the change information of the BFD state and the static route is pushed to the client for display, so that the situation that a user frequently refreshes a webpage to request a related network state is avoided, the BFD state change and the static route binding change situation can be presented in an intuitive and concise mode, and network management staff can conveniently master the network state change situation in time.
Detailed Description
The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
It should be understood that the terms "comprises" and "comprising," when used in this specification and in the claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
It is also to be understood that the terminology used in the description of the application herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in the specification and claims, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should be further understood that the term "and/or" as used in the present specification and claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.
As used in this specification and the claims, the term "if" may be interpreted as "when..once" or "in response to a determination" or "in response to detection" depending on the context. Similarly, the phrase "if a determination" or "if a [ described condition or event ] is detected" may be interpreted in the context of meaning "upon determination" or "in response to determination" or "upon detection of a [ described condition or event ]" or "in response to detection of a [ described condition or event ]".
Specific embodiments of the present application are described in detail below with reference to the accompanying drawings.
Fig. 1 illustrates an exemplary flow chart of a BFD Trap event trigger based system 100 for monitoring static route changes in accordance with an embodiment of the present application.
As shown in fig. 1, in step S110, an SNMP connection between a server side and a switch configured with BFD is established, where the BFD is bound to a static route.
Specifically, bidirectional forwarding detection (Bidirectional Forwarding Detection, BFD) is a network detection mechanism that is used to quickly detect, monitor, and control the forwarding connectivity status of links or IP routes in a network. BFD establishes a session on two network devices to detect a bidirectional forwarding path between the network devices to serve an upper layer application. And after the session is established, the BFD message is periodically and rapidly sent, if the BFD message is not received in the detection time, the bidirectional forwarding path is considered to be failed, and the served upper layer application is notified to carry out corresponding processing. By configuring BFD on the switch, connectivity of a line interconnected with the switch can be monitored, so that network fault detection speed can be increased, and the network fault detection device can be closely cooperated with other network components to jointly ensure quality and reliability of network service.
In the embodiment of the present application, various prior art techniques may be used in the process of establishing the SNMP connection between the server side and the switch configured with BFD, and the present application is not limited herein. For example, a community word of SNMP, SNMPv2c, and a mix library are first configured on the switch, and then SNMP connections of servers to the switch are established using an org.snmp4j.
In the prior art, in order to improve reliability, links are often arranged in a network in a redundant manner, a plurality of static routes are configured at a routing layer, and each static route is given different priority. When the high priority link is broken, the route is switched to the low priority route, so that the network quickly resumes connectivity. However, in the actual use process, because the static route cannot sense the interruption of the link, in the case of the interruption of the link, the static route is not switched according to the configured priority. Therefore, a BFD session needs to be configured to detect connectivity of the link, so as to implement BFD and static route binding.
After step S110 is performed, in step S120, the BFD Trap event from the switch is monitored.
In an embodiment of the present application, a specific process of listening for BFD Trap events from the foregoing switch may refer to fig. 2.
Figure 2 illustrates an exemplary flow chart of listening for BFD Trap events from a switch in accordance with an embodiment of the present application.
As shown in fig. 2, in step S210, an SNMP listening service is configured to listen for SNMP Trap events. In step S220, the OID identifier in the SNMP Trap event is parsed. In step S230, a BFD Trap event is acquired based on the OID identifier in the SNMPTrap event.
In an embodiment of the present application, a specific process of configuring an SNMP listening service to listen for SNMP Trap events may refer to fig. 3.
Fig. 3 shows an exemplary flow chart for configuring an SNMP snoop service to snoop SNMP Trap events in accordance with an embodiment of the present application.
As shown in fig. 3, in step S310, a transmission map instance is created at the server side, and the IP address of the server and the designated port are bound. In step S320, an SNMP instance is initialized and associated with the transport map instance. In step S330, the transmission map is started to listen to the designated port to receive SNMP packets. In step S340, a CommandResponder interface is created and registered with the SNMP instance. In step S350, the transmission map decodes the received SNMP packet into an SNMP Trap event and sends it to the registered CommandResponder interface through the message dispatcher.
In the embodiment of the present application, the aforementioned designated port is set according to the type of the transmission map instance. When the transmission mapping instance is a UDP-based transmission mapping instance, the aforementioned designated port is a UDP 162 port, and the UDP 162 port is a standard port number of SNMPTrap messages, which can be used to receive notification or warning information from the switch. Where the transmission map instance is of another type, the designated port may be another port, which is not limited herein.
In the embodiment of the application, the same SNMP version as the SNMP version of the switch is selected when the SNMP instance is initialized, so that the compatibility with the SNMP version of the switch is ensured.
In an embodiment of the present application, SNMP instances support GET, SET, GETNEXT, GETBULK, etc., multiple operation types, allowing administrators to query device status, modify configuration parameters, and obtain batch data.
In the embodiment of the application, by initializing the SNMP instance and associating the SNMP instance with the transmission mapping instance, a communication bridge between the server side and the switch can be established, so that the server side can send a request to the switch through the SNMP protocol and receive a response and/or Trap message from the switch.
In SNMP, the CommandResponder interface is a critical component for handling received requests, reports and notification PDUs (protocol data units). The CommandResponder interface processes the incoming PDU using the processPdu method and marks the event as processed. Wherein the incoming PDUs include Trap-like PDUs, i.e., commandResponder interface can handle SNMPTrap events.
In an embodiment of the present application, by creating CommandResponder interfaces and registering them with SNMP instances, the server side can listen to and process Trap messages from the switch. Whenever a new Trap message arrives, the processPdu method is called, allowing the developer to write logic to process the messages.
In the embodiment of the application, in the process of analyzing the OID identifier in the SNMP Trap event, the OID identifier in the SNMPTrap event is analyzed through a CommandResponder interface.
In the embodiment of the application, in the process of acquiring the BFD Trap event based on the OID identifier in the SNMP Trap event, the SNMPTrap event is taken as the BFD Trap event when the OID identifier in the SNMP Trap event is matched with the OID identifier related to the BFD state change.
In some embodiments of the present application, in matching the OID identifier in the SNMP Trap event with the OID identifier associated with the BFD state change, a wild card matching method may be used to match the OID identifier in the SNMPTrap event with the OID identifier associated with the BFD state change. In other embodiments of the present application, in the process of matching the OID identifier in the SNMP Trap event with the OID identifier related to the BFD state change, other methods than the wild card matching method may be used to match the OID identifier in the SNMP Trap event with the OID identifier related to the BFD state change.
In the embodiment of the application, when the OID identifier in the SNMP Trap event is matched with the OID identifier corresponding to the BFD session Down event or the OID identifier corresponding to the BFD session Up event, the SNMP Trap event is used as the BFD Trap event. Specifically, the OID identifier corresponding to the BFD session Down event is 1.3..3.1, the OID identifier corresponding to the BFD session Up event is 1.3..3.2, and when the OID identifier in the SNMP Trap event matches 1.3..3.1 or 1.3..3.2, the above SNMPTrap event is regarded as the BFD Trap event.
By matching the OID identifier in SNMPTrap events with the OID identifier associated with the BFD state change, the Trap events can be accurately classified, ensuring that only those traps that truly represent BFD state changes will be processed as BFD Trap events.
After step S120 is performed, in step S130, upon monitoring the BFD Trap event, the BFD state is checked, and change information of the static route bound to BFD is checked.
Specifically, only when the BFD session state of the link in the network is UP, the static route bound with BFD is effective, otherwise, the static route is invalid. In order to timely detect the change condition of the static route, the change condition of the static route table needs to be checked immediately when the BFD state changes. Therefore, after monitoring BFD Trap events, the bound static route information is checked while checking the BFD state, and then the acquired information is returned to the user so as to timely grasp the change condition of the network state.
After step S130 is performed, in step S140, the change information of the BFD state and the static route is pushed to the client for display.
In the embodiment of the application, before the change information of the BFD state and the static route is pushed to the client for display, the client establishes WebSocket connection with the server through handshake.
Specifically, in the process that the client establishes a WebSocket connection with the server through handshake, the client first needs to send an HTTP/1.1GET request to the server, which is called handshake request. Some specific header fields are included in the request to indicate that the client wishes to upgrade to the WebSocket protocol. After the server receives the handshake request, it checks whether the request meets the requirements of WebSocket protocol, and decides whether to accept the connection request. If the server agrees to establish a WebSocket connection, it will return an HTTP response with a state code of 101 (SWITCHING PROTOCOLS), meaning that the server has understood the client's request and agreed to complete it using a different protocol. After receiving the handshake response of the server, the client verifies the corresponding field in the handshake response. The client calculates its expected value according to the same algorithm and compares it with the same field received from the server as the corresponding field. If the two are equal, the handshake is considered successful, the WebSocket protocol can be used for communication continuously, and if the two are equal, the handshake fails, and the connection is closed.
In the embodiment of the application, in the process of pushing the change information of the BFD state and the static route to the client for visual presentation, firstly, the server pushes the change information of the BFD state and the static route to the webpage of the client. And then, the client webpage renders the change information of the BFD state and the static route, and displays the rendered information through the client.
In some embodiments of the application, the client web page employs a web page. In other embodiments of the present application, the client web page may also employ other web pages other than web pages, and the present application is not limited in this regard.
In some embodiments of the present application, in the process of rendering the change information of the BFD state and the static route by the client webpage, the BFD-UI component library may be used to render the change information of the BFD state and the static route. When the BFD state changes (e.g., from Up to Down), the corresponding UI update logic should be triggered to reflect the latest BFD state. For the change of the static route, the latest route configuration information can be displayed at the client according to the change condition of the routing table. In other embodiments of the present application, in the process of rendering the change information of the BFD state and the static route by the client web page, other component libraries outside the BFD-UI component library may be used to render the change information of the BFD state and the static route.
By comprehensively monitoring the static route change scheme based on BFD Trap event triggering provided by the embodiment of the application, the BFD Trap event triggers the operation of inquiring the BFD state information and the static route change information bound by the BFD Trap event by monitoring the BFD Trap event from the switch, so that the problems that the switch is frequently inquired, and the BFD state change and the static route change bound cannot be found in time can be avoided. Meanwhile, the change information of the BFD state and the static route is pushed to the client for display, so that the situation that a user frequently refreshes a webpage to request a related network state is avoided, the BFD state change and the static route binding change situation can be presented in an intuitive and concise mode, and network management staff can conveniently master the network state change situation in time.
The embodiment of the application also provides a system for monitoring the static route change based on BFD Trap event trigger, which can adopt the method 100 for monitoring the static route change based on BFD Trap event trigger to monitor the static route change based on BFD Trap event trigger, and can also adopt other systems for monitoring the static route change based on BFD Trap event trigger to monitor the static route change based on BFD Trap event trigger.
Fig. 4 is an exemplary block diagram of a system for monitoring static route changes based on BFD Trap event triggers in accordance with an embodiment of the present application.
As shown in fig. 4, the system 400 includes a server side 410, a BFD-configured switch 420, and a client side 430.
Specifically, an SNMP connection is established between the server side 410 and the BFD-configured switch 420, and the client side 430 is bound to the server side 410, wherein the BFD is static route. More specifically, the client 430 connects with the server 410 through WebSocket.
Specifically, the server 410 listens for a BFD Trap event from the switch 420 configured with BFD, and when the BFD Trap event is heard, checks the BFD state, and checks the change information of the static route bound to BFD, and pushes the BFD state and the change information of the static route to the client 430 for display.
When the system 400 performs the BFD Trap event-based monitoring of the static route change by using the BFD Trap event-based monitoring system 100, the server 410 performs the steps S110-S140. For specific implementation, reference is made to the foregoing, and details are not repeated here.
While various embodiments of the present application have been shown and described herein, it will be obvious to those skilled in the art that such embodiments are provided by way of example only. Numerous modifications, changes, and substitutions will occur to those skilled in the art without departing from the spirit and scope of the application. It should be understood that various alternatives to the embodiments of the application described herein may be employed in practicing the application. The appended claims are intended to define the scope of the application and are therefore to cover all equivalents or alternatives falling within the scope of these claims.