Share via


A port on the virtual switch has the same MAC as one of the underlying team members on Team Nic

Question

Thursday, November 14, 2013 7:37 AM

Experts !

Windows 2012 R2 Cluster.

2 Physical NICs dedicated for Hyper-V data traffic. These two NICs are used to create a team using Windows teaming (Switch Independent + HyperV Port) and this teamed interface is used for HyperV Virtual Switch.

I am getting the below warning frequently.

Log Name:      System
Source:        Microsoft-Windows-MsLbfoSysEvtProvider
Date:          11/12/2013 1:37:55 AM
Event ID:      16945
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      MSHVCLUSTER6N1
Description:
MAC conflict: A port on the virtual switch has the same MAC as one of the underlying team members on Team Nic Microsoft Network Adapter Multiplexor Driver
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-MsLbfoSysEvtProvider" Guid="{387ed463-8b1b-42c9-9ef0-803fdfd5d94e}" EventSourceName="MsLbfoProvider" />
    <EventID Qualifiers="32768">16945</EventID>
    <Version>0</Version>
    <Level>3</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2013-11-11T21:37:55.871565200Z" />
    <EventRecordID>4861</EventRecordID>
    <Correlation />
    <Execution ProcessID="4" ThreadID="6100" />
    <Channel>System</Channel>
    <Computer>MSHVCLUSTER6N1.INSIDEVIRTUALIZATION.COM</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="DriverObject">
    </Data>
    <Data Name="Member">Microsoft Network Adapter Multiplexor Driver</Data>
  </EventData>
</Event>

And while checking the Interface and MAC, the warning is true.

name                                                                   MacAddress
                                                                     
MANAGEMENT                                                     00-17-A4-77-00-6E
HEARTBEAT                                                          00-17-A4-77-00-6C
Ethernet                                                             00-17-A4-77-00-6A
LIVEMIGRATION                                                  00-17-A4-77-00-68
DATA-2                                                                00-17-A4-77-00-66
DATA-1                                                                00-17-A4-77-00-64
vEthernet (HCT-PRODUCTION-LOGICAL-SWITCH)                   00-17-A4-77-00-66
DATA-TEAM                                                          00-17-A4-77-00-64

While I did the same configuration using SCVMM for my Windows 2012 HyperV clusters, the fabric was deployed from SCVMM and hence the team and the virtual switch was just one. In the similar way, How should I do this with out SCVMM ?

Cheers ! Shaba

All replies (28)

Tuesday, December 10, 2013 11:31 AM ✅Answered | 1 vote

All,

Try this and let me know if that worked for you.

On the Virtual Switch Manager, Along with the External Network configuration, you have an option to check/uncheck "Allow Management Operating system to share  this network adapter". I unchecked it and the events releated with MAC Conflicts are no more.

Cheers ! Shaba


Wednesday, April 9, 2014 11:33 AM ✅Answered

HI,

Great to hear my blog post helped you to your solution.

Greetings, Robert Smit Follow me @clustermvp http://robertsmit.wordpress.com/ “Please click "Vote As Helpful" if it is helpful for you and Proposed As Answer” Please remember to click “Mark as Answer” on the post that helps you


Thursday, November 14, 2013 8:55 PM

I am having the same exact issue.  I keep trying to remove the virtual switch and add a new one, I end up with the same issue on both nodes of a 2 node cluster.  How did you "check the interface and mac"?  is this the result of a command?

Thanks

Rob


Thursday, November 14, 2013 10:08 PM | 1 vote

I'm having the same issue with network configured in VMM. Any ideas?

Rob, you can run this in powershell to get that output:

Get-NetAdapter | select name, macaddress


Friday, November 15, 2013 7:38 AM

Thanks Nadasurf2 for clarifying me that configuring through VMM also have the same issue.

I see that lot many others are having this same warning.

Cheers ! Shaba


Friday, November 15, 2013 7:28 PM

nadasurf2,

Thank you for the direction on getting info for the nics from powershell. I appreciate.  I hope someone will chime in soon with some direction on solving the problems. 

I have recently purchased multiple licenses for Server 2012 r2, two HP Proliant DL360p Gen8 servers and an HP P2000 SAN to setup a Hyper-V Cluster.  I have installed Server 2012 r2 and configured the Cluster.  I have 9 HA VM's up and running in production.  I am finding that the cluster is not totally dependable.  I am experiencing issues where the production Cluster Network becomes segmented.  I believe this comes down to the networking and is why I found the MAC conflict errors.  Though I am not totally sure that the issue of my undependable cluster is the MAC conflict. I am pretty sure I may need new drivers for the NIC's, but HP doesn't have an SPP out for Server2012 r2 yet.

anyway, thanks for the input.  would love to figure out the mac conflict.

Rob


Thursday, November 21, 2013 2:58 AM

Hi,

Just want to confirm the current situations.

Please feel free to let us know if you need further assistance.

Regards.

We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time.
Thanks for helping make community forums a great place.


Thursday, November 21, 2013 6:05 AM

Alex Lv, I have opened a case with Microsoft. This issue seems to be related with VMQ.

I will post an update once its fixed.

Cheers ! Shaba


Thursday, November 21, 2013 2:28 PM

Looking forward to your update!  VMQ?

Thanks

Rob


Sunday, November 24, 2013 5:19 PM

Case is still in progress. No clue as of know. One suggestion I got is to try recreating the Virtual Switch through SCVMM, which is not possible for me. I will post any updates the as I get.

Cheers ! Shaba


Friday, November 29, 2013 9:36 AM | 1 vote

I have the same Problem here on a bl460c g8 and Server 2012 R2.

I realised it because SCVMM was not able to connect (WINRM failure).


Monday, December 2, 2013 9:49 AM

I am also seeing this error on all 3 hosts in a 3 node cluster - 2012R2

No SCVMM involved in my setup.

Looking forward to the case updates!

Cheers,

Dave


Tuesday, December 10, 2013 12:41 PM | 2 votes

Unfortunately that won't work in my situation as I need the Hyper-V host to see the adapter as it uses it for host communication. We're setup in this type of configuration: http://blogs.technet.com/b/meamcs/archive/2012/05/06/converged-fabric-in-windows-server-2012-hyper-v-server-8-beta.aspx

Hopefully MS is still looking at this


Sunday, December 15, 2013 2:30 PM

Did anyone ever find an answer here?  I'm hitting the same message on two hosts I just configured.  I need the host to be able to use the virtual switch.

Is this warning message benign?

I am seeing VMQ related issues on one host (even after a reinstall) but not on another.  Sporadic guest networking issues and errors in the system log: The processor sets overlap when LBFO is configured with sum-queue mode

I had to set the processor queues manually and reboot.


Monday, December 16, 2013 6:16 PM | 1 vote

Hi JustinRush,

Please refer http://insidevirtualization.com/hyperv/the-processor-sets-overlap-when-lbfo-is-configured-with-sum-queue-mode/ . If VMQ is enabled on the NICs, you need to configure the NIC without overlapping.

Cheers ! Shaba


Tuesday, December 17, 2013 2:22 AM

I am having the same issue on a 4 node 2012R2 cluster. All 4 host nodes are getting this error. They are all using LBFO/NIC teaming. Our configuration does not allow us to uncheck "Allow Management Operating system to share this network adapter" We need that.

Just had 1 node go completely wacky network-wise. Couldn't ping in or out of the host but the guests it was hosting were still running and accessible on the network. That's what brought me here although I had noticed those errors previously and was just hoping they were benign.

No idea if the network issues were related to this error message and our network guy says he didn't see anything unusual.

hoping someone has an update or some ideas. This is happening on more than one cluster.

Dan


Thursday, December 19, 2013 8:08 PM

We have a 3 node 2012 R2 and one of the nodes is showing these errors. I have had some wacky network issues as well. The one recently related to an LBFo Team lost connection on the interface configured for LACP teaming mode after a reboot. To fix it I had change the mode then put it back to LACP, rebooting didn't resolve it. The switch is configured for LACP.


Monday, January 13, 2014 3:11 PM

Me too, just posting this to set up an alert when someone finds a solution.

I have a 2012r2 non-critical host with two network cards. The operating system and the virtual machines share the virtual switch. Might be related - I was sort of wondering how I should assign the IP address for the host - in the Team or the Virtual Switch. I have it set in the virtual switch.

Ken


Monday, January 13, 2014 5:03 PM

Configuring the processor sets made the error go away but wonky network issues remain.  I even tried disabling VMQ.  I opted to open a new thread since I think the two errors being reported here are actually benign.

http://social.technet.microsoft.com/Forums/windowsserver/en-US/3b9991de-2df0-4522-8ae9-fd97fb13325c/sporadic-tcp-packet-loss-on-guest-vms-on-one-server?forum=winserverhyperv


Tuesday, January 14, 2014 2:48 PM

I discovered one of my problems was that two of the nodes in the cluster had the same MAC address range set in virtual switch manager.

When a VM live migrates it keeps the same mac address it had from the original host. However, when it reboots on the new host it gets a mac address from the new hosts range. So occasionally VMs on the two hosts would have the same mac address.


Wednesday, February 12, 2014 6:57 PM

I ran into the same issue:

  • Single Windows Server 2012 R2 Hyper-V host with 2 NICs
  • Teamed them together using Windows teaming
  • Created a virtual switch and enabled management
  • Duplicate MAC error messages in the event log
  • Virtual Machine Manager 2012 R2 showing "host not responding" status for that host
  • Resetting the WinRM & VMM service on the Hyper-V host allowed VMM to see the host again
  • That was the first  temp fix since the error returned 
  • Due to time, we added a 3rd NIC and set that as the sole Mgmt NIC
  • The duplicate MAC address issue is gone, VMM is working, etc.

For others, adding another NIC may not be an option.


Thursday, February 27, 2014 12:33 AM

I have the same problem.  It's happening on both hosts in the cluster.


Friday, February 28, 2014 12:36 AM

It appears this all started when I reconfigured my teamed adapters to use Dynamic load balancing (the default).  I had originally selected address hash and decided I wanted to change to dynamic after learning more about dynamic.  When I did it I just went in and changed the setting without rebuilding the team.  It seemed to work, but I believe these errors started on that day.  Just now I removed the hyper-v switch and recreated the team with dynamic load balancing so it would be set at the time of creation.  I then recreated the hyper-v switch and found myself right back where I started.  Rebuilding the team and Hyper-V switch did not help.  The teams seem to share the macaddress of the physical adapter.  Once you create the hyper-v switch it also shares that same macaddress.  Really thought that would fix it too.

I then tried to change it back to address hash since that seemed to work before I started messing with it.  I was again surprised that the problem carried.  I'm back to my original configuration (using address hash) and it's still causing the error even though it didn't originally.  Makes no sense.  There has to be a logical explanation...


Friday, February 28, 2014 11:14 PM

I'm beginning to think this is expected behavior.  Today I completely reinstalled the OS on both machines and rebuilt the teams yet again.  It didn't matter whether I picked Dynamic or address hash for the load balancing type on the teams.  It was re-using the macaddress of one of the physical NICs as it built out the team.  Not sure how it determines which macaddress will get used out of the team members.  If you then attach a Hyper-V network switch to the team and then share it out with the management OS then that same macaddress will get shared out to the management OS as well.  Is this a case of it showing up as an error in the eventlog even though it's expected behavior?  I'm back to using LACP teaming mode and Dynamic load balancing on both nodes in the cluster.


Saturday, March 1, 2014 11:47 AM

Thanks Brian Klish for digging more.

This may be the expected behavior if we are using the same team for Hyper-V Data along with management. Its a while I stopped looking into this issue as I was not seeing this event after making the change on the virtual switch to not to share with Operating System.

I just looked into my new clusters which is built directly from SCVMM 2012 R2. Eventhough the Virtual Switch has "Allow Management Operating system to share  this network adapter" checked, I dont see this event anymore.

In this case, I see that the Virtual Switch is using the Mac address of one of the team member.

If we uncheck "Allow Management Operating system to share  this network adapter", the system is creating an adapter but keeping it hidden. This adapter don't have a MAC address and hence, we don't have a conflict. Not sure what the difference is while the virtual switches are created from a VMM server.

Optimism is the faith that leads to achievement. Nothing can be done without hope and confidence.

InsideVirtualization.com


Wednesday, April 9, 2014 7:52 AM | 2 votes

hi all!

i'm having same problem.

this article helped me.

I deleted all virtual interfaces. Created the team-group again. changed mac-address and created new virtual switch with management adapter.


Wednesday, April 9, 2014 12:06 PM

Thanks Robert !

Optimism is the faith that leads to achievement. Nothing can be done without hope and confidence.

InsideVirtualization.com


Thursday, August 17, 2017 4:03 AM

tried uncheck "Allow Management Operating system to share  this network adapter". I have been locked down... 

for all who locked down... visit http://fixmyitsystem.com/2013/01/PowerShell-AllowManagementOS.html for re-enable the option.