OIT filters NetBIOS over TCP/IP broadcast traffic on wireless networks operated by OIT.
NetBIOS over TCP/IP (a.k.a. NBT) is an important protocol supporting critical applications on the campus network; however, it is no longer necessary for it to use broadcasting to provide the needed functionality.
We filter this traffic because we have found that it is responsible for a significant volume of the overall broadcast traffic on the network, as well as triggering spikes in broadcast traffic. Each of these degrade network services provided by OIT.
We installed the filter in several stages during mid-October 2010 - early-November 2010.
NetBIOS over TCP/IP is a network protocol used to provide name registration and resolution services, session (connection-oriented) service, and a datagram distribution (connectionless) service. Microsoft products make extensive use of NetBIOS over TCP/IP for a variety of purposes, including (for example) printing and file sharing. A variety of other platforms that wish to interoperate with these Microsoft environments also support NetBIOS over TCP/IP.
The name registration and resolution services may use IP broadcast to register and resolve names. Or it may instead use IP unicast to talk to a server to that provides name registration and resolution service. The latter approach provides the necessary service without relying on broadcasting.
The datagram distribution service also may make use of IP broadcast to communicate with a set of NetBIOS devices which happen to reside on the same IP subnet.
OIT operates Active Directory and WINS servers for Princeton University. Among their varied services, the Active Directory and WINS servers allow NetBIOS over TCP/IP devices to perform NetBIOS name registration and resolution via IP unicast traffic. This means that it is not necessary for NetBIOS on the campus network to use IP broadcast traffic to perform NetBIOS name registration and resolution.
The use of IP broadcast to browse/discover NetBIOS services (such as printers or shares) was problematic. To discover services outside its current IP subnet, the client relied on another customer's workstation on the same subnet as the client. That other customer's workstation acted as a master browser for the subnet, essentially proxying information to the WINS server via IP unicast. As that critical functionality was running on someone else's workstation, when that workstation went offline, the functionality had to quickly migrate to someone else's workstation. This made the service less reliable. It also generated significant additional broadcast traffic (a traffic spike) each time it happened. This was a frequent occurrence on networks with many devices connecting and disconnecting often, such as our wireless networks.
Using IP broadcast to browse/discover NetBIOS services is no longer appropriate, because OIT operates Active Directory and WINS servers for Princeton University, and because OIT provides a variety of services at well-known DNS hostnames.
NetBIOS's use of IP broadcast does not scale well to large networks. As the number of devices speaking NetBIOS over TCP/IP on a single network grows, the volume of this broadcast traffic also grows. Such broadcast traffic is flooded to all devices on a single network.
We found that 20-25% (typically 23%) of all broadcast/multicast traffic on our wireless networks was NetBIOS over TCP/IP broadcasts. And this traffic in turn triggered additional ARP broadcast traffic; that accounted for an additional 25% of the broadcast traffic on our wireless networks. Taken together, this filter reduced broadcast/multicast traffic on our wireless networks by 45-50% (typically 48%).
NetBIOS's use of IP broadcast also results in frequent traffic spikes, as the protocol periodically generates traffic that require many NetBIOS devices to perform broadcast simultaneously. Such broadcast spikes also degrade service.
Broadcast traffic is a vital part of the network; its existance is not inherently bad. However, when there are high rates of broadcast traffic, this presents a problem. The network is forced to flood broadcast traffic to all clients And each client that receives the traffic is forced to examine these packets to decide what to do with each packet. Even when the actual bit rate for broadcast traffic may miniscule relative to the University's network capacity, our experience is that when the packet rate of such traffic gets too large, individual network-attached devices must consume excessive resources handling these packets. Workstations may be become unresponsive; network infrastructure may stop responding to management requests. Any networks with constrained bandwidth (e.g. wireless) may perform poorly. Eventually workstations become unusable and the network becomes unmanageable. As a result, we must take care that broadcast traffic on the network does not grow unecessarily large.
As the number of devices on a single IP subnet grows, and as the number of those devices speaking NetBIOS over TCP/IP grows, the volume of broadcast traffic on the network grows to a point that adversely affects network service for all devices on that network. This problem doesn't arise in the environment in which NetBIOS was originally designed (a small network), since that environment doesn't have many devices; it is a problem if many devices attached to single network speak NetBIOS over TCP/IP.
This in fact is the situation we find at Princeton University. All Windows devices speak NetBIOS over TCP/IP. Mac OS X devices have also spoken NetBIOS over TCP/IP for a number of years. This results in excessive brodcast traffic on significant portions of the campus network.
Prior to the availability of OIT WINS Service on the campus network, NetBIOS over TCP/IP devices had little choice but to use broadcast to provide NetBIOS functionality. However, OIT has for years provided OIT WINS Service (later subsumed by OIT Active Directory Service). That service provides the necessary naming functionality for NetBIOS over TCP/IP devices, so those devices no longer need to rely on IP broadcast. And over the years, other services have been introduced which provide critical services using well-known DNS hostnames, eliminating the need for browsing to find services. However, NetBIOS devices continue to try to use IP broadcast, often in addition to using IP unicast.
The traffic is filtered at the campus network's core Ethernet switches; all buildings (or groups of buildings) are attached to these core switches. It's installed in such a way as to apply only to those networks supporting wireless services provided by OIT. This causes the filter to apply to traffic (for our wireless networks) as that traffic passes through the campus core on its way from one leg of the network to another. (In some cases, multiple buildings share a single connection to the campus core, so this filter doesn't affect traffic which remains within that group of buildings.)
The filter is also applied at the edge of the wireless services provided by OIT, so it also applies to traffic sent by a wireless client as that traffic arrives at the wireless access point or the wireless controller. This filters the traffic before it would be flooded to other clients (wireless or wired), even if those clients are on the same leg of the network, or behind the same wireless access point.
It is possible that in the future, the filter installed at the network core might be expanded to also include the wired (non-wireless networks).
Any IPv4 traffic destined to UDP port 137 (NetBIOS Name Service) or UDP port 138 (NetBIOS Datagram Distribution Service) is discarded by the filter if the traffic is destined to an IPv4 broadcast traffic. (Specifically, the filter looks for the IPv4 broadcast addresses appropriate for use on these wireless networks, along with a few inappropriate broadcast addresses that some confused clients use anyway.)
The filter also discards any IPv4 traffic destined to UDP ports 137 or 138 if the traffic is destined to an IPv4 multicast address. Although we would not expect to see NetBIOS over TCP/IP multicast traffic, our experience is that some devices do transmit some NetBIOS over TCP/IP multicast traffic.
We do not filter other NetBIOS over TCP/IP traffic. In particular, unicast NetBIOS over TCP/IP traffic is not filtered. NetBIOS over TCP/IP remains an important protocol supporting critical applications; we do not intend to block the protocol in its entirety. We filter only its unecessary broadcast traffic.
The primary effect of this filter is to reduce the volume of broadcast traffic on the wireless network. And many of the spikes in broadcast traffic have been eliminated. This improves performance for clients on the wireless networks.
A side effect of this filter is that it is no longer possible to use NetBIOS "browsing" to discover NetBIOS services, for example, printers and file shares.
Prior to the installation of the filter, the ability to browse for such services was unreliable at best. The client was able to use broadcast only to directly discover services on the same IP subnet as the client. To discover services on other campus subnets, the client relied on a proxy service running on some other customer's workstation which happened to be on the same subnet as the client. This was unreliable, at best.
OIT believes that browsing for NetBIOS services in this way is no longer necessary, as other mechanisms are available to configure a NetBIOS client to connect to a shared service. For example, to configure a NetBIOS client to connect to a shared printer, the client may be configured to specify the DNS hostname of the shared printer or print server. To connect to a file share, the client may be configured to specify the DNS hostname of the file server.