1 / 16

SNMP Simple Network Management Protocol

SNMP Simple Network Management Protocol. SNMP Overview. Define mechanism for remote management of network devices (routers, bridges, etc.) Fundamental principle: all device management done by simple variable value manipulation Approach:

aden
Download Presentation

SNMP Simple Network Management Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SNMPSimple Network Management Protocol

  2. SNMP Overview • Define mechanism for remote management of network devices (routers, bridges, etc.) • Fundamental principle: all device management done by simple variable value manipulation • Approach: • standard means for specifying quantities recognized by devices • protocol for requesting, returning, notifying of changes of values

  3. SNMP Message Protocol • Messages use UDP, ports 161 (requests/responses) and 162 (notifications) • Message types: • GetRequest: request values of variables from device • GetNextRequest: request value of variable following the one supplied • GetResponse: return values • SetRequest: instruct device to set values of variables • Trap: from device - notify monitor / manager of value change

  4. SNMP SMI(Structure of Management Information) • Variables recognized by device supplied in MIB (Management Information Base) • text file giving variables and data structures defined using ASN.1 • standard variable sets often provided as RFC’s • device-specific sets provided by vendors • Management stations parse MIB’s to determine variables available for management • obtain both data structure and management information

  5. Example portion of MIB (from RFC 1213) -- the Interfaces group -- Implementation of the Interfaces group is mandatory for -- all systems. ifNumber OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The number of network interfaces (regardless of their current state) present on this system." ::= { interfaces 1 }

  6. ASN.1 Object Identifiers • Variables identified by globally unique strings of digits • ex: 1.3.6.1.4.1.3.5.1.1 • name space is hierarchical; tree on next slide • in above, 1 stands for iso, 3 stands for org, 6 stands for dod, 1 stands for internet, 4 stands for private, etc. • Variable names are aliases for digit strings (within MIB) • From previous page: ifNumber ::= { interfaces 1 } • interfaces was previously defined in MIB as 1.3.6.1.2.1.2, so ifNumber = 1.3.6.1.2.1.2.1

  7. Partial ASN.1 Object Identifier Tree

  8. SNMP Environment Network Manager Gateway Host/User Station MIB Manager process Manager process Manager process User Proc. SNMP SNMP SNMP FTP etc. UDP UDP UDP TCP IP IP IP Network dependent protocols Network dependent protocols Network dependent protocols Internetwork

  9. SNMP Specific Problems • Work on SNMP security took many many years to finally result in a stable and accepted SNMPv3 specification • Inefficiency of SNMP for retrieving bulk MIB data

  10. SNMP Bulk Retrieval Problem • Problem: • SNMP shows poor performance when retrieving several thousands of MIB variables in a single logical transaction • Reasons: • Lack of flow control • Bandwidth inefficiency due to OID naming overhead • High latency caused by a large number of request/response interactions

  11. Proposal #1: SNMP over TCP • SNMP over TCP gives flow and congestion control for virtually no costs • Originator of a request/response transaction chooses the transport for one or more complete transactions • SNMP engines can close TCP connections at any point in time • SNMP engines may revert to SNMP over UDP when needed • SNMP engines must perform packetizing and connection management

  12. Proposal #2: Lossless Payload Compression • Compress and wrap SNMP PDUs in a CompressedPDU • Each SNMP message is compressed and decompressed by itself without any relation to other SNMP messages (stateless compression) • The size of a compressed SNMP message must never exceed the size of the uncompressed message (non-expansion policy) • Support for multiple compression algorithms • Negotiation of compression algorithm via MIB objects

  13. Proposal #2: Lossless Payload Compression • Deflate: • Deflate achieves high compression ratios of 80 % on typical MIB-II data • Requires noticeable CPU resources on the sending SNMP engine • Interactions with message size constraints make it difficult to build response messages that send as much data as possible

  14. CG CR CG CR CG CR CG CR GetNext (rows in parallel) GetNext (row by row) GetBulk GetSubTree Proposal #3: Get-Subtree / Linked Responses

  15. Proposal #3: Get-Subtree / Linked Responses • The format of get-subtree PDUs is similar to the format of the get-bulk PDU, except that there is no max-repetitions parameter • Linked response PDUs are ordinary response PDUs where the error-index contains a sequence number if the error-status is noError • Measurements over the loopback interface on a Linux box show that get-subtree is 4.5 times faster compared to get-next walks and 2 times faster than get-bulk walks

  16. End of First Lecture

More Related