Hyper-V networking issue with Static IP

I'm stumped by this problem...

I have a D-Link DIR-330 router that I've been using for years. I was going to upgrade it to a DIR-815 so I configured the 815 to match all the settings. Regular laptops, computers etc. could connect fine.

My problem is that the Hyper-V guest computers cannot connect outside of the host server when connected to the new router. If I take one of the guest VMs and change it to be DHCP, then it connects and I can get out to the internet. But whenever the IP address is set to a static IP, the guest can no longer get to the internet. In fact, it can ping other VMs that are running on the same host, but I can't ping the router (as the gateway).

When things are in this broken state and I have a guest with a static IP assigned, I can litterally unplug the cable from the new router, plug back into the old, and then the guest VMs will be able to ping the gateway.

I've already tried removing the network from the guest VM's configuration. I've also double checked the router settings and they are configured pretty much identical; and since this server is connecting hard-wire, I know it's not a wireless issue.

I've verified that neither the IP address nor the MAC are duplicates of what are on the network.

I know it's probably more than likely something about the way hyper-v and the router are interacting for the guest connections, but I don't know what or how to fix it.  And if the answer is that it is an incompatibility with the router, then I want to know what I'm looking for in a router so that I can get one where I won't have this problem.

I need to get these guests running under static IPs, but I've run out of ways to try to fix this. Anyone with suggestions would be greatly appreciated.
LVL 8
VoloxAsked:
Who is Participating?
 
DrAtomicCommented:
I think that might be the best course of action to take indeed especially compared to the amount of time this has taken and will take you troubleshooting it further. Sure you could find the solution in 1 minute but it may take 2 months or more effort without result too.
0
 
DrAtomicCommented:
A short term solution would be to assign the static IP addresses using DHCP reservations.

Troubleshooting wise, did you fully compare your dhcp tcp/ip settings with your manual static settings? This sounds like a wrong gateway or subnet address.
0
 
MattCommented:
Can you post:

IPCONFIG /ALL

and

ROUTE PRINT

for both types of configuration? DHCP and for static IP?
0
Network Scalability - Handle Complex Environments

Monitor your entire network from a single platform. Free 30 Day Trial Now!

 
Manoj BojewarCommented:
Mostly DNS issues. use google dns (8.8.8.8) when you used public IP.
0
 
Philip ElderTechnical Architect - HA/Compute/StorageCommented:
What kind of virtual switch are the VM's vNICs attached to?
0
 
VoloxAuthor Commented:
The problem with using DHCP to assign the number is that the machines already have a bunch of internal config that is dependent on the IP number, and per good practice the static IP is outside the dynamic range.  If I expand the dynamic range, then I'd have to go gather all the other static IP and reserve them as well to avoid conflicts. In short, using DHCP to assign the number would mean hours of reconfiguration elsewhere. Just so you have a clear picture....

The VM machines have numbers like x.x.x.19 and x.x.x.25 the dynamic IP range is x.x.x.100-150.

The static IP settings and the dynamic IP settings are the same. In fact, if you note in my description, the two routers are configured identically and the static settings work fine on the old router and break on the new one.

Also, this is not a DNS problem since I'm trying to ping the GATEWAY from the VM and even that is not successful.  So consider this...

VM A = static 192.168.5.19
VM B = static 192.168.5.25
VM C = DHCP assigned 192.168.5.103

All three VMs can ping each other, but the only machine that can ping the gateway at 192.168.5.1 is VM C.  Since they are all in the same subnet and all have a 255.255.255.0 netmask, there shouldn't be anything getting in the way - the only thing between these VMs and the network cable plugged into the router is the HyperV virtual switch.  

I'd also point out that VM A is a Windows box and VM B is a Linux box, so the problem isn't unique to a guest operating system. I've also tried using both an Emulated network interface and a Synthetic network interface to configure the connection in Hyper-V and both type experienced this same issue.

Which brings me to Philip's question... not sure how to answer 'what kind' of virtual switch? It's the out of the box networking configuration in the Hyper-V product that runs on Win 2008 R2.
0
 
MattCommented:
Post

IPCONFIG /ALL

ROUTE PRINT

for

VM A = static 192.168.5.19
VM B = static 192.168.5.25
VM C = DHCP assigned 192.168.5.103

and do

tracert 8.8.8.8

from each client
0
 
VoloxAuthor Commented:
First for the Linux machine this is with it connected to the OLD router that works fine...

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:137161 errors:0 dropped:0 overruns:0 frame:0
          TX packets:137161 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:43711027 (41.6 MiB)  TX bytes:43711027 (41.6 MiB)

seth0     Link encap:Ethernet  HWaddr 00:15:5D:2D:6C:15  
          inet addr:192.168.45.25  Bcast:192.168.45.255  Mask:255.255.255.0
          inet6 addr: fe80::215:5dff:fe2d:6c15/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:215776 errors:0 dropped:0 overruns:0 frame:0
          TX packets:119918 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:209005427 (199.3 MiB)  TX bytes:11420445 (10.8 MiB)

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.45.0    *               255.255.255.0   U     0      0        0 seth0
169.254.0.0     *               255.255.0.0     U     0      0        0 seth0
default         192.168.45.1 0.0.0.0         UG    0      0        0 seth0

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets
 1  192.168.45.1  0.000 ms  0.000 ms  0.000 ms
 2  142.254.185.113  59.990 ms  59.990 ms  59.990 ms
 3  76.166.9.29  49.992 ms  49.992 ms  49.992 ms
 4  72.129.2.234  49.992 ms  49.992 ms  49.992 ms
 5  72.129.1.2  59.990 ms  59.990 ms  59.990 ms
 6  107.14.19.30  59.990 ms  59.990 ms  59.990 ms
 7  107.14.19.54  59.990 ms  19.997 ms  19.997 ms
 8  216.156.65.225  19.997 ms  19.997 ms  19.997 ms
 9  216.156.65.102  19.997 ms  19.997 ms  19.997 ms
10  209.85.240.187  29.996 ms  29.996 ms  29.996 ms
11  8.8.8.8  29.996 ms  29.996 ms  29.996 ms
0
 
VoloxAuthor Commented:
Now when I move both cables to the new router, I get this from that same VM...

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:139447 errors:0 dropped:0 overruns:0 frame:0
          TX packets:139447 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:44066411 (42.0 MiB)  TX bytes:44066411 (42.0 MiB)

seth0     Link encap:Ethernet  HWaddr 00:15:5D:2D:6C:15  
          inet addr:192.168.45.25  Bcast:192.168.45.255  Mask:255.255.255.0
          inet6 addr: fe80::215:5dff:fe2d:6c15/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:223230 errors:0 dropped:0 overruns:0 frame:0
          TX packets:124832 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:215487833 (205.5 MiB)  TX bytes:12030098 (11.4 MiB)

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.45.0    *               255.255.255.0   U     0      0        0 seth0
169.254.0.0     *               255.255.0.0     U     0      0        0 seth0
default         192.168.45.1 0.0.0.0         UG    0      0        0 seth0

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
0
 
MattCommented:
Can you clear ARP cache on Linux and on the router?
0
 
VoloxAuthor Commented:
And at the same time that I'm getting those failures to tracert from the guest VM, I'm getting this on the host machine...

Tracing route to 8.8.8.8 over a maximum of 30 hops

  1    29 ms    29 ms    12 ms  142.254.185.113
  2    13 ms    12 ms    12 ms  76.166.9.29
  3    15 ms    15 ms    15 ms  72.129.2.234
  4    19 ms    19 ms    19 ms  72.129.1.2
  5    19 ms    19 ms    19 ms  107.14.19.30
  6    20 ms    19 ms    19 ms  107.14.19.54
  7    19 ms    18 ms    18 ms  216.156.65.225
  8    19 ms    18 ms    18 ms  216.156.65.102
  9    20 ms    18 ms    18 ms  209.85.240.187
 10    17 ms    18 ms    19 ms  8.8.8.8
0
 
MattCommented:
OK, where do you have DHCP server defined?

Is there any FW up and running?
0
 
VoloxAuthor Commented:
I cleared the arp cache on the Linux VM and it didn't help.  I'm not sure how I'd clear the ARP cache on the router since it's interface doesn't have an option for that. Any suggestions on how I'd accomplish that?
0
 
VoloxAuthor Commented:
The DHCP server is on the DLINK router in both the OLD and the NEW router.

The firewall in the Linux server is disabled. The normal Windows firewall stuff is running on the host computer, but I've disabled that during my testing last night and it didn't solve the issue.
0
 
MattCommented:
Do you have also win client for testing available?

DLink, the same model and firmware?
0
 
VoloxAuthor Commented:
OLD router = D-Link DIR-330
NEW router = D-Link DIR-815

I can do the same on a Windows machine but the results and symptoms are exactly the same.

P.S. Just for kicks I tried clearing ARP on the host server as well... still no dice.
0
 
DrAtomicCommented:
Did you try reloading seth0 as well?

i.e.

1. change over ip
2. clear arp
3. reload seth0
4. ping gateway

Also jsut to be clear, what is the router situation? Are they both connected to the network? Is the 815 the onyl active one atm? Are you able to ping the machines from the router(s) itself?
0
 
VoloxAuthor Commented:
Yes I tried reloading seth0. In fact, I even tried removing the network interface from the VM in hyper-V (so that it essentially didn't have a network card). Then booted up the machine, shut it down again, added the network interface back to it, and booted up again. Still no dice.

Router situation... When I was running these tests, I would unplug the WAN side of the router and the physical network cable for the host machine from one and plug into the other. I'd then wait until the host machine could access the internet to start testing. I've also done it with a shutdown of the host machine in between swapping cables.
0
 
VoloxAuthor Commented:
I've toyed around some more this weekend and still haven't had any luck... just can't seem to get the guests to get beyond the virtual switch within Hyper-V. Such strange behavior.
0
 
Netman66Commented:
You mentioned a hyper-v host, so when you change the router the Host likely treated it as a new network and changed the profile to Public network.  

Check this and advise.
0
 
VoloxAuthor Commented:
Netman66 - You're saying you think that the host machine changed the profile of the connection? Even with the two networks using the same IPs? What would it be using to determine the networks are different?
0
 
Netman66Commented:
Does your host server share the same NIC as the virtual switch?  Not sure I would use the same networks, but I can't speculate on your configuration.

In Hyper-V Manager>Virtual Switch Manager, select the virtual switch and check the connection type.  Is it External, Internal or Private?  If External is it sharing the Host NIC or is there another one to select?

If you are using a separate NIC, is the IP on that NIC set?

My feeling is that, if you are using a separate NIC, the subnet should be different from the Host's network.
0
 
VoloxAuthor Commented:
I took a look at what happens when I switch the host server over. It was initially detecting the network type as "private" but then switches over to recognizing it as "Domain Network" the way it should once it detects the domain server. However that still didn't fix the issue... the Linux machine still can't seem to get anywhere outside the host.

My virtual switch and the host do share the same NIC since I only have one network card in this particular machine.

I tried out a trick I found where people had suggested removing the network adapters from the VM and adding a new network adapter back to the VM configuration, but that didn't seem to help either.
0
 
VoloxAuthor Commented:
Actually I just found something quite interesting... After putting the host on the new router, shutting down the guest VM, removing the network interface from the VM's configuration, rebooting the host physical machine, and then adding the network interface back to the VM's configuration, I get this...

The VM guest can now ping other machines on the network, but cannot ping the router. I can ping both other virtual machines as well as ping other physical machines on the local network and they can ping the guest VM, but I can't ping the router and can't get out to the internet from the guest VM. So what would cause the router and this guest VM to not be able to communicate?

I'm almost more puzzled now than I was to begin with.
0
 
VoloxAuthor Commented:
I did a bit more experimenting and either I am overlooking something completely obvious or this is just an absolutely baffling problem...

I've now gotten to the point where things look like this...

Internet is connected to WAN side of OLD router
OLD router is 192.168.45.1
NEW router is 192.168.45.5
OLD router and NEW router are connected on the internal side of both routers
NEW router has nothing connected to the WAN side

Hyper-V host plugged into NEW router.

From the hyper-V host and a windows VM machine on that host, I can connect to everything on the network and I can connect to the internet. I can ping both the .1 and the .5 IPs so it's clear that I can see both routers on the network at the same time.

However from the Linux VM I can ping .1 and other machines on the network and I can ping the internet, but I cannot ping the .5 IP of the NEW router. So for some reason no matter what I do, the Linux VM and the NEW router just don't seem to be able to route to one another; but I have no idea why since the other VMs are working fine now. Given this current configuration the Linux VM ought to just see the NEW router as another average endpoint on the network, it isn't using it as a gateway nor a DHCP server, so I'm not sure why that router's interaction with the Linux VM is any different than any other device on the network.

I'm now at a point where essentially I have to keep the old router as my bridge to the internet because one single VM on the network won't play nice. Unfortunately it's a critical VM so I can't just scrap it and rebuilding it isn't really an option. I'm totally banging my head against the wall here, so any suggestions would be greatly appreciated.
0
 
Netman66Commented:
Any chance you can post the new router config?

Also check MTU on new router.
0
 
VoloxAuthor Commented:
What part of the config are you interested in? With the exception of the IP address, the config between the two routers is virtually identical.
When I get a chance to check it, I'll post the MTU, but again, fairly sure they match between the two.
0
 
Netman66Commented:
Just wanted to compare text of the configs to see if there was any embedded differences that don't show in the GUI.

I'm not a fan of sharing the Host NIC for the virtual switch, but if you have no choice then we'll have to figure it out.
0
 
Netman66Commented:
There are emulators online for D-Link's models - not too bad, actually.  At least I can visually see them.

They look virtually identical.  Did you try saving a backup on the old one and restoring it to the new one?

One difference I noticed immediately was the 330 had a zero'd MAC on the manual setup page, where the 815 was blank with a button to clone MAC.  You didn't clone a MAC for this device, did you?
0
 
VoloxAuthor Commented:
So the DIR-330 has a MTU of 1435 and it has all zeros in the MAC address (because the MAC address and MTU is on the internet page, I'd kind of assume that's the MAC address on the WAN side).

The 815 also has an MTU at 1435 and I did NOT clone the MAC address so that box is still empty.

Neither of the routers has a problem connecting to the internet, it's just that one VM that for some reason can't ping the new 815 (irregardless of what IP address I give the 815).

The configuration on the new 815 was setup from scratch (not a backup off the 330); I've had bad luck with restoring from backups on mismatched models or versions so I always just setup by hand and match all the settings.
0
 
Netman66Commented:
I would back up the 815 and the 330, then restore the 330 config to the 815 to see if there is some hidden setting you can't see in the GUI.

Worst scenario is that you have to restore the 815 again with it's own backup.

The options I see in each of those model looks virtually identical.

Worth a shot.

Other than that, you would need to change the gateway on the server NIC to the new IP address and make sure all the VMs also get the new gateway - either with DHCP or static.
0
 
VoloxAuthor Commented:
I guess that's the part that's so puzzling to me. With the gateway set to the old router (the x.x.x.1 IP) and the new router having a x.x.x.5 IP, all the machines on the network can ping x.x.x.5 EXCEPT that one VM. Since the traffic going to x.x.x.5 shouldn't even need to go through a gateway, it just doesn't make any sense why the packets wouldn't be getting there and back.

I might try the backup and restore thing, but since that's going to be pretty disruptive to the environment, I'm going to have to wait until I've got some downtime to do that.
0
 
Netman66Commented:
Have you tried a traceroute from the linux box to both .1 and .5?

I'm not a linux expert, but I thought there was a conf file that needed to be addressed when the gateway changes?
0
 
VoloxAuthor Commented:
Tracert to the new router goes nowhere.

I guess that's what's puzzling me, from what I know of networking, if you're pinging an IP that is on the local network, the gateway shouldn't even come into play, right? So even with my gateway set to .1, I ought to still be able to ping .5, right?
0
 
DrAtomicCommented:
As long as .5 is in the same subnet as the server then yes you should be able to ping ip addresses within the subnet; the gateway only comes into play to find routes to addresses outside of the subnet.
0
 
VoloxAuthor Commented:
Yes. They are both in the same subnet. That's why this problem with not being able to ping doesn't make any sense to me.
0
 
DrAtomicCommented:
Another thought; did you check the routing table on the linux machine to see if the route is indeed within the subnet?
0
 
d0ughb0yPresident / CEOCommented:
I'm having a similar problem. So please keep this current? I'd love to hear what you've done to resolve the problem.
0
 
VoloxAuthor Commented:
@ d0ughb0y - Good to know I'm not the only one.

@ DrAtomic - Here is what the route table looks like in the linux machine. So that doesn't seem to explain why it cannot ping the new router at 192.168.45.5  I'm getting 100% packet loss from the linux guest when I ping that IP but I get 100% success from the underlying host machine. Just doesn't make any sense.

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.45.0    0.0.0.0         255.255.255.0   U     0      0        0 seth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 seth0
0.0.0.0         192.168.45.1    0.0.0.0         UG    0      0        0 seth0
0
 
d0ughb0yPresident / CEOCommented:
I actually solved the problem, and believe it or not, it wasn't a Hyper-V issue. It was a NAT issue. I can explain the details, if you'd like, but the main point I want to make is that it sounds like you need more visibility of what's actually happening. Is the DLink router actually receiving the packets at all? If so, what is it doing with them? Is it forwarding them out, or is it blocking them? Things like that. You're assuming it's the VM manager or the routing table on the machine itself, but it might be something else on the network. I'd check that too.
0
 
VoloxAuthor Commented:
@d0ughb0y - I'd love to hear the details since I'm at a standstill with this. Thanks.
0
 
d0ughb0yPresident / CEOCommented:
No problem. The router involved here is a SonicWALL 215, though, which has Packet Capture that I'm not sure the DLink has. But here's what happened:

Originally, the primary Internet connection was a DSL connection. This was inadequate, so we put in a 10Mbps Ethernet over Copper line, and configured it as the Primary, but we left the DSL line as a backup. So let's say the public IP address of the DSL line was x.x.x.x, and that of the EoC line was y.y.y.y.

On the SonicWALL, I ran a constant ping from the machine that didn't work, to an external address (8.8.8.8 - Google). Then I did a packet capture against the LAN interface, to see what showed up. The LAN interface showed that it was receiving the pings, and forwarding them on. It did not show replies.

Next, I monitored the EoC interface - remember, this is now the primary Internet connection - and saw the ping requests going out, but nothing coming back. But I also noticed something weird: The Source address of those outbound pings was x.x.x.x - the DSL line's public IP address.

Finally, I monitored the DSL interface, and discovered that it was seeing ping replies, and it was dropping them because it had never actually seen requests for them.

So my pings were going out, from the y.y.y.y interface, but with a source address of x.x.x.x. And they were being returned to x.x.x.x (which makes sense) which had no idea why it was getting them, and dropping them as a result. This had to be NAT.

I checked the NAT rules, and sure enough, there was a rule (that had been put in place a long time ago, for testing) that was setting anything from the specific internal address (a 10.*.*.* address), and changing the source to the DSL's public address (x.x.x.x), But only for that particular static address, which was why nothing else had the problem, and why, if I temporarily changed the address, or let it go to DHCP, it worked fine. Once I removed this NAT rule, it all worked properly.

Now I don't know if your problem will turn out to be NAT-related, but I would never have figured out what was going on, had I not been able to monitor what packets were coming to the SonicWALL, and where they were going from there. That's what you need to do. Where are the packets going? Are they even reaching the router? Where are they going from there?

Does that help?
0
 
VoloxAuthor Commented:
Sorry d0ughb0y but I'm certain that isn't my issue. My problem is that my VM machine cannot seem to ping the INSIDE address of the router; which would have nothing to do with NAT because both the VM and the inside of the router are on the same subnet.

Unfortunately the router doesn't have packet capture capabilities, so I can't diagnose whether the packets are truly getting to the router and it's just failing to respond or what else might be going on. And there is no managed switch or anything like that... it's just the VM on the host machine with the host machine plugged straight into the router.

To my knowledge the hyper-V virtual switch doesn't have any options that allow it to operate as a managed switch, so I have no idea why I'm having this issue. This is the first time I've every encountered where packets aren't making it to another IP on the same subnet; so I'm stumped.
0
 
d0ughb0yPresident / CEOCommented:
Like I said, it may not be NAT-related, but you're flying half-blind. I'd suggest you do something to get you some visibility. Even if it's a hub (not a switch) and a box running tcpdump/windump/ethereal.
0
 
VoloxAuthor Commented:
I've looked at wireshark and am still not getting any leads on what the issue is here. If I was running on enterprise grade equipment, I might be able to trace this down, but then again, I probably wouldn't be having this problem in the first place.

I think I might have to give up on trying to fix this and just build a new VM. It's a bunch of work, but I can't keep limping along an old router because of one single VM that can't figure out a new IP address.
0
 
VoloxAuthor Commented:
Never managed to solve this but I wanted to give credit to those that helped by providing ideas and troubleshooting steps.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.