WIndows Server 2012 LBFO /LACP - DNS resolution fails or is slow


  • Has anyone had a problem setting up LBFO with LACP where DNS resolution to even local resources stops working? I am experiencing this issue.

    I have LBFO configured on my Windows Server 2012 with LACP and Address Hash. I have two NICs in the LBFO team each connected to a different switch that I am told by the Network group is configured as a single logical switch. (Since LACP is switch dependent). Starting out, DNS resolution works fine. After a day or so, sometimes within minutes, DNS resolution to even local resources either time out or is extremely slow. If I disable one of the NICS in the LBFO team, DNS resolution works fine immediately. If I re-enable the NIC where both are enabled, DNS times out or is slow to resolve. If I delete the LBFO and reconfigure, DNS works for a little while but eventually malfunctions again. If I disable the LBFO interface and re-enable, DNS resolution works again. Both NICS are on the same VLAN behind an BigIP LTM with a single VIP.

    The LTM does not act in anyway as a firewall. What is weird is that if I see the malfunction with DNS resolution, all I have to do is disable one NIC in the team and DNS works fine. Re-enabling the NIC immediately brings back the problem. It does not matter which NIC of the team I disable. I contacted our Network team to inquire about the fact that LACP is switch dependent but I was told that the switches operate as a single logical switch and thereby meets the switch dependent criteria. We currently have other servers on LACP using Hyper-V rather than Address Hash and there are no problems. But my server is not a Hyper-V server. Can anyone help?

    Monday, October 14, 2013 5:39 PM


  • Turns out that the LBFO in Server 2012 had a bug in it and the only fix after exhaustive troubleshooting with a Microsoft Network Engineer was to upgrade to 2012 R2 which fixed the problem.


    • Marked as answer by WBrianBritt Thursday, April 23, 2015 12:55 AM
    Thursday, April 23, 2015 12:54 AM

All replies