Import configuration (NLB settings failed during activation)
-
Tuesday, October 30, 2012 12:08 PM
I am currently working on a UAG DirectAccess implementation for a customer. I am now doing several Disaster Recovery tests. Everything goes fine until I import and activate a previous saved configuration. It is an NLB problem that is hard to troubleshoot. Allow me to explain the scenario:
This setup contains four UAG DirectAccess Servers. Two datacenters, two UAG DirectAccess Servers at each datacenter (in a stretched VLAN). Importing a previously saved configuration completes successfully. You then need to activate the imported configuration. Activation completes with the following error message. "NLB settings failed during activation. Try to activate the configuration again."
At that stage UAG is still trying to synchronize, activate the configuration and such. Then, random issues occur (seen with several tests). Some UAG DirectAccess Servers can reach one and other, but they mostly lose connectivity with their internal gateway. Which results in connectivity loss to their internal gateway, which they are unable to contact the DNS Servers / Domain Controllers as well. When I re-activate the configuration as described again random issues occur. I need to wait, wait, wait a bit longer and sometimes even need to reboot two or more UAG DirectAccess Servers, until things start to get working again. All problems are related to NLB!
I am familiar with NLB. But I wonder if others have tested an import and encounter this as well. Another thing I notice. When you import a previous configuration it removes NLB and completes successfully. This means downtime. Because of that you should expect that re-activating would initiate a clean NLB configuration without issues. But that does not seem to be the case.
This scenario is a production environment. I have also tested it in a test environment with two nodes, same result.
Any suggestions?
Boudewijn Plomp, BPMi Infrastructure & Security
- Edited by Boudewijn Plomp Tuesday, October 30, 2012 1:29 PM
All Replies
-
Wednesday, December 12, 2012 4:10 PM
Apparently this does not work flawlessly. I have tested it in "three" environment, same result.
If you restore from a previous configuration; NLB is completely removed and rebuilded. This means downtime. With other words, only use it in a disaster recovery, not for going back after a minor change. I consider this post as answered.
Boudewijn Plomp, BPMi Infrastructure & Security
- Marked As Answer by Boudewijn Plomp Wednesday, December 12, 2012 4:10 PM
-
Thursday, December 13, 2012 10:36 PMI have had similar sync issues, it came down to not being on a layer 2 switch. Have you considered that as the issue?
-
Thursday, December 13, 2012 10:49 PMAre you using a layer 3 switch? I have seen this issue before when load balancing UAG's on a layer 2 switch.
-
Friday, December 14, 2012 2:33 AM
I experienced some similar problems once, and it came down to an internal firewall (a firewall that was filtering traffic between the UAGs and the internal network as well as filtering between the different UAG servers) - the firewall was not allowing packets for the virtual MACs that are created when you create an NLB array. Opening up that internal firewall resolved the issue for my install.
That being said, Microsoft does not support using stretched VLAN like you are doing, so ultimately you may want to go another route anyway.
-
Friday, December 14, 2012 8:30 AM
Are you using a layer 3 switch? I have seen this issue before when load balancing UAG's on a layer 2 switch.
Layer 3.Boudewijn Plomp, BPMi Infrastructure & Security
.png)
