IMPLEMENTATION GUIDE
Copyright © 2010, Juniper Networks, Inc. 1
DEPLOYING FIXED-CONFIGURATION AND CHASSIS-BASED EX SERIES ETHERNET SWITCHES IN CAMPUS LANS
2 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Three-Tiered Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Distributed Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Routed Network or Switched Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Campus Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Management Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Securing the Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Firewall Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Switch Management and Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
J-Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Juniper Networks Network and Security Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
sFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Bootp/DHCP Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Spanning Tree Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Loop Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Root Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
BPDU Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
RTG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Inter-VLAN Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
OSPF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
Three-Tiered Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Two-Tiered Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Multicast Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
GRES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
LAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Virtual Router Redundancy Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Port Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
VLAN Membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Apply-Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Port Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
LLDP/LLDP-MED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
802.3ah (Similar to Cisco’s Unidirectional Link Detection) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Copyright © 2010, Juniper Networks, Inc. 3
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Table of Figures
Figure 1: Traditional three-tiered network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Figure 2: Collapsing the aggregation layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Figure 3: Virtual Chassis technology reduces the number of uplinks and managed devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Figure 4: Distributed switching at the core/aggregation layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Figure 5: Routing to the aggregation layer in both a three-tiered and two-tiered architecture . . . . . . . . . . . . . . . . . . . . . . . . 8
Figure 6: Routing to the access layer in both a three-tiered and two-tiered architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Figure 7: Features to be configured for a three-tiered network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 8: MSTP allows VLAN load balancing so that all links are forwarding
and the network still remains loop-free . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 9: RTG before and after a primary link failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Figure 10: Logical representation of OSPF hierarchical area domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Figure 11: The host MAC address on the redundant box ages out, which causes
an unknown unicast flooding until the box re-ARPs for the IP address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figure 12: In a Virtual Chassis configuration, interconnected EX4200 switches act like a chassis-based system. Up to 10
switches can be interconnected to form a Virtual Chassis configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 13: LAG can be formed between any devices that have the LAG capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 14: Logical representation of VRRP between L3 switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 15: Switch divided into logical VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 16: Independent LAN connections for PC and IP phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 17: Hacker posing as the gateway (man-in-the-middle attack) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figure 18: EX Series CoS model for classification, queuing, and scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
MVRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Port Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
802.1X. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Access Port Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
DHCP Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
DAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
IP Source Guard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
IGMP Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Forwarding Classes (Queuing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
About Juniper Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Introduction
Campus networks vary from a few hundred (small campus) to thousands of Ethernet ports (large campus). These
ports are in relatively close proximity, within or across multiple floors and buildings. Additional locations interconnected
across a WAN are not considered part of the campus network.
Three-Tiered Network
A typical campus network may be segmented into a three-tiered layer network: core, aggregation, and access (as
shown in Figure 1). The access layer, typically located in wiring closets, is the entry point to the corporate network
for users and end devices. The access layer typically consists of 10/100/1000BASE-T switches, often capable of
supporting Power over Ethernet (PoE). End devices such as desktops, printers, and IP phones are commonly connected
to the closet access switches. Wireless access points are also commonly connected to the access switches, extending
access to mobile devices. It is important that access layer devices provide access control, security, and quality of
service (QoS) enforcements.
Depending on requirement, the Juniper Networks® EX2200, EX3200, and EX4200 Ethernet Switches are suitable
access switches.
• EX2200: The EX2200 is a low-cost entry-level switch that offers PoE and non-PoE options in 24 and 48
10/100/1000BASE-T ports, as well as four 1000BASE-X fixed uplink ports. The EX2200 is ideal for conference
rooms or low-density wiring closets.
• EX3200: The EX3200 is a mid-level switch that offers either 24 or 48 10/100/1000BASE-T ports with
interchangeable uplinks supporting either four 1000BASE-X or two 10 GbE ports. Two models are available; the “T”
model offers a full 15.4 watts of PoE on the first eight ports, while the “P” model offers a full 15.4 watts of PoE on all
24 or 48 ports. The EX3200 also offers full OSPF in the base license.
• EX4200: Like the EX3200, the EX4200 offers 24- and 48-port models with full and partial PoE options. In addition,
the EX4200 includes hardware redundancy for both power supplies (1+1) and fans (2+1). With Virtual Chassis
technology, up to 10 EX4200 switches can be interconnected as a single, logical device to create a high-density,
highly available configuration supporting up to 480 10/100/1000BASE-T ports plus 20 10 GbE or 40 GbE uplinks
ports. Virtual Chassis technology will be discussed in greater detail later in this document.
The aggregation layer typically is located in an intermediate distribution frame (IDF) and consists of a mixture of
high-density 10-Gigabit Ethernet or Gigabit Ethernet switches, and services appliances such as firewalls and intrusion
detection and prevention (IDP) devices. The aggregation switches are responsible for amassing all traffic from the
access switches as well as distributing information to the access switches. Similar to the core, aggregation devices
need to be highly available.
The hardware is dependant on the size and requirement, because either the Juniper Networks EX8200 line of
Ethernet switches or EX4200-24F switches in a Virtual Chassis configuration can be deployed in the aggregation
layer. The EX8200 is more suitable for medium to large campuses because of its high switching fabric capacity and
high 10-Gigabit Ethernet port densities. The EX4200-24F is more suitable for the small or medium campus with
1000BASE-X aggregation requirements. Both the EX4200 and the EX8200 switches support redundant REs, fabric,
power supplies, and fan blowers to provide hardware reliability to withstand a single point of failure.
The campus LAN core is typically located in a main distribution frame (MDF) and is the gateway between the campus
and external networks. The majority of campus traffic (client/server) passes through the core; thus it is vital that the
core be highly available, predictable, and manageable. The core layer usually consists of WAN routers, high-capacity
non-blocking switches, and perhaps firewalls.
The EX8200 is an ideal core chassis because of the large forwarding table size, performance, and 10-Gigabit Ethernet
port densities.
Copyright © 2010, Juniper Networks, Inc. 5
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Figure 1: Traditional three-tiered network
Simplifying the Network (Two-Tiered Network)
The high density, high performance, and flexible capabilities of Juniper Networks EX Series Ethernet Switches allow
network architects to break away from the traditional three-tiered network and converge the core and aggregation
layers into a single (core) layer, creating a two-tiered model (see Figure 2).
Note: In some campus environments, the physical cable plant layout and distance limitations may require a traditional
three-tier design.
In a two-tiered model, all access switches are directly connected to the core. All interconnects and connecting
devices are similar to the traditional three-tiered model except that the aggregation layer has been removed. The
fundamentals remain the same for the layers: the core still needs to be highly available and predictable, with the
added responsibility of performing the aggregation layer’s functionality; the access still needs to provide access to
authorized users, prevent malicious attacks, and properly identify and ensure services.
Eliminating the aggregation layer simplifies the network, reduces the number of devices, and improves overall
performance. Lower latency can be expected because there are fewer “hops” the traffic needs to traverse to reach
servers or the WAN. Capital expenses will also be lower since there are fewer devices to deploy and spare. The added
benefits of Juniper Networks Junos® operating system and the common EX Series switch architecture make managing
devices more consistent and efficient, which ultimately lowers operational expenses.
ACCESS LAYER• Campus wiring closet• End-point device/network boundary• 10/100/1000BASE-T Ethernet• In-line power• Access control boundary• QoS boundary
AGGREGATION LAYER• Aggregate wiring closets• High-density GbE• High availability• Core enforcement perimeter• Spatial Redundancy
CORE LAYER• Consolidates Aggregation Layer• Boundary between LAN and WAN• High density 10 GbE• Predictable performance• Always available
L2/L3Switch
L2/L3Switch
L2/L3Switch
L2/L3Switch
L2Switch
INTERNET/PRIVATE WAN
L2Switch
6 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Figure 2: Collapsing the aggregation layer
Additional steps can be taken to further simplify the network. With Virtual Chassis technology deployed between wiring
closets at the access layer, the number of uplinks can be reduced while effectively utilizing the full uplink bandwidth
(see Figure 3). Virtual Chassis technology also enables up to 10 EX4200 switches to be managed as a single entity,
which reduces the number of access layer devices to manage.
Figure 3: Virtual Chassis technology reduces the number of uplinks and managed devices
EX8200EX8200
Virtual Chassis Virtual Chassis Virtual Chassis
INTERNET/WAN
CORE
ACCESS
EX8200EX8200
Virtual Chassis Configuration Virtual Chassis Configuration
INTERNET/WAN
CORE
ACCESS
Copyright © 2010, Juniper Networks, Inc. 7
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Distributed Switching
With new emerging technologies, there is a shift in how networks are being designed. Administrators are always looking
for ways to eliminate Spanning Tree Protocol (STP) without the need to push Layer 3 to the access layer. One concept
that is garnering a fair amount of attention is distributed switching in the core/aggregation layer. Redundant devices
are being transformed into single, logical devices (see Figure 4).
Figure 4: Distributed switching at the core/aggregation layer
By distributing switching at the aggregation or core layers, the following benefits can be realized:
• No Spanning Tree (configure LAGs to eliminate Spanning Tree without L3 to the access)
• Layer 2, active/active topology
• Single management
The following should be taken into consideration when deploying distributed switching at the core/aggregation:
• Lack of spatial redundancy
• Software management—what is the upgrade process?
• High availability within the chassis—if the Routing Engine fails, do you lose half of your virtual switch?
• Switch capacity when part of the system fails—if half of the virtual system fails, can the other system manage twice
the load capacity?
• Split brain—what happens when the systems are split into two?
Routed Network or Switched Networks
Routing and switching are always present in every campus network; the question really boils down to which portion of
the network will be routed and which portion will be switched. In today’s network, the common campus deployment
is switching from the access to the aggregation layer, then routing from aggregation to core and WAN (see Figure 5).
Extending the L2 domain into the aggregation layer allows virtual LANs (VLANs) to span across wiring access closets,
which in turn allows administrators to group devices or users into logical groups, independent of their physical location.
As the network grows, however, it will be harder to scale and manage. The network becomes susceptible to inferior
network convergence, which is important for latency-sensitive applications such as voice and critical applications.
EX4200EX4200
DistributedSwitching
Virtual Chassis Virtual Chassis Virtual Chassis
INTERNET/WAN
CORE
LAG LAG LAG
ACCESS
8 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Figure 5: Routing to the aggregation layer in both a three-tiered and two-tiered architecture
Because of STP, convergence time, scalability, and manageability, network architects are considering pushing routing
to the access layer (see Figure 6). Each IP subnet or VLAN is confined to an access wiring closet switch. VLANs do not
span between wiring closet switches, resulting in no Layer 2 loops and eliminating the need for Spanning Tree Protocol.
In addition, the Virtual Router Redundancy Protocol (VRRP) is no longer needed, because the gateway for the subnet is
at the local access wiring closet switch rather than between two redundant boxes at the aggregation or core layer.
Figure 6: Routing to the access layer in both a three-tiered and two-tiered architecture
EX8200 EX8200
EX8200 EX8200
VirtualChassis
VirtualChassis
Access
Aggregation
Core
Access
Core
L2
L3
VirtualChassis
Three-Tiered Layer
Management VLANData VLANVoice VLANServer VLAN
NOTE: Management, data, and voice VLANsare configured on the L2 trunk link
VirtualChassis
VirtualChassis
L2
L3
VirtualChassis
Two-Tiered Layer
L2
L3 L3
L2
EX8200 EX8200
EX8200 EX8200
VirtualChassis
VirtualChassis
Access
Aggregation
Core
Access
Core
VirtualChassis
Three-Tiered Layer
Management VLANData VLANVoice VLANServer VLAN
NOTE: Management, data, and voice VLANsare configured on the L2 trunk link
VirtualChassis
VirtualChassisVirtual
Chassis
Two-Tiered Layer
Copyright © 2010, Juniper Networks, Inc. 9
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
This implementation guide will cover both deployment scenarios in a three-tiered and two-tiered model. This
document will also provide implementation guidelines such as high availability, connectivity, and/or feature
recommendations such as class of service (CoS) or security for L2, as well as L2/L3 in a three or two-tiered network.
Figure 7: Features to be configured for a three-tiered network
Scope
This implementation guide is targeted at the enterprise network designers, implementers, administrators, and other
technical audiences to describe how to deploy both fixed and chassis-based EX Series Ethernet Switches in a campus
LAN. This document covers implementation and configuration for the following EX Series switch features:
• VLAN
• STP
• Routing
• CoS
• High availability (HA)
• Security
• Management
Hardware
The EX Series Ethernet Switches covered in this implementation guide include the EX2200 and EX3200 fixed-configuration
switches, the EX4200 switches with Virtual Chassis technology, and the EX8200 line of modular switches.
Software
All features described in this implementation guide are available in Junos OS 10.1 or later for the EX2200, EX3200,
EX4200, and EX8200 switches.
ACCESS LAYER• VLANs• Voice VLAN• Access-security• CoS• Link Aggregation (LAG)• Spanning-Tree• System Features
AGGREGATION LAYER• VLANs• Routed VLAN Interface• LAG• Spanning-Tree• Routing Protocols• CoS• System Features
CORE LAYER• LAG• Routing Protocols• CoS• System Features
L2/L3Switch
L2/L3Switch
L2/L3Switch
L2/L3Switch
L2Switch
L2Switch
10 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Implementation
Campus Features
Determining what and where features should be configured for the campus network can be a daunting task. This
implementation guide will highlight recommended practices for the campus network. There are four major groups that
should be taken into consideration for the campus network when deploying EX Series Ethernet Switches:
• System features: What are the basic configurations that should be configured on a switch to allow management,
visibility, and protection from distributed denial of service (DDoS) attacks?
• Spanning Tree Protocol: Where should STP be configured? And what spanning-tree features should be configured to
ensure a loop-free network?
• Routing: Where and what should be configured to ensure unicast and multicast routing?
• HA: What can be done be ensure network availability from a physical, hardware or software perspective?
The table below is a cross matrix between campus features and switch devices in their respective network layers (core,
aggregation, or access). If there is a check between the row and column, then the feature should be configured on the
switches within that network layer.
Table 1: System Features/Protocols Table
LAYER ROUTING TO THE AGGREGATION LAYER ROUTING TO THE ACCESS LAYER
FEATURES ACCESS AGGREGATION CORE ACCESS AGGREGATION CORE
System
(management,
visibility, other)
✔ ✔ ✔ ✔ ✔ ✔
Spanning Tree ✔ ✔
Bridge
protocol data
unit (BPDU)
protection
only
BPDU
protection
only
BPDU protection
only
BPDU
protection
only
Routing ✔ ✔ ✔ ✔ ✔ ✔
HA ✔ ✔ ✔ ✔ ✔ ✔
System Configuration
System features are basic essentials that should be configured on all switches for manageability, security, or visibility.
Management Interface
EX Series switches have an out-of-band Ethernet interface (me0) and serial port (console 0) for management. For
secure management, it is a good practice to manage the switch out-of-band, although that can require a separate
infrastructure and some network administrators feel that it is too costly. Instead, an in-band management interface (on
the same network as the data) is more cost effective.
Any Layer 3 interfaces such as loopback 0 (lo0), routed VLAN interface (RVI), or L3 interfaces can be an in-band
management interface. Loopback 0 is commonly used as the in-band management interface. However there are certain
deployments where an in-band management interface is something other than lo0, such as access that is a strictly Layer 2
device. Therefore, configuring an RVI on the management VLAN will become the in-band management interface.
Copyright © 2010, Juniper Networks, Inc. 11
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Table 2: Management Interface Table
LAYER ROUTING TO THE AGGREGATION LAYER ROUTING TO THE ACCESS LAYER
IN-BAND
MANAGEMENTACCESS AGGREGATION CORE ACCESS AGGREGATION CORE
RVI ✔
lo0 ✔ ✔ ✔ ✔ ✔
root@switch# set interfaces vlan.1 family inet address 10.1.1.1/24root@switch# set vlans management l3-interface vlan.1
Securing the Switch
SSH: Secure Shell (SSH) provides an encrypted communication channel between two devices to prevent hackers from
peering into the conversation. SSH is preferred over telnet.
root@switch# set system services ssh
Firewall Filter
Applying a firewall filter for in-band management protects the Routing Engine CPU from malicious packets that
consume CPU processing cycles (DoS and DDoS attacks) or from unauthorized users accessing the device. Only
control and protocol packets from trusted sources should be allowed. The firewall filter provides such protection
without hindering the device’s performance.
When applying a firewall filter on lo0 interface, all packets to the CPU will be screened. This eliminates the need
to manage firewall filters on multiple interfaces. When designing the firewall filter for lo0 interface, things such as
management (SSH, SNMP) and pings/traceroutes must be taken into consideration when deciding whether they
should be permitted. For devices that are using RVI as in-band management, apply the firewall filter on the RVI instead
of lo0.
Step 1: Edit the firewall stanza and define a filter name.
root@switch# edit firewall family inet filter RE
Step 2: Define the firewall filter to accept access connections from trusted sources. Below is an example for SSH;
additional terms are needed for Juniper Networks Network and Security Manager.
root@switch# set term ssh from source-address 10.255.1.0/24root@switch# set term ssh from protocol tcp source-port sshroot@switch# set term ssh then accept
Step 3: Apply the filter to the in-band management interface.
root@switch# set interfaces lo.0 family inet filter input management
Note: On EX Series switches, policing actions are not supported within the lo0 firewall filter. However, the EX Series
Packet Forwarding Engine (PFE) has a built-in CPU rate limiter that protects it from DDoS attacks. Firewall filter on
me0 is not supported. This will be supported in a later software release.
Switch Management and Visibility
After configuring the management interface, the EX Series switches can be configured, managed, and monitored either
through a GUI or central network management device.
12 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
J-Web
Juniper Networks J-Web Software is a simple, intuitive GUI application that helps administrators configure, monitor,
and upgrade the router.
EX Series switches support HTTP and HTTPS for J-Web management. HTTPS provides secure access for J-Web and
therefore is recommended.
root@switch# set system services web-management https
Juniper Networks Network and Security Manager
NSM is a centralized management system that allows administrators to manage multiple devices such as security
devices, routers, and switches. NSM provides a single, integrated management interface that allows all device
parameters to be controlled in a centralized location. NSM uses a complete set of investigative tools that provide in-
depth network visibility and give users access to the information required to fulfill their job responsibilities.
NSM can auto-discover EX Series switches with the following configurations.
root@switch# set system services ssh protocol-version v2root@switch# set system services netconf sshroot@switch# set snmp view abc oid .1 includeroot@switch# set snmp community public view abcroot@switch# set snmp community public authorization read-only
sFlow
sFlow is a statistical, sampling-based network monitoring protocol for high-speed networks. With network visibility
from traffic flow sampling and interface statistics, network administrators can validate proper network usage and
services. sFlow is currently only supported on the EX3200 and EX4200 switches. sFlow support on the EX8200 will be
supported in a later release.
root@switch# edit protocols sflowroot@switch# set collector ip-address 10.255.1.101
Bootp/DHCP Relay
Dynamic Host Configuration Protocol (DHCP) is used by client devices to obtain parameters necessary for operating
in an IP network from a centralized server. Typically, the DHCP server is located on a different subnet. Since DHCP
discovery is a Layer 2 broadcast packet and is not forwarded beyond the Layer 2 broadcast domain, DHCP relay (bootp
relay) is required to forward the request from a client to a DHCP server to obtain the necessary IP parameters. The
DHCP/bootp relay feature should be configured at the default gateway router for the closet switches’ endpoints.
root@switch# set forwarding-options helpers bootp server 10.1.4.12
Spanning Tree Protocol
STP is a Layer 2 protocol that ensures a loop-free network by blocking redundant Layer 2 paths in the LAN. The EX
Series Ethernet Switches support IEEE 802.1D (STP), 802.1s Rapid Spanning Tree (RSTP), 802.1w Multiple Spanning
Tree (MSTP), and VSTP (VLAN Spanning Tree) for EX3200 and EX4200 switches; VSTP support on the EX8200
switches will be supported in a future release. On the EX Series, RSTP is enabled by default. There are other spanning-
tree features such as BPDU protection or loop protection that should also be taken into consideration.
Copyright © 2010, Juniper Networks, Inc. 13
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Table 3: Spanning-Tree Feature Table
LAYER ROUTING TO THE AGGREGATION LAYER ROUTING TO THE ACCESS LAYER
STP
FEATURESACCESS AGGREGATION CORE ACCESS AGGREGATION CORE
MSTP ✔ ✔
BPDU protection ✔ ✔ ✔ ✔ ✔ ✔
Root protection ✔
Loop protection ✔ ✔
Note: For a better understanding of STP, please refer to the implementation guide “Spanning Tree Protocol in Layer 2/
Layer 3 Environments.”
In a campus environment, MSTP is ideal because it is an extension of RSTP, offering the same features and allowing all
links to be in a forwarding state and still maintain a loop-free network. When configuring Spanning Tree, it is important
to match spanning-tree protocols between layers for optimal convergence behavior.
The first step is deciding which switch should be the root bridge. The root bridge should be configured on the switch
where the L2 and L3 domains meet (see Figure 4). In a three-tier model and routing to the aggregation layer, the
root bridge will be on one of the aggregation switches. In a two-tiered model, the root bridge will be one of the core
switches because the aggregation and core are collapsed into a single layer.
Step 1: Prior to configuring MSTP, RSTP must first be disabled or deleted.
root@switch# delete protocols rstproot@switch# set protocols mstp
Step 2: Configure Common Spanning Tree (CST) and Multiple Spanning Tree Instance (MSTI) bridge priorities on the
core switches.
• coreA will be root for MSTI 1 and CST and backup for MSTI 2.
• coreB will be backup root for STP and MSTI 1 and root for MSTI 2.
root@switch# set protocols mstp bridge-priority 8kroot@switch# set protocols mstp msti 1 bridge-priority 8kroot@switch# set protocols mstp msti 2 bridge-priority 4k
By splitting the root bridge between the two core switches, MSTI 1 will always be forwarding to coreA and blocking to
coreB, while MSTI 2 will always be forwarding to coreB and blocking to coreA (see Figure 8).
14 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Figure 8: MSTP allows VLAN load balancing so that all links are forwarding and the network still remains loop-free
The following output is from the spanning-tree parameters for the switch.
Management VLANData VLANVoice VLANSTP ForwardingSTP Blocking
NOTE: All inter-switch links aretrunk links and all VLANs are allowed.
VirtualChassis
Blockingfor voice,management
Blockingfor voice,
managementFWD for voice,management
coreBMSTI 1 Backup
MSTI 1
coreAMSTI 1 Root
EX8200EX8200
VirtualChassis FWD for voice,
management
coreBMSTI 2 Root
MSTI 2
coreAMSTI 2 Backup
EX8200EX8200
root@switch > show spanning-tree bridge STP bridge parameters Context ID : 0Enabled protocol : MSTP
STP bridge parameters for CIST Root ID : 8192.00:19:e2:51:49:00 CIST regional root : 8192.00:19:e2:51:49:00 CIST internal root cost : 0 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Number of topology changes : 0 Local parameters Bridge ID : 8192.00:19:e2:51:49:00 Extended system ID : 0 Internal instance ID : 0
STP bridge parameters for MSTI 1 MSTI regional root : 8193.00:19:e2:51:49:00 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Local parameters Bridge ID : 8193.00:19:e2:51:49:00 Extended system ID : 0 Internal instance ID : 1
Copyright © 2010, Juniper Networks, Inc. 15
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
STP bridge parameters for MSTI 2 MSTI regional root : 4098.00:19:e2:51:49:00 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Local parameters Bridge ID : 4098.00:19:e2:51:49:00 Extended system ID : 0 Internal instance ID : 2
Step 3: Map VLANs to MSTI. MSTI configurations must be the same for both core and access switches.
root@switch# set protocols mstp msti 1 vlan [1 10]root@switch# set protocols mstp msti 2 vlan [4 5]
The following command shows the MSTI configuration.
root@switch> show spanning-tree mstp configuration MSTP information Context identifier : 0Revision : 0Configuration digest : 0x5c97faba14eb0262961fcff959a44bac
MSTI Member VLANs 0 0,2-3,6-9,11-4094 1 4-5 2 1,10
Loop Protection
Loop protection provides additional protection against Layer 2 loops. This feature prevents a port from becoming a
designated port because of a unidirectional link. A unidirectional link is when there is a hardware (HW) or software
(SW) error that prevents the port from transmitting but it still can receive traffic (see 802.3ah section to help protect
the switch from this condition). In a topology where the access switch has two uplinks, one to each upper-layer switch,
one of the redundant links will be in a blocking state because of Spanning Tree. The redundant link that is in blocking
state should never be a designated port unless the link between the core and aggregation link fails. Loop protection
should be configured on the uplink ports that are non-designated—enable it on root or alternate ports.
root@switch# set protocols mstp interface ae0.0 bpdu-timeout-action blockroot@switch# set protocols mstp interface ae1.0 bpdu-timeout-action block
Root Protection
Root protection prevents a rogue switch from becoming a root bridge and causing a spanning-tree convergence. This
feature is ideally configured on the networking ports of the aggregation switches that are facing the access switches in
a three-tiered network layer topology.
root@switch# set protocols mstp interface <interface-name> no-root-port
16 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
BPDU Protection
The BPDU protection feature prevents rogue switches from connecting to the network, causing an undesired Layer 2
topology change. It is recommended that BPDU protection be enabled on user-facing ports of access layer switches.
If the protected port receives any BPDU, then the port goes into error (blocked) state. This should be configured for
switches that have MSTP enabled.
root@switch# set protocols mstp bpdu-block-on-edge
For switches that do not have STP enabled but still have Layer 2 ports, such as core switches, it is highly recommended
that BPDU protection be enabled. This feature can be enabled from the Ethernet-switching options.
root@switch# set ethernet-switching-options bpdu-block interface <name>
RTG
Redundant Trunk Group (RTG) is an alternative loop prevention feature that doesn’t require Spanning Tree between
the access and core/aggregation layer switches. In a dual-uplinked switching environment, RTG provides a simple
solution for network recovery when the primary link goes down: traffic is routed to the backup link, keeping network
convergence time to a minimum. A pair of links makes up an RTG group; the higher numbered interface is active and
forwarding while the other link is in standby and blocking mode. Links that are configured in an RTG group do not
participate in the Spanning Tree process—BPDUs are not forwarded or they are dropped if they are received.
Figure 9: RTG before and after a primary link failure
Step 1: Disable Spanning Tree for interfaces that are going to be part of RTG.
Management VLANData VLANVoice VLANSTP ForwardingSTP Blocking
NOTE: All inter-switch links aretrunk links and all VLANs are allowed.
VirtualChassis Blocking for
all VLANsFWD for
all VLANs
Core/AggregationSwitch B
NO LINK FAILURE
Core/AggregationSwitch A
VirtualChassis FWD for
all VLANsLink failure
Core/AggregationSwitch B
LINK FAILURE
Core/AggregationSwitch A
EX8200EX8200EX8200EX8200
root@switch# set protocols mstp interface ae0.0 disableroot@switch# set protocols mstp interface ae1.0 disable
Copyright © 2010, Juniper Networks, Inc. 17
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Step 2: Configure RTG.
root@switch# set ethernet-switching-options redundant-trunk-group group RTG-1 interface ae0.0root@switch# set ethernet-switching-options redundant-trunk-group group RTG-1 interface ae1.0
Note: The keyword “primary” gives an interface a higher weight to be active when the link is up.
The following output from RTG shows which link is active and forwarding.
root@switch> show redundant-trunk-group Group Interface State Time of last flap Flap name count
RTG-1 ae1.0 Up/Act Never 0 ae0.0 Up Never 0
Although Spanning Tree isn’t required between the core and access ports, it is still recommended that spanning-tree
and/or BPDU protection be enabled on the user-facing ports of the access switches.
Routing
Routing allows traffic to traverse a network boundary. There are two basic routing functions: unicast and multicast.
Unicast routing is sending traffic from one source to one destination while multicast is one-to-many routing.
Table 4: Routing Features Table
LAYER ROUTING TO THE AGGREGATION LAYER ROUTING TO THE ACCESS LAYER
ROUTING
FEATURESACCESS AGGREGATION CORE ACCESS AGGREGATION CORE
Inter-VLAN
routing/gateway✔ ✔
Static ✔
OSPF ✔ ✔ ✔ ✔ ✔
Equal-cost multipath
(ECMP)✔
Multicast ✔ ✔ ✔ ✔ ✔
Inter-VLAN Routing
Inter-VLAN routing requires routed VLAN interfaces (RVIs). RVI is a logical Layer 3 interface for a VLAN that allows
communication between VLANs and other Layer 3 networks. RVI is also the gateway for the local subnet (VLAN).
The example below shows the two steps required to configure a single RVI.
Step 1: Configure an IP address for the RVI interface.
root@coreB# set interfaces vlan.5 family inet address 10.1.5.252/24
Step 2: Bind the RVI interface to the VLAN.
root@coreB# set vlans data l3-interface vlan.5
18 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
The output below is a summary of VLANs, RVIs, and the number of active and total ports.
root@coreB> show vlans brief PortsName Tag Address Active/Totaldata 5 10.1.5.252/24 5/5default 4/18management 1 10.1.2.252/24 2/2server 4 10.1.4.252/24 1/1voice 10 10.1.5.252/24 2/2
Static Routes
Where access switches are pure Layer 2 devices and dynamic routing is not enabled, a static route is required for
management access. This allows other devices outside the subnet to communicate to the wiring closet switches.
root@switch# set routing-options static route 0.0.0.0/0 next-hop 10.1.1.254
The “show route” command will display all active routes.
root@switch> show route
inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 00:00:05 > to 10.1.1.254 via vlan.110.1.1.0/24 *[Direct/0] 00:00:05 > via vlan.110.1.1.1/32 *[Local/0] 00:02:44 Local via vlan.1
OSPF
Open Shortest Path First (OSPF) is a two-tier hierarchical link-state routing protocol. The backbone area (area
0.0.0.0) must border every area in its autonomous system (see Figure 10). The backbone distributes routing
information between areas; the routing table is based on the shortest path tree in each area.
Copyright © 2010, Juniper Networks, Inc. 19
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Figure 10: Logical representation of OSPF hierarchical area domains
Three-Tiered Model
If the routing and switching domains coincide at the aggregation layer, then the area 0.0.0.0 will consist of core devices and
uplinks to the core on the aggregation switches. Since the routing domain is small and only spans a portion of the campus
network, the RVIs on the aggregation switches can be part of area 0.0.0.0, but they should be configured as a passive
interface. Passive interface will suppress OSPF hellos on the configured interface, which prevents OSPF adjacencies from
forming and reduces OSPF processes, but will still be advertised by the OSPF as a connected network.
In a routed model, where routing is extended to the access switches, area 0.0.0.0 will consist of the core devices and
uplinks to the core on the aggregation switches. Every pair of aggregation switches and adjacent connecting access
closet switches can be contained in their own area (customer requirements may differ). The aggregation and access
switches should be configured as a stub area. A stub area is the edge of the OSPF routing domain and not a transit
area. By creating a stub network, the core area will just inject a single default route into each stub area, which reduces
the number of required routes programmed into the switch. The RVIs on the access switches should be configured as
passive interfaces.
Two-Tiered Model
If the routing and switching domains coincide at the core/aggregation layer, then area 0.0.0.0 will be routed links on
the core/aggregation box and the RVI will be a passive interface.
In a routed model, area 0.0.0.0 will be the core devices and the routed links between the core and access layers will
be part of the stub area. Since the core is also acting as an aggregation box, grouping multiple links into one area is
recommended. A good rule of thumb for determining the area boundary size is one multi-floor building equals one area
for a large campus, two to three buildings equal one area for a medium campus, and so forth.
This command enables OSPF, configures an interface to be part of an area, and configures authentication:
EX8200
EX8200
EX8200AREA0.0.0.1
AREA0.0.0.3
AREA0.0.0.0
AREA0.0.0.4
AREA0.0.0.2
VirtualChassis
EX8200
EX8200
VirtualChassis
VirtualChassis
root@switch# set protocols ospf area 0.0.0.0 interface ae0.0 authentication md5 1 key secure
If the authentication fails, then the interface will not establish adjacency with the neighboring OSPF router.
20 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
This command is to configure a stub area:
root@switch# set protocols ospf 0.0.0.1 stub
This command is to configure a passive interface for OSPF:
root@coreB# set protocols ospf area 0.0.0.0 interface vlan.1 passive
The following output can be used to confirm that OSPF has established a full adjacency with its neighbor:
root> show ospf neighbor Address Interface State ID Pri Dead10.1.3.2 ae0.0 Full 10.1.2.1 1 3010.1.3.6 ae1.0 Full 10.1.2.1 1 30
Note: It is also recommended that lo0 be advertised.
ECMP
OSPF supports equal-cost multipath (ECMP), which allows the router or switch to load-balance routed traffic between
equal-cost paths. Even though the equal-cost links are in the routing table, the EX Series Ethernet Switches will not
load-balance by default. This has to be configured.
EX Series switches implement a per-flow ECMP.
root@switch# set policy-options policy-statement ECMP then load-balance per-packet root@switch# set routing-options forwarding-table export ECMP
In a mixed L2/L3 environment where EMCP is combined with different Address Resolution Protocol (ARP) and MAC-
aging timers, unknown unicast flooding will occur due to asymmetrical routing—a condition where the “to” and “from”
paths are different. Since the paths are different, the host media access control (MAC) address will never get refreshed
on one of the switches. Thus, the switch eventually ages out and unicast flooding occurs until the redundant box re-
ARPs (see Figure 11).
Figure 11: The host MAC address on the redundant box ages out, which causes an unknown unicast flooding until the box re-ARPs for the IP address
EX8200
VLAN Faculty
MAC-addresstable ages out
EX8200
INTERNET/WAN
Copyright © 2010, Juniper Networks, Inc. 21
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
There are two different ways to mitigate this problem. The first requires route manipulation on the core routers; the
second and easier option is to match the ARP timer and MAC aging timer on the aggregation switches (in a three-tiered
model) or core (in a two-tiered model) for all VLANs. The MAC aging timer is configurable in seconds and defaults to
300 seconds. The ARP timer is configurable in minutes and defaults to 20 minutes.
root@switch# set system arp aging-timer 20 root@switch# set vlans data mac-table-aging-time 1200
Multicast Routing
Protocol Independent Multicast (PIM) is the predominant multicast routing protocol used today. PIM operates in three
different modes:
• PIM-DM (dense mode, flood, and prune): Multicast join requests are initially flooded to all PIM-DM-enabled
routers. If there are no downstream members, then the router will prune towards the source.
• PIM-SM (sparse mode, explicit join): The destination/receiver member must send an explicit “join” request to the
rendezvous point (RP) router.
• PIM-SSM (source specific): One-to-many model; receiving hosts must join with either Internet Group Management
Protocol version 3 (IGMPv3) or Multicast Listener Discovery version 2 (MLDv2).
Juniper recommends PIM-SM for campus deployment. PIM-SM is configured at the core layer devices.
Step 1: Enable PIM-SM on all multicast forwarding links (uplinks, RVI, and so on):
root@switch# set protocols pim interface ae0.0 mode sparse-mode
The following output can be used to check PIM neighbors:
root@switch> show pim neighbors Instance: PIM.master
Interface IP V Mode Option Uptime Neighbor addrae0.0 4 2 HPG 00:41:42 10.1.3.2ae1.0 4 2 HPG 00:41:40 10.1.3.6vlan.5 4 2 HPG 00:41:37 10.1.5.253
Step 2: Configure two multicast dense groups, 224.0.1.39 and 224.0.1.40.
Auto-RP requires multicast flooding to announce potential RP candidates and to discover the elected RPs in the
network. Multicast flooding occurs through a PIM-DM model where group 224.0.1.39 is used for “announce messages”
and group 224.0.1.40 is used for “discovery messages.”
root@switch# set protocols pim dense-groups 224.0.1.39root@switch# set protocols pim dense-groups 224.0.1.40
Step 3: RP is the multicast gatekeeper. All PIM-SM routers must know where the RP is located. RP information can be
configured statically or learned dynamically. From an ease of management perspective, dynamic is preferable to static.
root@switch# set protocols pim rp auto-discovery
22 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
The following command is used to see the RP information.
root@switch> show pim rpsInstance: PIM.masterAddress family INETRP address Type Holdtime Timeout Groups Group prefixes10.255.14.144 auto-rp 0 None 1 224.0.0.0/4
Address family INET6
Step 4: Configuring designated router (DR) for multicast—only on spanning-tree root switches.
The DR for multicast is responsible for sending joins to the RP and forwarding multicast traffic for the LAN, thus
preventing duplicate multicast requests from being forwarded to the LAN (one by each of the core switches). If priority
is not configured, then the interface with the highest IP address will become the DR for multicast. The default priority is
one. The switch that is the root for Spanning Tree should also be configured as the DR for multicast.
root@switch# set protocols pim interface vlan.5 priority 250
The following command is used to check on DR information for multicast.
root@switch> show pim neighbors detail | find vlan.Interface: vlan.5
Address: 10.1.5.252,IPv4, PIM v2, Mode: Sparse, Join Count: 0 Hello Option Holdtime: 65535 seconds Hello Option DR Priority: 250 Hello Option Generation ID: 186023536 Hello Option LAN Prune Delay: delay 500 ms override 2000 ms
Address: 10.1.5.253,IPv4, PIM v2, Join Count: 0 Hello Option Holdtime: 105 seconds 85 remaining Hello Option DR Priority: 1 Hello Option Generation ID: 582692152
High Availability
HA is important to ensure non-stop services for campus deployments. This section will cover Virtual Chassis, link
aggregation group (LAG), and graceful Routing Engine switchover (GRES).
Table 5: HA Table
LAYER ROUTING TO THE AGGREGATION LAYER ROUTING TO THE ACCESS LAYER
HA FEATURES ACCESS AGGREGATION CORE ACCESS AGGREGATION CORE
Virtual Chassis ✔ ✔ ✔ ✔
GRES ✔ ✔ ✔ ✔ ✔ ✔
LAG ✔ ✔ ✔ ✔ ✔
VRRP ✔
Copyright © 2010, Juniper Networks, Inc. 23
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Virtual Chassis
EX4200 switches can accommodate greater port densities by adding additional EX4200 switches to form a Virtual
Chassis configuration (see Figure 12). Virtual Chassis configurations can be created either by interconnecting EX4200
switches via the dedicated rear panel Virtual Chassis ports (VCPs) or through the optional front panel two-port
10-Gigabit Ethernet or four-port Gigabit Ethernet uplink module, as well as any port on the EX4200-24F model.
To enable VCP on the uplink ports and fixed ports of the EX4200-24F, the following command is required on both
switches in Junos OS operational mode.
root@switch> request virtual-chassis vc-port set pic-slot 1 port 3 member 0
A single Virtual Chassis configuration allows up to 10 EX4200 switches to be interconnected and managed as a single unit.
Figure 12: In a Virtual Chassis configuration, interconnected EX4200 switches act like a chassis-based system. Up to 10 switches can be interconnected to form a Virtual Chassis configuration.
root> show virtual-chassis status
Virtual Chassis ID: 0019.e250.8240 Mastership Neighbor List Member ID Status Serial No Model priority Role ID Interface0 (FPC 0) Prsnt BM0207431981 ex4200-24t 128 Master* 1 vcp-0 1 vcp-255/1/31 (FPC 1) Prsnt BP0207452211 ex4200-48t 128 Backup 0 vcp-0 0 vcp-255/1/3
Member ID for next new member: 2 (FPC 2)
In the above command, a Virtual Chassis configuration is formed through the dedicated Virtual Chassis ports (vcp-0)
and the front panel uplink module (vcp-255/1/3).
When EX4200 switches are deployed in a Virtual Chassis configuration, the member switches automatically elect a master
and backup Routing Engine (RE). The master RE is responsible for managing the Virtual Chassis configuration, while the
backup is available to take over in the event of a master failure. All other switches in a Virtual Chassis configuration assume
the role of a line card, and are eligible as a master or backup RE if the original master or backup were to fail.
The location of the master and backup RE should be evenly spaced between the line cards for a better fault management in
a VC split scenario. If LAGs are configured on the VC, then the LAG links should be on the line card and not on the master or
backup. Placing the LAGs on the line card minimizes traffic disruption in a master failover situation.
For more details and best practices on Virtual Chassis technology, please refer to Juniper’s “Virtual Chassis Technology
Best Practices” implementation guide (see references).
24 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Mastership Priority
There is a specific master election process when a Virtual Chassis configuration is formed. Upon boot up, all members
are eligible as candidates and participate in the election process.
The Master Election Decision Tree determines which switch becomes the master. The master and backup RE are
assigned based on the following criteria:
1. Highest mastership priority (default 128, user configurable 1 thru 255)
2. Master in previous boot among eligible switches
3. Uptime of the eligible masters (if uptime difference is more than 1 minute)
- Lowest switch base MAC address
root@switch# set virtual-chassis member 0 mastership-priority 250
When configuring the mastership priority, the master and backup REs should have the same value. This prevents
preemption and further traffic disruptions.
Pre-Provisioning
The pre-provisioning feature is a deterministic way of assigning a switch member role (RE or line card) prior to joining
the Virtual Chassis configuration. The entire configuration is done under the master RE. Any member that is not pre-
provisioned will not be part of the Virtual Chassis configuration upon connection.
Step 1: Enable pre-provisioning on the master RE.
root@switch# set virtual-chassis preprovisioned
Step 2: Configure members’ role on the master RE (all members need to be defined including the master RE).
root@switch# set virtual-chassis preprovisioned member 0 serial-number xxxxxxxxxxxx role routing-engineroot@switch# set virtual-chassis preprovisioned member 0 serial-number xxxxxxxxxxxx role routing-engineroot@switch# set virtual-chassis preprovisioned member 0 serial-number xxxxxxxxxxxx role line-card
Step 3: Connect the members.
GRES
Graceful Routing Engine switchover (GRES) is a Junos OS feature that facilitates seamless failover between the master
and backup REs. When GRES is enabled, the kernel and certain tables (MAC address, route tables, port states, and so
on) are synchronized between the master and the backup RE, eliminating the need for the backup RE to relearn states
and routes should the master RE fail. Minimal packet loss should be expected during master failover when GRES is
configured. GRES should be configured on all Virtual Chassis configurations and EX8200 switches.
root@switch# set chassis redundancy graceful-switchover
LAG
Link aggregation group (LAG) is the process of grouping multiple physical links into one virtual bundle to increase
bandwidth and provide physical link redundancy. LAGs can be formed either statically or dynamically through Link
Aggregation Control Protocol (LACP), which can either be a Layer 2 or Layer 3 port.
LACP is part of the IEEE 802.3ad specification that defines the bundling of several physical ports. Junos OS has an
added feature with LACP that provides basic error checking for misconfigurations. This feature ensures that LAG is
properly configured on both sides of the bundle. If a misconfiguration is detected, the bundle will not be active.
Copyright © 2010, Juniper Networks, Inc. 25
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Figure 13: LAG can be formed between any devices that have the LAG capability
On the EX Series Ethernet Switches, LAG is configured as aggregate Ethernet. When forming a LAG, all link speeds and
duplex conditions need to be identical. There are a maximum of eight links per LAG or 12 in the EX8200. LAG ports do
not need to be contiguous and may be across switch members in a Virtual Chassis configuration. (For more information
on Virtual Chassis technology, read the white paper “Juniper Networks EX4200 Switches Deliver True Chassis
Functionality in a Stackable Form Factor.”) Hashing is performed automatically and is based on whether the packet is
IP or non-IP and if the port is a switched or routed port. For a switched port when the packet is IP, hashing is based on
source and destination of MAC, IP, and TCP/UDP ports (if present); for non-IP, it is based on the source and destination
of the MAC address. For routed ports, hashing is based on source and destination of IP and, if present, source and
destination of network ports (UDP/TCP). Hashing on the EX Series switches is not user configurable.
It is recommended that redundant Ethernet connections be configured between the router and switches or on inter-
switch links.
Step 1: Define the number of LAG groups in the system.
EX8200
EX Series Switch
root@switch# set chassis aggregated-devices ethernet device-count 1
Step 2: Delete interfaces.
root@switch# delete interfaces ge-0/1/2
Step 3: Configure interfaces to be part of a LAG.
root@switch# set interfaces ge-0/1/2 ether-options 802.3ad ae0
Step 4: Configure LACP.
root@switch# set interfaces ae0 aggregated-ether-options lacp active
Step 5: Configure the LAG interface as a Layer 2 trunk port and members to all VLANs.
root@switch# set interfaces ae0.0 family ethernet-switching port-mode trunk vlan members all
26 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
The following commands can be used to confirm that the LAG is up.
root@switch> show lacp interfaces ae0 Aggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity ge-0/1/2 Actor No No Yes Yes Yes Yes Fast Active ge-0/1/2 Partner No No Yes Yes Yes Yes Fast Active ge-0/1/3 Actor No No Yes Yes Yes Yes Fast Active ge-0/1/3 Partner No No Yes Yes Yes Yes Fast Active LACP protocol: Receive State Transmit State Mux State ge-0/1/2 Current Fast periodic Collecting distributing ge-0/1/3 Current Fast periodic Collecting distributing
Virtual Router Redundancy Protocol
Typically, there are redundant boxes, both of which can act as gateways for the access wiring closet switches. In such
cases, both boxes should be configured for VRRP, which is for routers and/or L3 switches acting as a default gateway
to hosts on a LAN network. Through an election process, VRRP assigns a master to the router/switch of the VRRP
virtual router and is responsible for routing traffic to and from the LAN segment. The VRRP backup router/switch is on
standby, waiting to take over in the event of a master failure (see Figure 14).
Figure 14: Logical representation of VRRP between L3 switches
VRRP is supported on all Juniper platforms running Junos OS and may be configured on a Layer 3 interface.
The master VRRP should align with the Multiple Spanning Tree Instance (MSTI) root bridge. A priority can be
configured for the VRRP group to ensure mastership. Additionally, Juniper recommends that preemption be configured
in conjunction with the master virtual router. Preemption ensures that the device will always be the master virtual
router if it is operational and active, because it is most likely the optimal path.
EX8200
VLAN Mktg
coreA10.1.5.253backup VRRP 0
coreB10.1.5.252Master VRRP 0
Root Bridgefor VLAN Mktg
Virtual Router -010.1.5.254VRRP 0 VRRP 0
Host 1IP: 10.1.5.10GW: 10.1.5.254
EX8200
root@switch# set interfaces vlan.5 family inet 10.1.5.252/24 vrrp-group 0 virtual-address priority 250 10.1.5.254 accept-data preempt
Copyright © 2010, Juniper Networks, Inc. 27
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
The following output shows a summary of VRRP groups, VR state, and local and virtual IP addresses
root@coreB> show vrrp summary Interface State Group VR state Type Addressvlan.1 up 0 backup lcl 10.1.1.252 vip 10.1.1.254 vlan.5 up 0 master lcl 10.1.5.252 vip 10.1.5.254 vlan.10 up 0 backup lcl 10.1.10.252 vip 10.1.10.254
Port Roles
There are two basic port groups or roles within a campus network: networking ports and user ports. Networking ports
are interfaces that interconnect networking devices and services such as IDP, wireless AP, and firewalls, to name a few.
• Inter-switch Links: Connected to another switch as a Layer 2 port, this link extends the Layer 2 domain between
switches and is considered secure because it requires an administrator to bring this link up.
• Routed Links: A Layer 3 port that routes traffic between network boundaries. Similar to Services Ports and Inter-
switch links, this port is considered secure. Routed ports are common in a routed network.
• Wireless: An unsecure access port that allows end users to connect to the campus network via wireless. The
requirements are similar to desktop.
• Services Port: A service device such as a firewall or intrusion detection and prevention (IDP) appliance. Since these
connections are typically at the access layer, they are considered secure.
Table 6: Networking Port Role and Feature Matrix
NETWORKING PORTS PORT MODE VLAN 802.3AH MVRPLLDP/LLDP-
MED
PORT
SECURITY
IGMP-
SNOOPINGCOS
Inter-Switch Links Trunk ✔ ✔ ✔
Routed Ports L3 ✔ ✔ ✔ ✔ ✔
Wireless Access ✔ ✔ ✔ ✔
Services Port
(firewall, IDP)Trunk ✔
User-facing ports are interfaces connecting to end hosts such as users, printers, IP Telephony (IPT) and others.
Depending on the type of port, certain features are more suitable for one port type than another. The common port
roles in the campus network are:
• Desktop: An unsecure access port that allows end users to connect to the campus network. Typically, there will be
intermixes of traffic—unicast, multicast, and various applications. This connection is typically at the access wiring
closets.
• Desktop + IP Telephony (IPT): Similar to the desktop but with the addition of IP telephony. The PC and IPT share the
same link but voice and data traffic are logically in different Layer 2 domains.
• Printer: An unsecure access port used to connect to printers. Printers are typically connected to the access wiring
closets.
• Server: Servers are usually connected to a dedicated switch in a controlled environment. If the server is configured
as a Virtual Server, then the connection can be a trunk connection instead of an access port.
The majority of the time, these port roles will hold true regardless of the choice of campus network deployment. The table
below charts port roles in a campus network and recommends features that should be configured with the port role.
28 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Table 7: User Port Role Table and Feature Matrix
USER PORTS PORT MODE VLAN MVRPLLDP/LLDP-
MED
PORT
SECURITY
IGMP-
SNOOPINGCOS
Desktop Access ✔ ✔ ✔ ✔ ✔
Desktop + IPTAccess +
VoIP✔ ✔ ✔ ✔ ✔
Printer Access ✔ ✔ ✔
ServerAccess or
Trunk✔ ✔ ✔ ✔
VLAN
VLANs logically divide a Layer 2 domain into separate virtual local area networks within a switch. Each VLAN confines
all local traffic within its own domain.
Figure 15: Switch divided into logical VLANs
EX Series switches support 4,096 VLANs, any of which may be assigned to either an access or trunk port.
In the EX Series switches, creating and deleting VLANs is done under the VLANs stanza. The configuration example
below shows how to create a VLAN.
VLAN STUDENTS
EX Series Switch
VLAN VOICE
VLAN FACULTY
root@switch# set vlans management vlan-id 1
VLAN Membership
Depending on user preference, there are two different ways of assigning a port to a VLAN.
Option 1: VLAN-centric
Configuring a port to be part of a VLAN can be done under the VLAN itself.
root@switch# set vlans data interface ge-0/0/0.0
Option 2: Port-centric
Conversely, VLAN membership can be configured under the interface.
root@switch# set interfaces ge-0/0/2.0 family ethernet-switching vlan members data
Note: Junos OS allows the user to configure VLANs either by name or by vlan-id (tag).
Copyright © 2010, Juniper Networks, Inc. 29
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
As shown below, the “show vlans” command provides a summary of VLAN-to-port membership.
root> show vlans Name Tag Interfacesdata 5 ge-0/0/0.0*, ge-0/1/0.0*management 1 ge-0/1/0.0*voice 10 ge-0/0/1.0*, ge-0/0/2.0*, ge-0/1/0.0*
Apply-Groups
Apply-groups is a Junos OS feature that helps simplify configuration on any Junos OS-based system, including the EX
Series Ethernet Switches. It allows users to create templates that can be applied to any portion (such as interfaces and
protocols) of the configuration. An example is in a wiring closet where all switching ports are commonly configured to
be part of the same VLAN. Apply-groups will eliminate the need to retype repetitive configuration syntaxes. Instead of
manually configuring each interface to be part of a VLAN, an interface template can be created to be part of a specific
VLAN and then be applied at the top of the interface hierarchy so that all matched subsequent interfaces will inherit
the configuration.
Step 1: Create port template.
root@switch# set groups data-default <ge-0/0/*> unit 0 family ethernet-switching vlan members 5
Junos OS is based on FreeBSD; thus regular expression can be used within the apply-groups. For <ge-0/0/*>, the
asterisk represents all ports in PIC 0. With regular-expression, users can be confined to a particular group of ports.
For example, if only ports 0-9 need to be configured, then replace <ge-0/0/*> with “<ge-0/0/[0-9]>” (include the
quotes).
Step 2: Apply the groups to the interface stanza.
root@switch# set interface apply-groups data-default
To prevent a particular interface from inheriting the template, enter apply-groups-except under the specific interface
configuration. This command will prevent the interface from inheriting the template characteristics. For example, if the
following command was entered, set interface ge-0/0/5 apply-groups-except data-default, interface ge-0/0/5 will not
be part of VLAN 5.
Port Mode
On the EX Series switches, port interfaces are configured as Layer 2 access, Layer 2 trunk, or Layer 3 interface.
• Access (Layer 2): An access port is a member of a single VLAN, which is common for a host port. The packet on
the wire is unaltered (no VLAN identifier) with the exception of the voice over IP (VoIP) feature. root@switch# set
interfaces ge-0/0/0.0 family ethernet-switching port-mode access
• Trunk (Layer 2): A trunk port is a member of multiple VLANs. This is common for links that need to extend multiple
VLANs over a single link. When traffic traverses a trunk port, the traffic is tagged with a VLAN identifier (per IEEE 802.1Q).
root@switch# set interfaces ge-0/1/0.0 family ethernet-switching port-mode trunk
• Interface (Layer 3): Configuring an IP address to the interface itself creates a distinct Layer 3 network for the
interface. This is usually configured between two routed nodes (that is, between core router and switch or between
routed ports).
root@switch# set interfaces ge-0/1/1.0 family inet address 10.1.3.1/30
30 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Use the “show interface <name>” command (as shown below) to determine port type.
root@switch> show interfaces ge-0/0/0.0 Logical interface ge-0/0/0.0 (Index 67) (SNMP ifIndex 48) Flags: SNMP-Traps Encapsulation: ENET2 Bandwidth: 0 Input packets : 0 Output packets: 0 Protocol eth-switch, MTU: 0 Flags: None <--- Access Portroot> show interfaces ge-0/1/0.0 Logical interface ge-0/1/0.0 (Index 87) (SNMP ifIndex 104) Flags: SNMP-Traps Encapsulation: ENET2 Bandwidth: 0 Input packets : 0 Output packets: 0 Protocol eth-switch, MTU: 0 Flags: Is-Primary, Trunk-Mode <--- Trunk Port
root> show interfaces ge-0/1/1.0 Logical interface ge-0/1/1.0 (Index 88) (SNMP ifIndex 105) Flags: SNMP-Traps 0x0 Encapsulation: ENET2 Bandwidth: 0 Input packets : 0 Output packets: 0 Protocol inet, MTU: 1500 Flags: None <--- Layer 3 Port Addresses, Flags: Is-Preferred Is-Primary Destination: 10.1.1/24, Local: 10.1.3.1, Broadcast: 10.1.3.3
• Desktop + IP Telephony: Two devices connected on a single switch port while keeping the voice and data traffic in
separate VLANs (see Figure 16). This can be done either by configuring the port as trunk port or using the “voip vlan”
feature. Juniper recommends enabling the “voip vlan” feature to allow tagged packets on access ports; packets that
are tagged will be mapped into the voice VLAN while untagged packets will be mapped to the data VLAN.
Figure 16: Independent LAN connections for PC and IP phone
Step 1: Configure the access port to be a member of VLAN “data.”
Note: By default, all ports are access ports; therefore, it is not necessary to configure the “access” keyword.
Data VLANVoice VLAN
Access PortEX Series Switch
root@switch# set interfaces ge-0/0/2.0 family ethernet-switching vlan members data
Step 2: Configure voice VLAN. Even though interface ge-0/0/0.0 is an access port, it is configured to accept both
tagged packets for voice traffic and untagged packets for data traffic.
root@switch# set ethernet-switching-options voip interface ge-0/0/2.0 vlan voice
Copyright © 2010, Juniper Networks, Inc. 31
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
The following command is useful to validate VLANs on a given interface.
root@switch> show ethernet-switching interfaces ge-0/0/2.0 detail Interface: ge-0/0/2.0 Index: 66 State: up VLANs: data untagged unblocked voice tagged unblocked
Note: For full IPT implementation, please refer to the IP telephony (IPT) application note (see References).
LLDP/LLDP-MED
LLDP is a link-layer protocol that allows end devices to advertise their information to each other. LLDP-MED, an
extension of LLDP, is used to communicate with PoE-capable devices and will advertise the VLAN and 802.1p value to
the IP phone based on the VoIP configuration in the Ethernet switching options. LLDP and LLDP-MED are enabled by
default, and it is recommended that they stay enabled.
The output below shows the neighboring devices learned through LLDP.
root@switch> show lldp neighbors LocalInterface Chassis Id Port info System Nameae0.0 00:19:e2:50:87:a0 ae0.0 coreAae1.0 00:19:e2:50:ac:40 ae1.0 coreB
802.3ah (Similar to Cisco’s Unidirectional Link Detection)
IEEE 802.3ah is a standards-based feature that encompasses Operation, Administration, and Maintenance (OAM)
to help increase reliability and streamline administration and maintenance for Ethernet. The 802.3ah standard is a
link-layer and point-to-point protocol; thus, it does not extend beyond the local link. The 802.3ah standard provides
remote failure indication, remote loopback, link monitoring, and discovery, but this section will focus on how it can be
used to detect a unidirectional link, which occurs when a link between two devices is still up but one device is no longer
receiving traffic because of a hardware or software error.
The 802.3ah standard needs to be supported and enabled on the interfaces of both devices. Through discovery (OAM
protocol data unit, or OAMPDU), the two endpoints will establish adjacencies and learn each other’s capabilities. If one
end loses adjacency at any time, then the interface can be forced down.
Currently, 802.3ah is only supported on the EX3200 and EX4200 switches. The EX8200 will support this standard in
future releases. OAM is ideally configured for any fiber connections, especially inter-switch links.
Step 1: Configure OAM action profile for loss-adjacency; when adjacency is lost, bring the link down.
[edit protocols oam ethernet link-fault-management]root@switch# set action-profile <action-profile-name> event link-adjacency-lossroot@switch# set action-profile <action-profile-name> action link-down
Step 2: Enable OAM and link discovery. There are two modes, active and passive; the difference between the two is
that active can exert control over the passive and not vice versa.
[edit protocols oam ethernet link-fault-management]root@switch# set interface ge-0/1/0.0 link-discovery active
32 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Step 3: Apply the action profile to the OAM-enabled interface.
[edit protocols oam ethernet link-fault-management]root@switch# set interface ge-0/1/0.0 apply-action-profile
Step 4 (optional): The PDU timer interval can be configured from 100 to 1000 ms (default is 1000 ms). It is
recommended that timers on both sides be matched.
[edit protocols oam ethernet link-fault-management]root@switch# set interface ge-0/1/0.0 pdu-interval <time>
Step 5 (optional): The PDU threshold determines the number of PDUs that an interface can miss before the link
between peers is considered down. The threshold value range is three to ten; the default is three.
[edit protocols oam ethernet link-fault-management]root@switch# set interface ge-0/1/0.0 pdu-threshold <number>
The output below shows the remote end peer address, 802.3ah current state, and capabilities that are associated with
interface ge-0/1/0.
root@switch> show oam ethernet link-fault-management ge-0/1/0 Interface: ge-0/1/0.0 Status: Running, Discovery state: Send Any Peer address: 00:10:94:00:00:01 Flags:Remote-Stable Remote-State-Valid Local-Stable 0x50 Remote entity information: Remote MUX action: forwarding, Remote parser action: forwarding Discovery mode: active, Unidirectional mode: unsupported Remote loopback mode: supported, Link events: supported Variable requests: supported
MVRP
Multiple LAN Registration Protocol (MVRP) is a standard Layer 2 protocol for creating, deleting, and pruning VLANs.
If a host is a member of a VLAN that the switch is not a part of, then the switch will dynamically create the VLAN
and forward the VLAN requirement to all 802.1q trunks enabled for MVRP. MVRP also manages VLANs on trunk links.
If a downstream switch does not have any members for a given VLAN, then the switch will not “join” the VLAN. The
upstream switch will not need to forward any broadcast, multicast, or unknown unicast on the trunk link for that given
VLAN. MVRP is recommended on all inter-switch trunk links.
root# set protocols mvrp interface ae0.0
Note: VLAN propagation (adding/deleting) will be supported in a later software release.
Port Security
Access security is essential to prevent intruders from accessing and/or attacking the network. With the access switches
being the first line of defense, it is recommended that 802.1X, DHCP snooping, Dynamic ARP Inspection (DAI), and IP
Source Guard be enabled. Working together, these features provide good access layer protection against attackers in a
campus network.
Copyright © 2010, Juniper Networks, Inc. 33
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Table 8: Access Port Security Table
PORT
ROLESPORT SECURITY
802.1X DHCP-SNOOPING DAI IP SOURCE GUARD
Desktop ✔ ✔ ✔ ✔
Desktop + IPT ✔ ✔ ✔ ✔
Printer ✔ ✔
AP ✔ ✔ ✔ ✔
802.1X
802.1X is an IEEE standard that permits port-level access to end users. Teaming 802.1X with Juniper Networks Unified
Access Control allows administrators to define access privileges such as assigning VLANs and pushing policies (CoS,
firewall filters) down to the port level.
Based on physical connectivity, there are three 802.1X modes used to authenticate users when accessing the network.
These three authentication modes are:
• Single: Requires one supplicant to authenticate to an authenticator port. All other supplicants connecting to the
authenticator port after the first has connected successfully, whether they are 802.1X-enabled or not, are permitted
to access the port without further authentication. If the first authenticated supplicant logs out, all other supplicants
are locked out until a new supplicant successfully authenticates to the port.
• Single-secure: Allows only one supplicant to authenticate to an authenticator port. No other supplicant can connect
to the authenticator port until the first supplicant logs out.
• Multiple: Authenticates multiple supplicants individually on one authenticator port. There is no limit to the number
of supplicants that can be configured by a port. This should be used when the port is connected to wireless AP or in
a daisy-chained IPT deployment.
It is highly recommended that 802.1X be implemented on the following port roles: desktop, desktop + IPT, printers, and
all access switches.
Step 1: Configure UAC or radius server information, IP address, and password.
root@switch# set access radius-server 10.255.1.100 secret juniper
Step 2: Configure a radius profile.
root@switch# set access profile corp_radius authentication-order radius radius authentication-server 10.255.1.100
Step 3: Enable 802.1X on the interface and determine which radius profile to authenticate against. For a single device
connected to the switch interface, use single-secure. For multiple devices connected to a single switch interface (such
as AP or daisy-chained IPT deployment), use multiple.
root@switch# set protocols dot1x authenticator authentication-profile-name corp_radius interface ge-0/0/0.0 supplicant multiple
Option: For devices such as IPT or printers that cannot authenticate via 802.1X, use MAC-bypass as an alternative
authentication method.
root@switch# set protocols dot1x authenticator static 0a:0a:0a:0a:0a interface ge-0/0/0.0
34 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
The following command is used to view the 802.1X authentication.
root@switch> show dot1x interface 802.1X Information:Interface Role State MAC address Userge-0/0/0.0 Authenticator Authenticated 00:1C:C4:7E:9E:F1 No User ge-0/0/1.0 Authenticator Connecting ge-0/0/3.0 Authenticator Authenticated 00:11:25:16:A2:F4 Dustin
Access Port Security
There are three access-security features that should be deployed on the access switches to prevent “man-in-the-
middle” spoofing attacks, DHCP snooping, dynamic ARP inspection, and IP source guard.
Figure 17: Hacker posing as the gateway (man-in-the-middle attack)
DHCP Snooping
DHCP snooping prevents rogue DHCP servers by allowing the switch to become aware of DHCP packets. When
enabling DHCP snooping on an EX Series switch, the following assumptions are made:
1. All access ports are untrusted and trunk ports are trusted.
2. On untrusted ports, only DHCP requests/discoveries are allowed. All other DHCP packets are dropped. The switch
also builds a DHCP snooping database of MAC addresses, port locations, VLAN and IP-binding from DHCP
exchanges between the client and server.
Email Server L2/L3 Switch
Victim
Attacker
root@switch# set ethernet-switching-options secure-access-port vlan data examine-dhcp
If there is a local DHCP server connected to the switch, the port characteristics need to be changed from “untrusted” to
“trusted.”
root@switch# set ethernet-switching-options secure-access-port interface ge-0/0/0.0 dhcp-trusted
Copyright © 2010, Juniper Networks, Inc. 35
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
The following command is used to configure static entry for the DHCP snooping database. This is for devices that have
static IP addresses and do not rely on DHCP.
root@core# set ethernet-switching-options secure-access-port interface ge-0/0/0.0 static-ip 10.1.4.10 mac 0b:0b:0b:0b:0b:0b vlan server
The following command shows the DHCP-snooping table.
root@switch> show dhcp snooping binding DHCP Snooping Information:MAC address IP address Lease (seconds) Type VLAN Interface0A:0A:0A:0A:0A:0A 10.1.5.10 67678 dynamic data ge-0/0/0.00C:0C:0C:0C:0C:0C 10.1.5.15 67678 static data ge-0/0/10.00D:0D:0D:0D:0D:0D 10.1.10.12 77478 dynamic voice ge-0/0/1.0
DAI
Dynamic ARP Inspection (DAI) validates ARP packets on the network. The switch will intercept ARP reply packets from
access ports and check them against the IP-MAC database populated by DHCP snooping. If a mismatch is found, then
the ARP packet will be dropped, preventing any man-in-the–middle attacks such as ARP spoofing/poisoning.
root@switch# set ethernet-switching-options secure-access-port vlan data arp-inspection
IP Source Guard
IP Source Guard is dependent on the DHCP snooping binding database. IP Source Guard cross checks the IP source
address and the port upon which it was received. If the packet does not match the DHCP snooping binding database,
then the packet is discarded.
root@switch# set ethernet-switching-options secure-access-port vlan data ip-source-guard
IGMP Snooping
In a Layer 2 environment, multicasts are flooded to all ports in Layer 2 domain, by their nature. For some hosts, this
behavior is undesirable, as they do not require multicast traffic. By receiving unwanted multicast traffic, this can lead
to port congestion, induce latency for other traffic, and force endpoints to use CPU cycles to drop unwanted multicast
packets. IGMP snooping constrains multicast traffic to only interested users in a switched network. With IGMP
snooping enabled, a LAN switch monitors IGMP transmissions between a host (a network device) and a multicast
router, keeping track of the multicast groups and associated member ports. IGMP snooping is enabled by default on
EX Series switches. It is recommended that it remain enabled, with the exception of Service Ports. Service Ports do not
send any IGMP joins.
The output below is an IGMP snooping table taken from an access switch.
root@switch> show igmp-snooping membership VLAN: data 225.1.23.1 * 252 secs Interfaces: ge-0/0/0.0, ge-0/0/1.0, ge-0/0/4.0, ge-0/0/13.0
36 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
Class of Service
In the campus network, CoS is critical to maintaining a high-performance enterprise network that ensures prioritization
of business-critical traffic when congestion occurs, as well as meeting latency and jitter requirements for specialized
types of traffic. Under a high traffic load, voice, video, and other critical applications may be delayed by less critical or
latency/jitter-sensitive traffic in a best-effort (first-in, first-out or FIFO) queue. CoS manages the switch’s resources
based on traffic profile. It is recommended that CoS be implemented at the access ports and at any inter-networking
links (routers and switches).
Figure 18: EX Series CoS model for classification, queuing, and scheduling
EX Series switches classify traffic based on 802.1p, DSCP, or IP Precedence bits and/or MAC, IP, and TCP/UDP fields.
Traffic can be mapped to one of eight egress queues per port. By default, four forwarding classes are predefined:
network-control; assured-forwarding; expedited-forwarding; and best effort. These are mapped to Queue 7, Queue
5, Queue 1, and Queue 0 respectively. Of the four, only two forwarding classes are being used—network-control and
best effort. Network-control is allocated with a five percent buffer of the dedicated port buffer, and serviced as strict-
priority, while best effort is allocated the remaining 95 percent, and serviced as Smoothed Deficit Weighted Round-
Robin (SDWRR).
Forwarding Classes (Queuing)
EX Series switches support up to 16 system-wide forwarding classes, but Juniper recommends configuring the
following forwarding classes: network-control, voice, video, business applications, and best effort. These forwarding
classes should be mapped to queues 7, 6, 5, 2, and 0 respectively. Queues can be allocated and configured for either
strict-priority or SDWRR. This will be discussed further in the scheduling section.
Step 1: Define three additional egress queues for voice, video, and mission critical.
NC Q7
Q6
Q5
Q4
Q3
Q2
Q1
Q0
CLASSIFICATION QUEUING SCHEDULING
Note: This diagram is notdefault CoS behavior.Configuration is required.
File
File
Network
Control
NC
NetworkControl
Voice
Voice
Video
Video
root# set class-of-service forwarding-classes class voice queue-num 5root# set class-of-service forwarding-classes class video queue-num 4root# set class-of-service forwarding-classes class business_applications queue-num 2
Copyright © 2010, Juniper Networks, Inc. 37
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
If required, an additional forwarding class can be defined. Once committed, the queues are created for all ports. Below
is the output of the egress queues that were just configured.
root# run show interfaces ge-0/0/0 detail | find egress Egress queues: 8 supported, 5 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 0 0 1 assured-forw 0 0 0 2 business_app 0 0 0 3 vod 0 0 0 4 video 0 0 0 5 voice 0 0 0 7 network-cont 0 0 0 Active alarms : None Active defects : None
Classification
EX Series switches can classify traffic based on QoS (802.1p, DSCP, or IP Precedence), L2/L3 address, L4 ports, or any
combination of these. There are two types of classifiers on the EX Series switches:
• Behavior Aggregate (BA) Classifiers: Distinguish traffic based on 802.1p, DSCP, or IP Precedence
• Multifield (MF) Classifiers: Distinguish traffic on multiple fields, a combination of source and destination of L2/L3
address, L2/L3 QoS, and/or TCP/UDP ports
This section covers the BA Classifiers.
Step 1: Enter into CoS classifiers hierarchy, and create classification profile based on DSCP.
root# edit class-of-service classifiers dscp traffic_classifiers
Note: EX Series switches can match against DSCP, 802.1p, or IP-Precedence.
Step 2: Import default code-points defined by EX Series switches to avoid defining all QoS code-points.
root# set import default
Note: Use the command “show class-of-service classifier type dscp name dscp-default” to view the default DSCP
code-points defined by EX Series switches.
Step 3: Assign forwarding classes to a packet loss priority (PLP) and DSCP code-points. For the following applications,
Juniper recommends the following classifiers and PLP. Also referred to as Drop Precedence (DP), PLP sets the packet
drop precedence value (low or high) to help prevent queue congestion. Packets with a PLP of “low” have higher buffer
thresholds than a packet with a PLP of “high.” By default, the threshold for high is 100 percent of the buffer.
Table 9: Differentiated Services (Diff/Serv) Table
APPLICATION DIFFSERV PLP
Network-Control CS6 Low
Voice Expedited Forwarding (EF) Low
Video
Class Selector (CS)4, Assured Forwarding
(AF)41Low
AF42, AF43 High
Business ApplicationAF21, AF22 Low
AF23 High
AP Remaining Code Points Low
38 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
root# set forwarding-class voice loss-priority low code-points 101110root# set forwarding-class video loss-priority low code-points [100000 100010]root# set forwarding-class video loss-priority high code-points [100100 100110]root# set forwarding-class business_applications loss-priority low code-points [010010 010100]root# set forwarding-class business_applications loss-priority high code-points 010110
The following output shows the DSCP classifier just created (just a snippet is provided).
root# run show class-of-service classifier name traffic_classifiersClassifier: traffic_classifiers, Code point type: dscp, Index: 39944 Code point Forwarding class Loss priority 010001 best-effort low 010010 business_class low 010011 best-effort low 010100 business_class low 010101 best-effort low 010110 business_class high . . . 011111 best-effort low 100000 video low 100001 best-effort low 100010 video low 100011 best-effort low 100100 video high 100101 best-effort low 100110 video high . . . 101110 voice low 101111 best-effort low 110000 network-control low 110001 network-control low . . .
Scheduling
The next step is to allocate queue buffers and configure queue scheduling. Juniper recommends the following
configuration; network-control and voice traffic should have at least a five percent buffer allocation and be enabled as
a strict high-priority queue. The application queue should have between a 30 and 35 percent buffer allocation and a
transmit rate of 40 percent. The best effort will have the remaining buffer and transmit rate allocation.
Step 1: Enter CoS scheduler.
root# top edit class-of-service
Step 2: Create scheduler profile for network-control, voice, video, business applications, and best effort. Buffer size,
queue priority (low or strict-high), and transmit-rate (weight) can be defined within each profile. On the queues that
are configured as strict-priority queues, then configure a shaper-rate to prevent queue starvation to the other SDWRR.
root# set nc_scheduler buffer-size percent 5root# set nc_scheduler priority strict-highroot# set nc_scheduler shaping-rate 5000000root# set voice_scheduler buffer-size percent 5 # For fixed based chassis, add keyword “exact”. This limits the access to the shared buffer pool. #root# set voice_scheduler priority strict-highroot# set voice_scheduler shaping-rate 5000000root# set video_scheduler buffer-size percent 15root# set video_scheduler priority low
Copyright © 2010, Juniper Networks, Inc. 39
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
root# set video_scheduler transmit-rate percent 50 root# set bapp_scheduler buffer-size percent 25root# set bapp_scheduler priority lowroot# set bapp_scheduler transmit-rate percent 35root# set be_scheduler buffer-size remainderroot# set be_scheduler priority lowroot# set be_scheduler transmit-rate remainder
Note: On the EX Series switches, the egress queues can either be a strict-priority queue or a deficit weighted round-
robin (DWRR) queue. Strict-priority queues must always be the highest numbered queues; any queues that are not
strict-priority are considered DWRR.
Step 3: Enter the CoS scheduler map and create an access scheduler-map profile.
root# top edit class-of-service scheduler-maps access_scheduler
Step 4: Apply the scheduler to the appropriate egress queue.
root# set forwarding-class voice scheduler voice_schedulerroot# set forwarding-class video scheduler video_schedulerroot# set forwarding-class business_applications scheduler bapp_schedulerroot# set forwarding-class best-effort scheduler be_scheduler
Step 5: Create an uplink scheduler-map profile.
root# top edit class-of-service scheduler-maps uplink_schedulerroot# set forwarding-class network-control scheduler nc_schedulerroot# set forwarding-class voice scheduler voice_schedulerroot# set forwarding-class video scheduler video_schedulerroot# set forwarding-class business_applications scheduler bapp_schedulerroot# set forwarding-class best-effort scheduler be_scheduler
Step 6: Enter the CoS interface stanza.
root# top edit class-of-service interfaces
Step 7: Apply the classifier profile and scheduler map profile to an interface. This should be done on both user-facing
and uplink ports.
root# set ge-0/0/0 scheduler-map access_scheduler unit 0 classifiers dscp traffic_classifiersroot# set ae0 scheduler-map uplink_scheduler unit 0 classifiers dscp traffic_classifiers
The following output is the CoS summary for the interface.
root> show class-of-service interface ge-0/0/0 Physical interface: ge-0/0/0, Index: 130Queues supported: 8, Queues in use: 5 Scheduler map: access_scheduler, Index: 48327 Input scheduler map: <default>, Index: 3
Logical interface: ge-0/0/0.0, Index: 2684275700 Object Name Type Index Classifier traffic_classifiers dscp 39944
40 Copyright © 2010, Juniper Networks, Inc.
IMPLEMENTATION GUIDE - Deploying Fixed-Configuration and Chassis-Based EX Series Ethernet Switches in Campus LANs
8010021-002-EN April 2010
Copyright 2010 Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, Junos, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered marks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
EMEA Headquarters
Juniper Networks Ireland
Airside Business Park
Swords, County Dublin, Ireland
Phone: 35.31.8903.600
EMEA Sales: 00800.4586.4737
Fax: 35.31.8903.601
APAC Headquarters
Juniper Networks (Hong Kong)
26/F, Cityplaza One
1111 King’s Road
Taikoo Shing, Hong Kong
Phone: 852.2332.3636
Fax: 852.2574.7803
Corporate and Sales Headquarters
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
Phone: 888.JUNIPER (888.586.4737)
or 408.745.2000
Fax: 408.745.2100
www.juniper.net
To purchase Juniper Networks solutions,
please contact your Juniper Networks
representative at 1-866-298-6428 or
authorized reseller.
Printed on recycled paper
Summary
Juniper Networks EX Series Ethernet Switches provide a flexible solution for small, medium, and large campus
networks. With both fixed and chassis-based EX Series switches, security devices, and management systems,
customers are able to design, manage, and secure their business-critical environments.
References
Campus Reference Architecture: www.juniper.net/solutions/literature/misc/803005.pdf
Deploying IP Telephony with EX Series Switches: www.juniper.net/solutions/literature/app_note/350131.pdf
RFC4594: http://tools.ietf.org/html/rfc4594
Spanning Tree Protocol in Layer 2/Layer 3 Environments: www.juniper.net/techpubs/en_US/junos9.1/information-
products/topic-collections/EX Series/implementation-guide/spanning-trees-EX Series.pdf
Virtual Chassis Best Practices: www.juniper.net/solutions/literature/implementationguides/801018.pdf
About Juniper Networks
Juniper Networks, Inc. is the leader in high-performance networking. Juniper offers a high-performance network
infrastructure that creates a responsive and trusted environment for accelerating the deployment of services and
applications over a single network. This fuels high-performance businesses. Additional information can be found at
www.juniper.net.