North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: [Fwd:] Nvidia NICs with duplicate mac addresses

  • From: David W. Hankins
  • Date: Fri Sep 05 14:16:20 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

Attachment: pgp00013.pgp
Description: PGP signature