Corporate.Net
Private Dial-Up Networking Gets a Virtual Workout

3Com Corp. AccessBuilder 5000 Enterprise LAN/WAN Switch
Although 3Com's device lacks some of the more useful tools for tunnel management, such as those found in the Cisco IOS, we have to give credit for scaling nicely. When the port density increased on both the PPP and PPTP sessions, AccessBuilder 5000's FTP throughput times kept pace with the AS5200, though not as fast as either the Microcom or Shiva products'. For small files, like the one we used, the one- or two-second difference was hardly noticeable. But when we increased the file size, the slower throughput became obvious.

Acce ssBuilder is quite similar to the Access Integrator, as it is built on Microcom's chassis architecture. AccessBuilder, however, shouldn't be confused with the Access Integrator. Microcom provides the physical form factor and the modem management, and 3Com inserts its AccessBuilder 5000 brains into the chassis. AccessBuilder doesn't support L2F tunneling, making it less robust than the Access Integrator.

3Com's AccessBuilder sits in the chassis and talks to the Microcom modem modules over the backplane using PPTP. Incoming calls are routed to other AccessBuilders or other home gateways, such as Windows NT servers, based on rules in the modem configuration files. Because the modems and modem management are Microcom products, setting up the call routing in AccessBuilder is similar to Access Integrator. The decision of where to send the PPTP call is based on called numbers, which limits its usefulness for call routing.

AccessBuilder is the only device that has moved the installation and configuration of the PPTP tunnels into Transcend AccessBuilder Manager (TABM), 3Com's management station. TABM can only view and configure the PPTP tunnels that are terminated at the AccessBuilder--it does not look at the tunnels initiated from the modem modules to Windows NT home gateways. In cases where the dial-up racks are centralized and the remote-access servers are distributed (the motivation behind PPTP and L2F), TABM gives distributed, perhaps less skilled, staff an easy way to set up and manage the AccessBuilder's tunneling. The tunnel parameters on the modem modules are configured using Microcom's expressWATCH management station. Within TABM, you can tweak the flow-control parameters of each AccessBuilder to fit your needs.

Surprisingly, the modem modules don't use the flow-control mechanism of PPTP when communicating with the AccessBuilder in the same chassis, since there isn't any need for flow control over the backplane. If you are sending PPTP traffic over the LAN or WAN, you can configure parameters to st abilize connections. Because flow-control parameters are negotiated at tunnel creation, they only need be set at one end of the tunnel. Therefore, be careful when configuring the modem modules for the Windows NT servers or distributed AccessBuilders.

Mike Fratto can be reached at mfratto@nwc.com.

How We Tested VDPNs
Our test bed consisted of a Micron Electronics Millennia PRO Plus P200 with 96 MB of memory. We used a Digi International EPC/X Cluster Controller System with EPC/CON Concentrator to provide multiple asynchronous ports on our Windows NT client. We also used Microcom Corp.'s Access Integrator modem rack for client dial-out. A Madge Networks Teleos Model 60 provided our T1/ISDN Primary Rate Interface (PRI) signaling and call routing. The Layer 2 Forwarding (L2F) servers used a Cisco 4700 with IOS 11.2(3) as their home gateway. The Poin t-to-Point Tunneling Protocol (PPTP) server was a Dell Computer Corp. Dimension P90 with 96 MB of RAM and a 3Com Corp. Fast EtherLink XL 100-Mbps NIC running Windows NT 4.0. A Dell Dimension P90 router connected our two test networks with 96 MB of RAM and two 3Com Fast EtherLink 100-Mbps NICs. The PPTP home gateway, the Cisco 4700 and NT router were interconnected via a 100-Mbps Bay Networks hub. During the Virtual Dial-Up Private Network (VDPN) portion of the testing, the remote access servers were connected to a Cabletron Systems SmartSwitch 10/100 Mbps switch with the router connected to the 100-Mbps uplink.

We performed two tests for throughput. We ran a series of PPP connections in steps of six clients and ran FTP traffic over them to exercise the rack. Our test client was a Dell P90, which made PPP connections using dial-up networking. We did five FTP transfers on the test client and averaged the times. The second test involved running the same connection process, but this time running PPP over PPTP or L2F, as needed. This test provided us with an indication of cost in transfer times when using tunneling versus PPP alone.

End-To-End Tunneling Protocols
The remote-access solutions in this review provide a way for you to have multiprotocol tunneling between a Virtual Dial-up Private Network (VDPN)-enabled Network Access Server (NAS) and a home gateway on your network. You don't need to do anything special--except possibly use a modified user name--to use the technology because tunneling is transparent. However, none of these solutions provides data encryption or user authentication; they are simply transport protocols. Data encryption needs to be provided before data can be sent over the modem.

If you need to implement Layer 2 Forwarding (L2F) as your tunneling protocol, you first must establish a Point-to-Point Protocol (PPP) connection to a NAS. The NAS then tunnels the user's traffic to the home gateway associated with that user. There is no en d-to-end L2F connectivity--the tunnel is only available between the NAS and the home gateway. This is useful in centralizing access restrictions to network resources--including the Internet--because you can control users privileges.

Even though the servers in this review made Point-to-Point Tunneling Protocol (PPTP) tunnels on behalf of users, with a PPTP client, you can make your tunneled connections to the network and access the Internet locally from your Internet service provider (ISP). Currently, client PPTP tun-

neling is restricted to Windows NT servers and workstations. However, Microsoft is in the beta phase with its PPTP client for Windows95 (called Dial-up Networking upgrade 1.2). For Windows95 users, making connections using PPTP client is as simple as making a modem connection. You use the wizard to create a connection object and select the Virtual Private Network (VPN) adapter instead of your present network adapter.

Your users just need to enter the IP address of your home gateway, and they'll be ready to roll. This flexibility will provide them with a way to make PPP connections to any ISP and get to your home gateway without any software or hardware needed by the ISP. The encryption and session parameters are established on the NT home gateway, so you can retain control over how data is sent out of your network.

If y ou don't want to wait for the next service pack to be released, or need more than Windows95 support, Network Telesystems has TunnelBuilder, a PPTP client for Windows 3.11/95 and MacOS. This software uses a Virtual Device Driver (VxD) that installs onto your Windows 3.11 computer and lets you make PPTP connections through a Network Telesystems dialer. You can also make PPTP connections on the network. TunnelBuilder also works with Thursby Software Systems' DAVE, so you can use Windows NT, Windows95 and Windows for Workgroups NetBIOS over IP shares as well.