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

Re: (ASCEND) Re: SNMP Interface representation

On Wed, Nov 26, 1997 at 05:44:58PM -0800, Peter Lalor wrote:
> >From:	Phillip Vandry [SMTP:vandry@Mlink.NET]
> >
> >> We are fixing the interface numbering as I've stated many times. It is
> >>quite a
> >> large undertaking but is essential. I will post, as promised, our
> >>proposed fix
> >> to see if it jibes with what you all are expecting.
> >>
> >> The issue of dialed interface handling is not done well by any vendor.
> >>Every im
> >> plementation has shortcomings. If I am wrong about this please correct
> >>me. All
> >> input on this issue is desired. The IETF certainly does not have a
> >>reasonable i
> >> mplementation either. They are forging ahead with the notion that every
> >>VC shou
> >> ld have and an ifIndex. What do you do with a box like the TNT that can
> >>handle
> >> a T3? Traverse 672 interfaces? That will take 3 or 4 minutes.
> >
> >Recognize that we are almost never interested in everybody who connects.
> >Implement a configured static mapping between connection profiles and
> >ifIndices. Allow maybe 200 of these mappings, as memory permits.
> >
> >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.

> The routine around here is: Max resets (pick a reason). Tech finds what T1
> profiles moved where and tells our SNMP bandwidth graphing app about it.
> Repeat.
> 
> Gets old.

And is not really necessary. I would state here:

1) Ascends way of profile oriented setup vs. other vendors interface
   oriented setup is IMHO a progress. It makes a lot things easier
   and is the key to manage a larger NAS without extreme overhead.
   I would by no means request them to change _this_. This even
   includes the ifIndex jumping. The problem is not exactly with the
   ifIndex jumping but with the NMS which
   a) blindly adhere to Link == Interface philosophy
   b) cannot ask the Ascend box indirectly which ifIndex to use
   where b) is also an Ascend problem because the MIB for a long
   time was not capable of providing a trivial way for the NMS to
   do this.

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
   loaded ;) and will implement MPP bundles then as well (and if it
   is not too hard also dialed connections). It is a bit of overhead
   but could as well be implemented within MRTG itself like
   Target[uplink]: ascend-profile%isp-link:public@ourmax
   but I'm not the perl freak to do this (is Dave still around here ?).

3) I could imagine that leased lines get assigned to the first ifIndexes
   in profile order during startup. I could as well imagine specifying
   that I want them to have static ifIndexes in certain profiles. But
   IMHO a short and flexible way to crossref between profile name, IP
   address of the destination, slot/port and ifIndex is by far the
   best solution even if it requires some additional code on the
   NMS side.

4) The IETF has no clear concept. One ifIndex per VC is stupid. It
   allows old (stupid) NMS software to deal with an NAS as with a
   2 fixed interface router, but at what price...

-- 

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: