At a customer I ran into the following situation. Separate NIC’s are used on the PVS clients for provisioning traffic. And the provisioned clients are in a different subnet as the Provisioning Servers and the DHCP servers. Of course in DHCP the router address is configured so that clients are able to connect to the other subnet.

In between the two subnets the customer has two routers functioning as a HA pair. The default gateway address given to clients is a virtual IP configured on the HA pair. 

This looks something like this: 

Router1 physical IP: 192.168.1.251
Router2 physical IP: 192.168.1.252
Default gateway virtual IP: 192.168.1.253

 

 

There’s a helper configured on the routers so the provisioned clients can get IP configuration from DHCP in the other subnet.

 

                               

 

So what went wrong? 

Let’s take a look at the bootprocess. The PXE client on the provisioned machine sends a broadcast over the network looking for a DHCP server. One of the routers in the HA pair (lets say 192.168.1.251) picks up the request and passes this on to the DHCP server (according to the helper). The DHCP server accepts the request and sends an ip address back to the provisioned machine, including the default gateway VIP as router address.  What happens next is something that I didn’t expect. Instead of using the default gateway VIP that was configured in DHCP, the PXE client uses the IP address of the router that answered to the DHCP request as the default gateway (192.168.1.251). And it hands this IP information over to the TFTP bootstrap program.

Next Windows boots without a problem. Within Windows a new DHCP request is being done resulting in the correct address (192.168.1.253) being configured as default gateway in Windows. 

This all looks ok.. right?

BUT…. a very interesting fact here is that the communication between the  provisioned client and the vDisk residing on the PVS server is NOT handled by Windows. Even when Windows is started the bootstrap program is still handling the communication from and to the vDisk. So because this bootstrap program uses the Router1 address as the route to the other subnet, there’s now no redundant situation for the routers. When Router1 fails the provisioned client just freezes, because it’s are unable to contact the vDisk that resides in the other subnet!

We went even further in testing this by configuring no default gateway at all in DHCP. In this scenario Windows is able to boot because PXE just uses the router that first answers the DHCP request. But within Windows there is now no gateway to the Provisioning Server. Doing a ping to the Provisioning Server results in the message “Destination host unreachable”. So Windows is not even communicating with the vDisk when booted. 

Ok.. back to the problem.

 

 

The problem is that the PXE client uses the physical IP of Router1 as the gateway and passes this through to the bootstrap program. From this moment on the bootstrap program communicates over this IP, even when in Windows. So when Router1 fails, contact with the vDisk is lost.

 

Luckily this problem can be easily fixed by configuring a specific default gateway in the bootstrap program. You can do this by clicking Configure Bootstrap in the Provisioning Services console, and specifying the subnet and gateway address.

 

      

Now the bootstrap program uses this gateway as the route to communicate with the vDisk, in stead of using the gateway it get’s passed through from the PXE client. Resulting in fully working HA situation!

 
Comments (0)