|
Running V1.1 on a VAX 410FT produced some peculiar behaviour when
managing bridges, concentrators and terminal servers from the IMPM.
The main problem was that mcc seemed confused by the system apparently
having four Ethernet interfaces, although of course only two would have
been visible to mcc (and the fact that they were the new KFE type I
suspect didn't help too much).
According to the docs, if there is a choice of ports, and one isn't
selected by the "via port" qualifier, then mcc should round robin them
all to find the entity.
Unfortunately this doesn't appear to work too well. Therefore the via
port field in the IMPM has to be used all the time, which (when I tried
it) has two problems.
One is well known in that, having set the port, it is used for all
future operations. This has been known to confuse DECnet, etc.
Secondly, if a bridge is "looked into" (ie double click MB1), then the
port selected at the higher level appears to be no longer applicable,
and the via port option is greyed out for the current level and so the
port can't be reselected.
This means that while a bridge can be selected and managed at the
entity level, it is impossible to, for instance, look at any line
counters.
I have not had a chance to try T1.2.4 on the FT VAX, but would be
interested to know if anyone else has seen the behaviour.
Paul.
|
| > According to the docs, if there is a choice of ports, and one isn't
> selected by the "via port" qualifier, then mcc should round robin them
> all to find the entity.
The DECmcc Ethernet Access Exec common routines (mcc_ea*) round-robins
the ports that it KNOWS ABOUT. The list of "known devices" is hard-coded
in the EA code (but can be overridden using a logical...).
I don't think we knew about the KFE when we did V1.1 (what's the name of
the driver that supports it, EZDRIVER?).
> Unfortunately this doesn't appear to work too well. Therefore the via
> port field in the IMPM has to be used all the time, which (when I tried
> it) has two problems.
>
> One is well known in that, having set the port, it is used for all
> future operations. This has been known to confuse DECnet, etc.
How does defaulting VIA PORT confuse DECnet? Doesn't the DECnet AM
ignore the VIA PORT qualifier? (I don't have a copy of the DECnet IV
MRM to check this).
> Secondly, if a bridge is "looked into" (ie double click MB1), then the
> port selected at the higher level appears to be no longer applicable,
> and the via port option is greyed out for the current level and so the
> port can't be reselected.
>
> This means that while a bridge can be selected and managed at the
> entity level, it is impossible to, for instance, look at any line
> counters.
If what you're saying is true (that the Iconic Map PM won't pass
VIA PORT for Child Entities) you've found a pretty serious bug.
(we'll check the latest X1.2 version and respond with what we
find).
Are you sure that the VIA PORT isn't getting passed for child
entities (perhaps being cached by the Iconic Map?). Does BY PASSWORD
exhibit the same problem for NODE4 and SNMP entities?
Chris
|