Data Center LAN Migration Guide - Juniper Networks

Data Center LAN Migration Guide
Step 2: Build the MPLS layer. Once you have migrated to an MPLS capable network and tested and verified its
connectivity and performance, activate the MPLS overlay and build label-switched paths (LSPs) to reach other data
centers. Label distribution is automated with the use of LDP and RSVP with extensions, to support creation and
maintenance of LSPs and to create bandwidth reservations on LSPs (RFC 3209). BGP can also be used to support
label distribution at the customer’s choice. The choice of protocol for label distribution on the network depends on the
needs of the organization and applications supported by the network. If traffic engineering or fast reroute are required
on the network, you must use RSVP with extensions for MPLS label distribution. It is the decision of whether or not to
traffic engineer the network or require fast reroute that frequently makes the decision between the use of LDP or RSVP
for MPLS label distribution.
Step 3: Configure MPLS VPNs. MPLS VPNs can segregate traffic based on departments, groups, or users, as well as
by applications or any combination of user group and application. Let’s take a step back and look at why we call MPLS
virtualized networks “VPNs.” First, they are networks because they provide connectivity between separately defined
locations. They are private because they have the same properties and guarantees as a private network in terms of
network operations and in terms of traffic forwarding. And lastly, they are virtual because they may use the same
transport links and routers to provide these separated transport services. Since each network to be converged onto
the newly built network has its own set of QoS, security, and policy requirements, you will want to define MPLS-based
VPNs that map to the legacy networks already built. MPLS VPNs can be defined by:
Department, business unit, or other function: Where there is a logical separation of traffic that goes to a more
granular level than the network, perhaps down to the department or business unit, application, or specific security
requirement level, you will want to define VPNs on the MPLS network, each to support the logical separation
required for a unique QoS, security, and application support combination.
Service requirements: In the context of this Data Center LAN Migration Guide, VPLS makes it appear as though
there is a large LAN extended across the data center(s). VPLS can be used for IP services or it can be used to
interconnect with a VPLS service provider to seamlessly network data center(s) across the cloud. IP QoS in the
LAN can be carried over the VPLS service with proper forwarding equivalence class (FEC) mapping and VPN
configuration. If connecting to a service provider’s VPLS service, you will either need to collocate with the service
provider or leverage a metro Ethernet service, as VPLS requires an Ethernet hand-off from the enterprise to the
service provider.
QoS needs: Many existing applications within your enterprise may run on separate networks today. To be properly
supported, these applications and their users make specific and unique security and quality demands on the
network. This is why, as a best practice, it is suggested that you start by creating VPNs that support your existing
networks. This is the minimum number of VPNs you will need.
Security requirements: Security requirements may be defined by user groups such as those working on sensitive and
confidential projects, by compliance requirements to protect confidential information, and by application to protect
special applications. Each “special” security zone can be sectioned off with enhanced security via MPLS VPNs.
Performance requirements: Typically, your applications and available bandwidth will determine traffic engineering
and fast reroute requirements, however users and business needs may impact these considerations as well.
Additional network virtualization: Once MPLS-based VPNs are provisioned to support your existing networks,
user groups, QoS, and security requirements, consideration should be given to new VPNs that may be needed. For
example, evolving compliance processes supporting requirements such as Sarbanes-Oxley or Health Insurance
Portability and Accountability Act (HIPAA) may require new and secure VPNs. Furthermore, a future acquisition of a
business unit may require network integration and this can easily be performed on the network with the addition of
a VPN to accommodate the acquisition.
Step 4: Transfer networks onto the MPLS VPNs. All of the required VPNs do not have to be defined before initiating the
process of migrating the existing network(s) to MPLS. In fact, you may wish to build the first VPN and then migrate the
related network, then build the second VPN and migrate the next network and so on. As the existing networks converge to
the MPLS network, monitor network performance and traffic loads to verify that expected transport demands are being
met. If for some reason performance or traffic loads vary from expected results, investigate further as MPLS can provide
deterministic traffic characteristics, and resulting performance should not vary greatly from the expected results. Based
upon findings, there may be opportunities to further optimize the network for cost and performance gains.
Copyright © 2012, Juniper Networks, Inc. 51