5.

Automation and configuration of common protocols:

Introduction

You are a network engineer whose task is to maintain a network that uses a suite of different
network devices running Cisco IOS XE, Cisco IOS XR, and Cisco NX-OS operating systems. It can be
cumbersome to manage such a diverse network and challenging to maintain consistency. In this
course, you will learn to configure essential features and protocols across these platforms, including
remote access, Layer 2 and Layer 3 interfaces, VLANs, virtual routing, and high availability protocols.
These skills will help you ensure that configurations are streamlined across all platforms, enabling
consistent management and reducing complexity in your network operations.

Remote Access Configuration

Here you will explore the configuration of remote access protocols—Telnet and Secure Shell (SSH).
You will learn how to configure these protocols on Cisco IOS XE, Cisco NX-OS, and Cisco IOS XR
platforms, with an emphasis on the more secure SSH Protocol.

Telnet and SSH

Telnet and SSH are the most basic and common protocols that are used for remote management of
Cisco network devices. Telnet is an older protocol that transmits all data, including authentication
credentials in plaintext. Due to this lack of encryption, Telnet is considered insecure and should only
be used in closed controlled environments for testing and not in production environments.

SSH was designed to address the security flaws of Telnet by encrypting all
communication between the client and server. Even if traffic is intercepted,
the content cannot be deciphered without the decryption keys. SSH also
includes data integrity checking via message authentication codes to
prevent tempering.

SSH supports additional features, such as secure file transfers through

protocols such as Secure Copy Protocol (SCP) and Secure FTP (SFTP),
along with tunneling, forwarding TCP ports and X11 connections.

Configuring Telnet and SSH on Cisco IOS XE Software

To enable Telnet, configure vty lines with Telnet as the allowed transport
input and set a password.

line vty 0 4

transport input telnet

password cisco123

login

The previous example enables Telnet access on the first five VTY lines (vty
0 4), allowing up to five simultaneous remote Telnet sessions.
The transport input telnet command ensures that only Telnet is allowed as
the access protocol. The password password is set, and the login command
instructs the device to prompt for this password when a user attempts to
connect via Telnet. Telnet also supports authentication with local
usernames that are configured on the device when using the login
local command.

To configure SSH, a few prerequisites must be met:

1. Set the hostname of the device. SSH uses the hostname as part of
its identity and is required for RSA key pair generation.
2. Configure an IP domain name. The domain name is used with the
hostname to create a unique fully qualified domain name (FQDN) for
the device, which is also necessary for the generation of the RSA key
pair. You can configure the domain name using the ip domain-
name domain command.
3. Generate an RSA key pair, which is used for encrypting
communication between the client and the device. To generate the
RSA keys, use the crypto key generate rsa command followed by
specifying a modulus size. A typical size would be 1024 bits, which
provides a good balance between security and performance. After
the RSA keys are generated, the SSH server and client capability are
enabled on the device.

hostname CAT9000-OFFICE

ip domain-name example.com

crypto key generate rsa modulus 1024

line vty 0 4

login local

transport input ssh

In this example, a hostname and IP domain name are configured, and RSA
keys are generated. The first five virtual terminal lines (vty 0 4) are
configured with transport input ssh for SSH sessions. The login
local command indicates that locally configured usernames will be
considered for authentication. Besides local authentication, RADIUS and
TACACS+ are also supported.
By default, Telnet and SSH on Cisco IOS XE devices are enabled on all IP
interfaces. It is best practice to use access lists and virtual routing and
forwarding (VRF) to limit and isolate access to the device.

Configuring Telnet and SSH on Cisco NX-OS

Because Telnet is not considered secure, it is disabled by default. To
enable Telnet, use the feature telnet command in the global configuration
mode.

configure terminal

feature telnet

exit

The previous example enables the Telnet server on all IP interfaces on the
device. Local users are allowed by default.

On Cisco NX-OS, SSH is enabled by default using RSA keys that are
generated with 1024 bits.

configure terminal

no feature ssh

no ssh key rsa 1024

ssh key rsa 2048

feature ssh

exit

In this example, SSH is first disabled and the previously generated 1024-bit
RSA key is deleted, then a new 2048-bit key is generated and SSH is re-
enabled. Local users are allowed by default.

SSH authentication on Cisco NX-OS devices provides an X.509 digital

certificate support for host authentication and authentication using SSH
keys allowing users to authenticate securely without being prompted for a
password.
configure terminal

username netadmin sshkey ssh-rsa

AAAAB3NzaC1yc2EAAAABIwAAAIE....

exit

In the previous example, an Open Secure Shell (OpenSSH) public key is

assigned to the user netadmin, allowing the user to authenticate securely
without being prompted for a password each time.

Besides locally stored usernames and passwords RADIUS, TACACS+ and

Lightweight Directory Access Protocol (LDAP) user authentication
mechanisms are also supported.

Configuring Telnet and SSH on Cisco IOS XR Software

Telnet and SSH on Cisco IOS XR can be configured and handled similarly
as on the Cisco IOS XE Software.

crypto key generate rsa

configure

telnet ipv4 server max-servers 5

ssh server v2

commit

SSH is enabled using the ssh server v2 command and Telnet is configured
with the telnet ipv4 server max-servers max-servers command.

Some software versions do not support RSA key generations inside the
global configuration mode, so generation should be done in privileged
EXEC mode.

Configuring Persistent Telnet and SSH on Cisco IOS XR Software

Traditional Telnet and SSH connections can fail if there is an issue with the
IOS process, leaving the console port the only method of accessing the
device. Persistent Telnet and SSH allow users to configure a transport map
that can direct all incoming Telnet or SSH traffic on the special
Management Ethernet interface to diagnostic mode, bypassing IOS. The
Ethernet Management Interface is a special port on the device that is
designed for management and not regular network traffic.

configure terminal

transport-map type persistent telnet Telnet-Persistent

connection wait allow interruptible

transport interface GigabitEthernet 0

exit

transport type persistent telnet input Telnet-Persistent

The previous configuration example sets up a persistent Telnet handling.

The transport map that is named Telnet-Persistent is created and applied
to the GigabitEthernet 0 interface. The allow interruptible command
ensures that the console connection waits for an IOS vty line to become
available. It also allows the user to enter diagnostic mode by interrupting,
allowing the user to enter diagnostic mode if no vty line is available, for
example due to IOS process not running. The final command ensures that
persistent Telnet is activated using the defined transport map.

configure terminal

transport-map type persistent ssh SSH-Persistent

connection wait allow interruptible

rsa keypair-name ssh-rsa

transport interface GigabitEthernet 0

exit

transport type persistent ssh input SSH-Persistent

This example configuration sets up a persistent SSH handling. It is similar
to the persistent Telnet configuration with the addition of the rsa keypair-
name command. This command specifies the RSA key pair for secure
communication and is different than the RSA key pairs defined for standard
SSH access.

Answer

The correct answer is SSH, because it encrypts communication and checks data integrity. This answer
is correct because SSH encrypts all communication between the client and server. The encryption
ensures that intercepted traffic cannot be deciphered without decryption keys. Additionally, SSH
provides data integrity checking with message authentication codes and prevents tampering. The
answer Telnet, because it is easier to configure is incorrect because Telnet transmits data in plaintext
and is not secure. The answer Telnet, because it supports more simultaneous connections is
incorrect because Telnet's simplicity does not outweigh its security risks. The answer SSH, because it
transmits data in plaintext is incorrect because SSH does not transmit data in plaintext; this
statement describes Telnet.

Enable Remote Access

Enable SSH on Multiple Devices
Step 1
Show Me
Access the Cisco Modeling Labs WebUI. To access Cisco Modeling Labs
running in your lab environment, open a web browser on your student PC
and navigate to https://10.1.1.20 or click the Cisco Modeling
Labs bookmark.
Step 2
Show Me
Log in to access the main dashboard.

Use the following credentials:

 Username: student
 Password: 1234QWer
Step 3
Show Me
Click the Enable Remote Access topology to go to the Workbench page.
Step 4
Show Me
Review the network topology in the Workbench. Take note of the present
devices and their configured addresses.
Step 5
Show Me
Check all devices in the topology and ensure they have fully booted before
proceeding with the lab steps or accessing the console. Attempting to
interact with a device that has not fully booted may interrupt the boot
process. Wait for a green checkmark to appear next to each node,
indicating that it is ready.
Step 6
Show Me
To access the CAT8000V router console, right-click the node and
choose Console.
Step 7
Show Me
At the the bottom of the pane, click the OPEN CONSOLE button.
Step 8
Show Me
In the console, enable the terminal with the enable command. Then
generate the required RSA key and enable SSH.
Note
The crypto key generation command displays a warning and might not be
suitable for future versions or production use because it could be
deprecated.
Step 9
Show Me
Repeat the same step on CAT9000v.
Note
The crypto key generation command displays a warning and might not be
suitable for future versions or production use because it could be
deprecated.
Step 10
Show Me
Open the XRv9000 console, then authenticate and configure SSH.

Use the following credentials:

 Username: cisco
 Password: cisco123
Step 11
Show Me
Open the NX-OS 9000 console, then authenticate and configure SSH.

Use the following credentials:

 Username: cisco
 Password: cisco123

Access the Devices From the PC or Student VM

Step 12
Show Me
Review the network topology in the Cisco Modeling Labs Workbench. Take
note of the listed addresses.
Step 13
Show Me
Launch the Terminal from the taskbar on your Student VM.
Step 14
Show Me
In the Terminal, use the ssh command to connect
to CAT8000V at 10.1.1.22. After successfully connecting, exit the SSH
session.

Use the following credentials:

 Username: cisco
 Password: cisco123
Step 15
Show Me
In the Terminal, use the ssh command to connect
to CAT9000V at 10.1.1.23. After successfully connecting, exit the SSH
session.

Use the following credentials:

 Username: cisco
 Password: cisco123
Step 16
Show Me
In the Terminal use the SSH command to connect
to XRv9000 at 10.1.1.24. After successfully connecting, exit the SSH
session.

Use the following credentials:

 Username: cisco
 Password: cisco123
Step 17
Show Me
Finally, try to connect to NX-OS 9000 at 10.1.1.25. After successfully
connecting, exit the SSH session.

Use the following credentials:

 Username: cisco
 Password: cisco123
Answer

The correct answer is crypto key generate rsa modulus 2048. This command specifies the creation of
a 2048-bit RSA key, which is necessary for enabling SSH. The options generate rsa key modulus 2048,
generate crypto rsa key modulus 2048, and rsa generate crypto key modulus 2048, do not accurately
reflect the syntax required for this command in Cisco devices.

VLAN Configuration

VLAN configuration is essential for creating logical segmentation in every network. VLANs allow you
to separate Layer 2 domains, enhancing security and network efficiency. This topic covers VLAN
configuration with examples of how to configure standard and extended VLANs and manage VLAN
configuration files.

Configuring VLANs and VTP on Cisco IOS XE Software

Cisco IOS XE Software supports two VLAN types: standard VLANs with IDs from 1 to 1005 and
extended VLANs with IDs 1006 to 4094. The switch stores the VLAN configuration data in the vlan.dat
file, which is in the flash memory. Extended VLANs are not stored in the vlan.dat file and need to
saved in the startup configuration.

In a switch stack, the whole stack uses the same running configuration and saved configuration, and
extended-range VLAN information is shared across the stack.

To create a VLAN, use the vlan vlan-id command. Optionally, assign it a name with the name vlan-
name command and exit the VLAN configuration.

CAT9000(config)# vlan 901

CAT9000(config-vlan)# vlan 2001

CAT9000(config-vlan)# name NOC

CAT9000(config-vlan)# exit

The creation of several VLANs with a single command is also supported by separating VLANs with
commas or using a hyphen to specify a range. A combination of comma separation and hyphen-
defined ranges can be used.

CAT9000(config)# vlan 2001-2049,3001-3049

CAT9000(config-vlan)# exit

CAT9000(config)#

CAT9000(config)# do show vlan id 2001

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

2001 VLAN2001 active

Note that the name command is not mandatory for a VLAN to be created and in fact could not be
used on a list or range of VLANs as the names must be unique. This way the VLANs will be created
with autogenerated names in VLANxxxx format, but it is best practice to have a meaningful VLAN
naming scheme.

If you want to block a VLAN on a specific switch, you should configure the shutdown command under
that VLAN. The shutdown state prevents any Layer 2 traffic on that VLAN on the configured switch
but does not affect the VLAN status on other switches in the network.

CAT9000(config)# vlan 2001

CAT9000(config-vlan)# shutdown

CAT9000(config-vlan)# exit

To delete a VLAN, use the no vlan vlan-id command in configuration mode.

CAT9000(config)#

CAT9000(config)# no vlan 2001

CAT9000(config)#

Configuring VLANs on Cisco NX-OS Software

Just as on Cisco IOS XE Software, enter global configuration mode to configure a VLAN and create the
VLAN using vlan vlan-id. Optionally, assign it a name with the name vlan-name command and exit
the VLAN configuration. Again, the creation of several VLANs with a single command is supported.
After a VLAN is created, you can modify its name and state (active/suspended) and use the shutdown
command.

NX9000(config)# vlan 100

NX9000(config-vlan)# name Sales

NX9000(config-vlan)# exit

NX9000(config)#

NX9000(config)# vlan 200-220,230,240

NX9000(config-vlan)# exit

NX9000(config)#
NX9000(config)# vlan 100

NX9000(config-vlan)# state active

NX9000(config-vlan)#

NX9000(config-vlan)# shutdown

NX9000(config-vlan)# exit

VLAN Ranges and Default Settings on Cisco NX-OS Software

In Cisco NX-OS, VLANs are divided into different ranges, each with a different role and properties:

VLAN 1 is reserved as the default VLAN, and you cannot delete or alter it. By default, all interfaces
are assigned to VLAN 1.

VLANs in the range from 2 to 1005 are referred to as normal VLANs and can be created, deleted, and
suspended freely.

VLANs in the range from 1006 to 3967 are referred to as extended VLANs. They can also be created
or deleted, but extended VLANs are always active by default and cannot be suspended or shutdown.

VLANs 3968 to 4095 are, by default, internally allocated by the Cisco NX-OS system for specific
features, such as diagnostics or multicast routing. These VLANs cannot be used for general purposes.
You can reconfigure the reserved VLAN range to a different consecutive group of 128 VLANs by using
the system vlan reserve command. This change takes effect after you save the configuration and
reload the switch.

You can reconfigure the reserved VLAN range to a different consecutive group of 128 VLANs by using
the system vlan reserve command. This change takes effect after you save the configuration and
reload the switch.

Configuring VLANs on Cisco IOS XR Software

Cisco IOS XR Software is predominantly used in service provider routers featuring a suite of Layer 2
over Layer 3 services such as Pseudowire, E-Tree, and Virtual Private LAN Services (VPLS). However,
like in Cisco IOS XE routers, there is no support switch ports for traditional Layer 2 switching, so there
is no way to directly create VLANs. To handle such Layer 2 services on Cisco IOS XR Software, you can
use IRB which is not covered in this course.
Answer

The correct answer is Layer 2 traffic on that VLAN is blocked. The shutdown state prevents any Layer
2 traffic on that VLAN on the switch. The answer The selected VLAN is deleted from the switch is
incorrect because the VLAN is still configured on the switch once the command is executed. The
answer The VLAN is removed from the vlan.dat file is incorrect because the VLAN is still present in
the VLAN database once the command is executed. The answer Shutdown command is not allowed
when configuring a VLAN is incorrect, because shutdown command in VLAN configuration mode is
valid.

Layer 2 Interface Configuration

Layer 2 interface configuration on Cisco IOS XE, Cisco IOS XR, and Cisco NX-OS platforms allows for
flexible and scalable network design, each with its own unique but also some common approaches to
switching. While the Cisco IOS XE switches are primarily used in enterprise environments and Cisco
NX-OS switches in data centers, they both support traditional switching. The Cisco IOS XR routers
focus more on service provider environments with advanced Layer 2 transport services.

Port Types on Cisco IOS XE Software

On Cisco IOS XE switches (for example, Catalyst 9200 switches) several port types are supported,
each with its own role and configuration.

The port types are:

Switch ports: These are the most common and the default port type configuration on Cisco IOS XE
switches. Switch ports are Layer 2 interfaces that handle Ethernet frames and manage Layer 2
protocols, such as the Spanning Tree Protocol (STP) and the Dynamic Trunking Protocol (DTP). These
ports are not involved in routing; instead, they switch traffic within VLANs.

Access ports:

Function: Assigned to a single VLAN and carry untagged traffic.

Usage: Commonly used to connect endpoint devices.

Behavior: Drop any tagged traffic they receive, ensuring that only untagged traffic is forwarded.

Configuration: In specific setups, such as those involving IP phones, an access port can be configured
to carry both voice and data traffic on separate VLANs. For example, a tagged voice VLAN for the
phone and a data VLAN for devices connected to the phone.

Trunk ports:

Function: Allow traffic from multiple VLANs on a single interface.

Usage: Typically used for connectivity between network devices.

Behavior: By default, trunk ports are members of all VLANs in the VLAN Trunking Protocol (VTP)
database.

Configuration: You can restrict their VLAN membership by configuring an allowed VLAN list.

Tunnel Ports:

Function: Primarily used in service provider environments.

Usage: Use 802.1Q tunneling, also known as queue-in-queue (QinQ), to add an extra layer of tagging
(metro tag) to ensure that customer VLANs remain isolated within the provider's infrastructure.
Configuration: To configure a tunnel port, use the switchport mode dot1q-tunnel command on the
interface.

Routed Ports:

Function: Operate at Layer 3, unlike switch ports.

Usage: Function similar to traditional router interfaces.

Behavior: A routed port does not support 802.1Q VLAN tagging.

Configuration: To configure a routed port, apply the no switchport command, converting the
interface from Layer 2 to Layer 3 mode, allowing the assignment of IP addresses.

Configuring Layer 2 Interface on Cisco IOS XE Software

In Cisco IOS XE, switch ports can be configured as either access or trunk ports. The following are
examples for configuring both types of ports.

Use the following commands to configure an access port:

interface GigabitEthernet1/0/1

switchport mode access

switchport access vlan 10

no shutdown

Note

An access port is a Layer 2 interface that is assigned to a single VLAN. It carries traffic for only one
VLAN and does not tag the traffic with a VLAN ID.

In the previous configuration example, the following commands are used:

switchport mode access: Configures the port in access mode.

switchport access vlan 10: Assigns the port to VLAN 10.

no shutdown: Activates the interface.

Use the following commands to configure a trunk port:

interface GigabitEthernet1/0/2

switchport mode trunk

switchport trunk native vlan 10

switchport trunk allowed vlan 10,20-30

no shutdown

Note

A trunk port is a Layer 2 interface that carries traffic for multiple VLANs. It tags the traffic with a VLAN
ID to identify the VLAN to which the traffic belongs.

In the previous configuration example, the following commands are used:

switchport mode trunk: Configures the port in trunk mode.

switchport trunk native vlan 10: Defines that any untagged traffic on this port will be associated with
VLAN 10. The native VLAN must also be in the allowed VLANs list.

switchport trunk allowed vlan 10,20-30: Defines an explicit list of allowed VLANs on this trunk. VLANs
are separated by commas, and a hyphen can be used to specify a range of VLANs

Note

Cisco IOS XE routers, such as for example the Cisco ISR 1000 router, use routed ports, which are Layer
3 interfaces that do not support switchport mode like the Cisco IOS XE switch counterparts. Although
configuring traditional trunk or access ports is not possible, Layer 2 transport services are still
supported using IRB which is not covered in this course.

Configuring Layer 2 Interface on Cisco IOS XR Software

A physical interface on a Cisco IOS XR device is automatically detected when the line card is inserted
into the chassis. By default, the interface is in no shutdown state and has no IP address configured.

interface GigabitEthernet 0/0/0/0

description Physical-interface

Because Cisco IOS XR does not support switch ports and VLANs for traditional Layer 2 switching, no
access or trunk switched ports can be configured. In cases where dot1q VLAN segregation is needed,
subinterfaces are used. A subinterface is defined by a number between 0 and 2147483647 and
represents a logical subdivision of a physical interface. You can configure a subinterface with a
specific VLAN ID for 802.1Q encapsulation.

interface GigabitEthernet 0/0/0/0.100

description VLAN-100-Subinterface

encapsulation dot1q 100

In the previous example, a subinterface 100 is configured using the interface physical-
interface.subinterface-id command. VLAN 100 is configured using the encapsulation dot1q vlan-id
command. The subinterface number does not need to be identical as the VLAN ID but to avoid
confusion, it is best practice that they match.

The previous subinterface configuration by itself does not serve a specific function. However, with
additional configuration it could be used as a Layer 3 interface for example.

Note

IOS XR can be configured for Layer 2 Transport services (l2transport), but the specific configurations
are not covered in this course.

Configuring Layer 2 Interface on Cisco NX-OS Software

Depending on the platform, the ports on a Cisco NX-OS switch may be in Layer 2 or Layer 3 mode by
default:

Cisco Nexus 9300-EX switches: All ports are Layer 3 ports by default.

Cisco Nexus 9300 switches: All ports are Layer 2 ports by default.
To verify the mode that the ports are using, use the show interface status command. The following is
an example output:

NX9000# show interface status

--------------------------------------------------------------------------------

Port Name Status Vlan Duplex Speed Type

--------------------------------------------------------------------------------

Eth1/1 -- connected 10 auto auto 10g

Eth1/2 -- connected trunk full 1000 10g

Eth1/3 -- connected 1 full 1000 10g

Eth1/4 -- connected routed auto auto 10g

Eth1/5 -- connected routed auto auto 10g

Eth1/6 -- connected routed auto auto 10g

From the output, you can identify ports:

Layer 2 (switched) ports: Identified by the vlan tag or trunk keyword under the VLAN column

Layer 3 (routed) ports: Identified by the routed keyword under the VLAN column

The configuration of switched ports on NX-OS is similar to the configuration on Cisco IOS XE
Software.

interface ethernet 1/1

switchport mode access

switchport access vlan 10

no shutdown

In the configuration example, Ethernet interface 1/1 is configured as an access port using the
following commands:

switchport mode access: Configures Ethernet interface 1/1 as an access port.

switchport access vlan 10: Assigns VLAN 10 to this access port.

no shutdown: Brings up the interface.

Following is an example of configuring an Ethernet interface as a trunk port:

interface ethernet 1/2

switchport mode trunk

switchport trunk native vlan 10

switchport trunk allowed vlan 10,20-30

no shutdown

In the configuration example, Ethernet interface 1/2 is configured as a trunk port using the following
commands.

switchport mode trunk: Configures Ethernet interface 1/2 as a trunk port.

switchport trunk native vlan 10: Configures VLAN 10 as the native VLAN for this trunk. Any untagged
traffic on this port will be associated with VLAN 10.

switchport trunk allowed vlan 10,20-30: Configures the port to forward traffic for VLANs 10 and 20
through 30. The native VLAN must also be in the allowed VLANs list.

no shutdown: Brings up the interface.

EtherChannel Configuration

An EtherChannel bundles multiple physical interfaces into one logical interface, providing benefits
such as failover and a single configuration point and improving redundancy and load balancing. Link
Aggregation Control Protocol (LACP) is supported across all three Cisco IOS operating systems with a
similar configuration structure.

On Cisco IOS XE Software, a port-channel can be configured for switch ports, tunnel ports, and
routed ports.

interface port-channel 1
switchport

interface GigabitEthernet1/0/1

channel-group 1 mode active

interface GigabitEthernet1/0/2

channel-group 1 mode active

In the configuration example, two physical interfaces GigabitEthernet1/0/1 and GigabitEthernet1/0/2

are bundled into Port-channel 1 using active LACP mode.

On Cisco NX-OS Software, the configuration of EtherChannel is very similar to the configuration on
Cisco IOS XE Software. However, the feature lacp command is mandatory beforehand to enable LACP
on the device.

feature lacp

interface port-channel 1

switchport

interface ethernet 1/1

switchport

channel-group 1 mode active

interface ethernet 1/2

switchport

channel-group 1 mode active

In the configuration example, interfaces ethernet 1/1 and ethernet 1/2 are bundled into port-
channel 1 using active LACP mode.

On Cisco IOS XR Software, the configuration of EtherChannel is also similar but uses the bundle id
keyword instead of channel-group and the logical interface is called Bundle-Ether instead of port-
channel.
interface Bundle-Ether 1

description Bundle-Ether1

interface GigabitEthernet 0/0/0/1

description Bundle-Ether1-Link1

bundle id 1 mode active

no shutdown

interface GigabitEthernet 0/0/0/2

description Bundle-Ether1-Link2

bundle id 1 mode active

no shutdown

In the configuration example, Bundle-Ether1 is a logical interface that aggregates two physical
interfaces, GigabitEthernet 0/0/0/1 and GigabitEthernet 0/0/0/2, using active LACP mode

Answer

The correct answer is switchport mode trunk. You should use this command to configure a port as a
trunk, which allows it to carry traffic for multiple VLANs. The answer switchport mode access is
incorrect because it configures the port as an access port, which supports a single VLAN. The answer
switchport access vlan 10 is incorrect because is related to assigning a VLAN to an access port. The
answer no switchport is incorrect because you should use it to convert a port to a routed port, not
configure a trunk.
Configure Layer 2 Interfaces and VLANs
Configure VLANs
Step 1
Show Me
Access the Cisco Modeling Labs WebUI. To access Cisco Modeling Labs
running in your lab environment, open a web browser on your student PC
and navigate to https://10.1.1.20 or click the Cisco Modeling
Labs bookmark.
Step 2
Show Me
Log in to access the main dashboard.

Use the following credentials:

 Username: student
 Password: 1234QWer
Step 3
Show Me
Click the Configure Layer 2 Interfaces and VLANs topology to get to the
Workbench.
Step 4
Show Me
Review the network topology in the Workbench. Take note of the present
devices and their configured addresses.
Step 5
Show Me
Check all devices in the topology and ensure they have fully booted before
proceeding with the lab steps or accessing the console. Attempting to
interact with a device that has not fully booted may interrupt the boot
process. Wait for a green checkmark to appear next to each node,
indicating that it is ready.
Step 6
Show Me
Access the console of the NX-OS 9000 switch by right-clicking the node
and choosing Console.
Step 7
Show Me
In the pane at the bottom, click the OPEN CONSOLE button.
Step 8
Show Me
Log in to the device.

Use the following credentials:

 Username: cisco
 Password: cisco123
Step 9
Show Me
Examine the status of the interfaces and review their configurations.
Step 10
Show Me
Access the console of desktop-1 and attempt to ping all other desktop
devices.

Use the following credentials:

 Username: cisco
 Password: cisco123
Step 11
Show Me
Return to the console of your NX-OS 9000 device and create two VLANs:
one named SALES with a VLAN ID of 100 and another named IT with a
VLAN ID of 200.
Step 12
Show Me
Assign the newly created VLANs to interfaces; assign VLAN
SALES to desktop-1 and VLAN IT to desktop-2.
Step 13
Show Me
From desktop-1 try to ping desktop-2 again.
Step 14
Show Me
Open the console of your CAT9000v device and create two VLANs: one
named SALES with a VLAN ID of 100 and another named IT with a VLAN
ID of 200. Assign desktop-3 to the IT VLAN and desktop-4 to
the SALES VLAN.
Step 15
Show Me
From desktop-1 try to ping desktop-4.

Configure Trunk Ports

Step 16
Show Me
Configure trunk ports to enable VLAN communication between the
switches. Start by setting up the trunk on the NX-OS 9000.
Step 17
Show Me
Configure the trunk port on the CAT9000v.

Verify VLANs
Step 18
Show Me
Verify that desktop-1 can ping desktop-4, which is in the same VLAN.
Step 19
Show Me
Verify that desktop-1 cannot ping devices in other VLANs because they
are not in the same VLAN.
Step 20
Show Me
Verify that desktop-2 can only ping desktop-3.

Use the following credentials:

 Username: cisco
 Password: cisco123
Step 21
Show Me
Optionally, check the interface status on both switches.
Step 22
Show Me
Check the VLANs on both switches.
Step 23
Show Me
Check the trunk ports on both switches.

Answer

The correct answer is To allow multiple VLANs to communicate over a single physical link. Trunk ports
are essential for enabling VLAN traffic between switches, allowing multiple VLANs to share the same
physical connection. The option To assign multiple IP addresses to a single interface is incorrect
because trunking does not involve IP address configuration. The option To increase the speed of data
transmission on a single VLAN is incorrect because trunking does not inherently increase data
transmission speed. The option To enable broadcast storm control on the network is incorrect
because trunk configuration is unrelated to broadcast storm control.

Layer 3 Interface Configuration

Layer 3 interfaces are used to route IP traffic between different networks. Here you will explore Layer
3 interface configurations across Cisco IOS XE, Cisco IOS XR, and Cisco NX-OS platforms, focusing on
Switch Virtual Interfaces (SVIs), routed ports, and subinterfaces. Although all three operating systems
support Layer 3 interfaces, there are key differences in their configurations and capabilities.

Configuring Layer 3 Interfaces on Cisco IOS XE and NX-OS Software

In Cisco IOS XE and Cisco NX-OS software, there are three common types of Layer 3 interfaces: switch
virtual interfaces (SVIs), routed ports, and subinterfaces. Each type serves a specific purpose in
network design and configuration.
An SVI is a Layer 3 interface that is associated with a VLAN. It allows routing between VLANs and
provides Layer 3 functionality to VLANs that are defined on the switch. SVIs are used extensively in
VLAN-based networks where inter-VLAN routing is required without the need for an external router.
An SVI is commonly referred to as interface VLAN.

interface Vlan20

ip address 192.168.20.1 255.255.255.0

In the example, you can see the following commands:

The interface Vlan20 command specifies the SVI for VLAN 20, allowing it to perform Layer 3 routing.
Each VLAN requires a corresponding SVI to enable inter-VLAN routing.

The ip address 192.168.20.1 255.255.255.0 command assigns an IP address to the SVI. This address
usually acts as the default gateway for clients in that VLAN.

A routed port on a switch is a physical interface that is configured to operate at Layer 3, acting
similarly to a port on a router.

interface GigabitEthernet1/0/1

no switchport

ip address 192.168.10.1 255.255.255.0

In the example, you can see the following commands:

The no switchport command converts the interface into a Layer 3 routed port.

The ip address 192.168.10.1 255.255.255.0 command assigns an IP address and subnet mask to the
port, enabling it to route traffic at Layer 3.

Subinterfaces with dot1q VLAN tagging can be supported on Cisco IOS XE Software, depending on
switch capabilities. For example, the Cisco Catalyst 9600 series switches support VLAN tagging on
routed ports and EtherChannel interfaces, whereas the Cisco Catalyst 9300 series switches do not.
Subinterfaces with dot1q VLAN tagging are also supported on Cisco NX-OS switches.

interface HundredGigabitEthernet 1/0/33

no switchport

no ip address

exit

interface HundredGigabitEthernet 1/0/33.201

encapsulation dot1q 201

ip address 10.10.10.11 255.255.255.0

end

In this example, you can see the following:

A subinterface is configured on a routed port with dot1q VLAN 201 on a Cisco Catalyst 9600 series
switch.

The encapsulation dot1q 201 specifies the VLAN tagging.

The ip address 10.10.10.11 255.255.255.0 command assigns an IP address to the subinterface.

The same configuration syntax can be used to configure a dot1q subinterface on a port-channel
interface. Subinterfaces can be configured similarly on Cisco IOS XE routers.

Configuring Layer 3 Interfaces on Cisco IOS XR Software

Cisco IOS XR routers do not support traditional switched interfaces. Instead, Layer 3 interfaces are
configured on physical interfaces and subinterfaces.

Layer 3 interfaces on physical interfaces do not use a dot1q VLAN encapsulation, meaning the traffic
is untagged. The following is an example of configuring a Layer 3 interface on a physical port:

interface GigabitEthernet0/0/0/0

ipv4 address 192.168.1.1 255.255.255.0

Subinterfaces can use dot1q VLAN tags to segregate traffic. In the next example, a Layer 3 logical
subinterface with a dot1q encapsulation 100 is configured, so the traffic is tagged with VLAN 100.

interface GigabitEthernet0/0/0/0.100
encapsulation dot1q 100

ipv4 address 192.168.100.1 255.255.255.0

Other Layer 3 Interfaces

On Cisco IOS XE, Cisco IOS XR, and Cisco NX-OS platforms, several other types of Layer 3 interfaces
can be configured with a wide range of roles and purposes. Some of these interfaces are Loopback
interfaces, Tunnel interfaces, Null interfaces, and Unnumbered interfaces among others.

The most versatile Layer 3 interfaces are Loopback interfaces. They are virtual interfaces that are
considered stable because they are not tied to a physical port or other entity, so they are always in
an "up" state as long as the router is operational. Loopback interfaces are commonly used for router
identification, management purposes, and as stable endpoints for protocols like Open Shortest Path
First (OSPF), BGP, and MPLS.

interface Loopback0

ip address 10.0.0.1 255.255.255.255

Answer

The correct answer is Use the no switchport command. This answer is correct because the command
converts a physical interface into a Layer 3 routed port, which enables it to route traffic. The answer
Configure an SVI associated with a VLAN is incorrect. It pertains to SVIs, not routed ports. The answer
Assign multiple IP addresses to the interface is incorrect because assigning multiple IP addresses
does not change the interface type. The answer Enable VLAN encapsulation on the interface is
incorrect. This action is relevant to subinterfaces, not the conversion of a physical interface to a
routed port.

Virtual Routing and Forwarding Configuration

Here you will learn about Standard Virtual Routing and Forwarding (VRF) and VRF Lite support on
Cisco IOS XE, Cisco NX-OS, and Cisco IOS XR platforms. You will learn the role of each VRF type and
discover the similarities and differences in configuration for each platform.

Virtual Routing and Forwarding

VRF allows multiple routing tables to exist on the same physical device, enabling network
segmentation and isolation without additional hardware. This capability is crucial for creating
isolated network environments with a single physical infrastructure.

There are two distinct types of VRFs, each with a key difference:

Standard VRFs (MPLS VPN VRFs):

Usage: Primarily used in service provider environments to create Layer 3 VPNs for customers.

Mechanism: Utilizes Multiprotocol BGP (MP-BGP) to propagate routing information across a shared
infrastructure.

Configuration: Requires a more complex MP-BGP configuration.

Multi-VRF Customer Edge (CE) or VRF Lite:

Usage: More suited for enterprise networks.

Mechanism: Provides the benefits of VRFs but is limited to the local device without the added
complexity of MPLS.

Configuration: Simplified and does not require MPLS.

Note

Cisco IOS XE, Cisco IOS XR, and Cisco NX-OS platforms all support configuration for both VRF Lite and
standard VRFs. However, availability on individual devices may depend on device capability, licensing
and software versions.
The following are VRF defining parameters:

VRF name: A locally significant administrative name used to reference a specific VRF in the
configuration.

Route Distinguisher (RD): A locally unique identifier that is used by the routing process to distinguish
between routes in VRFs. Within a service provider network for example, two customers can have the
exact same route, and the RD is used to make each route unique. RD is written in X:Y format. It is
typically defined using a combination of an autonomous system (AS) number and a locally significant
value, for example, 5603:1001.

Route Target (RT): A BGP attribute attached to routes and used to control the import and export of
routes between VRF instances across different routers. This is mandatory in MPLS VRF configurations.

VRF name and RD are of local significance, so they can vary between devices. However, it is best
practice to maintain their consistency across the network for the same routing domain.

Configuring VRFs on Cisco IOS XE Software

Configuring Multi-VRF Cisco IOS XE Software contains two basic steps: defining the VRF and
associating interfaces with the VRF.

Enable IP routing: Ensure that IP routing is enabled on the device. This is required on Cisco IOS XE
switches that have routing disabled by default.

Define the VRFs: Define the VRFs using the ip vrf vrf-name command. Each VRF must have a unique
RD specified using the rd rd command.

Associate interfaces with VRFs: Associate each interface with its respective VRF using ip vrf
forwarding vrf-name command under the interface configuration. Notice that both interfaces have
the same IP address configured, but because they are in different VRFs, they are not duplicated.

Configure Static Routes for Each VRF: Configure static routes for each VRF using the ip route vrf vrf-
name command. This configuration ensures that each VRF has its own routing table.

The following configuration creates two VRFs named CUST01 and CUST02:
ip routing

ip vrf CUST01

rd 100:1

ip vrf CUST02

rd 100:2

interface Gi1

ip vrf forwarding CUST01

ip address 192.168.1.254 255.255.255.0

interface Gi2

ip vrf forwarding CUST02

ip address 192.168.1.254 255.255.255.0

ip route vrf CUST01 10.0.0.0 255.255.255.0 Gi1 192.168.1.1

ip route vrf CUST02 10.0.0.0 255.255.255.0 Gi2 192.168.1.1

Configuring VRFs on Cisco NX-OS Software

The configuration of VRFs on Cisco NX-OS is slightly different from Cisco IOS XE. The steps for
configuring VRFs on a Cisco NX-OS switch are as follows:

Define the VRF context:

Use the vrf context vrf-name command to define a VRF.

Configure routes inside the VRF context definition.

Associate interfaces with the VRF:

Use the vrf member vrf-name command under the interface configuration mode to associate the
interface with the VRF.
In the following example, the vrf context vrf-name command is used to define a VRF. Notice that
routes are configured inside the VRF context definition. The interfaces are associated with the VRF
using the vrf member vrf-name command under the interface.

vrf context CUST01

ip route 10.0.0.0/24 Eth1/1 192.168.1.1

vrf context CUST02

ip route 10.0.0.0/24 Eth1/1 192.168.1.1

interface Eth1/1

no switchport

vrf member CUST01

ip address 192.168.1.254/24

interface Eth1/2

no switchport

vrf member CUST02

ip address 192.168.1.254/24

Configuring VRFs on Cisco IOS XR Software

VRF configuration on Cisco IOS XR is similar to Cisco IOS XE Software, containing the same elements
but with a slightly different syntax.

The following is a step-by-step guide to configuring a VRF, assigning an interface to it, and setting up
a static route:

Create the VRF: Create the VRF instance and specify the RD. The address-family ipv4 unicast
command is mandatory to enable routing for this VRF.

Assign the interface to the VRF: Assign an interface to the VRF and configure its IP address.
Configure the static routes: Configure static routes under the router static configuration mode. This
involves specifying the VRF and then defining the static route within the address-family ipv4 unicast
submode.

vrf CUST01

rd 100:1

address-family ipv4 unicast

exit-address-family

interface GigabitEthernet0/0/0/1

vrf CUST01

ipv4 address 192.168.1.254 255.255.255.0

router static

vrf CUST01

address-family ipv4 unicast

10.0.0.0 255.255.255.0 GigabitEthernet0/0/0/1 192.168.1.1

exit-address-family

In this example, a single VRF and the belonging interface are configured like in the previous
examples. The VRF is created using the vrf vrf-name command and the address-family ipv4 unicast
command is mandatory to enable IPv4 routing for this VRF. The interface configuration is similar, and
the static route is configured under router static configuration mode, followed by vrf vrf-name. The
static route itself is specified under the address-family ipv4 unicast configuration submode.
Answer

The correct answer is Enable Layer 3 VPNs for customers in service provider environments. This
answer is correct because Standard VRFs are primarily utilized in service provider environments to
create Layer 3 VPNs. They use MP-BGP to propagate routing information across shared
infrastructure. The answer Provide isolated network environments within a single enterprise network
is incorrect because it aligns with VRF Lite usage. The answer Simplify the routing process in small
office networks is incorrect because it not applicable to Standard VRFs, which involve complex MP-
BGP configurations. The answer Enhance wireless communication capabilities in data centers is
incorrect because it is unrelated to the primary purpose of Standard VRFs.

First Hop Redundancy Protocols Configuration

Here you will learn about the configuration of Hot Standby Router Protocol (HSRP) and Virtual Router
Redundancy Protocol (VRRP) used for network gateway high availability and redundancy across Cisco
IOS XE, Cisco NX-OS, and Cisco IOS XR platforms. You will learn how the configuration of both
protocols is similar across all platforms and what parts of the configurations are platform-specific.

HSRP and VRRP

HSRP and VRRP are both protocols designed to provide high availability by enabling two or more
routers to share a virtual IP address in the same Layer 2 domain. This ensures that if one router fails,
another can take over, providing uninterrupted service.

The main characteristics of HSRP and VRRP are as follows:

HSRP: A Cisco proprietary protocol that enables multiple routers to appear as a single virtual router,
providing network redundancy and high availability within a LAN. It is specific to Cisco devices and
allows for seamless failover if the active router fails.
VRRP: An open standard protocol that also offers router redundancy by allowing multiple routers to
share a virtual IP address. Unlike HSRP, VRRP is vendor-neutral, enabling interoperability between
different manufacturers' devices.

Configuring HSRP and VRRP on Cisco IOS XE Software

On Cisco IOS XE Software, HSRP and VRRP are configured directly on Layer 3 interfaces.

HSRP provides high network availability by configuring a virtual IP address that is shared among a
group of routers. The router with the highest priority becomes the active router.

The following are details for the Router A and Router B configuration:

The virtual IP address is set using the standby group-id ip ip-address command.

Router A is given a higher priority (120) using the standby group-id priority priority command,
making it the active router.

Router A:

interface Gi4

ip address 192.168.1.2 255.255.255.0

standby 1 ip 192.168.1.1

standby 1 priority 120

Router B:
interface Gi4

ip address 192.168.1.3 255.255.255.0

standby 1 ip 192.168.1.1

VRRP is similar to HRRP but uses different keywords. The configuration is almost identical, with the
standby keyword replaced with vrrp.

The following are details for the Router A and Router B configuration:

The virtual IP address is set using the vrrp group-id ip ip-address command.

Router A is given a higher priority (120) using the vrrp group-id priority priority command, making it
the primary virtual router.

Router A:

interface Gi4

ip address 192.168.1.2 255.255.255.0

vrrp 1 ip 192.168.1.1

vrrp 1 priority 120

Router B:

interface Gi4

ip address 192.168.1.3 255.255.255.0

vrrp 1 ip 192.168.1.1

Configuring HSRP and VRRP on Cisco NX-OS

HSRP and VRRP on Cisco NX-OS is also configured directly on Layer 3 interfaces and is very similar to
the Cisco IOS XE configuration. Keep in mind that both protocols must be enabled using the feature
hsrp and feature vrrp command in the global configuration mode.

configure terminal
confeature hsrp

feature vrrp

When configuring HSRP on Cisco NX-OS, there are two small differences compared to Cisco IOS XE
Software:

Using the hsrp group-id command: Use the hsrp group-id command instead of standby group-id
under the interface configuration mode.

HSRP configuration submode: After entering the hsrp group-id command, you enter the HSRP
configuration submode where you can set the virtual IP address and priority using the ip ip-address
and priority priority commands.

Switch A:

interface Ethernet1/1

no switchport

ip address 192.168.1.2/24

hsrp 1

ip 192.168.1.1

priority 120

Switch B:

interface Ethernet1/1

no switchport

ip address 192.168.1.3/24

hsrp 1

ip 192.168.1.1

The VRRP configuration is very similar to the HSRP configuration on Cisco NX-OS, except that the hsrp
configuration keyword is replaced with vrrp.

Switch A:
interface Ethernet1/1

no switchport

ip address 192.168.1.2/24

vrrp 1

address 192.168.1.1

priority 120

Switch B:

interface Ethernet1/1

no switchport

ip address 192.168.1.3/24

vrrp 1

address 192.168.1.1

Configuring HSRP and VRRP on Cisco IOS XR

In contrast to Cisco IOS XE and Cisco NX-OS platforms, the HSRP and VRRP configurations on Cisco
IOS XR are not configured directly on the Layer 3 interfaces but in a different configuration mode.

Do the following to configure HSRP on Cisco IOS XR Software:

Use the router hsrp command to enter the HSRP configuration mode.

Define the interface with the interface interface command.

Enter the address family with the address-family ipv4 command.

Configure the HSRP group with the hsrp group-id command.

Set the virtual IP address with the address ip-address command.

Set the priority with priority priority command.

Note

The inteface interface command defines the interface that the HSRP process will run on.

Router A:

interface GigabitEthernet0/0/0/4

ipv4 address 192.168.1.2 255.255.255.0

router hsrp

interface GigabitEthernet0/0/0/4

address-family ipv4

hsrp 1

address 192.168.1.1

priority 120

Router B:

interface GigabitEthernet0/0/0/4

ipv4 address 192.168.1.3 255.255.255.0

router hsrp

interface GigabitEthernet0/0/0/4

address-family ipv4

hsrp 1

priority 120

address 192.168.1.1

The VRRP configuration is, again, almost identical to the HSRP configuration on Cisco IOS XR, except
that the hsrp configuration keyword is replaced with vrrp.

Router A:
interface GigabitEthernet0/0/0/4

ipv4 address 192.168.1.2 255.255.255.0

router vrrp

interface GigabitEthernet0/0/0/4

address-family ipv4

vrrp 1

address 192.168.1.1

priority 120

Router B:

interface GigabitEthernet0/0/0/4

ipv4 address 192.168.1.3 255.255.255.0

router vrrp

interface GigabitEthernet0/0/0/4

address-family ipv4

vrrp 1

priority 120

address 192.168.1.1
Answer

The correct answer is A Cisco proprietary protocol that ensures network redundancy and high
availability within a LAN. This answer is correct because HSRP is designed by Cisco to provide
redundancy by allowing multiple routers to appear as a single virtual router. The answer An open
standard protocol that enables multiple routers to share a virtual IP address for redundancy is
incorrect because it describes VRRP, not HSRP. The answer A protocol that configures security
settings on routers is incorrect because HSRP is not related to security settings. The answer A
protocol used to manage bandwidth allocation in a network is incorrect because HSRP is not involved
in bandwidth management.

Routing Protocols Configuration

Routing protocols such as Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing
Protocol (EIGRP), and Border Gateway Protocol (BGP) are a cornerstone in any network and are
supported on all Cisco platforms. This topic focuses on OSPFv2, highlighting differences in syntax,
process management, and interface configuration.

Dynamic Routing Protocols

Dynamic routing protocols are used in networks to automatically adjust to topology changes and
optimize routing paths without manual intervention. These protocols enable routers to exchange
routing information and make real-time decisions on the best paths for data transmission.
Cisco IOS XE, Cisco NX-OS, and Cisco IOS XR platforms each support a wide range of routing protocols
suited for different networking environments. The following is a comparison of the focus and
configuration methods for OSPF on these platforms.

OSPF Configuration

Configuring OSPF on Cisco IOS XE Software

In Cisco IOS XE Software, there are two primary methods for configuring OSPF on a router:

Configuring OSPF directly on an interface

Using the network statement within the OSPF process configuration

Both methods can be used to achieve the same outcome, but they differ in terms of automation and
configuration granularity.
The first method—configuring OSPF directly on an interface—involves explicitly binding the interface
to an OSPF process and assigning it to an area. The ip ospf process-id area area-id command is used
for this purpose.

interface GigabitEthernet1

ip vrf forwarding CUST01

ip address 192.168.10.1 255.255.255.0

ip ospf 10 area 0

router ospf 10 vrf CUST01

router-id 10.0.0.1

In the example, observe the following:

The ip ospf process-id area area-id command binds the interface to OSPF process 10 and assigns it to
area 0. The area designation can be specified either in decimal format, as shown here, or in dotted
decimal format.

The router-id 10.0.0.1 command manually configures the router ID. If not manually configured, the
router ID is automatically chosen from the highest IP address on available loopback interfaces or the
highest IP address of any other physical interface.

When OSPF is configured directly on an interface, the network command is not required in the router
OSPF configuration mode. It is common practice to manually configure the router ID, otherwise the
router ID is automatically chosen from the highest IP address on available loopback interfaces or the
highest IP address of any other physical interface.

The second method—using the network statement within the OSPF process configuration—uses the
network statement to specify a range of IP addresses that should be included in the OSPF process.
When an interface's IP address falls within the specified range, OSPF is automatically enabled on that
interface.

interface GigabitEthernet1

ip vrf forwarding CUST01

ip address 192.168.10.1 255.255.255.0

router ospf 10 vrf CUST01

router-id 10.0.0.1

network 192.168.10.0 0.0.0.255 area 0

In this example, the network ip wildcard-mask area area-id statement in the OSPF router
configuration mode specifies a range of IP addresses that should be included in the OSPF process.
When an interface's IP address falls within the specified range, OSPF is automatically enabled on that
interface.

Configuring OSPF on Cisco NX-OS Software

Configuring OSPF on Cisco NX-OS Software follows a slightly different syntax compared to Cisco IOS
XE Software.

Here are the key differences and steps for configuring OSPF on Cisco NX-OS:

Interface-level configuration: On Cisco NX-OS, the network command cannot be used under the OSPF
configuration mode to define OSPF participation. Instead, OSPF interface participation is configured
directly at the interface level.

Process tag: Unlike Cisco IOS XE Software where OSPF process IDs are numeric, Cisco NX-OS allows
the process tag to be descriptive with a name having up to 20 characters. This makes it easier to
identify multiple OSPF instances in large networks.

Area designation: The area designation on Cisco NX-OS can be specified either in decimal or in dotted
decimal format. However, the system always displays areas in the dotted decimal format. For
example, a configured decimal area 0 is displayed as 0.0.0.0 and a configured decimal area 256 is
displayed as 0.0.1.0.

The following example shows the interface configuration:

interface Ethernet1/1

no switchport

vrf member CUST01

ip address 192.168.10.1/24

ip router ospf CUST01-OSPF area 0.0.0.0

The following example shows the OSPF process configuration:

router ospf CUST01-OSPF

vrf CUST01

router-id 10.0.0.1

In these two configuration examples, you can see the following:

The OSPF process is configured with a custom process tag cust01-ospf.

The interface ethernet1/1 is configured to participate in the OSPF process cust01-ospf and is
assigned to area 0.0.0.0.

The OSPF process is associated with the virtual routing forwarding (VRF) cust01 and is assigned a
router ID of 10.0.0.1.

Configuring OSPF on Cisco IOS XR Software

The configuration of OSPF on Cisco IOS XR is again different than on the other platforms. No OSPF
commands are configured on the Layer 3 interface level, instead everything is configured under the
router ospf process configuration mode. Within it the VRF submode is configured using the vrf vrf-
name command. Here the router-id router-id is configured and an area is defined using area area-id,
which can be in decimal or dotted decimal format.

Unlike other platforms, OSPF configuration on Cisco IOS XR is done entirely under the router OSPF
process configuration mode. No OSPF commands are configured at the Layer 3 interface level. The
following are the steps to configure OSPF on Cisco IOS XR:

Enter the global configuration mode: configure

Enter the OSPF router configuration mode: router ospf process-id

Enter the VRF submode: vrf vrf-name

Configure the router ID: router-id router-id

Define the OSPF area: area area-id

Associate the interface with an OSPF area: interface type interface-path-id

Configure the network type: network point-to-point

Commit the configuration: commit

The following is an example configuration for an interface GigabitEthernet0/0/0/1 under VRF cust01
with an OSPF router ID of 10.0.0.1 and area 0.

interface GigabitEthernet0/0/0/1

vrf CUST01

ipv4 address 192.168.10.1 255.255.255.0

router ospf 1

vrf CUST01

router-id 10.0.0.1

area 0

interface GigabitEthernet0/0/0/1

network point-to-point
Answer

The correct answer is OSPF interface participation is configured directly at the interface level. This
answer is correct because Cisco NX-OS requires OSPF configuration to be done directly at the
interface level, unlike Cisco IOS XE, which can use the network command within the router process
configuration. The answer OSPF process IDs must be numeric like in Cisco IOS XE is incorrect because
Cisco NX-OS allows descriptive process tags. The answer The network command is used under the
OSPF configuration mode is incorrect because this command is not used in Cisco NX-OS for OSPF. The
answer The area designation cannot be in decimal format is incorrect because the area can be
specified in decimal format but is displayed in dotted decimal format.

Configure Layer 3 Interfaces and Routing

Configure Layer 3 interfaces
Step 1
Show Me
Access the Cisco Modeling Labs WebUI. To access Cisco Modeling Labs
running in your lab environment, open a web browser on your student PC
and navigate to https://10.1.1.20 or click the Cisco Modeling
Labs bookmark.
Step 2
Show Me
Log in to access the main dashboard.

Use the following credentials:

 Username: student
 Password: 1234QWer
Step 3
Show Me
Click the Configure Layer 3 Interfaces and Routing topology to get to the
Workbench.
Step 4
Show Me
Review the network topology in the Workbench. Take note of the present
devices and their networks.
Step 5
Show Me
Check all devices in the topology and ensure they have fully booted before
proceeding with the lab steps or accessing the console. Attempting to
interact with a device that has not fully booted may interrupt the boot
process. Wait for a green checkmark to appear next to each node,
indicating that it is ready.
Step 6
Show Me
Access the CAT8000V router console by right-clicking the node and
choosing Console.
Step 7
Show Me
In the bottom of the pane, click the OPEN CONSOLE button.
Step 8
Show Me
In the console, first enable the terminal with the enable command. Then
configure the IP address on all connected interfaces according to the given
topology.
Step 9
Show Me
Move to XRv 9000. Access it through the console and configure the
interfaces. After opening the console, press Enter to start the input
process.
Note
The interface path shown in the UI for this device is shortened. The full
path follows the format 0/0/0/X.
Step 10
Show Me
Open the console for the edge router IOSv-0 and configure the interface.
Step 11
Show Me
Open the console for the NX-OS 9000 switch and configure the interfaces.
Step 12
Show Me
Open the console for the CAT9000v switch and configure the interfaces.

Configure OSPF Routing

Step 13
Show Me
Return to the CAT8000V console and configure OSPF.
Step 14
Show Me
Configure OSPF on XRv 9000.
Step 15
Show Me
Configure OSPF on the NX-OS 9000 switch.
Step 16
Show Me
Configure OSPF on the CAT9000v switch and include the directly
connected network 192.168.6.0/30 in the OSPF configuration.

Configure Static Routing

Step 17
Show Me
On the CAT9000v, configure a default route for the 192.168.7.0/24 network
through 192.168.6.2, and redistribute it into the
existing OSPF configuration.
Step 18
Show Me
Create a default route on IOSv to CAT9000v.

Verify Connectivity Between Remote Networks

Step 19
Show Me
Open the console on NX-OS 9000 and review the available routes
and OSPF neighbors.
Step 20
Show Me
Try pinging devices that are not directly connected to verify end-to-end
connectivity.
Step 21
Show Me
Inspect the route a packet will take to reach 192.168.7.1 from NX-OS
9000 to verify OSPF and the created static route on the edge.
Step 22
Show Me
Stop a link on the packets route.
Step 23
Show Me
Wait a few seconds and inspect the route again.

Answer

The correct answer is router ospf. This command initiates the OSPF routing process on a router or
switch, enabling dynamic routing. The ospf start option is incorrect because it is not a valid Cisco IOS
command. The start ospf option is also incorrect, because it does not correctly start the OSPF
process. Last, the enable ospf option is incorrect because it does not exist as a command for
initiating OSPF.
Summary

Cisco IOS XE, Cisco NX-OS, and Cisco IOS XR operating systems are featured across a wide portfolio of
enterprise-, service provider-, and data center-oriented network equipment. Although each
operating system may have a different role or focus, they all share many common features and
protocols.

After completing this course, you will be able to address the following questions:

What is the difference between Telnet and SSH, and how is remote access handled across all three
operating systems?

How do VLAN types and their configurations compare, and what specifics or limitations are
associated with each platform?

What are the key differences in the capabilities of Layer 2 and Layer 3 interfaces, and how can similar
intent be configured using different approaches?

What is the purpose of VRF, what types exist, and how does its configuration and applicability differ
across operating systems?

What are the similarities and differences in the configuration of high availability protocols like HSRP
and VRRP and dynamic routing protocols like OSPF across the platforms?

Automation and Programmability

Introduction

Imagine you are an engineer who is part of a network team, responsible for managing a network of a
large multinational enterprise with many branch offices. This network is very dynamic and requires
weekly or sometimes even daily changes to device configurations. Due to the amount of relatively
simple, yet critical tasks you and your team need to perform, you probably find at least some degree
of network automation to be mandatory for efficient work. Through the automation of device
management, setup, and provisioning, you and your team can reduce errors and speed up the
deployment of changes to your network.

Cisco network device platforms running IOS XE, IOS XR, and NX-OS, use protocols such as Network
Configuration Protocol (NETCONF) and Representational State Transfer Configuration Protocol
(RESTCONF) to standardize and simplify resource management. Automation technologies that offer
strong foundations for Infrastructure as Code (IaC) and configuration management, such as Ansible
and Terraform, significantly increase productivity.

This course examines the importance of network automation using industry-standard technologies
and the evolution of network automation within Cisco platforms. It also explores the capabilities of
important protocols and useful applications that you can employ in your day-to-day work.
Evolution of Automation on Cisco Network
Devices
Network automation consists of using different software tools such as scripts and application
programming interfaces (APIs) to automate part of the network device lifecycle. You can automate
the provisioning, initial configuration, monitoring, and any additional Day 1 and Day 2 operation on
network devices.

The process of network automation can be as simple as automating device upgrades in a small, one-
branch office. But it can also be as complex as managing the entire lifecycle of a global network with
thousands of devices and diverse requirements. In today's dynamic and global networking landscape,
automation is essential for effective network management. It’s hard to justify dedicating network
engineers to possibly travel to the location, connect to the device, and manually change the
configuration each time a small network change is required in one of the hundreds of locations.

Automation reduces the amount of manual work that is required for operations tasks. It also
minimizes the number of errors (or at least makes them consistent, which facilitates
troubleshooting), and greatly improves deployment times of new devices.

As the image above depicts, network automation has come a long way since manual device
configuration. Cisco, a pioneer in networking technology, has integrated automation across its
network device platforms running Cisco IOS XE, IOS XR, and NX-OS operating systems. Each device
type is tailored to a specific network environment and supports multiple approaches in automation.
Cisco has also created some network automation tools, such as Cisco Network Services Orchestrator
(NSO), that have become the industry standard for network automation. As the demand for better
network scalability, programmability, and operational efficiency has grown, Cisco has continually
introduced new and advanced automation capabilities to meet these needs.

CLI Scripting

CLI was the initial method for managing Cisco or any other network devices. Administrators created
scripts to automate repetitive tasks such as device provisioning and interface configuration. The
scripts used SSH to directly connect to network devices, read the terminal output, and send the CLI
commands to the device. CLI scripts were an improvement but they were complex, hard to maintain,
and prone to errors, especially in large-scale networks. It was common for every OS upgrade on the
network devices to break most of the existing automation scripts.

These CLI scripts used the “expect” approach to automation. The script expected some terminal
output (that is “Enter your password:”), sent back the appropriate CLI command, and parsed the
resulting output again.

The following example shows an “expect” script using the Python pexpect module, which connects
to an IOS XR device, logs in, enters the privileged mode, and displays the version:

import pexpect

ssh_command = "ssh user@iosxr_device_ip"

child = pexpect.spawn(ssh_command)

child.timeout = 20

child.expect("Password:")

child.sendline("your_password")

child.expect(">")

child.sendline("enable")

child.expect("Password:")

child.sendline("your_enable_password")

child.expect("#")

child.sendline("show version")

child.expect("#")

print(child.before.decode("utf-8"))

child.sendline("exit")
child.expect(pexpect.EOF)

Such a script can be executed locally on your workstation or as a part of a broader automation
process. When the script is saved as get_version.py and executed locally, the output looks like the
following. The lines that the script sends to the device are highlighted.

~/ python get_version.py

ssh user@iosxr_device_ip

Password: ********

>

enable

Password: ********

show version

Cisco IOS XR Software, Version 7.2.1

Copyright (c) 2019 by Cisco Systems, Inc.

ROM: System Bootstrap, Version 1.0(20180401:172702) [xr-admin 1.0 (Test)]

cisco ASR9000 (RSP880) processor with 4194304K bytes of memory.

System image file is "bootflash:asr9k-mini-xr-7.2.1"

Last reload type: Normal Reload

System uptime is 5 weeks, 2 days, 4 hours, 3 minutes

...

exit

Simple Network Management Protocol

Simple Network Management Protocol (SNMP), which is a network protocol that came after the CLI
scripting, enabled easier network monitoring. This protocol provides device status, performance, and
configuration information through predefined object identifiers (OIDs) that are available on network
devices with the SNMP GET commands. The list of all OIDs for a device is stored in a Management
Information Base (MIB), which is either included in device documentation or dynamically discovered
by performing an "SNMP walk." An SNMP walk is a process of reading a complete list of all device
OIDs and data under a specific root element.

For example, examine the following command. It represents an SNMP call (with the snmpwalk tool)
command for reading IP addresses of interfaces on a particular device. The -v2c flag defines the
version of SNMP and the -c flag sets the SNMP community that is used for authentication. The
comma-separated string at the end of the command represents an object identifier for the list of
interfaces. The command returns all the values under a specific identifier, since it performs an SNMP
walk. If instead you used a more specific OID (for instance, an OID of a single interface), only a single
value would be returned.

~/ snmpwalk -v2c -c <community_string> <device_ip> .1.3.6.1.2.1.4.20.1.1

IP-MIB::ipAdEntAddr.10.1.1.1 = IpAddress: 10.1.1.1

IP-MIB::ipAdEntAddr.192.168.1.1 = IpAddress: 192.168.1.1

IP-MIB::ipAdEntAddr.172.16.0.1 = IpAddress: 172.16.0.1

IP-MIB::ipAdEntAddr.10.1.2.1 = IpAddress: 10.1.2.1

IP-MIB::ipAdEntAddr.10.1.3.1 = IpAddress: 10.1.3.1

SNMP also supports traps—messages that are automatically sent from a network device to a SNMP
management system, which are similar to HTTP webhooks. However, the ability of SNMP to modify
device configuration through SNMP SET was limited, making it unsuitable for full automation in
dynamic environments.

NETCONF

NETCONF is an application layer protocol developed solely with network device configuration as its
primary objective. NETCONF enables improved configuration management compared to SNMP,
primarily because it supports a transactional approach to configuration changes. NETCONF support is
included in almost any Cisco device that is running a software version that is released after 2015 and
used as a basis for device configuration in tools such as Cisco NSO.

RESTCONF

RESTCONF is another application layer protocol and is similar to NETCONF. RESTCONF operates using
HTTP/HTTPS requests and follows the RESTful approach to building APIs, whereas NETCONF focuses
on XML remote procedure calls to the device. RESTCONF is available on most devices that also
support NETCONF, since it is often implemented as an additional layer over the NETCONF
functionality on network devices.
Desired-State Automation Tools

All the tools that were mentioned previously use an imperative approach to device automation; it is
up to you to implement all the steps between the initial and the final state. A declarative approach,
on the other hand, allows you to focus on what the final state of the configuration should be. The
implementation of these steps depends on the tools that you use to specify only the desired final
state. These automation tools commonly use APIs or NETCONF for actual communication with the
devices. Examples of such tools include Ansible and Terraform.

API Automation

As network devices and their functionality grew more complex, Cisco that is integrated and started
supporting APIs in its operating systems. Unlike CLI and SNMP, APIs offered a predictable,
standardized, programmatic interface for interacting with network devices.

Their main advantages are the following:

Scalability: APIs are easier to scale across multiple devices.

Flexibility: APIs support various programming languages and automation frameworks.

Granularity: APIs provide fine-grained control over device features and configurations.

Programmability: APIs enable integration with external tools such as orchestration platforms and
monitoring systems.

The shift to API-driven automation enabled a more granular control and real-time configuration
management. The shift also transformed network management, laying the foundation for modern
automation tools and practices. Cisco NX-OS, IOS XE, and IOS XR operating systems have all evolved
to support APIs, leading the transition from manual management to automated operations, which
has become the default for network management.

APIs can be implemented in many different ways on the devices. Most of the time, when talking
about APIs, people have web-based HTTP APIs in mind. However, APIs provide programmatic control
over NETCONF, Google Remote Procedure Calls (gRPC), and message queue protocols.
Next you will get an overview of the three major Cisco operating systems (IOS XR, IOS XE, and NX-OS)
and how they handle HTTP APIs.

IOS XR HTTP APIs

The Cisco IOS XR family of devices features an XML-based HTTP API, which is specified by XML
schemas (XML-based data models of an API). Client applications can modify the device configuration
or request status information by sending XML-encoded requests to the device. The router processes
these requests and responds with XML-encoded data.

The XML API in Cisco IOS XR is essentially a virtual configuration editor. Client applications can load,
browse, and modify configuration data without directly affecting the router's active configuration.
This modified configuration is known as the target configuration and is separate from the router's
running configuration. The running configuration can only be updated indirectly through the target
configuration.

Initially, the XML agent on the router must be enabled. For example, to enable a Secure Sockets Layer
(SSL) agent that handles incoming XML sessions, the following set of CLI commands can be used:

configure terminal

xml agent ssl

aaa authorization exec default local

After the XML API is enabled, client applications can send XML messages to the device over a
dedicated TCP port (38752 by default). All client requests that to the router must begin with an XML
declaration tag, followed by a request tag and one or more operation type tags (for example Get, Set,
Delete). The authentication is handled on the router by the transport-specific XML agent and is not
exposed through the XML interface.

<?xml version="1.0" encoding="UTF-8"?>

<Request MajorVersion="1" MinorVersion="0">

<Operation>

Operation-specific content goes here

</Operation>
</Request>

Similarly, router responses start with an XML declaration, a response tag, operation type tags, and a
result summary with an error count. Each request includes operation tags for all supported
operations, and these tags can be repeated. The response's operation type tags match those in the
corresponding client request.

<?xml version="1.0" encoding="UTF-8"?>

<Response MajorVersion="1" MinorVersion="0">

<Operation>

Operation-specific response data returned here

</Operation>

<ResultSummary ErrorCount="0"/>

</Response>

The following example shows how to modify a Border Gateway Protocol (BGP) configuration using an
XML message:

<?xml version="1.0" encoding="UTF-8"?>

<Request MajorVersion="1" MinorVersion="0">

<Set>

<Configuration>

<BGP>

<AS>

<Naming>

<AS>0</AS>

</Naming>

<FourByteAS>

<Naming>

<AS>4</AS>

</Naming>

</FourByteAS>

</AS>

</BGP>
 </Configuration>

</Set>

</Request>

Note that the example above is used to modify the target configuration on the IOS XR device. To
promote the target configuration to the running configuration a <Commit> tag is needed.

In addition to the XML client, Cisco IOS XR devices also support the gRPC Network Management
Interface (gNMI). gNMI allows for modifying, installing, or deleting device configurations and enables
viewing operational data, controlling devices, and generating telemetry streams. gNMI uses a single
protocol for both configuration management and telemetry, streamlining network management
tasks.

NX-OS HTTP APIs

Cisco NX-OS offers users two different HTTP APIs to interact with: NX-API and NX-API
Representational State Transfer (REST). The first, NX-API, exposes CLI commands of NX-OS through an
API that enables programmatic access to device configurations and operations. NX-API also features a
standalone RESTCONF API, which is an HTTP-based overlay for the NETCONF protocol.

The following are key features of NX-API:

HTTP/HTTPS Interface: NX-API uses HTTP/HTTPS protocols to send commands to the switch, allowing
for easy integration with web applications and scripts.

JSON or XML Payloads: NX-API accepts either JSON or XML-formatted requests, making it easier to
work with if you are familiar with one or the other formatting.

Command Execution: Users can execute CLI commands directly through the API, providing familiar
access to device functionalities without needing to log in to the device console.

Support of Configuration and Operational Commands: NX-API allows both configuration changes and
operational queries, providing complete access to device capabilities.

Using this API is suitable for users who prefer direct command-based interaction with NX-OS, instead
of resource-based access. NX-API is also useful in scenarios where legacy CLI knowledge can be used
in automation scripts or tools.
The following NX-OS CLI command enables the HTTP API on Cisco Nexus switches:

configure terminal

feature nxapi

A more modern approach to using the API only as an intermediary between the client and the device
CLI, like the NX-API does, is to treat the configuration as a resource, using NX-API REST. REST is an
approach to building APIs. This approach involves managing—creating, reading, updating, and
deleting—resources instead of operations, CLI commands and so on.

The NX-API REST is a RESTful programmatic interface for Cisco Open NX-OS. NX-OS stores
configuration and operational data in a centralized object store, the management information tree
(MIT). The nodes in the MIT store the configuration and state for different configuration elements.

NX-API REST provides access to objects stored in the MIT. In this case, managed objects represent
resources in the API. They have a well-defined REST URI, can be queried or configured from NX-API
REST using their Uniform Resource Identifier (URI), and accept both JSON and XML payloads.

The NX-API REST URIs use a specific structure:

http(s)://: Indicates the protocol that is used (HTTP or HTTPS).

switch:port: Specifies the IP address or hostname of the switch and the port number.

/api: Identifies the API endpoint.

/[mo/class]: Specifies whether the request is for a managed object or a class-level query.

/[dn/class]: Specifies the distinguished name or class name of the object being queried.

[:method]: Specifies an optional method to be invoked on the object (applicable only for POST
requests).

.[xml|json]: Indicates the encoding format (XML or JSON).

?{options}: Specifies optional query options, filters, and arguments.

To use this REST API, you must first authenticate yourself with the API endpoint. To do so, create an
HTTP POST request toward the authentication API URI.

POST https://10.0.0.11/api/mo/aaaLogin.json

"aaaUser": {

"attributes": {

"name": "johndoe",

"pwd": "cisco123"

This authentication request returns a response similar to this one, containing an authentication
token:

"imdata": [

"aaaLogin": {

"attributes": {

"token": "K5Uojmg1XjqXJSRlN6AaVxUnJ="

This token can then be used as a cookie in all subsequent requests to make sure your API requests
that read or modify the configuration are authenticated.
POST https://10.0.0.11/api/mo/sys/intf.json

Set-Cookie: APIC-cookie=K5Uojmg1XjqXJSRlN6AaVxUnJ=

"interfaceEntity": {

"children": [

"l1PhysIf": {

"attributes": {

"id": "eth1/2",

"mode": "trunk",

"trunkVlans": "15-20"

IOS XE HTTP APIs

The Cisco IOS XE family of devices supports REST API. Compared to the NS-OX REST API, IOS XE REST
API only supports the JSON format for the requests that are made toward it.

IOS XE REST API supports the following four basic HTTP operations, which translate to operations
that are performed on device configuration resources:

GET: Retrieves a specified resource.

POST: Creates a new resource.

PUT: Replaces or modifies a specified resource.

DELETE: Deletes a specified resource.

To enable the IOS XE REST API, you must first enable it in the router configuration with the following
basic set of commands:

configure terminal

remote-management

(cfg-remote-mgmt)# restful-api

(cfg-remote-mgmt)# end

Once the RESTful API is enabled, clients can start to interact with the API. As with most other APIs,
you need to first authenticate the client by performing basic HTTP authentication with a predefined
URI and saving the token that the service returns. In basic HTTP authentication, a request contains a
header field in the form of Authorization: Basic <credentials>, where <credentials> is the Base64
encoding of ID and password joined by a single colon (:) symbol.

For example, the following request can be used to authenticate a client with the IOS XE API:

POST https://10.0.0.12/api/v1/auth/token-services

Authorization: Basic em9pZGJlcmc6YmVuZGVy

The response contains an authentication token, which must appear as a custom HTTP header (X-
auth-token) in subsequent API invocations:

"kind": "object#auth-token",

"token-id": "1ZA23BC",

"link":http://10.0.0.2/api/auth/token-services/exampleUser,

"expiry-time": "00:15:00"

Once successfully authenticated, you can interact with the API as specified in the API reference
documentation. For example, to create a new bridge domain on a Cisco IOS XE device, you can use an
API request similar to the one shown in the next example:

POST https://10.0.0.12/api/v1/bridge-domain

X-auth-token: 1ZA23BC
{

"bd-id":1001,

"vxlan-vni":5001"member-list":[

"l2if-name":"gigabitEthernet2",

"svc-instance":1001

},

"l2if-name":"gigabitEthernet4",

"svc-instance":2001

Answer

The correct answer is Predictable and standardized interface. This answer is correct because the
standardization and predictability of APIs make them ideal for integration with various external tools,
such as orchestration platforms. The answer Dependency on device-specific CLI commands is
incorrect because this pertains to CLI scripts, not APIs. The answer Exclusive use of XML for data
encoding is incorrect because APIs can use multiple data formats, not just XML. The answer Reliance
on MIBs for device information retrieval is incorrect because MIBs are associated with SNMP, not
APIs.

NETCONF Overview
NETCONF is a network management protocol that is developed by the Internet Engineering Task
Force (IETF) to simplify and standardize the configuration of network devices. The protocol allows
NETCONF clients, such as scripts and orchestration tools, to modify, read, and delete device
configuration on remote devices in a predictable and secure manner. The protocol works over a
secure channel, typically SSH (called NETCONF over SSH), making sure that the communication with
network devices is safe.

One of the biggest differences between NETCONF and other network management protocols, such as
SNMP, is that NETCONF was designed with network automation in mind. NETCONF supports
configuration, status monitoring, and device management while ensuring that changes to
configurations are applied in a transactional manner. This capability is very important in network
device configuration. This capability ensures that multiple configuration changes can either succeed
or fail together, preventing partial configurations that can cause network instability.

The key features of NETCONF are the following:

Transactional Configuration: Ensures that configuration changes are atomic (all or nothing) and
rollback is possible if something goes wrong.

Retrieve and Set Configurations: Can retrieve and modify configuration data from devices using a
standard structure.

Extensibility with YANG Models: NETCONF operates alongside YANG, a data modeling language, to
describe device configurations and state data.

Secure Communication: Operates over SSH, ensuring encrypted communication with devices.

The NETCONF protocol is implemented in almost every Cisco device and in many devices from other
device vendors. NETCONF has become the preferred protocol for network device configuration in
popular industry tools.

NETCONF RPCs

How does NETCONF communicate with the devices? By using a remote-procedure call (RPC). RPC is
the fundamental method of communication in NETCONF. RPC allows the client, which is usually a
network management system or a controller, to request operations on a network device. The server
then returns a response. Every action in NETCONF, whether it is just retrieving configuration data,
modifying it, or committing changes, is performed through an RPC request.
In NETCONF, RPCs work as follows:

Client-Server Model: NETCONF follows a client-server architecture where the client sends an RPC
request to the device (server); the server processes the request and sends an RPC reply.

Request and Response: The client sends an XML-based RPC message (for example, to retrieve or
modify configuration data), and the server responds with an XML-encoded reply.

Operation Execution: Every RPC message includes a specific operation, such as get-config (for
retrieving device configuration) or edit-config (for modifying the configuration). The device responds
with either the requested data, an empty response, or an error message.

The following are examples of common RPC operations:

<get>: Requests operational data from the device, such as an interface address or routing tables and
is the most basic operation.

<get-config>: Retrieves the configuration from a specific datastore such as running or startup
configuration.

<edit-config>: Allows modification of the device configuration.

<delete-config>: Deletes a configuration datastore such as startup configuration.

<commit>: Instructs the device to apply changes that are made in the candidate configuration to the
running configuration.

<lock> and <unlock>: Locks and unlocks configuration data to ensure that changes are not
overwritten by multiple clients simultaneously.
YANG Models

Network devices nowadays are complex with many configuration options and capabilities. Therefore,
a standardized way of describing this complexity is needed. Yet Another Next Generation (YANG) is a
data modeling language that is used together with NETCONF to define how configuration and other
data is structured on a network device. Together, YANG and NETCONF provide a consistent and
standardized way to represent device capabilities and configuration parameters, ensuring that
different vendors and device types can be managed using a common framework.

YANG defines data in a hierarchical structure similar to XML. This hierarchy allows network operators
to model complex configuration and state data in an organized and predictable way, which is key for
any automation or network engineers developing solutions based on this format.

Not only does YANG describe device models, it's also used to model network services and other data
in orchestration tools such as Cisco NSO.

The following are critical elements of YANG structures:

Modules: Collections of related data definitions that represent configuration, operational data, or
both. Modules define containers, lists, and leaves.

Containers: Groupings of data elements such as interfaces or routing protocols.

Lists: Ordered collections of data such as interface lists or routes.

Leaf Nodes: Individual data points within containers or lists such as IP addresses or interface names.
These elements actually hold data.

RPCs and Notifications: YANG models can define RPCs and notifications that represent actions (for
example, a ping or traceroute on a device) or asynchronous messages from the device.

YANG data models and its elements can be visualized as hierarchical structures.
Using these key elements, YANG models standardize the way network devices expose their
configuration and operational data. Each model defines the schema of how device data is structured
and accessed through NETCONF. While there are industry-standard YANG models, for instance IETF
models that describe common network concepts like IPv4 or IPv6 addresses, vendors such as Cisco
often provide custom YANG models specific to their devices. These models provide device-specific
capabilities while following the same structure. The result for network devices is usually a
combination of the two—vendor models that also include standard ones.

In the following example, a YANG module defines an "interfaces" container that holds a list of
interfaces. Each interface has a name, description, address, and an enabled or disabled status. This
data structure would then be used in NETCONF to retrieve or modify the configuration of interfaces
on a network device.

module example-interfaces {

container interfaces {

list interface {

key "name";

leaf name {

type string;

leaf description {

type string;

leaf enabled {

type boolean;

leaf address {
 type inet:ipv4-address;

Enabling NETCONF on Cisco Devices

To start using NETCONF on your devices, you must first enable it. Cisco supports NETCONF across its
different platforms, including Cisco IOS XE, IOS XR, and NX-OS. Each platform has slightly different
steps to enable NETCONF, but the process is generally similar and straightforward.

To enable NETCONF on Cisco IOS XE, use the following commands:

netconf-yang

To enable NETCONF on Cisco IOS XR, use the following commands:

ssh server v2

ssh server netconf

netconf agent tty

netconf-yang agent ssh

To enable NETCONF on Cisco NX-OS, use the following commands:

feature netconf

After you enable NETCONF on these platforms, you can verify the service using SSH to connect to the
NETCONF server on port 830. Also, you can check session information and NETCONF-specific logs to
help troubleshoot any issues.

Using Python ncclient Module

Outside of controllers and other orchestration platforms, the ncclient Python module provides an
easy way to interact with NETCONF-enabled devices. The module abstracts the complexity that is
associated with managing XML-based NETCONF sessions and allows network administrators to
automate configuration tasks across multiple devices.
ncclient is designed to perform all NETCONF communication by allowing users to connect to a
network device, execute NETCONF RPCs, and retrieve or modify configurations. The library supports
all NETCONF operations such as get-config, edit-config, and commit.

To install ncclient, use Python’s package manager, pip:

pip install ncclient

The following is a basic, simple Python script that uses ncclient to connect to a NETCONF Cisco device
to read the device's running configuration.

from ncclient import manager

# Connect to the NETCONF server on a Cisco device

with manager.connect(host="192.168.1.1", port=830, username="admin", password="cisco",

hostkey_verify=False) as m:

# Retrieve and print the running configuration

config = m.get_config(source="running").data_xml

print(config)

The following are critical components of the script:

manager.connect: Opens a connection to the device NETCONF server. You need to provide the device
IP address, port (default is 830), username, and password. hostkey_verify=False disables SSH key
verification, which is useful for development but shouldn’t be used in production.

m.get_config(): Retrieves the running configuration from the device. The parameter
source="running" specifies that the running configuration should be returned. Other options include
"candidate" or "startup" configurations.

data_xml: The get_config method returns the device configuration in an XML format, which is
printed or processed further.

To modify a device configuration, you can use the edit-config operation. The following example
updates the address and the description of an interface based on the YANG interface model that is
shown previously:
from ncclient import manager

# Define the XML configuration to be applied

config_data = """

<config>

<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">

<interfaces>

<interface>

<GigabitEthernet>

<name>1</name>

<description>Updated by NETCONF</description>

<address>10.0.0.21</address>

<enabled>true</enabled>

</GigabitEthernet>

</interface>

</interfaces>

</native>

</config>

"""

with manager.connect(host="192.168.1.1", port=830, username="admin", password="cisco",

hostkey_verify=False) as m:

# Apply the configuration change

m.edit_config(target="running", config=config_data)

print("Configuration updated.")

If the device supports the candidate configuration datastore (such as IOS XR), you can edit
configurations in the candidate configuration and then commit them. This approach adds a layer of
safety, as changes are only applied once committed.

...

# Edit candidate configuration first

m.edit_config(target="candidate", config=config_data)

# Commit the candidate configuration

m.commit()

Answer

The correct answer is Describe device configurations and state data. YANG models provide a
structured way to represent and manage network device data within NETCONF. The answer Encrypt
data during transmission is incorrect because encryption is handled by protocols like SSH. The
answer Manage user authentication is not applicable because YANG models are not involved in
authentication. The answer Perform real-time traffic analysis is incorrect because YANG does not
perform traffic analysis.

Manage a Cisco Nexus Switch with

NETCONF
Enable NETCONF on a Cisco NX-OS Switch

Step 1
Show Me
Access the Cisco Modeling Labs WebUI. To access Cisco Modeling Labs
running in your lab environment, open a web browser on your student PC
and navigate to https://10.1.1.20 or click the Cisco Modeling
Labs bookmark.
Step 2
Show Me
Log in to access the main dashboard.

Use the following credentials:

 Username: student
 Password: 1234QWer
Step 3
Show Me
Click the Enable NETCONF on a Cisco NX-OS Switch topology to get to
the Workbench.
Step 4
Show Me
Check all devices in the topology and ensure they have fully booted before
proceeding with the lab steps or accessing the console. Attempting to
interact with a device that has not fully booted may interrupt the boot
process. Wait for a green check mark to appear next to each node,
indicating that it is ready.
Step 5
Show Me
Access the console of the NX-OS 9000 router by right-clicking the node
and choosing Console.
Step 6
Show Me
In the pane at the bottom, click the OPEN CONSOLE button.
Step 7
Show Me
Use the console to enable NETCONF. Log in with
the cisco/cisco123 credentials and execute the feature netconf command.

Install the Python ncclient Library

Step 8
Show Me
Navigate to the desktop of the Student VM. Right-click on the empty space
and choose New folder.
Step 9
Show Me
Input a meaningful name for the folder such as student.
Step 10
Show Me
Right-click the new folder and choose Open in Terminal.
Step 11
Show Me
Open VS Code using code .. When prompted to confirm, trust in the authors
of the files in the folder, click Yes, I trust the authors.
Step 12
Show Me
Choose New File.
Step 13
Show Me
Create a new Python File.
Step 14
Show Me
Now open a new terminal by using the Terminal item in the top menu bar.
Step 15
Show Me
Use the terminal to install the ncclient library using pip install ncclient.

Use NETCONF and Python ncclient To Fetch and Parse Data

Step 16
Show Me
Now, let's get to coding. In your newly opened Python file in VS Code, at
the very top, import the required modules. You will use re for sorting and
the manager from ncclient to establish a NETCONF connection. Make
sure that these imports are the first lines in your file.
Step 17
Show Me
Next, define the connection details for your Cisco Nexus switch such as
the IP address, port, username, and password. This information is used
to connect to the NETCONF server running on the switch.
Step 18
Show Me
Now, define the XML filter to specify the data you want to retrieve. In this
case, you are interested only in the physical interfaces and two pieces of
information: the interface ID and administrative status.
Step 19
Show Me
Retrieve the filtered configuration from the switch using get_config.
Step 20
Show Me
Next, split the configuration data into individual interfaces for easier
processing. This way, you can extract each interface separately.
Step 21
Show Me
Loop through the split data and extract specific details for each interface.
Step 22
Show Me
Sort the data by interface number.
Step 23
Show Me
Finally, display the sorted list of interfaces. Limit it to the first 10 entries to
keep a shorter output due to the large number of interfaces.
Step 24
Show Me
Before running the code, thoroughly review the entire file to ensure that
there are no mistakes such as incorrect indentation or syntax errors.
Step 25
Show Me
Save the Python file by pressing CTRL+S or clicking File > Save As... in
the top menu.
Step 26
Show Me
Click the Debug icon in the left sidebar, then click Run and Debug. Click
the Python Debugger option and choose the Python file debug
configuration. Wait for the program to run and observe the output in the
terminal at the bottom of the window.
Use NETCONF To Modify Data
Step 27
Show Me
Now, either create a new Python file by choosing File > New File from the
top menu, or reuse the current file. If creating a new file, don't forget to
save it.
Step 28
Show Me
Start by importing the manager from the ncclient library.
Step 29
Show Me
Next, define the configuration data to be applied by creating an XML-
formatted string.
Step 30
Show Me
Now, define the connection details using manager.connect for your Cisco
Nexus switch.
Step 31
Show Me
Finally, apply the configuration changes using edit_config(), then print a
confirmation that it was updated.
Step 32
Show Me
Before running the code, thoroughly review the entire file to ensure that
there are no mistakes such as incorrect indentation or syntax errors.
Step 33
Show Me
Now click Run and Debug and wait for the program to run. Observe the
output in the terminal.

Verify Modified Data on the Switch Using CLI

Step 34
Show Me
Navigate back to the browser window with Cisco Modeling Labs.
Step 35
Show Me
Use the console to check the change with the show running-config interface
ethernet 1/1 command.

Answer

The correct answer is ncclient. This answer is correct because the ncclient library is specifically
designed for NETCONF operations with network devices. The requests option is incorrect because
the requests library is used for HTTP requests, not for NETCONF. The numpy option is incorrect
because numpy is used for numerical computations and is irrelevant to NETCONF. Finally, the pandas
option is incorrect because pandas is a data manipulation library and not related to NETCONF.

RESTCONF Overview

RESTCONF is a standardized protocol that is used to access and modify network device configuration
data over HTTP/HTTPS. It was developed as a lighter alternative to the more complex, but still very
similar NETCONF protocol. RESTCONF relies on the ease of use and popularity of REST APIs, making it
simpler to integrate with modern web services and applications. It also allows you to perform
management tasks over HTTP/HTTPS so that you don't have to take care of other connectivity.
RESTCONF supports both JSON and XML encoding for data.

RESTCONF relates to NETCONF in the following aspects:

Underlying Data Models: Both RESTCONF and NETCONF operate using the same YANG data models.
While NETCONF exchanges XML-encoded RPCs (such as get-config and edit-config) through SSH,
RESTCONF provides access to the same YANG-modeled data through HTTP methods such as GET,
POST, PUT, and DELETE.
Use Case: RESTCONF is generally used for lightweight, simple network configurations or when a quick
RESTful API integration is needed without a steep learning curve. In contrast, NETCONF is often
preferred for more complex, transactional, or bulk configuration tasks.

How RESTCONF Works

RESTCONF uses the REST architectural API style, which allows you to interact with network devices
using standard HTTP methods. This protocol provides a standardized way to retrieve, modify, and
manage network configurations and state data.

RESTCONF operations and structure are as follows:

Base URL: RESTCONF operations are initiated through a base URL, typically following the format
https://<hostname>/restconf/.

Resources:

/data: Used for accessing or modifying configuration and state data and is equivalent to NETCONF
get-config or edit-config.

/operations: Used for executing RPC-style operations and is similar to how NETCONF handles RPCs.

To construct a valid URI, you need to use the appropriate YANG data structure for the device you
want to access. To do so, you can explore the Cisco GitHub repository, which contains a collection of
YANG modules. This collection includes YANG modules for different software versions of NX-OS, IOS
XE, and IOS XR network operating systems. By selecting an operating system and a specific software
version, you can view all available YANG modules. Furthermore, you can examine the module
structure, including descriptions of leaves, lists, and other components.

In the following example, you can see the structure of the ietf-interfaces YANG module for devices
running IOS XE 16.11.1.

Alternatively, you can also use the Cisco YANG Suite tool, shown in the following image. This tool is
free to use and available on the Cisco DevNet page. Once installed on your PC, it enables you to
access devices, view available YANG modules in a tree view, and investigate their structure. Also, it
can be used to execute RPCs.

The following HTTP methods are used in RESTCONF:

GET: Retrieves data from a network device and is is equivalent to a NETCONF get or get-config
operation but is executed as an HTTP GET request.
POST: Creates or modifies configuration data.

PUT/PATCH: Updates existing configuration data.

DELETE: Removes configuration data from the device.

For example, if you want to retrieve the configuration of interfaces in a Cisco device using a simple
HTTP GET request, the request will be performed with a GET request on the following URI:

GET https://<device-ip>/restconf/data/ietf-interfaces:interfaces

If you want to modify an interface configuration, the request will be performed with a PATCH
request:

PATCH https://<device-ip>/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1

Content-Type: application/yang-data+json

"ietf-interfaces:interface": {

"description": "Updated by RESTCONF"

Enabling RESTCONF on Cisco Devices

RESTCONF is supported across most Cisco operating systems with newer software versions (some
older versions might not support it), including IOS XE, IOS XR, and NX-OS. The functionality is enabled
in a similar way across all these platforms:

To enable RESTCONF on Cisco IOS XE, use the following commands:

restconf

To enable RESTCONF on Cisco IOS XR, use the following commands:

restconf

To enable RESTCONF on Cisco NX-OS, use the following commands:

feature restconf

Using RESTCONF with Python

In addition to enabling RESTCONF on Cisco devices, you can interact with the RESTCONF API
programmatically using Python and make API requests through an application such as Postman.
Therefore, RESTCONF is a great choice for network automation and orchestration.

The Python requests module provides an easy and simple way to interact with RESTCONF APIs over
HTTPS. You can use the module to send HTTP GET, POST, PUT, PATCH, and DELETE requests to modify
and read the device configurations.

The following Python code snippet shows how to use the requests module to retrieve an interface
configuration from a Cisco IOS XE device that has RESTCONF enabled. This script sends a GET request
to the RESTCONF API on the Cisco device at the /ietf-interfaces:interfaces endpoint, and retrieves the
interface configurations in JSON format. The configuration is returned in a structured format, which
can be parsed or used to update the network.

import requests

from requests.auth import HTTPBasicAuth

# Device and API details

url = "https://<device-ip>/restconf/data/ietf-interfaces:interfaces"

headers = {

"Accept": "application/yang-data+json",

"Content-Type": "application/yang-data+json"

# Authentication credentials

auth = HTTPBasicAuth('admin', 'password')

# Sending a GET request to retrieve interface data

response = requests.get(url, headers=headers, auth=auth, verify=False)

# Print the response in JSON format

print(response.json())

Using RESTCONF with Postman

Postman is a popular API client that allows you to make REST API calls with ease, and it works
seamlessly with RESTCONF for testing network configurations. It’s especially useful for testing APIs
and validating RESTCONF requests without needing to write code.

The following is a standard workflow for using Postman with RESTCONF:

Create a new request: In Postman, create a new request and set the method (for example, GET, POST,
PATCH, and DELETE).

Set the URL: Enter the RESTCONF endpoint for your Cisco device, such as
https://<device-ip>/restconf/data/ietf-interfaces:interfaces.

Set the headers: Add the necessary headers Content-Type: application/yang-data+json and Accept:
application/yang-data+json.

Authentication: Under the “Authorization” tab, choose Basic Auth and provide your device username
and password.

Send the request: Click Send to execute the API request. You should see the interface configuration
data that is returned in the body of the response in the JSON or XML format.

The following are examples of actions that you can perform with Postman:

GET: Retrieve configuration and operational data (for instance, interface status and system uptime).

POST/PUT/PATCH: Modify configuration data (for instance, change interface descriptions).

DELETE: Remove specific configurations (for instance, delete an interface or routing entry).

Example of a GET request using Postman:

Answer

The correct answer is GET. This answer is correct because the GET method is used in RESTCONF to
retrieve data from a network device, similar to the NETCONF get or get-config operation. The answer
POST is incorrect because it is used to create or modify data. The answer PUT is incorrect because it
updates existing data. The answer DELETE is incorrect because it is used to remove data.
Manage Cisco Catalyst Router with
RESTCONF
Enable RESTCONF and HTTPS Server on the Router
Step 1
Show Me
Access the Cisco Modeling Labs WebUI. To access Cisco Modeling Labs
running in your lab environment, open a web browser on your student PC
and navigate to https://10.1.1.20 or click the Cisco Modeling
Labs bookmark.
Step 2
Show Me
Log in to access the main dashboard.

Use the following credentials:

 Username: student
 Password: 1234QWer
Step 3
Show Me
Click the Manage Cisco Catalyst Router with RESTCONF topology to
get to the Workbench.
Step 4
Show Me
Check all devices in the topology and ensure they have fully booted before
proceeding with the lab steps or accessing the console. Attempting to
interact with a device that has not fully booted may interrupt the boot
process. Wait for a green check mark to appear next to each node,
indicating that it is ready.
Step 5
Show Me
Access the console of the CAT8000V router by right-clicking the node and
choosing Console.
Step 6
Show Me
In the pane at the bottom, click the OPEN CONSOLE button.
Step 7
Show Me
Use the console to enable RESTCONF and HTTPS Server.
Press ENTER to start.

Enter the global configuration mode by executing the configure

terminal command. Enable secure web access using ip http secure-server .
Enable RESTCONF with the restconf command. Exit the configuration
mode by entering end.

Use Postman To Read and Modify the Configuration

Step 8
Show Me
Launch Postman from the taskbar on your Student VM.
Step 9
Show Me
Dismiss the update notification.
Step 10
Show Me
Create a GET request to the RESTCONF endpoint of your device to
retrieve its interface data.
Step 11
Show Me
Set up basic authentication using the device credentials in
the Authorization tab.

Use the following credentials:

 Username: cisco
 Password: cisco123
Step 12
Show Me
Send the request and examine the result.
Note
Requests may fail if the RESTCONF service is not fully synchronized.
Please allow up to 5 minutes for it to become fully operational.
Step 13
Show Me
Duplicate the tab by right-clicking the current tab.
Step 14
Show Me
Adjust the method to PATCH and adjust the URL to target the second
interface.
Step 15
Show Me
Move to the Body tab and define the configuration as raw in
the JSON format.
Step 16
Show Me
In the Headers tab, define a new header called Content-Type with the
value of application/yang-data+json.
Step 17
Show Me
Finally, send the request.
Step 18
Show Me
Return to the previous tab and resend the request to check for the change.

Use the Requests Library To Get the Device Configuration

Step 19
Show Me
Navigate to the desktop of the Student VM, right-click on the empty space,
and choose New folder.
Step 20
Show Me
Input a meaningful name for the folder, such as student.
Step 21
Show Me
Right-click the new folder and choose Open In Terminal.
Step 22
Show Me
Open VS Code using code .. When prompted to confirm, trust in the authors
of the files in the folder, click Yes, I trust the authors.
Step 23
Show Me
Choose New File.
Step 24
Show Me
Create a new Python File.
Step 25
Show Me
Return to Postman. On the right toolbar, click the Code icon, generate
a Python - Requests code, and copy it.
Note
Make sure to select the first GET request.
Step 26
Show Me
Paste the code into VS Code and adjust the code to ignore SSL.
Step 27
Show Me
Save the Python file by pressing CTRL+S or clicking File > Save As... on
the top menu.
Step 28
Show Me
Click the Debug icon in the left sidebar, then click Run and Debug. Click
the Python Debugger option and choose the Python file debug
configuration. Wait for the program to run and observe the output in the
terminal at the bottom of the window.

Use the Requests Library To Change the Configuration

Step 29
Show Me
Create a new Python file by choosing File > New File from the top menu.
Step 30
Show Me
Return to Postman, select the tab with the PATCH request and copy
its Python code.
Step 31
Show Me
Paste the code into Visual Studio Code, configure it to ignore SSL, and
update the target interface to GigabitEthernet3.
Step 32
Show Me
Run the new code and observe the output.
Note
Ensure that you save your code before running it.
Step 33
Show Me
Check the device configuration again. You can do this by running the first
script again, or through Postman or Cisco Modeling Labs.

Answer

The correct answer is GET, POST, PUT, PATCH, DELETE. These are the HTTP methods RESTCONF uses
for network management. The CONNECT, OPTIONS, TRACE option is incorrect because these
methods are not typically used by RESTCONF. The HEAD, OPTIONS, PATCH option is incorrect because
it includes only some methods that are used by RESTCONF and omits others. Finally, the TRACE,
CONNECT, HEAD option is incorrect because these methods are not part of RESTCONF's core
operations.

Ansible Automation Tool Overview

Ansible is an open-source automation tool that simplifies many different IT tasks, for example
installing software and its dependencies, provisioning infrastructure, automating daily tasks, and
patching systems. Ansible was originally written by Michael DeHaan in 2012 and acquired by Red Hat
in 2015. Red Hat also offers a paid version with support.

The following are two main features of Ansible:

Agentless Architecture: Ansible operates over SSH (for Linux devices) or WinRM (for Windows
devices), which eliminates the need for agents to be installed and managed on devices. This
approach simplifies deployment and reduces resource consumption on network devices.

Declarative Language: Ansible defines the state of configuration with playbooks, which use a
declarative syntax, allowing users to describe the desired state of a system rather than all the specific
steps to achieve that state. The steps are implemented by the Ansible collections for a specific
environment or device. This approach makes it easier to understand and maintain automation
scripts.

Ansible can be installed on your workstation as a CLI tool or managed as a service with one of the
many Ansible-based tools such as Ansible Tower. Ansible uses a simple and straightforward syntax
based on YAML (Yet Another Markup Language) to define configuration. This characteristic makes it is
accessible to both developers and network engineers because YAML is human-readable and widely
used for configuration files and other purposes.

How does Ansible work on a more technical level?

When a playbook is executed, Ansible establishes a secure connection to one or more of the target
devices, using inventory files to determine which hosts to manage. The playbooks consist of a series
of tasks. Each task is defined using different modules that contain specific functionality such as
connecting to a Cisco IOS XR device, configuring network interfaces, or deploying software. Ansible
processes each task sequentially, sending the necessary commands to the target device and receiving
the output in real time. It also uses an idempotent approach. For example, running a playbook
multiple times does not lead to unintended changes if the desired state is already achieved—it stays
the same and does not attempt to reconfigure something again. The idempotent approach allows for
consistent and predictable configurations across managed devices. In addition, Ansible supports
dynamic inventory sources, allowing you to automatically discover and manage devices across
complex environments such as cloud-based infrastructure.

Ansible for Network Automation

Ansible plays a significant role in automating network operations, extending beyond traditional IT
infrastructure such as servers and virtual machines. Ansible enables easy, repeatable, and reliable
configurations across various network devices from Cisco or other vendors. Ansible's ability extends
beyond just configuration management and provides tools for monitoring, orchestration, and even
integration with some cloud platforms.

The major benefits of using Ansible over other network automation solutions are as follows:

Simplicity and Ease of Use: Simplicity is one of the first things that you will notice about Ansible.
YAML syntax is human-readable, allowing you to write and understand automation scripts with
minimal training. Network engineers can quickly transition from using CLI to creating Ansible
playbooks without much programming knowledge.

Idempotency: Ansible ensures idempotency, meaning that applying the same playbook multiple
times will not result in unintended changes. This characteristic is vital for network automation, as it
guarantees that the desired state of configurations is maintained, regardless of the current state of
the devices.

Scalability: Ansible is designed to effectively manage large-scale environments. It allows

simultaneous execution of tasks across multiple devices, so network teams can quickly automate
complex operations, such as configuration updates or compliance checks, across an entire fleet of
devices.

Community and Extensibility: Ansible has a thriving community that contributes to its extensive
library of modules and plugins. Users can benefit from shared playbooks, roles, and collections,
enabling them to implement best practices and learn from one another. Also, custom modules can
be created for specialized tasks, extending the capabilities of Ansible.

Integration: Ansible can seamlessly integrate with various other tools, including CI/CD (continuous
integration and continuous delivery) pipelines, monitoring systems, and cloud platforms. This
integration allows for continuous deployment and monitoring of network configurations, enhancing
operational efficiency.

Ansible Use Cases

The following list contains the most common tasks in network automation that rely on Ansible:

Configuration Management: Ansible is widely used for configuration management in network

environments. It allows network teams to consistently apply configurations across multiple devices,
ensuring compliance with organizational policies and reducing configuration drift.

Example use case: A network team can use Ansible to deploy a standardized Day 1 configuration
across all routers in a branch office, ensuring that each device has the same security settings and
routing protocols.

Network Provisioning: Ansible automates the provisioning of new network devices, significantly
reducing the time and effort that is required for deployment. This capability is essential for rapidly
scaling networks or deploying temporary setups.

Example use case: In a data center environment, Ansible can be used to automatically configure new
switches when they are added to the network, applying consistent settings without manual
intervention.

Monitoring and Reporting: Ansible can also gather state data from network devices, generating
reports for audits or performance monitoring. This data can be crucial for compliance with regulatory
standards or internal policies.

Example use case: Ansible can run periodic playbooks to collect interface statistics and store the
results in a central database for analysis, providing insights into network performance over time.

Change Management: Ansible facilitates controlled changes to network configurations, allowing

network engineers to quickly implement changes while maintaining rollback capabilities if necessary.

Example use case: If a change to a routing configuration causes issues, Ansible allows for rapid
rollback to the previous configuration, minimizing downtime and disruption.

Ansible Collections for Cisco Devices

Ansible collections are a way to distribute Ansible content, including roles, playbooks, and modules
for specific environments, operating systems, and technological domains. Ansible collections simplify
the management and sharing of automation code, allowing you to install and use collections that are
tailored to a specific vendor.
Cisco provides many such collections, including IOS, IOS XR, NX-OS, Intersight, Meraki, ISE, UCS, ACI,
and ASA.

Note

You can find all the official Cisco collections at the following link:
https://docs.ansible.com/ansible/latest/collections/cisco/index.html

Cisco.IOS Collection: The Cisco.IOS collection is designed for managing Cisco IOS devices. This way
that you can easily automate configuration tasks and network operations. The collection includes
modules for common tasks such as configuring interfaces, managing VLANs, and handling routing
protocols.

The following example shows a playbook that sets the hostname of a Cisco IOS device to
"AnsibleRouter." The ios_config module handles configuration changes and ensures that the device is
updated accordingly:

- name: Configure Cisco IOS Device

hosts: cisco_ios

gather_facts: no

tasks:

- name: Configure hostname

ios_config:

lines:

- hostname AnsibleRouter

Cisco.IOSXR Collection: The Cisco.IOSXR collection is tailored for managing Cisco IOS XR devices,
which are typically used in service provider environments. This collection provides modules that
facilitate the management of advanced features specific to IOS XR such as policy-based routing and
segment routing.

The following example shows a playbook that updates the description of a specified interface on a
Cisco IOS XR device, showcasing how Ansible can simplify complex configurations:

- name: Configure Cisco IOS XR Device

hosts: cisco_iosxr

gather_facts: no
 tasks:

- name: Configure interface description

iosxr_interface:

interface: GigabitEthernet0/0/0/0

description: Configured by Ansible

Cisco.NXOS Collection: The Cisco.NXOS collection is designed for managing Cisco NX-OS devices that
are commonly found in data centers. This collection allows users to automate tasks that are related
to virtualization and high availability in Cisco Nexus environments.

The following example shows a playbook that creates a VLAN with ID 100 named "AnsibleVLAN" on a
Cisco NX-OS device, demonstrating how Ansible can simplify VLAN management:

- name: Configure Cisco NX-OS Device

hosts: cisco_nxos

gather_facts: no

tasks:

- name: Create a VLAN

nxos_vlans:

vlan_id: 100

name: AnsibleVLAN

Answer
The correct answer is Idempotency. Ansible's idempotent approach ensures that running a playbook
multiple times does not result in unintended changes if the desired state is already achieved. The
answer Centralized control node is incorrect because it refers to architecture rather than execution
model. The answer Stateful execution model is incorrect because Ansible uses a stateless model. The
answer Complex scripting language is incorrect because Ansible uses a simple, human-readable
language (YAML).

Automate Cisco IOS XR Router with

Ansible
Go Through the Cisco.iosxr Modules Documentation
Step 1
Show Me
Open a web browser on your student PC and navigate
to https://docs.ansible.com/ansible/latest/collections/cisco/index.html.
Step 2
Show Me
Choose cisco.iosxr from the list of collections.
Step 3
Show Me
Find and choose the iosxr_interfaces module option from the list of
modules.
Step 4
Show Me
Review the documentation, starting with the installation instructions.
Step 5
Show Me
Move to the module parameters and inspect the available options.
Step 6
Show Me
Finally, scroll down to review the usage examples.

Create an Ansible Playbook for Configuration Modification

Step 7
Show Me
Navigate to the desktop of the Student VM, right-click on the empty space,
and choose New folder.
Step 8
Show Me
Input a meaningful name for the folder, such as student.
Step 9
Show Me
Right-click the new folder and choose Open in Terminal.
Step 10
Show Me
Open VS Code using code .. When prompted to confirm, trust in the authors
of the files in the folder, click Yes, I trust the authors.
Step 11
Show Me
Create a new file by clicking New file... and name the file interfaces.yaml.
Step 12
Show Me
Create a new Ansible playbook. Give it a meaningful name and define the
hosts as cisco_iosxr. Then, create a new task for configuring an interface,
as shown in the example.
Note
Remember to save the file before moving on.
Step 13
Show Me
Create a new file called cisco_iosxr and define the details of the device.
Note
Remember to save the file before moving on.

Push the Configuration to the IOS XR Router Using Ansible

Step 14
Show Me
Open the terminal from within VS Code by clicking the Terminal menu item
in the top bar and clicking New Terminal.
Step 15
Show Me
Retrieve the host key of the device by attempting to connect to it
using SSH with the ssh cisco@10.1.1.24 command, as this method is the
simplest method to obtain the key. After grabbing the key, disconnect the
session by clicking Ctrl + C.
Step 16
Show Me
Run the playbook with the ansible-playbook interfaces.yaml -i
cisco_iosxr command; do not forget to specify the hosts file.
Note
Do not forget to save the files before trying to run the playbook. You can
save the files by selecting File > Save from the top menu bar. An unsaved
file is marked by a small circle next to its name.
Step 17
Show Me
Access the devices through SSH with the ssh cisco@10.1.1.24 command
and verify the changes to the configuration using the show running-config
interface command.

Use the following credentials:

 Username: cisco
 Password: cisco123

Answer

The correct answer is -i. The -i option in the ansible-playbook command specifies the inventory file
that contains the host details needed for the playbook execution. The -h option is incorrect because
it provides help information rather than specifying inventory. The -f option is incorrect because it is
used to set the number of parallel processes, not for inventory. The -p option is incorrect because it
does not relate to specifying an inventory file.
Terraform Automation Tool Overview

Terraform is an IaC tool that is developed by HashiCorp that enables you to efficiently define,
provision, and manage infrastructure resources. It provides a declarative configuration language
called HashiCorp Configuration Language (HCL), which allows users to describe their infrastructure in
a clear and transparent manner. By treating infrastructure as code, Terraform encourages teams to
automate and version their infrastructure setup, making it easier to manage changes and collaborate
across different departments.

Terraform was open source until August of 2023, when Hashicorp announced a licensing change from
Mozilla Public License to Business Source License. A popular alternative to Terraform is OpenTofu.
OpenTofu is an open-source, community-driven Terraform fork that is managed by the Linux
Foundation.

On a high level, Terraform works by applying Terraform plans. The tool first communicates with the
relevant providers to determine the current state of the infrastructure. These are usually APIs for
various cloud platforms and network devices. It then generates an execution plan that details the
actions that are required to achieve the desired state, allowing users to preview changes before they
are applied. Once confirmed, Terraform executes the plan by sending the necessary API calls to
provision or modify resources.

Terraform agentless architecture relies on secure protocols such as SSH or HTTPS for communication.
Same as with Ansible, this approach allows Terraform to manage resources without needing to install
any agents on the target devices and hosts. In addition, Terraform maintains a state file that tracks
the infrastructure's current configuration. This architecture supports features such as version control,
change management, and collaboration, making Terraform a very useful tool for infrastructure
automation.

Terraform for Network Automation

In the context of network automation, Terraform enables network engineers to programmatically
manage and provision network devices and services. Instead of manually configuring devices through
a CLI, engineers can define the desired state of their network infrastructure in Terraform
configuration files.

This approach improves efficiency, reduces human error rates, and promotes consistency across
environments. Also, by integrating Terraform with Cisco network devices, organizations can ensure
that configurations are not only automated but also versioned and repeatable.

The major benefits of using Terraform over other network automation solutions are as follows:

Infrastructure as Code (IaC): The IaC approach allows you to define the network infrastructure
through code, which can be stored in version control systems such as GitLab. This practice enables
multiple team members to work on the same codebase at the same time. Any changes to the
network infrastructure can be tracked, reviewed, and rolled back if necessary, providing greater
control and accountability.

Declarative Language: Terraform uses a declarative approach, where you specify the desired end
state of your infrastructure rather than detailing the steps to achieve it. This approach simplifies the
process of managing different operating systems and versions in complex infrastructure setups. Now
you can focus on defining what the infrastructure should look like, while Terraform handles the
underlying execution details.

Multiprovider Support: One of the significant advantages of Terraform is its multiprovider support,
allowing it to manage resources across various platforms, including cloud providers and on-premises
solutions. For Cisco network devices, Terraform can interface with various network operating
systems, including IOS XE, IOS XR, and NX-OS, providing a comprehensive solution for network
automation. If the device you are trying to automate is not currently supported, you can develop
new providers yourself.

Plan and Apply Workflow: Terraform follows a "plan and apply" workflow. When you create a
Terraform configuration, it first generates an execution plan, which details the actions Terraform will
take to achieve the desired state. This preview feature allows users to review changes before they
are applied, which minimizes the risk of outages and makes sure you understand the changes that
you want to perform

Terraform Use Cases

The most common tasks in network automation that can use Terraform are as follows:
Provisioning Network Resources: Terraform is great at automating the provisioning of network
resources and services, allowing organizations to deploy new devices and configurations quickly and
effortlessly. By defining infrastructure in code, network teams can ensure that all devices are
configured consistently and according to organizational standards.

Example use case: A network team can use Terraform to provision multiple routers with a
standardized configuration in a matter of minutes. This way the team can reduce the manual effort
and ensure compliance with best practices.

Change Management: By using Terraform, changes to network configurations can be managed

systematically. By treating network infrastructure as code, teams can make adjustments in a
controlled manner, allowing for review and rollback if necessary.

Example use case: If a configuration change leads to connectivity issues, the team can quickly revert
to a previous version of the configuration using Terraform version control features, minimizing
downtime and disruption.

Disaster Recovery: In the event of a network failure, Terraform enables rapid recovery by allowing
teams to recreate the network infrastructure based on version-controlled code. This capability is
essential for maintaining business continuity.

Example use case: A team can restore a data center network to its last known good state using
Terraform configurations, reducing recovery time and ensuring minimal impact on operations.

Environment Replication: Terraform simplifies the process of replicating network environments for
testing, development, or staging purposes. By applying the same Terraform code across different
instances, teams can ensure consistency in configurations and reduce the risk of discrepancies.

Example use case: When preparing for a new deployment, a network team can spin up a replica of
their production environment using Terraform, allowing for thorough testing before any changes are
made to the live network.

Terraform Providers for Cisco Devices

Terraform providers are basically components that enable Terraform to interact with different APIs
and platforms. They serve as the bridge between Terraform configurations and the underlying
infrastructure, meaning that they are the ones that allow you to manage resources programmatically.
Some of the Terraform providers for Cisco devices include:

iosxe

iosxr

nxos

dcnm

ciscoasa

aci

Note

You can find all the official Cisco providers at the following link:
https://registry.terraform.io/namespaces/CiscoDevNet

IOSXE Provider: The IOS XE provider allows users to automate the management of Cisco IOS XE
devices, which are commonly used in enterprise networking. This provider offers a range of
resources for configuring interfaces, VLANs, and other network settings.

In this Terraform configuration example, the provider is configured with the device connection
details. A resource is created to configure an interface on the Cisco IOS XE device. The interface is
enabled.

provider "iosxe" {

username = "admin"

password = "password"

url = "192.0.2.1"

resource "iosxe_interface" "GigabitEthernet0_1" {

name = "GigabitEthernet0/1"
 description = "Configured by Terraform"

enabled = true

IOSXR Provider: The IOS XR provider is designed for managing Cisco IOS XR devices, which are
typically used in service provider environments. This provider facilitates the automation of advanced
network functions specific to IOS XR.

The configuration snippet below demonstrates how to configure an interface on a Cisco IOS XR
device. The provider is set up with connection details, and an interface resource is defined with a
description. As you can see, the main difference between the IOS XR and IOS XE examples in this
instance is the use of a different provider.

provider "iosxr" {

username = "admin"

password = "password"

host = "192.0.2.2"

resource "iosxr_interface" "GigabitEthernet0_0_0_0" {

interface = "GigabitEthernet0/0/0/0"

enabled = true

NXOS Provider: The NXOS provider is used for managing Cisco NX-OS devices, typically found in data
center environments. This provider allows for the automation of various network configurations and
operations specific to NX-OS.

In the following example, the NXOS provider is configured with the device connection details. A
resource is created to configure a VLAN on the Cisco NX-OS device, specifying the VLAN ID and its
name. This showcases how Terraform can be used to manage VLAN configurations effectively.

provider "nxos" {

username = "admin"

password = "password"

host = "192.0.2.3"

}
resource "nxos_vlan" "vlan_100" {

vlan_id = 100

name = "TerraformVLAN"

Answer

The correct answer is Providers. Providers are the components that allow Terraform to interact with
APIs and platforms, facilitating management of resources. The answer Agents is incorrect because
Terraform operates without agents. The answer Modules is incorrect because modules are reusable
packages of Terraform configurations. The answer Resources is incorrect because it refers to the
specific items defined in configurations, not the interaction facilitators.

Automate Cisco Catalyst Switch with

Terraform
Prepare the Environment and Install Terraform
Step 1
Show Me
Access the official Terraform documentation. To access it in your lab
environment, open a web browser on your student PC and navigate
to https://developer.hashicorp.com/terraform/install.
Note
In the Privacy Settings windows, choose Accept Essentials Only.
Step 2
Show Me
Find and copy the installation instructions for Linux Ubuntu/Debian.
Step 3
Show Me
Navigate to the desktop of the Student VM, right-click the empty space, and
choose Open in Terminal.
Step 4
Show Me
Copy the Terraform install commands from the web browser to the terminal
to install Terraform.

Create Terraform Code

Step 5
Show Me
Use the Terminal to create a new folder called terraform and navigate to
the folder. To create a directory named terraform, use the mkdir
terraform command. To navigate to it, use cd terraform/.
Step 6
Show Me
Create a new file called iosxe_config.tf. Use the touch command followed
by the name the new file.
Step 7
Show Me
Use an editor such as Nano to open the file. Enter the nano
iosxe_config.tf command.
Step 8
Show Me
First, create the Terraform Block and specify the required provider.
Specify iosxe as the required provider, use CiscoDevNet/iosxe as the
source, and 0.5.6 as the version
Step 9
Show Me
Now, create the Provider Block, specifying the device details.
Use cisco as the username, cisco123 as the password,
and https://10.1.1.23 as the URL.
Step 10
Show Me
Finally, specify the resource to be managed; this should be one of the
interfaces. Use iosxe_interface_ethernet and GigabitEthernet1_0_ as
the resource, GigabitEthernet as the type, 1/0/1 as the name,
and Configured by Terraform as the description.
Step 11
Show Me
Check all the contents and save the file.

To save the file in Nano, press Ctrl + X, then Y and Enter.

Apply the Configuration Using Terraform

Step 12
Show Me
First, initialize the Terraform Working Directory. Use the terraform
init command.
Step 13
Validate the configuration using the terraform validate command.

student@student-vm:~/Desktop/terraform$ terraform validate

Success! The configuration is valid.

Step 14
Show Me
Create the execution plan with the terraform plan command and review the
changes.
Step 15
Show Me
Now apply the configuration with the terraform apply -auto-
approve command.
Step 16
Show Me
Finally, check the resources that are managed by Terraform with
the terraform show command.
Note
SSH is also available if you wish to check the configuration of the device.
Step 17
Show Me
Connect to the device using SSH to the 10.1.1.23 IP address. Use the ssh
cisco@10.1.1.23 command. When prompted, confirm the fingerprint by
typing yes, and then enter the password cisco123 when prompted.
Step 18
Show Me
Show the running configuration for the configured GigabitEthernet1/0/1
interface with the show run interface GigabitEthernet 1/0/1 command to
verify that Terraform has applied the description.

Answer

The correct answer is To apply the changes required to reach the desired state of configuration. The
terraform apply command executes the plan's actions, setting the infrastructure to the desired state.
To check the syntax of the Terraform configuration is incorrect, because this is the role of terraform
validate. To generate a plan without making changes is incorrect because a terraform plan does this,
not terraform apply. To delete all resources that are defined in the configuration is incorrect, because
deletion is not the purpose of terraform apply.

Summary

Network automation is essential for modern network management because of various tools and
vendor support that enhance operational efficiency, reduce human error, and accelerate the
deployment of network services.

Automation has evolved and is well supported across different Cisco platforms such as IOS XE, IOS
XR, and NX-OS. Protocols such as NETCONF and RESTCONF are supported on most devices and play
an important role in this automated approach to network configuration, since they allow for
standardized configuration and management of network devices.
Tools such as Ansible make automation much easier to set up than it was years ago by providing a
robust framework for configuring and managing network devices. In addition, Terraform offers the
IaC capabilities, allowing for versioned provisioning and management of network resources.

All in all, network automation not only simplifies operations but also improves reliability in
increasingly complex networking environments.

After completing this course, you will be able to address the following questions:

Which options are available if you want to automate network devices running Cisco IOS XR, IOS XE or
NX-OS operating systems?

What are the benefits and drawbacks of different network automation approaches?

Which open-source tools help you with network automation?

Cisco Network Automation Platforms

Introduction

A growing number of devices, services, and users are putting a strain on the day-to-day operations of
networks, impacting the ability to introduce new services or maintain existing ones.

As a network engineer, you must know how to use automation and orchestration to optimize
network lifecycle management processes and procedures, enabling your company to introduce new
services and improve reliability. What tools and solutions will you use to provide greater agility,
efficiency, flexibility, security, and consistency of your network?

In this course, you will learn about Cisco automation platforms that can automate networking
devices with Cisco IOS XE Software, Cisco Nexus Operating System (NX-OS), and Cisco IOS XR systems.

Cisco Catalyst Center Overview

Cisco Catalyst Center, formerly known as Cisco Digital Network Architecture (DNA) Center, is a
powerful network management platform that simplifies network operations. It provides a centralized
dashboard for designing, provisioning, and monitoring network devices and applications. The Cisco
Catalyst Center GUI provides full network visibility. By using network insights, Cisco Catalyst Center
helps you improve network performance, enhance security, and reduce operational costs.

After you log in, the Cisco Catalyst Center displays its homepage. You can see on the following figure
that the homepage has two main areas: Assurance Summary and Network Snapshot.

The Assurance Summary area includes:

Health: Provides the health score of your overall enterprise, which includes network devices, wired
clients, and wireless clients. Clicking View Details takes you to the Overall Health page.

Critical Issues: Provides the count of P1 and P2 issues. Clicking View Details takes you to the Open
Issues page. P1 represents critical issues that need immediate attention before they cause a wider
impact on network operations. P2 represents major issues that can potentially impact multiple
devices or clients.

Trends and Insights: Provides insights about the performance of your network. Clicking View Details
takes you to the Trends and Insights page.

The Network Snapshot area includes:

Sites: Provides the number of sites discovered on your network along with the number of DNS and
NTP servers. Clicking Add Sites takes you to the Network Hierarchy page.

Network Devices: Provides the number of network devices discovered on your network along with
the number of unclaimed, unprovisioned, and unreachable devices. Clicking Find New Devices takes
you to the Discover Devices page.

Application QoS Policies: Provides the number of application policies discovered on your network
along with the number of successful and errored deployments. Clicking Add New Policy takes you to
the Application Policies page.

Network Profiles: Provides the number of profiles discovered on your network. Clicking Manage
Profiles takes you to the Network Profiles page.

AI Endpoint Analytics: Provides information about the endpoints that are connected to your network,
including profiled endpoints, trust score alerts, and AI rules. Clicking View Details takes you to the
Policy > AI Endpoint Analytics > Overview page.

Images: Provides the number of images discovered on your network along with the number of
untagged and unverified images. Clicking Import Images/SMUs takes you to the Image Repository
page.

Software Image Updates: Provides the status of software image updates. Clicking Update Devices
takes you to the Image Update workflow.
Licensed Devices: Provides the number of devices that have a Cisco Catalyst Center license along
with the number of switches, routers, and wireless devices. Clicking Manage Licenses takes you to
the License Manager page.

EoX Status: Provides the number of devices scanned and EoX alerts discovered on your network.
Clicking Authorize Consent to Connect opens the Consent to Connect dialog box. Review the
information, check the check box confirming that you have read the conditions, and click Authorize
to scan the network for EoX alerts.

Field Notices: Provides the number of hardware and software field notices that affect devices in the
network. Clicking the displayed number takes you to the Field Notices page.

With Cisco Catalyst Center, there is no need for a time-consuming manual practice of network
provisioning and troubleshooting tasks. Zero-touch device connectivity and Software Image
Management features reduce device installation and upgrade times from hours to minutes, and they
bring new remote offices online with plug-and-play (PnP) ease.

You can explore Cisco Catalyst Center to see the main features and recommendations for your
resources as seen from the following figure.

The main Cisco Catalyst Center features include the following:

Design: Design your network using intuitive workflows, starting with locations where your network
devices will be deployed. Users of Cisco Prime Infrastructure and the Cisco Application Policy
Infrastructure Controller Enterprise Module (APIC-EM) can simply import existing network designs
and device images into Cisco Catalyst Center.

Policy: Define user and device profiles that facilitate highly secure access and network segmentation
based on business needs. Application policies allow your business-critical applications to provide a
consistent level of performance regardless of network congestion.

Provision: Use policy-based automation to deliver services to the network based on business priority
and to simplify device deployment. Zero-touch device provisioning and Software Image Management
features reduce device installation or upgrade time from hours to minutes and bring new remote
offices online with plug-and-play ease from an off-the-shelf Cisco device. Also, the Cisco Secure
Network Analytics service provisions network elements to send NetFlow and Encrypted Traffic
Analytics (ETA) to the analytics service.

Assurance: Enable every point on the network to become a sensor, sending continuous streaming
telemetry on application performance and user connectivity in real time. This, coupled with
automatic path-trace visibility and guided remediation, means that network issues are resolved in
minutes—before they become problems. Automated NetFlow switch configuration for Cisco Secure
Network Analytics provides detection and mitigation of threats, even when they are hidden in
encrypted traffic.

Platform: An open and extensible platform allows third-party applications and processes to exchange
data and intelligence with Cisco Catalyst Center. This improves IT operations by automating workflow
processes based on network intelligence coming from Cisco Catalyst Center.

System: To start using Cisco Catalyst Center, you must first configure the system settings so that the
server can communicate outside the network, ensure secure communications, authenticate users,
and perform other key tasks.

Automation is at the heart of Cisco Catalyst Center. The Cisco Catalyst Center function concerns
automation of network operations, making networks and services easy to deploy, manage, and
maintain—fundamentally changing the approach to network management. Cisco uses controllers to
fully abstract the network and automate all day-zero, day-one, and day-two functions. Through
centralized policy control, Cisco allows IT to provide the business intent, and have the controller drive
enforcement dynamically throughout the network.

Cisco Catalyst Center automation has the following benefits:

Simplify network management: You can manage the enterprise network over a centralized
dashboard.

Deploy networks in minutes, not days: Using intuitive workflows, Cisco Catalyst Center makes it easy
to design, provision, and apply policy across the network.

Lower costs: Policy-driven provisioning and guided remediation increase network uptime and reduce
the time that is spent on managing simple network operations.

Answer

The correct answer is Monitor application performance and user connectivity in real time. This
answer is correct because the Assurance feature provides real-time monitoring and telemetry data
for network performance and connectivity. The answer Manage software image updates is incorrect
as this task falls under software management functions. The answer Design network locations and
deployments option is incorrect because designing is a function of the Design feature. The
answer Import existing network designs is incorrect because importing is not the focus of the
Assurance feature.

Cisco Application Centric Infrastructure

and Cisco Nexus Dashboard Overview

As traditional IT departments are under pressure to provide more agility and better outcomes to the
business, a new model for operations has emerged, which is called Fast IT. Cisco Application Centric
Infrastructure (ACI) enables Fast IT by providing a common policy-based operational model across
the entire Cisco ACI-ready system. Fast IT drastically reduces cost and complexity.

In the data center, Cisco ACI is a holistic architecture with centralized automation and policy-driven
application profiles. Cisco ACI delivers software flexibility with the scalability of hardware
performance that provides a robust transport network for today’s dynamic workloads. Cisco ACI is
built on a network fabric that combines time-tested protocols with innovations to create a highly
flexible, scalable, and resilient architecture of low-latency, high-bandwidth links.

This system-based approach simplifies, optimizes, and accelerates the entire application deployment
lifecycle across data center, WAN, access, and cloud environments. In doing so, this system
empowers IT to be more responsive to changing business and application needs. This ability
enhances agility and adds business value.

The following are the main components of Cisco ACI:

Spine switches:

Represent the backbone of the Cisco ACI fabric

Connected to leaf switches

Leaf switches:

Represent a connection point for end devices, including the Cisco Application Policy Infrastructure
Controller (APIC)

Connected to spine switches

Cisco APICs:

Unified point of policy enforcement, health monitoring, and management for the Cisco ACI fabric

Not involved in data plane forwarding

Usually, traditional networks use traditional core-aggregation-access layers. When you add more
devices, this topology can be complicated to manage. In Cisco ACI, a spine-leaf topology is used. All
the connections within the Cisco ACI fabric are from leaf to spine switches, and a mesh topology is
between them. There is no leaf-to-leaf and no spine-to-spine connectivity. Leaf and spine topology is
the basis of the Cisco ACI architecture as seen from the previous figure.

The following are the key benefits of Cisco ACI:

Automation of IT workflows and application deployment agility

Open APIs and a programmable fabric, with 65-plus ecosystem partners

Security through allow lists, policy enforcement, microsegmentation, and analytics

Workload mobility at scale for physical and virtual load

The design of Cisco ACI is based on the fabric as a whole, as opposed to treating the fabric switches
individually. All the physical components form the overall system.

The physical devices that are used in the Cisco ACI Fabric are Cisco Nexus 9000 switches. Compared
to switches used in NX-OS mode, the difference is that the software used in ACI mode is the Cisco ACI
operating system. Therefore, although the hardware may be the same, Cisco ACI provides a
completely different product. Cisco ACI is not a feature of Cisco Nexus.

To verify if a switch is running in NX-OS standalone or in the ACI mode, check the image filename.

Issue the show version command to verify the switch mode:

If the image filename starts with nxos, the switch is running in the NX-OS standalone mode.

Leaf-2# show version

<...>

Software

BIOS: version

NXOS: version 9.3(13)

BIOS compile time:

NXOS image file is: bootflash:///nxos.9.3.13.bin

<...>

If the image filename starts with aci-n9000, the switch is running in the ACI mode.

Leaf1# show version

<...>

Software

BIOS: version 05.51

kickstart: version 16.0(6c) [build 16.0(6c)]

system: version 16.0(6c) [build 16.0(6c)]

PE: version 6.0(6c)

BIOS compile time: 11/29/2023

kickstart image file is: /bootflash/aci-n9000-dk9.16.0.6c.bin

kickstart compile time: 06/26/2024 08:24:12 [06/26/2024 08:24:12]

system image file is: /bootflash/auto-s

system compile time: 06/26/2024 08:24:12 [06/26/2024 08:24:12]

<...>

Cisco Nexus Dashboard

While many operational services are available to manage data center operations, maneuvering
through multiple applications has become a challenge by itself, because IT teams must now correlate
information from numerous tools across hybrid environments. Network operations teams are
struggling to reconcile fragmented toolchains, an inconsistent user experience, and siloed processes
to manage complex data center environments that include on-premises infrastructure and public
cloud sites.
Cisco Nexus Dashboard solves these challenges by offering a centralized management console that
helps you unify management and monitoring with different applications that run on top of it, as
illustrated in the following figure.

The Cisco Nexus Dashboard is a platform for the following services:

Data Broker: A solution to build a packet broker network for further analysis

Orchestrator: A solution to set up and operate multisite fabrics

Insights: A comprehensive solution for analysis, trending, anomaly detection, alerting, and much
more

Fabric Controller: A solution to deploy Cisco NX-OS-based VXLAN fabrics

Fabric Discovery: A solution to monitor Cisco NX-OS fabrics

SAN Controller: A solution to deploy and monitor SAN fabrics

Each Cisco Nexus Dashboard group consists of three primary nodes. In addition, you can add up to
four additional worker nodes to enable horizontal scaling and up to two standby nodes for easy
group recovery in case of a primary node failure.
After you have deployed the Cisco Nexus Dashboard cluster, you can perform any further actions by
using its GUI. To access the Cisco Nexus Dashboard GUI, simply navigate to any one of the node's
management IP addresses: https://<node-mgmt-ip>.

The landing page when you log in to your Cisco Nexus Dashboard cluster is the Admin Console. This
page provides information about the current Cisco Nexus Dashboard cluster’s status, sites, services,
and resources usage.

The Cisco Nexus Dashboard home screen allows you to navigate between the Admin Console and
various applications. Each service installed and enabled on the Cisco Nexus Dashboard has its own
entry in the list, for example, the Insights service in the following figure.

Cisco IOS XR Management and

Automation Solutions Overview

Cisco offers a comprehensive suite of management and automation solutions specifically tailored for
Cisco IOS XR devices. These solutions enable you to efficiently manage, monitor, and automate
various aspects of your network infrastructure. Key features include centralized configuration
management, network performance monitoring, fault detection and isolation, and automated
provisioning.

Cisco IOS XR management and automation solutions include the following:

Cisco Evolved Programmable Network Manager (EPNM): A network management solution that
provides end-to-end lifecycle management across device management, network provisioning, and
network assurance.

Cisco WAN Automation Engine (WAE): A software tool that provides visibility, analysis, and
optimization for complex WANs.

Cisco Network Services Orchestrator (NSO): A software platform that automates the provisioning,
management, and orchestration of network services across different domains and technologies.

Cisco Evolved Programmable Network Manager

Cisco EPNM simplifies network management with a single product experience and similar workflows
across lifecycle tasks. Service providers can increase business agility through fast service provisioning,
improve operational efficiencies through automation and ease of use, and ultimately lower costs
over time.

Cisco EPNM includes the following features:

Comprehensive, graphical views of the entire network from topology down to the device level with
centralized inventory, status, and fault information

Automated discovery, device configuration, and change management with up-to-date displays of
network events, states, and changes

Graphical user interface with wizard-driven workflows, topology-guided troubleshooting, and

multilayer visualization

Point-and-Click provisioning of Ethernet virtual connections (EVCs) and Carrier Ethernet (CE) services
sharing the same platform for optical transport circuits

Fault management for the underlying infrastructure, including CE services and EVCs

Proactive network health monitoring, including network-level alarms, threshold crossing alerts
(TCAs), metrics gathering, and performance reporting
Cisco EPNM provides the following benefits:

Increased operational scale and efficiency through simplified, integrated, and automated device
operations, network provisioning, and network assurance

Proactive service assurance, highly effective fault management, and trend information that help
providers avoid future service disruptions

Lower costs through integrated lifecycle management and standards-based northbound interfaces to
third-party operations support systems

Cisco WAN Automation Engine

Cisco WAN Automation Engine (WAE) is a software tool that provides multivendor and multilayer
visibility and analysis for the service provider and large enterprise networks. It plays a critical role in
understanding and abstracting how traffic moves through the network. You can use Cisco WAE to
simulate "what if" scenarios or determine how to best optimize the network by using the planning
application called Cisco WAE Design or Cisco WAE APIs.

The foundation software is Cisco WAE Planning, which provides a cross-sectional view of traffic,
topology, and equipment state. Cisco WAE works on IP and MPLS networks, allowing you to model
your multivendor IP, MPLS, or segment routing (SR) network.

Cisco WAE is a flexible, programmable framework:

It can programmatically present near real-time abstractions of the network.

It can compare different network states resulting in an effective what-if analysis.

Cisco WAE works with software-defined networking (SDN) controllers for path programming:

Cisco NSO

Cisco IOS XR Segment Routing Path Computation Element (SR-PCE)

Cisco WAE uses various data collection mechanisms, some of them are the following:

Simple Network Management Protocol (SNMP)

BGP Link State

Telemetry

Cisco WAE is a distributed system that runs on x86/Linux servers and offers an API-centric approach
in building third-party applications.

With Cisco WAE, the software builds a topology, determines where the traffic is flowing, and provides
you with the visibility that you need for traffic engineering, capacity planning, and future
requirements.

Without this visibility, it is harder and more time-consuming to add new services. You need to figure
out the impact that the new service will have on the network. It can take weeks to determine that
impact, whereas Cisco WAE lets you model the service on top of your existing network and offline.
That way, you can see exactly what is going to happen and bring the service to market faster.

There are three main components of Cisco WAE:

Cisco WAE server: Collects and builds an abstracted model of the IP/MPLS network. The server will
produce discrete models that contain the topology, traffic, and state from the period in which the
data was collected from the network. These models are used by the Cisco WAE applications—Cisco
WAE Design and Cisco WAE Live. The Cisco WAE network model includes the multivendor devices
that participate in the Interior Gateway Protocol (IGP)—Open Shortest Path First (OSPF) or
Intermediate System-to-Intermediate System (IS-IS).

Cisco WAE Live: A web-based application that will examine the models produced by the server by
putting the data in a time-series datastore. It features a topology weather map, table view of the
data and a reporting engine used to evaluate the time-series information.

Cisco WAE Design: A planning tool that runs on your desktop. In Cisco WAE Design you can retrieve a
network model from the server and view the topology. You can quickly filter and drill down, simulate
"what if" scenarios and run tools to evaluate potential risks, find optimal paths/IGP metrics or
suggest changes in capacity.

At its core, Cisco WAE defines an abstract network model, which can be built from an actual network
by stitching together network interface modules (NIMOs).

The main components of the WAE server architecture are illustrated in the following figure:

NIMOs

Topology Aggregator or Delta Aggregation Rules Engine (DARE)

Simple Aggregation Engine (SAgE)

You can perform the following tasks with Cisco WAE:

What-if scenarios and failure analysis

Traffic analysis and capacity planning

Network optimizations and traffic analytics

Cisco Network Services Orchestrator

Cisco Network Services Orchestrator (NSO) is the industry-leading software solution for automating
services across traditional and virtualized networks. Using Cisco NSO, Service Providers can realize
the promise of automation and virtualization by automating services, end-to-end, across traditional
physical networks, new virtual networks, or hybrid physical/virtual topologies.
Cisco NSO is a bridge between automation and orchestration frameworks and the underlying physical
and virtual infrastructure.

Cisco NSO has been shaped by nearly a decade of helping large, complex tier-1 service provider and
enterprise customers automate everything from simple device turn-up, to cross-domain automation,
to sophisticated full lifecycle service management.

The two primary components of Cisco NSO are:

Network Configuration Protocol (NETCONF) enables standard and efficient automation of

configuration management on network devices.

Yet Another Next Generation (YANG) enables simple and efficient modeling of services and devices.

Cisco NSO provides a series of unique capabilities:

A rich and diverse set of northbound APIs and software interfaces that allow straightforward
integration into existing business systems and operational tool chains, allowing control of everything
from simple device turn-up and configuration management to sophisticated, full lifecycle service
management

A multivendor device abstraction layer that uses Network Element Drivers (NEDs) to mediate access
to both Cisco and more than 170 other-party physical and virtual devices

Globally scalable, highly available data store for both configuration and state information.

Sophisticated integrated tools for maintaining state integrity, troubleshooting, and auditing

Extensibility through custom development or through prebuilt function packs for use cases such as
NFVI MANO and Secure Agile Exchange.

Answer

The correct answer is Traffic analysis and capacity planning. This answer is correct because Cisco WAE
is specifically designed to offer these functionalities,aiding in network optimization. The answer A
comprehensive graphical view of network topology is incorrect because it describes a feature of
Cisco EPNM. The answer Services automation across virtualized networks is incorrect because this
function refers to Cisco NSO's capabilities. The answer Point-and-click provisioning of Ethernet
services is incorrect, because this function is a feature of Cisco EPNM.

Summary

There are several Cisco automation platforms that can be used to automate networking devices with
Cisco IOS XE Software, Cisco NX-OS, and Cisco IOS XR systems. These platforms include Cisco Catalyst
Center, Cisco ACI, Cisco Nexus Dashboard, and Cisco IOS XR-focused solutions such as Cisco EPNM,
Cisco WAE, and Cisco NSO.

After completing this course, you will be able to address the following questions:

What is a Cisco Catalyst Center solution and what are its features and benefits?

What are the features and architecture of a Cisco Application Centric Infrastructure and Cisco Nexus
Dashboard solutions?

What are the management and automation solutions for Cisco IOS XR devices?

What are the main features of Cisco EPNM, Cisco WAE, and Cisco NSO?