I am experiencing the following communication problem with my VM server running on server 2012 hyper-v host:
when a network package leaves the vNIC of the VM it has the source mac address of the vNIC however when the same package leaves the physical NIC
of the Host the package no longer has the source MAC address of the vNIC but that of the physical NIC. See below package trace output:
Packet trace on the VM (TFTP server with IP 192.168.1.35) note the TFTP client has IP 192.168.22
Packet trace on the host note the TFTP server has IP 192.168.1.35 and TFTP client has IP
192.168.22
If we pay attention to the highlighted section we see that the packet leaves the VNic with the source MAC 00-15-5D-01-1E-0E (mac address
of the vNIC) and when it leave the physical NIC of the host the source MAC address is 78-AC-C0-11FC-9E (MAC address of the NIC of the HOST)
Furthermore you can see that none of the 5 packages (package 3-7) sent form the client to the server where the client sent the packet to the destination
MAC 78-AC-C0-11FC-9E arrives at the VM, however the subsequent 5 packages that the client send to the server with the destination MAC 00-15-5D-01-1E-0E all arrives at the client.
It forgot to mention that the uplink of the virtual switch on the host is a network team using LACP and that uses the source and destination IP
address as its load balancing mechanism.
Please note the following:
- this behavior disappear when I either remove one of the cables from one of the teamed nics (the sources MAC is always that of the vNIC when the packet
leaves the host etc)
- the problem also disappears if I configure a static ARP in the client
- The above behavior does not apply for all communication for example I can have the cables of both teamed NICS connected and simple
change the IP of the above problematic TFTP client form 192.168.1.22 to 192.168.1.13 and the communication works OK as the source MAC address of the VM will always be the correct MAC address that belongs
to the vNIC.
Last but not least we have tried, replacing the NICS in the server, connecting the host server to a different switch and even replacing all the
cabling to the host server but none of these helped to resolve the problem.
Has anyone seen this behavior? Any idea what could be causing this?
Regards,
Screech