Date: Fri, 5 Sep 2008 10:36:24 -0400 From: "Jay R. Ashworth" <jra@baylink.com>

On Fri, Sep 05, 2008 at 10:32:46AM -0400, Robert E. Seastrom wrote:

...

mac address 04:4b:80:80:80:03, was showing up in multiple places across the network. I googled the mac address and discovered that other people are having the same issue with this mac address. Below are some links describing the problem:

http://forums.nvidia.com/index.php?showtopic=22148 http://www.nvnews.net/vbulletin/archive/index.php/t-73469.html

I just wanted everyone to know about this problem in case you run across similar slow "connectivity" issues. I believe the network card is made by NVIDIA.

FWIW, IEEE's OUI lookup page says that's not assigned to *anyone*.

http://standards.ieee.org/regauth/oui/index.shtml

No, the IEEE page does not say anything. For many years IEEE considered OUIs to be confidential by default. IEEE would list the OUI only if a box was checked on the application for the OUI. At some point the default was changes to make the OUIs public, but existing "private" entries remain private. That said, it turns out the nVidia's OUI is 00:04:4B. So it looks like the addressing was completely hosed and the MAC was shifted over 1 byte. What mess! This used to happen in the early days of Ethernet, but I have not seen it in some time. -- 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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert D. Scott wrote:

Does this MAC present itself all the time, or just during boot?

Marvel makes a NIC prevalent in some Dell systems, that presents MAC 0c00.0000.0000 during its startup process. If you run port security, and several people boot their computer within the cam table expiration period, port security will disable the port. You can work around it but it is time consuming in large networks where port security are enabled.

I know that this doesn't apply here, but a year or so ago I had a client that had issues with port security continually dropping an end user's PC. The problem was the MAC address kept changing from Realtek to Cisco. Sometimes the same NIC would present both MACs at the same time. It turned out the box was apparently infected with something. Never could find anything specific (even when booting the Windows box from Knoppix and scanning for unusual files) except for some large ADS files that where apparently encrypted. A clean wipe and complete rebuild of the box fixed the problem. Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjBZLQACgkQUVxQRc85QlMUpwCfQXrML+jZ8Lkwh3z2QuvldWh6 6+YAn3eqq2GBv7qof+urEGtibAKQf/6m =un9B -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.

On Fri, Sep 05, 2008 at 01:19:44PM -0400, Robert E. Seastrom wrote:

The same DHCP server (ip helper-address blah) serves my office, my home, and the colo. Can you give me an idea of a good heuristic for telling the difference between moving my laptop around and finding MAC address collisions?

The theoretically conforming client supplies two pieces of information; Its DHCPv4 client-identifier-option (per RFC 4361), which will be different even on systems with identical MAC addresses (unless you are very lucky). The 'chaddr' BOOTP header contents ("its current MAC address"), which is a return-address for unicast replies (before the client has an IP address, ARP doesn't work). The DHCPv4 client-identifier tells us it's a specific interface on your laptop, no matter where it boots. Context from the packet (giaddr (relay-agent address on that network), the interface it was received upon) is used in normal DHCPv* operation (since its dawn) to find a broadcast domain. From there, we find subnets on that domain, and dynamic addresses within that subnet that are appropriate. This is how we locate configuration when your laptop connects to different wires in normal operation. The new trick is to detect two clients with the same MAC address, but with different client identifiers, that are active on the same broadcast domain. It's just a simple database lookup to detect a collision. The solution is to:

Or are you suggesting that you hand out a MAC address along with an IP address when the client DHCPs and the client then changes it?

Precisely. Negotiate a new address in a broadcast reply. I suppose you could just as easily always allocate a MAC dynamically, but this seems invasive. An alternative solution is to deny the client from receiving a config, signalling an error to the operator, so the first client remains operational. But this can have false positives. It'd take years to deploy tho. Many clients today send no identifier and just use their chaddr contents. Their MAC is their ID, so there is no way to detect collisions. Most others send a client-id that is identical to their chaddr contents, which is approximately useless. You'd also be suffering MAC changes on systems that boot multiple operating systems without releasing their previous lease (because the clients send inconsistent identifiers, and even with DUID-based id's, I think this is not going to change). This is in addition to today, where such clients consume multiple IPv4 addresses. Insult to injury. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins