Ethernet Products
Determine ramifications of Intel® Ethernet products and technologies
4810 Discussions

intel 82576 gigabit dual port team and vlb mode on hyper-v cluster - warning event 28 - vmsmp

idata
Employee
2,453 Views

Hi

I've have win 2008 r2 sp1 failover cluster with teamed two eth ports on Fujitsu BX 922 S2 which are connected to Connection Blade switch.

Eth. interfaces are intel 82576 gigabit dual port (i've used nic1 and nic4)

Drivers are from package 16.8.

Type of Team is VMLB.

Teamed (virtual) interface is added then into Hyper V Virtual Network as external network without sharing with OS and then vlan's are assigned when virt.net is added into VM. (switch ports are configured in trunk mode to bypass some vlan's which are neeeded into VM's and we're using dynamic mac addressess)

After power up VM event log is start to fill in with warning event 28 - vmsmp with message like this one:

Port 'SWITCHPORT-SM-A6285CC8-5521-4180-BEE9-59C9929D26CB-1-1' was prevented from using MAC address '00-15-5D-64-3A-16' because it is pinned to port '27263E05-4CB3-4751-9'

If i change team mode into SFT events are stopped.

Does anyone know about that issue and is there any workaround so that I can use VMLB team type.

Best regards

Nenad

0 Kudos
3 Replies
Mark_H_Intel
Employee
792 Views

Hi Nenad,

 

This question is something beyond my expertise, but I did some reading in other forums and blogs where others have encountered a similar issue. This may be an oversimplification, but I the causes for this error seem to lie in two general areas:
  1. There is a duplicate MAC address or a loop that makes the virtual switch think there is a duplicate MAC address.
  2. MAC address spoofing used by load balancing algorithms is causing the message.

You might check out this blog to see if David's suggestion helps. This looks like a possible solution if your messages are caused by an issue from the number 1 area:

 

http://davidlambros.com/hyper-v-vm-was-prevented-from-using-mac-address-because-it-is-pinned-to-port/273/ http://davidlambros.com/hyper-v-vm-was-prevented-from-using-mac-address-because-it-is-pinned-to-port/273/.

 

Since changing the team type makes the messages disappear, you might be encountering an issue with MAC address spoofing. You might want to try enabling MAC address spoofing in the settings of the NIC of the VM that connects through the teamed interface.

I hope this helps. Let me know about any solution you find.

Mark H

Message edit by Mark H @ Intel:

You should also consider using the latest software and driver package. Both the base drivers and the ANS drivers have gone through changes since the version 16.8 software package was released last year.

http://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=18725 http://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=18725 has the latest software and drivers.

idata
Employee
792 Views

Hi Mark and thank you for you comments.

Can we first clear how teamed nic's should be connected to switch:

two teamed nic's connected to same switch

or connected

with two different switches ?

As I can see from mgmt web interface it seems that blade connection switches are stacked. Can you tell me how ports on switches should be configured for VMLB so I can pass to our network team ? However first requirement is fault tolerance. If VMLB not provide FT on adapter and switches level I will fallback to SFT (I read in some posts that VMLB is switch port FT).

Actually I want to have "directed" traffic to particular VM so it is not yet clear to me, should I use VMLB, VMDq or both. More precisely I want to be sure that if someone flood network with whole bunch of udp packets which are directed to one particular VM affect only that VM and not other VM's or failover cluster / hypervisor hosts.

Today I've downloaded latest package 17.2 and I can see that driver e1q62x64.sys is updated (for 82576) so I will try of course them.

I've created one test VM from syspreped template using SC VMM 2012 so that STATIC MAC address is used from SC VMM pool (and not hypervisors pool) but I've also get warning event 28 - vmsmp. I did not play with enabling "spoofing".

Best regards

Nenad

0 Kudos
Mark_H_Intel
Employee
792 Views

Hi Nenad,

Here are your answers:

Can we first clear how teamed nic's should be connected to switch: two teamed nic's connected to same switch or connected with two different switches? The teamed NIC ports should be connected to switch ports on the same subnet. The two ports need to be able to communicate externally without going through a router.

However first requirement is fault tolerance. If VMLB not provide FT on adapter and switches level I will fallback to SFT (I read in some posts that VMLB is switch port FT). Yes, the VMLB team also provides fault tolerance. If you loose link on one port, the other port will carry all the traffic.

Can you tell me how ports on switches should be configured for VMLB so I can pass to our network team? No special configuration on the switches is required except that both ports must be in the same subnet.

 

Actually I want to have "directed" traffic to particular VM so it is not yet clear to me, should I use VMLB, VMDq or both. More precisely I want to be sure that if someone flood network with whole bunch of udp packets which are directed to one particular VM affect only that VM and not other VM's or failover cluster / hypervisor hosts. Traffic destined for either VM might be present on the physical adapter port because the traffic is being load balanced. The Hyper-V switch takes care of getting the packet to the right VM. Enabling virtual machine queues on the NIC team will offload processing from the Hyper-V virtual switch so that the packet can be sent directly to the VM's virtual NIC.

 

I did not play with enabling "spoofing". You might have to allow port spoofing to have full connectivity with a load-balanced team.

 

Mark H

 

0 Kudos
Reply