Swims in to the Mainstream
In the Pacific Northwest, some rainbow trout move from rivers to the
open water--large lakes or even saltwater. At that point, they're no longer
rainbow trout. They're called steelhead trout, Oncorhybchus Mykiss.
They're still good eating, but they're a fight, and you have to watch for bones.
Microsoft's Routing and Remote Access Service (RRAS) is the newest version
of its Multi-Protocol Routing (MPR) software for Windows NT Server. Before
release in June, the product was code-named Steelhead, and it has a few things
in common with the fish. For one thing, MPR software has moved from a very basic
routing system that Microsoft never intended for heavy-duty use--more suited to
the smaller tributaries and woodland streams of most intranets--to (Microsoft
claims) enough routing power to take on jobs dedicated routers currently do. (Or
perhaps the ichthyological name shows that it scales well--sorry, couldn't
resist.)
With a new version of MPR, I decided to revisit a subject that I covered in
several columns in 1996--using NT Server as a LAN/WAN Internet router for a
small C class or Classless Inter-Domain Routing (CIDR) network. But RRAS does
more than make existing NT routing tasks easier; it adds new capabilities,
including single-seat router administration, greater speed, support for Open
Shortest Path First (OSPF) routing, integration with Point-to-Point Tunneling
Protocol (PPTP), and packet filtering.
The Test Spawning Ground
I tested the Steelhead beta software, which Microsoft released as RRAS as I
finished writing this article. The scenario I tested was basic, what Microsoft
calls "home-office LAN" in the Steelhead documentation.
Figure 1 shows the configuration.
Suppose you have a small business (or a small part of a large business) and
want to connect your local LAN to the Internet over a dial-up connection. You
could always do this with NT, but doing so was a bit of a pain. Steelhead makes
it easier for the NT Server to act as your LAN/WAN Internet router. The solution
isn't perfect, but it's an improvement.
I started with a C network, or CIDR block of addresses, from my Internet
Service Provider (ISP). To set up a router with NT, I also needed a machine with
at least 32MB of RAM, NT Server 4.0, Service Pack 2 (SP2), Steelhead beta 2, a
modem, Integrated Services Digital Network (ISDN) or other Remote Access Service
(RAS)-capable connection, and a network card. Other PCs on my local network have
network cards, and I had to configure them with IP addresses from the block my
ISP provided.
First, I set up all the PCs on the LAN with the ISP-provided IP addresses.
This step is important: Each machine must have a separate and distinct,
honest-to-goodness Internet address. Do not make up addresses, and do not use
the non-routable addresses. (A surprising number of people email me looking for
help in setting up their routers, and the problem turns out to be that they just
made up some IP addresses.)
Then, I set up the NIC on the router PC and gave it an ISP-supplied
address. The router PC eventually ends up with two IP addresses, one for the NIC
and another for the RAS connection to the ISP. I installed a fresh copy of NT
Server 4.0 on the router machine from the distribution CD-ROM. I did not install
RAS, because Steelhead removes RAS before installing. I pointed all the PCs'
default gateways to the IP address on the router PC's NIC. Then I made sure that
all the PCs on the LAN could ping each other. With that done, I knew the LAN
worked properly.
I installed SP2 on the router PC; yes, that's SP2, because SP3 didn't work
with Steelhead and my dial-up configuration. Microsoft fixed this problem for
the final release, and RRAS requires SP3. I then installed Steelhead. It arrived
as one EXE file but expanded to several files that install with the command
mprsetup <directory> where <directory> is the directory that those
files reside in. The setup program offers check boxes to let Steelhead handle
network connections, routing, and dial-up connections; I checked them all, and
the system restarted.
Next, I logged on at the server, opened up Dial-Up Networking (DUN), and
figured out how to connect to my ISP. I wasn't worried about routing yet; I just
wanted to get the NT Server to successfully dial up the ISP and establish a
Point-to-Point Protocol (PPP) connection so that I could ping and run Internet
Explorer and the like from the NT Server--I'll discuss routing to the other PCs
a bit later. Mike Reilly covered using DUN to dial in to an ISP in "New to
NT: Remote Access Service," May 1997, so I won't repeat how to do it here.
You have to noodle around with the IP parameters to make a PPP connection with
your ISP work well. And when I say, "You have to noodle," I mean it.
My ISP had a specific FAQ on connecting with RAS and DUN, and some recommended
settings were wrong. If tech support from your ISP is like tech support from
most ISPs--that is, practically nonexistent--plan to spend a day or two messing
with the DUN parameters. If you use a full-time connection such as a Frame Relay
Access Device (FRAD) look to tech support for that device. In this case, don't
buy the FRAD until you speak to both your ISP and the FRAD maker to be sure that
someone will be around to help get you up and running.
You'll also need to experiment to find out how to automate your dial-in.
With ordinary DUN, you can just tell NT to pop up a terminal window that lets
you type in your username and password. But RRAS doesn't let you do that. Your
ISP has to support Password Authentication Protocol (PAP) or Challenge Handshake
Authentication Protocol (CHAP), or you'll need to write a login script. Now is
the time to get the bugs out of this procedure, before you start worrying about
routing. My ISP supported PAP, so authentication wasn't a problem.
Once you figure out all that ISP configuration stuff, write it down and
keep the information in a safe place. Now you're ready to route.
If you've tried to make an NT Server act as a LAN and WAN IP router, you
know that at this point, you must typically make a handful of Registry changes
and reboot. But with RRAS, this stage is easy downstream swimming.
RRAS has an administrative tool called Routing and RAS Administrator;
you'll find it in the Administrative Tools group. In my example, Steelhead
doesn't yet know about the dial-in connection, so you'll see a screen similar to
Screen 1, showing only the Ethernet connection. Steelhead doesn't know about the
modem, so I had to build the WAN link. I right-clicked the Ethernet interface to
get the Add Interface option. That action kicked off the Demand Dial Interface
Wizard, which looks a lot like the wizard that helps create new phone book
entries. A couple of clicks in, I found Screen 2, which tells Steelhead that I'm
using this modem as a dial-up IP router. The next few screens are similar to
ordinary New Phonebook Entry wizard screens. The last screen let me set filters,
which I'll get back to in a moment. Routing and RAS Admin then looked like
Screen 3; note the new interface, Clark Net. The Clark Net line type is
demand-dial, meaning that the interface senses when you need it. In my example,
I haven't tried to route through it yet, so it's disconnected.