1.3 Getting Familiar with an SMB Network
| Now that you have had a brief tour of Samba, let's take some time to get familiar with Samba's adopted environment: an SMB network. Networking with SMB is significantly different from working with common TCP/IP protocols such as FTP and Telnet because there are several new concepts to learn and a lot of information to cover. First, we will discuss the basic concepts behind an SMB network, followed by some Microsoft implementations of it, and finally we will show you where a Samba server can and cannot fit into the picture. 1.3.1 Understanding NetBIOSTo begin, let's step back in time. In 1984, IBM authored a simple application programming interface (API) for networking its computers, called the Network Basic Input/Output System (NetBIOS). The NetBIOS API provided a rudimentary design for an application to connect and share data with other computers. It's helpful to think of the NetBIOS API as networking extensions to the standard BIOS API calls. The BIOS contains low-level code for performing filesystem operations on the local computer. NetBIOS originally had to exchange instructions with computers across IBM PC or Token Ring networks. It therefore required a low-level transport protocol to carry its requests from one computer to the next . In late 1985, IBM released one such protocol, which it merged with the NetBIOS API to become the NetBIOS Extended User Interface ( NetBEUI ). NetBEUI was designed for small LANs, and it let each computer claim a name (up to 15 characters ) that wasn't already in use on the network. By a "small LAN," we mean fewer than 255 nodes on the network ”which was considered a generous number in 1985! The NetBEUI protocol was very popular with networking applications, including those running under Windows for Workgroups. Later, implementations of NetBIOS over Novell's IPX networking protocols also emerged, which competed with NetBEUI. However, the networking protocols of choice for the burgeoning Internet community were TCP/IP and UDP/IP, and implementing the NetBIOS APIs over those protocols soon became a necessity. Recall that TCP/IP uses numbers to represent computer addresses (192.168.220.100, for instance) while NetBIOS uses only names . This was a major issue when trying to mesh the two protocols together. In 1987, the IETF published standardization documents, titled RFC 1001 and 1002, that outlined how NetBIOS would work over a TCP/UDP network. This set of documents still governs each implementation that exists today, including those provided by Microsoft with its Windows operating systems, as well as the Samba suite. Since then, the standard that this document governs has become known as NetBIOS over TCP/IP , or NBT for short. [3]
The NBT standard (RFC 1001/1002) currently outlines a trio of services on a network:
The name service solves the name-to-address problem mentioned earlier; it allows each computer to declare a specific name on the network that can be translated to a machine-readable IP address, much like today's Domain Name System (DNS) on the Internet. The datagram and session services are both secondary communication protocols used to transmit data back and forth from NetBIOS computers across the network. 1.3.2 Getting a NameIn the NetBIOS world, when each computer comes online, it wants to claim a name for itself; this is called name registration . However, no two computers in the same workgroup should be able to claim the same name; this would cause endless confusion for any computer that wanted to communicate with either of them. There are two different approaches to ensuring that this doesn't happen:
Figure 1-8 illustrates a (failed) name registration, with and without an NBNS. Figure 1-8. Broadcast versus NBNS name registration As mentioned earlier, there must be a way to resolve a NetBIOS name to a specific IP address; this is known as name resolution . There are two different approaches with NBT here as well:
Figure 1-9 illustrates the two types of name resolution. Figure 1-9. Broadcast versus NBNS name resolution As you might expect, having an NBNS on your network can help out tremendously. To see exactly why, let's look at the broadcast method. Here, when a client computer boots, it will broadcast a message declaring that it wishes to register a specified NetBIOS name as its own. If nobody objects to the use of the name, it keeps the name. On the other hand, if another computer on the local subnet is currently using the requested name, it will send a message back to the requesting client that the name is already taken. This is known as defending the hostname. This type of system comes in handy when one client has unexpectedly dropped off the network ”another can take its name unchallenged ”but it does incur an inordinate amount of traffic on the network for something as simple as name registration. With an NBNS, the same thing occurs, except the communication is confined to the requesting computer and the NBNS. No broadcasting occurs when the computer wishes to register the name; the registration message is simply sent directly from the client to the NBNS, and the NBNS replies regardless of whether the name is already taken. This is known as point-to-point communication , and it is often beneficial on networks with more than one subnet. This is because routers are generally configured to block incoming packets that are broadcast to all computers in the subnet. The same principles apply to name resolution. Without an NBNS, NetBIOS name resolution would also be done with a broadcast mechanism. All request packets would be sent to each computer in the network, with the hope that one computer that might be affected will respond directly back to the computer that asked. Using an NBNS and point-to-point communication for this purpose is far less taxing on the network than flooding the network with broadcasts for every name-resolution request. It can be argued that broadcast packets do not cause significant problems in modern, high-bandwidth networks of hosts with fast CPUs, if only a small number of hosts are on the network, or the demand for bandwidth is low. There are certainly cases where this is true; however, our advice throughout this book is to avoid relying on broadcasts as much as possible. This is a good rule to follow for large, busy networks, and if you follow our advice when configuring a small network, your network will be able to grow without encountering problems later on that might be difficult to diagnose. 1.3.3 Node TypesHow can you tell what strategy each client on your network will use when performing name registration and resolution? Each computer on an NBT network earns one of the following designations, depending on how it handles name registration and resolution: b-node, p-node, m-node, and h-node. The behaviors of each type of node are summarized in Table 1-1. Table 1-1. NetBIOS node types
In the case of Windows clients , you will usually find them listed as h-nodes or hybrid nodes. The first three node types appear in RFC 1001/1002, and h-nodes were invented later by Microsoft, as a more fault-tolerant method. You can find the node type of a Windows 95/98/Me computer by running the winipcfg command from the Start 1.3.4 What's in a Name?The names NetBIOS uses are quite different from the DNS hostnames you might be familiar with. First, NetBIOS names exist in a flat namespace. In other words, there are no hierarchical levels, such as in oreilly.com (two levels) or ftp .samba.org (three levels). NetBIOS names consist of a single unique string such as navaho or hopi within each workgroup or domain. Second, NetBIOS names are allowed to be only 15 characters and can consist only of standard alphanumeric characters (a-z, A-Z, 0-9) and the following: ! @ # $ % ^ & ( ) - ' { } . ~ Although you are allowed to use a period (.) in a NetBIOS name, we recommend against it because those names are not guaranteed to work in future versions of NBT. It's not a coincidence that all valid DNS names are also valid NetBIOS names. In fact, the unqualified DNS name for a Samba server is often reused as its NetBIOS name. For example, if you had a system with a hostname of mixtec.ora.com , its NetBIOS name would likely be MIXTEC (followed by 9 spaces). 1.3.4.1 Resource names and typesWith NetBIOS, a computer not only advertises its presence, but also tells others what types of services it offers. For example, mixtec can indicate that it's not just a workstation, but that it's also a file server and can receive Windows Messenger messages. This is done by adding a 16th byte to the end of the machine (resource) name, called the resource type , and registering the name multiple times, once for each service that it offers. See Figure 1-10. Figure 1-10. The structure of NetBIOS names The 1-byte resource type indicates a unique service that the named computer provides. In this book, you will often see the resource type shown in angled brackets (<>) after the NetBIOS name, such as: MIXTEC<00> You can see which names are registered for a particular NBT computer using the Windows command-line nbtstat utility. Because these services are unique (i.e., there cannot be more than one registered), you will see them listed as type UNIQUE in the output. For example, the following partial output describes the toltec server: C:\> nbtstat -a toltec NetBIOS Remote Machine Name Table Name Type Status --------------------------------------------- TOLTEC <00> UNIQUE Registered TOLTEC <03> UNIQUE Registered TOLTEC <20> UNIQUE Registered ... This says the server has registered the NetBIOS name toltec as a machine (computer) name, as a recipient of messages from the Windows Messenger service, and as a file server. Some possible attributes a name can have are listed in Table 1-2. Table 1-2. NetBIOS unique resource types
1.3.4.2 Group names and typesSMB also uses the concept of groups, with which computers can register themselves . Earlier we mentioned that the computers in our example belonged to a workgroup , which is a partition of computers on the same network. For example, a business might very easily have an ACCOUNTING and a SALES workgroup, each with different servers and printers. In the Windows world, a workgroup and an SMB group are the same thing. Continuing our nbtstat example, the toltec Samba server is also a member of the METRAN workgroup (the GROUP attribute hex 00) and will participate in elections for the browse master (GROUP attribute 1E). Here is the remainder of the nbtstat output: NetBIOS Remote Machine Name Table Name Type Status --------------------------------------------- METRAN <00> GROUP Registered METRAN <1E> GROUP Registered ..__MSBROWSE__.<01> GROUP Registered The possible group attributes a computer can have are illustrated in Table 1-3. More information is available in Windows NT in a Nutshell by Eric Pearce, also published by O'Reilly. Table 1-3. NetBIOS group resource types
The final entry, _ _ MSBROWSE _ _ , is used to announce a group to other master browsers. The nonprinting characters in the name show up as dots in an nbtstat printout. Don't worry if you don't understand all of the resource or group types. Some of them you will not need with Samba, and others you will pick up as you move through the rest of the chapter. The important thing to remember here is the logistics of the naming mechanism. 1.3.4.3 Scope IDIn the dark ages of SMB networking before NetBIOS groups were introduced, you could use a very primitive method to isolate groups of computers from the rest of the network. Each SMB packet contains a field called the scope ID , with the idea being that systems on the network could be configured to accept only packets with a scope ID matching that of their configuration. This feature was hardly ever used and unfortunately lingers in modern implementations. Some of the utilities included in the Samba distribution allow the scope ID to be set. Setting the scope ID in a network is likely to cause problems, and we are mentioning scope ID only so that you will not be confused by it when you later encounter it in various places. 1.3.5 Datagrams and SessionsAt this point, let's digress to discuss the responsibility of NBT: to provide connection services between two NetBIOS computers. NBT offers two services: the session service and the datagram service . Understanding how these two services work is not essential to using Samba, but it does give you an idea of how NBT works and how to troubleshoot Samba when it doesn't work. The datagram service has no stable connection between computers. Packets of data are simply sent or broadcast from one computer to another, without regard to the order in which they arrive at the destination, or even if they arrive at all. The use of datagrams requires less processing overhead than sessions, although the reliability of the connection can suffer. Datagrams, therefore, are used for quickly sending nonvital blocks of data to one or more computers. The datagram service communicates using the simple primitives shown in Table 1-4. Table 1-4. Datagram primitives
The session service is more complex. Sessions are a communication method that, in theory, offers the ability to detect problematic or inoperable connections between two NetBIOS applications. It helps to think of an NBT session as being similar to a telephone call, an analogy that obviously influenced the design of the CIFS standard. Once the connection is made, it remains open throughout the duration of the conversation, each side knows who the caller and the called computer are, and each can communicate with the simple primitives shown in Table 1-5. Table 1-5. Session primitives
Sessions are the backbone of resource sharing on an NBT network. They are typically used for establishing stable connections from client computers to disk or printer shares on a server. The client "calls" the server and starts trading information such as which files it wishes to open, which data it wishes to exchange, etc. These calls can last a long time ”hours, even days ”and all of this occurs within the context of a single connection. If there is an error, the session software (TCP) will retransmit until the data is received properly, unlike the "punt-and-pray" approach of the datagram service (UDP). In truth, while sessions are supposed to handle problematic communications, they sometimes don't. If the connection is interrupted , session information that is open between the two computers might become invalid. If that happens, the only way to regain the session information is for the same two computers to call each other again and start over. If you want more information on each service, we recommend you look at RFC 1001. However, there are two important things to remember here:
|
Run dialog (or from an MS-DOS prompt) and clicking the More Info >> button. On Windows NT/2000/XP, you can use the ipconfig /all command in a command-prompt window. In either case, search for the line that says Node Type . 
EAN: 2147483647
Pages: 475