 | LIKE our fanpage 'BE YOURSELF!' |
|
Microsoft TCP/IP
Microsoft Windows operating systems support three network transport protocols: • NetBIOS Frame protocol (NBF). • NWLink. • TCP/IP. DLC: Supports network-attached printers. These protocols are integrated using two technologies: • The Network Driver Interface Specification (NDIS). • The Transport Driver Interface (TDI). The Microsoft Network Protocol Architecture:
Figure 127.shows the Microsoft Network Protocol Architecture. NDIS and TDI act as the unifying layers that enable Microsoft workstations to support multiple protocol stacks over a single network interface. At the lowest level of the protocol stack model are network interface adapters and the driver software that enables them to connect with upper layers. NDIS is a standard interface between the MAC layer protocols and the network layer. At the MAC layer, NDIS provides a well-defined interface that enables vendors to write drivers for their network interface products. NDIS also provides a standard protocol layer that upper-layer protocols can use, enabling multiple NDIS-compliant network layer protocols to interface with any NDIS-compliant network adapter. NDIS enables a computer to support multiple network adapters, which might be of the same or mixed type. These adapters communicate with the same upper-layer protocol stacks, mediated by the NDIS interface. The Transport Driver Interface (TDI) defines a protocol interface between session layer protocols and the transport layer. Transport protocols, therefore, can be written to standard interfaces both above (TDI) and below (NDIS) in the protocol stack. Above the TDI, Microsoft provides support for two Application Programming Interfaces (API’s). NetBIOS is the historic API for Microsoft network products. On the other hand, the standard API for TCP/IP applications is Berkeley sockets, which Microsoft has implemented as Windows Sockets. For environments that choose to implement TCP/IP without NetBEUI, and to support the non-routable NetBIOS protocols over internetworks, Microsoft has provides a NetBIOS over TCP/IP (NBT) feature that enables NetBIOS applications to access the TCP/IP transport. An efficient protocol that functions well in local networks, part of Windows NT. NBF is compatible with the earlier NetBEUI implementations found in LAN Manager and Windows 3.x.
• Unreliable connectionless communication (datagram). • Reliable connection-oriented communication (virtual circuit). reliable connectionless mode is unavailable. Connection-oriented communication is used in many situations on peer-to-peer networks. NBF depends heavily on broadcast messages, however, to advertise network names. When a NetBIOS computer enters a network, it broadcasts a message announcing its name to ensure that no other computer on the network already has the same name. This essential NetBIOS mechanism fails in internetworks because broadcasts do not cross routers. Ordinarily, therefore, NBF is restricted to non-routed networks. Is a Microsoft implementation of the two protocols (IPX and SPX) that are the standard transport on NetWare networks. • Internetwork Packet eXchange (IPX): Is a datagram network layer protocol that services as the primary workhorse on NetWare LAN’s. The majority of NetWare services operate over IPX. • Sequenced Packet eXchange (SPX): Is an optional transport-layer protocol that provides connection-oriented, reliable message delivery. IPX is a routable protocol, and NWLink can be used to construct routed networks using Microsoft products. The network/hardware address mechanism differs significantly from the mechanism used for IP. IPX uses sockets to direct messages to and from the correct upper-layer processes. In most cases, upper-layer functions are performed by the NetWare Core Protocols (NCP), which provides network services at the session, presentation, and application layers. NCP is not part of NWLink, although Microsoft has implemented a NetWare client requester that implements the client side of NCP. The IPX/SPX protocols offer high performance, because node ID’s need not be maintained manually. Use of IPX/SPX, however, has been confined primarily to the NetWare environment. Microsoft has been including TCP/IP support in network products since LAN Manager. TCP/IP was Microsoft's choice as a notable protocol for use when the non-routable NetBEUI was not functional. DHCP is based on DHCP servers, which assign IP addresses, and DHCP clients, to which addresses are assigned. A single DHCP server can supply addresses for more than one network. To support DHCP on an internetwork, routers must be configured with BOOTP forwarding. The DHCP servers maintains pools of IP addresses, called scopes. When a DHCP client enters a network, it request and is granted a lease to use an address from an appropriate scope. The concept of leasing is important, because DHCP clients are not ordinarily granted permanent use of an address. Instead, they receive a lease of limited duration. When the lease expires, it must be renegotiated. This approach ensures that unused addresses become available for use by other clients. DHCP can be configured to assign specific addresses to specific hosts, which enables administrators to use DHCP to set host protocol options while retaining fixed address assignments. Several types of hosts must be assigned fixed, manual addresses so that other hosts can enter the addresses into their configuration, including, among others, the following examples: Routers (Gateways), WINS servers, and DNS servers.
Figure 128 shows priority of DHCP options. The primary naming system for Microsoft networks is based on NetBIOS names. Each computer on the network is configured with a name that it broadcasts to the network make its presence known to all other computers on the local network. This system is easy to maintain because whenever a computer inserts itself into the network, the global name database is updated. This system works well on local networks on which all protocols are supported by Microsoft network products. Microsoft operating systems configured using only TCP/IP protocols can use NetBIOS names within the context of a local, non-routed network. A significant limitation of NetBIOS naming in a TCP/IP environment is that the names do not propagate across routers. NetBIOS names are disseminated using broadcast datagrams, which IP routers do not forward. The NetBIOS names on one network, therefore, are invisible to computers on networks connected via routers. The Microsoft LAN Manager products supported internetwork name resolution using static naming tables stored in files named LMHOSTS. An LMHOSTS file is a text file that contains mappings between NetBIOS names and IP addresses. To enable computers on the internetwork to resolve names, a network administrator had to manually update the LMHOSTS file and distribute it to all computers on the Internet. This was a distinctly labour-intensive method of maintaining NetBIOS naming. Like LMHOSTS, Windows Internet Name Service (WINS) maintains a NetBIOS global naming service for TCP/IP internets. Unlike LMHOSTS, WINS is dynamic, extending the automatic configuration of the NetBIOS name directory from local networks to internets. The WINS database is updated automatically as NetBIOS computers insert and remove themselves from the network. Using WINS in conjunction with DNS is possible, which would enable WINS to provide DNS with host names for Microsoft-based hosts within your network. Resolving Names on Microsoft Networks: Resolution is the process of associating host names with addresses. Resolution of NetBIOS names on TCP/IP environments is the responsibility of the NetBIOS over TCP/IP (NBT) service. NBT name resolution has evolved from a basic, broadcast-based approach to the current name-service approach. Before discussing WINS, it is necessary to examine the name resolution modes supported by NBT. • B-node: Is the oldest method employed on Microsoft networks, name resolution using broadcast messages. When Host A needs to communicate with Host B, it sends a broadcast message to interrogates the network for the presence of Host B. If Host B receives the broadcast, it sends a response to Host A that includes its address. If Host A does not receive a response within a preset period of time, it times out and the attempt fails.
Figure 129 shows B-node name resolution. It works well in small, local networks, but poses two disadvantages that become critical as networks grow: • As the number of hosts on the network increases, the amount of broadcast traffic can consume significant network bandwidth. • IP routers do not forward broadcasts, and this technique cannot propagate names through an internetwork. B-node is the default name resolution mode for Microsoft hosts not configured to use WINS for name resolution. In pure B-node environments, hosts can be configured to use LMHOSTS files to resolve names on the networks. • P-node: Is used for name resolution. P-node computers register themselves with a WINS server, which functions as a NetBIOS name server. The WINS server maintains a database of NetBIOS names, ensures that duplicate names do not exist, and makes the database available to WINS clients.
Figure 130 shows P-node name resolution. Each WINS client is configured with the address of a WINS server, which may reside on the local network or on a remote network. WINS clients and servers communicate via directed messages that can be routed. No broadcast messages are required to P-node name resolution.
• All computers must be configured using the address of a WINS server, even when communicating hosts reside on the same network. • If a WINS server is unavailable, name resolution fails for P-node clients. • M-node: computers first attempt to use B-node name resolution, which succeeds if the desired host resides on the local network. If B-node resolution fails, M-node hosts then to use P-node to resolve the name. M-node enables name resolution to continue on the local network when WINS servers are down. B-node resolution is attempted first on the assumption that in most environments, hosts communicate most often with hosts on their local networks. When this assumption holds, performance of B-node resolution is superior to P-node. Recall, however, that B-node can result in high levels of broadcast traffic. Microsoft warns that M-node can cause problems when network logons are attempted in a routed environment. • H-node: Is the default for Microsoft TCP/IP clients configured using the addresses of WINS servers. As a fallback, Windows TCP/IP clients can be configured to use LMHOSTS fields for name resolution. Nodes configured with H-node, however, first attempt to resolve addresses using WINS. Only after an attempt to resolve the name using a name server fails does an H-node computer an attempt to use B-node. H-Node computers, therefore, can continue to resolve local addresses when WINS is unavailable. When operating in B-node, H-node computers continue to poll the WINS server and revert to H-node when WINS services are restored. Architecture of the Windows Internet Name Service (WINS): WINS uses one ore more WINS servers to maintain a database that provides name-to-address mappings in response to queries from WINS clients. WINS is a particularly got fit when IP addresses are assigned by DHCP. Although the DHCP lease renewal process results in a certain stability of IP address assignments. IP addresses can change if hosts are moved to different networks or if a hosts is inactive for a time sufficient to cause its address to be reassigned. WINS automatically updates its database to respond to such changes. Because WINS clients communicate with WINS servers via directed messages, no problems are encountered when operating in a routed environment.
Figure 131 shows the architecture of a WINS name service. WINS proxies enable non-WINS clients to resolve names on the internetwork. When a WINS proxy receives a B-node broadcast attempting to resolve a name on a remote network, the WINS proxy directs a name query to a WINS server and returns the response to the non-WINS client. WINS makes maintaining unique NetBIOS names throughout the Internet possible. When a computer attempts to register a NetBIOS name with WINS, it is permitted to do so only if the name is not currently reserved in the WINS database. Without WINS, unique names are enforced only through the broadcast B-node mechanism on local networks. • When a WINS client is shut down in an orderly manner, it releases its name reservation in the WINS database and the name is marked as released. After a certain time, a released name is marked as extinct. Extinct names are maintained for a period of time sufficient to propagate the information to all WINS servers, after which the extinct name is removed from the WINS database. • If a computer has released its name through an orderly shutdown, WINS knows that the name is available and the clients can immediately reobtain the name when it reenters the network. If the client has changed network addresses, by moving to a different network segment, a released name can also be reassigned. • If a computer is not shut down in an orderly fashion, its name reservation remains active in the WINS database. When the computer attempt to reregister the name, the WINS server challenges the registration attempt. If the computer has changed IP addresses, the challenge fails and the client is permitted to reregister the name with its new address. If no other computer as actively using the name, the client is also permitted to reregister with the name. • All names in the WINS database bear a timestamp that indicates when the reservation will expire. If a client fails to reregister the name when the reservation expires, the name is released. WINS supports definition of static assignments that do not expire. Any Windows NT server computer can be configured as a WINS server, except WINS servers cannot receive their IP address assignment from DHCP. WINS clients communicate with WINS servers via directed datagrams, and you do not have to locate a WINS server on each network segment. However, non-WINS clients are supported only if at least one WINS proxy is installed on each network or subnetmask. Multihomed computers should not be configured as WINS server. A WINS server may register its name with only one network. The name of a multihomed WINS server, therefore, cannot be registered with all attached networks. Also, some client connection attempts fail with multihomed WINS servers. WINS recognises a variety of special names, identified by the value of the 16th byte of LAN Manager-compatible names. Special names are encountered when setting up static mappings and when examining entries in the WINS database. • Multihomed Names: A multihomed name is a single computer name that stores multiple IP addresses, which are associated with multiple network adapters on a multihomed computer. Each multihomed name can be associated with up to 25 IP addresses. This information is established when TCP/IP configuration is used to specify IP addresses for the computer. When the WINS server service is running on a multihomed computer, the WINS service is always associated with the first adapter in the computer configuration. All WINS messages on the computer, therefore, originate from the same adapter. Multihomed computers with connections to two or more networks should not be configured as WINS servers. If a client attempts a connection with a multihomed WINS server, the server might supply an IP address on the wrong network, causing the connection attempt to fail. • Normal Group Names: Are tagged with the value 0x1E in the 16th byte. Browsers broadcast to this name and respond to it when electing a master browser. In response to queries to this name, WINS always returns the broadcast address FF.FF.FF.FF. • Internet Group Names: An internet group is used to register Windows NT server computers in internet groups, principally Windows NT server domains. If the Internet group is not configured statically, member computers are registered dynamically as the enter and leave the group. Internet group names are identified by the value 0x1C in the 16th byte of the NetBIOS name. An internet group can contain up to 25 members, preference being given to the nearest Windows NT server computers. On a large internetwork, the Internet group register the 24 nearest Windows NT server computers plus the primary domain controller. • Other Special Names: 0x0 identifies the redirector name of a computer. 0x3 identifies the messenger service name, used to send messages. 0x1B identifies the domain master browser, which WINS assumes is the primary domain controller. If it is not. the domain master browser should be statically configured in WINS. 0x1 identifies _MSBROWSE_, the name to which master browsers broadcast to announce their domains to other master browsers on the local subnet. Having two or more WINS servers on any network is desirable. A second server can be used to maintain a replica of the WINS database that can be used if the primary server fails. On large internetworks, multiple WINS servers result in less routed traffic and spread the name resolution workload across several computers. Pairs of WINS servers can be configured as replication partners. WINS servers can perform two types of replication actions: Pushing and pulling. And a member of a replication pair functions as either a push partner or a full partner. All database replication takes place by transferring data from a push partner to a pull partner. But a push partner cannot unilaterally push data. Data transfers may be initiated in two ways. • A pull partner can initiate replication by requesting replication from a push partner. All records in a WINS database are stamped with a version number. When a pull partner sends a pull request, it specifies the highest version number that is associated with data received from the push partner. The push partner then sends any new data in its database that has a higher version number than was specified in the pull. • A push partner can initiate replication by notifying a pull partner that the push partner has data to send. The pull partner indicates its readlines to receive the data by sending a pull replication request that enables the push partner to push the data. Pulls generally are scheduled events that occur at regular intervals. Pushes generally are triggered when the number of changes to be replicated exceeds a specified threshold. An administrator, however, can manually trigger both pushes and pulls. WINS performs a complete backup of its database every 24 hours. If users cannot connect to a server running the WINS server service, the WINS database probably has become corrupt. In that case, you might need to restore the database from a backup copy.
Figure 132 shows a network with several WINS replication partnerships. Browsers, however, maintain databases only of host names. Addresses must still be derived from a name resolution process. Browsing works somewhat differently on TCP/IP networks than on networks running NetBIOS and NWLink, although the difference becomes apparent only when routing is involved. Windows browsing is based on browse lists, which catalogue all available domains and servers. Browse lists are maintained by browsers. By default all Windows NT server computer are browsers. Windows NT workstations computers are potential browsers, and can become browsers if required. Each domain has one master browser that serves as the primary point for collecting the browse database for the domain. Servers, any computer that offers shared resources, that enter the network transmit server announcements to the master browser to announce their presence. The master browser uses these server announcements to maintain its browse list. Backup browsers receive copies of the browse list from the master browser at periodic intervals. She introduce redundancy to the browsing mechanism and distribute browsing queries across several computers. An election process among the various browsers determines the master browser. In domains, the election is biased in favour of making the Primary Domain Controller (PDC) the master browser, which always is the master browser if it is operational. All Windows NT server computers function as master or backup browser. Windows NT workstations can function as browsers. In the presence of sufficient Windows NT server computers, no Windows NT workstation will be configured as browsers. When no Windows NT server computers are available, at least two Windows NT workstations computers will be activated as browsers. An additional browser will be activated for every 32 Windows NT workstation computers in the domain. Severs must announce their presence to the master browser at periodic intervals, starting at one minute intervals and increasing to 12 minutes. If a server fails to announce itself for three announcement periods, it is removed from the browse list. Therefore, up to 36 minutes may be required before a failed server is removed from the browse list. Domains are also maintained in the browse list. Every fifteen minutes, a master browser broadcast a message announcing its presence to master browsers in other domains. If a master browser is not heard for three 15-minutes periodes, other master browsers remove the domain from their browse list. Thus, 45 minutes may be required to remove information about another domain from a browse list. Internetworks based on NetBIOS and NWLink protocols can route broadcast name queries across routers. Maintaining a single master for each domain, therefore, is necessary. Internetworks based on TCP/IP cannot forward broadcast queries between networks. Therefore, Microsoft TCP/IP networks maintain a master browser for each network or subnetmask. If a domain spans more than one network or subnetwork, the domain master browser running on the PDC has a special responsibility of collecting browse lists from the master browser on each network and subnetwork. The domain master browser periodically rebroadcasts the complete domain browse list to the master browser, which in turn update backup browsers on their networks. Therefore, significant time might be required to disseminate browsing data through a domain on a large TCP/IP internetwork. The browsing service is a convenience but is not required to enable clients to access servers on the internetwork. Clients processes still can use shared resources by connecting directly with the Universal Naming Convention (UNC) name of the resource. On a TCP/IP internetwork, that makes WINS a near necessity. Browsing, on the other hand, is very convenient but is not essential. Multihomed hosts often present an ambiguous face to the network community. Different hosts can use different IP addresses to access services running on the host, with unpredictable results. One case in which this unpredictability seems to appear is browsing when the PDC for a domain is multihomed. Clients are not hard-wired with the address of browsers, and a multihomed browser appears to confuse things, causing various clients to see different browse lists. More consistent results seem to be obtained when the PDC has a single IP address. In any case, the PDC cannot serve as master browser for more than one network or subnetmask. Sometimes dynamic name-address mappings are not desirable. At such times, creating static mappings in the WINS database proves useful. A static mapping is a permanent mapping of a computer name to an IP address. Static mappings cannot be challenged and are removed only when they are explicitly deleted. Reserved IP addresses assigned to DHCP clients override any static mappings assigned by WINS. Static mappings for unique and special group names can be imported from files that conform to the format of LMHOSTS files. Although a complete name resolution system can be based on LMHOSTS files, static naming files can be a nightmare to administrator, particularly when they must be distributed to several hosts on the network. Nevertheless, LMHOSTS files may be necessary if WINS will no be run on a network or if having a backup is desirable in case the WINS service fails. Although LAN manager host files supported little more than mappings of NetBIOS names to IP addresses, Windows NT offers several options that make LMHOSTS considerably more versatile. The basic format of an LMHOSTS file is as follow:
IP-address Name 134.67.32.0 Logon-Server-Network-A 134.67.32.1 Host-1-Network-A 134.67.32.2 Host-2-Network-A 134.67.40.0 Logon-Server-Network-B 134.67.32.3 Host-3-Network-B 134.268.67.0 Logon-Server-Network-C 134.268.67.3 Host-3-Network-C 134.268.67.5 Host-5-Network-C Domain Name Service (DNS) is the standard naming service used on the Internet and on most TCP/IP networks. If your Windows TCP/IP network is not connected to non-Microsoft TCP/IP networks, you do not need DNS. WINS can provide all the naming services required on a Microsoft Windows Network. You need DNS if you want to connect your TCP/IP hosts to the Internet or to a UNIX based TCP/IP network, but only if you want to enable users outside the Windows network to access your TCP/IP hosts by name. Name Resolution with HOSTS Files: Before DNS, name resolution was accomplished using files named HOSTS. Supporting a naming service is a simple matter of editing a master HOSTS file and distributing it to all computers, which could be accomplished by copying the file when a user logs on to a domain, or it could be done using a software distribution system.
|
