| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1394.1 | | NETRIX::thomas | The Code Warrior | Mon Jul 11 1994 13:16 | 1 |
| That's to be expected.
|
| 1394.2 | the details? | CSC32::J_SHUMWAY | | Mon Jul 11 1994 13:46 | 1 |
| I thought so, could someone elaborate?
|
| 1394.3 | | NETRIX::thomas | The Code Warrior | Mon Jul 11 1994 14:05 | 3 |
| In what way? Just because DECnet has enabled a different physical address,
it doesn't that address will be used by any other protocol on the FDDI
controller.
|
| 1394.4 | | CSC32::J_SHUMWAY | | Mon Jul 11 1994 16:25 | 5 |
| >In what way?
I guess I am looking for an explantation to pass on to a customer so
he (I) can understand the differnece in how the XID is formed on each
controller for periodic sys ids.
|
| 1394.5 | | NETRIX::thomas | The Code Warrior | Mon Jul 11 1994 16:51 | 1 |
| SYSIDs are not XIDs. So there are no XIDs exchanged or sent.
|
| 1394.6 | | KONING::koning | Paul Koning, B-16504 | Mon Jul 11 1994 18:36 | 29 |
| SYSIDs are part of the MOP protocol and are sent according to the rules
in that protocol.
MOP does not require any special addresses, the way DECnet Phase IV does.
If your datalink only supports one individual address at a time, then
all protocols are forced to use the DECnet address if DECnet Phase IV is
enabled. MOP doesn't object to this; as a result, you often see SYSID
messages with the Phase IV style physical address. The Hardware Address
field, of course, shows the actual ROM address belonging to the datalink.
On datalinks that support multiple individual addresses, DECnet can change
the address it uses without affecting other protocols. In that case,
each protocol gets to pick its own address; if no preference is expressed,
the hardware address is used.
Multiple individual address support is optional on Ethernet hardware and
mandatory on FDDI. I know that at least some systems treat all Ethernet
hardware as single-address even if the hardware can do better; I don't know
if others do differently. In any case, on FDDI the support is required, so
on FDDI protocols that don't ask for a specific address will get the
hardware address. That's why the SYSID looks as it does.
Well, that answers one part. It doesn't answer "why is the circuit type wrong".
It may be that the configurator is confused, or it may be that the DEMFA
driver is sending the wrong code. A LAN analyzer or packet trace would
help settle that question. (It's definitely a bug, the only question is
in which component.)
paul
|
| 1394.7 | | NETRIX::thomas | The Code Warrior | Mon Jul 11 1994 18:50 | 2 |
| The circuit is the name of the circuit the sysid was received over. What
it a DEMNA? Then it isn't wrong.
|
| 1394.8 | | CSC32::J_SHUMWAY | | Mon Jul 11 1994 18:58 | 2 |
| The circuit name is indeed correct, MNA-0 is the receiver. Thanks for
the replys.
|
| 1394.9 | | koning.lkg.dec.com::koning | Paul Koning, B-16504 | Tue Jul 12 1994 11:52 | 4 |
| Oops, sorry, I mistook "circuit name" for "device type". It is indeed
correct.
paul
|
| 1394.10 | DEMFA (DEC-7000) LLC2/X.25 problem | OZROCK::GRIFFITHS | Tony, Networks Engineering @ OZY | Thu Feb 16 1995 20:01 | 12 |
| Other can creating a new note, can someone explain why the DEMFA "eats"
XID and TEST PDUs? The passing up of XIDs to the datalink is vital for
LLC2 Class 2 Type 2 connections. They are also needed by the SNA
software (SNA Peer Server).
Currently we have a problem whereby X.25 on a DEC-7000 running OSF/1
cannot connect to a DECnis because of the behaviour of the DEMFA.
Who is the Product Mgr for this device? Is there a Sustaining
Engineer?
Tony
|