[ofw] enable/disable device changes IPoIB physical address??

Fab Tillier ftillier at windows.microsoft.com
Thu Aug 2 12:17:24 PDT 2007


The MAC address on the wire is the standard IPoIB format.  ARP requests
are swizzled from 802.3 to IPoIB format when being put on the wire, and
back when being received.  Ditto for DHCP (though that code is a bit
challenged at the moment).

-Fab

-----Original Message-----
From: Sean Hefty [mailto:sean.hefty at intel.com] 
Sent: Wednesday, August 01, 2007 2:06 PM
To: Fab Tillier; Jeremy Enos; ofw at lists.openfabrics.org; David A.Norris
Subject: RE: [ofw] enable/disable device changes IPoIB physical
address??

>In Windows, IPoIB pretends to be a standard 802.3 NIC.  That means the
>MAC address it reports to the OS for both its local address and in any
>received ARP packets is a 6-byte MAC.  This 6-byte MAC is generated
from
>the 20-byte IPoIB MAC that goes over the wire and is made up of the GID
>and QPN.  Shrinking a 20-byte space down to 6 bytes is a bit of a
>challenge.  The driver discards the QPN and the subnet prefix from the
>GID, leaving just the port GUID.  This GUID is then reduced to a 6-byte
>MAC based on the vendor ID in the first 3 bytes.  There are algorithms
>in the IPoIB driver to convert Mellanox, QLogic (ex Sliverstorm), and
>Voltaire GUIDs.  For all other types, the driver generates a locally
>administered address (LAA) which starts with 02 00 (maybe an extra 00,
>too).  The lower bytes are a simple counter that gets incremented every
>time a new LAA is generated.  Note that Cisco HCAs fall into the "all
>other types" category, as there is currently no code in the IPoIB
driver
>to handle these GUIDs.

Does this work with non-Windows IPoIB implementations?  It doesn't
actually
report a 6-byte MAC address over the wire, does it?  This is just a made
up
address to fool Windows, correct?



More information about the ofw mailing list