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, andremote announceare 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.

Section9.7. Technical Overview of Browsing 135

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 thesmb.conffile.

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.

9.7.3.1

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 Figure 9.1.

Figure 9.1Cross-Subnet Browsing Example.

N1_A N1_B N1_C (DMB) N1_D N1_E Router 1 Subnet 1 Router 2 Subnet 2 N2_D (WINS) N2_C N2_B N2_A Subnet 3 N3_D N3_C N3_B N3_A

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

136 Network Browsing Chapter 9

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 authoritativefor 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 atrustedand

verifiableresource. Machines on other networks that the LMBs learn about when collating their browse lists have not been directly seen. These records are callednon-authoritative.

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

Table 9.1Browse 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 Table 9.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 aNetServerEnum2call. 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 Table 9.2

Table 9.2Browse 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

Section9.7. Technical Overview of Browsing 137

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 Table 9.3

Table 9.3Browse 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 Table 9.4.

Table 9.4Browse 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:

1. Names of computers on each side of the inaccessible network fragments will be main- tained for as long as 36 minutes in the Network Neighborhood lists.

2. Attempts to connect to these inaccessible computers will fail, but the names will not be removed from the Network Neighborhood lists.

138 Network Browsing Chapter 9

3. 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.

9.8

Common Errors

Many questions are asked on the mailing lists regarding browsing. The majority of browsing problems originate from incorrect configuration of NetBIOS name resolution. Some are of particular note.