For a long time, the evolution of the LAN and the evolution of the user’s service relationship with carriers and WAN technology have developed almost independently. This may change soon, because interest in IP virtual private networks (VPN) and the Internet, coupled with equipment vendor desire to increase revenue, are threatening to blur the LAN/WAN boundary forever.
When Level 3 (and
higher) LAN switches were introduced, some vendors realized their products could replace routers, which are also Level 3 products, and offered WAN interfaces. The “We’d like to be your router” mission – the keystone of the marketing approach of vendors such as Xylan Corp. (now part of Alcatel SA) – didn’t encourage the switch vendors to propose any unique LAN architecture. Instead, the message was “Whatever you did with your routers, you can do with our switches.”
But the trend toward WAN features on switches is also dovetailing with some key issues in the delivery of IP VPN services. In their early deployment, IP VPNs are most likely to supplement private networks rather than completely displace them. Getting LAN traffic to the right WAN connection (VPN or private network) involves building switched-LAN networks and integrating high-level LAN switching with VPNs. This fact ultimately will force switch vendors to address just how their products should be used to build the optimal LAN/WAN network.
The problem is that VPNs may represent special handling options for traffic involved in applications such as collaborative conferences, which require high quality of service. The conferees all have their own system addresses, and those addresses don’t change just because the participants happen to be using NetMeeting. What happens is the traffic between the collaborators gets prioritized for the period of the conference.
But how does that traffic get to the VPN? The VPN may well be connected to the LAN in a different spot than the private network is connected. If the routing tables in premises LAN switches or routers point to the private network as the route between the IP addresses of the conferencing users, none of the traffic will ever get to the IP VPN’s service point.
One strong step that can be taken to prevent difficulties in getting traffic to a VPN service connection is to build premises networks with a single WAN connection point for all traffic, whether it’s to a private network or an IP VPN. If all WAN traffic flows to a common exit point, only the device there needs to be made aware of the policy management steering rules that direct collaborative conferences one way and simple e-mail or other data activity another way. But while most LAN vendors would endorse this rule, few make it a recommendation in their design guides.
A more complex problem in the LAN/WAN relationship is how Level x (where x
is 4 through 7) LAN switches, which are application-aware by nature, are linked to IP VPNs, which may also be application-aware. If we go back to our conference example, we could assume that the LAN switches create a policy-based application network within the premises LAN for local user conferencing. Wouldn’t it be logical to assume that a VPN service for connecting off-site members would be effectively “joined” to this application network? This would permit policy management exchange between the application and the service provider, if needed, and also ensure that the VPN is used only for the application for which it was procured.
Unfortunately, that isn’t how the switch vendors are promoting their WAN interfaces. Linking Level x switches to IP VPNs isn’t just a problem for big companies, either. A small office LAN is a single, flat, structure consisting of a single subnet, and any traffic to anyone not on that local subnet goes to a common default gateway router. It’s true that the small office LAN probably won’t have a problem with a separate WAN connection for private networks and VPNs. But it could well support internal application networks built through Level x switches, and these networks may have to be extended off-site.
The introduction of VPN services, particularly those targeted at applications rather than whole networks, could expose many users to issues of LAN/WAN integration they’ve never seen before. Now is the time to bone up on your vendors’ capabilities in this area before it’s too late.
Nolle is president of CIMI Corp., a technology assessment firm in Voorhees, N.J. He can be reached at (856) 753-0004 or tnolle@cimicorp.com.