| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1267.1 | | KONING::KONING | Paul Koning, B-16504 | Wed Mar 09 1994 12:33 | 5 |
| MOP does not use the DECnet address. You should change the MOP node database
entry on the load host so it has the physical address of the load target
in it, rather than the DECnet style address.
paul
|
| 1267.2 | | OSLACT::BJORN | Bj�rn Olav Haugom | Thu Mar 10 1994 07:53 | 26 |
| I don't believe you read my description very well, so here's your 2nd chance to
give me some advice;
The primary boot file , i.e. the ROU012.SYS file is successfully loaded on the
DECrouter, using the Ethernet Hardware address of the router, specified in the
NCP NODE Charateristics. When the router has booted the "operating system", i.e.
the primary boot file, i.e. ROU012.SYS, it request load for Management file,
i.e. the ROUnodename.SYS. What the router uses in this request, I don't know,
but I guess it's using DECnet protocol to get the rest, since the router at that
point in time really is running DECnet ( I get Routing Circuit Adjacency change
events from a DECnis on the same LAN, detecting the Router as being UP).
So what I believe, is that the router is requesting the second load file using
DECnet, but specifies 08-00-2b-26-32-52 as the load host, instead of the
AA-00-04-00-0A-08 for the load host.
If you read my last part of the original topic, I said that if I load it from a
PhaseIV node's Ethernet port, the SDA output for the MOP protocol shows a
Physical address of AA-00-04-00-xx-yy for the Ethernet Port, while on the VAX
that has the FDDI port, the Physical address shows up as 08-00-2b-26-32-52, and
that's WHY the router tries to load the secondary load file using
08-00-2b-26-32-52 instead of the Ethernet HArdware address AA-00-04-00-0A-08.
Would you like to give it another try?
Bj�rn Olav
|
| 1267.3 | | KONING::KONING | Paul Koning, B-16504 | Thu Mar 10 1994 18:04 | 5 |
| I'll pass. This sounds like a good question for a MOP implementation expert
(Dave Porter, are you there?). Turning on tracing might help, if there is
any for MOP.
paul
|
| 1267.4 | Physical Address not changed when DECnet loaded? | OSLACT::BJORN | Bj�rn Olav Haugom | Mon Mar 14 1994 04:33 | 12 |
| Why is the data structure for the DNA MOPDL protocol different for the FDDI
Interface compared to the Ethernet Interface? That's the simple queastion behind
all this.
If you look at a VAX that has both Ethernet and FDDI interface, and both of them
enabled as DECnet routing Circuit (on separate LANs), the Ethernet interface
will come up with the Physical Address data structure for the DNA MOPDL set to
AA-00-04-00-0A-08, while the FDDI interface's data structure will show the
Physical Address as 08-00-2b-26-32-52. Why different behaviour for the FDDI
interface?
Bj�rn Olav Haugom
|
| 1267.5 | | KONING::KONING | Paul Koning, B-16504 | Mon Mar 14 1994 15:49 | 20 |
| It was never desirable on any datalink to change the address used by other
protocols simply because DECnet wanted a different address. This has always
caused serious trouble with LAT, and also introduces extra complexity elsewhere.
With Ethernet, some hardware only supports a single individual address, so
on that hardware you have no choice; you must set the address used by
everyone as soon as anyone wants a non-standard address. Other Ethernet
adapters do support multiple addresses, but VMS doesn't allow it on any
adapter on the grounds that some adapters can't do it. (Feh!)
On FDDI, there are very good reasons why it is NOT acceptable to have a single
individual address that is subject to change. So the primary address
(called "MLA" = "My long address" by the FDDI standard) is always taken
from the ROM. To support DECnet, all FDDI adapters are required to support
multiple individual addresses, and the drivers are also required to support
them (if they want to support DECnet). Therefore, on FDDI a particular
protocol implementation only gets a different address if it asks for it.
DECnet does, but other protocols don't. (Well, I think LAT can ask for it,
if you tell it to, but there is no sense in doing that for FDDI.)
paul
|
| 1267.6 | customer demands sometimes have to allow for concessions | MRLAT::RASPUZZI | Michael Raspuzzi - LAT Engineering et al | Tue Mar 15 1994 06:06 | 22 |
| >DECnet does, but other protocols don't. (Well, I think LAT can ask for it,
>if you tell it to, but there is no sense in doing that for FDDI.)
Due to customer demand, LAT can request the DECnet address on an FDDI
controller with:
LATCP> CREATE LINK FDDI$LINK /DEVICE=FCA0 /DECNET
As long as you are running OpenVMS VAX V6.0 and higher, OpenVMS AXP
V1.5 or higher or if you have CSCPAT_0511 V3.5 installed.
This change was done due to very high customer demand (CLDs even
appeared) so that they could easily figure out a machine's LAT address
(they knew it would be of the format AA-00-04-00-xx-xx). One site had
700+ PC users (and the PC LAT software does not listen to service
announcements to get the LAN address) and they did not want to go
around changing 700+ PCs just because they moved a VAX 7000 from
ethernet to FDDI (the PCs had the VAX 7000 already configured with the
AA-00-04-00-xx-xx address because the VAX was on the ethernet
originally).
Mike
|
| 1267.7 | Note 1007.* explains support statements | OSLACT::BJORN | Bj�rn Olav Haugom | Wed Mar 16 1994 06:28 | 6 |
| Well, in note 1007, there's a statement that none of the products on the
DEMSx-based platforms support MOP pver FDDI. I'll just have to provide an
explanation to the customer, and wait for the storm!
Bj�rn Olav
|