Next Previous Contents

2. Browsing über Subnetzgrenzen hinweg

Mit dem Erscheinen von Samba 1.9.17 ist Samba in der Lage, Browse Listen über Subnetzgrenzen hinweg zu weiterzugeben. Es gibt neuen Code und neue Optionen, mit denen dieses Feature gesteuert wird. Dieser Abschnitt beschreibt, wie Browsing über Subnetzgrenzen hinweg funktioniert, und wie es konfiguriert wird.

Um Browse Listen zu sehen, die über TCP/IP Subnetzgrenzen hinweg gehen, das heißt die durch Router getrennt sind, die keine Broadcasts durchlassen, müssen Sie mindestens einen WINS Server installieren. Der WINS Server arbeitet wie ein DNS Server für NetBIOS Namen. Damit können NetBIOS Namen mit einer direkten Anfrage an den WINS Server nach IP Adressen umgewandelt werden. Dies geschieht mit einem gerichteten UDP Paket nach Port 137 des WINS Servers. Der Grund, einen WINS Server einzusetzen, liegt darin, daß normalerweise die Auflösung von NetBIOS Namen nach IP Adressen durch Broadcasts geschieht. Damit können Maschinen im einen Subnetz die Namen der Maschinen im anderen Subnetz nicht auflösen, ohne einen WINS Server zu benutzen.

Bitte denken sie daran, daß beim Browsing über Netzwerkgrenzen hinweg alle Rechner, seien es Windows 95, Windows NT oder Samba Server die IP-Adresse des WINS Servers durch einen DHCP Server oder in der festen Konfiguration mitgeteilt bekommen müssen. Bei Windows 95 und NT geschieht dies in den Eigenschaften der Netzwerkumgebung, bei Samba in der Datei smb.conf.

2.1 Wie funktioniert Browsing über Subnetzgrenzen?

Browsing über Subnetzgrenzen ist kompliziert, mehrere Teilnehmer sind beteiligt, von denen keiner fest konfiguriert ist. Microsoft hat mehrere Jahre gebraucht, um den Code dafür richtig hinzubekommen. Samba hinkt in einigen Bereichen etwas hinterher. Jedoch kann Samba mit der Release 1.9.17 am Browsing über Subnetzgrenzen hinweg teilnehmen, wenn es richtig konfiguriert wird.

Stellen Sie sich folgendes Netzwerk vor:

                                   (DMB)
             N1_A      N1_B        N1_C       N1_D        N1_E
              |          |           |          |           |
          -------------------------------------------------------
            |          Subnetz 1                       |
          +---+                                      +---+
          |R1 | Router 1                  Router 2   |R2 |
          +---+                                      +---+
            |                                          |
            |  Subnetz 2             Subnetz 3         |
  --------------------------       ------------------------------------
  |     |     |      |               |        |         |           |
 N2_A  N2_B  N2_C   N2_D           N3_A     N3_B      N3_C        N3_D 
                    (WINS)

Dieses Netz besteht aus 3 Subnetzen (1,2,3), die durch 2 Router (R1 und R2) verbunden sind. Diese lassen keine Broadcasts durch. Subnetz 1 hat 5 Maschinen, Subnetz 2 4 Maschinen und Subnetz 3 auch 4 Maschinen. Nehmen wir für den Moment der Einfachheit halber an, daß alle Maschinen in der gleichen Arbeitsgruppe konfiguriert sind. Rechner N1_C im Subnetz 1 ist als Domain Master Browser konfiguriert. Das heißt, daß er die Browseliste für die ganze Arbeitsgruppe aufsammelt. Rechner N2_D ist als WINS Server konfiguriert und alle anderen Maschinen registrieren ihre NetBIOS Namen dort.

Wenn alle diese Maschinen gebootet werden, werden in jedem der drei Subnetze Wahlen um einen Local Master Browser abgehalten. Nehmen wir an, im Subnetz 1 gewinnt N1_C, im Subnetz 2 gewinnt N2_B und im Subnetz 3 gewinnt N3_D. Diese Maschinen sind als Local Master Browser in ihrem Subnetz bekannt. N1_C hat einen Vorteil bei den Wahlen im Subnetz 1, da diese Maschine als Domain Master Browser konfiguriert ist.

Alle Maschinen, die Serverdienste anzubieten haben, kündigen dies per Broadcast auf ihrem Subnetz an. Der Local Master Browser in jedem Subnetz empfängt diese Broadcasts und trägt alle Server in einer Liste ein. Diese Liste von Einträgen ist die Basis für die Browseliste. In unserem Fall nehmen wir an, daß alle Maschinen Serverdienste anbieten, das heißt, daß alle Maschinen in der Liste erscheinen.

Für jedes Subnetz wird der Local Master Browser als maßgeblich angesehen, und zwar für alle Namen, die er per lokalem Broadcast empfängt. Broadcasts verlassen das Subnetz nicht, und die Broadcasts im lokalen Subnetz werden als maßgeblich angesehen. Daher wird dem Local Master Browser bei diesen Servern geglaubt. Rechner, die sich in anderen Subnetzen befinden, und über die der Local Master Browser von anderen Local Master Browsern informiert wurde, werden als nicht maßgeblich angesehen.

An diesem Punkt sieht die Browse Liste folgendermaßen aus: (dies sind die Maschinen, die Sie in Ihrer Netzwerkumgebung sehen würden, wenn Sie sie in einem bestimmten Subnetz ansehen)

Subnetz           Browse Master   Liste
--------          -------------   -----
Subnetz1          N1_C            N1_A, N1_B, N1_C, N1_D, N1_E

Subnetz2          N2_B            N2_A, N2_B, N2_C, N2_D

Subnetz3          N3_D            N3_A, N3_B, N3_C, N3_D

An diesem Punkt sind alle Subnetze vollständig separat, keine Maschine wird in anderen Subnetzen gesehen.

Sehen wir uns nun Subnetz 2 an. Sobald N2_B der Local Master Browser geworden ist, sucht der den Domain Master Browser, um mit ihm die Browse Listen zu synchronisieren. Dies tut er, indem er den WINS Server (N2_D) nach der IP-Adresse fragt, die zum Namen WORKGROUP<1B> gehört. Dieser Name ist vom Domain Master Browser (N1_C) beim WINS Server registriert worden, als dieser gebootet wurde.

N2_B kennt nun den Domain Master Browser. Er kündigt sich als Local Master Browser für Subnetz 2 bei ihm an, indem er ein MasterAnnouncement Paket per UDP an Port 138 von N2_D schickt. Dann synchronisiert N2_B sich mit N2_D, indem er einen NetServerEnum2-Aufruf abschickt. Der Domain Master Browser schickt alle Server, die er kennt, zurück. Sobald der Domain Master Browser ein MasterAnnouncement Paket erhalten hat, wird auch er sich mit dem Local Master Browser synchronisieren. Nachdem beide Synchronisationen stattgefunden haben, sehen die Browse Listen so aus:

Subnetz          Browse Master   Liste
--------         -------------   -----
Subnetz1         N1_C            N1_A, N1_B, N1_C, N1_D, N1_E, 
                                 N2_A(*), N2_B(*), N2_C(*), N2_D(*)

Subnetz2         N2_B            N2_A, N2_B, N2_C, N2_D
                                 N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)

Subnetz3         N3_D            N3_A, N3_B, N3_C, N3_D

Die mit * bezeichneten Einträge werden als nicht maßgeblich angesehen, da sie von anderen Master Browsern erhalten wurden.

Zu diesem Zeitpunkt werden Benutzer in den Subnetzen 1 und 2, die die Netzwerkumgebung ansehen, die Server in beiden Subnetzen sehen, Benutzer im Subnetz 3 sehen immer noch nur die Server in ihrem eigenen Subnetz.

Der lokale Master Browser im Subnetz 3 (N3_D) macht nun exakt das gleiche wie N2_B. Wenn er die Browse Listen mit dem Domain Master Browser (N1_A) abgeglichen hat, bekommt er sowohl die Server in Subnetz 1, als auch die im Subnetz 2. Nachdem sich N3_D mit N1_C synchronisiert, und umgekehrt, sehen die Browse Listen folgendermaßen aus:

Subnetz           Browse Master   Liste
-------           -------------   -----
Subnetz1          N1_C            N1_A, N1_B, N1_C, N1_D, N1_E, 
                                  N2_A(*), N2_B(*), N2_C(*), N2_D(*),
                                  N3_A(*), N3_B(*), N3_C(*), N3_D(*)

Subnetz2          N2_B            N2_A, N2_B, N2_C, N2_D
                                  N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)

Subnetz3          N3_D            N3_A, N3_B, N3_C, N3_D
                                  N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*),
                                  N2_A(*), N2_B(*), N2_C(*), N2_D(*)

Jetzt sehen Benutzer in den Subnetzen 1 und 3 alle Server in allen Subnetzen, Benutzer im Subnetz 2 sehen jedoch immer noch nur die Server von Subnetz 1 und 2, nicht jedoch die im Subnetz 3.

Zum guten Schluß wird sich der lokale Master Browser im Subnetz 2 (N2_B) erneut mit dem Domain Master Browser abstimmen, und die fehlenden Servereinträge bekommen. Endlich sehen die Browse Listen als stabiler Zustand so aus:

Subnetz           Browse Master   Liste
-------           -------------   -----
Subnetz1          N1_C            N1_A, N1_B, N1_C, N1_D, N1_E, 
                                  N2_A(*), N2_B(*), N2_C(*), N2_D(*),
                                  N3_A(*), N3_B(*), N3_C(*), N3_D(*)

Subnetz2          N2_B            N2_A, N2_B, N2_C, N2_D
                                  N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
                                  N3_A(*), N3_B(*), N3_C(*), N3_D(*)

Subnetz3          N3_D            N3_A, N3_B, N3_C, N3_D
                                  N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*),
                                  N2_A(*), N2_B(*), N2_C(*), N2_D(*)

Synchronisationen zwischen dem Domain Master Browser und den Lokalen Master Browsern wird weiterhin auftreten, aber dies sollte den stabilen Zustand nur bestätigen.

Wenn Router R1 oder R2 ausfallen, wird das folgende passieren:

  1. Namen der Computer auf beiden Seiten der nicht mehr erreichbaren Subnetze werden für 36 Minuten weiter in den Browse Listen gehalten, so daß sie in der Netzwerkumgebung weiterhin erscheinen.
  2. Versuche, Verbindungen zu diesen Rechnern aufzubauen, werden scheitern, aber die Namen werden nicht von den Browse Listen entfernt werden.
  3. Wenn ein Subnetz vom WINS Server getrennt wird, wird es nur noch auf die lokalen Server zugreifen können, deren Namen mit lokaler Broadcast NetBIOS-Namensauflösung aufgelöst werden können. Das ist vergleichbar mit der Situation, keinen Zugriff auf einen DNS Server mehr zu haben.

Next Previous Contents