What are DFSR’s hardware requirements

I would guess an Atom CPU will handle 100mbit of OpenVPN traffic. Under load you might find an Atom will introduce a little more latency than a faster CPU but this will probably not be significant when considered against the latency of any long distant links you have between the server and the clients.

Some unscientific test results, running data between my netbook with an Atom CPU to a local OpenVPN server (over a 1000mbit network, but the netbook only has a 100Mbit NIC):

dspillett@minirant:~$ time dd if=/dev/zero bs=1024 count=1048576 | nc -q 0 192.168.43.1 3333
1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 91.2072 s, 11.8 MB/s
real        1m31.227s
user        0m1.792s
sys         0m25.874s
dspillett@minirant:~$ 

dspillett@minirant:~$ time dd if=/dev/zero bs=1024 count=1048576 | nc -q 0 192.168.44.1 3333
1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 113.082 s, 9.5 MB/s
real        1m53.107s
user        0m1.468s
sys         0m15.337s
dspillett@minirant:~$

where 192.168.43.1 is the server as seen just over the local network and 192.168.44.1 is the same machine as seen via an OpenVPN link over that network. The VPN is in bridged mode, using a UDP based connection.

htop showed the CPU being taxed more during the VPN test than the user+sys counts from time indicate because time is only counting dd's CPU activity not the VPN's. It showed cpu0 at ~70% and cpu1 at ~30% all through the test which would suggest the CPU is close to the limit it can transfer via OpenVPN in that test (that Atom was single core but with hyperthreading) - though it still managed to shuffle along at 9.5Mbyte/sec.

As an indication of the latency added by the VPN (which will be a combination of overheads from CPU work encrypting data and overhead from the tunnelling method), pinging with small (default, 56 byte payload) packets:

--- 192.168.43.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8997ms
rtt min/avg/max/mdev = 0.138/0.166/0.183/0.015 ms
--- 192.168.44.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8998ms
rtt min/avg/max/mdev = 0.544/0.614/0.860/0.091 ms

and larger (2048 byte payload) ones:

--- 192.168.43.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet los
rtt min/avg/max/mdev = 0.514/0.521/0.531/0.021 ms
--- 192.168.44.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 0.710/0.997/1.437/0.173 ms

Obviously you'll get different results with the VPN handling multiple connections exhibiting real-world traffic patterns, so you might want to perform some more detailed tests yourself. You might be able to squeeze more out with some tweaking - my OpenVPN set is pretty much running on out-of-the box defaults.

Well, we finally appear to have resolved this issue in our environment. For the benefits of others, here's what we discovered and how we fixed the problem:

To try and gain further insight into what was occurring before/during/after the delays we used Wireshark on a client machine to capture/analyse network traffic whilst that client attempted to access a DFS share.

These captures showed something strange: whenever the delay occurred, in between the DFS request being sent from the client to a DC, and the referral to a DFS root server coming back from the DC to the client, the DC was sending out several broadcast name lookups to the network.

Firstly, the DC would broadcast a NetBIOS lookup for DOMAIN (where DOMAIN is our pre-Windows 2000 Active Directory domain name). A few seconds later, it would broadcast a LLMNR lookup for DOMAIN. This would be followed by yet another broadcast NetBios lookup for DOMAIN. After these three lookups had been broadcast (and I assume timed out) the DC would finally respond to the client with a (correct) referral to a DFS root server.

These broadcast name lookups for DOMAIN were only being sent when the long delay opening a DFS share occurred, and we could clearly see from the Wireshark capture that the DC wasn't returning a referral to a DFS root server until all three lookups been sent (and ~7 seconds passed). So, these broadcast name lookups were pretty obviously the cause of our delays.

Now that we knew what the problem was, we started trying to figure out why these broadcast name lookups were occurring. After a bit more Googling and some trial-and-error, we found our answer: we hadn't set the DfsDnsConfig registry key on our domain controllers to 1, as is required when using DFS in a DNS-only environment.

When we originally setup DFS in our enviroment we did read the various articles about how to configure DFS for a DNS-only environment (e.g. Microsoft KB244380 and others) and were aware of this registry key, but had misintepreted the instructions on when/how to use it.

KB244380 says:

The DFSDnsConfig registry key must be added to each server that will participate in the DFS namespace for all computers to understand fully qualified names.

We thought this meant that the registry key has to be set on the DFS namespace servers only, not realising that it was also required on the domain controllers. After we set DfsDnsConfig to 1 on our domain controllers (and restarted the "DFS Namespace" service), the problem vanished.

Obviously we're happy with this outcome, but I would add that I'm still not 100% convinced that this is our only problem - I wonder if adding DfsDnsConfig=1 to our DCs has only worked around the problem, rather than solving it. I can't figure out why the DCs would be trying to lookup DOMAIN (the domain name itself, rather than a server in the domain) during the DFS referral process, even in a non-DNS-only environment, and I also know I haven't set DfsDnsConfig=1 on domain controllers in other (admittedly much smaller / simpler) DNS-only environments and haven't had the same issue. Still, we've solved our problem so we are happy.

I hope this is helpful to the others who are experiencing a similar issue - and thanks again to those that offered suggestions along the way.