I don't know that I've ever attempted the configuration you're describing. However, whenever dealing with Multi-homed Windows Servers (which would be similar since multiple gateways are configured), you would have a default route through one of the gateways. To direct traffic through the alternate gateway consistently, you may need to add a static route. I'm just not sure that Windows has the intelligence to leverage the correct route in that configuration.
If it were me, I'd just have SRM change the gateway during failover. On Mon, Jun 27, 2016 at 5:46 AM, Michael Leone <[email protected]> wrote: > On Fri, Jun 24, 2016 at 7:33 PM, Sean Martin <[email protected]> > wrote: > >> I'm referring to changing the actual IP settings of the VM. SRM includes >> the ability to do this as long as vmware tools are installed. >> > > I suppose that's possible, to change the gateway settings at that time, > > However, the more important question I have is why did some of the VMs use > the first gateway in the list, and some (apparently) did not, even though > the first gateway in the list was always available. > > And secondly, why did the VMs not try the other specified gateway, when > the first was non-responsive? > > > >> >> >> - Sean >> >> On Jun 24, 2016, at 10:53 AM, Michael Leone <[email protected]> wrote: >> >> SRM does modify the VM network settings to match the networks defined at >> the recovery site (to choose the networks defined at the recovery site), >> but those are a network definition, not a gateway definition. But my >> recovery site is based at one of my branches, which is online all the time. >> It obviously can't have the same IP address as the switch at my main >> production site. Hence the the recovery site has to have a different IP >> address than the switch at the main production site. If my recovery site >> was dedicated exclusively to D/R, then it might be different. >> >> And so that's why I have 2 gateway entries in my VMs. >> >> On Fri, Jun 24, 2016 at 2:35 PM, Sean Martin <[email protected]> >> wrote: >> >>> Why aren't you using SRM to modify the network settings during failover? >>> >>> - Sean >>> >>> On Jun 24, 2016, at 8:30 AM, Michael Leone <[email protected]> wrote: >>> >>> On Fri, Jun 24, 2016 at 12:04 PM, Rubens Almeida < >>> [email protected]> wrote: >>> >>>> Here's my 2 cents on this matter: I'm still waiting to see when a >>>> Windows server host will handle 2 gateways without trouble. I'm used to see >>>> on every customer I'm assigned to work as SME on my day job. Every one of >>>> them have this kind of issue on one degree or another. What I do is: on the >>>> production NIC I set the customer's gateway. On all other NICs no gateway >>>> at all. If needed, I then set a persistent routes pointing to the >>>> respective gateway handling that specific network. Hope that helps! >>>> >>> >>> As I said, there are no other NICs. Also, in case of disaster, I don't >>> want to have to edit 175 VMs, to set addressing on a previously unused NIC >>> (script-based or not). I need an automatic dead-gateway detection and >>> failover, apparently. >>> >>> >>> >>>> Rubens >>>> >>>> On Fri, Jun 24, 2016 at 12:23 PM, Michael Leone <[email protected]> >>>> wrote: >>>> >>>>> Here's my setup: I have a lot of VMware VMs. We also use their SRM >>>>> (Site Recovery Manager) for Disaster Recovery. Basically, SRM lets the VMs >>>>> fail over to another site, in case of disaster. They will keep their >>>>> current IP addressing. >>>>> >>>>> So what we did was set 2 gateways on each VM - first entry is x.x.x.1, >>>>> which is the gateway at the production site. Second entry is x.x.x.2, >>>>> which >>>>> is the gateway at the recovery site. This way, if the VMs did fail over, >>>>> they would still be able to find a gateway and continue to work (since >>>>> theoretically x.x.x.1 would not be available, being a smoldering pile of >>>>> ash or whatever). Note that these are all 1 NIC machines, no multi-homing. >>>>> And all static addressing, no DHCP. >>>>> >>>>> I seem to recall testing this a couple years ago, and it worked fine. >>>>> However, I'm old, so who knows how faulty my memory is ... >>>>> >>>>> Here's the problem - yesterday the recovery site went down. Mind you, >>>>> the main production site stayed up, and in fact, has never gone down. But >>>>> then I started getting weird calls - I couldn't ping some VMs, yet other >>>>> on >>>>> the same subnet as I am had no difficulties. >>>>> >>>>> Eventually, what I had to do was delete the x.x.x.2 gateway entry from >>>>> the problematical machines, flush their DNS cache, and then everyone could >>>>> access these VMs again. >>>>> >>>>> But why?. Since the main production site switch never went down, none >>>>> of the VMs should have been using the recovery site as a gateway; they >>>>> should all have been using x.x.x.1, and the fact that x.x.x.2 was >>>>> unavailable should not have matter to them in the slightest. >>>>> >>>>> And even if they were using the recovery site x.x.x.2 as gateway, >>>>> once it dropped, the VM should have still been able to use the other >>>>> entry, >>>>> the production site switch x.x.x.1, as a gateway and continued to be >>>>> available. >>>>> >>>>> So, 3 questions then: >>>>> >>>>> 1. Am I wrong in believing that a Windows machine (Win 2008 R2 and Win >>>>> 2012 R2) will use the gateways in the order listed? (i.e., use x.x.x.1 >>>>> first, and not try to use x.x.x.2 unless x.x.x.1 is unavailable). Seems >>>>> most of my VMs worked this way, but not all, yet all are configured the >>>>> same way. >>>>> >>>>> 2. And, if the gateway in use (for example, x.x.x.2) becomes >>>>> unavailable, I thought Windows would automatically try the other entry, >>>>> without any user intervention. Is this not so? >>>>> >>>>> 3. What I want is that for the VMs to use the first gateway listed. If >>>>> it can't reach or use that, then I want it to automatically use the next >>>>> entry in the gateway list. Is this possible? If so, then how? >>>>> >>>>> Thanks for any help. >>>>> >>>>> >>>> >>> >> >
