| >With the VITALINK AM I found the following: If you set a typefilter to
>disposition count, then all packets are counted. But you can't have a
>look to the counter with the Vitalink AM. Is that right, or haven't I
>seen the attribute?
Yes. I'm pretty sure that's right. If I remember from the V1.0
development, you can set disposition to "COUNT", but you can't see
the counters from VBAM. As the latest version of the VBAM is just
an update for the V1.2 kernel changes (i.e. no new capabilities
added) I'm pretty sure that this v1.0 'quirk' remains.
If you don't want a technical explanation, then skip the next 36 or
so lines; otherwise here it is: When TransLAN's were initially
designed, (Jurassic Era) it was intended that they would utilize
DEC's RBMS protocol (we had some sort of technology sharing agreement
with them at that time). At some point(s) in the development cycle
of the Translan line, the following things happened:
1) Digital's and Vitalink's RBMS implementations began to diverge.
Each vendor added extensions and transmogrified the protocol to
suit their own implmentation requirements. The 'common'
protocol was no longer that.
2) Vitalink's shift in management approach changed. They decided
(for some reason) that any management features added to the
TransLAN would be accomplished by using the *console* interface
(the beloved REC utility). What did NOT do was make console
management interface use the same 'code path' as the RBMS
interface. I.e. the RBMS agent code was bypassed and most of
the RBMS agent code went 'un-exercised'.
As a result of these two trends, the TransLAN line became
feature-rich, but the new features were only available from the
*console* interface. The RBMS agent could not access many of these
new features.
Now the VBAM has access *ONLY* to those TransLAN attributes that are
available to the RBMS agent. This means while the RBMS agent
may be able to set a filter disposition, it might *not* be able to
examine it if the 'hook' is not there in the TransLAN's agent.
For these reasons (and other coding practice issues that I discovered
while working with Vitalink Engineering) the TransLAN management code
is virtually un-maintainable. I predict that any requests for feature
addition to the RBMS agent will be met with deafening silence.
>If that's right, it's a bit stupid to set something to control some
>traffic and I can't watch to the counters.
Yep. Pretty questionable, if not stupid. [ For long-winded
explanation, see above. ]
>There are different leaks in the AM!!!
Do you mean actual _memory_ leaks, or just 'behavioral
inconsistencies'?
>Is there any further developement or is it died?
While I do not speak for Vitalink, I believe they have has no planned
bug-fixes or enhancements to VBAM. If you're waiting for an
improvement to it, don't bother.
As I have said at least a half dozen times in this conference (and
the IAMOK::VITALINK_BRIDGE conference) this AM is essentially only
a MAINTENANCE RELEASE. Vitalink's (publicly stated) strategic
direction is with SNMP. The entire TransLAN product line is a
'mature product technology' (translation: an end-of-life cash cow)
and they are investing in technology that will work across ALL of the
Network Systems line, *not* just the TransLAN line.
regards,
/doug mcpherson
|
| Hello Doug,
First thanks for you answer. I thought, that the answers will be like that. If
I understood you right, the limitations are in the protocol. So all arguments
that can be seen from remote (via the VBAM) we support. All additional stuff,
like the discussed counters are only supportet by the console interface.
>>There are different leaks in the AM!!!
>
> Do you mean actual _memory_ leaks, or just 'behavioral
> inconsistencies'?
I mean this counters, and patternfilters and sourceaddressfilters and
such things. All attributes that are seen with the consoleinterface and not with
the VBAM. But I know now why.
>Vitalink's (publicly stated) strategic direction is with SNMP.
Last week we had an infosession with Milton Thorn from VITALINK. I asked him
about the VITALINKs future management strategy. He told that they will follow
SNMP at the moment but the will change to CMIP. I asked him "realy"? He
answered "Yes, realy !!!!!!!!"
Reagrds Roland
|
| >First thanks for you answer. I thought, that the answers will be like that. If
>I understood you right, the limitations are in the protocol. So all arguments
Well... if you want to be *precise* the limitations are in the TransLAN
RBMS *agent*, not the protocol -- but that's pretty much academic, isn't
it?
>Last week we had an infosession with Milton Thorn from VITALINK. I asked him
>about the VITALINKs future management strategy. He told that they will follow
>SNMP at the moment but the will change to CMIP. I asked him "realy"? He
>answered "Yes, realy !!!!!!!!"
CMIP? Yeah, right. Let me guess -- Mr. Thorn is from Marketing, right?
Good luck.
/doug
|