WindowsNetworking.com Monthly Newsletter of June 2008 Sponsored by: ScriptLogic
Welcome to the WindowsNetworking.com newsletter by Thomas W Shinder MD, MVP. Each month we will bring you interesting and helpful information on the world of Windows Networking. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to: email@example.com
In last month's article, we spent some time looking into the history and functions of NetBIOS and the advantages of placing a WINS server on your network. We also went over some of the basics of how WINS works. Specially, you learned that WINS was a database server, and that the WINS database is a distributed one. We finally ended up with a scenario related to how you might configure a WINS replication network for a geographically dispersed organization.
This month we will take a look at WINS replication network topologies and convergence time. Both of these are key factors when configuring your WINS replication network.
WINS Replication Network Topologies
According to Microsoft's recommendations, you only need one primary WINS server and one Secondary WINS server for every 10,000 computers on your network. Many of the articles even go so far as to recommend that you call Microsoft Consulting Services if your network installation consists of more than 20 WINS servers.
In reading this documentation, you get a sense of urgency about the issue. Why would Microsoft be so concerned about a large number of WINS servers deployed by an organization?
Based on our own consulting experiences, here is a guess. Many organizations employ far too many WINS servers. Many more than they actually need. In the process of deploying supernumerary WINS servers, problems in WINS database synchronization "pop up". Many companies with multiple WINS servers end up creating Push and Pull partner relationships in an almost arbitrary fashion. Or worse, they configure all WINS servers to be push and pull partners of each other.
This type of haphazard approach to configuring a WINS replication network does not optimize WINS database consistency throughout the organization. Microsoft may be trying to "head trouble off at the pass" by urging customers to call before getting themselves in too deep.
A WINS network topology needs to be defined for any company with more than two WINS servers. The preferred WINS topology is the Spoke and Hub arrangement.
Exploring Spoke and Hub Topologies
In the Spoke and Hub model, one WINS server is chosen to be a Hub WINS server. The Hub collects updates to the WINS database from Spoke WINS servers. After the Hub WINS server has collected all the changes from its Spoke servers, the Hub WINS server is able to replicate the information it has collected from all its Spokes to all the WINS servers on the network.
This process is similar to the relationships between the Domain Master Browser and Master browser(s) on a multiple segment network. In a multi-segmented Browser network all of the segments have a single Master Browser which shares its information with the Domain Master Browser. The Domain Master Browser collects the information from all the segment Master Browsers, and then collates this information. The Domain Master Browser then sends back the collated information back to the segment Master Browsers. The Domain Master Browser is the Hub server, while the segment Master Browsers are the spokes.
Intersite and Intrasite Configuration
If your organization contains multiple, geographically disparate sites, then you will need to put together a Hub and Spoke configuration for each site. Therefore each physical site will have its own Hub and Spoke configuration. And because you need to configure exchange of information between the WINS servers from each site, you will have to create another Hub and Spoke configuration among the sites. This is referred to as Intersite Replication.
Intrasite replication should be based on the Spoke and Hub model. A single WINS server at each site is selected as a Hub WINS server. All other WINS servers are Spoke servers, and they are configured to be both Push and Pull partners of the Hub WINS server. By employing the Hub and Spoke Model you can simplify the replication partnerships, and be assured that all WINS servers will receive updates to changes in each WINS server's database.
Designing WINS Network Push and Pull Partnerships
You should always configure machines as Push and Pull partners when they are linked by fast LAN connections. When WINS servers are separated by comparatively slow WAN links, it is preferred to have them configured as Pull partners only. This allows you more control over when WINS database replication takes place. You would configure Pull replication to take place at times of lower WAN link utilization.
For example, imagine that your company consists of 7,500 computers distributed among three geographic locations. The company headquarters is in Dallas, Texas, where there are 3,500 hosts. You also have regional facilities in Los Angeles, California and Portland, Oregon. Each regional office has 2,000 hosts. Your network is a Windows based network, and all computers are capable of being WINS clients.
Creating the WINS Replication Network
You have been asked to design a WINS network to optimize WINS replication for two different scenarios.
Let's take a look at how we would solve the problem for each scenario.
Scenario 1: All Sites Connected to a Central Site
In the first scenario you should select a single WINS server at each location as a Site Hub for Dallas, Los Angeles, and Portland. The remaining servers within each site would be configured Spoke servers to the Site Hub and made Push and Pull partners of their respective Site Hub server. This configuration assures full replication of WINS database entries among all WINS servers within each site.
To insure WINS database consistency among all WINS servers in the organization, the Site Hub servers need to replicate their Site's WINS database. In order to accomplish this, you will create another Spoke and Hub arrangement among the site Hubs, using the Dallas WINS server as the "Hub of the Hubs".
Dallas is chosen as the Intersite Hub because each remote site is connected to Dallas via the WAN, and the remote sites are not connected to each other. You would configure the remote sites as Pull partners to the Dallas hub to minimize impact on the WAN. When the Intersite Hubs are configured in this way, all changes in the organization are pooled at the Dallas WINS server. These changes are then distributed back to the remote Site Hub servers. The Site Hubs then distribute the changes back to their respective Spoke WINS servers.
The major drawback of using a single Intersite Hub server for synchronizing all the Hubs across the WAN is that it represents a single point of failure. If the Dallas server becomes unavailable, no Intersite WINS database replication takes place until it comes back online.
This can have a major impact in destabilizing your the WINS synchronization scheme. In order to bring WINS database back into equilibrium, we have to take into account not only the time to bring the downed WINS server back on-line, but also the convergence time for all the sites. We will talk about convergence time at the end of this article.
Scenario 2: All Sites Connected to Each Other
In the second scenario, there are WAN links of equal speed connecting all three sites. Intrasite replication would be configured in the same fashion as seen in the first scenario, using a central Site Hub server setup as a Push and Pull replication partner to the remaining Spoke servers.
However, the Hub Servers would be configured in a "Ring" or "Chain" where all the links in the chain are connected. Each adjacent member in the ring is configured as a Pull partner of the other. This arrangement avoids a single point of failure. If the Dallas Site Hub should go down, the Los Angeles and Portland Site Hubs are still able to update their WINS database. Also, in this three-site scenario, convergence of the WINS database takes place more quickly.
The primary drawback to this type of configuration is that there is not a single Intersite hub collating the information for all sites. This does increase the risk of WINS database inconsistency and the possibility for corruption. However, the risk is not high. You should weigh this possibility with the risk of having all Intersite replication fail with the single Intersite Hub model.
Calculating Convergence Times
Convergence time represents the total time it would take for a changed WINS record to be replicated to all the WINS servers on the network. Practically speaking, these would be the WINS servers at the "far ends" of the replication topology.
Let's use the scenarios we have been working with. In the first scenario, all site hubs are connected to the central Dallas hub. If the Intrasite Pull interval is 5 minutes, and the Intersite Pull interval is 15 minutes, what is the maximum time required to get an updated WINS record from Spoke server in Portland to a Spoke server in Los Angeles?
The answer is 40 minutes. It would take five minutes to get the changed record from a Spoke server in Portland to the Portland Site Hub. It would then take up to 15 minutes to get the record to from the Portland Site Hub to the Dallas Site/Intersite Hub. Then another 15 minutes could pass before the Dallas Site/Intersite Hub sends the record to the Los Angeles Site Hub. Finally another 5 minutes could pass before the Los Angeles Site Hub replicates it to one of its Spoke servers. The WINS Intersite "hop count" was two: one hop from the Portland Site Hub to the Dallas hub, and a second hop from the Dallas to the Los Angeles Site Hub.
Convergence Time Within The Ring
What is the convergence time in the second scenario? All site hubs are only one hop away from any other site hub. For a changed WINS record to get to Los Angeles from Portland, it would take up to 5 minutes for the Portland spoke to get the information to the Portland Site Hub, then up to 15 minutes for the Portland Site Hub to send the record to the Los Angeles Site Hub, and finally up to 5 minutes from the Los Angeles Site Hub to the Los Angeles Spoke server. This represents a total of 25 minutes. It would appear that the ring model is more efficient, as well as being more fault tolerant.
However, the time to convergence is related to the number of Intersite hops (assuming all Intrasite hops are equal to 1 and the Pull interval is the same for all Intrasite servers). A ring of 4 Intersite Hubs would have a maximum hop count of 2 and a maximum convergence time of 40 minutes, as seen in the figure below.
With a 5-node Intersite Hub setup, the minimum Intersite hop count would be two, and the maximum would be three. So, the ring replication model appears to be equal, or superior to the Intersite Hub model for networks of up to 5 sites.
But what happens in our 5 Intersite Hub design if one of the Intersite Hub's goes down? The minimum hop count is no longer 2. It is now 3, as shown in the figure below.
The convergence time in the 5 Intersite hub model with one downed site is now 50 minutes and requires three hops! The time to convergence increases with each Intersite Hub when a single Intersite Hub becomes unavailable. So we again see in this example that we need to carefully weight the risks and benefits between the Intersite Hub and Ring replication designs.
Parting Words on WINS
As you can see from these examples, replication of the WINS database will always be a factor in determining how functional NetBIOS name resolution will be on your network. When you think about it, the WINS database is just one example of a distributed database solution. The Browse List is a distributed database, the Active Directory is a distributed database, and the DNS is a distributed database. In each of these examples, you need to design your network to minimize traffic and database inconsistency.
On the bright side, Microsoft has gone a long way toward moving away from NetBIOS name resolution. When Microsoft made the decision to create an enterprise grade operating system, they realized that NetBIOS dependence would be a significant rate limiting factor to acceptance in the enterprise market. Few new applications are dependent on the NetBIOS interface. WINS is useful only for older applications. However, be careful about completely expunging NetBIOS from your network until you are sure that none of your applications require it.
Next month I will talk about DNS and how the Windows Server 2008 DNS server works. Included in the discussion will be the basics of DNS, just in case you are not already a DNS wizard.
If you have any questions about WINS or Windows Networking or Windows Network Services, let me know! My answers will show up in next month's newsletter in the Q&A section. Write me at firstname.lastname@example.org.
Quote of the Month - "I wonder what it means when your grandson is more crotchety than you are?"
While I prefer the graphical interface and stay away from the command line in order to prevent potentially dangerous errors due to typos, sometimes it is fun to get into the command line to see how the other half lives and there are even occasions when the command line is faster.
For example, suppose you want to see the details of your network connection in Windows XP SP. Just type:
Netsh interface ip show config
And you will see something like this:
Configuration for interface "Local Area Connection"
Another useful command is the ARP command. This allows you to see the entries in the ARP table and also allows you to flush the ARP cache, which is useful when trying to troubleshoot IP addressing problems.
To view the ARP cache, use the command:
You should see something like:
Interface: 192.168.1.70 --- 0x10003
Another tool that you do not hear a lot about, but can give you very useful information about routers in the path that might be giving you problems is the pathping command.
For example, you can enter the command
pathping -n www.windowsnetworking.com
(the -n tells pathping not to waste time doing a DNS lookup for each hop)
You will see something like this:
Tracing route to www.windowsnetworking.com [184.108.40.206]
There are many other command line tools that are useful when troubleshooting Windows networking. We will cover those in subsequent issues of this newsletter.
I am having problems with my public DNS and would like to figure out how I can use a DNS server other than the one on my network to perform name resolution. I do not want to change our forwarders on our DNS servers, I just want to test by sending DNS queries directly to another DNS server outside my network. Is this possible? Thanks! -Howard.
Yes, you can do that using the nslookup tool at the command line. For example, suppose you want to send a query for www.zdnet.com to another DNS server. You will have to figure out what DNS server you want to use, and if that DNS server is off-network, then you need to confirm that it will answer queries for off-network clients. For this example, I will use one of the Verizon DNS servers at 220.127.116.11.
The first thing to do is open a command prompt and then enter nslookup and press ENTER.
You should see something like this:
Default Server: marsoutpost.tacteam.net
Notice the > at the end. That's the nslookup prompt. Type server 18.104.22.168 and press ENTER.
You should see something like this:
Default Server: marsoutpost.tacteam.net
Now to issue the query, you type www.windowsnetworking.com. It's important that you include the period at the end of the query.
You should see something like:
C:\Documents and Settings\tshinder.TACTEAM>nslookup
Notice that nslookup said that answer was "non-authoritative". That just means that the DNS server that you sent the query to was not responsible for the domain that was being queried for. This often confuses people and it is not something that you should worry about.
If you want to leave the nslookup prompt, just type exit and it will return you to the regular command prompt.
I want to separate my domain clients from domain member servers by a firewall. What protocols do I need to allow through my firewall to make sure that allow intradomain communications work through the firewall?
While the number of ports required varies with the type of traffic you need to support, a general list of protocols includes the following:
Note that not all of these may be required. For example, the NetBIOS ports are not required for name resolution or for file sharing if you have a correctly configured DNS environment. The WINS replication traffic port is not required if you are not using WINS or multiple WINS servers. Not that RPC traffic requires more than allowing TCP port 135 through your firewall. Your firewall needs a smart application filter that will manage the secondary ports required through the firewall after the connection to the RPC endpoint mapper is established. Advanced firewalls such as the Microsoft ISA Firewall and Check Point include this type of intelligence.
Got a question for Dr. Tom? Send it to email@example.com.