Right now, you probably have a router sitting on your network's every WAN connection. Most likely, it's moving your data traffic just as it should. And I bet it's one of the least utilized devices on your network. Even at T1 speeds, your router is forwarding just a few thousand packets per second. Admirable in 1993, but in 1999 we've got DSU/CSUs that exhibit three times enough MIPS for this. Any general-purpose computer purchased in the past five years could adequately handle routing for the WAN.
And there are many other WAN functions that routers don't perform well at all, necessitating add-on devices. WAN-service-level monitoring tools use external probes. Most bandwidth-management systems employ standalone devices for traffic shaping. Many billing and charge-back systems are hosted on external boxes. Each single-purpose system requires separate power, processors, memory and management.
As a result, these WAN functions cost more than they should, driving up the price of each fully managed WAN connection by hundreds or thousands of dollars. Yet all the data feeding these systems must traverse the router as it performs the relatively simple task of passing packets.
Sure, many routers offer extended features, such as circuit multiplexing, compression, NAT, tunneling and basic firewall protection. This is a good thing because these particular functions must alter packets to do their work, adding latency. Every microsecond counts when packets are being compressed, encrypted or otherwise modified.
Yet closed-architecture devices don't deliver best-of-breed services. A single development source incubates merely adequate software. You'll still find standalone firewalls, VPN systems and compressors with more functions and better performance than their router-based counterparts. So we will continue to introduce new devices at the WAN border, each with its own overhead--in both actual cost and ongoing management expense, often reducing total network performance.
If this situation were going to get better, it would happen in one of two ways. First, router manufacturers would open their packet-examination engines to third-party developers. This would give users a choice of products that serve a given function, and along the way add value to the underlying platform. It may sound Utopian, but it's common practice in the voice world, where third-party developers have long been embraced. Even Cisco has an open programmable voice switch, the VCO/4K. Just don't ask it about opening up IOS.
Open interfaces don't require manufacturers to give their code base away, but rather simply to provide APIs to other processes. Third-party code could run on the router in special-function cards or on an external host. Nbase-Xyplex has taken a few steps toward this goal with plans for the OSR8040, a large, carrier-class switch/router that uses onboard Pentium processors to host Linux for applications and provide high-level aggregate information to third-party software. That's a start, but it doesn't go far enough.
If routers don't open up, the more realistic option is a pure play for Linux in the WAN. A Linux-based PC can host a wide variety of applications, routing included, at a lower cost than going proprietary--and it's not as risky as you might think. As a platform for Internet services, Linux has already been proven and is the only network operating system worth considering here. It's leaner and more stable than Windows NT. It has a huge development community--the size of which NetWare will never achieve. And no other Unix can match its value for low-cost services.
Send your comments on this column to David Willis at dwillis@nwc.com.
REPORTS
Analyize In-Line NAC strategies and products.
ANALYTICS Plan and design your enterprise blade server deployments
InformationWeek U.S. IT Salary Survey 2008
Salaries for business technology professionals are falling. Here's what you need to know in order to make good hiring decisions and personal career choices. Download Today