CN112087318A - A network management method, server, client and system - Google Patents

Abstract

The embodiment of the invention discloses a network management method, a server, a client and a system. According to the method, the server and the client are enabled to ignore the unidentified content in the NETCONF message respectively, so that the server and the client can communicate based on the principle of non-strict matching, the server and the client can also communicate smoothly when the versions of the server and the client are inconsistent, and the network management efficiency is improved.

Description

A network management method, server, client and system

technical field

The invention relates to the field of communications, in particular to a network management method, server, client and system.

Background technique

NETCONF (Network Configuration Protocol, Network Configuration Protocol) is a network management protocol based on XML (Extensible Markup Language, Extensible Markup Language), which provides a method for configuring and managing network devices. This protocol allows devices to provide a series of complete and standardized programming interfaces, through which applications or users can configure parameters, obtain parameter values, or query parameter values for network devices.

In the process of network management based on NETCONF, the version of the network management device (client) and the target network device (server) need to be the same for smooth communication. Usually, because the network management device manages a large number of network devices, it is impossible to upgrade the network management device and the network device at the same time. For example, after the network management device is upgraded, some network devices are not upgraded, so that the versions of the network management device and the target network device are inconsistent, and the communication between the network management device and the target network device cannot be performed normally. For another example, after the network management device is upgraded, before all the network devices in the entire network are upgraded, the communication between the network management device and the network devices that have not been upgraded cannot be performed normally.

SUMMARY OF THE INVENTION

The embodiments of the present invention provide a network management method, server, client and system, so as to realize normal communication under the condition that the management module versions of the client and the server are inconsistent.

In a first aspect, an embodiment of the present invention provides a network management method, including:

The server sends a first Hello packet to the client through the SSH connection between the client and the server, wherein the first Hello packet carries the first friend friendly-element identifier, and the first friend friendly-element identifier is used To indicate that the server has the first friend capability, wherein the first friend capability is used to indicate that the server can ignore the unrecognized fields in the NETCONF request message received from the client; The SSH connection receives the second Hello packet from the client, the second Hello packet carries the second friend friendly-element identifier, and the second friend friendly-element identifier is used to indicate that the client has the second friend capability. , the second friend capability is used to indicate that the client can ignore the unidentifiable fields in the NETCONF response message received from the server; finally, the server is based on the first friend friendly-element identifier and the described The second friendly-element identifier identifies the friendly-element relationship between the server and the client. The friendly element relationship between the server and the client is established by carrying the friendly-element identifier in the Hello message between the server and the client, so that the server and the client can communicate based on the principle of non-strict matching. Therefore, communication can be performed smoothly even when the versions of the server and the client are inconsistent, and the network management efficiency is improved.

In a possible design, after the server determines the friend relationship between the server and the client according to the first friend friendly-element identifier and the second friend friendly-element identifier, the above method further includes:

The server receives the NETCONF request message sent by the client, wherein the NETCONF request message includes the edit-config request, the data node to be configured based on the client data model, and the to-be-configured value of the data node to be configured; then the server based on the server data The model determines whether the to-be-configured data node can be identified. When the to-be-configured data node can be identified, the server uses the to-be-configured value to perform data configuration on the to-be-configured data node. When the to-be-configured data node cannot be identified , the server ignores the data node to be configured; finally, the server returns a NETCONF response message to the client, wherein the NETCONF response message includes an indication of whether the data configuration is successful. This non-strict matching communication method based on friend connection can solve the problem that the versions of the client and the server do not match, that is, when the client data model is inconsistent with the server data model, the data configuration can be carried out smoothly without Error reporting enables the edit-config operation based on the NETCONF protocol to proceed smoothly and improves network management efficiency.

In a possible design, after the server determines the friend relationship between the server and the client according to the first friend friendly-element identifier and the second friend friendly-element identifier, the above method further includes:

The server receives the NETCONF request message sent by the client, the NETCONF request message includes a get or get-config request, and data filtering conditions based on the client data model, the data filtering conditions include selecting data nodes; the server determines based on the server data model. Whether the selection data node can be identified, when the selection data node can be identified, the server obtains the value of the selection data node corresponding to the selection data node from the preset server data to obtain the acquisition result data, when the selection data node is not When it can be identified, the server ignores the selected data node; finally, the server sends a NETCONF response message to the client, wherein the NETCONF response message includes the acquisition result data. By establishing a friend connection between the client and the server, the get or get-config operation can be performed smoothly even when the client and server versions are inconsistent, that is, when the client data model is inconsistent with the server data model. Errors will be reported to improve network management efficiency.

In a possible design, after the server determines the friend relationship between the server and the client according to the first friend friendly-element identifier and the second friend friendly-element identifier, the above method further includes:

The server receives the NETCONF request message sent by the client. The NETCONF request message includes the copy-config request, the data source identifier corresponding to the copy-config request, the target data set identifier corresponding to the copy-config request, and the data based on the copy-config request. The data node to be copied of the source data model, and the above-mentioned first friend capability is also used to indicate that the server can ignore the unrecognized fields in the data source indicated by the data source identifier; the server determines the data node to be copied based on the server data model. Whether it can be identified, when the data node to be copied can be identified, the server copies the value of the data node to be copied in the data source to the target data set indicated by the target data set identifier, when the data node to be copied cannot be copied. During identification, the server ignores the value of the data node to be copied in the data source; finally, the server sends a NETCONF response message to the client, where the NETCONF response message includes an indication of whether data copying is successful. By performing a communication method that does not strictly match the data source indicated by the data source identifier sent by the client based on the friend connection, the problem that the data model of the data source does not match the data model of the server can be solved, that is, the data model of the client and the data of the server can be solved. Even when the models are different, data can be copied without error, which enables the copy-config operation based on the NETCONF protocol to be carried out smoothly and improves the efficiency of network management.

In a possible design, the above method also includes:

If the server detects that the client data model or the server data model has changed, the server determines whether the client data model is consistent with the server data model; when the client data model is consistent with the server data model, the server closes the first friend capability, thereby The server does not have the ability to ignore the unrecognized fields in the received NETCONF request message from the client.

In a possible design, the above method also includes:

If the client data model is consistent with the server data model, the server sends an instruction message to the client via the SSH connection instructing the client to disable the second friend capability, so that the client does not have the ability to respond to the NETCONF received from the server. The ability to ignore unrecognized fields in a packet. This enables flexible control of the friend relationship between the client and the server in the process of network management and ensures communication security.

In a second aspect, an embodiment of the present invention provides a network management method, including:

The client receives the first Hello packet sent by the server through the SSH connection between the client and the server. The first Hello packet carries the first friend friendly-element identifier, and the first friend friendly-element identifier uses In order to indicate that the server has the first friend capability, the first friend capability is used to indicate that the server ignores the unrecognized fields in the received NETCONF request message from the client; the client sends to the server via the SSH connection The second Hello packet, the second Hello packet carries the second friend friendly-element identifier, where the second friend friendly-element identifier is used to indicate that the client has the second friend capability, and the second friend friendly element The capability is used to indicate that the client ignores the unrecognized fields in the NETCONF response message received from the server; finally, the client determines the client according to the first friend friendly-element identifier and the second friend friendly-element identifier. Friendship with the server. The friendly element relationship between the server and the client is established by carrying the friendly-element identifier in the Hello message between the server and the client, so that the server and the client can communicate based on the principle of non-strict matching. Therefore, communication can be performed smoothly even when the versions of the server and the client are inconsistent, and the network management efficiency is improved.

In a possible design, after the client determines the friend relationship between the client and the server according to the first friend friendly-element identifier and the second friend friendly-element identifier, the above method further includes:

The client receives the NETCONF response message returned by the server, and the NETCONF response message includes the acquisition result data obtained by the server according to the get or get-config request, wherein the data model of the acquired result data is the server data model; the client is based on the client The data model determines the data nodes that can be identified and the data nodes that cannot be identified in the acquisition result data, and then the client saves the values of the data nodes that can be identified in the acquisition result data, and ignores the unidentified data nodes in the acquisition result data. The value of the data node that can be identified. Therefore, when the version of the client and the server are inconsistent, the obtained result data from the server can also be saved smoothly without reporting an error, thereby improving the efficiency of network management.

In a possible design, the above method also includes:

If the client detects that the client data model or the server data model has changed, it determines whether the client data model is consistent with the server data model; if the client data model is consistent with the server data model, the client closes the second friend capability, So that the client does not have the ability to ignore the unrecognized fields in the NETCONF response message received from the server.

In a possible design, the above method also includes:

If the client data model is consistent with the server data model, the client sends an instruction message to the server via the SSH connection to instruct the server to disable the first friend capability, so that the server does not have the ability to respond to the received NETCONF request message from the client The ability to ignore unrecognized fields in . This enables flexible control of the friend relationship between the client and the server in the process of network management and ensures communication security.

In a third aspect, an embodiment of the present invention further provides a server, including a unit for executing the method in the first aspect of the embodiment of the present invention.

In a fourth aspect, an embodiment of the present invention further provides a client, including a unit for executing the method in the second aspect of the embodiment of the present invention.

In a fifth aspect, an embodiment of the present invention further provides a server, where the server includes a processor, and the processor is configured to support the server to perform corresponding functions in the network management method provided in the first aspect. The server may also include memory, coupled to the processor, which holds program instructions and data necessary for the server. The server may also include a communication interface for the server to communicate with other devices or communication networks.

In a sixth aspect, an embodiment of the present invention further provides a client, where the client includes a processor, and the processor is configured to support the client to perform corresponding functions in the network management method provided in the second aspect. The client may also include memory, coupled to the processor, that holds program instructions and data necessary for the client. The client may also include a communication interface for the client to communicate with other devices or communication networks.

In a seventh aspect, an embodiment of the present invention provides a computer storage medium for storing computer software instructions used by the server provided in the fifth aspect, including a program for executing the above aspect.

In an eighth aspect, an embodiment of the present invention provides a computer storage medium for storing computer software instructions used by the client provided in the sixth aspect, including the program designed for executing the above aspect.

These and other aspects of the invention will be more clearly understood from the description of the following embodiments.

Description of drawings

In order to explain the embodiments of the present invention or the technical solutions in the prior art more clearly, the following briefly introduces the accompanying drawings that need to be used in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only These are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can also be obtained according to these drawings without creative efforts.

1-a is a structural diagram of a network management system provided by an embodiment of the present invention;

FIG. 1-b is a schematic flowchart of an embodiment of a network management method provided by an embodiment of the present invention;

1-c is a schematic diagram of a client data model and a server data model provided by an embodiment of the present invention;

FIG. 1-d is a schematic diagram of an edit-config operation flow according to an embodiment of the present invention;

1-e is a schematic flowchart of a first embodiment of a get or get-config operation provided by an embodiment of the present invention;

1-f is a schematic flowchart of a second embodiment of a get or get-config operation provided by an embodiment of the present invention;

1-g is a schematic flowchart of a third embodiment of a get or get-config operation provided by an embodiment of the present invention;

1-h is a schematic flowchart of a fourth embodiment of a get or get-config operation provided by an embodiment of the present invention;

FIG. 2 is a schematic flowchart of another embodiment of a network management method according to an embodiment of the present invention;

FIG. 3 is a schematic flowchart of still another embodiment of a network management method according to an embodiment of the present invention;

4 is a schematic structural diagram of a first embodiment of a server provided by an embodiment of the present invention;

5 is a schematic structural diagram of a second embodiment of a server provided by an embodiment of the present invention;

6 is a schematic structural diagram of a third embodiment of a server provided by an embodiment of the present invention;

FIG. 7 is a schematic structural diagram of a first embodiment of a client according to an embodiment of the present invention;

FIG. 8 is a schematic structural diagram of a second embodiment of a client according to an embodiment of the present invention;

FIG. 9 is a schematic structural diagram of a third embodiment of a client according to an embodiment of the present invention.

Detailed ways

The embodiments of the present invention provide a network management method, server, client and system, so as to realize normal communication under the condition that the management module versions of the client and the server are inconsistent.

In order to make those skilled in the art better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only Embodiments are part of the present invention, but not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by persons of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

The terms "first", "second" and "third" in the description and claims of the present invention and the above drawings are used to distinguish different objects, rather than to describe a specific order. Furthermore, the term "comprising" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device comprising a series of steps or units is not limited to the listed steps or units, but optionally also includes unlisted steps or units, or optionally also includes For other steps or units inherent to these processes, methods, products or devices.

Reference herein to an "embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the present invention. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor a separate or alternative embodiment that is mutually exclusive of other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

Hereinafter, some terms in the present application will be explained so as to facilitate the understanding of those skilled in the art.

(1) Network management refers to the technical means to enable the network to operate effectively by monitoring, controlling and recording the performance and usage of telecommunication network resources. In network management, the most basic network management protocol used is simple network management. Protocol (Simple Network Management Protocol, SNMP for short).

(2) Network Configuration Protocol (NETCONF for short) refers to a new network configuration protocol based on Extensible Markup Language (XML) used in network management. NETCONF comprehensively defines There are nine basic operations, and the functions mainly include value operation, configuration operation, lock operation and session operation. In this embodiment of the present invention, it mainly targets several operations that require data exchange between the client and the server: edit- config operations, get or get-config operations, and copy-config operations.

(3) Friend means that a new capability is added to the NETCONF protocol in the embodiment of the present invention. This capability indicates that both parties (client and server) of the protocol can negotiate to become friends, and the two parties who negotiate to become friends are not strictly recognized. In this way, the network management (client) does not need to check the version matching relationship when sending packets, and can send packets according to its own supported capabilities, while the device When receiving a message, the unrecognized fields can be ignored. The network management is also based on the same processing principle for the received response packets, that is, the unrecognized fields are ignored. In this way, both the network management side and the device side can independently deliver and receive packets according to their own capabilities, and do not need to perform complex version comparison and related processing.

In the embodiment of the present invention, specifically, friend capability can be added to the client and the server by adding a friendly-element identifier in the hello message of both parties of the NETCONF protocol.

(4) Data model refers to a data format used by the client or server. The data model consists of various nodes, so that when the client or server sends specific data, the format of the specific data can directly use the data. The format of the model. In this embodiment of the present invention, the client data model refers to the data model used by the client, and the server data model refers to the data model used by the server.

(5) "Multiple" refers to two or more. "And/or", which describes the association relationship of the associated objects, means that there can be three kinds of relationships, for example, A and/or B, which can mean that A exists alone, A and B exist at the same time, and B exists alone. The character "/" generally indicates that the associated objects are an "or" relationship.

The embodiments of the present application will be described below with reference to the accompanying drawings.

Referring first to FIG. 1-a, FIG. 1-a is a structural diagram of a network management system provided by an embodiment of the present invention. The network management methods provided by the embodiment of the present invention are all implemented based on the network management system. The structure diagram of the network management system shown in the figure includes a client and a server. The client, also known as the network management device, refers to the installation of network management entities in network management to provide user interfaces for different network management protocols and operations. It is used to receive the business operation of the network administrator user, and convert the user's business operation into the business operation corresponding to each network management protocol and operation and send it to the corresponding target network device, that is, the server. In this embodiment of the present invention, the form of the client includes but is not limited to various forms of user equipment (User Equipment, UE for short), terminal (terminal), terminal equipment (TerminalEquipment), etc.; the server, that is, the target network device, Refers to the business operation used to receive network agents from NETCONF protocol network management entities and other non-NETCONF protocol network management entities. For example, if a network administrator user performs a configuration operation on the client interface, the server receives the operation content Configure the corresponding data of the server. In this embodiment of the present invention, the form of the server includes, but is not limited to, a NETCONF server, a hub, a router, a switch, and the like. During the execution of the network management method of the embodiment of the present invention, the client sends a NETCONF request including an operation request to the server based on the NETCONF protocol, and the server processes the NETCONF request and returns the processing result to the client.

Referring to FIG. 1-b, FIG. 1-b is a schematic flowchart of an embodiment of a network management method provided by an embodiment of the present invention. As shown in FIG. 1-b, an embodiment of the network management method provided by the embodiment of the present invention may include the following steps:

S101. The server receives the NETCONF request message sent by the client, and the server ignores the unrecognized content in the NETCONF request message sent by the client.

In this embodiment of the present invention, the client may send an edit-config operation request, a get or get-config operation request, and a copy-config operation request to the server through a NETCONF request message.

Example 1

The NETCONF request message includes an edit-config request, a to-be-configured data node based on the client data model, and a to-be-configured value of the to-be-configured data node;

The server determines whether the to-be-configured data node can be identified based on the server data model, and when the to-be-configured data node can be identified, the server uses the to-be-configured value to perform data configuration on the to-be-configured data node , when the data node to be configured cannot be identified, the server ignores the data node to be configured;

The server sends the NETCONF response message to the client, where the NETCONF response message includes an indication of whether the data configuration is successful.

In this embodiment of the present invention, the edit-config request may be a data configuration request, that is, the client makes the server configure the corresponding data by sending an edit-config request operation to the server.

The data node to be configured may be one or several data nodes in the client data model, or may be all data nodes in the client data model, and the value to be configured of the data node to be configured may be based on the client data model Sent to the server, or included in the NETCONF request message in other forms.

It should be noted that, in this embodiment of the present invention, when the client needs to configure certain data, it sends a NETCONF request message to the server, where the NETCONF request message includes an edit-config request, the data node to be configured (due to the The NETCONF request message is sent by the client, so the data node to be configured is a data node based on the client data model), and the value to be configured corresponding to the data node to be configured, so the server receives the NETCONF request After the message, it will perform loose matching on the NETCONF request message based on the friend connection, that is, the server will check whether the data node to be configured exists in the server data model, and if it finds that the data node to be configured exists in the server data model , that is, the server can identify the data node to be configured, so that the server will use the value to be configured corresponding to the data node to be configured to perform data configuration on the data node to be configured; if the server does not find the data node to be configured in the server data model. data node, so the server will ignore the data node to be configured.

Further, in some possible implementations of the present invention, there are multiple data nodes to be configured, some of which are data nodes identifiable by the server, and some are data nodes that are not identifiable by the server, then the server will search based on the server data model. And determine identifiable data nodes and unidentifiable data nodes in the data nodes to be configured, the specific determination method is the same as the above embodiment, and then the server uses the to-be-configured data nodes to configure the data nodes to be configured. data configuration, and at the same time, the server will ignore the unrecognized to-be-configured data nodes in the to-be-configured data nodes, that is, do not perform data configuration on the unrecognized to-be-configured data nodes in the to-be-configured data nodes.

Further, after the server only performs data configuration on the data nodes to be configured that the server can identify, if the data configuration is successful, it returns an indication of successful data configuration to the client, and if the data configuration is unsuccessful, returns the data configuration to the client. Unsuccessful instructions.

For example, in some possible implementations of the present invention, if the client data model model includes data node new, data node id and data node name, and the server data model model includes data node type, data node id and data node name 1-c, and FIG. 1-c is a schematic diagram of a client data model and a server data model provided by an embodiment of the present invention.

If the client requests to configure the value of the data node new as 1 and the value of the data node name as double based on the client data model, the server will determine the name of the data node that can be recognized based on the server data model, so the server will ignore the unrecognized data node. For the data node new, only the identifiable data node name=double is configured, and a NETCONF response message is used to return the successfully configured processing result to the client. Referring to FIG. 1-d, FIG. 1-d is a schematic diagram of an edit-config operation flow according to an embodiment of the present invention;

If the client requests to configure all the data in A, the server will ignore the unrecognized node new, and then configure the data based on the server data model for the identifiable node id and name.

It can be understood that this kind of communication method based on friend connection that does not strictly match can solve the problem that the versions of the client and the server do not match, that is, when the client data model is inconsistent with the server data model, the data configuration can also be carried out smoothly. No error is reported, so that the edit-config operation based on the NETCONF protocol can be carried out smoothly, and the network management efficiency can be improved.

Example 2

The server receives a NETCONF request message sent by the client, where the NETCONF request message includes a get or get-config request and a data filtering condition based on the client data model, where the data filtering condition includes selecting a data node;

The server determines whether the selected data node can be identified based on the server data model, and when the selected data node can be identified, the server obtains the selected data node corresponding to the selected data node from preset server data value to obtain the acquisition result data, when the selection data node cannot be identified, the server ignores the selection data node;

The server sends the NETCONF response message to the client, where the NETCONF response message includes the acquisition result data.

In this embodiment of the present invention, the get or get-config request may indicate that the client requests to obtain data from the server or query data, wherein get is used for the client to obtain or query data from the server when the data type is not restricted, and get -config is used on the client to get or query configuration data from the server.

The preset server data refers to the data acquisition source that exists in the server and when the server acquires data from the server by using get or get-config. Obviously, the preset server data is based on the server data model. Preferably, the preset server data is data that is currently being operated in a thread running on the current server.

The data filtering condition refers to the condition that the data to be acquired needs to be satisfied when acquiring data for get or get-config, that is, the server acquires the corresponding data from the server based on the data filtering condition, and the data filtering condition includes selecting a data node , select the data node to specify the data node when the server obtains data.

It should be noted that when the client needs to obtain data from the server, it sends a NETCONF request message to the server. In the NETCONF request message, the get or get-config request and data filtering conditions include selecting data nodes, thereby When the server receives the NETCONF request message, it will perform loose matching filtering on the data filter condition based on the friend connection, that is, the server will check whether the selected data node exists in the server data model based on the server data model. When the selected data node exists in the server data model, it means that the selected data node can be recognized by the server. At this time, the server will obtain the selected data node value corresponding to the selected data node from the preset server data to obtain the obtained result data. The selection data node does not exist in the server data model, which means that the server cannot recognize the selection data node, so the server will ignore the selection data node.

Further, the data filtering condition also includes a content matching data node and a matching value corresponding to the content matching data node, and the content matching data node is used by the server to obtain the content matching data node from the preset server data based on the server data model. And the content matching data node value is equal to the preset server data of the matching value.

In this embodiment of the present invention, after a friend connection is established between the client and the server, regardless of whether the server can identify the content matching data node, the server will use the content matching data node to perform data filtering to obtain acquisition result data , because if the server ignores the unrecognized content that matches the data node, it is equivalent to discarding the part of the data restriction condition by the server, resulting in an error in obtaining the result data.

Optionally, in some possible embodiments of the present invention, the data filtering conditions may only include selected data nodes, may only include content matching data nodes, or may include both selected data nodes and content matching data nodes, and the server is in the The acquisition rules based on the acquisition of data from the preset server data by using the data filtering conditions are: for content matching data nodes including content matching data node values, the server will use all content matching data nodes and content matching data node values to perform matching filtering The obtained result data is obtained, and for the selection data node, the server will determine the recognizable selection data node and the unrecognized selection data node based on the server data model. For the unrecognized selection data node, the server will ignore this part of the selection data node, do not use this part of the selected data node to obtain data, and only retain the identifiable selected data node as a filter condition, so that the server uses the identifiable selected data node to obtain the value of the selected data node from the preset server data to obtain the result. data.

In this embodiment of the present invention, the acquisition result data may be data including all node values in the server data model, or may be data including only some node values in the server data model.

Example three

The server receives the NETCONF request message sent by the client, where the NETCONF request message includes a copy-config request, a data source identifier corresponding to the copy-config request, and a data source identifier corresponding to the copy-config request. The target data set identifier and the data node to be copied based on the data source data model, the first friend capability is also used to indicate that the server ignores the unrecognized fields in the data source indicated by the data source identifier;

The server determines whether the data node to be copied can be identified based on the server data model, and when the data node to be copied can be identified, the server copies the data to be copied in the data source indicated by the data source identifier. The value of the data node is included in the target data set indicated by the target data set identifier, and when the data node to be copied cannot be identified, the server ignores the value of the data node to be copied in the data source;

The server sends a NETCONF response message to the client, where the NETCONF response message includes an indication of whether data copying is successful.

The data indicated by the data source identifier may be data existing in the server or data in other locations. For example, if the data source identifier is a uniform resource locator (Uniform Resoure Locator, URL for short), the data The source is the data pointed to by the URL, and the target data set can be the server's running data set.

The data node to be copied may be one or several data nodes in the data source data model, or may be all data nodes in the data source data model.

It should be noted that, in this embodiment of the present invention, when the client requests to copy data from a certain data source, the client sends a NETCONF request message to the server, where the NETCONF request message includes a copy-config request, and the copy-config request message. The identifier of the data source corresponding to the config request, the identifier of the target dataset corresponding to the copy-config request, and the data node to be copied based on the data source data model, so that after receiving the NETCONF request message, the server will The NETCONF request message is not strictly matched, that is, the server will find out whether the data node to be copied exists in the server data model. If it finds that the data node to be copied exists in the server data model, that is, the server can identify the data to be copied. node, so that the server will copy the value corresponding to the data node to be copied from the data source indicated by the data source identifier to the target dataset indicated by the target dataset identifier. If the server does not find the data to be copied in the server data model node, so the server will ignore the data node to be copied.

Further, in some possible implementations of the present invention, there are multiple data nodes to be copied, some of which are data nodes identifiable by the server, and some are data nodes that are not identifiable by the server, then the server will search based on the server data model. And determine the identifiable data nodes and unidentifiable data nodes in the data nodes to be copied, the specific determination method is the same as the above embodiment, and then the server copies the data nodes in the data source to be copied. , and the server will ignore the unidentifiable data nodes in the data nodes to be copied. When the data copy is successful, the server will return a copy success indication to the client, and when the data copy is unsuccessful, the server will return an unsuccessful data copy indication to the client.

For example, in some possible implementations of the present invention, if the data source data model model includes data node new, data node id and data node name, and the server data model model includes data node type, data node id and data node name , if the data node to be copied is new and id, since the server can only identify the data node id based on the server data model, the server will copy the value of the data node new in the data source indicated by the url to the target data set, ignoring the data in the data source The value of node new, and finally return the copy success indication to the client;

If the client requests to copy all the data in the data source, the server will ignore the value of the node new that cannot be recognized, and copy the value of the node id and name that the server can recognize to the target data set.

It can be understood that by performing a communication method that does not strictly match the data source indicated by the data source identifier sent by the client based on the friend connection, the problem that the data source data model does not match the server data model can be solved, that is, the client data model. When the data model is different from that of the server, the data can be copied smoothly without error reporting, so that the copy-config operation based on the NETCONF protocol can be carried out smoothly, and the network management efficiency can be improved.

S102. The server sends a NETCONF response message to the client, where the NETCONF response message includes a processing result of processing according to the NETCONF request message.

S103. The client receives the NETCONF response message sent by the server, and the client ignores the unrecognized content in the NETCONF response message sent by the server.

As an example, for example, the client receives a NETCONF response message returned by the server, where the NETCONF response message includes acquisition result data obtained by the server according to a get or get-config request, wherein the acquisition result The data model of the data is the server data model;

The client determines identifiable data nodes and unidentifiable data nodes in the acquisition result data based on the client data model, and the client stores the identifiable data nodes in the acquisition result data. The value of the data node, and the value of the data node that cannot be identified in the acquisition result data is ignored.

It should be noted that after the client receives the acquisition result data returned by the server, the client will determine, based on the client data model, whether each data node in the acquisition result data based on the server data model exists in the client data model. The data node of the client data model means that the client can recognize it. At this time, the client will save the value of the data node in the obtained result data based on the client data model. For data nodes that do not exist in the client data model, then Indicates that the client does not recognize the data node and ignores the data node at this time.

For example, in some possible implementations of the present invention, still referring to the schematic diagrams of the client data model and the server data model shown in FIG. 1-c, if the client data model model includes data node new, data node id and data node name, and the server data model model includes data node type, data node id and data node name. When the client requests to obtain the values of data node new and data node name based on the client data model, the data node new and data node name are equivalent at this time. In the selection data node in the filter conditions, the server will determine the name of the selection data node that can be identified in the selection data node and new based on the server data model. For example, modelA, the value of the data node name in modelA is double), get the value of the data node name, get double, this value is the obtained result data, and then the server returns the obtained result data to the client through the NETCONF response message, After the client receives the value double of the data node name, since the name exists in the client data model, that is, the client can identify the obtained result data, the client will save the value double of the data node name, as shown in Figure 1-e 1-e is a schematic flowchart of a first embodiment of a get or get-config operation provided by an embodiment of the present invention.

In another embodiment, if the client requests to obtain all the data of data node id=1 and data node new=2 in the preset server data, it is equivalent to setting the data node id and data node name as content matching data nodes, Since there is no data node new in the server data model, when using the filter condition of new=2 for data filtering, the preset server data will not be able to be searched for any preset server data that satisfies new=2, and finally returned Empty data is given to the client, but when the server uses the filter condition to filter, it cannot ignore the filter condition of new=2 based on the friend connection between the client and the server. If it is ignored, it is equivalent to deleting the filter condition. At this time, it is equivalent to only obtain the data with id=1 in the preset server data, which is the obtained result data, and the result display is different from the expected result. Please refer to Figure 1-f. Figure 1-f is the implementation of the present invention A schematic flowchart of the second embodiment of a get or get-config operation provided by the example.

In another embodiment, if the client requests to obtain the value of the data node new in the data of the data node id=1 in the preset server data, this is equivalent to setting the data filter condition, id is the content matching data node, and new is Select the data node, when the server receives the acquisition request, it first filters the data with the data node id=1 in the preset server data, for example, two data modelA and modelB are obtained at this time, and when the selected data node new is used for filtering , since there is no data node new in the server data model, it will not obtain any data from modelA and modelB, and finally return empty data to the client, see Figure 1-g, Figure 1-g is provided by the embodiment of the present invention A schematic flowchart of a third embodiment of a get or get-config operation.

In yet another embodiment, if the client sets the data filtering condition to include only the content matching node id=1, that is, it requests to obtain all the data of the data node id=1 in the preset server data, for example, the data modelA obtained at this time is the acquisition For the result data, the server returns modelA (modelA is based on the server data model, and the values of each data node are type=1, id=1, name=1) to the client. After the client receives the data, it will be based on the client The terminal data model determines the identifiable data node id and name, and saves the data node id value of 1 and the data node name value of 2. For the unrecognized data node type, it is ignored. See Figure 1-h, Figure 1. 1-h is a schematic flowchart of a fourth embodiment of a get or get-config operation provided by an embodiment of the present invention.

It can be understood that after a friend connection is established between the client and the server, in the process of the server processing the filter conditions of the get or get-config operation based on the NETCONF protocol, if the content matches the data node, all of them are filtered as filter conditions. Selecting data nodes ignores unrecognized selection nodes. In this way, the problem that the client and server versions do not match is solved, and the obtained result data is correct. After the obtained result data is finally returned to the client, the client has no effect on the obtained result data. In the process of parsing and saving, loose matching is also performed. Data nodes that cannot be recognized are ignored, and only data nodes that can be recognized by the client are saved. In this way, the problem that the client and server versions do not match is solved. Therefore, even when the client and server versions are inconsistent, that is, when the client data model is inconsistent with the server data model, the get or get-config operation can be smoothly performed without an error being reported, and the network management efficiency can be improved.

Optionally, in some possible embodiments of the present invention, before executing S101, the method further includes:

S101', the server sends a first Hello packet to the client via the SSH connection between the client and the server.

Wherein, the first Hello packet carries a first friend friendly-element identifier, and the first friend friendly-element identifier is used to indicate that the server has a first friend capability, and the first friend capability It is used to indicate that the server ignores the unrecognized fields in the NETCONF request message received from the client.

At the same time, after the server sends the first Hello message to the client via the SSH connection, the client receives the first Hello message sent by the server via the SSH connection between the client and the server. The document carries the first friend friendly-element identifier, which is used to indicate that the server has the first friend capability, and the first friend capability is used to indicate that the server has a The unrecognized fields in the received NETCONF request message from the client are ignored.

In this embodiment of the present invention, the client may send an edit-config operation request, a get or get-config operation request, and a copy-config operation request to the server through a NETCONF request message.

The SSH connection, that is, the Secure Shell connection, refers to a physical communication connection between the client and the server, so that based on the SSH connection, the client and the server can send Hello packets to establish a session connection.

S102', the client sends a second Hello packet to the server via the SSH connection.

The second Hello packet carries a second friend friendly-element identifier, and the second friend friendly-element identifier is used to indicate that the client has a second friend capability, and the second friend The capability is used to indicate that the client ignores the unrecognized fields in the NETCONF response message received from the server.

At the same time, the client sends a second Hello packet via the SSH connection, the server receives a second Hello packet from the client via the SSH connection, and the second Hello packet carries the second friend friendly-element identifier , the second friend friendly-element identifier is used to indicate that the client has a second friend capability, and the second friend capability is used to indicate that the client responds to the NETCONF received from the server Unrecognized fields in the packet are ignored.

The NETCONF response message refers to a data message returned by the server after processing the NETCONF request message sent by the client.

Further, in addition to the NETCONF response message, the data message sent by the server to the client may also be a NETCONF notification message, which refers to a data message actively sent by the server to the client.

S103', the server determines the friend relationship between the server and the client according to the first friend friendly-element identifier and the second friend friendly-element identifier.

Correspondingly, the client determines the friend relationship between the client and the server according to the first friend friendly-element identifier and the second friend friendly-element identifier.

It can be understood that after the friend relationship between the client and the server is determined in the above manner, it means that the client and the server can communicate based on the friend capability, so that the client and the server can perform a non-strict match during the communication process. The processing method will not report an error.

It should be noted that in this embodiment of the present invention, loose matching means that both parties in the communication ignore the unidentifiable fields in the data message sent by the other party, that is, the server responds to the NETCONF request message received from the client. The unrecognized fields in the text are ignored, and the client ignores the unrecognized fields in the NETCONF response message received from the server, without causing an error, so that the versions of the client and the server can be inconsistent. The communication between the two parties can be carried out smoothly.

Further, when the server and the client are of the same version, that is, the data model of the server and the client is the same, and in the case of communication based on the friend connection between the server and the client, when the server and the client communicate Strict matching will also be carried out based on the model, which is the same as the communication method when the friend connection is not established, so the establishment of the friend connection will not affect the normal communication of each other when the server and client versions are the same.

It can be seen that in the solution of this embodiment, the server sends a first Hello packet to the client through the SSH connection between the client and the server, and the first Hello packet carries the first friend friendly-element identifier, The first friend friendly-element identifier is used to indicate that the server has the first friend capability, and the first friend capability is used to indicate that the server is in the received NETCONF request message from the client. Unrecognized fields are ignored; the client also sends a second Hello packet to the server at the same time, and the second Hello packet carries the second friend friendly-element identifier, and the second friend friendly-element identifier is used to indicate that the client has a second friend capability, and the second friend capability is used to indicate that the client ignores the unrecognized field in the NETCONF response message received from the server; Therefore, after the server receives the second Hello packet sent by the client, and the client receives the first Hello packet sent by the server, the relationship between the server and the client is based on the first friend friendly-element identifier and the second Hello packet. The friendly-element logo establishes a friendly-element relationship. The friendly element relationship between the server and the client is established by carrying the friendly-element identifier in the Hello message between the server and the client, so that the server and the client can communicate based on the principle of non-strict matching. Therefore, communication can be performed smoothly even when the versions of the server and the client are inconsistent, and the network management efficiency is improved.

Optionally, in some possible embodiments of the present invention, the method further includes:

If the server detects that the client data model or the server data model has changed, it determines whether the client data model is consistent with the server data model;

If the data model of the client is consistent with the data model of the server, the server disables the first friend capability, so that the server does not have the ability to fail in the NETCONF request message received from the client. The ability for recognized fields to be ignored.

Optionally, in some possible embodiments of the present invention, the method further includes:

If the client data model is consistent with the server data model, the server sends an instruction message to the client via the SSH connection, instructing the client to disable the second friend capability, so that all The client does not have the ability to ignore the unrecognized fields in the NETCONF response message received from the server.

Optionally, in some possible embodiments of the present invention, the method further includes:

The method also includes:

If the client detects that the client data model or the server data model has changed, then determine whether the client data model is consistent with the server data model;

If the client data model is consistent with the server data model, the client disables the second friend capability, so that the client does not have the NETCONF response message received from the server The ability to ignore unrecognized fields in .

Optionally, in some possible embodiments of the present invention, the method further includes:

If the client data model is consistent with the server data model, the client sends an instruction message to the server via the SSH connection to instruct the server to disable the first friend capability, so that the The server does not have the ability to ignore the unrecognized fields in the received NETCONF request message from the client.

Specifically, by resending a Hello packet carrying the friendly-element-off identifier between the client and the server, the function can be disabled and the opposite end can be instructed to disable the friend capability at the same time.

It should be noted that in order to make the communication between the client and the server more secure and strict, the friend connection of both parties can be closed when the versions of the client and the server are the same, and when the client version or the server version is upgraded, the client data will be The model or server data model changes, so when the client data model or the server data model changes, the client or server can detect whether the client data model is consistent with the server data model, and check whether the client data model and the server data model are consistent. When the models are consistent, the friend capabilities of both parties are turned off, so that the client does not have the ability to ignore the unrecognized fields in the NETCONF response message received from the server, and the server does not have the ability to The capability of ignoring unrecognized fields in the client's NETCONF request message.

It can be understood that when the client and the server establish a friend connection, the friend capabilities of both parties are closed after the data models of the client and the server are upgraded to the same level, so that the communication between the client and the server is based on strict model matching again. Ensure communication security and make network management more flexible.

In order to facilitate better understanding and implementation of the above solutions in the embodiments of the present invention, several specific application scenarios will be used for description below.

Referring to FIG. 2, FIG. 2 is a schematic flowchart of a second embodiment of a network management method according to an embodiment of the present invention. As shown in FIG. 2 , the second embodiment of the network management method provided by the embodiment of the present invention may include the following steps:

S201. The server sends a first Hello packet to the client via the SSH connection between the client and the server.

Wherein, the first Hello packet carries a first friend friendly-element identifier, and the first friend friendly-element identifier is used to indicate that the server has a first friend capability, and the first friend capability It is used to indicate that the server ignores the unrecognized fields in the NETCONF request message received from the client.

Meanwhile, after the server sends the first Hello message to the client via the SSH connection, the client receives the first Hello message sent by the server via the SSH connection between the client and the server.

S202, the client sends a second Hello packet to the server via the SSH connection.

The second Hello packet carries a second friend friendly-element identifier, and the second friend friendly-element identifier is used to indicate that the client has a second friend capability, and the second friend The capability is used to indicate that the client ignores the unrecognized fields in the NETCONF response message received from the server.

Meanwhile, the client sends the second Hello packet via the SSH connection, and the server receives the second Hello packet from the client via the SSH connection.

Specifically, in this embodiment of the present invention, the client and the server can send a Hello packet carrying friendly-element through the following codes.

Server hello message:

Client hello message:

S203. The server determines the friend relationship between the server and the client according to the first friend friendly-element identifier and the second friend friendly-element identifier.

Correspondingly, the client determines the friend relationship between the client and the server according to the first friend friendly-element identifier and the second friend friendly-element identifier.

S204. The client sends a NETCONF request message to the server, where the NETCONF request message includes a get or get-config request.

In addition, the NETCONF request message also includes data filtering conditions based on the client data model, and the data filtering conditions include selecting data nodes.

After the client sends the NETCONF request message to the server, the server receives the NETCONF request message sent by the client.

Specifically, it can be implemented by the following code.

In an embodiment of the present invention, it is assumed that the data model of the server is as follows:

The client data model is as follows:

It can be seen that the server is a newer version and has one more leaf node id than the client.

In an embodiment of the present invention, the code for the client to send the request message is as follows:

In another embodiment of the present invention, it is assumed that the data model of the client is as follows:

The data model of the server is as follows:

It can be seen that the client is a newer version, with 2 more leaf nodes id and new than the server.

In another embodiment of the present invention, the code for the client to send the request message is as follows:

S205, the server obtains data from the preset server data according to the get or get-config request to obtain the obtained result data.

The server determines whether the selected data node can be identified based on the server data model, and when the selected data node can be identified, the server obtains the selected data node corresponding to the selected data node from preset server data value to obtain the acquisition result data, when the selected data node cannot be identified, the server ignores the selected data node.

S206, the server sends a NETCONF response message to the client, where the NETCONF response message includes the acquisition result data.

After the server sends the NETCONF response message to the client, the client receives the NETCONF response message sent by the server, and the NETCONF response message includes the acquisition result data.

In an embodiment of the present invention, the server returning a NETCONF response message can be implemented by the following code:

In another embodiment of the present invention, the server returning a NETCONF response message can be implemented by the following code:

When the server uses the content matching node id for matching, since the data node id does not exist in the server data model, it returns empty data.

S207, the client saves the acquisition result data based on the client data model.

The client determines identifiable data nodes and unidentifiable data nodes in the acquisition result data based on the client data model, and the client stores the identifiable data nodes in the acquisition result data. The value of the data node, and the value of the data node that cannot be identified in the acquisition result data is ignored.

Based on the above code analysis, after receiving the acquisition result data returned by the server, the client ignores the unrecognized node id based on the client data model, and saves name=a and other=foo.

It should be noted that the steps and descriptions in the second embodiment of the network management method provided by the embodiments of the present invention are the same as those in the first embodiment of the network management method provided by the embodiments of the present invention, and are not repeated here.

It can be seen that, in the solution of this embodiment, after a friend connection is established between the client and the server, the get or get-config operation between the server and the client can be performed based on the friend connection, so that the client and When the server data model is inconsistent, the communication can be carried out smoothly, and the network management efficiency can be improved.

The following describes the specific implementation of the edit-config operation request and the copy-config operation request in the NETCONF operation protocol. Referring to FIG. 3, FIG. 3 is a schematic flowchart of a third embodiment of a network management method provided by an embodiment of the present invention. , this embodiment is implemented based on the determination of the friend relationship between the client and the server, that is, after step S103, it may further include steps:

S301. The client sends a NETCONF request message to the server, where the NETCONF request message includes a data operation request.

In addition, when the NETCONF request message includes an edit-config request, the NETCONF request message also includes the data node to be configured based on the client data model and the to-be-configured value of the data node to be configured.

In some other possible embodiments of the present invention, when the NETCONF request message includes a copy-config request, the NETCONF request message further includes a data source identifier corresponding to the copy-config request, a data source identifier corresponding to the copy-config request, and the copy-config request. -config requests the corresponding target dataset identifier and the data node to be copied based on the data source data model.

After the client sends the NETCONF request message to the server, the server receives the NETCONF request message sent by the client.

Specifically, in some possible implementations of the present invention, the edit-config operation request can be implemented by the following code.

Specifically, it is assumed that the data model of the client is as follows:

The data model of the server is as follows:

It can be seen that the client is a newer version with one more leaf node id than the server

The client can send the NETCONF request message to the server through the following code:

S302, the server processes the data operation request.

Optionally, when the server edit-config request is processed, the server determines whether the data node to be configured can be identified based on the server data model, and when the data node to be configured can be identified, the server uses the The to-be-configured value performs data configuration on the to-be-configured data node, and when the to-be-configured data node cannot be identified, the server ignores the to-be-configured data node;

Optionally, when the server copy-config request is processed, the server determines whether the data node to be copied can be identified based on the server data model, and when the data node to be copied can be identified, the server copies all data nodes. The value of the data node to be copied in the data source indicated by the data source identifier is added to the target data set indicated by the target data set identifier. When the data node to be copied cannot be identified, the server ignores the value of the data node to be copied. The value of the data node to be copied in the data source.

Specifically, after the server receives the configuration request of the code in step S302, since the client and the server are in a friend relationship, the matching is not strictly performed. The data node name and other.

S303. The server sends an indication to the client whether the data operation processing is successful.

Optionally, when the data operation request is an edit-config request, the server sends a NETCONF response message to the client, where the NETCONF response message includes an indication of whether the data configuration is successful.

Optionally, when the data operation request is a copy-config request, the server sends a NETCONF response message to the client, where the NETCONF response message includes an indication of whether the data copy is successful.

After the server sends an indication of whether the data operation processing is successful to the client, the client will receive the indication of whether the data operation is successful sent by the server.

In response to the configuration request in step S301, after the server performs the configuration operation, based on the successful configuration of the friend connection, no error is reported, and a NETCONF response message with successful configuration is returned. The specific code implementation can be as follows:

It should be noted that the steps and descriptions in the second embodiment of the network management method provided by the embodiments of the present invention are the same as those in the first embodiment of the network management method provided by the embodiments of the present invention, and are not repeated here.

It can be seen that in the solution of this embodiment, after a friend connection is established between the client and the server, the edit-config or copy-config operation between the server and the client can be performed based on the friend connection, so that the client When the data model of the client and server is inconsistent, the communication can be carried out smoothly, and the efficiency of network management can be improved.

The embodiment of the present invention also provides a server, the server includes:

a receiving unit, used for the server to receive the network configuration protocol NETCONF request message sent by the client;

A processing unit, used for the server to ignore the unrecognized content in the NETCONF request message sent by the client;

A sending unit, used for the server to send a NETCONF response message to the client, where the NETCONF response message includes a processing result of processing according to the NETCONF request message.

It can be understood that in the above manner, the client and the server can perform a processing method that does not strictly match during the communication process, and no error will be reported, thereby improving the network execution efficiency and management efficiency.

It should be noted that in this embodiment of the present invention, loose matching means that both parties in the communication ignore the unidentifiable fields in the data message sent by the other party, that is, the server responds to the NETCONF request message received from the client. The unrecognized fields in the text are ignored, and the client ignores the unrecognized fields in the NETCONF response message received from the server, without causing an error, so that the versions of the client and the server can be inconsistent. The communication between the two parties can be carried out smoothly.

Further, when the server and the client are of the same version, that is, the data model of the server and the client is the same, and in the case of communication based on the friend connection between the server and the client, when the server and the client communicate Strict matching will also be carried out based on the model, which is the same as the communication method when the friend connection is not established, so the establishment of the friend connection will not affect the normal communication of each other when the server and client versions are the same.

FIG. 4 is a schematic structural diagram of another embodiment of a server provided by an embodiment of the present invention, which is used to implement the network management method disclosed by the embodiment of the present invention. Wherein, as shown in FIG. 4 , a server 400 provided by an embodiment of the present invention may include:

A sending unit 410 , a receiving unit 420 and a determining unit 430 .

The sending unit 410 is used for the server to send a first Hello packet to the client via the SSH connection between the client and the server, where the first Hello packet carries the first friend friendly-element identifier , the first friend friendly-element identifier is used to indicate that the server has a first friend capability, and the first friend capability is used to indicate that the server has received a NETCONF request message from the client The unrecognized fields in the field are ignored;

The SSH connection, that is, the Secure Shell connection, refers to a physical communication connection between the client and the server, so that based on the SSH connection, the client and the server can send Hello packets to establish a session connection.

A receiving unit 420, configured for the server to receive a second Hello packet from the client via the SSH connection, where the second Hello packet carries a second friend friendly-element identifier, the second friend friendly-element The element identifier is used to indicate that the client has a second friend capability, and the second friend capability is used to indicate that the client ignores the unrecognized fields in the NETCONF response message received from the server. deal with;

Further, in addition to the NETCONF response message, the data message sent by the server to the client may also be a NETCONF notification message, which refers to a data message actively sent by the server to the client.

The determining unit 430 is used for the server to determine the friend relationship between the server and the client according to the first friend friendly-element identifier and the second friend friendly-element identifier.

It can be seen that in the solution of this embodiment, the server 400 sends a first Hello packet to the client via the SSH connection between the client and the server, where the first Hello packet carries the first friendly-element identifier , the first friend friendly-element identifier is used to indicate that the server 400 has the first friend capability, and the first friend capability is used to indicate that the server 400 receives the NETCONF request from the client The unrecognized fields in the message are ignored; the server 400 receives the second Hello message sent by the client via the SSH connection between the client and the server 400, and the second Hello message carries the second friend friendly -element identifier, the second friend friendly-element identifier is used to indicate that the client has a second friend capability, and the second friend capability is used to indicate that the client has The unrecognized fields in the NETCONF response packet of 400 are ignored; the server 400 and the client establish a friend relationship according to the first friend friendly-element identifier and the second friend friendly-element identifier. The friendly element relationship between the server and the client is established by carrying the friendly-element identifier in the Hello message between the server and the client, so that the server and the client can communicate based on the principle of non-strict matching. Therefore, communication can be performed smoothly even when the versions of the server and the client are inconsistent, and the network management efficiency is improved.

In this embodiment, the server 400 is presented in the form of a unit. A "unit" herein may refer to an application-specific integrated circuit (ASIC), a processor and memory executing one or more software or firmware programs, an integrated logic circuit, and/or other devices that may provide the above-described functions .

It can be understood that the functions of each functional unit of the server 400 in this embodiment can be specifically implemented according to the methods in the above method embodiments, and the specific implementation process can refer to the relevant descriptions of the above method embodiments, which will not be repeated here.

Referring to FIG. 5, FIG. 5 is a schematic structural diagram of still another embodiment of a server provided by an embodiment of the present invention, which is used to implement the network management method disclosed by the embodiment of the present invention. The server shown in FIG. 5 is obtained by optimizing the server shown in FIG. 4 . The server shown in Figure 5 has the following extensions in addition to the elements of the server shown in Figure 4:

The receiving unit 520 is further configured for the server to receive a NETCONF request message sent by the client, where the NETCONF request message includes an edit-config request, a data node to be configured based on the client data model, and a to-be-configured data node. The to-be-configured value of the data node;

The server 500 further includes:

The processing unit 540 is used for the server to determine whether the data node to be configured can be identified based on the server data model, and when the data node to be configured can be identified, the server uses the value to be configured for the data node to be configured. configuring data nodes to perform data configuration, and when the data nodes to be configured cannot be identified, the server ignores the data nodes to be configured;

The sending unit 510 is further configured for the server to send the NETCONF response message to the client, where the NETCONF response message includes an indication of whether the data configuration is successful.

In this embodiment of the present invention, the edit-config request may be a data configuration request, that is, the client makes the server configure the corresponding data by sending an edit-config request operation to the server.

The data node to be configured may be one or several data nodes in the client data model, or may be all data nodes in the client data model, and the value to be configured of the data node to be configured may be based on the client data model Sent to the server, or included in the NETCONF request message in other forms.

Optionally, in some possible implementations of the present invention, the receiving unit 520 is further configured to:

The server receives a NETCONF request message sent by the client, where the NETCONF request message includes a get or get-config request and a data filtering condition based on the client data model, where the data filtering condition includes selecting a data node;

The processing unit 540 is also used for:

The server determines whether the selected data node can be identified based on the server data model, and when the selected data node can be identified, the server obtains the selected data node corresponding to the selected data node from preset server data value to obtain the acquisition result data, when the selection data node cannot be identified, the server ignores the selection data node;

The sending unit 510 is further configured for the server to send the NETCONF response message to the client, where the NETCONF response message includes the acquisition result data.

In this embodiment of the present invention, the get or get-config request may indicate that the client requests to obtain data from the server or query data, wherein get is used for the client to obtain or query data from the server when the data type is not restricted, and get -config is used on the client to get or query configuration data from the server.

The preset server data refers to the data acquisition source that exists in the server and when the server acquires data from the server by using get or get-config. Obviously, the preset server data is based on the server data model. Preferably, the preset server data is data that is currently being operated in a thread running on the current server.

The data filtering condition refers to the condition that the data to be acquired needs to be satisfied when acquiring data for get or get-config, that is, the server acquires the corresponding data from the server based on the data filtering condition, and the data filtering condition includes selecting a data node , select the data node to specify the data node when the server obtains data.

Further, the data filtering condition also includes a content matching data node and a matching value corresponding to the content matching data node, and the content matching data node is used by the server to obtain the content matching data node from the preset server data based on the server data model. And the content matching data node value is equal to the preset server data of the matching value.

Optionally, in some possible implementations of the present invention, the data filtering conditions may include only selection data nodes, only content matching data nodes, or both selection data nodes and content matching data nodes.

In this embodiment of the present invention, the acquisition result data may be data including all node values in the server data model, or may be data including only some node values in the server data model.

Optionally, in some possible implementations of the present invention, the receiving unit 520 is further configured to:

The server receives the NETCONF request message sent by the client, where the NETCONF request message includes a copy-config request, a data source identifier corresponding to the copy-config request, and a data source identifier corresponding to the copy-config request. The target data set identifier and the data node to be copied based on the data source data model, the first friend capability is also used to indicate that the server ignores the unrecognized fields in the data source indicated by the data source identifier;

The processing unit 540 is also used for:

The server determines whether the data node to be copied can be identified based on the server data model, and when the data node to be copied can be identified, the server copies the data to be copied in the data source indicated by the data source identifier. The value of the data node is included in the target data set indicated by the target data set identifier, and when the data node to be copied cannot be identified, the server ignores the value of the data node to be copied in the data source;

The sending unit 510 is further configured for the server to send a NETCONF response message to the client, where the NETCONF response message includes an indication of whether data copying is successful.

The data indicated by the data source identifier may be data existing in the server or data in other locations. For example, if the data source identifier is a uniform resource locator (Uniform Resoure Locator, URL for short), the data The source is the data pointed to by the URL, and the target data set can be the server's running data set.

The data node to be copied may be one or several data nodes in the data source data model, or may be all data nodes in the data source data model.

Optionally, in some possible implementations of the present invention, the server 500 further includes:

A judgment unit 550, configured to judge whether the client data model is consistent with the server data model if the server detects that the client data model or the server data model has changed;

The processing unit 540 is further configured to disable the first friend capability of the server if the client data model is consistent with the server data model, so that the server does not have the ability to respond to the received data from the server. Describes the capability of ignoring unrecognized fields in the client's NETCONF request message.

Optionally, in some possible implementations of the present invention, the sending unit 510 is further configured to:

If the client data model is consistent with the server data model, the server sends an instruction message to the client via the SSH connection, instructing the client to disable the second friend capability, so that all The client does not have the ability to ignore the unrecognized fields in the NETCONF response message received from the server.

Specifically, by resending a Hello packet carrying the friendly-element-off identifier between the client and the server, the function can be disabled and the opposite end can be instructed to disable the friend capability at the same time.

It should be noted that in order to make the communication between the client and the server more secure and strict, the friend connection of both parties can be closed when the versions of the client and the server are the same, and when the client version or the server version is upgraded, the client data will be The model or server data model changes, so when the client data model or the server data model changes, the client or server can detect whether the client data model is consistent with the server data model, and check whether the client data model and the server data model are consistent. When the models are consistent, the friend capabilities of both parties are turned off, so that the client does not have the ability to ignore the unrecognized fields in the NETCONF response message received from the server, and the server does not have the ability to The capability of ignoring unrecognized fields in the client's NETCONF request message.

It can be understood that when the client and the server establish a friend connection, the friend capabilities of both parties are closed after the data models of the client and the server are upgraded to the same level, so that the communication between the client and the server is based on strict model matching again. Ensure communication security and make network management more flexible.

It can be seen that in the solution of this embodiment, after the server and the client establish a friend connection, the server and the client can perform data communication that is not strictly matched based on the friend connection, so that the client and server data When the models are inconsistent, the communication can be carried out smoothly and the network management efficiency can be improved.

In this embodiment, the server 500 is presented in the form of a unit. A "unit" herein may refer to an application-specific integrated circuit (ASIC), a processor and memory executing one or more software or firmware programs, an integrated logic circuit, and/or other devices that may provide the above-described functions .

It can be understood that the functions of each functional unit of the server 500 in this embodiment can be specifically implemented according to the methods in the foregoing method embodiments, and the specific implementation process can refer to the relevant descriptions of the foregoing method embodiments, which will not be repeated here.

Referring to FIG. 6, FIG. 6 is a schematic structural diagram of another embodiment of a server provided by an embodiment of the present invention, which is used to implement the network management method disclosed by the embodiment of the present invention. The server 600 may include: at least one bus 601 , at least one processor 602 connected to the bus 601 , and at least one memory 603 connected to the bus 601 .

The processor 602 calls the code stored in the memory through the bus 601 for the server to send a first Hello packet to the client via the SSH connection between the client and the server, and the first Hello packet carries the The first friend friendly-element identifier, the first friend friendly-element identifier is used to indicate that the server has the first friend capability, and the first friend capability is used to indicate that the server has a The unrecognized fields in the NETCONF request message of the client are ignored; the server receives the second Hello message from the client via the SSH connection, and the second Hello message carries the second friend friendly- element identifier, the second friend friendly-element identifier is used to indicate that the client has a second friend capability, and the second friend capability is used to indicate that the client responds to the received information from the server. The unrecognized fields in the NETCONF response message are ignored; the server determines the relationship between the server and the client according to the first friend friendly-element identifier and the second friend friendly-element identifier. Friendship.

Optionally, in some possible implementations of the present invention, the processor 602 is executing the process of determining the relationship between the server and the server according to the first friend friendly-element identifier and the second friend friendly-element identifier. After the friend relationship between clients, the processor 602 is further configured to receive, by the server, a NETCONF request message sent by the client, where the NETCONF request message includes an edit-config request, based on client data The data node to be configured of the model and the value to be configured of the data node to be configured;

The server determines whether the to-be-configured data node can be identified based on the server data model, and when the to-be-configured data node can be identified, the server uses the to-be-configured value to perform data configuration on the to-be-configured data node , when the data node to be configured cannot be identified, the server ignores the data node to be configured;

The server sends the NETCONF response message to the client, where the NETCONF response message includes an indication of whether the data configuration is successful.

Optionally, in some possible implementations of the present invention, the processor 602 is executing the process of determining the relationship between the server and the server according to the first friend friendly-element identifier and the second friend friendly-element identifier. After the friend relationship between clients, the processor 602 is further configured to receive, by the server, a NETCONF request message sent by the client, where the NETCONF request message includes a get or get-config request, and a client-based Data filtering conditions of the terminal data model, the data filtering conditions include selecting data nodes;

The server determines whether the selected data node can be identified based on the server data model, and when the selected data node can be identified, the server obtains the selected data node corresponding to the selected data node from preset server data value to obtain the acquisition result data, when the selection data node cannot be identified, the server ignores the selection data node;

The server sends the NETCONF response message to the client, where the NETCONF response message includes the acquisition result data.

Optionally, in some possible implementations of the present invention, the processor 602 is executing the process of determining the relationship between the server and the server according to the first friend friendly-element identifier and the second friend friendly-element identifier. After the friend relationship between the clients, the processor 602 is further configured to receive, by the server, a NETCONF request message sent by the client, where the NETCONF request message includes a copy-config request, and the copy - The data source identifier corresponding to the config request, the target dataset identifier corresponding to the copy-config request, and the data node to be copied based on the data source data model, the first friend capability is also used to indicate that the server has The unrecognized fields in the data source indicated by the data source identifier are ignored;

The server determines whether the data node to be copied can be identified based on the server data model, and when the data node to be copied can be identified, the server copies the value of the data node to be copied in the data source to the In the target data set indicated by the target data set identifier, when the data node to be copied cannot be identified, the server ignores the value of the data node to be copied in the data source;

The server sends a NETCONF response message to the client, where the NETCONF response message includes an indication of whether data copying is successful.

Optionally, in some possible implementations of the present invention, the processor 602 is further configured to determine the client data model if the server detects that the client data model or the server data model has changed Whether the model is consistent with the server data model;

If the data model of the client is consistent with the data model of the server, the server disables the first friend capability, so that the server does not have the ability to fail in the NETCONF request message received from the client. The ability for recognized fields to be ignored.

Optionally, in some possible embodiments of the present invention, the processor 602 is further configured to, if the client data model is consistent with the server data model, send the server to the client via the SSH connection The client sends an instruction message instructing the client to close the second friend capability, so that the client does not have the ability to ignore the unrecognized fields in the NETCONF response message received from the server. .

It can be seen that, in the solution of this embodiment, the server 600 sends a first Hello packet to the client via the SSH connection between the client and the server, where the first Hello packet carries the first friendly-element identifier , the first friend friendly-element identifier is used to indicate that the server 600 has a first friend capability, and the first friend capability is used to indicate that the server 600 receives a NETCONF request from the client The unrecognized fields in the message are ignored; the server 600 receives the second Hello message sent by the client via the SSH connection between the client and the server 600, and the second Hello message carries the second friend friendly -element identifier, the second friend friendly-element identifier is used to indicate that the client has a second friend capability, and the second friend capability is used to indicate that the client has The unrecognized fields in the NETCONF response message of 600 are ignored; the server 600 and the client establish a friend relationship according to the first friend friendly-element identifier and the second friend friendly-element identifier. The friendly element relationship between the server and the client is established by carrying the friendly-element identifier in the Hello message between the server and the client, so that the server and the client can communicate based on the principle of non-strict matching. Therefore, communication can be performed smoothly even when the versions of the server and the client are inconsistent, and the network management efficiency is improved.

The embodiment of the present invention also provides a client, the client includes:

The sending unit, the client sends a NETCONF request message to the server;

a receiving unit, where the client receives a NETCONF response message sent by the server, where the NETCONF response message includes a processing result processed according to the NETCONF request message;

A processing unit, wherein the client ignores the unrecognized content in the NETCONF response message sent by the server.

FIG. 7 is a schematic structural diagram of another embodiment of a client according to an embodiment of the present invention, which is used to implement the network management method disclosed in the embodiment of the present invention. Wherein, as shown in FIG. 7 , a client 700 provided by an embodiment of the present invention may include:

A receiving unit 710 , a sending unit 720 and a determining unit 730 .

The receiving unit 710 is used for the client to receive the first Hello packet sent by the server via the SSH connection between the client and the server, where the first Hello packet carries the first friend friendly -element identifier, the first friend friendly-element identifier is used to indicate that the server has the first friend capability, and the first friend capability is used to indicate that the server has received the NETCONF from the client The unrecognized fields in the request message are ignored;

A sending unit 720, configured for the client to send a second Hello packet to the server via the SSH connection, where the second Hello packet carries a second friend friendly-element identifier, the second friend friendly-element The element identifier is used to indicate that the client has a second friend capability, and the second friend capability is used to indicate that the client ignores the unrecognized fields in the NETCONF response message received from the server. deal with;

The determining unit 730 is used for the client to determine the friend relationship between the client and the server according to the first friend friendly-element identifier and the second friend friendly-element identifier.

It can be understood that after the friend relationship between the client and the server is determined in the above manner, it means that the client and the server can communicate based on the friend capability, so that the client and the server can perform a non-strict match during the communication process. The processing method will not report an error.

It should be noted that in this embodiment of the present invention, loose matching means that both parties in the communication ignore the unidentifiable fields in the data message sent by the other party, that is, the server responds to the NETCONF request message received from the client. The unrecognized fields in the text are ignored, and the client ignores the unrecognized fields in the NETCONF response message received from the server, without causing an error, so that the versions of the client and the server can be inconsistent. The communication between the two parties can be carried out smoothly.

Further, when the server and the client are of the same version, that is, the data model of the server and the client is the same, and in the case of communication based on the friend connection between the server and the client, when the server and the client communicate Strict matching will also be carried out based on the model, which is the same as the communication method when the friend connection is not established, so the establishment of the friend connection will not affect the normal communication of each other when the server and client versions are the same.

It can be seen that, in the solution of this embodiment, the client 700 receives the first Hello packet sent by the server via the SSH connection between the client 700 and the server, and the first Hello packet carries the first Hello packet. friend friendly-element identifier, the first friend friendly-element identifier is used to indicate that the server has the first friend capability, and the first friend capability is used to indicate that the server has The unrecognized fields in the NETCONF request message of the client client 700 are ignored; the client client 700 sends a second Hello message to the server via the SSH connection, and the second Hello message carries the second Hello message. friend friendly-element identifier, the second friend friendly-element identifier is used to indicate that the client client 700 has a second friend capability, and the second friend capability is used to indicate that the client client 700 ignores the unrecognized fields in the received NETCONF response message from the server; between the server and the client client 700, according to the first friend friendly-element identifier and the second friend friendly-element Identifies the establishment of a friend relationship. The friendly element relationship between the server and the client is established by carrying the friendly-element identifier in the Hello message between the server and the client, so that the server and the client can communicate based on the principle of non-strict matching. Therefore, communication can be performed smoothly even when the versions of the server and the client are inconsistent, and the network management efficiency is improved.

In this embodiment, the client 700 is presented in the form of a unit. A "unit" herein may refer to an application-specific integrated circuit (ASIC), a processor and memory executing one or more software or firmware programs, an integrated logic circuit, and/or other devices that may provide the above-described functions .

It can be understood that the functions of each functional unit of the client 700 in this embodiment can be specifically implemented according to the methods in the above method embodiments, and the specific implementation process can refer to the relevant descriptions of the above method embodiments, which will not be repeated here.

Referring to FIG. 8, FIG. 8 is a schematic structural diagram of a second embodiment of a client according to an embodiment of the present invention, which is used to implement the network management method disclosed in the embodiment of the present invention. The client shown in FIG. 8 is obtained by optimizing the client shown in FIG. 7 . In addition to the elements of the client shown in Figure 7, the client shown in Figure 8 has the following extensions:

The receiving unit 810 is further configured for the client to receive a NETCONF response message returned by the server, where the NETCONF response message includes acquisition result data obtained by the server according to the get or get-config request, wherein the The data model of the obtained result data is the server data model;

The client 800 further includes:

The processing unit 840 is configured for the client to determine, based on the client data model, identifiable data nodes and unidentifiable data nodes in the acquisition result data, and the client saves the data in the acquisition result data. The numerical value of the data node that can be identified, and the numerical value of the data node that cannot be identified in the acquisition result data is ignored.

Optionally, in some possible implementations of the present invention, the client 800 further includes:

A judgment unit 850, configured to judge whether the client data model is consistent with the server data model if the client detects that the client data model or the server data model has changed;

The processing unit 840 is further configured to disable the second friend capability of the client if the data model of the client is consistent with the data model of the server, so that the client does not have the ability to respond to the received data. The ability to ignore unrecognized fields in the NETCONF response message from the server.

Optionally, in some possible implementations of the present invention, the sending unit 820 is further configured to:

If the client data model is consistent with the server data model, the client sends an instruction message to the server via the SSH connection to instruct the server to disable the first friend capability, so that the The server does not have the ability to ignore the unrecognized fields in the received NETCONF request message from the client.

Specifically, by resending a Hello packet carrying the friendly-element-off identifier between the client and the server, it is possible to disable and instruct the opposite end to disable the friend capability.

It should be noted that in order to make the communication between the client and the server more secure and strict, the friend connection of both parties can be closed when the versions of the client and the server are the same, and when the client version or the server version is upgraded, the client data will be The model or server data model changes, so when the client data model or the server data model changes, the client or server can detect whether the client data model is consistent with the server data model, and check whether the client data model and the server data model are consistent. When the models are consistent, the friend capabilities of both parties are turned off, so that the client does not have the ability to ignore the unrecognized fields in the NETCONF response message received from the server, and the server does not have the ability to The capability of ignoring unrecognized fields in the client's NETCONF request message.

It can be understood that when the client and the server establish a friend connection, the friend capabilities of both parties are closed after the data models of the client and the server are upgraded to the same level, so that the communication between the client and the server is based on strict model matching again. Ensure communication security and make network management more flexible.

It can be seen that in the solution of this embodiment, after the server and the client establish a friend connection, the server and the client can perform data communication that is not strictly matched based on the friend connection, so that the client and server data When the models are inconsistent, the communication can be carried out smoothly and the network management efficiency can be improved.

In this embodiment, the client 800 is presented in the form of a unit. A "unit" herein may refer to an application-specific integrated circuit (ASIC), a processor and memory executing one or more software or firmware programs, an integrated logic circuit, and/or other devices that may provide the above-described functions .

It can be understood that the functions of the functional units of the client 800 in this embodiment may be specifically implemented according to the methods in the foregoing method embodiments, and the specific implementation process may refer to the relevant descriptions of the foregoing method embodiments, which will not be repeated here.

Referring to FIG. 9, FIG. 9 is a schematic structural diagram of a third embodiment of a client according to an embodiment of the present invention, which is used to implement the network management method disclosed in the embodiment of the present invention. The client 900 may include: at least one bus 901 , at least one processor 902 connected to the bus 901 , and at least one memory 903 connected to the bus 901 .

The processor 902 calls the code stored in the memory through the bus 901 for the client to receive the first Hello message sent by the server via the SSH connection between the client and the server, and the first Hello message The document carries the first friend friendly-element identifier, which is used to indicate that the server has the first friend capability, and the first friend capability is used to indicate that the server has a The unrecognized fields in the NETCONF request message received from the client are ignored; the client sends a second Hello message to the server via the SSH connection, and the second Hello message carries the second friend Element friendly-element identifier, the second friend friendly-element identifier is used to indicate that the client has a second friend capability, and the second friend capability is used to indicate that the client The unrecognized fields in the NETCONF response message of the server are ignored; the client determines the relationship between the client and the Friendship between servers.

Optionally, in some possible implementations of the present invention, the processor 902 is executing the process of determining the relationship between the client and the user according to the first friend friendly-element identifier and the second friend friendly-element identifier. After the friend relationship between the servers is established, the processor 902 is further configured to:

The client receives the NETCONF response message returned by the server, and the NETCONF response message includes the acquisition result data obtained by the server according to the get or get-config request, wherein the data model of the acquisition result data is the Describe the server data model;

The client determines identifiable data nodes and unidentifiable data nodes in the acquisition result data based on the client data model, and the client stores the identifiable data nodes in the acquisition result data. The value of the data node, and the value of the data node that cannot be identified in the acquisition result data is ignored.

Optionally, in some possible implementations of the present invention, the processor 902 is further configured to:

If the client detects that the client data model or the server data model has changed, then determine whether the client data model is consistent with the server data model;

If the client data model is consistent with the server data model, the client disables the second friend capability, so that the client does not have the NETCONF response message received from the server The ability to ignore unrecognized fields in .

Optionally, in some possible implementations of the present invention, the processor 902 is further configured to:

If the client data model is consistent with the server data model, the client sends an instruction message to the server via the SSH connection to instruct the server to disable the first friend capability, so that the The server does not have the ability to ignore the unrecognized fields in the received NETCONF request message from the client.

It can be seen that, in the solution of this embodiment, the client 900 receives the first Hello packet sent by the server through the SSH connection between the client 900 and the server, and the first Hello packet carries the first Hello packet. friend friendly-element identifier, the first friend friendly-element identifier is used to indicate that the server has the first friend capability, and the first friend capability is used to indicate that the server has The unrecognized fields in the NETCONF request message of the client 900 are ignored; the client 900 sends a second Hello message to the server via the SSH connection, and the second Hello message carries the second friend friendly- element identifier, the second friend friendly-element identifier is used to indicate that the client 900 has a second friend capability, and the second friend capability is used to indicate that the client 900 responds to the received data from the Unrecognized fields in the server's NETCONF response message are ignored; a friend relationship is established between the server and the client 900 according to the first friend friendly-element identifier and the second friend friendly-element identifier. The friendly element relationship between the server and the client is established by carrying the friendly-element identifier in the Hello message between the server and the client, so that the server and the client can communicate based on the principle of non-strict matching. Therefore, communication can be performed smoothly even when the versions of the server and the client are inconsistent, and the network management efficiency is improved.

An embodiment of the present invention further provides a network management system, including a server and a client, and reference may be made to the schematic structural diagram of the network management system shown in FIG. 1-a.

The server 110 is configured to send a first Hello packet to the client via the SSH connection between the client and the server, where the first Hello packet carries a first friendly-element identifier, the first Hello packet The friend friendly-element identifier is used to indicate that the server has the first friend capability, and the first friend capability is used to indicate that the server does not recognize the fields in the NETCONF request message received from the client. ignore processing;

The server 110 is further configured to receive a second Hello packet from the client via the SSH connection, where the second Hello packet carries a second friend friendly-element identifier, and the second friend friendly-element identifier is used for Indicates that the client has a second friend capability, and the second friend capability is used to indicate that the client ignores unrecognized fields in the NETCONF response message received from the server;

The server 110 is further configured to determine the friend relationship between the server and the client according to the first friend friendly-element identifier and the second friend friendly-element identifier.

Optionally, in some possible implementations of the present invention, the server 110 determines the relationship between the server and the client according to the first friend friendly-element identifier and the second friend friendly-element identifier After the friend relationship between the terminals is established, the server 110 is also used for:

The server receives a NETCONF request message sent by the client, where the NETCONF request message includes an edit-config request, a data node to be configured based on the client data model, and a to-be-configured value of the data node to be configured;

The server determines whether the to-be-configured data node can be identified based on the server data model, and when the to-be-configured data node can be identified, the server uses the to-be-configured value to perform data configuration on the to-be-configured data node , when the data node to be configured cannot be identified, the server ignores the data node to be configured;

The server sends the NETCONF response message to the client, where the NETCONF response message includes an indication of whether the data configuration is successful.

Optionally, in some possible implementations of the present invention, the server 110 determines the relationship between the server and the client according to the first friend friendly-element identifier and the second friend friendly-element identifier After the friend relationship between the terminals is established, the server 110 is also used for:

The server receives a NETCONF request message sent by the client, where the NETCONF request message includes a get or get-config request and a data filtering condition based on the client data model, where the data filtering condition includes selecting a data node;

The server determines whether the selected data node can be identified based on the server data model, and when the selected data node can be identified, the server obtains the selected data node corresponding to the selected data node from preset server data value to obtain the acquisition result data, when the selection data node cannot be identified, the server ignores the selection data node;

The server sends the NETCONF response message to the client, where the NETCONF response message includes the acquisition result data.

Optionally, in some possible implementations of the present invention, the server 110 determines the relationship between the server and the client according to the first friend friendly-element identifier and the second friend friendly-element identifier After the friend relationship between the terminals is established, the server 110 is also used for:

The server receives the NETCONF request message sent by the client, where the NETCONF request message includes a copy-config request, a data source identifier corresponding to the copy-config request, and a data source identifier corresponding to the copy-config request. The target data set identifier and the data node to be copied based on the data source data model, the first friend capability is also used to indicate that the server ignores the unrecognized fields in the data source indicated by the data source identifier;

The server determines whether the data node to be copied can be identified based on the server data model, and when the data node to be copied can be identified, the server copies the value of the data node to be copied in the data source to the In the target data set indicated by the target data set identifier, when the data node to be copied cannot be identified, the server ignores the value of the data node to be copied in the data source;

The server sends a NETCONF response message to the client, where the NETCONF response message includes an indication of whether data copying is successful.

Optionally, in some possible implementations of the present invention, the server 110 is further configured to:

If the server detects that the client data model or the server data model has changed, it determines whether the client data model is consistent with the server data model;

If the client data model is consistent with the server data model, disable the first friend capability, so that the server does not have fields that cannot be recognized in the NETCONF request message received from the client The ability to do ignore processing.

Optionally, in some possible implementations of the present invention, the server 110 is further configured to:

If the client data model is consistent with the server data model, instructing the client to disable the second friend capability, so that the client does not have the ability to respond to the NETCONF response received from the server. The ability to ignore fields that are not recognized in the text.

The client 120 is configured to receive the first Hello packet sent by the server via the SSH connection between the client and the server, where the first Hello packet carries a first friendly-element identifier, and the first Hello packet carries a first friendly-element identifier. A friend friendly-element identifier is used to indicate that the server has a first friend capability, and the first friend capability is used to indicate that the server cannot recognize the NETCONF request message received from the client. fields are ignored;

The client 120 is further configured to send a second Hello packet to the server via the SSH connection, where the second Hello packet carries a second friend friendly-element identifier, and the second friend friendly-element identifier is used for Indicates that the client has a second friend capability, and the second friend capability is used to indicate that the client ignores unrecognized fields in the NETCONF response message received from the server;

The client 120 is further configured to determine the friend relationship between the client and the server according to the first friend friendly-element identifier and the second friend friendly-element identifier.

Optionally, in some possible implementations of the present invention, the client 110 determines the relationship between the client and the user according to the first friend friendly-element identifier and the second friend friendly-element identifier. After the friend relationship between the servers is established, the client 120 is also used to:

The client receives the NETCONF response message returned by the server, and the NETCONF response message includes the acquisition result data obtained by the server according to the get or get-config request, wherein the data model of the acquisition result data is the Describe the server data model;

The client determines identifiable data nodes and unidentifiable data nodes in the acquisition result data based on the client data model, and the client stores the identifiable data nodes in the acquisition result data. The value of the data node, and the value of the data node that cannot be identified in the acquisition result data is ignored.

Optionally, in some possible implementations of the present invention, the client 120 is further configured to:

If the client detects that the client data model or the server data model has changed, then determine whether the client data model is consistent with the server data model;

If the client data model is consistent with the server data model, the client disables the second friend capability, so that the client does not have the NETCONF response message received from the server The ability to ignore unrecognized fields in .

Optionally, in some possible implementations of the present invention, the client 120 is further configured to:

If the client data model is consistent with the server data model, the server is instructed to disable the first friend capability, so that the server does not have the ability to register in the NETCONF request message received from the client The ability to ignore unrecognized fields.

It can be seen that in the solution of this embodiment, the server sends a first Hello packet to the client through the SSH connection between the client and the server, and the first Hello packet carries the first friend friendly-element identifier, The first friend friendly-element identifier is used to indicate that the server has the first friend capability, and the first friend capability is used to indicate that the server is in the received NETCONF request message from the client. Unrecognized fields are ignored; the client also sends a second Hello packet to the server at the same time, and the second Hello packet carries the second friend friendly-element identifier, and the second friend friendly-element identifier is used to indicate that the client has a second friend capability, and the second friend capability is used to indicate that the client ignores the unrecognized field in the NETCONF response message received from the server; Therefore, after the server receives the second Hello packet sent by the client, and the client receives the first Hello packet sent by the server, the relationship between the server and the client is based on the first friend friendly-element identifier and the second Hello packet. The friendly-element logo establishes a friendly-element relationship. The friendly element relationship between the server and the client is established by carrying the friendly-element identifier in the Hello message between the server and the client, so that the server and the client can communicate based on the principle of non-strict matching. Therefore, communication can be performed smoothly even when the versions of the server and the client are inconsistent, and the network management efficiency is improved.

Embodiments of the present invention further provide a computer storage medium, wherein the computer storage medium may store a program, and when the program is executed, the program includes part or all of the steps of any network management method described in the above method embodiments.

It should be noted that, for the sake of simple description, the foregoing method embodiments are all expressed as a series of action combinations, but those skilled in the art should know that the present invention is not limited by the described action sequence. As in accordance with the present invention, certain steps may be performed in other orders or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and units involved are not necessarily required by the present invention.

In the above-mentioned embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference may be made to the relevant descriptions of other embodiments.

In the several embodiments provided in this application, it should be understood that the disclosed apparatus may be implemented in other manners. For example, the apparatus embodiments described above are only illustrative, for example, the division of the units is only a logical function division, and there may be other division methods in actual implementation, for example, multiple units or components may be combined or Integration into another system, or some features can be ignored, or not implemented. On the other hand, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, indirect coupling or communication connection of devices or units, and may be in electrical or other forms.

The units described as separate components may or may not be physically separated, and components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution in this embodiment.

In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit. The above-mentioned integrated units may be implemented in the form of hardware, or may be implemented in the form of software functional units.

The integrated unit, if implemented in the form of a software functional unit and sold or used as an independent product, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium , including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program codes .

As mentioned above, the above embodiments are only used to illustrate the technical solutions of the present invention, but not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand: The technical solutions described in the embodiments are modified, or some technical features thereof are equivalently replaced; and these modifications or replacements do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present invention.

Claims (16)

1. A network management method, characterized in that the method comprises: The server receives the network configuration protocol NETCONF request message sent by the client; The server ignores the unidentifiable content in the NETCONF request message sent by the client; The server sends a NETCONF response message to the client, where the NETCONF response message includes a processing result of processing according to the NETCONF request message. 2. The method according to claim 1, wherein, before the server ignores the unrecognized content in the NETCONF request message sent by the client, the method comprises: The server sends a first Hello packet to the client, where the first Hello packet is used to indicate that the server ignores the unrecognized content in the NETCONF request packet. 3. The method according to claim 1 or 2, wherein the NETCONF request message includes an edit-config request and a data node to be configured based on a client data model, and the server sends to the client The unrecognized content in the NETCONF request message is ignored, including: The server ignores the data node to be configured according to the fact that the data node to be configured cannot be identified. 4. The method according to claim 1 or 2, wherein the NETCONF request message includes a get or get-config request, and the NETCONF request message also includes a selection data node based on the client data model , the server ignores the unrecognized content in the NETCONF request message sent by the client, including: When one or more of the selected data nodes cannot be identified, the server ignores one or more of the selected data nodes. 5. The method according to claim 1 or 2, wherein the NETCONF request message includes a copy-config request, a data source identifier and a data node to be copied based on a data source data model, and the server has a The unrecognized content in the NETCONF request message sent by the client is ignored, including: When one or more of the data nodes to be copied cannot be identified, the server ignores the value of one or more of the data nodes to be copied in the data source. 6. The method according to any one of claims 1-5, characterized in that, before the server ignores the unrecognized content in the NETCONF request message sent by the client, the method include: receiving, by the server, the second Hello message sent by the client; The server determines, according to the second Hello message, that the client ignores the unrecognized content in the NETCONF response message received from the server. 7. The method according to any one of claims 1 to 6, wherein after the server sends a NETCONF response message to the client, the method further comprises: According to the data model of the client being consistent with the data model of the server, the server disables the ability to cause the server to ignore the unrecognized content in the NETCONF request message sent by the client. 8. A network management method, wherein the method comprises: The client sends a NETCONF request message to the server; The client receives the NETCONF response message sent by the server, and the NETCONF response message includes a processing result processed according to the NETCONF request message; The client ignores the unrecognized content in the NETCONF response message sent by the server. 9. The method according to claim 8, characterized in that, before the client ignores the unrecognized content in the NETCONF response message sent by the server, the method comprises: The client sends a second Hello packet to the server, where the second Hello packet is used to indicate that the client ignores the unrecognized content in the NETCONF response packet. 10. The method according to claim 8 or 9, wherein the NETCONF response message includes acquisition result data obtained by the server according to a get or get-config request, and the method further comprises: The client determines, based on the client data model, the data nodes that cannot be identified in the acquisition result data, and ignores the values of the unidentifiable data nodes in the acquisition result data. 11. The method of claim 10, wherein the method comprises: The client determines the identifiable data node based on the client data model; The client saves the value of the identifiable data node in the acquisition result data. 12. The method according to any one of claims 8-11, wherein, before the client ignores the unrecognized content in the NETCONF response message sent by the server, the method include: The client receives the first Hello packet sent by the server, where the first Hello packet is used to indicate that the server ignores the unrecognized content in the NETCONF request packet. 13. The method according to any one of claims 8-12, wherein after the client performs ignoring processing on unrecognized content in the NETCONF response message sent by the server, the method include: The client receives the instruction information sent by the server, where the instruction information is used to instruct the client to close and cause the client to ignore the unrecognized content in the NETCONF response message sent by the server. Ability. 14. A server comprising a processor and a memory, the processor for invoking a computer program stored in the memory to cause the server to perform the method of claims 1-7. 15. A client, the client comprising a processor and a memory, the processor for invoking a computer program stored in the memory to cause the client to perform the method of claims 8-13. 16. A network management system, wherein the system comprises: server and client, The server is the server of claim 14 , and the client is the client of claim 15 .

Images