[Fwd:] Nvidia NICs with duplicate mac addresses

David W. Hankins David_Hankins at isc.org
Fri Sep 5 18:15:04 UTC 2008


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20080905/a156f2a0/attachment.sig>


More information about the NANOG mailing list