Tài liệu Module 5: WINS as a Solution for NetBIOS Name Resolution doc

To enhance the availability of the service, a WINS solution can be designed to provide support for multiple WINS servers that use WINS replication, and to include WINS servers that are c

Contents

Overview 1

Designing a Functional WINS Solution 8

Enhancing a WINS Design for Availability 22

Optimizing a WINS Design

Lab A: Designing a WINS Solution 31

Review 38

Module 5: WINS as a Solution for NetBIOS Name Resolution

to represent any real individual, company, product, or event, unless otherwise noted Complying with all applicable copyright laws is the responsibility of the user No part of this document may

be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Microsoft Corporation If, however, your only means of access is electronic, permission to print one copy is hereby granted

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property

 2000 Microsoft Corporation All rights reserved

Microsoft, Active Directory, ActiveX, BackOffice, FrontPage, JScript, MS-DOS, NetMeeting, PowerPoint, Visual Basic, Visual C++, Visual Studio, Win32, Windows, Windows Media, Windows NT, are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A and/or other countries/regions

Project Lead: Don Thompson (Volt Technical)

Instructional Designers: Patrice Lewis (S&T OnSite), Renu Bhatt NIIT (USA) Inc

Instructional Design Consultants: Paul Howard, Susan Greenberg

Program Managers: Jack Creasey, Doug Steen (Independent Contractor)

Technical Contributors: Thomas Lee, Bernie Kilshaw, Joe Davies

Graphic Artist: Kirsten Larson (S&T OnSite)

Editing Manager: Lynette Skinner

Editor: Kristen Heller (Wasser)

Copy Editor: Kaarin Dolliver (S&T Consulting)

Online Program Manager: Debbi Conger

Online Publications Manager: Arlo Emerson (Aditi)

Online Support: Eric Brandt (S&T Consulting)

Multimedia Development: Kelly Renner (Entex)

Production Support: Lori Walker (S&T Consulting)

Manufacturing Manager: Rick Terek (S&T OnSite)

Manufacturing Support: Laura King (S&T OnSite)

Lead Product Manager, Development Services: Bo Galford

Lead Product Manager: Ken Rosen

Group Product Manager: Robert Stewart

Other product and company names mentioned herein may be the trademarks of their respective owners

Instructor Notes

This module provides students with the information and decision-making experience needed to develop a solution for resolving network basic input/output (NetBIOS) names by using WINS in Microsoft® Windows® 2000 Students will evaluate and create WINS solutions for the name resolution of NetBIOS resources in Transmission Control Protocol/Internet Protocol (TCP/IP) networks

At the end of this module, students will be able to:

Evaluate WINS as a solution for NetBIOS name resolution

Evaluate and create a functional design for baseline name resolution

Select appropriate strategies to secure a WINS solution

Select appropriate strategies to enhance a WINS design for availability

Select appropriate strategies to improve a WINS design for performance Upon completion of the lab, students will be able to evaluate and design WINS solutions that meet the requirements for resolving NetBIOS names in a variety

of organizations

Course Materials and Preparation

This section provides you with the materials and preparation needed to teach this module

Required Materials

To teach this module, you need the following materials:

Microsoft PowerPoint® file 1562B_05.ppt

Preparation Tasks

To prepare for this module, you should:

Review the contents of the module

Be familiar with RFCs 1001 and 1002

Review any relevant information in the Windows 2000 Help files, the Windows 2000 Resource Kit, or in documents provided on the Instructor

Module Strategy

Use the following strategy to present this module:

Introducing WINS The use of NetBIOS names in a TCP/IP network requires resource names to

be resolved into IP addresses WINS provides an RFC-compliant NetBIOS Name Service (NBNS) to resolve resource names throughout a network infrastructure

• Review the four distinct phases of name resolution provided by the WINS service in Windows 2000: registration, resolution, renewal, and release Mention that WINS removes names if the client fails to renew its entries

• Emphasize that the integration of WINS with DHCP and DNS solves a major networking issue by providing DNS name resolution for hosts with dynamic IP address allocations

Designing a Functional WINS Solution

A functional WINS solution supports both WINS and non-WINS clients in a local area network (LAN) or a routed network A WINS solution can be designed to control replication of the WINS databases when multiple WINS servers are required

In this section:

• Highlight that WINS uses a unicast protocol, thereby eliminating NetBIOS-related broadcast traffic in a LAN Emphasize that client counts and response times depend on the configuration of the hardware

• Point out that the unicast protocol used by WINS meets the routed network requirement for a nonbroadcast-based NetBIOS name service Emphasize that client performance issues, and the requirements for redundancy and replication, determine the number and placement of WINS servers

• Emphasize that all versions of Windows support a WINS client component Explain that this component further reduces broadcast traffic

• Emphasize that non-WINS clients can be supported by including WINS Proxy Agents and static WINS or Lmhosts entries, and by enabling NetBIOS traffic across all routers

• Explain that when using multiple WINS servers, the locally acquired entries must be replicated to configured partners Caution students that multicast announcements between WINS servers add traffic to the network

• Make sure that students understand the scenario description and the instructions for the Discussion Direct them to read through the scenario and answer the questions Be prepared to clarify if necessary Lead a class discussion on the students’ responses

Securing a WINS Solution Because replication and client traffic often occur across public networks, the security of the NetBIOS names and IP addresses of hosts within the

organization is at risk A WINS solution can be secured by using Layer Two Tunneling Protocol (L2TP)/Internet Protocol Security (IPSec) or Point-to-Point Tunneling Protocol (PPTP)-based virtual private network (VPN) tunnels There may also be scenarios that would benefit from the integration

of WINS servers into screened subnets

In this section:

• Stress that the decision whether to use L2TP/IPSec or PPTP VPN tunnels must be based on the existing network configuration and the public networks used to transfer data

• Point out that screened subnets can be used to avoid exposing NetBIOS names and WINS data to a public network Suggest students consider

using pull replication only if replication is required from the WINS

server in the screened subnet to the WINS server(s) within the corporate intranet Remind students that a Common Internet File System (CIFS) and WINS solution is simple by comparison to Web-based solutions

Enhancing a WINS Design for Availability Ideally, a WINS Service would be available whenever it is required To enhance the availability of the service, a WINS solution can be designed to provide support for multiple WINS servers that use WINS replication, and

to include WINS servers that are configured to use Windows Clustering

In this section:

• Emphasize that when using multiple WINS servers, the placement of servers depends on the network infrastructure, service performance, and location constraints Point out that adding additional WINS servers to remote locations provides name service redundancy in case a server fails

• Emphasize that installing WINS servers on a cluster provides immediate recovery in the event of hardware or service failure

• Make sure that students understand the scenario description and the instructions for the Discussion Direct them to read through the scenario and answer the questions Be prepared to clarify if necessary Lead a class discussion on the students’ responses

Optimizing a WINS Design for Performance Reducing response times to client requests, and reducing the time taken to replicate between servers, can maximize the performance of the WINS service

In this section:

• Emphasize that WINS in Windows 2000 supports the use of multiple CPUs, an optimized database, burst-mode client registrations, and multiple WINS servers to optimize the performance of the WINS service

• Point out that replication traffic between servers in a multiple-server environment reduces the performance of the WAN links Emphasize that the replication schedule can be planned to minimize replication traffic while meeting the goals for convergence time

Lab Strategy

Use the following strategy to present this lab

Lab A: Designing a WINS Solution

In the lab, students will design a WINS solution based on specific requirements outlined in the given scenario

Students will review the scenario and the design requirements and read any supporting materials They will use this information, and the knowledge gained from the module, to develop a detailed design that uses WINS as a solution

To conduct the lab:

Read through the lab carefully, paying close attention to the instructions and the details of the scenario

Divide the class into teams of two or more students

Present the lab and make sure students understand the instructions and the purpose of the lab

Direct students to use the planning worksheet to record their solutions

Remind students to consider any functionality, security, availability, and performance criteria provided in the scenario, and how they will incorporate strategies to meet these criteria in their design

Allow some time to discuss the solutions after the lab is completed A solution is provided in your materials to assist you in reviewing the lab results Encourage students to critique each other’s solutions and to discuss any ideas for improving their designs

Overview

The use of network basic input/output system (NetBIOS) names in a Transmission Control Protocol/Internet Protocol (TCP/IP) network requires resource names to be resolved throughout a network infrastructure WINS in Microsoft® Windows® 2000 implements an RFC-compliant NetBIOS name service (NBNS)

At the end of this module, you will be able to:

Evaluate WINS as a solution for NetBIOS name resolution

Evaluate and create a functional design for baseline name resolution

Select appropriate strategies to secure a WINS solution

Select appropriate strategies to enhance a WINS design for availability

Select appropriate strategies to improve a WINS design for performance

In this module, you will

evaluate and design WINS

solutions for locating

NetBIOS resources

Shared Resource

Windows Clients

Exchange Server

Windows 95 Using NetBIOS

Client Running Outlook

NetBIOS name resolution is

required by many clients

Within an organization’s intranet, the potentially large number of available NetBIOS resources, such as file and print services, creates the need for

meaningful device and logical resource names to simplify the user’s access to

resources WINS resolves NetBIOS resource names to IP addresses WINS can also integrate with other Windows 2000 services to extend name resolution capabilities

To design a strategy for locating NetBIOS resources by using WINS, you must:

Collect the network and host configuration data required to make the design decisions necessary for developing a WINS solution

Identify the features provided by WINS and how these features support the design requirements

Identify the benefits provided by integrating WINS with other services in Windows 2000

network hosts by using a

NetBIOS name instead of

the host’s IP address WINS

translates the NetBIOS

name to the resource IP

address

Explain that a network host

can be defined as any

device or computer that

participates in a TCP/IP

network Host may describe

a client or server

Design Decisions for a WINS Solution

File Servers

Exchange Server

Establishing the Need for WINS

In a TCP/IP routed or switched network, where broadcast packets may not pass between segments, a nonbroadcast-based service is required to accommodate a dynamic NetBIOS name resolution and registration service WINS meets this service need by providing unicast NetBIOS name registration and resolution

In a simple, nonrouted TCP/IP network, such as a single-segment local area network (LAN), WINS may be optional A non-WINS solution works in those instances where the broadcast domain is small, broadcast traffic is acceptable, and hosts are configured as b-node (broadcast nodes)

Identifying the Design Decisions

After you have established the network infrastructure requirements and configuration, the design decisions you must make include the:

Number and placement of WINS servers within the network

Plan for replication schedules, and architecture and configuration options for multi-WINS server environments

Configuration of WINS Client

Placement of WINS Proxy Agents to ensure unique non-Windows host names

Slide Objective

To introduce the decisions

required for a WINS

solution

Lead-in

The design of a NetBIOS

name resolution service

based on WINS depends on

the number of hosts, the

number of resources, and

the network configuration

Use the slide to discuss the

decisions required to design

a WINS solution

Explain that WINS is not

required in a single-segment

LAN within a single

broadcast domain, but is

Features of a WINS Service

Administration

WINS Server

WINS Client

WINS Client

Register Renew Release

Resolve

WINS Database

Client1 10.0.1.11 Client2 10.0.3.12 Client3 10.0.3.13

Remove

When designing a WINS-based NetBIOS name resolution service, you must understand the WINS features and how you can use these features to support the needs of your network infrastructure

Name Resolution Services

A WINS infrastructure builds and maintains a database of available NetBIOS resources and resolves NetBIOS names to IP addresses based on client requests WINS accomplishes name resolution in four distinct phases:

Registers new network device names as they become available

Resolves NetBIOS names to IP addresses for WINS clients

Renews name registrations for WINS clients

Releases NetBIOS names during normal WINS client computer shutdown

And, in addition, the WINS service:

Removes names from the registration database if the client fails to renew its

entries

RFC Compliance

WINS provides NetBIOS name service support that is compliant with RFC

1001 and RFC 1002 The implementation of WINS in Windows 2000 extends the RFC-compliant NetBIOS name service by supporting multiple distributed servers with replicated databases

DNS Integration

To fulfill DNS client queries, the WINS service integrates with DNS in Windows 2000 to allow forward and reverse lookup of NetBIOS resources by DNS servers You can also configure WINS clients to support name resolution

by using both DNS and WINS records

Slide Objective

To introduce the features in

WINS

Lead-in

To develop a WINS solution,

you need to understand the

WINS features

Mention that this is not a

complete list of the WINS

features; additional features

will be discussed later

Burst-Mode Name Registration

When a large number of WINS clients simultaneously try to register their NetBIOS names, the WINS server can become saturated Burst-mode name registration supports a high volume of WINS client name registrations

By default, when the queue of registration requests exceeds 500, a WINS server begins to positively respond to new registration requests with a shorter (5 – 50 minutes) Time to Live (TTL) The short TTL lease forces these WINS clients to reregister after the excessive WINS registration traffic has subsided

Secure and Centralized Administration

You can centrally administer WINS, thereby reducing name resolution–related support issues WINS clients automatically register and release their NetBIOS names, so no other administration is necessary Administration is secure because only specific Windows 2000–based groups can modify a WINS server configuration or database

Multiple WINS Servers

WINS provides a critical service for the network, so availability and performance are key design goals Multiple WINS servers provide greater availability and improve the performance of any WINS implementation The WINS architecture supports multiple servers that you can configure to replicate their database information In addition, you can configure WINS clients with a list of available WINS servers that are sequentially referenced in the case of a server failure

Integration Benefits

DHCP Server

DNS Server

Name Registration Name Resolution

WINS Server

WINS clients that have DHCP-allocated IP addresses must be registered in WINS to allow other clients to resolve resources The integration of WINS with other Windows 2000 networking services such as DHCP and DNS allows the other services to use these dynamic registrations

The integration of WINS with DHCP and DNS allows:

DNS servers to forward unresolved DNS queries to WINS servers for resolution of host names that have dynamic IP addresses

DNS resolution for resources located on other operating systems, such as previous versions of Microsoft Windows

In addition to the server-to-server integration, you can configure the WINS client to query a DNS server with unresolved WINS queries

DHCP Integration

The integration of WINS and DHCP allows client computer name registrations

to be updated in WINS for clients with dynamically allocated IP addresses This automated registration eliminates manual administration and configuration errors

You can select registration of the NetBIOS names in WINS to be completed by:

The DHCP Client

The DHCP Server

The DHCP Client and DHCP Server

Slide Objective

To describe the benefits of

integrating WINS with other

This integration allows the

other services to use

DNS Integration

The integration of WINS and DNS allows you to select whether DNS can use WINS to resolve host names This integration allows resources not registered in DNS to be resolved in the WINS namespace The DNS server then returns the resource’s IP address to the querying DNS client

Designing a Functional WINS Solution

You can create a WINS design for a LAN or routed network that supports both WINS and non-WINS clients If multiple WINS servers are required, you can create a solution to control replication of the WINS databases between partners

Slide Objective

To provide an overview of

the network configurations

in which WINS can be used

as a solution

Lead-in

You can design a WINS

solution for a LAN or a

routed network that supports

WINS or non-WINS clients

You can incorporate multiple

WINS servers if required

Designing a WINS Service for a LAN

h-node Register, Renew, Release, and Query by Unicast traffic then use Lmhosts and Broadcasts

h-node Register, Renew, Release, and Query by Unicast traffic then use Lmhosts and Broadcasts

WINS Server

WINS Clients (h-node)

Unicast reduces broadcasts

In a nonrouted LAN, you can register and resolve NetBIOS names by using broadcasts, but all hosts must process these broadcasts, which reduces the performance of the hosts WINS provides a NetBIOS name service that uses a unicast protocol, which can eliminate NetBIOS-related broadcast traffic

LAN Considerations

When designing a WINS solution for a nonrouted LAN, consider doing the following:

Enable all clients to use WINS to reduce broadcast traffic on the LAN

Set conservative client counts for a WINS server to minimize client query response times

A single WINS server can support thousands of WINS clients, but the performance depends on the configuration of the hardware The WINS service might be installed on a computer providing other services, which can further reduce performance In a larger network, you might need a dedicated WINS server, or more than one WINS server

Client Considerations

All Windows 2000–based clients—and most of the earlier Microsoft-based WINS clients—are configured by default as hybrid node (h-node) clients These WINS clients use any of the following methods, in the order listed, to handle requests to resolve names not already in the client NetBIOS name cache:

1 Direct (unicast) contact with a WINS server

2 Host lookup by using the Lmhosts file

3 Broadcast of the NetBIOS request to the local subnet

Slide Objective

To describe the factors to

consider when designing a

WINS solution for a LAN

Lead-in

WINS provides services for

LANs by using unicast

protocol, which minimizes

broadcast traffic

Remind students that client

counts and response times

are hardware-dependent

Recommend that students

read any relevant capacity

planning white papers or

perform testing to determine

the capacity of a server

If your entire network supports broadcasts and is made up of a single, routed LAN that occupies one physical segment or a single, non-routed LAN that occupies switched network segments with few clients, you probably do not need a WINS server For these small networks, using Lmhosts entries and broadcasts may be an effective and simple solution for providing NetBIOS name service to a small number of clients

non-Designing a WINS Service for a Routed Network

WINS Clients

Sydney

WINS Servers

WAN Connection

WINS Server

WINS Server

WINS Client

New York

nonbroadcast-The unicast protocol used by WINS provides NetBIOS name resolution for WINS clients in a routed TCP/IP environment Client performance issues, and WINS server redundancy and replication requirements, determine the required number and placement of WINS servers

In a routed LAN, it is best to position servers to minimize cross-subnet query and registration traffic, and to maximize performance and fault tolerance for client queries

In a geographically dispersed wide area network (WAN), in which there may be restricted bandwidth between locations, you must place the WINS servers to:

Maximize client response to registrations and queries

Minimize database convergence times between WINS partners

In a multiple WINS server solution, database convergence affects decisions on replication In a LAN environment, persistent connections allow incremental replication updates Restricted bandwidth WAN environments may require the use of schedules or database change counts to trigger replication updates, which increases convergence times

Minimize the number of WINS servers required by using only as many WINS servers as you need to support all clients

Slide Objective

To describe the factors to

consider when designing a

WINS service for a routed

network

Lead-in

In a routed network, you

need to position WINS

servers to provide the best

client performance while

reducing cross-router traffic

Emphasize that in a

well-designed WINS Service,

there may be no NetBIOS

broadcast traffic unless a

failure occurs or non-WINS

clients are used

Stress the fact that although

students may design with

convergence as the primary

issue, they must consider

connection and replication

traffic issues if the WAN

bandwidth is low

Important

Supporting WINS Clients

WINS Server

WINS Client Windows 2000 Router

WINS Server

WINS Client Subnet 1

Subnet 2

Subnet 3

WINS Clients

Unicast communications through routers

Router

All versions of Windows support a WINS client, resulting in reduced broadcast traffic

WINS Client Features

The WINS client in Windows 2000 provides the following features:

Communication with a WINS server by using unicast packets to reduce broadcast traffic

Support of up to 12 WINS servers for redundancy

Earlier Windows versions support either one or two WINS servers

Support for multiple node types as defined in RFC 1001

WINS Client Considerations

When designing a WINS Service that supports WINS clients, consider doing the following:

Specifying multiple WINS servers for clients to provide service redundancy

Increasing the NetBIOS name registration renewal period—the default is six days—to reduce client-to-server renewal traffic

Slide Objective

To describe the features of

the WINS client and the

design considerations for a

WINS service that supports

WINS clients

Lead-in

All versions of Windows

provide a WINS client

component, which aids in

the reduction of broadcast

traffic

Note

Supporting Non-WINS Clients

Non-WINS Client

Non-WINS Client

WINS Client with WINS Proxy Agent

Subnet 1

Subnet 2

WINS Clients

Windows 2000 Router with WINS Proxy Agent

Broadcast

Unicast

Subnet 3

WINS Server

Router

For resources not on the local subnet, non-WINS clients that use NetBIOS need

to have name registrations and requests resolved Name services extended to these hosts deal with both registration and resolution issues

You can use any combination of the following methods to support these WINS clients:

non-
Including WINS Proxy Agents on the subnet containing non-WINS clients

Including static WINS or Lmhosts entries to enable remote name resolution

Enabling NetBIOS broadcast traffic across all routers

WINS Proxy Agent

The WINS Proxy Agent receives the broadcast-based NetBIOS name service interaction from non-WINS clients and forwards the requests to a WINS server The WINS Proxy Agent:

Ensures unique NetBIOS names within the routed network

Extends name resolution services to the non-WINS clients

By default, does not register the resource names with WINS

You can configure any WINS client to provide WINS Proxy Agent functionality to a network segment Any subnets that contain non-WINS clients, and do not have any WINS servers, need to have at least one WINS Proxy Agent

If you plan multiple WINS Proxy Agents on a single segment for redundancy, keep them to a minimum, because all WINS Proxy Agents on the network segment forward each non-WINS client request to the server

Slide Objective

To describe how to provide

support for non-WINS

clients in a routed network

Lead-in

You can extend WINS name

resolution services to hosts

that use NetBIOS but are

not WINS-enabled

Note

Static WINS and Lmhosts Entries

Non-WINS client registrations are not added to the WINS database automatically To resolve these resources network-wide, you must manually add the registrations as a static entry to the WINS database, or include them in client Lmhosts files

Static name entries for non-WINS resources that are added to the WINS database allow WINS clients to resolve these resources

In Windows-based computers that use TCP/IP, entries to resolve remote resource names are made in an Lmhosts file To minimize administration of multiple Lmhosts files, you can enter resource names in a centrally maintained Lmhosts file referenced as a #INCLUDE in the client Lmhosts file

NetBIOS Broadcasts Across Routers

Enabling NetBIOS broadcasts across all routers in a network allows operation without WINS, but is not recommended, because it increases the size of the broadcast domain This would only be considered a viable solution for small network designs

Supporting Multiple WINS Servers

hub and spoke replication minimizes convergence times

hub and spoke replication minimizes convergence times

WINS clients access multiple WINS Servers

WINS clients access multiple WINS Servers

push/pull

push/pull Subnet B

WINS-B 192.168.3.5

WINS-C

WINS-E

WINS-D

WINS-A 192.168.2.5

TCP/IP Settings for WINS Clients on Subnet B

First WINS Server: 192.168.3.5 Second WINS Server: 192.168.2.5

Multiple WINS servers distribute the NetBIOS name service across LAN and WAN environments, confining WINS client traffic to localized areas To ensure consistent network-wide name resolution, WINS servers must replicate their locally acquired entries to configured partners

WINS Replication

You can configure WINS replication by using:

Scheduled push or pull intervals

Push, pull or push/pull partners

Automatic partner discovery with a two-hour schedule over a multicast group (224.0.1.24)

Multicast announcements between WINS servers add traffic to your network Automatic partner replication is recommended only if you have a small number of installed WINS servers (typically, three or fewer) on the reachable network

Push updates based on the number of changes to the database

Convergence Time

Convergence time is the time it takes for a new entry in a WINS database to be replicated from the originating WINS server to all other partner WINS servers When planning placement and replication for WINS servers, you must decide

an acceptable convergence time for your network

Slide Objective

To describe the use of

WINS database replication

in multiple server

environments

Lead-in

When you use multiple

WINS servers within a

network, replication is used

to synchronize the

databases

Key Points

The recommended

configuration for WINS

replication is push/pull with

hub and spoke

Caution

To minimize replication paths and convergence times:

Select push/pull when planning replication partners Avoid the use of limited replication partnerships (push only or pull only) between WINS

servers, unless required for slow WAN links

Select persistent connections between partners to improve replication performance in high-bandwidth networks

Plan for a hub-and-spoke model for WINS replication This provides the shortest convergence times