Hi, Lots of traffic recently about 64 bits being too short or too long. What about mac addresses? Aren't they close to exhaustion? Should be. Or it is assumed that mac addresses are being widely reused throughout the world? All those low cost switches and wifi adapters DO use unique mac addresses?
I've seen duplicate addresses in the wild in the past, I assume there is some amount of reuse, even though they are suppose to be unique. -jim On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. <skandor@gmail.com> wrote:
Hi,
Lots of traffic recently about 64 bits being too short or too long.
What about mac addresses? Aren't they close to exhaustion? Should be. Or it is assumed that mac addresses are being widely reused throughout the world? All those low cost switches and wifi adapters DO use unique mac addresses?
There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are likely to be errors, not accidental collisions. -Dave On Apr 4, 2010, at 10:57 AM, jim deleskie wrote:
I've seen duplicate addresses in the wild in the past, I assume there is some amount of reuse, even though they are suppose to be unique.
-jim
On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. <skandor@gmail.com> wrote:
Hi,
Lots of traffic recently about 64 bits being too short or too long.
What about mac addresses? Aren't they close to exhaustion? Should be. Or it is assumed that mac addresses are being widely reused throughout the world? All those low cost switches and wifi adapters DO use unique mac addresses?
On Sun, 4 Apr 2010 11:10:56 -0400 David Andersen <dga@cs.cmu.edu> wrote:
There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are likely to be errors, not accidental collisions.
-Dave
On Apr 4, 2010, at 10:57 AM, jim deleskie wrote:
I've seen duplicate addresses in the wild in the past, I assume there is some amount of reuse, even though they are suppose to be unique.
-jim
On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. <skandor@gmail.com> wrote:
Hi,
Lots of traffic recently about 64 bits being too short or too long.
What about mac addresses? Aren't they close to exhaustion? Should be. Or it is assumed that mac addresses are being widely reused throughout the world? All those low cost switches and wifi adapters DO use unique mac addresses?
Sun, for one, used to assign the same MAC address to every NIC in the same box.
-- John
On Sun, Apr 4, 2010 at 11:17 AM, John Peach <john-nanog@johnpeach.com> wrote:
Sun, for one, used to assign the same MAC address to every NIC in the same box.
Technically, they assigned a MAC to the NIC and a MAC to the box. Unless you configured it otherwise, all NICs in the box defaulted to using the box's MAC instead of their own. Made for some interesting problems with early VLAN switches... Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Excerpts from John Peach's message of Sun Apr 04 08:17:28 -0700 2010:
On Sun, 4 Apr 2010 11:10:56 -0400 David Andersen <dga@cs.cmu.edu> wrote:
There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are likely to be errors, not accidental collisions.
-Dave
On Apr 4, 2010, at 10:57 AM, jim deleskie wrote:
I've seen duplicate addresses in the wild in the past, I assume there is some amount of reuse, even though they are suppose to be unique.
-jim
On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. <skandor@gmail.com> wrote:
Hi,
Lots of traffic recently about 64 bits being too short or too long.
What about mac addresses? Aren't they close to exhaustion? Should be. Or it is assumed that mac addresses are being widely reused throughout the world? All those low cost switches and wifi adapters DO use unique mac addresses?
Sun, for one, used to assign the same MAC address to every NIC in the same box.
I could see how that *could* work as long as each interface connected to a different LAN. Maybe the NICs shared a single MII/MAC sublayer somehow? I've never borne witness to this though. Re: MAC address exhaustion, if the the second-to-least significant bit in the first byte is 0 (Globally Unique / Individually Assigned bit), then the first three bytes of the MAC should correspond to the manufacturer's "Organizationally Unique Identifier". These are maintained by the IEEE, and they have a list of who's who here: http://standards.ieee.org/regauth/oui/index.shtml I haven't ever programmatically gone through the list, but it looks like a lot of the space is assigned. Cheers, jof
On Apr 4, 2010, at 11:46 17AM, Jonathan Lassoff wrote:
Excerpts from John Peach's message of Sun Apr 04 08:17:28 -0700 2010:
On Sun, 4 Apr 2010 11:10:56 -0400 David Andersen <dga@cs.cmu.edu> wrote:
There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are likely to be errors, not accidental collisions.
-Dave
On Apr 4, 2010, at 10:57 AM, jim deleskie wrote:
I've seen duplicate addresses in the wild in the past, I assume there is some amount of reuse, even though they are suppose to be unique.
-jim
On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. <skandor@gmail.com> wrote:
Hi,
Lots of traffic recently about 64 bits being too short or too long.
What about mac addresses? Aren't they close to exhaustion? Should be. Or it is assumed that mac addresses are being widely reused throughout the world? All those low cost switches and wifi adapters DO use unique mac addresses?
Sun, for one, used to assign the same MAC address to every NIC in the same box.
I could see how that *could* work as long as each interface connected to a different LAN.
Maybe the NICs shared a single MII/MAC sublayer somehow? I've never borne witness to this though.
There was a socketed ROM IC with the *machine's* MAC address on the motherboard, way back when. If your motherboard needed replacing, the tech would move that IC to the replacement. Why was this done? The reason was simple: compatibility with other stacks. Remember that circa 1988-1990, it was not obvious that TCP/IP was going to be the winner. --Steve Bellovin, http://www.cs.columbia.edu/~smb
On 4/4/2010 08:46, Jonathan Lassoff wrote:
Excerpts from John Peach's message of Sun Apr 04 08:17:28 -0700 2010:
On Sun, 4 Apr 2010 11:10:56 -0400 David Andersen <dga@cs.cmu.edu> wrote:
There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are likely to be errors, not accidental collisions.
-Dave
On Apr 4, 2010, at 10:57 AM, jim deleskie wrote:
I've seen duplicate addresses in the wild in the past, I assume there is some amount of reuse, even though they are suppose to be unique.
-jim
On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. <skandor@gmail.com> wrote:
Hi,
Lots of traffic recently about 64 bits being too short or too long.
What about mac addresses? Aren't they close to exhaustion? Should be. Or it is assumed that mac addresses are being widely reused throughout the world? All those low cost switches and wifi adapters DO use unique mac addresses?
Sun, for one, used to assign the same MAC address to every NIC in the same box.
I could see how that *could* work as long as each interface connected to a different LAN.
That was a logic Sun used. Every NIC would be connected to a different subnet, so duplicate MACs shouldn't be a problem. For the most part this worked, but some situations required a unique MAC per NIC, and Sun had a bit you could flip to turn this on. I believe it was an OpenBoot prom variable called "local-mac-address?" which you'd set to true if you wanted it to use each NICs MAC instead of the "system MAC". -Jim
On Sun, 04 Apr 2010 14:48:38 -0700 Jim Burwell <jimb@jsbc.cc> wrote:
On 4/4/2010 08:46, Jonathan Lassoff wrote:
Excerpts from John Peach's message of Sun Apr 04 08:17:28 -0700 2010:
On Sun, 4 Apr 2010 11:10:56 -0400 David Andersen <dga@cs.cmu.edu> wrote:
There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are likely to be errors, not accidental collisions.
-Dave
On Apr 4, 2010, at 10:57 AM, jim deleskie wrote:
I've seen duplicate addresses in the wild in the past, I assume there is some amount of reuse, even though they are suppose to be unique.
-jim
On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. <skandor@gmail.com> wrote:
Hi,
Lots of traffic recently about 64 bits being too short or too long.
What about mac addresses? Aren't they close to exhaustion? Should be. Or it is assumed that mac addresses are being widely reused throughout the world? All those low cost switches and wifi adapters DO use unique mac addresses?
Sun, for one, used to assign the same MAC address to every NIC in the same box.
I could see how that *could* work as long as each interface connected to a different LAN.
That was a logic Sun used. Every NIC would be connected to a different subnet, so duplicate MACs shouldn't be a problem. For the most part this worked, but some situations required a unique MAC per NIC, and Sun had a bit you could flip to turn this on. I believe it was an OpenBoot prom variable called "local-mac-address?" which you'd set to true if you wanted it to use each NICs MAC instead of the "system MAC".
You can set the MAC address to whatever you want in Solaris, using ifconfig and local-mac-address was (is) the PROM variable. -- John
In message <20100404111728.2b5c9ecf@milhouse.peachfamily.net>, John Peach writes:
On Sun, 4 Apr 2010 11:10:56 -0400 David Andersen <dga@cs.cmu.edu> wrote:
There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are likely to be errors, not accidental collisions.
-Dave
On Apr 4, 2010, at 10:57 AM, jim deleskie wrote:
I've seen duplicate addresses in the wild in the past, I assume there is some amount of reuse, even though they are suppose to be unique.
-jim
On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. <skandor@gmail.com> wrote:
Hi,
Lots of traffic recently about 64 bits being too short or too long.
What about mac addresses? Aren't they close to exhaustion? Should be. Or it is assumed that mac addresses are being widely reused throughout the world? All those low cost switches and wifi adapters DO use unique mac addresses?
Sun, for one, used to assign the same MAC address to every NIC in the same box.
Which is perfectly legal.
-- John
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Sun, 04 Apr 2010 11:17:28 -0400 John Peach <john-nanog@johnpeach.com> wrote:
On Sun, 4 Apr 2010 11:10:56 -0400 David Andersen <dga@cs.cmu.edu> wrote:
There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are likely to be errors, not accidental collisions.
-Dave
On Apr 4, 2010, at 10:57 AM, jim deleskie wrote:
I've seen duplicate addresses in the wild in the past, I assume there is some amount of reuse, even though they are suppose to be unique.
-jim
On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. <skandor@gmail.com> wrote:
Hi,
Lots of traffic recently about 64 bits being too short or too long.
What about mac addresses? Aren't they close to exhaustion? Should be. Or it is assumed that mac addresses are being widely reused throughout the world? All those low cost switches and wifi adapters DO use unique mac addresses?
Sun, for one, used to assign the same MAC address to every NIC in the same box.
That actually follows the original MAC addressing model - "48-bit Absolute Internet and Ethernet Host Numbers" http://ethernethistory.typepad.com/papers/HostNumbers.pdf As add-in cards needed their own address, because they couldn't be sure the host had one, and most likely didn't, I think that has evolved into unique MAC addresses per-interface rather than per-host. Regards, Mark.
On Sun, 4 Apr 2010, jim deleskie wrote:
I've seen duplicate addresses in the wild in the past, I assume there is some amount of reuse, even though they are suppose to be unique.
5 percent of the mac addresses in a ADSL population used the same MAC address. Turned out to be some D-link device that didn't have unique address but they all had the same, and had a feature where you could "clone" the internal PC MAC address if you wanted to, otherwise it used some default address. D-link support responded to customer inquiries with "yes, we know that they're not unique enough". Nuff said, avoid. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Sun, Apr 04, 2010 at 11:53:54AM -0300, A.B. Jr. wrote:
Hi,
Lots of traffic recently about 64 bits being too short or too long.
What about mac addresses? Aren't they close to exhaustion? Should be. Or it is assumed that mac addresses are being widely reused throughout the world? All those low cost switches and wifi adapters DO use unique mac addresses?
http://en.wikipedia.org/wiki/MAC_address The IEEE expects the MAC-48 space to be exhausted no sooner than the year 2100[3]; EUI-64s are not expected to run out in the foreseeable future. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Richard A Steenbergen wrote:
On Sun, Apr 04, 2010 at 11:53:54AM -0300, A.B. Jr. wrote:
Hi,
Lots of traffic recently about 64 bits being too short or too long.
What about mac addresses? Aren't they close to exhaustion? Should be. Or it is assumed that mac addresses are being widely reused throughout the world? All those low cost switches and wifi adapters DO use unique mac addresses?
http://en.wikipedia.org/wiki/MAC_address
The IEEE expects the MAC-48 space to be exhausted no sooner than the year 2100[3]; EUI-64s are not expected to run out in the foreseeable future.
And this is what happens when you can use 100% of the bits on "endpoint identity" and not waste huge sections of them on the decision bits for "routing topology". Of course it comes with a privacy problem if you want to use that endpoint identifier globally and not change it for every session (as some protocols that separate routable-address from endpoint-identity do) Matthew Kaufman
On Sun, Apr 4, 2010 at 1:51 PM, Matthew Kaufman <matthew@matthew.at> wrote:
http://en.wikipedia.org/wiki/MAC_address
The IEEE expects the MAC-48 space to be exhausted no sooner than the year 2100[3]; EUI-64s are not expected to run out in the foreseeable future.
And this is what happens when you can use 100% of the bits on "endpoint identity" and not waste huge sections of them on the decision bits for "routing topology".
Having around 4 orders of magnitude more addresses probably doesn't hurt either... Although even MAC-48 addresses are "wasteful" in that only 1/4 of them are assignable to/by vendors, with the other 3/4 being assigned to multicast and local addresses (the MAC equivalent of RFC1918) Scott.
On Sun, 4 Apr 2010 14:05:50 -0700 Scott Howard <scott@doc.net.au> wrote:
On Sun, Apr 4, 2010 at 1:51 PM, Matthew Kaufman <matthew@matthew.at> wrote:
http://en.wikipedia.org/wiki/MAC_address
The IEEE expects the MAC-48 space to be exhausted no sooner than the year 2100[3]; EUI-64s are not expected to run out in the foreseeable future.
And this is what happens when you can use 100% of the bits on "endpoint identity" and not waste huge sections of them on the decision bits for "routing topology".
Having around 4 orders of magnitude more addresses probably doesn't hurt either...
Although even MAC-48 addresses are "wasteful" in that only 1/4 of them are assignable to/by vendors, with the other 3/4 being assigned to multicast and local addresses (the MAC equivalent of RFC1918)
Has anybody considered lobbying the IEEE to do a point to point version of Ethernet to gets rid of addressing fields? Assuming an average 1024 byte packet size, on a 10Gbps link they're wasting 100+ Mbps. 100GE / 1TE starts to make it even more worth doing. Actually the minimum 64 byte packet size could probably go too, as that was only there for collision detection.
Scott.
On Mon, Apr 05, 2010 at 10:57:46AM +0930, Mark Smith wrote:
Has anybody considered lobbying the IEEE to do a point to point version of Ethernet to gets rid of addressing fields? Assuming an average 1024 byte packet size, on a 10Gbps link they're wasting 100+ Mbps. 100GE / 1TE starts to make it even more worth doing.
If you're lobbying to have the IEEE do something intelligent to Ethernet why don't you start with a freaking standardization of jumbo frames. The lack of a real standard and any type of negotiation protocol for two devices under different administrative control are all but guaranteeing end to end jumbo frame support will never be practical. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
On 4/4/2010 7:57 PM, Richard A Steenbergen wrote:
On Mon, Apr 05, 2010 at 10:57:46AM +0930, Mark Smith wrote:
Has anybody considered lobbying the IEEE to do a point to point version of Ethernet to gets rid of addressing fields? Assuming an average 1024 byte packet size, on a 10Gbps link they're wasting 100+ Mbps. 100GE / 1TE starts to make it even more worth doing.
If you're lobbying to have the IEEE do something intelligent to Ethernet why don't you start with a freaking standardization of jumbo frames. The lack of a real standard and any type of negotiation protocol for two devices under different administrative control are all but guaranteeing end to end jumbo frame support will never be practical.
Not that I disagree, given that we use them rather a lot but 7.2usec (at 10Gbe) is sort of a long time to wait before a store and forward arch switch gets down to the task of figuring out what to do with the packet. The problem gets worse if mtu sizes bigger than 9k ever become popular, kind of like being stuck behind an elephant while boarding an elevator.
On Mon, Apr 5, 2010 at 12:05 AM, joel jaeggli <joelja@bogus.com> wrote:
On 4/4/2010 7:57 PM, Richard A Steenbergen wrote:
On Mon, Apr 05, 2010 at 10:57:46AM +0930, Mark Smith wrote:
Has anybody considered lobbying the IEEE to do a point to point version of Ethernet to gets rid of addressing fields? Assuming an average 1024 byte packet size, on a 10Gbps link they're wasting 100+ Mbps. 100GE / 1TE starts to make it even more worth doing.
If you're lobbying to have the IEEE do something intelligent to Ethernet why don't you start with a freaking standardization of jumbo frames. The lack of a real standard and any type of negotiation protocol for two devices under different administrative control are all but guaranteeing end to end jumbo frame support will never be practical.
Not that I disagree, given that we use them rather a lot but 7.2usec (at 10Gbe) is sort of a long time to wait before a store and forward arch switch gets down to the task of figuring out what to do with the packet. The problem gets worse if mtu sizes bigger than 9k ever become popular, kind of like being stuck behind an elephant while boarding an elevator.
I didn't run the numbers, but my guesstimate is that would be roughly half the latency that a max sized standard packet would have taken on a 1Gbe switch. It sound reasonable to me that at some point during the march from 10->100->1000->10000 mbit/sec a decision could have been made that one of those upgrades would only decrease max. per hop packet latency by a factor of 2 rather then 10. Particularly since when first introduced, each speed increment was typically used for aggregating a bunch of slower speed links which meant that the actual minimum total latency was already being constrained by the latency on those slower links anyway. OTOH, I totally buy the argument on the difficulty of frame size negotiation and backward compatibility. I think that one of the reasons for the continuing success of "Ethernet" technologies has been implementation simplicity and 100% compatibility above the level of the NIC. Bill Bogstad
On Apr 5, 2010, at 12:09 02PM, Jay Nakamura wrote:
negotiation and backward compatibility. I think that one of the reasons for the continuing success of "Ethernet" technologies has been implementation simplicity and 100% compatibility above the level of the NIC.
I would have attributed the success of Ethernet to price!
You've got the causality wrong -- it wasn't cheap, way back when. --Steve Bellovin, http://www.cs.columbia.edu/~smb
I would have attributed the success of Ethernet to price!
You've got the causality wrong -- it wasn't cheap, way back when.
I remember back in '93~94ish (I think) you could get a off brand 10BT card for less than $100, as oppose to Token Ring which was $300~400. I can't remember anything else that was cheaper back then. If you go back before that, I don't know. -Jay
On Mon, 05 Apr 2010 13:29:20 EDT, Jay Nakamura said:
I would have attributed the success of Ethernet to price!
You've got the causality wrong -- it wasn't cheap, way back when.
I remember back in '93~94ish (I think) you could get a off brand 10BT card for less than $100, as oppose to Token Ring which was $300~400. I can't remember anything else that was cheaper back then. If you go back before that, I don't know.
Steve is talking mid-80s pricing, not mid-90s. By '93 or so, the fact that Ethernet was becoming ubiquitous had already forced the price down.
On Apr 5, 2010, at 1:43 52PM, Valdis.Kletnieks@vt.edu wrote:
On Mon, 05 Apr 2010 13:29:20 EDT, Jay Nakamura said:
I would have attributed the success of Ethernet to price!
You've got the causality wrong -- it wasn't cheap, way back when.
I remember back in '93~94ish (I think) you could get a off brand 10BT card for less than $100, as oppose to Token Ring which was $300~400. I can't remember anything else that was cheaper back then. If you go back before that, I don't know.
Steve is talking mid-80s pricing, not mid-90s. By '93 or so, the fact that Ethernet was becoming ubiquitous had already forced the price down.
Yup. 10 years earlier, a 3Com Ethernet card for a Vax cost about $1500, if memory serves. --Steve Bellovin, http://www.cs.columbia.edu/~smb
On 05/04/2010 18:51, Steven Bellovin wrote:
Yup. 10 years earlier, a 3Com Ethernet card for a Vax cost about $1500, if memory serves.
To be fair, everything for a vax was somewhat pricey. And slow. On an even more unrelated note, does anyone remember the day that CMU-TEK tcp/ip stopped working some time in the early 1990s? That was a load of fun. Nick
Nick Hilliard wrote:
On an even more unrelated note, does anyone remember the day that CMU-TEK tcp/ip stopped working some time in the early 1990s? That was a load of fun.
I remember a satellite taking care of trans-Atlantic internet traffic going down in the mid 90s causing 30 minute lags on irc, if that counts. :-)
To be fair, everything for a vax was somewhat pricey. And slow.
On an even more unrelated note, does anyone remember the day that CMU-TEK tcp/ip stopped working some time in the early 1990s? That was a load of fun.
What made it stop working? I was the guy to blame for the IP/TCP/UDP parts of "CMU-TEK" and had long since left CMU by the mid-90s. Dale Moore (still at CMU last time I checked) did the applications. --Vince
On April 5, 2010 at 13:51 smb@cs.columbia.edu (Steven Bellovin) wrote:
Yup. 10 years earlier, a 3Com Ethernet card for a Vax cost about $1500, if memory serves.
Early-mid 80s? I'd say at least twice that, I don't think there were too many cards for Vaxes and similar for less than $5K. An NIU20 for DECSYSTEM-20 was a 3U box, it was just a single ethernet interface, and cost around $15-20K. About the same price for an IBM370 (specifically, 3090) ethernet box which included a PC/AT and sat on a box about the size of a dorm cube refrigerator which, if you opened it up, contained a chunk of Unibus backplane in which was a (I think 3COM?) ethernet board (and power supply etc.), some common Vax ethernet card. Weird, the whole thing was basically a kludged together Unibus to bus/tag channel adapter or maybe even 3274 using something like an IRMA board? I knew it well because it crashed a lot and operations decided I was the only one who had the magic voodoo to bring it back to life which as I remember was to POWER-CYCLE IT! Well, sometimes you had to power-cycle it more than once to get it all to synch. And we had to put coins in those boxes to get our packets through! If you wanted an email it cost a dime, FTP was 75cents for the first 100KB and 10c for each KB thereafter...ok, that may not be entirely accurate. -b
On Apr 5, 2010, at 4:58 59PM, Barry Shein wrote:
On April 5, 2010 at 13:51 smb@cs.columbia.edu (Steven Bellovin) wrote:
Yup. 10 years earlier, a 3Com Ethernet card for a Vax cost about $1500, if memory serves.
Early-mid 80s? I'd say at least twice that, I don't think there were too many cards for Vaxes and similar for less than $5K.
It could have been $3K, but I don't think it was higher.
An NIU20 for DECSYSTEM-20 was a 3U box, it was just a single ethernet interface, and cost around $15-20K.
About the same price for an IBM370 (specifically, 3090) ethernet box which included a PC/AT and sat on a box about the size of a dorm cube refrigerator which, if you opened it up, contained a chunk of Unibus backplane in which was a (I think 3COM?) ethernet board (and power supply etc.), some common Vax ethernet card. Weird, the whole thing was basically a kludged together Unibus to bus/tag channel adapter or maybe even 3274 using something like an IRMA board? I knew it well because it crashed a lot and operations decided I was the only one who had the magic voodoo to bring it back to life which as I remember was to POWER-CYCLE IT! Well, sometimes you had to power-cycle it more than once to get it all to synch.
I remember the design, but never used it.
And we had to put coins in those boxes to get our packets through! If you wanted an email it cost a dime, FTP was 75cents for the first 100KB and 10c for each KB thereafter...ok, that may not be entirely accurate.
Of course not -- you forgot about the credit card reader option. --Steve Bellovin, http://www.cs.columbia.edu/~smb
On Mon, Apr 5, 2010 at 10:51 AM, Steven Bellovin <smb@cs.columbia.edu> wrote:
On Apr 5, 2010, at 1:43 52PM, Valdis.Kletnieks@vt.edu wrote:
Steve is talking mid-80s pricing, not mid-90s. By '93 or so, the fact that Ethernet was becoming ubiquitous had already forced the price down.
Yup. 10 years earlier, a 3Com Ethernet card for a Vax cost about $1500, if memory serves.
$1500 is what I remember also (forget if that was the Interlan NI1010 or the DEUNA / DELUA), plus of course the cost of whatever Unibus you're burning the bandwidth on. Serial was cheaper, but most of the competition wasn't. I assume Datakit boards had a regular list price for customers other than intra-Bell? -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
On 05 Apr 2010 12:43, Valdis.Kletnieks@vt.edu wrote:
On Mon, 05 Apr 2010 13:29:20 EDT, Jay Nakamura said:
I would have attributed the success of Ethernet to price!
You've got the causality wrong -- it wasn't cheap, way back when.
I remember back in '93~94ish (I think) you could get a off brand 10BT card for less than $100, as oppose to Token Ring which was $300~400. I can't remember anything else that was cheaper back then. If you go back before that, I don't know.
Steve is talking mid-80s pricing, not mid-90s. By '93 or so, the fact that Ethernet was becoming ubiquitous had already forced the price down.
Ah, but what _caused_ Ethernet to become ubiquitous, given the price was initially comparable? The only explanation I can think of is the raft of cheap NE2000 knock-offs that hit the market in the late 1980s, which gave Ethernet a major price advantage over Token Ring (the chips for which all vendors _had_ to buy from IBM at ridiculous cost). That, in turn, led to mass adoption and further economies of scale, pushing the price lower and lower in a virtuous cycle. Still, lots of shops stuck with TR well into the mid- and even late 1990s because Ethernet didn't perform as well as TR under moderate to high utilization by multiple hosts, not to mention IBM's insistence that TR was required for SNA. It wasn't until Ethernet switching came out, mostly solving CSMA/CD's performance problems and eventually leading to full-duplex operation, that it was entirely obvious which was going to win, and I spent several years doing almost nothing but helping large enterprises convert to Ethernet (usually with the help of DLSw). By that point, off-brand Ethernet chips cost _less than 1%_ of what IBM's TR chips did, thanks to competition and sheer volume, so vendors had started including them "for free" on every PC and server, and that was the final nail in TR's coffin. (LocalTalk, ARCnet, and a variety of other physical layers suffered a similar fate, but unlike IBM, their backers quickly switched to Ethernet when they realized they couldn't compete with it on price _or_ on performance given their limited volumes, so those deaths were more sudden and absolute than TR's.) As to why no other technology has managed to dislodge Ethernet, though, I think it's fairly clear that's because the various successors to 10BaseT have all maintained the same connector and the same framing, which makes for trivial upgrades that deliver regular (and significant) performance improvements as customers' equipment replacement cycle turns. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On 4/6/2010 10:39 PM, Stephen Sprunk wrote:
On 05 Apr 2010 12:43, Valdis.Kletnieks@vt.edu wrote:
On Mon, 05 Apr 2010 13:29:20 EDT, Jay Nakamura said:
I would have attributed the success of Ethernet to price!
You've got the causality wrong -- it wasn't cheap, way back when.
I remember back in '93~94ish (I think) you could get a off brand 10BT card for less than $100, as oppose to Token Ring which was $300~400. I can't remember anything else that was cheaper back then. If you go back before that, I don't know.
Steve is talking mid-80s pricing, not mid-90s. By '93 or so, the fact that Ethernet was becoming ubiquitous had already forced the price down.
Ah, but what _caused_ Ethernet to become ubiquitous, given the price was initially comparable?
Early standardization.
The only explanation I can think of is the raft of cheap NE2000 knock-offs that hit the market in the late 1980s, which gave Ethernet a major price advantage over Token Ring (the chips for which all vendors _had_ to buy from IBM at ridiculous cost).
Metcalf didn't make computers, whereas IBM and Datapoint did, protecting their captive markets cost both of them quite dearly.
On Tue, 06 Apr 2010 23:02:12 -0400 joel jaeggli <joelja@bogus.com> wrote:
Ah, but what _caused_ Ethernet to become ubiquitous, given the price was initially comparable?
Early standardization.
In one of my other favorite books, Gigabit Ethernet, Rich Seifert says: "[...] IBM was the only computer *systems* manufacturer actively promoting a Token Ring-based strategy. Ultimately, the reason we build networks is to attach the computers that supports the users' applications. Network equipment vendors provide products to support the interconnection of the computers, but the network is the means, not the end. Ethernet had the necessary broad support from many computer systems manufacturers from the very beginning, including not only the original DIX consortium, but also major players like Sun Microsystems, Hewlett-Packard, and dozens of others." John
In article <4BBBF070.6000403@sprunk.org>, Stephen Sprunk <stephen@sprunk.org> writes
Ah, but what _caused_ Ethernet to become ubiquitous, given the price was initially comparable?
For me, as an SME user, I started using Ethernet when Dlink introduced an ISA card [DE205] which had a 4-port hub built in (actually 5-port if you counted the internal one), at not a great deal more than a normal 10Base-T card. I think it was about $250, when a typical desktop PC was $2500. So all I needed to build my network was one of those, some cable, and add-in Ethernet cards for each other PC I wanted to bring into the LAN. As icing on the cake, they also had a Centronics-port dongle to hook up almost all laptops very easily, and in an emergency you could even use it on a desktop. Price was a major feature, but interoperability and backwards compatibility were the tipping points. -- Roland Perry
For me, as an SME user, I started using Ethernet when Dlink introduced an ISA card [DE205] which had a 4-port hub built in (actually 5-port if you counted the internal one), at not a great deal more than a normal 10Base-T card. I think it was about $250, when a typical desktop PC was $2500.
[...]
Price was a major feature, but interoperability and backwards compatibility were the tipping points.
Ah, yes, backwards compatibility: implementing the fantastic feature of breaking the network... we all remember the fun of what happened when someone incorrectly unhooked a 10base2 network segment; D-Link managed to one-up that on the theoretically more-robust 10baseT/UTP by introducing a card that'd break your network when you powered off the attached PC. Designer of that deserved to be whipped with some RG-58. :-) ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
In article <201004071023.o37ANtww018405@aurora.sol.net>, Joe Greco <jgreco@ns.sol.net> writes
interoperability and backwards compatibility were the tipping points.
Ah, yes, backwards compatibility: implementing the fantastic feature of breaking the network...
By "backwards compatibility" I mean the ability to use the new LAN from a laptop that didn't have an Ethernet connection built in, and didn't have an optional [proprietary] internal Ethernet card available either. Later on, of course, you would get PCMCIA cards and USB dongles rather than Centronics-port dongles. But the market for these remained dominated by the Ethernet standard, rather than others.
we all remember the fun of what happened when someone incorrectly unhooked a 10base2 network segment; D-Link managed to one-up that on the theoretically more-robust 10baseT/UTP by introducing a card that'd break your network when you powered off the attached PC.
That tale of woe doesn't really sound like it's the fault of backwards compatibility. Didn't the operational status of the LAX immigration department fall to zero for almost a whole day, once; as a result of a rogue network card crashing the LAN? -- Roland Perry
In article <201004071023.o37ANtww018405@aurora.sol.net>, Joe Greco <jgreco@ns.sol.net> writes
interoperability and backwards compatibility were the tipping points.
Ah, yes, backwards compatibility: implementing the fantastic feature of breaking the network...
By "backwards compatibility" I mean the ability to use the new LAN from a laptop that didn't have an Ethernet connection built in, and didn't have an optional [proprietary] internal Ethernet card available either.
There are a lot of things to target with the term, I was picking conveniently. :-)
we all remember the fun of what happened when someone incorrectly unhooked a 10base2 network segment; D-Link managed to one-up that on the theoretically more-robust 10baseT/UTP by introducing a card that'd break your network when you powered off the attached PC.
That tale of woe doesn't really sound like it's the fault of backwards compatibility.
No, but I remember network people talking gleefully about the benefits of 10baseT (and come on - it has lots), and how it fixed the "someone needed to move a PC and disconnected the cables from the T rather than the T from the NIC" problem... and along came D-Link (and some other vendors I think) with the brilliant idea of a host-integrated hub. Now, remember, some network guys walked around with new-in-bag BNC T's in their pocket because they'd run across someone who disappeared a T every month or two, and there's great power in turning your back, twiddling for a few seconds, and then being able to holler "Network's back up!"... Unfortunately, power-cycling crashed PC's is (was?) pretty common, and many users are (were?) also trained to shut off PC's when done, so here you've introduced something that is by-design going to fail periodically. Not just if-and-when someone decides to move a computer and screws it up. Of course, if someone actually removes the PC in question, and does not realize that the network actually feeds _through_ the PC, um, well, you cannot just whip a T out of your pocket to "fix" the network. To me, this is a Dilbert-class engineering failure. I would imagine that if you could implement a hub on the network card, the same chip(s) would work in an external tin can with a separate power supply. Designing a product that actually exhibits a worse failure mode than 10base2 is ... strange to me. I was sarcastically referring to this as "backwards compatibility", possibly also with New Enhanced Features, ha ha.
Didn't the operational status of the LAX immigration department fall to zero for almost a whole day, once; as a result of a rogue network card crashing the LAN?
Probably. Not my area of the country. There are plenty of examples of networking disasters. ;-) ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Wednesday 07 April 2010 07:18:57 am Joe Greco wrote:
To me, this is a Dilbert-class engineering failure. I would imagine that if you could implement a hub on the network card, the same chip(s) would work in an external tin can with a separate power supply. Designing a product that actually exhibits a worse failure mode than 10base2 is ... strange to me.
I have in my gear museum a fairly large box with a couple of this type of 'hub on a card' installed. And in this particular case, it made perfect sense, as the box is an Evergreen Systems CAPserver, and has 16 486 single-board computers tied to two 8-port hub cards (two ports on each modular plug, too), with....wait for it... a 10Base-2 uplink. These were used mostly for remote network access and remote desktop access. If you want more data on this old and odd box, see http://www.bomara.com/Eversys/capserver2300.htm I can see a hub card being useful in an old NetWare server setting, though, since if the server went down you might as well not have a network in the first place, in that use case.
On Wednesday 07 April 2010 07:18:57 am Joe Greco wrote:
To me, this is a Dilbert-class engineering failure. I would imagine that if you could implement a hub on the network card, the same chip(s) would work in an external tin can with a separate power supply. Designing a product that actually exhibits a worse failure mode than 10base2 is ... strange to me.
I have in my gear museum a fairly large box with a couple of this type of 'hub on a card' installed. And in this particular case, it made perfect sense, as the box is an Evergreen Systems CAPserver, and has 16 486 single-board computers tied to two 8-port hub cards (two ports on each modular plug, too), with....wait for it... a 10Base-2 uplink. These were used mostly for remote network access and remote desktop access.
If you want more data on this old and odd box, see http://www.bomara.com/Eversys/capserver2300.htm
I can see a hub card being useful in an old NetWare server setting, though, since if the server went down you might as well not have a network in the first place, in that use case.
Certainly. I can come up with a bunch of reasonable-use scenarios too, but most of the people here will have run into that awful situation where a product is used in a manner that isn't "Recommended". In this case, I know that some of these cards were marketed in the same manner that workgroup hubs/switches are marketed; you would daisy-chain these stupid things so that your PC would feed the cubes right around you and then have an uplink and downlink a few cubes to the next "hub". Remember, it was this strange time when people were uncertain about how networks were going to evolve, and what the next thing would be, and even then, 10baseT was being deployed over Cat3 (sometimes recycled/ repurposed), so any sort of "enabling" gadget such as these cards had a tendency to be abused in various ways. Two ports on each modular plug, though.... (shudder) ;-) ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Apr 7, 2010, at 11:03 16AM, Joe Greco wrote:
On Wednesday 07 April 2010 07:18:57 am Joe Greco wrote:
To me, this is a Dilbert-class engineering failure. I would imagine that if you could implement a hub on the network card, the same chip(s) would work in an external tin can with a separate power supply. Designing a product that actually exhibits a worse failure mode than 10base2 is ... strange to me.
I have in my gear museum a fairly large box with a couple of this type of 'hub on a card' installed. And in this particular case, it made perfect sense, as the box is an Evergreen Systems CAPserver, and has 16 486 single-board computers tied to two 8-port hub cards (two ports on each modular plug, too), with....wait for it... a 10Base-2 uplink. These were used mostly for remote network access and remote desktop access.
If you want more data on this old and odd box, see http://www.bomara.com/Eversys/capserver2300.htm
I can see a hub card being useful in an old NetWare server setting, though, since if the server went down you might as well not have a network in the first place, in that use case.
Certainly. I can come up with a bunch of reasonable-use scenarios too, but most of the people here will have run into that awful situation where a product is used in a manner that isn't "Recommended".
In this case, I know that some of these cards were marketed in the same manner that workgroup hubs/switches are marketed; you would daisy-chain these stupid things so that your PC would feed the cubes right around you and then have an uplink and downlink a few cubes to the next "hub".
When I had the need to wire a building around 1987, I opted for the multiport 10Base5 repeaters that DEC made -- they were called DELUAs, I think. I'd had quite enough of distributed single points of failure, thank you.
Remember, it was this strange time when people were uncertain about how networks were going to evolve, and what the next thing would be, and even then, 10baseT was being deployed over Cat3 (sometimes recycled/ repurposed), so any sort of "enabling" gadget such as these cards had a tendency to be abused in various ways.
Right -- the wire and pin assignments for 10BaseT and 100BaseT were designed to permit sharing the cable between Ethernet and phone.
Two ports on each modular plug, though.... (shudder) ;-)
Hey, I had that in my house on my 100BaseT network, till I upgraded to gigE and had to give in and buy another switch. (Sigh -- home network configurations of NANOGers. I'm contemplating putting in VLANs now...) --Steve Bellovin, http://www.cs.columbia.edu/~smb
When I had the need to wire a building around 1987, I opted for the multiport 10Base5 repeaters that DEC made -- they were called DELUAs, I think. I'd had quite enough of distributed single points of failure, thank you.
Think those were something else; DEMPR = Digital Ethernet Multi Port Repeater DELNI = Digital Ethernet Local Network Interconnect ("hub") Threw some away a few years ago.
Hey, I had that in my house on my 100BaseT network, till I upgraded to gigE and had to give in and buy another switch. (Sigh -- home network configurations of NANOGers. I'm contemplating putting in VLANs now...)
VLAN's == fun ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
In article <DAA7E8AD-EFFF-4076-85DB-1CDC19AFA483@cs.columbia.edu>, Steven Bellovin <smb@cs.columbia.edu> writes
Remember, it was this strange time when people were uncertain about how networks were going to evolve, and what the next thing would be, and even then, 10baseT was being deployed over Cat3 (sometimes recycled/ repurposed), so any sort of "enabling" gadget such as these cards had a tendency to be abused in various ways.
Right -- the wire and pin assignments for 10BaseT and 100BaseT were designed to permit sharing the cable between Ethernet and phone.
I wired a new-build house (of mine) like that in 1995. The CAT5 cable was expensive enough that it made sense to share. And it worked. The bigger challenge was getting Internet to the house, not round the house. Ten years later, both voice and data would probably have been better done by wireless (DECT and wifi respectively). -- Roland Perry
On 04/07/2010 04:18 AM, Joe Greco wrote:
To me, this is a Dilbert-class engineering failure. I would imagine that if you could implement a hub on the network card, the same chip(s) would work in an external tin can with a separate power supply. Designing a product that actually exhibits a worse failure mode than 10base2 is ... strange to me.
This reminds of me of the failure-mode-within-a-failure-mode of 10b2 with vaxstation2000's using vms's vaxcluster software. Unplugging the 10b2 gave you a window of about 10 seconds before one by one every vaxstation2000 would bugcheck. I was always rather astonished that nobody at DEC either noticed it, or thought it was a very big deal because the bug survived a long time. Mike
On 04/07/2010 04:18 AM, Joe Greco wrote:
To me, this is a Dilbert-class engineering failure. I would imagine that if you could implement a hub on the network card, the same chip(s) would work in an external tin can with a separate power supply. Designing a product that actually exhibits a worse failure mode than 10base2 is ... strange to me.
This reminds of me of the failure-mode-within-a-failure-mode of 10b2 with vaxstation2000's using vms's vaxcluster software. Unplugging the 10b2 gave you a window of about 10 seconds before one by one every vaxstation2000 would bugcheck. I was always rather astonished that nobody at DEC either noticed it, or thought it was a very big deal because the bug survived a long time. Mike
In article <201004071118.o37BIvK1022393@aurora.sol.net>, Joe Greco <jgreco@ns.sol.net> writes
Unfortunately, power-cycling crashed PC's is (was?) pretty common, and many users are (were?) also trained to shut off PC's when done, so here you've introduced something that is by-design going to fail periodically.
OK, I agree that fitting a PC-powered hub into a client PC isn't the best decision in the world. But losing one segment of a 10Base-T LAN (which was the technology I used) is not the end of the world, and I took the precaution of installing the hub in my server. Despite these potential operational banana skins, it was still a product that tipped me irrevocably into the world of Ethernet (having earlier toyed with pale imitations). -- Roland Perry
2010/4/4 Scott Howard <scott@doc.net.au>
On Sun, Apr 4, 2010 at 1:51 PM, Matthew Kaufman <matthew@matthew.at> wrote:
http://en.wikipedia.org/wiki/MAC_address
The IEEE expects the MAC-48 space to be exhausted no sooner than the
year
2100[3]; EUI-64s are not expected to run out in the foreseeable future.
And this is what happens when you can use 100% of the bits on "endpoint identity" and not waste huge sections of them on the decision bits for "routing topology".
Having around 4 orders of magnitude more addresses probably doesn't hurt either...
Although even MAC-48 addresses are "wasteful" in that only 1/4 of them are assignable to/by vendors, with the other 3/4 being assigned to multicast and local addresses (the MAC equivalent of RFC1918)
Scott.
Wasteful in many ways. While most of end user devices work with temporarily assigned IP addresses, or even with RFC1918 behind a NAT, very humble ethernet devices come from factory with a PERMANENTE unique mac address. And one of those devices are thrown away – let’s say a cell phone with wifi, or a cheap NIC PC card - the mac address is lost forever. Doesn’t this sound not reasonable? A.b. --
On Sun, Apr 4, 2010 at 9:17 PM, A.B. Jr. <skandor@gmail.com> wrote:
While most of end user devices work with temporarily assigned IP addresses, or even with RFC1918 behind a NAT, very humble ethernet devices come from factory with a PERMANENTE unique mac address.
Just don't tell Greenpeace - I don't think we're quite at the state yet where we need to start recycling the MAC addresses from thrown out CPE routers. Plus I'm sure the CA government will be more than happy to add a $4/device recycling fee for anything sold with a MAC address if they find out about it. Scott (PS, I've run out of Popcorn - anyone got to share?)
I keep seeing mention here of the "permanent" MAC address. Really? Permanent? Been a long time, but it seems like one of the fun things about having DECNet-phase IV on the network was its propensity for changing the MAC address to be the DECNet address. And it seems like the HP-UX machines (among others) could write what every they wanted to as addresses. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Date: Sun, 04 Apr 2010 23:30:42 -0500 From: Larry Sheldon <LarrySheldon@cox.net>
I keep seeing mention here of the "permanent" MAC address.
Really? Permanent?
Been a long time, but it seems like one of the fun things about having DECNet-phase IV on the network was its propensity for changing the MAC address to be the DECNet address.
And it seems like the HP-UX machines (among others) could write what every they wanted to as addresses.
Almost every system can re-write the MAC address. It's in the original 802.3 and DIX (Blue Book) Ethernet standards. I have not run into a system in some time that lacked this capability. Works on Windows, MacOS, Linux, and BSD. That said, all 802.3 devices are expected to have a permanent MAC address in ROM. At initialization time, that address is always used until software can program in the new address. Made MOP-DL booting (DECnet equivalent of bootp) interesting. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On Sun, Apr 4, 2010 at 9:53 AM, A.B. Jr. <skandor@gmail.com> wrote:
Lots of traffic recently about 64 bits being too short or too long. What about mac addresses? Aren't they close to exhaustion? Should be. Or it is assumed that mac addresses are being widely reused throughout the world? All those low cost switches and wifi adapters DO use unique mac addresses?
Hardware MAC-48 addresses are not assigned based on a network topology. The first 24 bits are used for OUI which is an ID number applied for [and paid for] by a manufacturer of network devices, the 2nd LSB of the most significant byte is reserved for 'local vs universal administration flag', and the LSB of the most significant byte is reserved for unicast/multicast flag. The bottom 24 bits are assigned by manufacturer. So there are 22 bits of usable global unicast OUIs, that is 4,194,304 possible. and each OUI has 16,777,216 MAC address numbers. Of the possible OUIs, only 13,557 are currently listed as allocated in the IEEE OUI listing. http://standards.ieee.org/regauth/oui/index.shtml So a theoretical maximum of 227,448,717,312 unicast MAC addresses could be globally assigned today (which is a vast overestimate, assuming all presently assigned OUIs are already completely exhausted). Out of 70,368,744,177,664, that is what, 0.3% ? -- -J
On Sun, 4 Apr 2010, A.B. Jr. wrote:
Hi,
Lots of traffic recently about 64 bits being too short or too long.
What about mac addresses? Aren't they close to exhaustion? Should be. Or it is assumed that mac addresses are being widely reused throughout the world? All those low cost switches and wifi adapters DO use unique mac addresses?
Since they only really need to be unique per broadcast domain, it doesn't really matter. You can I could use the same MAC addresses on all our home gear, and never know it. For manufacturers, it's probably reasonably safe to reuse MAC addresses they put on 10mbit ISA ethernet cards...if they were a manufacturer back then. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Mon, 05 Apr 2010 16:36:26 EDT, Jon Lewis said:
Since they only really need to be unique per broadcast domain, it doesn't really matter. You can I could use the same MAC addresses on all our home gear, and never know it. For manufacturers, it's probably reasonably safe to reuse MAC addresses they put on 10mbit ISA ethernet cards...if they were a manufacturer back then.
Until you buy 25 cards with the same MAC address and deploy them all across your enterprise - the problem can go un-noticed for *weeks* as long as two boxes aren't squawking on the same subnet at the same time(*). Of course, you never stop to actually *check* that two cards in different machines have the same address, because That Never Happens, and you spin your wheels trying to figure out why your switching gear is confused about the MAC addresses it's seeing (and it always takes 3 or 4 tickets before one actually includes the message "Duplicate MAC address detected" in the problem report..) (*) And as Murphy predicts, whenever it happens, one of the two offenders will give up in disgust, power off the machine, and go on coffee break so the arp cache has timed out by the time you start trying to work the trouble ticket. ;) (Yes, we're mostly older and wiser now, and more willing to include "the damned hardware is posessed by an Imp of Perversity" in our troubleshooting analysis. Had an SL8500 tape library last week that reported 'Drive State: Unpowered' and 'Drive Status: Not Communicating' and still reported 'Drive Health: Good'.
On Apr 5, 2010, at 5:08 PM, Valdis.Kletnieks@vt.edu wrote:
On Mon, 05 Apr 2010 16:36:26 EDT, Jon Lewis said:
Since they only really need to be unique per broadcast domain, it doesn't really matter. You can I could use the same MAC addresses on all our home gear, and never know it. For manufacturers, it's probably reasonably safe to reuse MAC addresses they put on 10mbit ISA ethernet cards...if they were a manufacturer back then.
Until you buy 25 cards with the same MAC address and deploy them all across your enterprise
I don't think that's possible given that Jon was suggesting. I'm 3COM, I made ISA 10Base2 / 10Base5 cards in the 90s. I run out of MAC addresses. Instead of going to get more - if I even can! - I recycle those MAC addresses, figuring the 10GE PCI-X cards I'm making now have 0.000% chance of being on the same b-cast domain as one of those old ISA cards. Even if I am wrong, the max collision possibility is 2, not 25. Seems reasonable. If I am wrong, I'll apologize profusely, refund the price of the 10G card I gave the customer, ship him a new one free, so he gets two he can use (assuming he has more than one b-cast domain), which would probably make the customer happy. Wanna bet how many times 3COM would have to ship free 10GE cards? -- TTFN, patrick
- the problem can go un-noticed for *weeks* as long as two boxes aren't squawking on the same subnet at the same time(*). Of course, you never stop to actually *check* that two cards in different machines have the same address, because That Never Happens, and you spin your wheels trying to figure out why your switching gear is confused about the MAC addresses it's seeing (and it always takes 3 or 4 tickets before one actually includes the message "Duplicate MAC address detected" in the problem report..)
(*) And as Murphy predicts, whenever it happens, one of the two offenders will give up in disgust, power off the machine, and go on coffee break so the arp cache has timed out by the time you start trying to work the trouble ticket. ;)
(Yes, we're mostly older and wiser now, and more willing to include "the damned hardware is posessed by an Imp of Perversity" in our troubleshooting analysis. Had an SL8500 tape library last week that reported 'Drive State: Unpowered' and 'Drive Status: Not Communicating' and still reported 'Drive Health: Good'.
On Mon, 05 Apr 2010 17:26:53 EDT, "Patrick W. Gilmore" said:
I'm 3COM, I made ISA 10Base2 / 10Base5 cards in the 90s. I run out of MAC addresses. Instead of going to get more - if I even can! - I recycle those MAC addresses
There were several cases of production run errors from multiple vendors, where the MAC address went 14, 15, 16, 17, 17, 17, 17, *thwack*, 18, 19....
On 4/5/2010 5:26 PM, Patrick W. Gilmore wrote:
On Apr 5, 2010, at 5:08 PM, Valdis.Kletnieks@vt.edu wrote:
On Mon, 05 Apr 2010 16:36:26 EDT, Jon Lewis said:
Since they only really need to be unique per broadcast domain, it doesn't really matter. You can I could use the same MAC addresses on all our home gear, and never know it. For manufacturers, it's probably reasonably safe to reuse MAC addresses they put on 10mbit ISA ethernet cards...if they were a manufacturer back then.
Until you buy 25 cards with the same MAC address and deploy them all across your enterprise
I don't think that's possible given that Jon was suggesting.
I'm 3COM, I made ISA 10Base2 / 10Base5 cards in the 90s. I run out of MAC addresses. Instead of going to get more - if I even can! - I recycle those MAC addresses, figuring the 10GE PCI-X cards I'm making now have 0.000% chance of being on the same b-cast domain as one of those old ISA cards.
Even if I am wrong, the max collision possibility is 2, not 25.
Seems reasonable. If I am wrong, I'll apologize profusely, refund the price of the 10G card I gave the customer, ship him a new one free, so he gets two he can use (assuming he has more than one b-cast domain), which would probably make the customer happy. Wanna bet how many times 3COM would have to ship free 10GE cards?
3com is now HP and i doubt very much that either company would bother with that approach... That said, the volume production run for a circa 1992 isa bus ethernet nic (or the enitre sun microsystems product line for that matter) is propably two orders of magnitude lower than say the minimum volume production of mini-pci-express wireless card that goes into a laptop, and laptops might have two or three mac addresses.
On Mon, 5 Apr 2010, Patrick W. Gilmore wrote:
Until you buy 25 cards with the same MAC address and deploy them all across your enterprise
I don't think that's possible given that Jon was suggesting.
Given what I was suggesting, no...but there have been multiple cases of a vendor screwing up and producing large runs of devices/cards all with the same MAC address. IIRC, there was a batch of Netgear PCI NICs where you might find all the NICs in a multipack box had the same MAC address. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 4/5/2010 15:36, Jon Lewis wrote:
On Sun, 4 Apr 2010, A.B. Jr. wrote:
Hi,
Lots of traffic recently about 64 bits being too short or too long.
What about mac addresses? Aren't they close to exhaustion? Should be. Or it is assumed that mac addresses are being widely reused throughout the world? All those low cost switches and wifi adapters DO use unique mac addresses?
Since they only really need to be unique per broadcast domain, it doesn't really matter. You can I could use the same MAC addresses on all our home gear, and never know it. For manufacturers, it's probably reasonably safe to reuse MAC addresses they put on 10mbit ISA ethernet cards...if they were a manufacturer back then.
Seems like they have be unique within a DHCP "domain". And you'd have to pretty much outlaw mobiles. Wouldn't you? (Is there an accepted bit of nomenclature for all of the networks that forward DHCP traffic to a given cluster of servers?) -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
participants (34)
-
A.B. Jr. -
Barry Shein -
Bill Bogstad -
Bill Stewart -
David Andersen -
James Hess -
Jay Nakamura -
Jeroen van Aart -
Jim Burwell -
jim deleskie -
Joe Greco -
joel jaeggli -
John Kristoff -
John Peach -
Jon Lewis -
Jonathan Lassoff -
Kevin Oberman -
Lamar Owen -
Larry Sheldon -
Mark Andrews -
Mark Smith -
Matthew Kaufman -
Michael Thomas -
Mikael Abrahamsson -
Nick Hilliard -
Patrick W. Gilmore -
Richard A Steenbergen -
Roland Perry -
Scott Howard -
Stephen Sprunk -
Steven Bellovin -
Valdis.Kletnieks＠vt.edu -
Vince Fuller -
William Herrin