| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2263.1 | Questions. | CHRISB::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Tue Feb 04 1992 13:31 | 14 |
| 1. Version of DECmcc: V1.1 ? T1.2.4 ?
2. Does: SHOW STATION nx2161 ALL CHAR|IDENT
...fail in the same way?
3. Does: SHOW STATION either-address ALl STATUS
...work?
Chris
P.S. This sounds familiar (like an old
problem with V1.1).
|
| 2263.2 | the questions: | ROM01::PETTINARI | | Wed Feb 05 1992 04:31 | 31 |
| thank you, Chris.
The questions:
1. MCC version V1.1.0
2. MCC> SHOW STATION nx2161 ALL CHAR
Examination of attributes shows
Function supported = DEC_ENETV2
Alternate address = AA-00-A7-10-D2-C2
MCC> SHOW STATION nx2161 all ident
Examination of attributes shows
Name = TSSRM1_NS:.nx2161
Address = 00-00-A7-10-D2-C2
3. MCC> SHOW STATION 00-00-A7-10-D2-C2 ALL STATUS
Station TSSRM1_NS:.nx2161
AT 5-FEB-1992 09:10:48 Status
Cannot communicate with target
P.S.: The same result (3.) when I try to REGISTER another non-Digital
station (Olivetti LSX or SUN Host) with ethernet address obtained
through "UCX SHOW ARP lsx".
|
| 2263.3 | The answer... | MOLAR::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Mon Feb 10 1992 23:54 | 21 |
| Based on the additional information supplied, the Ethernet AM
is working as expected...
1. Systems running DECnet IV usually have two ethernet addresses,
the ROM address and the DECnet Physical Address (which is why
we have an ALTERNATE ADDRESS argument on the Register directive).
Ethernet Stations (as least any we've seen) will only respond to
a single address, which explains two-thirds of the base note.
2. The Register directive will determine the FUNCTION SUPPORTED
variant selector of a Station if not specified. The SHOW CHAR
command issued in .2 shows FUNC SUPP = DEC_ENETV2.
3. The SHOW STATION xxx ALL STATUS, when FUNC SUPP = DEC_ENETV2,
will issue a MOP REQUEST_COUNTERS. If the target station doesn't
respond to REQUEST_COUNTERS, the message returned should be
"Cannot communicate with target".
Hope this helps.
Chris
|
| 2263.4 | Interesting... | MARVIN::COBB | Graham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917 | Wed Feb 12 1992 15:18 | 18 |
| > 1. Systems running DECnet IV usually have two ethernet addresses,
> the ROM address and the DECnet Physical Address (which is why
> we have an ALTERNATE ADDRESS argument on the Register directive).
> Ethernet Stations (as least any we've seen) will only respond to
> a single address, which explains two-thirds of the base note.
There are a couple of things that may show up as problems when Hastings
(DECNIS) ships...
i) Hastings has 17 addresses. 16 are ROM addresses (one each for various
ethernet adaptors) plus 1 for the Phase IV compatible address. Presumably
the ethernet AM can't handle 16 alternate addresses (Phase V MOP can!).
ii) I am fairly sure (we need to test this!) that Hastings will respond to
either a ROM address or the Phase IV address but that the response will
always contain a ROM address as the source address.
Graham
|
| 2263.5 | Instant confusion... | MOLAR::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Thu Feb 13 1992 12:04 | 27 |
| >Systems running DECnet IV having two ethernet addresses...
More detail: we're actually talking two addresses per controller
(each controller is a "Station"). On a two-port node (both started
by DECnet) we're talking three addresses: two ROM addresses and the
DECnet Physical Address. Note that the ALTERNATE ADDRESS is the
DECnet Physical Address (a Characteristic - not unique thus not
an Identifier).
Thus Hastings has 17 Stations :(
>ii) I am fairly sure (we need to test this!) that Hastings will respond to
>either a ROM address or the Phase IV address but that the response will
>always contain a ROM address as the source address.
I find this a little confusing (to put it mildly).
It sounds like you're saying that a packet (e.g., IEEE802.2 TEST)
sent to the Hastings Phase IV (DECnet Physical) address, will result
in a response packet with a ROM address as source address.
My interpretation is incorrect, right?
Chris
|
| 2263.6 | Some food for thought there | MARVIN::COBB | Graham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917 | Mon Feb 17 1992 08:54 | 26 |
| Yes, you are right: Hastings has 17 stations. That seems consistent as each
station represents one interface.
> >ii) I am fairly sure (we need to test this!) that Hastings will respond to
> >either a ROM address or the Phase IV address but that the response will
> >always contain a ROM address as the source address.
>
> I find this a little confusing (to put it mildly).
>
> It sounds like you're saying that a packet (e.g., IEEE802.2 TEST)
> sent to the Hastings Phase IV (DECnet Physical) address, will result
> in a response packet with a ROM address as source address.
>
> My interpretation is incorrect, right?
Your interpretation of what I am saying is entirely correct. The Phase IV
compatible address is strictly an alias address (this is the first ethernet
adaptor DEC has built which implements real alias addresses): it is an extra
address to which we respond. When we respond the SA always contains the ROM
address.
It isn't clear to me whether that is really a problem. Also, what do the
FDDI implementations do (I believe the FDDI adaptors implement aliases the
same way we do)?
Graham
|
| 2263.7 | Yipes! | CHRISB::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Mon Feb 17 1992 18:46 | 29 |
| > Your interpretation of what I am saying is entirely correct. The Phase IV
> compatible address is strictly an alias address (this is the first ethernet
> adaptor DEC has built which implements real alias addresses): it is an extra
> address to which we respond. When we respond the SA always contains the ROM
> address.
>
> It isn't clear to me whether that is really a problem...
This is pretty wild stuff (and I'm still confused, though less than before 8)
For instance: if the SA in a return packet is always the ROM address, and
the alias address is DECnet IV (AA-00-04-00-xx-xx), how does any other
Phase IV system communicate with the Hastings box? I assume the answer is
that this isn't done (since this implementation prevents it).
Do Periodic SYSIDs get generated with the ALIAS ADDRESS as the source?
My guess is "NO, only with the ROM Address". Does a list of Alias Addresses
appear in the SYSID message?
All existing diagnostic utilities (that I'm aware of) assume that the
ethernet address "sent to" will be the ethernet address "responding"
(SA of responding packet), and will thus never receive the response
packet. Why bother to respond to the Alias Address at all?
Chris
|
| 2263.9 | | MARVIN::COBB | Graham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917 | Tue Feb 18 1992 09:55 | 32 |
| > For instance: if the SA in a return packet is always the ROM address, and
> the alias address is DECnet IV (AA-00-04-00-xx-xx), how does any other
> Phase IV system communicate with the Hastings box? I assume the answer is
> that this isn't done (since this implementation prevents it).
I simplified things slightly. Routing has a private interface to the
adaptor which allows it to send Phase IV packets with the Phase IV
compatible address as SA. This mechanism is entirely designed for that
particular function -- any other effects of using the Phase IV address are
almost entirely just dependent on how the code happens to work!
> Do Periodic SYSIDs get generated with the ALIAS ADDRESS as the source?
> My guess is "NO, only with the ROM Address".
That's right.
>Does a list of Alias Addresses
> appear in the SYSID message?
No.
> All existing diagnostic utilities (that I'm aware of) assume that the
> ethernet address "sent to" will be the ethernet address "responding"
> (SA of responding packet), and will thus never receive the response
> packet. Why bother to respond to the Alias Address at all?
Good question. The main reason is so that things like MOP Boot messages
will be honoured if they are sent to the Phase IV address (e.g. it could be
someone who has spotted this address being used and wants to kill it). Its
unlikely to be any *worse* than just ignoring the message.
Graham
|