Simple Network Management Protocol (SNMP) is a well-known standardized application layer protocol, originally developed for network management but mostly used for network monitoring. SNMP is designated to monitor a large number of different objects (object identifiers or OIDs) as long as managed entities and a management station speak the same language. It is achieved by the same Management Information Base (MIB) file loaded in managed devices and the Network Management Station (NMS). The MIB contains a set of defined OIDs ensuring that the managed devices and NMS can communicate together. This enables SNMP to monitor almost any object, such as a printer’s toner status, room temperature or in a case of a network device, incoming and outgoing traffic, the rate of package loss and a lot more.
In contrast to SNMP, NetFlow was designed with network traffic monitoring in mind. NetFlow enabled device examines each packet and the first unique packet creates a flow as an entry in NetFlow cache. The other packets matching the same parameters are aggregated to this flow and the bytes counter for the flow increases. If any of the parameters do not match, a new flow is created in the cache. Flow records are then exported from exporters to one or more NetFlow collectors. However, if a NetFlow enabled device does not receive IP traffic, flows are not created in the cache thus they are not exported to a collector. This mechanism is similar to SNMP traps that are sent to NMS once an alarm is raised.
Now let’s talk about the differences and similarities between SNMP and NetFlow in more details.
SNMP operates in both push and pull mode. In the push mode, a managed device sends traps to an NMS upon a certain event, for instance when values exceed the defined limits (alarms). In the pull mode, an NMS periodically sends SNMP get-requests to a managed device, requesting the SNMP agent that is running on a managed device to sent OID values. The device then replies to NMS with the SNMP get-responses, carrying the OIDs with their measured values.
Similar to SNMP, NetFlow works in a push mode, sending flow records from a cache to a flow collector. A flow is exported from the exporter (NetFlow enabled switch or a router) based on inactive flow timer when no other packets are received for a particular flow within an inactive timer (by default 15 seconds). A flow may be also exported when an active timer is reached (by default 30 minutes) and another packet of the same flow enters the interface with an enabled flow export. In both cases, flow records are pushed out of the exporter without being requested by the collector.
SNMP collects information about bandwidth usage of network devices on a port-by-port basis. It perfectly addresses the question of how much bandwidth is being used. However, SNMP can also monitor parameters such as CPU utilization, memory, disk consumption or temperature. Something that the NetFlow is not used for. There is a proof of concept, however, where the room temperature was exported to a flow collector inside the IPFIX (a modern NetFlow standard) messages.
SNMP is doing great in gaining network visibility and measuring network bandwidth usage. Nevertheless, it is not very good at providing details that would help network admins to understand what is going on with their networks. SNMP completely lacks the information such as who (source hosts), is doing what (the type of traffic) and where (destination hosts) (Picture 1).
Picture 1: SNMPv1 Query Response with OID Values
These limitations bar network admins from determining the root cause of issues that degrade network performance such as DDoS, misconfiguration, excessive bandwidth utilization (file sharing, social networks, streaming services) etc. In contrast to SNMP, NetFlow is good at delivering all this information in the form of NetFlow records. It allows a network admin to characterize traffic based on parameters such as source IP address (IP 23.67.156.61), the destination IP (172.16.2.1), application protocol (SSH), number of packets (1) (Picture 2).
Picture 2: NetFlow v9 Packet
SNMP datagrams are continuously sent across the network in real-time (i.e. every second) as responses to SNMP queries, while the exporting of NetFlow records depends on active/inactive timers. It may take up to 30 minutes to export a flow when NetFlow is used. Obviously, SNMP is better in traffic visibility than NetFlow. This issue may be solved by using sFlow instead of NetFlow. sFlow does not cache data, instead sFlow datagrams are sent in real-time to a collector where they are analyzed.
SNMP is defined in RFC 1157 (August 1990) but the design of SNMPv1 was done already in the 1980s. Since then SNMP has been widely adopted by all network vendors. Even the new generation of network devices that support NetFlow still support SNMP. The Cisco flow switching concept that the NetFlow is based on was introduced around 1996. Therefore, NetFlow is a much younger protocol and is not implemented in all network devices.
SNMP is limited to the use of UDP as a transport protocol while modern NetFlow versions (v9) can also use Stream Control Transmission Protocol (SCTP) when a reliable transport is required.
SNMP and NetFlow offer two different approaches to network monitoring. Wide vendor adaption, real-time characteristic and low resources consumption (mostly the older SNMP version 1 and 2 without authentication and encryption) speak for the use of SNMP whenever possible. Moreover, SNMP plays a key role in fault management where it can detect or even prevent hardware failures. All of this lets us assume that SNMP will be used for years to come despite its obvious limitations. On the other hand, SNMP lacks accuracy provided by NetFlow so it cannot qualify in traffic analysis. Therefore, if applicable, combine both methods for network monitoring. SNMP for fault management and quick network performance overview while NetFlow for accuracy in the estimation of network traffic parameters.