Returning to the era of 'duplicated' Ethernet addresses

July 3, 2010

Once upon a time back in the old days, Sun caused quite a stir by deciding that they would make the Ethernet addresses for their hardware be an attribute of the machine, not of the network interface. Or to translate, Sun machines used the same Ethernet address on all of their interfaces instead of doing what everyone else did, which was to have a different Ethernet address on each interface. This is spec-legal but caused various sorts of annoyances for system administrators and network designers; among the set of people who care about this stuff at all, there were many who felt that Sun had made the wrong decision and life was just simpler when multi-homed machines had different MAC addresses on different interfaces.

Over time this became less important as Sun's servers became less popular, and today this particular bit of trivia is probably long forgotten in most places. Even Sun's x86 servers used per-interface Ethernet addresses (and for all I know, Sun gave up on this in the end on their SPARC machines too).

Well, guess what. Those days are back, courtesy of VLAN-aware hosts. Such a machine has only a single physical network interface with a single Ethernet address, but that single interface is used by multiple networks through VLAN tagging. Outgoing Ethernet frames on each VLAN generally have no choice but to use the physical interface's Ethernet address, and so the host will be seen as having the same Ethernet address on different VLAN networks.

(There might be a use for this in detecting whether a host is using VLANs or physically separate network interfaces, assuming that you even care.)

In short: Ethernet addresses are now back to being only unique on their particular network, not globally unique across your entire set of networks. Hopefully no switches will explode.

(However, you're less likely to run into problems with this than people were in the Sun era. Back then, problems ensued because there were legitimate situations where people wanted to connect two network interfaces from the same machine onto the same network and tell them apart.)


Comments on this page:

From 69.113.211.148 at 2010-07-03 09:09:26:

A MAC is only useful within a broadcast domain, and a VLAN is a separate broadcast domain. What's the issue?

From 84.105.101.172 at 2010-07-03 13:07:00:

I'm also wondering what the big issue is. Having the same MAC addresses on different vlan's is no problem.

By cks at 2010-07-03 17:02:21:

Neglecting buggy hardware or software (which sometimes happens), you're entirely right; everything should work at a technical level with MAC addresses this way. These days what it complicates is monitoring and analysis, where it is convenient to assume that you can tie a MAC address to a particular network or VLAN that it is 'supposed' to be on.

(For example, you might build a monitoring system that alerts you if it sees the same MAC address on two separate VLANs within a short period of time, as a sign that someone has cross-connected two networks together accidentally.)

From 131.58.64.193 at 2010-07-05 07:46:25:

I just checked the 4 NIC's on a T5240 and each has a unique MAC. I assume they have to be for creating aggregates, although even if they were non-unique "out of the box" I suppose they could be changed at that point if needed. The MAC's are sequential on that box FWIW. -J.F.

Written on 03 July 2010.
« A gotcha with Python's socket.htonl() and ntohl()
/u, one of our long-standing Unix customizations »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Jul 3 01:35:04 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.