Cisco DNA Centre Assurance provides a tool for handling relevant customer requirements with the following capabilities:
Cisco SD-Access Fabric Configuration
Software Image Management (SWIM)
Simplified Provisioning for Devices
Wireless Network Management
Simplified Security Policies
Plug and Play
Cisco DNA Centre Assurance provides a feature called Network Time Travel in Network Assurance. It allows the network administrator to play back an event that happened in the network at a particular date and time to try locate the source of an issue; for example a user was unable to connect to the wireless network at 3pm.
Network Assurance can show what is happening in the network now plus show what is happening in the network with predicted trends for the future.
If an issue is found, Network Assurance can use artificial intelligence to try provide guided remediation steps to fix the problem.
Network Assurance provides an overall view of the health of the network from wired to wireless clients, to switches and other network devices.
A simple search in Network Assurance can provide all the information needed for a network administrator to troubleshoot an issue, in comparison to multiple show commands being required to be ran on multiple network devices.
The information presented can be as much as:
The device type
The OS version
The MAC address
The IPv4 address
The VLAN ID
When the device was last seen
What network device the device is connected too
Wireless SSID used
Last known location
Network Assurance can provide this information due to the APIs it can use to integrate with technologies such as Active Directory, Identity Services Engine (ISE), ServiceNow and Infoblox.
Network Assurance includes a tool called Path Trace. Path Trace is a visual traceroute tool that can be ran periodically or continuously.
In a larger environment, there may be a need to forward mirrored traffic across multiple switches to reach the traffic analyser.
From the source port, the mirrored traffic placed on a special VLAN called a RSPAN VLAN. The RSPAN VLAN acts differently from a regular VLAN.
Any ports that are associated with the RSPAN VLAN to not learn any MAC addresses. This ensures that the port associated with the VLAN does not try to use the port associated with the RSPAN VLAN to transmit data to a host.
Traffic is flooded out of all ports associated with a RSPAN VLAN. This means that the RSPAN VLAN should not be associated with ports that are not trunk ports between the source port and destination port.
To configure the RSPAN VLAN, on each switch that will partake in forwarding the SPAN traffic, configure the VLAN:
There a number of additional options that can be applied with setting the destination port.
The SPAN session with it’s default configuration copies traffic without any 802.1Q tags or Layer2 Protocols. Adding encapsulation replicate on as an option will include this additional data.
By default the port used for the destination only egresses mirror traffic but drops ingress traffic. Adding a dot1q vlan keyword on the end will expect any received traffic to be encapsulated with the VLAN ID specified. Adding untagged vlan will encapsulate any received traffic in the chosen VLAN.
Verifying the configuration
The configuration can be verified with the command show monitor session followed by the session ID
Switched Port Analyser technologies give a network administrator the ability to see a copy of the traffic that is transmitted on the wire.
The network device when configured with a SPAN technology will mirror all traffic at a data plane level for a specific criteria (port) to a destination. The destination could be a port on the local switch or a remote port connected to a traffic analyser.
Cisco switches provide three types of switched port analysers to make it possible to capture traffic:
Local Switched Port Analyser(SPAN): Capture local network traffic on the switch and send a copy of the network traffic to another port on the switch
Remote Switched Port Analyser(RSPAN): Capture local network traffic on the switch and send a copy of the network traffic through Layer 2 to a remote switch that is connected to a traffic analyser.
Encapsulated Remote Switched Port Analyser (ERSPAN): Capture local network traffic on the switch and send the traffic to a system through Layer 3 routing to a remote device connected to a traffic analyser.
It is possible to gather flows of network traffic as they traverse through devices.
This can be useful for many reasons, for billing or for checking if traffic is flowing optimally through the network.
This is done with Netflow, and requires two parts to be configured for it work, Netflow Data Capture and Netflow Data Export.
The Netflow Data Capture captures the traffic statistics on the network device.
The Netflow Data Export exports this data to a NetFlow collector, such as DNA Center or Cisco Prime Infrastructure.
Before enabling Network on a network device, it is important to note that it is does consume memory on the platform. Ensure the network device has enough memory to support Netflow and usual network operations.
Netflow can capture traffic on both the egress and ingress of a port.
Traffic that can be collected on egress/ingress on Netflow Version 9
IP to IP Packets
Netflow accounting for all IP traffic packets
IP to Multiprotocol Label Switching (MPLS) packets
MPLS to IP Packets
Frame Relay Terminated Packets
ATM Terminated Packets
Netflow collects information based on flows.
A flow is a unidirectional traffic stream that can contain a combination of the below data:
Source IP address
Destination IP address
Source port number
Destination port number
Layer 3 Protocol Type
Type of Service (ToS)
Input Logical Interface
ip flow-export version 9
ip flow-export destination 192.168.1.50 9997
ip flow ingress
ip flow egress
Network can be verified that it is working correctly with the commands show ip flow interface, show ip flow export, show ip cache flow
Enabling NetFlow brings an advantage to network administrators that they can quickly view the top connections on the network device with a simple command, show ip flow top-talkers
It requires a little bit more configuration to enable it on the router in global configuration mode
Flexible NetFlow was developed to provide an option for further network traffic analysis than is possible with normal NetFlow.
Flexible Netflow allows for the use and re-use of configuration components.
Flexible NetFlow allows the use of multiple Flow Monitors at the same time, meaning multiple flow policies can be applied to the same traffic as it flows through the device.
If there two different destinations to put NetFlow traffic, the same traffic can be analysed in two different ways then sent onto two different destinations.
Flexible NetFlow is broken down into four separate components
Flow records are a combination of key and non-key fields. Predefined and user records.
Flow monitors are applied to the interface to monitor network traffic
Flow exporters export NetFlow version 9 data from the Flow Monitor cache to a remote host
A flow sampler samples partial relevant NetFlow data rather than analysing all NetFlow data.
With the use of sampled NetFlow data, it reduces the load on memory and CPU on the network devices. There is a trade off that data collected may not give as accurate conclusions in comparison to all NetFlow data being collected.
Security is driver of the adoption of Flexible NetFlow due to the ability to track all parts of the IP header as well as the packet, normalising it into a single flow.
Flexible NetFlow can create a dynamic cache of each type of flow and filter ingress traffic to a specific destination.
Creating a customised Flow Record can be done with collect and match commands to match a flow record.
The match command is used to select a key field, the collect command is used to select a non-key field.
Value in type of service field
Value in IP Protocol Field
IP Source Address
Source IP Address
IP Destination Address
Destination IP Address
Transport Source Port
Transport Destination Port
Flow Sampler ID
ID number of Flow Sampler
IP Source AS
Source AS number
IP Destination AS
Destination AS number
IP Next-Hop Address
IP Source Mask
Subnet source mask
IP Destination Mask
Subnet destination mask
Value in TCP flag field
Number of bytes in flow
Number of packets in flow
Time Stamp System Uptime First
System uptime when packet was first switched
Time Stamp System Uptime Last
System uptime when packet was last switched
Flow Record Fields
Configuring a flow record is important with Flexible NetFlow as the flow record defines what type of traffic will be monitored and analysed.
Custom flow records can have many different combinations to meet the needs of the configuration required.
To define a flow record:
Define the flow record name
Set a description for the flow record
Set match criteria for key fields
Set non-key field data to be collected
flow record MyFlowRecord
description Capture Flow Record for IPv4
match ipv4 destination address
collect counter bytes
collect counter packets
With a custom Flow Record, they need to be exported with a Flow Exporter.
To create a Flow Exporter
Define the flow exporter name
Set a description for the flow exporter
Specify a destination for the flow exporter
Specify the NetFlow version to be used for export
Specify the UDP port to be used for export
flow exporter MyFlowExport
description My flow exporter
transport UDP 9997
With the Flow Record and Flow Exporter programmed, it needs to be tied together with the Flow Monitor.
The Flow monitor has it’s own cache. The Flow Record earlier describes how that cache is to be used for capturing NetFlow data.
The steps on configuring a Flow Monitor:
Define the flow monitor name
Set a description for the flow monitor
Specify the flow record to be used
Specify a cache timeout
Assign the exporter to a monitor
flow monitor MyFlowMonitor
description Flow Monitor
cache timeout active 60
Turn on Flexible NetFlow
The flow monitor needs to be applied to the appropriate interface where traffic will be captured
ip flow monitor MyFlowMonitor input
Simple Network Management Protocol (SNMP) provides a way for network engineers to get reactive alerts when something changes in the network.
SNMP can be used to configure devices too, but this is less common.
SNMP can send traps to a SNMP collector or network management system in response to a change that has happened in the network.
These traps or events are defined as part of a management information base (MIB). The MIB is a database of parameters that are triggered by these network events.
There are three versions of SNMP, SNMPv1, SNMPv2c, and SNMPv3
SNMPv1 uses a community string for authentication, and offers no encryption on data sent or received.
SNMPv2c again uses a community string for authentication with no encryption. It offers much better error handling and error code information over SNMPv1.
SNMPv3 is a major change to versions 1 and 2c. It can offer authentication based on HMAC-MD5 or HMAC-SHA algorithms in it’s authNoPriv mode.
SNMPv3 can go a step further in authPriv mode and offer encryption with Data Encryption Standard (DES) or Advanced Encryption Standard (AES)
As a result, SNMPv3 offers the most privacy and security options over the other two versions.
Offering username and password authentication over simple community strings is a major step for security in comparison to other versions.
SNMPv1 and SNMPv2c can use access lists to help secure access to their platforms by only whitelisted IP addresses.
Community strings can be set to read-only or read-write; so it can restrict SNMP agents to a ‘observation-only’ mode if set to read-only.
If no version is specified on a network device, SNMPv1 is used by default.
For communications between a network management system and a network device, SNMP use a number of operations
Retrieve a value from a specific variable.
Retrieve a value from a variable within a table
Retrieve a large block of data, such as multiple rows in a table with one transaction rather than multiple
Replies to a get-request, get next request
Stores a value in a specific variable
Sends an unsocialised message from an SNMP agent to a SNMP manager when an event has occurred
Defining a SNMP community
To define a secured SNMP community for SNMP v1 or v2c for the network 192.168.1.0
access-list 10 permit 192.168.1.0 0.0.0.255
snmp-server community SNMPCOMM ro 10
The above will create a read only community with the SNMP community string SNMPCOMM. Any network management server in the subnet 192.168.1.0 – 192.168.1.255 can poll the network device with the community string SNMPCOMM
A network device can be configured to send traps to a network management server.
Debugging can provide important information to a network engineer when troubleshooting an issue. One of the important reasons for enabling debugging is to check at a deeper level why something is not working as it should be.
Debugging can sometimes be too informational, so access lists can be used on some debug commands to restrict the output, for example with debug ip packet <access-list>. Some debugging features allow it to be restricted to an interface rather than all interfaces on a network device.