You are on page 1of 144

Implementation Guide

VertICal Campus

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.

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Design Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Wired LAN Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 WLAN Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 SRX Series Service Gateway Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Virtual Chassis for Collapsed Backbone Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Subnets and VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Class of Service and Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Forwarding Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Random Early Detection and Congestion Avoidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Remarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Class of Service Used in Design Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Wired LAN Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Building B: Configuring the Campus Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 EX8200 Virtual Chassis Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Verifying and Upgrading the Software Version for XRE200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Verifying and Upgrading the Software Version for EX8200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Configuring the EX8200 for Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Preprovisioning the XRE200 for Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Assembling the EX8200 Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Configuring Virtual Chassis Ports on the EX8200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Configuring Global Settings for the Core EX8200 Virtual Chassis Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Configuring Layer 2 Settings on EX8200 Virtual Chassis Core Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 Configuring Layer 3 Settings for the EX8200 Virtual Chassis Core Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Configure Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Verifying Class of Service Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Building B: Configuring the Access Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Software Version /Upgrading the EX6200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 EX6200 Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Configuring Global Settings for the EX6210 Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Configuring the EX6200 Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Configuring Layer 2 Settings for EX6200 Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Configure Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Verifying Class of Service Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Building A: Configuring the core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 EX4500 Virtual Chassis Procedure Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Configuring Global Settings for the Core Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Configuring a Virtual Chassis for the Mixed Mode Core Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Configuring Layer 2 Settings For Mixed Mode Core Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Configuring Layer 3 Settings For Mixed Mode Core Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Configure Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Verifying Class of Service Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Building A: Configuring the Access Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Configuring EX4200 as Extended Mode Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Configuring Global Settings for the Core Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Configuring an Extended Mode Virtual Chassis for the EX4200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 To configure a Virtual Chassis for the core switch: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Configuring Layer 2 Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72 Configure Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 Verifying Class of Service Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Building A: Configuring EX3300 Access Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 Configuring Global Settings for the Access Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Configuring an EX3300 Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Configuring Layer 2 Settings for EX3300 Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Configure Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Building A: Configuring EX4200 Dedicated Mode Access switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Configuring Global Settings for the Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Configuring a Dedicated Mode Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Configuring Layer 2 Settings for EX4200 Dedicated Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Configure Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Wireless LAN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Wireless Setup Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Wireless LAN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Pre-requisites for WLAN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Running Quick start on WLC2800-1b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Configuring VLANs and 802 .1q trunking for WLC2800-1b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107 Running Quickstart on WLC2800-2b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Configuring VLANs and 802 .1q trunking for WLC2800-2b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Installing Ringmaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Configuring WLCs and WLAs using Ringmaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Add devices to a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Uploading WLC2800-1b into RingMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Uploading WLC2800-2b into RingMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Creating a Mobility Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Activating Changes from the cluster wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Creating a Cluster in the Mobility Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 WLC2800-1b VLAN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 WLC2800-2b VLAN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Configuring Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Cluster RADIUS configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Cluster Guest Wireless Authentication Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Configuring the RADIUS Authentication Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Creating a RADIUS Server Group for guest users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Configuring the SmartPass authentication options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Setting up VLAN Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 VLAN Profile for Building A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 VLAN Profile Building B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Radio Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Creating Radio Profiles for building A and Building B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Setting up Wireless Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Setting up Building A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Setting up Building B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Setting up Wireless Voice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Building A Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Building B Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Guest Wireless setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Adding WLAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Building B WLA configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Preparing Clients for Wireless Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Configuring a Client for Guest Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Configuring a Client for Corporate Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 SRX Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123 Configuring the SRX Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124 Configuring Security Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Configuring Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Configuring Routing and OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Configuring NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Configuring DHCP services for guest VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133 Appendix A: Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134 Appendix B: Configuring DHCP on EX Series Ethernet Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Appendix C: EX8200 Virtual Chassis Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Appendix D: References and Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142 About Juniper Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

List of Figures
Figure 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 Tables
Table 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.

Implementation Guide Vertical Campus

Introduction
the 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

Scope
this 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 Considerations
the 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 Components
the network detailed in this document is divided into three separate functional blocks or moduleslaN 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.

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Table 1: Equipment and Software


Model
eX-Xre200-aC

Software
12.1r9

Description
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 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 8-port 10 Gbe sFp+ line card; requires sFp+ optics sold separately 40-port Gbe / 10Gbe line card; requires sFp and/or sFp+ optics sold separately 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 48-port 10/100/1000Base-t (48 poe ports) + 930 W aC psu. Includes 50cm Virtual Chassis cable. 930 W poe+ aC power supply unit (psu) 2-port 10G sFp+ / 4-port 1G sFp uplink module eX3300 48-port 10/100/1000Base-t (48 poe+ ports) with 4 sFp+ uplink ports (optics not included) eX3300 24-port 10/100/1000Base-t (24 poe+ ports) with 4 sFp+ uplink ports (optics not included) eX3300 48-port 10/100/1000Base-t with 4 sFp+ uplink ports (optics not included) sFp+ 10-Gigabit ethernet Direct attach Copper (twinax copper cable) 1 m 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 16 port 10/100/1000Base-t XpIm WlaN controller with two 10Gbe XFp ports and 8 x 1000Base-t (rJ-45 and sFp) ports, including single psu and 64 ap license. 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.

eX8208-reDuND-aC

12.1r9

eX8200-8Xs eX8200-40Xs eX4500-40F-VC1-FB

n/a n/a 12.1r9

eX4200-48p eX-pWr2-930-aC eX-um-2X4sFp eX3300-48p eX3300-24p eX3300-48t eX-sFp-10Ge-DaC-1m srX650-Base-sre6-645ap

12.1r9 n/a n/a 12.1r9 12.1r9 12.1r9 n/a 12.1r9

srX-Gp-16Ge

n/a

WlC2800* Wla532-us*

7.7.1.6 n/a

Wlm-rmts-10

7.7.1.3.0

*When estimating your wireless needs, 2530 users per ap is a good place to start for most wireless deployments. For highest performance wireless, one ap per 1015 users is the recommended starting value.

Wired LAN Infrastructure


the 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.

Implementation Guide Vertical Campus

BUILDING A
EX4200VC-3a WLA WLA WLA EX4200VC-2a WLA
LAG

BUILDING B

EX6200-1b WLC Cluster

EX3300VC-1a WLA

Centralized DHCP and other services App Servers

WLA
LAG LAG

WLA

SRX Series Cluster INTERNET


LAG

EX4500VC-1a

LAG

EX8200VC-1b

Figure 1: Overview of the Tested Network

Building A
the 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 B
Building 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.

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

WLAN Infrastructure
the 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.
WLA xyzcompany_guest WLAN

Tra c Tunneled to/from WLC

EX Series Switch

WLC places user tra c into guest_wirelessVLAN (60)

SRX Series is the only gateway for guest_wireless VLAN (60) INTERNET

WLC Cluster

SRX Series Cluster

WLC uses centralized switching for xyzcompany_guest SSID, tunneling all tra c and forwarding to WLC.

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.
WLA xyzcompany_internal or xyzcompany_voice WLANs Trunk Port

EX Series Switch

WLC places user tra c into guest_wirelessVLAN (60)

File Server

VoIP Phone

WLAs use local switching for xyzcompany_internal and xyzcompany_voice WLAN SSIDs. WLAs are congured with trunk ports so they can place user tra c directly onto the correct VLAN without tunneling tra c to the WLC.

Figure 3: Local Switching Overview

Copyright 2013, Juniper Networks, Inc.

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.
EX Series Switch

WLA
Primary WLC Secondary WLC

WLA

Wireless LAN Controller Cluster The primary WLC is the conguration point for the network and automatically load balances WLAs between the WLCs in the cluster. Each WLA forms two WLC connections a primary WLC connection and a backup WLC connection. This provides non-stop wireless performance in case of failure.

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 WlCsone 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 Infrastructure


the 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.

MANAGEMENT ZONE
management_1a management_1b

INTERNET EDGE ZONE


data_wired_1b data_wireless_1a servers_1b voip_wired_1a voip_wireless_1a access_points_1a internet_edge data_wired_1a data_wireless_1b servers_2b voip_wired_1b voip_wireless_1b access_points_1b SRX650-1b SERVICE PROVIDER 1 INTERNET SERVICE PROVIDER 2 SRX650-2b

UNTRUST ZONE
EX Series Switch

GUEST ZONE
guest_wireless

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.

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Clustering SRX Service Gateways


You 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 FlowNormal


SRX650-1b
ge-4/0/1 ge-2/0/0 ge-2/0/1 10.94.44.2

SERVICE PROVIDER 1

Worldwide Web, FTP, email, etc.

INTERNET
ge-20/0/1 ge-11/0/0 ge-11/0/2 10.94.44.6

EX8200 Virtual Chassis

SRX650-2b

SERVICE PROVIDER 2

SRX Tra c FlowSRX650-1b Reth Failure


SRX650-1b
ge-4/0/1 ge-2/0/0 ge-2/0/1 10.94.44.2

SERVICE PROVIDER 1

Worldwide Web, FTP, email, etc.

INTERNET
ge-20/0/1 ge-11/0/0 ge-11/0/2 10.94.44.6

EX8200 Virtual Chassis

SRX650-2b

SERVICE PROVIDER 2

SRX Tra c FlowSRX650-1b Failure


SRX650-1b
ge-4/0/1 ge-2/0/0 ge-2/0/1 10.94.44.2

SERVICE PROVIDER 1

Worldwide Web, FTP, email, etc.

INTERNET
ge-20/0/1 ge-11/0/0 ge-11/0/2 10.94.44.6

EX8200 Virtual Chassis

SRX650-2b

SERVICE PROVIDER 2

SRX Tra c FlowService Provider 1 Failure


SRX650-1b
ge-4/0/1 ge-2/0/0 ge-2/0/1 10.94.44.2

SERVICE PROVIDER 1

Worldwide Web, FTP, email, etc.

INTERNET
ge-20/0/1 ge-11/0/0 ge-11/0/2 10.94.44.6

EX8200 Virtual Chassis

SRX650-2b

SERVICE PROVIDER 2

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.

10

Copyright 2013, Juniper Networks, Inc.

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 sessionsthey 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 Design


traditional 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 closetsin the same or different buildingscan be easily combined to reduce the total number of managed devices.

Subnets and VLANs


It 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 831 are dedicated to wired data and voice. the tested design uses only four of these VlaNs, leaving plenty of room for future expansion. VlaNs 3242 are dedicated for corporate wireless data and voice access. the tested design uses only four of these VlaNs VlaNs 4459 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 VlaNit 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.

Copyright 2013, Juniper Networks, Inc.

11

Implementation Guide Vertical Campus

Table 2: Campus VLANs


VLAN ID
8 12 20 24 32 36 40 42 44 46 48 50 51 52 54 60

VLAN Name
data_wired_1b data_wired_1a voip_wired_1a voip_wired_1b data_wireless_1a data_wireless_1b voip_wireless_1a voip_wireless_1b internet_edge servers_1b servers_2b management_1b management_1a access_points_1b access_points_1a guest_wireless

Subnet
10.10.8.0/22 10.10.12.0/22 10.10.20.0/22 10.10.24.0/22 10.10.32.0/22 10.10.36.0/22 10.10.40.0/23 10.10.42.0/23 10.10.44.0/24 10.10.46.0/24 10.10.48.0/24 10.10.50.0/24 10.10.51.0/24 10.10.52.0/24 10.10.54.0/24 10.10.60.0/24

Table 3: VLANs by Building


Building A VLANs VLAN ID
12 24 36 42 51 54

Building B VLANs Subnet


10.10.12.0/22 10.10.24.0/22 10.10.36.0/22 10.10.42.0/23 10.10.51.0/24 10.10.54.0/24

VLAN Name
data_wired_1a voip_wired_1a data_wireless_1a voip_wireless_1a management_1a access_points_1a

VLAN ID
8 20 32 40 44 46 48 50 52 60

VLAN Name
data_wired_1b voip_wired_1b data_wireless_1b voip_wireless_1b internet_edge servers_1b servers_2b management_1b access_points_1b guest_wireless

Subnet
10.10.8.0/22 10.10.20.0/22 10.10.32.0/22 10.10.40.0/23 10.10.44.0/24 10.10.46.0/24 10.10.48.0/24 10.10.50.0/24 10.10.52.0/24 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 Junipers 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.

12

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Table 4: Building A VLAN and Device Map


Building A Device and VLAN Map VLAN ID
12 20 32

VLAN Name
data_wired_1a voip_wired_1a data_wireless_1a

Subnet
10.10.12.0/22 10.10.20.0/22 10.10.32.0/22

EX4200VC-1a Ip Ip
Ip Ip

EX3300VC-1a VlaN VlaN


VlaN VlaN

EX4200VC-2a VlaN VlaN


VlaN VlaN

EX4200VC-3a VlaN VlaN


VlaN VlaN

WLA

VlaN VlaN

40 51
54

voip_wireless_1a management_1a
access_points_1a

10.10.40.0/23 10.10.51.0/24
10.10.54.0/24

Ip Ip

Ip VlaN

Ip VlaN

Ip VlaN Ip

Table 5: Building B VLAN and Device Map


Building B Device and VLAN Map VLAN ID 8
24 36

VLAN Name data_wired_1b


voip_wired_1b data_wireless_1b

Subnet 10.10.8.0/22
10.10.24.0/22 10.10.36.0/22

EX8200VC-1b Ip Ip Ip Ip Ip Ip Ip Ip Ip VlaN

EX6200 -1b VlaN VlaN VlaN VlaN

WLC

SRX

WLA

VlaN VlaN Ip

42 44
46 48 50 52

voip_wireless_1b internet_edge
servers_1b servers_2b management_1b access_points_1b guest_wireless

10.10.42.0/23 10.10.44.0/24
10.10.46.0/24 10.10.48.0/24 10.10.50.0/24 10.10.52.0/24 10.10.60.0/24

Ip VlaN

Ip

Ip
Ip

60

Ip

Ip

Class of Service and Quality of Service


this 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 users 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 vendors 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.

Copyright 2013, Juniper Networks, Inc.

13

Implementation Guide Vertical Campus

Forwarding Class
a 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.

Classification
Classification 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 Classification
If 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 Classification


Ba 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 Classification
the 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 packetit is less commonly applicable to non-Ip traffic typesand 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.

Policing
policing 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.

14

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Random Early Detection and Congestion Avoidance


random 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 traffichigh value or sensitive to loss, latency, or jitteris 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.

Shaping
shaping 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 shapers 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.

Scheduling
scheduling 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.

Remarking
ethernet, 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 Example


the 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.

Copyright 2013, Juniper Networks, Inc.

15

Implementation Guide Vertical Campus

Table 6: CoS by Device Role


Device Role
Core access

Classification
Ba Ba

Congestion Management
-

Scheduling
X X

Rate Shaping
X X

Remarking
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
control voice business-app server-bulk best-effort

Queue #
7 5 3 1 0

DSCP
NC1/Cs6 NC2/Cs7 eF aF21 aF11 n/a

Buffer
5% 5% 40% 30% remainder

Transmit Rate
n/a n/a 40% 30% remainder

Rate Shaping
5% 5% n/a n/a 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.

Implementation
each 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 Deployment


Building B: Configuring the Campus Core
the 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.

16

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

BUILDING A
EX4200VC-3a WLA WLA WLA EX4200VC-2a WLA
LAG

BUILDING B

EX6200-1b WLC Cluster

EX3300VC-1a WLA

Centralized DHCP and other services App Servers

WLA
LAG LAG

WLA

SRX Series Cluster INTERNET


LAG

EX4500VC-1a

LAG

EX8200VC-1b

You are Here

Figure 7: Configuring the EX8200VC

For reference, detailed connection information for Building B is provided in Figure 8.


Master RE XRE200-1b
Member 8 ge-0/0/0 ge-0/0/2 ge-0/0/1 ge-0/0/0 ge-0/0/2 ge-0/0/1

Backup RE XRE200-2b
Member 9

SRE1-me0 SRE0-me0

SRE0-me0 xe-16/0/0 xe-18/0/0 SRE1-me0 ge-2/0/0 Control Link

SRX650-1b

To Building A

ge-2/0/1 Fabric Link

xe-0/0/0 xe-2/0/0

EX8200-1b
Member 0 Line Card 0 (slots 0-15)

xe-0/0/6 xe-0/0/7 xe-1/0/6 xe-1/0/7 xe-2/0/6 xe-2/0/7 xe-1/0/5 xe-1/0/4

xe-16/0/6 xe-16/0/7 xe-17/0/6 xe-17/0/7 xe-18/0/6 xe-18/0/7 xe-17/0/4 xe-17/0/5

ge-0/0/1 ge-9/0/1

ge-0/0/2 ge-9/0/2

INTERNET

ge-11/0/0

ge-11/0/2

EX8200-2b
Member 1 Line Card 1 (slots 16-31)

SRX650-2b

ge-4/0/0

ge-20/0/0

WLC2800-1b

port 8

WLC2800-2b

port 8 xe-5/0/0 xe-4/0/0 xe-4/0/1 xe-5/0/1

EX6200-1b

Figure 8: Building B Connection Details

Copyright 2013, Juniper Networks, Inc.

17

Implementation Guide Vertical Campus

EX8200 Virtual Chassis Configuration


the 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.
XRE200-1b
ge-0/0/1 ge-0/0/0 ge-0/0/2 ge-0/0/0 ge-0/0/2

XRE200-2b
ge-0/0/1

SRE1-me0 SRE0-me0 xe-0/0/6 xe-0/0/7 xe-1/0/6 xe-1/0/7 xe-2/0/6 xe-2/0/7

SRE0-me0 SRE1-me0 xe-16/0/6 xe-16/0/7 xe-17/0/6 xe-17/0/7 xe-18/0/6 xe-18/0/7

EX8200-1b

EX8200-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 XRE200


the Os version used for the tested network is Junos Os 12.1r9, 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: root Logging to master . JUNOS 11.4R1.6 built 2011-11-15 11:14:01 UTC root@:RE:0%
5. Verify that the Xre is running the correct Os version (12.1r9 for this validation). If the version is correct, verify the next Xre by repeating steps 14.

18

Copyright 2013, Juniper Networks, Inc.

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: root Logging to master . JUNOS 11.4R1.6 built 2011-11-15 11:14:01 UTC root@:RE:0%
Type cli at the % prompt.

root@:RE:0% cli {master:0} root>


Enter configuration mode by typing configure or edit.

root> configure Entering configuration mode {master:0}[edit] root#


At the # prompt, configure the password.

root# set system root-authentication plain-text-password New 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 remaining devices.

Copyright 2013, Juniper Networks, Inc.

19

Implementation Guide Vertical Campus

Verifying and Upgrading the Software Version for EX8200


the 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.1r9, 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: root Logging to master . JUNOS 12.1R9 built 2011-11-15 11:14:01 UTC root@: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 13.

Type cli at the % prompt.

root@:RE:0% cli {master:0} root>


Enter configuration mode by typing configure or edit.

root> configure Entering configuration mode {master:0}[edit] root#


At the # prompt, configure the password.

root# set system root-authentication plain-text-password New 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.

20

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Configuring the EX8200 for Virtual Chassis


On 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-switchover set system commit synchronize set routing-options nonstop-routing set 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% cli warning: 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.132f Virtual Chassis Mode: Enabled Member ID 0 (FPC 0-15) Status Prsnt Serial No Model BT0910434033 ex8208

Mastership priority 0

Neighbor List Role ID Interface Linecard*

Repeat these steps for the second EX8200 Virtual Chassis.

Copyright 2013, Juniper Networks, Inc.

21

Implementation Guide Vertical Campus

Preprovisioning the XRE200 for Virtual Chassis


It 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 set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis

preprovisioned member 8 role routing-engine member 8 serial-number 042011000023 member 9 role routing-engine member 9 serial-number 042011000036 member 0 role line-card member 0 serial-number BT0910433933 member 1 role line-card 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 nosplit-detection command. If you are not familiar with how split-detection works, review the split-detection section in appendix a.
Master RE XRE200-1b
Member 8 ge-0/0/1 ge-0/0/0 ge-0/0/2

Backup RE 1 2 3
ge-0/0/0 ge-0/0/2

XRE200-2b
ge-0/0/1 Member 9

SRE1-me0 SRE0-me0 xe-0/0/6 xe-0/0/7 xe-1/0/6 xe-1/0/7 xe-2/0/6 xe-2/0/7

SRE0-me0 SRE1-me0

EX8200-1b
Member 0 Line Card 0 (slots 0-15)

xe-16/0/6 xe-16/0/7 xe-17/0/6 xe-17/0/7 xe-18/0/6 xe-18/0/7

EX8200-2b
Member 1 Line Card 1 (slots 16-31)

Connect XRE200-1b and XRE200-2b together using ge-0/0/0 interfaces

2 Connect XRE200-1b ge-0/0/1 to EX8200-1b SRE0 me0, and ge-0/0/2 to EX8200-2b SRE0 me0 3 Connect XRE200-2b ge-0/0/1 to EX8200-1b SRE1 me0, and ge-0/0/2 to EX8200-2b SRE1 me0 4 Congure VCP ports on EX8200s and connect together

Figure 10: EX8200 Interface Connections

22

Copyright 2013, Juniper Networks, Inc.

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 Chassis Virtual Chassis ID: 1716.387c.f292 Virtual Chassis Mode: Enabled Member 0 (FPC 1 (FPC 8 (FPC 9 (FPC ID 0-15) 16-31) 128-143) 144-159) Status NotPrsnt NotPrsnt Prsnt Prsnt Serial No BT0910433933 BT0910434033 042011000023 042011000036 Model ex8208 ex8208 ex-xre ex-xre

Mastership priority 129 129

Role

Neighbor List ID Interface vcp-0/0 vcp-0/0

Master* 9 Backup 8

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 Chassis Virtual Chassis ID: 1716.387c.f292 Virtual Chassis Mode: Enabled Member ID 0 (FPC 0-15) 1 (FPC 16-31) Status Prsnt Prsnt Serial No Model BT0910433933 ex8208 BT0910434033 ex8208 042011000023 ex-xre 042011000036 ex-xre

8 (FPC 128-143) Prsnt 9 (FPC 144-159) Prsnt

Mastership Neighbor List priority Role ID Interface 0 Linecard 8 vcp-0/0 9 vcp-0/1 0 Linecard 8 vcp-0/0 9 vcp-0/1 129 Master* 9 vcp-0/0 0 vcp-1/0 1 vcp-1/1 129 Backup 8 vcp-0/0 0 vcp-1/0 1 vcp-1/1

Copyright 2013, Juniper Networks, Inc.

23

Implementation Guide Vertical Campus

Configuring Virtual Chassis Ports on the EX8200


Only 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 1631 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 0 member0: -------------------------------------------------------------------------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 0 member0: -------------------------------------------------------------------------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 0 member0: -------------------------------------------------------------------------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 1 member1: -------------------------------------------------------------------------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 1 member0: -------------------------------------------------------------------------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 1 member0: -------------------------------------------------------------------------This will also convert FPC slot 1 PIC slot 0 Port 7 to virtual chassis port.

24

Copyright 2013, Juniper Networks, Inc.

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-port member0: -------------------------------------------------------------------------Interface Type Trunk Status Speed Neighbor or ID (mbps) ID Interface Slot/PIC/Port vcp-0/0 Dedicated -1 Up 1000 8 vcp-1/0 vcp-0/1 Dedicated -1 Up 1000 9 vcp-1/0 0/0/6 Configured 3 Up 10000 1 vcp-0/0/6 0/0/7 Configured 3 Up 10000 1 vcp-0/0/7 1/0/6 Configured 3 Up 10000 1 vcp-1/0/6 1/0/7 Configured 3 Up 10000 1 vcp-1/0/7 2/0/6 Configured 3 Up 10000 1 vcp-2/0/6 2/0/7 Configured 3 Up 10000 1 vcp-2/0/7 member1: -------------------------------------------------------------------------Interface Type Trunk Status Speed Neighbor or ID (mbps) ID Interface Slot/PIC/Port vcp-0/0 Dedicated -1 Up 1000 8 vcp-1/1 vcp-0/1 Dedicated -1 Up 1000 9 vcp-1/1 0/0/6 Configured 3 Up 10000 0 vcp-0/0/6 0/0/7 Configured 3 Up 10000 0 vcp-0/0/7 1/0/6 Configured 3 Up 10000 0 vcp-1/0/6 1/0/7 Configured 3 Up 10000 0 vcp-1/0/7 2/0/6 Configured 3 Up 10000 0 vcp-2/0/6 2/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-switchover set system commit synchronize set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging commit 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 its time to configure it.

Copyright 2013, Juniper Networks, Inc.

25

Implementation Guide Vertical Campus

Configuring Global Settings for the Core EX8200 Virtual Chassis Switch
Connect 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: root Logging to master . JUNOS 12.1R9 built 2011-11-15 11:14:01 UTC root@: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> configure Entering 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 member8 set apply-groups member9
Configure management access.

root@EX8200VC-1b# set system services web-management https system-generated-certificate set system services ssh delete system services web-management http delete system services telnet
Configure DNS.

root@EX8200VC-1b# set system name-server 10.10.46.100 set system domain-name xyzcompany.com

26

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Configure NTP.

set system ntp server 10.10.46.100

Configuring Layer 2 Settings on EX8200 Virtual Chassis Core Switch


to 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 52 set vlans data_wired_1b vlan-id 8 set vlans data_wireless_1b vlan-id 32 set vlans guest_wireless vlan-id 60 set vlans internet_edge vlan-id 44 set vlans management_1b vlan-id 50 set vlans server_1b vlan-id 46 set vlans server_2b vlan-id 48 set vlans voip_wired_1b vlan-id 20 set vlans voip_wireless_1b vlan-id 40
VLAN Interface Configuration

root@EX8200VC-1b# set vlans access_points_1b l3-interface vlan.52 set vlans data_wired_1b l3-interface vlan.8 set vlans internet_edge l3-interface vlan.44 set vlans management_1b l3-interface vlan.50 set vlans server_1b l3-interface vlan.46 set vlans server_2b l3-interface vlan.48 set vlans voip_wired_1b l3-interface vlan.20 set vlans data_wireless_1b l3-interface vlan.32 set vlans voip_wireless_1b l3-interface vlan.40

Copyright 2013, Juniper Networks, Inc.

27

Implementation Guide Vertical Campus

IP interface configuration.

root@EX8200VC-1b# set interfaces vlan set interfaces vlan set interfaces vlan set interfaces vlan set interfaces vlan set interfaces vlan set interfaces vlan set interfaces vlan set interfaces vlan

unit unit unit unit unit unit unit unit unit

8 family inet address 10.10.8.1/22 20 family inet address 10.10.20.1/22 32 family inet address 10.10.32.1/22 40 family inet address 10.10.40.1/23 44 family inet address 10.10.44.1/24 46 family inet address 10.10.46.1/24 48 family inet address 10.10.48.1/24 50 family inet address 10.10.50.1/24 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/24 commit
Configure LAG (aggregated Ethernet) ports
In 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 ae1 set interfaces xe-2/0/0 ether-options 802.3ad ae1 set interfaces xe-16/0/0 ether-options 802.3ad ae1 set interfaces xe-18/0/0 ether-options 802.3ad ae1 set interfaces xe-1/0/4 ether-options 802.3ad ae0 set interfaces xe-1/0/5 ether-options 802.3ad ae0 set interfaces xe-17/0/4 ether-options 802.3ad ae0 set 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 set interfaces ae0 set interfaces ae1 set interfaces ae1

aggregated-ether-options aggregated-ether-options aggregated-ether-options aggregated-ether-options

lacp lacp lacp lacp

active periodic slow active periodic slow

28

Copyright 2013, Juniper Networks, Inc.

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 (clientfacing) 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 set set set set set

interfaces interfaces interfaces interfaces interfaces interfaces

ae0 ae0 ae0 ae0 ae0 ae0

unit unit unit unit unit unit

0 0 0 0 0 0

family family family family family family

ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching

vlan vlan vlan vlan vlan vlan

members members members members members members

data_wired_1b voip_wired_1b data_wireless_1b voip_wireless_1b access_points_1b 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.

Copyright 2013, Juniper Networks, Inc.

29

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 trunk set interfaces ge-4/0/0 unit 0 family ethernet-switching vlan members management_1b set interfaces ge-4/0/0 unit 0 family ethernet-switching vlan members guest_wireless set interfaces ge-20/0/0 unit 0 family ethernet-switching port-mode trunk set interfaces ge-20/0/0 unit 0 family ethernet-switching vlan members management_1b set 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 set interfaces ge-4/0/1 set interfaces ge-4/0/1 set interfaces ge-4/0/1 set set set set interfaces interfaces interfaces interfaces

unit unit unit unit

0 0 0 0

family family family family

ethernet-switching ethernet-switching ethernet-switching ethernet-switching

port-mode trunk vlan members internet_edge vlan members management_1b vlan members guest_wireless port-mode trunk vlan members internet_edge vlan members management_1b vlan members guest_wireless

ge-20/0/1 ge-20/0/1 ge-20/0/1 ge-20/0/1

unit unit unit unit

0 0 0 0

family family family family

ethernet-switching ethernet-switching ethernet-switching ethernet-switching

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 portmode trunk set interfaces <interface> unit 0 family ethernet-switching vlan members [servers_1b management_1b]

30

Copyright 2013, Juniper Networks, Inc.

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-error root@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

Copyright 2013, Juniper Networks, Inc.

31

Implementation Guide Vertical Campus

Configuring Layer 3 Settings for the EX8200 Virtual Chassis Core Switch
to 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 , 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 set forwarding-options set forwarding-options set forwarding-options set forwarding-options set forwarding-options set forwarding-options

helpers helpers helpers helpers helpers helpers helpers

bootp bootp bootp bootp bootp bootp bootp

description DHCP-SERVER-A server 10.10.46.100 interface vlan.8 interface vlan.20 interface vlan.32 interface vlan.40 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 set protocols ospf set protocols ospf set protocols ospf set protocols ospf set protocols ospf set protocols ospf set protocols ospf set protocols ospf set protocols ospf set protocols ospf

area area area area area area area area area area area

0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

interface interface interface interface interface interface interface interface interface interface interface

vlan.48 passive vlan.8 passive vlan.20 passive vlan.32 passive vlan.40 passive vlan.50 passive vlan.64 passive ae1.0 vlan.44 vlan.52 passive vlan.46 passive

Commit the configuration.

commit

32

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Configure Class of Service


the 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 classes


First we will configure the forwarding classes; this step also defines what queues are used as well.

root@EX8200VC-1b# set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service
Configuring classifiers

forwarding-classes forwarding-classes forwarding-classes forwarding-classes forwarding-classes

class class class class class

control queue-num 7 voice queue-num 5 business-app queue-num 3 server-bulk queue-num 1 best-effort queue-num 0

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 it will be considered best-effort traffic and treated accordingly.

root@EX8200VC-1b# set class-of-service classifiers priority low code-points nc1 set class-of-service classifiers priority low code-points nc2 set class-of-service classifiers low code-points ef set class-of-service classifiers priority low code-points af21 set class-of-service classifiers priority low code-points af11 set class-of-service classifiers priority low code-points be
Configuring schedulers

dscp dscp_trusted forwarding-class control lossdscp dscp_trusted forwarding-class control lossdscp dscp_trusted forwarding-class voice loss-priority dscp dscp_trusted forwarding-class business-app lossdscp dscp_trusted forwarding-class server-bulk lossdscp dscp_trusted forwarding-class best-effort loss-

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 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 set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service

schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers

control-network-sched shaping-rate percent 5 control-network-sched buffer-size percent 5 control-network-sched priority strict-high control-user-sched shaping-rate percent 5 control-user-sched buffer-size percent 5 control-user-sched priority strict-high voice-network-sched shaping-rate percent 5 voice-network-sched buffer-size percent 5 voice-network-sched priority strict-high voice-user-sched shaping-rate percent 5 voice-user-sched buffer-size percent 5 voice-user-sched priority strict-high business-sched transmit-rate percent 60 business-sched buffer-size percent 60 business-sched priority low server-sched transmit-rate percent 30 server-sched buffer-size percent 30 server-sched priority low be-sched transmit-rate remainder be-sched buffer-size remainder be-sched priority low

Copyright 2013, Juniper Networks, Inc.

33

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 scheduler control-network-sched set class-of-service scheduler-maps scheduler voice-network-sched set class-of-service scheduler-maps scheduler business-sched set class-of-service scheduler-maps scheduler server-sched set class-of-service scheduler-maps scheduler be-sched set class-of-service scheduler-maps scheduler control-user-sched set class-of-service scheduler-maps voice-user-sched set class-of-service scheduler-maps scheduler business-sched set class-of-service scheduler-maps scheduler server-sched set class-of-service scheduler-maps scheduler be-sched
Configuring rewrite rules.

network-port-sched forwarding-class control network-port-sched forwarding-class voice network-port-sched forwarding-class business-app network-port-sched forwarding-class server-bulk network-port-sched forwarding-class best-effort access-port-sched forwarding-class control access-port-sched forwarding-class voice scheduler access-port-sched forwarding-class business-app access-port-sched forwarding-class server-bulk access-port-sched forwarding-class best-effort

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 priority low code-point nc1 set class-of-service rewrite-rules priority high code-point nc2 set class-of-service rewrite-rules priority low code-point ef set class-of-service rewrite-rules loss-priority low code-point af21 set class-of-service rewrite-rules loss-priority low code-point be
Configuring interfaces.

dscp rewrite-dscp forwarding-class control lossdscp rewrite-dscp forwarding-class control lossdscp rewrite-dscp forwarding-class voice lossdscp rewrite-dscp forwarding-class business-app dscp rewrite-dscp forwarding-class best-effort

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.

34

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

root@EX8200VC-1b# set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service
Commit the configuration.

interfaces interfaces interfaces interfaces interfaces interfaces interfaces interfaces interfaces

ge-4/0/* scheduler-map access-port-sched ge-4/0/* unit 0 classifiers dscp dscp_trusted ge-4/0/* unit 0 rewrite-rules dscp rewrite-dscp ae0 scheduler-map network-port-sched ae0 unit 0 classifiers dscp dscp_trusted ae0 unit 0 rewrite-rules dscp rewrite-dscp ae1 scheduler-map network-port-sched ae1 unit 0 classifiers dscp dscp_trusted ae1 unit 0 rewrite-rules dscp rewrite-dscp

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 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.

Copyright 2013, Juniper Networks, Inc.

35

Implementation Guide Vertical Campus

root@EX8200VC-1b> show interfaces xe-1/0/4 Physical 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 detail Physical 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

36

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Egress queues: 8 supported, 8 in use Queue counters: Queued packets Transmitted packets 0 best-effort 0 22862 1 server-bulk 0 0 2 mcast-be 0 0 3 business-app 0 0 4 mcast-ef 0 0 5 voice 0 0 6 mcast-af 0 0 7 control 0 5783 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) (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 Output bytes : 0 Input packets: 0 Output packets: 0 Protocol aenet, AE bundle: ae0.0, Generation: 164, Route

Dropped packets 0 0 0 0 0 0 0 0

(HW Token 2147483649)

0 bps 0 bps 0 pps 0 pps table: 0

Copyright 2013, Juniper Networks, Inc.

37

Implementation Guide Vertical Campus

Building B: Configuring the Access Layer


BUILDING A
EX4200VC-3a WLA WLA WLA EX4200VC-2a WLA
LAG

BUILDING B

EX6200-1b

You are Here

WLC Cluster

EX3300VC-1a WLA

Centralized DHCP and other services App Servers

WLA
LAG LAG

WLA

SRX Series Cluster INTERNET


LAG

EX4500VC-1a

LAG

EX8200VC-1b

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.

38

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Software Version /Upgrading the EX6200


NOTE: 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: root Logging to master . JUNOS 11.4R1.6 built 2011-11-15 11:14:01 UTC root@: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> configure Entering 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-password New 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.

Copyright 2013, Juniper Networks, Inc.

39

Implementation Guide Vertical Campus

Routing-engine 1
Connect 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: root Logging to master . JUNOS 11.4R1.6 built 2011-11-15 11:14:01 UTC root@: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> configure Entering 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.

40

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

EX6200 Configuration Overview


1. Configure global configuration items perform Chassis type-specific configuration 3. Configure layer 2 settings 4. Configure layer 3 settings 5. Configure Class of service 2. Configure the Chassis

Configuring Global Settings for the EX6210 Switch


to 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: root Logging to master . JUNOS 12.1R9 built 2011-11-15 11:14:01 UTC root@: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> configure Entering 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-password New password:******* Retype new password:******* {master:0}[edit] root#

Copyright 2013, Juniper Networks, Inc.

41

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-certificate set system services ssh delete system services web-management http delete system services telnet
Configure DNS.

root@EX6200-1b# set system name-server 10.10.46.100 set system domain-name xyzcompany.com


Configure NTP.

root@EX6200-1b# set system ntp server 10.10.46.100

Configuring the EX6200 Chassis


Configure global Virtual Chassis commands.

root@EX6200-1b# set system commit synchronize set ethernet-switching-options nonstop-bridging set 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 re0 request 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.

42

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

root@EX6200-1b# set protocols igmp-snooping vlan all set protocols rstp set protocols lldp interface all set protocols lldp-med interface all set poe interface all set ethernet-switching-options storm-control interface all

Configuring Layer 2 Settings for EX6200 Chassis


to configure layer 2 parameters and settings on the access switch in dedicated mode:

Table 8: VLANs Configured on EX6200


VLAN-ID
8 20 32 40 50 52

VLAN Name
data_wired_1b voip_wired_1b data_wireless_1b voip_wireless_1b management_1b access_points_1b

Subnet
10.10.8.0/22 10.10.20.0/22 10.10.32.0/23 10.10.40.0/23 10.10.50.0/24 10.10.52.0/24 wired_access_ports wired_voice_ports

Port Range Name

wireless_access_points

Configure VLANs.

root@EX6200-1b# set vlans access_points_1b vlan-id 52 set vlans data_wired_1b vlan-id 8 set vlans data_wireless_1b vlan-id 32 set vlans voip_wired_1b vlan-id 20 set vlans voip_wireless_1b vlan-id 40 set 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.

Copyright 2013, Juniper Networks, Inc.

43

Implementation Guide Vertical Campus

Configure the interfaces to be part of the respective aggregated interfaces.

root@EX6200-1b# set interfaces xe-4/0/0 set interfaces xe-4/0/1 set interfaces xe-5/0/0 set interfaces xe-5/0/1

ether-options ether-options ether-options ether-options

802.3ad 802.3ad 802.3ad 802.3ad

ae0 ae0 ae0 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 active set 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 ae0.0 ae0.0 ae0.0 ae0.0 Ports xe-4/0/0 xe-4/0/1 xe-5/0/0 xe-5/0/1 to device EX8200VC-1b EX8200VC-1b EX8200VC-1b EX8200VC-1b to port xe-1/0/4 xe-17/0/4 xe-1/0/5 xe-17/0/5 Trunk/Access Trunk Trunk Trunk Trunk VLANs data_wired_1b voip_wired_1b data_wireless_1b voip_wireless_1b management_1b access_points_1b default Native VLAN

root@EX6200-1b# set interfaces ae0 set interfaces ae0 set interfaces ae0 set interfaces ae0 set interfaces ae0 set interfaces ae0

unit unit unit unit unit unit

0 0 0 0 0 0

family family family family family family

ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching

vlan vlan vlan vlan vlan vlan

members members members members members members

access_points_1b data_wired_1b data_wireless_1b voip_wired_1b voip_wireless_1b management_1b

Commit the configuration.

root@EX6200-1b# commit

44

Copyright 2013, Juniper Networks, Inc.

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 neighbors Local Interface Parent Interface xe-5/0/0.0 ae0.0 xe-5/0/1.0 ae0.0 xe-4/0/0.0 ae0.0 xe-4/0/1.0 ae0.0 ge-0/0/0.0 -

Chassis Id 28:c0:da:ba:90:00 28:c0:da:ba:90:00 28:c0:da:ba:90:00 28:c0:da:ba:90:00 10.10.52.10

Port info xe-1/0/5.0 xe-17/0/5.0 xe-1/0/4.0 xe-17/0/4.0 port 1

System Name EX8200VC-1b EX8200VC-1b EX8200VC-1b EX8200VC-1b WLA532-US

Run the show lacp interfaces command to verify that LACP is running.

root@EX6200-1> show lacp interfaces Aggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn xe-4/0/0 Actor No No Yes Yes Yes xe-4/0/0 Partner No No Yes Yes Yes xe-4/0/1 Actor No No Yes Yes Yes xe-4/0/1 Partner No No Yes Yes Yes xe-5/0/0 Actor No No Yes Yes Yes xe-5/0/0 Partner No No Yes Yes Yes xe-5/0/1 Actor No No Yes Yes Yes xe-5/0/1 Partner No No Yes Yes Yes LACP protocol: Receive State Transmit State xe-4/0/0 Current Slow periodic xe-4/0/1 Current Slow periodic xe-5/0/0 Current Slow periodic xe-5/0/1 Current Slow periodic
Configure secure access port features.

Aggr Yes Yes Yes Yes Yes Yes Yes Yes

Timeout Activity Slow Active Slow Active Slow Active Slow Active Slow Active Slow Active Slow Active Slow Active Mux State Collecting distributing Collecting distributing Collecting distributing Collecting distributing

NOTE: in the version of code tested in the tested network (12.1r9), 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-guard set 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 04 are reserved for wireless access points ports 526 are reserved for data. ports 2747 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.

Copyright 2013, Juniper Networks, Inc.

45

Implementation Guide Vertical Campus

Table 10: VLAN to Port Range


VLAN-ID
8 32 52

VLAN Name
data_wired_1b voip_wired_1b access_points_1b

Subnet
10.10.8.0/22 10.10.32.0/22 10.10.52.0/24

Port Range Name


wired_access_ports wired_voice_ports wireless_access_points

root@EX6200-1b# set interfaces interface-range wireless_access_points member-range ge-0/0/0 to ge-0/0/4 set interfaces interface-range wired_access_ports member-range ge-0/0/5 to ge-0/0/26 set 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 access set interfaces interface-range wired_voice_ports unit 0 family ethernet-switching portmode access set 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_ports set 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_1b set interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members voip_wireless_1b set 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

46

Copyright 2013, Juniper Networks, Inc.

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.1 PING 10.10.50.1 (10.10.50.1): 56 data bytes 64 bytes from 10.10.50.1: icmp_seq=0 ttl=64 time=3.458 ms 64 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 ethernetswitching interfaces ae0 command.

root@EX6200-1b> show ethernet-switching Interface State VLAN members ae0.0 up access_points_1b data_wired_1b data_wireless_1b management_1b voip_wired_1b voip_wireless_1b

interfaces ae0 Tag Tagging 52 tagged 8 tagged 32 tagged 50 tagged 20 tagged 40 tagged

Blocking unblocked unblocked unblocked unblocked unblocked 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 VlaNs output.

root@EX6200-1b> show vlans Name Tag Interfaces access_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 Service


the 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 set class-of-service set class-of-service set class-of-service set class-of-service

forwarding-classes forwarding-classes forwarding-classes forwarding-classes forwarding-classes

class class class class class

control queue-num 7 voice queue-num 5 business-app queue-num 3 server-bulk queue-num 1 best-effort queue-num 0

Copyright 2013, Juniper Networks, Inc.

47

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 priority low code-points nc1 set class-of-service classifiers priority low code-points nc2 set class-of-service classifiers low code-points ef set class-of-service classifiers priority low code-points af21 set class-of-service classifiers priority low code-points af11 set class-of-service classifiers priority low code-points be
Configuring schedulers.

dscp dscp_trusted forwarding-class control lossdscp dscp_trusted forwarding-class control lossdscp dscp_trusted forwarding-class voice loss-priority dscp dscp_trusted forwarding-class business-app lossdscp dscp_trusted forwarding-class server-bulk lossdscp dscp_trusted forwarding-class best-effort loss-

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 set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service

schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers

control-network-sched shaping-rate percent 5 control-network-sched buffer-size percent 5 control-network-sched priority strict-high control-user-sched shaping-rate percent 5 control-user-sched buffer-size percent 5 control-user-sched priority strict-high voice-network-sched shaping-rate percent 5 voice-network-sched buffer-size percent 5 voice-network-sched priority strict-high voice-user-sched shaping-rate percent 5 voice-user-sched buffer-size percent 5 voice-user-sched priority strict-high business-sched transmit-rate percent 60 business-sched buffer-size percent 60 business-sched priority low server-sched transmit-rate percent 30 server-sched buffer-size percent 30 server-sched priority low be-sched transmit-rate remainder be-sched buffer-size remainder 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.

48

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

root@EX6200-1b# set class-of-service scheduler-maps scheduler control-network-sched set class-of-service scheduler-maps scheduler voice-network-sched set class-of-service scheduler-maps scheduler business-sched set class-of-service scheduler-maps scheduler server-sched set class-of-service scheduler-maps scheduler be-sched set class-of-service scheduler-maps scheduler control-user-sched set class-of-service scheduler-maps voice-user-sched set class-of-service scheduler-maps scheduler business-sched set class-of-service scheduler-maps scheduler server-sched set class-of-service scheduler-maps scheduler be-sched
Configuring rewrite rules.

network-port-sched forwarding-class control network-port-sched forwarding-class voice network-port-sched forwarding-class business-app network-port-sched forwarding-class server-bulk network-port-sched forwarding-class best-effort access-port-sched forwarding-class control access-port-sched forwarding-class voice scheduler access-port-sched forwarding-class business-app access-port-sched forwarding-class server-bulk access-port-sched forwarding-class best-effort

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 priority low code-point nc1 set class-of-service rewrite-rules priority high code-point nc2 set class-of-service rewrite-rules priority low code-point ef set class-of-service rewrite-rules loss-priority low code-point af21 set class-of-service rewrite-rules loss-priority low code-point be
Configuring interfaces.

dscp rewrite-dscp forwarding-class control lossdscp rewrite-dscp forwarding-class control lossdscp rewrite-dscp forwarding-class voice lossdscp rewrite-dscp forwarding-class business-app dscp rewrite-dscp forwarding-class best-effort

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 set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service
Commit the configuration.

interfaces interfaces interfaces interfaces interfaces interfaces

ge-0/0/* scheduler-map access-port-sched ge-0/0/* unit 0 classifiers dscp dscp_trusted ge-0/0/* unit 0 rewrite-rules dscp rewrite-dscp ae0 scheduler-map network-port-sched ae0 unit 0 classifiers dscp dscp_trusted ae0 unit 0 rewrite-rules dscp rewrite-dscp

commit

Copyright 2013, Juniper Networks, Inc.

49

Implementation Guide Vertical Campus

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 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 detail Physical 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

50

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Egress queues: 8 supported, 5 in use Queue counters: Queued packets Transmitted packets 0 best-effort 0 69222 1 server-bulk 0 0 3 business-app 0 0 5 voice 0 0 7 control 0 47947 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) 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 Output bytes : 0 Input packets: 0 Output packets: 0 Protocol eth-switch, Generation: 159, Route table: 0 Flags: Trunk-Mode

Dropped packets 0 0 0 0 0

(Generation 139)

0 0 0 0

bps bps pps pps

Copyright 2013, Juniper Networks, Inc.

51

Implementation Guide Vertical Campus

BUILDING A
EX4200VC-3a WLA WLA WLA EX4200VC-2a WLA
LAG

BUILDING B

EX6200-1b WLC Cluster

EX3300VC-1a WLA

Centralized DHCP and other services App Servers

WLA
LAG LAG

WLA

SRX Series Cluster INTERNET


LAG

EX4500VC-1a

LAG

EX8200VC-1b

You are Here

Figure 12: EX4500VC Configuration

52

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Building A: Configuring the core


For reference throughout this portion of the document we have provided the Building a connection level details in Figure 13.

BUILDING A
EX4200VC-3a WLA
xe-3/1/1 xe-1/1/1

WLA

EX4200VC-2a WLA EX3300VC-1a WLA WLA


xe-7/1/0 LAG xe-0/1/0 xe-5/1/0

WLA
xe-0/1/0 LAG

EX4500VC-1a
xe-0/0/8 xe-0/0/6 LAG xe-0/0/6 xe-1/0/6 xe-0/0/38 xe-0/0/39 xe-1/0/38 xe-1/0/39

xe-1/0/8

xe-0/0/6

To Building B
LAG

Figure 13: Building A Connection Details

Copyright 2013, Juniper Networks, Inc.

53

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 Switch


to 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: root Logging to master . JUNOS 12.1R9 built 2011-11-15 11:14:01 UTC root@: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> configure Entering configuration mode {master:0}[edit] root#


You should now be at the # prompt and ready to start configuring the switch.

54

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Configure the password.

root# set system root-authentication plain-text-password New 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-certificate set system services ssh delete system services web-management http delete system services telnet
Configure DNS.

root@EX4500VC-1a# set system name-server 10.10.24.100 set system domain-name xyzcompany.com

Configuring a Virtual Chassis for the Mixed Mode Core Chassis


to 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.

Copyright 2013, Juniper Networks, Inc.

55

Implementation Guide Vertical Campus

root@EX4500VC-1a# set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis
Commit the configuration.

preprovisioned member 0 role routing-engine member 0 serial-number GX0212140825 member 1 role routing-engine member 1 serial-number GX0212140845 member 2 role line-card member 2 serial-number FP0211490796 member 3 role line-card member 3 serial-number FP0211490618

root@EX4500VC-1a# commit configuration check succeeds commit 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-chassis Preprovisioned Virtual Chassis Virtual Chassis ID: 8c7a.9353.df56 Virtual Chassis Mode: Mixed Mstr Mixed Neighbor List Member ID Status Serial No Model prio Role Mode ID Interface 0 (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 Chassis Virtual Chassis ID: 804d.1d7f.fd6a Virtual Chassis Mode: Mixed Member ID 0 (FPC 0) 1 (FPC 1) 2 (FPC 2) 3 (FPC 3) Status Prsnt Prsnt Prsnt Prsnt

Mstr Serial No Model prio GX0212140825 ex4500-40f 129

Mixed Neighbor List Mode ID Interface Y 1 vcp-1 2 vcp-0 GX0212140845 ex4500-40f 129 Master* Y 3 vcp-1 0 vcp-0 FP0211490796 ex4200-48px 0 Linecard Y 3 vcp-0 0 vcp-1 FP0211490618 ex4200-48px 0 Linecard Y 1 vcp-0 2 vcp-1 Role Backup

Enter configuration mode again.

56

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Configure global Virtual Chassis commands.

root@EX4500VC-1a# set system commit synchronize set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging set chassis redundancy graceful-switchover commit 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 all set protocols rstp set protocols lldp interface all set protocols lldp-med interface all set poe interface all set ethernet-switching-options storm-control interface all

Configuring Layer 2 Settings For Mixed Mode Core Switch


to 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 12 set 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.

Copyright 2013, Juniper Networks, Inc.

57

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 54 set vlans access_points_1a l3-interface vlan.54 set vlans data_wired_1a vlan-id 12 set vlans data_wired_1a l3-interface vlan.12 set vlans data_wireless_1a vlan-id 36 set vlans data_wireless_1a l3-interface vlan.36 set vlans voip_wired_1a vlan-id 24 set vlans voip_wired_1a l3-interface vlan.24 set vlans voip_wireless_1a vlan-id 42 set vlans voip_wireless_1a l3-interface vlan.42 set vlans management_1a vlan-id 51 set vlans management_1a l3-interface vlan.51
Interface configurations

root@EX4500VC-1a# set interfaces vlan set interfaces vlan set interfaces vlan set interfaces vlan set interfaces vlan set interfaces vlan
Commit the configuration.

unit unit unit unit unit unit

12 24 36 42 51 54

family family family family family family

inet inet inet inet inet inet

address address address address address address

10.10.12.1/22 10.10.24.1/22 10.10.36.1/22 10.10.42.1/23 10.10.51.1/24 10.10.54.1/24

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:

58

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

root@EX4500VC-1a# delete interfaces delete interfaces delete interfaces delete interfaces delete interfaces delete interfaces delete interfaces delete interfaces delete interfaces delete interfaces

xe-1/0/38 unit 0 xe-1/0/39 unit 0 xe-0/0/38 unit 0 xe-0/0/39 unit 0 xe-0/0/8 unit 0 xe-1/0/8 unit 0 xe-0/0/4 unit 0 xe-1/0/4 unit 0 xe-0/0/6 unit 0 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 ae0 set interfaces xe-1/0/39 ether-options 802.3ad ae0 set interfaces xe-0/0/38 ether-options 802.3ad ae0 set interfaces xe-0/0/39 ether-options 802.3ad ae0 set interfaces xe-0/0/8 ether-options 802.3ad ae1 set interfaces xe-1/0/8 ether-options 802.3ad ae1 set interfaces xe-0/0/4 ether-options 802.3ad ae2 set interfaces xe-1/0/4 ether-options 802.3ad ae2 set interfaces xe-0/0/6 ether-options 802.3ad ae3 set 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 set interfaces ae0 set interfaces ae1 set interfaces ae1 set interfaces ae2 set interfaces ae2 set interfaces ae3 set interfaces ae3

aggregated-ether-options aggregated-ether-options aggregated-ether-options aggregated-ether-options aggregated-ether-options aggregated-ether-options aggregated-ether-options aggregated-ether-options

lacp lacp lacp lacp lacp lacp lacp lacp

active periodic active periodic active periodic active periodic

slow slow slow 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 disable set protocols rstp interface ae2.0 disable set 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 trunk set interfaces ae1 unit 0 family ethernet-switching port-mode trunk set interfaces ae2 unit 0 family ethernet-switching port-mode trunk
Now commit the configuration.

Copyright 2013, Juniper Networks, Inc.

59

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 (clientfacing) 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 set interfaces ae1 set interfaces ae1 set interfaces ae1 set interfaces ae1 set interfaces ae1 set interfaces ae1 set interfaces ae2 set interfaces ae2 set interfaces ae2 set interfaces ae2 set interfaces ae2 set interfaces ae2 set interfaces ae2 set interfaces ae3 set interfaces ae3 set interfaces ae3 set interfaces ae3 set interfaces ae3 set interfaces ae3 set interfaces ae3

unit unit unit unit unit unit unit unit unit unit unit unit unit unit unit unit unit unit unit unit unit

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

family family family family family family family family family family family family family family family family family family family family family

ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching

port-mode trunk vlan members data_wired_1a vlan members voip_wired_1a vlan members data_wireless_1a vlan members voip_wireless_1a vlan members access_points_1a vlan members management_1a port-mode trunk vlan members data_wired_1a vlan members voip_wired_1a vlan members data_wireless_1a vlan members voip_wireless_1a vlan members access_points_1a vlan members management_1a port-mode trunk vlan members data_wired_1a vlan members voip_wired_1a vlan members data_wireless_1a vlan members voip_wireless_1a vlan members access_points_1a 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 set set set set set

ethernet-switching-options ethernet-switching-options ethernet-switching-options ethernet-switching-options ethernet-switching-options ethernet-switching-options

secure-access-port secure-access-port secure-access-port secure-access-port secure-access-port secure-access-port

vlan vlan vlan vlan vlan vlan

data_wired_1a data_wired_1a data_wired_1a voip_wired_1a voip_wired_1a voip_wired_1a

arp-inspection examine-dhcp ip-source-guard arp-inspection examine-dhcp 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

60

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Configuring Layer 3 Settings For Mixed Mode Core Switch


to 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 set forwarding-options set forwarding-options set forwarding-options set forwarding-options set forwarding-options set forwarding-options

helpers helpers helpers helpers helpers helpers helpers

bootp bootp bootp bootp bootp bootp bootp

description DHCP-SERVER-A server 10.10.46.100 interface vlan.12 interface vlan.24 interface vlan.36 interface vlan.42 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 set protocols ospf set protocols ospf set protocols ospf set protocols ospf set protocols ospf set protocols ospf set protocols ospf

area area area area area area area area

0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

interface interface interface interface interface interface interface interface

vlan.46 vlan.12 vlan.24 vlan.36 vlan.42 vlan.54 vlan.58 ae0.0

passive passive passive passive passive passive passive

Configure non-stop routing


Configure 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

Copyright 2013, Juniper Networks, Inc.

61

Implementation Guide Vertical Campus

Configure Class of Service


the 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 classes


First we will configure the forwarding classes, this step also defines what queues are used as well.

root@EX4500VC-1a# set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service
Configuring classifiers

forwarding-classes forwarding-classes forwarding-classes forwarding-classes forwarding-classes

class class class class class

control queue-num 7 voice queue-num 5 business-app queue-num 3 server-bulk queue-num 1 best-effort queue-num 0

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@EX4500VC-1a# set class-of-service classifiers priority low code-points nc1 set class-of-service classifiers priority low code-points nc2 set class-of-service classifiers low code-points ef set class-of-service classifiers priority low code-points af21 set class-of-service classifiers priority low code-points af11 set class-of-service classifiers priority low code-points be

dscp dscp_trusted forwarding-class control lossdscp dscp_trusted forwarding-class control lossdscp dscp_trusted forwarding-class voice loss-priority dscp dscp_trusted forwarding-class business-app lossdscp dscp_trusted forwarding-class server-bulk lossdscp dscp_trusted forwarding-class best-effort loss-

62

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 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 voicenetwork-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 set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service
Configuring scheduler maps

schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers

control-network-sched shaping-rate percent 5 control-network-sched buffer-size percent 5 control-network-sched priority strict-high control-user-sched shaping-rate percent 5 control-user-sched buffer-size percent 5 control-user-sched priority strict-high voice-network-sched shaping-rate percent 5 voice-network-sched buffer-size percent 5 voice-network-sched priority strict-high voice-user-sched shaping-rate percent 5 voice-user-sched buffer-size percent 5 voice-user-sched priority strict-high business-sched transmit-rate percent 60 business-sched buffer-size percent 60 business-sched priority low server-sched transmit-rate percent 30 server-sched buffer-size percent 30 server-sched priority low be-sched transmit-rate remainder be-sched buffer-size remainder be-sched priority low

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@EX4500VC-1a# set class-of-service scheduler-maps scheduler control-network-sched set class-of-service scheduler-maps scheduler voice-network-sched set class-of-service scheduler-maps scheduler business-sched set class-of-service scheduler-maps scheduler server-sched set class-of-service scheduler-maps scheduler be-sched set class-of-service scheduler-maps scheduler control-user-sched set class-of-service scheduler-maps voice-user-sched set class-of-service scheduler-maps scheduler business-sched set class-of-service scheduler-maps scheduler server-sched set class-of-service scheduler-maps scheduler be-sched

network-port-sched forwarding-class control network-port-sched forwarding-class voice network-port-sched forwarding-class business-app network-port-sched forwarding-class server-bulk network-port-sched forwarding-class best-effort access-port-sched forwarding-class control access-port-sched forwarding-class voice scheduler access-port-sched forwarding-class business-app access-port-sched forwarding-class server-bulk access-port-sched forwarding-class best-effort

Copyright 2013, Juniper Networks, Inc.

63

Implementation Guide Vertical Campus

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@EX4500VC-1a# set class-of-service rewrite-rules priority low code-point nc1 set class-of-service rewrite-rules priority high code-point nc2 set class-of-service rewrite-rules priority low code-point ef set class-of-service rewrite-rules loss-priority low code-point af21 set class-of-service rewrite-rules loss-priority low code-point be
Configuring interfaces.

dscp rewrite-dscp forwarding-class control lossdscp rewrite-dscp forwarding-class control lossdscp rewrite-dscp forwarding-class voice lossdscp rewrite-dscp forwarding-class business-app dscp rewrite-dscp forwarding-class best-effort

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 set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service
Commit the configuration.

interfaces interfaces interfaces interfaces interfaces interfaces interfaces interfaces interfaces interfaces interfaces interfaces interfaces interfaces interfaces

ge-* scheduler-map access-port-sched ge-* unit 0 classifiers dscp dscp_trusted ge-* unit 0 rewrite-rules dscp rewrite-dscp ae0 scheduler-map network-port-sched ae0 unit 0 classifiers dscp dscp_trusted ae0 unit 0 rewrite-rules dscp rewrite-dscp ae1 scheduler-map network-port-sched ae1 unit 0 classifiers dscp dscp_trusted ae1 unit 0 rewrite-rules dscp rewrite-dscp ae2 scheduler-map network-port-sched ae2 unit 0 classifiers dscp dscp_trusted ae2 unit 0 rewrite-rules dscp rewrite-dscp ae3 scheduler-map network-port-sched ae3 unit 0 classifiers dscp dscp_trusted ae3 unit 0 rewrite-rules dscp rewrite-dscp

commit

64

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

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 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 detail Physical 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: 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 : None Active defects : None Interface transmit statistics: Disabled

Copyright 2013, Juniper Networks, Inc.

65

Implementation Guide Vertical Campus

Building A: Configuring the Access Layer


BUILDING A
You are Here

BUILDING B

EX4200VC-3a

WLA WLA WLA EX4200VC-2a WLA


LAG

EX6200-1b WLC Cluster

EX3300VC-1a WLA

Centralized DHCP and other services App Servers

WLA
LAG LAG

WLA

SRX Series Cluster INTERNET


LAG

EX4500VC-1a

LAG

EX8200VC-1b

Figure 14: EX4200VC-3a Configuration

Configuring EX4200 as Extended Mode Virtual Chassis


Configuring 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 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 2. Configure the Virtual Chassis

Configuring Global Settings for the Core Switch


to 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

66

Copyright 2013, Juniper Networks, Inc.

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: root Logging to master . JUNOS 12.1R9 built 2011-11-15 11:14:01 UTC root@: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> configure Entering 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-password New 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-certificate set system services ssh delete system services web-management http delete system services telnet

Copyright 2013, Juniper Networks, Inc.

67

Implementation Guide Vertical Campus

Configure DNS

root@EX4200VC-3a#set system name-server 10.10.24.100 set system domain-name xyzcompany.com

Configuring an Extended Mode Virtual Chassis for the EX4200


to 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 set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis

preprovisioned member 0 role routing-engine member 0 serial-number FP0211490670 member 1 role line-card member 1 serial-number FP0211490804 member 2 role routing-engine member 2 serial-number FP0211490739 member 3 role line-card 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 synchronize set ethernet-switching-options nonstop-bridging


set 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.

68

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

root@EX4200VC-3a# commit error: Could not connect to fpc-1 : Cant assign requested address warning: Cannot connect to other RE, ignoring it configuration check succeeds commit 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-chassis Preprovisioned Virtual Chassis Virtual Chassis ID: 3f68.0cec.a7e1 Virtual Chassis Mode: Enabled Mstr Mixed Neighbor List Member ID Status Serial No Model prio Role Mode ID Interface 0 (FPC 0) Prsnt FP0211490670 ex4200-48px 129 Master* N 1 vcp-0 1 vcp-1 1 (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 0 request 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-port fpc0: -------------------------------------------------------------------------Interface Type Trunk Status Speed Neighbor or ID (mbps) ID Interface PIC / Port vcp-0 Dedicated 1 Up 32000 1 vcp-1 vcp-1 Dedicated 2 Up 32000 1 vcp-0 1/0 Configured -1 Up 10000 fpc1: -------------------------------------------------------------------------Interface Type Trunk Status Speed Neighbor or ID (mbps) ID Interface PIC / Port vcp-0 Dedicated 1 Up 32000 0 vcp-1 vcp-1 Dedicated 2 Up 32000 0 vcp-0 1/0 Configured -1 Up 10000

Copyright 2013, Juniper Networks, Inc.

69

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: root Logging to master . - - - JUNOS 12.1R9 built 2011-11-15 11:14:01 UTC root@: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-chassis Virtual Chassis ID: b155.0784.e162 Virtual Chassis Mode: Enabled Mstr Mixed Neighbor List Member ID Status Serial No Model prio Role Mode ID Interface 0 (FPC 0) Prsnt FP0211490739 ex4200-48px 128 Master* N 1 vcp-0 1 vcp-1 1 (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 0 request virtual-chassis vc-port set pic-slot 1 port 0 member 1

70

Copyright 2013, Juniper Networks, Inc.

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-port fpc0: -------------------------------------------------------------------------Interface Type Trunk Status Speed Neighbor or ID (mbps) ID Interface PIC / Port vcp-0 Dedicated 1 Up 32000 1 vcp-1 vcp-1 Dedicated 2 Up 32000 1 vcp-0 1/0 Configured -1 Down 10000 fpc1: -------------------------------------------------------------------------Interface Type Trunk Status Speed Neighbor or ID (mbps) ID Interface PIC / Port vcp-0 Dedicated 1 Up 32000 0 vcp-1 vcp-1 Dedicated 2 Up 32000 0 vcp-0 1/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-port fpc0: -------------------------------------------------------------------------Interface Type Trunk Status Speed Neighbor or ID (mbps) ID Interface PIC / Port vcp-0 Dedicated 1 Up 32000 1 vcp-1 vcp-1 Dedicated 2 Up 32000 1 vcp-0 1/0 Configured -1 Up 10000 2 vcp-255/1/0 fpc1: -------------------------------------------------------------------------Interface Type Trunk Status Speed Neighbor or ID (mbps) ID Interface PIC / Port vcp-0 Dedicated 1 Up 32000 0 vcp-1 vcp-1 Dedicated 2 Up 32000 0 vcp-0 1/0 Configured -1 Up 10000 3 vcp-255/1/0 fpc2: -------------------------------------------------------------------------Interface Type Trunk Status Speed Neighbor or ID (mbps) ID Interface PIC / Port vcp-0 Dedicated 1 Up 32000 3 vcp-1 vcp-1 Dedicated 2 Up 32000 3 vcp-0 1/0 Configured -1 Up 10000 0 vcp-255/1/0 fpc3: -------------------------------------------------------------------------Interface Type Trunk Status Speed Neighbor or ID (mbps) ID Interface PIC / Port vcp-0 Dedicated 1 Up 32000 2 vcp-1 vcp-1 Dedicated 2 Up 32000 2 vcp-0 1/0 Configured -1 Up 10000 1 vcp-255/1/0

Copyright 2013, Juniper Networks, Inc.

71

Implementation Guide Vertical Campus

use the show virtual-chassis command to verify that the Virtual Chassis is built as expected, based on the preprovisioning configuration we did earlier.

root@EX4200VC-3a> show virtual-chassis Preprovisioned Virtual Chassis Virtual Chassis ID: 3f68.0cec.a7e1 Virtual Chassis Mode: Enabled Member ID 0 (FPC 0) 1 (FPC 1) 2 (FPC 2) 3 (FPC 3) Status Prsnt Prsnt Prsnt Prsnt

Mstr Serial No Model prio Role FP0211490670 ex4200-48px 129 Backup

Mixed Neighbor List Mode ID Interface N 1 vcp-0 1 vcp-1 2 vcp-255/1/0 FP0211490804 ex4200-48px 0 Linecard N 0 vcp-0 0 vcp-1 3 vcp-255/1/0 FP0211490739 ex4200-48px 129 Master* N 3 vcp-0 3 vcp-1 0 vcp-255/1/0 FP0211490735 ex4200-48px 0 Linecard N 2 vcp-0 2 vcp-1 1 vcp-255/1/0

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 all set protocols rstp set protocols lldp interface all set protocols lldp-med interface all set poe interface all set ethernet-switching-options storm-control interface all

Configuring Layer 2 Settings


to 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 54 set vlans data_wired_1a vlan-id 12 set vlans data_wireless_1a vlan-id 36 set vlans voip_wired_1a vlan-id 24 set vlans voip_wireless_1a vlan-id 42 set vlans management_1a vlan-id 51
Configure Interfaces
We need to configure one Ip interface on the management VlaN.

set interfaces vlan unit 51 family inet address 10.10.51.9/24

72

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Configure LAG (aggregated Ethernet) Ports


the 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 0 delete interfaces xe-3/1/1 unit 0 root@EX4200VC-3a# set interfaces xe-1/1/1 ether-options 802.3ad ae0 set 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 active set 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:

Copyright 2013, Juniper Networks, Inc.

73

Implementation Guide Vertical Campus

root@EX4200VC-3a# set interfaces ae0 set interfaces ae0 set interfaces ae0 set interfaces ae0 set interfaces ae0 set interfaces ae0

unit unit unit unit unit unit

0 0 0 0 0 0

family family family family family family

ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching

vlan vlan vlan vlan vlan vlan

members members members members members members

data_wired_1a voip_wired_1a access_points_1a data_wireless_1a voip_wireless_1a 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# commit fpc0: configuration check succeeds fpc1: commit complete fpc2: commit complete fpc3: commit complete fpc0: 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 neighbors Local Interface Parent Interface Name xe-1/1/1.0 ae0.0 EX4500VC-1a xe-3/1/1.0 ae0.0 EX4500VC-1a

Chassis Id a8:d0:e5:b5:0f:80 a8:d0:e5:b5:0f:80

Port info xe-0/0/4.0 xe-1/0/4.0

System

run the show lacp interfaces command to verify that lacp is running

root@EX4200VC-3a# run show lacp interfaces Aggregated 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.

74

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

root@EX4200VC-3a# set ethernet-switching-options set ethernet-switching-options set ethernet-switching-options set ethernet-switching-options set ethernet-switching-options set ethernet-switching-options

secure-access-port secure-access-port secure-access-port secure-access-port secure-access-port secure-access-port

vlan vlan vlan vlan vlan vlan

data_wired_1a data_wired_1a data_wired_1a voip_wired_1a voip_wired_1a voip_wired_1a

arp-inspection examine-dhcp ip-source-guard arp-inspection examine-dhcp 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 04 are reserved for wireless access points ports 526 are reserved for data. ports 2747 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
12 24 54

VLAN Name
data_wired_1a voip_wired_1a access_points_1a

Subnet
10.10.8.0/22 10.10.24.0/22 10.10.54.0/24

Port Range Name


wired_access_ports wired_voice_ports wireless_access_points

root@EX4200VC-3a# set interfaces interface-range wired_access_ports member-range ge-0/0/5 to ge-0/0/26 set interfaces interface-range wired_voice_ports member-range ge-0/0/27 to ge-0/0/47 set interfaces interface-range wireless_access_points member-range ge-0/0/0 to ge0/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 access set interfaces interface-range wired_voice_ports unit 0 family ethernet-switching port-mode access set 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_ports set 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.

Copyright 2013, Juniper Networks, Inc.

75

Implementation Guide Vertical Campus

root@EX4200VC-3a# set interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members data_wireless_1a set interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members voip_wireless_1a set 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.1 PING 10.10.51.1 (10.10.51.1): 56 data bytes 64 bytes from 10.10.51.1: icmp_seq=0 ttl=64 time=2.254 ms 64 bytes from 10.10.51.1: icmp_seq=1 ttl=64 time=1.759 ms 64 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 ethernetswitching interfaces ae0 command.

root@EX4200VC-3a> show ethernet-switching interfaces ae0 Interface State VLAN members Tag Tagging Blocking ae0.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 VlaNs output.

root@EX4200VC-3a> show vlans Name Tag Interfaces access_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

76

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Configure Class of Service


the 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 set class-of-service set class-of-service set class-of-service set class-of-service
Configuring classifiers.

forwarding-classes forwarding-classes forwarding-classes forwarding-classes forwarding-classes

class class class class class

control queue-num 7 voice queue-num 5 business-app queue-num 3 server-bulk queue-num 1 best-effort queue-num 0

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 priority low code-points nc1 set class-of-service classifiers priority low code-points nc2 set class-of-service classifiers low code-points ef set class-of-service classifiers priority low code-points af21 set class-of-service classifiers priority low code-points af11 set class-of-service classifiers priority low code-points be
Configuring schedulers.

dscp dscp_trusted forwarding-class control lossdscp dscp_trusted forwarding-class control lossdscp dscp_trusted forwarding-class voice loss-priority dscp dscp_trusted forwarding-class business-app lossdscp dscp_trusted forwarding-class server-bulk lossdscp dscp_trusted forwarding-class best-effort loss-

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-usersched 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.

Copyright 2013, Juniper Networks, Inc.

77

Implementation Guide Vertical Campus

root@EX4200VC-3a# set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service

schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers

control-network-sched shaping-rate percent 5 control-network-sched buffer-size percent 5 control-network-sched priority strict-high control-user-sched shaping-rate percent 5 control-user-sched buffer-size percent 5 control-user-sched priority strict-high voice-network-sched shaping-rate percent 5 voice-network-sched buffer-size percent 5 voice-network-sched priority strict-high voice-user-sched shaping-rate percent 5 voice-user-sched buffer-size percent 5 voice-user-sched priority strict-high business-sched transmit-rate percent 60 business-sched buffer-size percent 60 business-sched priority low server-sched transmit-rate percent 30 server-sched buffer-size percent 30 server-sched priority low be-sched transmit-rate remainder be-sched buffer-size remainder 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 scheduler control-network-sched set class-of-service scheduler-maps scheduler voice-network-sched set class-of-service scheduler-maps scheduler business-sched set class-of-service scheduler-maps scheduler server-sched set class-of-service scheduler-maps scheduler be-sched set class-of-service scheduler-maps scheduler control-user-sched set class-of-service scheduler-maps voice-user-sched set class-of-service scheduler-maps scheduler business-sched set class-of-service scheduler-maps scheduler server-sched set class-of-service scheduler-maps scheduler be-sched

network-port-sched forwarding-class control network-port-sched forwarding-class voice network-port-sched forwarding-class business-app network-port-sched forwarding-class server-bulk network-port-sched forwarding-class best-effort access-port-sched forwarding-class control access-port-sched forwarding-class voice scheduler access-port-sched forwarding-class business-app access-port-sched forwarding-class server-bulk access-port-sched forwarding-class best-effort

78

Copyright 2013, Juniper Networks, Inc.

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 priority low code-point nc1 set class-of-service rewrite-rules priority high code-point nc2 set class-of-service rewrite-rules priority low code-point ef set class-of-service rewrite-rules loss-priority low code-point af21 set class-of-service rewrite-rules loss-priority low code-point be
Configuring interfaces.

dscp rewrite-dscp forwarding-class control lossdscp rewrite-dscp forwarding-class control lossdscp rewrite-dscp forwarding-class voice lossdscp rewrite-dscp forwarding-class business-app dscp rewrite-dscp forwarding-class best-effort

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 set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service
Commit the configuration.

interfaces interfaces interfaces interfaces interfaces interfaces

ge-* scheduler-map access-port-sched ge-* unit 0 classifiers dscp dscp_trusted ge-* unit 0 rewrite-rules dscp rewrite-dscp ae0 scheduler-map network-port-sched ae0 unit 0 classifiers dscp dscp_trusted ae0 unit 0 rewrite-rules dscp rewrite-dscp

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

Copyright 2013, Juniper Networks, Inc.

79

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 detail Physical 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) 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 Output bytes : 0 Input packets: 0 Output packets: 0 Protocol eth-switch, Generation: 395, Route table: 0 Flags: Trunk-Mode (Generation 349)

0 0 0 0

bps bps pps pps

80

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Building A: Configuring EX3300 Access Switch


BUILDING A
EX4200VC-3a WLA WLA WLA EX4200VC-2a WLA
LAG

BUILDING B

EX6200-1b WLC Cluster

EX3300VC-1a WLA

Centralized DHCP and other services App Servers

WLA
LAG LAG

WLA

You are Here

SRX Series Cluster INTERNET

LAG

EX4500VC-1a

LAG

EX8200VC-1b

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 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 2. Configure the Virtual Chassis

Copyright 2013, Juniper Networks, Inc.

81

Implementation Guide Vertical Campus

Configuring Global Settings for the Access Switch


to 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: root Logging to master . JUNOS 12.1R9 built 2011-11-15 11:14:01 UTC root@: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> configure Entering 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-password New 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

82

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Configure management access

root@EX3300VC-1a# set system services web-management https system-generated-certificate set system services ssh delete system services web-management http delete system services telnet
Configure DNS

root@EX3300VC-1a# set system name-server 10.10.24.100 set system domain-name xyzcompany.com

Configuring an EX3300 Virtual Chassis


to 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 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 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 preprovisioned set virtual-chassis member 0 role line-card set virtual-chassis member 0 serial-number GE0211392919 set virtual-chassis member 1 role line-card set virtual-chassis member 1 serial-number GE0211371778 set virtual-chassis member 2 role routing-engine set virtual-chassis member 2 serial-number GB0211501128 set virtual-chassis member 4 role line-card set virtual-chassis member 4 serial-number GB0211501285 set virtual-chassis member 5 role line-card set virtual-chassis member 5 serial-number GB0211494458 set virtual-chassis member 3 role routing-engine set virtual-chassis member 3 serial-number GA0212039606
Configure Specific Virtual Chassis Commands
NOTE: 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.

Copyright 2013, Juniper Networks, Inc.

83

Implementation Guide Vertical Campus

root@EX3300VC-1a> show virtual-chassis


Preprovisioned Virtual Chassis Virtual Chassis ID: 897e.c906.f943 Virtual Chassis Mode: Enabled Member ID 0 (FPC 0) 1 (FPC 1) Status Prsnt Prsnt

Mstr Serial No Model prio GE0211392919 ex3300-24p 0 GE0211371778 ex3300-24p 0

Role Linecard Linecard

Mixed Mode NA NA

2 (FPC 2) Prsnt 3 (FPC 3) Prsnt 4 (FPC 4) Prsnt 5 (FPC 5) Prsnt

GB0211501128 ex3300-48p 129 GA0212039606 ex3300-48t 129 GB0211501285 ex3300-48p GB0211494458 ex3300-48p 0 0

Master* Backup Linecard Linecard

NA NA NA NA

Neighbor List ID Interface 5 vcp-255/1/2 1 vcp-255/1/3 0 vcp-255/1/2 2 vcp-255/1/3

1 3 2 4 3 5 4 0

vcp-255/1/2 vcp-255/1/3 vcp-255/1/2 vcp-255/1/3 vcp-255/1/2 vcp-255/1/3 vcp-255/1/2 vcp-255/1/3

Configure global Virtual Chassis commands.

root@EX3300VC-1a# set system commit synchronize set ethernet-switching-options nonstop-bridging set 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 all set protocols rstp set protocols lldp interface all set protocols lldp-med interface all set poe interface all set ethernet-switching-options storm-control interface all

84

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Configuring Layer 2 Settings for EX3300 Virtual Chassis


to 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 54 set vlans data_wired_1a vlan-id 12 set vlans data_wireless_1a vlan-id 36 set vlans voip_wired_1a vlan-id 24 set vlans voip_wireless_1a vlan-id 42 set 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 0 delete interfaces xe-5/1/0 unit 0 set interfaces xe-0/1/0 ether-options 802.3ad ae0 set 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 active set interfaces ae0 aggregated-ether-options lacp periodic slow
Disable rstp on laG connections to access switches.

Copyright 2013, Juniper Networks, Inc.

85

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 set set set set set set

interfaces interfaces interfaces interfaces interfaces interfaces interfaces

ae0 ae0 ae0 ae0 ae0 ae0 ae0

unit unit unit unit unit unit unit

0 0 0 0 0 0 0

family family family family family family family

ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching

port-mode trunk vlan members data_wired_1a vlan members voip_wired_1a vlan members access_points_1a vlan members data_wireless_1a vlan members voip_wireless_1a 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 neighbors Local Interface Parent Interface Chassis Id Name xe-0/1/0.0 ae0.0 a8:d0:e5:b5:0f:80 EX4500VC-1a xe-5/1/0.0 ae0.0 a8:d0:e5:b5:0f:80 EX4500VC-1a
Run the show lacp interfaces command to verify that LACP is running.

Port info xe-0/0/6.0 xe-1/0/6.0

System

root@EX3300VC-1a# run show lacp interfaces Aggregated 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

86

Copyright 2013, Juniper Networks, Inc.

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 set ethernet-switching-options set ethernet-switching-options set ethernet-switching-options set ethernet-switching-options set ethernet-switching-options

secure-access-port secure-access-port secure-access-port secure-access-port secure-access-port secure-access-port

vlan vlan vlan vlan vlan vlan

data_wired_1a data_wired_1a data_wired_1a voip_wired_1a voip_wired_1a voip_wired_1a

arp-inspection examine-dhcp ip-source-guard arp-inspection examine-dhcp 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 04 are reserved for wireless access points ports 526 are reserved for data. ports 2747 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
12 24 54

VLAN Name
data_wired_1a voip_wired_1a access_points_1a

Subnet
10.10.8.0/22 10.10.24.0/22 10.10.54.0/24

Port Range Name


wired_access_ports wired_voice_ports wireless_access_points

root@EX3300VC-1a# set interfaces interface-range wired_access_ports member-range ge-0/0/5 to ge-0/0/26 set interfaces interface-range wired_voice_ports member-range ge-0/0/27 to ge-0/0/47 set interfaces interface-range wireless_access_points member-range ge-0/0/0 to ge0/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 access set interfaces interface-range wired_voice_ports unit 0 family ethernet-switching port-mode access set interfaces interface-range wireless_access_points unit 0 family ethernet-switching port-mode trunk

Copyright 2013, Juniper Networks, Inc.

87

Implementation Guide Vertical Campus

Configure port to VLAN.

root@EX3300-vc2# set vlans data_wired_1a interface wired_access_ports set 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_1a set interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members voip_wireless_1a set 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.1 PING 10.10.51.1 (10.10.51.1): 56 data bytes 64 bytes from 10.10.51.1: icmp_seq=0 ttl=64 time=4.240 ms 64 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 ethernetswitching interfaces ae0 command.

root@EX3300VC-1a# run show ethernet-switching Interface State VLAN members Tag ae0.0 up access_points_1a 54 data_wired_1a 12 data_wireless_1a 36 management_1a 51 voip_wired_1a 24 voip_wireless_1a 42

interfaces ae0 Tagging Blocking tagged unblocked tagged unblocked tagged unblocked tagged unblocked tagged unblocked 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 VlaNs output.

root@EX3300VC-1a> show vlans Name Tag Interfaces access_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*

88

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Configure Class of Service


the 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 set class-of-service set class-of-service set class-of-service set class-of-service
Configuring classifiers.

forwarding-classes forwarding-classes forwarding-classes forwarding-classes forwarding-classes

class class class class class

control queue-num 7 voice queue-num 5 business-app queue-num 3 server-bulk queue-num 1 best-effort queue-num 0

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 priority low code-points nc1 set class-of-service classifiers priority low code-points nc2 set class-of-service classifiers low code-points ef set class-of-service classifiers priority low code-points af21 set class-of-service classifiers priority low code-points af11 set class-of-service classifiers priority low code-points be

dscp dscp_trusted forwarding-class control lossdscp dscp_trusted forwarding-class control lossdscp dscp_trusted forwarding-class voice loss-priority dscp dscp_trusted forwarding-class business-app lossdscp dscp_trusted forwarding-class server-bulk lossdscp dscp_trusted forwarding-class best-effort loss-

Copyright 2013, Juniper Networks, Inc.

89

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 set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service

schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers

control-network-sched shaping-rate percent 5 control-network-sched buffer-size percent 5 control-network-sched priority strict-high control-user-sched shaping-rate percent 5 control-user-sched buffer-size percent 5 control-user-sched priority strict-high voice-network-sched shaping-rate percent 5 voice-network-sched buffer-size percent 5 voice-network-sched priority strict-high voice-user-sched shaping-rate percent 5 voice-user-sched buffer-size percent 5 voice-user-sched priority strict-high business-sched transmit-rate percent 60 business-sched buffer-size percent 60 business-sched priority low server-sched transmit-rate percent 30 server-sched buffer-size percent 30 server-sched priority low be-sched transmit-rate remainder be-sched buffer-size remainder 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 scheduler control-network-sched set class-of-service scheduler-maps scheduler voice-network-sched set class-of-service scheduler-maps scheduler business-sched set class-of-service scheduler-maps scheduler server-sched set class-of-service scheduler-maps scheduler be-sched set class-of-service scheduler-maps scheduler control-user-sched set class-of-service scheduler-maps voice-user-sched set class-of-service scheduler-maps scheduler business-sched set class-of-service scheduler-maps scheduler server-sched set class-of-service scheduler-maps scheduler be-sched

network-port-sched forwarding-class control network-port-sched forwarding-class voice network-port-sched forwarding-class business-app network-port-sched forwarding-class server-bulk network-port-sched forwarding-class best-effort access-port-sched forwarding-class control access-port-sched forwarding-class voice scheduler access-port-sched forwarding-class business-app access-port-sched forwarding-class server-bulk access-port-sched forwarding-class best-effort

90

Copyright 2013, Juniper Networks, Inc.

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 priority low code-point nc1 set class-of-service rewrite-rules priority high code-point nc2 set class-of-service rewrite-rules priority low code-point ef set class-of-service rewrite-rules loss-priority low code-point af21 set class-of-service rewrite-rules loss-priority low code-point be
Configuring interfaces.

dscp rewrite-dscp forwarding-class control lossdscp rewrite-dscp forwarding-class control lossdscp rewrite-dscp forwarding-class voice lossdscp rewrite-dscp forwarding-class business-app dscp rewrite-dscp forwarding-class best-effort

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 set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service
Commit the configuration.

interfaces interfaces interfaces interfaces interfaces interfaces

ge-* scheduler-map access-port-sched ge-* unit 0 classifiers dscp dscp_trusted ge-* unit 0 rewrite-rules dscp rewrite-dscp ae0 scheduler-map network-port-sched ae0 unit 0 classifiers dscp dscp_trusted ae0 unit 0 rewrite-rules dscp rewrite-dscp

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

Copyright 2013, Juniper Networks, Inc.

91

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 detail Physical 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) 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 Output bytes : 0 Input packets: 0 Output packets: 0 Protocol eth-switch, Generation: 232, Route table: 0 Flags: Trunk-Mode (Generation 202)

0 0 0 0

bps bps pps pps

92

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Building A: Configuring EX4200 Dedicated Mode Access switch


BUILDING A
EX4200VC-3a WLA WLA WLA EX4200VC-2a WLA
LAG

BUILDING B

EX6200-1b WLC Cluster

EX3300VC-1a WLA

Centralized DHCP and other services App Servers

You are Here

WLA
LAG LAG

WLA

SRX Series Cluster INTERNET


LAG

EX4500VC-1a

LAG

EX8200VC-1b

Figure 16: EX4200VC-2a Configuration

Procedure overview
1. Configure global configuration items 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 2. Configure the Virtual Chassis

Configuring Global Settings for the Switch


to 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: root Logging to master . JUNOS 12.1R9 built 2011-11-15 11:14:01 UTC root@:RE:0%

Copyright 2013, Juniper Networks, Inc.

93

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> configure Entering 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-password New 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-certificate set system services ssh delete system services web-management http delete system services telnet
Configure DNS.

root@EX4200VC-2a# set system name-server 10.10.24.100 set system domain-name xyzcompany.com

94

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Configuring a Dedicated Mode Virtual Chassis


to 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 set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis set virtual-chassis

preprovisioned member 0 role line-card member 0 serial-number BP0211386965 member 1 role line-card member 1 serial-number BP0211386975 member 2 role line-card member 2 serial-number BP0211386950 member 3 role routing-engine member 3 serial-number BP0211386957 member 4 role routing-engine member 4 serial-number BP0211386944 member 5 role line-card member 5 serial-number FP0211490429 member 6 role line-card member 6 serial-number FP0211490761 member 7 role line-card 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.

Copyright 2013, Juniper Networks, Inc.

95

Implementation Guide Vertical Campus

root@EX4200VC-2a> show virtual-chassis Preprovisioned Virtual Chassis Virtual Chassis ID: a2e4.9152.3afe Virtual Chassis Mode: Enabled Member ID 0 (FPC 0) 1 (FPC 1) 2 (FPC 2) 3 (FPC 3) 4 (FPC 4) 5 (FPC 5) 6 (FPC 6) 7 (FPC 7) Status Prsnt Prsnt Prsnt Prsnt Prsnt Prsnt Prsnt Prsnt

Mstr Serial No Model prio BP0211386965 ex4200-48t 0 BP0211386975 ex4200-48t BP0211386950 ex4200-48t 0 0

Role Linecard Linecard Linecard Backup Master* 0 Linecard 0 Linecard 0 Linecard

BP0211386957 ex4200-48t 129 BP0211386944 ex4200-48t 129 FP0211490429 ex4200-48px FP0211490761 ex4200-48px FP0211490744 ex4200-48px

Mixed Neighbor List Mode ID Interface N 7 vcp-0 1 vcp-1 N 0 vcp-0 2 vcp-1 N 1 vcp-0 3 vcp-1 N 2 vcp-0 4 vcp-1 N 3 vcp-0 5 vcp-1 N 4 vcp-0 6 vcp-1 N 5 vcp-0 7 vcp-1 N 6 vcp-0 0 vcp-1 1

Configure global Virtual Chassis commands.

root@EX4200VC-2a# set system commit synchronize set ethernet-switching-options nonstop-bridging set chassis redundancy graceful-switchover
Commit the configuration.

root@EX4200VC-2a# 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-2a# set protocols igmp-snooping vlan all set protocols rstp set protocols lldp interface all set protocols lldp-med interface all set poe interface all set ethernet-switching-options storm-control interface all

96

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Configuring Layer 2 Settings for EX4200 Dedicated Virtual Chassis


to 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 54 set vlans data_wired_1a vlan-id 12 set vlans data_wireless_1a vlan-id 36 set vlans voip_wired_1a vlan-id 24 set vlans voip_wireless_1a vlan-id 42 set 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 0 delete interfaces xe-7/1/0 unit 0 root@EX4200VC-2a# set interfaces xe-0/1/0 ether-options 802.3ad ae0 set 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 active set 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.

Copyright 2013, Juniper Networks, Inc.

97

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 set set set set set

interfaces interfaces interfaces interfaces interfaces interfaces

ae0 ae0 ae0 ae0 ae0 ae0

unit unit unit unit unit unit

0 0 0 0 0 0

family family family family family family

ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching ethernet-switching

vlan vlan vlan vlan vlan vlan

members members members members members members

data_wired_1a voip_wired_1a access_points_1a data_wireless_1a voip_wireless_1a 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 neighbors Local Interface Parent Interface xe-0/1/0.0 ae0.0 xe-7/1/0.0 ae0.0

Chassis Id a8:d0:e5:b5:0f:80 a8:d0:e5:b5:0f:80

Port info xe-0/0/8.0 xe-1/0/8.0

System Name EX4500VC-1a EX4500VC-1a

Run the show lacp interfaces command to verify that LACP is running.

root@EX4200VC-2a> show lacp interfaces Aggregated 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.

98

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

root@EX4200VC-2a# set ethernet-switching-options set ethernet-switching-options set ethernet-switching-options set ethernet-switching-options set ethernet-switching-options set ethernet-switching-options

secure-access-port secure-access-port secure-access-port secure-access-port secure-access-port secure-access-port

vlan vlan vlan vlan vlan vlan

data_wired_1a data_wired_1a data_wired_1a voip_wired_1a voip_wired_1a voip_wired_1a

arp-inspection examine-dhcp ip-source-guard arp-inspection examine-dhcp 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 04 are reserved for wireless access points ports 526 are reserved for data. ports 2747 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
12 24 54

VLAN Name
data_wired_1a voip_wired_1a access_points_1a

Subnet
10.10.8.0/22 10.10.24.0/22 10.10.54.0/24

Port Range Name


wired_access_ports wired_voice_ports wireless_access_points

root@EX3300VC-1a# set interfaces interface-range wired_access_ports member-range ge-0/0/5 to ge-0/0/26 set interfaces interface-range wired_voice_ports member-range ge-0/0/27 to ge-0/0/47 set interfaces interface-range wireless_access_points member-range ge-0/0/0 to ge0/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 access set interfaces interface-range wired_voice_ports unit 0 family ethernet-switching port-mode access set 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_ports set 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.

Copyright 2013, Juniper Networks, Inc.

99

Implementation Guide Vertical Campus

root@EX4200VC-2a# set interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members data_wireless_1a set interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members voip_wireless_1a set 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 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-2a> ping 10.10.51.1 PING 10.10.51.1 (10.10.51.1): 56 data bytes 64 bytes from 10.10.51.1: icmp_seq=0 ttl=64 time=2.717 ms 64 bytes from 10.10.51.1: icmp_seq=1 ttl=64 time=1.887 ms 64 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 ethernetswitching interfaces ae0 command.

root@EX4200VC-2a> show ethernet-switching interfaces ae0 Interface State VLAN members Tag Tagging Blocking ae0.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 VlaNs output.

root@EX4200VC-2a> show vlans Name Tag Interfaces access_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

100

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Configure Class of Service


the 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 set class-of-service set class-of-service set class-of-service set class-of-service
Configuring classifiers.

forwarding-classes forwarding-classes forwarding-classes forwarding-classes forwarding-classes

class class class class class

control queue-num 7 voice queue-num 5 business-app queue-num 3 server-bulk queue-num 1 best-effort queue-num 0

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 priority low code-points nc1 set class-of-service classifiers priority low code-points nc2 set class-of-service classifiers low code-points ef set class-of-service classifiers priority low code-points af21 set class-of-service classifiers priority low code-points af11 set class-of-service classifiers priority low code-points be

dscp dscp_trusted forwarding-class control lossdscp dscp_trusted forwarding-class control lossdscp dscp_trusted forwarding-class voice loss-priority dscp dscp_trusted forwarding-class business-app lossdscp dscp_trusted forwarding-class server-bulk lossdscp dscp_trusted forwarding-class best-effort loss-

Copyright 2013, Juniper Networks, Inc.

101

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 set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service

schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers schedulers

control-network-sched shaping-rate percent 5 control-network-sched buffer-size percent 5 control-network-sched priority strict-high control-user-sched shaping-rate percent 5 control-user-sched buffer-size percent 5 control-user-sched priority strict-high voice-network-sched shaping-rate percent 5 voice-network-sched buffer-size percent 5 voice-network-sched priority strict-high voice-user-sched shaping-rate percent 5 voice-user-sched buffer-size percent 5 voice-user-sched priority strict-high business-sched transmit-rate percent 60 business-sched buffer-size percent 60 business-sched priority low server-sched transmit-rate percent 30 server-sched buffer-size percent 30 server-sched priority low be-sched transmit-rate remainder be-sched buffer-size remainder 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 scheduler control-network-sched set class-of-service scheduler-maps scheduler voice-network-sched set class-of-service scheduler-maps scheduler business-sched set class-of-service scheduler-maps scheduler server-sched set class-of-service scheduler-maps scheduler be-sched set class-of-service scheduler-maps scheduler control-user-sched set class-of-service scheduler-maps voice-user-sched set class-of-service scheduler-maps scheduler business-sched set class-of-service scheduler-maps scheduler server-sched set class-of-service scheduler-maps scheduler be-sched

network-port-sched forwarding-class control network-port-sched forwarding-class voice network-port-sched forwarding-class business-app network-port-sched forwarding-class server-bulk network-port-sched forwarding-class best-effort access-port-sched forwarding-class control access-port-sched forwarding-class voice scheduler access-port-sched forwarding-class business-app access-port-sched forwarding-class server-bulk access-port-sched forwarding-class best-effort

102

Copyright 2013, Juniper Networks, Inc.

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 priority low code-point nc1 set class-of-service rewrite-rules priority high code-point nc2 set class-of-service rewrite-rules priority low code-point ef set class-of-service rewrite-rules loss-priority low code-point af21 set class-of-service rewrite-rules loss-priority low code-point be
Configuring interfaces.

dscp rewrite-dscp forwarding-class control lossdscp rewrite-dscp forwarding-class control lossdscp rewrite-dscp forwarding-class voice lossdscp rewrite-dscp forwarding-class business-app dscp rewrite-dscp forwarding-class best-effort

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 set class-of-service set class-of-service set class-of-service set class-of-service set class-of-service
Commit the configuration.

interfaces interfaces interfaces interfaces interfaces interfaces

ge-* scheduler-map access-port-sched ge-* unit 0 classifiers dscp dscp_trusted ge-* unit 0 rewrite-rules dscp rewrite-dscp ae0 scheduler-map network-port-sched ae0 unit 0 classifiers dscp dscp_trusted ae0 unit 0 rewrite-rules dscp rewrite-dscp

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

Copyright 2013, Juniper Networks, Inc.

103

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 detail Physical 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) 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 Output bytes : 0 Input packets: 0 Output packets: 0 Protocol eth-switch, Generation: 179, Route table: 0 Flags: Trunk-Mode (Generation 151)

0 0 0 0

bps bps pps pps

104

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Wireless LAN Overview


BUILDING A
EX4200VC-3a WLA WLA WLA EX4200VC-2a WLA
LAG

BUILDING B

EX6200-1b WLC Cluster

EX3300VC-1a WLA

Centralized DHCP and other services

You are Here

App Servers WLA


LAG LAG

WLA

SRX Series Cluster INTERNET


LAG

EX4500VC-1a

LAG

EX8200VC-1b

Figure 17: Wireless LAN

Wireless Setup Overview


We 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
xyzcompany_internal xyzcompany_voice xyzcompany_guest

Bldg A VLAN name


data_wireless_1a voip_wireless_1a n/a

Bldg A VLAN ID
36 42 n/a

Bldg B VLAN name


data_wireless_1b voip_wireless_1b wireless_guest

Bldg B VLAN ID
32 40 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
xyzcompany_internal wireless_voip guest_wireless

Authentication Method
raDIus, 802.1x ssID password, mac raDIus, captive portal

Local or Centralized Switching


local local Centralized

Copyright 2013, Juniper Networks, Inc.

105

Implementation Guide Vertical Campus

Wireless LAN Configuration


In 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 Configuration


In 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-1b


We will use the quick start configuration script; it will guide you through the initial setup of WlC2800-1. Its 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]: y Answer the following questions. Enter ? for help. ^C to break out System Name [WLC2800]: WLC2800-1b Country Code [US]: System IP address []: 10.10.50.100 System IP address netmask []: 255.255.255.0 Default route []: 10.10.50.1 Do 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/12 Enter the time (hh:mm:ss) []: 13:21:00 Enter the timezone []: PST Enter the offset (without DST) from GMT for PST in hh:mm [0:0]: -08:00 Do you wish to configure wireless? [y]: n success: created keypair for ssh success: Type save config to save the configuration success: change accepted.
Now save your configuration.

WLC2800-1b# save config success: configuration saved


Now connect port 8 on WLC-1 to EX8200VC-1B port ge-4/0/0.

106

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Configuring VLANs and 802.1q trunking for WLC2800-1b


It 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 its 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
Creating VLANs

vlan-id 50

set vlan 50 name management


Assigning VLANs to ports

set vlan 50 port 8 tag 50


Assigning IP interfaces to VLANs
By 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.1 PING 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 ms 64 bytes from 10.10.50.1: icmp_seq=2 ttl=64 time=1.925 ms 64 bytes from 10.10.50.1: icmp_seq=3 ttl=64 time=2.302 ms 64 bytes from 10.10.50.1: icmp_seq=4 ttl=64 time=2.508 ms 64 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.

Copyright 2013, Juniper Networks, Inc.

107

Implementation Guide Vertical Campus

Running Quickstart on WLC2800-2b


We will use the quick start configuration script will guide you through the initial setup of WlC2800-1b. Its 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# quickstart This will erase any existing config. Continue? [n]: y Answer the following questions. Enter ? for help. ^C to break out System Name [WLC2800]: WLC2800-2b Country Code [US]: System IP address []: 10.10.50.101 System IP address netmask []: 255.255.255.0 Default route []: 10.10.50.1 Do you need to use 802.1Q tagged ports for connectivity on the default VLAN? [n]: 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/12 Enter the time (hh:mm:ss) []: 13:30:00 Enter the timezone []: PST Enter the offset (without DST) from GMT for PST in hh:mm [0:0]: -08:00 Do you wish to configure wireless? [y]: n success: created keypair for ssh success: Type save config to save the configuration success: change accepted. .
Save your configuration.

WLC2800-2b# save config success: configuration saved


Connect port 8 on WLC2800-2 to EX8200VC-1B port ge-20/0/0

Configuring VLANs and 802.1q trunking for WLC2800-2b


this 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 its 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

108

Copyright 2013, Juniper Networks, Inc.

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 VLANs
By 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.1 PING 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 ms 64 bytes from 10.10.50.1: icmp_seq=2 ttl=64 time=2.529 ms 64 bytes from 10.10.50.1: icmp_seq=3 ttl=64 time=2.349 ms 64 bytes from 10.10.50.1: icmp_seq=4 ttl=64 time=2.397 ms 64 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 Ringmaster
Installation 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 Ringmaster


High 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 Network


Devices 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.

Copyright 2013, Juniper Networks, Inc.

109

Implementation Guide Vertical Campus

Uploading WLC2800-1b into RingMaster


1. 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 RingMaster


1. 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 wizard


the 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

110

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Creating a Cluster in the Mobility Domain


We 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 Configuration


1. 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.

Copyright 2013, Juniper Networks, Inc.

111

Implementation Guide Vertical Campus

WLC2800-2b VLAN Configuration


1. 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 Authentication
authentication 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 configuration


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 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

112

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Cluster Guest Wireless Authentication Configuration


Now 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 Options


Depending 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 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 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 options


Depending 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 changes
1. In the Organizer pane, select the xyzcompany-HQ mobility domain 2. select xyzcompany-HQ Cluster 3. select Cluster Configuration 4. select Deploy

Copyright 2013, Juniper Networks, Inc.

113

Implementation Guide Vertical Campus

Testing RADIUS authentication


If 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 Profiles


VlaN 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 A


1. 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

114

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

VLAN Profile Building B


1. 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 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 8. We will configure the data_wireless_1b network first

Activating changes
1. In the Organizer pane, select the xyzcompany-HQ mobility domain 2. select xyzcompany-HQ Cluster 3. select Cluster Configuration 4. select Deploy

Radio Profiles
Creating Radio Profiles for building A and Building B
radio 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

Copyright 2013, Juniper Networks, Inc.

115

Implementation Guide Vertical Campus

Setting up Wireless Services


the 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 A
1. 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 B
1. 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

116

Copyright 2013, Juniper Networks, Inc.

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 Configuration
1. 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

Copyright 2013, Juniper Networks, Inc.

117

Implementation Guide Vertical Campus

Building B Configuration
1. 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 setup


For building A
1. 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

118

Copyright 2013, Juniper Networks, Inc.

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 changes
1. In the Organizer pane, select the xyzcompany-HQ mobility domain 2. select xyzcompany-HQ Cluster 3. select Cluster Configuration 4. select Deploy

For Building B
1. 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 changes
1. In the Organizer pane, select the xyzcompany-HQ mobility domain 2. select xyzcompany-HQ Cluster 3. select Cluster Configuration 4. select Deploy

Copyright 2013, Juniper Networks, Inc.

119

Implementation Guide Vertical Campus

Adding WLAs
there 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 preconfiguration 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 operators manual.

Building B WLA configuration


1. 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 WLA


1. 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

120

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Preparing Clients for Wireless Connectivity


mss 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 Access


lets 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 youre connected, the Web portal page is displayed. 5. log in using the configured username and the password

Configuring a Client for Corporate Access


Now lets 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 lets connect to the xyzcompany_internal ssID; this is really easy! If your laptop doesnt 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

Copyright 2013, Juniper Networks, Inc.

121

Implementation Guide Vertical Campus

How to verify connectivity


lets 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

122

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Adding More Clients to the WLAN


Now its time to grab your colleagues and walk them through the steps of configuring the wireless client on various mobile devices. If youve 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
BUILDING A
EX4200VC-3a WLA WLA WLA EX4200VC-2a WLA
LAG

BUILDING B

EX6200-1b WLC Cluster

EX3300VC-1a WLA

Centralized DHCP and other services App Servers

WLA
LAG LAG

WLA

SRX Series Cluster INTERNET


LAG

EX4500VC-1a

LAG

EX8200VC-1b

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.

Copyright 2013, Juniper Networks, Inc.

123

Implementation Guide Vertical Campus

SRX Cluster Ports Control Links


SRX650-1b ge-0/0/1 SRX650-2b ge-0/0/1

Fabric Links
SRX650-1b ge-0/0/2 SRX650-2b ge-0/0/2 Active (Route Weighted) SERVICE PROVIDER 1
ge-2/0/1
Fabric Link

SRX650-1b
ge-2/0/0
Control Link

10.94.44.2

INTERNET
10.94.44.6

ge-11/0/0

EX8200 Virtual Chassis

SRX650-2b

ge-11/0/2

SERVICE PROVIDER 2

Trunk Links with reth Interfaces VLAN


internet_edge management_1b guest_wireless

Interface
reth 0.44 10.10.44.252/24 reth 0.50 10.10.50.254/24 reth 0.60 10.10.60.254/24

Figure 22: SRX Link Diagram

Configuring the SRX Cluster


to 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: root Password: - - - JUNOS 12.1R9 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> configure Entering configuration mode [edit] root#

124

Copyright 2013, Juniper Networks, Inc.

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 delete delete delete delete delete delete delete delete

interfaces protocols vlans system services dhcp system services web-management http interface system services web-management https interface security zones security policies 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 reboot root> set chassis cluster cluster-id 1 node 1 reboot

Copyright 2013, Juniper Networks, Inc.

125

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 015. 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 status Cluster ID: 1 Node Priority Status Preempt Manual failover Redundancy group: 0 , Failover count: 1 node0 1 primary no no node1 1 secondary no no {secondary:node1} root> show chassis cluster status Cluster ID: 1 Node Priority Status Preempt Manual failover Redundancy group: 0 , Failover count: 0 node0 1 primary no no node1 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: KB15503, KB20672 and KB20641.

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# config root# set group set group node0 set group node1 set group node1

node0 system host-name srx650-1b interfaces fxp0 unit 0 family inet address 10.94.188.103/24 system host-name srx650-2b 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 ]

126

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Commit the configuration.

root# commit You should see the configuration applied to node0 and node1 when you issue a commit {primary:node0}[edit] root# commit node0: configuration check succeeds node1: commit complete node0: 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 Groups
set 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 set chassis cluster set chassis cluster set chassis cluster

redundancy-group redundancy-group redundancy-group redundancy-group

0 0 1 1

node node node node

0 1 0 1

priority priority priority priority

100 1 100 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 255 set 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 1 set interfaces ge-2/0/0 gigether-options redundant-parent reth0 set interfaces ge-11/0/0 gigether-options redundant-parent reth0 set interfaces reth0 redundant-ether-options redundancy-group 1

Copyright 2013, Juniper Networks, Inc.

127

Implementation Guide Vertical Campus

Configure VLANs and IP interfaces on the reth interface

root@srx650-1b# set interfaces reth0 vlan-tagging set interfaces reth0 redundant-ether-options redundancy-group 1 set 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 1 set interfaces reth0 unit 44 description internet_edge set interfaces reth0 unit 44 vlan-id 44 set interfaces reth0 unit 44 family inet address 10.10.44.254/24 set interfaces reth0 unit 50 description management set interfaces reth0 unit 50 vlan-id 50 set interfaces reth0 unit 50 family inet address 10.10.50.254/24 set interfaces reth0 unit 60 description guest_wireless set interfaces reth0 unit 60 vlan-id 60 set 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/30 set 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 Zones


the 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-screen set security zones security-zone untrust interfaces ge-11/0/2.0 set security zones security-zone untrust interfaces ge-2/0/1.0

128

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Configure the guest security zone.

root@srx650-1b# set security zones 10.10.60.0/24 set security zones set security zones set security zones services dhcp set security zones services bootp

security-zone guest address-book address guest_wireless security-zone guest host-inbound-traffic system-services ping security-zone guest host-inbound-traffic system-services traceroute security-zone guest interfaces reth0.60 host-inbound-traffic systemsecurity-zone guest interfaces reth0.60 host-inbound-traffic system-

Configure the Management security zone.

root@srx650-1b# set security zones 10.10.51.0/24 set security zones 10.10.50.0/24 set security zones set security zones set security zones set security zones set security zones set security zones traceroute set security zones

security-zone management address-book address management_1a security-zone management address-book address management_1b security-zone security-zone security-zone security-zone security-zone security-zone management management management management management management host-inbound-traffic host-inbound-traffic host-inbound-traffic host-inbound-traffic host-inbound-traffic host-inbound-traffic system-services system-services system-services system-services system-services system-services ssh http https ping snmp

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 10.10.8.0/22 set security zones 10.10.12.0/22 set security zones 10.10.20.0/22 set security zones 10.10.24.0/22 set security zones 10.10.32.0/22 set security zones 10.10.36.0/22 set security zones 10.10.40.0/23 set security zones 10.10.42.0/23 set security zones 10.10.46.0/24 set security zones 10.10.48.0/24 set security zones ping set security zones traceroute set security zones set security zones

security-zone internet_edge address-book address data_wired_1b security-zone internet_edge address-book address data_wired_1a security-zone internet_edge address-book address voip_wired_1b security-zone internet_edge address-book address voip_wired_1a security-zone internet_edge address-book address data_wireless_1b security-zone internet_edge address-book address data_wireless_1a security-zone internet_edge address-book address voip_wireless_1b security-zone internet_edge address-book address voip_wireless_1a security-zone internet_edge address-book address server_1b security-zone internet_edge address-book address server_2b security-zone internet_edge host-inbound-traffic system-services security-zone internet_edge host-inbound-traffic system-services security-zone internet_edge host-inbound-traffic protocols ospf security-zone internet_edge interfaces reth0.44

Copyright 2013, Juniper Networks, Inc.

129

Implementation Guide Vertical Campus

Configuring Security Policies.


Configure guest user policy.

root@srx650-1# set security policies from-zone guest match source-address guest_wireless set security policies from-zone guest match destination-address any set security policies from-zone guest match application any set security policies from-zone guest then permit
Configure Internet Edge Security Policy.

to-zone untrust policy allow-guest-to-internet to-zone untrust policy allow-guest-to-internet to-zone untrust policy allow-guest-to-internet to-zone untrust policy allow-guest-to-internet

root@srx650-1b# set security policies from-zone internet_edge to-zone untrust edge-to-internet match source-address data_wired_1a set security policies from-zone internet_edge to-zone untrust edge-to-internet match source-address data_wired_1b set security policies from-zone internet_edge to-zone untrust edge-to-internet match source-address voip_wired_1a set security policies from-zone internet_edge to-zone untrust edge-to-internet match source-address voip_wired_1b set security policies from-zone internet_edge to-zone untrust edge-to-internet match source-address data_wireless_1a set security policies from-zone internet_edge to-zone untrust edge-to-internet match source-address data_wireless_1b set security policies from-zone internet_edge to-zone untrust edge-to-internet match source-address voip_wireless_1a set security policies from-zone internet_edge to-zone untrust edge-to-internet match source-address voip_wireless_1b set security policies from-zone internet_edge to-zone untrust edge-to-internet match source-address server_1b set security policies from-zone internet_edge to-zone untrust edge-to-internet match source-address server_2b set security policies from-zone internet_edge to-zone untrust edge-to-internet match destination-address any set security policies from-zone internet_edge to-zone untrust edge-to-internet match application any set security policies from-zone internet_edge to-zone untrust edge-to-internet then permit

policy allow-internet_ policy allow-internet_ policy allow-internet_ policy allow-internet_ policy allow-internet_ policy allow-internet_ policy allow-internet_ policy allow-internet_ policy allow-internet_ policy allow-internet_ policy allow-internet_ policy allow-internet_ policy allow-internet_

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 20 set 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.

130

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

{primary:node0} root@srx650-1> show route inet.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.0 *[OSPF/10] 1w2d 20:45:10, metric 2 > to 10.10.44.1 via reth0.44 *[OSPF/10] 1d 04:12:46, metric 3 > to 10.10.44.1 via reth0.44 *[OSPF/10] 1w2d 20:45:10, metric 2 > to 10.10.44.1 via reth0.44 *[OSPF/10] 1d 04:12:46, metric 3 > to 10.10.44.1 via reth0.44

10.10.8.0/22 10.10.12.0/22 10.10.20.0/22 10.10.24.0/22

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 NAT
Configure the Guest NAT policy.

root@srx650-1b# set security nat source set security nat source set security nat source address 0.0.0.0/0 set security nat source nat interface

rule-set Guest-to-untrust from zone guest rule-set Guest-to-untrust to zone untrust rule-set Guest-to-untrust rule Guest-source-nat match sourcerule-set Guest-to-untrust rule Guest-source-nat then source-

Configure the Internet Edge NAT policy.

root@srx650-1b# set security nat source rule-set internet_edge-to-untrust set security nat source rule-set internet_edge-to-untrust set security nat source rule-set internet_edge-to-untrust nat match source-address 0.0.0.0/0 set security nat source rule-set internet_edge-to-untrust nat then source-nat interface

from zone internet_edge to zone untrust rule internet_edge-sourcerule internet_edge-source-

Configuring DHCP services for guest VLANs


To configure DHCP services for guest VLANS:

root@srx650-1b# set system services set system services set system services set system services set system services set system services
Commit the configuration.

dhcp dhcp dhcp dhcp dhcp dhcp

pool pool pool pool pool pool

10.10.60.0/24 10.10.60.0/24 10.10.60.0/24 10.10.60.0/24 10.10.60.0/24 10.10.60.0/24

address-range low 10.10.60.11 address-range high 10.10.60.250 domain-name xyzcompany.com name-server 208.67.222.222 name-server 208.67.220.220 router 10.10.60.254

Commit

Copyright 2013, Juniper Networks, Inc.

131

Implementation Guide Vertical Campus

Verifying NAT
You 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 Nated. 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 nat node0: -------------------------------------------------------------------------Session ID: 15945, Policy name: allow-Internet_Edge-to-internet/5, State: Active, Timeout: 1798, Valid In: 10.10.10.52/3296 --> 173.194.79.104/80;tcp, If: reth0.22, Pkts: 0, Bytes: 0 Out: 173.194.79.104/80 --> 10.94.191.233/60064;tcp, If: ge-2/0/1.0, Pkts: 36, Bytes: 37380 Total sessions: 1
Configuring general settings.
set the date and time in the format: YYYYmmDDhhmm.ss

root@srx650-1> set date 201201220830.00 Enter configuration mode Configure 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.100 set system domain-name xyzcompany.com


Configure management access.

root@srx650-1# set system services web-management https system-generated-certificate set system services ssh delete system services telnet delete system services web-management http
Configure LLDP.

root@srx650-1# set protocols lldp interface ge-2/0/0.0 set protocols lldp interface ge-11/0/0.0
Commit the configuration.

root@srx650-1# commit

this completes the srX configuration.

132

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

BUILDING A
EX4200VC-3a WLA WLA WLA EX4200VC-2a WLA
LAG

BUILDING B

You are Done!

EX6200-1b WLC Cluster

EX3300VC-1a WLA

Centralized DHCP and other services App Servers

WLA
LAG LAG

WLA

SRX Series Cluster INTERNET


LAG

EX4500VC-1a

LAG

EX8200VC-1b

Figure 23: Configuration Complete

Summary
You 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 realtime traffic demands.

Copyright 2013, Juniper Networks, Inc.

133

Implementation Guide Vertical Campus

Appendix A: Virtual Chassis


Virtual Chassis for fixed configuration EX series switches
the 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 Chassis


We 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 Mode
the 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 Mode
the 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 Mode
the 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 Chassis


It 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.

134

Copyright 2013, Juniper Networks, Inc.

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 beeither 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 preprovisioned set virtual-chassis member 0 role routing-engine set virtual-chassis member 0 serial-number GX0211411253 set virtual-chassis member 1 role routing-engine set virtual-chassis member 1 serial-number GX0211411250 set virtual-chassis member 2 role line-card set virtual-chassis member 2 serial-number FP0211333181 set virtual-chassis member 3 role line-card set 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

Copyright 2013, Juniper Networks, Inc.

135

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 Chassis Virtual Chassis ID: 804d.1d7f.fd6a Virtual Chassis Mode: Mixed Member ID 0 (FPC 0) 1 (FPC 1) 2 (FPC 2) 3 (FPC 3) Status Prsnt Prsnt Prsnt Prsnt

Mstr Serial No Model prio GX0212140825 ex4500-40f 129

Mixed Neighbor List Mode ID Interface Y 1 vcp-1 2 vcp-0 GX0212140845 ex4500-40f 129 Master* Y 3 vcp-1 0 vcp-0 FP0211490796 ex4200-48px 0 Linecard Y 3 vcp-0 0 vcp-1 FP0211490618 ex4200-48px 0 Linecard Y 1 vcp-0 2 vcp-1 Role Backup

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-chassis Preprovisioned Virtual Chassis Virtual Chassis ID: 762b.b071.4181 Virtual 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.

136

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

root@EX4500VC-1a> show virtual-chassis Preprovisioned Virtual Chassis Virtual Chassis ID: 804d.1d7f.fd6a Virtual Chassis Mode: Mixed Member ID 0 (FPC 0) 1 (FPC 1) 2 (FPC 2) 3 (FPC 3) Status Prsnt Prsnt Prsnt Prsnt

Mstr Serial No Model prio GX0212140825 ex4500-40f 129

Mixed Neighbor List Mode ID Interface Y 1 vcp-1 2 vcp-0 GX0212140845 ex4500-40f 129 Master* Y 3 vcp-1 0 vcp-0 FP0211490796 ex4200-48px 0 Linecard Y 3 vcp-0 0 vcp-1 FP0211490618 ex4200-48px 0 Linecard Y 1 vcp-0 2 vcp-1 3 Role Backup

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 Configuration


enter the following commands for all Virtual Chassis:

Commit Synchronize
this 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 Bridging
this command replicates bridging protocol information between master and backup routing engines.

set ethernet-switching-options nonstop-bridging


Graceful Switchover
Graceful 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 items


Configure 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

Copyright 2013, Juniper Networks, Inc.

137

Implementation Guide Vertical Campus

Appendix B: Configuring DHCP on EX Series Ethernet Switches


If 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 set system services 10.10.28.250 set system services set system services set system services
To view DHCP statistics

dhcp pool 10.10.28.0/24 dhcp pool 10.10.28.0/24 address-range low 10.10.28.11 high dhcp pool 10.10.28.0/24 router 10.10.28.1 dhcp pool 10.10.28.0/24 domain-name xyzcompany.com dhcp pool 10.10.28.0/24 name-server 10.10.24.100

show system services dhcp statistics


To view DHCP bindings

show system services dhcp binding

138

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Appendix C: EX8200 Virtual Chassis Overview


the 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 switchs 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.
Active XRE200 Standby XRE200

LAG

EX8200 Virtual Chassis

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

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 Ports


a 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 eX8200InterXre200, 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.

Copyright 2013, Juniper Networks, Inc.

139

Implementation Guide Vertical Campus

Virtual Chassis Ports on the XRE200 External Routing Engine


all 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 Chassis


an 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 switchs 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 ports0 through 7with 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
Native Virtual Chassis support Virtual Chassis ports Virtual Chassis mastership

EX4200 Virtual Chassis


Inherent support for Virtual Chassis by the Forwarding engine. Fixed Virtual Chassis ports. any member is eligible to be a master or backup. routing engine has an election mechanism to choose master and backup. all members are managed from the master member laG load balancing is hash based. every pFe is a node in the Virtual Chassis topology.

EX8200 Virtual Chassis


Virtual Chassis emulated using Xre200. any 10Gbe port on 8Xs line card can be aVirtual Chassis port. Body Column

Virtual Chassis management link aggregation Group Virtual Chassis path calculation

all members are managed from master Xre200. laG load balancing is chassis-local. 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
eX8208 or eX8216 switch Xre200

Role
line card master or backup routing engine

Member IDS
0-7 8-9

table 18 illustrates the port numbering used by the eX8200VC based on member number and type of chassis.

140

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

Table 18: EX8200VC FPC and Interface Numbering


Member ID
0 1 2 3

FPC Numbering
0 through 15 for eX8216 0 through 7 for eX8208 16 through 31 for eX8216 16 through 23 for eX8208 32 through 47 for eX8216 32 through 39 for eX8208 48 through 63 for eX8216 48 through 55 for eX8208

Network Port Interface Range


xe-0/0/0 to xe-15/0/7 xe-0/0/0 to xe-7/0/7 xe-16/0/0 to xe-31/0/7 xe-16/0/0 to xe-23/0/7 xe-32/0/0 to xe-47/0/7 xe-32/0/0 to xe-39/0/7 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

Copyright 2013, Juniper Networks, Inc.

141

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

142

Copyright 2013, Juniper Networks, Inc.

Implementation Guide Vertical Campus

About Juniper Networks


Juniper Networks is in the business of network innovation. From devices to data centers, from consumers to cloud providers, Juniper Networks delivers the software, silicon and systems that transform the experience and economics of networking. the company serves customers and partners worldwide. additional information can be found at www.juniper.net.

Copyright 2013, Juniper Networks, Inc.

143

Implementation Guide Vertical Campus

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

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

to purchase Juniper Networks solutions, please contact your Juniper Networks representative at 1-866-298-6428 or authorized reseller.

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.

8010091-001-eN Jan 2013

printed on recycled paper

144

Copyright 2013, Juniper Networks, Inc.

You might also like