DECnet MIB question (Adjacencies)

"John A. Shriver" <> Fri, 21 August 1992 18:17 UTC

Received: from by IETF.NRI.Reston.VA.US id ab04598; 21 Aug 92 14:17 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04594; 21 Aug 92 14:17 EDT
Received: from by NRI.Reston.VA.US id aa13110; 21 Aug 92 14:18 EDT
Received: by; id AA24264; Fri, 21 Aug 92 11:14:27 -0700
Received: by; id AA20956; Fri, 21 Aug 92 10:54:12 -0700
Received: by; id AA20952; Fri, 21 Aug 92 10:54:11 -0700
Received: by; id AA23030; Fri, 21 Aug 92 10:54:00 -0700
Received: from by (5.65/1.8)id AA18426; Fri, 21 Aug 92 13:53:55 -0400
Received: by (3.2/SMI-3.2)id AA18433; Fri, 21 Aug 92 13:53:46 EDT
Date: Fri, 21 Aug 92 13:53:46 EDT
From: "John A. Shriver" <>
Message-Id: <>
In-Reply-To: Debasis Dalapati's message of Fri, 21 Aug 92 12:58:52 EDT <>
Subject: DECnet MIB question (Adjacencies)

The reality of the DECnet specification is that there is an index into
the adjacency array.  However, it is just an arbitrary number in the
range 1 to NC+NR+NBEA, which probably is sparsely populated.  Using
this index is fine, jsut so long as it is unique for each adjacency.

If your database is based on the DEC spec, this index is much easier
to manilute than a double-index of circuit and node address.  It's
going to run faster in the router, which can be an issue in SNMP.

All that most agents do with tables like this is grovel through them
with a get next anyways, so the index is relatively moot...