Physical Address.. . . .. . . .: 02–77–1B-62–73-A9
DHCP Enabled.. . . .. . . . . .: No
Autoconfiguration Enabled .. . .: Yes
Link-local IPv6 Address .. . . .: fe80::80fc:e6ea:e9a4:a940%21(Preferred)
IPv4 Address.. . . .. . . . . .: 169.254.2.5(Preferred)
Subnet Mask .. . . .. . . . . .: 255.255.0.0
Default Gateway .. . . .. . . .:
DHCPv6 IAID .. . . .. . . . . .: 688049663
DHCPv6 Client DUID.. . . .. . .: 00–01–00–01–19-B8–19-EC-00–26-B9–43-DA-12
NetBIOS over Tcpip.. . . .. . .: EnabledRemember, this is not a physical network adapter but rather a virtual device that is
using whatever network has the lowest cluster metric; the adapter can move between
physical networks as required. The MAC address of the NetFT adapter is generated by
a hash function based on the MAC address of the local network interface. A nice
change in Windows Server 2012 was that it is now supported to sysprep a cluster
member because during the specialized phase, a new NetFT MAC address will be
generated based on the new environment’s local network adapters. Previously, the
NetFT MAC was set at cluster membership and could not be changed or regenerated.
The user of the NetFT adapter is the cluster service. It communicates using TCP 3343
to the NetFT, which then tunnels over the physical network adapters with the fault-
tolerant routes using UDP 3343. Figure 7.20 shows this. Notice that there are two
physical network adapter paths because two network adapters in this example are
enabled for cluster communications and the NetFT has built the fault-tolerant path.
Figure 7.20 Cluster network properties