In case anyone runs into such a scenario in the future, here's what this turned out to be. In /etc/sysconfig/network the GATEWAY from the source VM was still present. Removing that allowed DHCP to set the default route properly.
-tim On Wed, Jul 15, 2015 at 4:26 PM, Tim Mackey <[email protected]> wrote: > > > On Wed, Jul 15, 2015 at 4:14 PM, Erik Weber <[email protected]> wrote: > >> On Wed, Jul 15, 2015 at 9:54 PM, Tim Mackey <[email protected]> wrote: >> >> > I feel this is something I should just know, but it's escaping me. For >> > some reason the virtual router for a guest network I've defined isn't >> > setting the default gateway via DHCP. This is CloudStack 4.4 with >> > XenServer 6.2 and it's an isolated network. >> > >> > This is what ip route shows after restart: >> > [root@piwigo122 ~]# ip route >> > 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.131 >> > 169.254.0.0/16 dev eth0 scope link metric 1002 >> > >> > If I add the default route in via "ip route add default via 192.168.1.1" >> > everything now works as expected. >> > >> > The network was created using the >> > "DefaultIsolatedNetworkOfferingWithSourceNatService". >> > >> > I do have egress rules in place, so it's only the lack of default route >> > which is causing me a problem. >> > >> >> >> You wouldn't happen to have changed nics on the vm after deployment? Ie. >> deployed with "network1", realized it was wrong, added "network2", sat >> "network2" detfault, removed "network1"? >> > Nothing like that happened. It's a newly created instance with a single > NIC. > >> >> In those scenarios I have seen that the rules on the VR for not sending >> default gw on the additional nic is not cleared after it has been set as >> default. >> >> In that case, clear it manually (/etc/dhcphosts.txt, /etc/dhcpopts.txt or >> something like that on the VR), or recreate the VR. >> > I do see an entry in dhcphosts.txt, but don't know what it should look > like to know if it's broken. > >> >> If that is not the case I don't know what's wrong, you could possibly >> tcpdump the dhcp traffic on the vm to see if it receive the information. >> That way atleast you can narrow down to troubleshooting either the VM or >> the VR. >> > Since this is a template from a running system, I'll start with the VM > tomorrow. Could very easily be cruft in there. > > Thanks > >> >> -- >> Erik >> > >
