linegar@bwdls49.bnr.ca (Derick Linegar) (10/05/90)
In trying to debug a problem we are having here with our file server with 2 ethernet boards connected to 2 *different* subnets on the same network, our vendor eluded to us that the 2 ethernet cards assume the *same* Ethernet address, obtained from the primary ethernet board. Of course, warning bells are going of here. Now I've been searching the RFC and IEEE docs and I cannot find any documentation that sort of says that Ethernet Addresses are assigned to Ethernet boards, not hosts. Anyone have an idea where it might be. I cannot go back to the vendor and say " .... well everyone *knows* that ethernet addresses *must* be unique..." -derick- -- #include <disclaimer.h> Derick Linegar, Internet Systems 4P27, Bell-Northern Research BITNET: LINEGAR@BNR.ca P.O. Box 3511 Station C UUCP: ...uunet!bnrgate!bwdls49!linegar Ottawa ONT. K1Y 4H7
leonard@arizona.edu (10/06/90)
In article <5A0A050B012801FE-MTAEMR1*fillmore@emrcan>, fillmore@emrcan.BITNET writes: > In the DEC VAX environment the unique Ethernet address on each board is > overridden by DECNET when it starts to use that board. The address is set > to four bytes of a constant value plus two bytes which contain the DECNET > area and node numbers. Lots of opportunity for duplication! > Does anyone know why DEC chose this scheme? Sure, it saves DECnet having to have an address resolution protocol a la ARP ... if a DECnet node wants to find the MAC address for a given DECnet address, it already knows what the address *should* be. There's a couple of problems with this approach: 1. If you are running different network protocols on the same Ethernet board, then obviously they can't *all* do this! I believe that Novell's IPX similarly hacks the Ethernet address, which (if true) means that DECnet and IPX can't share the same board. 2. A DECnet node can't have multiple Ethernet interfaces running DECnet on the same bridge-extended Ethernet. (Because the bridges will see the same Ethernet addr on both sides!) This may seem like a perverse topology to IP oriented folks, but given DEC's historical MAC layer uber alles approach, in some situations this can be exactly what you would want. In DECnet Phase V (due out twelve months from any given point in time ;-) ), DECnet is supposed to stop resetting the hardware addresses on its Ethernet adapters, and will presumably adopt some ARP protocol.
henry@zoo.toronto.edu (Henry Spencer) (10/06/90)
In article <linegar.655064040@bwdls49> linegar@bwdls49.bnr.ca (Derick Linegar) writes: >our vendor eluded to us that the 2 ethernet cards assume the *same* Ethernet >address, obtained from the primary ethernet board. Of course, warning bells >are going of here. Now I've been searching the RFC and IEEE docs and I cannot >find any documentation that sort of says that Ethernet Addresses are assigned >to Ethernet boards, not hosts. This seems to come up fairly often... The original intent of Ethernet was quite specifically to assign addresses to hosts, not boards, which is one reason why Ethernet addresses are required to be programmable instead of being locked into the boards. The XNS protocols use Ethernet addresses as host numbers and *must* have exactly one address per host. With TCP/IP, the Ethernet addresses are largely invisible to the upper levels and it doesn't really matter much either way, unless for some reason you've got two boards on the same network (in which case you will have other problems...). -- Imagine life with OS/360 the standard | Henry Spencer at U of Toronto Zoology operating system. Now think about X. | henry@zoo.toronto.edu utzoo!henry
bruce@balilly.UUCP (Bruce Lilly) (10/11/90)
In article <linegar.655064040@bwdls49> linegar@bwdls49.bnr.ca (Derick Linegar) writes: > >[ ... ] > Now I've been searching the RFC and IEEE docs and I cannot >find any documentation that sort of says that Ethernet Addresses are assigned >to Ethernet boards, not hosts. > >Anyone have an idea where it might be. I cannot go back to the vendor and >say > > " .... well everyone *knows* that ethernet addresses *must* be unique..." ``For information on global (U) address administration contact the Secretary, IEEE Standards Board, 345 East 47 Street, New York, NY 10017.'' (Footnote on page 26 of ANSI/IEEE Standard 802.3-1985 ISO/DIS 8802/3) My recollection is that each manufacturer is assigned a group of addresses and is expected to make the hardware address unique for each interface. As has been pointed out (for the specific case of DECnet) it is also possible to override the hardware address via software, and that may be a part of your problem. The IEEE Secretary ought to be able to clarify this situation, and may be able to tell you what range of addresses are assigned to your particular vendor. Late flash: after checking several references, I found: ``14.4.2 Ethernet addresses Host computers on Ethernet are identified by two addresses, the Ethernet address (a 48-bit hardware address) and an IP or software address. Ethernet addresses are guaranteed unique because vendors building Ethernet interfaces have a set of addresses assigned to them. The IEEE Standards Board in New York City assigns the first 24 bits to a manufacturer, which then allocates the last 24 bits sequentially. The address is either built into the interface board or stored in ROM on the board.'' (From _UNIX(R)_System_Administration_Handbook_ by Nemeth, Snyder, and Seebass, published by Prentice-Hall, p. 243) An excellent book, by the way, although it is heavily biased toward BSD. Note however that the IEEE standard permits either 16-bit or 48-bit addresses, so don't take that too literally. Hope this helps. -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
stanonik@NPRDC.NAVY.MIL (Ron Stanonik) (10/12/90)
The 10base5 NI cards in our AT&T 3b2's were all delivered with the same ethernet address. This was a big surprise, because we too had come to expect manufacturer's would assign unique addresses. The similar ethernet addresses didn't cause any problems because the IP layer in each machine filtered out only those packets destined for the local machine. Everyone ARP'ed to the same ethernet address. Sort of like multicasting (unicasting?). We didn't realize what was happening until packet tracing to find an unrelated problem. We've since found an undocumented command which allows setting the ethernet address and the machines now all have unique ethernet addresses. Ron Stanonik stanonik@nprdc.navy.mil
donp@na.excelan.com (don provan) (10/13/90)
In article <1990Oct5.123350.145@arizona.edu> leonard@arizona.edu writes: >I believe that Novell's IPX similarly hacks the Ethernet address.... This has nothing to do with TCP-IP, but i don't want this rumor to spread. IPX does not modify the ethernet address. don provan donp@novell.com
henry@zoo.toronto.edu (Henry Spencer) (10/14/90)
In article <9010121633.AA00795@atlantic.nprdc.navy.mil> stanonik@nprdc.navy.mil writes: >The 10base5 NI cards in our AT&T 3b2's were all delivered with >the same ethernet address... AT&T has probably been bitten by a problem that has affected a number of established companies when they tried to build Ethernet gear: traditional production facilities have a very strong mindset towards building utterly identical boxes, and the only thing they are set up to do with PROMs is to duplicate them. If you simply hand them the new design and tell them to build it, the odds are very good that you will get identical Ethernet addresses, even if it says in the fine print that they should be different. And testing the new boards one at a time won't catch it! -- "...the i860 is a wonderful source | Henry Spencer at U of Toronto Zoology of thesis topics." --Preston Briggs | henry@zoo.toronto.edu utzoo!henry
peter@ria.ccs.uwo.ca (Peter Marshall) (10/19/90)
In article <2126@excelan.COM>, donp@na.excelan.com (don provan) writes: |> In article <1990Oct5.123350.145@arizona.edu> leonard@arizona.edu writes: |> >I believe that Novell's IPX similarly hacks the Ethernet address.... |> |> This has nothing to do with TCP-IP, but i don't want this rumor to |> spread. IPX does not modify the ethernet address. While DECnet IV wants to change the ethernet number to match the DECnet node and host number, IPX only requires the same ethernet number to be used on all interfaces to a machine. It doesn't care what they are set to. This allows DECnet and IPX to coexist on the same router as long as you get the DECnet running first and then start the IPX. -- Peter Marshall, Manager (Academic Networking) CCS, NSC, U. of Western Ontario, London, Canada N6A 5B7 (519)661-2111x6032 peter.marshall@uwo.ca pm@uwovax (BITNET); peter@ria.uucp
xjeldc@tts.lth.se (Jan Engvald) (10/20/90)
>While DECnet IV wants to change the ethernet number to match the DECnet node >and host number, IPX only requires the same ethernet number to be used on all >interfaces to a machine. It doesn't care what they are set to. This allows >DECnet and IPX to coexist on the same router as long as you get the DECnet >running first and then start the IPX. No, NO. *NOVELL* IPX routers/servers don't change the Ethernet address of any interface card (*). We have several servers with two Ethernet cards. One card uses type 8137 protocoll and the other Novells ISO-like protocoll. Both are connected to the *SAME* Ethernet segment, and if they used the same Ethernet address it would mean disaster. Looking with an Ethernet monitor you can see that at the link layer each card uses its own address that it was born with. However, at the network layer Novell IPX uses 32 bits of network id + 48 bits node id, and the node id is the Ethernet address of the first (LAN A) card. (*) The Cisco router, for some reason I don't understand, say they do change the adress of its interfaces when Novell IPX routing is turned on. Jan Engvald, Lund University Computing Center ________________________________________________________________________ Address: Box 783 E-mail: xjeldc@ldc.lu.se S-220 07 LUND Earn/Bitnet: xjeldc@seldc52 SWEDEN (Span/Hepnet: Sweden::Gemini::xjeldc) Office: Soelvegatan 18 VAXPSI: psi%2403732202020::xjeldc Telephone: +46 46 107458 (X.400: C=se; A=TeDe; P=Sunet; O=lu; Telefax: +46 46 138225 OU=ldc; S=Engvald; G=Jan) Telex: 33533 LUNIVER S