vertical campus - juniper networks · the juniper networks vertical campus tested design is based...
TRANSCRIPT
Implementation Guide
Copyright © 2013, Juniper Networks, Inc. 1
Although Juniper Networks has attempted to provide accurate information in this guide, Juniper Networks does not warrant or guarantee
the accuracy of the information provided herein. Third party product descriptions and related technical details provided in this document
are for information purposes only and such products are not supported by Juniper Networks. All information provided in this guide is
provided “as is”, with all faults, and without warranty of any kind, either expressed or implied or statutory. Juniper Networks and its
suppliers hereby disclaim all warranties related to this guide and the information contained herein, whether expressed or implied of
statutory including, without limitation, those of merchantability, fitness for a particular purpose and noninfringement, or arising from a
course of dealing, usage, or trade practice.
VertICal Campus
2 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Table of ContentsIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
Design Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Wired LAN Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6WLAN Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8SRX Series Service Gateway Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Virtual Chassis for Collapsed Backbone Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Subnets and VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Class of Service and Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Forwarding Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Random Early Detection and Congestion Avoidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Remarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Class of Service Used in Design Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Wired LAN Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Building B: Configuring the Campus Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16EX8200 Virtual Chassis Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Verifying and Upgrading the Software Version for XRE200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Verifying and Upgrading the Software Version for EX8200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Configuring the EX8200 for Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Preprovisioning the XRE200 for Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Assembling the EX8200 Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Configuring Virtual Chassis Ports on the EX8200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Configuring Global Settings for the Core EX8200 Virtual Chassis Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Configuring Layer 2 Settings on EX8200 Virtual Chassis Core Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27Configuring Layer 3 Settings for the EX8200 Virtual Chassis Core Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Configure Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Verifying Class of Service Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Building B: Configuring the Access Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Software Version /Upgrading the EX6200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39EX6200 Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Configuring Global Settings for the EX6210 Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Configuring the EX6200 Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Configuring Layer 2 Settings for EX6200 Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Configure Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Verifying Class of Service Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Building A: Configuring the core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
EX4500 Virtual Chassis Procedure Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Configuring Global Settings for the Core Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Configuring a Virtual Chassis for the Mixed Mode Core Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Configuring Layer 2 Settings For Mixed Mode Core Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Configuring Layer 3 Settings For Mixed Mode Core Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61Configure Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Verifying Class of Service Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Building A: Configuring the Access Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Configuring EX4200 as Extended Mode Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Configuring Global Settings for the Core Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Configuring an Extended Mode Virtual Chassis for the EX4200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68To configure a Virtual Chassis for the core switch: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Configuring Layer 2 Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72Configure Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77Verifying Class of Service Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Building A: Configuring EX3300 Access Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81Configuring Global Settings for the Access Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Configuring an EX3300 Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Copyright © 2013, Juniper Networks, Inc. 3
Implementation Guide – Vertical Campus
Configuring Layer 2 Settings for EX3300 Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Configure Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Building A: Configuring EX4200 Dedicated Mode Access switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Configuring Global Settings for the Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Configuring a Dedicated Mode Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Configuring Layer 2 Settings for EX4200 Dedicated Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Configure Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Wireless LAN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Wireless Setup Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Wireless LAN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Pre-requisites for WLAN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Running Quick start on WLC2800-1b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Configuring VLANs and 802 .1q trunking for WLC2800-1b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107Running Quickstart on WLC2800-2b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Configuring VLANs and 802 .1q trunking for WLC2800-2b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Installing Ringmaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Configuring WLCs and WLAs using Ringmaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Add devices to a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Uploading WLC2800-1b into RingMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Uploading WLC2800-2b into RingMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Creating a Mobility Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Activating Changes from the cluster wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Creating a Cluster in the Mobility Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111WLC2800-1b VLAN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111WLC2800-2b VLAN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Configuring Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Cluster RADIUS configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Cluster Guest Wireless Authentication Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Configuring the RADIUS Authentication Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Creating a RADIUS Server Group for guest users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Configuring the SmartPass authentication options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Setting up VLAN Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114VLAN Profile for Building A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114VLAN Profile Building B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Radio Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Creating Radio Profiles for building A and Building B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Setting up Wireless Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Setting up Building A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Setting up Building B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Setting up Wireless Voice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Building A Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Building B Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Guest Wireless setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Adding WLAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Building B WLA configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Preparing Clients for Wireless Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Configuring a Client for Guest Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Configuring a Client for Corporate Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
SRX Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Configuring the SRX Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
Configuring Security Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Configuring Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Configuring Routing and OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Configuring NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Configuring DHCP services for guest VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133Appendix A: Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134Appendix B: Configuring DHCP on EX Series Ethernet Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Appendix C: EX8200 Virtual Chassis Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Appendix D: References and Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142About Juniper Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143
4 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
List of FiguresFigure 1: Overview of the Tested Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Figure 2: Guest Wireless Overview (Centralized WLAN Switching) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Figure 3: Local Switching Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Figure 4: WLC Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 5: SRX Zone Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 6: SRX Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Figure 7: Configuring the EX8200VC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 8: Building B Connection Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 9: EX8200 Virtual Chassis Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 10: EX8200 Interface Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 11: EX6200 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figure 12: EX4500VC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figure 13: Building A Connection Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 14: EX4200VC-3a Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figure 15: Configuration of EX3300VC-1a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
Figure 16: EX4200VC-2a Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Figure 17: Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Figure 18: Wireless Network Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Figure 19: ipconfig Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Figure 20: Verifying Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Figure 21: SRX Network Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Figure 22: SRX Link Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
Figure 23: Configuration Complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
Figure 24: EX8200 Virtual Chassis with XRE200 Connected to Each Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
List of TablesTable 1: Equipment and Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Table 2: Campus VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Table 3: VLANs by Building . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Table 4: Building A VLAN and Device Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Table 5: Building B VLAN and Device Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Table 6: CoS by Device Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Table 7: CoS Forwarding Classes Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Table 8: VLANs Configured on EX6200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Table 9: EX6200 Trunked VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Table 10: VLAN to Port Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Table 11: EX4200 Virtual Chassis 1 VLAN Address Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Table 12: EX3300 VLAN IP Address Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Table 13: EX4200 Virtual Chassis 2 VLAN IP Address Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Table 14: SSID VLAN Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Table 15: Authentication Methods by SSID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Table 16: EX4200/4500 and EX8200 Side by Side Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Table 17: EX8200 Virtual Chassis Member IDs and Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Table 18: EX8200VC FPC and Interface Numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Copyright © 2013, Juniper Networks, Inc. 5
Implementation Guide – Vertical Campus
Introductionthe Juniper Networks® Vertical Campus Implementation Guide provides a simple, tested, step-by-step process
for rapidly deploying a large campus solution. the deployment incorporates the most commonly used enterprise
network technologies to provide a simple and scalable network architecture that includes laN, WlaN, and security
components. this guide presents a specific configuration of Juniper Networks hardware and software platforms that
have been tested and provide a reliable foundation on which to base a customized network for your business.
the tested implementation is created with the following design objectives:
• easy to deploy – Consistent deployment approach for all products included in the design. the examples provide
reference methodologies and configurations to enable rapid deployment of a resilient network infrastructure.
• resilient – simple and robust design, maximizing user productivity by protecting traffic against unplanned outages.
• Flexible – adapted for modular expansion so that users can scale and adapt the network without requiring extensive
changes or forklift upgrades.
• solid foundation – easy support for additional technologies, such as video, collaboration, and other real-time traffic
demands.
some of the advantages include:
• modular design – each technology presented can be deployed independently of the others
• efficient and cost-effective deployment using a standardized design methodology
• redundant, highly available infrastructure for wired, wireless, and Internet connectivity
• Deployable by It professionals with a moderate amount of technical experience
• easy to manage, with few logical devices and protocols to configure
• standardized methodology to reduce deployment time
• reduced number of hardware and software platforms to learn, maintain, and spare
Scopethis document presents a sequential construction and configuration of a tested design that you can successfully
reproduce. the first part of the document describes the network elements used and their operation. It also includes
a scheme for a common layer 2 (l2) and layer 3 (l3) set of boundaries and network interfaces. the implementation
portion contains the specific configurations used to create this network.
this guide is intended for network designers and administrators who:
• Have a network that supports 1,000 or more connected employees
• require wired and wireless access for their employees
• Need a simplified, resilient network infrastructure
• Need a high-performance network that can be easily expanded and adapted to support new technologies
• are new to Juniper Networks products
• are system engineers who need a standardized process to design and deploy networks that comprise Juniper Networks
laN, WlaN, and security products
Design Considerationsthe Juniper Networks Vertical Campus tested design is based on Juniper Networks switching, wireless laN, and
security products. It presents an overall design with configurations to construct a campus network for 1,000 or more
users. this tested design is intended to be a starting point for configuring your own network and incorporates the most
commonly used enterprise network technologies. For information on additional functionality for each product, consult
the appendixes at the end of this document.
Design Componentsthe network detailed in this document is divided into three separate functional blocks or modules—laN and switching
infrastructure, wireless, and security. these sections highlight the design choices and main features implemented for
each component. although each section can stand on its own, the sections are presented in the logical sequence in
which the network would be deployed.
the equipment and software listed in table 1 conform to what was used to verify this design and its included features.
Future software releases should support the same functionality. Check the release notes for the specific version of
software you intend to deploy before deploying Ip in your specific environment.
6 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Table 1: Equipment and Software
Model Software Description
eX-Xre200-aC 12.1r1.9 eX8200 Virtual Chassis Juniper Networks Xre200 external routing engine with dual aC power supplies, dual fans, two 160 GB hard disks and one 4-port 10/100/1000Base-t rJ-45 I/O card
eX8208-reDuND-aC 12.1r1.9 redundant eX8208 2000 W aC system bundle: 8-slot chassis with passive backplane and 1x fan tray, 2x routing engine with switch fabric, 1x switch fabric module, 6x 2000 W aC psus with power cords, and all necessary blank panels
eX8200-8Xs n/a 8-port 10 Gbe sFp+ line card; requires sFp+ optics sold separately
eX8200-40Xs n/a 40-port Gbe / 10Gbe line card; requires sFp and/or sFp+ optics sold separately
eX4500-40F-VC1-FB 12.1r1.9 40-port Gbe/10Gbe sFp/sFp+ front-to back airflow, 128 Gbps Virtual Chassis Interconnect module, hardware support for Data Center Bridging, and support for eight pFC (802.1Qbb) queues
eX4200-48p 12.1r1.9 48-port 10/100/1000Base-t (48 poe ports) + 930 W aC psu. Includes 50cm Virtual Chassis cable.
eX-pWr2-930-aC n/a 930 W poe+ aC power supply unit (psu)
eX-um-2X4sFp n/a 2-port 10G sFp+ / 4-port 1G sFp uplink module
eX3300-48p 12.1r1.9 eX3300 48-port 10/100/1000Base-t (48 poe+ ports) with 4 sFp+ uplink ports (optics not included)
eX3300-24p 12.1r1.9 eX3300 24-port 10/100/1000Base-t (24 poe+ ports) with 4 sFp+ uplink ports (optics not included)
eX3300-48t 12.1r1.9 eX3300 48-port 10/100/1000Base-t with 4 sFp+ uplink ports (optics not included)
eX-sFp-10Ge-DaC-1m n/a sFp+ 10-Gigabit ethernet Direct attach Copper (twinax copper cable) 1 m
srX650-Base-sre6-645ap 12.1r1.9 srX650 services Gateway with sre 6, 645 W aC poe psu; includes 4 onboard 10/100/1000Base-t ports, 2 GB Dram, 2 GB CF, 247 W poe power, fan tray, power cord and rack-mount kit
srX-Gp-16Ge n/a • 16 port• 10/100/1000Base-t• XpIm
WlC2800* 7.7.1.6 WlaN controller with two 10Gbe XFp ports and 8 x 1000Base-t (rJ-45 and sFp) ports, including single psu and 64 ap license.
Wla532-us* n/a ap with dual radios 802.11a/b/g/n 3x3 mImO (3ss), single 1000Base-t 802.3af poe ethernet port, 6 internal antennas. Not rated for plenum use. Ceiling mount bracket included. For operation only in usa.
Wlm-rmts-10 7.7.1.3.0
*When estimating your wireless needs, 25–30 users per ap is a good place to start for most wireless deployments. For
highest performance wireless, one ap per 10–15 users is the recommended starting value.
Wired LAN Infrastructurethe example network tested is shown in Figure 1. It uses a two-tiered, collapsed core network model in each building.
this design combines the distribution and core layers together, reducing the complexity and cost of the network.
the heart of the network is the switching infrastructure. Juniper Networks eX8200 ethernet switches are used for the
campus core. the two eX8200 switches are configured as a single Virtual Chassis, which provides high availability (Ha)
and resiliency features not found in standalone chassis-based solutions. this configuration provides hardware-level
redundancy with a simplified configuration process because only one logical device needs to be configured, instead of
manually configuring and synchronizing multiple core devices.
the Juniper Networks Virtual Chassis technology reduces the number of actively managed devices and removes the
need for relying on legacy redundancy protocols, such as spanning tree protocol (stp) and Virtual router redundancy
protocol (Vrrp). Virtual Chassis also provides the flexibility to incrementally grow the network on an as-needed basis
without compromising performance or availability.
Copyright © 2013, Juniper Networks, Inc. 7
Implementation Guide – Vertical Campus
WLA
WLA
WLA
WLA
WLA
WLA
WLA
BUILDING A BUILDING B
EX4200VC-2a
EX3300VC-1a
EX4200VC-3a
LAGLAG
LAGEX8200VC-1b
SRX SeriesCluster
WLCCluster
INTERNET
EX6200-1b
App Servers
Centralized DHCPand other services
EX4500VC-1a LAG
LAG
Figure 1: Overview of the Tested Network
Building Athe Building a core provides high-density 10-Gigabit ethernet (10Gbe) and 1-Gigabit ethernet connectivity by
combining the Juniper Networks eX4500 ethernet switch and Juniper Networks eX4200 ethernet switch in a single
Virtual Chassis. this provides the core connectivity and routing for the network and acts as the layer 2 and layer 3
boundary for the access switches. the Building a core is connected to the Building B core (eX8200 Virtual Chassis)
using four 10Gbe ports configured as a routed link aggregation group (laG) and distributed across multiple line cards
on each side for redundancy.
the access layer uses eX4200 and/or eX3300 series switches providing power over ethernet (poe) and layer 2
connectivity back to the core, using two 10Gbe ports configured for laG. each access switch is connected back to the
core on different line cards, providing protection in case a single device fails on either end.
Building BBuilding B serves as the campus core; this is where all services are centrally located. the WaN connection, servers,
WlaN controllers all reside in Building B.
the Building B core is made up of two Juniper Networks eX8208 ethernet switches and two Juniper Networks Xre200
external routing engines, which are configured as a single Virtual Chassis. servers and services are directly connected
to the core switches. the eX8200 Virtual Chassis has many separate points of redundancy. each eX8208 has
redundant route engines that are connected to the Xre200. the Xre200s act as primary and backup route-engines
for the eX8200 Virtual Chassis. the eX8208 switches are connected together using six 10Gbe interfaces configured
as Virtual Chassis ports. this system is highly resilient and will be fully functional even if multiple components fail. see
the Best Practice Guidelines for Deploying EX8200 Virtual Chassis Configurations for more information.
the access layer in Building B uses eX6210 switches. the eX6210 is a modular chassis that meets the high-density
1Gbe and poe connectivity that is required in heavily populated environments. the eX6210 is equipped with redundant
route-engines and is connected to the building core via four 10Gbe interfaces. the interfaces are configured as a laG
and distributed between the eX8208 switches so that there is no single point of failure.
8 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
WLAN Infrastructurethe wireless network is configured for centralized switching of guest user traffic, as shown in Figure 2. Wireless user
traffic is received by access points (aps) and then sent to the wireless laN controller (WlC). the WlC then identifies
the traffic by user profile, authenticates against raDIus, and places the traffic in the proper VlaN. the gateway
for guest access traffic is the Juniper Networks srX series services Gateway, which provides isolation between the
enterprise users and guest users.
enterprise users and voice users use the local switching feature of the wireless system, as shown in Figure 3. enterprise
users are authenticated using 802.1x and raDIus when they connect to the wireless network. When an enterprise user
is authenticated, the Wla (Wireless laN access point) places user traffic directly onto the local VlaN to which the
user is assigned. this approach provides the lowest latency, highest performance, and best scalability. an individual
Wla can handle local and centralized switching of traffic simultaneously.
WLC uses centralized switching for xyzcompany_guest SSID, tunneling all tra�c and forwarding to WLC.
WLA
SRX SeriesCluster
WLCCluster
WLC places user tra�c into
guest_wirelessVLAN (60)
xyzcompany_guestWLAN
SRX Series is theonly gateway for
guest_wireless VLAN (60)
INTERNET
SwitchTra�c Tunneled
to/from WLCEX Series
Figure 2: Guest Wireless Overview (Centralized WLAN Switching)
Guest users are placed on the guest VlaN and can access the Internet only. Corporate users have full access to the
intranet and the Internet.
WLAs use local switching for xyzcompany_internal and xyzcompany_voice WLAN SSIDs.
WLAs are configured with trunk ports so they can place user tra�c directly onto the correct VLAN without tunneling tra�c to the WLC.
WLA
VoIP PhoneFile Server
WLC places user tra�c into
guest_wirelessVLAN (60)
xyzcompany_internal orxyzcompany_voice WLANs
Trunk Port
SwitchEX Series
Figure 3: Local Switching Overview
Copyright © 2013, Juniper Networks, Inc. 9
Implementation Guide – Vertical Campus
You can configure the WlCs in clusters of up to 32 units. the design example uses a two-WlC cluster, as shown in
Figure 4. the primary WlC (also known as the primary seed controller) is in charge of configuration management for all
WlCs and aps and acts as a central configuration point for all wireless laN changes.
Each WLA forms two WLC connections — a primary WLC connection and a backupWLC connection. This provides non-stop wireless performance in case of failure.
The primary WLC is the configuration point for the network andautomatically load balances WLAs between the WLCs in the cluster.
Wireless LANController
Cluster
WLA
WLA
PrimaryWLC
SecondaryWLC
SwitchEX Series
Figure 4: WLC Clustering
the primary WlC also configures and load-balances the aps across the WlCs to distribute the wireless traffic load.
access points form connections with two separate WlCs—one connection is active, and the other acts as a backup. If
the connection to the active WlC is interrupted, the backup connection takes over immediately, preserving all existing
wireless sessions so that users are not affected.
SRX Series Service Gateway Infrastructurethe Juniper Networks srX series services Gateway is a zone-based firewall in which different traffic networks are
classified as logical zones for easier management. Figure 5 illustrates the logical zones that are defined in the tested
design and the VlaNs contained in each zone.
this illustration sets the Guest zone apart from the eX series to present a clear logical view. the eX series switches
provide only layer 2 connectivity for these zones. the Guest VlaNs use the srX series services Gateway as their
default gateway to obtain Ip addresses using DHCp.
INTERNET EDGE ZONE
MANAGEMENT ZONE
EX SeriesSwitch SRX650-2b
data_wireless_1a data_wireless_1bdata_wired_1b data_wired_1a
management_1bmanagement_1a
UNTRUST ZONEvoip_wired_1a voip_wired_1bservers_1b servers_2b
access_points_1a access_points_1bvoip_wireless_1a voip_wireless_1b
internet_edge
SRX650-1b
GUEST ZONEguest_wireless
INTERNET
SERVICEPROVIDER 1
SERVICEPROVIDER 2
Figure 5: SRX Zone Overview
the Internet edge zone is where most of the tested network VlaNs reside. each VlaN uses the eX series core switch
as its gateway. the internet_edge VlaN is where the eX series forwards traffic requests intended for the Internet to
the srX series. the management VlaNs are in the management zone and kept separate by security policies on the
srX series. this security configuration protects the network management system from intrusion. the untrust zone
connects the srX series to the Internet and is where Network address translation (Nat) is performed. this zone highly
restricts inbound traffic from the Internet.
10 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Clustering SRX Service GatewaysYou can configure the srX series services Gateways as a cluster that operates as a single device with a single point
of configuration. traffic state is maintained between each pair of devices. When the srX series devices are clustered,
you can configure special interfaces called redundant ethernet (reth) interfaces. a reth interface has a primary and
secondary owner. traffic is directed to the primary owner, and the secondary owner takes over in case of a failure.
When clustered, the srX series devices have a control link to maintain state, configuration, and all other control
features. they also have a fabric link that is used to forward traffic within the cluster.
In this network, the srX series services Gateways are configured to use the fabric link to forward traffic in case of WaN
connection failures. this is a useful configuration for any similar network design that has two service providers and uses
Nat, resulting in two possible source addresses for Internet-bound traffic.
Figure 6 illustrates normal and failure traffic flow.
SRX Tra�c Flow—Normal
SRX650-1b
SRX650-2b
Worldwide Web,FTP, email, etc.
ge-4/0/1
ge-20/0/1
ge-2/0/0
ge-11/0/0
ge-2/0/1 10.94.44.2
10.94.44.6ge-11/0/2
INTERNET
SERVICEPROVIDER 2
EX8200Virtual Chassis
SERVICEPROVIDER 1
SRX Tra�c Flow—SRX650-1b Reth Failure
SRX650-1b
SRX650-2b
Worldwide Web,FTP, email, etc.
ge-4/0/1
ge-20/0/1
ge-2/0/0
ge-11/0/0
ge-2/0/1 10.94.44.2
10.94.44.6ge-11/0/2
INTERNET
SERVICEPROVIDER 2
EX8200Virtual Chassis
SERVICEPROVIDER 1
SRX Tra�c Flow—SRX650-1b Failure
SRX650-1b
SRX650-2b
Worldwide Web,FTP, email, etc.
ge-4/0/1
ge-20/0/1
ge-2/0/0
ge-11/0/0
ge-2/0/1 10.94.44.2
10.94.44.6ge-11/0/2
INTERNET
SERVICEPROVIDER 2EX8200
Virtual Chassis
SERVICEPROVIDER 1
SRX Tra�c Flow—Service Provider 1 Failure
SRX650-1b
SRX650-2b
Worldwide Web,FTP, email, etc.
ge-4/0/1
ge-20/0/1
ge-2/0/0
ge-11/0/0
ge-2/0/1 10.94.44.2
10.94.44.6ge-11/0/2
INTERNET
SERVICEPROVIDER 2EX8200
Virtual Chassis
SERVICEPROVIDER 1
Figure 6: SRX Traffic Flow
the srX devices tested are configured in an active or passive mode when service provider 1 has a better route
preference and is used for all Internet traffic, unless there is an outage. traffic is allowed to be routed across the fabric
link to retain the use of service provider 1 in case of a local interface outage. this removes the need to reset the session
because the source Nat addresses do not change.
Copyright © 2013, Juniper Networks, Inc. 11
Implementation Guide – Vertical Campus
In the examples illustrated in Figure 6, no session is reset in the case of local link failure because there is no change in
the source Nat address for the sessions—they continue to use the same service provider. Where the source address for
srX650-1b or service provider 1 is lost completely, traffic switches to service provider 2. the source Ip address for the
traffic changes when this occurs and results in existing sessions being reset due to the change.
Virtual Chassis for Collapsed Backbone Designtraditional networks achieve high availability and performance by configuring redundant devices and complex
protocols in multiple tiers that each require independent configuration, thereby increasing network complexity. this
design uses a collapsed core, a two-tier model that combines the distribution and core layers, reducing the complexity
and cost of the network. although the tiers are reduced, the network provides the redundancy benefits typically
associated with multiple-tiered designs.
a Virtual Chassis allows multiple eX series switches to act as a single device, achieving device-level redundancy
without creating loops in the network, requiring additional protocols, or tedious configuration management between
devices. all links can be fully utilized, reducing the cost associated with bandwidth upgrades and providing improved
resiliency and performance.
the core and distribution layer is commonly configured as the layer 2 and layer 3 boundary. using a Virtual Chassis in
both the core and access layer allows further simplification of the network by reducing the number of actively managed
devices.
NOTE: Juniper Virtual Chassis technology is unique in its ability to span distances of up to 40 km between devices.
multiple wiring closets—in the same or different buildings—can be easily combined to reduce the total number of
managed devices.
Subnets and VLANsIt is highly recommended that you consistently implement a VlaN and subnetting convention throughout a deployed
network to decrease network management and troubleshooting complexity. You can easily adapt the configuration
presented in this section to any network environment. the configuration matches the VlaN ID with the third octet of
the subnet used (where applicable) to simplify the network and maintain consistency. It is also recommended to leave
room between VlaN numbering to allow for future expansion and to maintain a consistent range of VlaNs for specific
functions. the network example uses the following VlaNs and addressing.
• VlaNs 8–31 are dedicated to wired data and voice. the tested design uses only four of these VlaNs, leaving plenty of
room for future expansion.
• VlaNs 32–42 are dedicated for corporate wireless data and voice access. the tested design uses only four of these
VlaNs
• VlaNs 44–59 are dedicated for network infrastructure.
- the management VlaN manages all the network devices, such as switches and routers.
- the ap VlaNs provide connectivity to the Wlas.
- the server VlaNs service network servers and applications. they are connected to the network.
- the internet_edge VlaN is where the eX8200 Virtual Chassis ethernet switch connects to the srX series services
Gateway and further out to the Internet. this is where the majority of security policies on the srX series are enforced.
• VlaN 60 is used for guest wireless access. the guest VlaN connects directly to the srX series services Gateway. the eX
series switches do not have any interfaces on the guest VlaN—it acts only as a layer 2 switch.
the network example uses private addressing, which enables flexible Ip address allocation. In this design, many of
the networks use a 24-bit subnet mask, but larger subnet masks are used for some services to reduce the number of
subnets and VlaNs to be managed and simplify configuration. larger subnets reduce the number of subnets required,
allowing more hosts to participate in each subnet.
the VlaNs are named in this order: purpose, number, and building. For example, the VlaN name “data_wired_1a”
indicates the purpose (data wired) , the number of the VlaN (1), and the building (a).
You should also reserve some addresses on each subnet for networking devices, typically the first or last few addresses
in a subnet. this design reserves the first 10 Ip addresses of the subnet for network devices and the last Ip address
(.254) for the srX series interface if it resides on a subnet.
tables 2 and 3 map the VlaNs IDs and subnets that are configured on each device. the core switches are configured to
support all VlaNs pertinent to their building. each access switch is configured with its management VlaN address.
12 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Table 2: Campus VLANs
VLAN ID VLAN Name Subnet
8 data_wired_1b 10.10.8.0/22
12 data_wired_1a 10.10.12.0/22
20 voip_wired_1a 10.10.20.0/22
24 voip_wired_1b 10.10.24.0/22
32 data_wireless_1a 10.10.32.0/22
36 data_wireless_1b 10.10.36.0/22
40 voip_wireless_1a 10.10.40.0/23
42 voip_wireless_1b 10.10.42.0/23
44 internet_edge 10.10.44.0/24
46 servers_1b 10.10.46.0/24
48 servers_2b 10.10.48.0/24
50 management_1b 10.10.50.0/24
51 management_1a 10.10.51.0/24
52 access_points_1b 10.10.52.0/24
54 access_points_1a 10.10.54.0/24
60 guest_wireless 10.10.60.0/24
Table 3: VLANs by Building
Building A VLANs Building B VLANs
VLAN ID VLAN Name Subnet VLAN ID VLAN Name Subnet
12 data_wired_1a 10.10.12.0/22 8 data_wired_1b 10.10.8.0/22
24 voip_wired_1a 10.10.24.0/22 20 voip_wired_1b 10.10.20.0/22
36 data_wireless_1a 10.10.36.0/22 32 data_wireless_1b 10.10.32.0/22
42 voip_wireless_1a 10.10.42.0/23 40 voip_wireless_1b 10.10.40.0/23
51 management_1a 10.10.51.0/24 44 internet_edge 10.10.44.0/24
54 access_points_1a 10.10.54.0/24 46 servers_1b 10.10.46.0/24
48 servers_2b 10.10.48.0/24
50 management_1b 10.10.50.0/24
52 access_points_1b 10.10.52.0/24
60 guest_wireless 10.10.60.0/24
the wireless aps are on the access_points VlaNs for each building and communicate with the WlCs that reside on the
management_1b VlaN.
NOTE: Having Wlas and WlCs on different subnets requires configuring the WlC Ip addresses using option 43 on
the DHCp servers so that the Wlas boot and find the WlCs automatically. see Deploying a Secure Wireless LAN or
Juniper’s Mobility System Software Configuration Guide for more details on Wla boot options.
Wireless traffic from guest users on the aps is placed in the proper VlaN when received by the WlC. each WlC has a
configured trunk port on the management_1b and guest_wireless VlaNs.
Copyright © 2013, Juniper Networks, Inc. 13
Implementation Guide – Vertical Campus
Table 4: Building A VLAN and Device Map
Building A Device and VLAN Map
VLAN ID VLAN Name Subnet EX4200-
VC-1aEX3300-
VC-1aEX4200-
VC-2aEX4200-
VC-3a WLA
12 data_wired_1a 10.10.12.0/22 Ip VlaN VlaN VlaN
20 voip_wired_1a 10.10.20.0/22 Ip VlaN VlaN VlaN
32 data_wireless_1a 10.10.32.0/22 Ip VlaN VlaN VlaN VlaN
40 voip_wireless_1a 10.10.40.0/23 Ip VlaN VlaN VlaN VlaN
51 management_1a 10.10.51.0/24 Ip Ip Ip Ip
54 access_points_1a 10.10.54.0/24 Ip VlaN VlaN VlaN Ip
Table 5: Building B VLAN and Device Map
Building B Device and VLAN Map
VLAN ID VLAN Name Subnet EX8200-
VC-1bEX6200
-1b WLC SRX WLA
8 data_wired_1b 10.10.8.0/22 Ip VlaN
24 voip_wired_1b 10.10.24.0/22 Ip VlaN
36 data_wireless_1b 10.10.36.0/22 Ip VlaN VlaN
42 voip_wireless_1b 10.10.42.0/23 Ip VlaN VlaN
44 internet_edge 10.10.44.0/24 Ip Ip
46 servers_1b 10.10.46.0/24 Ip
48 servers_2b 10.10.48.0/24 Ip
50 management_1b 10.10.50.0/24 Ip Ip Ip Ip
52 access_points_1b 10.10.52.0/24 Ip VlaN Ip
60 guest_wireless 10.10.60.0/24 VlaN Ip Ip
Class of Service and Quality of Servicethis section provides a high-level description of the most commonly used Juniper quality of service (Qos) and class of
service (Cos) items. Not all of these are used in the network example. they are listed here to provide a comprehensive
picture of the options available.
For the purposes of this guide, Qos is the manipulation of aggregates of traffic so that each is forwarded in a fashion
that is consistent with the required behaviors of the applications generating that traffic. From a user’s point of view,
Qos is experienced on the end-to-end (usually round trip) flow of traffic. It is implemented as a set of behaviors at
each hop. this is an important distinction. Basically, a single hop with no configured Qos can destroy the end-to-end
experience, and subsequent nodes can do nothing to recover the end-to-end quality of experience for the user. that
does not mean that Qos must be configured at every hop. However, it is critical to understand that a single, congested
hop can be the undoing of the most intricate Qos design.
On the other hand, Cos within the Junos Os is a configuration construct used to configure an individual node to
implement certain behaviors at that node so that the end-to-end Qos is consistent with the desired end-to-end user
experience or application behavior.
each class is associated with an aggregate of traffic that requires the same behaviors as it flows through the network
device. Classes do not relate implicitly to traffic belonging to a single application. Instead, any application requiring the
same behaviors generates traffic belonging to the same class.
each Cos implementation has certain functions that are required to be able to influence the behavior of outbound
packets on a particular interface. In the network example, only some of the Qos and Cos methods are used. For more
information on these methods, see Deploying Basic QoS or Juniper technical documentation.
NOTE: each vendor’s networking equipment implements the control of these functions in different ways and might use
slightly different terminology. the terminology in this guide is used in Junos Os configurations. the explanations are
vendor-agnostic to be broadly applicable to different vendors’ equipment.
14 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Forwarding Classa forwarding class is a label used entirely within a network node. It identifies all traffic that requires a single behavior
when leaving that node. a forwarding class does not explicitly appear outside a node. although if the Qos configuration
of all nodes in a network is consistent, it can easily be derived from information in packet headers.
ClassificationClassification identifies the class to which a packet belongs. Classification is usually initially performed on ingress
to each node, although a packet can be reclassified at various points on its path through a network node. Junos Os
has three main approaches to classifying packets, which vary in their degree of flexibility and in the complexity of
the required configuration: interface-based, behavior aggregate (Ba), and multifield (mF). these approaches are not
mutually exclusive and can be applied in a series to get a less granular first-pass behavior, followed by a more granular
reclassification of a subset of the traffic.
Interface-based ClassificationIf all traffic arriving on a single interface is known to be associated with a single class, the easiest way to classify this
traffic is to associate all traffic arriving on the interface with the relevant forwarding class. While trivial to implement,
this method assumes that all traffic arriving on the interface is of the same class. there is no inherent mechanism
to indicate any exceptions, so it is very inflexible. You can use interface-based classification in conjunction with mF
classifiers to provide more granular exceptions to the default interface classification, if required.
TIP: this mechanism is useful if the upstream node is untrusted and you want to bleach all traffic coming in by
applying a single class (usually Best effort).
Behavior Aggregate ClassificationBa classification provides a good balance between flexibility and complexity. this approach is particularly attractive
when the traffic being classified is transported in large aggregates, for example, in the core of a network where
traffic associated with many unique applications passes over a single link, making mF classification unattractive. Ba
classification relies on markings placed in the headers of incoming packets: ethernet frames, Ipv4 or Ipv6 packets,
or mpls frames. each of these packet or frame types includes a field in the header specifically designated for the
indication of a class to which this packet has been previously assigned.
ethernet 802.1Q VlaN frames include three 802.1p bits to indicate previous assignment. Ipv4 packets have the type
of service byte from which you can use either the three precedence bits or 6 bits to indicate the Diffserve Code point
(DsCp). Ipv6 has 6 bits of the Ipv6 DsCp, and mpls has the three experimental bits. the network example uses the
DsCp marking and Ba classification method.
the main constraint with this model is that the upstream node must be trusted to correctly (and fairly) mark packets.
If the upstream node cannot be trusted, the node could mismark traffic into a class that receives a higher Qos than it
requires.
Multifield Classificationthe most flexible but most complex classification to configure and maintain is mF classification. It uses firewall filters,
also known as access lists, to identify arbitrary attributes of an Ip packet—it is less commonly applicable to non-Ip
traffic types—and places traffic into a particular traffic class based on the contents of the Ip packet.
this approach is constrained only by the characteristics that can be matched in a firewall filter. It is possible to be very
granular in the choice of traffic class to which the packet belongs. However, granular choices require comparatively
complex filters, which might have to be customer-specific. this degree of complexity and administrative overhead
makes using mF classifiers attractive when the upstream node is not trusted (or not able) to mark the packets, and the
requirement to apply Qos based on arbitrary parameters is strong.
mF classifiers can also be used to modify the forwarding class selected by a Ba or interface classifier. You make a
rough classification based on a Ba or interface marking and then reclassify a subset of the traffic based on arbitrary
attributes in the Ip headers. the network example does not use mF classification, but it can be easily added to the
network.
Policingpolicing applies a hard limit to the rate at which traffic can access a resource (for example, upon ingress to a node or
to a queue on egress). a policer constrains access to the node or queue. If a packet is determined to be nonconforming
and should not gain access to the protected resource, it is dropped or reclassified. the hard-drop behavior can have a
negative impact, particularly on tCp traffic and when the policer is run consistently at its limit. While it is possible to
reclassify packets based on a policer, it is important to avoid reordering packets in applications that are sensitive to the
order in which packets are received, such as voice, video, and other real-time traffic. the example does not use policing.
Copyright © 2013, Juniper Networks, Inc. 15
Implementation Guide – Vertical Campus
Random Early Detection and Congestion Avoidancerandom early detection (reD), also known as random early discard, is a congestion avoidance mechanism. It helps
mitigate the impact of congestion, specifically with tCp-based traffic. For a thorough review of the behavior of tCp in
the presence of congestion and why reD can help avoid some of the worst aspects of that behavior, see QoS Enabled Networks: Tools and Foundations, by peter lundqvist and miguel Barreiros, (2011, John Wiley & sons).
By selecting random tCp packets from a queue and discarding them, the endpoint that was awaiting delivery of that
packet fails to send an acknowledgement for the packet (or, if that packet was an acknowledgement, the far end does
not receive the acknowledgement). this triggers retransmission of the packet and reduces the transmission window
size. as a consequence, it also reduces the speed with which the source transmits tCp packets, thereby reducing the
degree of congestion. the random nature of selecting packets to be dropped ensures that no single flow of traffic,
application, or source is unfairly penalized, and every source continues to get its “fair share” of the available capacity on
a link that is close to congestion.
although the mechanism is “fair” to all, Qos is not necessarily about being fair to all. rather, Qos is about ensuring that
high-priority traffic—high value or sensitive to loss, latency, or jitter—is given priority. to manipulate the rate at which
packets belonging to particular forwarding classes are dropped, it is necessary to apply a weight to each forwarding
class. this process is known as weighted reD (WreD). It is particularly important to apply a weight to avoid dropping
packets in forwarding classes that are intolerant of loss, such as expedited forwarding and assured forwarding.
Often, the traffic associated with applications that are intolerant of loss, latency, and jitter is transported in uDp. In this
case, using reD is counterproductive because it damages the perceived Qos of the application. In addition, because
uDp has no built-in mechanism to identify the loss of a packet and modify its rate of transmission, the packet is either
lost (reducing the perceived Qos) without having significant impact on the throughput, or worse, the application
identifies the loss and demands retransmission of the packet, so the packet is then seen twice, potentially increasing
the congestion. the network example does not use WreD.
Shapingshaping limits the rate at which traffic can be transmitted. unlike policing, it acts on traffic that has already been
granted access to a queue but is awaiting access to transmission resources. traffic that does not conform to the
shaper’s criteria is held in the queue until it does conform. No explicit constraint is placed on more traffic entering
the queue, as long as the queue is not full. shaping can be less aggressive than policing and have fewer negative side
effects.
Schedulingscheduling decides the order in which to place packets onto the wire based on the class to which they belong or the
queue in which they are waiting. there are multiple queues, all of which may contain packets waiting to be transmitted,
but only a single serial transmission medium is available. the configuration must designate which queue to service first,
for how long, and with what frequency.
Remarkingethernet, mpls, Ipv4, and Ipv6 packets all have a field in the header that can be used to inform another node about a
classification decision made earlier in the path. remarking places a value in the header of an outgoing packet, which
identifies the class to which the packet was assigned by the transmitting router. subsequent nodes can use this
marking to easily and consistently classify the packet using a Ba classifier. It is possible to remark each packet header
type using each marking type (Ieee 802.1p, mpls eXp, Ipv4 precedence, Ipv4 DsCp, or Ipv6 DsCp) that can be used by
Ba classifiers.
Class of Service Used in Design Examplethe network example addresses a primarily unicast environment with little to no multicast. If multicast is present, it is
treated as best effort. If more multicast handling is required, additional queues can be configured to properly manage
that traffic, but it is outside the scope of this document. For more information, see Enabling Class of Service on EX Series Switches in a Campus LAN or Juniper technical documentation.
table 6 shows the Cos settings used in the network example. Depending on the role the device plays in the network,
different features are enabled. For example, on the access devices, traffic is classified and remarked if needed. It is
assumed that remarking has already occurred at the access layer devices, so it is not required on the core devices.
the example uses the Ba classification method, which assumes that traffic is being properly classified by the hosts
or application before entering the switch. this type of deployment is considered a trusted environment. If the network
hosts do not mark traffic, you can configure the access layer to use mF classification instead, which allows for flexible
identification and classification of almost any traffic type.
16 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Table 6: CoS by Device Role
Device Role Classification Congestion Management Scheduling Rate Shaping Remarking
Core Ba - X X X
access Ba - X X X
table 7 lists the queues and forwarding classes used in the network example. traffic is classified by DsCp marking
on the received packets. We have identified several DsCp classifiers and assigned them to queues. additional DsCp
classifiers can be assigned to these queues and is described in the configuration section.
Table 7: CoS Forwarding Classes Used
Forwarding Class Queue # DSCP Buffer Transmit Rate Rate Shaping
control 7NC1/Cs6NC2/Cs7
5% n/a 5%
voice 5 eF 5% n/a 5%
business-app 3 aF21 40% 40% n/a
server-bulk 1 aF11 30% 30% n/a
best-effort 0 n/a remainder remainder n/a
NOTE: eX series switches require a scheduler for every queue used. Queues without a scheduler are not serviced.
eX series switches support eight queues. the tested network example uses five queues. the remaining three queues
can be configured at a later time if additional granularity is needed. It is typically easier to use fewer queues than trying
to define a queue for each application type.
Implementationeach deployment section provides step-by-step processes to set up the network components. each section is
independent. although they can be configured in any order, they are presented in a logical chronology in which each
section builds on the previous one. When deploying a new network, we recommend that you follow the order outlined
here. as you progress through the deployment sections, the diagrams indicate the components being configured. the
“You are here” labels point to where you are in the configuration process.
Wired LAN DeploymentBuilding B: Configuring the Campus Corethe core switch, as shown in Figure 7, connects all networking components together. In this network, it is responsible
for routing all traffic on the intranet, and it is the default gateway for all user networks in Building B, except the Guest
network wireless traffic. Guest access is routed directly to the srX series to maintain clear separation between the
guest and user network traffic. the WlCs, srX series, and network servers and services are also connected directly to
the core.
Copyright © 2013, Juniper Networks, Inc. 17
Implementation Guide – Vertical Campus
WLA
WLA
WLA
WLA
WLA
WLA
WLA
BUILDING A BUILDING B
EX4200VC-2a
EX3300VC-1a
EX4200VC-3a
LAGLAG
LAGEX8200VC-1b
SRX SeriesCluster
WLCCluster
INTERNET
EX6200-1b
App Servers
Centralized DHCPand other services
EX4500VC-1a LAG
LAG
You are Here
Figure 7: Configuring the EX8200VC
For reference, detailed connection information for Building B is provided in Figure 8.
xe-16/0/0
ge-0/0/2
ge-0/0/0
ge-0/0/2
ge-0/0/1ge-0/0/1
SRE1-me0SRE0-me0SRE1-me0 SRE0-me0
ge-0/0/0
Member 1
Member 9Member 8
Master RE
To Building A
Backup RE
Line Card 1(slots 16-31)
Control Link Fabric Link
Member 0Line Card 0(slots 0-15)
xe-18/0/0
EX8200-1b EX8200-2b
SRX650-1b
SRX650-2b
INTERNET
EX6200-1b
WLC2800-1b
XRE200-1b XRE200-2b
WLC2800-2b
xe-18/0/7xe-18/0/6xe-17/0/7xe-17/0/6xe-16/0/7xe-16/0/6
xe-2/0/7xe-2/0/6xe-1/0/7xe-1/0/6xe-0/0/7xe-0/0/6
xe-2/0/0xe-0/0/0
ge-11/0/0 ge-11/0/2
ge-9/0/1
ge-0/0/1
ge-9/0/2
ge-0/0/2
ge-2/0/0 ge-2/0/1
ge-4/0/0
port 8
port 8
xe-1/0/4
xe-1/0/5
xe-17/0/5ge-20/0/0
xe-17/0/4
xe-5/0/0
xe-4/0/0 xe-5/0/1
xe-4/0/1
Figure 8: Building B Connection Details
18 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
EX8200 Virtual Chassis Configurationthe eX8200 Virtual Chassis consists of two eX8200 chassis and two Xres. Because the eX8200 Virtual Chassis has
several components and can be configured in multiple ways, we suggest reading the Best Practice Guidelines for Deploying EX8200 Virtual Chassis Configurations or Appendix B: EX8200 Virtual Chassis Overview for the available
options and features. this guide steps through the required items for configuring the eX8200 in a Full mesh Fabric
mode configuration, as shown in Figure 9.
ge-0/0/2
ge-0/0/0
ge-0/0/2ge-0/0/1ge-0/0/1
SRE1-me0SRE0-me0SRE1-me0 SRE0-me0
ge-0/0/0
xe-18/0/7xe-18/0/6xe-17/0/7xe-17/0/6xe-16/0/7xe-16/0/6
xe-2/0/7xe-2/0/6xe-1/0/7xe-1/0/6xe-0/0/7xe-0/0/6
EX8200-1b EX8200-2b
XRE200-1b XRE200-2b
Figure 9: EX8200 Virtual Chassis Layout
the network example assumes that all eX8200s and Xres are running the default configuration as a starting point.
Procedure overview 1. upgrade all Xre200s and eX8200s to the same version of the Juniper Networks Junos® operating system.
2. Configure global configuration items.
3. Configure the Virtual Chassis.
4. Configure layer 2 settings.
5. Configure layer 3 settings.
6. Configure Cos.
Verifying and Upgrading the Software Version for XRE200the Os version used for the tested network is Junos Os 12.1r1.9, available at www.Juniper.net/support. all Xre200
routing engines must be running the same version.
1. unpack the Xres.
2. Connect to the Xre Console port (setting: s9600, 8, 1, none).
3. press enter. the following prompt appears.
Amnesiac (ttyu0)login
4. log in as root and press enter.
Because no password is configured, you are not prompted for one.
login: rootLogging to master.– – – JUNOS 11.4R1.6 built 2011-11-15 11:14:01 UTCroot@:RE:0%
5. Verify that the Xre is running the correct Os version (12.1r1.9 for this validation). If the version is correct, verify the next
Xre by repeating steps 1–4.
Copyright © 2013, Juniper Networks, Inc. 19
Implementation Guide – Vertical Campus
If an Xre requires an upgrade, the following procedure is a simplified setup that assumes an Ftp server is available to
download the code from directly. If Ftp is not an acceptable method for your environment, you can use a usB drive
(see this document for details).
Connect to the XRE Console port (Setting: s9600, 8, 1, none)press enter. the following prompt appears.
Amnesiac (ttyu0)login
Log in as root and press Enter.Because no password is configured, you are not prompted for one.
login: rootLogging to master.– – – JUNOS 11.4R1.6 built 2011-11-15 11:14:01 UTCroot@:RE:0%
Type cli at the % prompt.
root@:RE:0% cli{master:0}root>
Enter configuration mode by typing configure or edit.
root> configureEntering configuration mode{master:0}[edit]root#
At the # prompt, configure the password.
root# set system root-authentication plain-text-passwordNew password:*******Retype new password:*******{master:0}[edit]root#
Configure the management (me0) interface.
root# set interfaces me0 unit 0 family inet address <IP address/mask>commit and-quit
Connect the me0 interface to the network and upgrade the XREthe following line uploads the code and reboots the system.
root> request system software add ftp://anonymous@<IP_address>/<code_version> reboot
Verify the version after rebooting.
Repeat the process for the remaining devices.
20 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Verifying and Upgrading the Software Version for EX8200the tested network example assumes that each eX8200 has dual routing engines. You must verify, and possibly
upgrade, the software for each routing engine. the Os version used for the tested network is Junos Os 12.1r1.9, available
at www.juniper.net/support. all eX8200 routing engines must be running the same version. perform the following for
routing engine 0 and routing engine 1.
Connect to the Console port of EX8200 routing engine 0 (Setting: s9600, 8, 1, none).press enter. the following prompt appears.
Amnesiac (ttyu0)login
Log in as root and press Enter.Because no password is configured, you are not prompted for one.
login: rootLogging to master.– – – JUNOS 12.1r1.9 built 2011-11-15 11:14:01 UTCroot@:RE:0%root@:RE:0%
Verify that routing engine 0 is running the correct Os version. If the version is correct, verify the routing engine 1 by
repeating steps 1–3.
Type cli at the % prompt.
root@:RE:0% cli{master:0}root>
Enter configuration mode by typing configure or edit.
root> configureEntering configuration mode{master:0}[edit]root#
At the # prompt, configure the password.
root# set system root-authentication plain-text-passwordNew password:*******Retype new password:*******{master:0}[edit]root#
Configure the management (me0) interface.
root# set interfaces me0 unit 0 family inet address <IP address/mask>commit and-quit
Connect the me0 interface to the network and upgrade the XRE the following line uploads the code and reboots the system.
root> request system software add ftp://anonymous@<IP_address>/<code_version> reboot
Verify the version after rebooting.
Repeat the process for the other routing engines.
Copyright © 2013, Juniper Networks, Inc. 21
Implementation Guide – Vertical Campus
Configuring the EX8200 for Virtual ChassisOn the master routing engine of the first EX8200, connect to the console port (Setting: s9600, 8, 1, none).
Log in as root and enable edit mode.
root@ex8200> edit
Enable graceful switchover, nonstop routing, and nonstop bridging.
root# set chassis redundancy graceful-switchoverset system commit synchronizeset routing-options nonstop-routingset ethernet-switching-options nonstop-bridging commit and-quit
Configure resilient dual-boot partitions.this step is highly recommended because it improves the resiliency of the system in case of a primary boot partition
failure. It creates a backup copy of the Os. the process takes approximately 5 minutes for each routing engine or
member.
request system snapshot slice alternate all-members
Configure the EX8200 for Virtual Chassis.
root@ex8200> set chassis virtual-chassis This will reboot the RE(s)Do you want to continue ? [yes, no] yes
Verify that the EX8200 has booted back up in Virtual Chassis mode.after you log in to the eX8200 and type cli, you should see this:
root@:RE:0% cliwarning: This chassis is operating in a non-master role as part of a virtual-chassis (VC) system.warning: Use of interactive commands should be limited to debugging and VC Port operations.warning: Full CLI access is provided by the Virtual Chassis Master (VC-M) chassis.warning: The VC-M can be identified through the show virtual-chassis status command executed at this console.warning: Please logout and log into the VC-M to use CLI.{master:0}
You can also verify the mode using the show virtual-chassis status command.
the following example shows that Virtual Chassis mode is enabled.
{master:0}root> show virtual-chassis status
Virtual Chassis ID: 5ddf.6b28.132fVirtual Chassis Mode: Enabled Mastership Neighbor ListMember ID Status Serial No Model priority Role ID Interface0 (FPC 0-15) Prsnt BT0910434033 ex8208 0 Linecard*
Repeat these steps for the second EX8200 Virtual Chassis.
22 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Preprovisioning the XRE200 for Virtual ChassisIt is important to understand the numbering of Virtual Chassis members before continuing with the configuration. the
member details are shown in Figure 10. the following eX8200 Virtual Chassis numbering is used:
• primary Xre200 is member 8
• Backup Xre200 is member 9
• eX8200 Virtual Chassis are member 0 and member 1.
1. Identify the serial number for each component of the Virtual Chassis (Xre200 and eX8200 chassis serial numbers) and
determine the member ID for each device.
2. log in to the Xre that is used as the master Xre and enable edit mode.
root@ex8200> edit
3. preprovision the chassis. Only preprovisioned eX8200 Virtual Chassis are supported.
4. the Xres are configured as routing engines, and the eX8200s are configured as line cards. Note which member ID each
device is assigned, because you need that information when configuring the chassis later.
root#set virtual-chassis preprovisionedset virtual-chassis member 8 role routing-engineset virtual-chassis member 8 serial-number 042011000023set virtual-chassis member 9 role routing-engineset virtual-chassis member 9 serial-number 042011000036set virtual-chassis member 0 role line-cardset virtual-chassis member 0 serial-number BT0910433933set virtual-chassis member 1 role line-cardset virtual-chassis member 1 serial-number BT0910434033
NOTE: split-detection is enabled by default. However, all devices in the test network are located in the same room and
have many redundant connections, so an accidental chassis split is highly unlikely. But because this is the network core,
we recommend leaving split-detection enabled. If you want to disable split-detection, use the set virtual-chassis no-
split-detection command. If you are not familiar with how split-detection works, review the split-detection section in
appendix a.
ge-0/0/2
ge-0/0/0
ge-0/0/2ge-0/0/1ge-0/0/1
SRE1-me0SRE0-me0SRE1-me0 SRE0-me0
ge-0/0/0
xe-18/0/7xe-18/0/6xe-17/0/7xe-17/0/6xe-16/0/7xe-16/0/6
xe-2/0/7xe-2/0/6xe-1/0/7xe-1/0/6xe-0/0/7xe-0/0/6
Member 1
Member 9Member 8
Master RE Backup RE
Line Card 1(slots 16-31)
Member 0Line Card 0(slots 0-15)
EX8200-1b EX8200-2b
XRE200-1b XRE200-2b12
2
3
3
4
Connect XRE200-1b and XRE200-2b together using ge-0/0/0 interfaces
Connect XRE200-1b ge-0/0/1 to EX8200-1b SRE0 me0, and ge-0/0/2 to EX8200-2b SRE0 me0
Connect XRE200-2b ge-0/0/1 to EX8200-1b SRE1 me0, and ge-0/0/2 to EX8200-2b SRE1 me0
Configure VCP ports on EX8200s and connect together
1
2
3
4
Figure 10: EX8200 Interface Connections
Copyright © 2013, Juniper Networks, Inc. 23
Implementation Guide – Vertical Campus
Assembling the EX8200 Virtual Chassis Now that all the components are ready to be connected, we can start assembling the Virtual Chassis.
1. Connect the two Xre200s using ge-0/0/0 on each Xre200.
2. Verify that the Xres have identified each other properly:
root> show virtual-chassis
Preprovisioned Virtual ChassisVirtual Chassis ID: 1716.387c.f292Virtual Chassis Mode: Enabled Mastership Neighbor ListMember ID Status Serial No Model priority Role ID Interface0 (FPC 0-15) NotPrsnt BT0910433933 ex82081 (FPC 16-31) NotPrsnt BT0910434033 ex82088 (FPC 128-143) Prsnt 042011000023 ex-xre 129 Master* 9 vcp-0/09 (FPC 144-159) Prsnt 042011000036 ex-xre 129 Backup 8 vcp-0/0
3. Connect Xre200-1b ge-0/0/1 to the management port of eX8200VC-1b master routing engine 0. Connect Xre200-1b
ge-0/0/2 to the management port of eX8200VC-2b master routing engine 0.
4. Connect Xre200-2b ge-0/0/1 to the management port of eX8200VC-2b backup routing engine 1. Connect Xre200-2b
ge-0/0/2 to the management port of eX8200VC-2b backup routing engine 1.
5. Verify that the eX8200s have been identified properly and joined the Virtual Chassis:
{master:8}root> show virtual-chassis
Preprovisioned Virtual ChassisVirtual Chassis ID: 1716.387c.f292Virtual Chassis Mode: Enabled Mastership Neighbor ListMember ID Status Serial No Model priority Role ID Interface0 (FPC 0-15) Prsnt BT0910433933 ex8208 0 Linecard 8 vcp-0/0 9 vcp-0/11 (FPC 16-31) Prsnt BT0910434033 ex8208 0 Linecard 8 vcp-0/0 9 vcp-0/18 (FPC 128-143) Prsnt 042011000023 ex-xre 129 Master* 9 vcp-0/0 0 vcp-1/0 1 vcp-1/19 (FPC 144-159) Prsnt 042011000036 ex-xre 129 Backup 8 vcp-0/0 0 vcp-1/0 1 vcp-1/1
24 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Configuring Virtual Chassis Ports on the EX8200Only line-rate 10Gbe ports on the eX8200-8Xs line card support VCps. the 10Gbe network ports are converted to
VCps in pairs. For example, interfaces xe-0/0/0 and xe-0/0/1 are both converted to VCps, even though the ClI request
is to convert only one of them. VCps for both eX8200 Virtual Chassis members are configured from the master
Xre200 operational mode.
these are operational commands and are not entered in edit mode. these commands do not appear in the
configuration of the device. the port configurations are specific to each eX8200 chassis and do not reflect the Virtual
Chassis port numbering. For example, eX8200-2b, as part of a Virtual Chassis, uses slots 16–31 when configuring
ports in normal operation. However, because VCps are special, they are configured as their native port designations. to
configure port xe-0/0/6 as a VCp on eX8200-2b, type the following command:
request virtual-chassis vc-port set fpc-slot 0 pic-slot 0 port 6 member 1
We use six ports: xe-0/0/6, xe- 0/0/7, xe-1/0/6, xe-1/0/7, xe-2/0/6, and xe-2/0/7. You only need to configure the first
port in each pair.
Configure the VCPs for EX8200-1b.
root>request virtual-chassis vc-port set fpc-slot 0 pic-slot 0 port 6 member 0member0:--------------------------------------------------------------------------This will also convert FPC slot 0 PIC slot 0 Port 7 to virtual chassis port.
root> request virtual-chassis vc-port set fpc-slot 1 pic-slot 0 port 6 member 0member0:--------------------------------------------------------------------------This will also convert FPC slot 1 PIC slot 0 Port 7 to virtual chassis port.root> request virtual-chassis vc-port set fpc-slot 2 pic-slot 0 port 6 member 0member0:--------------------------------------------------------------------------This will also convert FPC slot 2 PIC slot 0 Port 7 to virtual chassis port.
Configure the VCPs for EX8200-2b.
root> request virtual-chassis vc-port set fpc-slot 2 pic-slot 0 port 6 member 1member1:--------------------------------------------------------------------------This will also convert FPC slot 2 PIC slot 0 Port 7 to virtual chassis port.root>
request virtual-chassis vc-port set fpc-slot 0 pic-slot 0 port 6 member 1member0:--------------------------------------------------------------------------This will also convert FPC slot 0 PIC slot 0 Port 7 to virtual chassis port.
root> request virtual-chassis vc-port set fpc-slot 1 pic-slot 0 port 6 member 1member0:--------------------------------------------------------------------------This will also convert FPC slot 1 PIC slot 0 Port 7 to virtual chassis port.
Copyright © 2013, Juniper Networks, Inc. 25
Implementation Guide – Vertical Campus
Connect all six ports together to create a highly resilient LAG connection between the EX8200 chassis, which will be spread across three separate cards in each chassis .
Connect the EX8200s together using the six ports.Verify that the VCps on the eX8200s came up correctly.
{master:8}root> show virtual-chassis vc-portmember0:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfaceSlot/PIC/Portvcp-0/0 Dedicated -1 Up 1000 8 vcp-1/0vcp-0/1 Dedicated -1 Up 1000 9 vcp-1/00/0/6 Configured 3 Up 10000 1 vcp-0/0/60/0/7 Configured 3 Up 10000 1 vcp-0/0/71/0/6 Configured 3 Up 10000 1 vcp-1/0/61/0/7 Configured 3 Up 10000 1 vcp-1/0/72/0/6 Configured 3 Up 10000 1 vcp-2/0/62/0/7 Configured 3 Up 10000 1 vcp-2/0/7
member1:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfaceSlot/PIC/Portvcp-0/0 Dedicated -1 Up 1000 8 vcp-1/1vcp-0/1 Dedicated -1 Up 1000 9 vcp-1/10/0/6 Configured 3 Up 10000 0 vcp-0/0/60/0/7 Configured 3 Up 10000 0 vcp-0/0/71/0/6 Configured 3 Up 10000 0 vcp-1/0/61/0/7 Configured 3 Up 10000 0 vcp-1/0/72/0/6 Configured 3 Up 10000 0 vcp-2/0/62/0/7 Configured 3 Up 10000 0 vcp-2/0/7
NOTE: Only the eX8200 is shown for brevity.
Configure graceful switchover and nonstop routing.
root# set chassis redundancy graceful-switchoverset system commit synchronizeset routing-options nonstop-routingset ethernet-switching-options nonstop-bridgingcommit and-quit
use the following commands to view the status of the Virtual Chassis:
show virtual-chassis
show virtual-chassis vc-port
this completes the setup of the basic eX8200 Virtual Chassis. Now it’s time to configure it.
26 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Configuring Global Settings for the Core EX8200 Virtual Chassis SwitchConnect to the Console port of the Master XRE200 and login (Setting: s9600, 8, 1, none). Note the version of Junos at the prompt and update as needed.
login: rootLogging to master.– – – JUNOS 12.1r1.9 built 2011-11-15 11:14:01 UTCroot@:RE:0%
Type cli at the % prompt.
root@:RE:0% cli{master:0}root>
You should now be at the >prompt.
Configure the date and time in the format: YYYYMMDDhhmm.ss.
set date 201210220830.00
Enter configuration mode by typing configure or edit.
root> configureEntering configuration mode{master:0}[edit]root#
You should now be at the # prompt and ready to start configuring the switch.
Configure the time zone.
root# set system time-zone America/Los_Angeles
Configure the hostname.
root# set system host-name EX8200VC-1b
Configure the management interfaces on the XREs.
EX8200VC-1b#set groups member8 interfaces me0 unit 0 family inet address <IP address/mask>set groups member9 interfaces me0 unit 0 family inet address <IP address/mask>set apply-groups member8set apply-groups member9
Configure management access.
root@EX8200VC-1b# set system services web-management https system-generated-certificateset system services sshdelete system services web-management httpdelete system services telnet
Configure DNS.
root@EX8200VC-1b# set system name-server 10.10.46.100set system domain-name xyzcompany.com
Copyright © 2013, Juniper Networks, Inc. 27
Implementation Guide – Vertical Campus
Configure NTP.
set system ntp server 10.10.46.100
Configuring Layer 2 Settings on EX8200 Virtual Chassis Core Switchto configure layer 2 parameters and settings on the core switch:
Set the bridge priority on the core switch.NOTE: spanning tree protocol is enabled to prevent loops from forming in the network, even though we do not use it as
a topology protocol. as an extra precaution, we set the bridge priority on the core switch to 8192, which ensures that it
is the default root bridge in the event another bridging device is connected to the network. Juniper Networks eX series
switches run rstp by default.
root@EX8200VC-1b# set protocols rstp bridge-priority 8k
commit
Configure VLANs and IP interfaces.NOTE: We configure all of the inter-VlaN routing on the core switch, except for our guest VlaN. this makes it easier to
simultaneously configure the VlaNs and Ip interfaces for those VlaNs. When creating VlaN names, it is important to
note that these names are case sensitive.
In our examples you may notice that the VlaN ID is the same as the interface VlaN unit number. this is not mandatory,
but we recommend that you match the VlaN ID and interface VlaN unit number. this helps to make things easier to
understand later when you have many VlaNs and interfaces to track.
NOTE: When you issue a large number of commands at once, it is recommended that you issue a commit command to
verify that the commands take effect with no configuration errors. alternatively, a commit check can be issued instead,
which verifies the configuration without making it active.
the complete set of VlaN and layer 3 interface statements for the core switch in the tested network example follows.
We also add the guest VlaN here, but we do not assign any layer 3 interfaces to this VlaN, because routing for the
VlaN are done using the srX series firewall.
VLAN Configurations
root@EX8200VC-1b# set vlans access_points_1b vlan-id 52set vlans data_wired_1b vlan-id 8set vlans data_wireless_1b vlan-id 32set vlans guest_wireless vlan-id 60set vlans internet_edge vlan-id 44set vlans management_1b vlan-id 50set vlans server_1b vlan-id 46set vlans server_2b vlan-id 48set vlans voip_wired_1b vlan-id 20set vlans voip_wireless_1b vlan-id 40
VLAN Interface Configuration
root@EX8200VC-1b# set vlans access_points_1b l3-interface vlan.52set vlans data_wired_1b l3-interface vlan.8set vlans internet_edge l3-interface vlan.44set vlans management_1b l3-interface vlan.50set vlans server_1b l3-interface vlan.46set vlans server_2b l3-interface vlan.48set vlans voip_wired_1b l3-interface vlan.20set vlans data_wireless_1b l3-interface vlan.32set vlans voip_wireless_1b l3-interface vlan.40
28 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
IP interface configuration.
root@EX8200VC-1b# set interfaces vlan unit 8 family inet address 10.10.8.1/22set interfaces vlan unit 20 family inet address 10.10.20.1/22set interfaces vlan unit 32 family inet address 10.10.32.1/22set interfaces vlan unit 40 family inet address 10.10.40.1/23set interfaces vlan unit 44 family inet address 10.10.44.1/24set interfaces vlan unit 46 family inet address 10.10.46.1/24set interfaces vlan unit 48 family inet address 10.10.48.1/24set interfaces vlan unit 50 family inet address 10.10.50.1/24set interfaces vlan unit 52 family inet address 10.10.52.1/24
the interface configuration for laG ae1 which connects to eX4500VC-1a is layer 3 interface and communicates routing
information using the OspF protocol. We will configure the laG for this in the next section.
root@EX8200VC-1b# set interfaces ae1 unit 0 family inet address 10.10.200.1/24commit
Configure LAG (aggregated Ethernet) portsIn the tested network configuration, the laG ports configured will be used to connect to the eX6200 series access
switches and for the inter-building connection to the eX4500VC-1a core chassis for building a.
Junos Os requires that you configure the number of laG interfaces you want to use before you begin configuring
the interfaces. We suggest picking a number slightly larger than you might need, in case you need to add more laG
interfaces later. You can change this value in the future. We need two aggregated ethernet ports for the tested network
example, but most deployments would have more than a single eX6200 so we will configure the core chassis with
eight, allowing us to add additional devices later without having to adjust this.
root@EX8200VC-1b#set chassis aggregated-devices ethernet device-count 8
to provide the highest level of resilience, you want to configure the laG to span multiple eX8200 slots and chassis.
NOTE: If the interfaces we want to use are currently configured, that configuration will need to be removed before they
can be enabled as laG the eX8200 chassis has no port configuration by default, so we can skip this step and move
directly to configuring the ports.
Configure the interfaces to be part of the respective aggregated interfaces.
root@EX8200VC-1b# set interfaces xe-0/0/0 ether-options 802.3ad ae1set interfaces xe-2/0/0 ether-options 802.3ad ae1set interfaces xe-16/0/0 ether-options 802.3ad ae1set interfaces xe-18/0/0 ether-options 802.3ad ae1set interfaces xe-1/0/4 ether-options 802.3ad ae0set interfaces xe-1/0/5 ether-options 802.3ad ae0set interfaces xe-17/0/4 ether-options 802.3ad ae0set interfaces xe-17/0/5 ether-options 802.3ad ae0
Next we want to add LACP to each LAG interface to provide some health checking.
NOTE: You need to configure laCp on the interfaces at both ends for the laG port to become active.
root@EX8200VC-1b# set interfaces ae0 aggregated-ether-options lacp activeset interfaces ae0 aggregated-ether-options lacp periodic slowset interfaces ae1 aggregated-ether-options lacp activeset interfaces ae1 aggregated-ether-options lacp periodic slow
Copyright © 2013, Juniper Networks, Inc. 29
Implementation Guide – Vertical Campus
Disable RSTP on LAG connections to access switches.
Because we are not using stp, we can disable it on the laG ports going to our access switches. this also reduces
potential convergence times in case a laG member fails, because fewer protocols need to converge.
NOTE: all access switches have rstp enabled locally to prevent looping.
root@EX8200VC-1b# set protocols rstp interface ae0.0 disable
commit
Configure trunk, access and VLAN settings for LAGs.We need to configure the laG ports as trunks and add the VlaNs that will be supported on the individual access
switches. after setting the trunks, commit the configuration.
root@EX8200VC-1b# set interfaces ae0 unit 0 family ethernet-switching port-mode trunk
commit
Configure VLANs on the trunk ports.You can configure port-to-VlaN mapping in two different ways:
• You can configure the VlaNs directly as part of the port configuration.
• You can configure the ports included in the VlaN under the VlaN configuration.
each of these has different advantages and disadvantages. Generally, it makes sense to configure access ports (client-
facing) under the VlaN configuration and configure VlaNs directly on the port for trunk port configuration. You cannot
configure the VlaN mapping in both places, because that might result in errors when doing a configuration commit
operation.
as discussed, it is recommended to configure the VlaNs that the trunk port will carry directly on the interface
configuration section. this simplifies identifying what VlaNs a specific trunk is part of when viewing the configuration.
When adding VlaNs directly to a trunk port you have the option of adding them by their VlaN ID or by the VlaN name.
In this example, we will add them by VlaN name; this makes the overall configuration more readable.
to add several VlaNs to a trunk, you can either specify them one at a time or you can specify several VlaNs at the
same time by enclosing them in [] brackets and separating them with spaces.
The VLAN configuration for ae0 connecting to EX6200-1b
root@EX8200VC-1b# set interfaces ae0 unit 0 family ethernet-switching vlan members [ data_wired_1b voip_wired_1b data_wireless_1b voip_wireless_1b access_points_1b management ]
or you can enter it one line at a time
set interfaces ae0 unit 0 family ethernet-switching vlan members data_wired_1bset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wired_1bset interfaces ae0 unit 0 family ethernet-switching vlan members data_wireless_1bset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wireless_1bset interfaces ae0 unit 0 family ethernet-switching vlan members access_points_1bset interfaces ae0 unit 0 family ethernet-switching vlan members management_1b
Configure dual-homed or other network device connections.Configuring connections for other devices that are dual homed (but do not use laG connections or other network
equipment) typically involves connections to the core and trunk ports. In the tested network, the srX series and
wireless laN controllers both use clustering technologies to provide High availability, In this case they are not
configured with laG connections to the core. each of these devices requires two identical port configurations on
separate eX series switches to provide link-level and box-level redundancy.
30 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Configure Wireless LAN controllers.Connect wireless laN controllers (WlCs) to ports ge-4/0/0 and ge-20/0/0 and add them to the following VlaNs:
management, and guest_wireless.
root@EX8200VC-1b# set interfaces ge-4/0/0 unit 0 family ethernet-switching port-mode trunkset interfaces ge-4/0/0 unit 0 family ethernet-switching vlan members management_1bset interfaces ge-4/0/0 unit 0 family ethernet-switching vlan members guest_wirelessset interfaces ge-20/0/0 unit 0 family ethernet-switching port-mode trunkset interfaces ge-20/0/0 unit 0 family ethernet-switching vlan members management_1bset interfaces ge-20/0/0 unit 0 family ethernet-switching vlan members guest_wireless
Configure SRX Firewalls.Connect the srX firewalls to ports ge-2/0/47 and ge-3/0/47 and make them part of the following VlaNs: Internet_
edge, management, Guest_Wired and Guest_Wireless.
root@EX8200VC-1b# set interfaces ge-4/0/1 unit 0 family ethernet-switching port-mode trunkset interfaces ge-4/0/1 unit 0 family ethernet-switching vlan members internet_edgeset interfaces ge-4/0/1 unit 0 family ethernet-switching vlan members management_1bset interfaces ge-4/0/1 unit 0 family ethernet-switching vlan members guest_wireless
set interfaces ge-20/0/1 unit 0 family ethernet-switching port-mode trunkset interfaces ge-20/0/1 unit 0 family ethernet-switching vlan members internet_edgeset interfaces ge-20/0/1 unit 0 family ethernet-switching vlan members management_1bset interfaces ge-20/0/1 unit 0 family ethernet-switching vlan members guest_wireless
Commit the configuration.
commit
Configure the server port.
server ports are typically configured as access ports that have a single VlaN. In the tested network example, we have a
few VlaNs where servers would typically reside. to configure a server port that is part of a single VlaN, it must first be
configured as an access port.
Set port into access mode:
root@EX8200VC-1b# set interfaces ge-4/0/44 unit 0 family ethernet-switching port-mode access
assign the port to a VlaN. as a general rule, we assign access ports under the VlaN configuration instead of the port
configuration, but either can be used. In this case we need to assign the server port to the VlaN servers.
root@EX8200VC-1b# set vlans server_1b interface ge-4/0/44
In some cases it may make more sense to assign the VlaN directly in the port configuration because servers are
different from a standard network host.
Configure server port in trunk mode.some servers reside on more than one VlaN and require a trunk port. In this case, configure the port for trunking and
assign the VlaNs it should belong to directly in the port configuration as we did for the laG ports. Below is an example
of an interface configured as a trunk that belongs to the VlaNs server_1b and management_1b. You can also review the
earlier trunk configuration sections discussing configuration of ports for WlC and srX devices.
root@ EX8200VC-1b# set interfaces <interface> unit 0 family ethernet-switching port-mode trunkset interfaces <interface> unit 0 family ethernet-switching vlan members [servers_1b management_1b]
Copyright © 2013, Juniper Networks, Inc. 31
Implementation Guide – Vertical Campus
Enable BPDU-block for server interfaces.Because we do not expect to connect any bridges to the network, the bpdu-block command protects the network
should anyone connect a bridge to the core switch that may shut down any ports sending BpDus. this command
maintains network stability if someone connects an unauthorized bridge to the network.
root@EX8200VC-1b# set ethernet-switching-options bpdu-block interface <interface name>
If interfaces become blocked, you need to clear them manually. the following commands can be used to clear a
blocked port condition:
root@EX8200VC-1b> clear ethernet-switching bpdu-errorroot@EX8200VC-1b> clear ethernet-switching port-error
to view the current state of interfaces run the following command:
root@ EX8200VC-1b> show ethernet-switching interfaces
32 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Configuring Layer 3 Settings for the EX8200 Virtual Chassis Core Switchto configure layer 3 parameters on the core switch:
Configure DHCPthe tested network example uses DHCp forwarding and a central DHCp server for all Ip address allocation , with the
exception of the guest wireless VlaN. Guest wireless addressing is allocated directly from the srX series Gateways to
maintain isolation from the rest of the network.
DHCp services can be set up directly on eX series switches if desired (see appendix C). DHCp forwarding is essentially
a broadcast forwarding system for DHCp requests that allows users to consolidate their DHCp services in a centralized
location instead of having a DHCp server for every subnet. the following configuration enables DHCp forwarding on the
VlaN interfaces listed, and forwards DHCp requests to the DHCp server 10.10.46.100.
root@EX8200-1b# set forwarding-options helpers bootp description DHCP-SERVER-Aset forwarding-options helpers bootp server 10.10.46.100set forwarding-options helpers bootp interface vlan.8set forwarding-options helpers bootp interface vlan.20set forwarding-options helpers bootp interface vlan.32set forwarding-options helpers bootp interface vlan.40set forwarding-options helpers bootp interface vlan.52
Configure default gateway and static routes.
root@EX8200-1b# set routing-options static route 0.0.0.0/0 next-hop 10.10.44.254
Configure OSPF.We need to configure a single OspF area that will be the backbone area 0.0.0.0 and add the interfaces and subnets we
wish to advertise to the srX series Gateways and eX4500VC-1a core in building a.
NOTE: the subnet is all that is required to add the interface to the area. mask information will be automatically
imported into OspF and redistributed. We have configured several interfaces as passive OspF interfaces. this means
their subnets will be advertised to other OspF routers, but we will not send OspF advertisements on these interfaces.
root@EX8200VC-1b# set protocols ospf area 0.0.0.0 interface vlan.48 passiveset protocols ospf area 0.0.0.0 interface vlan.8 passiveset protocols ospf area 0.0.0.0 interface vlan.20 passiveset protocols ospf area 0.0.0.0 interface vlan.32 passiveset protocols ospf area 0.0.0.0 interface vlan.40 passiveset protocols ospf area 0.0.0.0 interface vlan.50 passiveset protocols ospf area 0.0.0.0 interface vlan.64 passiveset protocols ospf area 0.0.0.0 interface ae1.0set protocols ospf area 0.0.0.0 interface vlan.44set protocols ospf area 0.0.0.0 interface vlan.52 passiveset protocols ospf area 0.0.0.0 interface vlan.46 passive
Commit the configuration.
commit
Copyright © 2013, Juniper Networks, Inc. 33
Implementation Guide – Vertical Campus
Configure Class of Servicethe basic Cos configuration is almost identical across core and access platforms in the network example. We will
configure Cos on the core eX8200 Virtual Chassis. the configuration defines the Cos service and then applies it to
specific interfaces.
Configuring forwarding classesFirst we will configure the forwarding classes; this step also defines what queues are used as well.
root@EX8200VC-1b# set class-of-service forwarding-classes class control queue-num 7set class-of-service forwarding-classes class voice queue-num 5set class-of-service forwarding-classes class business-app queue-num 3set class-of-service forwarding-classes class server-bulk queue-num 1set class-of-service forwarding-classes class best-effort queue-num 0
Configuring classifiersNext we will create the classifiers. In the tested network example we are only using DsCp marking for our classification
of traffic. the classifiers map the different DsCp marked packets to the correct queue – if the traffic is not marked or
marked with a DsCp value it will be considered best-effort traffic and treated accordingly.
root@EX8200VC-1b# set class-of-service classifiers dscp dscp_trusted forwarding-class control loss-priority low code-points nc1set class-of-service classifiers dscp dscp_trusted forwarding-class control loss-priority low code-points nc2set class-of-service classifiers dscp dscp_trusted forwarding-class voice loss-priority low code-points efset class-of-service classifiers dscp dscp_trusted forwarding-class business-app loss-priority low code-points af21set class-of-service classifiers dscp dscp_trusted forwarding-class server-bulk loss-priority low code-points af11set class-of-service classifiers dscp dscp_trusted forwarding-class best-effort loss-priority low code-points be
Configuring schedulersWe will create schedulers for each type of traffic we want to manage. When we define the schedulers we also configure
characteristics like shaping/limiting/forwarding rate, how much buffer is allocated, and what priority the traffic has.
In the tested network we have configured some similar sounding schedulers, for example: voice-user-sched and
voice-network-sched. the difference between these schedulers is they are intended to be applied to different types of
interfaces when we create our scheduler maps later. While these currently have the same values, you may later need
to change the characteristics of your network or access ports to be different from each other. Configuring schedulers in
this manner for the initial configuration makes for less work if changes are needed later.
root@EX8200VC-1b# set class-of-service schedulers control-network-sched shaping-rate percent 5set class-of-service schedulers control-network-sched buffer-size percent 5set class-of-service schedulers control-network-sched priority strict-highset class-of-service schedulers control-user-sched shaping-rate percent 5 set class-of-service schedulers control-user-sched buffer-size percent 5set class-of-service schedulers control-user-sched priority strict-highset class-of-service schedulers voice-network-sched shaping-rate percent 5 set class-of-service schedulers voice-network-sched buffer-size percent 5 set class-of-service schedulers voice-network-sched priority strict-highset class-of-service schedulers voice-user-sched shaping-rate percent 5 set class-of-service schedulers voice-user-sched buffer-size percent 5 set class-of-service schedulers voice-user-sched priority strict-high set class-of-service schedulers business-sched transmit-rate percent 60 set class-of-service schedulers business-sched buffer-size percent 60set class-of-service schedulers business-sched priority low set class-of-service schedulers server-sched transmit-rate percent 30 set class-of-service schedulers server-sched buffer-size percent 30set class-of-service schedulers server-sched priority lowset class-of-service schedulers be-sched transmit-rate remainder set class-of-service schedulers be-sched buffer-size remainderset class-of-service schedulers be-sched priority low
34 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Configuring scheduler map.scheduler maps tie the individual schedulers to forwarding classes and queues. Here we have created two scheduler
maps one for network (switch to switch) ports and one for access or host ports. the difference between the two is the
different names for the individual control and voice schedulers used in each scheduler-map.
root@EX8200VC-1b# set class-of-service scheduler-maps network-port-sched forwarding-class control scheduler control-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class voice scheduler voice-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps network-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps network-port-sched forwarding-class best-effort scheduler be-schedset class-of-service scheduler-maps access-port-sched forwarding-class control scheduler control-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class voice scheduler voice-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps access-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps access-port-sched forwarding-class best-effort scheduler be-sched
Configuring rewrite rules.rewrite rules are used to mark packets appropriately before packets exit an interface to preserve markings
throughout the network.
set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority low code-point nc1set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority high code-point nc2set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class voice loss-priority low code-point efset class-of-service rewrite-rules dscp rewrite-dscp forwarding-class business-app loss-priority low code-point af21set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class best-effort loss-priority low code-point be
Configuring interfaces.In order for Class of service to actually do anything it must be applied to interfaces. We have two main interface types:
Network ports (that connect switches together), and user ports (that users/hosts connect to.) When applying Class of
service to an interface in the tested network example you will configure a scheduler and classifier on network ports, or
a scheduler, classifier and rewrite policy on access ports. users do not connect directly to core switches, but servers do.
We can use the same access port scheduler for the servers on the core switch. this could be re-named or modified to
make it more appropriate for the individual environment.
Wildcards can be used to apply Class of service to multiple interfaces with a single command. For example: here we
use wildcards to configure all the Gbe ports on slot 4 to use the same Class of service settings. this can be done the
same way with our laG connections, but we have relatively few of these to configure so we will do so individually.
NOTE: the most specific commands win, so if you have a wildcard policy that is applied to all gigabit ethernet ports
and then you configure one of those ports specifically with different class of service settings they should not conflict;
instead the more specific port configuration will take precedence.
Copyright © 2013, Juniper Networks, Inc. 35
Implementation Guide – Vertical Campus
root@EX8200VC-1b# set class-of-service interfaces ge-4/0/* scheduler-map access-port-schedset class-of-service interfaces ge-4/0/* unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ge-4/0/* unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae0 scheduler-map network-port-schedset class-of-service interfaces ae0 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae0 unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae1 scheduler-map network-port-schedset class-of-service interfaces ae1 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae1 unit 0 rewrite-rules dscp rewrite-dscp
Commit the configuration.
commit
Verifying Class of Service Settingsthere are various commands that can be used to verify portions of the Class of service configuration.
Show class-of-service <sub-category>
examples:
show class-of-service scheduler-map
show class-of-service interface <interface name>
show class-of-service rewrite-rule
the most useful Class of service command might be looking at the interface statistics using the command.
show interfaces <interface name> detail
this command will provide details on what queues are configured on the port and how many packets were seen and if
any were dropped.
NOTE: When looking for Class of service statistics using the show interface command you can only see the statistics
on physical interfaces so when looking at a laG interface you need to run this command for each of the physical
interfaces that make up the link in order to view the Class of service details.
36 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
root@EX8200VC-1b> show interfaces xe-1/0/4Physical interface: xe-1/0/4, Enabled, Physical link is Up Interface index: 162, SNMP ifIndex: 530 Link-level type: Ethernet, MTU: 1514, Speed: 10Gbps, Duplex: Full-Duplex, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x4000 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Current address: 2a:c0:da:ba:90:03, Hardware address: 28:c0:da:ba:90:37 Last flapped : 2012-10-22 10:52:25 PDT (2w3d 22:10 ago) Input rate : 0 bps (0 pps) Output rate : 2880 bps (0 pps) Active alarms : None Active defects : None Interface transmit statistics: Disabled
Logical interface xe-1/0/4.0 (Index 79) (SNMP ifIndex 533) Flags: 0x4000 Encapsulation: ENET2 Protocol aenet, AE bundle: ae0.0
{master:8}root@EX8200VC-1b> show interfaces xe-1/0/4 detailPhysical interface: xe-1/0/4, Enabled, Physical link is Up Interface index: 162, SNMP ifIndex: 530, Generation: 165 Link-level type: Ethernet, MTU: 1514, Speed: 10Gbps, Duplex: Full-Duplex, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x4000 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Hold-times : Up 0 ms, Down 0 ms Current address: 2a:c0:da:ba:90:03, Hardware address: 28:c0:da:ba:90:37 Last flapped : 2012-10-22 10:52:25 PDT (2w3d 22:10 ago) Statistics last cleared: 2012-11-08 08:54:00 PST (23:08:50 ago) Traffic statistics: Input bytes : 1321996 0 bps Output bytes : 3688005 0 bps Input packets: 6065 0 pps Output packets: 29479 0 pps IPv6 transit statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0
Copyright © 2013, Juniper Networks, Inc. 37
Implementation Guide – Vertical Campus
Egress queues: 8 supported, 8 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 22862 0 1 server-bulk 0 0 0 2 mcast-be 0 0 0 3 business-app 0 0 0 4 mcast-ef 0 0 0 5 voice 0 0 0 6 mcast-af 0 0 0 7 control 0 5783 0 Queue number: Mapped forwarding classes 0 best-effort 1 server-bulk 2 mcast-be 3 business-app 4 mcast-ef 5 voice 6 mcast-af 7 control Active alarms : None Active defects : None Interface transmit statistics: Disabled
Logical interface xe-1/0/4.0 (Index 79) (SNMP ifIndex 533) (HW Token 2147483649) (Generation 144) Flags: 0x4000 Encapsulation: ENET2 Local statistics: Input bytes : 936000 Output bytes : 1139271 Input packets: 3000 Output packets: 3808 Transit statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps Protocol aenet, AE bundle: ae0.0, Generation: 164, Route table: 0
38 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Building B: Configuring the Access Layer
WLA
WLA
WLA
WLA
WLA
WLA
WLA
BUILDING A BUILDING B
EX4200VC-2a
EX3300VC-1a
EX4200VC-3a
LAGLAG
LAGEX8200VC-1b
SRX SeriesCluster
WLCCluster
INTERNET
EX6200-1b
App Servers
Centralized DHCPand other services
EX4500VC-1a LAG
LAG
You are Here
Figure 11: EX6200 Configuration
In Building B the access layer uses eX6210 series modular switches. the eX6210 provides high density ethernet
switching with redundant routing-engines and power supplies for high availability. In the tested network we only show
a single eX6210, but in an actual deployment this will likely be a larger number.
NOTE: this process assumes that the eX6200 has redundant routing-engines and both are running the same version.
Copyright © 2013, Juniper Networks, Inc. 39
Implementation Guide – Vertical Campus
Software Version /Upgrading the EX6200NOTE: In the tested network example it is assumed that each eX6200 has dual routing-engines, each of the two
routing engines in each eX6200 need have their software version checked and upgraded to the tested version (Junos
12.1r1.9.) the process outlined here steps through the upgrade process for both routing-engines.
NOTE: if the eX6200 code version is already upgraded to Junos 12.1r1.9 you can skip steps 1-8 and start at the “eX6200
Configuration Overview” section.
Routing-engine 0 Connect to the Console port of the EX6200 routing-engine 0 (Setting: s9600, 8, 1, none).press enter. the following prompt appears.
Amnesiac (ttyu0)login
Log in as root and press Enter.Because no password is configured, you are not prompted for one.
login: rootLogging to master.– – – JUNOS 11.4R1.6 built 2011-11-15 11:14:01 UTCroot@:RE:0%
Note version of code, if the routing-engine 0 is running the correct version then check routing-engine 1
Type cli at the % prompt.
root@:RE:0% cli{master:0}root>
Enter configuration mode by typing configure or edit.
root> configureEntering configuration mode{master:0}[edit]root#
You should now be at the # prompt and ready to start configuring the switch.
Configure the password.
root# set system root-authentication plain-text-passwordNew password:*******Retype new password:*******{master:0}[edit]root#
Configure the management (me0) interface.
root# set interfaces me0 unit 0 family inet address <IP address/mask>commit and-quit
Connect the me0 interface to the network and upgrade the XRE. the following line will Ftp the code to the system and then reboot it running the new code.
root> request system software add ftp://anonymous@<IP_address>/<code_version> reboot
Verify the correct version boots up.
40 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Routing-engine 1Connect to the Console port of the EX6200 routing-engine 1 (Setting: s9600, 8, 1, none).press enter. the following prompt appears.
Amnesiac (ttyu0)login
Log in as root and press Enter.Because no password is configured, you are not prompted for one.
login: rootLogging to master.– – – JUNOS 11.4R1.6 built 2011-11-15 11:14:01 UTCroot@:RE:0%
Note version of code, if the routing-engine is running the correct version then check the next routing-engine
Type cli at the % prompt.
root@:RE:0% cli{master:0}root>
Enter configuration mode by typing configure or edit.
root> configureEntering configuration mode{master:0}[edit]root#
You should now be at the # prompt and ready to start configuring the switch.
the eX6210 does not require redundant routing-engines to operate, but some configuration items related to
redundancy in our example will fail if there is no second routing-engine installed.
Copyright © 2013, Juniper Networks, Inc. 41
Implementation Guide – Vertical Campus
EX6200 Configuration Overview 1. Configure global configuration items
2. Configure the Chassis
• perform Chassis type-specific configuration
3. Configure layer 2 settings
4. Configure layer 3 settings
5. Configure Class of service
Configuring Global Settings for the EX6210 Switchto configure global settings on the switch:
Connect to the Console port of the EX6210 route-engine 0 (Setting: s9600, 8, 1, none).press enter. the following prompt appears.
Amnesiac (ttyu0)login
Log in as root and press Enter.Because no password is configured, you are not prompted for one.
login: rootLogging to master.– – – JUNOS 12.1r1.9 built 2011-11-15 11:14:01 UTCroot@:RE:0%
Type cli at the % prompt.
root@:RE:0% cli{master:0}root>
You should now be at the >prompt.
Configure the date and time in the format: YYYYMMDDhhmm.ss.
set date 201210220830.00
Enter configuration mode by typing configure or edit.
root> configureEntering configuration mode{master:0}[edit]root#
You should now be at the # prompt and ready to start configuring the switch.
Configure the password.
root# set system root-authentication plain-text-passwordNew password:*******Retype new password:*******{master:0}[edit]root#
42 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Configure the time zone.
root# set system time-zone America/Los_Angeles
Configure the hostname.
root# set system host-name EX6200-1b
Configure the management and VME interface (optional).
root@EX6200-1b# set interfaces vme unit 0 family inet address <IP address/mask>
Configure management access.
root@EX6200-1b# set system services web-management https system-generated-certificateset system services sshdelete system services web-management httpdelete system services telnet
Configure DNS.
root@EX6200-1b# set system name-server 10.10.46.100set system domain-name xyzcompany.com
Configure NTP.
root@EX6200-1b#set system ntp server 10.10.46.100
Configuring the EX6200 ChassisConfigure global Virtual Chassis commands.
root@EX6200-1b# set system commit synchronizeset ethernet-switching-options nonstop-bridgingset chassis redundancy graceful-switchover
Commit the configuration.
root@EX6200-1b# commit
Configure resilient dual-boot partitions.NOTE: It is important to run this step as it improves the resiliency of the system in the case of primary boot partition
failure. this step creates a backup copy of the operating system and is highly recommended. this process takes
approximately 5 minutes for each re or member.
request system snapshot slice alternate re0request system snapshot slice alternate re1
Configure default settings.the following commands show items that should be enabled by default in the configuration. You may wish to review
and verify that these setting are desired for your specific network.
Copyright © 2013, Juniper Networks, Inc. 43
Implementation Guide – Vertical Campus
root@EX6200-1b# set protocols igmp-snooping vlan allset protocols rstpset protocols lldp interface allset protocols lldp-med interface allset poe interface allset ethernet-switching-options storm-control interface all
Configuring Layer 2 Settings for EX6200 Chassisto configure layer 2 parameters and settings on the access switch in dedicated mode:
Table 8: VLANs Configured on EX6200
VLAN-ID VLAN Name Subnet Port Range Name
8 data_wired_1b 10.10.8.0/22 wired_access_ports
20 voip_wired_1b 10.10.20.0/22 wired_voice_ports
32 data_wireless_1b 10.10.32.0/23
40 voip_wireless_1b 10.10.40.0/23
50 management_1b 10.10.50.0/24
52 access_points_1b 10.10.52.0/24 wireless_access_points
Configure VLANs.
root@EX6200-1b#set vlans access_points_1b vlan-id 52set vlans data_wired_1b vlan-id 8set vlans data_wireless_1b vlan-id 32set vlans voip_wired_1b vlan-id 20set vlans voip_wireless_1b vlan-id 40set vlans management_1b vlan-id 50
Configure interfaces.We need to configure one Ip interface on the management VlaN.
root@EX6200-1b# set interfaces vlan unit 50 family inet address 10.10.50.10/24
Configure LAG (aggregated Ethernet) ports.the eX6200-1 chassis has only one laG port configured to connect to the eX8200VC core switch. Junos Os requires
that you configure the number of laG interfaces you want to use before you begin configuring the laG interfaces. We
suggest picking a number slightly larger than what you need in case you add more laG interfaces later. You can change
this value in the future.
Because we need one laG interface for this configuration, we will configure the eX6200-1b chassis with two in case we
add another laG connection later.
root@EX6200-1b# set chassis aggregated-devices ethernet device-count 2
the 10-Gigabit ethernet ports on the eX6200 are only available on the route-engines themselves at this time. each
routing-engine has four 10Gbe ports. the port designations for routing-engine 0 are xe-4/0/0 through 4/0/3 and
for routing-engine 1 xe-5/0/0 through 5/0/3. the routing-engines can only be inserted in slots 4 or 5 so the starting
interface slot numbers will always be 4 or 5.
In the tested network example we will use four ports to create the laG xe-4/0/0, xe-4/0/1, xe-5/0/0 and xe-5/0/1
NOTE: If there are pre-existing configurations on the interfaces required for laG ports they must be removed prior to
laG configuration. a new eX6200 chassis has no port configuration by default, so we can move directly to configuring
the ports.
44 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Configure the interfaces to be part of the respective aggregated interfaces.
root@EX6200-1b# set interfaces xe-4/0/0 ether-options 802.3ad ae0set interfaces xe-4/0/1 ether-options 802.3ad ae0set interfaces xe-5/0/0 ether-options 802.3ad ae0set interfaces xe-5/0/1 ether-options 802.3ad ae0
Next, we need to add laCp to each laG interface to provide some health checking.
NOTE: laCp must be configured on both sides for the laG port to become active.
root@EX6200-1b# set interfaces ae0 aggregated-ether-options lacp activeset interfaces ae0 aggregated-ether-options lacp periodic slow
Disable RSTP on LAG connections to access switches.Because we do not use rstp as a topology protocol, we can disable it on the laG ports going to our access switches.
Disabling rstp also reduces potential convergence times in case a laG member fails, because fewer protocols need to
converge.
NOTE: Note all access switches have rstp enabled locally for loop protection.
root@EX6200-1b# set protocols rstp interface ae0.0 disable
Configure the trunk port and VLAN.Next, we need to configure the laG port as a trunk and add the VlaNs that will be supported going to the core switch.
to enable the laG port as a trunk port, use the set interfaces command.
root@EX6200-1b# set interfaces ae0 unit 0 family ethernet-switching port-mode trunk
Configure VLANs on trunk ports.
Table 9: EX6200 Trunked VLANs
LAG Ports to device to port Trunk/Access VLANs Native VLAN
ae0.0 xe-4/0/0 EX8200VC-1b xe-1/0/4 Trunk data_wired_1b
default
ae0.0 xe-4/0/1 EX8200VC-1b xe-17/0/4 Trunk voip_wired_1b
ae0.0 xe-5/0/0 EX8200VC-1b xe-1/0/5 Trunk data_wireless_1b
ae0.0 xe-5/0/1 EX8200VC-1b xe-17/0/5 Trunk voip_wireless_1b
management_1b
access_points_1b
root@EX6200-1b#set interfaces ae0 unit 0 family ethernet-switching vlan members access_points_1bset interfaces ae0 unit 0 family ethernet-switching vlan members data_wired_1bset interfaces ae0 unit 0 family ethernet-switching vlan members data_wireless_1bset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wired_1bset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wireless_1bset interfaces ae0 unit 0 family ethernet-switching vlan members management_1b
Commit the configuration.
root@EX6200-1b# commit
Copyright © 2013, Juniper Networks, Inc. 45
Implementation Guide – Vertical Campus
Connect the LAG connections to the core switch using the show lldp neighbors command to verify that the connection is up and you can see the other side of the connection.
root@EX6200-1> show lldp neighborsLocal Interface Parent Interface Chassis Id Port info System Namexe-5/0/0.0 ae0.0 28:c0:da:ba:90:00 xe-1/0/5.0 EX8200VC-1bxe-5/0/1.0 ae0.0 28:c0:da:ba:90:00 xe-17/0/5.0 EX8200VC-1bxe-4/0/0.0 ae0.0 28:c0:da:ba:90:00 xe-1/0/4.0 EX8200VC-1bxe-4/0/1.0 ae0.0 28:c0:da:ba:90:00 xe-17/0/4.0 EX8200VC-1bge-0/0/0.0 - 10.10.52.10 port 1 WLA532-US
Run the show lacp interfaces command to verify that LACP is running.
root@EX6200-1> show lacp interfacesAggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-4/0/0 Actor No No Yes Yes Yes Yes Slow Active xe-4/0/0 Partner No No Yes Yes Yes Yes Slow Active xe-4/0/1 Actor No No Yes Yes Yes Yes Slow Active xe-4/0/1 Partner No No Yes Yes Yes Yes Slow Active xe-5/0/0 Actor No No Yes Yes Yes Yes Slow Active xe-5/0/0 Partner No No Yes Yes Yes Yes Slow Active xe-5/0/1 Actor No No Yes Yes Yes Yes Slow Active xe-5/0/1 Partner No No Yes Yes Yes Yes Slow Active LACP protocol: Receive State Transmit State Mux State xe-4/0/0 Current Slow periodic Collecting distributing xe-4/0/1 Current Slow periodic Collecting distributing xe-5/0/0 Current Slow periodic Collecting distributing xe-5/0/1 Current Slow periodic Collecting distributing
Configure secure access port features.NOTE: in the version of code tested in the tested network (12.1r1.9), there is an issue where DHCp requests do not
complete when configuring ports for arp-inspection and dhcp-examine. so we are omitting this step for the eX6200
in this guide. the bug id for this problem is pr# 787161 this pr# has been fixed in newer versions of code. If you need
this feature verify the fix is in the version of code you are loading by looking at the release notes in the issues resolved
section.
We recommend configuring basic security features on user facing VlaNs on access switches. enable these features on
the data_wired_1b and voip_wired_1b, VlaNs.
NOTE: Do not enable these features on networks that frequently have static Ip address assignments. each device with
a static Ip address attached to a port on a VlaN – with these features enabled – requires a static port configuration
with an Ip address and a maC address in order to communicate with the rest of the network. If required, this additional
level of security can be configured, but it will add some overhead when network changes are made.
root@EX6200-1b# set ethernet-switching-options secure-access-port vlan data_wired_1b ip-source-guardset ethernet-switching-options secure-access-port vlan voip_wired_1b ip-source-guard
For more information on the secure access port features see Day One book, Configuring EX Series Ethernet Switches.
Junos Os supports a feature called interface-range, which allows you to group several interfaces together so that you
can configure the entire group using one statement. this can be helpful when you have many similar ports that share
much of the same configuration. this statement can be used to simplify configurations.
With access switches in the tested network, each member in the Virtual Chassis is divided up by port type.
• ports 0–4 are reserved for wireless access points
• ports 5–26 are reserved for data.
• ports 27–47 reserved for voice.
Because these ports are typically configured identically, they use the interface-range statement to simplify operations
and create three different port groups wireless_access_points, wired_data_ports and wired_voice_ports as listed in
table 8.
46 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Table 10: VLAN to Port Range
VLAN-ID VLAN Name Subnet Port Range Name
8 data_wired_1b 10.10.8.0/22 wired_access_ports
32 voip_wired_1b 10.10.32.0/22 wired_voice_ports
52 access_points_1b 10.10.52.0/24 wireless_access_points
root@EX6200-1b# set interfaces interface-range wireless_access_points member-range ge-0/0/0 to ge-0/0/4set interfaces interface-range wired_access_ports member-range ge-0/0/5 to ge-0/0/26set interfaces interface-range wired_voice_ports member-range ge-0/0/27 to ge-0/0/47
Set the port mode.For the user facing ports we need to set the port mode to access. Because we have used the interface-ranges
statement, we only need to set the port mode at the interface-range level, instead of editing every port. For the ports
supporting Wlas we will configure these as trunk ports, but they all have the same VlaN configuration.
root@EX6200-1b# set interfaces interface-range wired_access_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wired_voice_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wireless_access_points unit 0 family ethernet-switching port-mode trunk
Configure port to VLAN.
root@EX6200-1b# set vlans voip_wired_1b interface wired_voice_portsset vlans data_wired_1b interface wired_access_ports
the ports for the Wlas require a trunking configuration and require a native VlaN (access_points_1b) be configured in
order for the access point to boot up. When configuring a native VlaN you cannot configure the port VlaN members
with this same VlaN or it will ignore the native VlaN configuration and will not work.
set interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members data_wireless_1bset interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members voip_wireless_1bset interfaces interface-range wireless_access_points unit 0 family ethernet-switching native-vlan-id access_points_1b
Configure Layer 3 settings.layer 3 configuration for the access switch involves setting a default route in the case of the tested network. In this
case, it points to 10.10.50.1 which is the core switch Ip interface on the management_1a VlaN.
set routing-options static route 0.0.0.0/0 next-hop 10.10.50.1
Commit the configuration.
commit
Copyright © 2013, Juniper Networks, Inc. 47
Implementation Guide – Vertical Campus
Verify IP reachability.Next, you need to verify Ip reachability by “pinging” the core switch management Ip address from the access switch.
this also indicates that trunking is configured properly on the interface and working properly.
root@EX6200-1b> ping 10.10.50.1PING 10.10.50.1 (10.10.50.1): 56 data bytes64 bytes from 10.10.50.1: icmp_seq=0 ttl=64 time=3.458 ms64 bytes from 10.10.50.1: icmp_seq=1 ttl=64 time=3.070 ms
Verify VLANs and trunking.to verify that the proper VlaNs are configured for trunking on the ae0 interface, you can use the show ethernet-
switching interfaces ae0 command.
root@EX6200-1b> show ethernet-switching interfaces ae0Interface State VLAN members Tag Tagging Blockingae0.0 up access_points_1b 52 tagged unblocked data_wired_1b 8 tagged unblocked data_wireless_1b 32 tagged unblocked management_1b 50 tagged unblocked voip_wired_1b 20 tagged unblocked voip_wireless_1b 40 tagged unblocked
to see what ports are configured for specific VlaNs use the show vlans command.
NOTE: Because of the large number of ports in eX6200-1b, the show command output below show the first VlaN’s output.
root@EX6200-1b> show vlansName Tag Interfacesaccess_points_1b 52 ae0.0*, ge-0/0/0.0*, ge-0/0/1.0, ge-0/0/2.0, ge-0/0/3.0, ge-0/0/4.0, ge-1/0/0.0
Configure Class of Servicethe basic Class of service configuration used is almost identical across core and access platforms in the tested
network example.
We will configure Class of service on the core eX6210. the configuration of Cos is done in five steps the first four define
what the Cos service will look like and the last step applies Cos to specific interfaces.
• Forwarding Classes
• Classifiers
• schedulers
• scheduler-maps
• rewrite rules
• Configuring Interfaces
Configuring forwarding classes.First we will configure the forwarding classes, this step also defines what queues are used as well.
root@EX6200-1b# set class-of-service forwarding-classes class control queue-num 7set class-of-service forwarding-classes class voice queue-num 5set class-of-service forwarding-classes class business-app queue-num 3set class-of-service forwarding-classes class server-bulk queue-num 1set class-of-service forwarding-classes class best-effort queue-num 0
48 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Configuring classifiers.Next we will create the classifiers. In the tested network example we are only using DsCp marking for our classification
of traffic. the classifiers map the different DsCp marked packets to the correct queue, if the traffic is not marked or
marked with a DsCp value not listed it will be considered best-effort traffic and treated accordingly.
root@EX6200-1b# set class-of-service classifiers dscp dscp_trusted forwarding-class control loss-priority low code-points nc1set class-of-service classifiers dscp dscp_trusted forwarding-class control loss-priority low code-points nc2set class-of-service classifiers dscp dscp_trusted forwarding-class voice loss-priority low code-points efset class-of-service classifiers dscp dscp_trusted forwarding-class business-app loss-priority low code-points af21set class-of-service classifiers dscp dscp_trusted forwarding-class server-bulk loss-priority low code-points af11set class-of-service classifiers dscp dscp_trusted forwarding-class best-effort loss-priority low code-points be
Configuring schedulers.We will create schedulers for each type of traffic we want to manage. When we define the schedulers we also configure
characteristics like shaping/limiting/forwarding rate, how much buffer is allocated and what priority the traffic has.
In the tested network we have configured a couple of similar sounding schedulers for example voice-user-sched and
voice-network-sched the difference between these schedulers is they are intended to be applied to different types
of interfaces when we create our scheduler maps later. While these currently have the same values, it may be in the
future you need to change the characteristics of your network ports or access ports to be different from each other. By
configuring schedulers this way from the beginning it makes for less work if changes are needed later.
root@EX6200-1b# set class-of-service schedulers control-network-sched shaping-rate percent 5set class-of-service schedulers control-network-sched buffer-size percent 5set class-of-service schedulers control-network-sched priority strict-highset class-of-service schedulers control-user-sched shaping-rate percent 5 set class-of-service schedulers control-user-sched buffer-size percent 5set class-of-service schedulers control-user-sched priority strict-highset class-of-service schedulers voice-network-sched shaping-rate percent 5 set class-of-service schedulers voice-network-sched buffer-size percent 5 set class-of-service schedulers voice-network-sched priority strict-highset class-of-service schedulers voice-user-sched shaping-rate percent 5 set class-of-service schedulers voice-user-sched buffer-size percent 5 set class-of-service schedulers voice-user-sched priority strict-high set class-of-service schedulers business-sched transmit-rate percent 60 set class-of-service schedulers business-sched buffer-size percent 60set class-of-service schedulers business-sched priority low set class-of-service schedulers server-sched transmit-rate percent 30 set class-of-service schedulers server-sched buffer-size percent 30set class-of-service schedulers server-sched priority lowset class-of-service schedulers be-sched transmit-rate remainder set class-of-service schedulers be-sched buffer-size remainderset class-of-service schedulers be-sched priority low
Configuring scheduler maps.scheduler maps tie the individual schedulers to forwarding classes and queues. Here we have created two scheduler
maps one for network (switch to switch) ports and one for access or host ports. the difference between the two is the
different names for the individual control and voice schedulers used in each scheduler-map.
Copyright © 2013, Juniper Networks, Inc. 49
Implementation Guide – Vertical Campus
root@EX6200-1b# set class-of-service scheduler-maps network-port-sched forwarding-class control scheduler control-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class voice scheduler voice-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps network-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps network-port-sched forwarding-class best-effort scheduler be-schedset class-of-service scheduler-maps access-port-sched forwarding-class control scheduler control-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class voice scheduler voice-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps access-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps access-port-sched forwarding-class best-effort scheduler be-sched
Configuring rewrite rules.rewrite rules are used to mark packets appropriately before packets exit an interface so that markings are preserved
throughout the network.
root@EX6200-1b#set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority low code-point nc1set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority high code-point nc2set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class voice loss-priority low code-point efset class-of-service rewrite-rules dscp rewrite-dscp forwarding-class business-app loss-priority low code-point af21set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class best-effort loss-priority low code-point be
Configuring interfaces.In order for Class of service to actually do anything it must be applied to interfaces. We have two main interface types:
Network ports that connect switches together and user ports that users/hosts connect to. When applying Class of
service to an interface in the tested network example you will configure a scheduler and classifier on network ports or a
scheduler, classifier and rewrite policy on access ports.
You can also use wildcards to apply Class of service to multiple interfaces with a single command. For example here
we have used wildcards to configure all the Gbe ports use the same Class of service settings. We could do the same
with our laG connections, but we have relatively few of these to configure so we will do so individually.
NOTE: the most specific commands win, so if you have a wildcard policy that is applied to all gigabit ethernet ports
and then you configure one of those ports specifically with different class of service settings they will not conflict;
instead the more specific port configuration will take precedence.
root@EX6200-1b#set class-of-service interfaces ge-0/0/* scheduler-map access-port-schedset class-of-service interfaces ge-0/0/* unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ge-0/0/* unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae0 scheduler-map network-port-schedset class-of-service interfaces ae0 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae0 unit 0 rewrite-rules dscp rewrite-dscp
Commit the configuration.
commit
50 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Verifying Class of Service Settingsthere are various commands that can be used to verify portions of the Class of service configuration.
Show class-of-service <sub-category>
examples:
show class-of-service scheduler-map
show class-of-service interface <interface name>
show class-of-service rewrite-rule
the most useful Class of service command might be looking at the interface statistics using the command,
show interfaces <interface name> detail
this command will provide details on what queues are configured on the port and how many packets were seen and if
any were dropped.
NOTE: When looking for Class of service statistics using the show interface command you can only see the statistics
on physical interfaces so when looking at a laG interface you need to run this command for each of the physical
interfaces that make up the link in order to view the Class of service details.
root@EX6200-1b# run show interfaces ge-0/0/0 detailPhysical interface: ge-0/0/0, Enabled, Physical link is Up Interface index: 137, SNMP ifIndex: 560, Generation: 140 Link-level type: Ethernet, MTU: 1514, Speed: Auto, Duplex: Auto, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x0 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Hold-times : Up 0 ms, Down 0 ms Current address: 88:e0:f3:c 8:42:03, Hardware address: 88:e0:f3:c8:42:03 Last flapped : 2012-11-05 02:52:26 PST (4d 05:35 ago) Statistics last cleared: 2012-11-08 08:45:06 PST (23:42:31 ago) Traffic statistics: Input bytes : 20807332 5504 bps Output bytes : 10707158 2776 bps Input packets: 83597 2 pps Output packets: 117169 3 pps IPv6 transit statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0
Copyright © 2013, Juniper Networks, Inc. 51
Implementation Guide – Vertical Campus
Egress queues: 8 supported, 5 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 69222 0 1 server-bulk 0 0 0 3 business-app 0 0 0 5 voice 0 0 0 7 control 0 47947 0 Queue number: Mapped forwarding classes 0 best-effort 1 server-bulk 3 business-app 5 voice 7 control Active alarms : None Active defects : None Interface transmit statistics: Disabled Logical interface ge-0/0/0.0 (Index 74) (SNMP ifIndex 896) (Generation 139) Flags: SNMP-Traps 0x0 Encapsulation: ENET2 Traffic statistics: Input bytes : 382375 Output bytes : 6507401 Input packets: 2875 Output packets: 47947 Local statistics: Input bytes : 382375 Output bytes : 6507401 Input packets: 2875 Output packets: 47947 Transit statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps Protocol eth-switch, Generation: 159, Route table: 0 Flags: Trunk-Mode
52 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
WLA
WLA
WLA
WLA
WLA
WLA
WLA
BUILDING A BUILDING B
EX4200VC-2a
EX3300VC-1a
EX4200VC-3a
LAGLAG
LAGEX8200VC-1b
SRX SeriesCluster
WLCCluster
INTERNET
EX6200-1b
App Servers
Centralized DHCPand other services
EX4500VC-1a LAG
LAG
You are Here
Figure 12: EX4500VC Configuration
Copyright © 2013, Juniper Networks, Inc. 53
Implementation Guide – Vertical Campus
Building A: Configuring the coreFor reference throughout this portion of the document we have provided the Building a connection level details in
Figure 13.
WLA
WLA
WLA
WLA
WLA
WLA
BUILDING A
EX4200VC-2a
EX3300VC-1a
EX4200VC-3a
LAGLAG
LAG
EX4500VC-1a
LAG
xe-0/0/6
xe-1/0/39xe-1/0/38xe-0/0/39xe-0/0/38
xe-0/0/6xe-1/0/8
xe-7/1/0 xe-0/1/0
xe-0/0/8
xe-3/1/1 xe-1/1/1
xe-0/1/0xe-5/1/0
xe-1/0/6
xe-0/0/6To Building B
Figure 13: Building A Connection Details
54 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
EX4500 Virtual Chassis Procedure Overview 1. perform the initial setup of the first switch.
2. Configure global configuration items
3. Configure the Virtual Chassis
• Identify the type of Virtual Chassis
• pre-provision the Virtual Chassis
• perform the Virtual Chassis type-specific configuration
• perform the Virtual Chassis standard configuration
4. Configure layer 2 settings
5. Configure layer 3 settings
6. Configure Class of service
Configuring Global Settings for the Core Switchto configure global settings on the core switch:
Connect to the Console port of the EX4500 switch (Setting: s9600, 8, 1, none).press enter. the following prompt appears.
Amnesiac (ttyu0)login
Log in as root and press Enter.Because no password is configured, you are not prompted for one. Check the Junos version and upgrade as needed.
login: rootLogging to master.– – – JUNOS 12.1r1.9 built 2011-11-15 11:14:01 UTCroot@:RE:0%
Type cli at the % prompt.
root@:RE:0% cli{master:0}root>
You should now be at the >prompt.
Configure the date and time in the format: YYYYMMDDhhmm.ss.
set date 201201220830.00
Enter configuration mode by typing configure or edit.
root> configureEntering configuration mode{master:0}[edit]root#
You should now be at the # prompt and ready to start configuring the switch.
Copyright © 2013, Juniper Networks, Inc. 55
Implementation Guide – Vertical Campus
Configure the password.
root# set system root-authentication plain-text-passwordNew password:*******Retype new password:*******{master:0}[edit]root#
Configure the time zone.
root# set system time-zone America/Los_Angeles
Configure the hostname.
root# set system host-name EX4500VC-1a
Configure the management and VME interface (optional).
set interfaces vme unit 0 family inet address 10.94.188.101/24
Configure management access.
root@EX4500VC-1a# set system services web-management https system-generated-certificateset system services sshdelete system services web-management httpdelete system services telnet
Configure DNS.
root@EX4500VC-1a# set system name-server 10.10.24.100set system domain-name xyzcompany.com
Configuring a Virtual Chassis for the Mixed Mode Core Chassisto configure a Virtual Chassis for the core switch:
Identify the Virtual Chassis type.In the case of the tested network, the core switch is a mixed mode Virtual Chassis (both eX4500 and eX4200 switches
in the same Virtual Chassis). For more information about Virtual Chassis, see “Virtual Chassis” on page 93, or the Day
One book, Configuring EX Series Ethernet Switches.
Configure a pre-provisioned Virtual Chassis.the recommended setup process for a Virtual Chassis is called pre-provisioned, which is the process we will use here.
to pre-provision a Virtual Chassis, you need to identify the serial numbers of each device that will be part of the Virtual
Chassis, the device function, and the order in which you want each switch to be placed. Here we have configured the
eX4500 switches to be in slot 0 and slot 1, and act as routing engines. the eX4200 switches are in slot 2 and slot 3,
and configured as line cards. later, when all the switches are connected and powered up, they will automatically be
assigned the proper function and slot. make sure you pay attention to the serial numbers and ordering of each switch
when you connect them together.
the eX series switches by default automatically form a Virtual Chassis, but because the ordering is nondeterministic,
and so the switches may not be numbered sequentially, making things confusing. For more information about Virtual
Chassis, see appendix a and B, or the Day One book, Configuring EX Series Ethernet Switches.
56 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
root@EX4500VC-1a# set virtual-chassis preprovisionedset virtual-chassis member 0 role routing-engineset virtual-chassis member 0 serial-number GX0212140825set virtual-chassis member 1 role routing-engineset virtual-chassis member 1 serial-number GX0212140845set virtual-chassis member 2 role line-cardset virtual-chassis member 2 serial-number FP0211490796set virtual-chassis member 3 role line-cardset virtual-chassis member 3 serial-number FP0211490618
Commit the configuration.
root@EX4500VC-1a# commitconfiguration check succeedscommit complete
Configure specific Virtual Chassis commands.
NOTE: Because this is a mixed mode chassis, we need to configure it to accept a mix of eX4500 and eX4200
devices in the same Virtual Chassis. exit configuration mode by typing exit at the # prompt. the next command is an
operational command.
root@EX4500VC-1a> request virtual-chassis mode mixed
Verify that the mode is correct, by typing show virtual-chassis.
root@EX4500VC-1a> show virtual-chassisPreprovisioned Virtual ChassisVirtual Chassis ID: 8c7a.9353.df56Virtual Chassis Mode: MixedMstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt GX0212140825 ex4500-40f 129 Master* Y
using the VCp ports at the back of the units, cable the remaining members together in a daisy-chained configuration.
When all of the units are cabled properly, power them up. remember to pay attention to the serial number of each
switch when connecting them together to ensure they are in the right position.
after the switches finish booting up, verify that all of the members of the Virtual Chassis are active by running the show
virtual-chassis command.
Preprovisioned Virtual ChassisVirtual Chassis ID: 804d.1d7f.fd6aVirtual Chassis Mode: Mixed Mstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt GX0212140825 ex4500-40f 129 Backup Y 1 vcp-1 2 vcp-01 (FPC 1) Prsnt GX0212140845 ex4500-40f 129 Master* Y 3 vcp-1 0 vcp-02 (FPC 2) Prsnt FP0211490796 ex4200-48px 0 Linecard Y 3 vcp-0 0 vcp-13 (FPC 3) Prsnt FP0211490618 ex4200-48px 0 Linecard Y 1 vcp-0 2 vcp-1
Enter configuration mode again.
Copyright © 2013, Juniper Networks, Inc. 57
Implementation Guide – Vertical Campus
Configure global Virtual Chassis commands.
root@EX4500VC-1a# set system commit synchronizeset routing-options nonstop-routingset ethernet-switching-options nonstop-bridgingset chassis redundancy graceful-switchovercommit and-quit
Configure resilient dual-boot partitions.NOTE: It is important to run this step as it improves the resiliency of the system in case of primary boot partition failure.
this step creates a backup copy of the operating system and is highly recommended. the process takes approximately
5 minutes for each re or member.
request system snapshot slice alternate all-members
Configure default settings.the following items should be enabled by default in the configuration. You may wish to review and verify that these
setting are desired for your specific network.
root@EX4500VC-1a# set protocols igmp-snooping vlan allset protocols rstpset protocols lldp interface allset protocols lldp-med interface allset poe interface allset ethernet-switching-options storm-control interface all
Configuring Layer 2 Settings For Mixed Mode Core Switchto configure layer 2 parameters and settings on the core switch:
Set the bridge priority on the core switch.
NOTE: We enable spanning tree protocol to prevent loops from forming in the network, even though we do not use it
as a topology protocol. as an extra precaution, we set the bridge priority on the core switch to 8192, which will ensure
that it will be the default root bridge in the event another bridging device is connected to the network.
Juniper Networks eX series switches run rstp by default.
root@EX4500VC-1a# set protocols rstp bridge-priority 8k
Configure VLANs and IP interfaces.NOTE: We configure all of the inter-VlaN routing on the core switch. this makes it easier to simultaneously configure
the VlaNs and Ip interfaces for those VlaNs. When creating VlaN names, it is important to note that these names
are case sensitive. the first command creates the VlaN data_wired_1a with a VlaN ID of 12 and then assigns a layer 3
interface called vlan.10 to that VlaN. the second line creates the vlan.12 interface and assigns an Ip address.
root@EX4500VC-1a# set vlans data_wired_1a vlan-id 12set vlans data_wired_1a l3-interface vlan.12
You may notice that the VlaN ID is the same as the interface VlaN unit number (both are number 12). this is not
mandatory, but we recommend that you match the VlaN ID and interface VlaN unit number. It helps to make things
easier to understand later when you have many VlaNs and interfaces to track. We also used a compound command for
the first line. We created the VlaN, assigned the VlaN ID, and assigned a layer 3 interface all at the same time. this
can save you some time but does not have to be done in a single statement. When you look at the configuration, you
will notice that this is separated into two disparate statements.
58 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
NOTE: When you issue a large number of commands at once, we recommend that you issue a commit command to
verify that the commands take effect with no configuration errors. alternatively, you can do a commit check instead,
which verifies the configuration without making it active.
the complete set of VlaN and layer 3 interface statements for the core switch in the tested network example follows.
VLAN configurations
root@EX4500VC-1a# set vlans access_points_1a vlan-id 54set vlans access_points_1a l3-interface vlan.54set vlans data_wired_1a vlan-id 12set vlans data_wired_1a l3-interface vlan.12set vlans data_wireless_1a vlan-id 36set vlans data_wireless_1a l3-interface vlan.36set vlans voip_wired_1a vlan-id 24set vlans voip_wired_1a l3-interface vlan.24set vlans voip_wireless_1a vlan-id 42set vlans voip_wireless_1a l3-interface vlan.42set vlans management_1a vlan-id 51set vlans management_1a l3-interface vlan.51
Interface configurations
root@EX4500VC-1a# set interfaces vlan unit 12 family inet address 10.10.12.1/22set interfaces vlan unit 24 family inet address 10.10.24.1/22set interfaces vlan unit 36 family inet address 10.10.36.1/22set interfaces vlan unit 42 family inet address 10.10.42.1/23set interfaces vlan unit 51 family inet address 10.10.51.1/24set interfaces vlan unit 54 family inet address 10.10.54.1/24
Commit the configuration.
commit
Configure LAG (aggregated Ethernet) ports.In the tested network configuration, laG ports are configured to connect to access switches as trunk ports, and one
laG is the routed interface connecting to building B core eX8200ViC.
Junos Os requires that you configure the number of laG interfaces you want to use before you begin configuring
the interfaces. We suggest picking a number slightly larger than you might need, in case you need to add more laG
interfaces later. You can change this value in the future. We need four aggregated ethernet ports for the tested network
example, so we will configure the core chassis with six, in case we add another access switch.
root@EX4500VC-1a#set chassis aggregated-devices ethernet device-count 6
to provide the highest level of resilience, you need to configure the laG to span multiple eX series switches. In the
tested network example, we use xe-0/0/0 through xe-0/0/2 and xe-1/0/0 through xe-1/0/2 for the laG connections
to the access switches. It is required to assign the laG ports in matching pairs (For example, xe-0/0/0 and xe-1/0/0)
between the eX4500 switches so that they will be part of the same laG interface. this provides link-level and
hardware-level redundancy and provides consistency(making things easier to remember.)
First, we need to remove any port-specific configuration on the physical ports that we want to aggregate. Interfaces
have unit 0 defined by default, but this is not allowed on an interface that is part of an aggregated interface, because it
would conflict with unit 0 on the logical aggregated interface:
Copyright © 2013, Juniper Networks, Inc. 59
Implementation Guide – Vertical Campus
root@EX4500VC-1a# delete interfaces xe-1/0/38 unit 0delete interfaces xe-1/0/39 unit 0delete interfaces xe-0/0/38 unit 0delete interfaces xe-0/0/39 unit 0delete interfaces xe-0/0/8 unit 0delete interfaces xe-1/0/8 unit 0delete interfaces xe-0/0/4 unit 0delete interfaces xe-1/0/4 unit 0delete interfaces xe-0/0/6 unit 0 delete interfaces xe-1/0/6 unit 0
then we configure the interfaces to be part of the respective aggregated interfaces:
root@EX4500VC-1a# set interfaces xe-1/0/38 ether-options 802.3ad ae0set interfaces xe-1/0/39 ether-options 802.3ad ae0set interfaces xe-0/0/38 ether-options 802.3ad ae0set interfaces xe-0/0/39 ether-options 802.3ad ae0set interfaces xe-0/0/8 ether-options 802.3ad ae1set interfaces xe-1/0/8 ether-options 802.3ad ae1set interfaces xe-0/0/4 ether-options 802.3ad ae2set interfaces xe-1/0/4 ether-options 802.3ad ae2set interfaces xe-0/0/6 ether-options 802.3ad ae3set interfaces xe-1/0/6 ether-options 802.3ad ae3
Next we want to add laCp to each laG interface to provide some health checking.
NOTE: You need to configure laCp on the interfaces at both ends for the laG port to become active.
root@EX4500VC-1a# set interfaces ae0 aggregated-ether-options lacp activeset interfaces ae0 aggregated-ether-options lacp periodic slowset interfaces ae1 aggregated-ether-options lacp activeset interfaces ae1 aggregated-ether-options lacp periodic slowset interfaces ae2 aggregated-ether-options lacp activeset interfaces ae2 aggregated-ether-options lacp periodic slowset interfaces ae3 aggregated-ether-options lacp activeset interfaces ae3 aggregated-ether-options lacp periodic slow
Disable RSTP on LAG connections to access switches.Because we are not using stp, we will disable it on the laG ports going to our access switches. this reduces potential
convergence times in case a laG member fails because fewer protocols need to converge.
NOTE: all access switches have rstp enabled locally to prevent looping. Interface ae0.0 is not enabled for switching
so we do not need to disable rstp for that interface.
root@EX4500VC-1a# set protocols rstp interface ae1.0 disableset protocols rstp interface ae2.0 disableset protocols rstp interface ae3.0 disable
Configure trunk and VLAN settings.
We need to configure the laG ports as trunks and add the VlaNs that will be supported on the individual access
switches.
root@EX4500VC-1a# set interfaces ae0 unit 0 family ethernet-switching port-mode trunkset interfaces ae1 unit 0 family ethernet-switching port-mode trunkset interfaces ae2 unit 0 family ethernet-switching port-mode trunk
Now commit the configuration.
60 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Configure VLANs on the trunk ports.You can configure port-to-VlaN mapping in two different ways:
• You can configure the VlaNs directly as part of the port configuration.
• You can configure the ports included in the VlaN under the VlaN configuration.
each of these has different advantages and disadvantages. Generally, it makes sense to configure access ports (client-
facing) under the VlaN configuration and configure VlaNs directly on the port for trunk port configuration. You cannot
configure the VlaN mapping in both places— that might produce errors when doing a configuration commit operation.
as discussed previously, we need to configure the VlaNs that the trunk port will carry directly on the interface
configuration section. this makes it easier to tell what VlaNs a specific trunk is part of when viewing the configuration.
When you add VlaNs directly to a trunk port you have the option of adding them by their VlaN ID or by the VlaN
name. In this example, we will add them by VlaN name, because this makes the overall configuration more readable.
the addition of several VlaNs to a trunk can be achieved in two ways: specified one at a time, or several VlaNs can
be configured simultaneously by enclosing them in [] brackets and separating them with spaces. this example shows
each set command. the interfaces are being configured as a trunk and then vlans being added for each of the laG
interfaces we have configured as trunk ports ae1, ae2, and ae3.
root@EX4500VC-1a#set interfaces ae1 unit 0 family ethernet-switching port-mode trunkset interfaces ae1 unit 0 family ethernet-switching vlan members data_wired_1aset interfaces ae1 unit 0 family ethernet-switching vlan members voip_wired_1aset interfaces ae1 unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces ae1 unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces ae1 unit 0 family ethernet-switching vlan members access_points_1aset interfaces ae1 unit 0 family ethernet-switching vlan members management_1aset interfaces ae2 unit 0 family ethernet-switching port-mode trunkset interfaces ae2 unit 0 family ethernet-switching vlan members data_wired_1aset interfaces ae2 unit 0 family ethernet-switching vlan members voip_wired_1aset interfaces ae2 unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces ae2 unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces ae2 unit 0 family ethernet-switching vlan members access_points_1aset interfaces ae2 unit 0 family ethernet-switching vlan members management_1aset interfaces ae3 unit 0 family ethernet-switching port-mode trunkset interfaces ae3 unit 0 family ethernet-switching vlan members data_wired_1aset interfaces ae3 unit 0 family ethernet-switching vlan members voip_wired_1aset interfaces ae3 unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces ae3 unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces ae3 unit 0 family ethernet-switching vlan members access_points_1aset interfaces ae3 unit 0 family ethernet-switching vlan members management_1a
Configure Secure Access Port Features.
most ports on core switches do not need any secure access port features enabled it unnecessarily complicates the
configuration. the reason is that statically assigned Ip addresses are typically used for servers and other networking
devices, and each of these would require exceptions to be manually entered in order to work if these features are
enabled. there are some VlaNs on the core switch, however, on which we recommend enabling these features: the
data_wired_1a, voip_wired_1a ; client-facing VlaNs that are configured on this switch.
root@EX4500VC-1a# set ethernet-switching-options secure-access-port vlan data_wired_1a arp-inspectionset ethernet-switching-options secure-access-port vlan data_wired_1a examine-dhcpset ethernet-switching-options secure-access-port vlan data_wired_1a ip-source-guardset ethernet-switching-options secure-access-port vlan voip_wired_1a arp-inspectionset ethernet-switching-options secure-access-port vlan voip_wired_1a examine-dhcpset ethernet-switching-options secure-access-port vlan voip_wired_1a ip-source-guard
Configuring Power Over Ethernet (Optional).
If you have poe-capable eX4200 switches, you can enable poe on the system. By default this is disabled, because the
default configuration is derived from the eX4500 switch, which does not have poe support. to enable poe on the core
switch run the command:
set poe interface all
root@EX4500VC-1a# set poe interface all
Copyright © 2013, Juniper Networks, Inc. 61
Implementation Guide – Vertical Campus
Configuring Layer 3 Settings For Mixed Mode Core Switchto configure layer 3 parameters on the core switch:
Configure DHCP.the tested network example uses DHCp forwarding and a central DHCp server for all Ip address allocation except for
the guest_wireless VlaN. addresses for guest users are allocated directly from the srX series Gateways to keep these
clients isolated from the rest of the network. DHCp services can be set up directly on eX series switches if desired
(see appendix C). DHCp forwarding is essentially a broadcast forwarding system for DHCp requests that allows users
to consolidate their DHCp services in a centralized location instead of having a DHCp server for every subnet. the
following configuration enables DHCp forwarding on the VlaN interfaces listed, and forwards DHCp requests to the
DHCp server 10.10.46.100.
root@EX4500VC-1a# set forwarding-options helpers bootp description DHCP-SERVER-Aset forwarding-options helpers bootp server 10.10.46.100set forwarding-options helpers bootp interface vlan.12set forwarding-options helpers bootp interface vlan.24set forwarding-options helpers bootp interface vlan.36set forwarding-options helpers bootp interface vlan.42set forwarding-options helpers bootp interface vlan.54
Configure default gateway and static routes.
root@EX4500VC-1a# set routing-options static route 0.0.0.0/0 next-hop 10.10.200.1
Configure OSPF.We need to configure a single OspF area that will be the backbone area 0.0.0.0 and add the interfaces and subnets we
wish to advertise to the building B core.
NOTE: the subnet is all that is required to add the interface to the area. mask information will be automatically
imported into OspF and redistributed. We have configured several interfaces as passive OspF interfaces. this means
their subnets will be advertised to other OspF routers, but we will not send OspF advertisements on these interfaces;
just ae0 connecting to the eX8200 Virtual Chassis in building B.
root@EX4500VC-1a# set protocols ospf area 0.0.0.0 interface vlan.46 passiveset protocols ospf area 0.0.0.0 interface vlan.12 passiveset protocols ospf area 0.0.0.0 interface vlan.24 passiveset protocols ospf area 0.0.0.0 interface vlan.36 passiveset protocols ospf area 0.0.0.0 interface vlan.42 passiveset protocols ospf area 0.0.0.0 interface vlan.54 passiveset protocols ospf area 0.0.0.0 interface vlan.58 passiveset protocols ospf area 0.0.0.0 interface ae0.0
Configure non-stop routingConfigure non-stop routing to keep the routing engines in sync with routing protocol state.
root@EX4500VC-1a# set routing-options nonstop-routing
Commit the configuration.
commit
62 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Configure Class of Servicethe basic Cos configuration used is almost identical across core and access platforms in the network example. We
will configure Cos on the core eX4500VC-1a. the configuration first defines the Cos and then applies it to specific
interfaces.
Configuring forwarding classesFirst we will configure the forwarding classes, this step also defines what queues are used as well.
root@EX4500VC-1a# set class-of-service forwarding-classes class control queue-num 7set class-of-service forwarding-classes class voice queue-num 5set class-of-service forwarding-classes class business-app queue-num 3set class-of-service forwarding-classes class server-bulk queue-num 1set class-of-service forwarding-classes class best-effort queue-num 0
Configuring classifiersNext we will create the classifiers. In the tested network example we are only using DsCp marking for our classification
of traffic. the classifiers map the different DsCp marked packets to the correct queue, if the traffic is not marked or
marked with a DsCp value not listed it will be considered best-effort traffic and treated accordingly.
root@EX4500VC-1a# set class-of-service classifiers dscp dscp_trusted forwarding-class control loss-priority low code-points nc1set class-of-service classifiers dscp dscp_trusted forwarding-class control loss-priority low code-points nc2set class-of-service classifiers dscp dscp_trusted forwarding-class voice loss-priority low code-points efset class-of-service classifiers dscp dscp_trusted forwarding-class business-app loss-priority low code-points af21set class-of-service classifiers dscp dscp_trusted forwarding-class server-bulk loss-priority low code-points af11set class-of-service classifiers dscp dscp_trusted forwarding-class best-effort loss-priority low code-points be
Copyright © 2013, Juniper Networks, Inc. 63
Implementation Guide – Vertical Campus
Configuring schedulersWe will create schedulers for each type of traffic we want to manage. When the schedulers are defined we also
configure characteristics like shaping/limiting/forwarding rate, how much buffer is allocated, and what priority the
traffic has. In the tested network there are similar sounding schedulers, for example: voice-user-sched and voice-
network-sched. the difference between these schedulers is they are intended to be applied to different types of
interfaces when we create our scheduler maps later. While these currently have the same values, they may be changed
if you need to change the characteristics of your network ports or access ports. By configuring schedulers this way from
the beginning it is less work to implement changes later.
root@EX4500VC-1a#set class-of-service schedulers control-network-sched shaping-rate percent 5set class-of-service schedulers control-network-sched buffer-size percent 5set class-of-service schedulers control-network-sched priority strict-highset class-of-service schedulers control-user-sched shaping-rate percent 5 set class-of-service schedulers control-user-sched buffer-size percent 5set class-of-service schedulers control-user-sched priority strict-highset class-of-service schedulers voice-network-sched shaping-rate percent 5 set class-of-service schedulers voice-network-sched buffer-size percent 5 set class-of-service schedulers voice-network-sched priority strict-highset class-of-service schedulers voice-user-sched shaping-rate percent 5 set class-of-service schedulers voice-user-sched buffer-size percent 5 set class-of-service schedulers voice-user-sched priority strict-high set class-of-service schedulers business-sched transmit-rate percent 60 set class-of-service schedulers business-sched buffer-size percent 60set class-of-service schedulers business-sched priority low set class-of-service schedulers server-sched transmit-rate percent 30 set class-of-service schedulers server-sched buffer-size percent 30set class-of-service schedulers server-sched priority lowset class-of-service schedulers be-sched transmit-rate remainder set class-of-service schedulers be-sched buffer-size remainderset class-of-service schedulers be-sched priority low
Configuring scheduler mapsscheduler maps tie the individual schedulers to forwarding classes and queues. Here we have created two scheduler
maps: one for network (switch to switch) ports and one for access or host ports. the difference between the two is the
different names for the individual control and voice schedulers used in each scheduler-map.
root@EX4500VC-1a#set class-of-service scheduler-maps network-port-sched forwarding-class control scheduler control-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class voice scheduler voice-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps network-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps network-port-sched forwarding-class best-effort scheduler be-schedset class-of-service scheduler-maps access-port-sched forwarding-class control scheduler control-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class voice scheduler voice-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps access-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps access-port-sched forwarding-class best-effort scheduler be-sched
64 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Configuring rewrite rulesrewrite rules are used to mark packets appropriately before packets exit an interface, so that markings are preserved
throughout the network.
root@EX4500VC-1a#set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority low code-point nc1set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority high code-point nc2set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class voice loss-priority low code-point efset class-of-service rewrite-rules dscp rewrite-dscp forwarding-class business-app loss-priority low code-point af21set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class best-effort loss-priority low code-point be
Configuring interfaces.In order for Class of service to actually do anything it must be applied to interfaces. We have two main interface types:
Network ports that connect switches together and user ports that connect users/hosts. When applying Class of service
to an interface in the tested network example you will configure a scheduler and classifier on network ports, or a
scheduler, classifier and rewrite policy on access ports.
You can also use wildcards to apply Class of service to multiple interfaces with a single command. For example, here
we have used wildcards to configure all the Gbe ports use the same Class of service settings. We could do the same
with our laG connections, but we have relatively few of these to configure so we will do so individually.
NOTE: the most specific commands win, so if you have a wildcard policy that is applied to all gigabit ethernet ports
and then you configure one of those ports specifically with different class of service settings they will not conflict;
instead the more specific port configuration will take precedence.
root@EX4500VC-1a#set class-of-service interfaces ge-* scheduler-map access-port-schedset class-of-service interfaces ge-* unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ge-* unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae0 scheduler-map network-port-schedset class-of-service interfaces ae0 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae0 unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae1 scheduler-map network-port-schedset class-of-service interfaces ae1 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae1 unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae2 scheduler-map network-port-schedset class-of-service interfaces ae2 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae2 unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae3 scheduler-map network-port-schedset class-of-service interfaces ae3 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae3 unit 0 rewrite-rules dscp rewrite-dscp
Commit the configuration.
commit
Copyright © 2013, Juniper Networks, Inc. 65
Implementation Guide – Vertical Campus
Verifying Class of Service Settingsthere are various commands that can be used to verify portions of the Class of service configuration.
Show class-of-service <sub-category>
examples:
show class-of-service scheduler-map
show class-of-service interface <interface name>
show class-of-service rewrite-rule
the most useful Class of service command might be looking at the interface statistics using the command.
show interfaces <interface name> detail
this command will provide details on what queues are configured on the port and how many packets were seen and if
any were dropped.
NOTE: When looking for Class of service statistics using the show interface command you can only see the statistics
on physical interfaces so when looking at a laG interface you need to run this command for each of the physical
interfaces that make up the link in order to view the Class of service details.
root@EX4500VC-1a> show interfaces ge-3/0/47 detailPhysical interface: ge-3/0/47, Enabled, Physical link is Up Interface index: 232, SNMP ifIndex: 727, Generation: 235 Link-level type: Ethernet, MTU: 1514, Speed: Auto, Duplex: Auto, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x0 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Hold-times : Up 0 ms, Down 0 ms Current address: 78:fe:3d:4e:b2:32, Hardware address: 78:fe:3d:4e:b2:32 Last flapped : 2012-05-10 02:16:17 GMT-8 (26w1d 22:23 ago) Statistics last cleared: 2012-11-07 19:03:38 GMT-8 (2d 05:36 ago) Traffic statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps IPv6 transit statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0Egress queues: 8 supported, 5 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 0 0 1 server-bulk 0 0 0 3 business-app 0 0 0 5 voice 0 0 0 7 control 0 0 0 Queue number: Mapped forwarding classes 0 best-effort 1 server-bulk 3 business-app 5 voice 7 control Active alarms : None Active defects : None Interface transmit statistics: Disabled
66 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Building A: Configuring the Access Layer
WLA
WLA
WLA
WLA
WLA
WLA
WLA
BUILDING A BUILDING B
EX4200VC-2a
EX3300VC-1a
EX4200VC-3a
LAGLAG
LAGEX8200VC-1b
SRX SeriesCluster
WLCCluster
INTERNET
EX6200-1b
App Servers
Centralized DHCPand other services
EX4500VC-1a LAG
LAG
You are Here
Figure 14: EX4200VC-3a Configuration
Configuring EX4200 as Extended Mode Virtual ChassisConfiguring access switches is simpler than configuring the core switch. We only configure layer 2 services on the
access switches and an Ip address on the management VlaN to provide remote management. this section covers the
configuration for eX4200VC-3b, which is an extended mode Virtual Chassis in the tested network (see Figure 14). this
section includes the following topics:
Procedure overview 1. Configure global configuration items
2. Configure the Virtual Chassis
• Identify the type of Virtual Chassis
• pre-provision the Virtual Chassis
• perform the Virtual Chassis type-specific configuration
• perform the Virtual Chassis standard configuration
3. Configure layer 2 settings
4. Configure layer 3 settings
5. Configure Class of service
Configuring Global Settings for the Core Switchto configure global settings on the core switch:
Connect to the Console port of the EX4200 switch (Setting: s9600, 8, 1, none).press enter. the following prompt appears.
Amnesiac (ttyu0)login
Copyright © 2013, Juniper Networks, Inc. 67
Implementation Guide – Vertical Campus
Log in as root and press Enter.
Because no password is configured, you are not prompted for one. Check the version of Junos and upgrade if required.
login: rootLogging to master.– – – JUNOS 12.1r1.9 built 2011-11-15 11:14:01 UTCroot@:RE:0%
Type cli at the % prompt.
root@:RE:0% cli{master:0}root>
You should now be at the >prompt.
Configure the date and time in the format: YYYYMMDDhhmm.ss.
set date 201201220830.00
Enter configuration mode by typing configure or edit.
root> configureEntering configuration mode{master:0}[edit]root#
You should now be at the # prompt and ready to start configuring the switch.
Configure the password.
root# set system root-authentication plain-text-passwordNew password:*******Retype new password:*******{master:0}[edit]root#
Configure the time zone.
root# set system time-zone America/Los_Angeles
Configure the hostname.
root# set system host-name EX4200VC-3b
Configure the management and VME interface.
set interfaces vme unit 0 family inet address 10.94.188.101/24
Configure management access.
root@ EX4200VC-3b# set system services web-management https system-generated-certificateset system services sshdelete system services web-management httpdelete system services telnet
68 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Configure DNS
root@EX4200VC-3a#set system name-server 10.10.24.100set system domain-name xyzcompany.com
Configuring an Extended Mode Virtual Chassis for the EX4200to configure a Virtual Chassis for the core switch:
Identify the Virtual Chassis Type.In the case of the tested network, this access switch is an extended mode Virtual Chassis (it uses 10-Gigabit ethernet
links to extend the Virtual Chassis between wiring closets and is managed as a single logical switch). For more
information about Virtual Chassis, see appendix a and B, or the Day One book, Configuring EX Series Ethernet Switches.
Configure a Pre-provisioned Virtual Chassis.the recommended setup process for a Virtual Chassis is called pre-provisioned, which is the process we will use here.
to pre-provision a Virtual Chassis, you need to identify the serial numbers of each device that will be part of the Virtual
Chassis, the device function, and the order in which you want each switch to be placed.
the eX series switches will by default form a Virtual Chassis group automatically when connected together be Virtual
Chassis ports. However, the ordering is nondeterministic, so the switches may not be numbered sequentially, making
things confusing. For more information about Virtual Chassis, see appendix a and B, or the Day One book, Configuring EX Series Ethernet Switches.
root@EX4200VC-3a# set virtual-chassis preprovisionedset virtual-chassis member 0 role routing-engineset virtual-chassis member 0 serial-number FP0211490670set virtual-chassis member 1 role line-cardset virtual-chassis member 1 serial-number FP0211490804set virtual-chassis member 2 role routing-engineset virtual-chassis member 2 serial-number FP0211490739set virtual-chassis member 3 role line-cardset virtual-chassis member 3 serial-number FP0211490735
Set the Virtual Chassis to support fast failover on 10-Gigabit Ethernet Virtual Chassis interfaces.
root@EX4200VC-3a# set virtual-chassis fast-failover xe
NOTE: by default split-detection is enabled, and because all devices are not located in the same location we
recommend leaving split-detection enabled. If you want to disable split detection it can be done by issuing the
command “set virtual-chassis no-split-detection”. It is recommended that split-detection be disabled for Virtual
Chassis with only two devices. If you are not familiar with how split-detection works please review the section on
Virtual Chassis split-detection located appendix a for more details.
Configure global virtual chassis commands.
root@EX4200VC-3a# set system commit synchronizeset ethernet-switching-options nonstop-bridgingset chassis redundancy graceful-switchover
Commit the configuration.
root@EX4200VC-3a# commit
If you see an error message like the following, you can ignore it. the configuration commit operation has been
completed.
Copyright © 2013, Juniper Networks, Inc. 69
Implementation Guide – Vertical Campus
root@EX4200VC-3a# commiterror: Could not connect to fpc-1 : Can’t assign requested addresswarning: Cannot connect to other RE, ignoring itconfiguration check succeedscommit complete
using the VCp ports at the back of the units, cable each pair of eX series switches together. remember to pay careful
attention to the serial numbers of each switch before cabling them together.
WARNING: Do not connect the 10-Gigabit Ethernet ports at this time.
When all of the switches are cabled properly, power them up. You should now have two Virtual Chassis each, with two
members. One of the two-member chassis will be pre-provisioned. Verify that this is working properly by running the
show virtual-chassis command. Output similar to the example below indicates that the chassis members are present,
the Virtual Chassis is pre-provisioned, and that the members are correctly identified. Here, member 0 supposed to be a
routing engine and member 1 is supposed to be in line card mode. this is verified by the output.
root@EX4200VC-3a> show virtual-chassisPreprovisioned Virtual ChassisVirtual Chassis ID: 3f68.0cec.a7e1Virtual Chassis Mode: EnabledMstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt FP0211490670 ex4200-48px 129 Master* N 1 vcp-0 1 vcp-11 (FPC 1) Prsnt FP0211490804 ex4200-48px 0 Linecard N 0 vcp-0 0 vcp-1
Configure Virtual Chassis extended ports.since this is an extended mode chassis, we need to configure it to use some of the 10-Gigabit ethernet ports as Virtual
Chassis extended ports so the switches can form a single Virtual Chassis. In our example, we use the eX-um-2x4sFp
uplink module on our chassis that supports either two 10-Gbps or four 1-Gbps ports. the first and third positions
coincide with the 10-Gigabit ethernet ports and are filled on the uplink module, so we will configure ports xe-x/1/0 and
xe-x/1/2. We will use port 0 in our case for each switch.
NOTE: the port definition in your example could be different if you use a different model of eX series device as your
uplink module, but as it should still have port 0, this part of the configuration does not change.
root@EX4200VC-3a> request virtual-chassis vc-port set pic-slot 1 port 0 member 0request virtual-chassis vc-port set pic-slot 1 port 0 member 1
use the show virtual-chassis vc-port command to verify that the ports are configured correctly. Here we can see that
interface 1/0 on each switch is configured and up but has no neighbors.
root@EX4200VC-3a> show virtual-chassis vc-portfpc0:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 1 vcp-1vcp-1 Dedicated 2 Up 32000 1 vcp-01/0 Configured -1 Up 10000fpc1:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 0 vcp-1vcp-1 Dedicated 2 Up 32000 0 vcp-01/0 Configured -1 Up 10000
70 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Connect your console to the second pair of switches. Press Enter and you should see the following prompt:
Amnesiac (ttyu0)login:
Log in as root and press Enter. there should be no password configured, so you should not be prompted for one. Note the version of Junos and
upgrade the unit if necessary.
login: rootLogging to master.- - - JUNOS 12.1r1.9 built 2011-11-15 11:14:01 UTCroot@:RE:0%
You should now be at the % prompt of the switch.
Type cli at the % Prompt.
root@:RE:0% cli{master:0}root>
You should now be at the > prompt.
use the show virtual-chassis command to verify that the switches are up and running. When both of the switches show
up, we can configure the Virtual Chassis ports on these switches.
root> show virtual-chassisVirtual Chassis ID: b155.0784.e162Virtual Chassis Mode: EnabledMstr Mixed NeighborListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt FP0211490739 ex4200-48px 128 Master* N 1 vcp-0 1 vcp-11 (FPC 1) Prsnt FP0211490735 ex4200-48px 128 Backup N 0 vcp-0 0 vcp-1
Configure the Second Set of Virtual Chassis Extended Ports
root>request virtual-chassis vc-port set pic-slot 1 port 0 member 0request virtual-chassis vc-port set pic-slot 1 port 0 member 1
Copyright © 2013, Juniper Networks, Inc. 71
Implementation Guide – Vertical Campus
use the show virtual-chassis vc-port command to verify the ports are configured correctly. Here we can see that
interface 1/0 on each switch is configured and up but has no neighbors.
root> show virtual-chassis vc-portfpc0:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 1 vcp-1vcp-1 Dedicated 2 Up 32000 1 vcp-01/0 Configured -1 Down 10000fpc1:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 0 vcp-1vcp-1 Dedicated 2 Up 32000 0 vcp-01/0 Configured -1 Down 10000
Connect the Virtual Chassis extended ports• Connect switches 1 and 3 together using the 10-Gigabit ethernet port xe-x/1/0 on each switch
• Connect switches 2 and 4 together using the 10-Gigabit ethernet port xe-x/1/0 on each switch.
Verify Virtual Chassis extended ports• Connect the console back to the first pair of switches.
• use the show virtual-chassis vc-port command to verify the port configuration is correct. all of the four switches are
visible, with one configured 1/0 port that has a neighbor listed.
root@EX4200VC-3a> show virtual-chassis vc-portfpc0:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 1 vcp-1vcp-1 Dedicated 2 Up 32000 1 vcp-01/0 Configured -1 Up 10000 2 vcp-255/1/0
fpc1:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 0 vcp-1vcp-1 Dedicated 2 Up 32000 0 vcp-01/0 Configured -1 Up 10000 3 vcp-255/1/0
fpc2:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 3 vcp-1vcp-1 Dedicated 2 Up 32000 3 vcp-01/0 Configured -1 Up 10000 0 vcp-255/1/0
fpc3:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 2 vcp-1vcp-1 Dedicated 2 Up 32000 2 vcp-01/0 Configured -1 Up 10000 1 vcp-255/1/0
72 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
use the show virtual-chassis command to verify that the Virtual Chassis is built as expected, based on the pre-
provisioning configuration we did earlier.
root@EX4200VC-3a> show virtual-chassis
Preprovisioned Virtual ChassisVirtual Chassis ID: 3f68.0cec.a7e1Virtual Chassis Mode: Enabled Mstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt FP0211490670 ex4200-48px 129 Backup N 1 vcp-0 1 vcp-1 2 vcp-255/1/01 (FPC 1) Prsnt FP0211490804 ex4200-48px 0 Linecard N 0 vcp-0 0 vcp-1 3 vcp-255/1/02 (FPC 2) Prsnt FP0211490739 ex4200-48px 129 Master* N 3 vcp-0 3 vcp-1 0 vcp-255/1/03 (FPC 3) Prsnt FP0211490735 ex4200-48px 0 Linecard N 2 vcp-0 2 vcp-1 1 vcp-255/1/0
Configure resilient dual-boot partitionsNOTE: It is important to run this step as it improves the resiliency of the system in the case of primary boot partition
failure. this step creates a backup copy of the operating system and is highly recommended. this process takes
approximately 5 minutes for each re or member.
request system snapshot slice alternate all-members
Configure default settingsthe following commands show items that should be enabled by default in the configuration. You may wish to review
and verify that these setting are desired for your specific network.
root@EX4200VC-3a# set protocols igmp-snooping vlan allset protocols rstpset protocols lldp interface allset protocols lldp-med interface allset poe interface allset ethernet-switching-options storm-control interface all
Configuring Layer 2 Settingsto configure layer 2 parameters and settings on the access switch in extended mode:
Configure VLANs
the eX4200VC-3b chassis has the following VlaNs assigned: data_wired_1a, data_wireless_1a, voip_wired_1a, voip_
wireless_1a, management_1a. It has only one Ip interface defined, which is on the management_1a VlaN.
root@EX3300VC-1a# set vlans access_points_1a vlan-id 54set vlans data_wired_1a vlan-id 12set vlans data_wireless_1a vlan-id 36set vlans voip_wired_1a vlan-id 24set vlans voip_wireless_1a vlan-id 42set vlans management_1a vlan-id 51
Configure InterfacesWe need to configure one Ip interface on the management VlaN.
set interfaces vlan unit 51 family inet address 10.10.51.9/24
Copyright © 2013, Juniper Networks, Inc. 73
Implementation Guide – Vertical Campus
Configure LAG (aggregated Ethernet) Portsthe eX4200VC-3b chassis has only one laG port configured to connect to the core switch. Junos Os requires that you
configure the number of laG interfaces you want to use before you begin configuring the laG interfaces. We suggest
picking a number slightly larger than what you need in case you add more laG interfaces later. You can change this
value in the future.
Because we need one laG interface for this configuration, we will configure the chassis with two in case we add
another laG connection later.
root@EX4200VC-3a# set chassis aggregated-devices ethernet device-count 2
the 10-Gigabit ethernet ports on the eX4200 series are only available using the uplink module ports. We have uplink
modules on each of the four switches. However, the first port xe-x/1/0 is already in use on each switch to form the
extended Virtual Chassis. We need to configure the laG connection on switch members 1 and 3, using ports xe-1/1/1
and xe-3/1/1.
First, we need to remove any port-specific configuration on the physical ports we want to aggregate. By default,
interfaces have unit 0 defined, but this is not allowed on an interface that is part of an aggregate interface because it
would conflict with unit 0 on the logical aggregate interface.
root@EX4200VC-3a# delete interfaces xe-1/1/1 unit 0delete interfaces xe-3/1/1 unit 0
root@EX4200VC-3a# set interfaces xe-1/1/1 ether-options 802.3ad ae0set interfaces xe-3/1/1 ether-options 802.3ad ae0
Next, we need to add LACP to each LAG interface to provide some health checking.NOTE: laCp must be configured on both sides for the laG port to become active.
root@EX4200VC-3a# set interfaces ae0 aggregated-ether-options lacp activeset interfaces ae0 aggregated-ether-options lacp periodic slow
Disable RSTP on LAG connections to access switches.Because we are not using rstp as a topology protocol, we can disable it on the laG ports going to our access
switches. Disabling rstp also reduces potential convergence times in case of a laG member failure, because fewer
protocols need to converge.
NOTE: all access switches will have rstp enabled for loop protection locally.
root@EX4200VC-3a# set protocols rstp interface ae0.0 disable
Configure the trunk port and VLAN
Next, we need to configure the laG port as a trunk and add the VlaNs that will be going to the core switch. to enable
the laG port as a trunk port, use the set interfaces command.
root@EX4200VC-3a# set interfaces ae0 unit 0 family ethernet-switching port-mode trunk
Configure VLANs on trunk ports.VlaN configuration for ae0, which connects to the eX4500VC-1a has data_wired_1a, voip_wired_1a, data_wireless_1a,
voip_wireless_1a, the management_1a VlaN for switch management and access_points_1a for the Wlas to reside.
VlaNs can be added in a single statement surrounded by [] or can be added one line at a time. this example shows
each command:
74 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
root@EX4200VC-3a# set interfaces ae0 unit 0 family ethernet-switching vlan members data_wired_1aset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wired_1aset interfaces ae0 unit 0 family ethernet-switching vlan members access_points_1aset interfaces ae0 unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces ae0 unit 0 family ethernet-switching vlan members management_1a
Commit the configuration.
commit
You should see the commit operation finish on each of the eX series switches in the Virtual Chassis.
root@EX4200VC-3a# commitfpc0:configuration check succeedsfpc1:commit completefpc2:commit completefpc3:commit completefpc0:commit complete
Now Connect the LAG connections to the core switch.run the show lldp neighbors command to verify that the connection is up and you can see the other side of the
connection.
root@EX4200VC-3a> show lldp neighborsLocal Interface Parent Interface Chassis Id Port info System Namexe-1/1/1.0 ae0.0 a8:d0:e5:b5:0f:80 xe-0/0/4.0 EX4500VC-1axe-3/1/1.0 ae0.0 a8:d0:e5:b5:0f:80 xe-1/0/4.0 EX4500VC-1a
run the show lacp interfaces command to verify that lacp is running
root@EX4200VC-3a# run show lacp interfacesAggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-3/1/1 Actor No No Yes Yes Yes Yes Slow Active xe-3/1/1 Partner No No No No Yes Yes Slow Active xe-1/1/1 Actor No No Yes Yes Yes Yes Slow Active xe-1/1/1 Partner No No Yes Yes Yes Yes Slow Active LACP protocol: Receive State Transmit State Mux State xe-3/1/1 Current Slow periodic Collecting distributing xe-1/1/1 Current Slow periodic Collecting distributing
Configure secure access port features.We recommend configuring these basic security features on the majority of the VlaNs on access switches. We need to
enable these features on the data_wired_1a and voip_wired_1a VlaNs.
You may notice that we do not enable these features on all the VlaNs. some VlaNs have a greater tendency to have
statically configured devices or may not require this feature. each device with a static Ip address attached to a port on
a VlaN, with these features enabled, requires a static port configuration with an Ip address and a maC address in order
to communicate with the rest of the network. this additional level of security can be configured If required, but it will
add some configuration overhead when network changes are made.
Copyright © 2013, Juniper Networks, Inc. 75
Implementation Guide – Vertical Campus
root@EX4200VC-3a# set ethernet-switching-options secure-access-port vlan data_wired_1a arp-inspectionset ethernet-switching-options secure-access-port vlan data_wired_1a examine-dhcpset ethernet-switching-options secure-access-port vlan data_wired_1a ip-source-guardset ethernet-switching-options secure-access-port vlan voip_wired_1a arp-inspectionset ethernet-switching-options secure-access-port vlan voip_wired_1a examine-dhcpset ethernet-switching-options secure-access-port vlan voip_wired_1a ip-source-guard
For more information about port security features, see the Day One book, Configuring EX Series Ethernet Switches, or
Port Security on EX Series Switches Guide at www.Juniper.net/techpubs.
Junos Os supports a feature called interface-range, which allows you to group several interfaces together so that you
can configure the entire group using one statement. this can be helpful when you have many similar ports that will
share much of the same configuration, and this statement can be used to simplify configurations.
With the access switches in the tested network, each member in the Virtual Chassis is divided up by port type:
• ports 0–4 are reserved for wireless access points
• ports 5–26 are reserved for data.
• ports 27–47 reserved for voice.
since these ports are typically configured identically, you use the interface-range statement to simplify operations and
create three different port groups wireless_access_points, wired_data_ports and wired_voice_ports as listed in table 9.
Table 11: EX4200 Virtual Chassis 1 VLAN Address Mapping
VLAN-ID VLAN Name Subnet Port Range Name
12 data_wired_1a 10.10.8.0/22 wired_access_ports
24 voip_wired_1a 10.10.24.0/22 wired_voice_ports
54 access_points_1a 10.10.54.0/24 wireless_access_points
root@EX4200VC-3a# set interfaces interface-range wired_access_ports member-range ge-0/0/5 to ge-0/0/26set interfaces interface-range wired_voice_ports member-range ge-0/0/27 to ge-0/0/47set interfaces interface-range wireless_access_points member-range ge-0/0/0 to ge-0/0/4
Set the port mode.set the port mode to access. Because we have used the interface-ranges statement, we only need to set the port mode
at the interface-range instead of editing every port.
root@EX4200VC-3a# set interfaces interface-range wired_access_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wired_voice_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wireless_access_points unit 0 family ethernet-switching port-mode trunk
Configure port to VLAN.
root@EX4200VC-3a# set vlans data_wired_1a interface wired_access_portsset vlans voip_wired_1a interface wired_voice_ports
the ports for the Wlas require a trunking configuration and require a native VlaN (access_points_1a) be configured in
order for the access point to boot up. When configuring a native VlaN you cannot configure the port VlaN members
with this same VlaN or it will ignore the native VlaN configuration and will not work as expected.
76 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
root@EX4200VC-3a# set interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces interface-range wireless_access_points unit 0 family ethernet-switching native-vlan-id access_points_1a
Configure layer 3 settings.layer 3 configuration for the access switch involves setting a default route in the case of the tested network. In this
case, it points to 10.10.28.1 which is the core switch
Ip interface on the management VlaN.
root@EX4200VC-3a# set routing-options static route 0.0.0.0/0 next-hop 10.10.51.1
Commit the configuration.
root@EX4200VC-3a# commit
Verify IP reachability.Next, you need to verify Ip reachability by “pinging” the core switch management Ip address from the access switch.
this also indicates that trunking is configured properly on the interface and working properly.
root@EX4200VC-3a# run ping 10.10.51.1PING 10.10.51.1 (10.10.51.1): 56 data bytes64 bytes from 10.10.51.1: icmp_seq=0 ttl=64 time=2.254 ms64 bytes from 10.10.51.1: icmp_seq=1 ttl=64 time=1.759 ms64 bytes from 10.10.51.1: icmp_seq=2 ttl=64 time=1.720 ms
Verify VLANs and trunking.to verify that the proper VlaNs are configured for trunking on the ae0 interface, you can use the show ethernet-
switching interfaces ae0 command.
root@EX4200VC-3a> show ethernet-switching interfaces ae0Interface State VLAN members Tag Tagging Blockingae0.0 up access_points_1a 54 tagged unblocked data_wired_1a 12 tagged unblocked data_wireless_1a 36 tagged unblocked management_1a 51 tagged unblocked voip_wired_1a 24 tagged unblocked voip_wireless_1a 42 tagged unblocked
to see what ports are configured for specific VlaNs use the show vlans command.
NOTE: Because of the large number of ports in eX4200VC-3a, the show command output below show the first
VlaN’s output.
root@EX4200VC-3a> show vlansName Tag Interfacesaccess_points_1a 54 ae0.0*, ge-0/0/0.0*, ge-0/0/1.0, ge-0/0/2.0, ge-0/0/3.0, ge-0/0/4.0
Copyright © 2013, Juniper Networks, Inc. 77
Implementation Guide – Vertical Campus
Configure Class of Servicethe basic Class of service configuration used is almost identical across core and access platforms in the tested
network example.
We will configure Class of service on the core eX4500VC-1a. the configuration of Cos is done in five steps the first four
define what the Cos service will look like and the last step applies Cos to specific interfaces.
• Forwarding Classes
• Classifiers
• schedulers
• scheduler-maps
• rewrite rules
• Configuring Interfaces
Configuring forwarding classes.First we will configure the forwarding classes, this step also defines what queues are used as well.
root@EX4200VC-3a# set class-of-service forwarding-classes class control queue-num 7set class-of-service forwarding-classes class voice queue-num 5set class-of-service forwarding-classes class business-app queue-num 3set class-of-service forwarding-classes class server-bulk queue-num 1set class-of-service forwarding-classes class best-effort queue-num 0
Configuring classifiers.Next we will create the classifiers. In the tested network example we are only using DsCp marking for our classification
of traffic. the classifiers map the different DsCp marked packets to the correct queue; if the traffic is not marked, or
marked with a DsCp value not listed, it will be considered best-effort traffic and treated accordingly.
root@EX4200VC-3a# set class-of-service classifiers dscp dscp_trusted forwarding-class control loss-priority low code-points nc1set class-of-service classifiers dscp dscp_trusted forwarding-class control loss-priority low code-points nc2set class-of-service classifiers dscp dscp_trusted forwarding-class voice loss-priority low code-points efset class-of-service classifiers dscp dscp_trusted forwarding-class business-app loss-priority low code-points af21set class-of-service classifiers dscp dscp_trusted forwarding-class server-bulk loss-priority low code-points af11set class-of-service classifiers dscp dscp_trusted forwarding-class best-effort loss-priority low code-points be
Configuring schedulers.We will create schedulers for each type of traffic we want to manage. When the schedulers are defined we also
configure characteristics like shaping/limiting/forwarding rate, how much buffer is allocated and what priority the
traffic has. In the tested network we have configured a couple of similar sounding schedulers; for example: voice-user-
sched and voice-network-sched. the difference between these schedulers is that they are intended to be applied to
different types of interfaces when we create our scheduler maps later. While these currently have the same values, in
the future you may need to change the characteristics of your network ports or access ports to be different from each
other. By configuring schedulers this way from the beginning it makes for less work if changes are needed later.
78 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
root@EX4200VC-3a#set class-of-service schedulers control-network-sched shaping-rate percent 5set class-of-service schedulers control-network-sched buffer-size percent 5set class-of-service schedulers control-network-sched priority strict-highset class-of-service schedulers control-user-sched shaping-rate percent 5 set class-of-service schedulers control-user-sched buffer-size percent 5set class-of-service schedulers control-user-sched priority strict-highset class-of-service schedulers voice-network-sched shaping-rate percent 5 set class-of-service schedulers voice-network-sched buffer-size percent 5 set class-of-service schedulers voice-network-sched priority strict-highset class-of-service schedulers voice-user-sched shaping-rate percent 5 set class-of-service schedulers voice-user-sched buffer-size percent 5 set class-of-service schedulers voice-user-sched priority strict-high set class-of-service schedulers business-sched transmit-rate percent 60 set class-of-service schedulers business-sched buffer-size percent 60set class-of-service schedulers business-sched priority low set class-of-service schedulers server-sched transmit-rate percent 30 set class-of-service schedulers server-sched buffer-size percent 30set class-of-service schedulers server-sched priority lowset class-of-service schedulers be-sched transmit-rate remainder set class-of-service schedulers be-sched buffer-size remainderset class-of-service schedulers be-sched priority low
Configuring scheduler maps.scheduler maps tie the individual schedulers to forwarding classes and queues. Here we have created two scheduler
maps one for network (switch to switch) ports and one for access or host ports. the difference between the two is the
different names for the individual control and voice schedulers used in each scheduler-map.
root@EX4200VC-3a#set class-of-service scheduler-maps network-port-sched forwarding-class control scheduler control-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class voice scheduler voice-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps network-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps network-port-sched forwarding-class best-effort scheduler be-schedset class-of-service scheduler-maps access-port-sched forwarding-class control scheduler control-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class voice scheduler voice-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps access-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps access-port-sched forwarding-class best-effort scheduler be-sched
Copyright © 2013, Juniper Networks, Inc. 79
Implementation Guide – Vertical Campus
Configuring rewrite rules.these rules are used to mark packets appropriately before they exit an interface so that markings are preserved
throughout the network.
root@EX4200VC-3a#set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority low code-point nc1set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority high code-point nc2set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class voice loss-priority low code-point efset class-of-service rewrite-rules dscp rewrite-dscp forwarding-class business-app loss-priority low code-point af21set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class best-effort loss-priority low code-point be
Configuring interfaces.In order for Class of service to actually do anything it must be applied to interfaces. We have two main interface types:
Network ports that connect switches together and user ports that connect to users/hosts. When applying Class of
service to an interface in the tested network example you will configure a scheduler and classifier on network ports or a
scheduler, classifier and rewrite policy on access ports.
Wildcards can also be used to apply Class of service to multiple interfaces with a single command. In this example
wildcards are used to configure all the Gbe ports that use the same Class of service settings. We could do the same
with our laG connections, but we have relatively few of these to configure so we will do so individually.
NOTE: the most specific commands win, so if you have a wildcard policy that is applied to all gigabit ethernet ports
and then you configure one of those ports specifically with different class of service settings they will not conflict;
instead the more specific port configuration will take precedence.
root@EX4200VC-3a#set class-of-service interfaces ge-* scheduler-map access-port-schedset class-of-service interfaces ge-* unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ge-* unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae0 scheduler-map network-port-schedset class-of-service interfaces ae0 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae0 unit 0 rewrite-rules dscp rewrite-dscp
Commit the configuration.
commit
Verifying Class of Service Settingsthere are various commands that can be used to verify portions of the Class of service configuration
Show class-of-service <sub-category>
examples:
show class-of-service scheduler-map
show class-of-service interface <interface name>
show class-of-service rewrite-rule
the most useful Class of service command might be looking at the interface statistics using the command
80 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Show interface <interface name> detail
this command will provide details on what queues are configured on the port ,how many packets were seen, and if any
were dropped.
NOTE: when looking for Class of service statistics using the show interface command you will only see the statistics
on physical interfaces. therefore, when looking at a laG interface you need to run this command for each of the
physical interfaces that make up the link in order to view the Class of service details.
root@EX4200VC-3a> show interfaces ge-0/0/0 detailPhysical interface: ge-0/0/0, Enabled, Physical link is Up Interface index: 377, SNMP ifIndex: 502, Generation: 823 Link-level type: Ethernet, MTU: 1514, Speed: Auto, Duplex: Auto, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x0 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Hold-times : Up 0 ms, Down 0 ms Current address: 78:fe:3d:4e:6c:83, Hardware address: 78:fe:3d:4e:6c:83 Last flapped : 2012-11-09 16:56:38 UTC (00:00:05 ago) Statistics last cleared: 2012-11-07 12:16:51 UTC (2d 04:39 ago) Traffic statistics: Input bytes : 31437476 0 bps Output bytes : 13483181 504 bps Input packets: 127219 0 pps Output packets: 138641 0 pps IPv6 transit statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Egress queues: 8 supported, 5 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 19677 0 1 server-bulk 0 0 0 3 business-app 0 0 0 5 voice 0 0 0 7 control 0 118967 0 Queue number: Mapped forwarding classes 0 best-effort 1 server-bulk 3 business-app 5 voice 7 control Active alarms : None Active defects : None Interface transmit statistics: Disabled
Logical interface ge-0/0/0.0 (Index 68) (SNMP ifIndex 503) (Generation 349) Flags: SNMP-Traps 0x0 Encapsulation: ENET2 Traffic statistics: Input bytes : 2302688 Output bytes : 13055885 Input packets: 9641 Output packets: 119040 Local statistics: Input bytes : 2302688 Output bytes : 13055885 Input packets: 9641 Output packets: 119040 Transit statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps Protocol eth-switch, Generation: 395, Route table: 0 Flags: Trunk-Mode
Copyright © 2013, Juniper Networks, Inc. 81
Implementation Guide – Vertical Campus
Building A: Configuring EX3300 Access Switch
WLA
WLA
WLA
WLA
WLA
WLA
WLA
BUILDING A BUILDING B
EX4200VC-2a
EX3300VC-1a
EX4200VC-3a
LAGLAG
LAGEX8200VC-1b
SRX SeriesCluster
WLCCluster
INTERNET
EX6200-1b
App Servers
Centralized DHCPand other services
EX4500VC-1a LAG
LAG
You are Here
Figure 15: Configuration of EX3300VC-1a
the setup and configuration for the eX3300 access switches share some common elements with both the dedicated
and extended mode of the eX4200. the difference is that unlike the eX4200 series switches, the eX3300 does not
have dedicated Virtual Chassis ports. Instead, the eX3300 has four fixed 10Gbe ports and two of those are configured
by default to act as VCpe ports. You can build a Virtual Chassis much like you would with the eX4200 – by connecting
the pre-configured VCpe ports together using 10Gbe ports (typically DaC cables).
If an eX3300 extended mode Virtual Chassis is desired (spanning greater distance, consolidating wiring closets, and
such) you simply use different optics to support the distance required and connect the switches as you would in a
normal extended Virtual Chassis setup.
For additional information on the eX3300, please follow this link.
Procedure overview 1. Configure global configuration items
2. Configure the Virtual Chassis
• Identify the type of Virtual Chassis
• pre-provision the Virtual Chassis
• perform the Virtual Chassis type-specific configuration
• perform the Virtual Chassis standard configuration
3. Configure layer 2 settings
4. Configure layer 3 settings
5. Configure Class of service
82 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Configuring Global Settings for the Access Switchto configure global settings on the access switch:
Connect to the Console Port of the EX3300 Switch (Setting: s9600, 8, 1, none).press enter. the following prompt appears.
Amnesiac (ttyu0)login
Log in as Root and Press Enter.Because no password is configured, you are not prompted for one. Note the release of Junos and upgrade if required.
login: rootLogging to master.– – – JUNOS 12.1r1.9 built 2011-11-15 11:14:01 UTCroot@:RE:0%
Type cli at the % Prompt
root@:RE:0% cli{master:0}root>
You should now be at the >prompt.
Configure the date and time in the format: YYYYMMDDhhmm.ss.set date 201201220830.00
Enter configuration mode by typing configure or edit.
root> configureEntering configuration mode{master:0}[edit]root#
You should now be at the # prompt and ready to start configuring the switch.
Configure the password.
root# set system root-authentication plain-text-passwordNew password:*******Retype new password:*******{master:0}[edit]root#
Configure the time zone.
root# set system time-zone America/Los_Angeles
Configure the hostname.
root# set system host-name EX3300VC-1a
Configure the management and VME interface (optional).
set interfaces vme unit 0 family inet address 10.94.188.101/24
Copyright © 2013, Juniper Networks, Inc. 83
Implementation Guide – Vertical Campus
Configure management access
root@EX3300VC-1a# set system services web-management https system-generated-certificate set system services sshdelete system services web-management httpdelete system services telnet
Configure DNS
root@EX3300VC-1a# set system name-server 10.10.24.100set system domain-name xyzcompany.com
Configuring an EX3300 Virtual Chassisto configure a Virtual Chassis for the access switch in dedicated mode:
Identify the Virtual Chassis type
In the case of the tested network, access switch eX3300 is a dedicated mode Virtual Chassis using only the VCp ports
to form the switching fabric interconnect. all switches are the same model.
Configure a pre-provisioned Virtual Chassisto pre-provision a Virtual Chassis you need to identify the serial numbers of each device that will be part of the Virtual
Chassis, the device function, and the order in which you want each switch to be placed. later, when all of the switches
are connected and powered up, they will automatically be assigned the proper function and slot. make sure you pay
attention to the serial numbers and positioning of each switch when you connect them together.
By default, the eX series devices automatically form a Virtual Chassis, but because the ordering is nondeterministic,
the switches may not be numbered sequentially. For more information about Virtual Chassis, see appendix a and B, or
the Day One book, Configuring EX Series Ethernet Switches.
root@EX3300VC-1a# set virtual-chassis preprovisionedset virtual-chassis member 0 role line-cardset virtual-chassis member 0 serial-number GE0211392919set virtual-chassis member 1 role line-cardset virtual-chassis member 1 serial-number GE0211371778set virtual-chassis member 2 role routing-engineset virtual-chassis member 2 serial-number GB0211501128set virtual-chassis member 4 role line-cardset virtual-chassis member 4 serial-number GB0211501285set virtual-chassis member 5 role line-cardset virtual-chassis member 5 serial-number GB0211494458set virtual-chassis member 3 role routing-engineset virtual-chassis member 3 serial-number GA0212039606
Configure Specific Virtual Chassis CommandsNOTE: split-detection is enabled by default, but because all devices are located in the same room and have dual
redundant connections, an accidental chassis split is unlikely. the eX3300 series switches use an extended Virtual
Chassis type we recommend keeping split-detection enabled. If you want to disable split detection it can be done by
issuing the command “set virtual-chassis no-split-detection”. For Virtual Chassis composed of only two devices we
recommend disabling split-detection. If you are not familiar with how split-detection works please review the section
on Virtual Chassis split-detection located in appendix a for more details.
using the VCpe ports on the front of the units, cable each the eX series switches together. When all of the switches are
cabled properly, power up the remaining switches. Once all the switches are powered up, verify that all of the members
are active by running the show virtual-chassis command.
84 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
root@EX3300VC-1a> show virtual-chassis
Preprovisioned Virtual ChassisVirtual Chassis ID: 897e.c906.f943Virtual Chassis Mode: Enabled Mstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt GE0211392919 ex3300-24p 0 Linecard NA 5 vcp-255/1/2 1 vcp-255/1/31 (FPC 1) Prsnt GE0211371778 ex3300-24p 0 Linecard NA 0 vcp-255/1/2 2 vcp-255/1/32 (FPC 2) Prsnt GB0211501128 ex3300-48p 129 Master* NA 1 vcp-255/1/2 3 vcp-255/1/33 (FPC 3) Prsnt GA0212039606 ex3300-48t 129 Backup NA 2 vcp-255/1/2 4 vcp-255/1/34 (FPC 4) Prsnt GB0211501285 ex3300-48p 0 Linecard NA 3 vcp-255/1/2 5 vcp-255/1/35 (FPC 5) Prsnt GB0211494458 ex3300-48p 0 Linecard NA 4 vcp-255/1/2 0 vcp-255/1/3
Configure global Virtual Chassis commands.
root@EX3300VC-1a# set system commit synchronizeset ethernet-switching-options nonstop-bridgingset chassis redundancy graceful-switchover
Commit the configuration.
root@EX3300VC-1a# commit
Configure resilient dual-boot partitions.NOTE: It is important to run this step as it improves the resiliency of the system in the case of primary boot partition
failure. this step creates a backup copy of the operating system and is highly recommended. this process takes
approximately 5 minutes for each re or member.
request system snapshot slice alternate all-members
Configure default settings.
the following commands show items that should be enabled by default in the configuration. You may wish to review
and verify that these setting are desired for your specific network.
root@EX4200VC-3a# set protocols igmp-snooping vlan allset protocols rstpset protocols lldp interface allset protocols lldp-med interface allset poe interface allset ethernet-switching-options storm-control interface all
Copyright © 2013, Juniper Networks, Inc. 85
Implementation Guide – Vertical Campus
Configuring Layer 2 Settings for EX3300 Virtual Chassisto configure layer 2 parameters and settings on the access switch in dedicated mode:
Configure VLANs.the eX3300VC-1a chassis has the following VlaNs assigned: data_wired_1a, data_wireless_1a, voip_wired_1a, voip_
wireless_1a, management_1a. It has only one Ip interface defined, which is on the management_1a VlaN.
root@EX3300VC-1a# set vlans access_points_1a vlan-id 54set vlans data_wired_1a vlan-id 12set vlans data_wireless_1a vlan-id 36set vlans voip_wired_1a vlan-id 24set vlans voip_wireless_1a vlan-id 42set vlans management_1a vlan-id 51
Configure interfaces.We need to configure one Ip interface on the management VlaN.
root@EX3300VC-1a# set interfaces vlan unit 51 family inet address 10.10.51.6/24
Configure LAG (aggregated Ethernet) ports.the eX3300 chassis has only one laG port configured to connect to the core building switch. Junos Os requires that
you configure the number of laG interfaces you want to use before you begin configuring the laG interfaces. We
suggest picking a number slightly larger than what you need in case you add more laG interfaces later. You can change
this value in the future.
Because we need one laG interface for this configuration, we will configure the eX3300 chassis with two in case we
add another laG connection later.
root@EX3300VC-1a# set chassis aggregated-devices ethernet device-count 2
there are four 10-Gigabit ethernet ports on the eX3300 series however, only two of those are pre-configured as VCpe
connections. the remaining two can be used as uplinks. the ports are numbered as xe-0/1/0 through xe-0/1/3. By
default only xe-0/1/0 and xe-0/1/1 are available as uplinks, while the remaining two ports are configured to act as
VCpe ports.
We will use ports xe-0/1/0 and xe-5/1/0 for our laG connection.
First, we need to remove any port-specific configuration on the physical ports we want to aggregate. By default,
interfaces have unit 0 defined, but this is not allowed on an interface that is part of an aggregate interface, because it
would conflict with unit 0 on the logical aggregate interface.
root@EX3300VC-1a# delete interfaces xe-0/1/0 unit 0delete interfaces xe-5/1/0 unit 0
set interfaces xe-0/1/0 ether-options 802.3ad ae0set interfaces xe-5/1/0 ether-options 802.3ad ae0
Next, we need to add laCp to each laG interface to provide some health checking.
NOTE: laCp must be configured on both sides for the laG port to become active.
root@EX3300VC-1a# set interfaces ae0 aggregated-ether-options lacp activeset interfaces ae0 aggregated-ether-options lacp periodic slow
Disable rstp on laG connections to access switches.
86 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Because we do not use rstp as a topology protocol, we can disable it on the laG ports going to our access switches.
Disabling rstp also reduces potential convergence times in case a laG member fails, because fewer protocols need to
converge.
NOTE: Note all access switches have rstp enabled locally for loop protection.
root@EX3300VC-1a# set protocols rstp interface ae0.0 disable
Configure the trunk port and VLAN.Next, we need to configure the laG port as a trunk and add the VlaNs that will be supported going to the core switch.
to enable the laG port as a trunk port, use the set interfaces command.
root@EX3300VC-1a# set interfaces ae0 unit 0 family ethernet-switching port-mode trunk
Configure VLANs on trunk ports.VlaN configuration for ae0, which connects to: eX4500VC-1a switch, data_wired_1a, voip_wired_1a, data_wireless_1a,
voip_wireless_1a, the management_1a VlaN for switch management and access_points_1a for the Wlas to reside.
VlaNs can be added in a single statement surrounded by [] or can be added one line at a time. In this example we will
show each command.
set interfaces ae0 unit 0 family ethernet-switching port-mode trunkset interfaces ae0 unit 0 family ethernet-switching vlan members data_wired_1aset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wired_1aset interfaces ae0 unit 0 family ethernet-switching vlan members access_points_1aset interfaces ae0 unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces ae0 unit 0 family ethernet-switching vlan members management_1a
Commit the configuration.
root@EX3300VC-1a# commit
Connect the LAG connections to the core switch using the show lldp neighbors command to verify that the connection is up and you can see the other side of the connection.
root@EX3300VC-1a# run show lldp neighborsLocal Interface Parent Interface Chassis Id Port info System Namexe-0/1/0.0 ae0.0 a8:d0:e5:b5:0f:80 xe-0/0/6.0 EX4500VC-1axe-5/1/0.0 ae0.0 a8:d0:e5:b5:0f:80 xe-1/0/6.0 EX4500VC-1a
Run the show lacp interfaces command to verify that LACP is running.
root@EX3300VC-1a# run show lacp interfacesAggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-5/1/0 Actor No No Yes Yes Yes Yes Slow Active xe-5/1/0 Partner No No Yes Yes Yes Yes Slow Active xe-0/1/0 Actor No No Yes Yes Yes Yes Slow Active xe-0/1/0 Partner No No Yes Yes Yes Yes Slow Active LACP protocol: Receive State Transmit State Mux State xe-5/1/0 Current Slow periodic Collecting distributing xe-0/1/0 Current Slow periodic Collecting distributing
Copyright © 2013, Juniper Networks, Inc. 87
Implementation Guide – Vertical Campus
Configure secure access port features.We recommend configuring these basic security features on the majority of the VlaNs on access switches. We need to
enable these features on the data_wired_1a and voip_wired_1a VlaNs.
You may notice that we do not enable these features on all the VlaNs. some VlaNs have a greater tendency to have
statically configured devices or may not require this feature. each device with a static Ip address attached to a port on
a VlaN – with these features enabled – requires a static port configuration with an Ip address and a maC address in
order to communicate with the rest of the network. If required, this additional level of security can be configured, but it
will add some overhead when network changes are made.
root@EX3300-vc2# set ethernet-switching-options secure-access-port vlan data_wired_1a arp-inspectionset ethernet-switching-options secure-access-port vlan data_wired_1a examine-dhcpset ethernet-switching-options secure-access-port vlan data_wired_1a ip-source-guardset ethernet-switching-options secure-access-port vlan voip_wired_1a arp-inspectionset ethernet-switching-options secure-access-port vlan voip_wired_1a examine-dhcpset ethernet-switching-options secure-access-port vlan voip_wired_1a ip-source-guard
For more information on the secure access port features see Day One book, Configuring EX Series Ethernet Switches.
Junos Os supports a feature called interface-range, which allows you to group several interfaces together so that you
can configure the entire group using one statement. this can be helpful when you have many similar ports that share
much of the same configuration. this statement can be used to simplify configurations.
With the access switches in the tested network, each member in the Virtual Chassis is divided up by port type:
• ports 0–4 are reserved for wireless access points
• ports 5–26 are reserved for data.
• ports 27–47 reserved for voice.
since these ports are typically configured identically, you use the interface-range statement to simplify operations and
create three different port groups wireless_access_points, wired_data_ports and wired_voice_ports as listed in table 10.
Table 12: EX3300 VLAN IP Address Mapping
VLAN-ID VLAN Name Subnet Port Range Name
12 data_wired_1a 10.10.8.0/22 wired_access_ports
24 voip_wired_1a 10.10.24.0/22 wired_voice_ports
54 access_points_1a 10.10.54.0/24 wireless_access_points
root@EX3300VC-1a# set interfaces interface-range wired_access_ports member-range ge-0/0/5 to ge-0/0/26set interfaces interface-range wired_voice_ports member-range ge-0/0/27 to ge-0/0/47set interfaces interface-range wireless_access_points member-range ge-0/0/0 to ge-0/0/4
Set the port mode.We need to set the port mode to access. Because we have used the interface-ranges statement, we only need to set
the port mode at the interface-range level, instead of editing every port.
root@EX3300VC-1a# set interfaces interface-range wired_access_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wired_voice_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wireless_access_points unit 0 family ethernet-switching port-mode trunk
88 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Configure port to VLAN.
root@EX3300-vc2# set vlans data_wired_1a interface wired_access_portsset vlans voip_wired_1a interface wired_voice_ports
the ports for the Wlas require a trunking configuration and require a native VlaN (access_points_1a) be configured in
order for the access point to boot up. When configuring a native VlaN you cannot configure the port VlaN members
with this same VlaN or it will ignore the native VlaN configuration and will not work as expected.
root@EX3300VC-1a# set interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces interface-range wireless_access_points unit 0 family ethernet-switching native-vlan-id access_points_1a
Configure layer 3 settings.layer 3 configuration for the access switch involves setting a default route in the case of the tested network. In this
case, it points to 10.10.28.1 which is the core switch Ip interface on the management_1a VlaN
set routing-options static route 0.0.0.0/0 next-hop 10.10.51.1
Commit the configuration.
commit
Verify IP reachability.Next, you need to verify Ip reachability by “pinging” the core switch management Ip address from the access switch.
this also indicates that trunking is configured properly on the interface and working properly.
root@EX3300VC-1a> ping 10.10.51.1PING 10.10.51.1 (10.10.51.1): 56 data bytes64 bytes from 10.10.51.1: icmp_seq=0 ttl=64 time=4.240 ms64 bytes from 10.10.51.1: icmp_seq=1 ttl=64 time=3.078 ms
Verify VLANs and trunking.to verify that the proper VlaNs are configured for trunking on the ae0 interface, you can use the show ethernet-
switching interfaces ae0 command.
root@EX3300VC-1a# run show ethernet-switching interfaces ae0Interface State VLAN members Tag Tagging Blockingae0.0 up access_points_1a 54 tagged unblocked data_wired_1a 12 tagged unblocked data_wireless_1a 36 tagged unblocked management_1a 51 tagged unblocked voip_wired_1a 24 tagged unblocked voip_wireless_1a 42 tagged unblocked
to see what ports are configured for specific VlaNs use the show vlans command.
NOTE: Because of the large number of ports in eX4200VC-3a, the show command output below show the first VlaN’s
output.
root@EX3300VC-1a> show vlansName Tag Interfacesaccess_points_1a 54 ae0.0*, ge-0/0/0.0*, ge-0/0/1.0, ge-0/0/2.0, ge-0/0/3.0, ge-0/0/4.0, ge-5/0/0.0*
Copyright © 2013, Juniper Networks, Inc. 89
Implementation Guide – Vertical Campus
Configure Class of Servicethe basic Class of service configuration used is almost identical across core and access platforms in the tested
network example.
We will configure Class of service on the access switch eX3300VC-1a. the configuration of Cos is done in five steps
the first four define what the Cos service will look like and the last step applies Cos to specific interfaces.
• Forwarding Classes
• Classifiers
• schedulers
• scheduler-maps
• rewrite rules
• Configuring Interfaces
Configuring forwarding classes.First we will configure the forwarding classes, this step also defines what queues are used as well.
root@EX3300VC-1a# set class-of-service forwarding-classes class control queue-num 7set class-of-service forwarding-classes class voice queue-num 5set class-of-service forwarding-classes class business-app queue-num 3set class-of-service forwarding-classes class server-bulk queue-num 1set class-of-service forwarding-classes class best-effort queue-num 0
Configuring classifiers.Next we will create the classifiers. In the tested network example we are only using DsCp marking for our classification
of traffic. the classifiers map the different DsCp marked packets to the correct queue, if the traffic is not marked or
marked with a DsCp value not listed it will be considered best-effort traffic and treated accordingly.
root@EX3300VC-1a# set class-of-service classifiers dscp dscp_trusted forwarding-class control loss-priority low code-points nc1set class-of-service classifiers dscp dscp_trusted forwarding-class control loss-priority low code-points nc2set class-of-service classifiers dscp dscp_trusted forwarding-class voice loss-priority low code-points efset class-of-service classifiers dscp dscp_trusted forwarding-class business-app loss-priority low code-points af21set class-of-service classifiers dscp dscp_trusted forwarding-class server-bulk loss-priority low code-points af11set class-of-service classifiers dscp dscp_trusted forwarding-class best-effort loss-priority low code-points be
90 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Configuring schedulers.We will create schedulers for each type of traffic we want to manage. When we define the schedulers we also configure
characteristics like shaping/limiting/forwarding rate, how much buffer is allocated and what priority the traffic has.
In the tested network we have configured a few similar sounding schedulers. For example: voice-user-sched and
voice-network-sched. the difference between these schedulers is they are intended to be applied to different types
of interfaces when we create our scheduler maps later. While these currently have the same values, this configuration
allows granular changes to the characteristics of your network or access ports to diverge. Configuring schedulers this
way from the beginning makes less work if changes are needed later.
root@EX3300VC-1a# set class-of-service schedulers control-network-sched shaping-rate percent 5set class-of-service schedulers control-network-sched buffer-size percent 5set class-of-service schedulers control-network-sched priority strict-highset class-of-service schedulers control-user-sched shaping-rate percent 5 set class-of-service schedulers control-user-sched buffer-size percent 5set class-of-service schedulers control-user-sched priority strict-highset class-of-service schedulers voice-network-sched shaping-rate percent 5 set class-of-service schedulers voice-network-sched buffer-size percent 5 set class-of-service schedulers voice-network-sched priority strict-highset class-of-service schedulers voice-user-sched shaping-rate percent 5 set class-of-service schedulers voice-user-sched buffer-size percent 5 set class-of-service schedulers voice-user-sched priority strict-high set class-of-service schedulers business-sched transmit-rate percent 60 set class-of-service schedulers business-sched buffer-size percent 60set class-of-service schedulers business-sched priority low set class-of-service schedulers server-sched transmit-rate percent 30 set class-of-service schedulers server-sched buffer-size percent 30set class-of-service schedulers server-sched priority lowset class-of-service schedulers be-sched transmit-rate remainder set class-of-service schedulers be-sched buffer-size remainderset class-of-service schedulers be-sched priority low
Configuring scheduler maps.scheduler maps tie the individual schedulers to forwarding classes and queues. Here we have created two scheduler
maps one for network (switch to switch) ports and one for access or host ports. the difference between the two is the
different names for the individual control and voice schedulers used in each scheduler-map.
root@EX3300VC-1a# set class-of-service scheduler-maps network-port-sched forwarding-class control scheduler control-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class voice scheduler voice-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps network-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps network-port-sched forwarding-class best-effort scheduler be-schedset class-of-service scheduler-maps access-port-sched forwarding-class control scheduler control-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class voice scheduler voice-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps access-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps access-port-sched forwarding-class best-effort scheduler be-sched
Copyright © 2013, Juniper Networks, Inc. 91
Implementation Guide – Vertical Campus
Configuring rewrite rules.rewrite rules are used to mark packets appropriately before egress into an interface so that markings are preserved
throughout the network.
root@EX3300VC-1a# set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority low code-point nc1set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority high code-point nc2set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class voice loss-priority low code-point efset class-of-service rewrite-rules dscp rewrite-dscp forwarding-class business-app loss-priority low code-point af21set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class best-effort loss-priority low code-point be
Configuring interfaces.In order for Class of service to actually do anything it must be applied to interfaces. We have two main interface types:
Network ports that connect switches together and ports that connect users/hosts. When applying Class of service
to an interface in the tested network example you will configure a scheduler and classifier on network ports or a
scheduler, classifier and rewrite policy on access ports.
You can also use wildcards to apply Class of service to multiple interfaces with a single command. For example here
we have used wildcards to configure all the Gbe ports use the same Class of service settings. We could do the same
with our laG connections, but we have relatively few of these to configure so we will do so individually.
NOTE: the most specific commands win, so if you have a wildcard policy that is applied to all gigabit ethernet ports
and then you configure one of those ports specifically with different class of service settings they will not conflict;
instead the more specific port configuration will take precedence.
root@EX3300VC-1a# set class-of-service interfaces ge-* scheduler-map access-port-schedset class-of-service interfaces ge-* unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ge-* unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae0 scheduler-map network-port-schedset class-of-service interfaces ae0 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae0 unit 0 rewrite-rules dscp rewrite-dscp
Commit the configuration.
commit
Verifying class of service settings.there are various commands that can be used to verify portions of the Class of service configuration,
Show class-of-service <sub-category>
examples:
show class-of-service scheduler-map
show class-of-service interface <interface name>
show class-of-service rewrite-rule
the most useful Class of service command might be looking at the interface statistics using the command
Show interface <interface name> detail
92 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
this command will provide details on what queues are configured on the port and how many packets were seen and if
any were dropped.
NOTE: when looking for Class of service statistics using the show interface command you can only see the statistics on
physical interfaces so when looking at a laG interface you need to run this command for each of the physical interfaces
that make up the link in order to view the Class of service details.
root@EX3300VC-1a> show interfaces ge-0/0/0 detailPhysical interface: ge-0/0/0, Enabled, Physical link is Up Interface index: 450, SNMP ifIndex: 504, Generation: 501 Link-level type: Ethernet, MTU: 1514, Speed: Auto, Duplex: Auto, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x4000 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Hold-times : Up 0 ms, Down 0 ms Current address: 88:e0:f3:6e:c1:03, Hardware address: 88:e0:f3:6e:c1:03 Last flapped : 2012-11-05 10:54:05 GMT-8 (4d 06:02 ago) Statistics last cleared: 2012-11-07 12:01:39 GMT-8 (2d 04:55 ago) Traffic statistics: Input bytes : 46419257 3280 bps Output bytes : 28092328 3792 bps Input packets: 186168 4 pps Output packets: 276847 5 pps IPv6 transit statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Egress queues: 8 supported, 5 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 169799 0 1 server-bulk 0 0 0 3 business-app 0 0 0 5 voice 0 0 0 7 control 0 107047 2 Queue number: Mapped forwarding classes 0 best-effort 1 server-bulk 3 business-app 5 voice 7 control Active alarms : None Active defects : None Interface transmit statistics: Disabled
Logical interface ge-0/0/0.0 (Index 90) (SNMP ifIndex 505) (Generation 202) Flags: SNMP-Traps 0xc0004000 Encapsulation: ENET2 Traffic statistics: Input bytes : 866374 Output bytes : 12880915 Input packets: 6631 Output packets: 107049 Local statistics: Input bytes : 866374 Output bytes : 12880915 Input packets: 6631 Output packets: 107049 Transit statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps Protocol eth-switch, Generation: 232, Route table: 0 Flags: Trunk-Mode
Copyright © 2013, Juniper Networks, Inc. 93
Implementation Guide – Vertical Campus
Building A: Configuring EX4200 Dedicated Mode Access switch
WLA
WLA
WLA
WLA
WLA
WLA
WLA
BUILDING A BUILDING B
EX4200VC-2a
EX3300VC-1a
EX4200VC-3a
LAGLAG
LAGEX8200VC-1b
SRX SeriesCluster
WLCCluster
INTERNET
EX6200-1b
App Servers
Centralized DHCPand other services
EX4500VC-1a LAG
LAG
You are Here
Figure 16: EX4200VC-2a Configuration
Procedure overview 1. Configure global configuration items
2. Configure the Virtual Chassis
• Identify the type of Virtual Chassis
• pre-provision the Virtual Chassis
• perform the Virtual Chassis type-specific configuration
• perform the Virtual Chassis standard configuration
3. Configure layer 2 settings
4. Configure layer 3 settings
Configuring Global Settings for the Switchto configure global settings on the switch:
Connect to the Console Port of the EX4200 Switch (Setting: s9600, 8, 1, none).press enter. the following prompt appears.
Amnesiac (ttyu0)login
Log in as root and Press Enter.Because no password is configured, you are not prompted for one. Note the version of Junos and update if needed.
login: rootLogging to master.– – – JUNOS 12.1r1.9 built 2011-11-15 11:14:01 UTCroot@:RE:0%
94 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Type cli at the % Prompt
root@:RE:0% cli{master:0}root>
You should now be at the >prompt.
Configure the date and time in the format: YYYYMMDDhhmm.ss.
set date 201201220830.00
Enter configuration mode by typing configure or edit.
root> configureEntering configuration mode{master:0}[edit]root#
You should now be at the # prompt and ready to start configuring the switch.
Configure the password.
root# set system root-authentication plain-text-passwordNew password:*******Retype new password:*******{master:0}[edit]root#
Configure the time zone.
root# set system time-zone America/Los_Angeles
Configure the hostname.
root# set system host-name EX4200VC-2a
Configure the management and VME interface (optional)
set interfaces vme unit 0 family inet address 10.94.188.101/24
Configure management access.
root@EX4200VC-2a# set system services web-management https system-generated-certificateset system services sshdelete system services web-management httpdelete system services telnet
Configure DNS.
root@EX4200VC-2a# set system name-server 10.10.24.100set system domain-name xyzcompany.com
Copyright © 2013, Juniper Networks, Inc. 95
Implementation Guide – Vertical Campus
Configuring a Dedicated Mode Virtual Chassisto configure a Virtual Chassis for the access switch in dedicated mode:
Identify the Virtual Chassis type.In the case of the tested network, access switch eX4200VC-2a is a dedicated mode Virtual Chassis using only the VCp
ports to form the switching fabric interconnect. Configure a pre-provisioned Virtual Chassis.
to pre-provision a Virtual Chassis you need to identify the serial numbers of each device that will be part of the Virtual
Chassis, the device function, and the order in which you want each switch to be placed. later, when all of the switches
are connected and powered up, they will automatically be assigned the proper function and slot. make sure you pay
attention to the serial numbers and ordering of each switch when you connect them together later.
By default, the eX series devices automatically form a Virtual Chassis, but because the ordering is nondeterministic,
the switches may not be numbered sequentially. For more information about Virtual Chassis, see “Virtual Chassis” on
page 93, or the Day One book, Configuring EX Series Ethernet Switches.
root@EX4200VC-2a# set virtual-chassis preprovisionedset virtual-chassis member 0 role line-cardset virtual-chassis member 0 serial-number BP0211386965set virtual-chassis member 1 role line-cardset virtual-chassis member 1 serial-number BP0211386975set virtual-chassis member 2 role line-cardset virtual-chassis member 2 serial-number BP0211386950set virtual-chassis member 3 role routing-engineset virtual-chassis member 3 serial-number BP0211386957set virtual-chassis member 4 role routing-engineset virtual-chassis member 4 serial-number BP0211386944set virtual-chassis member 5 role line-cardset virtual-chassis member 5 serial-number FP0211490429set virtual-chassis member 6 role line-cardset virtual-chassis member 6 serial-number FP0211490761set virtual-chassis member 7 role line-cardset virtual-chassis member 7 serial-number FP0211490744
Configure specific Virtual Chassis commands.NOTE: by default split-detection is enabled, but because all devices are located in the same room, and there are dual
redundant connections between devices, an accidental chassis split is unlikely. split detection can be disabled by
issuing the command “set virtual-chassis no-split-detection”. If you are making a Virtual Chassis with only two devices
we recommend disabling split-detection. If you are not familiar with how split-detection works please review the
section on Virtual Chassis split-detection located in appendix a for more details.
using the VCp ports at the back of the units, cable each pair of eX series switches together. When all of the switches
are cabled properly, power up the remaining switch. Once all the switches are powered up, verify that all of the
members are active by running the Commit the configuration show virtual-chassis command.
96 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
root@EX4200VC-2a> show virtual-chassis
Preprovisioned Virtual ChassisVirtual Chassis ID: a2e4.9152.3afeVirtual Chassis Mode: Enabled Mstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt BP0211386965 ex4200-48t 0 Linecard N 7 vcp-0 1 vcp-11 (FPC 1) Prsnt BP0211386975 ex4200-48t 0 Linecard N 0 vcp-0 2 vcp-12 (FPC 2) Prsnt BP0211386950 ex4200-48t 0 Linecard N 1 vcp-0 3 vcp-13 (FPC 3) Prsnt BP0211386957 ex4200-48t 129 Backup N 2 vcp-0 4 vcp-14 (FPC 4) Prsnt BP0211386944 ex4200-48t 129 Master* N 3 vcp-0 5 vcp-15 (FPC 5) Prsnt FP0211490429 ex4200-48px 0 Linecard N 4 vcp-0 6 vcp-16 (FPC 6) Prsnt FP0211490761 ex4200-48px 0 Linecard N 5 vcp-0 7 vcp-17 (FPC 7) Prsnt FP0211490744 ex4200-48px 0 Linecard N 6 vcp-0 0 vcp-1 1
Configure global Virtual Chassis commands.
root@EX4200VC-2a# set system commit synchronizeset ethernet-switching-options nonstop-bridgingset chassis redundancy graceful-switchover
Commit the configuration.
root@EX4200VC-2a# commit
Configure resilient dual-boot partitionsNOte: It is important to run this step as it improves the resiliency of the system in the case of primary boot partition
failure. this step creates a backup copy of the operating system and is highly recommended. this process takes
approximately 5 minutes for each re or member.
request system snapshot slice alternate all-members
Configure default settings.the following commands show items that should be enabled by default in the configuration. You may wish to review
and verify that these setting are desired for your specific network.
root@EX4200VC-2a# set protocols igmp-snooping vlan allset protocols rstpset protocols lldp interface allset protocols lldp-med interface allset poe interface allset ethernet-switching-options storm-control interface all
Copyright © 2013, Juniper Networks, Inc. 97
Implementation Guide – Vertical Campus
Configuring Layer 2 Settings for EX4200 Dedicated Virtual Chassisto configure layer 2 parameters and settings on the access switch in dedicated mode:
Configure VLANs.the eX4200VC-2a chassis has the following VlaNs assigned: data_wired_1a, data_wireless_1a, voip_wired_1a, voip_
wireless_1a, management_1a. It has only one Ip interface defined, which is on the management_1a VlaN.
root@EX4200VC-2a# set vlans access_points_1a vlan-id 54set vlans data_wired_1a vlan-id 12set vlans data_wireless_1a vlan-id 36set vlans voip_wired_1a vlan-id 24set vlans voip_wireless_1a vlan-id 42set vlans management_1a vlan-id 51
Configure interfaces.We need to configure one Ip interface on the management VlaN.
root@EX4200VC-2a# set interfaces vlan unit 51 family inet address 10.10.51.8/24
Configure LAG (aggregated Ethernet) ports.
the eX4200VC-2a chassis has only one laG port configured to connect to the core switch. Junos Os requires that you
configure the number of laG interfaces you want to use before you begin configuring the laG interfaces. We suggest
picking a number slightly larger than what you need in case you add more laG interfaces later. You can change this
value in the future.
Because we need one laG interface for this configuration, we will configure the eX4200VC-2a chassis with two in case
we add another laG connection later.
root@EX4200VC-2a# set chassis aggregated-devices ethernet device-count 2
the 10-Gigabit ethernet ports on the eX4200 series are only available using the uplink module ports. We have uplink
modules installed on switch member 0 and 7. We need to configure the laG connection on switch members 0 and 7,
using ports xe-0/1/0 and xe-7/1/0.
First, we need to remove any port-specific configuration on the physical ports we want to aggregate. By default,
interfaces have unit 0 defined, but this is not allowed on an interface that is part of an aggregate interface, because it
would conflict with unit 0 on the logical aggregate interface.
root@EX4200VC-2a# delete interfaces xe-0/1/0 unit 0delete interfaces xe-7/1/0 unit 0
root@EX4200VC-2a# set interfaces xe-0/1/0 ether-options 802.3ad ae0set interfaces xe-7/1/0 ether-options 802.3ad ae0
Next, we need to add laCp to each laG interface to provide some health checking.
NOTE: laCp must be configured on both sides for the laG port to become active.
root@EX4200VC-2a# set interfaces ae0 aggregated-ether-options lacp activeset interfaces ae0 aggregated-ether-options lacp periodic slow
Disable RSTP on LAG connections to access switches.Because we do not use rstp as a topology protocol, we can disable it on the laG ports going to our access switches.
Disabling rstp also reduces potential convergence times in case a laG member fails, because fewer protocols need to
converge.
98 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
NOTE: Note all access switches have rstp enabled locally for loop protection.
root@EX4200VC-2a# set protocols rstp interface ae0.0 disable
Configure the trunk port and VLAN.Next, we need to configure the laG port as a trunk and add the VlaNs that will be supported going to the core switch.
to enable the laG port as a trunk port, use the set interfaces command.
root@EX4200VC-2a# set interfaces ae0 unit 0 family ethernet-switching port-mode trunk
Configure VLANs on trunk ports.VlaN configuration for ae0, which connects to the eX4500VC-1a switch, data_wired_1a, voip_wired_1a, data_
wireless_1a, voip_wireless_1a, the management_1a VlaN for switch management and access_points_1a for the Wlas to
reside. VlaNs can be added in a single statement surrounded by [] or can be added one line at a time. In this example
we will show each command.
set interfaces ae0 unit 0 family ethernet-switching vlan members data_wired_1aset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wired_1aset interfaces ae0 unit 0 family ethernet-switching vlan members access_points_1aset interfaces ae0 unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces ae0 unit 0 family ethernet-switching vlan members management_1a
Commit the configuration.
root@EX4200VC-2a# commit
Connect the LAG connections to the core switch. the show lldp neighbors command will verify that the connection is up and that you can see the other side of the
connection.
root@EX4200VC-2a> show lldp neighborsLocal Interface Parent Interface Chassis Id Port info System Namexe-0/1/0.0 ae0.0 a8:d0:e5:b5:0f:80 xe-0/0/8.0 EX4500VC-1axe-7/1/0.0 ae0.0 a8:d0:e5:b5:0f:80 xe-1/0/8.0 EX4500VC-1a
Run the show lacp interfaces command to verify that LACP is running.
root@EX4200VC-2a> show lacp interfacesAggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-0/1/0 Actor No No Yes Yes Yes Yes Slow Active xe-0/1/0 Partner No No Yes Yes Yes Yes Slow Active xe-7/1/0 Actor No No Yes Yes Yes Yes Slow Active xe-7/1/0 Partner No No Yes Yes Yes Yes Slow Active LACP protocol: Receive State Transmit State Mux State xe-0/1/0 Current Slow periodic Collecting distributing xe-7/1/0 Current Slow periodic Collecting distributing
Configure secure access port features.We recommend configuring these basic security features on the majority of the VlaNs on access switches. We need to
enable these features on the data_wired_1a and data_wireless_1a VlaNs.
You may notice that we do not enable these features on all the VlaNs. some VlaNs are more likely to have statically
configured devices or may not require this feature. each device with a static Ip address attached to a port on a VlaN
– with these features enabled – requires a static port configuration with an Ip address and a maC address in order to
communicate with the rest of the network. If required, this additional level of security can be configured, but it will add
configuration overhead when network changes are made.
Copyright © 2013, Juniper Networks, Inc. 99
Implementation Guide – Vertical Campus
root@EX4200VC-2a# set ethernet-switching-options secure-access-port vlan data_wired_1a arp-inspectionset ethernet-switching-options secure-access-port vlan data_wired_1a examine-dhcpset ethernet-switching-options secure-access-port vlan data_wired_1a ip-source-guardset ethernet-switching-options secure-access-port vlan voip_wired_1a arp-inspectionset ethernet-switching-options secure-access-port vlan voip_wired_1a examine-dhcpset ethernet-switching-options secure-access-port vlan voip_wired_1a ip-source-guard
For more information on the secure access port features see Day One book, Configuring EX Series Ethernet Switches.
Junos Os supports a feature called interface-range, which allows you to group several interfaces together so that you
can configure the entire group using one statement. this can be helpful when you have many similar ports that share
much of the same configuration. this statement can be used to simplify configurations.
With the access switches in the tested network, each member in the Virtual Chassis is divided up by port type:
• ports 0–4 are reserved for wireless access points
• ports 5–26 are reserved for data.
• ports 27–47 reserved for voice.
since these ports are typically configured identically, you use the interface-range statement to simplify operations and
create three different port groups wireless_access_points, wired_data_ports and wired_voice_ports as listed in table 13.
Table 13: EX4200 Virtual Chassis 2 VLAN IP Address Mapping
VLAN-ID VLAN Name Subnet Port Range Name
12 data_wired_1a 10.10.8.0/22 wired_access_ports
24 voip_wired_1a 10.10.24.0/22 wired_voice_ports
54 access_points_1a 10.10.54.0/24 wireless_access_points
root@EX3300VC-1a# set interfaces interface-range wired_access_ports member-range ge-0/0/5 to ge-0/0/26set interfaces interface-range wired_voice_ports member-range ge-0/0/27 to ge-0/0/47set interfaces interface-range wireless_access_points member-range ge-0/0/0 to ge-0/0/4
Set the port mode.We need to set the port mode to access. Because we have used the interface-ranges statement, we only need to set
the port mode at the interface-range level, instead of editing every port.
root@EX4200VC-2a# set interfaces interface-range wired_access_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wired_voice_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wireless_access_points unit 0 family ethernet-switching port-mode trunk
Configure port to VLAN.
root@EX4200VC-2a# set vlans data_wired_1a interface wired_access_portsset vlans voip_wired_1a interface wired_voice_ports
the ports for the Wlas require a trunking configuration and require a native VlaN (access_points_1a) be configured in
order for the access point to boot up. When configuring a native VlaN you cannot configure the port VlaN members
with this same VlaN or it will ignore the native VlaN configuration and will not work as expected.
100 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
root@EX4200VC-2a# set interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces interface-range wireless_access_points unit 0 family ethernet-switching native-vlan-id access_points_1a
Configure layer 3 settings.layer 3 configuration for the access switch involves setting a default route in the case of the tested network. In this
case, it points to 10.10.28.1 which is the core switch Ip interface on the management VlaN.
set routing-options static route 0.0.0.0/0 next-hop 10.10.51.1
Commit the configuration.
commit
Verify IP reachabilityNext, you need to verify Ip reachability by “pinging” the core switch management Ip address from the access switch.
this also indicates that trunking is configured properly on the interface and working properly.
root@EX4200VC-2a> ping 10.10.51.1PING 10.10.51.1 (10.10.51.1): 56 data bytes64 bytes from 10.10.51.1: icmp_seq=0 ttl=64 time=2.717 ms64 bytes from 10.10.51.1: icmp_seq=1 ttl=64 time=1.887 ms64 bytes from 10.10.51.1: icmp_seq=2 ttl=64 time=2.198 ms
Verify VLANs and trunking.to verify that the proper VlaNs are configured for trunking on the ae0 interface, you can use the show ethernet-
switching interfaces ae0 command.
root@EX4200VC-2a> show ethernet-switching interfaces ae0Interface State VLAN members Tag Tagging Blockingae0.0 up access_points_1a 54 tagged unblocked data_wired_1a 12 tagged unblocked data_wireless_1a 36 tagged unblocked management_1a 51 tagged unblocked voip_wired_1a 24 tagged unblocked voip_wireless_1a 42 tagged unblocked
to see what ports are configured for specific VlaNs use the show vlans command.
NOTE: Because of the large number of ports in eX4200VC-2a, the show command output below show the first VlaN’s
output.
root@EX4200VC-2a> show vlansName Tag Interfacesaccess_points_1a 54 ae0.0*, ge-0/0/0.0, ge-0/0/1.0, ge-0/0/2.0, ge-0/0/3.0, ge-0/0/4.0
Copyright © 2013, Juniper Networks, Inc. 101
Implementation Guide – Vertical Campus
Configure Class of Servicethe basic Class of service configuration used is almost identical across core and access platforms in the tested
network example.
We will configure Class of service on the core eX4500VC-1a. the configuration of Cos is done in five steps the first four
define what the Cos service will look like and the last step applies Cos to specific interfaces.
• Forwarding Classes
• Classifiers
• schedulers
• scheduler-maps
• rewrite rules
• Configuring Interfaces
Configuring forwarding classes.First we will configure the forwarding classes, this step also defines what queues are used as well.
root@EX4200VC-2a# set class-of-service forwarding-classes class control queue-num 7set class-of-service forwarding-classes class voice queue-num 5set class-of-service forwarding-classes class business-app queue-num 3set class-of-service forwarding-classes class server-bulk queue-num 1set class-of-service forwarding-classes class best-effort queue-num 0
Configuring classifiers.Next we will create the classifiers. In the tested network example we are only using DsCp marking for our classification
of traffic. the classifiers map the different DsCp marked packets to the correct queue; if the traffic is not marked – or
marked with a DsCp value not listed – it will be considered best-effort traffic and treated accordingly.
root@EX4200VC-2a# set class-of-service classifiers dscp dscp_trusted forwarding-class control loss-priority low code-points nc1set class-of-service classifiers dscp dscp_trusted forwarding-class control loss-priority low code-points nc2set class-of-service classifiers dscp dscp_trusted forwarding-class voice loss-priority low code-points efset class-of-service classifiers dscp dscp_trusted forwarding-class business-app loss-priority low code-points af21set class-of-service classifiers dscp dscp_trusted forwarding-class server-bulk loss-priority low code-points af11set class-of-service classifiers dscp dscp_trusted forwarding-class best-effort loss-priority low code-points be
102 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Configuring schedulers.We will create schedulers for each type of traffic we want to manage. When we define the schedulers we also configure
characteristics like shaping/limiting/forwarding rate, how much buffer is allocated, and what priority the traffic has. In
the tested network there are schedulers that have very similar names and configuration. For example: voice-user-sched
and voice-network-sched, the difference between these schedulers is they are intended to be applied to different
types of interfaces when we create our scheduler maps later. While these currently have the same values, it may be
necessary to change the characteristics of your network or access ports to be different from each other. Configuring
schedulers this way from the beginning it makes less work if changes are needed later.
root@EX4200VC-2a# set class-of-service schedulers control-network-sched shaping-rate percent 5set class-of-service schedulers control-network-sched buffer-size percent 5set class-of-service schedulers control-network-sched priority strict-highset class-of-service schedulers control-user-sched shaping-rate percent 5 set class-of-service schedulers control-user-sched buffer-size percent 5set class-of-service schedulers control-user-sched priority strict-highset class-of-service schedulers voice-network-sched shaping-rate percent 5 set class-of-service schedulers voice-network-sched buffer-size percent 5 set class-of-service schedulers voice-network-sched priority strict-highset class-of-service schedulers voice-user-sched shaping-rate percent 5 set class-of-service schedulers voice-user-sched buffer-size percent 5 set class-of-service schedulers voice-user-sched priority strict-high set class-of-service schedulers business-sched transmit-rate percent 60 set class-of-service schedulers business-sched buffer-size percent 60set class-of-service schedulers business-sched priority low set class-of-service schedulers server-sched transmit-rate percent 30 set class-of-service schedulers server-sched buffer-size percent 30set class-of-service schedulers server-sched priority lowset class-of-service schedulers be-sched transmit-rate remainder set class-of-service schedulers be-sched buffer-size remainderset class-of-service schedulers be-sched priority low
Configuring scheduler maps.scheduler maps tie the individual schedulers to forwarding classes and queues. Here we have created two scheduler
maps one for network (switch to switch) ports and one for access or host ports. the difference between the two is the
different names for the individual control and voice schedulers used in each scheduler-map.
root@EX4200VC-2a# set class-of-service scheduler-maps network-port-sched forwarding-class control scheduler control-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class voice scheduler voice-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps network-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps network-port-sched forwarding-class best-effort scheduler be-schedset class-of-service scheduler-maps access-port-sched forwarding-class control scheduler control-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class voice scheduler voice-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps access-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps access-port-sched forwarding-class best-effort scheduler be-sched
Copyright © 2013, Juniper Networks, Inc. 103
Implementation Guide – Vertical Campus
Configure rewrite rules.rewrite rules are used to mark packets appropriately before packets exit an interface so that markings are preserved
throughout the network.
root@EX4200VC-2a# set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority low code-point nc1set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority high code-point nc2set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class voice loss-priority low code-point efset class-of-service rewrite-rules dscp rewrite-dscp forwarding-class business-app loss-priority low code-point af21set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class best-effort loss-priority low code-point be
Configuring interfaces.In order for Class of service to actually do anything it must be applied to interfaces. We have two main interface types:
network ports that connect switches together and ports that connect users/hosts. When applying Class of service
to an interface in the tested network example, you will configure a scheduler and classifier on network ports, or a
scheduler, classifier and rewrite policy on access ports.
You can also use wildcards to apply Class of service to multiple interfaces with a single command. For example: here
we have used wildcards to configure all the Gbe ports use the same Class of service settings. We could do the same
with our laG connections, but we have relatively few of these to configure so we will do so individually.
NOTE: the most specific commands win, so if you have a wildcard policy that is applied to all gigabit ethernet ports
and then you configure one of those ports specifically with different class of service settings they will not conflict;
instead the more specific port configuration will take precedence.
root@EX4200VC-2a# set class-of-service interfaces ge-* scheduler-map access-port-schedset class-of-service interfaces ge-* unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ge-* unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae0 scheduler-map network-port-schedset class-of-service interfaces ae0 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae0 unit 0 rewrite-rules dscp rewrite-dscp
Commit the configuration.
commit
Verifying class of service settings.there are various commands that can be used to verify portions of the Class of service configuration
Show class-of-service <sub-category>
examples:
show class-of-service scheduler-map
show class-of-service interface <interface name>
show class-of-service rewrite-rule
the most useful Class of service command might be looking at the interface statistics using the command
Show interface <interface name> detail
104 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
this command will provide details on what queues are configured on the port and how many packets were seen and if
any were dropped.
NOTE: when looking for Class of service statistics using the show interface command you can only see the statistics on
physical interfaces so when looking at a laG interface you need to run this command for each of the physical interfaces
that make up the link in order to view the Class of service details.
root@EX4200VC-2a> show interfaces ge-0/0/0 detailPhysical interface: ge-0/0/0, Administratively down, Physical link is Down Interface index: 469, SNMP ifIndex: 504, Generation: 472 Link-level type: Ethernet, MTU: 1514, Speed: Auto, Duplex: Auto, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online Device flags : Present Running Down Interface flags: Hardware-Down Down SNMP-Traps Internal: 0x0 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Hold-times : Up 0 ms, Down 0 ms Current address: f8:c0:01:c6:72:83, Hardware address: f8:c0:01:c6:72:83 Last flapped : 2012-05-25 16:10:46 GMT-8 (2w2d 06:25 ago) Statistics last cleared: 2012-06-08 17:40:37 GMT-8 (2d 04:56 ago) Traffic statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps IPv6 transit statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Egress queues: 8 supported, 5 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 0 0 1 server-bulk 0 0 0 3 business-app 0 0 0 5 voice 0 0 0 7 control 0 0 0 Queue number: Mapped forwarding classes 0 best-effort 1 server-bulk 3 business-app 5 voice 7 control Active alarms : LINK Active defects : LINK Interface transmit statistics: Disabled
Logical interface ge-0/0/0.0 (Index 86) (SNMP ifIndex 505) (Generation 151) Flags: Device-Down SNMP-Traps 0x0 Encapsulation: ENET2 Traffic statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Local statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Transit statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps Protocol eth-switch, Generation: 179, Route table: 0 Flags: Trunk-Mode
Copyright © 2013, Juniper Networks, Inc. 105
Implementation Guide – Vertical Campus
Wireless LAN Overview
WLA
WLA
WLA
WLA
WLA
WLA
WLA
BUILDING A BUILDING B
EX4200VC-2a
EX3300VC-1a
EX4200VC-3a
LAGLAG
LAGEX8200VC-1b
SRX SeriesCluster
WLCCluster
INTERNET
EX6200-1b
App Servers
Centralized DHCPand other services
EX4500VC-1a LAG
LAG
You are Here
Figure 17: Wireless LAN
Wireless Setup OverviewWe will use the following wireless ssIDs and VlaNs for the wireless laN table x shows the ssID to VlaN mapping for
each of the two buildings.
Table 14: SSID VLAN Mapping
SSID Bldg A VLAN name Bldg A VLAN ID Bldg B VLAN name Bldg B VLAN ID
xyzcompany_internal data_wireless_1a 36 data_wireless_1b 32
xyzcompany_voice voip_wireless_1a 42 voip_wireless_1b 40
xyzcompany_guest n/a n/a wireless_guest 60
as you can see there are consistent ssIDs throughout the campus, but they will map to different VlaNs in the different
buildings. this will be accomplished using the local switching option on the Wlas that was discussed in the Wireless
laN Overview section
authentication is configured depending on the ssID used (see table x). For example, internal users will be required
to authenticate via 802.1x to a corporate raDIus server. Guest users will have an open ssID no encryption, but will
authenticate using captive portal and be checked against a raDIus server used for guest access. Wireless Ip phones
will authenticate using a Wep key and allowed maC address range for security – many wireless phones have limited
authentication options.
Table 15: Authentication Methods by SSID
SSID Authentication Method Local or Centralized Switching
xyzcompany_internal raDIus, 802.1x local
wireless_voip ssID password, mac local
guest_wireless raDIus, captive portal Centralized
106 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Wireless LAN ConfigurationIn this example we will step through all the essential steps in setting up wireless for corporate users and wireless Guest access.
WlCs will be clustered to provide Ha and load balancing of aps dynamically.
the guest access is for external access only it will provide guest users the ability to connect to the internet and is
isolated from the corporate network.
the setup process assumes your WlC is running the factory default configuration.
We will configure the Wireless laN Controllers in two steps.
1. Configure WlC2800-1b and WlC2800-2b with a base configuration providing Ip reachability using the quick start
configuration script.
2. Complete the configuration (clustering, ap specifics, VlaNs) of the WlCs using ringmaster.
Pre-requisites for WLAN ConfigurationIn order to complete the WlaN configuration section you will need to have the following software components
installed a network reachable server.
• ringmaster
• raDIus server
• DHCp server that supports option 43
Running Quick start on WLC2800-1bWe will use the quick start configuration script; it will guide you through the initial setup of WlC2800-1. It’s possible to
configure more items in quick start than we will be doing here, but this example steps through the process manually —
it allows more control and it will be easier to make changes later if needed.
NOTE: as we go through the Quick start pay close attention to vlan names, VlaN-IDs and password you select. these
items are all device independent and if they are out of sync with the other WlCs it can result in some seemingly
inconsistent behavior. also we will need the enable password for ringmaster to talk with the WlC.
• Connect to the console port of the WlC using settings 9600-8-N-1-None
• Hit the enter key a few times until you get a prompt.
• login with no username/password.
• enter “enable” at the prompt. No password is configured by default so just hit enter when prompted for a password.
• enter “quickstart” at the prompt.
WLC2800-0801B0# quickstart This will erase any existing config. Continue? [n]: yAnswer the following questions. Enter ‘?’ for help. ^C to break outSystem Name [WLC2800]: WLC2800-1bCountry Code [US]:System IP address []: 10.10.50.100System IP address netmask []: 255.255.255.0Default route []: 10.10.50.1Do you need to use 802.1Q tagged ports for connectivity on the default VLAN? [n]:Enable Webview [y]:Admin username [admin]:Admin password [mandatory]:Enable password [optional]:Do you wish to set the time? [y]:Enter the date (dd/mm/yy) []: 24/10/12Enter the time (hh:mm:ss) []: 13:21:00Enter the timezone []: PSTEnter the offset (without DST) from GMT for ‘PST’ in hh:mm [0:0]: -08:00Do you wish to configure wireless? [y]: nsuccess: created keypair for sshsuccess: Type “save config” to save the configurationsuccess: change accepted.
Now save your configuration.
WLC2800-1b# save configsuccess: configuration saved
Now connect port 8 on WLC-1 to EX8200VC-1B port ge-4/0/0.
Copyright © 2013, Juniper Networks, Inc. 107
Implementation Guide – Vertical Campus
Configuring VLANs and 802.1q trunking for WLC2800-1bIt is assumed that the associated switch port configuration on the eX8200VC-1B has already been done. If this is not
the case, please review the eX8200VC-1B configuration section and configure the associated ports for the WlCs.
the next configuration item is the system Ip address and VlaN that will be used and enable them on the trunk port.
the WlCs will be configured as part of the following VlaNs.
NOTE: the WlCs can be configured with a different vlan-id from the actual 802.1q tag this is specific to the WlC and
should not be confused with the 802.1q tag. For example you could have a vlan-id of 5 on the WlC, but it’s sent out as
802.1q tag 13 so to the network it is vlan-id 13. there can be advantages to this in more complex deployments, but that
is outside the scope of this document. to make things easier to understand we will configure the internal vlan-id the
same as the 802.1q tag that the rest of the network uses.
We will configure the following VlaN on WlC2800-1b
management vlan-id 50
Creating VLANs
set vlan 50 name management
Assigning VLANs to ports
set vlan 50 port 8 tag 50
Assigning IP interfaces to VLANsBy default the WlC will allocate the first Ip address (“system Ip address”) to VlaN 1. In our case we want this to be
VlaN 50 the management VlaN so we will first delete the Ip address association with VlaN 1 and then we will add it
to VlaN 50. NOte: this will still be the system address which has a special meaning to the WlC. the system Ip address
is the source Ip address the WlC uses to communicate with the access points to.
clear interface 1 IP
set interface management IP 10.10.50.100/24
Save your configuration.
save config
You should now be able to ping the Ip address of the eX8200VC-1B on the management VlaN.
WLC2800-1b# ping 10.10.50.1PING 10.10.50.1 (10.10.50.1) from 10.10.50.100 : 56(84) bytes of data.64 bytes from 10.10.50.1: icmp_seq=1 ttl=64 time=5.666 ms64 bytes from 10.10.50.1: icmp_seq=2 ttl=64 time=1.925 ms64 bytes from 10.10.50.1: icmp_seq=3 ttl=64 time=2.302 ms64 bytes from 10.10.50.1: icmp_seq=4 ttl=64 time=2.508 ms64 bytes from 10.10.50.1: icmp_seq=5 ttl=64 time=2.386 ms--- 10.10.50.1 ping statistics ---5 packets transmitted, 5 packets received, 0 errors, 0% packet loss
NOTE: you may notice we have configured the Ip address 10.10.50.100 twice. actually we configured this as the system
Ip address earlier now we are just assigning it to a VlaN. the system Ip address needs to reside on the management
network since that is the address that will be used to communicate to the aps and with other WlCs.
108 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Running Quickstart on WLC2800-2bWe will use the quick start configuration script will guide you through the initial setup of WlC2800-1b. It’s possible to
configure more items in quick start than is done in this example, but we will step through the process manually – we
will have more control and it will be easier to make changes later if needed.
• Connect to the console port of the WlC using settings 9600-8-N-1-None.
• Hit the enter key a few times until you get a prompt.
• login with no username/password.
• enter enable at the prompt. By default, no password is configured. Just press enter when prompted for a password.
• enter “quickstart” at the prompt.
WLC2800-08033C# quickstartThis will erase any existing config. Continue? [n]: yAnswer the following questions. Enter ‘?’ for help. ^C to break outSystem Name [WLC2800]: WLC2800-2bCountry Code [US]:System IP address []: 10.10.50.101System IP address netmask []: 255.255.255.0Default route []: 10.10.50.1Do you need to use 802.1Q tagged ports for connectivity on the default VLAN? [n]: nEnable Webview [y]:Admin username [admin]:Admin password [mandatory]:Enable password [optional]:Do you wish to set the time? [y]:Enter the date (dd/mm/yy) []: 24/10/12Enter the time (hh:mm:ss) []: 13:30:00Enter the timezone []: PSTEnter the offset (without DST) from GMT for ‘PST’ in hh:mm [0:0]: -08:00Do you wish to configure wireless? [y]: nsuccess: created keypair for sshsuccess: Type “save config” to save the configurationsuccess: change accepted..
Save your configuration.
WLC2800-2b# save configsuccess: configuration saved
Connect port 8 on WLC2800-2 to EX8200VC-1B port ge-20/0/0
Configuring VLANs and 802.1q trunking for WLC2800-2bthis section assumes that the associated switch port configuration on the eX8200VC-1b has already been done. If this
is not the case please review the eX8200VC-1B configuration section and configure the associated ports for the WlCs.
Next we will configure the system Ip address and VlaN that will be used and enable them on our trunk port. the WlCs
will be configured as part of the following VlaNs.
the WlCs can be configured with a different vlan-id from the actual 802.1q tag. this is specific to the WlC and should
not be confused with the 802.1q tag. For example, you could have a vlan-id of 5 on the WlC, but it’s sent out as 802.1q
tag 13, so to the network it is vlan-id 13. there can be advantages to this in more complex deployments, but that is
outside the scope of this document. to make things easier to understand we will configure the internal vlan-id the
same as the 802.1q tag that the rest of the network uses.
We will configure the following VlaN on WlC2800-1b.
management vlan-id 50
Copyright © 2013, Juniper Networks, Inc. 109
Implementation Guide – Vertical Campus
Creating VLANs
set vlan 50 name management
Assigning VLANs to ports.
set vlan 50 port 8 tag 50
Assigning IP interfaces to VLANsBy default the WlC will allocate the first Ip address (“system Ip address”) to VlaN 1. In our case we want this to be
VlaN 50 the management VlaN so we will first delete the Ip address association with VlaN 1 and then we will add it
to VlaN 50. NOte: this will still be the system address which has a special meaning to the WlC. the system Ip address
is the source Ip address the WlC uses to communicate with the access points.
clear interface 1 ip
set interface Management ip 10.10.50.101/24
Save your configuration.
save config
It should now possible to ping the Ip address of the eX8200VC-1B on the management VlaN:
WLC2800-2b# ping 10.10.50.1PING 10.10.50.1 (10.10.50.1) from 10.10.50.101 : 56(84) bytes of data.64 bytes from 10.10.50.1: icmp_seq=1 ttl=64 time=5.283 ms64 bytes from 10.10.50.1: icmp_seq=2 ttl=64 time=2.529 ms64 bytes from 10.10.50.1: icmp_seq=3 ttl=64 time=2.349 ms64 bytes from 10.10.50.1: icmp_seq=4 ttl=64 time=2.397 ms64 bytes from 10.10.50.1: icmp_seq=5 ttl=64 time=4.906 ms--- 10.10.50.1 ping statistics ---5 packets transmitted, 5 packets received, 0 errors, 0% packet loss
You are now ready to complete the configuration using ringmaster.
Installing RingmasterInstallation of ringmaster is outside the scope of this document. to install and license ringmaster please see the
ringmaster Quick start Guide and/or the ringmaster documentation located at www.juniper.net/support.
Configuring WLCs and WLAs using RingmasterHigh level list of tasks to be done in order to setup the wireless laN in ringmaster
• upload WlCs into ringmaster
• Create mobility Domain and add WlCs to mobility Domain using the wizard
• Create a cluster
• Configure local WlC VlaNs, Ip addresses, etc…
• Configure authentication services
• Configure VlaN and radio profiles
• Configure wireless services (ssID setup)
• Configure local switching on Wlas
• adding Wlas to the system
Add devices to a NetworkDevices can be added two ways they can be pre-configured in ringmaster and deployed, they can be imported from
the existing network. We have previously configured the two WlCs (WlC2800-1b and WlC2800-2b) for basic network
connectivity. We will import these WlCs into ringmaster. Once this is done we can start managing both the WlCs.
110 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Uploading WLC2800-1b into RingMaster1. select the Configuration Navigation Bar button.
2. In the tasks panel, select upload WlC.
3. In the Ip address field, type the Ip address for WlC2800-1b.
4. In the enable password field, type the enable password for WlC2800-1b. this password must match the enable
password defined using the ClI command set enablepass. For more information, see the Juniper mobility system
software Configuration Guide.
5. Click Next. the uploading progress is shown.
6. after the successfully uploaded device message is displayed, click Finish.
7. If ringmaster displayed error or warning messages, select the Verification Navigation Bar button and go to Verifying
Configuration Changes.
Uploading WLC2800-2b into RingMaster1. select the Configuration Navigation Bar button.
2. In the tasks panel, select upload WlC.
3. In the Ip address field, type the Ip address for WlC2800-2b.
4. In the enable password field, type the enable password for WlC2800-2b. this password must match the enable
password defined using the ClI command set enablepass. For more information, see the Juniper mobility system
software Configuration Guide.
5. Click Next. the uploading progress is shown.
6. after the successfully uploaded device message is displayed, click Finish.
7. If ringmaster displayed error or warning messages, select the Verification Navigation Bar button and go to Verifying
Configuration Changes.
ringmaster starts with a default Network plan called “default” when we will first import the WlCs they will be
part of this Network.
Creating a Mobility Domain 1. First we will create a mobility domain.
2. select the Configuration Navigation Bar button.
3. select the Create mobility Domain task in the tasks panel. the setup mobility Domain wizard is displayed.
4. In the Name field, type the name for the mobility Domain (1 to 16 characters, with no spaces or tabs).
In our example we will call it “xyzcompany-HQ” Click Next.
5. From the available Devices list, select WlC2800-1b and WlC2800-2b to add to the mobility Domain.
6. Click Next.
7. select WlC2800-1b to act as the primary seed WlC for the mobility Domain.
8. to provide mobility domain redundancy, select WlC2800-2b to act as secondary seed. Click Finish.
Activating Changes from the cluster wizardthe wizard makes the appropriate changes in the individual WlCs, but does not activate these changes. this must
be done manually on both WlCs. ringmaster also provides the ability to review the changes on the device before
deploying them. If you would like to view the changes first you can select “review” from the tasks panel.
1. select the Configuration Navigation Bar button
2. select WlC2800-1b
3. In the tasks panel select “Deploy”, once deploy is completed press “close”
4. select WlC2800-2b
5. In the tasks panel select “Deploy” once deploy is completed press “close”
Copyright © 2013, Juniper Networks, Inc. 111
Implementation Guide – Vertical Campus
Creating a Cluster in the Mobility DomainWe will now create a cluster inside the mobility domain. When device are in a cluster the majority of configuration is
shared between the devices in the cluster – but some things are not; for example, items that are locally significant like
Ip addresses and local VlaNs. an easy way to understand what is shared and what is not between WlCs is to select
configuration from the toolbar in ringmaster and click on cluster configuration. all the items there are shared between
devices in the cluster. If you select one of the individual WlCs you will see the items that are specific to that WlC.
1. In the Organizer pane select “xyzcompany-HQ”
2. From the tasks pane select “setup Cluster”
3. Next
4. You should see both the WlCs displayed
5. Check the merge checkbox
6. press “Deploy Changes”
7. Next
8. everything should now complete, when overall progress is 100% press “Finish”
9. You should now see a cluster under “xyzcompany-HQ” called “xyzcompany-HQ Cluster” that contains both
WlC2800-1b and WlC2800-2b when expanded
Configuring VLANs We configured the system Ip address and VlaN id using the ClI already, but we need to add an additional VlaN for
Guest access to the WlCs. each of the WlCs will be configured to sit on the management and guest_wireless VlaNs.
later we will configure the individual Wlas for local switching and configure their VlaN mapping separately.
We have already configured the management VlaN and Ip so we will now configure the remaining VlaN that the WlC
will use.
NOTE: in the tested network example both WlCs are located in the same subnet and have the same VlaNs. You
should be careful when making device specific changes that have local significance like VlaN membership, etc… as
these are NOt sYNCrONIZeD between the WlCs in the cluster. make sure you pay attention as you configure the VlaN
information. For example: if you have one WlC configured with a VlaN called guest_wireless and the other configured
with one called wireless_guest by mistake, you will have some users that will not connect properly to the wireless
network – and some that will – because we load balance Wlas between controllers. On the surface it may seem like
random behavior when one user can connect and another in the same building cannot.
WLC2800-1b VLAN Configuration1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select WlC2800-1b
3. select the system-> VlaNs item
4. From the tasks pane select “Create VlaN”
5. set VlaN name and VlaN ID
• VlaN name: wireless_guest
• VlaN id: 60
6. Next
7. add WlC port(s) to the VlaN
• add port 8 to the VlaN wireless_guest
8. Next
Configure WLC IP address for VLAN 1. Ip address: 10.10.60.100/24
2. select “Interface enabled”
3. Finish
4. From the tasks pane select “Deploy”
5. select “close”
to verify the configuration you can select the VlaN you just configured and click properties. this will include the
information you just entered and some additional configuration panes that we will ignore for now.
112 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
WLC2800-2b VLAN Configuration1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select WlC2800-2
3. select the system-> VlaNs item
4. From the tasks pane select “Create VlaN”
5. set VlaN name and VlaN ID
• VlaN name: wireless_guest
• VlaN id: 60
6. Next
7. add WlC port(s) to the VlaN
• add port 8 to the VlaN wireless_guest
8. Next
Configure WLC IP address for VLAN 1. Ip address: 10.10.60.101/24
2. select “Interface enabled”
3. Finish
4. From the tasks pane select “Deploy”
5. select “close”
to verify the configuration you can select the VlaN you just configured and click properties. this will include the
information you just entered and some additional configuration panes that we will ignore for now.
Configuring Authenticationauthentication uses a standard raDIus server for enterprise users and a smartpass server for our guest users.
a single raDIus server could be used for both user types, but in this case we are using smartpass for guest
access because it has specific features that make it easier to manage guest users in an ad-hoc manner. setup and
configuration of smartpass is outside the scope of this document please see the smartpass Quick start Guide or
smartpass documentation located at www.juniper.net/support
We could also configure local authentication if needed for interim testing – if no raDIus servers have been setup yet.
However, this requires users be replicated between WlCs and this manual synchronization process is typically error
prone; it is not recommended as a primary method for authenticating users.
Cluster RADIUS configuration1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select “Cluster Configuration”
4. select aaa -> raDIus
5. In the tasks pane select “Create raDIus server”
6. Name: enterprise_raDIus_server
7. enter the Ip address of the raDIus server
• 10.10.48.100
8. enter the raDIus Key
• <radius key>
9. Next
10. either select next or edit the raDIus server Group name and then select next
11. Finish
Copyright © 2013, Juniper Networks, Inc. 113
Implementation Guide – Vertical Campus
Cluster Guest Wireless Authentication ConfigurationNow we will configure the smartpass server for the guest wireless users
1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select aaa -> raDIus
4. In the tasks pane select “Create raDIus server”
5. Name: smartpass_Guest_access_server
6. enter the Ip address of the raDIus server
• 10.10.64.100
7. enter the raDIus Key
• <radius key>
8. Next
9. Do not add this raDIus server to the existing raDIus group we will create a new one for it later
10. Finish
Configuring the RADIUS Authentication OptionsDepending on the setup of your raDIus server you may need to change the authentication protocol option of your
server or the authentication port.
1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select aaa -> raDIus
4. select the server “enterprise_raDIus_server”
5. press the “properties” button
6. select the authentication protocol pull-down menu and select the appropriate option for your raDIus server.
In the tested network we used msCHap-V2, but this could be different for your raDIus server configuration.
Creating a RADIUS Server Group for guest users1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select aaa -> raDIus
4. In the tasks pane select “Create raDIus server Group”
5. Name: “smartpass_Guest_access-GrOup”
6. Next
7. select the smartpass_Guest_access_server and add it to the group
8. Finish
Configuring the SmartPass authentication optionsDepending on the setup of your raDIus server you may need to change the authentication protocol option of your
server or the authentication port.
1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select aaa -> raDIus
4. select the server “smartpass_Guest_access_server”
5. press the “properties” button
6. select the authentication protocol pull-down menu and select the appropriate option for your smartpass server.
In the tested network we used NONe, but this could be different for your smartpass server configuration.
Activating changes1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select “Cluster Configuration”
4. select “Deploy”
114 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Testing RADIUS authenticationIf the raDIus servers are up and active you can test out the raDIus server connection by using the raDIus ping utility
in ringmaster.
1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select “Cluster Configuration”
4. select aaa-> raDIus
5. In the tasks pane, select raDIus ping
6. select one of the raDIus servers configured previously
7. select request type “authentication”
8. enter valid username and password information for your raDIus server
9. select “start”
10. You should see the authentication accepted
11. repeat steps 6-10 to verify additional raDIus servers
12. select “close”
Setting up VLAN ProfilesVlaN profiles are created under the local switching section of ringmaster. this allows selection of what VlaNs will
be mapped to ssIDs. we will create VlaN profiles for building a and building B of the tested network. this is required
because we want to use a consistent ssID for both buildings, but each building will have slightly different VlaN
mapping. VlaN profiles allow us to provide this single global ssID and authentication method globally, but maps
locally to the specific environment.
VLAN Profile for Building A1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select “Cluster Configuration”
4. select “Wireless”
5. select “local switching”
6. In the tasks pane select “Create VlaN profile”
7. Name: “Building_a”
8. Next
9. None of the VlaNs we need have been configured yet so we will do that now.
10. select the “add VlaN” button
11. We will configure the data_wireless_1a network first
• Name: data_wireless_1a
• Check “Is VlaN tagged”
• tag value 36
12. Click OK
13. Now click “add VlaN” again and add the voice wireless
• Name: voip_wireless_1a
• Check “Is VlaN tagged”
• tag value 42
14. Click OK
15. Next
16. We have not configured any Wlas yet so we will skip this step for now.
17. Finish
Copyright © 2013, Juniper Networks, Inc. 115
Implementation Guide – Vertical Campus
VLAN Profile Building B1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select local switching
4. In the tasks pane select “Create VlaN profile”
5. Name: “Building_B”
6. Next
7. select the “add VlaN” button
8. We will configure the data_wireless_1b network first
• Name: data_wireless_1b
• Check “Is VlaN tagged”
• tag value 32
9. Click OK
10. Now click “add VlaN” again and add the voice wireless
• Name: voip_wireless_1b
• Check “Is VlaN tagged”
• tag value 40
11. Click OK
12. Next
13. We have not configured any Wlas yet so we will skip this step for now.
14. Finish
Activating changes1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select “Cluster Configuration”
4. select “Deploy”
Radio ProfilesCreating Radio Profiles for building A and Building Bradio profiles allow you to manage groups of Wlas easily in one spot. this is very handy when you need to configure
your channel plan and other features after the infrastructure has been deployed. In this tested network example
we have two simple plans – one for each building – but this could be more complex depending on the specific
requirements.
1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ” Cluster
3. select Wireless -> radio profiles
4. In the tasks pane select “Create radio profile”
5. enter “Building_a” for name
6. Next
7. We will skip adding radio profile members for the moment because we have not configured any Wlas yet.
8. Next
9. We will add service profiles in the next section so skip this for now
10. Finish
11. In the tasks pane select “Create radio profile”
12. enter “Building_B” for name
13. Next
14. We will skip adding radio profile members for the moment because we have not configured any Wlas yet.
15. Next
16. We will add service profiles in the next section so skip this for now
17. Finish
116 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Setting up Wireless Servicesthe first step is to set up wireless services for the enterprise users. since we are using local switching a wireless
services profile is required for each building. this will allow a single wireless ssID “xyzcompany_internal” for all
enterprise users in both buildings, but will modify the behavior based on the building. this ensures that user traffic is
handled locally by the wireless access points.
Setting up Building A1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select “Cluster Configuration”
4. select Wireless -> Wireless services
5. In the tasks pane select “802.1X service profile”
6. Next
7. enter the name for this profile “secure-802.1X-Building-a”
8. enter the ssID for enterprise users “xyzcompany_internal”
9. Next
10. select eap type “external server authentication”
11. select the server group associated with the enterprise users “enterprise_raDIus_server-GrOup” and
add it to “Current aaa server Groups”
12. Next
13. ImpOrtaNt type in the VlaN name for the VlaN that will be used in building a for internal users “data_wireless_1a”
14. Next
15. Now select the radio profile “Building_a”.
16. Next
17. We will not make any changes to the 802.11n attributes
18. Finish
19. Check “apply changes to Cluster members”
20. Next
21. Finish
22. In the tasks pane select “Deploy”
Setting up Building B1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select “Cluster Configuration”
4. select Wireless -> Wireless services
5. In the tasks pane select “802.1X service profile”
6. Next
7. enter the name for this profile “secure-802.1X-Building-B”
8. enter the ssID for enterprise users “xyzcompany_internal”
9. Next
10. select eap type “external server authentication”
11. select the server group associated with the enterprise users “enterprise_raDIus_server-GrOup” and
add it to “Current aaa server Groups”
12. Next
13. ImpOrtaNt type in the VlaN name for the VlaN that will be used in building a for internal users “data_wireless_1b”
14. Next
15. Now select the radio profile “Building_B”.
16. Next
17. We will not make any changes to the 802.11n attributes
18. Finish
19. Check “apply changes to Cluster members”
20. Next
21. Finish
22. In the tasks pane select “Deploy”
23. select “close”
Copyright © 2013, Juniper Networks, Inc. 117
Implementation Guide – Vertical Campus
Setting up Wireless Voice Wireless phones typically have some unique requirements. there are in-depth wireless deployment guides available
for different phone models available at www.Juniper.net. these settings are specific to the tested network example
and will need some modification if you are deploying wireless voice. as with the enterprise users, two Wireless service
profiles will be configured – one for each building. Both profiles will share the same ssID “xyzcompany_voice”.
Building A Configuration1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select Wireless -> Wireless services
4. In the tasks pane select “Voice service profile”
5. Next
6. enter the ssID for voice users “xyzcompany_voice”
7. select a vendor from the list or create your own profile, for the tested network example we will use spectralink.
8. Next
9. We will leave the CaC configuration alone
10. Next
11. In Qos profile selection screen you should see “Create new Qos profile” checked
12. Next
13. type in a name for the Qos profile, in our case we will use “spectralink”
14. select enable Voice Cos
15. Next
16. access type we are using is maC
17. Next
18. In the Wireless security screen select “static Wep”
19. Next
20. enter the Wep key that will be used for the Wireless Voice users (0123456789)
21. For authentication select the lOCal server option
22. Next
23. set VlaN to “voip_wired_1a”
24. Next
25. For Client maC addresses select “Create”
26. under maC user Information, Vendor spectralink
27. select the OuI for spectralink
28. Next
29. leave the authorization attributes alone for now
30. Finish
31. select the Client maC addresses that are allowed (this should have only one value for spectralink
(a partial mac address)
32. Next
33. We will not make any changes to the Qos spectralink screen
34. Next
35. select radio profile “Building_a”
36. Next
37. We will not change the 802.11n attributes
38. Finish
39. select “apply changes to Cluster members”
40. select “Next”
41. select “Finish”
42. select “Deploy”
118 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Building B Configuration1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select Wireless -> Wireless services
4. In the tasks pane select “Voice service profile”
5. Next
6. enter the ssID for voice users “xyzcompany_voice”
7. select a vendor from the list or create your own profile, for the tested network example we will use spectralink.
8. Next
9. We will leave the CaC configuration alone
10. Next
11. In Qos profile selection screen you should see the qos profile created previously “spectralink”. select that from the list
12. Next
13. access type we are using is maC
14. Next
15. In the Wireless security screen select “static Wep”
16. Next
17. enter the Wep key that will be used for the Wireless Voice users (0123456789)
18. For authentication select the lOCal server option
19. Next
20. set VlaN to “voip_wireless_1b”
21. Next
22. For Client maC addresses select “Create”
23. under maC user Information, Vendor spectralink
24. select the OuI for spectralink
25. Next
26. leave the authorization attributes alone for now
27. Finish
28. select the Client maC addresses that are allowed (this should have only one value for spectralink
(a partial mac address)
29. Next
30. We will not make any changes to the Qos spectralink screen
31. Next
32. select radio profile “Building_B”
33. Next
34. We will not change the 802.11n attributes
35. Finish
36. select “apply changes to Cluster members”
37. select “Next”
38. select “Finish”
39. select “Deploy”
Guest Wireless setupFor building A1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select Wireless -> Wireless services
4. In the tasks pane select “Web-portal service profile”
5. Next
6. enter the name for the profile “Guest-access-Building-a”
7. enter the ssID for Guest users “xyzcompany_guest”
8. Next
9. set the VlaN pool to “guest_wireless”
Copyright © 2013, Juniper Networks, Inc. 119
Implementation Guide – Vertical Campus
10. Next
11. We will leave the Web portal aCl alone
12. Next
13. set the authentication server to smartpass_Guest_access-GrOup
14. Next
15. select radio profile “Building a”
16. Next
17. We will not change the 802.11n attributes
18. Finish
19. select apply changes to cluster members
20. Next
21. Finish
Activating changes1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ” Cluster
3. select “Cluster Configuration”
4. select “Deploy”
For Building B1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select Wireless -> Wireless services
4. In the tasks pane select “Web-portal service profile”
5. Next
6. enter the name for the profile “Guest-access-Building-B”
7. enter the ssID for Guest users “xyzcompany_guest”
8. Next
9. set the VlaN pool to “guest_wireless”
10. Next
11. We will leave the Web portal aCl alone
12. Next
13. set the authentication server to smartpass_Guest_access-GrOup
14. Next
15. select radio profile “Building_B”
16. Next
17. We will not change the 802.11n attributes
18. Finish
19. select apply changes to cluster members
20. Next
21. Finish
Activating changes1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ” Cluster
3. select “Cluster Configuration”
4. select “Deploy”
120 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Adding WLAsthere are multiple ways to deploy the Wlas:
• the Wlas can be deployed in the network and configured later if desired.
• the Wlas can be deployed and automatically configured by the system.
• Wlas can pre-configure in ringmaster and then deployed later.
each method has its own advantages and disadvantages. the example presented in the tested network presents pre-
configuration of the Wlas for later deployment. this requires having the serial numbers for the Wlas that are going to
deploy beforehand, and also have an idea where the Wlas will be placed.
NOTE: in the tested network example we have the WlCs and the Wlas on different networks. Because of this it was
necessary to configure option 43 on our DHCp servers. the information contained in that field tells the Wla the Ip
address of the WlCs. Option 43 is a list of Ip addresses that correspond to the WlC(s) configured in the network. For
our case the list has two entries 10.10.50.100 and 10.10.50.101. If deploying your Wlas on a different network from the
WlCs you will need to configure option 43 for the Wlas to boot up and get their configuration from the WlCs.
there are other ways to have Wlas boot and find their WlC without using option 43 that are documented in the day
one book Deploying a Secure Wireless LAN or you can find this in the operator’s manual.
Building B WLA configuration1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select Wireless -> WlaN access points
4. In the tasks pane select “Wla” under the “Create section
5. enter the following information for each Wla
a. assign a Wla number or let the system pick one for you
b. enter a name for the Wla, you can leave the default or give the Wla a name
c. leave connection as Distributed
d. enter a description if you would like, this could include additional details to help in locating the Wla if needed
later.
6. Next
7. enter the serial number of the unit
8. Next
9. select the Wla model for the Wla in the tested network it is Wla532-us
10. Next
11. select the correct radio profile for the first radio on the Wla in our case we select “Building_B”
12. Next
13. select the correct radio profile for the second radio on the Wla in our case we select “Building_B” again.
14. Finish
Enable local switching on the WLA1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select Wireless -> WlaN access points
4. select the Wla you just configured
5. select properties
6. select “enable local switching”
7. select VlaN profile “Building_B”
8. Click “ok”
9. Now click on the “save” button located in the configuration pane
10. Now in the tasks pane select “Deploy”
Copyright © 2013, Juniper Networks, Inc. 121
Implementation Guide – Vertical Campus
Preparing Clients for Wireless Connectivitymss uses 802.1X for access to secure (encrypted) ssIDs, like xyzcompany_internal, using dynamic keys. to allow a
wireless client access on an encrypted ssD with dynamic keys, 802.1X must be configured on the client.
time to set up that laptop.
Configuring a Client for Guest Accesslet’s configure a Windows laptop for guest access to the public network and see if things are working from this
perspective. the exact procedure, of course, depends on your operating system and hardware:
1. On your Windows 7 pC, right-click the Wireless icon on the toolbar at the bottom right of the screen.
2. select xyzcompany_guest from the list of available wireless networks.
3. Double-click and wait for a successful connection.
4. Once you’re connected, the Web portal page is displayed.
5. log in using the configured username and the password
Configuring a Client for Corporate AccessNow let’s configure a Windows 7 client for access to an encrypted ssID. the exact procedure, of course, depends on
your operating system and hardware:
1. In Windows 7, go to Control panel > Network and Internet >Network and sharing Center.
2. under Change Your Network settings, click Manually to connect to a wireless network.
3. enter acme-corp as the Network name.
4. From the security type list, select Wpa2-enterprise.
5. leave the encryption type as aes.
6. the default authentication method is microsoft:protected eap (peap).
7. Click settings.
8. Clear the Validate server certificate check box.
9. under select authentication method, the default method is secured password (eap-msCHapv2).
10. Click Configure.
11. Clear the automatically use my Windows logon name and password (and domain if any) check box. Click OK.
12. Click OK, and then click Close.
13. Click the Wireless icon in the toolbar, and select xyzcompany_internal from the list of available wireless networks. and
let’s connect to the xyzcompany_internal ssID; this is really easy!
If your laptop doesn’t automatically find the ssID, open Network Connections, and then right-click the Wireless
Connection icon. select View available Wireless Networks to display the list of networks in the area.
In Figure 18, three ssIDs are displayed. Double-click xyzcompany_internal to get connected.
Figure 18: Wireless Network Connection
122 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
How to verify connectivitylet’s also verify your Ip address information, by opening a command prompt window, and typing in ipconfig. all of your
wireless client settings are displayed as shown in Figure 19.
Figure 19: ipconfig Information
as you can see from the Ip address assigned, we have connected through an ap located in Building B. so this tells us
we have connected to the wireless network and been assigned a proper Ip address. Now test some basic connectivity.
ping an internal or external device in this case we will ping a device on the internet to verify connectivity, see Figure 20.
Figure 20: Verifying Connectivity
Copyright © 2013, Juniper Networks, Inc. 123
Implementation Guide – Vertical Campus
Adding More Clients to the WLANNow it’s time to grab your colleagues and walk them through the steps of configuring the wireless client on various
mobile devices. If you’ve followed the configuration correctly, wireless clients should have no problem finding
and connecting to your wireless network. Bring in all your mobile devices and laptops to document and test their
connectivity. update the drivers on laptops or tablets to be sure that you have the latest versions.
For additional information on Juniper WlaN products and troubleshooting, see appendix C.
SRX Deployment
WLA
WLA
WLA
WLA
WLA
WLA
WLA
BUILDING A BUILDING B
EX4200VC-2a
EX3300VC-1a
EX4200VC-3a
LAGLAG
LAGEX8200VC-1b
SRX SeriesCluster
WLCCluster
INTERNET
EX6200-1b
App Servers
Centralized DHCPand other services
EX4500VC-1a LAG
LAG
You are Here
Figure 21: SRX Network Location
Before you begin configuring the srX series services Gateway for the tested network design, ensure the following:
• that all the srX series devices to be configured in the cluster are of the same model and comprise the same modules.
• that all the srX series devices have the same version of Junos Os installed.
Figure 22 shows the srX series cluster configured for the tested network. to keep it simple, each device identifies the
fabric and control links as local physical ports, because these are connected before configuring the srX series cluster
(after the srX series cluster is configured, srX650-2b will see these ports as ge-9/0/2 and 9/0/1). the remaining port
identifiers are listed in the clustering context.
124 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
SRX650-1b
Trunk Links with reth Interfaces
VLAN Interface
SRX650-2b
Active(Route Weighted)
ge-2/0/0
ge-11/0/0
ge-2/0/1 10.94.44.2
10.94.44.6ge-11/0/2
INTERNET
SERVICEPROVIDER 2
EX8200Virtual Chassis
SERVICEPROVIDER 1
Control Link Fabric Link
internet_edge reth 0.44 10.10.44.252/24
management_1b reth 0.50 10.10.50.254/24
guest_wireless reth 0.60 10.10.60.254/24
SRX Cluster Ports
Fabric LinksSRX650-1b ge-0/0/2
SRX650-2b ge-0/0/2
Control LinksSRX650-1b ge-0/0/1
SRX650-2b ge-0/0/1
Figure 22: SRX Link Diagram
Configuring the SRX Clusterto configure the srX series Gateway devices for the tested network, you must first perform the following setup
procedure for both srX series devices that will make up the cluster.
to perform the initial setup for the srX650 devices:
Unpack the SRX650 and connect a console cable to the serial port with the following settings: 9600, 8, 1 and none.
To access the SRX650 using the Junos OS CLI:1. Connect one end of the console cable to the serial port adapter, plug the adapter into a serial port on the pC or laptop,
and plug the other end of the cable into the console port on the srX series device.
2. start the terminal emulation program on the pC or laptop, select the COm port, and configure the following port
settings: 9600 (bits per second), 8 (data bits), none (parity), 1 (stop bits), and none (flow control).
3. press the pOWer button on the router, and verify that the pOWer leD turns green.
4. log in as root, and press enter at the password prompt. (When booting the factory default configuration, you do not
need to enter a password.)
5. enter the uNIX shell after you are authenticated through the ClI:
Amnesiac (ttyu0)login: rootPassword:- - - JUNOS 12.1r1.9 built 2011-11-16 09:23:09 UTC
6. at the % prompt, type “cli” to start the ClI and press enter. the prompt changes to an angle bracket (>) when you enter
ClI operational mode.
root@%cli root>
7. at the (>) prompt, type “configure” and press enter. the prompt changes from > to # when you enter configuration mode.
root> configureEntering configuration mode[edit]root#
Copyright © 2013, Juniper Networks, Inc. 125
Implementation Guide – Vertical Campus
8. Create a password for the root user to manage the srX series device.
root# set system root authentication plain-text-password
(will prompt for password)
9. remove some default configuration items from the srX devices. this is done to make later configuration simpler.
NOTE: Not all of these settings may actually be configured on your device, but we include all these items for
completeness.
root# delete interfacesdelete protocolsdelete vlansdelete system services dhcpdelete system services web-management http interfacedelete system services web-management https interfacedelete security zonesdelete security policiesdelete security nat
10. use the commit command at the ClI prompt to activate the configuration.
Commit
Now repeat this process with the other srX650.
Connect the two SRX devices.NOte: the following process is for the srX650. If you use another srX model, the ports used to connect the two srXs
will be different than the process described below. please see the Juniper Networks support site for clustering details
on your specific model of srX.
On the srX650, connect ge-0/0/1 on device a to ge-0/0/1 on device B. the ge-0/0/1 interface on device B will change
to ge-9/0/1 after clustering happens.
TIP: to connect the devices, it is helpful to know that after we create the cluster the following interface assignments
will occur:
• ge-0/0/0 will be used as fxp0 for individual management of each of the devices
• ge-0/0/1 will become fxp1 and used as the control link between the two devices (this is also documented inKB15356.).
this interface assignment is not configurable.
the other interfaces are also renamed on the secondary device. For example, on a srX 650 device, the ge-0/0/0
interface is renamed to ge-9/0/0 on the secondary node 1. refer to the complete mapping for each srX series device:
Node Interfaces on Active SRX Series Chassis Clusters.
NOTE: the interfaces used for the control link, in this example ge-0/0/1, must be connected with a cable. a switch
cannot be used for the control link connection. also, you will need to decide on a third link to connect the devices,
which will be used for the fabric link between the devices.
In this case we will use ge-0/0/2, but you could use any other open port either onboard or on a gpIm.
Now connect ge-0/0/2 on srX650-1 to ge-0/0/2 on srX650-2.
Enable clustering on the SRX devices.set the devices in cluster mode with the following command and reboot the devices.
NOTE: this is an operational mode command.
root> set chassis cluster cluster-id 0-15 node 0-1 reboot
For example:
root> set chassis cluster cluster-id 1 node 0 rebootroot> set chassis cluster cluster-id 1 node 1 reboot
126 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
the cluster ID is the same on both devices, but the node ID should be different, with the node ID as node0 on one
device, at node1 on the other device.
this command should be issued on both devices at the same time so that they boot up together.
the range for the Cluster ID is 0–15. setting it to 0 effectively disables cluster mode.
after rebooting, the ge-0/0/0 and ge-0/0/1 interfaces become as fxp0 and fxp1, respectively.
Check both srX series devices to ensure that the cluster is active and that the primary and secondary devices are both
active.
NOTE: It may take a minute or two for the status to complete after booting, so you may need to enter this command
more than once. the prompt on each srX series device displays the status and node information for the respective
device.
{primary:node0}root> show chassis cluster statusCluster ID: 1Node Priority Status Preempt Manual failoverRedundancy group: 0 , Failover count: 1node0 1 primary no nonode1 1 secondary no no
{secondary:node1}root> show chassis cluster statusCluster ID: 1Node Priority Status Preempt Manual failoverRedundancy group: 0 , Failover count: 0node0 1 primary no nonode1 1 secondary no no
When the primary and secondary status is confirmed, move to the next step. If you encounter any problems during this
step, the following KB articles may be of use in diagnosing clustering problems: KB–15503, KB–20672 and KB–20641.
Configure the SRX Series cluster.
NOTE:
• the following steps are all performed on the primary srX series device. the configuration is automatically copied over to
the secondary srX series device when a configuration is committed.
• We use the Junos Os group configuration feature for this operation. For more information on the group configuration
feature, see the Day One book, Configuring Junos Basics.
• Configuring device-specific properties using the group command: set up device-specific settings such as hostnames
and management Ip addresses. this is specific to each device and is the only part of the configuration that is unique to
specific nodes. this is done by entering the following commands (all on the primary node):
On device srx650-1b: Enter configuration mode
root# configroot# set group node0 system host-name srx650-1bset group node0 interfaces fxp0 unit 0 family inet address 10.94.188.103/24set group node1 system host-name srx650-2bset group node1 interfaces fxp0 unit 0 family inet address 10.94.188.104/24
NOTE: the apply groups command is set so that the individual configurations for each node set by the above
commands applies only to that node.
root# set apply-groups [ node0 node1 ]
Copyright © 2013, Juniper Networks, Inc. 127
Implementation Guide – Vertical Campus
Commit the configuration.
root# commitYou should see the configuration applied to node0 and node1 when you issue a commit{primary:node0}[edit]root# commitnode0:configuration check succeedsnode1:commit completenode0:commit complete
Configure the Fabric Link Create FAB links (data plane links for RTO sync, etc).You need to first delete any specific configuration related to the interfaces. In this case ge-0/0/2 has an address
assigned by default so we will delete it.
root@srx650-1# set interfaces fab0 fabric-options member-interfaces ge-0/0/2 set interfaces fab1 fabric-options member-interfaces ge-9/0/2
Configuring Redundancy Groupsset up the redundancy Group 0 for the routing engine failover properties. also setup redundancy Group 1 (all the
interfaces will be in one redundancy Group in this example) to define the failover properties for the reth interfaces.
NOTE: If you want to use multiple redundancy Groups for the interfaces, refer to the Junos documentationSecurity Configuration Guide.
root@srx650-1b# set chassis cluster redundancy-group 0 node 0 priority 100set chassis cluster redundancy-group 0 node 1 priority 1set chassis cluster redundancy-group 1 node 0 priority 100set chassis cluster redundancy-group 1 node 1 priority 1
Configuring Interface Monitoring set up the Interface monitoring. monitoring the health of the interfaces is one way to trigger redundancy group failover.
NOte: Interface monitoring is not recommended for redundancy-group 0.
root@srx650-1b# set chassis cluster redundancy-group 1 interface-monitor ge-2/0/0 weight 255set chassis cluster redundancy-group 1 interface-monitor ge-11/0/0 weight 255
Set up the reth interface.setup the redundant ethernet interfaces (reth interface) and assign the redundant interface to a zone. make sure that
you setup your redundant interfaces as follows:
root@srx650-1b# set chassis cluster reth-count 1set interfaces ge-2/0/0 gigether-options redundant-parent reth0set interfaces ge-11/0/0 gigether-options redundant-parent reth0set interfaces reth0 redundant-ether-options redundancy-group 1
128 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Configure VLANs and IP interfaces on the reth interface
root@srx650-1b# set interfaces reth0 vlan-taggingset interfaces reth0 redundant-ether-options redundancy-group 1set interfaces reth0 unit 0 description “Unit 0 must be given a VLAN tag so using a dummy tag to align units to tags”set interfaces reth0 unit 0 vlan-id 1set interfaces reth0 unit 44 description internet_edgeset interfaces reth0 unit 44 vlan-id 44set interfaces reth0 unit 44 family inet address 10.10.44.254/24set interfaces reth0 unit 50 description managementset interfaces reth0 unit 50 vlan-id 50set interfaces reth0 unit 50 family inet address 10.10.50.254/24set interfaces reth0 unit 60 description guest_wirelessset interfaces reth0 unit 60 vlan-id 60set interfaces reth0 unit 60 family inet address 10.10.60.254/24
Commit the configuration to activate it.
commit
Configure the Internet connections
root@srx650-1b# set interfaces ge-2/0/1 description “Primary Internet Connection”set interfaces ge-2/0/1 unit 0 family inet address 10.94.44.2/30set interfaces ge-11/0/2 description “Backup Internet Connection”set interfaces ge-11/0/2 unit 0 family inet address 10.94.44.6/30
Commit the configuration.
root@srx650-1b# commit
NOTE: even though we have configured interfaces, we will not have reachability because no security policies are in
place yet.
Configuring Security Zonesthe srX series services Gateways use a zone-based model for security. the most basic configurations typically have
just two zones: trust (the inside) and untrust (the outside). In our case we have four: untrust, guest, management, and
internet_edge.
NOTE: the security policies shown here are meant to be a starting point and may need to be adjusted to your specific
network. For example, the voice networks can talk to all devices in the intranet and internet currently, but you may want
to restrict the type of traffic allowed to only voice and signaling.
Configure the untrust security zone.the untrust zone is where the srX series devices connect to the Internet. this is considered the least trusted zone. We
have configured our internet-facing ports in this zone.
root@srx650-1b# set security zones security-zone untrust screen untrust-screenset security zones security-zone untrust interfaces ge-11/0/2.0set security zones security-zone untrust interfaces ge-2/0/1.0
Copyright © 2013, Juniper Networks, Inc. 129
Implementation Guide – Vertical Campus
Configure the guest security zone.
root@srx650-1b# set security zones security-zone guest address-book address guest_wireless 10.10.60.0/24set security zones security-zone guest host-inbound-traffic system-services pingset security zones security-zone guest host-inbound-traffic system-services tracerouteset security zones security-zone guest interfaces reth0.60 host-inbound-traffic system-services dhcpset security zones security-zone guest interfaces reth0.60 host-inbound-traffic system-services bootp
Configure the Management security zone.
root@srx650-1b# set security zones security-zone management address-book address management_1a 10.10.51.0/24set security zones security-zone management address-book address management_1b 10.10.50.0/24set security zones security-zone management host-inbound-traffic system-services sshset security zones security-zone management host-inbound-traffic system-services httpset security zones security-zone management host-inbound-traffic system-services httpsset security zones security-zone management host-inbound-traffic system-services pingset security zones security-zone management host-inbound-traffic system-services snmpset security zones security-zone management host-inbound-traffic system-services tracerouteset security zones security-zone management interfaces reth0.50
Configure the Internet Edge security zone.the majority of the networks are contained in the internet_edge zone. We use a feature called address-book to map
our networks in this zone to user-friendly names for easier management. that should be easier to understand when
we configure our policies that just use subnet designations. We also need to allow OspF in this zone, because we will
communicate routing information with the eX series switch in this zone.
root@srx650-1b# set security zones security-zone internet_edge address-book address data_wired_1b 10.10.8.0/22set security zones security-zone internet_edge address-book address data_wired_1a 10.10.12.0/22set security zones security-zone internet_edge address-book address voip_wired_1b 10.10.20.0/22set security zones security-zone internet_edge address-book address voip_wired_1a 10.10.24.0/22set security zones security-zone internet_edge address-book address data_wireless_1b 10.10.32.0/22set security zones security-zone internet_edge address-book address data_wireless_1a 10.10.36.0/22set security zones security-zone internet_edge address-book address voip_wireless_1b 10.10.40.0/23set security zones security-zone internet_edge address-book address voip_wireless_1a 10.10.42.0/23set security zones security-zone internet_edge address-book address server_1b 10.10.46.0/24set security zones security-zone internet_edge address-book address server_2b 10.10.48.0/24set security zones security-zone internet_edge host-inbound-traffic system-services pingset security zones security-zone internet_edge host-inbound-traffic system-services tracerouteset security zones security-zone internet_edge host-inbound-traffic protocols ospfset security zones security-zone internet_edge interfaces reth0.44
130 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Configuring Security Policies.Configure guest user policy.
root@srx650-1# set security policies from-zone guest to-zone untrust policy allow-guest-to-internet match source-address guest_wirelessset security policies from-zone guest to-zone untrust policy allow-guest-to-internet match destination-address anyset security policies from-zone guest to-zone untrust policy allow-guest-to-internet match application anyset security policies from-zone guest to-zone untrust policy allow-guest-to-internet then permit
Configure Internet Edge Security Policy.
root@srx650-1b# set security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address data_wired_1aset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address data_wired_1bset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address voip_wired_1aset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address voip_wired_1bset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address data_wireless_1aset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address data_wireless_1bset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address voip_wireless_1aset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address voip_wireless_1bset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address server_1bset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address server_2bset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match destination-address anyset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match application anyset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet then permit
Configuring Routing and OSPF.Configure Routes.
root@srx650-1b# set routing-options static route 0.0.0.0/0 qualified-next-hop 10.94.44.5 preference 20set routing-options static route 0.0.0.0/0 qualified-next-hop 10.94.44.1 preference 10
Configure OSPF.
root@srx650-1b# set protocols ospf area 0.0.0.0 interface reth0.44
Commit the configuration.
root@srx650-1b# commit
You can see the internal networks advertised by OspF by using the show route command.
Copyright © 2013, Juniper Networks, Inc. 131
Implementation Guide – Vertical Campus
{primary:node0}root@srx650-1> show routeinet.0: 32 destinations, 35 routes (32 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/10] 6w1d 23:50:07 > to 10.94.44.1 via ge-2/0/1.0 [Static/20] 00:03:53 > to 10.94.44.5 via ge-11/0/2.010.10.8.0/22 *[OSPF/10] 1w2d 20:45:10, metric 2 > to 10.10.44.1 via reth0.4410.10.12.0/22 *[OSPF/10] 1d 04:12:46, metric 3 > to 10.10.44.1 via reth0.4410.10.20.0/22 *[OSPF/10] 1w2d 20:45:10, metric 2 > to 10.10.44.1 via reth0.4410.10.24.0/22 *[OSPF/10] 1d 04:12:46, metric 3 > to 10.10.44.1 via reth0.44…
For readability the remainder of the show route output not shown.
Verifying internal reachability.use the ping command to verify basic reachability to the internal gateway and external interface.
Configuring NATConfigure the Guest NAT policy.
root@srx650-1b# set security nat source rule-set Guest-to-untrust from zone guestset security nat source rule-set Guest-to-untrust to zone untrustset security nat source rule-set Guest-to-untrust rule Guest-source-nat match source-address 0.0.0.0/0set security nat source rule-set Guest-to-untrust rule Guest-source-nat then source-nat interface
Configure the Internet Edge NAT policy.
root@srx650-1b# set security nat source rule-set internet_edge-to-untrust from zone internet_edgeset security nat source rule-set internet_edge-to-untrust to zone untrustset security nat source rule-set internet_edge-to-untrust rule internet_edge-source-nat match source-address 0.0.0.0/0set security nat source rule-set internet_edge-to-untrust rule internet_edge-source-nat then source-nat interface
Configuring DHCP services for guest VLANsTo configure DHCP services for guest VLANS:
root@srx650-1b# set system services dhcp pool 10.10.60.0/24 address-range low 10.10.60.11set system services dhcp pool 10.10.60.0/24 address-range high 10.10.60.250set system services dhcp pool 10.10.60.0/24 domain-name xyzcompany.comset system services dhcp pool 10.10.60.0/24 name-server 208.67.222.222set system services dhcp pool 10.10.60.0/24 name-server 208.67.220.220set system services dhcp pool 10.10.60.0/24 router 10.10.60.254
Commit the configuration.
Commit
132 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Verifying NATYou are now configured to be able to access the Internet from your internal user networks. When connecting to the
Internet from inside, the network traffic will be Nat’ed. to view the network sessions and verify that Nat is taking place
properly issue the command show security flow session nat (to see all flows, remove the keyword nat).
the following example shows Nat performed for a session. source address 10.10.10.52 is translated to an external
address of 10.94.191.233 and the destination address is 173.194.79.104.
root@srx> show security flow session natnode0:--------------------------------------------------------------------------Session ID: 15945, Policy name: allow-Internet_Edge-to-internet/5, State:Active, Timeout: 1798, ValidIn: 10.10.10.52/3296 --> 173.194.79.104/80;tcp, If: reth0.22, Pkts: 0, Bytes:0Out: 173.194.79.104/80 --> 10.94.191.233/60064;tcp, If: ge-2/0/1.0, Pkts:36, Bytes: 37380Total sessions: 1
Configuring general settings.set the date and time in the format: YYYYmmDDhhmm.ss
root@srx650-1> set date 201201220830.00Enter configuration modeConfigure the time zone.root@srx650-1# set system time-zone America/Los_Angeles
Configure DNS.
root@srx650-1# set system name-server 10.10.24.100set system domain-name xyzcompany.com
Configure management access.
root@srx650-1# set system services web-management https system-generated-certificateset system services sshdelete system services telnetdelete system services web-management http
Configure LLDP.
root@srx650-1# set protocols lldp interface ge-2/0/0.0set protocols lldp interface ge-11/0/0.0
Commit the configuration.
root@srx650-1# commit
this completes the srX configuration.
Copyright © 2013, Juniper Networks, Inc. 133
Implementation Guide – Vertical Campus
WLA
WLA
WLA
WLA
WLA
WLA
WLA
BUILDING A BUILDING B
EX4200VC-2a
EX3300VC-1a
EX4200VC-3a
LAGLAG
LAGEX8200VC-1b
SRX SeriesCluster
WLCCluster
INTERNET
EX6200-1b
App Servers
Centralized DHCPand other services
EX4500VC-1a LAG
LAG
You are Done!
Figure 23: Configuration Complete
SummaryYou now have a base Vertical Campus network infrastructure providing most commonly used enterprise network
technologies: redundant ethernet, WlaN, and firewall services. the deployment incorporates a simple and scalable
network architecture that provides a reliable foundation on which to base a customized network for your business. the
Juniper Virtual Chassis technology makes it easy to manage because there are few logical devices and protocols to
configure. the modular approach allows you to expand and adapt the network without requiring extensive changes or
forklift upgrades. the infrastructure also supports additional technologies, such as video, collaboration, and other real-
time traffic demands.
134 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Appendix A: Virtual Chassis Virtual Chassis for fixed configuration EX series switchesthe Virtual Chassis flexible scaling solution allows users to connect two or more individual switches together to form
one unit that is managed as a single chassis. Virtual Chassis is supported on the Juniper Networks eX3300, eX4200,
eX4500, and eX8200 series ethernet switches. In this section, however, we discuss only the eX3300, eX4500 and
eX4200 switches.
eX4200 and eX4500 series switches can be interconnected into a Virtual Chassis using the dedicated Virtual Chassis
ports (VCps) on the rear panel of the eX4200 switches, and the dedicated VCps on the Virtual Chassis modules in
the eX4500 switches. You can easily expand the Virtual Chassis configuration to include more member switches.
additional switches are added to an eX4200 or eX4500 Virtual Chassis by cabling together the dedicated VCps.
You can also expand a Virtual Chassis configuration beyond a single wiring closet. Interconnect switches located in
multiple wiring closets or in multiple data center racks by installing sFp, sFp+, or XFp uplink modules, the connect the
uplink module ports on eX4200 member switches or connect the 10-Gigabit ethernet sFp+ network interfaces on the
eX4500 member switches.
Types of Virtual ChassisWe assume that you are configuring at least two or more eX series switches as a single Virtual Chassis. If you are
configuring a standalone eX series switch, then you can perform the basic setup as listed in the Quick start guide that
comes with the switch. after setup, go to the section “Global setup for eX series switches.”
• Dedicated mode
• extended mode
• mixed mode
Dedicated Modethe dedicated mode is the most common method of connecting adjacent eX4500 or eX4200 series switches into a
single Virtual Chassis. Dedicated mode involves interconnecting the switches using the special Virtual Chassis ports
(VCps) at the back of the switch. the two commonly-used methods of cabling when connecting eX series switches
together are: daisy chained and braided ring.
NOTE: although Juniper Networks recommends using one of these two switch topologies; other topologies are
supported (but that is beyond the scope of this document.)
Extended Modethe extended Virtual Chassis method enables switches to be part of a single Virtual Chassis even when the switches
are far apart. You can use the optional uplink modules on the eX4200 switch to connect multiple switches, using
1-Gigabit ethernet and 10-Gigabit ethernet links to provide great flexibility in how a network is configured.
For example, you could have multiple wiring closets on a single floor managed as a single device. this simplifies many
operational tasks, because this reduces the number of individual devices that must be managed.
the eX3300 only uses 10Gbe ports to create a Virtual Chassis, so it is an extended type of Virtual Chassis by default
when compared to the eX4200/eX4500 series products. However, the eX3300 does not require purchase of uplink
modules, instead it has four fixed 10Gbe ports and two of these are already configured to support Virtual Chassis.
eX3300s are typically connected together using DaC cables because of their low cost as a short distance network
medium.
Mixed Modethe mixed -mode Virtual Chassis enables you to interconnect more than one type of switch to act as a single Virtual
Chassis. this is currently only supported between the eX4500 and eX4200 series switches, and provides the ability
to have high-density 10-Gigabit ethernet and 1-Gigabit ethernet in the same Virtual Chassis. this topic provides
configuration examples for each of these Virtual Chassis types.
Virtual Chassis tips for Fixed Configuration eX series switches:
• When you have a two-member Virtual Chassis, we recommend that you disable split detection.
• When you have three or more members in a Virtual Chassis, we recommend that you do not place uplinks on the master
routing engine.
Pre-provisioning of the Virtual ChassisIt is often desirable to deterministically control the role and member ID assigned to each member switch in a Virtual
Chassis. this is accomplished by creating a pre-provisioned configuration. switches can be pre-provisioned by using
the auto provisioning feature to automatically configure the uplink ports as VCps on the switches to be added.
Copyright © 2013, Juniper Networks, Inc. 135
Implementation Guide – Vertical Campus
although it is not mandatory to pre-provision each Virtual Chassis, we recommend it, and this is the process we use in
this guide.
NOTE: If you do not pre-provision the Virtual Chassis, the devices are numbered in the order in which they come up. For
example, if you have five switches in a Virtual Chassis and you turn on the middle switch, say #3, this will be member/
card 0, then you turn on the top switch next, and that will be member/slot 1 and you turn on the other switches at
about the same time the rest of the cards will be randomly filled so you may end up with chassis numbering something
like this.
member 1
member 4
member 0
member 3
member 2
although this is confusing, it is completely operational. You can re-assign slots later to make a more logical chassis, but
it is easier to avoid this in the first place.
prerequisites: the switches need to be set at factory defaults to follow this process.
To pre-provision the Virtual Chassis:1. understand what type of Virtual Chassis you will be setting up: Dedicated, extended or mixed. If you are unsure, see
“types Of Virtual Chassis”.
2. unpack and power up the switch you intend to be member 0. Go through the initial setup process for the switch.
3. Identify the serial numbers of the other switches that will be part of this Virtual Chassis. then decide what their function
will be—either routing engine or line card. You can only have two switches configured as routing engines and one will
be member 0 (the first device we booted up). You can change the roles for devices later if required.
the following is a sample set of configuration statements for a four-member Virtual Chassis, specifying each
member role and slot by serial number.
root@EX4500VC-1a# set virtual-chassis preprovisionedset virtual-chassis member 0 role routing-engineset virtual-chassis member 0 serial-number GX0211411253set virtual-chassis member 1 role routing-engineset virtual-chassis member 1 serial-number GX0211411250set virtual-chassis member 2 role line-cardset virtual-chassis member 2 serial-number FP0211333181set virtual-chassis member 3 role line-cardset virtual-chassis member 3 serial-number FP0211333260
4. Determine if you need to disable split detection.
• If your Virtual Chassis has only two members go to step 5: Disable split detection.
• If your Virtual Chassis has more than two members, go to step 6, step 7, or step 8, as appropriate for the type of
Virtual Chassis you want to set up (dedicated mode, extended mode, or mixed mode).
5. Disable split detection if desired or needed.
NOTE: Virtual Chassis split Detection
split detection is designed to avoid possible dual active-or split-brain conditions. this happens when the chassis
loses multiple Virtual Chassis connections and becomes partitioned into two separate Virtual Chassis. the default
behavior is for the primary routing engine to disable itself and the backup routing engine (re) to promote itself to
master.
In a two-switch Virtual Chassis this is not desirable. For example, if the backup re is powered off, the master re
will stop forwarding traffic. therefore we recommend disabling this feature in a two-switch configuration. For more
information, read about Virtual Chassis in the Junos Os documentation for Juniper Networks eX series ethernet
switches.
the below command disables split detection:
root@EX4500VC-1a# set virtual-chassis no-split-detection
136 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
6. set up a dedicated mode Virtual Chassis.
If you have a dedicated Virtual Chassis (that is, if the members are all of the same type say all eX4200 or all
eX4500 switches) no additional commands are necessary.
• Cable up the remaining members using the VCp ports on the back of the units and power them up.
• Verify that all members are active by running the show virtual-chassis command.
root@EX4500VC-1a> show virtual-chassis
Preprovisioned Virtual ChassisVirtual Chassis ID: 804d.1d7f.fd6aVirtual Chassis Mode: Mixed Mstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt GX0212140825 ex4500-40f 129 Backup Y 1 vcp-1 2 vcp-01 (FPC 1) Prsnt GX0212140845 ex4500-40f 129 Master* Y 3 vcp-1 0 vcp-02 (FPC 2) Prsnt FP0211490796 ex4200-48px 0 Linecard Y 3 vcp-0 0 vcp-13 (FPC 3) Prsnt FP0211490618 ex4200-48px 0 Linecard Y 1 vcp-0 2 vcp-1
• proceed to “Virtual Chassis Base Configuration”
7. set up an extended mode Virtual Chassis.
some Virtual Chassis members are connected together using 1-Gigabit ethernet or 10-Gigabit ethernet ports
configured as Virtual Chassis extended (VCe) ports.
NOTE: 10-Gigabit ethernet uplink ports must be configured as VCe ports. the following is an operational mode
command that will not appear in the configuration. Once this is set, the option to configure these ports when in
configuration mode will not appear.
root@EX4500VC-1a> request virtual-chassis vc-port set pic-slot pic-slot port port member-id memberid.
8. set up a mixed mode Virtual Chassis. (eX4500 and eX4200 combined chassis)
• When setting up a combined eX4500 and eX4200 chassis, the chassis must be specifically configured to support
mixed mode operation. If not, the entire chassis will be active. the command to change modes is an operational
command and therefore does not show up in the configuration. request virtual-chassis mode mixed
• to verify that the chassis is indeed in mixed mode, you can view the status by issuing the operational command
show virtual-chassis and look for line Virtual Chassis mode:
root@EX4500VC-1a> show virtual-chassisPreprovisioned Virtual ChassisVirtual Chassis ID: 762b.b071.4181Virtual Chassis Mode: Mixed
• You can now cable up the remaining members using the VCp ports on the back of the units and power them up.
Verify that all of the members are active by running the show virtual-chassis command.
Copyright © 2013, Juniper Networks, Inc. 137
Implementation Guide – Vertical Campus
root@EX4500VC-1a> show virtual-chassis
Preprovisioned Virtual ChassisVirtual Chassis ID: 804d.1d7f.fd6aVirtual Chassis Mode: Mixed Mstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt GX0212140825 ex4500-40f 129 Backup Y 1 vcp-1 2 vcp-01 (FPC 1) Prsnt GX0212140845 ex4500-40f 129 Master* Y 3 vcp-1 0 vcp-02 (FPC 2) Prsnt FP0211490796 ex4200-48px 0 Linecard Y 3 vcp-0 0 vcp-13 (FPC 3) Prsnt FP0211490618 ex4200-48px 0 Linecard Y 1 vcp-0 2 vcp-1 3
To change a Virtual Chassis back to non-mixed mode issue the following command.
request virtual-chassis mode mixed disable
Proceed to “Virtual Chassis Base Configuration”
Virtual Chassis Base Configurationenter the following commands for all Virtual Chassis:
Commit Synchronizethis ensures that whenever you issue a commit command, it is synchronized with all of the other members of the
Virtual Chassis. Without this command in the configuration, you should issue a commit synchronize command after
every change instead of just the commit command.
set system commit synchronize
Non-stop Bridgingthis command replicates bridging protocol information between master and backup routing engines.
set ethernet-switching-options nonstop-bridging
Graceful SwitchoverGraceful switchover should be configured on any multichassis Virtual Chassis to ensure that the master and backup
routing engines are in sync.
set chassis redundancy graceful-switchover
Layer 3 base configuration itemsConfigure the Default Static Route
root@host# set routing-options static route 0.0.0.0/0 next-hop <IP address>
Configure nonstop active routing
root@host# set routing-options nonstop-routing
138 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Appendix B: Configuring DHCP on EX Series Ethernet SwitchesIf you do not have a central DHCp server or need a temporary DHCp solution, you can configure the eX series ethernet
switches to act as a DHCp server.
NOTE: the srX series firewalls are configured to provide DHCp information to guest wireless users in the tested
Network.
In the tested network design presented in this document, the core switches would be used as DHCp servers because it
has Ip addresses on each of the subnets in the network.
to enable the eX series to act as a DHCp server you need the following:
• Ip interface configured on each VlaN to receive DHCp
• Ip address pool and pool range to be allocated to users on each VlaN to receive DHCp
• Default gateway for users on each VlaN
• Domain name for users
• Name server for users
the sample that follows shows DHCp configured for the management VlaN presented in this guide. We already have
the Ip address configured as 10.10.28.1 for this VlaN.
set system services dhcp pool 10.10.28.0/24set system services dhcp pool 10.10.28.0/24 address-range low 10.10.28.11 high 10.10.28.250set system services dhcp pool 10.10.28.0/24 router 10.10.28.1set system services dhcp pool 10.10.28.0/24 domain-name xyzcompany.comset system services dhcp pool 10.10.28.0/24 name-server 10.10.24.100
To view DHCP statistics
show system services dhcp statistics
To view DHCP bindings
show system services dhcp binding
Copyright © 2013, Juniper Networks, Inc. 139
Implementation Guide – Vertical Campus
Appendix C: EX8200 Virtual Chassis Overviewthe eX8200 Virtual Chassis is similar to the extended Virtual Chassis. this section details the connections and
processes required to set up the eX8200 Virtual Chassis for Building B. For more information, see Best Practice Guidelines for Deploying EX8200 Virtual Chassis Configurations.
Virtual Chassis technology was first introduced on the Juniper Networks eX4200 line of ethernet switches. Virtual
Chassis technology allows up to 10 interconnected eX4200 switches to operate as a single, unified, high bandwidth
device. these interconnections can be made using any combination of dedicated high-speed Virtual Chassis ports
(VCps) on the switch’s rear panel or front panel gigabit ethernet (Gbe) or 10Gbe fiber links.
eX8200 Virtual Chassis technology was first introduced with the Juniper Networks Junos® operating system 10.4
release, enabling up to two eX8200 chassis to be interconnected as a single logical device – with the ability to expand
to four.
the eX8200 Virtual Chassis architecture consists of redundant external routing engines – the Xre200 external
routing engine – capable of managing up to four eX8200 line Card Chassis (lCCs) connected using 1Gbe or 10Gbe
VCps and operating as a single chassis. unlike other virtual system technologies, eX8200 Virtual Chassis technology
separates the controller of the virtual system from the chassis routing engine. the Xre200s connect to the eX8200
chassis via the 1Gbe out-of-band
management ports on the routing engine modules are installed in the modular switch, forming a single Virtual Chassis
configuration as shown in Figure 24. these interconnections, known as dedicated VCp links, constitute the control
plane connection and do not carry data traffic.
Intra-XRE Connection for HA (1GbE)
XRE-LCC — Active XRE to Internal Routing Engine Connection (1GbE)
XRE-LCC — Standby XRE to Internal Routing Engine Connection (1GbE)
Intra-VC — 10GbE LAG Connection
ActiveXRE200
StandbyXRE200
EX8200Virtual Chassis
LAG
Figure 24: EX8200 Virtual Chassis with XRE200 Connected to Each Member
Figure 24 shows a fully meshed two-member Virtual Chassis configuration with two Xre200s and a single 10Gbe link
aggregation Group (laG) between lCCs. In an eX8200 Virtual Chassis configuration, each eX8200 chassis becomes
an lCC and are interconnected through eX8200-8Xs line cards using either a 10Gbe link or a laG bundle with up
to twelve 10Gbe line-rate links. this connectivity serves two functions: to allow data traffic between lCCs for single
homed access devices, and to pass control traffic between the eX8200 chassis in case of the failure of all dedicated
VCp links. the eX8200-8Xs line cards use small form-factor pluggable transceivers (sFp+) that can support
connections up to 40 km in distance. eX8200-based Virtual Chassis configurations can span a large metropolitan area.
If the Virtual Chassis members are located in the same or adjacent racks, low-cost direct attach cables (DaCs) can be
used as the interconnect mechanism. members of an eX8200 Virtual Chassis configuration can include a mix of the
Juniper Networks eX8208 ethernet switch (eight-slot) and eX8216 ethernet switch (16-slot).
EX8200 Virtual Chassis Portsa Virtual Chassis port (VCp) is any port that is capable of sending and receiving Virtual Chassis Control protocol traffic
to create, monitor, and maintain the Virtual Chassis configuration. there are three types of VCps on the eX8200—Inter-
Xre200, Xre-lCC, and intra-Virtual Chassis. the Inter-Xre200 and Xre-lCC are called “dedicated” VCps as they carry
control traffic, while intra-Virtual Chassis ports carry data traffic between lCCs. In some cases, intra-Virtual Chassis
ports may carry data as well as control traffic.
140 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Virtual Chassis Ports on the XRE200 External Routing Engineall Gbe ports on the Xre200 Virtual Chassis Control Interface (VCCI) modules are VCps. any of the VCps can be used
to connect eX8200 switches to the Xre200 to form a Virtual Chassis configuration and also to connect Xre200s
together to provide redundancy within the Virtual Chassis configuration. any link connecting an Xre200 to an eX8200
switch or to another Xre200 is a VCp link. No user configuration is required to configure these VCp links. all VCp links
on the Xre200 only carry Virtual Chassis Control protocol traffic.
Virtual Chassis Ports on EX8200 Member Chassisan eX8200 switch in standalone mode has no VCps. When a standalone eX8200 switch is enabled to function as a
Virtual Chassis switch, the management ports on the switch’s routing engines are converted into dedicated Xre-lCC
Virtual Chassis ports that carry the Virtual Chassis Control protocol traffic over the Xre-lCC VCp links. No further
configuration is required to configure these VCp links.
lastly, the intra-Virtual Chassis ports, which can only reside on the eX8200 switches, can only be configured on the
10Gbe eX8200-8Xs line cards. VCps on the 10Gbe eX8200-8Xs line card are enabled in pairs, i.e., ports that reside
on the same packet Forwarding engine (pFe). the eX8200-8Xs line card offers eight ports—0 through 7—with two
contiguous ports residing on the same pFe. If port 0 is enabled as a VCp, Junos Os will automatically enable port 1 as a
VCp. Intra-Virtual Chassis links between member switches in Virtual Chassis configuration are automatically configured
to form a single laG; no further user configuration is required. It is possible to configure up to 12 ethernet ports as VCps
to form a laG between member switches in a Virtual Chassis configuration.
For highest availability it is recommended to have a two-member laG at a minimum. However, a four-member laG
with two pairs of port members residing on different line cards is preferred.
table 16 provides a summary of differences between the eX8200VC and the eX4500/eX4200 Virtual Chassis
implementation.
Table 16: EX4200/4500 and EX8200 Side by Side Comparison
Category EX4200 Virtual Chassis EX8200 Virtual Chassis
Native Virtual Chassis support Inherent support for Virtual Chassis by the Forwarding engine.
Virtual Chassis emulated using Xre200.
Virtual Chassis ports Fixed Virtual Chassis ports. any 10Gbe port on 8Xs line card can be aVirtual Chassis port.
Virtual Chassis mastership any member is eligible to be a master or backup. routing engine has an election mechanism to choose master and backup.
Body Column
Virtual Chassis management all members are managed from the master member
all members are managed from master Xre200.
link aggregation Group laG load balancing is hash based. laG load balancing is chassis-local.
Virtual Chassis path calculation every pFe is a node in the Virtual Chassis topology.
every chassis is a node in the Virtual Chassis topology.
table 17 shows the chassis member numbering by device role.
Table 17: EX8200 Virtual Chassis Member IDs and Roles
Device Role Member IDS
eX8208 or eX8216 switch line card 0-7
Xre200 master or backup routing engine 8-9
table 18 illustrates the port numbering used by the eX8200VC based on member number and type of chassis.
Copyright © 2013, Juniper Networks, Inc. 141
Implementation Guide – Vertical Campus
Table 18: EX8200VC FPC and Interface Numbering
Member ID FPC Numbering Network Port Interface Range
0 0 through 15 for eX8216 0 through 7 for eX8208
xe-0/0/0 to xe-15/0/7 xe-0/0/0 to xe-7/0/7
1 16 through 31 for eX8216 16 through 23 for eX8208
xe-16/0/0 to xe-31/0/7 xe-16/0/0 to xe-23/0/7
2 32 through 47 for eX8216 32 through 39 for eX8208
xe-32/0/0 to xe-47/0/7 xe-32/0/0 to xe-39/0/7
3 48 through 63 for eX8216 48 through 55 for eX8208
xe-48/0/0 to xe-63/0/7 xe-48/0/0 to xe-55/0/7
For more details on the eX8200 Virtual Chassis please see the implementation guide Best Practice Guidelines for Deploying EX8200 Virtual Chassis Configurations or the operators manual located at www.juniper.net
142 Copyright © 2013, Juniper Networks, Inc.
Implementation Guide – Vertical Campus
Appendix D: References and Next Steps
General References• technical documentation for all Juniper products
www.Juniper.net/customers/support/
• Juniper Day One Books for all products
www.Juniper.net/us/en/community/junos/training-certification/day-one/
• Juniper Networks Books
www.Juniper.net/us/en/training/jnbooks/
EX Series Specific References • Implementation Guide: Best practice Guidelines for Deploying eX8200 Virtual Chassis Configurations
• Implementation Guide: Virtual Chassis technology Best practice
• Day One: Configuring eX series ethernet switches
• tested Design: Juniper Networks Horizontal Campus tested Design Guide
• Book: Junos enterprise switching
QoS References• Implementation Guide: enabling Class of service on eX series switches in a Campus laN
• Implementation Guide:
• Day One: Deploying Basic Qos
WLAN References• Day One: Deploying a secure Wireless laN
• tested Design: Juniper Networks Horizontal Campus tested Design Guide
• srX references
• Day One: Deploying srX series Gateways
• Books: Junos security
Copyright © 2013, Juniper Networks, Inc. 143
Implementation Guide – Vertical Campus
About Juniper NetworksJuniper Networks is in the business of network innovation. From devices to data centers, from consumers to cloud
providers, Juniper Networks delivers the software, silicon and systems that transform the experience and economics
of networking. the company serves customers and partners worldwide. additional information can be found at
www.juniper.net.
Implementation Guide – Vertical Campus
144 Copyright © 2013, Juniper Networks, Inc.
8010091-003-eN may 2013
Copyright 2013 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.
APAC and EMEA Headquarters
Juniper Networks International B.V.
Boeing avenue 240
1119 pZ schiphol-rijk
amsterdam, the Netherlands
phone: 31.0.207.125.700
Fax: 31.0.207.125.701
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