System and method for monitoring status of network components in a network configuration

A system and method for monitoring configuration status of a plurality of network components of a network. The method comprises generating, based on a network object model, a first configuration file indicative of expected configuration status of the plurality of network components, the network model comprising Node objects, Interface objects, evpnEdge objects and Layer objects. The method further comprises receiving a second configuration file indicative of current configuration status of the plurality of network components, the first and second configuration files comprising tagged sections and sub-sections, and comparing the first and second configuration files comprising comparing a first sub-section of the first configuration file with a corresponding second sub-section of the second configuration file based on tags of the first and second sub-sections, the first and second sub-sections comprising configuration commands relative to one of the plurality of network components.

The present application claims priority to European Patent Convention Application No. 21306302.7, entitled “System and Method for Monitoring Status of Network Components in a Network Configuration,” filed on Sep. 21, 2021, the entirety of which is incorporated by reference herein.

FIELD

The present technology relates to network monitoring and more particularly monitoring status of network components in a network configuration.

BACKGROUND

Network monitoring is a critical information technology (IT) function often used by Enterprises and Service Providers, such as Infrastructure Providers that provide network devices and hardware/software capacities to their customers. Network monitoring involves watching the activities occurring on an internal network for problems related to performance, potential routing errors, communication between different network components, etc. Network monitoring is made possible due to the information generated and provided by various network components. Such information may be embedded in transmitted data referred to as “network metadata”, i.e., a class of information describing activity on the network which is supplemental to the primary information traffic transmitted over the network.

More specifically, subsequently to instantiating network components according to an expected network configuration, executing network monitoring procedures may be useful to assess whether a current network configuration of a network corresponds to the expected network configuration. As such, errors of instantiation of network components may be detected and located, as well as unwanted or unregistered modifications of status of network components.

Many developed technologies attempt to address this problem by using computer-implemented monitoring platforms. Yet, these platforms do not enable the Infrastructure Provider nor its customer to obtain a location of the failing network components and/or are not suitable for identifying configuration errors in configuration files associated with the network components.

Therefore, even though the developments identified above may provide benefits, improvements are still desirable.

SUMMARY

Implementations of the present technology have been developed at least in part based on developers' appreciation of shortcomings associated with the prior art. Developers of the present technology have devised methods and systems for monitoring configuration status of a plurality of network components of a network.

In a first broad aspect of the present technology, there is provided a method for monitoring a configuration status of a plurality of network components of a network, the method comprising generating, using a network object model associating one or more instantiation objects to each one of the plurality of network components, a first configuration file indicative of an expected configuration status of the plurality of network components. The instantiation objects include Node objects representing points of interconnection in the network; Interface objects, being hierarchically inferior to the Node objects, and representing connections to points of interconnection; evpnEdge objects representing transports to/from of points of interconnection in the network; and Layer objects, being hierarchically inferior to the evpnEdge objects, and representing characteristics of the transported protocol to/from point of interconnection. The first configuration file includes one or more tagged sections, each tagged section comprising one or more tagged sub-section, the tagged sections and tagged sub-sections comprising configuration commands being respective instantiations of one of more instantiation objects and indicative of the expected configuration status of each of the plurality of network components. The method further includes receiving a second configuration file indicative of a current configuration status of the plurality of network components, the second configuration file comprising one or more tagged sections, each tagged section comprising one or more tagged sub-sections, the tagged sections and tagged sub-sections comprising configuration commands indicative of the current configuration status of each of the plurality of network components; and comparing the first and second configuration files comprising comparing a first sub-section of the first configuration file with a corresponding second sub-section of the second configuration file based on tags of the first and second sub-sections, the first and second sub-sections comprising configuration commands relative to one of the plurality of network components.

In some embodiments of the present technology, the method further includes, prior to receiving the second configuration file, transmitting configuration status queries to the plurality of network components; and generating the second configuration file based on responses to the configuration status queries from the plurality of network components.

In some embodiments of the present technology, the method further includes a setup phase prior to generating the first configuration file, the setup phase comprising receiving a user request for applying a network configuration to the network; using the network object model to describe each network component through one or more corresponding instantiation objects of the network object model; generating one or more configuration instantiating commands based on the user request, each configuration instantiating command being directed to a corresponding network component; transmitting the one or more configuration instantiating commands to a corresponding one or more network component of the plurality of network components; and executing the one or more configuration instantiating commands to apply the network configuration to the network.

In some embodiments of the present technology, the method further includes identifying, based on a result of the comparison between the first and second configuration files, incoherent configuration commands in sub-sections of the first and second configuration files, a given configuration command of a sub-section of the first configuration file being identified as incoherent if a corresponding sub-section of the second configuration file lacks the given configuration command, and a given configuration command of a sub-section of the second configuration file being identified as incoherent if a corresponding sub-section of the first configuration file lacks the given configuration command.

In some embodiments of the present technology, the method further includes causing, by the monitoring entity, an execution of the incoherent configuration commands of the first configuration file by their corresponding network components.

In some embodiments of the present technology, the method further includes causing, by the monitoring entity, an execution of corrective configuration commands discarding an incoherent configuration command of a sub-section of the second configuration file from the configuration status of the corresponding network component.

In some embodiments of the present technology, generating the first configuration file and generating the second configuration file are made in response to receiving a monitoring request by an operator of the network.

In some embodiments of the present technology, the method further includes periodically updating the second configuration file and comparing the first and second configuration file.

In some embodiments of the present technology, the network is a multi-tenant network where at least one network component of the plurality of network components supports a first service and a second service, the first and second configuration files being respectively indicative of the expected and current configuration status of the at least one network component for a given one of the first and second services.

In some embodiments of the present technology, a data format of the first and second configuration files is JSON.

In some embodiments of the present technology, a given Layer object is adapted for a Layer 2 protocol to be the transported protocol.

In some embodiments of the present technology, at least one of the one or more tagged sub-sections of the first configuration file includes one or more tagged sub-sub-sections.

In some embodiments of the present technology, at least one of the one or more tagged sub-sections of the second configuration file includes one or more tagged sub-sub-sections.

In some embodiments of the present technology, comparing the first and second configuration files includes executing a textual comparison between the first and second configuration files.

In some embodiments of the present technology, the method further includes executing the incoherent configuration commands of the first configuration file onto their corresponding network components.

In some embodiments of the present technology, the method further includes discarding an incoherent configuration command from a sub-section of the second configuration file and executing the configuration commands of the sub-section on the corresponding network component.

In some embodiments of the present technology, generating the first configuration file and generating the second configuration file are made in response to receiving a monitoring request by an operator of the network.

In some embodiments of the present technology, a given Layer object is adapted for a Layer 2 protocol to be the transported protocol.

In some embodiments of the present technology, a given Layer object is adapted for a Layer 3 protocol to be the transported protocol.

In some embodiments of the present technology, the transported protocol is an Ethernet-based protocol.

In some embodiments of the present technology, the transported protocol is IPv4.

In some embodiments of the present technology, the transported protocol is IPv6.

In a second broad aspect of the present technology, there is provided a system for monitoring a network configuration of a network comprising a plurality of network components, the system comprising a processor and a memory configured to store instructions which, upon being executed by the processor, cause the processor to generate, using a network object model associating one or more instantiation objects to each one of the plurality of network components, a first configuration file indicative of an expected configuration status of the plurality of network components, the instantiation objects comprising Node objects representing points of interconnection in the network, Interface objects, being hierarchically inferior to the Node objects, and representing connections to points of interconnection, evpnEdge objects representing transports to/from of points of interconnection in the network; and Layer objects, being hierarchically inferior to the evpnEdge objects, and representing characteristics of the transported protocol to/from point of interconnection, the first configuration file comprising one or more tagged sections, each tagged section comprising one or more tagged sub-sections, the tagged sections and tagged sub-sections comprising configuration commands being respective instantiations of one of more instantiation objects and indicative of the expected configuration status of each of the plurality of network components. The processor further receives a second configuration file indicative of a current configuration status of the plurality of network components, the second configuration file comprising one or more tagged sections, each tagged section comprising one or more tagged sub-sections, the tagged sections and tagged sub-sections comprising configuration commands indicative of the current configuration status of each of the plurality of network component, compares the first and second configuration files comprising comparing a first sub-section of the first configuration file with a corresponding second sub-section of the second configuration file based on tags of the first and second sub-sections, the first and second sub-sections comprising configuration commands relative to one of the plurality of network components, identifies, based on a result of the comparison between the first and second configuration files, incoherent configuration commands in sub-sections of the first and second configuration files, a given configuration command of a sub-section of the first configuration file being identified as incoherent if a corresponding sub-section of the second configuration file lacks the given configuration command, and a given configuration command of a sub-section of the second configuration file being identified as incoherent if a corresponding sub-section of the first configuration file lacks the given configuration command, and causes, by employing a monitoring entity, an execution of the incoherent configuration commands of the first configuration file by their corresponding network components.

In some embodiments of the system, the processor is further configured to, prior to receiving the second configuration file, transmit configuration status queries to the plurality of network components; and generate the second configuration file based on responses to the configuration status queries from the plurality of network components.

In some embodiments of the system, the processor is further configured to execute a setup phase prior to generating the first configuration file, the setup phase comprising receiving a user request for applying a network configuration to the network, using the network object model to describe each network component through one or more corresponding instantiation objects of the network object model, generating one or more configuration instantiating commands based on the user request, each configuration instantiating command being directed to a corresponding network component, transmitting the one or more configuration instantiating commands to a corresponding one or more network component of the plurality of network components; and causing execution the one or more configuration instantiating commands to apply the network configuration to the network.

In some embodiments of the system, the processor is further configured to cause, by employing the monitoring entity, an execution of corrective configuration commands discarding an incoherent configuration command of a sub-section of the second configuration file from the configuration status of the corresponding network component.

In some embodiments of the system, generating, by the processor, the first configuration file and generating the second configuration file are made in response to receiving a monitoring request by an operator of the network.

In some embodiments of the system, the processor is further configured to cause an automatic and periodical update of the second configuration file and compare the first and second configuration file upon receiving an updated second configuration file.

In some embodiments of the system, the network is a multi-tenant network where at least one network component of the plurality of network components supports a first service and a second service, the first and second configuration files being respectively indicative of the expected and current configuration status of the at least one network component for a given one of the first and second services.

In some embodiments of the system, a data format of the first and second configuration files is JSON.

In some embodiments of the system, at least one of the one or more tagged sub-sections of one or more of the first and second configuration files comprises one or more tagged sub-sub-sections.

In the context of the present specification, “user device” is any computer hardware that is capable of running software appropriate to the relevant task at hand. Thus, some (non-limiting) examples of user devices include personal computers (desktops, laptops, netbooks, etc.), smartphones, and tablets, as well as network equipment such as routers, switches, and gateways. It should be noted that a device acting as a user device in the present context is not precluded from acting as a server to other user devices. The use of the expression “a user device” does not preclude multiple user devices being used in receiving/sending, carrying out or causing to be carried out any task or request, or the consequences of any task or request, or steps of any method described herein.

In the context of the present specification, the expression “component” is meant to include software (appropriate to a particular hardware context) that is both necessary and sufficient to achieve the specific function(s) being referenced.

In the context of the present specification, the expression “computer usable information storage medium” is intended to include media of any nature and kind whatsoever, including RAM, ROM, disks (CD-ROMs, DVDs, floppy disks, hard drivers, etc.), USB keys, solid state-drives, tape drives, etc.

In the context of the present specification, a “network”, or “computer network”, is intended to include a configuration of devices and software that are in mutual communication and can exchange information, including data and instructions. Such communication is accomplished by the presence of a direct physical connection between devices (i.e., wired communication) and/or indirectly by electromagnetic or other non-physically connected communication (i.e., wireless communication), using whatever protocols are extant between the two devices. A network can include arbitrary numbers and types of devices, systems, and applications, which, in some exemplary, illustrative, non-limiting embodiments, function in accordance with established policies. In some networks, the network components, systems and applications included in the network can change over time, as can their configurations, locations and other parameters as devices are connected or disconnected from the network whether purposely or inadvertently.

In the context of the present specification, unless expressly provided otherwise, an “indication” of an information element may be the information element itself or a pointer, reference, link, or other indirect mechanism enabling the recipient of the indication to locate a network, memory, database, or other computer-readable medium location from which the information element may be retrieved. For example, an indication of a document could include the document itself (i.e. its contents), or it could be a unique document descriptor identifying a data object with respect to a particular object storage device, or some other means of directing the recipient of the indication to a network location, memory address, database table, or other location where the data object may be accessed. As one skilled in the art would recognize, the degree of precision required in such an indication depends on the extent of any prior understanding about the interpretation to be given to information being exchanged as between the sender and the recipient of the indication. For example, if it is understood prior to a communication between a sender and a recipient that an indication of an information element will take the form of a database key for an entry in a particular table of a predetermined database containing the information element, then the sending of the database key is all that is required to effectively convey the information element to the recipient, even though the information element itself was not transmitted as between the sender and the recipient of the indication.

It should also be noted that, unless otherwise explicitly specified herein, the drawings may not be drawn to scale.

DETAILED DESCRIPTION

Software modules, or simply modules which are implied to be software, may be represented herein as any combination of flowchart elements or other elements indicating performance of process steps and/or textual description. Such modules may be executed by hardware that is expressly or implicitly shown. Moreover, it should be understood that module may include for example, but without being limitative, computer program logic, computer program instructions, software, stack, firmware, hardware circuitry or a combination thereof which provides the required capabilities.

In one aspect, the present technology provides systems and methods for monitoring a network and identifying differences between a current network configuration of the network and an expected network configuration. As such, the present technology enables identification of unwanted and/or unregistered modifications in the configuration status of the network components of the network. In a non-limiting embodiment of the present technology, the network is modelled as a network object model wherein each network component is modelled through instantiation objects having different parameters indicative of a configuration status of the network component. A first and a second configuration files are generated and indicative of an expected and a current network configuration of the network respectively. The first configuration file may be generated based on the network object model. The network components may be caused, upon request by a monitoring entity, to generate configuration description file to be transmitted to the monitoring entity to further generate the second configuration file. A comparison procedure is further executed between the first and second configuration files to identify the differences between the current network configuration of the network and the expected network configuration.

Referring toFIG.1, there is shown a schematic diagram of a system100, the system100being suitable for implementing non-limiting embodiments of the present technology. Broadly speaking and as an example, the system100may be employed for providing network configuration monitoring functionalities. To that end, the system100includes inter alia a monitoring entity110, a communication network120, and a plurality of network components130such as routers or switches. As such, any system variation configured to enable network configuration monitoring can be adapted to execute embodiments of the present technology, once teachings presented herein are appreciated. In the context of the present disclosure, the network components130are interconnected via the communication network120and form a network having a given current network configuration, each network component130having a corresponding current status, or “configuration”. The current network configuration of the network is representative of a physical architecture and a virtual architecture of the network.

For example, in a non-limiting embodiment, the network components130may physically belong to an Infrastructure Provider115and be used to provide one or more services for one or more corresponding clients of the Infrastructure Provider115. Clients of the Infrastructure Provider115may use resources inside network tenants140such as Public Cloud instances, Dedicated Servers or Private Cloud environments or the like. Clients may also use resources141outside of Infrastructure Provider115such as resource servers, routers, endpoints (e.g. laptops or cellphones) or the like. In this embodiment, the Infrastructure Provider115operates the monitoring entity110. More specifically, in this embodiment, the system100may be defined in a multi-tenant environment such that at least one network component130(e.g. a resource server) provides services160for a plurality of clients of the Infrastructure Provider115. Clients define individually each desired service160by interaction with an application frontend116which activates a non-limited list of tasks to an automation layer118. In use, the automation layer118instructs network components130to configure the one or more desired services160. Automation layer118may use a network model described, for instance, in the European Patent No. EP3703314A1, published on Sep. 2, 2020, the entirety of which is incorporated by reference herein.

With respect toFIG.1, the monitoring entity110is communicably connected to administrator devices150(only one of which being depicted inFIG.1for simplicity), each administrator device150being associated with a corresponding administrator of the Infrastructure Provider115. As an example, a given administrator may be a client of the Infrastructure Provider115that may use the network components130for his/her own clients. Even though the monitoring entity110and the administrator device150are depicted as being in direct communication onFIG.1, it is contemplated that they may be communicably connected via the communication network120, or any other communication network suitable to communicably connect to administrator device150to the monitoring entity, in alternative embodiments. The monitoring entity110functionalities may be provided by a controller600(seeFIG.6). As will be described in greater details below, a given administrator may transmit, in use and via its corresponding administrator device150, a monitoring request152to the monitoring entity110to receive, in return, information117about a network configuration of the specific network components130providing services for that administrator. Some functionality of components of the system100will now be described in greater detail.

Communication Network

In one non-limiting example, the communication network120may be implemented as the Internet. In other non-limiting examples, the communication network120or portion thereof may be implemented differently, such as any wide-area communication network, local-area communication network, a private communication network and the like. In fact, how the communication network120is implemented is not limiting and will depend on inter alia how other components of the system100are implemented.

The purpose of the communication network120is to communicatively couple at least some of the components of the system100such as the plurality of network components130and the monitoring entity110. For example, this means that the plurality of network components130is accessible via the communication network120by the monitoring entity110.

The communication network120may be used in order to transmit data packets amongst the plurality of network components130and the monitoring entity110. For example, the communication network120may be used to transmit, from the monitoring entity110configuration status queries for receiving information about configuration of a given one or more of the network components130and/or configuration instructions for instantiating the given one or more of the network components130. As another example, the communication network120may be used to transmit, from a given one or more network components130to the monitoring entity110, information about a current configuration of the given one or more of the network components130.

Network Components

As mentioned above, the plurality of network components130may be routers or switches. A given one of the pluralities of network components130may be implemented as Arista running EOS, for example. Each network component130includes a memory or is communicatively connected thereto, said memory storing data including information about the current configuration status of the corresponding network component130. The plurality of network components130may be accessed for the purpose of configuration tasks, including but not limited to, by methods such as SSH, HTTP or HTTPS. Any of the methods can imply the use of direct commands or encapsulating commands within headers or equivalent through the use of an Application Programming Interface (API). The plurality of network components130may imply the use of various network protocols, without limitation, such VxLAN or MPLS. The use of such protocols enables configuration of the network services160individually for each client associated to their network tenants140. Such network services160can provide network connectivity based on OSI Layer 2 or OSI Layer 3.

Each network service160is individually configured. In other words, there are no dependencies between two distinct network services160. A given network service160may be created, updated or deleted at any time without impact on others network services160. The configuration that forms a network service is based on client's instructions to the Infrastructure Provider115, said instructions may include, without being limited to, information about: IP address, vlan tag, BGP AS Number or IP Route. Based on adjustment and customization of each network services based on the client's instructions, the network configuration may not be suitably compared to a single configuration template, given that variability of the instructions (i.e. configuration commands) is up to the network complexity of the network tenants140associated with the client.

Monitoring Entity

In this embodiment, the monitoring entity110is a cluster of servers (only one of which is represented inFIG.1for simplicity) of the Infrastructure Provider. As such, functionalities of the monitoring entity110are distributed on multiple servers. In an example of an embodiment of the present technology, a given one of the servers of the cluster of servers may be implemented as a Dell™ PowerEdge™ server running the Microsoft™ Windows Server™ operating system. The monitoring entity110may be implemented in any other suitable hardware and/or software and/or firmware or a combination thereof.

Generally speaking, the monitoring entity110is under control and/or management of the Infrastructure Provider that may receive queries from the administrator devices150. For example, the monitoring entity110may receive a monitoring request152(seeFIG.1) from a given administrator device150indicative of a query submitted by a corresponding administrator. The monitoring entity110may perform a network configuration search responsive to the submitted query for generating information about a current network configuration of network components of the network that are associated with the given client. In this embodiment, said information includes error identification between expected network configuration and current network configuration of the network components. The monitoring request152may also be automatically and periodically generated by the monitoring entity110itself such that potential errors between an expected network configuration and the current network configuration of the network components are automatically and periodically identified.

More specifically, in use, the administrator device150may transmit, in response to instructions from a given client of the Infrastructure Provider115, a request for instantiating a virtual architecture of a group of network components according to an expected network configuration. For example, the expected network configuration may include expected status of given resource servers130, expected status of communication links between given resource servers130or the like (e.g. configurations for different layers of the Open Systems Interconnection model (OSI model) for network components).

Generally speaking, instantiation objects and classes are defined for each network component130to cover all information required to deploy and describe a network configuration. More specifically, in this embodiment, each network component130is represented as a set of instantiation objects in an object model, or “network model”300(seeFIG.3), maintained by the monitoring entity110, the network model300being thus indicative of a network configuration of the network. As such, upon instantiating a given network component130, the monitoring entity110may generate one or more new instantiation objects or update information of existing instantiation objects representative of characteristics of the given network component in the network model300. It should be understood that the expected network configuration and the current network configuration may be generated and further compared based on the network model300. The network model300may be for example, the model described in the European patent No.

In a non-limiting embodiment, four instantiation object types are modelled in the network model300:a Node object representing a point of interconnection in the network (e.g. a server, a router, an endpoint or the like);an Interface object, being hierarchically inferior to the Node object, and representing a connection to a point of interconnection;an evpnEdge object representing the transport to/from of a point of interconnection in the network; anda Layer object, being hierarchically inferior to the evpnEdge object, and representing the characteristics of a transported protocol to/from a point of interconnection.

Each instantiation object of the network model300may be instantiated with a specific set of configuration commands indicative of the expected configuration status of the network component130that they model. In a non-limiting embodiment, a given Layer object may be instantiated such that a Layer 2 protocol is the transported protocol, and a given Layer object instantiated such that a Layer 3 protocol is the transported protocol. For example, a transported Layer 2 protocol may be any Ethernet-based protocol (e.g. IEEE 802.1q header), and a transported Layer 3 protocol may be the IPv4 protocol or the IPv6 protocol.

In this embodiment, the monitoring entity110is configured to communicate with the network components130accessible via the communication network120and to retrieve configuration description files therefrom for further use, as it will be described below. To do so, in a non-limiting embodiment, the monitoring entity110includes an Application Programming Interface (API) that may be indirectly executed from a given administrator device150upon transmitting the monitoring request152to the monitoring entity110. In another non-limiting embodiment, the monitoring entity110may be configured to autonomously retrieve the configuration description files at a pre-determined frequency such that errors in the network configuration of the network may be regularly monitored and autonomously detected.

With reference toFIG.2, the monitoring entity110is configured to generate a reference configuration file400based on the network model300, the reference configuration file400being thus representative of the expected configuration status of the network components130. In this embodiment, the reference configuration file400includes a plurality of sections, such as sections410and420, comprising sub-sections. In the illustrative example ofFIG.2, the section410includes two sub-sections412and414. In this embodiment, the sections and sub-sections of the reference configuration file400include configuration commands being respective instantiation commands (or simply “instantiations”) of one of more instantiation objects of the network model300and indicative of the expected configuration status of each of the plurality of network components130. More specifically, in this embodiment and upon generation of the reference configuration file400, each section and sub-section of the reference configuration file400is populated with instantiations of instantiation objects of the network model300. As an example, in the illustrative example ofFIG.2, a given Interface object308is instantiated as “physical” (other instantiations for Interface objects are contemplated such as, without limitation, “aggregate”, “loopback”, “SVI”). Also in the in the illustrative example ofFIG.2, a given Layer object306is instantiated as “Layer3”, being itself instantiated as “bgp” and “vrrp”. Such instantiations generate specific sets of instantiation commands in the reference configuration file400. As such, the section420is populated with instantiations of the given instantiation Layer object306and instantiations of the given instantiation Interface object308. In this illustrative example, given the fact that the Interface Object308is instantiated as “physical”, the section420is populated with a corresponding specific set of instantiation commands: no switchport/speed <speed/duplex>/mtu <mtu>. In the event of the Interface object308being instantiated as “aggregate”, the section420may be populated with a different set of instantiation commands.

The sections and sub-sections of the reference configuration file400may have a respective identifier (e.g. a tag) indicative of which instantiation objects and/or which one or more network components they derive from.

In this embodiment, the reference configuration file400is generated as a JSON file, but other data formats are contemplated in alternative embodiments of the present technology. In one embodiment, a given sub-section of the reference configuration file400may also include one or more sub-sub-sections and so forth. In the context of the present description, characteristics of the sections may be also valid for sub-sections, sub-sub-sections and so forth.

How the sections and sub-sections are defined and populated is not limiting and will depend on inter alia which type of instantiation objects is described in the network model300. In this embodiment, the monitoring entity110generates the reference configuration file400according to a pre-defined template. As such, the pre-defined template defines the sections and sub-sections to be generated by the monitoring entity110based on the types of instantiation objects described in the network model300. A process for populating the sections and sub-sections may be predetermined by computer-readable instructions that may be retrieved by the monitoring entity110. In the illustrative embodiment ofFIG.2, instantiations of a plurality of instantiation objects in the network model300may be used to populate a given section and/or sub-section of the reference configuration file400.

With reference toFIG.3, the monitoring entity110transmits a configuration status query114to one or more of the network component130(only one of which is depicted inFIG.2for simplicity) over the communication network120. Upon reception of the configuration status query114, the network component130is configured to generate a configuration description file134based on the data comprising information about its current configuration status. In this embodiment, said data is included in object parameters132associated with the network component130. The object parameters132may have been, for example and without limitation, generated upon an instantiation of the network component130and stored in a memory of the network component130. The configuration description file134is further transmitted from the network component130to the monitoring entity110such that a current configuration file350(seeFIG.4) is received by the monitoring entity110. As such, in this embodiment, the monitoring entity receives the current configuration file350in response to having transmitted the configuration status query114to the network components130.

As an example and without limitation, the configuration status query114may be transmitted by executing the following command on ARISTA′ command-line interface (CLI) or on ARISTA™ EOS API (eAPI) such that the current configuration file350is received by the monitoring entity110:show running|json

As best shown inFIGS.4aand4b, in this embodiment, the received current configuration file350includes a plurality of sections, such as sections360and370, and sub-sections, such as sub-sections362and364describing the current configuration of each network component130. In this embodiment, the current configuration file350is generated as a JSON file, but other data formats are contemplated in alternative embodiments of the present technology. In one embodiment, a given sub-section of the current configuration file350may also include one or more sub-sub-sections and so forth.

How the sections and sub-sections are defined and populated is not limiting and will depend on inter alia which type of configuration status query114is transmitted to the network component130and/or which type of configuration description file134. In one embodiment, it an be said that a structure (i.e. sections and sub-sections) of the reference configuration400are set according to a pre-determined template such that said structure matches a structure of the received current configuration file350. The sections and sub-sections of the current configuration file350may have a respective identifier (e.g. a tag) indicative of which one or more network components they derive from.

The monitoring entity110may further compare the current configuration file350, representative of the current network configuration, to the reference configuration file400, representative of the expected network configuration. The monitoring entity110may be configured to execute a text comparison procedure between sections and sub-sections of the current configuration file350and the reference configuration file400. More specifically, given that each section of the current configuration file350and the reference configuration file400is associated with a given network component130, the monitoring entity110may be configured to execute the text comparison procedure between a first section and a second section related to a same network component130, the first and second sections being included in the current configuration file350and the reference configuration file400respectively.

In this embodiment, comparing texts of the first and second sections may include comparing each sub-section of the first section of the current configuration file350with a corresponding sub-section of the second section of the reference configuration file400. For example, as illustrated inFIG.4a, the section360is tagged and describes a configuration status of a router Border Gateway Protocol (BGP) and includes three sub-sections362,364and366. The monitoring entity110is configured to identify, in the reference configuration file400the section410corresponding to the router BGP and further execute the text comparison procedure. Based on an identification of said sub-sections (e.g. using tags based on characteristics of the router BGP such as vxlan<x> and vrf<name>), the monitoring entity110may compare instructions included in said sub-sections. As such, in this example, instructions included in the sub-section412are compared with instructions included in the sub-section362. Similarly, instructions included in the sub-section414are compared with instructions included in the sub-section364. In this embodiment, each section and sub-section of the current configuration file350and the reference configuration file400may be associated with an identifier indicative of a network component that they describe and characteristics thereof. As such, each section and sub-section of the current configuration file350may have a unique identifier (e.g. a tag) and each section and sub-section of the reference configuration file400may have a unique identifier. One section (or sub-section) of the current configuration file350may have a same identifier that a section (or sub-section) of the reference configuration file400, such that the monitoring entity110may compare the two sections (or sub-sections).

In this embodiment, if determination is made that a section of the current configuration file350does not correspond to any sections of the reference configuration file400, said section may be ignored in the text comparison procedure. Similarly, if determination is made that sub-section of a given section of the current configuration file350, the given section corresponding to a section of the reference configuration file400, does not correspond to any sub-section of the section of the reference configuration file400, said sub-section is ignored in the text comparison procedure. For example, in the illustrative example ofFIGS.4aand4b, the sub-sections366and the sections380,390do not correspond to a sub-section of the section410and sections respectively of the reference configuration file400. As such, the sub-section366may be identified as being an additional sub-section with respect to the reference configuration file400, and the sections380,390may be identified as being additional sections with respect to the reference configuration file400.

Upon comparing two sub-sections, the monitoring entity110may identify incoherent configuration commands, namely “additional” configuration commands and “missing” configuration commands. More specifically, additional configuration commands may be defined as configuration commands that are present in a sub-section of the current configuration file350but absent from a corresponding sub-section of the reference configuration file400. Missing configuration commands may be defined as configuration commands that are present in a sub-section of the reference configuration file400but absent from a corresponding sub-section of the current configuration file350. In the illustrative example ofFIG.4a, upon comparing the sub-section414with the sub-section364, the configuration command of the sub-section414neighbor <ip> fall-over bfd is identified as a missing configuration command, and the configuration command of the sub-section364neighbor <ip> update-source <intf> is identified as an additional configuration command. In a non-limiting embodiment, the monitoring entity110may generate a list of the incoherent configuration commands, along with their respective sub-section and sections identifiers such that an operator of the monitoring entity110may be provided with locations of the additional and missing configuration commands in the current configuration file350and the reference configuration file400respectively. As such, network components130whose sections in the current configuration file350differ from corresponding sections in the reference configuration file400may be identified as failing network components.

In one embodiment, the monitoring entity110may further update the network configuration (e.g. configuration status of the network components130) based on the identified additional configuration commands and the missing configuration commands. More specifically, configuration commands may be applied by the monitoring entity110on one or more of the network components130such that the current network configuration matches the expected network configuration. In this embodiment, the monitoring entity110may, in response to identifying a missing configuration command in a given sub-section of the reference configuration file400, the given sub-section corresponding to a given network component130, cause the network component130to execute the missing configuration command.

In the same or another embodiment, the monitoring entity110may, in response to identifying an additional configuration command in a given sub-section of the current configuration file350, the given sub-section corresponding to a given network component130, cause the network component130to execute corrective configuration commands that, upon being executed, cause the configuration status of the network component130to match a configuration status described by the other configuration commands of the sub-section without the additional configuration command. As an example and without limitation, in response to identifying the configuration command neighbor <ip> update-source <intf> as an additional configuration command, the monitoring entity110may execute the following corrective configuration command: NO neighbor <ip> update-source <intf. In other words, it can be said that the additional configuration command is discarded from the sub-section, and that configuration the missing configuration command. How the corrective configuration commands are defined based on the additional configuration commands is not limiting and will depend on inter alia a type and/or a programming language of configuration command.

With reference toFIG.5, a method500for monitoring configuration status of a plurality of network components of a network, the plurality of network components forming a network configuration of the network, according to some implementations of the present technology is illustrated in the form of a flow chart. In one or more aspects, the method500or one or more operations thereof may be performed by the controller600(FIG.6). In some implementations, one of more steps of the method500could be implemented, whole or in part, by another computer-implemented device. It is also contemplated that the method500or one or more operations thereof may be embodied in computer-executable instructions that are stored in a computer-readable medium, such as a non-transitory mass storage device, loaded into memory and executed by a processor, such as the controller600. Some operations or portions of operations in the flow diagram may be possibly being executed concurrently, omitted or changed in order.

The method500includes generating, at operation505and based on the network model300, the reference configuration file400indicative of the expected configuration status of the network components130. The configuration status may include information about a physical architecture and a virtual architecture of the network for each network components130. In this embodiment, the network model and/or the reference configuration file400may be stored, for example, in a memory135(seeFIG.6) of the monitoring entity110. The reference configuration file400may be generated using the network model300associating one or more instantiation objects to each one of the plurality of network components130, the instantiation objects comprising, as described herein above, Node objects, Interface objects, evpnEdge objects and Layer objects.

The reference configuration file400includes tagged sections such as section410, each tagged section comprising one or more tagged sub-sections, such as sub-section412and414, of configuration commands being respective instantiations (e.g. sets of instantiation commands associated with instantiation of the instantiation objects) of one of more instantiation objects of the network model300and indicative of the expected configuration status of each of the plurality of network components. In a non-limiting embodiment, the configuration file400is generated in response to receiving, by the monitoring entity110, the monitoring request152.

In this embodiment, the data format of the configuration file400is the JSON format, but other data formats are contemplated in alternative embodiments of the present technology.

The method continues with, at operation510, receiving the current configuration file350indicative of current configuration status of the plurality of network components. In one embodiment, the monitoring entity110transmits the configuration status queries114to the plurality of network components130and generates the current configuration file350based on responses to the status queries from the plurality of network components130. In another embodiment, the monitoring entity receives the current configuration file350from the network component130.

The current configuration file350also includes tagged sections, such as sections360, each tagged section comprising one or more tagged sub-sections, such as sub-sections362,364and366, of configuration commands indicative of a current configuration status of the network component. As an example, the configuration commands of the current configuration file350may be configuration commands that have been previously executed by the network components.

A new current configuration file350may be periodically received at a pre-determined rate, such that the latest received current configuration file350is representative of an “up-to-date” current network configuration of the network components130. For example, the monitoring entity110may periodically transmit the configuration status query114to the network components130to, in response to the configuration status query114, periodically receive “up-to-date” current configuration file350.

The network may be a multi-tenant network where at least one network component130supports a first service and a second service. For example, the first service may be associated with a first client (or first administrator device150) and the second service may be associated with a second client (or second administrator device150). As such, functionalities of the at least one network component may be shared between the first and second services. However, the reference and current configuration files400,350are respectively indicative of the expected and current configuration status of the at least one network component for a given one of the first and second services. This may facilitate preservation of data privacy between the first and second clients.

The method500continues with, at operation515, comparing the current configuration file350and the reference configuration file400by the monitoring entity110. The monitoring entity110may, for example, execute a textual comparison between the configuration files350and400. More specifically, the sub-sections of the current configuration file350are textually compared with sub-sections of the configuration file400having a same tag. As such, sub-sections comprising configuration commands relative to same characteristics of a same network component130are textually compared. In this embodiment, comparing the current configuration file350and the reference configuration file400includes comparing a first sub-section of the reference configuration file400with a corresponding second sub-section of the current configuration file350based on tags of the first and second sub-sections, the first and second sub-sections comprising configuration commands relative to one of the plurality of network components130.

In one embodiment, comparing the configuration files350and400is performed periodically at a pre-determined rate or in response to an update of one of the configuration files350and400. In the context of the present disclosure, update of a given one of the configuration files350,400may be executed by generating a new given one of one of the configuration files350,400.

In at least some embodiments, the method500includes a setup phase prior to operation505, the setup phase comprising receiving a user request for applying a network configuration to the network, generating the network object model300of the network configuration through instantiation objects as previously described, each network component being described by one or more corresponding instantiation objects of the network object model, generating one or more configuration instantiating commands based on the user request, each configuration instantiating command being directed to a corresponding network component130, transmitting, by the monitoring entity110, the one or more configuration instantiating commands to a corresponding one or more network component of the plurality of network components, and executing the one or more configuration instantiating commands to apply the network configuration to the network.

In at least some embodiments, the method500further includes identifying, based on a result of the comparison between the configuration files350,400, incoherent configuration commands in sections of the configuration files350,400, a configuration commands of a section of the configuration file400being identified as incoherent if a corresponding section of the current configuration file350lacks the given configuration command, and a configuration commands of a section of the current configuration file350being identified as incoherent if a corresponding section of the configuration file400lacks the configuration command. In one embodiment, the monitoring entity110may generate instructions causing an execution of the incoherent configuration commands of the configuration file400onto their corresponding network components130. Similarly, the monitoring entity110may discard incoherent configuration commands from a given sub-section of the current configuration file350and execute the configuration commands of the given sub-section on the corresponding network component130, or execute corrective configuration commands that emulate a discarding of the incoherent configuration commands of the current configuration file350. In other words, upon being executed by the monitoring entity110, the corrective configuration commands cause the configuration status of a given network component130having a corresponding sub-section of the current configuration file350comprising an incoherent configuration command, to match a configuration status described by the other configuration commands of said sub-section without the incoherent configuration command. As such, the current network configuration matches the expected network configuration.

While the above-described implementations have been described and shown with reference to particular steps performed in a particular order, it will be understood that these steps may be combined, sub-divided, or re-ordered without departing from the teachings of the present technology. At least some of the steps may be executed in parallel or in series. Accordingly, the order and grouping of the steps is not a limitation of the present technology.

As an example,FIG.6is a schematic block diagram of the controller600providing the functionalities of the monitoring entity110according to an embodiment of the present technology. The controller600includes a processor or a plurality of cooperating processors (represented as a processor610for simplicity), a memory device or a plurality of memory devices (represented as a memory device630for simplicity), and a input/output interface620allowing the controller600to communicate with the communication network120, the plurality of network components130communicably connected thereto, and/or administrator devices150. The processor610is operatively connected to the memory device630and to the input/output interface620. The memory device630includes a storage for storing parameters634, including for example and without limitation the current configuration file350and the reference configuration file400. The memory device630may include a non-transitory computer-readable medium for storing code instructions632that are executable by the processor610to allow the controller600to perform the various tasks allocated to the controller600in the method500.

The controller600is operatively connected, via the input/output interface620, to the communication network120and the administrator devices150. The controller600executes the code instructions732stored in the memory device730to implement the various above-described functions that may be present in a particular embodiment.FIG.6as illustrated represents a non-limiting embodiment in which the controller600orchestrates operations of the monitoring entity110. This particular embodiment is not meant to limit the present disclosure and is provided for illustration purposes.

It should be expressly understood that not all technical effects mentioned herein need to be enjoyed in each and every implementation of the present technology.