Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (ASCEND) Re: SNMP Interface representation



On Fri, Dec 05, 1997 at 06:38:38PM -0500, Phillip Vandry wrote:
> > > >Then if I want to monitor my dedicated customers, they probably fit in the
> > > >static mappings, so I can assign them an ifIndex and use that ifIndex to
> > > >monitor them whereas I will not assign a mapping to Joe 28.8 User.
> > > >
> > > >- -Phil
> > > 
> > > I totally agree with this methodology. I don't care about the switched
> > > connections. I care about the nailed ones.
> > 
> > A good solution however should care about all of them. I may as well be
> > interested in graphing certain dial-on-demand customer links.
> 
> So if you have 50,000 dial up users, do you want each and every one of
> your Maxes to reserve an interface slot for each user, in case that user
> connects to that Max so you can monitor the user without having to first
> look up the interface number?

No, that's exactly what I dont want. This is what the interface-based
approach would require - one "logical" interface per potential connection,
and exactly this is what makes it a bad idea. Maybe nice with a Cisco1005
or similar two-fixed-interfaces-router, but fails badly with a NAS.

What I want (and what seems to be there in 6.0) is one ifEntry per
quasi-physical interface and a mapping from logical to physical interface
that is easy to use and requires minimal SNMP traffic.

> Remember that you can still find every session under this scheme. You
> just have to do a table lookup to find the dynamically assigned
> interface number for the less often used ones.

Exactly what I want. And as stated - maybe Ascend makes access to nailed
interfaces a bit more static, but IMHO it is more useful to supply a
complete solution with minimal overhead for all interfaces but not only
for nailed ones. Of course it is easier to query a fixed ifIndex and
it was sufficient for a long enough time to become a quasi standard
in the NMS world, but it never was thought this way _only_ and logic
has to be added on the NMS side and not necessarily on the NAS.

> > 2) Starting with 5.0A it is possible to automate the above. I've posted
> >    an example here on the list that marriages Ascend leased lines with
> >    MRTG. I will adapt this to the WAN MIB ASAP (6.0b site is already
> 
> It is quite heavy to do this, though. It involves an snmpwalk.

Yes, and that's what I would like to get fixed. 5.0A already made it
easier due to a working sessionActiveTable (IIRC) but still required
a full walk of the callStatusTable. With a working callActiveTable it
would reduce again, but is still suboptimal. I'm under the impression
that the WAN MIB in 6.0 will give a short way into the ifTable and
eventually supply a nice set of shortcuts. It is a good question of
how to supply a one-hop access for a ProfileName-->ifIndex mapping, but
creating internal hash values from profile names by a known algorithm
(i.e. known to the NMS) could do this if the table is then indexed by
these hash values. In an optimal world this could allow to find such
mapping in one GET or (if hash values collide) with a small set of
GETNEXTs - certainly faster than with a full walk. Our infrastructure
can stand a full walk every 5 minutes, but thats because it is rather
small ;->

Andre.
-- 

Kanther-Line: PGP SSH IDEA MD5 GOST RIPE-MD160 3DES RSA FEAL32 RC4

+-o-+--------------------------------------------------------+-o-+
| o |               \\\- Brain Inside -///                   | o |
| o |                   ^^^^^^^^^^^^^^                       | o |
| o | Andre' Beck (ABPSoft) beck@ibh-dd.de XLink PoP Dresden | o |
+-o-+--------------------------------------------------------+-o-+
++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>


References: