Article ID: 169415 - Last Review: October 31, 2006 - Revision: 1.1 Routing and Remote Access Release Notes Readme.doc FileThis article was previously published under Q169415 On This PageSUMMARY
This article contains the Release Notes Readme.doc file for Routing and
Remote Access Service, formerly known as Steelhead.
MORE INFORMATIONRelease Notes for Windows NT Routing and Remote Access Service June 1997*(c) 1997 Microsoft Corporation. All rights reserved.This document contains known issues for the Microsoft Routing and Remote Access Service for Windows NT Server version 4.0 release. Contents
Using WordPad to View This DocumentIf you enlarge the WordPad window to its maximum size, this document will be easier to read. To do so, click the Maximize button in the upper-right corner of the window. Or open the Control menu in the upper-left corner of the WordPad window (press ALT+SPACEBAR), and then click Maximize.To move through the document, press PAGE UP or PAGE DOWN. Or click the arrows at the top and bottom of the scroll bar along the right side of the WordPad window. To wrap words to the screen size or the ruler:
Routing and Remote Access Service DocumentationAfter you download the Routing and Remote Access Service files from the Web, documentation is available for Routing and Remote Access Service in the \Doc directory of the directory in which you choose to install the files on your computer. For example, if you choose to install the files in theC:\Program Files\Routing directory, the documentation will be available in the C:\Program Files\Routing\Doc directory.If you want to view management information through an SNMP console, you can use the .mib (Management Information Base) files supported by Routing and Remote Access Service. The .mib files are also copied to the \Doc directory, as described in the preceding paragraph. NOTE: Routing and Remote Access Service running on Windows NT Server version 4.0 is also referred to as the Windows NT router. Setup IssuesGeneral Setup Issues
For more setup information, see Chapter 2, "Installing and Configuring Routing and Remote Access Service," in the Administrator's Guide. Install Network Adapters Before Routing and Remote Access Service It is recommended that you install any network adapters or services (such as ISDN or PPTP) before installing Routing and Remote Access Service. If you install a network adapter or service after you have installed Routing and Remote Access Service, and if the adapter or service requires you to reinstall Service Pack 3, you must then update Routing and Remote Access Service. To update Routing and Remote Access Service:
During the Routing and Remote Access Service Setup, you can install Remote access service (RAS), LAN routing, Demand-dial routing, or all three. If you install LAN routing, whatever network protocols are currently installed on your computer are automatically enabled for routing. However, if you install demand-dial routing, you can choose the protocols. To do this, click Network in the Routing and Remote Access Setup dialog box. NOTE: If you cancel Setup after the dialog box in which you choose Remote Access Service (RAS), LAN routing, or Demand-dial routing, then the Oemnsvra.inf file in your Systemroot\System32 directory is the version from Routing and Remote Access Service. To install Windows NT version 4.0 RAS or a previous version of Routing and Remote Access Service, you must manually copy the file Oemnsvra.inf from your Windows NT version 4.0 CD or your Service Pack CD to your Systemroot\System32 directory. For more information on the Setup options, see Chapter 2, "Installing and Configuring Routing and Remote Access Service," in the Administrator's Guide. Routing and Remote Access Service Packet Filtering and Windows NT 4.0 TCP/IP SecurityYou can resolve the following two issues by using Network in Control Panel. On the Protocols tab, select TCP/IP Protocol and click Properties.
Routing and Remote Access Service Packet Filtering and Microsoft Proxy ServerIf you install Microsoft Proxy Server and Routing and Remote Access Service on the same computer, it is important to use caution when you configure filtering in both Microsoft Proxy Server and Routing and Remote Access Service. Packet filtering in Routing and Remote Access Service can impair the functionality of Microsoft Proxy Server in two ways:
Using DHCP Versus Static Pool Addresses on a RAS ServerIf a RAS server is connected to a LAN with multiple network numbers on the same physical wire, do not use DHCP to assign addresses to clients. Instead, use a static address pool to assign the addresses. If you use DHCP to assign addresses to RAS clients, some clients might not be able to reach other computers on the LAN that are on the same subnet.For example, say a RAS Server uses DHCP to assign addresses. For its LAN interface, it gets the address a.a.a.11 from the range a.a.a.0, with a mask of 255.255.255.0. The RAS Server also uses the DHCP server to assign addresses for its RAS address pool. It gets the addresses b.b.b.10, b.b.b.11, and b.b.b.12 from the range b.b.b.0, with a mask of 255.255.255.0. Because the DHCP server gives addresses from both ranges to computers on the LAN, other computers on the LAN will have addresses on the b.b.b.0 subnet. Although the RAS Server uses only a few addresses from the b.b.b.0 subnet, it adds a route for the whole subnet through the RAS Server interface. Therefore, RAS dial-in clients cannot reach other computers on the b.b.b.0 subnet because of this bad route. To work around this, either use a static pool on the RAS Server, or add a static route to the RAS Server for all logical subnets on your local segment. Demand-Dial Interface IssuesGeneral Demand-Dial Interface Issues:
When a demand-dial interface reconnects after the WAN link has been disconnected, an error might appear in the Event Log. Also, in Routing and RAS Admin, the Connection State for the interface is temporarily marked unreachable. The event logged in Event Viewer is the result of a timing condition and is incorrectly marked as an error. It should be marked as information because the router recovers and successfully reconnects the interface in these cases. The event logged in Event Viewer is the following:
Event ID: 20111 Source: Router Event Description: A Demand Dial connection to the remote interface <interface name> on port <port name> was successfully initiated but failed to complete successfully because of the following error: The interface is already connected. You can enable a Windows NT router to request an IP address when you connect to third-party routers through demand-dial interfaces. To enable a Windows NT router to request an IP address:
To delete an entry from the router phonebook:
IPX IssuesGeneral IPX Issues:
By default, if you have installed the IPX transport protocol, your router is an IPX router. If you want to disable IPX routing on your computer, you must disable IPX on all RIP for IPX and SAP for IPX interfaces in Routing and RAS Admin. Do not delete the NWLink IPX/SPX Compatible Transport protocol or disable the bindings for IPX in Network in Control Panel. If you do, Routing and RAS Admin will not start. To disable IPX routing:
Disable RIP or SAP Protocol: There is no way to individually remove RIP for IPX or SAP for IPX routing protocols. However, you can disable them by using the Routing and RAS Admin tool in the Start/Programs/Administrative Tools (Common) folder. To disable IPX RIP or IPX SAP on an interface:
In Routing and RAS Admin, if you do an auto-static update over an IPX demand-dial interface and the static table remains empty for the interface you are updating, check the network number of the interface. To check the network number:
To do this, copy the Nwlnkipx.sys file from the directory in which you installed the Routing and Remote Access Service files on your computer to your Systemroot\System32\Drivers directory, and then restart your computer. For more details about this problem, see the Ipxfix.txt file that is located in the \Support directory in the directory in which you installed the Routing and Remote Access Service files on your computer. OSPF IssuesGeneral OSPF Issues:
If OSPF is configured on an interface that has multiple IP addresses and you want to change one of the IP addresses, complete the following steps:
It is possible to unintentionally advertise a default route within an autonomous system (AS). If you configure the TCP/IP protocol by using Network in Control Panel and enable a default gateway, adding this same default gateway address on an OSPF interface might cause the unintentional advertisement. The problem occurs when the router is defined as an autonomous system boundary router (ASBR) and you add the interface to OSPF, then enable OSPF to run on the interface. OSPF, as a result, picks all of the non-OSPF routes that are configured on the interface and advertises them to the AS. This means that the router also picks the default route (0.0.0.0) and advertises it to the other OSPF routers. If the router that is the default gateway also runs OSPF, it will learn about the default route and thus learn that the next hop for the default route is itself. This causes the default gateway to drop all the packets destined to the default route since the next hop is its own interface. This can cause major network problems. NOTE: This can also occur when you add a static route to the address 0.0.0.0. If you still need the default route locally, you can prevent OSPF from picking it up and advertising it by adding a route filter that processes all the external routes except the default route. To add the route filter:
Use OSPF and RIP Together: If two routers use OSPF, do not use any other routing protocols between them. This is because you do not want the routers to exchange intra-area or inter-area routes through another routing protocol that were originally learned by OSPF. To work around this problem, configure only one router to listen to RIP. Configure the other router not to listen at all. To do this, you can use either of these methods:
Miscellaneous Issues
Information in this document is subject to change without notice. The names of companies, products, people, characters, and/or data mentioned herein are fictitious and are in no way intended 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. Microsoft, MS-DOS, MS, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners. | Article Translations
|

Back to the top
