The evolution of the LAN and the evolution of the user's service relationship with carriers and WAN technology have traditionally developed almost independently but that may soon change.
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 realised 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 (now part of Alcatel) - 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 prioritised 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 to where 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 to 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.
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.