Re: MAC address confusion
On (2009-03-03 13:50 -0800), Kevin Oberman wrote: This is only a problem if you have multiple systems running DECnet (or some other protocol using this) with the same layer 3 address. That should never happen, so there should be no duplication. Why would they need to have same L3 address? The way I see it, only thing that matters is, if or not, the addresses might speak ethernetII. If your ethernetII switch sees your local 02 address and one of the addresses below and they collide, the switch will keep relearning the address behind two ports. Unless of course it is guaranteed, that none of these addresses will ever appear as BIA in ethernetII capable NIC. 02-07-01 (hex)RACAL-DATACOM 02-1C-7C (hex)PERQ SYSTEMS CORPORATION 02-60-86 (hex)LOGIC REPLACEMENT TECH. LTD. 02-60-8C (hex)3COM CORPORATION 02-70-01 (hex)RACAL-DATACOM 02-70-B0 (hex)M/A-COM INC. COMPANIES 02-70-B3 (hex)DATA RECALL LTD 02-9D-8E (hex)CARDIAC RECORDERS INC. 02-AA-3C (hex)OLIVETTI TELECOMM SPA (OLTECO) 02-BB-01 (hex)OCTOTHORPE CORP. 02-C0-8C (hex)3COM CORPORATION 02-CF-1C (hex)COMMUNICATION MACHINERY CORP. 02-E6-D3 (hex)NIXDORF COMPUTER CORPORATION -- ++ytti
Re: MAC address confusion
Sorry fot the top-post, but my Treo makes it almost impossible to do otherwise. The protocols using these reserved, local addresses all use them to embed the network layer address. AA addresses are used by DECnet and kin while 02 is for XNS, I seem to recall. As long as the only addresses used in these spaces are thse asigned by those protocols and they use peoperly assigned network layer addresses, ther will never be a conflict. That is the point in0the registration...marking them as reserved for the protocols in question and not to be used for anything else. Sent from my Treo: R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) E. O. Lawrence Berkeley National Laboratory (LBNL) ober...@es.net +1 510-486-8634 -Original Message- From: Saku Ytti saku+na...@ytti.fi Date: Wednesday, Mar 4, 2009 12:49 am Subject: Re: MAC address confusion To: nanog@nanog.org On (2009-03-03 13:50 -0800), Kevin Oberman wrote: This is only a problem if you have multiple systems running DECnet (or some other protocol using this) with the same layer 3 address. That should never happen, so there should be no duplication. Why would they need to have same L3 address? The way I see it, only thing that matters is, if or not, the addresses might speak ethernetII. If your ethernetII switch sees your local 02 address and one of the addresses below and they collide, the switch will keep relearning the address behind two ports. Unless of course it is guaranteed, that none of these addresses will ever appear as BIA in ethernetII capable NIC. 02-07-01 (hex)RACAL-DATACOM 02-1C-7C (hex)PERQ SYSTEMS CORPORATION 02-60-86 (hex)LOGIC REPLACEMENT TECH. LTD. 02-60-8C (hex)3COM CORPORATION 02-70-01 (hex)RACAL-DATACOM 02-70-B0 (hex)M/A-COM INC. COMPANIES 02-70-B3 (hex)DATA RECALL LTD 02-9D-8E (hex)CARDIAC RECORDERS INC. 02-AA-3C (hex)OLIVETTI TELECOMM SPA (OLTECO) 02-BB-01 (hex)OCTOTHORPE CORP. 02-C0-8C (hex)3COM CORPORATION 02-CF-1C (hex)COMMUNICATION MACHINERY CORP. 02-E6-D3 (hex)NIXDORF COMPUTER CORPORATION -- ++ytti
Re: MAC address confusion
Date: Tue, 3 Mar 2009 08:42:16 +0200 From: Saku Ytti saku+na...@ytti.fi On (2009-03-02 17:31 -0800), Kevin Oberman wrote: http://standards.ieee.org/regauth/oui/oui.txt 02-07-01 (hex) RACAL-DATACOM Would be interesting to see what are the historical reasons.Perhaps they simply predate the scheme or some might not even co-exist in ethernet network to begin with, in which case they might be better documented elsewhere. IEEE after 802.3 was ratified. IEEE agreed to retain existing registrations and they have remained there. So where does this leave the current local scape addresses being globally assigned? Is it possible that we will run into legit 02 MAC addresses in the wild? Thee are properly locally assigned,not local scope addresses, but the effect is the same. This is only a problem if you have multiple systems running DECnet (or some other protocol using this) with the same layer 3 address. That should never happen, so there should be no duplication. The only real issue I see is with IPv6 EUI-64 addresses and even in that case, there would have to be two systems getting their address space from the same router interface before there is a conflict. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: MAC address confusion
Whic one of these, is locally assigned unicast MAC address, when talking about output format CSCO uses? 4000.. (Local IXPs choice) 0200.. (My money is here) the second one. most significant byte is on the left, but within the byte, most significant bits are on the right. so U/L bit is the second one counting from the left. http://standards.ieee.org/regauth/oui/oui.txt 02-07-01 (hex) RACAL-DATACOM good point, dunno.
Re: MAC address confusion
http://standards.ieee.org/regauth/oui/oui.txt 02-07-01 (hex) RACAL-DATACOM A0-6A-00 (hex) Verilink Corporation In either case two of the lowest or highest bits of 1st octet seems to be happily used to assign addresses. What am I missing here? After enabling DECnet routing, the interface MAC address turns to something like this: GigabitEthernet0/2 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is aa00.0400.0a04 (bia 000b.bffd.fc1a) And you'll find AA-00-04 (hex)DIGITAL EQUIPMENT CORPORATION in the list. I don't know what 02-07-01 is, but I guess that could be something similar: The OUI belongs to a company, but they don't use the addresses to burn them into interface cards. Andras
Re: MAC address confusion
On (2009-02-28 22:38 +0100), JAKO Andras wrote: Hey, http://standards.ieee.org/regauth/oui/oui.txt 02-07-01 (hex)RACAL-DATACOM After enabling DECnet routing, the interface MAC address turns to something like this: Hardware is BCM1250 Internal MAC, address is aa00.0400.0a04 (bia 000b.bffd.fc1a) AA-00-04 (hex) DIGITAL EQUIPMENT CORPORATION in the list. I don't know what 02-07-01 is, but I guess that could be something similar: The OUI belongs to a company, but they don't use the addresses to burn them into interface cards. I guess you shouldn't be able to assign 02 (or AA) to a company for ethernet number, much in the same way you shouldn't be able to assign RFC1918. However you are right, it seems that these are unexplained exceptions to rules: http://www.iana.org/assignments/ethernet-numbers 'some of the known addresses do not follow the scheme (e.g., AA0003; 02)' Would be interesting to see what are the historical reasons.Perhaps they simply predate the scheme or some might not even co-exist in ethernet network to begin with, in which case they might be better documented elsewhere. In any case, to avoid collision with history, better start with 06 which seems cruft free, instead of 02, when choosing local MAC address prefix. As a side note, the 40 prefix used as local MAC in IXP here, seems to be just mistake in assuming ethernet follows tokenring in numbering scheme. -- ++ytti
