?
Solved

redundant dhcp and wins

Posted on 2005-03-10
5
Medium Priority
?
764 Views
Last Modified: 2008-01-09
I need a little bit of help with dhcp and wins. As part of my disaster recovery plan I am installing a dhcp and win server in our recovery site. I am running win2k on all servers. I want to create a redundant wins and dhcp server on our recovery site. the recovery site is in one of our branches and located on a different subnet.

I want to accomplish the follwoing:

redundant wins server where the headquaters wins server is setup as a push partner and dr server setup as pull. To reduce traffic I want replication to occur nightly. Also are there issue with doing replication over on a separate network?

redundant dhcp server, from all the articles I read the only way i can do this is by introducing an 80/20 split scope. Can someone provide me with good documentation on how to do an 80/20 split. Will it be best to setup a dhcp relay agent?
0
Comment
Question by:Maquinaloca
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
5 Comments
 
LVL 57

Expert Comment

by:Mike Kline
ID: 13508522
Nice work setting up a disaster recovery plan!!

What is the link speed between your branch office and your head office.   Replication to a separate network is fine.  We replicate between our child domain and our parent across the country but we have a fast link.

The 80/20 split is a good idea for redudancy.  I'll get you a guide on that.  Are you currently backing up your WINS and DHCP databases?

This article is a little dated but I'm such a huge Mark Minasi fan I wanted to include it

http://www.windowsitpro.com/Windows/Article/ArticleID/4976/4976.html
DHCP recovery

Thanks
Mike
0
 
LVL 4

Expert Comment

by:Blackmoorian
ID: 13510164
You will definitey need a relay agent to be able to go across the router to the different subnet. That is the only way a DHCP request will be able to reach the server.

As far as setting up the DHCP split, it depends on the number of machines that request addresses from your DHCP Server. I myself use a 50/50 split and both are online at all times and service requests. If one fails the other picks up the slack but then again I never have more machines online than half the number available for the total scope.
0
 
LVL 35

Accepted Solution

by:
Nirmal Sharma earned 500 total points
ID: 13514061
You both are talking about your own and now talking about his requirement for WINS...first read the question carefully note all lines and then start answering.

Advice.

I need a little bit of help with dhcp and wins. As part of my disaster recovery plan I am installing a dhcp and win server in our recovery site. I am running win2k on all servers. I want to create a redundant wins and dhcp server on our recovery site. the recovery site is in one of our branches and located on a different subnet.

I want to accomplish the follwoing:

>>>redundant wins server where the headquaters wins server is setup as a push partner and dr server setup as pull. To reduce traffic I want replication to occur nightly.
>>>Also are there issue with doing replication over on a separate network?

That's what they said....Speed and Convergenece Time.

Configuring WINS replication

Before configuring replication, you should first carefully design and review your WINS replication topology. For wide area networks (WANs), this planning can be critical to the success of your deployment and use of WINS. In general, WINS offers you the following options and possibilities to choose from when you are configuring replication:

    * You can manually configure WINS replication for a WAN environment.
    * For some larger campus networks, you might also configure WINS to replicate within a LAN environment.
    * In smaller or bounded LAN installations, you might consider enabling and using WINS automatic partner configuration for simplified setup of WINS replication.
    * In some larger or more global installations, you might have to configure WINS across untrusted Windows NT domains.

***********Replication across wide area networks**************

When configuring WINS replication, the two most important planning issues are:

    * Whether your WINS replication occurs over slower WAN links.
    * The length of time required for all replicated changes in the WINS database to converge and achieve consistency on the network.

The frequency of WINS database replication between WINS servers is a major planning issue. The WINS server database should be replicated frequently enough to prevent the downtime of a single WINS server from affecting the reliability of the mapping information in other WINS servers. However, the time interval between replications should not be so small that it interferes with network throughput.

Network topology can influence your decision on replication frequency. For example, if your network has multiple hubs connected by relatively slow WAN links, you can configure WINS database replication between WINS servers on the slow links to occur less frequently than replication on the local area network or on fast WAN links. This reduces traffic across the slow link and reduces contention between replication traffic and WINS client name queries.

For example, as shown in the following figure, the intervals used for configuring pull replication for WINS servers could be set according to proximity between servers and the likelihood of a high-speed link connecting servers configured as replication partners of each other.
Art Image

In this example, two WINS servers--SEA-WINS and ATL-WINS--are located in Seattle and Atlanta. Another two servers--MEX-WINS and SYD-WINS--are located outside the United States in Mexico City and Sydney. Because SEA-WINS and ATL-WINS are located across a higher-speed WAN link, they are configured to replicate once every hour. For the servers outside the United States, replication intervals might be set higher, such as either 3 or 12 hours, because lower-speed links are associated with these connections.
Planning the convergence time

Convergence time is the time needed to replicate a new entry in a WINS database from the WINS server that owns the entry to all other WINS servers on the network. When planning for WINS servers, you must decide what is acceptable as the convergence time for your network.

Using the previous example, if a WINS client in Seattle registers its name with the WINS server in the figure labeled SEA-WINS, other WINS clients in remote locations might query for the client name and not find it in WINS. In some cases, if the address of the client has been changed, the remote locations would only have a mapping for the previous IP address of the client in their local server databases.

WINS clients that query any of the other WINS servers in the figure (that is, ATL-WINS, MEX-WINS, SYD-WINS) only receive a positive and correct response when the new or updated mapping for the client has been fully replicated from the owning WINS server, SEA-WINS, to all of the other servers. Replications from SEA-WINS could be triggered in one of two ways:

    * A push replication trigger is sent based on the frequency of updates made at SEA-WINS.
    * A pull replication trigger is sent to other WINS servers based on the configured Replication interval set in Replication Partners Properties at SEA-WINS.

Given this configuration, a new or updated entry at SEA-WINS is only replicated when the pull replication interval expires, but queries at remote sites for the new name mapping might not succeed until later. This is because the time interval for replication to ATL-WINS is one hour; it is three hours for MEX-WINS; and it is 12 hours for SYD-WINS. In this case, WINS convergence time is calculated as:

12 hours + 2 * (1 hour) = 14 hours

In reality, name query requests can succeed before the convergence time elapses. This happens when the entries replicate over a shorter path than the worst-case path. It also happens when the Number of changes in version ID before replication threshold in push replication settings passes before the Replication Interval expires in pull replication settings. This results in earlier replication of the new entry. The longer the replication path, the longer the convergence time.

Notes

    * After each administrator configures the respective WINS server, you can use Replicate Now (in the WINS console) to start immediate replication between the configured WINS servers.
    * When replication occurs, you can use Display Records to view records for the remote WINS server database. However, to make changes to the remote WINS database, you must be logged on under an account with required user rights in the respective domains for both servers involved.
    * Replication can also occur between two separate stand-alone servers that participate in a workgroup.

Replication across local area networks

When configuring WINS replication for local area networks (LANs), the issues are similar to those that occur in WAN environments, although less critical.

Because the speed of the underlying network links for LANs are much greater than for WANs, it might be acceptable to increase the frequency of WINS database replication, by optimizing push and pull parameters for LAN-based replication partners. For push/pull partners, you can do this by decreasing the Number of changes in version ID before replication and Replication interval settings accordingly, from what you would use for WAN-based partners on slower links.

For example, between LAN-based replication partners it often works to enable WINS to use a persistent connection between the servers. If a persistent connection was not used, the normal update count threshold would default to a minimum of 20. With persistence, a smaller update count value can be specified.

Next, you could specify a much smaller number, such as a value of one to three in Number of changes in version ID before replication before WINS sends a push replication trigger to the other partner. For pull partners, you might also consider setting the Replication interval to a value in minutes, instead of hours.

As in WAN replication planning, the WINS server database should be replicated frequently enough to prevent the downtime of a single WINS server from affecting the reliability of the mapping information in other WINS servers. However, the time interval between replications should not be so small that it interferes with network throughput.

For network-intensive environments, it is a good idea to use a network monitoring tool such as Network Monitor to help measure and determine how to optimize your WINS replication strategy.
Automatic partner configuration

You can configure a WINS server to automatically configure other WINS server computers as its replication partners. With this automatic partner configuration, other WINS servers are discovered when they join the network and are added as replication partners.

Automatic configuration is possible because each WINS server announces its presence on the network through periodic multicasts. These announcements are sent as IGMP messages for the multicast group address of 224.0.1.24 (the well-known multicast IP address reserved for WINS server use).

Automatic replication configuration monitors multicast announcements from other WINS servers and automatically performs the following configuration steps:

    * Adds the IP addresses for the discovered servers to its list of replication partner servers.
    * Configures the discovered servers as both push and pull partners.
    * Configures pull replication at two-hour intervals with the discovered servers.

If a remote server is discovered and added as a partner through multicasting, it is removed as a replication partner when WINS shuts down properly. To have automatic partner information persist when WINS restarts, you must manually configure the partners.

To manually configure replication with other WINS servers, use the WINS console to specify roles for each partner and any related information.

Ref: - http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/Default.asp?url=/resources/documentation/windowsserv/2003/standard/proddocs/en-us/sag_WINS_imp_ConfiguringReplication.asp

>>>redundant dhcp server, from all the articles I read the only way i can do this is by introducing an 80/20 split scope. Can someone provide me with good documentation on how to do an 80/20 split. Will it be best to setup a dhcp relay agent?

You have to configure Relay Agent because ordinary routers does not pass brodcast send by client machines (DHCPDISCOVER) . If you setup Relay Agent on both sides you have redudency if not then there is no use of two DHCP Servers across the sites.
80/20 is the best configuration as suggested by Mike because it is recommended by Microsoft also. So we follow MS.

Are you running DNS on your Network ?

Let me know.

Thanks
0
 
LVL 35

Expert Comment

by:Nirmal Sharma
ID: 13514074
One more thing..you also need to protect your WINS Servers...any hacker can execute a code.

WINS Replication IPSec Script
Download from here: -
http://www.microsoft.com/downloads/details.aspx?FamilyID=20f8df98-7eee-4293-b80a-c34bb1208828&displaylang=en

***Quote***

Overview
This is a sample script that can be used to automate the creation of a local registry based IPSec policy on a WINS server.

WINS Replication Blocker Script version 1.0

Purpose:
The purpose of this script is to create an IPSec policy on Windows 2000 or later WINS servers that will protect them from remote hosts exploiting a vulnerability in the WINS Replication protocol operating over TCP or UDP port 42.

This script accomplishes this by creating an IPSec policy with two filter rules that:
1. Block inbound packets destined for TCP or UDP port 42 from any host
2. Block outbound packets destined for TCP or UDP port 42 to any host

These default block rules will break WINS replication between any configured WINS replication partners, so in addition to the rules defined above; if the script is run interactively with no command line parameters it will prompt the user to enter the IP addresses of any WINS replication partners to exempt them from the default ‘block’ rule and allow WINS replication to continue functioning between trusted replication partners.

If you chose to enter IP addresses of WINS replication partners, the IP addresses you specify will be allowed to communicate with the local WINS server (i.e. these IP addresses will be exempt from the ‘block’ policy being created on the local WINS server).

All other IP addresses will be unable to communicate with the WINS server on TCP or UDP port 42.

This script can be run interactively and will guide the user through creating the policy and entering the IP addresses of the WINS replication partners or the script can be used with command line parameters to automate deployment from other scripts such as a logon script or machine startup script.

For more information please refer to the following knowledge base article:
890710 How to help protect against a WINS security issue
http://support.microsoft.com/?id=890710

***End Quote***
0
 
LVL 35

Expert Comment

by:Nirmal Sharma
ID: 13598384
0

Featured Post

On Demand Webinar: Networking for the Cloud Era

Ready to improve network connectivity? Watch this webinar to learn how SD-WANs and a one-click instant connect tool can boost provisions, deployment, and management of your cloud connection.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

NTFS file system has been developed by Microsoft that is widely used by Windows NT operating system and its advanced versions. It is the mostly used over FAT file system as it provides superior features like reliability, security, storage, efficienc…
The well known Cerber ransomware continues to spread this summer through spear phishing email campaigns targeting enterprises. Learn how it easily bypasses traditional defenses - and what you can do to protect your data.
Michael from AdRem Software outlines event notifications and Automatic Corrective Actions in network monitoring. Automatic Corrective Actions are scripts, which can automatically run upon discovery of a certain undesirable condition in your network.…
In this video, Percona Director of Solution Engineering Jon Tobin discusses the function and features of Percona Server for MongoDB. How Percona can help Percona can help you determine if Percona Server for MongoDB is the right solution for …
Suggested Courses

770 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question