Juniper Data Center LAN Migration Guide

DATA CENTER LAN MIGRATION GUIDE

2 Copyright © 2011, Juniper Networks, Inc.

Data Center LAN Migration Guide

Table of Contents

Chapter 1: Why Migrate to Juniper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Introduction to the Migration Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Data Center Architecture and Guide Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Why Migrate? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Scaling Is Too Complex with Current Data Center Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

The Case for a High Performing, Simplified Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Why Juniper? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Other Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Chapter 2: Pre-Migration Information Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Pre-Migration Information Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

Technical Knowledge and Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

QFX3500 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Chapter 3: Data Center Migration -Trigger Events and Deployment Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

How Migrations Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Trigger Events for Change and Their Associated Insertion Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Considerations for Introducing an Alternative Network Infrastructure Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Trigger Events, Insertion Points, and Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

IOS to Junos OS Conversion Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Data Center Migration Insertion Points: Best Practices and Installation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

New Application/Technology Refresh/Server Virtualization Trigger Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Network Challenge and Solutions for Virtual Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Network Automation and Orchestration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Data Center Consolidation Trigger Event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Best Practices: Designing the Upgraded Aggregation/Core Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Best Practices: Upgraded Security Services in the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

Aggregation/Core Insertion Point Installation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

Consolidating and Virtualizing Security Services in the Data Center: Installation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . 44

Business Continuity and Workload Mobility Trigger Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Best Practices Design for Business Continuity and HADR Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Best Practices Design to Support Workload Mobility Within and Between Data Centers . . . . . . . . . . . . . . . . . . . . . . . . 48

Best Practices for Incorporating MPLS/VPLS in the Data Center Network Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Six Process Steps for Migrating to MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Completed Migration to a Simplified, High-Performance, Two-Tier Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Juniper Professional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Copyright © 2011, Juniper Networks, Inc. 3


Chapter 4: Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Troubleshooting Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

OSI Layer 1: Physical Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

OSI Layer 2: Data Link Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Virtual Chassis Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

OSI Layer 3: Network Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

VPLS Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

Quality of Service/Class of Service (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

OSI Layer 4-7: Transport to Application Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Troubleshooting Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Chapter 5: Summary and Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Data Center Design Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Training Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Juniper Networks Professional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

About Juniper Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66



Table of Figures

Figure 1: Multitier legacy data center LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Figure 2: Simpler two-tier data center LAN design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Figure 3: Data center traffic flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

Figure 4: Collapsed network design delivers increased density, performance, and reliability . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 5: Juniper Networks 3:2:1 Data Center Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Figure 6: Junos OS - The power of one . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figure 7: The modular Junos OS architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

Figure 8: Junos OS lowers operations costs across the data center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

Figure 9: Troubleshooting with Service Now . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Figure 10: Converting IOS to Junos OS using I2J . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Figure 11: The I2J input page for converting IOS to Junos OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Figure 12: Inverted U design using two physical servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Figure 13: Inverted U design with NIC teaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Figure 14: EX4200 top-of-rack access layer deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Figure 15: Aggregation/core layer insertion point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Figure 16: SRX Series platform for security consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Figure 17: Workload mobility alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Figure 18: Switching across data centers using VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Figure 19: Transitioning to a Juniper two-tier high-performance network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Copyright © 2010, Juniper Networks, Inc.

Chapter 1: Why Migrate to Juniper



Introduction to the Migration Guide

IT has become integral to business success in virtually all industries and markets. Today’s data center is the centralized

repository of computing resources enabling enterprises to meet their business objectives. Today’s data center traffic

flows and performance requirements have changed considerably from the past with the advent of cloud computing

and service-oriented architecture (SOA)-based applications. In addition, increased mobility, unified communications,

compliance requirements, virtualization, the sheer number of connecting devices, and changing network security

boundaries present new challenges to today’s data center managers. Architecting data centers based on old traffic

patterns and outdated security models is inefficient and results in lower performance, unnecessary complexity,

difficulty in scaling, and higher cost.

A simplified, cloud-ready, two-tier data center design is needed to meet these new challenges—without any

compromise in performance. Migrating to such a data center network can theoretically take place at any time.

Practically speaking, however, most enterprises will not disrupt a production data center except for a limited time

window to perform scheduled maintenance and business continuity testing. Luckily and within this context, migration

to a simpler two-tier design can begin at various insertion points and proceed in controlled ways in an existing legacy

data center architecture.

Juniper’s Data Center LAN Migration Guide identifies the most common trigger events at which migration to a

simplified design can take place together with design considerations at each network layer for a successful migration.

The guide is segmented into two parts. For the business decision maker, Chapter 1: Why Migrate to Juniper will be most

relevant. The technical decision maker will find Chapters 2 and 3 most relevant, particularly Chapter 3, which covers

the data center “trigger events” that can stimulate a transition and the corresponding insertion points, designs, and

best practices associated with pre-install, install, and post-install tasks.

Audience

While much of the high-level information presented in this document will be useful to anyone making strategic

decisions about a data center LAN, this guide is targeted primarily to:

• Data center network and security architects evaluating the feasibility of new approaches in network design

• Data center network planners, engineers, and operators designing and implementing new data center networks

• Data center managers, IT managers, network and security managers planning and evaluating data center

infrastructure and security requirements

Data Center Architecture and Guide Overview

One of the primary ways to increase data center efficiency is to simplify the infrastructure. Most data center networks

in place today are based on a three-tier architecture. A simplified two–tier design, made possible by the enhanced

performance and more efficient packaging of today’s Ethernet switches, reduces cost and complexity, and increases

efficiency without compromising performance.

During the 1990s, Ethernet switches became the basic building block of enterprise campus network design. Networks

were typically built in a three-tier hierarchical tree structure to compensate for switch performance limitations. Each

tier performed a different function and exhibited different form factors, port densities, and throughputs to handle the

workload. The same topology was deployed when Ethernet moved into the data center displacing Systems Network

Architecture (SNA), DECnet, and token ring designs.



Figure 1: Multitier legacy data center LAN

This multitiered architecture, shown in Figure 1, worked well in a client/server world where the traffic was primarily “north

and south,” and oversubscription ratios at tiers of the network closest to the endpoints (including servers and storage)

could be high. However, traffic flows and performance requirements have changed considerably with the advent of

applications based on SOA, increased mobility, Web 2.0, unified communications, compliance requirements, and the

sheer number of devices connecting to the corporate infrastructure. Building networks today to accommodate 5 to 10

year old traffic patterns is not optimal, and results in lower performance, unnecessary complexity, and higher cost.

A new data center network design is needed to maximize IT investment and easily scale to support the new

applications and services a high-performance enterprise requires to stay competitive. According to Gartner,

“Established LAN design practices were created for an environment of limited switch performance. Today’s high-

capacity switches allow new design approaches, thus reducing cost and complexity in campus and data center LANs.

The three-tier concept can be discarded, because all switch ports can typically deliver rich functionality without

impacting performance.”1

Data Center InterconnectWAN Edge

Aggregation Layer

Core

Access Layer

Ethernet

Servers NAS FC Storage

FC SAN

3-TIER LEGACY NETWORK

1Neil Rikard “Minimize LAN Switch Tiers to Reduce Cost and Increase Efficiency,” Gartner Research ID Number: G00172149 November 17, 2009



Figure 2: Simpler two-tier data center LAN design

Juniper Networks offers a next-generation data center solution, shown in Figure 2, which delivers:

• Simplified design for high performance and ease of management

• Scalable services and infrastructure to meet the needs of a high-performance enterprise

• Virtualized resources to increase efficiency

This two-tier data center LAN architecture provides a more elastic and more efficient network that can also easily scale.

This guide covers the key considerations in migrating an existing three-tier data center network to a simplified, cloud-

ready, two-tier design. From a practical perspective, most enterprises won’t initiate a complete data center redesign

for an existing, operational data center. However, there are several events, such as bringing a new application or

service online or a data center consolidation, which require an addition to the existing data center infrastructure. We

call these common events at which migration can begin trigger events. Trigger events generate changes in design at a

given network layer, which we call an insertion point. In Chapter 3 of this guide, we cover the best practices and steps

involved for migration at each of the insertion points presented by a specific trigger event. By following these steps and

practices, it is possible to extend migration to other legacy network tiers and continue towards a simplified two-tier

Juniper infrastructure over time.

In summary, this Data Center LAN Migration Guide describes:

• Pre-migration information requirements

• Migration process overview and design considerations

• Logical migration steps and Juniper best practices for transitioning each network layer insertion point

• Troubleshooting steps

• Additional resources

GbE

SRX5800

MX Series

QFX3500 Switch

Core Layer

EX8216

ServersNAS

FC Storage

FC SAN

FC



Why Migrate?

IT continues to become more tightly integrated with business across all industries and markets. Technology is the

means by which enterprises can provide better access to information in near or real time to satisfy customer needs,

while simultaneously driving new efficiencies. However, today’s enterprise network infrastructures face growing

scalability, agility, and security challenges. This is due to factors such as increased collaboration with business

partners, additional workforce mobility, and the sheer proliferation of users with smart mobile devices requiring

constant access to information and services. These infrastructure challenges are seriously compounded when growth

factors are combined with the trend towards data center consolidation. What is needed is a new network infrastructure

that is more elastic, more efficient, and can easily scale.

Scalability is a high priority, as it is safe to predict that much of the change facing businesses today is going to come as

a requirement for more storage, more processing power, and more flexibility.

Recent studies by companies such as IDC suggest that global enterprises will be focusing their investments and

resources in the next 5 to 10 years on lowering costs while continuing to look for new growth areas. Industry analysts

have identified several key data center business initiatives that align with these directions:

• Data center consolidation: Enterprises combine data centers as a result of merger or acquisition to reduce cost as

well as centralize and consolidate resources.

• Virtualization: Server virtualization is used to increase utilization of CPU resources, provide flexibility, and deliver

“on-demand” services that easily scale (currently the most prevalent virtualization example).

• Cloud computing: Pooling resources within a cloud provides a cost-efficient way to reconfigure, reclaim, and reuse

resources to deliver responsive services.

• I/O convergence or consolidation: Ethernet and Fibre Channel are consolidated over a single wire on the server side.

• Virtual Desktop Infrastructure (VDI): Applications are run on centralized servers to reduce operational costs and

also provide greater flexibility.

These key initiatives all revolve around creating greater data center efficiencies. While meeting these business

requirements, it is vital that efficient solutions remain flexible and scalable systems are easy to manage to maximize

all aspects of potential cost savings.

In today’s data center, applications are constantly being introduced, updated, and retired. Demand for services is

unpredictable and ever changing. Remaining responsive, and at the same time cost efficient, is a significant resource

management challenge, and adding resources needs to be a last resort since it increases the cost basis for service

production and delivery. Having the ability to dynamically reconfigure, reclaim, and reuse resources positions the data

center to effectively address today’s responsiveness and efficiency challenges.

Furthermore, existing three-tier architectures are built around a client/server model that is less relevant in today’s

application environment. Clearly, a new data center LAN design is needed to adapt to changing network dynamics,

overcome the complexity of scaling with the current multitiered architecture, as well as capitalize on the benefits of

high-performance platforms and a simplified design.



Figure 3: Data center traffic flows

Applications built on SOA architecture and those delivered in the software as a service (SaaS) model require an

increasing number of interactions among servers in the data center. These technologies generate a significant amount of

server-to-server traffic; in fact, up to 70% of data center LAN traffic is between servers. Additional server traffic may also

be produced by the increased adoption of virtualization, where shared resources such as a server pool are used at greater

capacity to improve efficiency. Today’s network topologies need to mirror the nature of the traffic being transported.

Existing three-tier architectures were not designed to handle server-to-server traffic without going up and back through

the many layers of tiers. This is inherently inefficient, adding latency at each hop, which in turn impacts performance,

particularly for real-time applications like unified communications, or in industries requiring high performance such as

financial trading.

Scaling Is Too Complex with Current Data Center Architectures

Simply deploying ever more servers, storage, and devices in a three-tier architecture to meet demand significantly

increases network complexity and cost. In many cases, it isn’t possible to add more devices due to space, power,

cooling, or throughput constraints. And even when it is possible, it is often difficult and time-consuming to manage due

to the size and scope of the network. Or it is inherently inefficient, as it’s been estimated that as much as 50% of all

ports in a typical data center are used for connecting switches to each other as opposed to doing the more important

task of interconnecting storage to servers and applications to users. Additionally, large Layer 2 domains using Spanning

Tree Protocol (STP) are prone to failure and poor performance. This creates barriers to the efficient distribution of

resources in the DC and fundamentally prevents a fast and flexible network scale out. Similarly, commonly deployed

data center technologies like multicast don’t perform at scale across tiers and devices in a consistent fashion.

Legacy security services may not easily scale and are often not efficiently deployed in a data center LAN due to the

difficulty of incorporating security into a legacy,multitiered design. Security blades which are bolted into switches at the

aggregation layer consume excessive power and space, impact performance, and don’t protect virtualized resources.

Another challenge of legacy security service appliances is the limited performance scalability, which may be far

below the throughput requirements of most high-performance enterprises consolidating applications or data centers.

The ability to cluster together firewalls as a single logical entity to increase scalability without added management

complexity is another important consideration.

Proprietary systems may also limit further expansion with vendor lock-in to low performance equipment. Different

operating systems at each layer may add to the complexity to operate and scale the network. This complexity is costly,

limits flexibility, increases the time it takes to provision new capacity or services, and restricts the dynamic allocation of

resources for services such as virtualization.

UP TO 70%

Network topologies should mirrorthe nature of the tra�c they transport

N

WS

E



The Case for a High Performing, Simplified Architecture

Enhanced, high-performance LAN switch technology can help meet these scaling challenges. According to Network World,

“Over the next few years, the old switching equipment needs to be replaced with faster and more flexible switches. This

time, speed needs to be coupled with lower latency, abandoning spanning tree and support for the new storage protocols.

Networking in the data center must evolve to a unified switching fabric.”2

New switching technology such as that found in Juniper Networks® EX Series Ethernet Switches has caught up to

meet or surpass the demands of even the most high-performance enterprise. Due to specially designed application-

specific integrated circuits (ASICs) which perform in-device switching functions, enhanced switches now offer high

throughput capacity of more than one terabit per second (Tbps) with numerous GbE and 10GbE ports, vastly improving

performance and reducing the number of uplink connections. Some new switches also provide built-in virtualization

that reduces the number of devices that must be managed, yet can rapidly scale with growth. Providing much greater

performance, enhanced switches also enable the collapsing of unnecessary network tiers—moving towards a new,

simplified network design. Similarly, scalable enhanced security devices can be added to complement such a design,

providing security services throughout the data center LAN.

A simplified, two-tier data center LAN design can lower costs without compromising performance. Built on high-

performance platforms, a collapsed design requires fewer devices, thereby reducing capital outlay and the operational

costs to manage the data center LAN. Having fewer network tiers also decreases latency and increases performance,

enabling wider support of additional cost savings and high bandwidth applications such as unified communications.

Despite having fewer devices, a simplified design still offers high availability (HA) with key devices being deployed in

redundant pairs and dual homed to upstream devices. Additional HA is offered with features like redundant switching

fabrics, dual power supplies, and the other resilient capabilities available in enhanced platforms.

Figure 4: Collapsed network design delivers increased density, performance, and reliability

2Robin Layland/Layland Consulting “10G Ethernet shakes Net Design to the Core/Shift from three- to two-tier architectures accelerating,” Network World September 14, 2009

DensityPerformance

Reliability

MULTI-TIER LEGACY NETWORK 2-TIER DESIGN



Two-Tier Design Facilitates Cloud Computing

By simplifying the design, by sharing resources, and by allowing for integrated security, a two-tier design also enables

the enterprise to take advantage of the benefits of cloud computing. Cloud computing delivers on-demand services to

any point on the network without requiring the acquisition or provisioning of location-specific hardware and software.

These cloud services are delivered via a centrally managed and consolidated infrastructure that has been virtualized.

Standard data center elements such as servers, appliances, storage, and other networking devices can be arranged in

resource pools that are shared securely across multiple applications, users, departments, or any other way they should

be logically shared. The resources are dynamically allocated to accommodate the changing capacity requirements of

different applications and improve asset utilization levels. This type of on-demand service and infrastructure simplifies

management, reduces operating and ownership costs, and allows services to be provisioned with unprecedented

speed. Reduced application and service delivery times mean that the enterprise is able to capitalize on opportunities

as they occur.

Achieving Power Savings and Operating Efficiencies

Fewer devices require less power, which in turn reduces cooling requirements, thus adding up to substantial

power savings. For example, a simplified design can offer more than a 39% power savings over a three-tier legacy

architecture. Ideally, a common operating system should be used on all data center LAN devices to reduce errors,

decrease training costs, ensure consistent features, and thus lower the cost of operating the network.

Consolidating Data Centers

Due to expanding services, enterprises often have more than one data center. Virtualization technologies like server

migration and application load balancing require multiple data centers to be virtually consolidated into a single, logical

data center. Locations need to be transparently interconnected with LAN interconnect technologies such as virtual

private LAN service (VPLS) to interoperate and appear as one.

All this is possible with a new, simplified data center LAN design from Juniper Networks. However, as stated earlier,

Juniper recognizes that it is impractical to flash migrate from an existing, operational, three-tier production data center

LAN design to a simpler two-tier design, regardless of the substantial benefits. However, migration can begin as a result

of any of the following trigger events:

• Addition of a new application or service

• Refresh cycle

• Server virtualization migration

• Data center consolidation

• Business continuity and workload mobility initiatives

• Data center core network upgrade

• Higher performance and scalability for security services

The design considerations and steps for initiating migration from any of these trigger events is covered in detail in

Chapter 3: Data Center Migration—Trigger Events and Deployment Processes.



Why Juniper?

Juniper delivers high-performance networks that are open to and embrace third-party partnerships to lower total cost

of ownership (TCO) as well as to create flexibility and choice. Juniper is able to provide this based on its extensive

investment in software, silicon, and systems.

• Software: Juniper’s investment in software starts with Juniper Networks Junos® operating system. Junos OS offers

the advantage of one operating system with one release train and one modular architecture across the enterprise

portfolio. This results in feature consistency and simplified management throughout all platforms in the network.

• Silicon: Juniper is one of the few network vendors that invests in ASICs which are optimized for Junos OS to

maximize performance and resiliency.

• Systems: The combination of the investment in ASICs and Junos OS produces high-performance systems that

simultaneously scale connectivity, capacity, and the control capability needed to deliver new applications and

business processes on a single infrastructure that also reduces application and service delivery time.

Juniper’s strategy for simplifying the data center network is called the 3-2-1 Data Center Network Architecture, which

eliminates layers of switching to “flatten” and collapse the network from today’s three-tier tree structure to two

layers, and in the future just one (see Figure 5). A key enabler of this simplification is achieved by deploying Juniper’s

Virtual Chassis fabric technology, which interconnects multiple physical switches to create a single, logical device that

combines the performance and simplicity of a switch with the connectivity and resiliency of a network. Organizations

can migrate from a three-tier to a two-tier network beginning with a Trigger Event such as adding a new POD or a

technology refresh. Migration Trigger Events will be presented in more detail in Chapter 3. Alternatively, they can

move directly into a Juniper-enabled data center fabric as it becomes available. Creating a simplified infrastructure

with shared resources and secure services delivers significant advantages over other designs. It helps lower costs,

increase efficiency, and keep the data center agile enough to accommodate any future business changes or technology

infrastructure requirements. The steps to migrate from an existing three-tier network to a flatter design, as articulated

by the Juniper Networks 3-2-1 Data Center Network Architecture, is built on four core principles:

• Simplify the architecture: Consolidating legacy siloed systems and collapsing inefficient tiers results in fewer

devices, a smaller operational footprint, and simplified management from a “single pane of glass.”

• Share the resources: Segmenting the network into simple, logical, and scalable partitions with privacy, flexibility,

high performance, and quality of service (QoS) enables network agility to rapidly adapt to an increasing number of

users, applications, and services.

• Secure the data flows: Integrating scalable, virtualized security services into the network core provides benefits to all

users and applications. Comprehensive protection secures data flows into, within, and between data centers. It also

provides centralized management and the distributed dynamic enforcement of application and identity-aware policies.

• Automate network operations at each step—An open, extensible software platform reduces operational costs

and complexity, enables rapid scaling, minimizes operator errors, and increases reliability through a single network

operating system. A powerful network application platform with innovative applications enables network operators

to leverage Juniper or third-party applications for simplifying operations and scaling application infrastructure to

improve operational efficiency.



Figure 5: Juniper Networks 3:2:1 Data Center Network Architecture

Juniper’s data center LAN architecture embodies these principles and enables high-performance enterprises to build

next-generation, cloud-ready data centers. For information on Building the Cloud-Ready Data Center, please refer to:

www.juniper.net/us/en/solutions/enterprise/data-center.

Other Considerations

It is interesting to note that even as vendors introduce new product lines, the legacy three-tier architecture remains as

the reference architecture for Data Centers. This legacy three-tier architecture retains the same limitations in terms of

scalability and increased complexity.

Additionally, migrating to a new product line, even with an incumbent vendor, may require adopting a new OS,

modifying configurations, and replacing hardware. The potential operational impact of introducing new hardware

is a key consideration for insertion into an existing data center infrastructure, regardless of the platform provider.

Prior to specific implementation at any layer of the network, it is sound practice to test interoperability and feature

consistency in terms of availability and implementation. When considering an incumbent vendor with a new platform,

any Enterprise organization weighing migration to a new platform from their existing one, should also evaluate moving

towards a simpler high performing Juniper-based solution, which can deliver substantial incremental benefits. (See

Chapter 3: Data Center Migration—Trigger Events and Deployment Processes for more details about introducing a

second switching infrastructure vendor into an existing single vendor network.)

In summary, migrating to a simpler data center design enables an enterprise to improve the end user experience and

scale without complexity, while also driving down operational costs.

W Up to 75% of tra�c E

Legacy three-tierdata center3.

W Up to 75% of tra�c E

Juniper two-tierdata center2. Juniper’s data

center fabric1.



Chapter 2: Pre-Migration Information

Requirements



Pre-Migration Information Requirements

Migrating towards a simplified design is based on a certain level of familiarity with the following Juniper solutions:

• Juniper Networks Junos operating system

• Juniper Networks EX Series Ethernet Switches and MX Series 3D Universal Edge Routers

• Juniper Networks SRX Series Services Gateways

• Juniper Networks Network and Security Manager, STRM Series Security Threat Response Managers, and Junos Space

network management solutions

Juniper Networks Cloud-Ready Data Center Reference Architecture communicates Juniper’s conceptual framework and

architectural philosophy in creating data center and cloud computing networks robust enough to serve the range of

customer environments that exist today. It can be downloaded from: www.juniper.net/us/en/solutions/enterprise/

data-center/simplify/#literature.

Technical Knowledge and Education

This Migration Guide assumes some experience with Junos OS and its rich tool set, which will not only help simplify

the data center LAN migration but also ongoing network operations. A brief overview of Junos OS is provided in the

following section. Juniper also offers a comprehensive series of Junos OS workshops. Standardization of networking

protocols should ease the introduction of Junos OS into the data center since the basic constructs are similar. Juniper

Networks offers a rich curriculum of introductory and advanced courses on all of its products and solutions.

Learn more about Juniper’s free and fee-based online and instructor-led hands-on training offerings at:

www.juniper.net/us/en/training/technical_education.

Additional education may be required for migrating security services such as firewall and intrusion prevention system (IPS).

If needed, Juniper Networks Professional Services can provide access to industry-leading IP experts to help with all

phases of the design, planning, testing, and migration process. These experts are also available as training resources,

to help with project management, risk assessment, and more. The full suite of Juniper Networks Professional Services

offerings can be found at: www.juniper.net/us/en/products-services/consulting-services.

Junos OS Overview

Enterprises deploying legacy-based solutions today are most likely familiar with the number of different operating

systems (OS versions) running on switching, security, and routing platforms. This can result in feature inconsistencies,

software instability, time-consuming fixes and upgrades. It’s not uncommon for a legacy data center to be running

many different versions of a switching OS, which may increase network downtime and require greater time, effort, and

cost to manage the network. From its beginning, Juniper set out to create an operating system that addressed these

common problems. The result is Junos OS, which offers one consistent operating system across all of Juniper’s routing,

switching, and security devices.

www.juniper.net/us/en/solutions/enterprise/data-center/simplify/#literature




Figure 6: Junos OS - The power of one

Junos OS serves as the foundation of a highly reliable network infrastructure and has been at the core of the world’s

largest service provider networks for over 10 years. Junos OS offers identical carrier-class performance and reliability

to any sized enterprise data center LAN. Also through open, standards-based protocols and an API, Junos OS can be

customized to optimize any enterprise-specific requirement.

What sets Junos OS apart from other network operating systems is the way it is built: one operating system (OS)

delivered in one software release train, and with one modular architecture. Feature consistency across platforms and

one predictable release of new features ensure compatibility throughout the data center LAN. This reduces network

management complexity, increases network availability, and enables faster service deployment, lowering TCO and

providing greater flexibility to capitalize on new business opportunities.

Junos OS’ consistent user experience and automated tool sets make planning and training easier and day-to-day

operations more efficient, allowing for faster changes. Further, integrating new software functionality protects not just

hardware investments, but also an organization’s investment in internal systems, practices, and knowledge.

Junos OS Architecture

The Junos OS architecture is a modular design conceived for flexible yet stable innovation across many networking

functions and platforms. The architecture’s modularity and well-defined interfaces streamline new development and

enable complete, holistic integration of services.

One Architecture

ModuleX

— A

PI —

One Release Track

Frequent Releases

11.110.410.3

T Series

Junos Space

Junos Pulse

EX8216

EX8208

NSMXpress

NSM

MX Series

M Series

J Series

SECURITY ROUTERS SWITCHES

EX3200 Line

EX2200 Line

QFX3500

EX4200 Line

EX4500 Line

SRX5000 Line

SRX3000 Line

SRX210

SRX240SRX650

SRX100 LN1000

One OS

CoreBranch



Figure 7: The modular Junos OS architecture

The advantages of modularity reach beyond the operating system software’s stable, evolutionary design. For example,

the Junos OS architecture’s process modules run independently in their own protected memory space, so one module

cannot disrupt another. The architecture also provides separation between control and forwarding functions to support

predictable high performance with powerful scalability. This separation also hardens Junos OS against distributed

denial-of-service (DDoS) attacks. Junos operating system’s modularity is integral to the high reliability, performance,

and scalability delivered by its software design. It enables unified in-service software upgrade (ISSU), graceful Routing

Engine switchover (GRES), and nonstop routing.

Automated Scripting with Junoscript Automation

With Junoscript Automation, experienced engineers can create scripts that reflect their own organization’s needs and

procedures. The scripts can be used to flag potential errors in basic configuration elements such as interfaces and

peering. The scripts can also automate network troubleshooting and quickly detect, diagnose, and fix problems as

they occur. In this way, new personnel running the scripts benefit from their predecessors’ long-term knowledge and

expertise. Networks using Junoscript Automation can increase productivity, reduce OpEx, and increase high availability

(HA), since the most common reason for a network outage is operator error.

For more detailed information on Junos Script Automation, please see: www.juniper.net/us/en/community/junos.

ServiceApp 1

ServiceApp 2

ServiceApp n

ServiceApp 3

Se

rvic

es

Inte

rfa

ces

Kernel

Packet Forwarding

Physical Interfaces

SE

RV

ICE

S P

LA

NE

CO

NT

RO

L P

LA

NE

DA

TA

PL

AN

E

OPEN MANAGEMENT INTERFACES

ToolkitJ-WebCLI

Scripts NSM/Junos Space

Ma

na

gem

en

t

Ro

uti

ng

Inte

rfa

ces

Mo

du

le n



A key benefit of using Junos OS is lower TCO as a result of reduced operational challenges and improved operational

productivity at all levels in the network.

Figure 8: Junos OS lowers operations costs across the data center

An independent commissioned study conducted by Forrester Consulting3 (www.juniper.net/us/en/reports/junos_tei.pdf)

found that the use of Junos OS and Juniper platforms produced a 41% reduction in overall operations costs for network

operational tasks including planning and provisioning, deployment, and planned and unplanned network events.

Juniper Platform Overview

The ability to migrate from a three-tier network design to a simpler two-tier design with increased performance,

scalability, and simplicity is predicated on the availability of hardware-based services found in networking platforms

such as the EX Series Ethernet Switches, MX Series 3D Universal Edge Routers, and the SRX Series Services Gateways.

A consistent and unified view of the data center, campus, and branch office networks is provided by Juniper’s “single

pane of glass” management platforms, including the recently introduced Junos Space.

The following section provides a brief overview of the capabilities of Juniper’s platforms. All of the Junos OS-based

platforms highlighted provide feature consistency throughout the data center LAN and lower TCO.

EX4200 Switch with Virtual Chassis Technology

Typically deployed at the access layer in a data center, Juniper Networks EX4200 Ethernet Switch provides chassis-

class, high availability features, and high-performance throughput in a pay as you grow 1 rack unit (1 U) switch.

Depending on the size of the data center, the EX4200 may also be deployed at the aggregation layer. Offering flexible

cabling options, the EX4200 can be located at the top of a rack or end of a row. There are several different port

configurations available with each EX4200 switch, providing up to 48 wire-speed, non-blocking, 10/100/1000 ports

with full or partial Power over Ethernet (PoE). Despite its small size, this high-performance switch also offers multiple

GbE or 10Gbe uplinks to the core, eliminating the need for an aggregation layer. And because of its small size, it takes

less space, requires less power and cooling, and it costs less to deploy and maintain sparing.

Up to 10 EX4200 line switches can be connected, configured, and managed as one single logical device through built-in

Virtual Chassis technology. The actual number deployed in a single Virtual Chassis instance depends upon the physical

layout of your data center and the nature of your traffic. Connected via a 128 Gbps backplane, a Virtual Chassis can be

comprised of EX4200 switches within a rack or row, or it can use a 10GbE connection anywhere within a data center or

across data centers up to 40 km apart.

Critical Categories of Enterprise Network Operational Costs

Multiple network operating systems diminish e�ciency3

Baseline for all network operating systems

27%*Lowerwith

Junos

(Based on reductionin frequency and

duration ofunplanned

network events)

(A “plannedevents”

category)

(The “addinginfrastructure”

task)

(The time needed toresolve unplanned

network events)

(The combined totalsavings associated

with planned,unplanned, planning

and provisioning,and adding

infrastructure tasks)

54%*Lowerwith

Junos

25%*Lowerwith

Junos

40%*Lowerwith

Junos

41%*Lowerwith

Junos

Switchand RouterDowntime

Costs

Switch andRouter

Maintenanceand Support

Costs

Switch andRouter

DeploymentTime Costs

UnplannedSwitch and

RouterEvents

ResolutionCosts

OverallSwitch

and RouterNetwork

OperationsCosts

3“The Total Economic Impact of Junos Network Operating Systems”, a commissioned study conducted by Forrester Consulting on behalf of Juniper Networks, February 2009



Juniper’s Virtual Chassis technology enables virtualization at the access layer, offering three key benefits:

1. It reduces the number of managed devices by a factor of 10X.

2. The network topology now closely maps to the traffic flow. Rather than sending inter-server traffic up to an

aggregation layer and then back down in order to send it across the rack, it’s sent directly “east-to-west,” reducing

the latency for these transactions. This also more easily facilitates workload mobility when server virtualization is

deployed.

3. Since the network topology now maps to the traffic flows directly, the number of uplinks required can be reduced.

The Virtual Chassis also delivers best-in-class performance. According to testing done by Network World (see full

report at www.networkworld.com/slideshows/2008/071408-juniper-ex4200.html), the EX4200 offers the lowest

latency of any Ethernet switch they had tested, making the EX4200 an optimal solution for high-performance, low

latency, real-time applications. There has also been EX4200 performance testing done in May 2010 by Network Test

which demonstrates the low latency high performance and high availability capabilities of the EX 4200 series, viewable

at http://networktest.com/jnprvc.

When multiple EX4200 platforms are connected in a Virtual Chassis configuration, they offer the same software high

availability as traditional chassis-based platforms. Each Virtual Chassis has a master and backup Routing Engine pre-

elected with synchronized routing tables and routing protocol states for rapid failover should a master switch fail. The

EX4200 line also offers fully redundant power and cooling.

To further lower TCO, Juniper includes core routing features such as OSFP and RIPv2 in the base software license,

providing a no incremental cost option for deploying Layer 3 at the access layer.

In every deployment, the EX4200 reduces network configuration burdens and measurably improves performance for

server-to-server communications in SOA, Web services, and other distributed application designs.

For more information, refer to the EX4200 Ethernet Switch data sheet for a complete list of features, benefits, and

specifications at: www.juniper.net/us/en/products-services/switching/ex-series.

QFX3500

QFabric consists of edge, interconnect, and control devices that work together to create a high-performance, low

latency fabric that unleashes the power of the data center. QFabric represents the “1” in Juniper Networks 3-2-1

architecture, dramatically reducing complexity in the data center by delivering any-to-any connectivity while lowering

capital, management, and operational expenses.

The first QFabric product, the Juniper Networks QFX3500 represents a new level of integration and performance for

top of rack switches by being the first to combine all of the following in 1 RU.

• Ultra Low Latency - matching industry best latency for a 48+ port Ethernet switch

• L2 – full L2 switching functionality

• L3 – routing and IP addressing functions (Future)

• Storage convergence – Ethernet storage (NAS, iSCSI, FCoE)and Fibre Channel gateway

• 40G – high capacity uplinks (Future)

Refer to the QFX3500 data sheet for more information at:

www.juniper.net/us/en/local/pdf/datasheets/1000361-en.pdf

EX4500 10GbE Switch

The Juniper Networks EX4500 Ethernet Switch delivers a scalable, compact, high-performance platform for supporting

a mix of GbE and high-density 10 gigabit per second (10 Gbps) data center top-of-rack, as well as data center, campus,

and service provider aggregation deployments. The QFX3500 is the preferred platform for 10 Gigabit per second Top

of Rack Deployments. The Junos OS-based EX4500 is a 48 port wire-speed switch whose ports can be provisioned as

either gigabit Ethernet (GbE) or 10GbE ports in a two rack unit (2 U) form factor. The 48 ports are allocated with 40

1000BaseT ports in the base unit and 8 optional uplink module ports. The EX4500 delivers 960 Gbps throughput (full

duplex) for both Layer 2 and Layer 3 protocols. The EX4500 also supports Virtual Chassis technology.



For smaller data centers, the EX4500 can be deployed as the core layer switch, aggregating 10GbE uplinks from

EX4200 Virtual Chassis configurations in the access layer. Back-to-front and front-to-back cooling ensure consistency

with server designs for hot and cold aisle deployments.

Juniper plans to add support to the EX4500 for Data Center Bridging and Fibre Channel over Ethernet(FCoE) in

upcoming product releases, providing FCoE Transit Switch Functionality.

Refer to the EX4500 Ethernet Switch data sheet for more information at: www.juniper.net/us/en/products-services/

switching/ex-series/ex4500/#literature.

The QFX3500 would be the preferred platform for those organizations that are building out a high density 10 Giga-

bit Data Center. It is also a building block towards the single Data Center Fabric which Juniper will be providing in the

future. For Data Center architectures where there is a mix of primarily Gigabit and 10 Gigabit, the EX4500 would be the

appropriate platform.

EX8200 Line of Ethernet Switches

The Juniper Networks EX8200 line of Ethernet switches is a high-performance chassis platform designed for the high

throughput that a collapsed core layer requires. This highly scalable platform supports up to 160,000 media access

control (MAC) addresses, 64,000 access control lists (ACLs), and wire-rate multicast replication. The EX8200 line

may also be deployed as an end-of-rack switch for those enterprises requiring a dedicated modular chassis platform.

The advanced architecture and capabilities of the EX8200 line, similar to the EX4200, accelerate migration towards a

simplified data center design.

The EX8200-40XS line card brings 10GbE to the access layer for end-of-row configurations. This line card will deliver

25 percent greater density per chassis and consume half the power of competing platforms, reducing rack space and

management costs. The EX8200 line is expected to add Virtual Chassis support later in 2010 with additional features

being added in early 2011. With the new 40-port line card, the EX8200 line with Virtual Chassis technology will enable

a common fabric of more than 1200 10GbE ports.

The most fundamental challenge that data center managers face is the challenge of physical plant limitations. In this

environment, taking every step possible to minimize power draw for the required functionality becomes a critical goal.

For data center operators searching for the most capable equipment in terms of functionality for the minimum in rack

space, power, and cooling, the EX8200 line delivers higher performance and scalability in less rack space with lower

power consumption than competing platforms.

Designed for carrier-class HA, each EX8200 line model also features fully redundant power and cooling, fully

redundant Routing Engines, and N+1 redundant switch fabrics.

For more information, refer to the EX8200 line data sheets for a complete list of features and specifications at:

www.juniper.net/us/en/products-services/switching/ex-series.

MX Series 3D Universal Edge Routers

It’s important to have a consistent set of powerful edge services routers to be able to interconnect the data center to

other data centers and out to dispersed users. The MX Series with the new Trio chipset delivers cost-effective, powerful

scaling that allows enterprises to support application-level replication for disaster recovery or virtual machine migration

between data centers by extending VLANs across data centers using mature, proven technologies such as VPLS.

It is interesting to note the following observation from the recent 2010 MPLS Ethernet World Conference from the Day 3

Data Center Interconnect session: “VPLS is the most mature technology today to map DCI requirements”.

Delivering carrier-class HA, each MX Series model features fully redundant power and cooling, fully redundant Routing

Engines, and N+1 redundant switch fabrics.

For more information, refer to the MX Series data sheet for a complete list of features, benefits, and specifications at:

www.juniper.net/us/en/products-services/routing/mx-series.

www.juniper.net/us/en/products-services/switching/ex-series/ex4500/#literature


www.juniper.net/us/en/products-services/routing/mx-series



Consolidated Security with SRX Series Services Gateways

The SRX Series Services Gateways replace numerous legacy security solutions by providing a suite of services in one

platform, including a firewall, IPS, and VPN services.

Supporting the concept of zones, the SRX Series can provide granular security throughout the data center LAN. The

SRX Series can be virtualized and consolidated into a single pool of security services via clustering. The SRX Series

can scale up to 10 million concurrent sessions allowing the SRX Series to massively and rapidly scale to handle any

throughput without additional devices, multiple cumbersome device configurations, or operating systems.

The highly scalable performance capabilities of the SRX Series platform, as with the EX Series switches, lays the

groundwork for a simplified data center infrastructure and enable enterprises to easily scale to meet future growth

requirements. This is in contrast to legacy integrated firewall modules and standalone appliances which have limited

performance scalability. Even when multiple firewall modules are used, the aggregate performance may still be far

below the throughput required for consolidating applications or data centers, where firewall aggregate throughput of

greater than 100 gigabits may be required. The lack of clustering capabilities in some legacy firewalls not only limits

performance scalability but also increases management and network complexity.

The SRX Series provides HA features such as redundant power supplies and cooling fans, as well as redundant switch

fabrics. This robust platform also delivers carrier-class throughput. The SRX5600 is the industry’s fastest firewall and

IPS by a large margin, according to Network World.

For more information, refer to the SRX Series data sheet for a complete list of features, benefits, and specifications at:

www.juniper.net/us/en/products-services/security/srx-series.

Juniper Networks vGW Virtual Gateway

To address the unique security challenges of virtualized networks and data centers, the vGW virtual firewall and cloud

protection software provides network and application visibility and granular control over virtual machines (VM).

Combining a powerful stateful virtual firewall, VM Introspection and automated compliance assessment, the vGW

Virtual Gateway protecting virtualized workloads slipstreams easily into Juniper environments featuring any of the

following:

• SRX Series Services Gateways

• STRM Series Security Threat Response Managers

• IDP Series Intrusion Detection and Prevention Appliances

The vGW integrations focus on preserving customers’ investment into Juniper security, and extending it to the

virtualized infrastructure with the similar feature, functionality, and enterprise-grade requirements like high-

performance, redundancy, and central management.

Juniper customers can deploy the vGW software on the virtualized server, and integrate security policies, logs, and

related work flow into existing SRX Series, STRM Series, and IDP Series infrastructure. Customers benefit from layered,

granular security without the management and OpEx overhead. vGW will export firewall logs and inter-VM traffic flow

information to STRM Series to deliver ‘single-pane’ of glass for threat management. Customers who have deployed

Juniper Networks IDP Series, and management processes around threat detection and mitigation can extend that to

the virtualized server infrastructure with no additional CapEx investment.

The vGW Virtual Gateway’s upcoming enhancements with SRX Series and Junos Space continues on the vision to

deliver ‘gapless’ security with a common management platform. The vGW-SRX Series integration will ensure trust zone

integrity is guaranteed to the last mile - particularly relevant in cloud and shared-infrastructure deployments. vGW

integration with Junos Space will bridge the gap between management of physical resources and virtual resources to

provide a comprehensive view of the entire data center.

Refer to the vGW Virtual Gateway datasheet for more:

www.juniper.net/us/en/local/pdf/datasheets/1000363-en.pdf.



MPLS/VPLS for Data Center Interconnect

The consolidation of network services increases the need for Data Center Interconnect (DCI). Resources in one data

center are often accessed by one or more data centers. Different business units, for example, may share information

across multiple data centers via VPNs. Or compliance regulations may require that certain application traffic be kept

on separate networks throughout data centers. Or businesses may need a real-time synchronized standby system to

provide optimum HA in a service outage.

MPLS is a suite of protocols developed to add transport and virtualization capabilities to large data center networks.

MPLS enables enterprises to scale their topologies and services. An MPLS network is managed using familiar protocols

such as OSPF or Integrated IS-IS and BGP.

MPLS provides complementary capabilities to standard IP routing. Moving to an MPLS network provides business

benefits like improved network availability, performance, and policy enforcement. MPLS networks can be employed for

a variety of reasons:

• Inter Data Center Transport: To connect consolidated data centers to support mission critical applications. For

example, real-time mainframe replication or disk, database, or transaction mirroring.

• Virtualizing the Network Core: For logically separating network services. For example, providing different levels of

QoS for certain applications or separate application traffic due to compliance requirements.

• Extending L2VPNs for Data Center Interconnect: To extend L2 domains across data centers using VPLS. For example,

to support application mobility with virtualization technologies like VMware VMotion, or to provide resilient business

continuity for HA by copying transaction information in real time to another set of servers in another data center.

The MX Series provides high capacity MPLS and VPLS technologies. MPLS networks can also facilitate migration

towards a simpler, highly scalable and flexible data center infrastructure.

Juniper’s Unified Management Solution

Juniper provides three powerful management solutions for the data center LAN via its NSM and STRM Series platforms,

as well as Junos Space.

For more information on MPLS/VPLS, please refer to the “Implementing VPLS for Data Center Interconnectivity”

Implementation Guide at: www.juniper.net/us/en/solutions/enterprise/data-center/simplify/#literature.

Network and Security Manager

NSM offers a single pane of glass to manage and maintain Juniper platforms as the network grows. It also helps

maintain and configure consistent routing and security policies across the entire network. And NSM helps delegate

roles and permissions as well.

Delivered as a software application or a network appliance, NSM provides many benefits:

• Centralized activation of routers, switches, and security devices

• Granular role-based access and policies

• Global policies and objects

• Monitoring and investigative tools

• Scalable and deployable solutions

• Reliability and redundancy

• Lower TCO



The comprehensive NSM solution provides full life cycle management for all platforms in the data center LAN.

• Deployment: Provides a number of options for adding device configurations into the database, such as importing a

list of devices, or discovering and importing deployed network devices, or manually adding a device and configuration

in NSM, or having the device contact NSM to add its configuration to the database.

• Configuration: Offers central configuration to view and edit all managed devices. Provides offline editing/modeling

of device configuration. Facilitates the sharing of common configurations across devices via templates and policies.

Provides configuration file management for backup, versioning, configuration comparisons, and more.

• Monitoring: Provides centralized event log management with predefined and user-customizable reports. Provides

tools for auditing log trends and finding anomalies. Provides automatic network topology creation using standards-

based discovery of Juniper and non-Juniper devices based on configured subnets. Offers inventory management

for device management interface (DMI)-enabled devices, and Job Manager to view device operations performed by

other team members.

• Maintenance: Delivers centralized Software Manager to version track software images for network devices. Other

tools also transform/validate between user inputs and device-specific data formats via DMI schemas.

Using open standards like SNMP and system logging, NSM has support for third-party network management solutions

from IBM, Computer Associates, InfoVista, HP, EMC, and others.

Refer to the Network and Security Manager data sheet for a complete list of features, benefits, and specifications:

www.juniper.net/us/en/products-services/security/nsmcm.

STRM Series Security Threat Response Managers

Complementing Juniper’s portfolio, the STRM Series offers a single pane of glass to manage security threats. It

provides threat detection, event log management, compliance, and efficient IT access to the following:

• Log Management: Provides long-term collection, archival, search, and reporting of event logs, flow logs, and

application data.

• Security Information and Event Management (SIEM): Centralizes heterogeneous event monitoring, correlation, and

management. Unrivaled data management greatly improves IT’s ability to meet security control objectives.

• Network Behavior Anomaly Detection (NBAD): Discovers aberrant network activities using network and application

flow data to detect new threats that others miss.

Refer to the STRM Series data sheet for a complete list of features, benefits, and specifications: www.juniper.net/us/

en/products-services/security/strm-series.

Junos Space

Another of IT’s challenges has been adding new services and applications to meet the ever growing demand. Historically,

this has not been easy, requiring months of planning and only making changes in strict maintenance windows.

Junos Space is a new, open network application platform designed for building applications that simplify network

operations, automate support, and scale services. Organizations can take control of their own networks through self-

written programs or third-party applications from the developer community. Embodied in a number of appliances

across Juniper’s routing, switching, and security portfolio, an enterprise can seamlessly add new applications, devices,

and device updates as they become available from Juniper and the developer community, without ever restarting the

system for full plug and play.



Junos Space applications include:

• Junos Space Virtual Control allows users to monitor, manage, and control the virtual network environments that

support virtualized servers deployed in the data center. Virtual Control provides a consolidated solution for network

administrators to gain end-to-end visibility into, and control over, both virtual and physical networks from a single

management screen. By enabling network-wide topology, configuration, and policy management, Virtual Control

minimizes errors and dramatically simplifies data center network orchestration, while at the same time lowering

total cost of ownership by providing operational consistency across the entire data center network. Virtual Control

also greatly improves business agility by accelerating server virtualization deployment.

Juniper has also formed a new collaboration with VMware that takes advantage of its open APIs to achieve seamless

orchestration across both physical and virtual network elements by leveraging Virtual Control. The combination of

Junos Space Virtual Control and VMware vSphere™ provides automated orchestration between the physical and virtual

networks, wherein a change in the virtual network is seamlessly carried over the physical network and vice versa.

• Junos Space Ethernet Design is a Junos Space software application that enables end-to-end campus and data

center network automation. Ethernet Design provides full automation including configuration, provisioning,

monitoring, and administration of large switch and router networks. Designed to enable rapid endpoint connectivity

and operationalization of the data center, Ethernet Design uses a best practice configuration and scalable workflows

to scale data center operations with minimal operational overhead. It is a single pane of glass platform for end-to-

end network automation that improves productivity via a simplified, “create one, use extensively” configuration and

provisioning model.

• Junos Space Security Design enables fast, easy, and accurate enforcement of security state across the enterprise

network. Security Design enables quick conversion of business intent to device-specific configuration, and it enables

auto-configuration and provisioning through workflows and best practices to reduce the cost and complexity of

security operations.

• Service Now and Junos Space Service Insight consists of Junos Space applications that enable fast and proactive

detection, diagnosis, and resolution of network issues. (See Automated Support with Service Now for more details.)

• Junos Space Network Activate facilitates fast and easy setup of VPLS services, and allows for full lifecycle

management of MPLS services

In addition, the Junos Space Software Development Kit (SDK) will be released to enable development of a wide range

of third-party applications covering all aspects of network management. Junos Space is designed to be open and

provides northbound, standards-based APIs for integration to third-party data center and service provider solutions.

Junos Space also includes DMI based on NetConf, an IETF standard, which can enable management of DMI-compliant

third-party devices.

Refer to the following URL for more information on Junos Space applications: www.juniper.net/us/en/products-

services/software/junos-platform/junos-space/applications.

www.juniper.net/us/en/products-services/software/junos-platform/junos-space/applications

www.juniper.net/us/en/products-services/software/junos-platform/junos-space/applications



Automated Support with Service Now

Built on the Junos Space platform, Service Now delivers on Juniper’s promise of network efficiency, agility, and

simplicity by delivering service automation that leverages Junos OS embedded technology.

For devices running Junos OS 9.x and later releases, Service Now aids in troubleshooting for Juniper’s J-Care Technical

Services. Junos OS contains the scripts which provide device and incident information that is relayed to the Service

Now application where it is logged, stored, and with the customer’s permission, forwarded to Juniper Networks

Technical Services for immediate action by the Juniper Networks Technical Assistance Center (JTAC).

Not only does Service Now provide automated incident management, it offers automated inventory management for

all Junos OS devices running release 9.x and later. These two elements provide substantial time savings in the form

of more network uptime and less time spent on administrative tasks like inventory data collection. This results in a

reduction of operational expenses and streamlined operations, allowing key personnel to focus on the goals of the

network rather than its maintenance—all of which enhance Juniper’s ability to simplify the data center.

Figure 9: Troubleshooting with Service Now

The Service Insight application, available in Fall 2010 on the Junos Space platform, takes service automation to the

next level by delivering proactive, customized support for networks running Juniper devices. While Service Now enables

automation for reactive support components such as incident and inventory management for efficient network

management and maintenance, Service Insight brings a level of proactive, actionable network insight that helps

manage risk, lower TCO, and improve application reliability.

The first release of Service Insight will consist of the following features:

• Targeted product bug notification: Proactive notification to the end user of any new bug notification that could

impact network performance and availability with analysis of which devices could be vulnerable to the defect. This

capability can avoid network incidents due to known product issues, as well as save numerous hours of manual

impact analysis for system-wide impact of a packet-switched network (PSN).

• EOL/EOS reports: On-demand view of the end of life (EOL), end of service (EOS), and end of engineering (EOE)

status of devices and field-replaceable units (FRUs) in the network. This capability brings efficiency to network

management operations and mitigates the risk of running obsolete network devices and/or software/firmware.

With this capability, the task of taking network inventory and assessing the impact of EOL/EOS announcements is

reduced to the touch of a button instead of a time-consuming analysis of equipment and software revision levels

and compatibility matrices.

JuniperSupport System

ServiceInsight

Gateway

JUNIPER

AI ScriptsInstalled

CUSTOMERNETWORK

CUSTOMER ORPARTNER NOC

Service Now

INTERNET

JMBHardwareSo�ware

ResourcesCalibration



Chapter 3: Data Center Migration -Trigger Events and

Deployment Processes



How Migrations Begin

Many enterprises have taken on server, application, and data center consolidations to reduce costs and to increase the

return on their IT investments. To continue their streamlining efforts, many organizations are also considering the use of

cloud computing in their pooled, consolidated infrastructures. While migrating to a next-generation cloud-ready data

center design can theoretically take place at any time, most organizations will not disrupt a production facility except

for a limited time-window to perform scheduled maintenance and continuity testing, or for a suitably compelling

reason whose return is worth the investment and the work.

In Chapter 3 of this guide, we identify a series of such reasons—typically stimulated by trigger events—and the way

these events turn into transitions at various insertion points in the data center network. We also cover the best

practices and steps involved in migration at each of the insertion points presented by a specific trigger event. By

following these steps and practices, it is possible to extend migration to legacy network tiers and move safely towards

a simplified data center infrastructure.

Trigger Events for Change and Their Associated Insertion Points

Change in the data center network is typically determined by the type of event triggering the organization to make

that change. What follows is a short description of trigger events which can stimulate an organization to make the

investments related to these events:

• Provisioning a new area of infrastructure area or Point of Delivery (POD) in an existing data center due to

additional capacity required for new applications and services. The new applications may also have higher

performance requirements that cannot be delivered by the existing infrastructure.

• Technology refresh due to either EOL on a given product line or an upgrade to the latest switching and/or server

technology. A refresh can also be driven by the end of an equipment depreciation cycle, company policy regarding

available headroom capacity, or for adding capacity to meet planned future expansion.

• Infrastructure redesign due to increased use of server virtualization.

• Data center consolidation due to merger or acquisition, cost saving initiatives, or moving from an existing co-

location facility. Due to the increased scalability, performance, and high availability requirements, data center

consolidation may also require a technology refresh.

• Business continuity and workload mobility initiatives. Delivering HA and VM/application mobility typically involves

“VLAN stretching” within or between data centers.

• Upgrade to the core data center network for higher bandwidth and capacity to support new capabilities such as

server virtualization/workload mobility or higher application performance. This may also be due to a technology

refresh as a result of the retirement of legacy equipment which is at end of life (EOL).

• Need for higher performance and scale in security. Existing security gateways, whether integrated in a chassis

or running as standalone appliances, may not be able to deliver the higher performance required to support the

increased traffic from data center consolidation, growth in connected devices, increased extranet collaboration,

and internal/external compliance and auditing requirements. Server, desktop, and application virtualization may

also drive changes in the security model, to increase the strength of security in the new environments and ease

complexity in management. Enhancements can be made to the core, edge, or virtual server areas of the data center

network to deal with these requirements.

• OnRamp to QFabric: QFabric represents the “1” in Juniper Networks 3-2-1 architecture, dramatically reducing

complexity in the data center by delivering any-to-any connectivity while lowering capital, management, and

operational expenses. QFabric consists of edge, interconnect, and control devices that work together to create a

high-performance, low latency fabric that unleashes the power of the data center. The QFabric technology also

offers unprecedented scalability with minimal additional overhead, supporting converged traffic and making it

easy for enterprises to run Fibre Channel, Ethernet, and Fibre Channel over Ethernet on a single network. The high-

performance, non-blocking, and lossless QFabric architecture delivers much lower latency than traditional network

architectures--crucial for server virtualization and the high-speed communications that define the modern data

center. The first QFabric product, the Juniper Networks QFX3500, delivers a 48-port 10GbE top-of-rack switch that

provides low latency, high-speed access for today’s most demanding data center environments. When deployed

with the other components, the QFX3500 offers a fabric-ready edge solution that contributes to the QFabric’s highly

scalable, highly efficient architecture for supporting today’s exponential data center.



Addressing any or all of these trigger events results in deployment of new technology into the access, aggregation,

core, or services tiers of an existing data center network.

Considerations for Introducing an Alternative Network Infrastructure Provider

In some installations, a key consideration when evolving an existing infrastructure is the impact of introducing another

vendor. Organizations can minimize any impact by using the same best practices they employ in a single vendor

network. For example, it is sound practice to test interoperability and feature consistency before an implementation at

any network layer. Many enterprises do this today, since there are often multiple inconsistent versions of an operating

system within a single vendor’s portfolio, or even completely different operating systems within that portfolio. For

example, the firewall or intrusion prevention system (IPS) platforms may have a different OS and interface from the

switching products. Even within a switching portfolio, there may be different operating systems, each supporting

different feature implementations.

It is also sound practice to limit fault domains and contain risks when introducing an additional vendor. This can be

accomplished with a building block design for the target insertion point, when deploying into an existing LAN. This

approach allows for definition of the new insertion as a functional module, testing of the module in proof-of-concept

(PoC) environments before deployment, and clean insertion of the new module into production after testing. As

mentioned earlier, PoC testing is often done as a best practice in a single vendor network as well.

Other steps that can ensure successful insertion of Juniper Networks technology into an existing data center LAN include:

• Training

• Multivendor automation and management tools

Training

The simplicity of Juniper’s implementations typically minimizes the need for extensive training to accompany

deployment; however, Juniper also offers a variety of training resources to accelerate deployments. To start with,

standardization of protocols within the network typically eases introduction, since basic constructs are similar and

interoperability has usually been tested and proven ahead of time by Juniper. Beyond the protocols, differences in

command-line interface (CLI) are usually easier to navigate than people initially think. Time after time, people familiar

with other CLIs find themselves able to make the transition quickly due to the consistent, intuitive nature of Junos

operating system’s implementation (it is easy to learn and use). Junos OS also has a tremendous amount of flexibility

and user support built into it. For example, to ease migration from Cisco’s IOS, there is a Junos OS command to display

a configuration file in a format similar to IOS. Additionally, hands-on training is available in the form of a two-day boot

camp. Customized training can also be mapped to address any enterprise’s specific environment. Training not only

gives an opportunity to raise the project team’s skill level, but also to get experience with any potential configuration

complexities prior to entering the implementation phase of a project.

Junos OS also provides embedded automation capabilities. A library of scripts that automate common operations

tasks is readily available online for viewing and downloading. Categorized by function, the script with the best fit can

easily be found. Refer to the Junos OS Script Library for a complete list: www.juniper.net/us/en/community/junos/

script-automation/library.

Multivendor Automation and Management Tools

In a multivendor environment, it is often critical to establish a foundation of multivendor management tools that

work with existing suppliers as well as with Juniper. There are well established multivendor tools available in the

fault and performance analysis areas. These tools work with equipment from all of the major vendors in the market

including Juniper and other vendors. In the provisioning, configuration, inventory management, and capacity planning

areas, existing third-party tools typically don’t scale or leverage the capabilities and best practices of each vendor’s

equipment. In these situations, it works well to leverage an integrated platform like Junos Space to support the Juniper

infrastructure consistently, and, where possible, to incorporate support for other vendors’ platforms and applications

if the APIs and SDKs of Junos Space can be used to complete that integration. Junos Space provides APIs and SDKs

to customize existing applications, and also enables partners to integrate their applications into this homogenous

application platform.



Trigger Events, Insertion Points, and Design Considerations

To summarize the preceding discussions, the table below highlights the mapping between a trigger event, the

corresponding network insertion point, and the network design considerations that are pertinent in each of the data

center tiers.

Table 1: Trigger Event Design Consideration Summary

TRIGGER EVENT NETWORK INSERTION LAyER(S) DESIGN CONSIDERATIONS

New application or service

Technology refresh

Server virtualization

New switching infrastructure for:

• Access

• Aggregation

• Core

Top–of-rack or end-of-row deployment

Cabling changes

Traffic patterns among servers

VLAN definitions for applications/services segmentation

L2 domain for VM workload mobility

Server connectivity speed: GbE/10GbE

• Application latency requirements

• Network interface card (NIC) teaming

• Fibre Channel Storage Network Convergence

Uplinks

• Uplink oversubscription ratios

• Number and placement of uplinks

• GbE/10GbE uplinks

• Use of L2 or L3 for uplinks

• IEEE Spanning Tree Protocol (STP)

• Redundant trunk groups as STP alternative

- Link aggregation sizing/protocol

QoS

• Classification and prioritization

• Policing

High availability (HA) requirements

Multicast scalability/performance requirements

Interoperability testing definitions

IOS configuration for conversion to Junos OS

Data center consolidation Aggregation/core layer

Access layer

Services layer

Sufficiency of existing physical capacity

Interior gateway protocol (IGP) and exterior gateway protocol (EGP) design

Multicast requirements

L2/L3 domain boundaries

IEEE STP

Default gateway/root bridge mapping

Virtualized services support requirements (VPN/VRF)

Uplinks

Density

Speed

Link aggregation

Scaling requirements for MAC addresses and ACLs

Latency requirements

Fibre Channel Storage Network Convergence

HA features

QoS

Security Policies

• Existing policy migration

• ACL migration

• New policy definitions





TRIGGER EVENT NETWORK INSERTION LAyER(S) DESIGN CONSIDERATIONS

Business continuity

Workload mobility

Data center core network

upgrade

Core layer Sufficiency of existing physical capacity

VLAN definitions for applications/services segmentation

VLAN/VPN routing and forwarding (VRF) mapping

Latency/performance requirements

Traffic engineering/QoS requirements

Connecting with legacy/proprietary IGP protocols

Data Center Interconnect (DCI) method

Stretching VLANs

• Physical layer extension via dense wavelength-division

multiplexing (DWDM)

• VPLS/MPLS



Higher performance security

services

Aggregation/core layer Insertion Capacity and throughput requirements

Compliance and audit requirements

Existing security policy rules migration

Zone definitions

Virtual machine security requirements for virtual firewall


IOS to Junos OS Conversion Tools

For organizations with existing Cisco IOS configurations, Juniper provides an IOS to Junos OS (I2J) migration tool.

I2J is a web-based software translation tool that converts Cisco IOS configurations for Cisco Catalyst switches and

Cisco routers into their Junos OS equivalent. I2J lowers the time and cost of migrating to Juniper router and switching

platforms. The I2J tool supports configurations for physical and logical interfaces, routing protocols, routing policies,

packet filtering functions, and system commands. I2J also automatically flags any conversion errors or incompatible

configurations. It can be used for IOS configuration conversions at all network insertion points. Figure 9 shows a

sample I2J screen.

Since all network operating systems are not created equal, it should be noted that a straight IOS to Junos OS

conversion may mask opportunities to improve the overall network configuration or implement features or functions

not possible with IOS. Conversely, I2J also helps identify IOS-specific features which may not be implementable under

Junos OS in a direct 1:1 mapping but need to be implemented in an alternate manner.

Figure 10: Converting IOS to Junos OS using I2J

I2J is only available to Juniper customers or partners with a support contract via a secure Advanced Encryption

Standard (AES) 256-bit encrypted website found at: https://i2j.juniper.net.



IOS Input Page

The main interface for I2J supports upload or cut and paste of IOS configuration files. You can adjust a variety of

translation options, such as outputting verbose IOS comments or consolidating firewall terms. Then use the Translate

button to convert the IOS file into Junos OS. The output is displayed with statistics, the Junos OS configuration output,

and the IOS source with messages.

Figure 11: The I2J input page for converting IOS to Junos OS

Data Center Migration Insertion Points: Best Practices and Installation Tasks

The legacy three-tier design found in many of today’s data centers was depicted in Figure 1. This is the baseline for

layer insertion points addressed in this document. For a specific insertion point such as the access layer, for example,

the recommended Juniper best practices pertaining to that layer are provided first. This is then followed by the

recommended preinstallation, installation, and post installation tasks.

Recommended best practices and installation-related tasks focus primarily on currently shipping products and

capabilities.

A dedicated Troubleshooting chapter detailing Juniper recommended guidelines for the most commonly encountered

migration and installation issues is also included in this guide.

New Application/Technology Refresh/Server Virtualization Trigger Events

These events are often driven by a lack of capacity in the existing infrastructure to support a new application or service.

They may also occur when an organization is trying to maximize its processor capacity through use of virtual servers.

Redesigns based on these triggers can involve upgrades to either data center access or aggregation tiers (or both) as

described later in this section. They may also involve a redesign across data centers, addressed later in the Business

Continuity and Workload Mobility Trigger Events section. In general, server virtualization poses an interesting set of

design challenges, detailed at the end of this section.

The insertion point for each of these triggers often involves provisioning one or more new Points of Delivery (PODs) or

designated sections of a data center layout, including new switches for the network’s access layer. The new POD(s)

may also include an upgrade of the related aggregation layer which, depending on the requirements, could potentially

later serve as the core in a simplified two-tier design. The process may also involve a core switch/router upgrade or

replacement to increase functionality and bandwidth for each new POD requirement.

For 10GbE server connectivity in a top of rack deployment, Juniper’s recommended design would be based on either the

QFX3500 or EX4500. The choice would be based on several factors.

• The QFX3500 would be the preferred platform where sub microsecond latency is required such as a high

performance compute cluster and financial services transactions.



• The QFX3500 is also preferred for 10 Gigabit data center designs and for those deployments requiring FCoE and

Fibre Channel Gateway functionality.

• The QFX3500 also is a building block to Juniper’s QFabric technology to deliver a data center fabric which enables

exponential gains in scale,performance and efficiency.

The EX4500 is typically deployed in smaller Enterprise as a data center aggregation switch or in a smaller campus

environment. When the requirement is for GbE server connectivity, the EX4200 would be the platform of choice, where

up to 480 GbE server connections may be accommodated within a single Virtual Chassis.

For 10 Gigabit connectivity, the QFX3500 enables IT organizations to take advantage of the opportunity to converge

I/O in a rack. Servers can connect to the QFX3500 using a converged network adaptor (CNA) over 10Gb channeling

both IP and SAN traffic over a single interface. The QFX3500 devices will in turn connect directly to the data center

SAN Array functioning as a Fiber Channel (FC) gateway. Additionally, the solution can support operating the QFX3500

as a FC transit switch and connect it to an external SAN director that will fulfill the FC gateway functionality.

Design Options and Best Practices: New Application/Technology Refresh/Server Virtualization Trigger Events

When deploying a new access layer as part of this trigger event, there are issues related to uplink oversubscription,

STP, and Virtual Chassis. Understanding design options and best practices for each of these topics is important to

a successful deployment. This next section will cover access layer migration for Gigabit connected servers. The next

version of the data center Migration guide will include 10 Gigabit as well as Fibre Channel convergence best practices.

Tunable Oversubscription in Uplink Link Aggregation

In legacy networks, oversubscription is an ongoing issue, leading to unpredictable performance and the inability to

deploy or provision a new application with confidence. Oversubscription typically occurs between the access and the

core/aggregation switches (on the access network uplinks).

Juniper provides a tunable oversubscription ratio of from 1 to 12 between the access and the core with the EX4200

Virtual Chassis. Up to 10 EX4200 Virtual Chassis systems can be configured together to perform and be managed as

one device. Each Virtual Chassis supports up to 48 GbE connections and up to two 10GbE uplinks.

A full configuration of 10 EX4200s has up to 480 GbE ports + 2 x (m) x 10GbE uplinks, where m is 1 to 10. The

oversubscription ratio is tuned by adjusting the number of units in the Virtual Chassis, the number of GbE ports, and the

10GbE uplinks. An oversubscription ratio of 1, delivering full wire rate, is achieved when there is no greater than 2 units

in a Virtual Chassis configuration and 40 gigabit user ports provisioned. An oversubscription ratio of 12:1 is achieved if

there are 480 GbE ports and 4x10GbE uplinks.

The target oversubscription ratio is always going to be based on the applications and services that the Virtual Chassis

is expected to support. It can be easily adjusted by adding or removing 10GbE uplinks, or by increasing or reducing

the number of member switches in the Virtual Chassis. For example, a 5 to 6 member Virtual Chassis using two to

four 10GbE uplinks delivers oversubscription ratios between 7:1 and 12:1. Or, a 7 to 8 member Virtual Chassis using 4

10GbE uplinks, two in the middle and two at the ends, delivers oversubscription ratios between 8:1 and 9:1. While these

oversubscription levels are common, the most important point is that they can be adjusted as needed.

Spanning Tree Alternatives for Access Layer Insertion Point

STP offers benefits to the data center, but it is also plagued with a number of well-known and hard to overcome issues.

These include inefficient link utilization, configuration errors that can potentially bring an entire L2 domain down, and

other problems. To avoid these issues, enterprises may consider alternative architectures to STP when inserting a new

POD into the network. These can include an inverted U design, Redundant Trunk Groups (RTGs), and L3 uplinks.

Inverted U Design

An enterprise can create an STP-free data center topology when using an L2 domain to facilitate virtual machine

mobility through the way it connects servers to an access layer switch. An inverted U design can be used such that

no L2 loops are created. While technologies like STP or RTG aren’t required to prevent the loop, best practices still

recommend provisioning STP to prevent accidental looping due to incorrect configuration.



There are two basic options to provision this design: two physically separate servers connected to two separate access

layer switches, or two separate Virtual Chassis units in a Juniper deployment as depicted in Figure 11.

Figure 12: Inverted U design using two physical servers

The bold lines show that there are no loops in this upside down or inverted U design. Load balancers are typically used

in this design for inbound server traffic as well as Global Load Balancing Protocol on outbound server traffic.

The next option is to use NIC teaming within a VMware infrastructure as depicted in Figure 12.

Figure 13: Inverted U design with NIC teaming

This option, using network interface teaming in a VMware environment, is the more prevalent form of an inverted

U design. NIC teaming is a feature of VMware Infrastructure 3 that allows you to connect a single virtual switch to

multiple physical Ethernet adapters. A team can share traffic loads between physical and virtual networks and provide

passive failover in case of an outage. NIC teaming policies are set at the port group level.

Access

EX82XX EX82XX

802.3ad LAG802.1q Trunking



Virtual Chassis Virtual ChassisEX4200 EX4200

AGGREGATION / CORE

EX4200EX4200

EX82XX EX82XX



pNIC1 pNIC2


Access

vNIC1 10.0.1.4/24

vNIC2 10.0.2.4/24

AGGREGATION / CORE

http://www.vmware.com/



For more detailed information on NIC teaming using VMware Infrastructure 3, refer to:

www.vmware.com/technology/virtual-networking/virtual-networks.html

www.vmware.com/files/pdf/virtual_networking_concepts.pdf

The main advantages to the inverted U design are that all ports on the aggregation switches have useable bandwidth

100% of the time, traffic flows between access and aggregation are always deterministic, and there is a deterministic

latency to all Virtual Chassis connected to a single aggregation or core switch.

Redundant Trunk Groups

LAN designs using the EX4200 Ethernet Switch with Virtual Chassis technology also benefit from RTG protocol as a

built-in, optimized replacement to STP for sub-second convergence and automatic load balancing.

RTG is an HA link feature of the EX Series Ethernet Switches that eliminates the need for STP. In fact, STP can’t be

provisioned on an RTG link. Ideally implemented on a switch with a dual-home connection, RTG configures one link

as active and forwarding traffic, and the other link as blocking and backup to the active link. RTG provides extremely

fast convergence in the event of a link failure. It is similar in practice to Rapid Spanning Tree Protocol (RSTP) root and

alternate port, but doesn’t require an RSTP configuration.

Layer Three Uplinks

Another alternative is to use L3 uplinks from the access layer to the aggregation/core switches. This limits L2 domain and

VLANs to a single Virtual Chassis. Equal-cost multipath (ECMP), which is included in the base license for L3 OSPF on

EX Series data center switches, is used for uplinks. An advanced license is needed if BGP, IS-IS, or Ipv6 are required. Up

to 480 servers can be provisioned with one EX4200 Virtual Chassis. This allows applications to maintain L2 adjacency

within a single switch, however servers are typically collocated within a single row which is part of the Virtual Chassis. The

VLAN boundary is the access layer for low latency application data transfer. Virtual Chassis extension would allow distant

servers to be accommodated as well. These servers would be part of a single Virtual Chassis domain.

Virtual Chassis Best Practices

These best practices should be followed when deploying and operating the EX4200 at the access layer:

• When designing a Virtual Chassis configuration, consider a deployment in which ports are distributed across as many

switches as possible to provide the highest resiliency and the smallest failure domain.

• When possible, place uplink modules in the Virtual Chassis configuration line card switches, and place uplinks in

devices which are separated at equal distances by member hop.

• Use the virtual management Ethernet (VME) interface as the management interface to configure Virtual Chassis

technology options.

• Evenly space master and backup switches by member hop when possible.

• When installing a Virtual Chassis configuration, explicitly configure the mastership priority of the members that you

want to function as the master and backup switches.

• When removing a switch from a Virtual Chassis configuration, immediately recycle its member ID so that the ID

becomes the next lowest available unused ID. In this way, the replacement switch automatically is assigned that

member ID and inherits the configuration of the original switch.

• Specify the same mastership priority value for the master and backup switches in a Virtual Chassis configuration.

• Configure the highest possible mastership priority value (255) for the master and backup switches.

• Place the master and backup switches in separate locations when deploying an extended Virtual Chassis

configuration.

• For maximum resiliency, interconnect Virtual Chassis member devices in a ring topology.

• When changing configuration settings on the master switch, propagate changes to all other switches in the Virtual

Chassis configuration via a “commit sync” command.

Refer to Juniper’s Virtual Chassis Technology Best Practices Implementation Guide for more information:

www.juniper.net/us/en/products-services/switching/ex-series/ex4200/#literature.




Figure 13 below depicts an EX4200 Virtual Chassis top-of-rack access layer deployment.

Figure 14: EX4200 top-of-rack access layer deployment

Access Layer Preinstallation Tasks

• One of the first tasks is to determine space requirements for the new equipment. If the new access layer switches are

to be housed in new racks, make sure that there is adequate space for the racks in the POD or data center. Or, if it is

a switch refresh, ensure that there is sufficient space in the existing racks to accommodate the new switches. If the

existing racks have the capacity, the eventual switchover becomes a matter of simply switching server cables from

the old switches to the new ones. New racks are usually involved when a server refresh is combined with a switch

refresh. It is assumed that data center facilities already have the power, cooling, airflow, and cabling required for any

new equipment being provisioned.

• In a top-of-rack configuration, the EX4200 with Virtual Chassis technology can be logically viewed as a single

chassis horizontally deployed across racks. It is important to understand the traffic profiles, since this determines the

number of required uplinks. If the traffic flows are predominantly between servers, often referred to as “east-west”

traffic, fewer uplinks to the core network layer are required since inter-server traffic primarily traverses the Virtual

Chassis’ 128 Gbps backplane. The number of uplinks required is also a function of acceptable oversubscription

ratios, which can be easily tuned as per the Virtual Chassis Best Practices section. The EX4200 with Virtual Chassis

technology may also be used in an end-of-row deployment taking these same considerations into account.

• When connecting to an existing non-Juniper aggregation layer switch, it’s important to use open standard protocols

such as 802.1Q for trunking VLANs and Multiple VLAN Registration Protocol (MVRP) if VLAN propagation is desired.

To ensure interoperability, one of the standards-based STPs (IEEE STP, Rapid Spanning Tree Protocol, or Multiple

Spanning Tree Protocol) should also be used.

• If they exist, company standard IOS-based access layer configurations should be collected. They can be quickly and

easily converted into Junos OS using Juniper’s I2J translation tool as previously described.

• To simplify the deployment process and ensure consistent configurations when installing multiple access layer

switches, Junos OS automation tools such as AutoInstall may be used. Refer to the following for more information:

www.juniper.net/techpubs/software/junos-security/junos-security96/junos-security-admin-guide/config-

autoinstall-chapter.html.

• To further save time and ensure consistency, configuration files may be generated in advance, and then uploaded to

a Trivial File Transfer Protocol (TFTP)/HTTP or FTP server for later downloading. The operations support systems

(OSS) in place for switch provisioning and configuration management determine the type of server to use.

• To test feature consistency and feature implementations for the new Juniper access layer switches, a proof-of-

concept (PoC) lab could be set up, as previously noted. Feature and compatibility testing is greatly reduced with a

single OS across all platforms such as Junos OS, which maintains a strict, serial release cycle. Feature testing in a

L2/L3 SwitchL2/L3 Switch

TOR DEPLOYMENT

Virtual Chassis Virtual ChassisEX4200 EX4200

Legacy Aggregation Layer

Access Layer



PoC lab could include:

- Interface connectivity

- Trunking and VLAN mapping

- Spanning-tree interoperability with aggregation layer

- QoS policy—classification marking, rate limiting

- Multicast

• Provision the new access layer switches into any existing terminal servers for out of band CLI access via SSH.

• Network Automation: The approach to use for automating management in these scenarios depends on which other

vendors’ equipment will be collocated in the data center, what other multivendor tools will be employed (Tivoli,

OpenView, etc.), and how responsibilities will be partitioned across teams for different parts of the infrastructure.

If the insertion is relatively small and contained, and other tools supporting each vendor’s platforms are already

deployed, testing for compatible integration of the Juniper equipment is the best PoC step. However if this insertion

is the start of a longer term, more expanded, strategic deployment of Juniper infrastructure into multiple PODs

and sites (because of the importance of new applications, for example), then it may make sense to also test for

integration of Junos Space into the environment because of the likely value of Space to the installation over time.

Ethernet Design, Network Activate, or other Junos Space data center management applications could be considered.

Space could be deployed as either a physical or a virtual appliance, depending on the allocation of responsibilities

for management and the allocation of resources within the design. VM requirements for running Junos Space are 8

GB RAM and 40 GB hard disk in a production environment. If Junos Space VM is installed for lab/trial purposes, 2 GB

RAM and 8 GB hard disk space is sufficient.

For more information on deploying the Junos Space platform and managing nodes in the Junos Space fabric, please

refer to the technical documentation: www.juniper.net/techpubs/en_US/junos-space1.0/information-products/

index-junos-space.html.

Installation

After comprehensive PoC testing, physical installation of the new POD should be relatively straightforward. As

previously mentioned, if the installation only involves adding new access layer switches to existing racks, switchover

becomes a matter of changing server cables from the old switches to the new ones. If a server refresh is combined

with a switch refresh, those components should be physically installed in the new racks. Uplink interfaces are then

connected to the aggregation switch(es).

Post Installation

Procedures which are similar to installing a new POD within a single vendor environment should be employed after

physical installation is complete. As a best practice, verify:

• Access to the new POD via CLI or network management tools.

• Monitoring and alerting through OSS tools is functional.

• Security monitoring is in place and working. To limit false positives, security tuning should be conducted if a Security

Incident and Event Manager (SIEM) system such as the STRM Series is in place.

• Interface status for server connections and uplinks via CLI or network management tools.

• L2/STP state between access and aggregation tiers.

• QoS consistency between access and aggregation tiers.

• Multicast state (if applicable).

• Traffic is being passed via ping tests and traffic monitoring tools.

• Applications are running as anticipated via end user test, performance management, and other verifications.



Network Challenge and Solutions for Virtual Servers

Server virtualization has introduced a new layer of software to the data center called the hypervisor. This layer

allows multiple dissimilar operating systems, and the applications running within them, to share the server’s physical

resources such as CPU, memory, and I/O using entities called virtual machines (VMs). A Virtual Ethernet Bridge (VEB)

within the physical server switches traffic between the VMs and applications running within the same server, as well

as between VMs and external network resources. Instead of interfacing directly to the physical NICs, the applications

now talk to “virtual ports” on the internal VEB (or vSwitch). This creates virtual network endpoints, each with its own

virtual IP and MAC addresses. Unique to server virtualization, a virtual switch (vSwitch) is a Layer 2 switch with limited

function and security. Physical switches (or pSwitches) like the EX Series Ethernet Switches are actual pieces of

network equipment.

The network design for server virtualization requires an organization to consider the connections between the

vSwitch and the pSwitch, including network functionality such as VLAN tagging and link aggregation (LAG) between

network nodes. As VM to physical server ratios increase, server-based networking becomes more complex and

may require multiple virtual switches, different VLANs, QoS tags, security zones, and more. Adding this amount of

network processing to physical server infrastructures adds a great deal of overhead to their loads. It also requires

more networking functionality to be added into hypervisors. To reduce this overhead and simplify operations, an

alternative approach, strategically, is to use a Virtual Ethernet Port Aggregator (VEPA), where servers remain focused

on application processing, and the hypervisor has visibility into the network, delegating switching tasks to collaborating

physical switches. Networking for a large number of physical and logical servers can be simplified by attaching many of

them to the wide configuration of a single Juniper Virtual Chassis switch. As previously described, EX Series switches,

initially, the EX4200, can be logically combined into a single switch spanning over 400 physical server access ports and

supporting several thousand virtual machines using Virtual Chassis technology.

It is important to note that vSwitches and pSwitches are not competing technologies. The IEEE standards body is

working on solving vSwitch issues within its VEPA standards working group. VEPA proposes to offload all switching

activities from hypervisor-based vSwitches to the actual physical switches. In addition, VEPA proposes to ease

management issues. The IEEE 802.1Qbg (Edge Virtual Bridging) and 802.1Qbh (Bridge Port Extension) VEPA standards

specify how to move networking from virtual servers to dedicated physical Ethernet switches. This will help by

concentrating networking functions into equipment that is purpose-built for tasks, enhancing performance, security,

and management within the data centers. It will also help reduce computing overhead on virtual servers, allowing the

CPU cycles to be spent on application processing as opposed to networking tasks. Offloading switching activities from

hypervisor-based vSwitches will also result in an increase in the supported number of VMs. Most importantly, a ratified

VEPA standard will be universal as opposed to a vendor-specific, proprietary solution. For more information on VEPA,

please see: www.ieee802.org/1/files/public/docs2008/new-congdon-vepa-1108-v01.pdf.

In addition to Virtual Chassis and VEPA-based forwarding, a management application such as Junos Space Virtual

Control allows users to monitor, manage, and control the virtual network environments that support virtualized servers

deployed in the data center. Virtual Control provides a consolidated solution for network administrators to gain end-to-

end visibility into, and control over, both virtual and physical networks from a single management screen.

Network Automation and Orchestration

Automation is a crucial tool for running a scalable and resilient data center at all levels. When developing an

automation plan, it often works well to partition functions to be covered by the automation platforms and detail how

these functions map into operations teams and data center domains. Within these boundaries, an open architecture

should be selected that addresses the functions across the respective equipment suppliers’ platforms and maps them

to the appropriate applications. In a multivendor infrastructure, a difference typically exists in the level at which vendor

integration occurs—sometimes integration is possible in a multivendor application, and in other cases the integration

is less complete and some number of each vendor’s specific tools needs to be kept in service to accomplish the

necessary tasks.



Significant levels of integration can be done in fault, performance, and network configuration and change

management. As an example, IBM’s Tivoli NetCool is a well established leading multivendor solution for fault

management. Juniper’s Junos Space platform licenses and integrates NetCool into its Junos Space offering. There

are also well established multivendor solutions for performance management that include IBM NetCool Proviso,

CA eHealth, InfoVista, and HP OpenView that an enterprise can consider for managing network and application

performance for both current vendor and Juniper network infrastructures.

There are currently over a dozen Network Configuration and Change Management (NCCM) vendors with multivendor

tools. These tools bring more structure to the change management process and also enable automated configuration

management. NCCM vendors include IBM Tivoli, AlterPoint, BMC (EmprisaNetworks), EMC (Voyence), HP (Opsware),

and others. Prior to introducing Juniper into an existing single vendor infrastructure, Juniper recommends that you

replace manual network configuration management processes and vendor-specific tools with automated multivendor

NCCM tools. It is also good practice to establish standard network device configuration policies which would apply to

all vendors in the network infrastructure. Automated network configuration management is more efficient and also

reduces operational complexity. An IT management solution should be built around the standards outlined by the

Fault, Configuration, Accounting, Performance, Security (FCAPS) Model.

Refer to the following URL for more information: http://en.wikipedia.org/wiki/FCAPS.

Integrating Management and Orchestration with Junos Space

Some amount of integration for management and orchestration can be accomplished using Junos Space. Junos Space

is a network application platform for developing and deploying applications that simplify data center operations. Junos

Space abstracts network intelligence such as traffic flows, routing topology, security events, and user statistics (to

name a few), and makes this available as services used both by Juniper-developed applications and applications from

third-party vendors leveraging the Junos Space SDKs/APIs. Junos Space applications are designed to be collaborative.

They share common services such as inventory and configuration management, job scheduling, HA/clustering, etc.,

and they use a common security framework. This enables users to optimize scale, security, and resources across their

application environment. The Junos Space application portfolio currently includes Ethernet Design (rapid endpoint and

switch port configuration in campus/data center environments), Security Design (fast, accurate deployment of security

devices and services), Network Activate (point/click setup and management of VPLS services), Route Insight (visibility,

troubleshooting, and change modeling for L3 MPLS/IP networks), Virtual Control, which provides a consolidated

solution for network administrators to gain end-to-end visibility into, and control over, both virtual and physical

networks from a single management screen, and Service Now (automated case and incident management).

Data Center Consolidation Trigger Event

Numerous large enterprises are consolidating their geographically distributed data centers into mega data

centers to take advantage of cost benefits, economies of scale, and increased reliability, and to fully exploit the

latest virtualization technologies. According to industry research, more than 50% of the companies surveyed had

consolidated data centers within the last year and even more planned to consolidate in the upcoming year. Data center

consolidation can involve multiple insertion points into access and core aggregation layers as well as consolidation of

security services.

Best Practices in Designing for the Access Layer Insertion Point

We have already discussed the recommended best practices for the access layer insertion point. In this section, we will

highlight key best practice/design considerations for the other insertion points related to the consolidation trigger event.



Best Practices: Designing the Upgraded Aggregation/Core Layer

The insertion point for an enterprise seeking to initially retain its existing three-tier design may be at the current design’s

aggregation layer. In this case, the recommended Juniper aggregation switch, typically an EX8200 line or MX Series

platform, should be provisioned in anticipation of it eventually becoming the collapsed core/aggregation layer switch.

If the upgrade is focused on the aggregation layer in a three-tier design (to approach transformation of the data

center network architecture in an incremental way, as just described), the most typical scenario is for the aggregation

switches to be installed as part of the L2 topology of the data center network, extending the size of the L2 domains

within the data center and interfacing them to the organization’s L3 routed infrastructure that typically begins at the

core tier, one tier “up“in the design from the aggregation tier.

In this case, the key design considerations for the upgraded aggregation tier include:

• Ensuring sufficient link capacity for the necessary uplinks from the access tier, resiliency between nodes in the

aggregation tier, and any required uplinks between the aggregation and core tiers in the network

• Supporting the appropriate VLAN, LAG, and STP configurations within the L2 domains

• Incorporating the correct configurations for access to the L3 routed infrastructure at the core tier, especially for

knowledge of the default gateway in a VRRP (Virtual Router Redundancy Protocol) environment

• Ensuring continuity in QoS and policy filter configurations appropriate to the applications and user groups supported

At a later point of evolution (or perhaps at the initial installation, depending on your requirements), it may be that these

nodes perform an integrated core and aggregation function in a two-tier network design. This would be the case if it suited

the organization’s economic and operational needs, and could be accomplished in a well managed insertion/upgrade.

In such a case, the new “consolidated core” of the network would most typically perform both L2 and L3 functions. The

L2 portions would, at a minimum, include the functions described above. They could also extend or “stretch” the L2

domains in certain cases to accommodate functions like application mirroring or live migration of workloads in a virtual

server operation between parts of the installation in other areas of the data center or even in other data centers. We

describe design considerations for this later in this guide.

In addition to L2 functions, this consolidated core will provide L3 routing capabilities in most cases. As a baseline, the

L3 routing capabilities to be included are:

• Delivering a resilient interface of the routed infrastructure to the L2 access portion of the data center network. This

is likely to include VRRP default gateway capabilities. It is also likely to include one form or another of an integrated

routing/bridging interface in the nodes such as routed VLAN interfaces (RVIs), or integrated routing and bridging

interfaces (IRBs), to provide transition points between the L2 and L3 forwarding domains within the nodes.

• Resilient, HA interfaces to adjacent routing nodes, typically at the edge of the data center network. Such high

availability functions can include nonstop active routing (NSR), GRES, Bidirectional Forwarding Detection (BFD),

and even MPLS fast reroute depending on the functionality and configuration of the routing services in the site.

For definitions of these terms, please refer to the section on Node-Link Resiliency. MPLS fast reroute is a local

restoration network resiliency mechanism where each path in MPLS is protected by a backup path which originates

at the node immediately upstream.

• Incorporation of the appropriate policy filters at the core tier for enforcement of QoS, routing area optimization,

and security objectives for the organization. On the QoS level, this may involve the use of matching Differentiated

Services code points (DSCPs) and MPLS traffic engineering designs with the rest of the routed infrastructure to

which the core is adjacent at the edge, as well as matching priorities with the 802.1p settings being used in the L2

infrastructure in the access tier. On the security side, it may include stateless filters that forward selected traffic to

security devices such as firewall/IDP platforms at the core of the data center to enforce appropriate protections for

the applications and user groups supported by the data center (see the next section of the core tier best practices

for a complementary discussion of the firewall/IDP part of the design).

In some cases, the core design may include use of VPN technology—most likely VPLS and MPLS—to provide

differentiated handling of traffic belonging to different applications and user communities, as well as to provide

special networking functions between various data center areas, and between data centers and other parts of the

organization’s network.



The most common case will be use of VPLS to provide “stretched” VLANs between areas of a large data center

network, or between multiple distant data centers using VPLS (over MPLS) to create a transparent extension of the

LAN to support nonstop application services (transparent failovers), transaction mirroring, data base backups, and

dynamic management of virtual server workloads across multiple data center sites.

In these cases, the core nodes will include VPLS instances matching the L2 topology and VLAN configurations required

by the applications, as well as the appropriate implementation of MPLS between the core nodes and the rest of the

organization’s routed IP/MPLS network. This design will include ensuring high availability and resilient access of the

L2 access tier into the “elastic” L2 infrastructure enabled by VPLS in the core; use of appropriate traffic engineering,

and HA features of MPLS to enable the proper QoS and degree of availability for the traffic being supported in the

transparent VLAN network. Details on these design points are included in the section of the Migration Guide on

incorporating multiple sites into the data center network design using MPLS in the Six Process Steps for Ensuring

MPLS Migration section.

Best Practices: Upgraded Security Services in the Core

Frequently a data center consolidation requires consolidating previously separate and siloed security appliances into

a more efficient security tier integrated into the L2 and L3 infrastructures at the core network layer. Here we describe

design considerations for accomplishing that integration of security services in the core.

• All security appliances should be consolidated and virtualized into a single pool of security services with a platform

such as the SRX Series Services Gateways.

• To connect to and protect all core data center network domains, the virtual appliance tier should optimally

participate in the interior gateway routing protocols within the data center network.

• Security zones should be defined to apply granular and logically precise protection for network partitions and

virtualized resources within the network wherever they reside, above and beyond the granularity of traditional

perimeter defenses.

• The security tier should support the performance required by the data center’s applications and be able to inspect

information up to L7 at line rate. A powerful application decoder is necessary on top of the forwarding, firewall

filtering, and IDP signature detection also applied to the designated traffic streams. Including this range of logic

modularly in a high-performance security architecture for the core helps reduce the number of devices in the network

and increase overall efficiency.

• Scalable, strong access controls for remote access devices and universal access control should be employed to

ensure that only those with an organizational need can access resources at the appropriate level. Integration of

secure access with unified policies and automation using coordinated threat control not only improves security

strength but also increases efficiency and productivity of applications within the data center.

• Finally, incorporation of virtual appliances such as virtual firewalls and endpoint verification servers into the data

center’s security design in a way that integrates protection for the virtual servers, desktops, and related network

transports provides an extension of the common security fabric into all of the resources the IT team needs to protect.

Aggregation/Core Insertion Point Installation Tasks

Preinstallation Tasks

The tasks described in this section pertain to a consolidation within an existing data center that has the required space

and power to support consolidation. Alternatively, a consolidation may take place in a new facility, sometimes referred

to as a “greenfield” installation. That scenario would follow the best practices outlined in Juniper’s Cloud-Ready Data

Center Reference Architecture: www.juniper.net/us/en/solutions/enterprise/data-center/simplify/#literature.

The steps outlined here also apply to a case in which the organization wants to stay with its existing three-tier design,

at least for the initial steps in the process. In such a case, deployment and provisioning should be done leaving

flexibility to move to a two-tier design at some future date.



The scenario for transitioning the core data center network in a design upgrade triggered by a consolidation project

should encompass the following kinds of tasks, suited to each organization’s case:

• Ensure that the power, cooling, airflow, physical rack space, and cabling required for any new equipment has

been designed, ordered, and installed (however your organization breaks down these responsibilities between

departments, suppliers, and integrators).

• Size the new/upgraded switching platforms using your organization’s policy for additional performance and capacity

headroom for future growth.

• Design should include a pair of switches that can eventually serve as the new collapsed core/aggregation layer. Initial

design can be tuned to the exact role the switches will perform. For example, if they will be focused on pure core

functions in the initial phase, they can be focused on capacity/functionality required for that role (e.g., IGP policies

and area design appropriate to a core data center switch). If they will be focused on pure aggregation functions

initially, design can focus on L2 and L3 interface behaviors appropriate to that role. Or, if they will be performing a

blended core/aggregation role (as would be appropriate in many two-tier data center networks), a mix of L2 and L3

functions can be designed to fit the network’s requirements.

• If the new switches are aggregating existing access layer switches, industry standard protocols (such as 802.1D,

802.1Q, 802.1s, 802.3ad, etc.) should be used to ensure interoperability.

• Configuration checklist should include:

- IGP and EGP requirements such as area border roles, routing metrics and policies, and possible route

redistributions

- L2/L3 domain demarcations

› VLAN to VRF mapping

› Virtualized service support requirements (VPN/VRF)

› Default gateway/root bridge mapping

› Hot Standby Routing Protocol (HSRP) to Virtual Router Redundancy Protocol (VRRP) mappings

- Uplink specifications

› Density

› Speeds (number of GbE and 10GbE links)

› Link aggregations

› Oversubscription ratios

- Scaling requirements for MAC addresses

- Firewall filters (from IOS ACL mapping)

- QoS policies

- Multicast topology and performance

- Audit/compliance requirements should be clarified and any logging or statistics collection functions designed in.

- IOS configurations should be mapped to Junos OS as outlined in the section on IOS to Junos OS translation tools.

• As noted earlier, a PoC lab could be set up to test feature consistency and implementation in the new Juniper

infrastructure. Testing could include:

- Interface connections

- Trunking and VLAN mapping

- STP interoperability with any existing switches

- QoS policy (classification marking; rate limiting)

- Multicast



Installation Tasks

Refer to Figure 14 when considering the tasks described in this section:

Figure 15: Aggregation/core layer insertion point

• If the new aggregation layer switches are part of a new POD that includes new access layer switches, the installation

should be straightforward.

• If the new aggregation layer switches are part of a replacement for existing legacy switches, it is important to create

a fallback position in the event of any unforeseen issues. Typically, EX8200 line switches would be provisioned and

deployed as a pair, replacing the legacy switches.

• Once the EX8200 line switches are installed, they should be connected to the existing core layer. Again, this scenario

is appropriate in cases where the organization initially will maintain its existing three-tier architecture. Appropriate

IGP and EGP configurations as identified in the preinstallation configuration checklist would have been provisioned

and interoperability verified by checking neighbor state and forwarding tables.

• An initial access layer switch’s uplinks would then be connected to the EX8200 line switches and connectivity

verified as outlined in the post installation checklist. Once this baseline is established, additional access layer

switches would then be migrated to the EX8200 line.

Post Installation

As previously noted, procedures which are similar to those employed when installing a new aggregation switch in a

single vendor environment can be used, after physical installation is complete, to verify successful operations. As a

best practice, verify:

• Access to new configuration via CLI or network management tools.

• Interface status for server connections and uplinks via CLI or network management tools.

• L2/STP status between network tiers.

• QoS consistency between network tiers.

• Multicast state (if applicable).

• Traffic passing via ping tests.

• Application connectivity and flows with statistics or end user tests (or both).

EX8200EX8216“West”

EX8200EX8216“East”

Legacy Switch “West” Legacy Switch “East”

Legacy Access Layer

Legacy AggregationLayer Switches andSecurity Applicances



Consolidating and Virtualizing Security Services in the Data Center: Installation Tasks

In addition to cyber theft and increasing malware levels, organizations must guard against new vulnerabilities

introduced by data center technologies themselves. To date, security in the data center has been applied primarily

at the perimeter and server levels. However, this approach isn’t comprehensive enough to protect information and

resources in new system architectures. In traditional data center models, applications, compute resources, and

networks have been tightly coupled, with all communications gated by security devices at key choke points. However,

technologies such as server virtualization and Web services eliminate this coupling and create a mesh of interactions

between systems that create subtle and significant new security risks within the interior of the data center. For a

complete discussion of security challenges in building cloud-ready, next-generation data centers, refer to the white

paper, “Security Considerations for Cloud-Ready Data Center”: www.juniper.net/us/en/local/pdf/implementation-

guides/8010046-en.pdf.

A key requirement for this insertion point is for security services platforms to provide the performance, scalability, and

traffic visibility needed to meet the increased demands of a consolidated data center. Enterprises deploying platforms

which do not offer the performance and scalability of Juniper Networks SRX Series Services Gateways and their associated

management applications are faced with a complex appliance sprawl and management challenge, where numerous

appliances and tools are needed to meet requirements. This is a more costly, less efficient, and less scalable approach.

Preinstallation Tasks for Security Consolidation and Virtualization

Figure 16: SRX Series platform for security consolidation

• Ensure that the appropriate power, cooling, airflow, physical rack space, and cabling required to support the new

equipment have been ordered and installed.

• Ensure that the security tier is sized to meet the organization’s requirements for capacity headroom for future growth.

• Define and provision routing/switching Infrastructure first (see prior section). This sets the L3/L2 foundation

domains upon which the security “zones” the SRX Series enforces will be built. The SRX Series supports a pool

of virtualized security services that can be applied to any application flow traversing the data center network.

Setting up the network with this foundation of subnets and VLANs feeding the dynamic security enforcement point

segments the data center resources properly and identifies what is being protected and what level of protection

is needed. With SOA, for example, there are numerous data flows between servers within the data center and

perimeter but security is often insufficient for securing these flows. Policies based on role/function, applications,

business goals, or regulatory requirements can be achieved using a mix of VLAN, routing, and security zone policies

enabling the SRX Series to enforce the appropriate security posture for each flow in the network.

• The performance and scalability requirements should be scoped. SRX Series devices can be paired together in a

cluster to scale to 120 Gbps of firewall throughput, as well as providing HA.

Virtual machine security requirements should also be defined. Juniper’s vGW Virtual Gateway is hypervisor neutral,

eliminating VM security blind spots. For more information on Juniper’s virtual firewall solution, refer to Chapter 2 (vGW

Virtual Gateway).

EX82XXSRX5800

Legacy Security Appliances



In the preinstallation phase, security policies must be developed. This typically takes time and can be complex to

coordinate. Juniper Professional Services can be used as a resource to help analyze and optimize security policies at all

enforcement points. The full suite of Juniper Networks Professional Services offerings can be found at:

www.juniper.net/us/en/products-services/consulting-services.

• Establish a migration plan, identifying a time line and key migration points, if all appliances cannot be migrated in a

flash cut.

• As with the other insertion points, PoC testing can be done and could include:

- Establishing the size of the target rule base to be used post conversion

- Checking the efficacy of the zone definitions

- Determining the effectiveness of the IPS controls

- Determining the suitability and implementation of the access controls to be used

Installation Tasks

As with the aggregation/core insertion point, it is important to have a fallback position to existing appliances in the

event of any operational issues. The current firewall appliances should be kept on hot standby. The key to a successful

migration is to have applications identified for validation and to have a clear test plan for success criteria. There are

three typical options for migration, with option 1 being the one most commonly used.

Migration Test Plan (Option 1)

• Test failover by failing the master firewall (legacy vendor) to the backup (this confirms that HA works and the other

devices involved in the path are working as expected).

• Replace the primary master, which was just manually failed, with the Juniper firewall. The traffic should still be

flowing through the secondary, which is the legacy vendor firewall.

• Turn off the virtual IP (VIP) address or bring the interface down on the backup (legacy vendor firewall) and force

everything through the new Juniper firewall.

• A longer troubleshooting window helps to ensure that the switchover has happened successfully. Also, turn off

synchronization checks (syn-checks) initially, to process already established sessions, since the TCP handshake has

already occurred on the legacy firewall. This will ensure that the newly established Juniper firewall will not drop all

active sessions as it starts up.


• This is essentially a flash cut option where an alternate IP address for the new firewall is configured along with the

routers and the hosts then point to the new firewall. If there is an issue, gateways and hosts can then be provisioned

to fall back to the legacy firewalls. With this option, organizations will sometimes choose to leave IPsec VPNs or

other termination on their old legacy firewalls and gradually migrate them over a period of time.


• This option is typically used by financial organizations due to the sensitive nature of their applications.

• A Switched Port Analyzer (SPAN) session will be set up on the relevant switches with traffic sent to the Juniper

firewalls, where traffic is analyzed and session tables are built. This provides a clear understanding of traffic

patterns and provides more insight into the applications being run. This option also determines whether there is any

interference due to filter policies or IPS, and it creates a more robust test and cutover planning scenario. This option

typically takes more time than the other options, so organizations typically prefer to go with option 1. Again, this is a

more common option for companies in the financial sector.



Post Installation

As previously noted, procedures similar to those used when installing new security appliances in a single vendor

environment could be used after physical installation is complete. As a best practice:

• Verify access via CLI or network management tools.

• Verify interface status via CLI or network management tools.

• Verify that traffic is passing through the platform.

• Verify that rules are operational and behaving as they should.

• Confirm that Application Layer Gateway (ALG) policies/IPS are stopping anomalous or illegal traffic in the

application layer, while passing permitted traffic.

• Confirm that security platforms are reporting appropriately to a centralized logging or SIEM platform.

Business Continuity and Workload Mobility Trigger Events

Sometimes an improvement in availability of systems to external and internal users drives a critical initiative to enhance

the availability of data center infrastructures, either within an individual data center or between sets of data centers

such as primary, backup, and distributed data center sites. The goal is almost always to preserve a business’ value to its

stakeholders, and it often requires upgrades or extensions to critical infrastructure areas to achieve this goal.

Business continuity or disaster recovery sites can be set up as active/active, warm-standby, or cold-standby

configurations. A cold-standby site could involve an agreement with a provider such as SunGuard in which backup

tapes are trucked to a SunGuard backup data center facility. A warm-standby site could interconnect primary and

standby data centers for resumption of processing after a certain amount of backup/recovery system startup has

occurred. A hot-standby, active/active configuration involves continuously available services running in each site that

allow transparent switching between “primary” and “secondary” as needed, driven by planned or unplanned outages. A

large organization may have instances of each.

Business continuity and workload mobility are tightly coupled. Business continuity or high availability disaster recovery

(HADR) often involves provisioning between two or more data centers. The design could involve replicating an entire

data center (essentially a Greenfield installation), or the design could involve adding additional capacity to one or

more existing data centers. The specific insertion points could be at any of the tiers of an existing three-tier design. We

have already outlined best practices and specific installation tasks for several of these network insertion points in this

chapter. Once provisioning for the disaster recovery data center has been done, users should be able to connect into

any of the data centers transparently.

Since we have already described the installation tasks for access and aggregation/core switching and services tiers

of the new data center network, we won’t repeat those here. The same procedures can be used to enhance the data

center infrastructures that will take part in the HADR system. To the extent that MPLS and VPLS are involved in the

configuration between centers, we will address the steps associated with that part of the network in the section on

workload mobility further on in this guide.

Best Practices Design for Business Continuity and HADR Systems

• Business continuity is enabled using a mix of device-level, link-level, and network-level resiliency within and between

an organization’s data center sites. In most cases, it also involves application and host system resiliency capabilities

that need to interwork seamlessly with the network to achieve continuity across multiple sites.

• In this section, we first concentrate on the network-level design within the data center sites.

• In the following section (on workload mobility), we also describe capabilities that extend continuity to the

network supporting multiple data center sites and to certain considerations around host and application resiliency

interworking with the network.



• Link-level redundancy in data center networks can be implemented with the following network technologies:

- Link Aggregation Group (LAG)

- Redundant Trunk Groups (RTGs)

- Spanning Tree Protocol (STP) and its variations

- Bidirectional Forwarding Detection (BFD)

- MPLS

We have already discussed LAG, RTG, and STP earlier in this guide. BFD is rapidly gaining popularity in data center

deployments, because it is a simple protocol aiding rapid network convergence (30 to 300 ms resulting in a sub-

second convergence time). BFD is a simple low layer protocol involving a hello mechanism between two devices. The

communication can be across directly connected links or across a virtualized communications path like MPLS.

• Node level resiliency can be achieved using the following technologies:

- Graceful Routing Engine switchover (GRES)

- Graceful restart

- Nonstop active routing (NSR) and nonstop bridging (NSB)

GRES is a feature used to handle planned and unplanned platform restarts gracefully, without any disruptions, by

deploying a redundant Routing Engine in a chassis. The Routing Engines synchronize and share their forwarding state

and configuration. Once synchronized, if the primary Routing Engine fails due to a hardware or software problem, the

secondary Routing Engine comes online immediately, resulting in minimum traffic forwarding interruption.

Rather than being a feature, graceful restart is a standards-based protocol that relies on routing neighbors to

orchestrate and help a restarting router to continue forwarding. There is no disruption in control or in the forwarding

path when the graceful restart node and its neighbors are participating fully and are employing the standard

procedures.

NSR builds on GRES and implements a higher level of synchronization between the Routing Engines. In addition to

the synchronizations and checkpoints between the Routing Engines that GRES achieves, NSR employs additional

protective steps and results in no disruption to the control or data planes, hiding the failure from the rest of the

network. And, it does not require any help from its neighbors to achieve these results. Note that graceful restart and

NSR are mutually exclusive—they are two different means to achieve the same high availability goal.

NSB is similar to GRES and preserves interface and Layer 2 protocol information. In the event of a planned or

unplanned disruption in the primary Routing Engine, forwarding and bridging are continued during the switchover

resulting in minimal packet loss.

Node-level HA includes many aspects, starting with the architecture of the node itself and ending with the protocols

that the node uses to network with other components. Paralleling the Open Systems Interconnection (OSI) Reference

Model, you can view the network infrastructure components starting from the physical layer, which is the node’s

internal architecture and protocols, and ending with the upper tiers, which would include components such as OSPF,

IS-IS, BGP, MPLS, GRES, NSR, etc. No single component provides HA. It is all of the components working together

which creates one architecture and results in high availability.

For more detailed information on HA features on Juniper platforms, refer to: www.juniper.net/techpubs/en_US/

junos10.1/information-products/topic-collections/swconfig-high-availability/frameset.html.

To complement the node-level availability mechanisms highlighted above, devices and systems deployed at critical

points in the data center design should include redundancy of important common equipment such as power supplies,

fans, and Routing Engines at the node levels, so that the procedures mentioned above can have a stable hardware

environment to build upon.

In addition, the software/firmware in these devices should be based on a modular architecture to prevent software

failures or upgrade events from impacting the entire device. There should also be a clean separation between control

plane and data processes to ensure system availability. Junos OS is an example of a multitasking OS that operates in

this manner, ensuring that a failure in one process doesn’t impact any others.



Best Practices Design to Support Workload Mobility Within and Between Data Centers

In current and future data centers, the application workloads will increasingly be handled on an infrastructure of

extensively virtualized servers, storage, and supporting network infrastructure. In these environments, operations teams

will frequently need to move workloads from test into production, and distribute the loads among production resources

based on performance, time of day, and other considerations. This kind of workload relocation among servers may

occur between servers within the same rack, within the same data center, and increasingly, between multiple data

centers depending on the organization’s size, support for cloud computing services for “bursting overloads,” and other

similar considerations.

In general, we refer to this process of relocating virtual machines and their supporting resources as “workload mobility.”

Workload mobility plays an important part in maintaining business continuity and availability of services, and, as such,

is discussed within this section of the guide.

Workload mobility can be deployed in two different ways, as shown in Figure 16.

Figure 17: Workload mobility alternatives

With Juniper’s Virtual Chassis technology, a Layer 2 domain can be easily extended across racks or rows, allowing

server administrators to move virtual machines quickly and easily within a data center.

When moving workloads between data center sites, consideration should be given to the latency requirements

of applications spanning the data center sites to be sure that the workload moves can meet application needs.

If it is important to support the movement of workloads between data centers, the L2 domain supporting the VM

infrastructure can be extended, or stretched, across data centers in two different ways:

• If the data centers are under 100 km apart, and the sites are directly connected physically, a Virtual Chassis can

be extended across the sites, using the 10 Gigabit chassis extension ports supporting a configuration up to the

maximum of 10 switches in a single Virtual Chassis. Note that directly connected means that ports are directly

connected to one another, i.e., a single fiber link connecting one device to another device or L1 signal repeater is used.

• If the connection between data centers is at a distance requiring services of a WAN, MPLS can be used to create

transparent virtual private LANs at very high scale using a Juniper infrastructure.

VPLS

Rack A Rack B

Virtual Chassis Virtual Chassis

VirtualChassis

Layer 2 domain across racksand across data center

RACK TO RACK

Cloud Center Cloud Center

Layer 2 domain acrossvirtual private LAN

CLOUD TO CLOUD



At the level of the data center network core and the transparent virtual WAN that an organization can use to support

its business continuity and workload mobility goals, MPLS provides a number of key advantages over any other

alternative:

• MPLS virtualization enables the physical network to be run as many separate virtual networks. The benefits include

cost savings, improved privacy through traffic segmentation, improved end user experience with traffic engineering

and QoS, and improved resiliency with functionality such as MPLS fast reroute and BFD. This can be done in a

completely private network context (e.g., the enterprise owns the entire infrastructure), or it can be achieved through

the interworking of the organization’s private data center and WAN infrastructures with an appropriately deployed

carrier service.

• VPLS provides Ethernet-based point-to-point, point-to-multipoint, and multipoint-to-multipoint (full mesh)

transparent LAN services over an IP/MPLS infrastructure. It allows geographically dispersed LANs to connect across

an MPLS backbone, allowing connected nodes (such as servers) to interpret that they are on the same Ethernet LAN.

VPLS thus provides an efficient and cost-effective method for communicating at L2 across two or more data center

sites. This can be useful for transaction mirroring in active/active or other backup configurations. And it is necessary

for supporting workload mobility and migration of virtual machines between locations over a WAN.

• MPLS can provide private L3VPN networks between data center sites that share the same L3 infrastructure. A

composite, virtualized L2 and L3 infrastructure can thus be realized. Very useful security properties can be achieved

in such a design as well. For example, by mapping L3VPNs to virtual security zones in an advanced firewall such as

the SRX Series, many security policies can be selectively layered on the traffic.

Also in support of business continuity, MPLS’ traffic engineering (TE) and fast reroute capabilities combine

sophisticated QoS and resiliency features into a multiservice packet core for superior performance and economics.

TE could be used to support real-time data replication and transaction mirroring, along with service-level agreement

(SLA) protection for real-time communications such as video conferencing and collaboration services. Fast reroute

delivers rapid path protection in the packet-based network without requiring redundant investments in SONET or SDH

level services (e.g., superior performance for lower cost).

For workload mobility that involves extending a Layer 2 domain across data centers to support relevant applications

like VMware VMotion, archiving, backup, and mirroring, L2VPNs using VPLS could be used between data center(s).

VPLS allows the connected data centers to be in the same L2 domain, while maintaining the bandwidth required for

backup purposes. This feature ensures that other production applications are not overburdened.

Best Practices for Incorporating MPLS/VPLS in the Data Center Network Design

Current L2/L3 switching technologies designed for the LAN do not scale well with the appropriate levels of rerouting,

availability, security, QoS, and multicast capabilities to achieve the required performance and availability. As a result,

when redesigning or upgrading the data center, an upgrade to MPLS is frequently appropriate and justified to meet

business operational demands and cost constraints. MPLS often simplifies the network for the data center, removing

costly network equipment and potential failure points while providing complete network redundancy and fast rerouting.

When fine grained QoS is required with traffic engineering for the data center, RSVP should be used to establish

bandwidth reservations based upon priorities, available bandwidth, and server performance capacities. MPLS-based

TE is a tool made available to the data center network administrators which is not presently available in common

IP networks. Furthermore, MPLS virtualization capabilities can be leveraged to segment and secure server access,

becoming a very important part of maintaining a secure data center environment.

For this section of the Data Center LAN Migration Guide, the prior construct of best practice, preinstall, install, and post

install is going to be combined into six process steps for migrating to MPLS, keeping in mind that VPLS runs over an IP/

MPLS network.



Switching across data centers using VPLS is depicted below in Figure 17.

Figure 18: Switching across data centers using VPLS

Six Process Steps for Migrating to MPLS

The following approach using a phased series of steps is one we have found useful in many enterprises. However, there

may be specific circumstances which could dictate a different approach in a given case.

Step 1: Upgrade the IP network to MPLS-capable platforms, yet continue to run it as an IP network. In step one,

upgrade the routers connecting the data centers to routers capable of running MPLS, yet configure the network as an IP

network without MPLS. Use this time to verify a stable and properly performing inter data center connection. This will

provide the opportunity to have the MPLS network in place and to be sure routers are configured and working correctly

to support IP connectivity. If you’re presently running Extended IGRP (EIGRP), use this opportunity to migrate to OSPF

or one of the other L3 protocols that will perform better with MPLS. Depending upon how many data centers will be

inter connected, once you’ve migrated to OSPF and/or IS-IS, it is a good time to enable BGP as well. BGP can be used

for automatic MPLS label distribution. Juniper has multiple sources of design guidelines and practical techniques for

accomplishing these tasks, which can be delivered in either document-based or engineering professional services

modes. Please refer to the Additional Resources sections in Chapter 5 for specific URLs.

Apps Apps

CORE

DATA CENTER 1 DATA CENTER 2

MX Series

M Series

Mirroring VLAN 10 Mirroring VLAN 20

Apps Apps

MX Series

M Series

VLAN 10 VLAN 20

Virtual Chassis

EX4200 EX4500

Virtual Chassis

EX4200 EX4500



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.



Step 5: Traffic engineer the network. Step 5 does not require steps 3 or 4 above to be completed before initiating this

step. Traffic engineering may begin as soon as the MPLS network plane is established. However, as a best practice it

is recommended to first migrate some of the existing traffic to the MPLS plane before configuring TE. This will allow

you to experience firsthand the benefits and granular level of control you have over the network through the traffic

engineering of an MPLS network. Start by assessing the existing traffic demand of applications across data center(s).

Group traffic demand into priority categories, for instance, voice and video may be gathered into a “real time” priority

category, while private data is grouped into a second and Internet traffic is grouped into a third category.

Step 6: Monitor and manage. As with any network, you must continue to monitor and manage the network once it

is deployed and running while supporting new service loads and demands. An advantage MPLS provides above and

beyond IP is its capability to traffic engineer based upon utilization and application demands as the business evolves.

For more information on MPLS, refer to: www.juniper.net/techpubs/software/junos/junos53/swconfig53-mpls-

apps/html/mpls-overview.html.

For more information on VPLS, refer to: www.juniper.net/techpubs/en_US/junos10.2/information-products/

pathway-pages/config-guide-vpns/config-guide-vpns-vpls.html.

High-Performance Security Services Trigger Event

Please refer to the best practices and related installation information outlined in the Upgrading Security Services in

the Core section. as that trigger event covers the security services network insertion point.

Completed Migration to a Simplified, High-Performance, Two-Tier Network

As discussed throughout this document, enterprises with an existing legacy three-tier data center architecture can

begin their migration to a next-generation, cloud-ready, Juniper-based two-tier design from any of the common trigger

events outlined in this chapter. We’ve identified the best practices and the key prescriptive installation steps needed to

ensure successful insertion into the existing architecture. You can transition to a simplified architecture from an existing

legacy multitier architecture, as shown in Figure 18, by provisioning each of these network insertion points.

Figure 19: Transitioning to a Juniper two-tier high-performance network

SRX5800

Aggregation Layer

Core

Collapsed Aggregation/Core Layer

Access Layer Access Layer

Ethernet


FC SAN

3-TIER LEGACY NETWORK

Virtual Chassis EX82XX

EX82XX

EX4200 EX4500


FC SAN

SIMPLER, 2-TIER DESIGN

www.juniper.net/techpubs/en_US/junos10.2/information-products/pathway-pages/config-guide-vpns/config-guide-vpns-vpls.html

www.juniper.net/techpubs/en_US/junos10.2/information-products/pathway-pages/config-guide-vpns/config-guide-vpns-vpls.html



Juniper Professional Services

Juniper Networks offers a suite of professional services that span the entire migration process—from the design and

planning to the implementation and operation phases of a new environment. These services provide an expeditious

and thorough approach to getting the network up and running, while at the same time minimizing the risk of business

disruptions and optimizing the network’s performance. High- and low-level design services, as well as network consulting,

help determine the high-level technical requirements to support business needs, including network assessment and

recommendations. Implementation services offer a thorough review of the system configurations to be migrated,

complete the actual migration/implementation tasks, and provide the necessary testing and troubleshooting activities

to ensure a successful network implementation. Custom and fixed scope installation, quick start and transition services

are available to ease the installation and enable a complete knowledge transfer of Juniper technology. These services

also help accelerate the migration and minimize the risk and cost in moving from legacy products. Subsequent to

the migration activities, Juniper consultant expertise can be obtained when and where it provides the most benefit

during operation, to efficiently fill potential skill gaps and to help assess current network performance, providing

recommendations to meet specific operational needs and maintain the network in the most optimal way.

The full suite of Juniper Networks Professional Services offerings can be found at: www.juniper.net/us/en/products-

services/consulting-services.

www.juniper.net/us/en/products-services/consulting-services/

www.juniper.net/us/en/products-services/consulting-services/




Chapter 4: Troubleshooting



Troubleshooting

Introduction

The scope of this section is to provide an overview of common issues that might be encountered at different insertion

points when inserting Juniper platforms as a result of a trigger event (adding a new application or service to the

organization). This section won’t provide exhaustive troubleshooting details, however, we do describe the principal

recommended approaches to troubleshooting the most common issues and provide guidelines for identification,

isolation, and resolution.

Troubleshooting Overview

When investigating the root cause of a problem, it is important to determine the problem’s nature and analyze its

symptoms. When troubleshooting a problem, it is generally advisable to start at the most general level and work

progressively into the details, as needed. Using the OSI model as a reference, troubleshooting typically begins at the

lower layers (physical and data link) and works progressively up toward the application layer until the problem is found.

This approach tends to quickly identify what is working properly so that it can be eliminated from consideration, and

narrows the problem domain for quick problem identification and resolution.

The following list of questions provides a methodology on how to use clues and visible effects of a problem to reduce

the diagnostic time.

• Has the issue appeared just after a migration, a deployment of new network equipment, a new link connection, or

a configuration change? This is the context being presented in this Data Center LAN Migration Guide. The Method of

Procedure (MOP) detailing the steps of the operation in question should include the tasks to be performed to return

to the original state before the network event, should any abnormal conditions be identified. If any issue arises during

or after the operation that cannot be resolved in a timely manner, it may be necessary to roll back and disconnect

newly deployed equipment while the problem is researched and resolved. The decision to back out should be

made well in advance, prior to the expiration of the maintenance window. This type of problem is likely due to an

equipment misconfiguration or planning error.

• Does the problem have a local or a global impact on the network? The possible causes of a local problem may

likely be found at L1 or L2, or it could be related to an Ethernet switching issue at the access layer. An IP routing

problem may potentially have a global impact on networks, and the operator should focus its investigation on the

aggregation and core layer of the network.

• Is it an intermittent problem? When troubleshooting an intermittent problem, system logging and traceoptions

provide the primary debugging tools on Juniper Networks platforms, and can be focused on various protocol

mechanisms at various levels of detail. Events occurring in the network will cause the logging of state transitions

related to physical, logical, or protocols to local or remote files for analysis.

• Is it a total or partial loss of connectivity or is it a performance problem? All Juniper Networks platforms have

a common architecture in that there are separate control and forwarding planes. For connectivity issues, Juniper

recommends that you first focus on the control plane to verify routing and signaling states and then concentrate

on the forwarding or data plane, which is implemented in the forwarding hardware (Packet Forwarding Engine or

PFE). If network performance is adversely affected by packet loss, delays, and jitter impacting one or multiple traffic

types, the root cause is most likely related to network congestion, high link utilization, and packet queuing along the

traversed path.



Hardware

The first action to take when troubleshooting a problem and also before making any change in the network is to ensure

proper functionality and integrity of the network equipment and systems. A series of validation checks and inspection

tests should be completed to verify that the hardware and the software operate properly and there are not any fault

conditions. The following presents a list of “show commands” from the Junos OS CLI relative to this, as well as a brief

description of expected outcomes.

• show system boot-messages

Review the output and verify that no abnormal conditions or errors occurred during the booting process. POST (power-

on self-test) results are captured in the bootup message log and stored on the hard drive.

• show chassis hardware detail

Verify that all hardware appears in the output (i.e., routing engines, control boards, switch fabric boards, power

supplies, line cards, and physical ports). Verify that no hardware indicates a failure condition.

• show chassis alarms

Verify that there are no active alarms.

• show log messages

Search log for errors and failures and review the log for any abnormal conditions. The search can be narrowed to

specific keywords using the “grep” function.

• show system core-dumps

Verify any transient software failures. Junos OS under fatal fault condition will create a core file of the kernel and

processes in question for diagnostic analysis.

For more details on platform specifics, please refer to the Juniper technical documentation that can be found at:

www.juniper.net/techpubs.

OSI Layer 1: Physical Troubleshooting

An OSI Layer 1 problem or physical link failure can occur in any part of the network. Each media type has different

physical and logical properties and provides different diagnostic capabilities. Focus here will be on Ethernet, as it is

universally deployed in data centers at all tiers and in multiple flavors: GbE, 10GbE, copper, fiber, etc.

• show interface extensive command produces the most detailed and complete information about all interfaces. It

displays input and output errors for the interface displayed in multiple categories such as carrier transition, cyclic

redundancy check (CRC) errors, L3 incomplete errors, policed discard, L2 channel errors, static RAM (SRAM) errors,

packet drops, etc. It also contains interface status and setup information at both physical and logical layers. Ethernet

networks can present many symptoms, but troubleshooting can be helped by applying common principles: verify

media type, speed, fiber mode and length, interface and protocol maximum transmission unit (MTU), flow control

and link mode. The physical interface may have a link status of “up” because the physical link is operational with no

active alarm, but the logical interface has a link status of “down” because the data link layer cannot be established

end to end. If this occurs, refer to the next command.

• monitor interface provides real-time packets and byte counters as well as displaying error and alarm conditions.

After an equipment migration or a new link activation, the network operator should ping a locally connected host to

verify that the link and interface are operating correctly and monitor if there are any incrementing error counters. The

do-not-fragment flag in a ping test is a good tool to detect MTU problems which can adversely affect end-to-end

communication.

For 802.3ad aggregated Ethernet interfaces, we recommend enabling Link Aggregation Control Protocol (LACP) as a

dynamic bundling protocol to form one logical interface with multiple physical interfaces. LACP is designed to provide

link monitoring capabilities and fast failure detection over an Ethernet bundle connection.



OSI Layer 2: Data Link Troubleshooting

Below are some common steps to assist in troubleshooting issues at Layer 2 in the access and aggregation tiers:

• Are the devices utilizing DHCP to obtain an IP addresses? Is the Dynamic Host Configuration Protocol (DHCP)

server functioning properly so that host devices receive an IP address assignment from the DHCP server? If routed, is

the DHCP request being correctly forwarded?

• monitor traffic interface ge-0/0/0 command provides a tool for monitoring local traffic. Expect to see all packets

that are sent out and received to and from ge-0/0/0. This is particularly useful to verify the Address Resolution

Protocol (ARP) process over the connected LAN or VLAN. Use the show arp command to display ARP entries.

• Is the VLAN in question active on the switch? Is a trunk active on the switch that could interfere with the ability

to communicate? Is the routed VLAN interface (RVI) configured with the correct prefix and attached to the

corresponding VLAN? Is VRRP functioning properly and showing one unique routing node as master for the virtual IP

(VIP) address?

• Virtual Chassis, Layer 3 uplinks, inverted U designs, and VPLS offer different alternatives to prevent L2 data

forwarding loops in a switching infrastructure without the need to implement Spanning Tree Protocols (STPs).

Nevertheless, it is common best practice to enable STP as a protection mechanism to prevent broadcast storms in

the event of a switch misconfiguration or a connection being established by accident between two access switches.

Virtual Chassis Troubleshooting

Configuring a Virtual Chassis is essentially plug and play. However, if there are connectivity issues, the following

section provides the relevant commands to perform operational analysis and troubleshooting. To troubleshoot the

configuration of a Virtual Chassis, perform the following steps.

Check and confirm Virtual Chassis configuration and status with the following commands:

• show configuration virtual-chassis

• show virtual-chassis member-config all-members

• show virtual-chassis status

Check and confirm Virtual Chassis interfaces:

• show interfaces terse

• show interfaces terse vcp*

• show interfaces terse *me*

Verify that the mastership priority is assigned appropriately:

• show virtual-chassis status

• show virtual-chassis vc-port all-members

Verify the Virtual Chassis active topology and neighbors:

• show virtual-chassis active-topology

• show virtual-chassis protocol adjacency

• show virtual-chassis protocol database extensive

• show virtual-chassis protocol route

• show virtual-chassis protocol statistics

In addition to the verifications above, also check the following:

• Check the cable to make sure that it is properly and securely connected to the ports. If the Virtual Chassis port (VCP)

is an uplink port, make sure that the uplink module is model EX-UM-2XFP.

• If the VCP is an uplink port, make sure that the uplink port has been explicitly set as a VCP.

• If the VCP is an uplink port, make sure that you have specified the options (pic-slot, port-number, member-id)

correctly.



OSI Layer 3: Network Troubleshooting

While L1 and L2 problems have limited effect and are local, L3 or routing issues may affect other networks by

propagation and may have a global impact. In the data center, the aggregation/core tiers may be affected. The

following focuses on the operation of OSPF and BGP as they are commonly implemented in data centers to exchange

internal and external routing information.

In a next -generation or newly deployed network, OSPF’s primary responsibility typically is to discover endpoints for internal

BGP. Unlike OSPF, BGP may play multiple roles that include providing connectivity to an external network, information

exchange between VRFs for L3 MPLS VPN or VPLS, eventually carrying data centers internal routes to access routers.

OSPF

A common problem in OSPF is troubleshooting adjacency issues which can occur for multiple reasons: mismatched IP

subnet/mask, area number, area type, authentication, hello/dead interval, network type, or mismatched IP MTU.

The following are useful commands for troubleshooting an OSPF problem:

• show ospf neighbor displays information about OSPF neighbors and the state of the adjacencies which must be

shown as “full.”

• show ospf interface displays information about the status of OSPF interfaces.

• show ospf log logs shortest-path-first (SPF) calculation.

• show ospf statistics displays number and type of OSPF packets sent and received.

• show ospf databases displays entries in the OSPF link-state database (LSDB).

OSPF traceoptions provide the primary debugging tool, and the OSPF operation can be flagged to log error packets

and state transitions along with the events causing them.

BGP

show bgp summary is a primary command used to verify the state of BGP peer sessions, and it should display that the

peering is “established” to be fully operational.

BGP has multiprotocol capabilities made possible through simple extensions that add new address families. This

command also helps to verify which address families are carried over the BGP session, for example, inet-vpn if L3 MPLS

VPN service is required or L2VPN for VPLS.

BGP is a policy-driven routing protocol. It offers flexibility and granularity when implementing routing policy for path

determination and for prefix filtering. A network operator must be familiar with the rich set of attributes that can

be modified and also with the BGP route selection process. Routing policy controls and filters can modify routing

information entering or leaving the router in order to alter forwarding and routing decisions based on the following criteria:

• What should be learned about the network from all protocols?

• What routes should be shared with other routing protocols?

• What should be advertised to other routers?

• What routing information should be modified, if any?

Consistent policies must be applied across the entire network to filter/advertise routes and modify BGP route

attributes. The following commands assist in the troubleshooting of routing policies:

• show route receive-protocol bgp <neighbor> displays received attributes.

• show route advertising-protocol bgp <neighbor> displays route and attributes sent by BGP to a specific peer.

• show route hidden extensive displays routes not usable due to BGP next-hop problems and routes filtered by an

inbound route filter.

Logging of peer state transitions and flagging BGP operations provides a good source of information when investigating

BGP problems.



VPLS Troubleshooting

This section provides a logical approach to take when determining the root cause of a problem in a VPLS network. A good

place to start is to verify the configuration setup. Following is a brief configuration snippet with corresponding descriptor.

routing-instance { vpls_vpn1 { #arbitrary name instance-type vpls; #VPLS type vlan-tags outer 4094 inner 4093; #VLAN Normalization must match if configured interface ge-1/0/0.3001; # int.unit route-distinguisher 65000:1001; # RD carried in MPGP vrf-target target:65000:1001; # VPN RT must match on all PEs in this VPLS protocols { vpls { mac-table-size { 100; # max mac table size } interface-mac-limit { # max mac that may be learned from all CE 50; facing interfaces } no-tunnel-services; # lsi interfaces for tunneling site site-1 { # arbitrary name site-identifier 1001; # unique site ID interface ge-1/0/0.3001; # list of int.unit in this VPN

The next step is to verify the control plane with the following operation commands:

• show route receive-protocol bgp <neighbor> table <vpls-vpn> detail displays BGP routes received from an MP-

iBGP peer for a VPLS instance. Use the detail/extensive option to see other BGP attributes such as route-target RT,

label base, and site-ID. The BGP next hop must have a route in the routing table for the mapping to a transport MPLS

LSP.

• show vpls connections is an excellent command to verify the VPLS connection status and to aid in troubleshooting.

After the control plane has been validated as fully functional, the forwarding plane should be checked next by issuing

the following commands. Note that the naming of devices maps to a private MPLS network, as opposed to using a

service provider MPLS network.

On local switch:

• show arp

• show interfaces ge-0/0/0

On MPLS edge router

• show vpls mac-table

• show route forwarding-table

On MPLS core router

• show route table mpls



The commands presented in this section should highlight the proper VPLS operation as follows:

• Sending to unknown MAC address, VPLS edge router floods to all members of the VPLS.

• Sending to a known MAC address, VPLS edge router maps to an outer and inner label.

• Receiving a MAC address, VPLS edge router identifies the sender and maps the MAC address to a label stack in the

MAC address cache.

• VPLS provider edge (PE) router periodically ages out unused entries from the MAC address cache.

Multicast

Looked at simplistically, multicast routing is upside down unicast routing. Multicast routing functionality is focused on

where the packet came from and directs traffic away from its source. When troubleshooting multicast, the following

methodology is recommended:

• Gather information

In one-to-many and many-to-many communications, it is important to have a good understanding of the expected

traffic flow to clearly identify all sources and receivers for a particular multicast group.

• Verify receiver interest by issuing the following commands:

show igmp group <mc_group> displays information about Internet Group Management Protocol (IGMP) group

membership received from the multicast receivers on the LAN interface.

show pim interfaces is used to verify the designated router for that interface or VLAN.

• Verify knowledge of the active source by issuing the following commands:

show multicast route group <mc_group> source-prefix <ip_address> extensive displays the forwarding state (pruned

or forwarding) and the rate for this multicast route.

show pim rps extensive determines if the source designated router has the right rendezvous point (RP) and displays

tunnel interface-related information for register message for encapsulation/de-encapsulation.

• Trace the forwarding state backwards, working your way back towards the source IP and looking for Physical

Interface Module (PIM) problems along the way with the following commands:

show pim neighbors displays information about PIM neighbors.

Show pim join extensive <mc_group> validates outgoing interface list and upstream neighbor and displays source tree

and shared tree (Real-Time Transport Protocol or RTP) state, with join/prune status.

Show multicast route group <mc_group> source-prefix <ip_address> produces extensive checks if traffic is flowing

and has a positive traffic rate.

show multicast rpf <source_address>Multicast routing uses “reverse path forwarding” check. A router forwards only

multicast packets if received on the upstream interface to the source. Otherwise, the RPF check fails, and the packet is

discarded.

Quality of Service/Class of Service (CoS)

Link congestion in the network can be the root cause of packet drops. The show interfaces queue command provides

CoS queue statistics for all physical interfaces to assist in determining the number of packets dropped due to tail drop,

and the number of packets dropped due to random early detection (RED).



OSI Layer 4-7: Transport to Application Troubleshooting

This type of problem is most likely to occur on firewalls or on routers secured with firewall filters. Below are some

important things to remember when troubleshooting Layer 4-7 issues:

• Standard troubleshooting tools such as ping and traceroute may not work. Generally, ping and traceroute are not

enabled through a firewall except in specific circumstances.

• Firewalls are routers too, In addition to enforcing stateful policies on traffic, firewalls also have the responsibility of

routing packets to their next hop. To do this, firewalls must have a working and complete routing table statically or

dynamically defined. If the table is incomplete or incorrect, the firewall will not be able to forward traffic correctly.

• Firewalls are stateful and build state for every session that has passed through the firewall. If a non-SYN packet

comes to the firewall and the firewall does not have a session open for that packet, it is considered an “out of state”

packet. This can be the sign of an attack or an application that is dormant beyond the firewall session timeout

duration attempting to send traffic.

• By definition, stateful firewalls enforce traffic though their policy based on the network and transport layers of the

OSI model. In addition, firewalls may also do protocol anomaly checks and signature matches on the application

layer for selected protocols.

• This function is implemented by ALGs. ALGs recognize application-specific sequences, change the application layer

to make protocols compatible with Port Address Translation (PAT) attempting to send traffic and Network Address

Translation (NAT), and deliver higher layer content to deep inspection (DI), antivirus, URL filter, and spam filter

features, if enabled.

• If you experience a problem that involves the passing or blocking of traffic, the very first place to look is the firewall

logs. Often the log messages will give strong hints about the problem.

Tools

Junos OS has embedded script tools to simplify and automate some tasks for network engineers. Commit scripts,

operation (op) scripts, and event scripts provide self monitoring, self diagnosing, and self healing capabilities to the

network. The apply-macro command feeds a commit script to extend and customize the router configuration based

on user-defined data and templates. Together, these tools offer an almost infinite number of applications to reduce

downtime, minimize human error, accelerate service deployment, and reduce overall operational costs. For more

information, refer to: www.juniper.net/us/en/community/junos/script-automation.

Troubleshooting Summary

Presenting an exhaustive and complete troubleshooting guide falls outside the scope of this Data Center LAN

Migration Guide. Presented in this section is a methodology to understand the factors contributing to a problem and a

logical approach to the diagnostics needed to investigate root causes. This method relies on the fact that IP networks

are modeled around multiple layered architectures. Each layer depends on the services of the underlying layers. From

the physical network topology comprised of access, aggregation, and core tiers to the model of IP communication

founded on the 7 OSI layers, matching symptoms to the root cause layer is a critical step in the troubleshooting

methodology. Juniper platforms have also implemented a layered architecture by integrating separate control and

forwarding planes. Once the root cause layer is correctly identified, the next steps are to isolate the problem and to

take the needed corrective action at that specific layer.

For more details on platform specifics, please refer to the Juniper technical documentation that can be found at:

www.juniper.net/techpubs.

www.juniper.net/us/en/community/junos/script-automation


Chapter 5: Summary and Additional Resources



Summary

Today’s data center is a vital component to business success in virtually all industries and markets. New trends and

technologies such as cloud computing and SOA-based applications have significantly altered data center traffic flows

and performance requirements. Data center designs based on the performance characteristics of older technology

and traffic flows have resulted in complex architectures which do not easily scale and also may not provide the

performance needed to efficiently meet today’s business objectives.

A simplified, next-generation, cloud-ready two-tier data center design is needed to meet these new challenges without

compromising performance or security. Since most enterprises won’t disrupt a production data center except for

scheduled maintenance and business continuity testing, a gradual migration to the “new network” is often most practical.

This guide has identified and described how migration towards a simpler two-tier design can begin at any time and

at various insertion points within an existing legacy data center architecture. These insertion points are determined

by related trigger events such as adding a new application or service, or by larger events such as data center

consolidation. This guide has outlined the design considerations for migration at each network layer, providing

organizations with a path towards a simplified high-performance network which can not only lower TCO, but also

provide the agility and efficiency to enable organizations to gain a competitive advantage by leveraging their data

center network.

Juniper Networks has been delivering a steady stream of network innovations for more than a decade. Juniper brings

this innovation to a simplified data center LAN solution built on three core principles: simplify, share, and secure.

Creating a simplified infrastructure with shared resources and secure services delivers significant advantages over

other designs. It helps lower costs, increase efficiency, and keep the data center agile enough to accommodate any

future business changes or technology infrastructure requirements.

Additional Resources

Data Center Design Resources

Juniper has developed a variety of materials that complement this Migration Guide and are helpful to the network

design process in multiple types of customer environments and data center infrastructures. On our public Internet

website, we keep many of these materials at the following locations:

1. Data Center Solution Reference Materials Site:


At this location you will find information helpful to the design process at a number of levels, organized by selectable

tabs according to the type of information you are seeking—analyst reports, solution brochures, case studies, reference

architecture, design guides, implementation guides, and industry reports.

The difference between a reference architecture, design guide, and implementation guide is the level of detail the

document addresses. The reference architecture is the highest level organization of our data center network approach;

the design guide provides guidance at intermediate levels of detail appropriate to, say, insertion point considerations

(in the terms of this Migration Guide); and implementation guides provide specific guidance for important types

of network deployments at different tiers of the data center network. Implementation guides give customers and

other readers enough information to start specific product implementation tasks appropriate for the most common

deployment scenarios, and are quite usable in combination with an individual product’s installation, configuration, or

operations manual.

2. Information on Juniper’s individual lines relevant to the insertion scenarios described in this guide can be found at:

Ethernet switching: www.juniper.net/us/en/products-services/switching

IP routing: www.juniper.net/us/en/products-services/routing

Network security: www.juniper.net/us/en/products-services/security

Network management: www.juniper.net/us/en/products-services/software/junos-platform/junos-space

http://www.juniper.net/us/en/products-services/software/junos-platform/junos-space



3. Information on the way Juniper’s offerings fit with various alliance partners in the data center environment can be

found at: www.juniper.net/us/en/company/partners/enterprise-alliances.

4. Information on Juniper’s Professional Services to support planning and design of migration projects can be found at:

www.juniper.net/us/en/products-services/consulting-services/#services.

For more detailed discussions of individual projects and requirements, please contact your Juniper or authorized

Juniper partner representative directly.

Training Resources

Juniper Networks offers a rich curriculum of introductory and advanced courses on all of its products and solutions.

Learn more about Juniper’s free and fee-based online and instructor-led hands-on training offerings:

www.juniper.net/us/en/training/technical_education.

Juniper Networks Professional Services

Juniper Networks Professional Services organization is uniquely qualified to help enterprises or service providers design,

implement, and optimize their networks for confident operation and rapid returns on infrastructure investments.

The Professional Services team understands today’s Internet demands and those that are just around the corner—

for bandwidth efficiency, best-in-class security, solid reliability, and cost-effective scaling. These highly trained,

experienced professionals augment your team to keep your established network protected, up-to-date, performing at

its best, and aligned with the goals of your organization.

• Planning and design consulting—Ensures that the new design is aligned with your stated business and technical goals.

Incorporates critical business information in the network re-architecture. Eliminates costly redesigns and lost time.

• Implementation and configuration services—Helps you achieve the deployment of complex products and

technologies efficiently with minimal business disruption. These services shorten the interval between network

element installation and revenue generation. This may includes services such as onsite and remote support

for installation, configuration, and testing. It may also include production of site requirements, site survey

documentation, hardware installation documentation, and network test documentation.

• Knowledge transfer—Juniper Networks’ IP experts can train internal teams in best-in-class migration practices or

any specific enterprise issues.

• Project management—A dedicated project manager can be assigned to assist with administration and management

throughout the entire migration project. In general, this service provides an emphasis on tasks such as project

planning, reports that track project tasks against scheduled due dates, and project documentation.

• Resident engineer—A Juniper Networks Resident Engineer (RE) can be placed onsite at any desired enterprise

location to engage with the engineering or operations staff on a daily basis to support a data center network.

Functioning as part of the enterprise team, REs are available for a 12-month engagement to the specific networking

environment, and provide technical assistance such as network implementation and migration, troubleshooting

and operations support, network and configuration analysis, assistance in testing Juniper product features and

functionality to help optimize the value of high-performance networking to meet an evolving business environment.

Learn more about Juniper Networks Professional Services at: www.juniper.net/us/en/products-services/consulting-

services.

Juniper Networks Technical Assistance Center (JTAC) provides a single point of contact for all support needs with

skilled engineers and automatic escalation alerts to senior management.

The Customer Support Center (CSC) provides instant, secure access to critical information, including the Juniper

Networks Knowledge Base, frequently asked questions, proactive technical bulletins, problem reports, technical notes,

release notes, and product documentation.



About Juniper Networks

Juniper Networks is in the business of network innovation. From devices to data centers, from consumers to cloud

providers, Juniper Networks delivers the software, silicon and systems that transform the experience and economics of

networking. The company serves customers and partners worldwide. Additional information can be found at

www.juniper.net.





7100128-002-EN Feb 2011

Copyright 2011 Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, Junos, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered marks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

EMEA Headquarters

Juniper Networks Ireland

Airside Business Park

Swords, County Dublin, Ireland

Phone: 35.31.8903.600

EMEA Sales: 00800.4586.4737

Fax: 35.31.8903.601

APAC Headquarters

Juniper Networks (Hong Kong)

26/F, Cityplaza One

1111 King’s Road

Taikoo Shing, Hong Kong

Phone: 852.2332.3636

Fax: 852.2574.7803

Corporate and Sales Headquarters

Juniper Networks, Inc.

1194 North Mathilda Avenue

Sunnyvale, CA 94089 USA

Phone: 888.JUNIPER (888.586.4737)

or 408.745.2000

Fax: 408.745.2100

www.juniper.net

Printed on recycled paper

To purchase Juniper Networks solutions,

please contact your Juniper Networks

representative at 1-866-298-6428 or

authorized reseller.

Documents

Juniper Data Center LAN Migration Guide