When designing a WAN, numerous factors must be considered. The first issue to consider is the organization and its short-, medium- and long-term goals. Among the factors to think about are:
- Existing applications
- Planned applications (it's very important to factor these into the design process)
- Local access requirements
- Remote access requirements
- End-user equipment (workstations)
- Network equipment (routers, switches)
- Connectivity outside the organization (to suppliers, stakeholders, customers)
- Competitive considerations
Requirements will change, depending on whether you are creating a new network, modifying an existing network or integrating an existing network with other networks. Assuming there is an existing network, the next step is to inventory the network, identifying the circuits and all associated hardware (routers, firewalls) and software supporting the network, and summarizing
WAN discovery, analysis and simulation
Let's assume we have an existing WAN based on a combination of fixed private lines and Internet-based virtual private networks (VPNs). Clearly the WAN must be designed to accommodate traffic generated at each network node as well as from remote users, plus traffic across the inter-node channels. Once the incoming and outgoing traffic statistics are compiled, the network topology is defined, and relevant operational and business-related data are identified, the new network architecture's design can begin. Unless a major business change (such as a merger or acquisition) is involved, the existing network architecture usually can be retained. The WAN may need to be slightly modified in terms of node positioning, device configuration and inter-node bandwidth, as well as local access bandwidth. It may be necessary to replace fixed private lines with an MPLS (multi-protocol label switching) architecture for cost and performance reasons.
The next activity is performance analysis, which summarizes how the network is operating in terms of throughput, bandwidth, latency, and other key factors. When capturing network performance data, a network analyzer is often the tool of choice.
The data captured must next be analyzed in the context of current and future requirements. The most efficient and cost-effective way to do this is with network simulation software. However, it's not uncommon for organizations to develop their own home-grown methods for network analysis.
Assuming you prefer the software route, numerous simulation products are available. Three examples are Shunra VE Desktop, a Windows-based software that simulates WAN links so that applications can be tested under a variety of current and potential network conditions; WANDL IP/MPLSView, a multi-vendor, multi-protocol, and multi-layer traffic engineering solution for IP and/or MPLS networks, and Boson NetSim, a software application that simulates Cisco hardware and software and builds a virtual routing table to simulate a real network environment.
Managed services for WAN design
Additional options for designing WAN architectures are the carriers, networking consultants, and managed service providers. If your organization doesn't have the staffing or other resources needed to dynamically design and manage your WAN, consider third parties who can do all or most of it for you. Typical services include network design and provisioning, project management, help desk, network monitoring and maintenance, and management of all remote locations.
Once the newly redesigned WAN has been installed and tested, regular monitoring of network performance ensures that the WAN will continue to support the organization's needs. Assuming network managers are aware of planned applications and expanded (or reduced) requirements, the network design can continue to cost-effectively support those needs.
About the author: Paul F. Kirvan, FBCI, CBCP, CISSP, has more than 35 years experience in telecommunications and information technology as a practitioner, consultant, author and educator. He also specializes in business continuity and disaster recovery.
This was first published in March 2009