Browse Prior Art Database

SNMP GET/SET MUX AGENT

IP.com Disclosure Number: IPCOM000008290D
Original Publication Date: 1997-Sep-01
Included in the Prior Art Database: 2002-Jun-04
Document File: 3 page(s) / 154K

Publishing Venue

Motorola

Related People

Pat Chan: AUTHOR [+2]

Abstract

SNMP V.1 is the Internet network management protocol standard'. The protocol specifies two entities, namely the manager and the agent. The protocol allows four operations between the manager and the agent; GET, GET-NEXT, SET and TRAP One responsibility of the SNMP agent is to listen to the SNMP port (161) for requests from the manager. Upon receiving requests, it performs the operations (GET, GET-NEXT or SET) on the management information base (MIB) of the managed object accordingly.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 49% of the total text.

Page 1 of 3

0 M M-LA

Technical Developments

SNMP GET/SET MUX AGENT

by Pat Chan and Qing Zhang

1.0 INTRODUCTION

  Background: SNMP V. 1 is the Internet network management protocol standard'. The protocol specifies two entities, namely the manager and the agent. The protocol allows four operations between the manager and the agent; GET, GET-NEXT, SET and TRAP One responsibility of the SNMP agent is to listen to the SNMP port (161) for requests from the manager. Upon receiving requests, it performs the operations (GET, GET-NEXT or SET) on the management information base (MIB) of the managed object accordingly.

  A problem arises when two or more SNMP agents in one network node want to listen to the same port (161), but only one agent will be allowed. This is often the case when the operating system (like Solaris) provides a SNMP agent to manage the hardware platform and the application has its own SNMP agent to manage the application specific objects.

  The way to solve the problem is to create a master agent which is listening to the SNMP port (161), and multiplexing the incoming SNMP requests from manger to sub-agents. After receiving responses from the sub-agents, it forwards them back to manager. See the following figure.

;ii-i$

<

mnp rolocol

16

managed obj@ I-

--.

Currently, there are a number of different ways to implement this approach:

the manager has to treat each sub-agent on the network node as a separate SNMP agent instead of one SNMP agent for one network node.

  Both approaches are not desirable if one sub-agent does not support SMUX or DPI, and you want the multiple sub-agents to behave as if there is only one agent managing all the objects within the network node. This is exactly what we want to achieve with our mux agent.

Using the protocols like SMUX and DPI to pass information between the master agent and sub-agents. This requires both master agent and sub-agent to support SMUX or similar protocols.

l

Using a community name in each SNMP request to identify the sub-agent. The problem with this implementation is its lack of transparency. That is,

l

Q M.ammls, ,"C. ,997 82 Seprember 1997

[This page contains 15 pictures or other non-text objects]

Page 2 of 3

M-A Technical Developments

@

2.0 ALGORITHM DESCRIPTION

  The key idea of the algorithm is to look into the variable list of each SNMP request, find out the sub-agent(s) which are responsible for the requested information, and then forward the request to the relevant sub-agents(s). The difficult part is to handle a single SNMP request which needs to access infor- mation across multiple sub-agents.

  We have designed a Split-and-Merge algorithm to solve the problem. The precondition in this algo- rithm is that the sub-agent is a fully functional SNMP agent which listens to a port other than SNMP port 161. Each sub-agent is configured to manage a number of non-overlapping subtrees of managed information base.

The Split-and-Merge algorithm works in the following way.

Each SNMP request contain...