RAS & hardware

[paras]

Have to setup remote access for approximately 13 users into the local LAN. There is a gateway that runs DHCP for connecting clients. The gateway is Vicom Internet Gateway. It supports RAS.

The gateway is dunning on Windows NT 4.0. The 13 outside clients who need remote access need TCP/IP connections via 56K V.90 modem over analog voice lines.

Wanted to know just how many modems are needed to connect to the Windows 98 systems for sufficient connection. Would 8 modems suffice? Or should we go in for a modem pool?

Is there a thing such as a 8-port modem?...or do we need a 8-port serial host card and connect 8 separate external modem devices?

Can someone suggest hardware setup and manufacturers that supply the needed components.

Also, if there is an alternate solution to this requirement, we are open to it.

[paras]

hi there guys.

i just found the answer with a bit of R&D. thanks anyways.

here is what i put in for others to understand should they come to this forum :)

----------------------------
For RAS clients, the RAS server must have one or more NT-compatible modems attached to an available serial port. You will need a separate phone line for each modem. There are over a 1000 listed modems which are NT-compatible. Most of the well-known international brands have such modems.

However, when you setup RAS on NT server that has a large number of modems attached, setup may take extended amount of time to add all attached modems and complete the setup. This slowdown occurred when using the modem installer during the RAS setup procedure and was caused by the method used by setup to enumerate each modem. This was a problem with NT 4.0 but in the latest U.S. Service Pack for NT 4.0, it has been resolved.

Note: You can also setup RAS through ISDN lines or X.25 connections. Whatever you choose, always check the Hardware Compatibility List (HCL).

For better performance, from multiple modems, attach to the RAS server an NT-compatible multiport serial card. DigiBoard is one manufacturer of this type of hardware. There are only about 15 cards that are certified as NT-compatible and most of them are DigiBoard.

Remember that default COM 2 interrupt (IRQ3) has slightly higher priority than the COM 1 interrupt (IRQ4). If you have two serial ports, use COM 2 for your higher-speed serial device (such as high-speed modems).

All RAS communication devices must be installed, configured, connected and powered up before installing RAS.

Another thing is that the remote clients may have static IPs and if you are using a DHCP, make sure that it is not leasing out IP addresses to clients which cause a conflict with these IP addresses. You could consider configuring the remote clients with this DHCP.

Another alternative device that supports multiple RAS clients is a machine that is nothing but many modems (like 15) that are configured together into one box. I do not know brands that manufacture this but I know they exist and I think DELL has some of these. You would need to call the hardware manufacturers for further information on this stuff. Cost may be one of your considerations however, when doing this.

Microsoft integrated several new technologies into NT 4.0's RAS that greatly enhance and extend its functionality. One new technology is the Multilink dialing feature, which lets an NT 4.0 RAS client make multiple physical connections (via multiple RAS devices) and combine them into one logical connection. This feature is a boon to all RAS users because it provides a way to get virtually unlimited bandwidth on a RAS connection. For example, you can use two 28.8Kbps modems in a Multilink RAS connection to create an effective bandwidth of 57.6Kbps. Multilink dialing also benefits ISDN users, who can now take advantage of both ISDN B channels to create 128Kbps ISDN connections. You can even combine ISDN and analog modem connections in a Multilink RAS connection.

But both the RAS client and the RAS server must support Multilink RAS or Multilink PPP (MPPP). For example, if you use RAS to connect to your Internet Service Provider (ISP) but it doesn't support Multilink connections, Multilink RAS won't work. If you're an ISDN RAS user, you probably can take advantage of the Multilink dialing feature because MPPP was originally developed with the ISDN community in mind and most ISP and corporate routers are MPPP capable. Analog modem users face tougher odds, however, because most ISPs don't currently use NT Server 4.0 or have MPPP support for modem-based connections.

Once you find a compatible server to connect with, implementing Multilink RAS in NT 4.0 is a simple matter. To use multiple RAS devices to dial a phonebook entry, edit the phonebook entry and go to the Basic tab. In the Dial Using section, choose Multiple Lines.

Select the devices you want and the phone numbers the devices will dial. After you make a Multilink RAS connection, NT automatically bundles the lines into one logical connection, and you're off and running.

Another option you can consider is PPTP Virtual Networks. NT 4.0's RAS includes a beneficial new network protocol, the Point-to-Point Tunneling Protocol (PPTP). Despite all the talk about this new protocol, many users are still unclear about what PPTP is and what it does. In a nutshell, PPTP is a WAN protocol that lets a RAS client and server establish a secure connection over a TCP/IP connection such as the Internet.

Here's how PPTP works: First, a remote user establishes a connection to an IP-based internetwork (e.g., the Internet). Next, the user makes a second connection to an NT 4.0 RAS server running PPTP. The result is what Microsoft calls a VPN that uses PPTP over TCP/IP.

With a regular PPP-based RAS connection (the kind you're probably used to), RAS clients communicate with the RAS server by transmitting LAN protocols such as NetBEUI, IPX, and TCP/IP inside PPP packets over analog, ISDN, or X.25 switched connections. However, rather than using a switched connection, PPTP uses your existing IP network connection (e.g., your connection to the Internet) as its WAN protocol to communicate with a PPTP-enabled RAS server. The "tunneling" part of PPTP's name comes from the fact that any of the LAN protocols can be encapsulated (or tunneled) inside PPTP packets. For example, with PPTP you can create a NetBEUI or an IPX-based connection to a corporate network over the Internet. If you explicitly enable encryption, PPTP encapsulates and encrypts the data in PPP packets and sends them as IP-based packets to the RAS server (as shown in Figure 1). Because the packets are encapsulated and encrypted, they are safe from prying eyes--an obvious concern for organizations that send data over the Internet.

The ramifications of this new technology are astounding. Now for the first time, organizations can leverage the Internet as a WAN backbone for secure remote network connections. This capability can provide substantial savings for businesses, compared to the cost of creating a private WAN over specialized equipment and dedicated lines. PPTP puts WAN connectivity within the reach of many smaller organizations that simply can't afford a private WAN.

Another interesting twist PPTP creates is the ability to physically separate the RAS server from remote access hardware. Organizations can outsource their dial-up network to a communications server or an ISP and maintain on their premises
only a RAS server running PPTP. The service provider supplies dial-up connections to a PPTP-enabled NT RAS server, which in turn connects to the client organization's RAS PPTP server over an Internet-based PPTP tunnel. The client organization benefits because it no longer needs to maintain any remote access equipment. Using a service provider also enables non-PPTP-capable systems (e.g., systems not running NT 4.0) to make secure connections over standard PPP--the service provider's server maintains the secure PPTP connection to the RAS server on the client's behalf. In some cases, this approach also lets remote clients use local phone numbers rather than long distance or expensive 800 numbers to access the RAS server (depending on the access numbers the ISP provides).
This facet of PPTP opens up a new outsourcing service opportunity for ISPs.
So what's the bad news? Well none, except that Microsoft currently supports PPTP on only NT 4.0: An NT 4.0 machine must be on each end of the connection. I expect Microsoft will eventually release a PPTP stack for its other operating systems, although I've found no information about expanded support.

The MS documentation on PPTP falls woefully short. The general descriptions of the technology are good, but the step-by-step details on setting up and connecting PPTP sessions are conspicuously absent. With that shortcoming in mind, here are a few tips for configuring and connecting RAS PPTP sessions.

The first step is to install the PPTP protocol via Control Panel's Network applet. In the Protocols tab, choose Add, and then select Point-to-Point Tunneling Protocol. Enter the maximum number of VPNs you want to let PPTP support (each RAS connection over PPTP constitutes one VPN). Because PPTP is implemented as a virtual RAS device, you also need to reconfigure RAS on your machine (in the Network applet's Services tab) and add your new PPTP RAS adapter. When you click Add for a new RAS device, you see a new choice in the RAS Capable Devices list that says RASPPTPM (or something similar); select and install this device.

Then you need to configure a dial entry to use it. First, select the protocols (IP, IPX, and NetBEUI) you want to tunnel over the PPTP connection (all selected protocols must be installed on the RAS PPTP server). Next, you must tell the dial entry how to connect to the PPTP RAS server. Enter the IP address of the PPTP RAS server in the phone number box (in the Basic tab) to enable the PPTP dial entry to find and connect to the server. (The documentation fails to tell you to do this step.)

Now you're ready to make the PPTP connection. First, use a DUN entry to dial the IP-based connection that both your PC and the PPTP RAS server are connected to. When you've made this connection, use your PPTP phonebook entry to dial.
You must enter a username, password, and domain name to make the connection. Once these items are authenticated, you're on the network. Furthermore, you're communicating via the network protocols you selected in the PPTP entry's configuration, such as IPX or NetBEUI (not necessarily TCP/IP, unless that's one of the protocols you selected to tunnel; you can tunnel IP within IP using PPTP).

Another important new feature of NT 4.0's DUN is AutoDial, a dial-on-demand feature that lets NT automatically offer to dial a remote network connection via DUN when an application (or the user) attempts to access data on that network.
For example, if your Internet mail program tries to access your ISP's mail server and you aren't connected, a dialog similar to the one in Screen 3 appears, and asks whether you want DUN to connect to the remote network. If you don't answer within 15 seconds, AutoDial applies the default answer: No, do not dial. AutoDial is intelligent; it remembers which DUN entries it uses to make which connections. So, if you answer "Yes" to the do-you-want-to-connect question, AutoDial completes the appropriate connection. This entire process is transparent to the background application that requests the data, and after the connection is made (assuming the program hasn't issued a time-out message), the application can then access the requested data.

Although the AutoDial feature is usually helpful, in some situations it's a nuisance. If an application running in the background continually attempts to connect to a remote machine on a network you don't really want to connect with at that moment, you'll quickly tire of the returning dialog that asks whether to dial the remote network. In this case, you can disable AutoDial for the current session by selecting the appropriate check box in the returning dialog. You also can configure AutoDial via several options: For example, you can disable AutoDial completely, or you can disable its prompt and have it automatically dial the remote connection without asking. You can also permanently disable the RAS AutoDial feature or disable it from only certain dialing locations. You can set up AutoDial to automatically redial on a link failure, an especially handy feature for NT systems that act as RAS routers to the remote networks or the Internet. To find these options, click the "More" button on the DUN main dialog and choose the User Preferences menu option.

When a RAS server is set to allocate IP addresses from DHCP, it grabs n+1 addresses when the service starts, (where n is the number of dial-up interfaces), and keeps them. Therefore, the lease time is largely irrelevant. When a client dials in, the RAS server issues one of these cached leases and the RAS server maintains the lease on behalf of the client. The RAS server only records the address of the DHCP server and the lease parameters. All other DHCP options are discarded.

You may notice that, if you use IPCONFIG or WINIPCFG on a RAS client to look at lease information, it has null dates (ie. Jan 1, 1980). When the client disconnects, the IP address will be released back to the RAS server, NOT back to the DHCP server. This causes a lot of confusion when people expect to get their IP addresses back to the DHCP server. These will only be released back to DHCP when the RAS service is stopped and then the lease expires in due course.

Check this out for further information. http://www.geocities.com/SiliconValley/Monitor/3131/ntserver/nt_core12.html http://www.kmj.com/chase/pciras.html

Go through this. It is quite important for the requirement. http://www.ntfax.com/NAMultiport.htm

More information: http://www.win2000mag.com/Articles/Index.cfm?ArticleID=5868 http://www.win2000mag.com/Articles/Index.cfm?ArticleID=568 http://www.windows2000faq.com/Articles/Index.cfm?ArticleID=14702 http://www.windows2000faq.com/Articles/Index.cfm?ArticleID=14685
:)