Samba Administration Guide - Behavior of Cross-Subnet Browsing

Since the release of Samba 1.9.17 (alpha1), Samba has supported the replication of browse lists across subnet boundaries. This section describes how to set this feature up in different settings.

To see browse lists that span TCP/IP subnets (i.e., networks separated by routers that do not pass broadcast traffic), you must set up at least one WINS server. The WINS server acts as a DNS for NetBIOS names. This will allow NetBIOS name-to-IP address translation to be completed by a direct query of the WINS server. This is done via a directed UDP packet on port 137 to the WINS server machine. The WINS server avoids the necessity of default NetBIOS name-to-IP address translation, which is done using UDP broadcasts from the querying machine. This means that machines on one subnet will not be able to resolve the names of machines on another subnet without using a WINS server. The Samba hacks, remote browse sync , and remote announce are designed to get around the natural limitations that prevent UDP broadcast propagation. The hacks are not a universal solution and they should not be used in place of WINS, they are considered last resort methods.

Remember, for browsing across subnets to work correctly, all machines, be they Windows 95, Windows NT, or Samba servers, must have the IP address of a WINS server given to them by a DHCP server or by manual configuration: for Windows 9x/Me and Windows NT/200x/XP, this is in the TCP/IP Properties, under Network settings; for Samba, this is in the smb.conf file.

It is possible to operate Samba-3 without NetBIOS over TCP/IP. If you do this, be warned that if used outside of MS ADS, this will forgo network browsing support. ADS permits network browsing support through DNS, providing appropriate DNS records are inserted for all Samba servers.

Behavior of Cross-Subnet Browsing

Cross-subnet browsing is a complicated dance, containing multiple moving parts. It has taken Microsoft several years to get the code that correctly achieves this, and Samba lags behind in some areas. Samba is capable of cross-subnet browsing when configured correctly.

Consider a network set up as in Cross-Subnet Browsing Example.

Figure9.1.Cross-Subnet Browsing Example.

This consists of three subnets (1, 2, 3) connected by two routers (R1, R2), which do not pass broadcasts. Subnet 1 has five machines on it, subnet 2 has four machines, and subnet 3 has four machines. Assume for the moment that all machines are configured to be in the same workgroup (for simplicity's sake). Machine N1_C on subnet 1 is configured as the DMB (i.e., it will collate the browse lists for the workgroup). Machine N2_D is configured as a WINS server, and all the other machines are configured to register their NetBIOS names with it.

As these machines are booted up, elections for master browsers take place on each of the three subnets. Assume that machine N1_C wins on subnet 1, N2_B wins on subnet 2, and N3_D wins on subnet 3. These machines are known as LMBs for their particular subnet. N1_C has an advantage in winning as the LMB on subnet 1 because it is set up as DMB.

On each of the three networks, machines that are configured to offer sharing services will broadcast that they are offering these services. The LMB on each subnet will receive these broadcasts and keep a record of the fact that the machine is offering a service. This list of records is the basis of the browse list. For this case, assume that all the machines are configured to offer services, so all machines will be on the browse list.

For each network, the LMB on that network is considered authoritative for all the names it receives via local broadcast. This is because a machine seen by the LMB via a local broadcast must be on the same network as the Local Master Browser and thus is a trusted and verifiable resource. Machines on other networks that the LMBs learn about when collating their browse lists have not been directly seen. These records are called non-authoritative.

At this point the browse lists appear as shown in Browse Subnet Example 1 (these are the machines you would see in your network neighborhood if you looked in it on a particular network right now).

Table9.1.Browse Subnet Example 1

Subnet	Browse Master	List
Subnet1	N1_C	N1_A, N1_B, N1_C, N1_D, N1_E
Subnet2	N2_B	N2_A, N2_B, N2_C, N2_D
Subnet3	N3_D	N3_A, N3_B, N3_C, N3_D

At this point all the subnets are separate, and no machine is seen across any of the subnets.

Now examine subnet 2 in Browse Subnet Example 2. As soon as N2_B has become the LMB, it looks for a DMB with which to synchronize its browse list. It does this by querying the WINS server (N2_D) for the IP address associated with the NetBIOS name WORKGROUP<1B>. This name was registered by the DMB (N1_C) with the WINS server as soon as it was started.

Once N2_B knows the address of the DMB, it tells it that is the LMB for subnet 2 by sending a MasterAnnouncement packet as a UDP port 138 packet. It then synchronizes with it by doing a NetServerEnum2 call. This tells the DMB to send it all the server names it knows about. Once the DMB receives the MasterAnnouncement packet, it schedules a synchronization request to the sender of that packet. After both synchronizations are complete, the browse lists look like those in Browse Subnet Example 2

Table9.2.Browse Subnet Example 2

Subnet	Browse Master	List
Subnet1	N1_C	N1_A, N1_B, N1_C, N1_D, N1_E, N2_A(), N2_B(), N2_C(), N2_D()
Subnet2	N2_B	N2_A, N2_B, N2_C, N2_D, N1_A(), N1_B(), N1_C(), N1_D(), N1_E(*)
Subnet3	N3_D	N3_A, N3_B, N3_C, N3_D

Servers with an (*) after them are non-authoritative names.

At this point users looking in their Network Neighborhood on subnets 1 or 2 will see all the servers on both; users on subnet 3 will still see only the servers on their own subnet.

The same sequence of events that occurred for N2_B now occurs for the LMB on subnet 3 (N3_D). When it synchronizes browse lists with the DMB (N1_A) it gets both the server entries on subnet 1 and those on subnet 2. After N3_D has synchronized with N1_C and vica versa, the browse lists will appear as shown in Browse Subnet Example 3

Table9.3.Browse Subnet Example 3

Subnet	Browse Master	List
Subnet1	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()
Subnet2	N2_B	N2_A, N2_B, N2_C, N2_D, N1_A(), N1_B(), N1_C(), N1_D(), N1_E(*)
Subnet3	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(*)

Servers with an (*) after them are non-authoritative names.

At this point, users looking in their Network Neighborhood on subnets 1 or 3 will see all the servers on all subnets, while users on subnet 2 will still see only the servers on subnets 1 and 2, but not 3.

Finally, the LMB for subnet 2 (N2_B) will sync again with the DMB (N1_C) and will receive the missing server entries. Finally, as when a steady state (if no machines are removed or shut off) has been achieved, the browse lists will appear as shown in Browse Subnet Example 4.

Table9.4.Browse Subnet Example 4

Subnet	Browse Master	List
Subnet1	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()
Subnet2	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(*)
Subnet3	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(*)

Servers with an (*) after them are non-authoritative names.

Synchronizations between the DMB and LMBs will continue to occur, but this should remain a steady-state operation.

If either router R1 or R2 fails, the following will occur:

Names of computers on each side of the inaccessible network fragments will be maintained for as long as 36 minutes in the Network Neighborhood lists.
Attempts to connect to these inaccessible computers will fail, but the names will not be removed from the Network Neighborhood lists.
If one of the fragments is cut off from the WINS server, it will only be able to access servers on its local subnet using subnet-isolated broadcast NetBIOS name resolution. The effect is similar to that of losing access to a DNS server.