Management Systems–Cisco Managing Networks
At some scale or level of complexity, all operators move from manually monitoring and managing their networks to using some form of network management system (NMS). Figure 21-9 illustrates the basic components of an NMS.
Figure 21-9 Management System Components
• Time series database: Not all network management systems have a time series database keeping periodic snapshots of network state and a historical record of network events. The time series database, if one exists, can be used to “rewind” prior network states, which can be helpful in root cause analysis or understanding a change’s impact.
• Intent engine: Not all network management systems have an intent system translating business or operational intent into a network model.
• State database: This database contains information about the current state of individual devices and overall network health.
Comparing this to the single source of truth (SSOT ) can highlight points where the network is not configured or doing what the operator intends. This state is gathered from many systems, including those shown in Figure 21-9. Some network management systems store this information using a modeling language, in a relational database, or some other organized format. The state database is rarely just dumps of data gathered from individual devices.
• Single source of truth (SSOT): The SSOT is the intended configuration of each network device. It might contain actual configurations, or it might contain configurations stored in a modeling language.
• Automation system: This script set pulls data from the SSOT and makes configuration changes on individual devices as needed. These same scripts might pull data off each device to build a database of the current network state.
• Hardware abstraction: If the SSOT is stored using a modeling language, the hardware abstraction module converts data to and from the device’s configuration format to the modeling language.
The bottom of Figure 21-9 shows four different ways data is collected from network devices and used to configure network devices. These include
• Simple Network Management Protocol (SNMP): This older protocol is used for managing network-connected devices.
SNMP formats data using Management Information Bases (MIBs). SNMP is widely considered a legacy protocol—many operators are working toward eliminating SNMP from their networks—because it is considered insecure.
• NETCONF/ YANG: NETCONF is a protocol to carry YANG-formatted data. YANG is a markup language, which means it is human-readable and formatted using tags like the Hypertext Markup Language (HTML) or Extensible Markup Language (XML).
• Command-line interface (CLI): This is the same CLI operators use to interact with individual routers and switches. Scripts can pull the data from a router’s CLI output, parse it into databases, comma-separated value (CSV) files, etc. Automation modules can also build commands and feed them to a router or switch through the CLI.
• Machine interface: Many network devices now have an interface designed for automation. These interfaces allow operators to access device data in its native format. Google Remote Procedure Call (GRPC) is one widely used interface.
There are many other information sources in a network.
Heating and cooling systems, power supplies, and even scripts that periodically ping or traceroute to specific destinations to test for liveness generate data a network management system can consume and act on.
NMS Dashboard
Most NMSs allow operators to quickly gauge the network’s health, or an individual device, through a dashboard—often called a pane of glass. These systems can alert the operator when a device or link fails, when a specific server is no longer reachable, when a device or link is too heavily utilized, and for many other conditions.
Work Process System
Every network operations team needs a way for users to report problems, triage those problems, and then repair them over time. Triage determines how important a reported failure is and how hard the failure will be to repair, and then prioritizes the workload.
Modeling Language versus Configuration
What is the difference between a modeling language and a configuration as a router’s CLI displays it? Figure 21-10 illustrates both forms of configuration.
Figure 21-10 CLI Output Versus Modeled Data
The upper part of Figure 21-10 shows a snippet of the CLI output from a Cisco router’s interface configuration. The lower part of Figure 21-10 shows the same information placed inside a YANG model.
On initial examination, the YANG version appears more complex: there is more text, and some text is enclosed in brackets. The text inside brackets is made up of tags, markup, or even metadata; they explain the tagged text. For instance:
• The interface address is the text between <address> and
</address>.
• The interface IP address is the text between <ip> and </ip>.
• The subnet mask is the text between <netmask> and
</netmask>.
While these tags make the text harder for a human to read, they make it much easier for a computer program or script to find the right information. Rather than searching for the term
Internet Address in the output—which might be used for more than just an IPv4 address—the script can look for the correct tags.
Information structured using markup is designed to be easily machine-readable and at least human-readable.