8648bfa256370b36a0b06a03aed7a07ae60518fa
[samba.git] / docs / docbook / projdoc / NetworkBrowsing.xml
1 <chapter id="NetworkBrowsing">
2 <chapterinfo>
3         &author.jht;
4         <pubdate>July 5, 1998</pubdate>
5         <pubdate>Updated: April 21, 2003</pubdate>
6 </chapterinfo>
7
8 <title>Samba / MS Windows Network Browsing Guide</title>
9
10 <para>
11 This document contains detailed information as well as a fast track guide to
12 implementing browsing across subnets and / or across workgroups (or domains).
13 WINS is the best tool for resolution of NetBIOS names to IP addesses. WINS is
14 NOT involved in browse list handling except by way of name to address resolution.
15 </para>
16
17 <note><para>
18 MS Windows 2000 and later can be configured to operate with NO NetBIOS 
19 over TCP/IP. Samba-3 and later also supports this mode of operation.
20 When the use of NetBIOS over TCP/IP has been disabled then the primary
21 means for resolution of MS Windows machine names is via DNS and Active Directory.
22 The following information assumes that your site is running NetBIOS over TCP/IP.
23 </para></note>
24
25 <sect1>
26 <title>Features and Benefits</title>
27
28 <para>
29 Someone once referred to the past in terms of: <emphasis>They were the worst of times,
30 they were the best of times. The more we look back, them more we long for what was and
31 hope it never returns!</emphasis>.
32 </para>
33
34 <para>
35 For many MS Windows network administrators that statement sums up their feelings about
36 NetBIOS networking precisely. For those who mastered NetBIOS networking it's fickle
37 nature was just par for the course. For those who never quite managed to tame it's
38 lusty features NetBIOS is like Paterson's Curse.
39 </para>
40
41 <para>
42 For those not familiar with botanical problems in Australia: Paterson's curse,
43 Echium plantagineum, was introduced to Australia from Europe during the mid-nineteenth
44 century. Since then it has spread rapidly. The high seed production, with densities of
45 thousands of seeds per square metre, a seed longevity of more than seven years, and an
46 ability to germinate at any time of year, given the right conditions, are some of the
47 features which make it such a persistent weed.
48 </para>
49
50 <para>
51 In this chapter we explore vital aspects of SMB (Server Message Block) networking with
52 a particular focus on SMB as implmented through running NetBIOS (Network Basic
53 Input / Output System) over TCP/IP. Since Samba does NOT implement SMB or NetBIOS over
54 any other protocols we need to know how to configure our network environment and simply
55 remember to use nothing but TCP/IP on all our MS Windows network clients.
56 </para>
57
58 <para>
59 Samba provides the ability to implement a WINS (Windows Internetworking Name Server)
60 and implements extensions to Microsoft's implementation of WINS. These extensions
61 help Samba to affect stable WINS operations beyond the normal scope of MS WINS.
62 </para>
63
64 <para>
65 Please note that WINS is exclusively a service that applies only to those systems
66 that run NetBIOS over TCP/IP. MS Windows 200x / XP have the capacity to turn off
67 support for NetBIOS, in which case WINS is of no relevance. Samba-3 supports this also.
68 </para>
69
70 <para>
71 For those networks on which NetBIOS has been disabled (ie: WINS is NOT required)
72 the use of DNS is necessary for host name resolution.
73 </para>
74
75 </sect1>
76
77 <sect1>
78 <title>What is Browsing?</title>
79
80 <para>
81 To most people browsing means that they can see the MS Windows and Samba servers
82 in the Network Neighborhood, and when the computer icon for a particular server is
83 clicked, it opens up and shows the shares and printers available on the target server.
84 </para>
85
86 <para>
87 What seems so simple is in fact a very complex interaction of different technologies.
88 The technologies (or methods) employed in making all of this work includes:
89 </para>
90
91 <simplelist>
92         <member>MS Windows machines register their presence to the network</member>
93         <member>Machines announce themselves to other machines on the network</member>
94         <member>One or more machine on the network collates the local announcements</member>
95         <member>The client machine finds the machine that has the collated list of machines</member>
96         <member>The client machine is able to resolve the machine names to IP addresses</member>
97         <member>The client machine is able to connect to a target machine</member>
98 </simplelist>
99
100 <para>
101 The samba application that controls/manages browse list management and name resolution is
102 called <filename>nmbd</filename>. The configuration parameters involved in nmbd's operation are:
103 </para>
104
105 <para><programlisting>
106         Browsing options:
107         -----------------
108                 * os level
109                   lm announce
110                   lm interval
111                 * preferred master
112                 * local master
113                 * domain master
114                   browse list
115                   enhanced browsing
116
117         Name Resolution Method:
118         -----------------------
119                 * name resolve order
120
121         WINS options:
122         -------------
123                   dns proxy
124                   wins proxy
125                 * wins server
126                 * wins support
127                   wins hook
128 </programlisting></para>
129
130 <para>
131 For Samba the WINS Server and WINS Support are mutually exclusive options. Those marked with
132 an '*' are the only options that commonly MAY need to be modified. Even if not one of these
133 parameters is set nmbd will still do it's job.
134 </para>
135
136 </sect1>
137
138 <sect1>
139 <title>Discussion</title>
140
141 <para>
142 Firstly, all MS Windows networking uses SMB (Server Message Block) based messaging.
143 SMB messaging may be implemented with or without NetBIOS. MS Windows 200x supports
144 NetBIOS over TCP/IP for backwards compatibility. Microsoft are intent on phasing out NetBIOS
145 support.
146 </para>
147
148 <sect2>
149 <title>NetBIOS over TCP/IP</title>
150
151 <para>
152 Samba implements NetBIOS, as does MS Windows NT / 200x / XP, by encapsulating it over TCP/IP.
153 MS Windows products can do likewise. NetBIOS based networking uses broadcast messaging to
154 affect browse list management. When running NetBIOS over TCP/IP this uses UDP based messaging.
155 UDP messages can be broadcast or unicast.
156 </para>
157
158 <para>
159 Normally, only unicast UDP messaging can be forwarded by routers. The
160 <command>remote announce</command> parameter to smb.conf helps to project browse announcements
161 to remote network segments via unicast UDP. Similarly, the 
162 <command>remote browse sync</command> parameter of <filename>smb.conf</filename>
163 implements browse list collation using unicast UDP.
164 </para>
165
166 <para>
167 Secondly, in those networks where Samba is the only SMB server technology
168 wherever possible <filename>nmbd</filename> should be configured on one (1) machine as the WINS
169 server. This makes it easy to manage the browsing environment. If each network
170 segment is configured with it's own Samba WINS server, then the only way to
171 get cross segment browsing to work is by using the 
172 <command>remote announce</command> and the <command>remote browse sync</command>
173 parameters to your <filename>smb.conf</filename> file.
174 </para>
175
176 <para>
177 If only one WINS server is used for an entire multi-segment network then
178 the use of the <command>remote announce</command> and the 
179 <command>remote browse sync</command> parameters should NOT be necessary.
180 </para>
181
182 <para>
183 As of Samba 3 WINS replication is being worked on. The bulk of the code has
184 been committed, but it still needs maturation. This is NOT a supported feature
185 of the Samba-3.0.0 release. Hopefully, this will become a supported feature
186 of one of the samba-3 release series.
187 </para>
188
189 <para>
190 Right now samba WINS does not support MS-WINS replication. This means that
191 when setting up Samba as a WINS server there must only be one <filename>nmbd</filename>
192 configured as a WINS server on the network. Some sites have used multiple Samba WINS
193 servers for redundancy (one server per subnet) and then used 
194 <command>remote browse sync</command> and <command>remote announce</command>
195 to affect browse list collation across all segments. Note that this means clients
196 will only resolve local names, and must be configured to use DNS to resolve names
197 on other subnets in order to resolve the IP addresses of the servers they can see
198 on other subnets. This setup is not recommended, but is mentioned as a practical
199 consideration (ie: an 'if all else fails' scenario).
200 </para>
201
202 <para>
203 Lastly, take note that browse lists are a collection of unreliable broadcast
204 messages that are repeated at intervals of not more than 15 minutes. This means
205 that it will take time to establish a browse list and it can take up to 45
206 minutes to stabilise, particularly across network segments.
207 </para>
208
209 </sect2>
210
211 <sect2>
212 <title>TCP/IP - without NetBIOS</title>
213
214 <para>
215 All TCP/IP using systems use various forms of host name resolution. The primary
216 methods for TCP/IP hostname resolutions involves either a static file (<filename>/etc/hosts
217 </filename>) or DNS (the Domain Name System). DNS is the technology that makes
218 the Internet usable. DNS based host name resolution is supported by nearly all TCP/IP
219 enabled systems. Only a few embedded TCP/IP systems do not support DNS.
220 </para>
221
222 <para>
223 When an MS Windows 200x / XP system attempts to resolve a host name to an IP address
224 it follows a defined path:
225 </para>
226
227 <orderedlist>
228         <listitem><para>
229         Checks the <filename>hosts</filename> file. It is located in
230         <filename>C:\WinNT\System32\Drivers\etc</filename>.
231         </para></listitem>
232
233         <listitem><para>
234         Does a DNS lookup
235         </para></listitem>
236
237         <listitem><para>
238         Checks the NetBIOS name cache
239         </para></listitem>
240
241         <listitem><para>
242         Queries the WINS server
243         </para></listitem>
244
245         <listitem><para>
246         Does a broadcast name lookup over UDP
247         </para></listitem>
248
249         <listitem><para>
250         Looks up entries in LMHOSTS. It is located in
251         <filename>C:\WinNT\System32\Drivers\etc</filename>.
252         </para></listitem>
253 </orderedlist>
254
255 <para>
256 Windows 200x / XP can register it's host name with a Dynamic DNS server. You can
257 force register with a Dynamic DNS server in Windows 200x / XP using:
258 <command>ipconfig /registerdns</command>
259 </para>
260
261 <para>
262 With Active Directory (ADS), a correctly functioning DNS server is absolutely
263 essential. In the absence of a working DNS server that has been correctly configured
264 MS Windows clients and servers will be totally unable to locate each other,
265 consequently network services will be severely impaired.
266 </para>
267
268 <para>
269 The use of Dynamic DNS is highly recommended with Active Directory, in which case
270 the use of BIND9 is preferred for it's ability to adequately support the SRV (service)
271 records that are needed for Active Directory.
272 </para>
273
274 </sect2>
275
276 <sect2>
277 <title>DNS and Active Directory</title>
278
279 <para>
280 Occasionally we hear from Unix network administrators who want to use a Unix based Dynamic
281 DNS server in place of the Microsoft DNS server. While this might be desirable to some, the
282 MS Windows 200x DNS server is auto-configured to work with Active Directory. It is possible
283 to use BIND version 8 or 9, but it will almost certainly be necessary to create service records
284 so that MS Active Directory clients can resolve host names to locate essential network services.
285 The following are some of the default service records that Active Directory requires:
286 </para>
287
288 <itemizedlist>
289         <listitem><para>_ldap._tcp.pdc.ms-dcs.<emphasis>Domain</emphasis></para>
290
291                 <para>
292                 This provides the address of the Windows NT PDC for the Domain.
293                 </para>
294         </listitem>
295
296         <listitem><para>_ldap._tcp.pdc.ms-dcs.<emphasis>DomainTree</emphasis></para>
297
298                 <para>
299                 Resolves the addresses of Global Catalog servers in the domain.
300                 </para>
301         </listitem>
302
303         <listitem><para>_ldap._tcp.<emphasis>site</emphasis>.sites.writable.ms-dcs.<emphasis>Domain</emphasis></para>
304                 <para>
305                 Provides list of domain controllers based on sites.
306                 </para>
307         </listitem>
308
309         <listitem><para>_ldap._tcp.writable.ms-dcs.<emphasis>Domain</emphasis></para>
310
311                 <para>
312                 Enumerates list of domain controllers that have the writable    
313                 copies of the Active Directory data store.
314                 </para>
315         </listitem>
316
317         <listitem><para>_ldap._tcp.<emphasis>GUID</emphasis>.domains.ms-dcs.<emphasis>DomainTree</emphasis></para>
318                 <para>
319                 Entry used by MS Windows clients to locate machines using the
320                 Global Unique Identifier.
321                 </para>
322         </listitem>
323
324         <listitem><para>_ldap._tcp.<emphasis>Site</emphasis>.gc.ms-dcs.<emphasis>DomainTree</emphasis></para>
325                 <para>
326                 Used by MS Windows clients to locate site configuration dependant
327                 Global Catalog server.
328                 </para>
329         </listitem>
330 </itemizedlist>
331
332 </sect2>
333
334 </sect1>
335
336 <sect1>
337 <title>How Browsing Functions</title>
338
339 <para>
340 MS Windows machines register their NetBIOS names 
341 (ie: the machine name for each service type in operation) on start 
342 up. The exact method by which this name registration 
343 takes place is determined by whether or not the MS Windows client/server 
344 has been given a WINS server address, whether or not LMHOSTS lookup 
345 is enabled, or if DNS for NetBIOS name resolution is enabled, etc.
346 </para>
347
348 <para>
349 In the case where there is no WINS server all name registrations as 
350 well as name lookups are done by UDP broadcast. This isolates name 
351 resolution to the local subnet, unless LMHOSTS is used to list all 
352 names and IP addresses. In such situations Samba provides a means by 
353 which the samba server name may be forcibly injected into the browse 
354 list of a remote MS Windows network (using the 
355 <command>remote announce</command> parameter).
356 </para>
357
358 <para>
359 Where a WINS server is used, the MS Windows client will use UDP 
360 unicast to register with the WINS server. Such packets can be routed 
361 and thus WINS allows name resolution to function across routed networks.
362 </para>
363
364 <para>
365 During the startup process an election will take place to create a 
366 local master browser if one does not already exist. On each NetBIOS network 
367 one machine will be elected to function as the domain master browser. This 
368 domain browsing has nothing to do with MS security domain control. 
369 Instead, the domain master browser serves the role of contacting each local 
370 master browser (found by asking WINS or from LMHOSTS) and exchanging browse 
371 list contents. This way every master browser will eventually obtain a complete 
372 list of all machines that are on the network. Every 11-15 minutes an election 
373 is held to determine which machine will be the master browser. By the nature of 
374 the election criteria used, the machine with the highest uptime, or the 
375 most senior protocol version, or other criteria, will win the election 
376 as domain master browser.
377 </para>
378
379 <para>
380 Clients wishing to browse the network make use of this list, but also depend 
381 on the availability of correct name resolution to the respective IP 
382 address/addresses. 
383 </para>
384
385 <para>
386 Any configuration that breaks name resolution and/or browsing intrinsics 
387 will annoy users because they will have to put up with protracted 
388 inability to use the network services.
389 </para>
390
391 <para>
392 Samba supports a feature that allows forced synchonisation 
393 of browse lists across routed networks using the <command>remote 
394 browse sync</command> parameter in the <filename>smb.conf</filename> file. 
395 This causes Samba to contact the local master browser on a remote network and 
396 to request browse list synchronisation. This effectively bridges 
397 two networks that are separated by routers. The two remote 
398 networks may use either broadcast based name resolution or WINS 
399 based name resolution, but it should be noted that the <command>remote 
400 browse sync</command> parameter provides browse list synchronisation - and 
401 that is distinct from name to address resolution, in other 
402 words, for cross subnet browsing to function correctly it is 
403 essential that a name to address resolution mechanism be provided. 
404 This mechanism could be via DNS, <filename>/etc/hosts</filename>, 
405 and so on.
406 </para>
407
408 <sect2>
409 <title>Setting up WORKGROUP Browsing</title>
410
411 <para>
412 To set up cross subnet browsing on a network containing machines
413 in up to be in a WORKGROUP, not an NT Domain you need to set up one
414 Samba server to be the Domain Master Browser (note that this is *NOT*
415 the same as a Primary Domain Controller, although in an NT Domain the
416 same machine plays both roles).  The role of a Domain master browser is
417 to collate the browse lists from local master browsers on all the
418 subnets that have a machine participating in the workgroup.  Without
419 one machine configured as a domain master browser each subnet would
420 be an isolated workgroup, unable to see any machines on any other
421 subnet.  It is the presense of a domain master browser that makes
422 cross subnet browsing possible for a workgroup.
423 </para>
424
425 <para>
426 In an WORKGROUP environment the domain master browser must be a
427 Samba server, and there must only be one domain master browser per
428 workgroup name.  To set up a Samba server as a domain master browser,
429 set the following option in the [global] section of the &smb.conf; file :
430 </para>
431
432 <para>
433 <programlisting>
434         domain master = yes
435 </programlisting>
436 </para>
437
438 <para>
439 The domain master browser should also preferrably be the local master
440 browser for its own subnet.  In order to achieve this set the following
441 options in the [global] section of the &smb.conf; file :
442 </para>
443
444 <para>
445 <programlisting>
446         domain master = yes
447         local master = yes
448         preferred master = yes
449         os level = 65
450 </programlisting>
451 </para>
452
453 <para>
454 The domain master browser may be the same machine as the WINS
455 server, if you require.
456 </para>
457
458 <para>
459 Next, you should ensure that each of the subnets contains a
460 machine that can act as a local master browser for the
461 workgroup.  Any MS Windows NT/2K/XP/2003  machine should be
462 able to do this, as will Windows 9x machines (although these
463 tend to get rebooted more often, so it's not such a good idea
464 to use these).  To make a Samba server a local master browser
465 set the following options in the [global] section of the
466 &smb.conf; file :
467 </para>
468
469 <para>
470 <programlisting>
471         domain master = no
472         local master = yes
473         preferred master = yes
474         os level = 65
475 </programlisting>
476 </para>
477
478 <para>
479 Do not do this for more than one Samba server on each subnet,
480 or they will war with each other over which is to be the local
481 master browser.
482 </para>
483
484 <para>
485 The <command>local master</command> parameter allows Samba to act as a
486 local master browser.  The <command>preferred master</command> causes nmbd
487 to force a browser election on startup and the <command>os level</command>
488 parameter sets Samba high enough so that it should win any browser elections.
489 </para>
490
491 <para>
492 If you have an NT machine on the subnet that you wish to
493 be the local master browser then you can disable Samba from
494 becoming a local master browser by setting the following
495 options in the <command>[global]</command> section of the 
496 &smb.conf; file :
497 </para>
498
499 <para>
500 <programlisting>
501         domain master = no
502         local master = no
503         preferred master = no
504         os level = 0
505 </programlisting>
506 </para>
507
508 </sect2>
509
510 <sect2>
511 <title>Setting up DOMAIN Browsing</title>
512
513 <para>
514 If you are adding Samba servers to a Windows NT Domain then
515 you must not set up a Samba server as a domain master browser.
516 By default, a Windows NT Primary Domain Controller for a Domain
517 name is also the Domain master browser for that name, and many
518 things will break if a Samba server registers the Domain master
519 browser NetBIOS name (<replaceable>DOMAIN</replaceable>&lt;1B&gt;)
520 with WINS instead of the PDC.
521 </para>
522
523 <para>
524 For subnets other than the one containing the Windows NT PDC
525 you may set up Samba servers as local master browsers as
526 described.  To make a Samba server a local master browser set 
527 the following options in the <command>[global]</command> section 
528 of the &smb.conf; file :
529 </para>
530
531 <para>
532 <programlisting>
533         domain master = no
534         local master = yes
535         preferred master = yes
536         os level = 65
537 </programlisting>
538 </para>
539
540 <para>
541 If you wish to have a Samba server fight the election with machines
542 on the same subnet you may set the <command>os level</command> parameter
543 to lower levels.  By doing this you can tune the order of machines that
544 will become local master browsers if they are running.  For
545 more details on this see the section <link linkend="browse-force-master">
546 Forcing samba to be the master browser</link>
547 below.
548 </para>
549
550 <para>
551 If you have Windows NT machines that are members of the domain
552 on all subnets, and you are sure they will always be running then
553 you can disable Samba from taking part in browser elections and
554 ever becoming a local master browser by setting following options 
555 in the <command>[global]</command> section of the &smb.conf;
556 file :
557 </para>
558
559 <para>
560 <programlisting>
561         domain master = no
562         local master = no
563         preferred master = no
564         os level = 0
565 </programlisting>
566 </para>
567
568 </sect2>
569
570 <sect2 id="browse-force-master">
571 <title>Forcing samba to be the master</title>
572
573 <para>
574 Who becomes the <command>master browser</command> is determined by an election
575 process using broadcasts.  Each election packet contains a number of parameters
576 which determine what precedence (bias) a host should have in the
577 election.  By default Samba uses a very low precedence and thus loses
578 elections to just about anyone else.
579 </para>
580
581 <para>
582 If you want Samba to win elections then just set the <command>os level</command> global
583 option in &smb.conf; to a higher number.  It defaults to 0.  Using 34
584 would make it win all elections over every other system (except other
585 samba systems!)
586 </para>
587
588 <para>
589 A <command>os level</command> of 2 would make it beat WfWg and Win95, but not MS Windows
590 NT/2K Server.  A MS Windows NT/2K Server domain controller uses level 32.
591 </para>
592
593 <para>The maximum os level is 255</para>
594
595 <para>
596 If you want samba to force an election on startup, then set the
597 <command>preferred master</command> global option in &smb.conf; to "yes".  Samba will
598 then have a slight advantage over other potential master browsers
599 that are not preferred master browsers.  Use this parameter with
600 care, as if you have two hosts (whether they are windows 95 or NT or
601 samba) on the same local subnet both set with <command>preferred master</command> to
602 "yes", then periodically and continually they will force an election
603 in order to become the local master browser.
604 </para>
605
606 <para>
607 If you want samba to be a <command>domain master browser</command>, then it is
608 recommended that you also set <command>preferred master</command> to "yes", because
609 samba will not become a domain master browser for the whole of your
610 LAN or WAN if it is not also a local master browser on its own
611 broadcast isolated subnet.
612 </para>
613
614 <para>
615 It is possible to configure two samba servers to attempt to become
616 the domain master browser for a domain.  The first server that comes
617 up will be the domain master browser.  All other samba servers will
618 attempt to become the domain master browser every 5 minutes.  They
619 will find that another samba server is already the domain master
620 browser and will fail.  This provides automatic redundancy, should
621 the current domain master browser fail.
622 </para>
623
624 </sect2>
625
626 <sect2>
627 <title>Making samba the domain master</title>
628
629 <para>
630 The domain master is responsible for collating the browse lists of
631 multiple subnets so that browsing can occur between subnets.  You can
632 make samba act as the domain master by setting <command>domain master = yes</command>
633 in &smb.conf;.  By default it will not be a domain master.
634 </para>
635
636 <para>
637 Note that you should NOT set Samba to be the domain master for a
638 workgroup that has the same name as an NT Domain.
639 </para>
640
641 <para>
642 When samba is the domain master and the master browser it will listen
643 for master announcements (made roughly every twelve minutes) from local
644 master browsers on other subnets and then contact them to synchronise
645 browse lists.
646 </para>
647
648 <para>
649 If you want samba to be the domain master then I suggest you also set
650 the <command>os level</command> high enough to make sure it wins elections, and set
651 <command>preferred master</command> to "yes", to get samba to force an election on
652 startup.
653 </para>
654
655 <para>
656 Note that all your servers (including samba) and clients should be
657 using a WINS server to resolve NetBIOS names.  If your clients are only
658 using broadcasting to resolve NetBIOS names, then two things will occur:
659 </para>
660
661 <orderedlist>
662 <listitem>
663         <para>
664         your local master browsers will be unable to find a domain master
665         browser, as it will only be looking on the local subnet.
666         </para>
667 </listitem>
668
669 <listitem>
670         <para>
671         if a client happens to get hold of a domain-wide browse list, and
672         a user attempts to access a host in that list, it will be unable to
673         resolve the NetBIOS name of that host.
674         </para>
675 </listitem>
676 </orderedlist>
677
678 <para>
679 If, however, both samba and your clients are using a WINS server, then:
680 </para>
681
682 <orderedlist>
683 <listitem>
684         <para>
685         your local master browsers will contact the WINS server and, as long as
686         samba has registered that it is a domain master browser with the WINS
687         server, your local master browser will receive samba's ip address
688         as its domain master browser.
689         </para>
690 </listitem>
691
692 <listitem>
693         <para>
694         when a client receives a domain-wide browse list, and a user attempts
695         to access a host in that list, it will contact the WINS server to
696         resolve the NetBIOS name of that host.  as long as that host has
697         registered its NetBIOS name with the same WINS server, the user will
698         be able to see that host.  
699         </para>
700 </listitem>
701 </orderedlist>
702
703 </sect2>
704
705 <sect2>
706 <title>Note about broadcast addresses</title>
707
708 <para>
709 If your network uses a "0" based broadcast address (for example if it
710 ends in a 0) then you will strike problems.  Windows for Workgroups
711 does not seem to support a 0's broadcast and you will probably find
712 that browsing and name lookups won't work.
713 </para>
714 </sect2>
715
716 <sect2>
717 <title>Multiple interfaces</title>
718
719 <para>
720 Samba now supports machines with multiple network interfaces.  If you
721 have multiple interfaces then you will need to use the <command>interfaces</command>
722 option in &smb.conf; to configure them. 
723 </para>
724 </sect2>
725 <sect2>
726 <title>Use of the <command>Remote Announce</command> parameter</title>
727 <para>
728 The <command>remote announce</command> parameter of 
729 <filename>smb.conf</filename> can be used to forcibly ensure
730 that all the NetBIOS names on a network get announced to a remote network.
731 The syntax of the <command>remote announce</command> parameter is:
732 <programlisting>
733         remote announce = a.b.c.d [e.f.g.h] ...
734 </programlisting>
735 _or_
736 <programlisting>
737         remote announce = a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP] ...
738 </programlisting>
739
740 where:
741 <variablelist>
742 <varlistentry><term><replaceable>a.b.c.d</replaceable> and 
743 <replaceable>e.f.g.h</replaceable></term>
744 <listitem><para>is either the LMB (Local Master Browser) IP address
745 or the broadcst address of the remote network.
746 ie: the LMB is at 192.168.1.10, or the address
747 could be given as 192.168.1.255 where the netmask
748 is assumed to be 24 bits (255.255.255.0).
749 When the remote announcement is made to the broadcast
750 address of the remote network every host will receive
751 our announcements. This is noisy and therefore
752 undesirable but may be necessary if we do NOT know
753 the IP address of the remote LMB.</para></listitem>
754 </varlistentry>
755
756 <varlistentry>
757 <term><replaceable>WORKGROUP</replaceable></term>
758 <listitem><para>is optional and can be either our own workgroup
759 or that of the remote network. If you use the
760 workgroup name of the remote network then our
761 NetBIOS machine names will end up looking like
762 they belong to that workgroup, this may cause
763 name resolution problems and should be avoided.
764 </para></listitem>
765 </varlistentry>
766 </variablelist>
767 </para>
768
769 </sect2>
770
771 <sect2>
772 <title>Use of the <command>Remote Browse Sync</command> parameter</title>
773
774 <para>
775 The <command>remote browse sync</command> parameter of 
776 <filename>smb.conf</filename> is used to announce to
777 another LMB that it must synchronise it's NetBIOS name list with our
778 Samba LMB. It works ONLY if the Samba server that has this option is
779 simultaneously the LMB on it's network segment.
780 </para>
781
782 <para>
783 The syntax of the <command>remote browse sync</command> parameter is:
784
785 <programlisting>
786 remote browse sync = <replaceable>a.b.c.d</replaceable>
787 </programlisting>
788
789 where <replaceable>a.b.c.d</replaceable> is either the IP address of the
790 remote LMB or else is the network broadcast address of the remote segment.
791 </para>
792
793 </sect2>
794
795 </sect1>
796
797 <sect1>
798 <title>WINS - The Windows Internetworking Name Server</title>
799
800 <para>
801 Use of WINS (either Samba WINS _or_ MS Windows NT Server WINS) is highly
802 recommended. Every NetBIOS machine registers it's name together with a
803 name_type value for each of of several types of service it has available.
804 eg: It registers it's name directly as a unique (the type 0x03) name.
805 It also registers it's name if it is running the lanmanager compatible
806 server service (used to make shares and printers available to other users)
807 by registering the server (the type 0x20) name.
808 </para>
809
810 <para>
811 All NetBIOS names are up to 15 characters in length. The name_type variable
812 is added to the end of the name - thus creating a 16 character name. Any
813 name that is shorter than 15 characters is padded with spaces to the 15th
814 character. ie: All NetBIOS names are 16 characters long (including the
815 name_type information).
816 </para>
817
818 <para>
819 WINS can store these 16 character names as they get registered. A client
820 that wants to log onto the network can ask the WINS server for a list
821 of all names that have registered the NetLogon service name_type. This saves
822 broadcast traffic and greatly expedites logon processing. Since broadcast
823 name resolution can not be used across network segments this type of
824 information can only be provided via WINS _or_ via statically configured
825 <filename>lmhosts</filename> files that must reside on all clients in the
826 absence of WINS.
827 </para>
828
829 <para>
830 WINS also serves the purpose of forcing browse list synchronisation by all
831 LMB's. LMB's must synchronise their browse list with the DMB (domain master
832 browser) and WINS helps the LMB to identify it's DMB. By definition this
833 will work only within a single workgroup. Note that the domain master browser
834 has NOTHING to do with what is referred to as an MS Windows NT Domain. The
835 later is a reference to a security environment while the DMB refers to the
836 master controller for browse list information only.
837 </para>
838
839 <para>
840 Use of WINS will work correctly only if EVERY client TCP/IP protocol stack
841 has been configured to use the WINS server/s. Any client that has not been
842 configured to use the WINS server will continue to use only broadcast based
843 name registration so that WINS may NEVER get to know about it. In any case,
844 machines that have not registered with a WINS server will fail name to address
845 lookup attempts by other clients and will therefore cause workstation access
846 errors.
847 </para>
848
849 <para>
850 To configure Samba as a WINS server just add 
851 <command>wins support = yes</command> to the <filename>smb.conf</filename>
852 file [globals] section.
853 </para>
854
855 <para>
856 To configure Samba to register with a WINS server just add
857 "wins server = a.b.c.d" to your smb.conf file [globals] section.
858 </para>
859
860 <important><para>
861 Never use both <command>wins support = yes</command> together
862 with <command>wins server = a.b.c.d</command>
863 particularly not using it's own IP address.
864 Specifying both will cause &nmbd; to refuse to start!
865 </para></important>
866
867 <sect2>
868 <title>Setting up a WINS server</title>
869
870 <para>
871 Either a Samba machine or a Windows NT Server machine may be set up
872 as a WINS server.  To set a Samba machine to be a WINS server you must
873 add the following option to the &smb.conf; file on the selected machine :
874 in the [globals] section add the line 
875 </para>
876
877 <para>
878 <programlisting>
879         wins support = yes
880 </programlisting>
881 </para>
882
883 <para>
884 Versions of Samba prior to 1.9.17 had this parameter default to
885 yes.  If you have any older versions of Samba on your network it is
886 strongly suggested you upgrade to a recent version, or at the very
887 least set the parameter to 'no' on all these machines.
888 </para>
889
890 <para>
891 Machines with <command>wins support = yes</command> will keep a list of 
892 all NetBIOS names registered with them, acting as a DNS for NetBIOS names.
893 </para>
894
895 <para>
896 You should set up only ONE wins server.  Do NOT set the
897 <command>wins support = yes</command> option on more than one Samba 
898 server.
899 </para>
900
901 <para>
902 To set up a Windows NT Server as a WINS server you need to set up
903 the WINS service - see your NT documentation for details.  Note that
904 Windows NT WINS Servers can replicate to each other, allowing more
905 than one to be set up in a complex subnet environment.  As Microsoft
906 refuse to document these replication protocols Samba cannot currently
907 participate in these replications.  It is possible in the future that
908 a Samba->Samba WINS replication protocol may be defined, in which
909 case more than one Samba machine could be set up as a WINS server
910 but currently only one Samba server should have the 
911 <command>wins support = yes</command> parameter set.
912 </para>
913
914 <para>
915 After the WINS server has been configured you must ensure that all
916 machines participating on the network are configured with the address
917 of this WINS server.  If your WINS server is a Samba machine, fill in
918 the Samba machine IP address in the "Primary WINS Server" field of
919 the "Control Panel->Network->Protocols->TCP->WINS Server" dialogs
920 in Windows 95 or Windows NT.  To tell a Samba server the IP address
921 of the WINS server add the following line to the [global] section of
922 all &smb.conf; files :
923 </para>
924
925 <para>
926 <programlisting>
927         wins server = &lt;name or IP address&gt;
928 </programlisting>
929 </para>
930
931 <para>
932 where &lt;name or IP address&gt; is either the DNS name of the WINS server
933 machine or its IP address.
934 </para>
935
936 <para>
937 Note that this line MUST NOT BE SET in the &smb.conf; file of the Samba
938 server acting as the WINS server itself.  If you set both the
939 <command>wins support = yes</command> option and the 
940 <command>wins server = &lt;name&gt;</command> option then
941 nmbd will fail to start.
942 </para>
943
944 <para>
945 There are two possible scenarios for setting up cross subnet browsing.
946 The first details setting up cross subnet browsing on a network containing
947 Windows 95, Samba and Windows NT machines that are not configured as
948 part of a Windows NT Domain.  The second details setting up cross subnet
949 browsing on networks that contain NT Domains.
950 </para>
951
952 </sect2>
953
954 <sect2>
955 <title>WINS Replication</title>
956
957 <para>
958 Samba-3 permits WINS replication through the use of the <filename>wrepld</filename> utility.
959 This tool is not currently capable of being used as it is still in active development.
960 As soon as this tool becomes moderately functional we will prepare man pages and enhance this
961 section of the documentation to provide usage and technical details.
962 </para>
963
964 </sect2>
965 <sect2>
966 <title>Static WINS Entries</title>
967
968 <para>
969 New to Samba-3 is a tool called <filename>winsedit</filename> that may be used to add
970 static WINS entries to the WINS database. This tool can be used also to modify entries
971 existing in the WINS database.
972 </para>
973
974 <para>
975 The development of the winsedit tool was made necessary due to the migration
976 of the older style wins.dat file into a new tdb binary backend data store.
977 </para>
978
979 </sect2>
980 </sect1>
981
982 <sect1>
983 <title>Helpful Hints</title>
984
985 <para>
986 The following hints should be carefully considered as they are stumbling points
987 for many new network administrators.
988 </para>
989
990 <sect2>
991 <title>Windows Networking Protocols</title>
992
993 <warning><para>
994 Do NOT use more than one (1) protocol on MS Windows machines
995 </para></warning>
996
997 <para>
998 A very common cause of browsing problems results from installing more than
999 one protocol on an MS Windows machine.
1000 </para>
1001
1002 <para>
1003 Every NetBIOS machine takes part in a process of electing the LMB (and DMB)
1004 every 15 minutes. A set of election criteria is used to determine the order
1005 of precidence for winning this election process. A machine running Samba or
1006 Windows NT will be biased so that the most suitable machine will predictably
1007 win and thus retain it's role.
1008 </para>
1009
1010 <para>
1011 The election process is "fought out" so to speak over every NetBIOS network
1012 interface. In the case of a Windows 9x machine that has both TCP/IP and IPX
1013 installed and has NetBIOS enabled over both protocols the election will be
1014 decided over both protocols. As often happens, if the Windows 9x machine is
1015 the only one with both protocols then the LMB may be won on the NetBIOS
1016 interface over the IPX protocol. Samba will then lose the LMB role as Windows
1017 9x will insist it knows who the LMB is. Samba will then cease to function
1018 as an LMB and thus browse list operation on all TCP/IP only machines will
1019 fail.
1020 </para>
1021
1022 <para><emphasis>
1023 Windows 95, 98, 98se, Me are referred to generically as Windows 9x.
1024 The Windows NT4, 2000, XP and 2003 use common protocols. These are roughly
1025 referred to as the WinNT family, but it should be recognised that 2000 and
1026 XP/2003 introduce new protocol extensions that cause them to behave 
1027 differently from MS Windows NT4. Generally, where a server does NOT support
1028 the newer or extended protocol, these will fall back to the NT4 protocols.
1029 </emphasis></para>
1030
1031 <para>
1032 The safest rule of all to follow it this - USE ONLY ONE PROTOCOL!
1033 </para>
1034
1035 </sect2>
1036
1037 <sect2>
1038 <title>Name Resolution Order</title>
1039
1040 <para>
1041 Resolution of NetBIOS names to IP addresses can take place using a number
1042 of methods. The only ones that can provide NetBIOS name_type information
1043 are:</para>
1044
1045 <simplelist>
1046         <member>WINS: the best tool!</member>
1047         <member>LMHOSTS: is static and hard to maintain.</member>
1048         <member>Broadcast: uses UDP and can not resolve names across remote segments.</member>
1049 </simplelist>
1050
1051 <para>
1052 Alternative means of name resolution includes:</para>
1053 <simplelist>
1054 <member>/etc/hosts: is static, hard to maintain, and lacks name_type info</member>
1055 <member>DNS: is a good choice but lacks essential name_type info.</member>
1056 </simplelist>
1057
1058 <para>
1059 Many sites want to restrict DNS lookups and want to avoid broadcast name
1060 resolution traffic. The "name resolve order" parameter is of great help here.
1061 The syntax of the "name resolve order" parameter is:
1062 <programlisting>
1063 name resolve order = wins lmhosts bcast host
1064 </programlisting>
1065 _or_
1066 <programlisting>
1067 name resolve order = wins lmhosts       (eliminates bcast and host)
1068 </programlisting>
1069 The default is:
1070 <programlisting>
1071 name  resolve order = host lmhost wins bcast
1072 </programlisting>
1073 where "host" refers the the native methods used by the Unix system
1074 to implement the gethostbyname() function call. This is normally
1075 controlled by <filename>/etc/host.conf</filename>, <filename>/etc/nsswitch.conf</filename> and <filename>/etc/resolv.conf</filename>.
1076 </para>
1077 </sect2>
1078 </sect1>
1079
1080 <sect1>
1081 <title>Technical Overview of browsing</title>
1082
1083 <para>
1084 SMB networking provides a mechanism by which clients can access a list
1085 of machines in a network, a so-called <command>browse list</command>.  This list
1086 contains machines that are ready to offer file and/or print services
1087 to other machines within the network. Thus it does not include
1088 machines which aren't currently able to do server tasks.  The browse
1089 list is heavily used by all SMB clients.  Configuration of SMB
1090 browsing has been problematic for some Samba users, hence this
1091 document.
1092 </para>
1093
1094 <para>
1095 MS Windows 2000 and later, as with Samba 3 and later, can be
1096 configured to not use NetBIOS over TCP/IP. When configured this way
1097 it is imperative that name resolution (using DNS/LDAP/ADS) be correctly
1098 configured and operative. Browsing will NOT work if name resolution
1099 from SMB machine names to IP addresses does not function correctly.
1100 </para>
1101
1102 <para>
1103 Where NetBIOS over TCP/IP is enabled use of a WINS server is highly
1104 recommended to aid the resolution of NetBIOS (SMB) names to IP addresses.
1105 WINS allows remote segment clients to obtain NetBIOS name_type information
1106 that can NOT be provided by any other means of name resolution.
1107 </para>
1108
1109 <sect2>
1110 <title>Browsing support in samba</title>
1111
1112 <para>
1113 Samba facilitates browsing.  The browsing is supported by &nmbd;
1114 and is also controlled by options in the &smb.conf; file.
1115 Samba can act as a local browse master for a workgroup and the ability
1116 to support domain logons and scripts is now available.
1117 </para>
1118
1119 <para>
1120 Samba can also act as a domain master browser for a workgroup.  This
1121 means that it will collate lists from local browse masters into a
1122 wide area network server list.  In order for browse clients to
1123 resolve the names they may find in this list, it is recommended that
1124 both samba and your clients use a WINS server.
1125 </para>
1126
1127 <para>
1128 Note that you should NOT set Samba to be the domain master for a
1129 workgroup that has the same name as an NT Domain: on each wide area
1130 network, you must only ever have one domain master browser per workgroup,
1131 regardless of whether it is NT, Samba or any other type of domain master
1132 that is providing this service.
1133 </para>
1134
1135 <note><para>
1136 Nmbd can be configured as a WINS server, but it is not
1137 necessary to specifically use samba as your WINS server.  MS Windows
1138 NT4, Server or Advanced Server 2000 or 2003 can be configured as
1139 your WINS server.  In a mixed NT/2000/2003 server and samba environment on
1140 a Wide Area Network, it is recommended that you use the Microsoft
1141 WINS server capabilities.  In a samba-only environment, it is
1142 recommended that you use one and only one Samba server as your WINS server.
1143 </para></note>
1144
1145 <para>
1146 To get browsing to work you need to run nmbd as usual, but will need
1147 to use the <command>workgroup</command> option in &smb.conf;
1148 to control what workgroup Samba becomes a part of.
1149 </para>
1150
1151 <para>
1152 Samba also has a useful option for a Samba server to offer itself for
1153 browsing on another subnet.  It is recommended that this option is only
1154 used for 'unusual' purposes: announcements over the internet, for
1155 example.  See <command>remote announce</command> in the 
1156 &smb.conf; man page.  
1157 </para>
1158 </sect2>
1159
1160 <sect2>
1161 <title>Problem resolution</title>
1162
1163 <para>
1164 If something doesn't work then hopefully the log.nmb file will help
1165 you track down the problem.  Try a debug level of 2 or 3 for finding
1166 problems. Also note that the current browse list usually gets stored
1167 in text form in a file called <filename>browse.dat</filename>.
1168 </para>
1169
1170 <para>
1171 Note that if it doesn't work for you, then you should still be able to
1172 type the server name as <filename>\\SERVER</filename> in filemanager then
1173 hit enter and filemanager should display the list of available shares.
1174 </para>
1175
1176 <para>
1177 Some people find browsing fails because they don't have the global
1178 <command>guest account</command> set to a valid account.  Remember that the
1179 IPC$ connection that lists the shares is done as guest, and thus you must
1180 have a valid guest account.
1181 </para>
1182
1183 <para><emphasis>
1184 MS Windows 2000 and upwards (as with Samba) can be configured to disallow
1185 anonymous (ie: Guest account) access to the IPC$ share. In that case, the
1186 MS Windows 2000/XP/2003 machine acting as an SMB/CIFS client will use the
1187 name of the currently logged in user to query the IPC$ share. MS Windows
1188 9X clients are not able to do this and thus will NOT be able to browse
1189 server resources.
1190 </emphasis></para>
1191
1192 <para>
1193 The other big problem people have is that their broadcast address,
1194 netmask or IP address is wrong (specified with the "interfaces" option
1195 in &smb.conf;)
1196 </para>
1197 </sect2>
1198
1199 <sect2>
1200 <title>Browsing across subnets</title>
1201 <para>
1202 Since the release of Samba 1.9.17(alpha1) Samba has been
1203 updated to enable it to support the replication of browse lists
1204 across subnet boundaries.  New code and options have been added to
1205 achieve this.  This section describes how to set this feature up
1206 in different settings.
1207 </para>
1208
1209 <para>
1210 To see browse lists that span TCP/IP subnets (ie.  networks separated
1211 by routers that don't pass broadcast traffic) you must set up at least
1212 one WINS server.  The WINS server acts as a DNS for NetBIOS names, allowing
1213 NetBIOS name to IP address translation to be done by doing a direct
1214 query of the WINS server.  This is done via a directed UDP packet on
1215 port 137 to the WINS server machine.  The reason for a WINS server is
1216 that by default, all NetBIOS name to IP address translation is done
1217 by broadcasts from the querying machine.  This means that machines
1218 on one subnet will not be able to resolve the names of machines on
1219 another subnet without using a WINS server.
1220 </para>
1221
1222 <para>
1223 Remember, for browsing across subnets to work correctly, all machines,
1224 be they Windows 95, Windows NT, or Samba servers must have the IP address
1225 of a WINS server given to them by a DHCP server, or by manual configuration 
1226 (for Win95 and WinNT, this is in the TCP/IP Properties, under Network 
1227 settings) for Samba this is in the &smb.conf; file.
1228 </para>
1229
1230 <sect3>
1231 <title>How does cross subnet browsing work ?</title>
1232
1233 <para>
1234 Cross subnet browsing is a complicated dance, containing multiple
1235 moving parts.  It has taken Microsoft several years to get the code
1236 that achieves this correct, and Samba lags behind in some areas.
1237 Samba is capable of cross subnet browsing when configured correctly.
1238 </para>
1239
1240 <para>
1241 Consider a network set up as follows :
1242 </para>
1243
1244 <para>
1245 <programlisting>
1246                                    (DMB)
1247              N1_A      N1_B        N1_C       N1_D        N1_E
1248               |          |           |          |           |
1249           -------------------------------------------------------
1250             |          subnet 1                       |
1251           +---+                                      +---+
1252           |R1 | Router 1                  Router 2   |R2 |
1253           +---+                                      +---+
1254             |                                          |
1255             |  subnet 2              subnet 3          |
1256   --------------------------       ------------------------------------
1257   |     |     |      |               |        |         |           |
1258  N2_A  N2_B  N2_C   N2_D           N3_A     N3_B      N3_C        N3_D 
1259                     (WINS)
1260 </programlisting>
1261 </para>
1262         
1263 <para>
1264 Consisting of 3 subnets (1, 2, 3) connected by two routers
1265 (R1, R2) - these do not pass broadcasts.  Subnet 1 has 5 machines
1266 on it, subnet 2 has 4 machines, subnet 3 has 4 machines.  Assume
1267 for the moment that all these machines are configured to be in the
1268 same workgroup (for simplicities sake).  Machine N1_C on subnet 1
1269 is configured as Domain Master Browser (ie.  it will collate the
1270 browse lists for the workgroup).  Machine N2_D is configured as
1271 WINS server and all the other machines are configured to register
1272 their NetBIOS names with it.
1273 </para>
1274
1275 <para>
1276 As all these machines are booted up, elections for master browsers
1277 will take place on each of the three subnets.  Assume that machine
1278 N1_C wins on subnet 1, N2_B wins on subnet 2, and N3_D wins on
1279 subnet 3 - these machines are known as local master browsers for
1280 their particular subnet.  N1_C has an advantage in winning as the
1281 local master browser on subnet 1 as it is set up as Domain Master
1282 Browser.
1283 </para>
1284
1285 <para>
1286 On each of the three networks, machines that are configured to 
1287 offer sharing services will broadcast that they are offering
1288 these services.  The local master browser on each subnet will
1289 receive these broadcasts and keep a record of the fact that
1290 the machine is offering a service.  This list of records is
1291 the basis of the browse list.  For this case, assume that
1292 all the machines are configured to offer services so all machines
1293 will be on the browse list.
1294 </para>
1295
1296 <para>
1297 For each network, the local master browser on that network is
1298 considered 'authoritative' for all the names it receives via
1299 local broadcast.  This is because a machine seen by the local
1300 master browser via a local broadcast must be on the same 
1301 network as the local master browser and thus is a 'trusted'
1302 and 'verifiable' resource.  Machines on other networks that
1303 the local master browsers learn about when collating their
1304 browse lists have not been directly seen - these records are
1305 called 'non-authoritative'.
1306 </para>
1307
1308 <para>
1309 At this point the browse lists look as follows (these are 
1310 the machines you would see in your network neighborhood if
1311 you looked in it on a particular network right now).
1312 </para>
1313
1314 <para>
1315 <programlisting>
1316 Subnet           Browse Master   List
1317 ------           -------------   ----
1318 Subnet1          N1_C            N1_A, N1_B, N1_C, N1_D, N1_E
1319
1320 Subnet2          N2_B            N2_A, N2_B, N2_C, N2_D
1321
1322 Subnet3          N3_D            N3_A, N3_B, N3_C, N3_D
1323 </programlisting>
1324 </para>
1325
1326 <para>
1327 Note that at this point all the subnets are separate, no
1328 machine is seen across any of the subnets.
1329 </para>
1330
1331 <para>
1332 Now examine subnet 2.  As soon as N2_B has become the local
1333 master browser it looks for a Domain master browser to synchronize
1334 its browse list with.  It does this by querying the WINS server
1335 (N2_D) for the IP address associated with the NetBIOS name 
1336 WORKGROUP&lt;1B&gt;.  This name was registerd by the Domain master
1337 browser (N1_C) with the WINS server as soon as it was booted.
1338 </para>
1339
1340 <para>
1341 Once N2_B knows the address of the Domain master browser it
1342 tells it that is the local master browser for subnet 2 by
1343 sending a MasterAnnouncement packet as a UDP port 138 packet.
1344 It then synchronizes with it by doing a NetServerEnum2 call.  This
1345 tells the Domain Master Browser to send it all the server
1346 names it knows about.  Once the domain master browser receives
1347 the MasterAnnouncement packet it schedules a synchronization
1348 request to the sender of that packet.  After both synchronizations
1349 are done the browse lists look like :
1350 </para>
1351
1352 <para>
1353 <programlisting>
1354 Subnet           Browse Master   List
1355 ------           -------------   ----
1356 Subnet1          N1_C            N1_A, N1_B, N1_C, N1_D, N1_E, 
1357                                  N2_A(*), N2_B(*), N2_C(*), N2_D(*)
1358
1359 Subnet2          N2_B            N2_A, N2_B, N2_C, N2_D
1360                                  N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
1361
1362 Subnet3          N3_D            N3_A, N3_B, N3_C, N3_D
1363
1364 Servers with a (*) after them are non-authoritative names.
1365 </programlisting>
1366 </para>
1367
1368 <para>
1369 At this point users looking in their network neighborhood on
1370 subnets 1 or 2 will see all the servers on both, users on
1371 subnet 3 will still only see the servers on their own subnet.
1372 </para>
1373
1374 <para>
1375 The same sequence of events that occured for N2_B now occurs
1376 for the local master browser on subnet 3 (N3_D).  When it
1377 synchronizes browse lists with the domain master browser (N1_A)
1378 it gets both the server entries on subnet 1, and those on
1379 subnet 2.  After N3_D has synchronized with N1_C and vica-versa
1380 the browse lists look like.
1381 </para>
1382
1383 <para>
1384 <programlisting>
1385 Subnet           Browse Master   List
1386 ------           -------------   ----
1387 Subnet1          N1_C            N1_A, N1_B, N1_C, N1_D, N1_E, 
1388                                  N2_A(*), N2_B(*), N2_C(*), N2_D(*),
1389                                  N3_A(*), N3_B(*), N3_C(*), N3_D(*)
1390
1391 Subnet2          N2_B            N2_A, N2_B, N2_C, N2_D
1392                                  N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
1393
1394 Subnet3          N3_D            N3_A, N3_B, N3_C, N3_D
1395                                  N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*),
1396                                  N2_A(*), N2_B(*), N2_C(*), N2_D(*)
1397
1398 Servers with a (*) after them are non-authoritative names.
1399 </programlisting>
1400 </para>
1401
1402 <para>
1403 At this point users looking in their network neighborhood on
1404 subnets 1 or 3 will see all the servers on all sunbets, users on
1405 subnet 2 will still only see the servers on subnets 1 and 2, but not 3.
1406 </para>
1407
1408 <para>
1409 Finally, the local master browser for subnet 2 (N2_B) will sync again
1410 with the domain master browser (N1_C) and will recieve the missing
1411 server entries.  Finally - and as a steady state (if no machines
1412 are removed or shut off) the browse lists will look like :
1413 </para>
1414
1415 <para>
1416 <programlisting>
1417 Subnet           Browse Master   List
1418 ------           -------------   ----
1419 Subnet1          N1_C            N1_A, N1_B, N1_C, N1_D, N1_E, 
1420                                  N2_A(*), N2_B(*), N2_C(*), N2_D(*),
1421                                  N3_A(*), N3_B(*), N3_C(*), N3_D(*)
1422
1423 Subnet2          N2_B            N2_A, N2_B, N2_C, N2_D
1424                                  N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
1425                                  N3_A(*), N3_B(*), N3_C(*), N3_D(*)
1426
1427 Subnet3          N3_D            N3_A, N3_B, N3_C, N3_D
1428                                  N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*),
1429                                  N2_A(*), N2_B(*), N2_C(*), N2_D(*)
1430         
1431 Servers with a (*) after them are non-authoritative names.
1432 </programlisting>
1433 </para>
1434
1435 <para>
1436 Synchronizations between the domain master browser and local
1437 master browsers will continue to occur, but this should be a
1438 steady state situation.
1439 </para>
1440
1441 <para>
1442 If either router R1 or R2 fails the following will occur:
1443 </para>
1444
1445 <orderedlist>
1446 <listitem>
1447         <para>
1448         Names of computers on each side of the inaccessible network fragments
1449         will be maintained for as long as 36 minutes, in the network neighbourhood
1450         lists.
1451         </para>
1452 </listitem>
1453
1454 <listitem>
1455         <para>
1456         Attempts to connect to these inaccessible computers will fail, but the
1457         names will not be removed from the network neighbourhood lists.
1458         </para>
1459 </listitem>
1460
1461 <listitem>
1462         <para>
1463         If one of the fragments is cut off from the WINS server, it will only
1464         be able to access servers on its local subnet, by using subnet-isolated
1465         broadcast NetBIOS name resolution.  The effects are similar to that of
1466         losing access to a DNS server.
1467         </para>
1468 </listitem>
1469 </orderedlist>
1470 </sect3>
1471 </sect2>
1472 </sect1>
1473
1474 <sect1>
1475 <title>Common Errors</title>
1476
1477 <para>
1478 Many questions are sked on the mailing lists regarding browsing. The majority of browsing
1479 problems originate out of incorrect configuration of NetBIOS name resolution. Some are of
1480 particular note.
1481 </para>
1482
1483 <sect2>
1484 <title>How can one flush the Samba NetBIOS name cache without restarting samba?</title>
1485
1486 <para>
1487 Sambas' nmbd process controls all browse list handling. Under normal circumstances it is
1488 safe to restart nmbd. This will effectively flush the samba NetBIOS name cache and cause it
1489 to be rebuilt. Note that this does NOT make certain that a rogue machine name will not re-appear
1490 in the browse list. When nmbd is taken out of service another machine on the network will
1491 become the browse master. This new list may still have the rogue entry in it. If you really
1492 want to clear a rogue machine from the list then every machine on the network will need to be
1493 shut down and restarted at after all machines are down. Failing a complete restart, the only
1494 other thing you can do is wait until the entry times out and is then flushed from the list.
1495 This may take a long time on some networks (months).
1496 </para>
1497
1498 </sect2>
1499 </sect1>
1500 </chapter>