1

I have a Server 2008 R2 x64 installation (we'll call it MARS) that will not communicate with one of my Server 2008 R2 x64 Hyper-V hosts (we'll call it VENUS) or any of its guests.

  • They're both on the same VLAN and plugged into the same switch.
  • All other nodes on the network can connect to both MARS and VENUS (+ guests) including other Server 2008 R2 x64 servers and Hyper-V hosts.
  • The firewalls for all network profiles are disabled on both servers.
  • I have rebuilt MARS and the problem persists.
  • VENUS is our only Hyper-V host running on a full installation of Server 2008 R2 Datacenter edition. The other hosts are running 2008 R2 Server Core with the Hyper-V role installed.
  • VENUS has 4 teamed HP NC382i NICs.

We plan to migrate all guests off VENUS and rebuild it on Server Core. That might resolve the problem, but I was curious if anyone had encountered anything like this before.

Rob D.
  • 233
  • 1
  • 3
  • 10

3 Answers3

2

Since both NICs are on the same switch & VLAN, start looking at Layer 2. What occurs on either ARP tables as the result of a simple "ping" from either direction? Does the corresponding MAC show up on the opposite end's ARP table? If the ARP entries are correct, then move up to Layer 3 by checking for IP level filters as the next stop/step up the OSI model (heading towards the Event Logs as needed).

user48838
  • 7,431
  • 2
  • 18
  • 14
  • MARS shows up in the VENUS arp table when I ping MARS from VENUS, but VENUS doesn't show up in the MARS arp table when I ping VENUS from MARS. – Rob D. Aug 09 '10 at 16:26
  • You might check the behavior of VENUS against other systems to ensure it is not a side-affect of the NIC teaming, as well as verifying heuristics against MARS. If "cross/control" checks show up as one would normally expect between MARS and VENUS, then start by looking for possible MAC filtering from MARS towards the switching environment. – user48838 Aug 09 '10 at 16:56
  • 1
    It turns out about half of our servers were using a /16 subnet mask, and the other half were using /24. Switched them all to /24 and everything is working. – Rob D. Sep 17 '10 at 13:38
  • So it was layer 3, but going through the other systems helped identify the configuration mis-match. Good deal... – user48838 Sep 17 '10 at 19:42
0

It turns out that even if Windows Firewall defaults block pings, the pinging machine shows up in the recieving machine's ARP table.

My fix, since the network was completely internal was to shut down the Windows firewall on the private network and then be sure the associated NICs point to that external network.

(Earlier posting on virtual networks (virtual switches) at IPv6 problem in Hyper-V)

Community
  • 1
0

I've seen this problem with teamed NICs - one dodgy switch port that the team doesn't recognize as failed but is either misconfigured or slightly broken may only affect traffic to\from specific host pairs not all hosts pairs. It can be very confusing.

e.g.:
Server X can talk happily to Server A
Server X can talk happily to Server B
But Server A and Server B can't talk to each other.

I haven't seen this with Hyper-V but I've seen it more than once with VMware ESX - although in that case the problem wasn't consistent across all VM's on the host as it is in your case.

Helvick
  • 20,019
  • 4
  • 38
  • 55