Next Generation Enterprise MPLS VPN-Based WAN Design and Implementation Guide
Solution Description
Downloads: This chapterpdf (PDF - 382.0KB) The complete bookPDF (PDF - 2.41MB) | Feedback

Solution Description

Table Of Contents

Solution Description


Solution Description


Enterprise customers have in the past relied heavily upon traditional WAN/MAN services for their connectivity requirements. Layer 2 circuits based on TDM, Frame Relay, ATM, and SONET have formed the mainstay of most low-speed WAN services. More recently, high-speed MAN solutions have been delivered directly over Layer 1 optical circuits, SONET, or through the implementation of point-to-point or point-to-multipoint Ethernet services delivered over one of these two technologies.

Today, many enterprise customers are turning to Multiprotocol Label Switching (MPLS)-based VPN solutions because they offer numerous secure alternatives to the traditional WAN/MAN connectivity offerings. The significant advantages of MPLS-based VPNs over traditional WAN/MAN services include the following:

Provisioning flexibility

Wide geographical availability

Little or no distance sensitivity in pricing

The ability to mix and match access speeds and technologies

Perhaps most importantly, the ability to securely segment multiple organizations, services, and applications while operating a single MPLS-based network

Although service providers have been offering managed MPLS-based VPN solutions for years, the larger enterprises, universities, and federal and state governments are now beginning to investigate and deploy MPLS in their own networks to implement self-managed MPLS-based VPN services. The concept of self-managed enterprise networks is not new; many enterprise customers purchase Layer 2 TDM, Frame Relay, or ATM circuits and deploy their own routed network for these circuits. The largest of enterprise customers even manage their own core networks by implementing Frame Relay or ATM-based switching infrastructures and "selling" connectivity services to other organizations within their companies.

Both of these solutions have had disadvantages; deploying an IP-based infrastructure over leased lines offers little flexibility and segmentation capabilities that are cumbersome at best. Deploying a switched Frame Relay or ATM infrastructure to allow for resiliency and segmentation is a solution within reach of only the largest and most technically savvy enterprises.

As noted, the self-managed MPLS-based network is typically reserved for larger enterprises willing to make an investment in network equipment and training, with an IT staff that is comfortable with a high degree of technical complexity. A self-managed MPLS VPN can be an attractive option if a business meets these requirements and wants to fully control its own WAN or MAN and to increase virtualization across multiple sites to guarantee delivery of specific applications. There are alternate approaches to full-fledged MPLS implementations such as Multi-VRF or a combination of both MPLS and Multi-VRF that allow existing networks to be easily transitioned to virtualized ones. The level of security between separated networks is comparable to private connectivity without needing service provider intervention, allowing for consistent network segmentation of departments, business functions, and user groups.

Corporations with a propensity for mergers and acquisitions benefit from the inherent any-to-any functions of MPLS that, when the initial configuration is completed, allow even new sites with existing networks to be merged with the greater enterprise network with minimal overhead. Secure partner networks can also be established to share data and applications as needed, on a limited basis. Theself-managed MPLS is also earning greater adoption as an important and viable method for meeting and maintaining compliance with regulatory privacy standards such as HIPAA and the Sarbanes-Oxley Act.

While the technology enables you to create the logical separation across networks, it is important to understand the reasons for creating these logical networks. Enterprise customers increasingly require segmentation for a number of different reasons:

Closed User Groups (CUG)—The CUGs could be created based on a number of different business criteria, with guest Internet access for onsite personnel being the simplest example. Providing NAC/isolation services also creates a need to separate the non-conforming clients. While this can be done using VLANs within a Layer 2 campus network, it requires Layer 3 VPN functionality to extend it across Layer 3 boundaries. CUGs could be created with partners, either individually or as a sub-group, where the segmentation criteria are resources that are to be shared/accessed. This simplifies the information sharing with partners while still providing security and traffic separation.

Virtualization—Segmentation to the desktop is driving virtualization in the application server space. This means that even existing employees can be segmented into different CUGs where they are provided access to internal services based on their group membership.

Enterprise as a Service Provider—With some of the enterprise networks expanding as their organization expands, IT departments at some of the large enterprises have become internal Service Providers. They leverage a shared network infrastructure to provide network services to individual Business Units within the enterprise. This not only requires creating VPNs, but also requires the ability of each of the BUs to access shared corporate applications. Such a model can be expanded to include scenarios in which a company acquires another company (possibly with an overlapping IP addressing scheme) and needs to eventually consolidate the networks, the applications, and the backoffice operations.

Protecting critical applications—Another segmentation criteria could be based off the applications themselves rather than the users. An organization that feels that its critical applications need to be separated from everyday network users can create VPNs for each or a group of applications. This not only allows it to protect them from any malicious traffic, but also more easily control user access to the applications. An example of this is creating separate VPNs for voice and data.

Beyond the segmentation criteria, the overarching consideration should be based on the need to share. The VPNs create a closed user group that can easily share information, but there will always be the scenario that requires sharing across the VPNs. For example, a company-wide multicast stream would need to be accessible by all the employees irrespective of their group association. Thus the VPNs should be created based on practical considerations that conform to the business needs of the organization.

The first phase of the solution provided design guidelines for creating a self deployed MPLS MAN for the enterprise. It focused on Layer 3 VPNs and Layer 2 VPNs deployments, multicast and voice services supported by a end-to-end QoS model. It provided models for shared services deployments such as Internet access.

The next logical step for expanding virtualization across enterprise networks is to extend it into two other areas (Figure 1-1):

Connecting large MAN/campus MPLS networks

Remote branches

Figure 1-1 NGMAN/WAN 2.0—Solution Scope

While the MAN deployment in phase 1.0 was characterized by higher bandwidth requirements, WAN deployment (especially branch aggregation) is characterized by higher scale requirements to support 100s to 1000s of sites. A WAN may be a Layer 2 or Layer 3 service and may be spread across providers. A Layer 3 WAN may require some form of overlay network to support enterprise virtualization. The virtualization deployment in the WAN also has a important bearing on how the sites are integrated with the core MPLS network.

The remaining chapters explore the different deployment models for inter-MAN MPLS connectivity and virtualized branch aggregation. It focuses on data, voice, and multicast services along with QoS. Each of the models is discussed with lab tested and deployable examples.

For a technology refresher and MPLS MAN deployment, refer to the phase 1.0 DIG:

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns241/c649/ccmigration_09186a008055edcf.pdf