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
Configuration Templates
Network Assurance
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
Connectivity Status
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.
IP SLA is a tool built into Cisco routers. It allows for the continuous monitoring on parts of the network.
There are number of different types of probes that can be set up with IP SLA to monitor different things, such as:
Delay
Jitter
Packet Loss
Packet Sequencing
Path
Connectivity
Server or Website Download Time
Voice Quality
Configuring an IP SLA
ip sla 10
icmp-echo 192.168.1.50 source-interface GigabitEthernet0/0
frequency 300
The above example will send an ICMP echo to 192.168.1.50 sourced from the IP address on GigabitEthernet0/0 every 300 seconds
The SLA can be switched on with the following command
ip sla schedule 10 life forever start-time now
There is many options on when an SLA should start, and how long it should last for. The above configuration starts the SLA monitoring immediately with no expiration.
The SLA configuration can be viewed with the command show ip sla configuration 10
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:
The most basic form of packet capture, the destination of mirrored traffic configured by SPAN is another port on the local switch.
The source of the packet capture can be one of the following interfaces:
One or more specific switch ports
An entire port channel
All of the ports assigned to a VLAN
There are some considerations when setting up a local SPAN session
Most switches can support more than two SPAN sessions
The source port can not be re-used for more than one SPAN session
Source ports can be switch or routed ports
The destination can not be reused between multiple SPAN sessions
It is possible to saturate the destination port, for example a port channel being mirrored to a single destination port, or a 10Gbps port being mirrored to a 1Gbps port
Specifying a Source Port
The source port can be defined with the global configuration command monitor session <session-id> source.
Complete the command by choosing to mirror a interface or vlan. Finally complete the configuration line on whether to mirror received traffic with rx, transmitted traffic with tx, or both
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
Ingress Traffic
Egress Traffic
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
Configuring NetFlow
config terminal
ip flow-export version 9
ip flow-export destination 192.168.1.50 9997
interface GigabitEthernet1/1
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
Top Talkers
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
ip flow-top-talkers
sort-by bytes
top 15
Flexible NetFlow
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
Flow records are a combination of key and non-key fields. Predefined and user records.
Flow Monitors
Flow monitors are applied to the interface to monitor network traffic
Flow Exporters
Flow exporters export NetFlow version 9 data from the Flow Monitor cache to a remote host
Flow Samplers
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.
Flow Records
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.
Field
Key/Non-Key
Definition
IP ToS
Key
Value in type of service field
IP Protocol
Key
Value in IP Protocol Field
IP Source Address
Key
Source IP Address
IP Destination Address
Key
Destination IP Address
Transport Source Port
Key
Source Port
Transport Destination Port
Key
Destination Port
Interface Input
Key
Interface Received
Flow Sampler ID
Key
ID number of Flow Sampler
IP Source AS
Non-Key
Source AS number
IP Destination AS
Non-Key
Destination AS number
IP Next-Hop Address
Non-Key
Next-hop address
IP Source Mask
Non-Key
Subnet source mask
IP Destination Mask
Non-Key
Subnet destination mask
TCP Flags
Non-Key
Value in TCP flag field
Interface Output
Non-Key
Outbound interface
Counter Bytes
Non-Key
Number of bytes in flow
Counter Packets
Non-Key
Number of packets in flow
Time Stamp System Uptime First
Non-Key
System uptime when packet was first switched
Time Stamp System Uptime Last
Non-Key
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
Flow Exporter
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
destination 192.168.1.50
export-protocol netflow-v9
transport UDP 9997
Flow Monitor
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
record MyFlowRecord
cache timeout active 60
exporter MyFlowExport
Turn on Flexible NetFlow
The flow monitor needs to be applied to the appropriate interface where traffic will be captured
interface GigabitEthernet0/1
ip flow monitor MyFlowMonitor input
Devices can generate large amounts of information.
The information can be sent to the device logging buffer, onto the console screen, or to a syslog server. Different logging levels can be set for all three.
Level Definition
Level
Description
syslog Definition
emergencies
0
System Unstable
LOG_EMERG
alerts
1
Immediate Action Needed
LOG_ALERT
critical
2
Critical Condition
LOG_CRIT
errors
3
Error Condition
LOG_ERR
warnings
4
Warning Condition
LOG_WARNING
notifications
5
Normal but significant condition
LOG_NOTICE
informational
6
Informational Message
LOG_INFO
debugging
7
Debugging Message
LOG_DEBUG
Levels of logging
Logging to Memory Buffer
Logging can be enabled to the buffer with the command logging buffer followed by the logging level chosen numerically (0-7) or by definition (debugging, errors, alerts)
The default size of the logging buffer is only 4096 bytes, so it is a good idea to extend it with the command logging buffer followed by the size in bytes.
Logging to Syslog Server
Logging to a syslog server can be carried out with the command logging host followed by the IP address of the host
To modify the logging level used with syslog, use the command logging trap followed by the logging level of detail required numerically
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.
SNMP Operations
For communications between a network management system and a network device, SNMP use a number of operations
get-request
Retrieve a value from a specific variable.
get-next-request
Retrieve a value from a variable within a table
get-bulk-request
Retrieve a large block of data, such as multiple rows in a table with one transaction rather than multiple
get-response
Replies to a get-request, get next request
set-request
Stores a value in a specific variable
trap
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
Sending traps
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.