By using the SCO SNMP implementation, a network administrator can gather information such as routing entries, interface status, and protocol statistics. If problems are encountered, the administrator can manipulate items such as the ARP cache and the routing table to add, delete, and modify entries.
This chapter describes SNMP commands and files, explains how to configure SNMP, and shows some examples of how you might use SNMP to troubleshoot your network.
See also:
There are three basic components of SNMP: the protocol itself, described in detail in RFC 1157; SMI, the Structure of Management Information (RFC 1155); and MIB, the Management Information Base (RFCs 1156 and 1213).
Systems using SNMP are divided into two categories: management stations (sometimes called ``clients'') and agents (sometimes called ``servers''). The management station is the system that issues a query; the agent is the system that is being queried. Queries are sent and received in the form of Protocol Data Units (PDUs).
SNMP uses object identifiers (OIDs) to provide variables with a name that both the management station and the agent can understand. The Structure of Management Information (SMI) provides a set of rules used in defining objects. A scheme by which objects are grouped together for easier reference is known as a Management Information Base (MIB).
See also:
For more information, see the manual page for
snmpd(ADMN).
Agents and management stations
Although there is no architectural reason that a system
cannot have both types of
functionality, most SNMP agents are found in dedicated routers
and other specialized network equipment that is not capable of acting
as a management station.
The SNMP package included with your SCO system provides the functionality of both an agent and a management station. A system running the software can monitor other systems and be monitored as well.
Using the SCO implementation, time-sharing systems and workstations can act both as an agent and as a management station.
See also:
Although using an unreliable protocol such as UDP may initially seem counter intuitive, it has definite advantages. For example, sending UDP packets over an unreliable network is faster than establishing a TCP connection. This is because SNMP requires only one packet for the request and a second one for the response. On the other hand, all TCP implementations require three packets just to establish a connection.
See also:
A fundamental concept of SNMP is the notion of object identifiers. An object identifier (OID) is a tag that allows a management entity to refer unambiguously to a particular object. Object identifiers are allocated in a tree fashion. The value of the object identifier is a sequence of integers that refer to a particular traversal of the object tree. Figure 10-1, ``Object identifier hierarchy'', shows a portion of the object identifier hierarchy.
The root of the OID tree has no label. Currently, there are three children of the root, ccitt(0), iso(1), and joint-iso-ccitt(2). The ISO node has many children, one of which is org(3), which is allocated for international organizations. Under org(3) is the U.S. Department of Defense, dod(6), which has the child internet(1).
The name { iso org dod internet } is a symbolic representation for the integer series 1.3.6.1. Both refer to the object identifier of the Internet subtree. In practice, 1.3.6.1 can simply be referred to as ``internet''. The terms { iso org dod internet }, 1.3.6.1, and internet are all different ways of identifying the same object. In SNMP PDUs, only the numeric sequences are used.
Figure 10-1 Object identifier hierarchy
To ensure that object identifiers are unique, each organization is responsible for a particular section of the OID tree. Just as ISO and CCITT have responsibility for their portions, the Internet Activities Board (IAB) has responsibility for the internet portion.
To allow vendors to support objects that may not be defined in the standard MIB, the IAB reserves a portion of the OID tree for enterprises MIBs. This provides vendors with the flexibility they need.
The SMI defines basic data types that make it convenient to describe managed objects. These types are: Integer, Octet_String, Object_Identifier, ipAddress, Counter, Gauge, TimeTicks, NetworkAddress, and Opaque. Readers who are interested in the precise semantics of these objects are encouraged to read the RFC for further information.
See also:
An example of a MIB is the Internet TCP/IP MIB, commonly referred to as MIB-II. It includes objects that are associated with TCP/IP variables and SNMP protocol variables. Other MIBs are defined for OSI protocols, Gateway protocols, and other protocols.
The SCO SNMP product supports the standard objects in the following MIBs that are readable and writable. In other words, all writable objects listed can be set and all readable objects can be retrieved using SCO SNMP.
SCO SNMP supports the readable objects in the following MIBs that can be retrieved with SNMP (none of the writable objects can be set).
The SCO SNMP product also supports all the objects under the SNMP Multiplexing (SMUX) group.
Each MIB is divided into logically related groups
of objects. The important ones are:
system, interfaces, tcp, udp,
ip, egp, icmp, and snmp.
These are also the groups under MIB-II.
SCO SNMP supports MIB-II and can therefore
manage all MIB-II objects.
Each object in the MIB has two important characteristics: its object identifier (OID) and its type. Object types are constructed from the fundamental types defined in the SMI.
The system group contains general information about the network node. An example of this is the physical location of the node, for example, ``R&D Facility, 3rd floor machine room.''
The interfaces group contains information about network interfaces, such as Ethernet® and point-to-point links. Information is kept about such items as interface status (for example, up or down), packet counts, and so on.
The rest of the groups contain information about the particular protocol to which they refer. This includes items such as the number of packets received with a particular protocol type and the number of packets received with incorrect checksums.
See also:
Select option 1 to install. When the process completes, you see:
Loading Host Resources MIB..........done
"hostmib" 1.3.6.1.4.1.32.99.1 "aintNoThing"
The output should be similar to the following sample excerpt:
Name: hrSystemUptime.0 Value: 118356496Name: hrSystemDate.0 Value: 07 d0 03 0d 09 06 17 00 2d 00 00
The agent, upon receiving this UDP message, first converts the string of bytes in the message into a form it can understand and then performs authentication checks using the community name field contained therein. Upon passing authentication, the agent takes necessary actions to get or set the variable and issues a response indicating success or failure of the operation, which is then interpreted by the management station.
There are five different types of PDU used in SNMP. They are:
The commands getid and getone use the get operation while the command setany uses the set operation. The commands getnext, getmany, and snmpstat use the getnext operation. Figure 10-2, ``Flow diagram of the get/getnext operation'', and Figure 10-3, ``Flow diagram of the set operation'', illustrate flow sequences that take place during get and set operations.
Figure 10-2 Flow diagram of the get/getnext operation
Figure 10-3 Flow diagram of the set operation
The getnext operation deserves special mention here since it works differently from others. The OID contained in a PDU formed as a result of this operation is taken by the agent, and an object instance whose OID is lexicographically next to this OID is retrieved. For example, referring to Figure 10-3, ``Flow diagram of the set operation'' if the OID contained in a getnext request is 1.3.6.1.2.1.2.2.1.7.2 ifAdminStatus.2, the agent looks for the lexicographically next variable, which could be ifAdminStatus.3, and returns its value. Similarly, when the OID contained in the request is 1.3.6.1.2.1.2.2.1.7.3 (ifAdminStatus.3), the lexicographically next variable chosen by the agent could be 1.3.6.1.2.1.2.2.1.8.1 (ifOperStatus.1). Thus, it can be seen that the getnext operation could be useful in retrieving values of object instances even when the management station is not aware of the instances of an object, as is done by getnext. It could also be useful in retrieving values of all object instances under a subtree of the MIB by starting with the OID of the root object of the subtree, as is done by getmany. Figure 10-4, ``Flow diagram of the trap operation'', illustrates the flow sequence that takes place during the trap operation.
Figure 10-4 Flow diagram of the trap operation
See also:
Because traps are asynchronous messages signaling an event that may require attention, there are no responses from the management station to them. An agent may generate seven kinds of trap:
See also:
When an agent receives a request, it validates the identity (community name, IP address pair) of the sender by comparing it against the list in /etc/snmpd.comm of authorized management stations. If the sender is not listed, or does not have the appropriate access permissions, the packet is discarded. The agent can also be configured to send an authentication trap to a specified group of management stations, informing them that an invalid access has been attempted.
See also:
The SMUX peer is said to be exporting a MIB module containing those objects and is responsible for SNMP operations on all objects within that MIB module. This also allows users to define their own private MIBs, usually called ``enterprise MIBs'', and export them via a SMUX peer process so that objects in that private MIB may be managed from any SNMP-compliant management station.
For example, the GateD routing daemon (see gated(ADMN)) maintains routing and configuration information for the EGP, BGP, RIP, and OSPF routing protocols. In SCO's implementation, the SNMP agent and GateD are separate processes, therefore the SNMP agent cannot access information about the routing protocols directly. Therefore, if a network management station requests that the agent read/modify this information, the SNMP agent cannot do this directly. Instead, the agent forwards the SNMP requests to the GateD process that also acts as an SMUX peer. This peer exports MIB modules containing the objects which represent the information about the routing protocol mentioned above. In the role of an SMUX peer, the GateD process acts on the requests from the agent and sends responses to the agent. The agent then forwards these responses to the management station originating the request.
For an agent to be aware of an SMUX peer and to know what MIB modules the peer is exporting, an SMUX peer, when it starts running, must register with the local SNMP agent and export all the MIB modules it plans to support. The agent checks the registration requests from an SMUX peer against entries in the file /etc/snmpd.peers. If a valid entry does not exist for the peer requesting registration, the agent rejects the registration request.
The fields that comprise the entries in the /etc/snmpd.peers file
are described in
``Configuring the SNMP ``peers'' group''
and
snmpd.peers(SFF).
One of the fields, however, requires more explanation.
This is the priority field.
Each peer registration has associated
with it an integer priority value in the range of 0 to
the maximum value of a 32-bit signed long integer, (2
And what happens when a peer attempts to register a MIB module that encompasses a MIB module already registered by another SMUX peer? When peer B registers a MIB module that encompasses the module registered by peer A, peer B assumes responsibility for managing A's module as well.
A peer's registration request may have a special priority value of -1. When a peer uses this priority to register a MIB module, the agent will assign the highest available priority (that is, the lowest integer value available for that module) to that registration.
Details on the SMUX protocol and development of an SMUX peer may be found in RFC 1227 and the Network Programming Interfaces.
See also:
SNMP is automatically enabled with default configuration files when the system goes into multiuser mode, if the TCP/IP protocol stack is configured on the system. Even with these default configuration files, each site will need to customize its environment. Do this in one of two ways:
Configuring SNMP with the SNMP Agent Manager
Use the
SNMP Agent Manager
to:
The SNMP Agent Manager interface
The SNMP Agent Manager allows you to perform most SNMP
configuration graphically. You can start the SNMP Agent Manager
in any of these ways:
The SNMP Agent Manager's top level and menus are illustrated here:
To configure SNMP:
To limit the list to those hosts matching a certain pattern, enter the pattern (including wildcard characters) in the ``Filter'' field, then click on Filter. Then, select the host name from the list and click on OK.
To sort the list by name or address, click on the appropriate radio button.
Configuring the SNMP ``system'' group
The system group contains the basic
information that the SNMP agent needs. These are:
Generally, only the latter three items need to be updated.
Enter the appropriate information in each field, and click on OK when done.
The last item, SMUX reserved classes, allows you to specify those SMUX MIB classes that may only be managed by the local agent. Any classes not listed here may be, but will not necessarily be, managed by other SNMP agents.
When you make changes to the system group using the SNMP Agent Manager, the information is placed into the file /etc/snmpd.conf:
Example 10-1 Sample snmpd.conf file
descr=SCO TCP/IP Runtime Release 2.0.0 objid=SCO.1.2.0.0 contact=Trevor Jones x 256 location=First Floor Computer Room smux_reserved=sco
The SNMP communities group contains a list of community/IP address pairs identifying those management stations from which the agent on the local host accepts queries. Along with each pair is an access field that controls whether access is allowed, and if so, whether the access granted is read-only or read-write. In addition, the special community public, with an address of 0.0.0.0, restricts or allows access to all other members of the public community.
With the Community Names Editor of the SNMP Agent Manager, you can:
The changes you make are saved to the file /etc/snmpd.comm
when you click on OK in the information screen.
By default, this file originally contains one
entry: public 0.0.0.0 read. This allows
read access to all members of the public community.
The following is an example of /etc/snmpd.comm. In this example, system 10.0.118.6 of community ``mynet.rivers'' is allowed read access only, whereas system 10.0.246.1 of community ``mynet.cities'' is allowed read and write access. Note that the public community default read access has been changed to no access.
Example 10-2 Sample snmpd.comm file
# community address access # public 0.0.0.0 none mynet.rivers 10.0.118.6 read mynet.cities 10.0.246.1 write
With the Trap Configuration Editor of the SNMP Agent Manager, you can:
The changes you make are saved to the file /etc/snmpd.trap when you click on OK in the information screen:
Example 10-3 Sample snmpd.trap file
# community address port # mynet.rivers 10.0.118.1 162 mynet.cities 10.0.246.1 162
See also:
With the Peers Configuration Editor of the SNMP Agent Manager, you can:
The changes you make are saved to the file /etc/snmpd.peers when you click on OK in the information screen:
Example 10-4 Sample snmpd.peers file
# # <name> <object-id> <password> [<priority>] # "gated" 1.3.6.1.4.1.2.3.1.2.1.2 "gated_password" "foo" 1.3.6.1.4.1.4.3.99 "aintNoThing" -1
See also:
Before explaining the SNMP commands in detail, it is useful to explain some of the MIB variables used in the examples.
The following variables are from the system group: sysDescr, sysContact, and sysName. These are the description of the node, the name of the person responsible for the node, and the name of the node.
The following variables are from the interfaces group: ifDescr, ifOperStatus, ifType, and ifPhysAddress variables. These are the name, status, type, and physical address associated with a particular interface.
The following variables are from the ip group, and cover routing table information: ipRouteDest, ipRouteNextHop, and ipRouteType. These are the destination, next hop of the route entry, and the type of route (for example, direct or indirect).
The snmpstat command provides the administrator with an easy way of retrieving information such as routing tables, address translation tables, interface status, and so on. Using snmpstat, a network administrator can quickly detect error conditions on a misbehaving network node.
The remaining commands provide the administrator with the ability to retrieve or modify arbitrary objects. Many vendors have their own enterprises MIBs in addition to the standard MIB. Because these continually evolve, it may well be the case that a particular node maintains information beyond that which can be conveniently accessed via snmpstat. The additional commands can provide access to these enterprises MIBs.
See also:
Using the numeric dot-notation format to identify an object is cumbersome compared to using the text name format. For example, it is easier to talk of ``ifAdminStatus'' than to talk of ``1.3.6.1.2.1.2.2.1.7''. (The object ``ifAdminStatus'' is used here only to compare the two OID formats: text and numeric dot-notation. These commands do recognize the text name ``ifAdminStatus''.)
This limitation is overcome by passing to these commands a definitions
file that maps the OID in numeric dot-notation format into the
text name.
This definitions file is passed on the command line
using the optional argument -f.
The syntax of these commands is
<SNMP command> [-f defns_file] node community other_arguments ...
The definitions file passed to these commands must be a processed version of the file containing the vendor-specific or third-party MIB module. For information on creating a MIB module, see ``MIB modules''. This MIB module must be processed by two commands to create a definitions file in a format that the commands getmany, getnext, getone, and setany can read. Use the commands mosy and post_mosy, in this order, to process the MIB module. See mosy(ADMN) and post_mosy(ADMN) for the command syntax and descriptions.
See also:
The following shows two uses of getone:
Example 10-5 getone example
# getone paris public sysDescr.0Name: sysDescr.0 Value: SNMPD Version 3.0 for SCO UNIX
# getone paris public sysName.0
Name: sysName.0 Value: paris.cities.mynet.com
See also:
The following shows an example of getid:
Example 10-6 getid example
# getid paris publicThe sysUpTime variable is the number of clock ticks since the agent was last restarted; each tick represents 1/100th of a second.Name: sysDescr.0 Value: SNMPD Version 3.0 for SCO UNIX
Name: sysObjectID.0 Value: SCO.1.0
Name: sysUpTime.0 Value: 178892
See also:
The syntax is getnext node community variable.
The following shows an example of getnext:
Example 10-7 getnext example
# getnext paris public ifTypeName: ifType.1 Value: 6
# getnext paris public ifType.1
Name: ifType.2 Value: 6
# getnext paris public ifType.2
Name: ifType.3 Value: 24
# getnext paris public ifType.3
Name: ifMtu.1 Value: 1500
See also:
The following is an example of using getmany to get the system group.
Example 10-8 getmany example
# getmany paris public systemName: sysDescr.0 Value: SNMPD Version 3.0 for SCO UNIX
Name: sysObjectID.0 Value: SCO.1.0
Name: sysUpTime.0 Value: 206730
Name: sysContact.0 Value: Trevor Jones x256
Name: sysName.0 Value: paris.cities.mynet.com
Name: sysLocation.0 Value: First Floor Computer Room
Name: sysServices.0 Value: 72
See also:
The following shows the results of two getmet invocations:
Example 10-9 getmet example
# getmet paris public Route to: 0.0.0.0 metric1: 2, metric2: 0, metric3: 0, metric4: 0 Route to: 127.0.0.1 metric1: 0, metric2: 0, metric3: 0, metric4: 0 Route to: 10.0.0.0 metric1: 1, metric2: 0, metric3: 0, metric4: 0 Route to: 10.0.118.0 metric1: 1, metric2: 0, metric3: 0, metric4: 0 Route to: 10.0.246.0 metric1: 0, metric2: 0, metric3: 0, metric4: 0# getmet paris public 10.0 Route to: 10.0.0.0 metric1: 1, metric2: 0, metric3: 0, metric4: 0 Route to: 10.0.118.0 metric1: 1, metric2: 0, metric3: 0, metric4: 0 Route to: 10.0.246.0 metric1: 0, metric2: 0, metric3: 0, metric4: 0
See also:
The following shows sample output from a getroute invocation.
Example 10-10 getroute example
# getroute paris public Route to: 0.0.0.0 via: 10.0.246.1 on if: 1 metric: 2 type: 4 proto: 8 Route to: 127.0.0.1 via: 127.0.0.1 on if: 2 metric: 0 type: 3 proto: 2 Route to: 10.0.0.0 via: 10.0.246.1 on if: 1 metric: 2 type: 4 proto: 8 Route to: 10.0.118.0 via: 10.0.246.1 on if: 1 metric: 2 type: 4 proto: 8 Route to: 10.0.246.0 via: 10.0.246.3 on if: 1 metric: 0 type: 3 proto: 2
See also:
The following shows sample output from two getsub invocations:
Example 10-11 getsub example
# getsub paris public 10.0.118 Route to: 10.0.118 via: 1 10.0.246 on if: 1 metric: 2 type: 4 proto: 8# getsub paris public 10.0 Route to: 10.0.118 via: 1 10.0.246 on if: 1 metric: 2 type: 4 proto: 8 Route to: 10.0.246 via: 1 10.0.246 on if: 1 metric: 0 type: 3 proto: 2
See also:
The legal values for the type argument are given in Table 10-1, ``setany type values'', along with their corresponding object types. For a complete explanation of these types, refer to RFC 1155.
Table 10-1 setany type values
--------------------------------------------------------------------- Object type setany type arguments --------------------------------------------------------------------- Integer -i Octet string -o Object identifier -d IP address -a Counter -c Gauge -g Time_ticks -t Display string -s Null -nThe following shows an example of using setany to alter the status of an interface. The status is checked before and after the change to verify that the change took place correctly. Changing the status from 1 to 2 marks the interface as ``down'':
Example 10-12 Altering interface status
# getone paris public ifAdminStatus.2Name: ifAdminStatus.2 Value: 1
# setany paris public ifAdminStatus.2 -i 2
Name: ifAdminStatus.2 Value: 2
# getone paris public ifAdminStatus.2
Name: ifAdminStatus.2 Value: 2
See also:
These statistics displays will, by default, show system and network names. To show numbers instead, select Display Mode from the Stats menu and select numeric.
You can also view these statistics from the command line by
using snmpstat with the options shown above. Its complete
syntax is:
snmpstat [options] [node] [community]
If you specify a community, you must also specify a node name. If no community argument is specified, the default community of public is used.
See also:
The following is an example of using snmpstat with the -s option to retrieve the system group.
Example 10-13 snmpstat system group example
# snmpstat -s paris publicsnmpstat takes care of formatting the information in a way that is easier to understand. For example, snmpstat converts the raw clock ticks of the agent uptime into hours, minutes, seconds, and hundredths of a second.System Group Description: SNMPD Version 3.0 for SCO UNIX ObjectID: SCO.1.0 UpTime: 1 hour, 1 minute, 40 seconds, 95 hundredths Contact: Trevor Jones x256 Name: paris.cities.mynet.com Location: First Floor Computer Room Services: applications, end-to-end
See also:
The display shows:
See also:
The display shows:
You can also use snmpstat(ADMN) with the -t option to view this information.
See also:
The display shows:
In the example shown, five routes are shown for the system paris. Three of them are directly attached. These are the routes for loopback, the local system, and the cities subnet. Two others have been acquired by the RIP routing protocol from the host volga-cities.
You can also obtain this information by using snmpstat(ADMN) with the -r option.
See also:
The display shows:
You can also obtain this information by using
snmpstat(ADMN)
with the -a option.
Viewing active interfaces
You can view cumulative statistics for active interfaces.
From the SNMP
Agent Manager's Stats menu, click on Active Interfaces:
The display shows:
You can also obtain this information by using
snmpstat(ADMN)
with the -i option.
Viewing all objects in an SNMP group
You can view all SNMP objects from the SNMP
Agent Manager's Stats menu by clicking on SNMP Statistics:
You can also obtain this information by using
snmpstat(ADMN)
with the -S option.
See also:
The command trap_rece starts a daemon that displays, to
standard output, information about SNMP traps received at
the host on which it is running.
It must be run with root permissions.
Its syntax is:
trap_rece [-d]
When run with the -d option, trap_rece includes a packet dump in the output display.
A typical use for this command is to test whether an agent is successfully transmitting traps to a specific host. For such a test, include the host in the /etc/snmpd.trap configuration file that the agent uses to determine trap recipients. Start trap_rece on the host intended to receive the trap messages. Start the agent and verify that the intended host received a cold-start trap message.
The command trap_send sends SNMP traps to
management stations.
Its primary purpose is to test whether a management application is
successfully receiving traps.
Its syntax is:
trap_send ip_address community generic_trap_type [ enterprise_specific_trap_type ]
The argument generic_trap_type is an integer
that specifies the type of trap to be generated and sent.
Table 10-2, ``trap_send trap_type values'',
shows the list of legal values for generic_trap_type.
The optional argument enterprise_specific_trap_type
is specified when the value of generic_trap_type is 6.
The meanings and values for
enterprise specific trap types
are defined in the corresponding enterprise
specific MIBs.
Table 10-2 trap_send trap_type values
--------------------------------------------------- Option Description --------------------------------------------------- 0 Cold Start 1 Warm Start 2 Link Down 3 Link Up 4 Authentication Failure 5 EGP Neighbor Loss 6 Enterprise Specific
See also:
See also:
The following example shows how the administrator might proceed. In the example, the setany command line is split with a backslash for clarity. It should be typed in as one line to the shell.
In addition to the new next hop, the administrator specifies the type of route. In this case, the route is an indirect or remote route (type 4), that was reported by snmpstat as rem.
Example 10-14 Correcting routing entries
# snmpstat -r paris public | grep 10.0.118.0 10.0.118.0 volga-cities 2 rem rip net1The administrator could also have deleted the route by setting its ipRouteType to invalid (type 2). This is useful if a routing protocol reacquires the route information automatically.# setany paris public ipRouteNextHop.10.0.118.0 \ -a 10.0.246.1 ipRouteType.10.0.118.0 -i 4
Name: ipRouteNextHop.10.0.118.0 Value: 10.0.246.1
Name: ipRouteType.10.0.118.0 Value: 4
See also:
The following example shows the commands the administrator might use.
Example 10-15 Verifying the origin of a network connection
# snmpstat paris publicActive Internet connections Proto Local Address Foreign Address (state) tcp paris.nntp bach.CS.ESU.EDU.1021 ESTABLISHED
# snmpstat -s bach.CS.ESU.EDU
System Group Description: SNMPD VERSION 9.4.0.0 SUN 3/260 - SUNOS3.5 ObjectID: SNMP_Research_UNIX_agent.9.4.0.3 UpTime: 4 days, 15 hours, 56 minutes, 39 seconds, 74 hundredths Contact: Operations 1-999-555-1040 Name: bach.CS.ESU.EDU Location: Comp Center Services: applications, end-to-end
See also:
First, the error count can be obtained with snmpstat.
# snmpstat -i paris public
Interface statistics
Type InOctet InPckts InErrs IfMtu
Name Address Speed OutOctet OutPckts OutErrs OutQlen
net1 paris enetv2 18952186 18239 7036 1500
02000000ec6c 10000000 4392148 4183 147 0
lo0 localhost loop 5832 64 0 2048
0 5832 64 0 0
ppp0 paris ppp 3682304 14384 4800 296
9600 2122240 8290 2138 0
Next, the interface can be marked as being
``down'' using setany.
# setany paris public ifAdminStatus.3 -i 2 Name: ifAdminStatus.3 Value: 2When the line is repaired, the interface can be reactivated in a similar fashion.
See also:
The following example shows how the administrator might proceed.
Example 10-16 Removing ARP entry
# snmpstat -a paris publicAddress Translation table Host Physical Address Flags Interface 10.0.246.1 8:0:14:40:1:21 dyna net1 10.0.246.3 0:0:c0:6d:82:23 dyna net1
# setany paris public ipNetToMediaType.1.10.0.246.3 -i 2
# snmpstat -a paris public
Address Translation table Host Physical Address Flags Interface 10.0.246.1 8:0:14:40:1:21 dyna net1
See also:
------------------------------------------------------------------ Manual page Information provided ------------------------------------------------------------------ getid(ADMN) retrieve system MIB variables getmany(ADMN) retrieve class of SNMP variables getmet(ADMN) retrieve routing metrics from SNMP entity getnext(ADMN) retrieve the next SNMP variable getone(ADMN) retrieve a single SNMP variable getroute(ADMN) retrieve routing info from SNMP entity getsub(ADMN) retrieve routing subnets from SNMP entity snmpd(ADMN) the SNMP daemon snmpstat(ADMN) SNMP statistics command mosy(ADMN) managed object compiler post_mosy(ADMN) back-end wrapper for mosy setany(ADMN) set an SNMP variable trap_rece(ADMN) receive an SNMP trap trap_send(ADMN) send an SNMP trap snmpd.comm(SFF) communities configuration file snmpd.conf(SFF) system configuration file snmpd.peers(SFF) peers configuration file snmpd.trap(SFF) trap configuration fileTo get more information about SNMP and related protocols, see the following Requests for Comments (RFCs). For information on how to obtain RFCs, see ``Obtaining RFCs from the Internet''.
--------------------------------------------------------------------
RFC Title
--------------------------------------------------------------------
768 User Datagram Protocol
1058 Routing Information Protocol
1155 Structure and Identification of Management Information for
TCP/IP-Based Internets
1156 Management Information Base for Network Management of
TCP/IP-Based Internets
1157 Simple Network Management Protocol (SNMP)
1213 Management Information Base for Network Management of
TCP/IP-based Internets:MIB-II
1227 SNMP MUX Protocol and MIB
A good place to start for beginners is the book
The Simple Book, by Marshall T. Rose, copyright 1991 by
Prentice-Hall, Englewood Cliffs NJ. ISBN: 0-13-812611-9.