Cisco Network Mgmt Protocol FAQ: Common Management Protocols
Q1. Why is SNMPv1 not considered secure? How could a hacker exploit its security holes?
Answer: SNMPv1’s only security mechanism is a community string that is part of SNMP messages, which is communicated in the clear. For example, it does not offer authentication, which would enable an agent to ascertain the identity of a manager, or encryption, which would prevent SNMP messages from being seen by others or tampered with. A hacker could exploit the lack of authentication by sending unauthorized commands to a device that might alter its configuration, for example, to steal service or to sabotage the network. For this reason, many agents do not allow their configurations to be modified through SNMP and limit SNMP’s use to monitoring, where exposure to security holes is less critical.
Q2. One of the advantages of SNMPv1 lies in the simplicity of its agent implementations. Does this simplicity also have drawbacks?
Answer: The simplicity means limited power, which, in turn, means that management applications have to do more work. Note also that SNMPv3 is much more powerful and, hence, less simple than the original SNMPv1.
Q3. Explain the difference between an SNMP trap and a syslog message.
Answer: The information that is conveyed as part of a trap is formally defined in a MIB specification. A syslog message is much more ad hoc and informal; the contents carried in its body part are typically not formally defined.
Figure: syslog Message Structure According to IETF
Q4. What is the most important reason CLI is hard to use for management applications?
Answer: Screen scraping—that is, interpreting the returned results, which can take vastly different formats and, therefore, are difficult to parse and process in a generic manner.
Q5. In what way do CLI and syslog complement each other?
Answer: CLI provides for request-response–based management interactions and does not address events, whereas syslog addresses events but not request-response–based management interactions.
Q6. SNMP has a specific concept of MIBs. Where is the MIB in Netconf?
Answer: The MIB consists of the datastore that contains the management information of the device, which can be subjected to the Netconf operations. Specifically (for configuration management information), the MIB is the running config.
Q7. One criticism in conjunction with SNMP concerns reliability because SNMP in general uses UDP as a transport, in which packets (and, hence, SNMP management requests or responses) can be dropped. Describe an obvious way of handling reliability in Netconf.
Answer: Specify reliability as a requirement for the Netconf transport in the application protocol layer.
Q8. File transfer protocols allow the transfer of files between two locations. Netconf operations have some resemblance to file transfer protocols, in that they allow the copying, transfer, and deletion of config files. Name three ways in which Netconf differs from a simple file transfer protocol for configuration files.
Answer: 1) edit-config of a running config causes commands within a configuration file to be executed, not merely transferred. 2) Additional capabilities, such as validation of config files or (again, linked to the execution of commands within a config file) rollback on failure.
3) Subtree filtering, allowing to process only subconfigurations within a configuration file.
Q9. What is a flow in Netflow?
Answer: A flow is a set of IP packets that traverse a router and that apparently belong to the same communication context, as defined by seven parameters: the source IP address and port, the destination IP address and port, the protocol type, the type of service (TOS), and the interface that the IP packets were received on.
Q10. We stated that Netflow can help you identify the top talkers in your network. How? (You may assume that each talker connects to your network using a static IP address—that is, an IP address that does not change.)
Answer: You collect flow information from all your access routers. For each router, you aggregate the flow information for each source IP address, adding the traffic totals from each flow. At the end of this exercise, you can stack rank the addresses from which the most amount of traffic originated. Clearly, with the volume of Netflow records, a lot of number crunching will be required. (Note that in the case of dynamic IP addresses, you also need to reconcile the flow information with the records of who had what IP address at what point in time.)