“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 9-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”

1. What does the acronym PDIOO stand for?

1. Prep, do, inform, organize, operate

2. Python, define, integrate, own, observe

3. Plan, design, implement, operate, optimize

4. Plan, do, integrate, organize, operate

2. SNMPv3 uses

1. The MD5 and SHA authentication methods.

2. Community string-based authentication.

3. Key-based authentication.

4. The AES-128 authentication method.

3. What does SRE stand for?

1. Source route engineering

2. Site reliability engineering

3. Self-regulating entity

4. Source route entity

4. What type of network is used for highly partitioned administrative traffic?

1. FWM (firewall management)

2. SR (segment routing)

3. OOB (out-of-band network)

4. VLAN (virtual local-area network)

5. What is an example of zero-touch deployment functionality?

1. Powered-on provisioning

2. Plug-and-play (PNP)

3. Auto SmartPorts

4. Papoose

6. Intent-based networking transforms a hardware-centric network of manually provisioned devices into a controller-centric network that uses ____________ translated into policies that are automated and applied consistently across the network.

1. Business requirements

2. Software definitions

3. Routing protocols

4. Artificial intelligence

7. What is NETCONF?

1. A collaboration protocol for audio conferencing.

2. A JSON-based schema for configuration management.

3. A network controller function using Python.

4. A protocol standardized by the IETF to normalize configuration management across multiple vendors using XML-based schemas and YANG models.

8. What is a 2FA or MFA function used to do?

1. Develop resilient Python functions for device auditing.

2. Provide a user-access accounting service.

3. Validate something a user knows with proof of who they are to provide access.

4. Programmatically initiate a Webex meeting.

9. An embedded management function is all that is needed for comprehensive IT Service Management.

1. True

2. False

Foundation Topics

Network Management

Ahh, network management. The oft-maligned discipline of network IT. If you ever worked in an environment where you were given marching orders, you might have cringed at the boss’s directive: “I need you to work on network management.” If you were in an environment where you were able to pick your own priorities, you probably did not select network management as a first choice. However, much has changed; there have been great strides and improvements in network management and operations that can be attributed to advancements with software-defined networks (SDN), DevOps, continuous integration/continuous deployment (CI/CD), and site reliability engineering (SRE).

You can’t deal with network infrastructure without using proper planning, design, implementation, operation, and optimization (PDIOO) methodologies. The PDIOO model has been used for many years to provide structure in the networking discipline. Implementation, operations, and optimization have been most impacted by network programmability and automation over the years. The other planning and design components have also seen benefits from frameworks such as the Information Technology Information Library (ITIL), The Open Group Architecture Framework (TOGAF), and Control Objectives for Information and Related Technologies (COBIT). Whichever IT service management model is used, it is important that automation be a prime consideration in order to reduce human effort and errors, to increase speed of service delivery, and to gain operational efficiencies and repeatability of services against the network infrastructure.

However, you might wonder why network management and operations were given short shrift. Many times, it was the last consideration on the proposal/budget and the first to get cut. It’s true that a well-engineered network could operate for a time without network management focus and still perform well. Over time that well-engineered network would undergo changes. A few configuration changes here. A decommissioned syslog event server there. An additional branch network here or 20 everywhere, and before you know it, serious problems need to be addressed! How many times have you heard about someone walking through the data center to see a red or amber light on a module, fan, or power supply, and then look at the logs and see the alert was first registered months ago (something like Figure 9-1)? Surely that has never happened to you!

Network has always been important. Depending on an organization’s complexity, level of sophistication, and operational needs, using common commercial offerings from Cisco, such as DNA Center, Prime Infrastructure, Crosswork Network Automation, or Network Services Orchestrator (NSO), may be well suited to the situation. There are also well-equipped solutions from other vendors. However, as complexity increases and as scope of services expands, then automation, orchestration, and integration—among many other management tools and controllers—must occur.

A company that has multiple networking domains and dependent services will have many management tools and controllers to consider. Additionally, other IT systems, both commercial and open source, would be common. Popular open-source solutions, such as Grafana, Zabbix, Nagios, and OpenNMS, are often seen. Figure 9-2 shows an example.

Network management concepts provided strong roots for current alignments to automation, orchestration, software-defined networking (SDN), DevOps, CI/CD, and site reliability engineering (SRE). SDN is a mature technology by now, whereas DevOps, CI/CD, and SRE may be new concepts to traditional network engineers. The collaboration among developers and network operations personnel to achieve highly automated solutions in a quick fashion is the foundation of DevOps. Continuous integration/continuous deployment (CI/CD) refers to a combined practice in software development of continuous integration and either continuous delivery or continuous deployment. Site reliability engineering is a practice that brings together facets of software engineering and development, applying them to infrastructure and operations. SRE seeks to create functional, scalable, and highly reliable software systems. It is good to have foundational networking skills, but it is even better when you can complement them with programming skills that can make monitoring and provisioning more automated and scalable.

As an engineer, like you, I experience a lot of personal satisfaction in creating practical solutions that impact my company and the world.

So, network management is not the career-limiting role it was once considered. Those in that discipline benefited by augmenting their skills with network programmability because it felt like a logical extension of the work already being done. And it served as the foundation for the skills professionals are aspiring to today. Don’t lose heart if you’re just joining us on your own network programmability journey; you’re not too late! When you break free from continuous fire-fighting mode and enjoy the benefits of automation and network programmability, there is a lot of satisfaction. Ideally, the network management, operations, or SRE teams are doing their best work when network IT is transparent and accountable to the user and customer.

Indeed, the automation of network management, including service provisioning, has been a key differentiator for several large, successful companies. As an example, consider how Netflix moved from private data centers to the public cloud between 2008 and 2016. The company focused on automating its processes and tooling to give it a sense of assurance, even though its service operated over physical infrastructure it did not control. The company recognized that while it didn’t own the infrastructure, it still owned the customer experience. Automation reduces effort for you and your customers. A customer-experience-focused business is a differentiator. Remember Henry Ford’s 1909 comment about his Model T that you could “have any color so long as it’s black”? That was not a customer-inclusive concept then and remains so now. Obviously, the company has since transformed its business to appeal to broader customer preferences.

Many companies differentiate themselves from competitors through automation. When they automate more services, they save money and meet customer expectations faster.

Methods of Network Provisioning

Network provisioning has taken many forms over the years. To be sure, the industry had to start somewhere. All the way back to the earliest Cisco products of AGS, AGS+, and IGS in the late 1980s and early 1990s, network engineers would interact with their network devices through serial console cables directly connected to their terminal. Who can forget the ubiquitous blue serial console cable that came in the box with a router or switch (see Figure 9-3)? How many have a dozen or so squirreled away in the lab or at home?

In a worst-case scenario of needing to do a password reset, you might even have used dual in-line package (DIP) switches that needed to be flipped in sequence.

Fortunately, the industry has come a long way. Ideally, you don’t even need to see a device physically or know where it exists to influence its operation. In some environments, the networking functions are not even physical devices. Consider the Cisco Cloud Services Router (CSR) 1000V. It is a wholly software virtualized router running Cisco IOS XE software, commonly deployed in cloud environments. Virtualization of network functions and services means no more physical console cables and no need to “touch” something to affect its function or operation.

As the device (or node) count increases, it is unrealistic to expect individuals to interact with them physically or manually. There are just too many devices and too many changes. Some resource or feature requirements can be very short-lived. If human effort, which can be error-prone from time to time, is regularly used, then your deployments and customer experience will suffer. Customers expect speedy delivery in a consistent fashion. Waiting for an engineer to read an email, process a request, and implement it takes too long.

CLI/Console

The original serial console connection methods morphed into solutions using terminal servers that could aggregate 8, 16, 32, or more terminal connections into one device that would fan out to many other devices in the same or nearby racks. Figure 9-4 shows a logical network representation illustrating where a multiplexing terminal server might reside.

This out-of-band (OOB) management model separates a dedicated management network from production traffic. OOB models persist in highly available or remotely accessible environments today. In-band management models intermingle the administrative and management traffic with the regular user and production traffic.

In-band management became de rigueur with insecure Telnet persisting for many years. Eventually, slowly, Secure Shell (SSH) took over as the preferred mode to connect to a device for configuration management or other interaction. The initial methods of configuration management would entail typing entire configuration syntax. Only slightly more advanced was using terminal cut-and-paste operations, if you had a well-equipped terminal emulator! However, this method does not scale, nor is it efficient.

Let’s look at a classic “what not to do” user example from many years ago. In this situation, the network team used a service request management (SRM) system to document, request, review, and gain approvals for change requests. However, the SRM was not integrated with their change management processes, which were PuTTY and HyperTerminal. The change one Friday night was to implement an almost 10,000-line access control list (ACL). The network engineer dutifully accepted the approved change, took a copy of the 10K-line ACL from the pages of a Microsoft Word document detailing the change request, and then started PuTTY. The engineer SSH’d into the device, entered configuration mode, and pasted the ACL. Because a command-line interface (and paste) is a flow-control-based method, it took more than 10 minutes to get the ACL into the system. When the engineer saw the device prompt, they copied the running configuration to the startup configuration and went home at the end of their shift. Four hours later, the engineer was called back in because network traffic was acting unexpectedly. Some desirable traffic was being blocked, and other, undesirable traffic was being passed! Eventually, the root cause was determined. The engineer had a 10K-line access control list, but the terminal emulator was configured for a maximum of 5K lines. They pasted only half the total ACL!

Despite examples like this, the CLI model of managing a device has persisted for many years. I often refer to it as finger-defined networking (FDN) in a snarky accommodation against the preferred software-defined networking (SDN) model everyone aspires to, as you can see in Figure 9-5.

Why has this model persisted so long? The reality of ease of use with command arguments and syntax that suit users’ readability explains the “death grip” among many network engineers. If you want to see an FDN-centric engineer squirm, disable or delete their terminal emulator.

If you’re going to be using FDN, you should at least do so securely. Thankfully, SSH is ubiquitous today. It is used in foundational interactions with device CLIs, but also as the Secure Copy Protocol (SCP) subsystem to move files. The growth of git and the use of SSH to synchronize code and files in repositories only increase the need for security. The interactive username/password model has been common for authentication. Key-based authentication has been available for many years, but some organizations are resistant to use it, despite it being well suited to automation and unattended device interaction. Two-factor authentication (2FA) and multifactor authentication (MFA) are some of the most impactful innovations in securing user access. Combining something you know, like a username and password, with something that proves who you are, like the possession of a smartphone with an authentication app or a hardware token generator or even a biometric reader, has significant impact on authorized access.

The Cisco acquisition of Duo in 2018 provides MFA that enables varied and flexible alternative factor authentication methods, such as smartphone app, callback, SMS, and hardware token generator, as shown in Figure 9-6.

Although some 2FA token generators are physical devices, recognize that alternative solutions are necessary to generate tokens for automated and programmatic purposes.

Some environments implement 2FA for human user interaction and have alternative key-based authentication for automated service accounts. Thankfully, the staunch dependency to continue FDN and yet increase the security posture influenced the industry to create programmatic token generators for Python scripts and other automated and unattended uses.

The most desirable methods for interacting with a physical or virtual device, in order of security posture, are

• SSHv2 with two-factor authentication

• SSHv2 with key-based authentication

• SSHv2 with username/password authentication

• Terminal server/console (physical)

• Telnet (not suggested)

The use of insecure Trivial File Transfer Protocol (TFTP) transfer of a configuration with a TFTP server is still popular. However, the better-intentioned Secure Copy Protocol is where most discerning network operators focus.

SNMP

Simple Network Management Protocol (SNMP) continues to exist, seemingly off to the side.

Note

SNMP is not part of the DEVCOR exam, so the information provided here is for historical context.

Many network engineers repeat the joke that SNMP is not simple. Can you configure a device with it? In some cases, many more MIB objects are readable versus those that are writable. SNMP has been the standard method for collecting performance, configuration, inventory, and fault information. It did not take off as well for provisioning. Indeed, the closest that SNMP got to network provisioning for most situations was using an SNMP Set operation against the CISCO-CONFIG-MAN-MIB to specify a TFTP server and a file to transfer representing text of the configuration. A second SNMP Set operation triggered the merge with a device’s running configuration.

Thankfully, the industry pushes toward streaming telemetry, a more efficient and programmatic method that we cover later. It’s notable that Google talked of its push away from SNMP at the North American Network Operators’ Group (NANOG) 73 conference in the summer of 2018. Reference the video at https://youtu.be/McNm_WfQTHw and presentation at https://pc.nanog.org/static/published/meetings/NANOG73/1677/20180625_Shakir_Snmp_Is_Dead_v1.pdf.

Then Google shared experiences with its three-year project to remove SNMP usage. Because SNMP is still widely used in many environments and the core collection mechanism of most performance management tools, we continue our review of it, limited to the more secure SNMPv3, which you should be using if doing SNMP at all.

SNMPv3 brought new excitement to the network management space in the early 2000s. SNMPv3 brought authentication and encryption along with other security features like anti-replay protections. The criticisms about SNMPv1 and v2c being insecure finally could be addressed. The use of MIB objects did not change, only the transport and packaging of the SNMP packets. Figure 9-7 alludes to the promise of securing the sensitive management traffic.

The Internet Engineering Task Force (IETF) defined SNMPv3 in RFCs 3410 to 3418, while RFC 3826 brought advanced encryption. SNMPv3 provides secure access to devices through a combination of authenticating and encrypting packets. The security features provided in SNMPv3 are

• Message integrity: Ensuring that a packet has not been tampered with in transit

• Authentication: Determining the message is from a valid source

• Encryption (optional): Obscuring the contents of an SNMP payload, preventing it from being seen by an unauthorized source

Whereas SNMPv1/2c required community strings to read/write a device’s MIB variables, in SNMPv3 user/group assignments with an authentication password permit authentication. A separate privacy passphrase enables encryption, if desired.

Every SNMPv3 sender/receiver has a snmpEngineID that uniquely identifies it. Even back to legacy Cisco IOS 12.0 in 2000, if you looked at a device config, an snmp-server engineID local 000 statement existed. This was the foundation for SNMPv3 on the device.

Any read/write done with an invalid snmpEngineID is rejected, and a REPORT packet, a new type of notification, is generated.

Each device can have multiple identities called a context, which is essentially a separate MIB environment or partitioned space, used with situations like BRIDGE-MIB/VLAN polling or VRFs.

Figure 9-8 shows the new SNMPv3 category levels and capabilities.

Many organizations and network management tools initially test the waters by supporting authNoPriv—Authentication with No Privacy (encryption). This can be a reasonable first step; SNMP interactions are authenticated, and if encryption isn’t a goal, such as with internal networks or labs, then the model is sufficient. For organizations needing more security, such as financial, government, and health-care industries, then authPriv—Authentication with Privacy—is more desirable.

The initial IETF specification for SNMPv3 called for 56-bit DES encryption. For some environments, this is enough. However, there was pressure from the financial industry to embrace more sophisticated encryption models. The IETF complied through RFC 3826 by adding AES-128; many devices and management tools likewise added support for the additional specification. Cisco went a step further with even more enhanced encryption models to include 168-bit triple-DES: 128-, 168-, and even 256-bit AES. It is important to map the device authentication and encryption capabilities with those of the management tools; otherwise, the security will not be as desired.

File Transfer Methods

For network provisioning, TFTP is common in lower-risk areas, such as development and testing environments. Traditional methods of archiving a device configuration or changing it through TFTP would be logging in to the device with a terminal emulator through an out-of-band console or in-band SSH session and issuing a copy tftp running-config (or similar) command. This method is also used for file transfer of device software images. Some of the CLI and UI representations in Figure 9-9 should be familiar.

Regular File Transfer Protocol (FTP) and the more secure method, Secure File Transfer Protocol (SFTP), are options with devices to a varying level of adoption. When it comes to secure transfer of configurations or software images, the Secure Copy Protocol has been more widely used because it depends on a subsystem of SSH for its secure transport, which is already, hopefully, being used for command-line access.

Element Management Systems

While progress was being made to help device manageability, most service providers and large enterprise environments were looking for more efficiencies. In the late 1990s and early 2000s, the story on the network management application side was not much better. The applications, or element management systems (EMSs), as they became known, were focused on their individual functionality. The notion of even sharing device lists—hostnames, IP addresses, and credentials—was largely an unrealized concept. The EMSs acted as isolated islands of functionality and information. Eventually, attempts were made to integrate, first among product suites of individual vendors, then across popular EMSs. The integration adapters were the first pair-wise data sharing systems. A network management operator in the early 2000s might remember hearing about the integration adapters between CiscoWorks 2000 and HP OpenView Network Node Manager. Other adapters became available with popular EMSs like Concord eHealth, Tivoli OMNIbus Netcool, and Infovista. However, these were still one-to-one pairings, as depicted in Figure 9-10.

Web interfaces on routers and switches became possible but underutilized for making changes. People just loved the CLI and FDN!

The device-by-device web method lacked efficiencies that large-scale environments sought even though the browser-based model appeared intriguing.

Some attempts at vendor- and product-specific interactions with remote-procedure calls (RPCs) were also developed. Eventually, around 2006, the industry recognized that having different configuration syntax for different device types, models, and vendors was inefficient. The IETF working group for NETCONF (network configuration) was born to normalize configuration management through the use of common Extensible Markup Language (XML) schemas. The operator or management tool would perform a terminal connection to a specific port, and the device’s NETCONF agent would respond. The XML-rendered configuration would be pushed, and the NETCONF agent would translate it to the device’s native syntax. The hope was there would be no further need for the Cisco IOS BGP configlet, the Cisco IOS-XR BGP configlet, the Juniper JUNOS BGP configlet, the HP BGP configlet, and so on. If you had multiple device models, operating systems, and/or vendors, you could have one representation of that BGP configuration standard. It could be pushed to any NETCONF-supporting device with equal effect.

It wasn’t until the advent of SDN starting in 2008 that there was a push to include network programmability in earnest with control plane and data plane separation and network virtualization. The IT industry experienced a proliferation of mechanisms to change network devices. Some methods came from the compute/application IT discipline because they had similar needs to perform rapid and scalable configuration changes. Users first saw Puppet and Chef, and the now-popular Ansible and Terraform. Sophisticated and cloud-native environments use Kubernetes and Terraform-based solutions to achieve orchestrated provisioning. Some of these systems required agents on the managed devices, as the early Puppet and Chef implementations did, but others were agentless and would leverage the near-ubiquitous SSH interface on devices to automate the same commands and configuration directives a person would perform manually. The agentless model is largely used now. It was the primary method for Ansible and was later picked up by Puppet and Chef.

An interesting artifact of the drive to network programmability was the growing community of programmers and coders who were joining the network IT discipline. These innovators brought with them the notions of DevOps, CI/CD, and Infrastructure as Code (IaC). When the coders were onboard with IaC, new solutions that abstracted the network device configuration into intent-based models became relevant, such as HashiCorp’s Terraform.

Embedded Management

As centralized EMSs increased in prominence, the notion of a device’s “self-monitoring” was considered. The benefits of distributing the management work or dealing with a network isolation issue were found through embedded management techniques. Cisco’s Embedded Event Manager (EEM) has been a popular and mature feature for many years in distributing management functions to the devices themselves.

Some use cases with EEM have been

• Monitoring an interface error counter and administratively disabling when a threshold is reached

• Sending an email or syslog event message when a CPU or memory threshold is reached

• Changing a routing metric when a specific condition is met

• Clearing a terminal line that has been running over a defined time length

Often, having the device self-monitor with EEM could be more frequent than a centralized monitoring solution that may be managing hundreds, thousands, or more devices. This is especially true if the condition being monitored is not something that needs to be collected and graphed for long-term reporting. Consider monitoring an interface or module health state every 30 seconds. This rate may be unachievable with a centralized system that has tens of thousands of devices to manage. However, a device may be able to use embedded management functions to self-monitor at this rate with little impact. It could then send notifications back to a centralized fault management system as necessary.

In IT, service management performance and fault management often have similar goals. Performance management usually entails periodic polling or reception of streaming telemetry in a periodic fashion. The performance information may be below thresholds of concern, and the information is not especially useful. However, retaining the periodically gathered data can be useful for trending and long-term analysis.

Conversely, the fault management function may collect data to compare against a threshold or status and not retain it if the data doesn’t map to the condition. This function becomes very ad hoc and may not align to standard polling frequencies. Fault management also benefits from asynchronous alerts and notifications, usually through Syslog event messaging or SNMP traps.

For CiscoLive events, the network operations center (NOC) has used advanced EEM scripts to monitor CDP neighbor adjacency events; identify the device type; and configure the connected port for the appropriate VLAN, security, QoS, and interface description settings.

Using Embedded Event Manager is beneficial for device-centric management; however, it should not be relied on solely for health and availability management. If you didn’t get an email or syslog event message from the device, does that mean all is healthy? Or does it mean the device went offline and can’t report? It is wise to supplement embedded management solutions with a robust availability monitoring process to ensure device reachability.

Zero-Touch Provisioning (ZTP)

A zero-touch provisioning (ZTP) function enables you to provision and configure devices automatically. It is useful primarily during the initial setup of an unconfigured, or virgin state, device. ZTP has been achieved by different feature names on varying platforms, such as AutoInstall, Power-On Auto Provisioning (POAP), Network Plug and Play (PnP), and SmartInstall. AutoInstall is the most ubiquitous and historical of these options.

The general process is similar, however; an unconfigured device starts up, seeking its IP address from a DHCP server, and kicks off a process to download a base configuration file from a file server identified in DHCP options. The secure and recommended approach would be via HTTPS, whereas the TFTP service was initially offered in the feature. Even older variations rely on BOOTP processes that will not be covered.

It’s notable that the Meraki and Cisco SD-WAN platforms fundamentally use ZTP as their core means of provisioning via cloud or centralized controller means. Essentially, these classes of devices organically have enough network intelligence and process/workflow embedded to make connections through the Internet to their cloud-based provisioning systems. The network administrator uses the Meraki or SD-WAN portal to “claim” the device and proceed with specific customizations.

ZTP is an alternative method for configuration on many other platforms using IOS-XE, NX-OS, IOS-XR, and so on, when there is no base configuration. It is also intriguing to network programmers because it allows mass provisioning in a programmatic sense.

A ZTP process has several common functions that mimic some familiar staging tasks:

• Obtaining base network connectivity (DHCP, DNS, default routing)

• Performing software/firmware upgrades

• Obtaining and incorporating “Day-0” base config (core services such as NTP, SSH, SNMP, Syslog; generating/importing certificates, or using Trusted Platform Module or International Organization for Standardization and the International Electrotechnical Commission (ISO/IEC) Standard 11889, and so on)

• Obtaining and incorporating “Day-0” device/function-specific configuration (interfaces, routing protocols, VLANs/VRFs, and so on)

The ZTP process has most of its notable magic in the Obtaining Base Network Connectivity task. Consider the standard flow of ZTP for NX-OS, IOS-XR, and IOS-XE devices from Figure 9-11.

Of interest to network programmers is the enhanced AutoInstall Support for TCL Script feature. It enhances AutoInstall by providing more flexibility in the installation process. The administrator can program the device with TCL scripts to get information about what to download and to choose the type of file server and the required file transfer protocol.

Of special interest to network programmers is the even more advanced option to ZTP using Python scripts, as found in the IOS-XE 16.6+ platforms. In this case, DHCP option 67 settings are used to identify a Python script to download. The device executes the Python script locally using Guest Shell on-box functionality, as depicted in Figure 9-12.

With a script-based deployment, you can program and execute a dynamic installation process on the device itself instead of relying on a configuration management function driven by a centralized server.

As an example, consider the Python ZTP script in Example 9-1.

Example 9-1 Python ZTP Script

Click here to view code image

# Importing cli module
import cli

print('
## Bootstrap ZTP Python Script
')
cli.execute('configure replace flash:base-config force')

print('## Executing show version

')
cli.executep('show version')
print('## Configuring Loopback Interface

')
cli.configurep(["interface loop 10", "ip address 10.1.1.1 255.255.255.255", "end"])

print('## Executing show ip interface brief
')
cli.executep('show ip int brief')

print('## Bootstrap ZTP Python Script Execution Complete

')

This simplistic Python script merely echoes the show version command (to the console, when booting up), configures a Loopback 10 interface, and then echoes the show ip interface brief command. Obviously, in its current form, the script is not portable, but with some basic Python skills, you can easily enhance it to have conditional logic or even off-box, alternate server interactions performing basic GET/POST operations to a REST API. This is when the magic happens: the device could provide a unique identifier, such as serial number or first interface MAC address, which could be used for more sophisticated and purposeful device provisioning.

Atomic or SDN-Like/Controller-Based Networking

The traditional element management system (EMS) approach to network management is very atomic and becoming untenable. In atomic-based EMSs, devices are managed one by one with little or no consideration to interdependencies and relationships across devices. The EMS might expect you to provide the intelligence and discernment that upgrading both devices in service-pairs, such as HSRP, primary/backup DHCP, or route reflectors, at the same time is unwise. The EMS may dutifully take both out of service, without warning you of the implication to service availability.

With atomic EMSs, the notion of service is largely foreign because it involves characteristics and relationships spanning multiple devices.

In traditional networking, there is the notion of the control plane and data plane residing on the same device. These logical concepts functionally separate the forwarding determinations and decisions, as a brain would, from the actual processing of the packets for forwarding, as muscles would. There is also a provisioning distinction known as the management plane that deals with protocols and methods to configure the control plane, such as SNMP, NETCONF/RESTCONF, and REST. Table 9-2 shows this distinction.

Figure 9-13 depicts this model graphically.

If you find yourself running network discovery or entering device management addresses and credentials with a network management tool, you are probably dealing with a traditional EMS system. Systems like Prime Infrastructure, Data Center Network Manager (DCNM), Prime Collaboration, Statseeker, and others are examples of atomic EMSs.

The advent of software-defined networking catalyzed the centralized controller management model. In most cases, the managed devices seek out the controller that manages it. Minimal, if any, initial configuration is necessary on the device. The controller identification may occur by expected IP address or hostname, broadcast/multicast address, a DHCP option, DNS resource record (SRV), or a Layer-2/3 discovery process.

After the device registers with the controller, it shows up in the inventory. Additional authorization may have been performed with the device and/or controller. In the Meraki or Cisco SD-WAN models, the devices register with a central, cloud-based controller, and administrators must “claim” the device. Additional examples of SDN and controller-like management systems are DNA Center and the ACI APIC controller.

You can look to the wireless industry for some examples of both atomic EMS and SDN controller models. Initially, wireless access points (WAPs) operated autonomously and required individual configuration. A centralized management tool, like Cisco Prime Network Control System (NCS), which eventually converged with Prime Infrastructure, was used to manage autonomous WAPs. Later, centralized controller-based WAPs, or lightweight WAPs (LWAPs), were developed that used the wireless LAN controller (WLC) appliance for central management. Yet another iteration of manageability occurred with a distributed model using wiring closet-based controllers in the Catalyst 3850. The multiple options existed to suit customer deployment preference and need.

In a more SDN literal model, the control plane function is separated from the device and is provided by a centralized controller. The data plane function still resides on the device, as seen in Figure 9-14.

Advanced Concepts—Intent-Based Networking

Intent-based networking (IBN) is one of the newest principles to transform the networking industry. Users, devices, and distributed applications have exploded in number, greatly outstripping legacy frameworks such as IPv4 and complicating security frameworks.

The Cisco Annual Internet Report (www.cisco.com/c/en/us/solutions/collateral/executive-perspectives/annual-internet-report/white-paper-c11-741490.html) describes a healthy growth of Internet-connected users and devices. Figure 9-15 shows how growth appears over several years.

When you consider the growth of underpinning network devices necessary to accommodate the mobile user, servers, and virtual machines, you can quickly understand how atomic EMS-based management is truly untenable. To address the diversity of endpoints and functions, the networking environment has become exponentially more complex. IBN transforms a hardware-centric network of manually provisioned devices into a controller-centric network that uses business intent translated into policies that are automated and applied consistently across the network. The network continuously monitors and adjusts network configuration and performance to achieve the specified business outcomes. Operational efficiencies are realized when IBN models allow for natural language directions to be translated to native controller-centric directives as conceptualized in Figure 9-16.

IBN augments the network controller model of software-defined networking. The network controller is the central, authoritative control point for network provisioning, monitoring, and management. Controllers empower network abstraction by treating the network as an integrated whole. This is different from legacy element management systems where devices are managed atomically, without functional or relational consideration. Cross-domain orchestration is enabled when controllers span multiple domains (access, WAN, data center, compute, cloud, security, and so on) or when they provide greater efficiencies in programmability.

A closed-loop function of IBN ensures practical feedback of provisioning intent that reflects actual implementation and operations. The activation function translates the intent into policies that are provisioning into the network. An assurance function continuously collects analytics from the devices and services to assess whether proper intent has been applied and achieved. Advanced solutions apply machine learning to accurately estimate performance or capacity constraints before they become service impacting.

The DNA Center management solution and CX Cloud are solutions from Cisco that enable intent-based networking.

Summary

This chapter focuses on capabilities in network management, infrastructure provisioning, element management systems, zero-touch provisioning (ZTP), atomic or SDN-like/controller-based networking, and intent-based networking. It depicts the growth and transformation in the network industry over the past 30 years. As technological problems were identified, solutions were made and transformation occurred. Each step of the way, refined principles have improved the state of networking. If you find yourself implementing or sustaining the legacy methods first described, you are highly encouraged to adopt the newer methods defined later in the chapter.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here, Chapter 17, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep Software Online.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key Topic icon in the outer margin of the page. Table 9-3 lists a reference of these key topics and the page numbers on which each is found.

Complete Tables and Lists from Memory

Print a copy of Appendix C, “Memory Tables” (found on the companion website), or at least the section for this chapter, and complete the tables and lists from memory. Appendix D, “Memory Tables Answer Key,” also on the companion website, includes completed tables and lists to check your work.

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

continuous integration/continuous deployment (CI/CD)

control plane

data plane

DevOps

intent-based networking (IBN)

management plane

Power-On Auto-Provisioning (POAP)

software-defined networking (SDN)

site reliability engineering (SRE)

zero-touch provisioning (ZTP)

References

URL	QR Code
https://youtu.be/McNm_WfQTHw
https://pc.nanog.org/static/published/meetings/NANOG73/1677/20180625_Shakir_Snmp_Is_Dead_v1.pdf
https://cfnng.cisco.com/
https://www.cisco.com/c/en/us/solutions/collateral/executive-perspectives/annual-internet-report/white-paper-c11-741490.html