Microsoft Peer-To-Peer Networking

How it Works, and Why We Don't Support It

Overview

Back in 1994, we started to have network outages around campus caused by too much traffic over portions of our network infrastructure. At that time, we tracked the problem down to the excessive broadcast traffic generated by Microsoft Peer-To-Peer Networking in Win95 and WinNT4.

While evaluating MS Networking, and hoping to find a way to reduce the amount of broadcast traffic generated by the clients, we came to the unfortunate conclusion that MS Networking is, in a campus environment, inherently unsupportable. We can do many things to try and keep it working correctly, but when a problem arises, we are unable to actually locate the cause.

This paper gives a basic overview of Microsoft Networking, describes what we do to try and make it work while not causing too much network traffic, and why we are unable to actually support it.

How Browsing Works

Microsoft Networking is a four part system. Any host on the network may act in any or all of these roles.

Clients: Clients are hosts that browse different workgroups and view shared resources on servers
Servers: Servers are hosts that offer shared resources for others to use,
Browsers: Browsers are hosts that help maintain the list of available servers on the network on a per workgroup basis.
Name Servers (WINS): The WINS servers are hosts that turn the NetBIOS name (IE: carnegie_net) into an IP address (IE: 128.2.35.60)

Microsoft Networking Servers

[NTRES], Page 142

Microsoft Networking servers are host that are sharing resources -- disks, printers, etc. Once a Microsoft Networking Server boots, it periodically announces itself to the Local Master Browser (LMB) by sending a directed datagram to the LMB on the network. These announcements are initially sent every minute, with the inter-announcement delay increasing until it hits ~12 minutes. The LMB keeps the server's name in the browse list until the server fails to send an announcement for 3 intervals. It could take up to 36 minutes for a host to be removed from the browse list once it is turned off.

Observed Behavior

[NBT DUMP]

However, in practice, this does not appear to be the case. When a machine boots on a subnet that has a LMB, it does not send directed datagrams to the LMB in order to keep it's registration active. Instead, the client sends a subnet broadcast.

Microsoft Networking Clients

Microsoft Networking clients are, for the most part, relatively quiet. Clients register a collection of names with the WINS servers. These names include the hostname (IE: KRYTEN), the workgroup name (IE: CAMPUS), and the user's identity (IE: RYAN). Each registered name is followed by one byte that signifies what the registered name is to be used for.

Client name registration is done via unicast datagrams to the WINS servers.

Name Servers (WINS)

The Microsoft Networking Name Servers (WINS) are hosts that perform NetBIOS server name to IP address mappings. All MS networking hosts (clients and servers) register their names and IP address with WINS. Clients use WINS to determine the IP address for a given server name.

WINS lookups are performed via unicast datagrams.

WINS replication is not within the scope of this paper.

Browsers

All of the magic behind Microsoft Networking occurs with the browsers. These are the machines that collect information about what servers are on the network sharing resources, and hand that information out to any client that asks. The browse hierarchy is split up into four types of computers: the Workgroup Browse Master (WBM), the Local Master Browsers (LMB), the Local Backup Browsers (LBB), and Non-Browsers (NB).

Local Master Browses are responsible for gathering host announcements from all machines on the local subnet and propagating this information back to the Workgroup Browse Master. These hosts are also responsible for announcing what workgroups are already handled (IE: browsers available) on the local subnet.

Local Backup Browsers keep a copy of the entire browse list (which is gathered from the Local Master Browser). They refresh this list from the LMB, and hand it out to any clients that request it. They are also supposed to be next in line to become the LMB if the current one goes away.

Non-Browsers are hosts that have been configured to never, ever become part of the browse hierarchy. By default, all Microsoft Operating Systems from Win95 on are capable of becoming a browser. Prior OSs are not, unless extra software is installed.

The Workgroup Browse Master is the master browser on the network that has the responsibility of collating all of the announcements forwarded to it by all of the LMBs, and then propagating the full list to all of the LMBs. These machines are responsible for making sure that the entire network is browsable, even across routed subnets.

How Does Browsing Work

To understand how browsing works, let's look at the worst-case example. In this example, a Win95 machine in the CAMPUS workgroup wishes to browse the HEINZ workgroup. However, nothing on the local subnet is in the HEINZ workgroup, so there is no LMB available for the HEINZ workgroup.

[95 BROWSE OTHER]

The first thing the client must do is determine what the backup browsers for the HEINZ workgroup are. This is done via a subnet broadcast, which will be answered by the LMB for the HEINZ workgroup. Since there is no LMB for this workgroup, the request goes unanswered.

Having received no reply, the client then asks the WINS servers for the Domain Controller for the HEINZ workgroup. If a Domain Controller exists for the workgroup (indicating there is also a domain with the same name), the domain controller is asked for the list of Backup Browsers for the domain. If no domain controller is present, the client performs an RPC via the local master browser to determine the backup browser list.

At this point, the client knows the list of backup browsers for the workgroup. The backup browser list is of the main Workgroup Backup Browsers, not a local set. Now the client picks one at random, uses WINS to resolve the name into an IP address, contacts the browser and downloads the browse list.

Overall Problems with Microsoft Networking

The entire browser hierarchy is dynamic, and MS Networking hosts on that subnet are elected LMBs and LBBs based on host attributes such as what OS it is running, whether or not it already has browse information (currently a LMB or LBB), uptime, etc. In the absence of any machines capable of being a LMB, servers on the local subnet will not be able to share files and printers with other hosts on the network. Clients will still be able to browse the workgroup.

Unable to Guarantee Existence of Local Master Browser

However, the implementation of the browse hierarchy within Microsoft Networking is both it's strength and it's weakness. While it is fully dynamic, it relies on a set of hosts that are up most, if not all, of the time. In a subnet such as our dorms, this is not the case. We can't guarantee that there is a host on every subnet that will be on all of the time, so the LMB may move around from day to day. At some point, there may be no machines on the local subnet that are actually on, and thus no LMB available when a machine does boot.

Election Criteria Unfair in Heterogenous Network

On top of that, the collection of machines in our dorms is heterogenous. With it's collection of Win95, Win98, NT4 Workstation, and NT4 Server, browser elections may not always choose the 'best' host. For example, if there is an active LMB, an NT4 Server (with MaintainServerList set to Yes), and some Win95 machines on the subnet, and an election is forced, the NT Server will win, even though it may have no existing browse information.

Resolution of a Workgroup with No Associated Domain

When a client attempts to browse a workgroup for which there is no associated domain; and there are no hosts in that workgroup on the local subnet, entirely too much traffic is generated.

First, the client performs a subnet broadcast to find the local master browser for the specified workgroup. When that fails, it asks the WINS server for the Domain Controller for the specified workgroup. This also fails, as the workgroup is not a domain.

Next, instead of asking about the Workgroup Master Browser for the domain, the client proceeds to repeat the first two queries, along with DNS queries that are syntacticly incorrect. These DNS queries go on for quite a while. Finally, the client gives up completely, and performs an RPC with the LMB, which results in the client fetching the appropriate list.

If the client had asked the WINS server for the Workgroup Master Browser after the first two queries failed, the amount of traffic would be kept at a minimum, and everything would work well.

Lack of Debugging Tools

The tools available for debugging MS Networking problems are almost nonexistent. At this time, the only utilities available to determine the existing LMB / LBBs are browstat and browmon, available on the NT Resources Kit CDROM. These only work under NT.

When tracking down what's happening on a local subnet, there are no packet sniffers that do an adequate job of dumping data in real-time. Microsoft's Network Monitor does provide very detailed information about each packet, but it does not allow you to easily limit what you are gathering, has a limited buffer size, and does not allow you to watch what's happening as you capture it.

Additionally, there is no documentation available that discusses how elections actually occur or how a workgroups browse list is transferred. Without this information, even if a detailed packet dump is gathered, the information may not be as helpful as it would if you knew exactly what should be going on.

Some of the tools that we would find useful in debugging these problems include:

Display Backup Browser IP Addresses: Find the list of backup browsers for a given workgroup/domain, and then resolve them into IP addresses.
Resolve NetBIOS name via WINS: SAMBA provides software that does NetBIOS name resolution via subnet broadcasts. However, it doesn't use WINS.
List Names and IP addresses of hosts in a workgroup: Grab a workgroups membership list from one of the appropriate browsers, and then display the list of hosts along with their IP addresses.

What We Do To Help

[DHCP OPTS]

On our campus, we provide two WINS servers to help alleviate the amount of broadcast traffic for NetBIOS name to IP address lookups. The WINS server addresses are given out to all clients via DHCP. (DHCP Tag 44, RFC 2132)

Via DHCP, we also set all MS Networking Client types to P-Node, which should make sure they do not use broadcasts to resolve NetBIOS names. (DHCP Tag 46, RFC 2132)

One other thing we do to help is announce what services are available on other platforms (Linux, Solaris, etc.) which may cause problems with MS Networking. When we locate such a service, we will either provide documentation on how to configure it so that it does not cause a problem with our MS Networking setup, or (if it's really mis-behaved), remove it from our network entirely.

At this time, the only service we've found that interacts with MS Networking in a poor way is Samba. It is possible to configure Samba to become a browse master, which will cause problems if the machine is turned off, etc. We have also seen SAMBA machines become backup browsers, but refuse to ever hand out the browse list due to access control lists. This has the capability of breaking browsing for the entire workgroup. (Our configuration instructions are at http://www.net.cmu.edu/docs/services/ip/samba.html.)

Detailed Packet Dumps

Here are some other detailed packet dumps showing how various Microsoft Networking hosts boot, browse the network neighborhood, and open shares listed in the network neighborhood.

Windows 95

Bibliography

NTRES: Windows NT Server Networking Guide
DHCP OPTS: DHCP Options and BOOTP Vendor Extension (RFC 2132)
NBT DUMP: NetBios Port Packet Dump
95 BROWSE OTHER: Packet Dump of Win95 Browsing a Different Domain

Ryan Troll ryan+@andrew.cmu.edu
September 1998