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

From: David W. Hankins (no email)
Date: Fri Sep 05 2008 - 14:15:04 EDT

  • Next message: Paul Wall: "Re: Force10 Gear - Opinions"

    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 message: Paul Wall: "Re: Force10 Gear - Opinions"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD