| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
SNMP Protocol Message Generation, Addressing, Transport and Retransmission (Page 2 of 3) SNMP Message Transport Using UDP The standard IP transport mapping for SNMP calls for it to be carried using UDP. This decision goes back to the initial implementation of SNMPv1 (before there were distinct transport mappings.) UDP was likely chosen because it is more efficient for the simple request/reply messaging scheme SNMP uses; the many TCP features were not considered necessary and add overhead that SNMP's designers wanted to avoid. It is possible that TCP could be used to carry SNMP, defined as a different transport mapping, but I don't believe this is actually done. Two well-known UDP port numbers are reserved for SNMP. The first is port 161, which is the general-purpose SNMP number. All devices that are set up to listen for SNMP requestsboth agents and managerslisten on port 161. Each device receives any messages sent and replies back to the client, the SNMP entity that issued the request, which uses an ephemeral port number to identify the requesting process. The second UDP port number is 162, which is reserved for SNMP traps. Having two numbers allows regular messages and traps to be kept separate. Normally only NMSes would listen on port 162, since agents are not recipients of traps. The use of UDP allows SNMP information communication to be streamlined, since there is no need to establish a TCP connection, and since message headers are shorter and processing time slightly reduced. But the use of UDP introduces a couple of issues that SNMP implementations must be concerned with. The first issue is that of message length. SNMP PDUs can carry many MIB objects, which means they could potentially be rather large. However, UDP is limited in the size of message it can carry (where TCP is not). The standards specify that SNMP entities must accept messages up to at least 484 bytes in size. They also recommend that SNMP implementations be able to accept even larger messages, up to 1472 bytes, which would correspond to the largest size message that can be encapsulated in an Ethernet frame (1,500 bytes, allowing 20 bytes for the IP header and 8 for the UDP header.) The use of the GetBulkRequest-PDU message type in SNMPv2/v3 requires particular care, since it allows a single request to result in many MIB objects being sent back in a response. The Max Repetitions parameter must be chosen conservatively so the SNMP agent doesn't try to send an enormous message that won't fit.
Home - Table Of Contents - Contact Us The TCP/IP Guide (http://www.TCPIPGuide.com) Version 3.0 - Version Date: September 20, 2005 © Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. |