docs/textdocs/BROWSING-Config.txt

   1 !==
   2 !== BROWSING-Config.txt for Samba release 2.2.0-alpha3 24 Mar 2001
   3 !==
   4 Date:           July 5, 1998
   5 Contributor:    John H Terpstra <jht@samba.org>
   6
   7 Subject:        Cross Subnet Browsing / Cross Workgroup Browsing
   8 ===============================================================================
   9
  10 OVERVIEW:
  11 =========
  12
  13 This document should be read in conjunction with BROWSING.txt and may
  14 be taken as the fast track guide to implementing browsing across subnets
  15 and / or across workgroups (or domains). WINS is the best tool for resolution
  16 of NetBIOS names to IP addesses. WINS is NOT involved in browse list handling
  17 except by way of name to address mapping.
  18
  19
  20 DISCUSSION:
  21 ===========
  22
  23 Firstly, all MS Windows networking is based on SMB (Server Message
  24 Block) based messaging. SMB messaging is implemented using NetBIOS. Samba
  25 implements NetBIOS by encapsulating it over TCP/IP. MS Windows products can
  26 do likewise. NetBIOS based networking uses broadcast messaging to affect
  27 browse list management. When running NetBIOS over TCP/IP this uses UDP
  28 based messaging. UDP messages can be broadcast or unicast.
  29
  30 Normally, only unicast UDP messaging can be forwarded by routers. The
  31 "remote announce" parameter to smb.conf helps to project browse announcements
  32 to remote network segments via unicast UDP. Similarly, the "remote browse sync"
  33 parameter of smb.conf implements browse list collation using unicast UDP.
  34
  35 Secondly, in those networks where Samba is the only SMB server technology
  36 wherever possible nmbd should be configured on one (1) machine as the WINS
  37 server. This makes it easy to manage the browsing environment. If each network
  38 segment is configured with it's own Samba WINS server, then the only way to
  39 get cross segment browsing to work is by using the "remote announce" and
  40 the "remote browse sync" parameters to your smb.conf file.
  41
  42 If only one WINS server is used then the use of the "remote announce" and the
  43 "remote browse sync" parameters should NOT be necessary.
  44
  45 Samba WINS does not support MS-WINS replication. This means that when setting up
  46 Samba as a WINS server there must only be one nmbd configured as a WINS server
  47 on the network. Some sites have used multiple Samba WINS servers for redundancy
  48 (one server per subnet) and then used "remote browse sync" and "remote announce"
  49 to affect browse list collation across all segments. Note that this means
  50 clients will only resolve local names, and must be configured to use DNS to
  51 resolve names on other subnets in order to resolve the IP addresses of the
  52 servers they can see on other subnets. This setup is not recommended, but is
  53 mentioned as a practical consideration (ie: an 'if all else fails' scenario).
  54
  55 Lastly, take note that browse lists are a collection of unreliable broadcast
  56 messages that are repeated at intervals of not more than 15 minutes. This means
  57 that it will take time to establish a browse list and it can take up to 45
  58 minutes to stabilise, particularly across network segments.
  59
  60
  61 A) Use of the "Remote Announce" parameter
  62 ------------------------------------------
  63 The "remote announce" parameter of smb.conf can be used to forcibly ensure
  64 that all the NetBIOS names on a network get announced to a remote network.
  65 The syntax of the "remote announce" parameter is:
  66
  67         remote announce = a.b.c.d [e.f.g.h] ...
  68 _or_
  69         remote announce = a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP] ...
  70
  71 where:
  72         a.b.c.d:        is either the LMB (Local Master Browser) IP address
  73         e.f.g.h:        or the broadcst address of the remote network.
  74                         ie: the LMB is at 192.168.1.10, or the address
  75                         could be given as 192.168.1.255 where the netmask
  76                         is assumed to be 24 bits (255.255.255.0).
  77                         When the remote announcement is made to the broadcast
  78                         address of the remote network every host will receive
  79                         our announcements. This is noisy and therefore
  80                         undesirable but may be necessary if we do NOT know
  81                         the IP address of the remote LMB.
  82
  83         WORKGROUP:      is optional and can be either our own workgroup
  84                         or that of the remote network. If you use the
  85                         workgroup name of the remote network then our
  86                         NetBIOS machine names will end up looking like
  87                         they belong to that workgroup, this may cause
  88                         name resolution problems and should be avoided.
  89
  90
  91 B) Use of the "Remote Browse Sync" parameter
  92 --------------------------------------------
  93
  94 The "remote browse sync" parameter of smb.conf is used to announce to
  95 another LMB that it must synchronise it's NetBIOS name list with our
  96 Samba LMB. It works ONLY if the Samba server that has this option is
  97 simultaneously the LMB on it's network segment.
  98
  99 The syntax of the "remote browse  sync" parameter is:
 100
 101         remote browse sync = a.b.c.d
 102
 103 where:
 104         a.b.c.d:        is either the IP address of the remote LMB or else
 105                         is the network broadcast address of the remote segment.
 106
 107
 108 C) Use of WINS
 109 --------------
 110
 111 Use of WINS (either Samba WINS _or_ MS Windows NT Server WINS) is highly
 112 recommended. Every NetBIOS machine registers it's name together with a
 113 name_type value for each of of several types of service it has available.
 114 eg: It registers it's name directly as a unique (the type 0x03) name.
 115 It also registers it's name if it is running the lanmanager compatible
 116 server service (used to make shares and printers available to other users)
 117 by registering the server (the type 0x20) name.
 118
 119 All NetBIOS names are up to 15 characters in length. The name_type variable
 120 is added to the end of the name - thus creating a 16 character name. Any
 121 name that is shorter than 15 characters is padded with spaces to the 15th
 122 character. ie: All NetBIOS names are 16 characters long (including the
 123 name_type information).
 124
 125 WINS can store these 16 character names as they get registered. A client
 126 that wants to log onto the network can ask the WINS server for a list
 127 of all names that have registered the NetLogon service name_type. This saves
 128 broadcast traffic and greatly expedites logon processing. Since broadcast
 129 name resolution can not be used across network segments this type of
 130 information can only be provided via WINS _or_ via statically configured
 131 "lmhosts" files that must reside on all clients in the absence of WINS.
 132
 133 WINS also serves the purpose of forcing browse list synchronisation by all
 134 LMB's. LMB's must synchronise their browse list with the DMB (domain master
 135 browser) and WINS helps the LMB to identify it's DMB. By definition this
 136 will work only within a single workgroup. Note that the domain master browser
 137 has NOTHING to do with what is referred to as an MS Windows NT Domain. The
 138 later is a reference to a security environment while the DMB refers to the
 139 master controller for browse list information only.
 140
 141 Use of WINS will work correctly only if EVERY client TCP/IP protocol stack
 142 has been configured to use the WINS server/s. Any client that has not been
 143 configured to use the WINS server will continue to use only broadcast based
 144 name registration so that WINS may NEVER get to know about it. In any case,
 145 machines that have not registered with a WINS server will fail name to address
 146 lookup attempts by other clients and will therefore cause workstation access
 147 errors.
 148
 149 To configure Samba as a WINS server just add "wins support = yes" to the
 150 smb.conf file [globals] section.
 151
 152 To configure Samba to register with a WINS server just add
 153 "wins server = a.b.c.d" to your smb.conf file [globals] section.
 154
 155 DO NOT EVER use both "wins support = yes" together with "wins server = a.b.c.d"
 156 particularly not using it's own IP address.
 157
 158
 159 D) Do NOT use more than one (1) protocol on MS Windows machines
 160 ---------------------------------------------------------------
 161
 162 A very common cause of browsing problems results from installing more than
 163 one protocol on an MS Windows machine.
 164
 165 Every NetBIOS machine take part in a process of electing the LMB (and DMB)
 166 every 15 minutes. A set of election criteria is used to determine the order
 167 of precidence for winning this election process. A machine running Samba or
 168 Windows NT will be biased so that the most suitable machine will predictably
 169 win and thus retain it's role.
 170
 171 The election process is "fought out" so to speak over every NetBIOS network
 172 interface. In the case of a Windows 9x machine that has both TCP/IP and IPX
 173 installed and has NetBIOS enabled over both protocols the election will be
 174 decided over both protocols. As often happens, if the Windows 9x machine is
 175 the only one with both protocols then the LMB may be won on the NetBIOS
 176 interface over the IPX protocol. Samba will then lose the LMB role as Windows
 177 9x will insist it knows who the LMB is. Samba will then cease to function
 178 as an LMB and thus browse list operation on all TCP/IP only machines will
 179 fail.
 180
 181 The safest rule of all to follow it this - USE ONLY ONE PROTOCOL!
 182
 183
 184 E) Name Resolution Order
 185 ========================
 186
 187 Resolution of NetBIOS names to IP addresses can take place using a number
 188 of methods. The only ones that can provide NetBIOS name_type information
 189 are:
 190         WINS:           the best tool!
 191         LMHOSTS:        is static and hard to maintain.
 192         Broadcast:      uses UDP and can not resolve names across
 193                         remote segments.
 194
 195 Alternative means of name resolution includes:
 196         /etc/hosts:     is static, hard to maintain, and lacks name_type info.
 197         DNS:            is a good choice but lacks essential name_type info.
 198
 199 Many sites want to restrict DNS lookups and want to avoid broadcast name
 200 resolution traffic. The "name resolve order" parameter is of great help here.
 201 The syntax of the "name resolve order" parameter is:
 202
 203         name resolve order = wins lmhosts bcast host
 204 _or_
 205         name resolve order = wins lmhosts       (eliminates bcast and host)
 206
 207 the default is:
 208         name  resolve order = host lmhost wins bcast
 209
 210 where:
 211         "host" refers the the native methods used by the Unix system
 212         to implement the gethostbyname() function call. This is normally
 213         controlled by:
 214                 /etc/host.conf
 215                 /etc/nsswitch.conf
 216                 /etc/resolv.conf
 217
 218 ===============================================================================