Juniper Networks Design Fundamentals-15 b-R_SG_v1of2

Prévia do material em texto

SH
AR
E
Juniper Networks Design 
Fundamentals
15.b
Student Guide
Volume 1 of 2
US
E 
ON
LY
 —
 D
O 
NO
T 
1133 Innovation Way
Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Worldwide Education ServicesWorldwide Education Services
NA
L 
Course Number: EDU-JUN-JNDFER
IN
T
This document is produced by Juniper Networks, Inc.
This document or any part thereof may not be reproduced or transmitted in any form under penalty of law, without the prior written permission of Juniper Networks Education 
Services. 
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The 
Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service RE
marks are the property of their respective owners.
Juniper Networks Design Fundamentals Student Guide, Revision 15.b
Copyright © 2015 Juniper Networks, Inc. All rights reserved. 
Printed in USA.
Revision History:
Revision 15.a—March 2015.
Revision 15.b—June 2015.
The information in this document is current as of the date listed above.
The information in this document has been carefully verified and is believed to be accurate. Juniper Networks assumes no responsibilities for any inaccuracies that may 
appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary, incidental, or consequential damages resulting from any defect or 
omission in this document, even if advised of the possibility of such damages.
O 
NO
T 
SH
A
Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has no known 
time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an agreement 
executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and agree to be bound by its 
license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper Networks software, may contain 
prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should consult the software license for further details.
IN
TE
RN
AL
 U
SE
 O
NL
Y 
—
 D
Contents
Chapter 1: Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Chapter 2: Network Design Fundamentals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
A Need for Network Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Knowledge Is King . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
A Proposed Design Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
A Reference Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
Chapter 3: Understanding Customer Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
RFP Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Scoping the Design Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
Analyzing the Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
Lab: Understanding Customer Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25
Chapter 4: Organizing the Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Processing the Data and Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Identifying Boundaries and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Design Proposal Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
Chapter 5: Securing the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Why Secure the Network? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Security Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
Chapter 6: Creating the Design—Campus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
The Campus Network: An Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Best Practices and Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
Architectural Design Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29
Lab: Creating the Design—Campus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-41
Chapter 7: Creating the Design—WAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
The WAN: An Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Best Practices and Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
WAN Design Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-30
Lab: Creating the Design—WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-38
Chapter 8: Creating the Design—Data Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
The Data Center: An Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Best Practices and Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7
Data Center Design Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-31
Lab: Creating the Design—Data Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-44
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Contents • iiiI
Chapter 9: Business Continuity and Network Enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1
Business Continuity Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
High Availability Design Considerations and Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10
High Availability Offerings and Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18
Acronym List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ACR-1
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
iv • Contents www.juniper.netI
Course Overview
This three-day course is designed to cover introductory best practices, theory, and design principles for overall network 
design and will serve as the prerequisite course for other design subject areas — data center, security, and WAN. 
Objectives
After successfully completing this course, you should be able to:
• Provide an overview of network design needs and common business requirements.
• Describe key product groups related to campus, WAN, data center, and security architectures.
• Analyze and interpret common RFP requirements.
• Scope a network design by gathering data and working with key stakeholders.
• Describe ways of processing customer data and design requests.
• Identify boundaries and scope for the design proposal.
• List common considerations when creating a design proposal.
• Provide an overview of network security design and common vulnerabilities.
• List high-level design considerations and best practices for securing the network.
• List the components of the campus network design.
• Describe best practices and design considerations for the campus.
• Describe architectural design options for the campus.
• List the components of the WAN.
• Describe best practices and design considerations for the WAN.
• Describe design options for the WAN.
• List the components of the data center design.
• Describe best practices and design considerations for the data center.
• Describe architectural design options for the data center.
• Define business continuity and its importance in network design.
• Describe high availability design considerations and best practices.
• Provide an overview of high availability offerings and solutions.
• Describe class of service (CoS) design considerations.
• Provide an overview of environmental considerations in network design.
• List design considerations and best practices for managing the network.
• Provide an overview of Juniper Networks and third party options for network management.
• List design considerations and best practices for network automation.
• Provide an overview of automation tools.
• Explain the foundational topics that have been taught throughout the course.
• Create a network design proposal that satisfies customer requirements and business needs.
• Provide an overview of the steps involved in migrating a network.
• Describe best practices used in network migration.
• List the various campus network topographies.
• Describe sample design options for the campus.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Course Overview • vI
Intended Audience
This course is targeted for Juniper Networks system engineers, partner sales engineers (including Champions), and 
services partners who are interested in learning network design introductory concepts. However, the course is also 
applicable to a general audience of Juniper customers with a desire to learn more about network design. 
Course Level
Juniper Networks Design Fundamentals is an associate-level course. 
Prerequisites
The prerequisites for this course are as follows:
• Understanding of the OSI model and TCP/IP;
• Knowledge of routing architectures and protocols;
• Knowledge of switching architectures and protocols;
• Knowledge of Juniper Networks products and solutions;
• Understanding of infrastructure security principles; and
• Basic knowledge of hypervisors and load balancers.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
vi • Course Overview www.juniper.netI
Course Agenda
Day 1
Chapter 1: Course Introduction
Chapter 2: Network Design Fundamentals
Chapter 3: Understanding Customer Requirements
Lab: Understanding Customer Requirements
Chapter 4: Organizing the Data
Chapter 5: Securing the Network
Day 2
Chapter 6: Creating the Design—Campus
Lab: Creating the Design—Campus
Chapter 7: Creating the Design—WAN
Lab: Creating the Design—WAN
Chapter 8: Creating the Design—Data Center
Lab: Creating the Design—Data Center
Chapter 9: Business Continuity and Network Enhancements
Day 3
Chapter 10: Network Management
Chapter 11: Automation
Lab: Enhancing the Design
Chapter 12: Putting Network Design into Practice
Lab: Final Project
Appendix A: Network Migration Strategies
Appendix B: Sample Campus Designs
Appendix C: Sample Response to RFP
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Course Agenda • viiI
Document Conventions
CLI and GUI Text
Frequently throughout this course, we refer to text that appears in a command-line interface (CLI) or a graphical user 
interface (GUI). To make the language of these documents easier to read, we distinguish GUI and CLI text from standard 
text according to the following table.
Style Description Usage Example 
Franklin Gothic Normal text. Most of what you read in the Lab Guide and 
Student Guide.
Console text:
GUI text elements:
Select File > Open, and then click 
Configuration.conf in the Filename 
text box.
Input Text Versus Output Text
You will also frequently see cases where you must enter input text yourself. Often these instances will be shown in the 
context of where you must enter them. We use bold style to distinguish text that is input versus text that is simply 
displayed.
Style Description Usage Example
Normal CLI
Normal GUI
No distinguishing variant. Physical interface:fxp0, Enabled
View configuration history by clicking 
Configuration > History.
CLI Input
GUI Input
Text that you must enter.
Select File > Save, and type config.ini 
in the Filename field.
 
Defined and Undefined Syntax Variables
Finally, this course distinguishes between regular text and syntax variables, and it also distinguishes between syntax 
variables where the value is already assigned (defined variables) and syntax variables where you must assign the value 
(undefined variables). Note that these styles can be combined with the input style as well. 
Style Description Usage Example
CLI Variable
GUI Variable
Text where variable value is already 
assigned.
policy my-peers
Click my-peers in the dialog.
CLI Undefined
GUI Undefined
Text where the variable’s value is the 
user’s discretion or text where the 
variable’s value as shown in the lab 
guide might differ from the value the 
user must input according to the lab 
topology.
Type set policy policy-name.
ping 10.0.x.y
Select File > Save, and type filename in 
the Filename field.
Courier New
• Screen captures
• Noncommand-related syntax
• Menu names
• Text field entry
commit complete
Exiting configuration mode 
lab@San_Jose> show route
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
viii • Document Conventions www.juniper.netI
Additional Information
Education Services Offerings
You can obtain information on the latest Education Services offerings, course dates, and class locations from the World 
Wide Web by pointing your Web browser to: http://www.juniper.net/training/education/.
About This Publication
The Juniper Networks Design Fundamentals Student Guide is written and maintained by the Juniper Networks Education 
Services development team. Please send questions and suggestions for improvement to training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats: 
• Go to http://www.juniper.net/techpubs/.
• Locate the specific software or hardware release and title you need, and choose the format in which you 
want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or accountrepresentative.
Juniper Networks Support
For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or at 1-888-314-JTAC 
(within the United States) or 408-745-2121 (outside the United States).
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Additional Information • ixI
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
x • Additional Information www.juniper.netI
HA
RE
Juniper Networks Design Fundamentals 
Chapter 1: Course Introduction
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
S
IN
T
Juniper Networks Design Fundamentals 
We Will Discuss:
• Objectives and course content information;
• Additional Juniper Networks, Inc. courses; and
• The Juniper Networks Certification Program.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 1–2 • Course Introduction www.juniper.netI
Juniper Networks Design Fundamentals 
Introductions
The slide asks several questions for you to answer during class introductions. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Course Introduction • Chapter 1–3I
Juniper Networks Design Fundamentals 
Course Contents: Part 1
The slide lists the topics we discuss in this course.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 1–4 • Course Introduction www.juniper.netI
Juniper Networks Design Fundamentals 
Course Contents: Part 2
The slide lists the remainder of the topics we discuss in this course.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Course Introduction • Chapter 1–5I
Juniper Networks Design Fundamentals 
Prerequisites
The slide lists the prerequisites for this course.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 1–6 • Course Introduction www.juniper.netI
Juniper Networks Design Fundamentals 
General Course Administration
The slide documents general aspects of classroom administration.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Course Introduction • Chapter 1–7I
Juniper Networks Design Fundamentals 
Training and Study Materials
The slide describes Education Services materials that are available for reference both in the classroom and online.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 1–8 • Course Introduction www.juniper.netI
Juniper Networks Design Fundamentals 
Additional Resources
The slide provides links to additional resources available to assist you in the installation, configuration, and operation of 
Juniper Networks products.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Course Introduction • Chapter 1–9I
Juniper Networks Design Fundamentals 
Satisfaction Feedback
Juniper Networks uses an electronic survey system to collect and analyze your comments and feedback. Depending on the 
class you are taking, please complete the survey at the end of the class, or be sure to look for an e-mail about two weeks 
from class completion that directs you to complete an online survey form. (Be sure to provide us with your current e-mail 
address.)
Submitting your feedback entitles you to a certificate of class completion. We thank you in advance for taking the time to 
help us improve our educational offerings.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 1–10 • Course Introduction www.juniper.netI
Juniper Networks Design Fundamentals 
Juniper Networks Education Services Curriculum
Juniper Networks Education Services can help ensure that you have the knowledge and skills to deploy and maintain 
cost-effective, high-performance networks for both enterprise and service provider environments. We have expert training 
staff with deep technical and industry knowledge, providing you with instructor-led hands-on courses in the classroom and 
online, as well as convenient, self-paced eLearning courses.
Courses 
You can access the latest Education Services offerings covering a wide range of platforms at 
http://www.juniper.net/training/technical_education/.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Course Introduction • Chapter 1–11I
Juniper Networks Design Fundamentals 
Juniper Networks Certification Program
A Juniper Networks certification is the benchmark of skills and competence on Juniper Networks technologies. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 1–12 • Course Introduction www.juniper.netI
Juniper Networks Design Fundamentals 
Juniper Networks Certification Program Overview
The Juniper Networks Certification Program (JNCP) consists of platform-specific, multitiered tracks that enable participants 
to demonstrate competence with Juniper Networks technology through a combination of written proficiency exams and 
hands-on configuration and troubleshooting exams. Successful candidates demonstrate a thorough understanding of 
Internet and security technologies and Juniper Networks platform configuration and troubleshooting skills. 
The JNCP offers the following features:
• Multiple tracks;
• Multiple certification levels;
• Written proficiency exams; and
• Hands-on configuration and troubleshooting exams.
Each JNCP track has one to four certification levels—Associate-level, Specialist-level, Professional-level, and Expert-level. The 
Associate-level, Specialist-level, and Professional-level exams are computer-based exams composed of multiple choice 
questions administered at Pearson VUE testing centers worldwide. 
Expert-level exams are composed of hands-on lab exercises administered at select Juniper Networks testing centers. Please 
visit the JNCP website at http://www.juniper.net/certification for detailed exam information, exam pricing, and exam 
registration.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Course Introduction • Chapter 1–13I
Juniper Networks Design Fundamentals 
Preparing and Studying
The slide lists some options for those interested in preparing for Juniper Networks certification.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 1–14 • Course Introduction www.juniper.netI
Juniper Networks Design Fundamentals 
Junos Genius 
The Junos Genius application takes certification exam preparation to a new level. With Junos Genius you can practice for 
your exam with flashcards, simulate a live exam in a timed challenge, and even build a virtual network with device 
achievements earned by challenging Juniper instructors. Download the app now and Unlock your Genius today!
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Course Introduction • Chapter 1–15I
Juniper Networks Design Fundamentals 
Find Us Online
The slide lists some online resources to learn and share information about Juniper Networks.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 1–16 • Course Introduction www.juniper.netI
Juniper Networks Design Fundamentals 
Any Questions?
If you have any questions or concerns about the class you are attending, we suggest that you voice them now so that your 
instructor can best address your needs during class.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Course Introduction • Chapter 1–17I
Juniper Networks Design Fundamentals 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 1–18 • Course Introduction www.juniper.netI
HA
RE
Juniper Networks Design Fundamentals
Chapter 2: Network Design Fundamentals
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
S
IN
T
Juniper Networks Design Fundamentals
We Will Discuss:
• Network design needs and common business requirements; and
• Key product groups related to campus, WAN, data center, and security architectures.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 2–2 • Network Design Fundamentals www.juniper.netI
Juniper Networks Design Fundamentals
A Need for Network Design
The slide lists the topics we will discuss. We discuss the highlighted topic first.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NOT 
SH
AR
E
www.juniper.net Network Design Fundamentals • Chapter 2–3I
Juniper Networks Design Fundamentals
You Are the Architect
Imagine the role of a building architect. The process of creating a new building typically goes through various stages of 
planning, designing, and construction. The architect must consider environmental impact, governing laws in the surrounding 
area, building functionality, and aesthetic style. A successful architectural plan can result in a beautiful building that will 
withstand the tests of time. Indeed, some of the oldest buildings in the world not only have withstood the tests of time, they 
have transformed the cities where they were built, and changed the lives of the architects who designed them!
You are a network designer; thus, you are an architect who builds networks. Network architecture is a lot like building 
architecture—you must consider proper planning, design, flow, and construction of the network you are about to design. 
Many of the key elements you must understand are listed on the slide. We will discuss these elements in greater detail 
throughout this content. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 2–4 • Network Design Fundamentals www.juniper.netI
Juniper Networks Design Fundamentals
Doing the Research
Before you sit down for your first meeting with the customer, it’s important that you understand who your customer is—
beyond the name or title on the business cards. You must fully research what your customer is doing as a business. What do 
they sell? What is their industry? How are they organized structurally? What sets your customer apart from their 
competitors? As you start to put the pieces of your customer’s puzzle together, you will start to understand what potential 
network designs you can offer that will meet their approval.
Your First Meeting
Your first discussion with the customer should be to understand business requirements and establish goals. Early on, you 
should understand from the customer what their overall goal for the network design project is. What are the benefits and 
risks to designing a new network? What will be considered “success” to key stake holders? Answering these questions early 
is imperative to building a network that suits—and exceeds—the customer’s needs. Consider that business requirements and 
goals might change as you work on your design plan, so the process of establishing goals and understanding business 
requirements is cyclical. We discuss engaging the customer more on the next slide.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Network Design Fundamentals • Chapter 2–5I
Juniper Networks Design Fundamentals
Engaging with the Customer
Understanding the customer you are designing for takes more than searching the Internet or reading a few publications. You 
likely will not fully understand the customer and what they do without becoming a partner with them—that is to say—seeing 
the company as its leaders see it. You must understand who the stake holders are. How visible is the project to leaders of the 
organization? More importantly, how critical is this project to them? Do you personally view this project as equally important? 
As you work closely with the customer to understand what their overall goal is, you will better know what is required to create 
a successful design that meets or exceeds any goals the customer has. If you know where the risks and consequences are 
should the project fail, you are beginning to understand the customer. If your desire to succeed is based less on how much 
you get paid, but is based more on seeing the customer’s goals as important to you, then you are starting to think like the 
customer. You are partnering with them on the road to building a successful network design.
Engaging with the Customer Requires Back and Forth Communication
In the classic video game Pong, two players simulate a table tennis match and attempt to hit a ball back and forth until the 
opposing player misses the ball. Often, the game might seem to last an eternity because the opposing player is able to 
respond to your attempts to score a point. Engaging the customer will often feel like a game of Pong because there is so 
much “back-and-forth” when creating a design to fit the customer’s needs. However, unlike Pong, there is no attempt in this 
back-and-forth communication to beat the customer by scoring more points than them. Instead, the questions and answers 
that result from the back-and-forth communication should eventually result in 100 percent satisfaction with the network 
design plan. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 2–6 • Network Design Fundamentals www.juniper.netI
Juniper Networks Design Fundamentals
Knowledge Is King
The slide highlights the topic we discuss next.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Network Design Fundamentals • Chapter 2–7I
Juniper Networks Design Fundamentals
What’s in the Tool Bag?
Understanding who the customer is and what type of business they offer is only part of the equation for building a successful 
network. You are the architect and you represent Juniper Networks; thus, you are responsible for knowing what products and 
solutions Juniper Networks can offer. Network design, however, is a team effort. The thought might seem ridiculous, but a 
building architect would never set out to build a skyscraper without any help. You might not be a subject matter expert (SME) 
for every solution that Juniper Networks offers, but as the architect, you will know who the SMEs are and with whom to 
surround yourself in order to make an efficient team. 
Although you will often rely on SMEs for specific recommendations on the design, you are still the lead architect, so you want 
to be very comfortable discussing Juniper Networks’ solutions and specific platforms. We highlight these solutions on the 
next several slides.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 2–8 • Network Design Fundamentals www.juniper.netI
Juniper Networks Design Fundamentals
Overview of Junos Devices
While this course does not focus on platform specifics or configuration options for any specific platform, it is important that 
you understand the solution that Juniper Networks offers and how you can incorporate that into your design.
Juniper Networks offers a wide variety of solutions in routing, switching, and security. These devices run the Junos OS; 
meaning, all of the devices shown on the slide run on a single network operating system. The Junos OS offers the power of a 
single operating system that can reduce complexity, achieve operational excellence, and dynamically deliver services with 
lower Total Cost of Ownership (TCO). 
Running devices on a single operating system means that the software for those devices is developed along a single 
software release train and built on one modular software architecture, as depicted in the slide above.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Network Design Fundamentals • Chapter 2–9I
Juniper Networks Design Fundamentals
Junos Routing Devices
The following are some of the routing devices that run the Junos OS:
• The ACX Series products deliver simplified end-to-end provisioning and support Layer 2 and Layer 3 
functionality with IP/MPLS traffic engineering. The fixed 1 U ACX Series models are environmentally hardened 
and support passive cooling (fan-less design) for outdoor deployments. 
• The LN Series provides high-performance network routing, firewall, and intrusion detection service (IDS) for 
harsh environments, including terrestrial, air, and sea vehicles and remote data aggregation points.
• The M Series multiservice routers provide up to 320 Gbps of aggregate half-duplex throughput. The M Series 
family can be deployed in both high-end enterprise and service-provider environments. Large enterprises deploy 
M Seriesrouters in a number of different roles, including Internet gateway router, WAN connectivity router, 
campus core router, regional backbone and data center routers. In service-provider environments, the M Series 
router operates predominantly as a multiservice edge router, but you can also deploy it in small and medium 
cores, and in peering, route reflector, multicast, mobile, and data-center applications. 
• The T Series core routers provide up to 25.6 Tbps of throughput. The T Series family is ideal for service provider 
environments and is deployed within the core of those networks. 
• The PTX Series packet transport switches provide up to 16 Tbps of throughput in a single chassis. The PTX 
Series family is ideal for the service provider supercore and can readily adapt to today’s rapidly changing traffic 
patterns for video, mobility and cloud-based services. 
Continued on the next page.NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 2–10 • Network Design Fundamentals www.juniper.netI
Juniper Networks Design Fundamentals
Junos Routing Devices (contd.)
The following are some more of the routing devices that run the Junos OS:
• The MX Series Ethernet services routers provide up to 34.4 Tbps of aggregate half-duplex throughput today, 
with scalability to 80 Tbps in the future. The MX Series family is targeted for dense dedicated access 
aggregation and provider edge services in medium and large points of presence (POPs). Large enterprise 
environments and service providers can leverage MX Series Ethernet services routers for a variety of network 
functions including Ethernet transport and aggregation, and can use them to offer new Ethernet-based 
services. 
Other devices, such as SRX Series, also provide routing. For more information on all of Juniper’s routing devices, go to 
http://www.juniper.net/us/en/products-services/routing/.
Note
For simplification purposes, we focus primarily 
on the MX Series as a routing device throughout 
the course.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Network Design Fundamentals • Chapter 2–11I
Juniper Networks Design Fundamentals
Positioning MX Series Devices
The slide lists the different MX Series devices available and where they are typically positioned. MX Series devices are 
typically considered for the network edge. When selecting a routing device for network design, you must consider throughput 
requirements, capacity, scale, and overall performance. 
More information on MX Series devices can be found on the Juniper Website.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 2–12 • Network Design Fundamentals www.juniper.netI
Juniper Networks Design Fundamentals
Junos Switching Devices
The following are some of the switching devices that run the Junos OS:
• The EX Series Ethernet switches provide up to 6.2 Tbps of full duplex throughput. The EX Series switches are 
designed for access, aggregation, and core deployments and are well suited for low-density to high-density 
enterprise and data center environments. 
• The QFX Series switches are high-performance, low-latency platforms for top-of-rack or end-of-row installations. 
They can also be deployed as 10 GbE, 40 GbE or100GbE access, spine, core or aggregation devices in Virtual 
Chassis, Virtual Chassis Fabric, Multi-Chassis LAG and Junos Fusion architectures.
• The OCX Series open networking switches provide the Junos OS software with cloud-optimized, open source 
switching hardware built on commercially sourced components, as defined by the industry-recognized Open 
Compute Project (OCP) Foundation. OCX Series switches deliver cost-effective switching for customers that 
require massive-scale cloud deployments. 
For more information on Juniper’s switching devices, go to http://www.juniper.net/us/en/products-services/switching/.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Network Design Fundamentals • Chapter 2–13I
Juniper Networks Design Fundamentals
Positioning Ethernet Switches
The slide pinpoints where both EX Series and QFX Series devices are typically positioned. EX Series devices can offer 
throughput speeds of up to 240 Gbps per slot (full duplex), where QFX Series devices can offer up to 2.56 Tbps per slot. 
Form factor, density, and economics should be considered when positioning a switching device. 
For specifics on EX Series and QFX Series devices, see the Juniper Website.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 2–14 • Network Design Fundamentals www.juniper.netI
Juniper Networks Design Fundamentals
Junos Security Devices
The following is one of the security devices that run the Junos OS:
• The SRX Series services gateways provide up to 120 Gbps of full duplex throughput. The SRX Series family is 
designed to meet the network and security requirements for consolidated data centers, managed services 
deployments, and aggregation of security services in both enterprise and service provider environments. 
For more information on all of Juniper’s switching devices, go to http://www.juniper.net/us/en/products-services/security/. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Network Design Fundamentals • Chapter 2–15I
Juniper Networks Design Fundamentals
Positioning SRX Series Devices
Juniper hardware platforms cover a broad range to meet the specific needs of any deployment. The SRX platform runs from 
branch office CPE suitable for managed service offerings to Campus platforms and all the way to high end modular systems 
capable of running at up to 2 Tbs for the most demanding enterprise, data center, and service provider deployments. 
For more information on SRX Series devices, see the Juniper Website.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 2–16 • Network Design Fundamentals www.juniper.netI
Juniper Networks Design Fundamentals
vSRX
Virtualization technologies have taken the data center by storm in recent years. Gartner, a technology research company, 
predicts that over 70% of server workloads will be virtualized in just a few short years. Data center virtualization and cloud 
computing technologies enable agility that accelerate the implementation of all kinds of new applications, technologies, and 
features. But this new, faster speed of change brings on new security risks just as quickly.
vSRX can address the security challenges of virtualization.vSRX is a virtual version of the Junos OS, which runs as a virtual 
machine (VM) using either VMware or KVM as the host software. vSRX delivers in a VM the Junos OS and SRX Series 
advanced security for branch SRX Series devices. It protects VM traffic and the virtualized network at the tenant virtual 
network edge. 
For additional, in-depth details on vSRX, go to https://www.juniper.net/us/en/products-services/security/firefly-perimeter/.
vMX
We discussed MX Series edge routers previously. The vMX virtual router is a full-featured carrier-grade router that offers the 
same quality and features of the physical MX Series platform. The vMX provides complete control, forwarding, and 
management planes. vMX support vTrio packet handling and forwarding by compiling the programmable Junos Trio chipset 
microcode for x86 chipsets. 
For additional, in-depth details on the vMX Series, go to 
https://www.juniper.net/us/en/products-services/routing/mx-series/vmx/.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Network Design Fundamentals • Chapter 2–17I
Juniper Networks Design Fundamentals
Other Key Solutions
There are many products that Juniper Networks, in addition to the Junos OS based platforms we have discussed in this 
content. These solutions should also be included as part of your design proposal:
• Junos Space: Comprehensive network management solution that simplifies and automates management of 
Juniper’s switching, routing, and security devices. For more information on Junos Space, go to http://www.juniper.net/us/en/products-services/network-management/junos-space-platform/.
• Juniper Networks Secure Analytics, (JSA): Security Information and Event Management (SEIM) that 
consolidates large volumes of event data from thousands of both Juniper and non-Juniper devices, endpoints, 
and applications in near real time. For more information on JSA, go to 
http://www.juniper.net/us/en/products-services/security/secure-analytics/.
Partner Solutions
Juniper works with many partners to provide solutions to needs that Juniper cannot necessarily fulfill. Examples of these 
solutions include partnerships to provide secure remote access, network access control, load balancing, and wireless 
access. For more information on some of these partnerships, see the Juniper Website.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 2–18 • Network Design Fundamentals www.juniper.netI
Juniper Networks Design Fundamentals
Understanding the Competition
If you are to successfully sell a design plan that incorporates solutions from Juniper Networks, you will need to know your 
competition, what they offer, and how their solution matches up with what you have to offer. In some instances, the customer 
might only be familiar with proprietary systems or protocols due to their experience with a competitor. In these situations, you 
can often counter with a similar solution that Juniper Networks offers, but is compliant with standards that will allow for 
greater scalability in the future. 
In some situations, you will need to build a design around an existing solution from a competitor. You might need to design a 
solution that can live in harmony with other vendors. This means switching from proprietary services to using more 
standardized protocols. In all cases, you should be able to understand and easily explain how your design will respond to 
questions regarding the competition.
Confidence is Key
Regardless of who your customer has worked with in the past, or what equipment is in their current environment, you must 
be able to show total confidence in your network design. Feeling comfortable with your design means that you can provide 
immediate feedback when customers ask questions related to competing services. Do not focus on what your solution can’t 
provide. Likely, there is an alternate solution that your design will provide that can meet any challenge from competing 
products. Customers—and people in general—can be wary of change. Understanding what you do best and focusing on those 
key areas will help the customer gain confidence in your plan. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Network Design Fundamentals • Chapter 2–19I
Juniper Networks Design Fundamentals
A Proposed Design Methodology
The slide highlights the topic we discuss next.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 2–20 • Network Design Fundamentals www.juniper.netI
Juniper Networks Design Fundamentals
Juniper’s Lifecycle Service Approach
Juniper follows a simple lifecycle approach when designing a network for a customer. This approach consists of three main 
phases and is often cyclical through the lifetime of the design:
1. Plan: 
a. Assess the current environment and its ability to satisfy the customer’s business and technology 
requirements. 
b. Design high-level architectural plans, as well as low-level detailed plans of network devices, 
configurations, and interconnections. 
2. Build:
a. Deploy the design in both test and production environments. 
b. Migrate from the existing environment to the new environment. Provide installation and configuration, 
system testing, and system enablement.
3. Operate:
a. Support the customer by focusing on the most effective use of the solution. Provide support for any 
issues and faults, as well as proactive maintenance. 
b. Optimize the network as more systems and users come online, and as system usage increases.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Network Design Fundamentals • Chapter 2–21I
Juniper Networks Design Fundamentals
Plan Methodology
In this course, we focus primarily on the design—or Plan—phase of the service lifecycle. This phase consists of two main 
sub-phases:
1. Assess the current environment and its ability to satisfy the customer’s business and technology requirements.
a. Identify the technology shortfalls that need to be addressed as well as develop a Core technology 
roadmap that will achieve the customer’s required end-game environment. Evaluate what is necessary 
for migrating successfully from one environment to the other. 
b. Determine the scope of the design project. For example, the customer might need a design as small as a 
network segment, or as large as an entire enterprise network. Is the network a simple upgrade from an 
existing environment, or will you be creating an entirely new network?
c. Perform a data analysis to determine the condition of the current network and what improvements need 
to be made based on customer requirements and scope of the design. How does the business drive the 
data used on the network? How many users access the network internally and externally? 
2. Design high-level architectural plans, as well as low-level detailed plans of network devices, configurations, and 
interconnections. Create a project plan. Evaluate and detail responsibilities, timelines, and dependencies.
a. The High-level design typically is the logical topology that identifies protocols used, network addressing, 
security, and naming conventions. The design also might include WAN and service provider access.
b. The low-level design is the physical design and consists of physical devices that will be used in the 
design, cabling and wiring considerations. Service provider access should be determined by this point.NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 2–22 • Network Design Fundamentals www.juniper.netI
Juniper Networks Design Fundamentals
A Reference Network
The slide highlights the topic we discuss next.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Network Design Fundamentals • Chapter 2–23I
Juniper Networks Design Fundamentals
Putting It All Together
Throughout this content, we have discussed the importance of knowing who your customer is and what Juniper Networks 
solutions you can use to create a successful network design. The slide, although overly simplified, clearly illustrates where a 
variety of devices might be positioned in the key focus areas, (campus and branch offices, WAN, and the data center). If you 
were to include a high-level diagram in a proposal to a customer such as the one on the slide, you would likely include a more 
detailed physical diagram with product and wiring specifics. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 2–24 • Network Design Fundamentals www.juniper.netI
Juniper Networks Design Fundamentals
We Discussed:
• Network design needs and common business requirements; and
• Key product groups related to campus, WAN, data center, and security architectures.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Network Design Fundamentals • Chapter 2–25I
Juniper Networks Design Fundamentals
Review Questions
1.
2.
3.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 2–26 • Network Design Fundamentals www.juniper.netI
Juniper Networks Design Fundamentals
Answers to Review Questions
1.
If you understand your customer, you understand how their business drives the networking needs of the company. You understand 
who the stake holders are and how visible the project is to decision makers within the company. You understand the importance of the 
project and how your design will benefit the company and help them grow their business.
2.
The three main types of devices that run the Junos OS are routing, switching, and security devices.
3.
The threephases of Juniper Network’s lifecycle service approach are Plan, Build, and Operate.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Network Design Fundamentals • Chapter 2–27I
Juniper Networks Design Fundamentals
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 2–28 • Network Design Fundamentals www.juniper.netI
HA
RE
Juniper Networks Design Fundamentals
Chapter 3: Understanding Customer Requirements
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
S
IN
T
Juniper Networks Design Fundamentals
We Will Discuss:
• Analyzing and interpreting common Request for Proposal (RFP) requirements; and 
• Scoping a network design by gathering data and working with key stakeholders.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 3–2 • Understanding Customer Requirements www.juniper.netI
Juniper Networks Design Fundamentals
RFP Requirements
The slide lists the topics we will discuss. We discuss the highlighted topic first.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Understanding Customer Requirements • Chapter 3–3I
Juniper Networks Design Fundamentals
Design Methodology: Assess
Juniper Networks believes in a systematic, three phase approach to building networks: Plan, Build, and Operate. In this 
course, we focus primarily on the planning phase of the design. Before any network can be designed, you must first assess 
the customer’s environment. When assessing a customer’s environment, you must determine what the customer 
requirements and scope are for the design project, and you must analyze the data provided to you to build a scalable 
network that will last well into the future. We discuss these steps in detail throughout this content.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 3–4 • Understanding Customer Requirements www.juniper.netI
Juniper Networks Design Fundamentals
The Request for Proposal
The RFP is the process the customer typically used to solicit potential vendors for network design proposals. No two RFPs are 
identical, as each customer has unique requirements. The RFP can be very short and concise, or it can contain several 
pages filled with concise requests. As the architect, your job is to ensure you have thoroughly read and understood the RFP. 
Although they can differ in appearance and requirements, every RFP normally includes the following:
• A list of design requirements including business goals, scope, and information on the existing network 
environment. 
• The types of solutions that the design must include, such as wireless, high availability (HA), security, and so 
forth. The wording for these requirements can be generalized or very specific.
• Warranty requirements for the products you offer as well as any legal terms attached to the solution.
Continued on the next page.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Understanding Customer Requirements • Chapter 3–5I
Juniper Networks Design Fundamentals
The Customer Considers Multiple Vendors
In many instances, you are not the only vendor the customer is considering. When the customer first recognizes the need to 
create or update a network, they will usually create the RFP and send it out to multiple vendors, including you. There might 
be a specific format or deadline that you must follow in your response. Be sure to include as much relevant information as 
you can in your response. The customer will use RFP responses to quickly eliminate vendors who do not meet their 
requirements. In many ways, responding to an RFP is like applying for a job. If you apply for a job, but do not represent 
yourself well during the application process, you most likely will not pass the initial screening. When responding to the RFP, 
be timely, thorough, and honest. Respond to the RFP using the customer’s requested format. to avoid eliminating yourself 
from consideration.
In some cases, you might receive a Request for Information, (RFI) rather than an RFP. What is the difference? An RFI can be 
quite broad in scope and typically only covers the technical aspects of the design request. A customer will often send an RFI 
to you to determine if you are capable of providing the services they are looking for. The customer will send you an RFP if they 
want information on pricing and contract information included in the design proposal. Responding to an RFI is a great way to 
throw your name into consideration for a project, while the RFP takes more effort on the part of both parties because you 
would also include details on pricing, warranty, timetables and legal expectations. For the simplicity in this course, we 
identify both the RFI and RFP as the same thing and use the term RFP to describe them.
The next several slides examine various elements of the RFP.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 3–6 • Understanding Customer Requirements www.juniper.netI
Juniper Networks Design Fundamentals
RFP Key Elements: Part 1
The RFP can include a variety of elements that describe the company and the business they are in. The business summary 
will likely include a description of the network design project and objectives describing the business and technical goals of 
the new design. The general overview will likely include planning for future growth and an explanation for why the new design 
is required. If any of these key elements are missing from the project description, you should follow up and get more 
information so you can properly respond to the RFP.
Example
The slide illustrates a simple example of what a project description might look like in an RFP. Given the information on the 
slide, what are some of the customer’s primary challenges and goals? This short description gives us at minimum a 
high-level idea of what the customer is looking for. Remember that the RFP typically lists several pages of requested 
information. The project summary is just a small part of the RFP.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Understanding Customer Requirements • Chapter 3–7I
Juniper Networks Design Fundamentals
RFP Key Elements: Part 2
The RFP will typically include several environmental elements, including Layer 1 infrastructure details such as power supply, 
voltage, Power over Ethernet (PoE) requirements, and so forth. A campus-based RFP might include several details about the 
facilities, number of users and types of connections that users will make to connect to the network. In this section of the 
RFP, you begin to understand the scope of the project. For example, the network might be part of a larger Wide Area Network 
(WAN) solution. The environmental requirements might call for connections to a separate data center, or simply require a 
dedicated server room that’s located on site.
Example
The example on the slide describes a need for a centralized server room for data and voice connections. Note that, based on 
the description, the server room layout has not been finalized and might not be ready before your proposal is submitted. 
Sometimes you will not have all of the information you need when you respond to the RFP. Although the architectural design 
of the site is still a work in progress, you can still build a response based on the number of connections, throughput, and 
bandwidth requirements.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 3–8 • Understanding Customer Requirements www.juniper.netI
Juniper Networks Design Fundamentals
RFP Key Elements: Part 3
Many of today’s networks are large in scale and complex in nature. Most customers will likely express the requirement that 
their network be easy to maintain and troubleshoot. The customer will likely require compatibility for future expansion and 
new technologies. You should always consider a modular design to support these requirements when responding to the RFP. 
In a modular design, each device has a clearly assigned function.The simplest example of modularity is assigning devices 
based on their function in a hierarchical model. A hierarchical approach allows you to easily troubleshoot and maintain the 
network. You can easily replicate additions to the network by replicating what already exists. We discuss modular design in 
detail later in the course.
Example
In the example on the slide, the customer is not directly asking for a modular design; however, the customer is expecting that 
the business will triple in size over the next 5 years with expansion into several branch offices. The customer will need to 
easily expand the network to accommodate the growth of the business. A modular design will benefit the customer because, 
as more job roles are added and office space is opened, the network can be expanded based on the functions of the existing 
network. There is no need to create something new or rewrite something that already exists.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Understanding Customer Requirements • Chapter 3–9I
Juniper Networks Design Fundamentals
RFP Key Elements: Part 4
Connectivity and throughput requirements vary from site to site. Customers dealing with older infrastructure might prefer 
wireless connections because the cost of running wired connections to each workstation could be too great. Most customers 
will tell you that speed is critical to business success. After all, who wants to work on a slow network? Some information on 
required network speeds might be defined in the RFP, but you might need to provide the customer with a traffic analysis to 
fully understand what equipment is required to support the customer’s goals. This information is typically collected as you 
assess the customer’s existing network environment. We discuss scoping the network in detail later in this content.
Example
The example on the slide provides only a brief explanation of what the customer requires. Providing gigabit wire speeds to 
the desktop and 300 Mbps speeds to wireless devices seems simple enough, but how complex will the network be to provide 
those speeds to all users without performance degradation? Will there be enough bandwidth for all users on the network? 
Do these requirements include remote users working from home or offices with slower network speeds? The answers will 
depend on several factors, including the applications used, services offered, and available resources. As we discussed 
previously, understanding the answers to these questions will require additional research, traffic analysis, and even 
interviews with the customer’s employees. In addition, you should assemble your own team of subject matter experts to 
assist you in responding to the RFP.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 3–10 • Understanding Customer Requirements www.juniper.netI
Juniper Networks Design Fundamentals
RFP Key Elements: Part 5
In addition to the obvious speed and throughput requirements most customers expect, you can also expect to see 
requirements for business continuity. What happens to the network if a key device stops responding? Will users continue to 
access the network without interruption? Are certain applications more critical than others and therefore require priority 
during peak times? You will certainly expect to see requirements for network efficiency, quality of service (QoS), and load 
balancing solutions in most RFPs you receive.
Example
The example on the slide is a simple request that high availability (HA) be included in the RFP response. Often, the initial RFP 
will have only high level requests for certain features in the design. Some RFPs will have more specific requests to 
accommodate specific protocols or services that already exist in the network. Your job will be to find out what exactly is 
required so you can respond accordingly without eliminating yourself from consideration.
The RFP might request support for proprietary services used by specific vendors that Juniper Networks does not support. 
Respond to these requests by offering standardized solutions using Juniper Networks devices that can also inter-operate 
with other vendors. Always offer solutions by focusing on what your solution can do rather than what it does not support.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Understanding Customer Requirements • Chapter 3–11I
Juniper Networks Design Fundamentals
Scoping the Design Project
The slide highlights the topic we discuss next.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 3–12 • Understanding Customer Requirements www.juniper.netI
Juniper Networks Design Fundamentals
Responding to the RFP
As we discussed previously, every RFP is different. You are likely one of multiple vendors that the customer is considering for 
a design proposal. It is critical that you pay attention to what is defined in the RFP. Your initial response will be critical to keep 
yourself in consideration for getting the design contract. Of course, you are competing with other vendors, so you will want to 
respond in a way that highlights the benefits of choosing your proposal over other vendors. Respond to every applicable 
requirement in the RFP, and use the format specified by the customer. Remember, every customer uses different formats 
and terminology when describing their network, so be sure to use the terminology that the customer understands in your 
response.
An RFP response consists of several elements, but should always include the following:
• Executive Summary—A brief overview of your design proposal that should highlight the benefits of using your 
design.
• Network Topology—High level logical design as well as low level physical design of the proposed network.
• Design Details—Information on the devices, protocols, and technologies included in the proposed design.
• Implementation Plan—A description for how the design will be implemented, as well as timetables for when the 
plan will be ready for operation.
• Training—An education plan for employees as the new network becomes available for use.
• Support—A plan for supporting and servicing the design, once operational.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Understanding Customer Requirements • Chapter 3–13I
Juniper Networks Design Fundamentals
Defining Key Stakeholders
As you begin to work closely with the customer on a network design plan, you’ll want to determine who the key stakeholders 
are in the proposed design. Certainly your design is expected to include several benefits. The benefits of a new network also 
include some level of risk. Remember that networks provide a service for people, and no two people are the same! You must 
get to know the key people, or stakeholders, you are working with so you can build a network that they will embrace. The 
slide lists three tips to help you work with the stakeholders for your customer:
• Understand the corporate structure: Typically you will work closely with a representative or group of 
representatives from the company who are seeking your help; however, those representatives might not have 
final say in the design plan. Who has the final say in accepting or rejecting your design? You must understand 
who the decision makers are, and understand what will make the difference so they accept your design.
• Ask the right people the right questions: Having a clear idea of what the customer wants is important when 
submitting your proposal to the customer. If the customer has spent a lot of time discussing their needs with 
you and you submit a proposal that does not satisfy those needs, your proposal will not be accepted. Be 
proactive in asking questions concerning the existing network what technical requirements are needed to 
create the new network.
• Understand corporate politics: It would be nice if everybody saw things the same way, but when you are dealing 
with people, you will undoubtedlydeal with individuals within the company who do not like your design. 
Corporate politics can play a big part in decision making. Some people might prefer one vendor over Juniper 
Networks despite the obvious benefits that your design provides. Key decision makers might be divided into 
“camps” where no proposal can be agreed upon. Employees might resist your network design if it requires more 
head count or eliminates positions within the company. Be sensitive to the culture within the company you are 
working with as you develop your design proposal. NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 3–14 • Understanding Customer Requirements www.juniper.netI
Juniper Networks Design Fundamentals
Gathering Data: Part 1
As you begin to work with the customer more closely, you will need to gather the data necessary to accurately determine 
what you will need for your network design. If networks are all about providing a service for people, why not interact with the 
people you are building the network for? Use questionnaires, surveys, and interviews to interact with your customer’s 
workforce. Find out what is most important to them. How do they use the network to accomplish their daily tasks? You might 
be able to access job aids that describe in detail the daily routines of the customer’s user base. If you can get copies of job 
aids, take them!
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Understanding Customer Requirements • Chapter 3–15I
Juniper Networks Design Fundamentals
Gathering Data: Part 2
When considering a new design for your customer, you take into consideration the customer’s goals, requirements, and 
employee feedback. Consider the role of a police detective who must separate the facts from opinions and false information 
when determining who committed the crime. You must also collect the facts about the customer’s existing environment and 
vision of the future when designing the new network. You must determine the limitations to the current network and what is 
required for the new network to be successful. If the customer can provide utilization and performance reports, along with 
historical trends, you can use that data to help formulate your proposal. If the customer relationship is amicable, you might 
offer performing a traffic flow analysis as part of the proposal. The traffic flow analysis assists you in determining many 
variables—some of which are listed on the slide—that will assist you in understanding what is needed when developing the 
new design. 
If the customer already owns Juniper products, you might be able to use those products to assist in a network analysis. Junos 
devices have several troubleshooting tools that can assist you in traffic flow analysis, such as traceoptions (troubleshooting 
logs), packet capturing, and flow capturing, (J-flows). The information collected from Junos devices can then be sent to 
servers that specialize in Security Information and Event Management, (SIEM). Juniper Networks Secure Analytics (JSA) is a 
great option for SIEM because it can collect and parse out the events and flows from network devices and identify threats 
and assets from the information it collects. JSA supports Junos devices, but also a wide variety of other 3rd party devices 
that likely exist in the customer’s network.
Junos Space Network Director also has several monitoring tools for Junos devices, including visibility and network status, as 
well as traffic statistics, active alarms, and the ability to spot trends that develop over time.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 3–16 • Understanding Customer Requirements www.juniper.netI
Juniper Networks Design Fundamentals
Identifying Applications
You should now have a good idea of what applications are used based on the data from traffic analysis and feedback from 
the customer. Keep track of the applications that the customer uses on a spreadsheet or table such as the example on the 
slide. Creating a list of applications not only helps you understand what applications the customer is using and planning to 
use, but helps you prioritize traffic based on criticality. This is important, particularly, for required applications that demand 
large amounts of bandwidth. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Understanding Customer Requirements • Chapter 3–17I
Juniper Networks Design Fundamentals
Understanding Scope
As you assess the company infrastructure, you must understand the entire scope of the design project. A network design 
might seem small initially, with only a few hundred users, but that network has the potential to grow significantly over time. 
Your design must be able to accommodate any foreseeable change in capacity. Designing with modularity in mind will help 
you accommodate any network the customer has asked you to design. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 3–18 • Understanding Customer Requirements www.juniper.netI
Juniper Networks Design Fundamentals
Analyzing the Data
The slide highlights the topic we discuss next.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Understanding Customer Requirements • Chapter 3–19I
Juniper Networks Design Fundamentals
Validating the Data
The exhibit on the slide is a simple example of the validation process when developing a network design for your customer. 
You begin by collecting the data from your customer. There likely will be a lot of data to examine and decipher, so the 
question must be asked, Do I understand what is needed? If the answer is no, then you will need to refer back to the 
customer and ask more questions and collect more data. 
This cycle continues until you feel like you do understand what the customer is asking for. You should then determine, Do I 
know how I can help? If the answer is yes, assemble your team of subject matter experts and begin planning your proposal. 
If you don’t know how you can help, you will need to consult with the subject matter experts that will help you answer 
questions and help you with a design. In every case where you do not feel comfortable with a certain concept, you must not 
only consult with individuals who are experts, but truly become the expert yourself. There are not many issues that only come 
up once. Become an expert and you will put yourself ahead of the crowd on future projects.
In many cases, after you validate the data and consult with your team, new questions might arise where you must refer back 
to the customer. At this point, you should ask yourself, Do I need more information? If the answer is yes, then you will again 
find yourself cycling through customer data to fill in the blanks for your RFP response. 
Once you have all the information you need and are your proposal is ready, you can respond to the RFP. We focus on the 
important details of this process on the next few slides.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 3–20 • Understanding Customer Requirements www.juniper.netI
Juniper Networks Design Fundamentals
Designing Greenfield Projects
Most design projects involve some sort of upgrade to the existing environment; however, sometimes you’ll get to design a 
network from the ground up. These types of design projects are sometimes referred to as greenfield projects. Greenfield 
projects typically have very little existing equipment or restraints to consider in the design plan. Ideally, a fully optimized 
next-generation network would be designed in greenfield conditions. With that in mind, even greenfield designs will have 
restraints to consider. For example, you might be asked to maximize a network’s potential while dealing with infrastructural 
limitations, such as inadequate server room space or poor rack cooling conditions. Perhaps wiring an older office space for 
wired desktop connections would be cost prohibitive. Be aware of these limitations when formulatingyour responses.
Upgrading Existing Network
Upgrading a customer’s network is the more common approach in network design. There are many factors that contribute to 
a customer’s decision to upgrade rather than complete replace a network. Those factors include timing, training, and cost. 
Certainly, if a customer’s network was designed with modularity in mind the first time, you should be able to add the new 
requests to the existing network without much disruption. In some cases, the customer is happy with the network design but 
the equipment needs to be replaced. Perhaps you must cope with a design that is completely obsolete and must be 
replaced. 
It will be your job to determine the best approach in your response to the customer when bidding for the job, taking into 
consideration all of the data analysis factors that we have described in this content.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Understanding Customer Requirements • Chapter 3–21I
Juniper Networks Design Fundamentals
Creating Equipment Lists
As you assemble the proposal for your customer, you will need to include an equipment list, sometimes referred to as the Bill 
of Materials (BOM) that includes equipment and sub-components needed to create the network design. Depending on the 
complexity of the design, the BOM might be a simple list of equipment needed to complete the proposal, while a more 
complex BOM might be modular—where equipment, services, and cost are broken down and associated with design 
functionality. More complex BOMs can be multi-level—or nested—list s whose parent devices are listed with a set of child 
devices nested in two or more levels of detail. Modular and multi-level BOMs work well when you are sharing your design 
requires a set of requirements that are used for multiple customers or partners.
Understanding the Budget when Setting Price
Hopefully, the customer has clearly specified the budget that you are to work with. It’s important that you understand the 
budget you are working with as you develop your proposal. We all would love to own a fast sports car, but more often than 
not, we have to opt for the car we can afford and save the sports car for a time when we have the money. Some people will 
never be able to afford a sports car, and frankly, they’ll be just fine owning a nice, less expensive sedan. Your job is to come 
up with a design that matches the customer’s needs and budget. Consider that the budget might change over time, so keep 
constant communication with the customer as you work on their design. Consider other costs associated with your design, 
such as additional staffing, as well as testing and training on the new equipment. Do not overlook the possibility that your 
design will either eliminate jobs or require additional headcount. Communicate the possibility of these factors to the 
customer so they can provide further instruction if these additional factors can be figured into the proposal.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 3–22 • Understanding Customer Requirements www.juniper.netI
Juniper Networks Design Fundamentals
We Discussed:
• Analyzing and interpreting common RFP requirements; and
• Scoping a network design by gathering data and working with key stakeholders.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Understanding Customer Requirements • Chapter 3–23I
Juniper Networks Design Fundamentals
Review Questions
1.
2.
3.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 3–24 • Understanding Customer Requirements www.juniper.netI
Juniper Networks Design Fundamentals
Lab: Understanding Customer Requirements
The slide provides the objectives for this lab.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Understanding Customer Requirements • Chapter 3–25I
Juniper Networks Design Fundamentals
Answers to Review Questions
1.
When responding to the RFP, you should always follow the customer’s requested format to demonstrate that you understand what the 
customer is asking and keep yourself in contention when competing with other vendors.
2.
Questionnaires, surveys, interviews, job aids, a list of applications, and a traffic flow analysis are all examples of data you should collect 
from the customer when determining the scope of the design.
3.
Budget, the elimination of jobs, corporate politics and existing infrastructure are all factors that can accept the customer’s acceptance of 
your design plan.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 3–26 • Understanding Customer Requirements www.juniper.netI
HA
RE
Juniper Networks Design Fundamentals
Chapter 4: Organizing the Data
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
S
IN
T
Juniper Networks Design Fundamentals
We Will Discuss:
• Ways of processing customer data and requests;
• Boundaries and scope for the design proposal; and
• Considerations when creating a design proposal.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 4–2 • Organizing the Data www.juniper.netI
Juniper Networks Design Fundamentals
Processing the Data and Requests
The slide highlights the topics we will discuss. We discuss the highlighted topic first.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Organizing the Data • Chapter 4–3I
Juniper Networks Design Fundamentals
Plan Methodology: Data Analysis
The slide is a review of the idealogical flow behind planning a network design for a customer. We focus on data analysis in 
this content.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 4–4 • Organizing the Data www.juniper.netI
Juniper Networks Design Fundamentals
Plan: Organizing the Data
The slide depicts the typical flow that you might follow when planning the initial design. Assuming you have collected all of 
the data you require from the customer, you will have a lot of information to organize! The data you have collected can be 
sorted into three main categories—customer data, customer requirements, and project boundaries. We discussed the types 
of data you collect from the customer in the last chapter. We discuss customer requirements and project boundaries in the 
next several slides. 
Once you have successfully sorted, organized, and processed the data, you should have a good idea as to what the design 
should look like. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Organizing the Data • Chapter 4–5I
Juniper Networks Design Fundamentals
Data Analysis
You can typically take the customer data, as well as customer requirements, and organize them into the six main categories 
shown on the slide. The customer requirements will typically be based on a few key focus areas, such as functional areas 
and user groups. We discuss some of the more common customer requirements on the next several slides.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 4–6 • Organizing the Data www.juniper.netI
Juniper Networks Design Fundamentals
Sample Security Requirements
The slide lists some sample security requirements. Can you think of Juniper Networks solutions that could fulfill these 
requirements? List them in the space below.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Organizing the Data • Chapter 4–7I
Juniper Networks Design Fundamentals
Sample Availability Requirements
The slide lists some sample availability requirements. Can you think of Juniper Networks solutions that could fulfill these 
requirements? List them in the space below.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 4–8 • Organizing the Data www.juniper.netI
Juniper Networks Design Fundamentals
Sample Scalability Requirements
he slide lists some sample scalability requirements. Can you think of Juniper Networks solutions that could fulfill these 
requirements? List them in the space below.
NT
ER
NA
L 
US
E 
ON
LY
 —
 DO 
NO
T 
SH
AR
E
www.juniper.net Organizing the Data • Chapter 4–9I
Juniper Networks Design Fundamentals
Sample Manageability Requirements
he slide lists some sample manageability requirements. Can you think of Juniper Networks solutions that could fulfill these 
requirements? List them in the space below.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 4–10 • Organizing the Data www.juniper.netI
Juniper Networks Design Fundamentals
Sample Performance Requirements
he slide lists some sample Performance requirements. Can you think of Juniper Networks solutions that could fulfill these 
requirements? List them in the space below.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Organizing the Data • Chapter 4–11I
Juniper Networks Design Fundamentals
Identifying Boundaries and Scope
The slide highlights the topic we discuss next.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 4–12 • Organizing the Data www.juniper.netI
Juniper Networks Design Fundamentals
Identifying Design Proposal Boundaries
One of the steps to organizing the data will be to detect the boundaries that exist. In other words, you need to determine 
aspects of the customer requirements that will limit or alter the final result of your design. Some of the more common 
boundaries include:
• Characterizing existing and future user groups, their respective applications, data flows, and data flow types.
• Identifying required network parts such as campus, WAN, remote office locations, and the data center.
• Documenting the current environment, if one exists, so you know which elements must stay and which ones 
can change.
• Determining budgetary constraints. Estimated cost will also impose some design boundaries —in other words, 
you’re not going to propose a solution that far exceeds the customer’s budget.
• Identifying the unknown boundaries that exist. These types of boundaries might include hidden agendas from 
employees within the company, governmental laws or statutes that were not previously identified, or even 
limitations on the existing physical media that is in place. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Organizing the Data • Chapter 4–13I
Juniper Networks Design Fundamentals
Greenfield Deployments
Most design architects will state that greenfield deployments are preferred over brownfield deployments. Designing in a 
greenfield is like painting on a blank canvas. You have the opportunity to create the right design completely from the ground 
up. You have a better opportunity to make the design modular—we discuss modularity later in this content. Greenfield 
deployments are rare because most customers already have some networking component in place. Even when dealing with 
expansion to a new branch location or data center, the customer likely will have a network in place at the main campus. 
Brownfield Deployments
Brownfield deployments are much more common than greenfield deployments. As we noted above, unless you are working 
with a start-up company with no network in place, you will be dealing with some type of existing network environment. 
Brownfield environments can present challenges in your design. You’ll need to consider all aspects of the existing 
environment, such as building design, the layout of the existing physical media, network devices from other vendors, as well 
as any proprietary protocols they might be using.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 4–14 • Organizing the Data www.juniper.netI
Juniper Networks Design Fundamentals
User Groups and Applications
As you organize the data from the customer, you will need to determine the types of users that will be accessing the network 
and what applications they use. The various user groups that access the network might impose certain restrictions on your 
design. For example, if a customer only allows certain groups of users to access sensitive parts of the network, you’ll need to 
create a design where security is configured to enforce their desired policies. Enforcing security whilst maintaining 
accessibility, ease of use, and performance benchmarks will be a top priority.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Organizing the Data • Chapter 4–15I
Juniper Networks Design Fundamentals
Considering Data Flow
While IT administrators will likely outline the importance of network security as a part of their network requirements, most 
employees of the customer will likely emphasize the importance of speed and ease of access when connecting to resources. 
Security, speed, and simplicity become more critical as resources are opened up across WAN connections (in other words, 
remote offices, home users, off-site date connections all can impact data flow in one way or another.)
You must identify the types of communication that happen—or will happen—on the network. You can use flow analysis tools 
to determine the types of communication that occur on the network. These types of traffic patterns might include user to 
user, user to machine, and machine to machine communication. Determining the traffic patterns currently in use—as well as 
calculating the data flow for the future network—will allow you to create a successful network design.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 4–16 • Organizing the Data www.juniper.netI
Juniper Networks Design Fundamentals
Functional Parts of the Network
We have discussed the three main functional areas in network design, including campus (and branch), WAN, and data center 
connections. Boundaries surrounding these functional areas might include those noted on the slide.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Organizing the Data • Chapter 4–17I
Juniper Networks Design Fundamentals
Exceeding Known Boundaries
Although you might feel that your design is restricted by the identified boundaries set by the customer, you should still seek 
to exceed those boundaries. As a representative for Juniper Networks, your goal should be to create a design that not only 
meets the customer’s requirements, but exceeds their expectations. Seek out where Juniper Networks can make a notable 
difference and present those elements as benefits to your design.
Provide Options
In many cases, you might discover multiple solutions that can meet the customers needs. Often, the differentiating factor to 
these solutions is cost. For example, the best solution might also be the most expensive solution. Providing the customer 
with multiple options—such as good, better, best—can keep you in the forefront when the customer is considering multiple 
vendors. If the customer likes yours “good” solution because it is within budget, it might be easier for the customer to come 
up with the additional funding to go with the “best” option.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 4–18 • Organizing the Data www.juniper.netI
Juniper Networks Design Fundamentals
Design Proposal Considerations
The slide highlights the topic we discuss next.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Organizing the Data • Chapter 4–19I
Juniper Networks Design Fundamentals
Design Proposal Considerations
As you create your design proposal, you will need to keep the tips listed on the slide in mind. These tips will not only help you 
keep your proposal in consideration with the customer, they can also help position your proposal above the others. You’ve 
spent a lot of time collecting data from the customer and organizing it into a proposal you believe in. Now is the time to pay 
attention to the details so ensure your customer actually pays attention to your proposal!
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 4–20 • Organizing the Data www.juniper.netI
Juniper Networks Design Fundamentals
Keeping Things Simple
Keep the customer in mind at alltimes as you create your design. Some designs can be so complicated that they will not only 
be difficult to implement, they will be difficult for the customer to comprehend. Document your design well and keep it 
simple for the customer to understand. You might believe that your design is the customer’s best option, but if the document 
is difficult to read, the customer might perceive that the design is too complicated. Some customers will equate a 
complicated design as being too time consuming and too expensive to implement.
Modularity in Network Design
Designing a network with modularity in mind should always be a top consideration when writing your proposal. Modularity 
provides better network structure, easier troubleshooting, and will more easily facilitate future growth. Modularity also will 
provide a hierarchical structure to your network design, with each “module” serving a specific purpose.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Organizing the Data • Chapter 4–21I
Juniper Networks Design Fundamentals
Logical Before Physical Design
A section of your design proposal will be dedicated to the network topology. In simple terms, the network topology is like a 
drawing of what your network design will look like. In reality, even the simplest design projects have some level of complexity 
to them. Simplify your design for the customer by first Including a logical diagram of your network, followed by a physical 
diagram of the network. Both diagrams are important and should be included in your documentation.
When creating your design, consider using what is often called a “top-down” design methodology. The top-down methodology 
follows the OSI model, as shown on the slide. A “bottom up” methodology would simply identify cables or hardware that can 
be used to “patch” or provide a quick fix to a network problem; however, most “bottom up” resolutions fail to completely 
solve the true problem the customer faces because they are usually intended as a temporary fix to that problem. 
Top-down design is different. Top down design takes into consideration the customer data you collected, as well as their 
documented requirements and known boundaries, and uses that information to create a logical design first. As you move 
from the top of the OSI model down, you can identify the protocols and stability requirements, followed by networking devices 
and physical media that you will use. Top-down design is ideal, as it allows for better scalability and modularity. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 4–22 • Organizing the Data www.juniper.netI
Juniper Networks Design Fundamentals
Incorporating Security
Incorporating security into your design is a necessity. Every functional area of your network topology will require some level of 
security within it. The slide highlights some of the key focus areas as you plan for security in your design.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Organizing the Data • Chapter 4–23I
Juniper Networks Design Fundamentals
Choices and Trade-offs
As you select the topologies and equipment that will be used to form your network design, you should be aware that each 
choice you make will include certain trade-offs. For example, implementing security can affect performance. Taking steps to 
improve performance might affect security. The categories shown on the slide can be easily interchangeable as both choices 
and trade-offs. The following are some specific examples of choices you could make that have trade-offs associated with 
them:
• Distributing corporate applications through a public store, such as Apple iTunes or Google Android Market 
requires increased security measures;
• Using low speed links and high over-subscription ratios in the LAN (thus decreasing the available bandwidth), 
will impact network performance and consequently result in a poor user experience, which can then negatively 
influence the adoption of collaboration tools; and
• Network complexity at an enterprise campus causes reliability issues throughout the network as it becomes 
difficult to support seamless connectivity and growing bandwidth requirements through the lifespan of the 
network. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 4–24 • Organizing the Data www.juniper.netI
Juniper Networks Design Fundamentals
Capacity Planning
Your design should also include capacity planning. The following are general guidelines when planning for capacity:
1. Form a discussion group. The group needs wide representation from the customer. The group should be used to 
elicit what network uses are found to be acceptable and unacceptable.
2. Quantify user behavior. Determine the population and location of all users. Create a summary of major user 
groups, as well as the applications they use.
3. Quantify Application behavior. Identify the applications that can affect performance, the location and 
performance of the identified servers and client devices. Determine key constraints on performance.
4. Determine the baseline existing network. Baselining the network involves creating a behavioral profile of the 
network using packet traces, transaction rates, event logs, and statistics. Identify router Access Control Lists, 
(ACLs) and firewall rules.
5. Make Traffic projections. Capture data for a stable working network with details of bandwidth utilization by 
packet type and protocol, packet and frame size distribution, background error rates, and collision rates.
6. Summarize the input data for the design process. Consider budget, database of all sites, user populations, key 
applications and their behavior.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Organizing the Data • Chapter 4–25I
Juniper Networks Design Fundamentals
Design Stages: Design Specification
A good network design proposal will include excellent documentation. The documentation will serve as a benchmark for 
design changes, as changes most certainly will occur throughout the life of the network design process. The design 
documentation should include finalized design choices and changes, as well as their justification. The document might 
change from the time it is drafted to its final state, so be sure to include a change log that documents those changes for 
future maintenance purposes. The document will be used for the implementation of the network, so be sure that the 
document is clear and easy to follow.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 4–26 • Organizing the Data www.juniper.netI
Juniper Networks Design Fundamentals
We Discussed:
• Ways of processing customer data and requests;
• Boundaries and scope for the design proposal; and
• Considerations when creating a design proposal.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Organizing the Data • Chapter 4–27I
Juniper Networks Design Fundamentals
Review Questions
1.
2.
3.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 4–28 • Organizing the Data www.juniper.netI
Juniper Networks Design Fundamentals
Answers to Review Questions
1.
The six baseline customer requirements to which data can be organized include security, availability, scalability, manageability, 
performance, an budget.
2.
Identifying the customer’s boundaries will help you understand where to focus your network design and determine where you can 
provide value by meeting, of not exceeding the requirements the customer has set forth.
3.
Top-down network design allows you to design a network that is scalable, modular, and easier to implement.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Organizing the Data • Chapter 4–29I
Juniper Networks Design Fundamentals
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 4–30 • Organizing the Data www.juniper.netI
HA
RE
Juniper Networks Design Fundamentals
Chapter 5: Securingthe Network
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
S
IN
T
Juniper Networks Design Fundamentals
We Will Discuss:
• An overview of network security and common vulnerabilities; and
• High-level design considerations and best practices for securing the network.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 5–2 • Securing the Network www.juniper.netI
Juniper Networks Design Fundamentals
Why Secure the Network?
The slide lists the topics we will discuss. We discuss the highlighted topic first.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Securing the Network • Chapter 5–3I
Juniper Networks Design Fundamentals
The Network Security Problem
The Internet allows an attacker to reach your network from anywhere in the world. Furthermore, an attacker only has to find 
one vulnerability but you have to account for all the vulnerabilities when planning, building, and operating the network.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 5–4 • Securing the Network www.juniper.netI
Juniper Networks Design Fundamentals
Security Threats Facing Networks Today
The network today faces a multitude of security threats—from viruses, trojans, and worms infecting machines with Internet 
access, to hackers and spies trying to steal intellectual property. Any of these threats might apply to WAN, campus, branch, 
or data center networks. That said, security requirements exist for each type of network. We discuss these in subsequent 
slides.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Securing the Network • Chapter 5–5I
Juniper Networks Design Fundamentals
Evolution of Network Security: Part 1
Not too long ago, a typical managed network had defined boundaries and edges. Network security was rather simple, 
involving mainly a firewall at the head of the network, some basic user management (credentials, permissions, etc.), and, 
perhaps, a mandated anti-virus application. Everything was considered managed and a bring-your-own-device (BYOD) 
mentality wasn’t even an option.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 5–6 • Securing the Network www.juniper.netI
Juniper Networks Design Fundamentals
Evolution of Network Security: Part 2
Fast-forward to a typical modern network and it is markedly different. Not only are there many more managed devices on the 
network such as VoIP phones, audio and video conferencing, smartphones, and tablets, there can now be numerous 
unmanaged devices. Additionally, remote employees and remote locations now connect back to the main network through 
VPNs. In such a network, security is tougher to implement as there is much more risk involved. Some of these risks include:
• Remote access adds another attack vector.
• Wireless device use is trending up and these types of connections need to be made secure.
• An anti-virus policy is extremely difficult to implement across all devices, especially mobile. Moreover, users 
managing their own devices might not be aware if they’re infected.
• Virtual servers present a new type of vector to accommodate.
• External storage devices, such as external hard drives and USB sticks, present yet another attack vector that is 
hard to combat. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Securing the Network • Chapter 5–7I
Juniper Networks Design Fundamentals
Assessing Security in Network Design
We discussed in previous chapters that the first step in designing—or planning—the network is to “assess”. Assessing the 
customer’s network includes understanding customer requirements, determining scope of the project, and analyzing the 
data the customer has provided. 
Security should be a top consideration in network design, even early on in the “assess” phase. The slide highlights several 
key security factors that you should identify and understand before proceeding with your network design.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 5–8 • Securing the Network www.juniper.netI
Juniper Networks Design Fundamentals
Security Design Considerations
The slide highlights the topic we discuss next.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Securing the Network • Chapter 5–9I
Juniper Networks Design Fundamentals
Typical Security Concerns
Juniper Networks recently sponsored a a survey on the efficacy of emerging network security technologies. The purpose of 
the survey was to understand organizational viewpoints on emerging network security technologies and their ability to 
address serious security threats. 
The figure on the slide indicates the most important factors in network design that security features should address. As a 
network designer, you have the responsibility of understanding how your design will help address these concerns.
Take into consideration, for example, the security factor with the highest rating of concern for organizations—increasing 
visibility to web traffic. Given the indication that 78% of organizations surveyed believe visibility to web traffic is important, it 
is likely that this factor will be a requirement in your design. How will your design address Web visibility? Does Juniper 
Networks provide a solution to this problem? The answer, of course, is yes! Juniper Network’s Security Intelligence solution 
can address web visibility. We discuss Security Intelligence in more detail later in this content. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 5–10 • Securing the Network www.juniper.netI
Juniper Networks Design Fundamentals
Security Effectiveness
The slide highlights another figure from the survey mentioned on the previous slide. Ogranizations were also questions on 
the effectiveness of Next Generation Firewalls (NGFWs). While most NGFWs are thought of as effective at intrusion 
prevention and security policies, the same devices are not as effective at Virtual Private Network (VPN) and URL content 
filtering features, according to the survey. Understanding your customer’s concerns will be important as you plan out what 
features to implement in your customer’s network. Other factors to consider will be complexity in configuration and daily 
maintenance. We discuss NGFW solutions in more detail later in this chapter. 
For more information on the survey referenced in the slide, see 
http://www.juniper.net/assets/us/en/local/pdf/additional-resources/ponemon-jnpr-network-security-report.pdf.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Securing the Network • Chapter 5–11I
Juniper Networks Design Fundamentals
Security is Everywhere!
As we noted previously, network security should be designed into the network from the very beginning and not bolted on as 
an afterthought. The slide illustrates many common points in the network where security should be implemented. As the 
network designer, you must understand the scope of the design, the information collected from the data analysis, and what 
offerings Juniper Networks can provide to meet all customer requirements.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 5–12 • Securing the Network www.juniper.netI
Juniper Networks Design Fundamentals
The Evolution of the Firewall
The slide depicts how firewalls have evolved over the last several years. The traditional firewall started out with basic packet 
filtering capabilities and evolved to include dynamic routing and “stateful” session filtering. Stateful firewalls started to 
include layer 3-7 protection, including Application Layer Gateways (ALGs), integrated Intrusion Detection and Protection (IDP), 
as well as anti-virus, email, and spam protection. The inclusion of these solutions resulted in what is now known as an 
NGFW. While the NGFW provides many security benefits, many of the main security benefits are static in nature and do not 
always adjust dynamically to the changes that occur in the network over time. 
Customerstoday demand an intelligent firewall—a firewall that can adapt to the most sophisticated threats and take 
immediate action based on both known and emerging intelligence. Juniper networks offers a complete portfolio of scalable 
security solutions that protect customers from the most serious threats. We highlight these solutions in the next few slides. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Securing the Network • Chapter 5–13I
Juniper Networks Design Fundamentals
SRX Series Devices
We discussed SRX Series devices previously in the course. In addition to supporting the traditional and NGFW features 
shown on the slide, SRX Series devices are also the enforcement points for Juniper’s security intelligence solution. The SRX 
device allows for scalable security by enabling security intelligence in SRX Series security policies, high threat data capacity 
by supporting over a million custom feed entries, and effective protection by enforcing only the most relevant intelligence, 
which ensures rapid enforcement while reducing false positives. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 5–14 • Securing the Network www.juniper.netI
Juniper Networks Design Fundamentals
Sample Placement of Security Devices
This slide provides a visual representation of the many SRX Series options provided by Juniper networks along with some 
general idea of where you might position the different switching models in the branch, campus, and data center 
environments. Not all devices can support security intelligence, as noted on the slide. Note that this illustration is only meant 
as a generalized positioning for products shown and is not exact or definitive by any means. As per usual with network design 
and product placement, there is always some flexibility and, in all cases, is dictated by customer needs. While this might be 
a reasonably good starting point, you should take a closer look at the product’s scaling details, hardware options, and 
software feature set to ensure you are recommending the right product and solution for the customer’s environment.
For more details on the on these devices, please refer to the following URL:
SRX Series devices: http://www.juniper.net/us/en/products-services/security/srx-series/
vSRX: http://www.juniper.net/us/en/products-services/security/firefly-perimeter/
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Securing the Network • Chapter 5–15I
Juniper Networks Design Fundamentals
Junos Space Security Director
Junos Space is a next-generation network application platform designed to manage and orchestrate next-generation 
networks. The platform is an open, extensible network application platform that simplifies common enterprise management 
system (EMS) functionality and management, and provides modularity, scalability, and usability. The Junos Space platform 
opens the network to new business opportunities by developing and hosting applications that simplify network operations, 
scale network services, and automate support.
Junos Space Security Director delivers a scalable and responsive network security management application that improves 
the reach, ease, and accuracy of policy administration. Security Director helps administrators more quickly and intuitively 
manage all phases of the security policy lifecycle through one centralized Web-based interface. Security Director includes 
powerful network security features such as application identification control with application signatures, as well as UTM, IPS, 
Network Address Translation (NAT), and VPN security policy management.
Security Director enables administrators to utilize extensive policy control capability. This capability includes managing 
network security policy horizontally across multiple SRX Series devices, and also vertically to manage logical systems (LSYS) 
instances. Security Director improves network security policy consistency and compliance, even as networks scale. It also 
speeds and simplifies security administration, and reduces management costs and errors with efficient network security 
policy and workflow tools.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 5–16 • Securing the Network www.juniper.netI
Juniper Networks Design Fundamentals
Junos Space Applications
Junos Space supports additional applications beyond Junos Space Security Director. Those applications are noted on the 
slide. These applications implement workflows that allow you to simplify network operations, scale services, automate 
support, and open the network to new business opportunities:
• Network Management Platform: Provides tools that enable automated device discovery and management, job 
operation management, audit logging, and network administration.
• Service Now and Service Insight: Provide detection, isolation, and resolution of network faults and incidents. 
These components also help in accelerating operational analysis and managing the exposure to known issues.
• Network Director: Simplifies Ethernet switch deployments and provides rapid operation of campus and data 
center networks. Network Director also provides virtual control, which is the ability to manage virtual server 
deployments.
• Security Director: Delivers a scalable and responsive security management application that improves the reach, 
ease, and accuracy of policy administration. It helps administrators more quickly and intuitively manage all 
phases of a security policy life cycle through one centralized Web-based interface.
• Services Activation Director: Includes the applications Network Activate, Transport Activate, QoS Design, Sync 
Design, and Operation, Administration, and Maintenance (OAM) insight. 
As noted on the slide, Security Director, Network Director, and Services Activation Director require additional licensing. The 
Service Now and Service Insight applications are included with the Network Management platform, but require a valid 
support contract to function.NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Securing the Network • Chapter 5–17I
Juniper Networks Design Fundamentals
Security Technologies and Threat Intelligence
NGFWs, such as SRX devices, include integrated capabilities, including IDP and antivirus signatures. However, even the SRX 
device, on it’s own, can not take full advantage of the highly diverse third-party and custom feeds utilized by customers that 
are specific to their industry. Security intelligence fills the needs that NGFWs, on their own, can’t provide. The slide depicts 
multiple Juniper security technologies working together to provide an intelligent solution to threat management. 
When security devices work in conjunction with Spotlight Secure, Juniper Network’s Threat Intelligence solution, to address 
the challenges and constraints by aggregating threat feeds from multiple sources to deliver open, consolidated, actionable 
intelligence to SRX Series devices across the organization. Sources include threat feeds from Juniper Networks’ own 
cloud-based service, third-party threat feeds, and threat detection technologies that a customer can deploy. The security 
intelligence service extracts relevant multi-threat feeds and delivers them to SRX Series firewalls for advanced threat 
protection. Spotlight Secure Connector is a virtual machine that serves as a hub linking the management functions provided 
by Security Director with the Spotlight Secure “cloud”, as well as the SRX firewalls protecting customer assets.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 5–18 • Securing the Network www.juniper.netI
Juniper Networks Design Fundamentals
Spotlight Secure Threat Intelligence Platform
The slide highlights the steps involved in how Spotlight Secure operates:
1. Spotlight Secure, operating in the cloud, collects aggregated and optimized threat intelligence.
2. Spotlight Secure delivers threat intelligence on known threats to thecustomer’s Spotlight Secure Connector.
3. Local customer data is aggregated into the solution.
4. The information gathered is centrally managed by Junos Space Security Director.
5. The intelligence collected is then distributed to SRX enforcement points. Enforcement actions include 
discarding or redirecting network traffic that is identified as a threat. All threat events are then logged by Log 
Director.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Securing the Network • Chapter 5–19I
Juniper Networks Design Fundamentals
Juniper Networks Secure Analytics
Another important security Solution that Juniper Networks provides is the Juniper Networks Secure Analytics (JSA). The JSA 
Series device addresses the needs of network security management by combining, analyzing, and managing an incomparable 
set of surveillance data to empower companies to efficiently manage business operations on their network from a single 
Web-based console. The JSA device offers multiple network security management features, including but not limited to the 
following:
• Comprehensive log management and reporting: Scalable and secure log management with storage capabilities 
from gigabytes to terabytes of data storage;
• Threat detection: The ability to analyze the right threats at the right time;
• Compliance reporting: Over 1300 report templates allow you to customize and schedule daily, weekly and 
monthly reports; and
• Log retention and storage: You can easily archive logs and integrate into an existing storage infrastructure for 
long-term log retention and hands-on storage.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 5–20 • Securing the Network www.juniper.netI
Juniper Networks Design Fundamentals
i
JSA Series Devices: Sample Placement
The slide shows the JSA Series products. EC stands for Event Collector and FC stands for Flow Collector. Note that all appliances, 
including the JSA VM, can be deployed as all-in-one solutions or distributed systems.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Securing the Network • Chapter 5–21I
Juniper Networks Design Fundamentals
We Discussed:
• An overview of network security and common vulnerabilities; and
• High-level design considerations and best practices for securing the network.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 5–22 • Securing the Network www.juniper.netI
Juniper Networks Design Fundamentals
Review Questions
1.
2.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Securing the Network • Chapter 5–23I
Juniper Networks Design Fundamentals
Answers to Review Questions
1.
The network today faces a multitude of security threats—from viruses, trojans, and worms infecting machines with Internet access, to 
hackers and spies trying to steal intellectual property.
2.
Security Intelligence provides dynamic intelligence on security information about attackers and attacks, which provides the customer 
with more accurate information and protection against the most common threats facing a network.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 5–24 • Securing the Network www.juniper.netI
HA
RE
Juniper Networks Design Fundamentals
Chapter 6: Creating the Design—Campus
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
S
IN
T
Juniper Networks Design Fundamentals
We Will Discuss:
• Components of the campus network;
• Best practices and consideration for the campus; and
• Architectural design options for the campus.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–2 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
The Campus Network: An Overview 
The slide lists the topics we will discuss. We discuss the highlighted topic first.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–3I
Juniper Networks Design Fundamentals
Defining the Campus
Campus networks come in all shapes and sizes. A campus is often a corporate headquarters or a main company site. A 
campus could be a sprawling university with many buildings, several buildings in an office complex, or a multi-floor building. 
All buildings and floors are connected to shared resources in a data center, which might or might not be part of the campus. 
The campus could also be connected to other campuses, the Internet, regional sites, or branch locations through a WAN 
connection. 
The location of the buildings, users, and devices in a campus network will be important factors in deciding both the physical 
topology and the link types that you should use as you design the campus network. Connections to off-campus resources 
such as data centers and branch offices also must be considered.
The modern day campus network has moved beyond supporting traditional client/server based traffic to supporting 
real-time application traffic such as voice over IP (VoIP), video conferencing, and other unified communications (UC) tools, 
while at the same time accommodating an increasing number of users and devices. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–4 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
Campus Topologies
The modern campus can be further described as falling within five topologies: 
• A horizontal topology of low to medium density such as a small office building with only a few floors and perhaps 
1–4 wiring closets per floor. 
• A vertical topology will have a higher density of users with multiple points of access such as in a multi-floor 
building. 
• A metro campus is essentially a group of buildings located in close proximity to each other connected with fiber. 
• The user density is usually lower in a metro campus, whereas a widely distributed campus, which will have 
multiple types of buildings (such as horizontal, vertical, and metro) spread out over a wider geographic area and 
connected through a LAN or WAN. User density will vary.
• Finally, a hub and satellite topology would be one or two campuses or data centers connected to several smaller 
branch offices. The main site would typically have a higher user density while the branch sites would have a 
lower user density.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–5I
Juniper Networks Design Fundamentals
Legacy 3-Tier Design
The slide shows what a legacy 3-tier network looks like: needlessly complex, inefficient, and costly. The 3-tier design 
approach was used because of oversubscribed interfaces. A large number of devices requires additional links, which means 
even more devices to purchase, maintain, and manage. 
Key campus network requirements include: keeping downtime to a minimum, reducing complexity, and lowering costs. 
Legacy 3-tier architecture cannot meet these key requirements. We must think differently about network design. The design 
must scale to accommodate emerging trends and services without a wholesale redesign, which does not mean just adding 
more devices to the network. Other vendors take that approach. They sell more product to try to solve an issue, but they also 
increase complexity. As complexity increases, the network is more likely to break, and costs will continue to rise. 
However, if we make the network more reliable and simple to manage, the IT staff can focus on rolling out new deployments 
and maintaining the network, making better use of their time and effort. Throughout this course we look at an approach 
toward simplification and lowering overall costs while increasing performance and reliability. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–6 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
Evolution of the Campus: Today and Beyond
Although some servers might still be kept on the premises, enterprises are consolidating applicationsand data centers to 
simplify the network and reduce costs. The network must also accommodate an increasing number of users, devices, and 
services while protecting them from an increasing number of threats. Access to other parts of the network such as data 
centers, other campuses or branch offices, or other shared resources and services, is typically provided through a campus 
LAN or WAN connection. However, all applications might not run in the cloud or in data centers. Campuses might still have 
on-premise servers and a need for a demilitarized zone (DMZ) to isolate these servers from the rest of the network. As 
security issues increase, providing traffic isolation between devices becomes necessary. The need for security, DMZs, virtual 
LANs (VLANs), and segmentation are critical concerns in today's campus network.
Network traffic has also increased with the growing use of new technologies such as UC. Today, instead of a user sitting at 
their desktop PC accessing information on a local server, users with a wide variety of wired and wireless devices are 
accessing a variety of information and services inside and outside the network. Users might connect to each other across 
the LAN or WAN through instant messaging, IP phones, wireless laptops, or teleconferencing. Users need connectivity to 
remote resources and the Internet. Security cameras have also joined the array of networked devices. The legacy campus 
was not built to handle this explosion of devices and services.
Although campus network design can sometimes be a complex task, a design can be successfully achieved by following 
fundamental principles and guidelines. We examine some of the fundamental principles and guidelines throughout this 
chapter. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–7I
Juniper Networks Design Fundamentals
Consolidating Security
The first step in the campus evolution has been to consolidate security. Most design architects now use an approach which 
eliminates a large number of small, single-function security devices by consolidating their functions into larger, 
centrally-deployed devices. Device consolidation improves efficiency by lowering latency and reducing the number of device 
connections. Fewer devices also means lower power, cooling, and space costs. Security consolidation shifts away from 
security embedded in the network to virtualizing security onto a minimum number of devices and offering it as a service into 
the network.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–8 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
Collapsing Layers 
The next step in the network design evolution has been to virtualize the access layer. With Juniper Networks’ Virtual Chassis 
technology, you can connect up to ten switches to create a single logical device that behaves, and is managed as, a single 
switch. Virtual Chassis technology simplifies operations by reducing the number of switches to manage by a factor of up to 
10. 
Next we collapse the core and aggregation layers, further flattening the network. We eliminate a layer of latency, thus 
improving overall performance. We reduce the number of devices to manage, simplifying operations. Collapsing the core and 
aggregation layers also reduces the number of uplinks, which simplifies cabling requirements. Fewer devices also means 
reduced capital equipment costs, as well as lower power, space, and cooling costs.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–9I
Juniper Networks Design Fundamentals
Best Practices and Considerations 
The slide highlights the topic we discuss next.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–10 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
Design Guidelines for the Campus 
A number of design guidelines and considerations exist to help ensure the campus LAN is secure, highly available, and easy 
to deploy and operate. The guidelines and considerations which focus on securing the campus LAN and ensuring it is 
available are covered in other chapters in this course. The content in this section specifically focuses on the guidelines and 
considerations that ensure the campus design is easy to deploy and operate. 
The slide illustrates a number of guidelines that ensure the campus design is easy to deploy and operate. We cover some of 
these guidelines in more detail on subsequent slides in this section. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–11I
Juniper Networks Design Fundamentals
Making the Design Modular 
Today’s campus networks are increasing in size and, in some cases, complexity. To scale a campus network and to simplify 
moves, adds, and changes, you must make the network’s design modular. 
Incorporating modularity into a network’s design reduces the amount of data individual devices must process as well as the 
amount of information you must deal with when designing, deploying, managing, and troubleshooting the network. In other 
words, making your network design modular should simplify life and put a smile on your face. 
In a modular design, you have devices with clearly assigned functions. For example, in the illustration on the slide we have 
access switches bundled together in a Virtual Chassis in a given wiring closet, on a given floor, in a given building, that 
provide access to a given set of users or devices. While the other Virtual Chassis’ illustrated on the slide perform a similar 
function, they service a different set of users and devices in a different location. Since all Virtual Chassis in the access layer 
perform the same basic function, they can be designed and implemented in a similar fashion using a similar configuration, 
thus making this modularized element repeatable and familiar to the individuals responsible for designing the structure and 
managing the resulting environment. A similar approach is used for the core layer with individual chassis-based systems or 
Virtual Chassis deployments. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–12 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
Knowing the Trends and Requirements 
Determining the number of wired and wireless ports requires evaluating the typical user profile. The slide shows that the 
current trends are moving toward less wired ports overall (at least to each desk) and toward an increase in wireless ports. 
The increase in wireless connections stresses the importance of a solid wireless network foundation.
With the proliferation of wireless laptops, smart phones, and tablets, the number of wired and wireless connections per 
person is increasing. The need for this many connections puts increased demands on the wireless infrastructure and each 
wireless access point (AP) and requires thoughtful planning when designing the network infrastructure. In networks where 
wireless is required to perform well and is one of the primary access methods, an average of one AP for every 10–15 users 
is common. Exact density requirements will vary depending on the environment and application requirements. While not 
covered in this course, a careful assessment of the environment should be made for AP placement. 
Although the preferred method is to terminate PCs behind IP phones, because half as many switch ports are required, other 
methods are available for connecting IP phones if necessary. In the preferred method, both the IP phone and PC support 
802.1x and can be authenticated and assigned to the same VLAN dynamically or the IP phone can provide VLAN tagging. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–13I
Juniper Networks Design Fundamentals
Think About It!
This slideis intended to get you thinking about the overall impact that implementing a bring your own device (BYOD) offering 
has on a company’s network and its resources. 
BYOD is a user driven initiative, which means a positive user experience is vital. A user must have the ability to use their 
device of choice, gain easy access to required enterprise applications, and enjoy optimal application performance. While 
ensuring the network can accommodate the users and provide them a euphoric experience, it is not the only objective or 
concern. One key concern with network design, as previously identified, is ensuring the company’s users and assets are 
protected. A poorly designed and implemented network and BYOD policy is nothing short of a disaster waiting to happen. For 
this reason it is imperative that access to required resources is controlled and that unauthorized or unauthenticated users 
are isolated and only allowed generalized access to the Internet. We provide more details regarding guest access isolation 
on a subsequent slide.
In addition to the security provisions required to support a BYOD implementation, other provisions must be considered as 
well when designing the network. One such consideration includes the placement of access points (APs) throughout the 
campus environment. This placement strategy should be based on a careful assessment of employee workspace and 
high-density areas including conference rooms, auditoriums, lunchroom facilities, and ingress points into the buildings. 
Because of the increased number of devices that will join the network, you must also take care to properly plan your IP 
subnet scopes for internal and external users. This IP subnet planning must include appropriately sized IP subnets on your 
DHCP servers. In some cases you may also need to strategically place DHCP and DNS servers in locations other than the 
corporate data center, which may require site-specific servers and IP subnet allocations. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–14 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
Security Through Isolation 
While there are many considerations when implementing a BYOD deployment, none are more critical than a well defined 
policy. Deciding who and what devices will be allowed on the network and what resources they may access will help you 
clearly understand how BYOD should be deployed. Making these determinations should not be taken lightly and will likely 
require input from several groups throughout the company along with the IT personnel. 
The ultimate plan should determine the company’s flexibility with regards to the permitted personal and wireless devices. 
Ideally the plan should also include details pertaining to the company’s right to monitor and manage corporate data on 
mobile devices along with the rights of employee’s personal data on those same devices. Once you have determined the 
BYOD policy, you can then begin to create the design that will support the business and its policy.
In almost every situation, your design should include some form of user-based isolation. A common approach is to associate 
unauthorized users with a unique VLAN, often called a guest VLAN. In addition to separating authorized and unauthorized 
users at Layer 2 through unique VLANs, it is also highly recommended that you separate them at Layer 3 using unique virtual 
routing and forwarding (VRF) instances. The implementation of unique VRFs to isolate user traffic is typically done at the first 
Layer 3 device in the network. Using this approach ensures the traffic passes through the network in that isolated VRF until 
it reaches the device at the Internet edge. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–15I
Juniper Networks Design Fundamentals
VLAN Connectivity
To begin the LAN design, you must first define the VLANs of the campus and map these VLANs to physical interfaces on the 
Layer 2 switches. It is highly recommended that you standardized design for the VLANs that will be used throughout the 
campus network environment. In addition to the standardized design for the VLANs, we recommend creating a standardized 
VLAN schema that can be used on all access switches. An example of how the available ports might be assigned to the 
various network devices is shown on the slide. Note that while creating and using a standardize schema on all access 
switches provides some clear benefits, such as ease of deployment and troubleshooting, you should also allow for some 
flexibility in your design approach because all areas within an environment are not created equal and do not have the same 
exact requirements. 
In the example on the slide, the wired user is connected behind an IP phone, which terminates on port ge-0/0/1 on the EX 
Series switch. This common wiring approach for users in environments that use voice over IP (VoIP) requires a special hybrid 
port configuration to allow both tagged traffic, for the IP phone on VLAN 108, and untagged traffic for the PC. This hybrid port 
configuration requirement can be accomplished using the voice VLAN feature on select EX Series switches or by simply 
configuring the port as a trunk port for the IP phones tagged traffic with a native (non-trunk) VLAN configured for the wired 
user (VLAN 100).
Continued on the next page.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–16 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
VLAN Connectivity (contd.)
With the exception of the port connecting to the illustrated AP (ge-0/0/32), all other interfaces will be configured as 
untagged access ports for their respective VLANs shown in the table on the slide. Port ge-0/0/32, which connects to the AP, 
must be configured as a trunk port for VLAN 120 (WLAN Private) and VLAN 130 (WLAN Public). While not illustrated in the 
diagram on the slide, all uplink connections, from this access layer switch to the upstream core/aggregation layer switches, 
must be configured as trunk ports associated with all defined VLANs. 
Some devices, such as IP phones and cameras, support Link Layer Discovery Protocol–Media Endpoint Discovery 
(LLDP-MED); a protocol that allows switches to auto-discover the type of device and assign its VLAN. LLDP-MED can be used 
to automatically assign IP phones to a voice VLAN and provide physical location data (commonly used for E911 reporting). In 
a large campus LAN, you might decide to take advantage of all of these mechanisms to authenticate users and devices to 
the LAN. We discuss access control and authentication options on a subsequent slide. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–17I
Juniper Networks Design Fundamentals
Subnet Design
In most deployments, a network will be assigned to the campus office, such as 10.200.0.0/16, which can be divided up into 
many /22 and /24 networks for use inside the campus. In the example on the slide, the campus subnet is divided up using /
22 subnets for the users, and /24 for other networks. A standard and scalable IP schema is necessary in large scale 
deployments. 
The slide posts an interesting question to get you thinking about how devices on the different subnets communicate at Layer 
3 and specifically where the routing occurs. The answer to that question is that it depends on the ultimate design of the 
network. In Layer 3 access designs, the defined subnets must be unique to each access layer switch and, in that design 
scenario, each access switch also performs the inter-VLAN routing functions for the subnets it maintains. In a Layer 2 access 
design, where the same VLANs are shared across several switches in the Layer 2 network, the VLAN interfaces and subnets 
are defined on the core switches. We examine these two design scenarios more closely in the next section of this chapter.NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–18 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
Device Naming Conventions 
Similar to ensuring your VLANs and IP subnets are organized, there is value in defining and following a naming convention for 
your network infrastructure devices. This includes standardizing a naming convention for such as switches, firewalls, load 
balancers, and routers. Having a standardized naming convention that clearly describes the device’s role, function, and 
location can ease the burden of becoming familiar with the network structure and can aid in any required troubleshooting 
efforts. 
The slide provides a sample device naming convention, which leaves much to be desired, for the Layer 2 switches; Virtual 
Chassis in this example. In this example, there is no descriptive quality to the naming convention. If someone, not completely 
familiar with the environment, was asked to go physically inspect VC7, for example, they would not know in which location 
(including the building, floor, or wiring closet) the device was positioned. 
Ideally, the names you give the various devices should indicate what the device is and where it is physically located. An 
example, which meets the desired specifications and that is based on the illustrated environment, is SV-BB-F2-WC1-AS1 
which indicates the locale (Sunnyvale, CA), building (Building B), floor (2), wiring closet (1), and the device’s role and number 
in the physical location (access switch #1). 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–19I
Juniper Networks Design Fundamentals
Access Control Design
A number of methods exist that can be used to authenticate users within the campus LAN. 802.1x Extensible Authentication 
Protocol (EAP) authentication is a good choice for wired and wireless users, provided they have a modern operating system 
with a 802.1x client. 802.1x EAP can authenticate the user against an external RADIUS or Lightweight Directory Access 
Protocol (LDAP) server such as Microsoft Active Directory and can be used to provide a dynamic VLAN assignment, based on 
user or group attributes (for example, users in the “Engineering” group might be assigned to an Engineering LAN). 
For endpoints that do not support 802.1x, such as some IP phones, cameras, printers, or legacy devices, media access 
control (MAC) address authentication can be used to ensure that only that device can send traffic on a switch port. MAC 
authentication can be difficult to manage in large-scale deployments.
As previously mentioned, some devices, such as IP phones and cameras, support LLDP-MED. LLDP-MED can be used to 
automatically assign IP phones to a voice VLAN and provide physical location data (commonly used for E911 reporting). In a 
large campus LAN, you might decide to take advantage of all three authentication methods. 
To complete the access control design, you should identify which ports will require 802.1x authentication, and which devices 
will use MAC authentication. In the example on the slide, IP phones support both LLDP-MED and 802.1x, IP cameras support 
LLDP-MED, and a legacy printer must be authenticate using its MAC address.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–20 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
Think About It!
Although the authentication server performs the actual authentication process, it is up to the 802.1x authenticator (EX Series 
switch in the illustrated diagram) to facilitate network access for individual supplicants (network devices such as an IP phone or 
PC) through the switch ports. On EX Series switches, supplicants can be authenticated using one of three modes:
• The single mode authenticates only the first supplicant. All other supplicants who connect later to the port are 
allowed full access without any further authentication. The subsequent supplicants utilize the first supplicant’s 
authentication. This setting is the default supplicant mode on EX Series switches. It is also the recommended 
mode when a user’s PC and IP telephone use the same switch port and one of the supplicants does not support 
802.1X.
• The single-secure mode allows only one supplicant to connect to the port. No other supplicant is allowed to connect 
until the first supplicant logs out. 
• The multiple mode allows multiple supplicants to connect to the port. Each supplicant is authenticated individually.
The answer to the question posted on the slide is to use the multiple supplicant mode. This mode overcomes the security 
concerns of the single supplicant mode while providing more flexibility than the single-secure mode.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–21I
Juniper Networks Design Fundamentals
CoS In the Campus Network
Another concern you must address when designing the campus network is network performance. Class of Service (CoS) is 
typically necessary in the campus network due to the convergence of voice, video, and data networks, and the need to 
differentiate between applications and types of users, such as guest users. The ability to guarantee bandwidth to a 
particular set of users or applications makes best use of available bandwidth, especially on congested low-speed links.
CoS decisions should not be based solely on reported packet drops on interfaces; decisions should also consider issues 
such as end user QoE and whether an application needs to meet certain service requirements. Other factors to consider 
include whether end users are noticing application performance problems such as timeouts, long delays, or voice or video 
quality issues like choppy or clipped transmissions and pixilated or constantly buffering video streams. When these 
problems do occur, CoS is recommended as a potential solution.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–22 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
Using the Top-Down Design Approach 
The modern day campus network has moved beyond supporting traditional client/server based traffic to supporting 
real-time application traffic such as unified communications (UC), voice over IP (VoIP), video conferencing, and wireless, 
while at the same time accommodating an increasing number of users and devices.
Before properly creating a physical network design that meets your customer’s requirements, you must have an 
understanding of the users, the applications, the traffic types and patterns found on the network, and some idea of what 
constitutes an acceptable performance level, also known as quality of experience level, from the end-users perspective. 
Having some historical baseline information of traffic types and patterns as well as the performance offered by the existing 
network is ideal but not always available. When the information is not available, you must rely on the details you can extract 
from the customer or, with the customer’s permission, from the customer’s users and network. Knowing these details will 
allow you to begin the process of constructing the physical network design that will best support the customer’s needs.
If a BYOD offering is being added to the customer’s network, you can safely assume that the network traffic will increase (in 
some cases significantly). Some studies show that companies that add a BYOD offering increase their device load on the 
network, in many cases, by three times the expected level. Although the traffic on the network may not increase at the same 
rate, you will undoubtedly see some increase with traffic as well. This increase of the number of devices and its 
accompanying traffic load on the network must be considered when creating the campus network design. 
The location of the buildings, users, and devices in a campus network will be importantfactors when deciding on the 
physical topology and the link types that you should use. Connections to off-campus resources, such as data centers and 
branch offices, must be considered. We discuss the connectivity between campus locations in a subsequent chapter. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–23I
Juniper Networks Design Fundamentals
A Real-World Example 
Today’s campus network must connect people, data, devices, and applications. Increased connectivity and geographical 
dispersion create the need for unified communications and collaboration (UCC). UCC is no longer just about reducing travel 
costs or combining diverse communication tools. It is about enabling the organization to effectively achieve its business 
goals. In all cases, a positive user experience—defined as the ability to use a device of choice (BYOD), gain easy access to 
required enterprise applications, and enjoy optimal application performance—is vital. 
Organizations not only require consistent connectivity to enhance employee productivity; they also demand better 
collaboration and more timely communication between employees, which comes at a cost. Introducing connected devices to 
the enterprise network requires tighter control of corporate data, the network, compliance, and privacy. For instance, using 
existing consumer application stores, such as Apple iTunes or Google Android Market, to distribute corporate applications is 
a common practice because they are available 24x7 and accessible from any location. This distribution method does, 
however, require the organization to implement and enforce stricter security policies.
Additionally, network latency, jitter, and lack of available bandwidth impact network performance, resulting in a poor user 
experience that could negatively influence the adoption of collaboration tools. Diversity of devices, legacy technologies, and 
the amount of effort required to make small changes can slow down operations even more and cause network disruptions.
Finally, network complexity makes it difficult to support seamless connectivity and growing bandwidth requirements. The 
enterprise campus cannot be the weakest link in the business; it must be reliable enough to support continuous operations 
and simple enough to make ongoing maintenance and support easy. An agile network is the key to avoiding these problems.
Continued on the next page.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–24 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
A Real-World Example (contd.) 
To address the inherent challenges that come with deploying a company-wide UCC solution, you must ensure the network 
design is secure, flexible, and can accommodate the associated bandwidth requirements. You must ensure the end-to-end 
communications path has sufficient bandwidth and can appropriately prioritize the traffic associated with the UCC solution. 
You can ensure the wired infrastructure is robust enough to handle the bandwidth requirements using EX Series switches in 
the Layer 2 infrastructure and MX Series routers on the campus edge. The EX Series switches can function as standalone 
devices at the access, distribution, and core layers or can be included in a Virtual Chassis solution for a simplified collapsed 
architecture. While using high-bandwidth uplinks between the various layers will meet most of the UCC traffic requirements, 
it is highly recommended that you define and implement an end-to-end quality of service (QoS) plan for UCC traffic to ensure 
the users quality of experience does not degrade when traffic levels spike. We cover QoS and traffic engineering in a later 
chapter. 
While not specifically highlighted in this chapter, the SRX Series Services Gateways and the Junos Space Network Director 
and Security Director applications provide network performance monitoring and capacity planning as well as centralized 
security policy management and control.
For wireless access, Juniper Networks partners with leading WLAN vendors, allowing customers to choose between 802.11n 
or move to more advanced technologies such as 802.11ac. By integrating with collaboration tools such as Microsoft Lync, 
Juniper Networks’ products and solutions can help users work together in real time over a reliable network infrastructure.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–25I
Juniper Networks Design Fundamentals
Over Subscription Ratios
When evaluating network traffic requirements, you must consider two key elements within the proposed architecture; first 
the aggregate interface bandwidth and the throughput capabilities of the infrastructure devices that make up the 
communications path between the devices sending and receiving the traffic. These two points highlight the importance of 
selecting the right devices at each layer of the network and selecting an acceptable subscription (or over subscription) ratio 
between the selected infrastructure devices.
Switches are generally categorized has having a non-blocking architecture or a blocking architecture. A non-blocking 
architecture means that the switch's internal resources can accommodate the ingress and egress traffic flows at their 
maximum rate. A blocking architecture means that the switch's internal resources cannot accommodate the ingress and 
egress traffic flows at their maximum rate, thus becoming a potential bottleneck in the network. Note that in reality there is 
little chance that all interfaces on a given switch would ever be filled to their maximum capacity at the same time, which 
implies that whether the targeted switch has a blocking or non-blocking architecture may or may not matter. Like many 
aspects of network design, it really depends on the environment and customer's requirements.
Network over subscription also occurs on the Layer 2 devices positioned at the various layers in a network, but this deals 
with the number of downstream and upstream interfaces you implement in your physical design of the network. Over 
subscription occurs when the aggregate bandwidth associated with the downstream interfaces is higher than the aggregate 
bandwidth of the upstream interfaces on the same device. The illustration on the slide shows Switch-3 has 44 1 GbE 
downstream interfaces, for an aggregate bandwidth capacity of 44 Gbps, and four 1 GbE upstream interfaces, for an 
aggregate bandwidth capacity of 4 Gbps. This design offers an 11:1 over subscription ratio. While some architects use a 
20:1 ratio for the access-to-distribution uplink as a general starting point, it ultimately depends on the environment and 
customer's needs; thus emphasizing, once again, the importance of knowing and meeting your customer’s needs while 
providing a quality of experience at an acceptable level. NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–26 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
Think About It!
This slide is intended to get you thinking about over subscription. Specifically, this slide tests your knowledge on how over 
subscription is calculated, which trade-offs exist for lowering the subscription ratio, and what other alternatives are available 
instead of lowering the subscription ratio. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–27I
Juniper Networks Design Fundamentals
Selecting the Device: Sample Placement 
This slide provides a visual representation of the many Layer 2 switch options provided by Juniper networks along with some 
general idea of where you might position the different switching models in the campus network and data center 
environment. Note that this illustration is only meant as a generalized positioning guide for the products shown and is not 
exact or definitive by any means.As per usual with network design and product placement, there is always some flexibility 
and in all cases it should ultimately be dictated by the customer’s needs. 
While this may be a reasonably good starting point, you should take a closer look at the product’s scaling details, hardware 
options, and software feature set to ensure you are recommending the right product and solution for the customer’s 
environment.
For more details on the EX Series switches and the QFX Series switches, please refer to the following URLs:
• EX Series switches: http://www.juniper.net/us/en/products-services/switching/ex-series/
• QFX Series switches: http://www.juniper.net/us/en/products-services/switching/qfx-series/
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–28 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
Architectural Design Options 
The slide highlights the topic we discuss next.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–29I
Juniper Networks Design Fundamentals
Campus Core: Legacy Campus Architecture
The slide depicts a generic diagram of a typical legacy campus network. Three network tiers are utilized in the design: the 
access tier, the aggregation tier, and the core tier. As the slide illustrates, many interconnection points exist between the 
tiers, contributing to architectural and troubleshooting complexity. More devices and more connections within a network 
means more potential points of failure. Furthermore, a larger number of devices introduces higher latency, which many 
applications today simply cannot tolerate. Other vendors address many of these issues by adding more devices, which only 
further increases the complexity.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–30 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
Common Configuration Scenarios 
The looped Layer 2 access topology is the most common type of deployment for the access layer. The aggregation layer is 
configured as Layer 2 and Layer 3. The looped Layer 2 access topology design requires very little configuration on the access 
switches. Re-use of the same VLANs and other settings allows for simple configuration replication across multiple switches 
and closets—this reduces deployment time and keeps things simple at the access layer.
The problem with the looped Layer 2 access topology design is the fact that it creates loops and is very inefficient from a 
bandwidth perspective since only half the links can forward traffic. Spanning tree is used for redundancy, but has slow 
convergence times. Spanning tree is difficult to troubleshoot and, if configured improperly, can take down part of the 
network. This design can be further complicated by attempting load-balancing per VLAN across the switches which also 
involves VRRP or HSRP coordination as well. Attempting load-balancing and involving VRRP and HSRP undermines the 
simplicity of the original design and creates several new problems.
The loop-free Layer 2 access topology removes spanning tree from the design and has improved reliability and failover—there 
are no blocked links and convergence is fast. However, this design requires more configuration per switch for both the 
access and aggregation layers—more VLANs, interfaces, and so forth need to be configured. Also, each switch is now unique 
so you lose the simple configuration replication capability found in the looped Layer 2 access topology design.
The loop-free Layer 3 access topology provides fast convergence and no links are blocked. Layer 3 at the access layer 
eliminates loops, provides load balancing, and (with Virtual Chassis) has redundancy as well. However, more planning and 
configuration is needed because this design introduces routing protocols as another layer and each switch configuration has 
many unique items which can reduce the amount of configuration replication flexibility.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–31I
Juniper Networks Design Fundamentals
Improving Looped Layer-2 Access Design 
The benefits of using Virtual Chassis technology at the aggregation layer or at both the aggregation and access layers in the 
looped Layer 2 access topology design are as follows:
• Virtual Chassis provides a loop free design with all links forwarding packets using link aggregation (LAG); 
• The need for spanning tree is eliminated;
• Convergence is faster;
• Troubleshooting is easier; and
• There are fewer devices to manage which reduces complexity and cost. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–32 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
Improving Loop-Free Layer-2 Access Design 
The benefits of using Virtual Chassis technology at the aggregation layer or at both the aggregation and access layers in the 
loop-free Layer 2 access topology design are as follows:
• VRRP is not required and complexity is reduced;
• Convergence is faster;
• All links are forwarding packets;
• Troubleshooting is easier; and
• Fewer VLANs are required, access layer configuration is reduced, and there are fewer IP subnets when using 
Virtual Chassis technologies in both the access and aggregation layer.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–33I
Juniper Networks Design Fundamentals
Improving Loop-Free Layer-3 Access Design 
The benefits of using Virtual Chassis technology at the aggregation layer or at both the aggregation and access layers in the 
loop-free Layer 3 access topology design are as follows:
• All links are forwarding;
• Fewer VLANs are required with Virtual Chassis deployed at both the access and aggregation layers;
• Fewer unique access switch configurations are needed with Virtual Chassis deployed at both the access and 
aggregation layers;
• Complexity is reduced, especially when Virtual Chassis is deployed at both the access and aggregation layers 
because there will be fewer devices to manage; and 
• Although there might be an increased cost for a Layer 3 switch over a Layer 2 switch, all Juniper switches 
capable of Virtual Chassis include Layer 3 capabilities in the base license, which is a competitive differentiator. 
Many competitors charge extra for a Layer 3 license for their switches.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–34 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
When Is Spanning Tree Still Required?
When connecting the access layer to legacy core or aggregation switches that do not support LAG, you might have no choice 
but to use a Layer 2 design with STP. Juniper Networks EX Series switches provide Layer 2 loop prevention through STP, 
Rapid Spanning Tree Protocol (RSTP), Multiple Spanning Tree Protocol (MSTP), and VLAN Spanning Tree Protocol (VSTP). The 
default factory configuration for most EX Series switches uses RSTP. 
Spanning tree is still recommended on access ports (not uplinks) for the protection of loops at the access layer. For example, 
if all ports are enabled and assigned to a default VLAN on the access switch and a user who does not know any better (the 
“problem user” illustrated on the slide) connects a hub device into both uplinks in his office, spanning tree would prevent the 
loop caused by the user error. STP should be enabled to prevent inadvertent loops. Alternately, STP can be disabled and 
bridge protocol data unit (BPDU) protection enabled, because BPDU protection would be easier to troubleshoot.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–35I
Juniper Networks Design Fundamentals
Root Bridge Placement 
This slide is intended to test your knowledge related to the proper placement ofthe root bridge in a Layer 2 environment as 
well as how you can deterministically designate a device as the root bridge. In general you want the root bridge to be a device 
that can maintain the MAC addresses for the entire Layer 2 environment, which implies the need for adequate set of 
resources and processing power. This typically narrows your selection to the aggregation or core Layer 2 devices. You also 
want the root bridge to be a device that is centrally located in the network, to ensure it has a direct connection to most (if not 
all) other switches in the environment. Again, this typically narrows your selection to a device in the aggregation layer of the 
network.
If you have designed your Layer 2 network well and placed the root bridge in a 'good' position, traffic from a source device 
should be able to pass through the root bridge and arrive at its intended destination without any noticeable delay. In the 
sample topology shown on the slide, Switch-1 or Switch-2 should ideally be designated as the root bridge to meet the stated 
criteria. 
If MSTP is used, you could implement load balancing by designating Switch-1 as the root bridge for a group of VLANs and 
Switch-2 as the root bridge for all other VLANs. Similarly you could use VSTP to incorporate load balancing on a per-VLAN 
basis, where each VLAN has its own root bridge. Note that in a practical VSTP deployment the same device will likely service 
many VLANs while another device will service other VLANs, similar to MSTP. 
You designate a switch as the root bridge by ensuring the selected device has a lower root bridge priority than all other 
switches in the environment. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–36 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
Spanning Tree Protection Features 
Once you have determined the desired spanning tree structure and have identified the root bridge, or root bridges depending 
on your deployment, the last thing you want is for some misconfiguration or user error to disrupt the spanning tree 
environment and cause Layer 2 issues throughout your network. To help protect the structure, you can enable a number of 
features designed to protect spanning tree.
You can enable BPDU protection on switch interfaces on which no BPDUs are expected. If a protected interface receives 
BPDUs, the switch disables the interface and stops forwarding frames by transitioning the interface to a blocking state. This 
feature can be enabled on a switch with or without a spanning tree protocol enabled. If BPDU protection is not enabled and 
a rogue switch (or any other device sending BPDUs) sends a BPDU to its attached switch, which is an authorized participant 
in the Layer 2 network, the rogue switch will be added to the spanning tree. Having an unauthorized device become part of 
the spanning tree, or worse become the root bridge for the Layer 2 network, could have some negative impact and affect the 
network’s overall performance or even cause a complete network outage.
Continued on the next page.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–37I
Juniper Networks Design Fundamentals
Spanning Tree Protection Features (contd.) 
You can add an additional protection that prohibits superior BPDUs, sent from rogue devices or through misconfiguration on 
an authorized access switch, from being processed and causing the spanning tree to be recalculated in an unwanted 
manner. This additional protection comes in the form of the root protection feature. You enable root protection on interfaces 
that should not receive superior BPDUs and should not be elected as the root port. These interfaces become designated 
ports. If the bridge receives superior BPDUs on a port that has root protection enabled, that port transitions to an 
inconsistency state, blocking the interface. This blocking prevents a switch that should not be the root bridge from being 
elected the root bridge. After the switch stops receiving superior BPDUs on the interface with root protection, the interface 
returns to a listening state, followed by a learning state, and ultimately back to a forwarding state. Recovery back to the 
forwarding state is automatic. When root protection is enabled on an interface, it is enabled for all the STP instances on that 
interface. Interface is blocked only for instances for which it receives superior BPDUs. Otherwise, it participates in the 
spanning-tree topology.
A third protection feature exists, which is not highlighted on the slide. The third feature is the loop protection feature. 
Although the purpose of STP, RSTP, and MSTP is to provide Layer 2 loop prevention, switch hardware or software errors could 
result in an erroneous interface state transition from the blocking state to the forwarding state. Such behavior could lead to 
Layer 2 loops and consequent network outages. When loop protection is enabled, the spanning-tree topology detects root 
ports and blocked ports, and ensures that both are receiving BPDUs. If an interface with the loop protection feature enabled 
stops receiving BPDUs from its designated port, it reacts as it would react to a problem with the physical connection on this 
interface. It does not transition the interface to a forwarding state. Instead, it transitions the interface to a loop-inconsistent 
state. The interface recovers and then transitions back to the spanning-tree blocking state when it receives a BPDU. 
We recommend that if you enable loop protection, you enable it on all switch interfaces that have a chance of becoming root 
or designated ports. Loop protection is most effective when it is enabled on all switches within a network.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–38 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
We Discussed:
• Components of the campus network;
• Best practices and consideration for the campus; and
• Architectural design options for the campus.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–39I
Juniper Networks Design Fundamentals
Review Questions
1.
2.
3.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–40 • Creating the Design—Campus www.juniper.netI
Juniper Networks Design Fundamentals
Lab: Creating the Design—Campus
The slide provides the objective for this lab.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Campus • Chapter 6–41I
Juniper Networks Design Fundamentals
Answers to Review Questions
1.
By collapsing the core and aggregation layers, an entire layer of latency is eliminated which improves the overall performance. This 
approach also reduces the number of devices to manage, which simplifies operations. Collapsing the core and aggregation layers also 
reduces the number of uplinks, which simplifies the cabling requirements. Fewer devices also means reduced capital equipment costs, as 
well as lower power, space, and cooling costs.
2.
While a number of impacts on a network implementing BYOD exists, the two most notable impacts relate to security, which includes 
incorporating an isolated network segment for guest users among other things, as well as an increase to the overall wireless and wired 
capacity requirements throughout the network. 
3.
While including Virtual Chassis in the common designs provides a number of benefits, some of the more notable benefits include a 
loop-free design is provided; all links forwarding packets; spanning tree is eliminated; convergence is faster; VRRP is not required; 
troubleshooting is easier; fewer unique switch configurations; and there are fewer devices to manage which reduces complexity and 
cost. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 6–42 • Creating the Design—Campus www.juniper.netI
HA
RE
Juniper NetworksDesign Fundamentals
Chapter 7: Creating the Design—WAN 
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
S
IN
T
Juniper Networks Design Fundamentals
We Will Discuss:
• Components of the wide area network (WAN);
• Best practices and consideration for the WAN; and
• Architectural design options for the WAN.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–2 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
The WAN: An Overview 
The slide lists the topics we will discuss. We discuss the highlighted topic first.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–3I
Juniper Networks Design Fundamentals
Wide Area Network Defined 
A wide area network (WAN) is a network covering a broad and geographically disperse area that is used to interconnect 
business locations and resources. The WAN is considered a key component of today’s business and allows companies to 
operate and function effectively. It is through the WAN that key application traffic, critical for business operations, may pass 
between remote locations. We describe key components of the WAN along with design considerations and options 
throughout this chapter. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–4 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
Enterprise WAN Connectivity Functions 
This slide illustrates the four primary functions of WAN connectivity throughout the enterprise network. We describe each of 
these functions in more detail on subsequent slides. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–5I
Juniper Networks Design Fundamentals
Internet Edge 
The Internet edge function is typically found in the campus, branch, and data center environments and is used to provide 
gateway services for the users and applications in those different environments. In some cases the Internet edge function 
for branch offices is hosted in a remote part of the network, such as a WAN aggregation site or data center. 
As illustrated on the slide, the Internet edge function provides access to a number of services and resources such as 
corporate Internet access, access to Web 2.0 applications, connectivity to services hosted in a DMZ, teleworker access, 
backup WAN connectivity for the branch office to the WAN aggregation site or data center, and Internet peering. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–6 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
WAN Aggregation 
The WAN aggregation function is typically found in a regional campus location known as a WAN aggregation site but can also 
be located within a data center. This function is used to connect or aggregate remote branches to the enterprise WAN in a 
hub and spoke fashion. This WAN design approach can help simplify policy management and provides some level of 
modularization, which can ease deployment and troubleshooting efforts.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–7I
Juniper Networks Design Fundamentals
Private WAN 
The private WAN function, which is made possible through the WAN aggregation function, connects all enterprise sites and 
serves as the corporate-managed backbone for the entire enterprise network. This corporate-managed backbone consists of 
several connections, typically structured in a hub-and-spoke or mesh topology. The end devices, such as routers, switches, 
and firewalls, participating in the private WAN are typically managed by the corporate network support personnel rather than 
the service provider through which the circuits and connections are provided. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–8 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
Data Center Interconnect 
As the name implies, the data center interconnect function interconnects data centers. The method used to interconnect 
data centers is typically performed using a standards-based Layer 2 or Layer 3 solution that uses MPLS. Some examples of 
such solutions include virtual private LAN services (VPLS) and Ethernet VPN (EVPN). 
Some reasons to for having multiple data centers, in some cases exact mirrors of each other, and interconnecting those data 
centers are illustrated on the slide. Note that we discuss disaster recovery and business continuity in a subsequent chapter. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–9I
Juniper Networks Design Fundamentals
Best Practices and Considerations 
The slide highlights the topic we discuss next.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–10 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
Enterprise WAN Design Goals 
The design of the enterprise WAN solution should be guided by a number of goals that align with the needs of the enterprise 
business. The identified design for a given enterprise WAN should include the following considerations:
• Easy to deploy — A top goal in any effective network architecture should be ease of deployment. A fantastic 
solution that features complicated deployment scenarios is likely to encounter more issues than a network that 
features a simple and documented deployment.
• Flexible and scalable — New network architecture should be designed to grow with the business and change as 
business needs dictate. Installing a design that just meets the needs of the business today is a recipe for 
increasing expenses and complexity as the network is upgraded in the future.
• Resilient and secure — Architecture that is vital to business success, as in the case of the enterprise WAN, 
should be designed with the expectation that failure and security breaches are not only possible, but probable. 
Rather than designing around unplanned outages and attacks, design in a way that expects outage and attacks 
on the network and its protected resources.
• Easy to manage — An effective network design features management that is simple and centralized. The ideal 
scenario has a single operator with a single pane of glass that is able to manage the entire network. Designing 
ease in the management of the network is just as important as any other factor in the network design.
• Services ready — Finally, a network should be able to easily adopt new technologies and services that allow the 
network to provide enhanced functionality to the business. The ability to introduce value-added services in-line 
with existing network flows is a key design consideration in an enterprise WAN solution. This enables the 
network administrators to add services like WAN acceleration, content caching, elevated security (anti-virus, 
intrusion detection and prevention), to name a few, to the network (often without the addition of new hardware).NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–11I
Juniper Networks Design Fundamentals
Connectivity Considerations: Part 1 
Among other things, the geographic location can dictate the type of WAN connectivity available at each location within the 
enterprise network. If new WAN connectivity will be deployed as part of a network refresh effort, you might need to 
coordinate with the service provider when planning the deployment. Determine now how the WAN will terminate at the 
branch. Will the service provider provision a router or will the connection terminate directly to an locally managed EX, MX, or 
SRX Series device?
In some deployments, the desired WAN connectivity might not be available at all physical locations associated with the 
enterprise network. You might need to propose an alternate connectivity method for these locations which could affect the 
product and interfacesolution you select. While some locations might require exceptions to the standard products and 
solutions you have identified, try to keep these exceptions to a minimum. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–12 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
Connectivity Considerations: Part 2 
Branch locations come in different shapes and sizes and have differing requirements. In some cases a single connection 
from the branch office to the WAN aggregation device is sufficient. In other situations a backup WAN connection may be 
required. With this in mind, when does it really make sense to include a backup WAN link at a remote branch office?
A backup WAN Link makes sense anytime your service provider cannot or does not meet their service-level agreement (SLA). 
The need for a second link is especially critical when your enterprise relies on VoIP or Unified Communications to work. A 
backup link allows you to preserve the full UC experience without complex PSTN-based failover techniques or Survivable 
Remote Telephony. For some enterprises where any downtime means lost revenue, if the cost of a second link is less then 
the cost of downtime, then it makes business sense to add a second WAN link. The increased availability of business-class, 
high-speed Internet has reduced the costs of a second-link considerably making this point more relevant. 
This slide illustrates two possible scenarios where redundant WAN connections are included in the design. In the first 
scenario, a single device with two distinct WAN connections is used at the branch location. In the second scenario, two 
redundant devices are used; each with its own WAN connection. In either of these two scenarios, the branch Layer 2 
infrastructure connects to the illustrated devices, which function as gateways to the WAN. 
Depending on the business requirements and capacity needs at the branch offices, the backup WAN connection may be a 
slower link or a link of equal capacity when compared to the primary WAN connection. If the backup WAN is a slower link, it 
may make sense to only use it when the primary WAN link fails. If the backup WAN link has the same capacity as the primary 
link, you may choose to use both links at the same time and incorporate load balancing. If no backup WAN is available, you 
might need to investigate 3G or other options for backup.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–13I
Juniper Networks Design Fundamentals
Connectivity Considerations: Part 3 
WAN connectivity between the branch locations and the WAN aggregation device can be categorized as one of the following:
• Private WAN: A private WAN will be maintained by the enterprise and is typically deployed across T1/E1, DS3 or 
fractional links. Multiple quality of service (QoS) classes could be available for traffic prioritization across the 
private WAN.
• Public Internet: Low-cost business class Internet is abundant these days and is typically deployed using a digital 
subscriber line (DSL), cable, or Metro Ethernet link. An IP security virtual private network (IPsec VPN) is required 
to secure and authenticate the traffic between locations. It is highly recommended that a firewall and Network 
Address Translation (NAT) be used to isolate the enterprise traffic from the Internet. Typically, only a single class 
of service is available with these Internet connections. 
• Provider-Managed MPLS Service: A private VPN service offered by a service provider can replace the need to 
deploy and manage IPsec VPNs. It gives branch locations a fully-meshed connection to other locations within 
the enterprise network over the MPLS cloud. Typically, four QoS classes are offered for traffic prioritization 
across the MPLS WAN. 
Note
Customers are often sold an “MPLS Service” but do not realize 
that the last-mile to the branch is typically not true MPLS. Rarely 
will the branch CPE device ever need to run MPLS encapsulation. 
In most cases, MPLS terminates on a provider-provisioned router.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–14 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
WAN Device Roles 
The primary role of WAN aggregation is to aggregate connections from multiple branches or regional sites to a central site, 
enabling access to services in the central site or data center. The aggregation hub can be located at a regional office, at the 
data center, or at a service provider central office to enable localized termination of core transport. 
WAN Aggregation Site A, referenced on the slide, shows the three functional roles that routers in an aggregation hub typically 
perform. These roles constitute the functions typically required in a large enterprise WAN solution and include: 
• WAN aggregation – This router role is considered an internal role because the router performing this role does 
not typically have a direct connection to the Internet. The router performing this role is the termination point for 
private leased line and private Layer 3 and Layer 2 VPN services managed through an attached service 
provider. This is also where services such as Web caching are hosted. 
• Internet gateway– This router role is considered an external role because the router performing this role peers 
with the public Internet. It is through the router performing the Internet gateway role that remote enterprise 
locations reach the router used for IPsec tunnel termination. 
• IPsec termination – This router role includes the responsibility of terminating the IPsec and GRE tunnels from 
the Internet connected remote locations. It is recommended that the tunnel endpoints be placed in an Internet 
facing virtual-routing instance. We discuss routing instances in more detail on subsequent slides. 
While these roles are tightly integrated in large enterprise WAN solutions, the customers ultimately decides which functional 
elements they will include in their design. The WAN design illustrated in this chapter uses all three router roles and is 
modular enough to allow for some custom adaptation. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–15I
Juniper Networks Design Fundamentals
A Need for Routing 
Regardless of how the network is designed or what WAN connections are used in the enterprise network, a need for router 
exists. For a given user or device in any enterprise location to communicate with other devices in the enterprise network, the 
needed routes must exist on the appropriate devices. When a WAN aggregation hub is used in the network design, traffic 
from one location to another will pass through the routers in the hub performing the previously discussed roles and 
functions. If traffic is destined to an external resource located on the Internet, that traffic may or may not pass through the 
devices at the hub location depending on the connection type and provisioning of the edge devices and services. 
The diagram on the slide illustrates three distinct connection types: a private leased line, a connection through an Internet 
service provider (ISP), and an MPLS-based Layer 3 VPN connection through a service provider. The branch offices use one or 
more connection types for WAN connectivity. In the case of the first connection type, where the private leased line is used, all 
Layer 3 routing for both internal and external destination subnets will pass through the WAN aggregation site. The lack of 
path flexibility, which results in routing inefficiencies, is an inherent result of the private leased line connection. 
Continued on the next page.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–16 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
A Need for Routing (contd.) 
In the case of the connections using the ISP, an IPsec tunnelis required and used to reach all internal destinations within the 
enterprise network while the direct connection to the ISP may be used for all external destinations. The traffic destined to 
external subnets, in this case, does not need to pass through the WAN aggregation site, thus offering more path flexibility to 
use the direct and more efficient path for traffic destined to external prefixes. Note that while it is more efficient to use the 
direct connection for external prefixes rather than the IPsec tunnel through the WAN aggregation site, it may not always be 
the right choice. In some cases, depending on business goals and policies, it may be a requirement to pass all traffic, 
regardless of the connection type used, through the WAN aggregation site for accounting and conformance purposes. 
The third scenario, which uses a Layer 3 VPN service provider, may be provisioned to send all traffic to the WAN aggregation 
site or only the traffic destined to internal prefixes. Similar to the second connectivity scenario, which uses an ISP and IPsec 
tunnel, depending on business goals and policies, it may be a requirement to pass all traffic through the WAN aggregation 
site for accounting and conformance purposes. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–17I
Juniper Networks Design Fundamentals
Think About It! 
This slide is intended to get you thinking about WAN deployment scenarios. Specifically, this slide has proposed a question 
related to the benefits for identifying similarities between branch office locations and grouping them in some logical fashion. 
While the classes list may include several benefits of classifying branch offices, the primary benefit to consider is that this 
classification can ease the deployment, management, and troubleshooting efforts related to remote branch offices. 
Some general methods for grouping branch office locations into specific categories include the branch’s size, the region in 
which it is deployed, the location’s high-availability requirements, and the function of the branch office. Note that other 
methods for classification may exist and that this is not an exhaustive list. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–18 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
Determining Throughput Requirements
One exercise that must be performed for all locations in an enterprise network is to determine the WAN throughput 
requirements. You can begin this exercise by looking at the number and type of endpoints that the LAN associated with each 
location must support. How many users are there? Where are they located? How many and what type of connections does 
each user need? What applications will be used and what is the anticipated traffic load? Each of these questions should be 
answered for all enterprise locations. 
As described in the previous chapter, the days are gone where a network user only has a desktop computer plugged into the 
network to access some client/server applications and perhaps the Internet. An individual user in today’s network can have 
a desktop computer, a laptop, an IP phone, and a mobile device. They might need wired connectivity and also wireless 
connectivity. Guest access is another concern; guests are users too! Determine where they will be allowed access, what type 
of access, and how many there might be. This type of information helps you determine the overall number of switches, ports, 
access points, and ultimately the required bandwidth for the WAN connection. 
When scoping the required bandwidth associated with the WAN connection for the WAN aggregation sites and data centers, 
remember to take the remote users and their incoming bandwidth requirements into consideration. In addition to these 
considerations, you should also take the future needs of the customer into account! The customer might want to have a 
certain number of unused ports available for future needs without having to wait for the requisition, purchase, and 
installation of a new device. The WAN connection throughput should include a reasonable buffer to account for future growth 
and expansion. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–19I
Juniper Networks Design Fundamentals
Performance Considerations
Throughout the enterprise network, the WAN speed and latency are often the largest bottleneck points in overall 
performance. Therefore, matching a device to the maximum WAN capacity is a good start. Note that smaller packets such as 
voice and video will impact performance the most; therefore when evaluating a router's performance, we recommend using 
Internet mix (IMIX), which is a mix of packet sizes. 
When determining a router's performance capabilities, you should keep in mind that enabling features, such as traffic 
shaping, will typically have a 20% reduction in total packets per second. You should also understand that enabling certain 
security features on a firewall, such as intrusion detection and prevention (IDP) or Unified Threat Management (UTM), will 
impact the device's performance on the inspected traffic flows. Because it is difficult to accurately predict the real-world 
performance of IDP and UTM, we recommend you position a slightly higher capacity platform in these use cases.
When planning the network, latency requirements should be taken into account. How much latency is acceptable for the 
applications that will run across the network? Voice and video require less than 100 milliseconds end-to-end or the quality 
will be impacted. Storage, trading applications, and cloud computing all require low latency. Because of these considerations 
and requirements, it is helpful to thoroughly assess the end-to-end environment and characteristics of the network. 
Continued on the next page.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–20 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
Performance Considerations (contd.) 
The major sources of latency include WAN propagation delay, WAN serialization delay, and encryption and decryption delays. 
WAN propagation delay is the time it takes for a packet to travel from one location to another, assuming there are not any 
hops (for example, New York to London). WAN propagation delay is largely based on the speed of light and not much can be 
done to improve the delay. It may be helpful to understand that providers often publish their average latency between major 
cities, where the infrastructure is healthy and vibrant. The latency between two locations in your customer's environment 
that are remote and not located in major cities may be significantly different. WAN serialization delay is the time it takes to 
serialize a packet across a WAN connection. The time is largely dependent on link speed and queue size. Lower speed links 
equate to more latency. Encryption and decryption delays are the time it takes to encrypt and decrypt packets when using 
IPsec. Devices with IPsec hardware acceleration introduce less delay than software solutions.
If latency is excessive, it might prohibit a hub-and-spoke VPN design because the packets must travel back to the hub 
location to route between branch offices which can cause unacceptable levels of latency. Multiple serialization delays occur 
and double encryption and decryption takes place. To ensure excessive latency will not become a problem, you should 
conduct end-to-end latency tests before finalizing the VPN design. 
Future changes to the geography of the branch office must also be considered. While discussing network infrastructure with 
the customer, you must also plan for future growth. Any planned relocation, additions, acquisitions, and so forth can affect 
the network. The best way to assist the customer with future events is to offer flexibility in your WAN design. GoodWAN 
designs address contemporary issues and accommodate future growth. 
By flexibility we mean “accommodating future requirements with minimal effort and cost.” Flexibility in your branch design 
can be facilitated through device capacities and capabilities. Device capacity allows for growth in terms of performance and 
scalability, while capabilities allow networks to operate in a way that meets quality of experience requirements. Consider the 
following when designing a flexible branch network:
• Extra capacity can be added on the same platform or by adding additional devices without disrupting the 
network;
• Flexibility to add feature support in the future such as different dynamic path discovery protocols;
• Service flexibility to facilitate the introduction of services such as firewall or intrusion prevention system (IPS) on 
the same platform;
• Different network virtualization techniques; and
• Advanced QoS functionalities.
Flexibility can come with higher capital expenditures (CapEx) initially. However, it provides both lower CapEx and operational 
expenditures (OpEx) in the long term. To provide a flexible design that allows for capacity enhancements over time, you can 
choose between two options, or a combination of both. The first option is to start with higher capacity products and add line 
cards as needed. Or you could start with lower capacity products that make it possible to grow the network when needed 
with minimal disruption. 
In addition, reducing the sheer number of devices and simplifying the network produce a direct savings associated with 
network maintenance and service costs, helping you to future-proof the network.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–21I
Juniper Networks Design Fundamentals
Test Your Knowledge 
When planning the usable bandwidth across the WAN, do not forget to account for protocol overhead. The overhead will 
increase the bandwidth used by small packets, or high cells per second (CPS) applications such as voice and video, more 
than large packet applications such as the Web.
The overhead can cause maximum transmission unit (MTU) and fragmentation issues that could lead to noticeable 
performance degradation especially across an IPsec VPN. MTU and fragmentation issues are typically addressed by 
configuring a Transmission Control Protocol maximum segment size (TCP-MSS) length and properly configuring interface 
MTUs. The table on the slide shows the protocol overhead for common Layer 2 or Layer 3 transport protocols. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–22 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
VPN Design Considerations 
Remember that tunneling any protocol within another increases the overall packet length. IPsec typically adds 36 bytes 
(without Network Address Translation (NAT) traversal) when using Encapsulating Security Payload (ESP) tunnel mode. 
Because of the increase in overall packet length, a recommended best practice is to limit the size of packets prior to 
encryption. 
Limiting the packet size can be accomplished by changing the maximum transmission unit (MTU) size on nodes or routers, or 
by advertising a TCP maximum segment size (MSS) value to limit the TCP window size. Fragmentation will kill the 
performance of any VPN, even if it is hardware accelerated.
The following values are given for the TCP-MSS size when using IPsec:
• IPsec tunnel mode with no NAT traversal: 1463 bytes; and
• IPsec tunnel mode with NAT traversal (UDP): 1400 bytes.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–23I
Juniper Networks Design Fundamentals
Test Your Knowledge 
If a branch office has a dynamically learned IP address that is unknown to the VPN termination device in the WAN 
aggregation site, you must use Internet Key Exchange (IKE) aggressive-mode with non-IP identities to authenticate that 
branch device through IPsec. 
Because the VPN termination device in the WAN aggregation site does not yet know the IP address of the branch, it cannot 
bring up the tunnel. The tunnel must be brought up by the branch device—typically when the device first boots. After the 
tunnel has been initiated by the branch, it is typically left up or re-keyed so that connectivity into the branch is always 
maintained. In these scenarios, you might want to use long lifetimes for the tunnels themselves and the VPN monitor 
keepalive features.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–24 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
A Need for Quality of Service 
Traffic congestion can either be attributed to the hardware itself, or to the network deployment. The most common cause of 
congestion is the network deployment, where the ingress traffic rate is greater than the egress bandwidth. 
If the network device’s congestion management features are not capable of managing traffic during these periods, the 
device can drop packets or induce latency. In a TCP/IP network, packet retransmissions will be generated because of either 
packet drops or long latencies causing TCP timeouts, and this will generate additional network load. In networks that are 
already congested, this increase in network load further exacerbates any existing network performance issues.
With voice, video, and critical business applications such as service-oriented applications (SOA) where traffic converges onto 
existing data networks, congestion management is even more critical. Traffic that is sensitive to latency like voice and video 
can be severely impacted if transmission delays occur. Increasing memory or bandwidth will help reduce packet drops, but it 
will not necessarily solve latency.
A well planned quality of service (QoS) implementation is necessary in the enterprise network due to the convergence of 
voice, video, and data networks, and the need to differentiate between applications and types of users, such as guest users. 
The ability to guarantee bandwidth to a particular set of users or applications makes best use of available bandwidth, 
especially on congested low-speed links.
Continued on the next page.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–25I
Juniper Networks Design Fundamentals
A Need for Quality of Service (contd.) 
QoS decisions should not be based solely on reported packet drops on interfaces; decisions should also consider issues 
such as the quality of experience (QoE) provided to the end user and whether an application needs to meet certain service 
requirements. Other factors to consider include whether end users are noticing application performance problems such as 
timeouts, long delays, or voice or video quality issues like choppy or clipped transmissions and pixilated or constantly 
buffering video streams. When these problems do occur, QoS is recommended as a potential solution.
“Trust” and “untrust” are commonly used terms in a security context, but they can also be used in QoS discussions, as they 
provide a clear demarcation and make developing a QoS strategy easier. An edge device (such as an access switch or router 
connecting to the Internet) resides between the trust and untrust boundary. These are the first and last entry points into and 
out of the campus network. There is uncertainty about the QoS markings on packets coming from the untrusted domain, but 
once they enter the campus LAN, network administrators have complete control and can manipulate packets so that they 
comply with the established QoS strategy. Anything outside the enterprise network is considered untrusted; anything within 
the enterprise network is considered trusted.
QoS is only effective if it is deployed end-to-end across the LAN. It serves no useful purpose if it is only configured in one or a 
few sections of thenetwork, and needs to be configured at every hop along the way from the source to the destination. 
We discuss QoS in more detail in a subsequent chapter. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–26 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
A Need for Security 
The security of the enterprise network is another important factor in designing network architecture. As networks become 
larger and more complex, entry points into the network and areas where security vulnerabilities exist are more probable. 
Effective WAN aggregation and enterprise WAN designs ensure a secure network that does not restrict usability to the point 
where using the network becomes a burden to the end user, hindering the customer experience in the process. Security 
should be designed to address vulnerability and risk while enhancing the user experience on the network as much as 
possible.
“Trust” and “untrust” areas within the network should be identified. Once identified, these areas provide a clear demarcation 
and make developing a security strategy easier. An edge device (such as an access switch or router connecting to the 
Internet) resides between the trust and untrust boundary. These are the first and last entry points into and out of the 
enterprise network. There is uncertainty about the packets coming from the untrusted domain. To protect the enterprise 
network and its users, network administrators define acceptance policies to control what can and cannot enter the network 
through the demarcation points to ensure the incoming traffic complies with the established policies. Traffic from outside 
the enterprise network is considered untrusted; traffic from within the network is considered trusted.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–27I
Juniper Networks Design Fundamentals
Using Virtual Routers 
Junos routing and security devices placed at the edge of the enterprise WAN have the ability to configure multiple routing 
instances, which are also known as virtual routers (VRs). Each routing instance provides logical separation of routing table, 
protocols, and interfaces within that instance. You can use physical or logical tunnel interfaces along with policy and filters to 
route and control traffic between VRs.
As shown on the slide, a number of scenarios when using VRs makes sense in the enterprise exist. You can use VRs:
• To isolate WAN and edge routing from LAN routing domains when running multiple protocols;
• To isolate guest networks with Internet access over a separate WAN connection; and
• To isolate point-of-sale (PoS) networks and route over a specific VPN.
Some additional scenarios where network traffic might have to be kept separate using routing instances include:
• Merging organizations;
• Multi-tenant buildings;
• Secure facilities (such as government facilities or military bases); and 
• College campuses with many of different departments.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–28 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
Selecting the Device: Sample Placement 
This slide provides a visual representation of the many WAN routing and security options provided by Juniper networks along 
with some general idea of where you might position the different products in the enterprise WAN. Note that this illustration is 
only meant as a generalized positioning for products shown and is not exact or definitive by any means. As per usual with 
network design and product placement, there is always some flexibility and in all cases is dictated by customer needs. While 
this may be a reasonably good starting point, you should take a closer look at the product’s scaling details, hardware 
options, and software feature set to ensure you are recommending the right product and solution for the customer’s 
environment.
For more details on the MX Series routers and the SRX Series devices, please refer to the following URLs:
• MX Series routers: http://www.juniper.net/us/en/products-services/routing/mx-series/
• SRX Series devices: http://www.juniper.net/us/en/products-services/security/srx-series/
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–29I
Juniper Networks Design Fundamentals
WAN Design Examples 
The slide highlights the topic we discuss next.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–30 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
A Design Example 
This slide illustrates the primary components used when designing an enterprise WAN. In this example, there are a number 
of different sized branch offices that use varying WAN connection types to connect to redundant WAN aggregation sites. The 
redundant WAN aggregation sites include three routers, which are performing the Internet gateway, VPN termination, and 
WAN aggregation roles. Both WAN aggregation sites have connectivity to the corporate data center as well as the hosted 
services used in the enterprise. 
Note that while all the key components are illustrated in this example design, in practice the design may be different than 
that shown here. Depending on the deployment and available options, your design may only use one of the available WAN 
connection types or perhaps only a single WAN aggregation site. Your design may consolidate the router roles into a reduced 
number of physical devices or perhaps eliminate some roles altogether. In a fully redundant environment where 
high-availability and business continuity are top priorities, your design may include multiple data centers with redundant 
connections to each data center. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–31I
Juniper Networks Design Fundamentals
Enterprise WAN: Active/Passive Design 
This slide illustrates the active/passive design option for the WAN. In this example, a single WAN aggregation router uses one 
of its two links that offer a connectivity path to the data center. The selection of one path over another is made by using link 
cost and route preference. Note that in some cases, the active/passive method makes sense because the secondary link 
and path may not provide the same performance capability because of the associated link speed or because of a less direct 
path. In the illustrated example, the active/passive makes sense because the secondary path, which traverses the other 
WAN aggregation router, is a less direct path. Ideally, the two WAN aggregation sites will have a balanced distribution of 
traffic from the attached branch offices so all transit traffic destined to the data center will use the local connection with a 
more direct path. 
In other cases, it may not make sense to use the active/passive design but rather the active/active design, which we cover 
on the next slide. Note that all WAN devices in all areas of the enterprise network that have redundant WAN connections and 
egress paths must incorporate either an active/passive design or an active/active design. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–32 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
Enterprise WAN: Active/Active Design 
This slide illustrates the active/active design option for the WAN. In this example, a WAN router at a remote branch location 
has two independent WAN connections to two distinct Layer 3 VPN service providers. In this case each WAN connection is 
active. The WAN router at the branch location has a default route pointing to the provider edge (PE) routers in the service 
providers’ networks. As traffic destined to remote subnets is received by the WAN router, it will be balanced between and 
sent across both connections. 
Regardless of which traffic forwarding design option you use;active/passive or active/active, you will need to ensure that the 
required routes are placed on the required devices. You could use static routing, however in a large enterprise network that 
would not be a practical or scalable approach but rather a clear indication that you hate yourself or the customer attempting 
to help! This author assumes you are smarter than that and that you do not hate yourself or your customer. To simplify things 
you should consider using routing protocols between the various locations in the enterprise network. In large scale 
deployments, an interior gateway protocol (IGP) such as OSPF is used in conjunction with internal BGP (IBGP). The manner in 
which these protocols are used will depend on the design and overall deployment objectives! 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–33I
Juniper Networks Design Fundamentals
Enterprise WAN: VPN Design Options 
As shown on the slide, a number of VPN design options exist for the enterprise network. The descriptions of these design 
options follow:
• In a 2-tier hub-and-spoke IPsec VPN design, branch offices (spokes) connect to one or more WAN aggregation 
sides or data centers (hubs). The design is kept simple because only a small number of tunnels are needed at 
each branch. Any traffic routed between branch offices must first route through one of the hubs, which can 
double the latency when one branch communicates with another branch. Before you decide on such a design, 
you should verify that the latency is acceptable between branch offices, especially if voice, video, or UC 
applications are to be used across branch offices. Note that in an MPLS-VPN design, branch offices often have 
direct connectivity to each other inside the MPLS provider’s network.
• In a 3-tier hub-and-spoke IPsec VPN design, branch offices terminate tunnels to their regional WAN aggregation 
site and data center. Devices between regions will route between the regional hub locations to communicate, 
possibly adding more latency. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–34 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
Enterprise WAN: VPN Design Options (contd.) 
• In a fully-meshed VPN design, each branch has a direct route to other branch offices as well as to the WAN 
aggregation sites and data centers. While this design offers fewer hops and less latency, the design increases 
the complexity and size of the configuration as the number of tunnels grows exponentially with the number of 
branch offices. Because of this complexity and scale, many enterprises have migrated to provider-MPLS 
networks to fulfill the need for fully-meshed connectivity between branch offices. If the design is used, a 
recommended best practice is to limit VPN tunnels to come up on-demand. Routing protocols such as RIP, with 
on-demand circuits or BGP, can be used to dynamically control routing across the fully-meshed design because 
static routing is often too difficult to scale effectively in this design.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–35I
Juniper Networks Design Fundamentals
We Discussed:
• Components of the WAN;
• Best practices and consideration for the WAN; and
• Design options for the WAN.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–36 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
Review Questions
1.
2.
3.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–37I
Juniper Networks Design Fundamentals
Lab: Creating the Design—WAN
The slide provides the objective for this lab.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–38 • Creating the Design—WAN www.juniper.netI
Juniper Networks Design Fundamentals
Answers to Review Questions
1.
The three roles performed by the devices in the WAN aggregation site of a large enterprise WAN deployment include: 
WAN aggregation – This router role is considered an internal role because the router performing this role does not typically have a 
direct connection to the Internet. The router performing this role is the termination point for private leased line and private Layer 3 
and Layer 2 VPN services managed through an attached service provider. This is also where services such as Web caching are hosted. 
Internet gateway– This router role is considered an external role because the router performing this role peers with the public Internet. 
It is through the router performing the Internet gateway role that remote enterprise locations reach the router used for IPsec tunnel 
termination. 
IPsec termination – This router role includes the responsibility of terminating the IPsec and GRE tunnels from the Internet connected 
remote locations. It is recommended that the tunnel endpoints be placed in an Internet facing virtual-routing instance. 
2.
You can determine the general bandwidth and throughput requirements for the WAN connection for a given site by looking at the 
number and type of endpoints that the LAN associated with the location supports. Some good questions to answer include: How many 
users are there? Where are they located? How many and what type of connections does each user need? What applications will be used 
and what is the anticipated traffic load?
3.
The protocol overhead of the Layer 2 and Layer 3 WAN protocols will decrease the usable bandwidth for the WAN connection. The 
overhead will increase the bandwidth used by small packets, or high cells per second (CPS) applications such as voice and video, more 
than large packet applications such as the Web. The overhead can cause MTU and fragmentation issues that could lead to noticeable 
performance degradation especially across an IPsec VPN. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—WAN • Chapter 7–39I
Juniper Networks Design Fundamentals
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 7–40 • Creating the Design—WAN www.juniper.netI
HA
RE
Juniper Networks Design Fundamentals
Chapter 8: Creating the Design—Data Center
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
S
IN
T
Juniper Networks Design Fundamentals
We Will Discuss:
• Components of the data center;
• Best practices and consideration for designing data centers; and
• Architectural design options for the data center.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–2 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
The Data Center: An Overview 
The slide lists the topics we will discuss. We discuss the highlighted topic first.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–3I
Juniper Networks Design Fundamentals
What Is a Data Center? 
As the name implies, a data center is a center, or facility, in which data is collected (or stored) and processed. Data centers 
come in many shapes and sizes but do share some common components, as shown on the slide. 
The primary ingress and egress point for a data center along with the equipment used to provide those gateway services are 
included in the WAN domain. The components, processes, and policies used to protect the data center and its resources are 
part of the security domain. The systems and tools used to manage and monitor the data center and its operations are found 
in the management domain. The compute and storage domain include the data assets, services, applications and the 
compute and storage equipment required by the business and its users. The Layer 2 and Layer 3 infrastructure domain 
include the devices, connections, and corresponding policies and protocols used to interconnect all other domains and to 
facilitate communications between users and their targetedresources. 
Our primary focus in this chapter is on the Layer 2 and Layer 3 infrastructure domain. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–4 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
Traditional Data Centers
As shown on the slide, the physical structure, or architecture, of traditional data centers includes multiple tiers or layers. 
Each of these tiers has a designated function and responsibility, which are defined on the slide. 
As its name implies, the access tier is the point of entry (or access) into the network for the compute and storage resources. 
The access tier is the foundation and building block of the entire data center network. The size and structure of this tier 
affects the other tiers and overall size of the data center network. Most data center access switches are deployed at the 
top-of-rack (TOR), bottom-of-rack (BOR), middle-of-rack (MOR), or at the end-of-row (EOR) of server racks. You can configure 
access switches to use Layer 2 protocols, Layer 3 routing protocols, or both. 
The function of the aggregation tier is simply to interconnect all of the access switches with the rest of the world. The size of 
the aggregation and core tiers is directly proportional to the size of the access tier. Specifically, the number of uplinks from 
the access switches to the aggregation tier determine the size of the aggregation tier and the number of uplinks from the 
aggregation switches to the core tier determine the size of the core tier. Using the size and throughput requirements 
identified through this qualifying exercise can help you determine which products are best suited for the various tiers in your 
data center! 
The switches required in the aggregation and core tiers are typically line-rate, nonblocking switches. In large 
high-performance data centers, you will likely need many line-rate, 10 Gbps ports to accommodate the uplink connections 
from the access tier. Because bandwidth demand is always increasing, you may need the switches positioned in these tiers 
to be expandable to 40GbE and 100GbE in the future. In many cases chassis-based switches are used in these tiers to meet 
high port density and high-performance requirements. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–5I
Juniper Networks Design Fundamentals
Recognizing the Challenges 
Data centers built more than a few years ago face one or more of the following challenges:
• The legacy multitier switching architecture cannot provide today’s applications and users with predictable 
latency and uniform bandwidth. This problem is made worse when virtualization is introduced, where the 
performance of virtual machines (VMs) depends on the physical location of the servers hosting those VMs.
• The management of an ever growing data center is becoming more and more taxing administratively speaking. 
While the north to south boundaries have been fixed for years, the east to west boundaries have not stopped 
growing. This growth, of the compute, storage, and infrastructure, requires a new management approach. 
• The power consumed by networking gear represents a significant proportion of the overall power consumed in 
the data center. This challenge is particularly important today, when escalating energy costs are putting 
additional pressure on budgets.
• The increasing performance and densities of modern CPUs has led to an increase in network traffic. The 
network is often not equipped to deal with the large bandwidth demands and increased number of media 
access control (MAC) addresses and IP addresses on each network port.
• Separate networks for Ethernet data and storage traffic must be maintained, adding to the training and 
management budget. Siloed Layer 2 domains increase the overall costs of the data center environment. In 
addition, outages related to the legacy behavior of the Spanning Tree Protocol (STP), which is used to support 
these legacy environments, often results in lost revenue and unhappy customers.
Given these challenges, along with others, data center operators are seeking solutions. This, interestingly enough, is where 
you and your, soon to be refined, design skills come into play! NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–6 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
Best Practices and Considerations 
The slide highlights the topic we discuss next.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–7I
Juniper Networks Design Fundamentals
Assessing the Data Center Needs
As previously mentioned, data centers come in various shapes and sizes and with different levels of sophistication. A 
one-size fits all approach for designing data centers simply does not work. Because customer's needs vary, it only makes 
sense that their data center environments will also vary. To properly design a data center environment that meets the needs 
of the customer, you must gather the right information. 
The questions listed on the slide are crucial for understanding your customer’s data center needs:
• Does your data center deliver revenue generating services, or does it support your internal IT and campus 
environments? This question relates to the segmentation of the customer’s data center deployment.
• In addition to your main data center network, how many additional data centers do you have? Will they need to 
be connected? The answers to these questions provide information about additional data center opportunities.
• What are the growth plans for server farms over the next two years? Does the customer plan include 1GbE, 
10GbE, or a combination of both? The answers to these questions provide you with information about 
expandability and growth in the existing data center, as well as what types of switches the customer needs.
• What are the performance requirements? The answer to this question provides information on latency 
requirements and wire speed deployment, which also relate back to the switches the customer needs.
• Does the customer need traffic separation or service level agreements (SLAs)? The answer to this question 
provides insight as to whether they need to meet service provider specifications.
The information gathered from these questions can help categorize the customer’s data center and identify the right 
products and design for the environment. NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–8 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
Categorizing Data Centers
Data centers vary in size, performance, and price requirements. Also, individuals managing data centers have different 
motivations driving the adoption of updating their designs to incorporate new technology. For example, a financial company 
needs to gain an edge against the competition. They might be willing to try a new technology whereas a traditional IT 
company might be more conservative when building their data centers or bringing in new technology. Two different types of 
data centers can have exactly the same number of servers yet their switching requirements could be completely different. 
No “one size fits all” solution or product set exists. The kind of technology used or switching deployment chosen is 
dependent upon the nature of the business. Segmenting by number of servers can be misleading—different types of data 
centers can require exactly the same number of servers and completely opposite switching infrastructures. 
The slide illustrates three general categories of data centers; each with different requirements. Enterprise IT data centers 
can be for large enterprises, medium-sized enterprises, or a small business. What the typical enterprise IT customer will 
focus on are capital expenditures (CapEx) and operating expenditures(OpEx). Optimization of CapEx and OpEx is a primary 
concern because the data centers associated with enterprise IT companies are most likely cost centers, which means cost 
must be kept under control. Another area of concern for the enterprise IT data center is on server virtualization or converging 
storage on their LAN networks. Focusing on these areas can increase efficiency while also managing costs. 
The second general category of data centers is the cloud provider category. Cloud providers are companies that require 
massive scale, primarily because they have millions of users. Because of their scaling needs, they also are very cost 
conscious.
Continued on the next page.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–9I
Juniper Networks Design Fundamentals
Categorizing Data Centers (contd.) 
In the performance oriented data center, for example companies in the financial sector or scientific research, speed matters. 
A financial company’s revenue is dependent on how quickly they can complete transactions. For a financial customer, high 
performance in terms of low latency and low jitter is going to be very important. Customers that typically look for high 
performance networks will be financial services firms, research facilities, and high performance computing (HPC) 
companies. 
Another more generalized method of categorizing data centers is to classify them as either IT data centers or production 
data centers. The main difference between these two data center categories is that IT data centers are more of a cost center 
and need to control costs whereas production data centers are more of a profit center and need to generate revenue. 
Production data centers are important to the profitability of a business. 
There are typically fewer servers in an IT data center than in a production data center, but they are static. The emphasis is 
more on stability and ease of management. The IT data center will most likely be connected to a campus network and a 
single service provider. The IT data center is most interested in server virtualization to help them become more efficient. 
Convergence, bringing storage and LAN together using storage area networks (SANs) and networked attached storage (NAS), 
is another area of interest for the IT data center. 
The production data center’s primary concerns are revenues and ratings. Production data centers can grow at a fast pace 
and can be dynamically changing their data centers very often, so the emphasis is on performance, scale, and negotiating 
an acceptable price point. The infrastructure of a production data center has to be agile because this type of data center will 
be connecting to different service providers, the Internet, and their own infrastructure. Some server virtualization will be 
present in a production environment, and typically they do some custom deployments in terms of server infrastructure, so 
the production data center might also be interested in convergence. However, the primary emphasis is always going to be on 
increasing the number servers and providing applications on a dynamic basis.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–10 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
Design Guidelines and Requirements 
This slide lists some common guidelines and requirements when designing data center networks. We highlight some ways of 
addressing these points on subsequent slides throughout this section. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–11I
Juniper Networks Design Fundamentals
Understanding the Trends: Part 1 
As you engage with your customers to create the data center design, there are some trends you should consider. This and 
the next slide describe trends that may impact the design of your customer’s data center in some way.
Large enterprise data centers provide users with a significant number of servers, provide users with access to data and 
resources to perform their work and collaborate. Over the years, many data centers have quickly grown and the 
organization's requirements have expanded. Through the growth and expansion, applications were deployed on dedicated 
servers providing the needed compute and storage resources. In many cases the dedicated server resources were 
underutilized resulting in waste. Because these dedicated server resources were designed for a specific application, the 
result was that the data center supported a broad assortment of devices with their unique operating systems and storage 
solutions, which resulted in a number of isolated applications that were difficult to change or expand and expensive to 
manage, integrate, secure, and back up.
As shown on the slide, this server-centric data center model is now moving to a service-centric model. This trend in the data 
center includes the following:
• Using virtual machine software on larger more capable servers to break the one-to-one relationship between 
applications and the server hardware and operating system on which they run. Virtual machine software, such 
as VMware, allows multiple applications to run on a single server, independent of each other and of the 
underlying operating system.
• Removing storage from the server and placing it in consolidated storage pools. Using networked storage that is 
shared, such as storage area networks (SAN), allows you to more easily manage and provision the storage 
resource while improving utilization and implementing a data recovery strategy for increased continuity. NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–12 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
Understanding the Trends: Part 2 
Clearly, more devices within a network architecture means more points of failure. Furthermore, a larger number of devices 
introduces a higher network latency, which many applications today simply cannot tolerate. Most legacy chassis switches 
add latencies of the order of 20 to 50 microseconds.
Today, we have extremely high-density 10GbE Layer 2 and Layer 3 switches, in the data center core. Many of these switches 
have 100 Gbps or more of capacity per slot and over 100 line-rate 10GbE ports in a chassis. This enhanced performance 
capability in data center switches has resulted in a trend of simplification throughout the entire data center. With this design 
simplification, made possible by higher performing and more capable switches, you can eliminate the aggregation tier of a 
legacy three-tier data center network altogether. 
Using a simplified architecture reduces latency through a combination of collapsed switching tiers, Virtual Chassis for direct 
path from server to server, and advanced application-specific integrated circuit (ASIC) technologies. By simplifying the data 
center architecture, you reduce the overall number of devices, which means the physical interconnect architecture is 
simplified. By simplifying the overall design and structure at the physical layer, your deployment, management, and future 
troubleshooting efforts are made easier. We examine these points in greater detail on subsequent slides.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–13I
Juniper Networks Design Fundamentals
Why Do Traffic Patterns Matter? 
This slide is intended to get you thinking about traffic flows within the data center. Truly understanding traffic flows and 
patterns can help you determine the best design for the data center. Using the illustrated architecture, which is based on the 
traditional three-tier structure, the traffic patterns (be those in the west and east directions or north and south directions) 
ultimately determine the required capacity of the uplinks between the various layers, including the WAN connection.This knowledge coupled with the proper placement of the right switches and the right technologies can help you identify the 
needed structure; be that a collapsed tiered structure or some new emerging architecture. On subsequent slides we 
examine the relationship between a selected design and the traffic the resulting environment supports. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–14 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
Building the Foundation 
As its name implies, the access tier is the point of entry (or access) into the network for the compute and storage resources. 
The access tier is the foundation and building block of the entire data center network. The size and structure of this tier 
affects the other tiers and overall size of the data center network. Most data center access switches are deployed at the 
top-of-rack (TOR), bottom-of-rack (BOR), middle-of-rack (MOR), or at the end-of-row (EOR) of server racks. You can configure 
access switches to use Layer 2 protocols, Layer 3 routing protocols, or both. 
While you could incorporate a larger switch with more access ports into the access layer to reduce traffic flows in the west 
and east directions, this approach does not scale economically nor does this approach fit into the current or foreseeable 
placement scenario of access switches in data center environments because of the alloted rack space and environmental 
considerations. To accommodate the standard placement scenario and environment in which access switches reside and 
reduce the northbound traffic levels some other solution is required. We cover one possible solution on the next slide! 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–15I
Juniper Networks Design Fundamentals
Using Virtual Chassis in the Design
To simplify and scale a data center network, the first step is to scale the data center access tier. Scaling the data center 
access tier creates a domino effect, with fewer access switches, enabling you to design a network that allows traffic to flow 
directly between racks, without going through the aggregation layer. This deployment scenario results in fewer uplinks to the 
aggregation tier, and therefore fewer ports required at the aggregation tier switches. In turn, the result is fewer aggregation 
devices, which may result in the elimination of the aggregation tier altogether! 
So, how exactly do you reduce the number of switches in the access tier and also allow server traffic across racks in the west 
and east directions? The answer is to use Juniper Networks Virtual Chassis technology. The Virtual Chassis technology allows 
up to 10 switches to be interconnected through a high-speed interchassis connections, which may use either special 
backplane cables, or using 1GbE or 10GbE uplinks. The result is up to 10 line cards that, instead of fitting into a single 
chassis, each work on their own, with their own power supplies and fans. Because the member switches function together as 
a single chassis, cross member link aggregation groups (LAGs) run from the members of the Virtual Chassis up to the 
aggregation tier. Depending on the design, a Spanning Tree may not always be required because the member switches 
function as a single switch. A server in one rack, connected to a member of the Virtual Chassis, can communicate with a 
server in different rack that connects to another member of the same Virtual Chassis through the virtual backplane 
connection, without going through the upper tier. 
Continued on the next page.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–16 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
Using Virtual Chassis in the Design (contd.) 
In environments that require an increased level of availability, you can deploy two Virtual Chassis spanning the same racks. 
With two Virtual Chassis running across the same racks, the deployed servers can be dual-home attached to each Virtual 
Chassis. One network interface card (NIC) of the server connects to one Virtual Chassis and a second NIC in the same server 
connects to the other Virtual Chassis—just like a server dual-homing to two switches.
Using Virtual Chassis you no longer need to run two uplinks from each of the TOR switches unless, of course, the bandwidth 
capacity required for the environment and applications demand it. Instead of deploying 20 uplinks from 10 TOR switches, 
you may now, depending on the environmental requirements, deploy as few as just two uplinks from these same 10 TOR 
switches, which are now part of a single Virtual Chassis. Using Virtual Chassis allows you to reduce the number of uplinks 
going to the aggregation tier. Whatever number of uplinks is needed in your environment can be bundled into a LAG. If you 
have multiple aggregation switches, you will want to ensure that a LAG (ideally of equal capacity) connects each upper tier 
switch with the Virtual Chassis. To incorporate spatial redundancy, you will want to make sure that each member link within 
a given LAG is sourced from a different member switch in the Virtual Chassis. 
Using Virtual Chassis has many advantages, including simplified device management, simplified network design, higher 
resiliency and flexibility, and superior performance at a lower entry price point. Instead of having separate management IP 
addresses, separate software upgrades, and separate housekeeping on every switch, a Virtual Chassis enables you to 
manage all the switches as one logical entity. This logical switch is maintained through a single active configuration file. 
The physical placement of the member switches in a Virtual Chassis configuration is flexible. Possible deployments include 
members in a single rack, across several racks, in the same wiring closet, and spanning wiring closets across floors, 
buildings, and facilities. For the highest level of operational performance and resiliency, we recommend that all switches in a 
Virtual Chassis configuration be connected in a ring topology. For more details on Virtual Chassis for a given platform, you 
should check the technical publications and platform-specific datasheets.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–17I
Juniper Networks Design Fundamentals
Illustrating Some of the Benefits of Virtual Chassis 
This slide illustrates some of the performance-related benefits of using Virtual Chassis. As previously mentioned, when a 
Virtual Chassis is deployed at the access tier, all traffic between servers and racks connected through the Virtual Chassis is 
directly relayed through the Virtual Chassis and is not required to pass through the upper tier. In this scenario, the simplified 
design creates a more direct and efficient path for the traffic, which ultimately increases performance and user satisfaction. 
As shown on the slide, one common scenario that benefits from this increased level of performance is when virtual 
machines (VMs) must be migrated between different servers that reside in different racks. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–18 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
Layer 2 at the Access Tier? 
One of the many design choices you must make is whether to use Layer 2 or Layer 3 at the design tier. This slide illustrates 
some of the considerations when using Layer 2 in the access tier. Note that on a subsequent slide, we highlight the 
comparative differences between using Layer 2 and Layer 3 in the access tier. 
In the illustrated example, where Layer 2 is used in the access tier, the Layer 3 termination of traffic occurs at the 
core-aggregation tier. Using this design option, virtual LANs (VLANs) can span across multiple access devices including 
multiple Virtual Chassis.Some inherent challenges when using Layer 2 at the access tier include:
• Undesirable growth of the spanning tree domain; 
• An increased span of the fault containment area;
• The required inclusion of a loop-prevention mechanism; and 
• blocked spanning tree links, which result in wasted resources.
Many of the identified challenges result in an environment that can be difficult to troubleshoot as well as an environment 
with increased network convergence time. 
Continued on the next page.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–19I
Juniper Networks Design Fundamentals
Layer 2 at the Access Tier? (contd.) 
Because the illustrated environment uses Layer 2 between the access and aggregation tiers and a looped wiring topology 
exists, a loop-prevention mechanism must be deployed. The loop-prevention mechanisms available in this environment 
include Redundant Trunk Groups (RTGs) or one of the supported spanning tree protocols. Note that other options, which 
require structural modifications, also exist but are not mentioned here. 
The RTG feature eliminates the need to configure STP on the switch. It is similar to the RSTP root and alternate port 
functions, without the need for configuring RSTP. RTG is typically implemented on a switch with a dual-home connection, 
where one link becomes active and forwards traffic, while the other link is blocking the traffic and is a backup to the active 
link. It provides sub-second convergence and achieves loop prevention without a spanning tree. 
RSTP provides sub-second convergence while avoiding STP slow network convergence. While STP can take 30 to 50 seconds 
to respond to a topology change, RSTP is typically able to respond to changes within three times the Hello message interval 
(The default value is 6 seconds). MSTP builds on RSTP and provides manual distribution of load to avoid the wasted link 
resources throughout the Layer 2 environment. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–20 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
What If...? 
This slide is intended to get you thinking about the effects of a link failure within a spanning tree domain as well as other 
design options that can avoid the impact of a single failure altogether. In this case, the root port on VC1, which is a single 
connection, fails and consequently causes a change in the spanning tree structure which could impact traffic flows.
There are a number of modifications you could make, in this scenario, to reduce or eliminate the impact of such a failure. 
The easy solution is to simply increase the number of links between VC1 and the aggregation switches (Agg-1 and Agg-2) and 
make those links part of a LAG. Note that this same change should be performed on VC2 as well! 
Alternatively, you could deploy MC-LAG between Agg-1 and Agg-2 and remove STP from the access tier altogether. If MC-LAG 
were deployed, the two existing uplinks on VC1 would become member links of a common LAG that terminates on Agg-1 and 
Agg-2, which would now function as MC-LAG peers. Note that this same modification should be made on VC2! 
Another option, and the one we illustrate on subsequent slides, is to create a new Virtual Chassis at the aggregation tier. This 
design change would completely eliminate the need for STP in the illustrated environment (assuming all Layer 3 termination 
is done at the aggregation tier). 
While not covered in detail in this course, you could also implement a Virtual Chassis Fabric system, which is an emerging 
spine and leaf solution, to encompass the access and aggregation tiers. Using a Virtual Chassis Fabric system allows for 
increased scaling, when compared to the illustrated example, as well as the management benefits of a standard Virtual 
Chassis, as previously mentioned. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–21I
Juniper Networks Design Fundamentals
Simplifying the Topology Further 
While not the only option as previously mentioned, you can use Virtual Chassis in the aggregation tier to further simplify the 
illustrated environment. In this example, we make Agg-1 and Agg-2 members of a Virtual Chassis, which introduces a 
number of benefits.
Adding Virtual Chassis in the aggregation tier eliminates or minimizes control plane complexity. While you can still configure 
STP, or some kind of Layer 2 loop prevention protocol, as an added level of protection, it should not be necessary because 
the topology is now loop free. Because redundancy is built into the Virtual Chassis and the Virtual Chassis functions as a 
single logical device, you should not need to run a first hop redundancy protocol (FHRP) such as virtual router redundancy 
protocol (VRRP) at the aggregation tier. This same level of redundancy is included by simply configuring the required routed 
VLAN interfaces on the Virtual Chassis and ensuring there are multiple connections from the down stream access switches. 
Using Virtual Chassis in the aggregation tier allows you to fully utilize all uplinks from the access tier through a 
standards-based, multi-path technology, which is a cross-chassis LAG. This technology increases the effective uplink 
bandwidth, and creates a “unified virtual fabric” interconnecting all of the access tier switches.
In addition to the previously identified benefits, the number of devices to be managed is reduced making your management 
requirements a bit easier! 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–22 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
Layer 3 at the Access Tier? 
As previously mentioned, one of the many design choices you must make is whether to use Layer 2 or Layer 3 at the design 
tier. This slide illustrates some of the considerations when using Layer 3 in the access tier. Note that on a subsequent slide, 
we highlight the comparative differences between using Layer 2 and Layer 3 in the access tier. 
In the illustrated example, where Layer 3 is used in the access tier, the access switches, Virtual Chassis in this example, are 
used for Layer 3 termination. Using this design option, VLANs are restricted to the access switch or Virtual Chassis on which 
they are configured. While in some environments this restriction may not matter, in other environments it causes serious 
implications on the internal operations and mobility demands. 
Using Layer 3 at the access tier requires the use of an interior gateway protocol (IGP) such as OSPF. We recommend 
including equal-cost multipath (ECMP) routing, which provides traffic load balancing between the network tiers. The use of 
ECMP on the uplink LAGs, interconnecting the access and core tiers, replaces STP and has many advantages. These 
advantages include the following: 
• Minimized Layer 2 broadcast domain; 
• Ease of troubleshooting; 
• Deterministic behavior for minimal packet loss; 
• Automatic load balancing at a per-prefix or a per-packet level; and 
• Dynamic network optimization and path selection. 
Continued on the next page.NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–23I
Juniper Networks Design Fundamentals
Layer 3 at the Access Tier? (contd.) 
Because a single Layer 3 routing domain directs network traffic flow, any failure in the link or network device results in a 
topology change and network reconvergence across the entire network. Network path optimization happens automatically, 
resulting in network deterministic behavior, providing a consistent latency of traffic flow, and allowing easier network 
provisioning. 
In this deployment model, The access tier requires Layer 3 configuration, which includes the routed VLAN interface. You 
must also ensure that the access switches provide load balancingand full fault tolerance at the uplink level. Therefore, at 
least two links connect to the core tier from each access switching element. Each link terminates at a different core device. 
With this design, a core device failure does not impact the availability of a server that connects to the access element. In 
addition, the link-level redundancy is provided using the connections from the access switches to each core device or 
multiple, physical links that act as the LAG. The server VLANs or subnets are advertised in IGP and are not trunked to the 
core network tier. 
Also, you must evaluate the need for segmentation support, because multiple VLANs are part of the same access device, 
and, as such, might need to communicate with each other through firewall services. The core tier should run Layer 3 routing 
and multiple routing tables to support segmentation and security services. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–24 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
A Quick Comparison 
This slide provides a comparison of the key design considerations when implementing Layer 2 or Layer 3 in the access tier of 
the data center. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–25I
Juniper Networks Design Fundamentals
Provisioning Considerations 
In addition to determining if the access tier will be configured for Layer 2 or Layer 3, you must also understand what type of 
device will be attached downstream and how the port associated with that device must be configured. This slide illustrates 
these provisioning considerations. 
When working with virtualized servers, you must also understand how the server will be provisioned. One specific 
consideration relates to the virtual switch integrated into the server. You must understand, to some degree, how the 
integrated virtual switch will be configured. 
Will the network administrators manage the virtual switch or will it be manged by the system administrators? If the system 
administrators will manage the virtual switch (which is typically the case), some level of coordination will be needed between 
them and the network administrators to ensure the connectivity requirements are met.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–26 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
Think About It! 
This slide is intended to get you thinking a bit deeper about the impact of virtualization on the design of a data center. As 
mentioned earlier in this chapter, the introduction of Virtual Chassis at the access tier can have some significant impact on 
the traffic flowing between servers in different racks serviced by the same Virtual Chassis. The impact, as previously 
described, is on the flow of the traffic and its ability to bypass the aggregation tier altogether. The result of this change in 
traffic patterns may be a reduced number of uplinks to the aggregation tier. 
When using bare metal servers in a data center environment that uses Virtual Chassis at the access tier, the traffic flows 
either pass within the Virtual Chassis to another attached server or up through the access and aggregation tiers in a 
northbound direction to some other remote destination. When a data center design adds virtualized servers with virtual 
switches into the equation, traffic patterns change once again. In this case, traffic may pass between VMs through the 
virtual switch within the same virtualized server. The ending result is, once again, a likely reduction of uplinks to the 
aggregation tier or the bandwidth associated with those uplinks. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–27I
Juniper Networks Design Fundamentals
Incorporating Security 
Incorporating security into data center design is an important consideration. As data centers become larger and more 
complex, entry points into the network and areas where security vulnerabilities exist become more probable. Effective data 
center design ensures a secure environment without restricting usability for the users and business operations. 
“Trust” and “untrust” domains should be identified in the data center. Once identified, these areas provide a clear 
demarcation and make developing a security strategy easier. To protect the data center resources, network administrators 
define acceptance policies to control what can and cannot enter the network through the demarcation points to ensure 
incoming traffic complies with the established policies. Traffic from outside the data center is considered untrusted; traffic 
from within the data center is generally considered trusted. 
Traffic is evaluated and security policies are enforced for traffic entering the data center in the north to south direction. 
Traffic passing between servers in the west and east directions can also be evaluated. All visible traffic can be securely 
processed at the perimeter using high-end SRX Series devices. Note that generally speaking only traffic between Layer 3 
subnets sourced and destined within the data center is processed by the physical SRX Series devices. Layer 2 traffic sourced 
and destined within the data center is typically considered trusted and not evaluated. 
Another security consideration is for traffic passing between VMs within a virtualized server, which is also considered to be 
west and east directional traffic. The concern with this traffic is that there is, in many cases, low to no visibility, which makes 
evaluation and security policy enforcement difficult to say the least. To ensure visibility of this traffic and incorporate 
evaluation and policy enforcement, you can deploy a vSRX instance in the virtualized server. Once the vSRX VM is running in 
the virtualized server, you then configure the server’s virtual switches in such a way that all interVM traffic within the server 
is forced through the vSRX VM for evaluation and policy enforcement. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–28 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
Selecting the Device: Sample Placement 
This slide provides a visual representation of the many Layer 2 switch options provided by Juniper networks along with some 
general idea of where you might position the different switching models in the campus network and data center 
environment. Note that this illustration is only meant as a generalized positioning guide for the products shown and is not 
exact or definitive by any means. As per usual with network design and product placement, there is always some flexibility 
and in all cases it should ultimately be dictated by the customer’s needs. 
While this may be a reasonably good starting point, you should take a closer look at the product’s scaling details, hardware 
options, and software feature set to ensure you are recommending the right product and solution for the customer’s 
environment.
For more details on the EX Series switches and the QFX Series switches, please refer to the following URLs:
• EX Series switches: http://www.juniper.net/us/en/products-services/switching/ex-series/
• QFX Series switches: http://www.juniper.net/us/en/products-services/switching/qfx-series/
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–29I
Juniper Networks Design Fundamentals
Environmental Design Considerations
One step that can not be overlooked in data center design is planning the physical layout of the data center. Multiple physical 
divisions exist within the data center that are usually referred to as segments, zones, cells, or pods. Each segment consists 
of multiple rows of racks containing equipment that provides computing resources, data storage, networking, and other 
services. 
Physicalconsiderations for the data center include placement of equipment, cabling requirements and restrictions, and 
power and cooling requirements. Once you determine the appropriate physical layout, you can replicate the design across all 
segments within the data center or in multiple data centers. Using a modular design approach improves the scalability of the 
deployment while reducing complexity and easing data center operations. 
The physical layout of networking devices in the data center must balance the need for efficiency in equipment deployment 
with restrictions associated with cable lengths and other physical considerations. Pros and cons must be considered 
between deployments in which network devices are consolidated in a single rack versus deployments in which devices are 
distributed across multiple racks. Adopting an efficient solution at the rack and row levels ensures efficiency of the overall 
design because racks and rows are replicated throughout the data center.
We discuss environmental design considerations in more detail in the course Juniper Networks Design Data Center.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–30 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
Data Center Design Examples 
The slide highlights the topic we discuss next.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–31I
Juniper Networks Design Fundamentals
Data Center Architectures 
A number of data center architectures exist as shown on the slide. While some of the illustrated architectures are vendor 
neutral, others are specific to Juniper Networks and its switching products, such as the QFX5100 Series switches. Note that 
the QFX5100 Series switches can be used in all of the illustrated architectures. 
Please note that this course only covers the foundational architectures, which are based on the traditional tiered structure. 
We provide some illustrated examples of these architectures, which often incorporate Virtual Chassis or MC-LAG, on the 
proceeding slides. The other architectures, specifically Virtual Chassis Fabric, QFabric, and Layer 3 Clos, are outside the 
scope of this course. 
For technical training on Virtual Chassis Fabric (and other features related to the QFX5100 Series switches), consider 
attending the Data Center Switching (DCX) and Troubleshooting Data Center Switching (TDCX) classes. 
For technical training on QFabric systems, consider attending the Configuring and Monitoring QFabric Systems (CMQS) and 
Troubleshooting QFabric Systems (TQS) classes. 
For details on Layer 3 Clos deployments using QFX5100 Series switches, you can download an associated whitepaper at 
http://www.juniper.net/assets/us/en/local/pdf/whitepapers/2000565-en.pdf. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–32 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
Traditional Data Center Design: A Review 
This slide provides you an opportunity to review the structure of the traditional data center design. The subsequent design 
examples, shown later in this section, deviate from this structure and incorporate more efficient designs for given sets of 
requirements. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–33I
Juniper Networks Design Fundamentals
Selecting a Profile Design Template 
Experience has shown that customers have different requirements to meet their specific needs. As previously mentioned, no 
two data centers are exactly alike, however, based on the specific needs, we can generally place each data center into one of 
five unique profile solution templates. We will use these templates as a starting point for placing the customer into the 
proper scenario. The five main profile solution templates for data centers are as follows: 
• Transactional; 
• Mid-Tier;
• Enterprise IT;
• High Performance Computing (HPC); and 
• Content and Services hosting.
Each of the referenced templates consists of three key dimensions. One dimension is functionality and what kind of features 
can be supported—advanced security, advanced availability, advanced routing functions, and so on. Another dimension is 
cost—capital expenditure (CapEx), operating expenditure (OpEx), as well as total cost of ownership (TCO) in terms of 
managing infrastructure in a period of 3 to 5 years. The third dimension is performance—how fast the network is, along with 
latency and over subscription concerns. 
Continued on the next page.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–34 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
Selecting a Profile Design Template (contd.) 
Assessing the customer’s requirements and understanding what is most important to them will help you identify their 
respective position and data center needs using the three referenced dimensions. For example, if your customer has a 
production network and is concerned with financial applications, you will want to describe how performance is going to be 
very important for them. As for functionality, basic functionality should be all they require for this type of data center. They 
probably do not require advanced routing technologies, as long as they get the basic security and basic availability functions, 
they are willing to trade off costs for performance. 
As another example, looking at the functionality dimension of the IT data center, a customer might not require high speed 
but they might require advanced functions to support their IT infrastructure—but cost is always going to be kept in mind 
because they are most likely going to manage the infrastructure for several years to come. Managing costs in their 
infrastructure is going to be important for them. In that sense, for IT data centers, cost is going to drive an opportunity, 
functionality is next, and then performance might be of lowest importance. 
The next several slides provide some sample design architectures for each of the identified profile solution templates. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–35I
Juniper Networks Design Fundamentals
Transactional Data Center
The slide shows a sample architecture for the transactional data center profile solution template. Transactional data centers 
rely on high-performance, high data-rate computation for their business success. A transactional data center will require a 
lot of 10GbE deployments in terms of the access technology. The requirements are going to be ultra low latency switches and 
low jitter. The latency has to be consistent across the ports and across the packet sizes. Transactional data centers might be 
scaling up to 1,000 10GbE servers per POD or in a site—perhaps even more than 10,000 in a site. While scaling upwards, 
transactional data centers are always looking at building high performance infrastructure. Most important for the 
transactional data center in terms of features are security as well as providing virtualization so that they can provide a simple 
operational model. 
Space is going to be a concern for transactional data centers because they are going to be collocating in a data center that is 
close to the exchange or it might be in a HPC deployment where space is going to be constrained. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–36 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
Mid-Tier Data Centers
The slide depicts the mid-tier data center template, which is typically a small IT data center. Mid-tier data centers are 
challenged to keep up with the dynamic pace of innovation. This, along with resource constraints, means that in order to 
enjoy the benefits of technology innovation, they need a network that isfast, reliable, and easy to use and manage. 
In this deployment, the customer is creating an infrastructure with a mix of a 10GbE and 1GbE connections. The customer 
might be looking for flexibility in terms of what kind of servers they want to use or what kind of line cards they want to 
choose—but the scale is going to be limited to approximately 500 to 600 servers.
Virtual Chassis technology on the EX Series or QFX Series switches is the recommended solution for mixed 1GbE and 10GbE 
environments. Virtual Chassis technology allows multiple interconnected switches to operate as a single, logical device. This 
dramatically reduces the number of managed devices, links, and layers in the data center, delivering a highly efficient, 
high-performance network. Virtual Chassis members can even be spread over large distances—up to 80 km—to further 
simplify multisite management operations. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–37I
Juniper Networks Design Fundamentals
Enterprise Data Centers
The slide depicts the traditional two-tier enterprise data center template, which is larger than the mid-tier data center 
previously illustrated. At this scale, the requirements are greater. The scale will involve a large number of users, 
high-availability is going to be an important requirement, and typically multiple data centers are present. The workload 
migration between the data centers, such as storage and convergence, is going to be important for the customer. Enterprise 
data centers are typically not just 1GbE or 10GbE; a mix of both types of connections is always present. 1GbE connections 
will be predominant, but there is a need for 10GbE and this need continues to grow. Juniper offers multiple options for this 
architecture. 
The EX8200 or EX9200 are ideal for the core. If EX8200 is selected, you may want to simplify the design by incorporating 
Virtual Chassis. If EX9200 is selected for the core, MC-LAG should be used to simplify tier interconnects. In the access layer, 
for connectivity to 1GbE servers you can use the EX Series or QFX Series, both of which are Virtual Chassis capable. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–38 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
HPC Data Center—1GbE Servers
For HPC deployments needing connectivity for a large number of 1GbE servers and a small number of 10GbE servers, the 
EX Series Virtual Chassis can be used in the access layer. Customers can deploy about 400 servers in a single-tier design 
using a Virtual Chassis, but if they move to two tiers, using EX9200 Series switches in the core, they can support close to 
10,000 servers. For the WAN edge, the MX routers can provide the connectivity needed.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–39I
Juniper Networks Design Fundamentals
HPC Data Center 10GbE Servers
HPC requires a non-blocking core and access connectivity. Most of the deployments for HPC are moving toward 10GbE—a 
large scale of 10GbE capacity in the access layer is required, along with a low over subscription ratio as well. The over 
subscription ratio requirement from the access layer to core or from the servers to the access layer, is very low because the 
customer needs non-blocking HPC.
Juniper’s recommendation for this type of deployment is to use QFX Series switches in a Virtual Chassis in the access layer 
and EX9200 Series switches in the core. The interconnect between the access and core tiers can be made using MC-LAG 
with redundant EX9200 Series switches functioning as MC-LAG peers.
The WAN edge can use the MX80 and for larger deployments you can us the larger MX Series routers for both WAN edge and 
as data center interconnectivity devices. In some cases, HPC customers might have multiple data centers. If they want to 
interconnect between multiple data centers, the MX Series routers can also provide the data center interconnect (DCI) 
functionality.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–40 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
Content and Hosting Services Data Centers
A content and hosting services data center deployment is ideally suited for content providers, hosting providers, and 
Everything as a Service (XaaS) services firms. This solution can support dozens to tens of thousands of servers, connected 
with converged I/O links and full redundancy for agility, resiliency, and high performance. The key requirement for the 
customer in this scenario is a need for the resources to be more dynamic. The workload has to be very dynamic because the 
workload could be moving across different segments. The security policies also need to be dynamic because the customer 
might be hosting multiple customers on a single infrastructure. 
For content and hosting providers, convergence is also important if they want to converge their storage and the WAN 
infrastructure. Scaling up to thousands of 10GbE servers or perhaps tens of thousands of 1GbE servers might also be a 
requirement of content and hosting providers. A mix of 10GbE and 1GbE will still be present, however the majority of content 
and hosting providers are deploying 10GbE servers. 
The data center infrastructure for content and hosting services scales modularly to satisfy the capacity requirements of a 
variety of hosting providers and the inevitable growth in demand for their services. The basic compute point of delivery (POD) 
network infrastructure is constructed of EX Series Virtual Chassis and QFX Series server access switches connected through 
EX9200 core switches. 
MX Series routers can interconnect PODs and locations in a seamless manner such that operationally all locations are 
similar, and connectivity maintained at Layer 2 or Layer 3 as desired.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–41I
Juniper Networks Design Fundamentals
We Discussed:
• Components of the data center;
• Best practices and consideration for designing data centers; and
• Architectural design options for the data center.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–42 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
Review Questions
1.
2.
3.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–43I
Juniper Networks Design Fundamentals
Lab: Creating the Design—Data Center
The slide provides the objective for this lab.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–44 • Creating the Design—Data Center www.juniper.netI
Juniper Networks Design Fundamentals
Answers to Review Questions
1.
The main difference between these two data center categories is that IT data centers are more of a cost center and need to control costs 
whereas production data centers are more of a profit center and need to generate revenue. Production data centers are important to the 
profitability of a business. 
2.
Using Virtual Chassis has many advantages, including simplified device management, simplified network design, higher resiliency and 
flexibility, and superior performance at a lower entry price point.
3.
When compared to a Layer 2 deployment, using Layer 3 at the access tier offers lower network convergence and reduced complexity. 
Some potential challenges include an inherent restriction of a the broadcast domains, which are contained to a switch or Virtual Chassis 
within the access tier and limited Layer 2 mobility, which means Layer 2 broadcast domains are confined to a set of access devices.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Creating the Design—Data Center • Chapter 8–45I
Juniper Networks Design FundamentalsNT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 8–46 • Creating the Design—Data Center www.juniper.netI
HA
RE
Juniper Networks Design Fundamentals
Chapter 9: Business Continuity and Network Enhancements
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
S
IN
T
Juniper Networks Design Fundamentals
We Will Discuss:
• Business continuity and its importance in a network;
• High availability design considerations and best practices; and
• An overview of high availability offerings and solutions.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 9–2 • Business Continuity and Network Enhancements www.juniper.netI
Juniper Networks Design Fundamentals
Business Continuity Planning
The slide lists the topics we will discuss. We discuss the highlighted topic first.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Business Continuity and Network Enhancements • Chapter 9–3I
Juniper Networks Design Fundamentals
What Is Business Continuity?
Today, more than ever, all sizes of enterprise businesses are becoming dependent on a variety of applications and resources 
used to access, store, and process critical information for business functions. Business continuity (BC) is an organization’s 
need to ensure that essential functions can continue during and after a disaster, including the prevention of interruption to 
mission-critical services, and the ability to reestablish full functionality as quickly as possible. Ideally, continuity planning 
should be proactively built into the network design from the beginning. In practice, some might confuse disaster recovery 
(DR) with business continuity but do not make this mistake. Disaster recovery, while certainly a part of business continuity, is 
much more reactive and slower paced in nature, involving things like turning up a cold backup server or reloading previously 
backed up data.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 9–4 • Business Continuity and Network Enhancements www.juniper.netI
Juniper Networks Design Fundamentals
Business Continuity Planning: Part 1
Depending on your enterprise, creating a BC plan can be tremendously complex. However, it is vital to the organization’s 
longevity that one is created. Unfortunately, there are no cookie-cutter templates, and one size does not fit all. There are 
some common elements among plans, but every plan will be different because every organization’s structure and 
circumstances are unique.
This leads us to the first step – know your network. You must have a thorough understanding of your network if you are to 
determine which functions and services are critical and how their downtime would likely affect your network and customers. 
Typically, this is determined by performing a Business Impact Analysis which can help to answer such questions as:
• Which functions and services are critical to the company’s survival?
• The cost of both partial and full outages. Downtimes costs money.
• How long could an outage be sustained?
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Business Continuity and Network Enhancements • Chapter 9–5I
Juniper Networks Design Fundamentals
Business Continuity Planning: Part 2
Risk assessment is a determination of the chance of something happening that will impact your customer’s business in 
some way. Not all hazards are created equal, therefore, most are considered in terms of likelihood and impact. It is vital that 
each type of risk is taken into account, and a choice made, if said risk requires a mitigation plan of some type or can be 
safely ignored.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 9–6 • Business Continuity and Network Enhancements www.juniper.netI
Juniper Networks Design Fundamentals
Business Continuity Planning: Part 3
Now that the contingencies have been assessed and an impact analysis completed, it is time to develop a plan of action to 
mitigate each type of risk. Depending on the type risk, these will range from simple to exceedingly complex. Furthermore, you 
cannot plan for every scenario. This is where you use the risk assessment to plan for the most likely scenarios within the 
customer’s budget.
Regarding WAN design:
• You must consider redundant paths and providers, if possible.
• Moreover, you must consider the service providers’ continuity plans as well. It does not make much sense to 
implement local plans if the service provider has no plans of its own.
In addition to the standard networking paradigms of redundancy and resiliency, campus and branch locations must account 
for:
• If staff cannot physically make it to work, plan for telecommuting as a possibility.
• Lack of primary staff due to an unforeseen event. Ensure the network is simple enough, or documented well 
enough, that a secondary staff could operate it.
Continued on the next page.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Business Continuity and Network Enhancements • Chapter 9–7I
Juniper Networks Design Fundamentals
Business Continuity Planning: Part 3 (contd.)
More and more, continuity planning focuses heavily around data centers. Regarding data centers, questions to ask yourself 
include:
• Will the customer have geographically diverse actively redundant data centers or will they have a primary data 
center and one or more cold standby backup data centers? If geographically diverse, how far apart should they 
be to maintain an acceptable latency between them?
• Will they host their own servers and applications or will the host them virtually in the cloud? If hosted virtually, 
what sort of continuity plan does the hosting company maintain?
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 9–8 • Business Continuity and Network Enhancements www.juniper.netI
Juniper Networks Design Fundamentals
Business Continuity Planning: Part 4
Now that the plan is written, it is time to test it. Before a plan can be tested, staff must be notified and also be familiar with 
what is expected of them for a given scenario. The actual tests can be theoretical or, better yet, they can be full-fledged live 
exercises. 
Checking your Work
After running your test, you must:
• Review: Look at what happened, why it happened, and figure out how to ensure that it won’t happen again. 
Could it have been prevented? What procedures worked well? What systems did not function well? Could these 
have been prevented?
• Revise: The continuity plan is a living document and, thus, needs to be revised to accommodate deficiencies in 
the plan or new additions.
• Retest: As the cycle on the slide shows, business continuity is an ongoing process. It is vital that continuity 
planning be reviewed and tested regularly to ensure it remains up to date and effective.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Business Continuity and Network Enhancements • Chapter 9–9I
Juniper Networks Design Fundamentals
High Availability Design Considerations and Best Practices
The slide highlights the topic we discuss next.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 9–10 • Business Continuity and Network Enhancements www.juniper.netI
Juniper Networks Design Fundamentals
High Availability Principles
High availability consists of a few simple principles:
• Remaining accessible if any given component fails
• Degrading gracefully during a failure
• Recovering automatically (without manual intervention, if possible)
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Business Continuity and Network Enhancements • Chapter 9–11I
Juniper Networks Design Fundamentals
Resiliency
When you ask a customer for their uptime requirements, they typically always say no downtime is acceptable; however in 
reality, there will always be some downtime. Customers plan for known and unknown downtime and target an availability for 
the network. Migrations and changewindows are often tied to scheduled downtime based on the enterprise’s availability 
profile. 
Factors that Affect Network Update
The following list, also shown on the slide, represents some factors that can affect the uptime of the network:
• Power outage;
• WAN failure;
• Device power supply failure;
• Device failure;
• Device firmware upgrades or reboots; and 
• Planned outages (for upgrades or migrations).
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 9–12 • Business Continuity and Network Enhancements www.juniper.netI
Juniper Networks Design Fundamentals
Calculating Downtime Based on Availability
The table shows the total downtime per year, month, and week based on various availability profiles from “one to six nines”. 
Three nines (99.9%) availability means only 10 minutes of total downtime per week (planned and unplanned).
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Business Continuity and Network Enhancements • Chapter 9–13I
Juniper Networks Design Fundamentals
Building a Highly Resilient Network
Addressing the resiliency and network availability requirements of a network can require one or more of the following:
• Link-level redundancy such as multiple WAN connections and uplink ports.
• Physical-device redundancy such as backup devices, high-availability (HA) clusters, virtual chassis, and stateful 
failover for firewall platforms; and
• Device-level redundancy such as hot-swappable interface cards, chassis components, and power supplies.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 9–14 • Business Continuity and Network Enhancements www.juniper.netI
Juniper Networks Design Fundamentals
Link-Level Redundancy
A backup WAN Link makes sense anytime your service provider cannot or does not meet their service-level agreement (SLA). 
If your target availability is greater than that of the provider or you have had previous poor experiences with that provider, 
consider, preferably from a different provider.
The need for a second link is especially true when your enterprise relies on VoIP or Unified Communications to work. A 
backup link allows you to preserve the full UC experience without complex PSTN-based failover techniques or Survivable 
Remote Telephony. 
For some enterprises, where any downtime means lost revenue, the cost of a second link is less then the cost of downtime. 
In these situations, it makes business sense to add a second WAN link. The increased availability of business-class, 
high-speed Internet has reduced the costs of a second-link considerably making this point more relevant. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Business Continuity and Network Enhancements • Chapter 9–15I
Juniper Networks Design Fundamentals
Physical Device Redundancy
A redundant gateway device makes sense for customers with the highest levels of availability requirements (three nines or 
above). Enterprises that cannot afford downtime due to firmware upgrades or device reboots can also benefit, because the 
backup device will become active during these times, allowing upgrades without downtime.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 9–16 • Business Continuity and Network Enhancements www.juniper.netI
Juniper Networks Design Fundamentals
Device Level Redundancy
Redundant power makes sense any time two power sources are available. Also, when a two-device HA solution is not used 
due to cost or complexity, redundant chassis components can offer device-level resiliency.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Business Continuity and Network Enhancements • Chapter 9–17I
Juniper Networks Design Fundamentals
High Availability Offerings and Solutions
The slide highlights the topic we discuss next.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 9–18 • Business Continuity and Network Enhancements www.juniper.netI
Juniper Networks Design Fundamentals
Using VRRP in Network Design
The Virtual Router Redundancy Protocol (VRRP) is a standards-based (RFC 2338) election protocol that can facilitate 
redundancy in a LAN environment and eliminate the single point of failure highlighted on the previous slide. VRRP elects one 
of the participating routers (known as VRRP routers) to function as gateway device, while all other VRRP routers serve in a 
backup capacity. All communications between VRRP routers occur through a common switch. 
VRRP is supported on EX Series switches and MX Series routers, and is most commonly found in Ethernet environments but 
can also be used in LAN environments that use Token Ring or Fiber Distributed Data Interface (FDDI).
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Business Continuity and Network Enhancements • Chapter 9–19I
Juniper Networks Design Fundamentals
Using Chassis Clustering in Network Design
Another HA solution that SRX Series devices support is chassis clustering. With a chassis cluster, it is possible to have two 
identical SRX series devices connected together to form a single logical device, providing redundancy in case of a failure in 
one of the two nodes or their surroundings. Chassis clustering can be used in different topologies and together with various 
other features, provide the desired failover functionality and redundancy. A chassis cluster consists of two identical SRX 
devices that work together to provide stateful failover of processes, services and traffic flow. In case a failure occurs in one 
of the nodes, this is detected and, as needed, a failover to the other node occurs. This allows the continued forwarding of 
traffic. The cluster nodes are connected together with two logical links called a control link and fabric link. The Junos OS 
periodically transmits heartbeat signals over the control link to determine the health of the control link. The fabric link is 
used for the HA data plane.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 9–20 • Business Continuity and Network Enhancements www.juniper.netI
Juniper Networks Design Fundamentals
The Small Branch
The small branch allows consolidating of all routing, switching, and security into a single device—the branch SRX device—at 
the branch location. However, it allows one or more EX Series switch or generic Layer 2 switch to increase the total number 
of switch ports as needed. Onboard switching on the SRX device can still be used with this design.
For this solution any branch SRX device, SRX100 through SRX650, might be used. Regarding HA, the design supports 
multiple WAN connections with WAN failover, as well as policy-based routing across the WAN links.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Business Continuity and Network Enhancements • Chapter 9–21I
Juniper Networks Design Fundamentals
The HA Small Branch
The HA small branch allows consolidation of all routing and security into a cluster of SRX devices with a single management 
interface. For this solution, you must use an SRX210 through SRX650, because HA is not offered on the SRX100. A separate 
EX Series switch (or generic Layer 2 switch) is used to provide all LAN connectivity to endpoints, and to both branch SRX 
devices. If multiple WAN connections are used, a single WAN connection should terminate to each SRX device. Active/
passive or active/active HA can be used. Finally, the design supports multiple WAN connections with WAN failover, as well as 
policy-based routing across the WAN links.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 9–22 • Business Continuity and Network Enhancements www.juniper.netI
Juniper Networks Design Fundamentals
i
The HA Large Branch
The HA large branch allows consolidation of all routing and security into a cluster of SRX devices with a single management 
interface. For this solution, you must use an SRX210 through SRX650, because HA is not offered on the SRX100. A separateEX Series switch (or generic Layer 3 switch) is used to provide all LAN connectivity to endpoints, and to both branch SRX 
devices. If multiple WAN connections are used, a single WAN connection should terminate to each SRX device. Active/
passive or active/active can be used and Layer 3 routing protocols can be used between the SRX devices and EX Series 
switches such as OSPF with static link costing. EX Series switches can be deployed across the branch using Virtual Chassis 
cables or 10 Gigabit Ethernet fiber interconnects. As with the other designs, multiple WAN connections with WAN failover are 
supported, as well as policy-based routing across the WAN links.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Business Continuity and Network Enhancements • Chapter 9–23I
Juniper Networks Design Fundamentals
A Potential Problem
While operational continuity is a top priority, it is not guaranteed simply by adding multiple, bundled connections between the 
compute resources (servers) and their attached access switch. This design, while improved over a design with a single link, still 
includes potential single points of failure including the access switch and the compute device.
While the survivability of compute resources can be handled through the duplication of the impacted resources on some other 
physical device in the network, typically done through virtualization technologies, the access switch, in this deployment model, 
remains a single point of failure and prohibits the utilization of the attached resources.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 9–24 • Business Continuity and Network Enhancements www.juniper.netI
Juniper Networks Design Fundamentals
A Solution
To eliminate the access switch as being a single point of failure in the data center environment, you can use multichassis 
link aggregation. Multichassis link aggregation builds on the standard LAG concept defined in 802.3ad and allows a LAG 
from one device, in our example a server, to be spread between two upstream devices, in our example two access switches 
to which the server connects. Using multichassis link aggregation avoids the single point of failure scenario related to the 
access switches described previously and allows operational continuity for traffic and services, even when one of the two 
switches supporting the server fails.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Business Continuity and Network Enhancements • Chapter 9–25I
Juniper Networks Design Fundamentals
Common MC-LAG Positioning Scenarios
As previously mentioned, multichassis link aggregation groups (MC-LAGs) are very useful in a data center when deployed at 
the access layer, which connects to the compute resources. These deployment scenarios at the access layer are performed 
on select EX Series switches and the QFX Series switches, which are designed for and positioned in the data centers as top 
of rack (TOR) switches. In addition to the access layer, MC-LAGs are also commonly deployed at the core layer, which is 
commonly supported by the EX9200 Series switches or the MX Series routers. 
While the illustrated scenarios are the most common deployments of MC-LAG in the data center, MC-LAGs have also been 
used at the distribution layer. Our focus throughout this chapter is at the access layer where the QFX5100 Series switches 
are well positioned as TORs. Note that the CLI syntax used to deploy MC-LAGs on MX Series routers and QFX Series switches 
may differ. We recommend that you consult the technical documentation for support and deployment details when 
implementing MC-LAG on the MX Series routers. 
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 9–26 • Business Continuity and Network Enhancements www.juniper.netI
Juniper Networks Design Fundamentals
Campus Redundancy Best Practices
Campus and branch redundancy should encompass both the LAN and wireless networks, because the wireless network is 
becoming more and more important in the day to day operations for many companies. Multiple links should be used to 
connect devices. Technologies like Juniper’s Virtual Chassis allow for multiple links between devices that are connected 
across separate switches for redundancy. However, the multiple links can still act like a single aggregated link or LAG. Virtual 
Chassis technology can help eliminate complexities like spanning tree, First Hop Redundancy Protocol (FHRP), or other 
routing protocols and still provide redundancy.
Wireless access points (APs) can be clustered to provide seamless failover and no interruption of applications in case of 
failure. The density of APs should be implemented as appropriate to the business needs.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Business Continuity and Network Enhancements • Chapter 9–27I
Juniper Networks Design Fundamentals
Recommended Redundancy Example
The illustration on this slide shows the recommended link-level and device-level redundancy in the context of a three-tier 
design. Redundant interconnections between access, aggregation, and core tiers should be provided (all of these examples 
use at least two 10 Gigabit Ethernet LAG links to provide redundancy). Redundant nodes in the aggregation tier provide 
device-level redundancy, while redundant interconnects between aggregation and core tiers eliminate a single potential 
point of failure. A Layer 3 triangle link configuration is recommended between the core and aggregation tiers. Redundant 
core devices with a fully meshed connectivity to the Internet or WAN routers eliminate a single potential point of failure in the 
core.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 9–28 • Business Continuity and Network Enhancements www.juniper.netI
Juniper Networks Design Fundamentals
Virtual Chassis in Network Design
Virtual Chassis provides a simple way of interconnecting multiple switches into a ring topology and managing those 
interconnected switches as a single device. You can, for example, connect four switches, each with 48 ports, into one Virtual 
Chassis with 192 ports. (A Virtual Chassis scales to ten devices.) The devices can be on a single rack or in different locations 
that can be connected with long-distance optical cabling.
Virtual Chassis Benefits
Virtual Chassis is managed from a single IP address, eliminating the need to have an IP address for each device. Traffic can 
easily be redirected within a Virtual Chassis when a member device fails, increasing fault tolerance. Virtual Chassis 
simplifies network topology by minimizing or eliminating the need for loop prevention protocols like Spanning Tree Protocol 
(STP). 
What does Virtual Chassis Solve?
Virtual Chassis solves a problem of complex management. It is optimized for traffic that is directionally North-South traffic, 
for example, between a user and an application. It is optimized for deployment in campus or enterprise networks.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Business Continuity and Network Enhancements • Chapter 9–29I
Juniper Networks Design Fundamentals
Virtual Chassis Positioning: Campus (Small to Medium)
VC allows your customer to simplify their enterprise networks. Small to medium-sized campuses (up to 5,000 access ports) 
can collapse their aggregation and core layers using VC positioning as shown on the slide. Fewer 10GbE uplinks are required 
when using this solution. Up to 10 Juniper Networks EX3300, EX4200, EX4300, EX4500, and EX4550 Ethernet Switches, in 
any combination, can be interconnected using VC technology—further simplifying the network by reducing the number of 
managed devices. Alternatively, up to four EX2200 switches with Virtual Chassis technology can be interconnected in 
low-density wiring closets.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 9–30 • Business Continuity and Network Enhancements www.juniper.netIJuniper Networks Design Fundamentals
What Is a Virtual Chassis Fabric?
Virtual Chassis Fabric (VCF) evolves Virtual Chassis by allowing customers to interconnect multiple switches into a 
spine-and-leaf fabric architecture and manage the interconnected switches as a single device. VCF provides many of the 
benefits of a Virtual Chassis while supporting up to 32 devices. VCF works well for small data centers in which the Point of 
Delivery (POD) size could be as large as 30 racks, and can still be managed from a single device for the entire fabric.
Benefits of VCF
Virtual Chassis Fabric uses many of the same principles of Virtual Chassis, but it is purpose-built for data center traffic that 
requires predictable and consistent performance for virtualized and non-virtualized workloads. 
VCF has the following attributes:
• It has a deterministic latency between any two endpoints within the fabric.
• It has a deterministic performance between any two points within the fabric.
• It supports workload mobility—any workload, anywhere in the fabric—without impacting performance.
• All host nodes within the fabric are equal distance, equal hops, from each other.
• VCF has a single point of management.
• Once VCF has been deployed, you can automate a variety of day-to-day management tasks using many tools, 
such as Puppet, Chef, Ansible, Python, and Junos Space.
Continued on the next page.NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Business Continuity and Network Enhancements • Chapter 9–31I
Juniper Networks Design Fundamentals
Benefits of VCF (contd.)
The following is a continuing list of VCF attributes:
• VCF allows customers that have maximized the port capacity of a Virtual Chassis to expand it without having to 
remove the existing, previously-purchased devices of that Virtual Chassis.
• It supports data centers that contain a mix of 1Gbps, 10Gbps, and 40Gbps Ethernet interfaces.
What does VCF Solve?
Virtual Chassis Fabric tackles complex management by providing connectivity for applications within data centers. This 
machine-to-machine, or application-to-application traffic, also referred to as East-West traffic, is in addition to the 
North-South traffic between data center and user. East-West traffic often lives on virtual machines (VMs) and as these VMs 
move, overall performance still needs to be predictable and deterministic. In order to optimize bandwidth for the growing 
amount of East-West traffic and support workload mobility, VCF uses a three-stage Clos spine-leaf topology optimized for 
data centers.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 9–32 • Business Continuity and Network Enhancements www.juniper.netI
Juniper Networks Design Fundamentals
VCF—The Big Picture
The slides shows a fully loaded VCF with 4 Spine nodes and 16 Leaf nodes. Remember, to the outside world (anything 
outside of the rectangle on the slide) the VCF appears to be a standalone switch. The slides demonstrates the typical 
connectivity in the northbound and southbound directions of a VCF.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Business Continuity and Network Enhancements • Chapter 9–33I
Juniper Networks Design Fundamentals
We Discussed:
• Business continuity and its importance in a network;
• High availability design considerations and best practices; and
• An overview of high availability offerings and solutions.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 9–34 • Business Continuity and Network Enhancements www.juniper.netI
Juniper Networks Design Fundamentals
Review Questions
1.
2.
3.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Business Continuity and Network Enhancements • Chapter 9–35I
Juniper Networks Design Fundamentals
Answers to Review Questions
1.
The four stages of business continuity planning are to know your network, assess the risks, formulate the plan, and test the plan.
2.
Highly resilient networks consist of some form of link-level redundancy, device-level redundancy, and physical device redundancy.
3.
A Virtual Chassis is two or more switches that are connected using either special backplane cables, or using the front port of 1 Gigabit 
Ethernet or 10 Gigabit Ethernet uplinks interconnected, enabling switches to operate as one logical system.
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
Chapter 9–36 • Business Continuity and Network Enhancements www.juniper.netI
Acronym List
AAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authentication, Authorization, and Accounting 
ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .access control list
AP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . access point
API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .application programming interface 
ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Resolution Protocol 
ASIC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .application-specific integrated circuit
ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Asynchronous Transfer Mode 
BC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . business continuity
BCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Best Current Practices
BOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .bill of materials
BoR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bottom-of-rack
BPDU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bridge protocol data unit
BYOD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bring-your-own-device
CapEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .capital expenditures
CE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . customer edge
CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .command-line interface
COS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . class of service
CPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cells per secondCRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customer Relationship Management
CSV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . comma-separated variable
DCI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . data center interconnect
DMZ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . demilitarized zone
DNS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domain Name System
DPI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Deep Packet Inspection
DR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . disaster recovery
DSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .digital subscriber line
EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Extensible Authentication Protocol
ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . equal-cost multipath
ECR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Energy Consumption Rating
EER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . energy efficiency ratio
EMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . enterprise management system
EoR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . end-of-row
ESP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Encapsulating Security Payload
EVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ethernet VPN
FDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fiber Distributed Data Interface
FHRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .First Hop Redundancy Protocol
GRES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . graceful Routing Engine switchover
GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .graphical user interface
HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .high availability
HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .high-availability
HPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . high performance computing
HTML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hypertext Markup Language
HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hypertext Transfer Protocol over Secure Sockets Layer
HVAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . heating ventilation and cooling
IaaS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Infrastructure as a Service
IBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . internal BGP
IDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .intrusion detection and prevention
IEEE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Institute of Electrical and Electronics Engineers
IGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . interior gateway protocol
IKE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Key Exchange
IPS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . intrusion prevention system
IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Security
IMIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Internet mix
ISP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet service provider
JSA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Juniper Networks Secure AnalyticsNT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Acronym List • ACR–1I
JTAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Juniper Technical Assistance Center
LAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . link aggregation group
LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lightweight Directory Access Protocol
LLDP-MED. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Link Layer Discovery Protocol–Media Endpoint Discovery
LSYS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . logical systems
MAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .media access control
MC-LAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . multichassis link aggregation group
MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Main Distribution Area
MIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modular Interface Controller
MMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . multimode fiber
MoR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .middle-of-rack
MPC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modular Port Concentrator
MPO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . multifiber push-on
MSS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .maximum segment size
MSTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Multiple Spanning Tree Protocol
MTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mechanical transfer pull-off
MTU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . maximum transmission unit
NAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . network access control
NAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . networked attached storage
NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Address Translation
NIC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .network interface card
NMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .network management system
NSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Network and Security Manager
NSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . nonstop active routing
NVF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Virtualization Function
OCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Open Compute Project Foundation
OpEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .operational expenditures
PCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Payment Card Industry
PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . provider edge
POD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . point of delivery
PoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Power over Ethernet
PoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . point-of-sale
PVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . permanent virtual connection
QoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . quality of experience
QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . quality of service
QSFP+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .quad small form-factor pluggable plus
REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . representational state transfer
reth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . redundant ethernet
RF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . radio frequency
RMON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . remote monitoring
RSTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Rapid Spanning Tree Protocol
RFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Request for Information
RFP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Request for Proposal
ROC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . report on compliance
ROI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . return of investment
RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . remote procedure call
RPM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . real-time performance monitoring
RTG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Redundant Trunk Group
SAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .storage area network
SCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . secure copy protocol
SEIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security Information and Event Management
SFP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .small form-factor pluggable
SFP+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .small form-factor pluggable plus
SMF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . single mode fiber
SLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .service-level agreement
SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . service-oriented applications
SME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .subject matter expert
SOX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Sarbanes-Oxley
STP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Spanning Tree Protocol
TCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . total cost of ownershipNT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
ACR–2 • Acronym List www.juniper.netI
TCP-MSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transmission Control Protocol maximum segment size (TCP-MSS
ToR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .top-of-rack
TTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . time to restore
UC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . unified communications
UCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . unified communications and collaboration
UTM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unified Threat Management
VAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Value Added Services
VC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Chassis
VIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . virtual IP address
VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .virtual LAN
VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .virtual machine
VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . voice over IP
VPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Virtual Private Cloud
VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . virtual private LAN services
VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . virtual private network
VR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . virtual router
VRID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . virtual router identifier
VRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . virtual routing and forwarding
VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . virtual router redundancy protocol
VSTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VLAN Spanning Tree Protocol
WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Wide Area Network
WDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . wavelength-division multiplexing
XaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Everything as a Service
XFP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . small form-factor pluggable transceivers
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
www.juniper.net Acronym List • ACR–3I
NT
ER
NA
L 
US
E 
ON
LY
 —
 D
O 
NO
T 
SH
AR
E
ACR–4 • Acronym List www.juniper.netI
	Student Guide Volume 1 of 2
	Contents
	Course Overview
	Course Agenda
	Document Conventions
	Additional Information
	Chapter 1: Course Introduction
	Chapter 2: Network Design Fundamentals
	A Need for Network Design
	Knowledge Is King
	A Proposed Design Methodology
	A Reference Network
	Chapter 3: Understanding Customer Requirements
	RFP Requirements
	Scoping the Design Project
	Analyzing the Data
	Lab: Understanding Customer Requirements
	Chapter 4: Organizing the Data
	Processing the Data and Requests
	Identifying Boundaries and Scope
	DesignProposal Considerations
	Chapter 5: Securing the Network
	Why Secure the Network?
	Security Design Considerations
	Chapter 6: Creating the Design—Campus
	The Campus Network: An Overview
	Best Practices and Considerations
	Architectural Design Options
	Lab: Creating the Design—Campus
	Chapter 7: Creating the Design—WAN
	The WAN: An Overview
	Best Practices and Considerations
	WAN Design Examples
	Lab: Creating the Design—WAN
	Chapter 8: Creating the Design—Data Center
	The Data Center: An Overview
	Best Practices and Considerations
	Data Center Design Examples
	Lab: Creating the Design—Data Center
	Chapter 9: Business Continuity and Network Enhancements
	Business Continuity Planning
	High Availability Design Considerations and Best Practices
	High Availability Offerings and Solutions