Immediate Network Synchronization with Low Overhead: Cisco Prime Network Reduced Polling VNE
PDF(675.6 KB) View with Adobe Reader on a variety of devices
Updated:March 13, 2015
Cisco Prime™ Network's near real-time model relies on accurate information about the managed network typically obtained through repeated polling of network elements that imposes an overhead burden on devices, the telemetry network, and Cisco Prime Network servers. To relieve this burden, the Reduced Polling virtual network element (VNE) has been added to Cisco Prime Network's VNE framework. The Reduced Polling VNE implements a low-overhead method for keeping Cisco Prime Network's device information synchronized with network elements in a timely manner without the drawbacks of repeated polling. Network users can expect to see a vast reduction in polling compared to repeated polling.
Cisco Prime Network brings a new level of control to users for managing individual devices across the network. In addition to supporting a wide range of network elements, new capabilities within Cisco Prime Network provide complete visibility into each device's logical and physical configuration, software image, dynamic characteristics, and relationships to other devices. Users are able to take advantage of these capabilities, which are integrated to work across all Cisco
® devices as well as many non-Cisco products, even in networks with elements from multiple vendors.
Timely access to comprehensive device information is critical to improving network efficiency and avoiding costly downtime. As a consequence, maintaining an up-to-date database of each device and its complete profile is essential. For some network elements, particularly those supporting large numbers of interfaces and subinterfaces, traditional polling methods using either command-line interface (CLI) commands or Simple Network Management Protocol (SNMP) requests can result in extensive queries or bulk data retrievals, which can negatively affect performance.
With the increase in device visibility and the amount of information that must be kept updated, network users need a more efficient alternative to traditional polling methods. The introduction of the Reduced Polling VNE capabilities in Cisco Prime Network gives network users the ability to maximize visibility and productivity without overwhelming the network elements being managed: a typical device is polled 85 percent less compared to standard polling. The result is a network carrying significantly fewer queries retrieving less data to dramatically improve CPU loading, telemetry bandwidth, and Cisco Prime Network server processing efficiency.
The benchmarks in Table 1 illustrate the drastic reduction in commands sent by Cisco Prime Network to a network element when the Reduced Polling VNE is enabled. Command counts were collected from a 7600 Series Router and an ASR 9000 device located within a Carrier Ethernet network. The network was configured with Multiprotocol Label Switching (MPLS), Virtual Private LAN Services (VPLS), and corresponding pseudowires traversing the MPLS network. Data was collected for a 1-hour period after initial discovery and after the VNE reached the operational state. Total commands include SNMP and Telnet commands.
Table 1. Total Commands Sent with Periodic and Reduced Polling
Total commands sent to network element in 1 hour when
Reduced polling is turned off
Reduced polling is turned on
Percentage reduction in commands
As expected, a reduction in CPU load on network elements was also observed. Figure 1 shows the drastic reduction in CPU load observed on the ASR 9000.
Figure 1. CPU Load Example
Managing Dynamic Configuration
When a new network element is first added to the network, Cisco Prime Network performs a complete discovery of all aspects of the device. Some of these aspects, such as what software the device supports and how its interfaces are configured, are defined during the provisioning process. There are hundreds of details, however, that can change dynamically as part of regular operation as elements adapt to the network, such as whether a port is primary or alternative, which VLANs are configured over a port, remote IDs, and which device serves as a designated root for spanning tree protocol operations.
It is important for network users to have knowledge of every change in configuration to most efficiently manage the network. At the most basic level, users need to be able to confirm that devices are still available and are configured as expected. At a higher level, this information can be used to analyze network performance to improve efficiency and reduce operating costs.
Cisco Prime Network presents device information in a context that facilitates both managing individual elements and the network as a whole. Network users can view the physical characteristics of an element (see Figure 2) such as what it looks like and its connectivity. For example, if the device is a chassis, network users will be able to see what is in each of its slots. Also available is the logical connectivity of the element (see Figure 3), including whether it is part of an MPLS VPN, tunnel, or Label Switched Path. User-defined characteristics, such as the device's software configuration and relationships to other devices, are also available.
Figure 2. Network Element Physical Characteristics
Figure 3. Network Element Logical and Physical Connectivities
All of this information is collected in a central location by Cisco Prime Network to greatly simplify operations across the entire service lifecycle - design, fulfillment, assurance, and analysis - of the network. This helps enable network users to navigate easily between network elements while lower operating costs, accelerating deployment, increasing efficiency, and reducing downtime.
Understanding Reduced Polling
For a network management system to maintain a detailed and up-to-date representation of a network element's physical and logical configuration, the network management system needs to detect device configuration changes in a timely manner. Typically, changes to device configuration are detected by polling the network element in preconfigured intervals ranging in frequency from 3 to 15 minutes, depending upon the network. Queries that detect configuration changes result in a data retrieval request to synchronize the device with the management system.
Cisco Prime Network uses Cisco's extensive expertise and experience in understanding the nature of today's complex networks. Through comprehensive field studies of real-world networks, Cisco has identified a cost-effective means for updating the management database without adversely affecting performance or compromising the integrity the network.
In traditional periodic polling:
• Repetitive queries are sent to devices that have not changed configuration since last being checked.
• The entire device configuration is retrieved periodically even though most of the configuration remains unchanged.
• Device bandwidth and CPU utilization are reduced to handle repeated queries.
• Excessive and reoccurring high CPU load on the management server is required to manage the large numbers of repeated queries.
The Reduced Polling VNE replaces periodic polling with intelligent mechanisms that reduce the CPU utilization and bandwidth required to track configuration changes:
• Active updates: When a configuration change occurs, devices alert Cisco Prime Network to the change rather than requiring to be polled. Upon receiving an alert, Cisco Prime Network will then update its database. On average, active updates occur at a much lower frequency than updates made on a standard, 15-minute polling schedule. This eliminates repetitive and unnecessary queries, a substantial number, as Figure 1 showed.
• Reduced polling frequency: Some periodic polling is required (1) to confirm that stable devices that haven't been heard from in a while are still active and (2) just in case a change alert fails to reach the central manager. When combined with active updates, however, a much lower periodic polling frequency is required. By default Cisco Prime Network will synch every 24 hours unless the Failsafe mechanism is enabled (in this case it will check for all changes that occurred during a user-defined time interval).
• Partial data retrieval: When a change occurs, rather than collect the entire profile again, only those portions of the profile that are anticipated to have changed are retrieved. This significantly reduces the amount of data transferred between network elements and Cisco Prime Network.
• Increased device resources: Fewer queries eliminate CPU spikes and reduce average CPU load on devices.
• Available server resources: Cisco Prime Network servers have more processing resources available for other tasks.
• Real-time inventory: Configuration profiles managed through intelligent polling are more up to date compared to periodic polling because changes are captured immediately.
With the innovation of the Reduce Polling VNE, Cisco Prime Network is able to maintain a complete and up-to-date database quickly, efficiently, and reliably. Not only is the load on the network reduced, scalability is improved as a larger number of devices can be managed without overloading the management server.
The rest of this white paper will provide greater detail on how to implement the Reduced Polling VNE.
Reduced Polling VNE Alerts
Network elements support the Reduced Polling VNE by sending an alert when a configuration change on the device has occurred. A Cisco device does this by generating a configuration change syslog message (Figure 4).
%MGBL-CONFIG-6-DB_COMMIT: Configuration committed by user 'anauser'. Use 'show configuration commit changes 1000001755' to view the changes.
Cisco IOS configuration change syslog example:
%SYS-5-CONFIG_I: Configured from console by vty1 (172.23.95.46).
Cisco Prime Network receives the syslog message and queries the command history archive on the device to identify the exact commands executed on the device that resulted in a change on the device ("show archive config" for Cisco IOS based devices, "show conf commit" for Cisco IOS XR). Cisco Prime Network uses these commands to identify the component or components in Cisco Prime Network's VNE model that need to be updated.
For each model component, Cisco Prime Network contains a preconfigured query for retrieving related updates from network elements. Cisco Prime Network assembles the set of queries needed to update the previously identified model components and then polls the network element by issuing this set of queries. These queries, issued as CLI commands or SNMP requests, retrieve the needed information from the network element. Cisco Prime Network uses the retrieved information to update its VNE model.
Efficient Handling of Rapid Successions of Configuration Changes
Cisco Prime Network may receive multiple configuration change syslog messages from the same device in rapid succession. To help the Reduced Polling VNE handle rapid configuration changes, a throttling mechanism can be used (this option is disabled by default). When the initial configuration change syslog is received, the throttling mechanism triggers a timer that causes the Reduced Polling VNE to wait for a preconfigured interval (manually defined once this feature is enabled). During this wait interval, any additional configuration change syslog messages Cisco Prime Network receives from the same device are collected and collated. When the timer expires, the Reduced Polling VNE queries the command history archive and then retrieves the corresponding configuration changes. The throttling mechanism is also reset to trigger with the next configuration change syslog (see Figure 5). The throttling mechanism can be applied to either specific VNEs or device types. Please refer to the Cisco Prime Network Administration Guide for registry configuration command.
Note: The throttle is disabled by default. It can be enabled and administered using Cisco Prime Network registry techniques.
Figure 5. Throttling Configuration Changes
Handling Loss of Configuration Change Syslog Messages
Since syslog messages are sent using the User Datagram Protocol (UDP), it is possible that some configuration change syslog messages may fail to reach Cisco Prime Network. The following options are available to counter loss of configuration change syslog messages:
• Wait for the next configuration change syslog message: Upon reception of a configuration change syslog, previously missed configuration changes are available in the command history archive on the device. The Reduced Polling VNE retrieves the configuration changes and updates the VNE representation. This method works best when configuration changes are frequent. The primary drawback of this method is that a missed configuration change may go unnoticed for an extended period of time if configuration changes for this device are infrequent.
• Archive log monitoring (Failsafe) mechanism: When the Failsafe mechanism is enabled, the Reduced Polling VNE checks the command history archive on the device in 15-minute intervals to identify if any new configuration commands were executed. Note that polling the command history archive has a minimal impact on the overall device CPU utilization while guaranteeing that configuration changes are captured within 15 minutes of being implemented. Please refer to the Cisco Prime Network Administration Guide for registry configuration change command.
• Configure the network element to send syslog messages as SNMP Inform messages: Using the CISCO-SYSLOG-MIB, syslog messages can be transferred reliably as SNMP Inform messages.The Reduced Polling VNE can rely on change notifications to poll for device configuration changes only when changes occur.However,since SNMP Inform messages are acknowledged messages, the overhead for message transfer and processing doubles.
• Poll Now used at granular level: When users suspect that some configuration updates were missed for a particular feature of a device, they can make use of the Poll Now option available at the granular level. This is very lightweight and specific to the component to be updated.
• Poll Now used on demand: When users suspect that some configuration updates were missed across technologies, they can execute the Poll Now option from the Cisco Prime Network Vision user interface or through the Cisco Prime Network API for that VNE. The Poll Now option will retrieve the complete device configuration information and remodel the entire device representation within Cisco Prime Network. Since Poll Now can be time consuming and expose the network element to the burden of a complete polling cycle, this option is offered primarily as a last resort and intended to augment the other options.
• Wait for the system interval cycle: Cisco Prime Network checks network elements for changes at the end of each system interval, which is typically set to every 24 hours. If no configuration change syslog message has been received by the time the system interval is up, then the Reduced Polling VNE will check the network element and retrieve any missed configuration changes as above. The chief drawback of this method is that a missed configuration change may go unnoticed for as long as 24 hours.
Complete Network Element Configuration Refresh
Whichever option is employed for handling loss of configuration change syslog messages, it is prudent to occasionally refresh the Cisco Prime Network representation of a network element. Cisco Prime Network automatically refreshes its device representation by remodeling the entire device representation in any of the following three situations:
• Poll Now option: As outlined above, the Poll Now option retrieves the complete network element configuration and remodels the corresponding device representation.
• Route Switch Processor (RSP) failover: If Cisco Prime Network detects on a network element an RSP failover condition that may have caused unrecorded configuration changes, Cisco Prime Network will poll for the network element configuration and remodel the device representation.
• Command history archive buffer overflow: The device command history archive buffer contains the configuration commands executed by the device. For Cisco IOS devices, it is possible for the buffer to overflow when a large number of commands have been executed. If some commands are lost, they can be identified by a gap in the buffer, and the VNE assumes itself to be out of synch with the device. VNEs using reduced polling are more sensitive to these overruns due to their different polling frequency. If Cisco Prime Network detects a command history archive buffer overflow condition on the network element, it will proceed to refresh the entire device representation.
The VNE representation refresh is similar to the initial VNE discovery process with the main difference being what triggers the process. As with any discovery process, the VNE refresh has the potential of raising the CPU usage on the device. However, several factors work together to keep CPU usage low: a queuing mechanism controls command execution, the VNE logic reuses command results, and adaptive throttling introduces a delay between commands to spread CPU usage out.
The amount of time needed for the VNE refresh depends on many factors, such as gateway server activities and device and network latency. To help identify when a refresh process is in progress and when it has completed, the VNE moves to the Currently Unsynchronized investigation state and its icon changes to an hourglass (Figure 6).
Figure 6. Currently Unsynchronized
When the refresh is complete, the VNE moves to the Operational state and the hourglass is removed.
Network Elements Supported Through the Reduced Polling VNE
At this point, Reduced Polling VNEs are applied to Cisco devices. In its first release with Cisco Active Network Abstraction (ANA) 3.7.2 (Cisco Prime Network's former name), Reduced Polling VNE support was available for the Cisco ASR 9000, 7600, and CRS-1 Series devices. Since then, support for more device types has been added through monthly Cisco Prime Network Device Package updates.
Table 2 lists Reduced Polling VNE support for Cisco device families in Cisco Prime Network 3.8.
Table 2. Reduced Polling VNE Support
Cisco 10000 Series
Cisco 36xx Series
Cisco 38xx Series
Cisco 45xx Series
Cisco 49xx Series
Cisco ASR 1000 Series
Cisco ASR 9000 Series
Cisco CPT Series
Cisco CRS-1 Series
Cisco Catalyst® 3750ME
Cisco ISR 19xx Series
Cisco ISR 29xx Series
Cisco ISR 39xx Series
Cisco MWR 2900
Cisco Nexus® 50xx Series
Cisco XR 12000 Series
Cisco uBR 10000
Cisco Prime Network Device Package 1.0, released on December 16, 2011, extended Reduced Polling support to the Cisco Nexus 70xx family.
Configuring Devices to Support the Reduced Polling VNE
For a device to support reduced polling, the Config Logger feature needs to be enabled and syslog host should be set to Cisco Prime Network on the device managed as VNE in Reduced Polling mode. Please refer to the device platform reference guide for proper syntax to be used to enable Config Logger.
An example for Cisco IOS devices can be as follows:
logging size 200
Cisco IOS XR based devices have this enabled by default.
Reduced Polling can be enabled or disabled from the Cisco Prime Network Manage administrator user interface when creating a new VNE or editing existing VNE properties.
When creating a VNE, the default polling approach is set to Cisco Prime Network default, which means that Cisco Prime Network controls whether the device is modeled as a regular VNE or a Reduced Polling VNE, depending on the device type. An administrator can also select to model the device as a regular polling VNE or as a Reduced Polling VNE. This selection can be done per VNE instance or as the default for a device type (see Figure 7).
Figure 7. Defining Polling Method
Before selecting the Reduced Polling option, it is recommended to verify that the device or device type is supported through the Reduced Polling VNE. The Cisco Prime Network Manage administrator user interface provides a method for listing the device types supported through the Reduced Polling VNE (see Figure 8).
Figure 8. Supported Device List
Important: Cisco network elements do not generate configuration change syslog messages when configuration changes are made through SNMP. Enabling the reduced polling feature is
not recommended for devices that may be configured through SNMP.
Which polling method has been selected and is currently in effect for a particular device can be checked through the Communication Details view for the VNE (see Figure 9).
Figure 9. Checking Polling Method
Polling Continually Changing Networking Objects
Even with Reduce Polling VNE enabled, Cisco Prime Network will periodically poll for updates from continually changing network objects. Cisco Prime Network obtains updates for continually changing network objects at regular intervals, defined by the administrable Configuration Interval value (typically 15 minutes). These continually changing network objects include routing and forwarding tables, Bidirectional Forwarding Detection (BFD) sessions, label switching (LSP) tables, and so on.