Cisco Network Mgmt Protocol FAQ: Management Organization

Cisco Network Mgmt Protocol FAQ: Management Organization

Q1. Assume that you have to manage an enterprise network with several remote branch locations. You are told that you need to collect performance data from each remote location to assess the total traffic that goes to headquarters, that is directed to other enterprise locations, and that goes to destinations outside the enterprise. Your low-bandwidth WAN connection that leads back to your network operations center doesn’t seem to have enough bandwidth to allow for the export of all the Netflow data from the remote locations. What other options do you have?

Answer: You can deploy a management solution with a remote subordinate management application that collects Netflow data at the remote site, aggregates the desired information, and sends back only the aggregated information to the NOC.

Q2. What is RMON?

Answer: RMON stands for remote monitoring MIB. It refers to a capability to delegate certain management functionality to so-called RMON probes using SNMP. RMON probes reside near the monitored network elements, sometimes in the devices themselves. They offer functions that include threshold-crossing alerts, periodic polling and statistics collection of performance-related MIB variables, and event filtering and subscription capabilities, all of which are remotely controlled through a MIB.

Q3. Give an example of a management task that a management appliance could provide.

Answer: One example is tasks associated with RMON—RMON probes.

Q4. If management by delegation is such a great idea, why don’t we simply delegate all management tasks to the network?

Answer: There are limitations in the processing horsepower that is available, such as CPU and memory. The primary purpose of devices in the network is to provide communication functions; making the job easier for management applications is a distant second. In addition, many tasks don’t lend themselves to delegation, such as tasks that require additional information (for example, customer information) that is not readily available to devices in the network.

Q5. What do the acronyms PDP and PEP stand for?

Answer: Policy Decision Point and Policy Enforcement Point.

cisco-network-mgmt-protocol-faq-management-organization

Figure: Policy-Based Management

Q6. How can policy-based management help scale management?

Answer: Policies provide guidelines for what behavior is expected under certain conditions, without requiring intervention by the upper-layer management system, similar to reflexes in the human nervous system that do not require conscious thought. This frees the upper-layer management system from routine tasks, allowing it to scale better and to cover a larger domain.

Q7. What are the main limitations of syntactical management mediation?

Answer: For one thing, in many cases, not all aspects of the underlying source interface can be hidden. This concerns, for example, the way in which management information is exposed across the interface. In addition, not all features of the target interface can be leveraged. This is specifically the case for functions that are not supported on the source interface, which cannot be emulated using syntactical management mediation alone.

Q8. Why is stateful mediation more complex than stateless mediation?

Answer: Stateful mediation is more complex for a variety of reasons. For example, single operations might need to be broken into multiple operations, their execution kept track of, and results aggregated. The management gateway needs to deal with exceptions when some of the operations fail, having to provide the semantics of a transaction for what are only single operations on the target interface. Also, the management gateway might need to cache information about the underlying network elements, bringing about the need to deal with all the issues usually associated with synchronizing management information. In contrast, stateless mediation requires none of this; it’s a translate-and-forget kind of deal.

Q9. Assume for a moment that you have two fictitious management protocols, SIMP and COMP. SIMP is a very simple protocol, providing only a small set of the most basic management primitives. COMP is much more powerful; it offers all the capabilities that SIMP offers, plus additional functionality. For example, COMP enables you to apply the same management operation to a group of managed objects that meet a certain criteria, and it offers a thresholdcrossing alerting capability, whereas SIMP does not. Now assume that you are asked to build two management gateways, one for SIMP managers to manage COMP agents, the other for COMP managers to manage SIMP agents. Which of the two do you expect to be simpler? Why?

Answer: The gateway that allows SIMP managers to manage COMP agents will be much simpler. The reason is that COMP provides a much richer interface than SIMP. SIMP primitives can most likely be mapped directly to COMP operations. The reverse is not true: Many COMP capabilities will not have an SIMP counterpart. The difference in capabilities will need to be made up by the gateway, requiring functionality that goes well beyond translating from one management message to another.

Q10. Would you expect semantic mediation of management information that involves CLI as the source (agent) interface to be simple or hard? Why?

Answer: This is likely to be difficult. The reason is that interpreting the responses to CLI commands requires screen scraping to properly populate responses for the target interface, and this must be done for a large number of CLI commands.

More Resources

About the author

Prasanna

Leave a Comment