Top Doc
asked on
Hyper-V / Debian VM Network issue
Hello,
I am running Debian 9 on Server 2012 R2 Hyper-V. The scnario is that I have 2 physical servers each with a Debian virtual machine.
A) Setup Hyper-v for mirroring
1) The goal is to capture packets so Hyper-v on both is set in monitoring mode.
2) Once the "Destination" settings under the virtual machine network adapter for mirroring is set in the Hyper-v configuration.
I immediately notice that the physical network interface on the server (for the Hyper-v virtual switch) starts increasing rapidly say 70 Mb/s ON BOTH Servers...
this is good it means that the Hyper-v settings are sane (and of course the Network Configuration on the switch is perfect).
B) Setup Debian for promiscuous mode
1) Here I use:
and verify with ifconfig as shown below
###
As you can see promiscuous mode is configured correctly for both servers and linux boxes.
BUT the second box is not getting the forwarded packets from the windows network interface all that is being received are broadcasts and multicasts.
Any idea what may be the issue?
I am running Debian 9 on Server 2012 R2 Hyper-V. The scnario is that I have 2 physical servers each with a Debian virtual machine.
A) Setup Hyper-v for mirroring
1) The goal is to capture packets so Hyper-v on both is set in monitoring mode.
2) Once the "Destination" settings under the virtual machine network adapter for mirroring is set in the Hyper-v configuration.
I immediately notice that the physical network interface on the server (for the Hyper-v virtual switch) starts increasing rapidly say 70 Mb/s ON BOTH Servers...
this is good it means that the Hyper-v settings are sane (and of course the Network Configuration on the switch is perfect).
B) Setup Debian for promiscuous mode
1) Here I use:
allow-hotplug eth1
iface eth1 inet manual
up ifconfig eth1 promisc up
down ifconfig eth1 promisc downand verify with ifconfig as shown below
Debian VM1 on Server1
eth1: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500
ether 00:15:5d:15:16:17 txqueuelen 1000 (Ethernet)
RX packets 5090918 bytes 3090553169 (2.8 GiB)
RX errors 0 dropped 6 overruns 0 frame 0
TX packets 89 bytes 7638 (7.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Debian VM2 on Server2
eth1: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500
ether 00:15:5d:15:16:17 txqueuelen 1000 (Ethernet)
RX packets 42094 bytes 3877731 (3.6 MiB)
RX errors 0 dropped 66 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0###
As you can see promiscuous mode is configured correctly for both servers and linux boxes.
BUT the second box is not getting the forwarded packets from the windows network interface all that is being received are broadcasts and multicasts.
Any idea what may be the issue?
Adam Brown
Possibly the ARP table on the switch between physical servers directing incoming packets to the original host server of the VM once you fail over. Reset the arp cache on the switch and see if that fixes things for you (reboot it if it isn't a managed switch)
@Adam:
arp should not have anything to do with this.... (arp is for translation between IP address & Mac address, those interface not even have an IP address....).
The issue might be with the switch in a different way.
MAC addresses for these interfaces are the same, if those MAC addresses are ALSO the same for other interfaces then network traffic may actualy only go to one system (except for Multicast/Broadcast)....
Please verify that you have different MAC addresses on the HyperV side of things.
(Duplicate MAC address in one domain will not work...) Not for these intefaces (eth1) this is a non issue as they are receive only.
I specifically mean the OTHER interfaces for all systems. (So any MAC address should be unique on your network).
arp should not have anything to do with this.... (arp is for translation between IP address & Mac address, those interface not even have an IP address....).
The issue might be with the switch in a different way.
MAC addresses for these interfaces are the same, if those MAC addresses are ALSO the same for other interfaces then network traffic may actualy only go to one system (except for Multicast/Broadcast)....
Please verify that you have different MAC addresses on the HyperV side of things.
(Duplicate MAC address in one domain will not work...) Not for these intefaces (eth1) this is a non issue as they are receive only.
I specifically mean the OTHER interfaces for all systems. (So any MAC address should be unique on your network).
ASKER
Adam / Noci,
Thanks for responding.
Noci, i am agreeing Adam here on this point.
However, Adam I have already checked the point you have raised before I posted the question here.
This I believe is a unique situation.
Thanks for responding.
Noci, i am agreeing Adam here on this point.
However, Adam I have already checked the point you have raised before I posted the question here.
This I believe is a unique situation.
Adding to my previous comment a switch doesn't actually use ARP (except for a management interface), unmanaged switches have no ARP table.
The internal table of where what interface is seen (updated on recept of any packet) is either called CAM table or MAC table depending on manufacturer.
Those entries die in a bout a minute after a an address has been seen
The internal table of where what interface is seen (updated on recept of any packet) is either called CAM table or MAC table depending on manufacturer.
Those entries die in a bout a minute after a an address has been seen
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.