Zugriff auf DFS vs. Round Robin

[Daniel-H 10]

Hallo,

ich hab eine Frage zu DFS und Round Robin:

 

Es existiert eine Domain mit drei Sites mit eigenen DCs:

Site 1:

DC1 IP 192.168.2.2

Subnets 192.168.1.0/24 (VPN-RoadWarrior) + 192.168.2.0/24 (LAN)

 

Site 2:

DC2 IP 192.168.3.2

Subnet 192.168.3.0/24

 

Site 3:

DC3 IP 192.168.4.2

Subnet 192.168.4.0/24

 

Die Replikation zwischen den Standorten funktioniert. Die Kosten wurden aufgrund unterschieldicher Bandbreiten angepasst:

DC1 - (cost 10 - 8MBit) - DC2

DC1 - (cost 20 - 1MBit) - DC3

DC2 - (cost 20 - 1MBit) - DC3

 

Es existiert ein DFS-N "\\intern.domain.de\DFS", alle DCs hosten eine Kopie.

In Site1 existiert ein VPN-Server.

 

Problem:

Ein RoadWarrior verbindet sich mit dem Netz und will aufs DFS Zugreifen.

Vom DNS bekommt es auf den Request nach "intern.domain.de" die IPs aller drei DCs in wechselnder Reihenfolge zurück (Round Robin). Das führt folglich dazu, dass der Warrior die Kommunikation in 2/3 der Fälle nicht über den Server am Standort des VPN-Server abgewickelt (DC1), sondern umständlich erst über einen langsamen Standort-Tunnel geht. Das führt natürlich zu einer relativ nervigen Verzögerung beim DFS-Zugriff.

 

Ist das normal (Round Robin ist ja standardmäßig aktiv), oder habe ich bei der Standortverknüpfung bzw. beim DFS-Setup etwas falsch gemacht?

 

Danke!

Daniel

[olc 18]

Hi Daniel,

 

zuerst mußt Du zwischen DNS und DFSN Auflösung unterscheiden: Bei der DNS Auflösung bekommt der Client einen Verweis auf einen DC in seiner Site. Ist dies schon nicht der Fall, stimmt wahrscheinlich etwas an Deiner DNS oder Site-Struktur nicht.

 

Vermutlich hat der Client bei der Einwahl per VPN keine IP-Adresse, die einem Subnetz Deiner internen Struktur entspricht. Somit kann kein "site-lokaler" DC gefunden werden.

 

Nachdem der DC per DNS lokalisiert wurde (unter Umständen schon der "falsche"), fragt der Client nun über den Workstation Service bei einem DC nach einem DFSN Referral. Da hier ebenso die Site-Zuordnungen nicht korrekt sein werden, kann auch hier kein DC der eigenen Site gefunden werden. Daher landest Du immer "auf irgend einem" DFSN Ziel.

 

Ergo: Du mußt Dir überlegen, ob Du die Client-Subnetze auch bei Roadwarrior Einwahl in einem bestimmten, vordefinierten IP-Adressbereich gewährleisten kannst. Falls nicht, könnte man schauen, ob es andere Alternativen gibt.

 

Falls der Client (das geht aus Deiner Erläuterung für mich nicht einwandfrei hervor) doch mit dem Subnetz der Site 1 in das "interne Netz" kommt, sollte der vom DNS zurückgegebene DC ein DC der Site 1 sein. Ist dies nicht der Fall, sind wir wieder bei einem Site Problem.

 

Sollte der Client per DNS den korrekten DC bekommen (anhand Deiner Beschreibung sieht es nicht so aus), wären wir wieder bei DFSN. Hier könnte ein "repadmin /siteoptions DEIN_DC /site:SITE1 +W2K3_BRIDGES_REQUIRED " helfen, aber an dem Punkt sind wir noch nicht...

 

Viele Grüße

olc

[Daniel-H 10]

Hallo olc,

 

Vermutlich hat der Client bei der Einwahl per VPN keine IP-Adresse, die einem Subnetz Deiner internen Struktur entspricht. Somit kann kein "site-lokaler" DC gefunden werden.

Das kann ich m.E. ausschließen. Die Standortkonfiguration ist korrekt und bei der Größe auch noch leicht überschaubar.

Außerdem wird kein NETLOGON-Event 5807 protokolliert (%SystemRoot%\debug\netlogon.log ist sauber), was bei fehlender Subnetzzuordnung einer Client-IP ja erfolgen würde.

 

Nachdem der DC per DNS lokalisiert wurde (unter Umständen schon der "falsche"), fragt der Client nun über den Workstation Service bei einem DC nach einem DFSN Referral. D

Danke für den Tip, mit dem Verfahren hatte ich mich noch nicht auseinandergesetzt. Ich schmeiss mal Wireshark an und schaue was dort passiert. Ich melde mich ggf. mit dem Ergebnis.

 

Mit ist in der Zwischenzeit schon aufgefallen, das das Problem offensichtlich nur bei Clients auftritt, die nicht Mitglied der Domäne sind. Wenn ich also z.B. mit meinem Home-PC via VPN aufs DFS zugreife. Gibt es da einen Zusammenhang? Ich dachte bislang, das allein die Subnetzzuordnung via IP ausschlaggebend für die Zuordnung des passenden Servers ist...

 

Gruß,

Daniel

[olc 18]

Hi Daniel,

 

Danke für den Tip, mit dem Verfahren hatte ich mich noch nicht auseinandergesetzt. Ich schmeiss mal Wireshark an und schaue was dort passiert. Ich melde mich ggf. mit dem Ergebnis.

 

Ja, das ist ein guter Ansatz. Auf dem Client erledigt der NETLOGON Dienst die Abfrage, der DC / DFS-Root Server nutzt jedoch AFAIR für die Generierung der Referral-Liste den Workstation Dienst. Und genau da kann ein Problem liegen, je nach Konstellation.

 

Mit ist in der Zwischenzeit schon aufgefallen, das das Problem offensichtlich nur bei Clients auftritt, die nicht Mitglied der Domäne sind. Wenn ich also z.B. mit meinem Home-PC via VPN aufs DFS zugreife. Gibt es da einen Zusammenhang? Ich dachte bislang, das allein die Subnetzzuordnung via IP ausschlaggebend für die Zuordnung des passenden Servers ist...

 

Na ja, dann hast Du die Ursache vermutlich gefunden... ;)

 

Der Client fragt wie oben schon beschrieben nach einem DC der eigenen Site - der DCLocator ist hierfür verantwortlich. Wenn der Client jedoch selbst nichts von seinem Subnetz weiß (bzw. nicht wissen kann, da kein Domänenmitglied), bekommt der Client irgend einen generischen DNS Eintrag für einen "beliebigen" DC zurück.

 

An den DC wendet der Client sich dann und bekommt u.a. über den Workstation Service des DFS-Root Server (in dem Fall der DC selbst) den entsprechenden Verweis. Der DC gibt hierbei einen DC der eigenen Site zurück, hier ist es also schon zu spät.

 

Versuche einmal folgendes: Setze auf den nicht-Domänen-Clients einmal den folgenden Registry Schlüssel, als Wert der Name Deiner Site1:

 

Schlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

REG_SZ (falls nicht vorhanden bitte erstellen): SiteName

Wert: Site1

 

Siehe dazu auch: Finding a Domain Controller in the Closest Site

 

Danach sollte der nicht-Domänen-Client beim richtigen DC in Site1 landen.

 

Viele Grüße

olc