----- Begin Included Message -----
>From mailer-daemon@slcs.psi Tue Sep 1 12:45:57 1992
Received: from slcs.psi by GEST20.sinet.slb.com; Tue, 1 Sep 92 12:45:57 +0200
Date: Tue, 1 Sep 92 12:45:57 +0200
From: mailer-daemon@slcs.psi (Mail Delivery Subsystem)
To: davies
X-Vms-To: <gest20::davies>
Subject: Returned mail: Host unknown
Status: R
----- Transcript of session follows ----
Hi - thanks for all your replies.
I have been very busy so appologies for time to summaraise. I will directly quote two replies that caught every angle. Thanks guys
Marc Rinfret Tells me:-
> Sun Managers : a puzzling question of address
>
> Maybe I am mistaken but, I understand that the arp tables maintained by my workstation
> (examinable by arp -a) maintain a "data base" of ip-address to ethernet address mapping.
> [...]
That's right
>
> The above information is correct - as I can examine the ethernet address the boot messages.
> The ethernet address - I thought - cannot be altered, it is encoded in hardware and is unique.
The "real" ethernet address (the one displayed at boot time) should be unique and should
be allocated from the reserved address block of the manufacturer. The "effective" ethernet
address is usually loaded from the "real" one, it is however generally possible to modify it.
> Then I installed Sunlink DNI.
And all of a sudden you are dealing with Digital :-(
>
> Now this node publishes a different ethernet address when replying to the icmp broadcast.
The subtlety involved in mapping physical addresses to logical ones was probably
beyond the designers of DECNET. They simply modify the physical address so it
has a direct correspondance with the logical one.
> If I hard code this into my arp table using arp -f I get the following from arp node3.
>
> node3 (129.87.87.17) at 8:0:20:c:a5:7e permanent published
>
> but now I can no-longer communicate with my node!
>
This is normal, the ethernet interface is now set with the aa:... address,
permanently publishing a "wrong" address causes obvious problems.
> questions are these:
>
> 1> Is this normal; if so why.
Is Digital normal?
> 2> Does the ethernet controller obtain information obtained from the arp tables in order to establish links on the cable.
The other way around. The arp tables are maintained from the answers of the ethernet
interfaces on the net. (ARP is an Address Resolution Protocol, When a system wants to
contact another one, it first check in the arp cache to see if the mapping from the
internet (IP) address of that host to the ethernet address is present. If there is
no mapping present, it sends a broadcast message (arp request) requesting the ethernet
address of that host. Every host will get that packet, the one with the corresponding
IP address will reply (arp reply) with a packet containing its ethernet address. The
local system caches these answers for a while afteward).
> 3> If yes; does this mean that I am somehow changing the actual ethernet address ?????
At least the "effective" one, for all practical purpose the only one visible on the "wire".
> 4> If yes; what happens if by some chance I obtain a peice of equipment with the "changed" ethernet address.
I assume the aa:00:.... block is reserved for Decnet by Digital. In this case collisions
could only occur if you had to decnet hosts with the same address.
> 5> If no; why bother to keep arp tables ???
The arp table maps IP addresses to Ethernet. TCP/IP uses it. Decnet doesn't what it is.
> I discovered this while trying to identify a rogue ethernet interface on my network,
> I spent many hours looking for a piece of equipment with aa:..... having decided that
> this could not be Sun Microsystems (8:0:20.....). ummmmmmmmmph.
>
Isn't that nice :-(. I think we must thank Digital for this.
Marc.
and from Bob Reardon
All Decnet nodes dynamically modify their E-net addresses and are, in
fact, know on the network by the modified addresses. This usually does
not cause trouble but I have had one server that never would talk to
any clients after dni started - had to remove dni to get the server to
ever work again.
Here is some info/background that Dan Erlich(SDR) and Jimmie Keddie
published a few years ago relative to vaxes..
=====================================================================
If you think about it trying to get 1023 addresses out of 8 bits is
impossible. The actual breakdown of the last 16 bit word in an Ethernet
address, with DECnet running, is as follows:
1
5 0
aaaannnnnnnnnnnn Where: aaaa is the DECnet area
number
nnnnnnnnnnnn is the DECnet node
number
This value is then byte swapped, so what gets printed out looks
like:
nnnnnnnnnnnnaaaa
As the default area is 4, DECnet node 16 would have the following in
the last 16 bits of it's physical address:
0000111100000100
This was down because DEC was to lazy to maintain a table that maps
the 12 bit DECnet node number into the 48 bit Ethernet address. The ability
to change a stations physical address is actually in the Ethernet V2.0John Paul O'Brien"
specification but it is listed as a MAINTENANCE function. I was told by DEC
that when they get some sort of Ethernet name server they MIGHT use the ROM
based address.
THanks esp to:
Marc.Rinfret@eng.canadair.ca
sws::reardon (Bob Reardon Maildrop 3F - x4794)
macphed@dvinci.usask.ca (Ian MacPhedran)dan@ees1s0.engr.ccny.cuny.edu (Dan Schlitt)
trinkle@cs.purdue.edu
John Paul O'Brien" <john@solar.nova.edu>
poffen@sj.ate.slb.com (Russ Poffenberger)
t@wbst845e.xerox.com (Matt Goheen)
strn@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer
Arne Henrik Juul <arnej@lise.unit.no>
Tom Hutton <hutton@opus.sdsc.edu>
birger@vest.sdata.no (Birger A. Wathne)
Barry Margolin <barmar@Think.COM>
mike%trdlnk@uunet.UU.NET (Michael Sullivan)
Dave Mitchell <D.Mitchell@dcs.sheffield.ac.uk>
Christian Lawrence <cal@soac.bellcore.com>
fabrice%carlyle@uu.psi (Fabrice Guerini)
Joseph C. Grant. K8/TDV3.
----- End Included Message -----
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:48 CDT