Vertical Campus - Juniper Networks · the Juniper Networks Vertical Campus tested design is based...

Implementation Guide

Copyright © 2013, Juniper Networks, Inc. 1

Although Juniper Networks has attempted to provide accurate information in this guide, Juniper Networks does not warrant or guarantee

the accuracy of the information provided herein. Third party product descriptions and related technical details provided in this document

are for information purposes only and such products are not supported by Juniper Networks. All information provided in this guide is

provided “as is”, with all faults, and without warranty of any kind, either expressed or implied or statutory. Juniper Networks and its

suppliers hereby disclaim all warranties related to this guide and the information contained herein, whether expressed or implied of

statutory including, without limitation, those of merchantability, fitness for a particular purpose and noninfringement, or arising from a

course of dealing, usage, or trade practice.

VertICal Campus

2 Copyright © 2013, Juniper Networks, Inc.

Implementation Guide – Vertical Campus

Table of ContentsIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

Design Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Wired LAN Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6WLAN Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8SRX Series Service Gateway Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Virtual Chassis for Collapsed Backbone Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Subnets and VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Class of Service and Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Forwarding Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Random Early Detection and Congestion Avoidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Remarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Class of Service Used in Design Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Wired LAN Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Building B: Configuring the Campus Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16EX8200 Virtual Chassis Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Verifying and Upgrading the Software Version for XRE200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Verifying and Upgrading the Software Version for EX8200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Configuring the EX8200 for Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Preprovisioning the XRE200 for Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Assembling the EX8200 Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Configuring Virtual Chassis Ports on the EX8200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Configuring Global Settings for the Core EX8200 Virtual Chassis Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Configuring Layer 2 Settings on EX8200 Virtual Chassis Core Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27Configuring Layer 3 Settings for the EX8200 Virtual Chassis Core Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Configure Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Verifying Class of Service Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Building B: Configuring the Access Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Software Version /Upgrading the EX6200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39EX6200 Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Configuring Global Settings for the EX6210 Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Configuring the EX6200 Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Configuring Layer 2 Settings for EX6200 Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Configure Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Verifying Class of Service Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Building A: Configuring the core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

EX4500 Virtual Chassis Procedure Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Configuring Global Settings for the Core Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Configuring a Virtual Chassis for the Mixed Mode Core Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Configuring Layer 2 Settings For Mixed Mode Core Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Configuring Layer 3 Settings For Mixed Mode Core Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61Configure Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Verifying Class of Service Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Building A: Configuring the Access Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Configuring EX4200 as Extended Mode Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Configuring Global Settings for the Core Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Configuring an Extended Mode Virtual Chassis for the EX4200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68To configure a Virtual Chassis for the core switch: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Configuring Layer 2 Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72Configure Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77Verifying Class of Service Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Building A: Configuring EX3300 Access Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81Configuring Global Settings for the Access Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Configuring an EX3300 Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83



Configuring Layer 2 Settings for EX3300 Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Configure Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Building A: Configuring EX4200 Dedicated Mode Access switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Configuring Global Settings for the Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Configuring a Dedicated Mode Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Configuring Layer 2 Settings for EX4200 Dedicated Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Configure Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Wireless LAN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Wireless Setup Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Wireless LAN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Pre-requisites for WLAN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Running Quick start on WLC2800-1b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Configuring VLANs and 802 .1q trunking for WLC2800-1b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107Running Quickstart on WLC2800-2b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Configuring VLANs and 802 .1q trunking for WLC2800-2b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Installing Ringmaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Configuring WLCs and WLAs using Ringmaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Add devices to a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Uploading WLC2800-1b into RingMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Uploading WLC2800-2b into RingMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Creating a Mobility Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Activating Changes from the cluster wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Creating a Cluster in the Mobility Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111WLC2800-1b VLAN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111WLC2800-2b VLAN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Configuring Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Cluster RADIUS configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Cluster Guest Wireless Authentication Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Configuring the RADIUS Authentication Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Creating a RADIUS Server Group for guest users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Configuring the SmartPass authentication options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Setting up VLAN Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114VLAN Profile for Building A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114VLAN Profile Building B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Radio Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Creating Radio Profiles for building A and Building B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Setting up Wireless Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Setting up Building A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Setting up Building B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Setting up Wireless Voice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Building A Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Building B Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Guest Wireless setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Adding WLAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Building B WLA configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Preparing Clients for Wireless Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Configuring a Client for Guest Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Configuring a Client for Corporate Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

SRX Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Configuring the SRX Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124

Configuring Security Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Configuring Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Configuring Routing and OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Configuring NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Configuring DHCP services for guest VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133Appendix A: Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134Appendix B: Configuring DHCP on EX Series Ethernet Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Appendix C: EX8200 Virtual Chassis Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Appendix D: References and Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142About Juniper Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143



List of FiguresFigure 1: Overview of the Tested Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Figure 2: Guest Wireless Overview (Centralized WLAN Switching) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Figure 3: Local Switching Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Figure 4: WLC Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Figure 5: SRX Zone Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Figure 6: SRX Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

Figure 7: Configuring the EX8200VC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figure 8: Building B Connection Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figure 9: EX8200 Virtual Chassis Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Figure 10: EX8200 Interface Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Figure 11: EX6200 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Figure 12: EX4500VC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Figure 13: Building A Connection Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Figure 14: EX4200VC-3a Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Figure 15: Configuration of EX3300VC-1a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81

Figure 16: EX4200VC-2a Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Figure 17: Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Figure 18: Wireless Network Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Figure 19: ipconfig Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Figure 20: Verifying Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Figure 21: SRX Network Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Figure 22: SRX Link Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124

Figure 23: Configuration Complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133

Figure 24: EX8200 Virtual Chassis with XRE200 Connected to Each Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

List of TablesTable 1: Equipment and Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Table 2: Campus VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Table 3: VLANs by Building . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Table 4: Building A VLAN and Device Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Table 5: Building B VLAN and Device Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Table 6: CoS by Device Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Table 7: CoS Forwarding Classes Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Table 8: VLANs Configured on EX6200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Table 9: EX6200 Trunked VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Table 10: VLAN to Port Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Table 11: EX4200 Virtual Chassis 1 VLAN Address Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Table 12: EX3300 VLAN IP Address Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Table 13: EX4200 Virtual Chassis 2 VLAN IP Address Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Table 14: SSID VLAN Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Table 15: Authentication Methods by SSID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Table 16: EX4200/4500 and EX8200 Side by Side Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Table 17: EX8200 Virtual Chassis Member IDs and Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Table 18: EX8200VC FPC and Interface Numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141



Introductionthe Juniper Networks® Vertical Campus Implementation Guide provides a simple, tested, step-by-step process

for rapidly deploying a large campus solution. the deployment incorporates the most commonly used enterprise

network technologies to provide a simple and scalable network architecture that includes laN, WlaN, and security

components. this guide presents a specific configuration of Juniper Networks hardware and software platforms that

have been tested and provide a reliable foundation on which to base a customized network for your business.

the tested implementation is created with the following design objectives:

• easy to deploy – Consistent deployment approach for all products included in the design. the examples provide

reference methodologies and configurations to enable rapid deployment of a resilient network infrastructure.

• resilient – simple and robust design, maximizing user productivity by protecting traffic against unplanned outages.

• Flexible – adapted for modular expansion so that users can scale and adapt the network without requiring extensive

changes or forklift upgrades.

• solid foundation – easy support for additional technologies, such as video, collaboration, and other real-time traffic

demands.

some of the advantages include:

• modular design – each technology presented can be deployed independently of the others

• efficient and cost-effective deployment using a standardized design methodology

• redundant, highly available infrastructure for wired, wireless, and Internet connectivity

• Deployable by It professionals with a moderate amount of technical experience

• easy to manage, with few logical devices and protocols to configure

• standardized methodology to reduce deployment time

• reduced number of hardware and software platforms to learn, maintain, and spare

Scopethis document presents a sequential construction and configuration of a tested design that you can successfully

reproduce. the first part of the document describes the network elements used and their operation. It also includes

a scheme for a common layer 2 (l2) and layer 3 (l3) set of boundaries and network interfaces. the implementation

portion contains the specific configurations used to create this network.

this guide is intended for network designers and administrators who:

• Have a network that supports 1,000 or more connected employees

• require wired and wireless access for their employees

• Need a simplified, resilient network infrastructure

• Need a high-performance network that can be easily expanded and adapted to support new technologies

• are new to Juniper Networks products

• are system engineers who need a standardized process to design and deploy networks that comprise Juniper Networks

laN, WlaN, and security products

Design Considerationsthe Juniper Networks Vertical Campus tested design is based on Juniper Networks switching, wireless laN, and

security products. It presents an overall design with configurations to construct a campus network for 1,000 or more

users. this tested design is intended to be a starting point for configuring your own network and incorporates the most

commonly used enterprise network technologies. For information on additional functionality for each product, consult

the appendixes at the end of this document.

Design Componentsthe network detailed in this document is divided into three separate functional blocks or modules—laN and switching

infrastructure, wireless, and security. these sections highlight the design choices and main features implemented for

each component. although each section can stand on its own, the sections are presented in the logical sequence in

which the network would be deployed.

the equipment and software listed in table 1 conform to what was used to verify this design and its included features.

Future software releases should support the same functionality. Check the release notes for the specific version of

software you intend to deploy before deploying Ip in your specific environment.



Table 1: Equipment and Software

Model Software Description

eX-Xre200-aC 12.1r1.9 eX8200 Virtual Chassis Juniper Networks Xre200 external routing engine with dual aC power supplies, dual fans, two 160 GB hard disks and one 4-port 10/100/1000Base-t rJ-45 I/O card

eX8208-reDuND-aC 12.1r1.9 redundant eX8208 2000 W aC system bundle: 8-slot chassis with passive backplane and 1x fan tray, 2x routing engine with switch fabric, 1x switch fabric module, 6x 2000 W aC psus with power cords, and all necessary blank panels

eX8200-8Xs n/a 8-port 10 Gbe sFp+ line card; requires sFp+ optics sold separately

eX8200-40Xs n/a 40-port Gbe / 10Gbe line card; requires sFp and/or sFp+ optics sold separately

eX4500-40F-VC1-FB 12.1r1.9 40-port Gbe/10Gbe sFp/sFp+ front-to back airflow, 128 Gbps Virtual Chassis Interconnect module, hardware support for Data Center Bridging, and support for eight pFC (802.1Qbb) queues

eX4200-48p 12.1r1.9 48-port 10/100/1000Base-t (48 poe ports) + 930 W aC psu. Includes 50cm Virtual Chassis cable.

eX-pWr2-930-aC n/a 930 W poe+ aC power supply unit (psu)

eX-um-2X4sFp n/a 2-port 10G sFp+ / 4-port 1G sFp uplink module

eX3300-48p 12.1r1.9 eX3300 48-port 10/100/1000Base-t (48 poe+ ports) with 4 sFp+ uplink ports (optics not included)

eX3300-24p 12.1r1.9 eX3300 24-port 10/100/1000Base-t (24 poe+ ports) with 4 sFp+ uplink ports (optics not included)

eX3300-48t 12.1r1.9 eX3300 48-port 10/100/1000Base-t with 4 sFp+ uplink ports (optics not included)

eX-sFp-10Ge-DaC-1m n/a sFp+ 10-Gigabit ethernet Direct attach Copper (twinax copper cable) 1 m

srX650-Base-sre6-645ap 12.1r1.9 srX650 services Gateway with sre 6, 645 W aC poe psu; includes 4 onboard 10/100/1000Base-t ports, 2 GB Dram, 2 GB CF, 247 W poe power, fan tray, power cord and rack-mount kit

srX-Gp-16Ge n/a • 16 port• 10/100/1000Base-t• XpIm

WlC2800* 7.7.1.6 WlaN controller with two 10Gbe XFp ports and 8 x 1000Base-t (rJ-45 and sFp) ports, including single psu and 64 ap license.

Wla532-us* n/a ap with dual radios 802.11a/b/g/n 3x3 mImO (3ss), single 1000Base-t 802.3af poe ethernet port, 6 internal antennas. Not rated for plenum use. Ceiling mount bracket included. For operation only in usa.

Wlm-rmts-10 7.7.1.3.0

*When estimating your wireless needs, 25–30 users per ap is a good place to start for most wireless deployments. For

highest performance wireless, one ap per 10–15 users is the recommended starting value.

Wired LAN Infrastructurethe example network tested is shown in Figure 1. It uses a two-tiered, collapsed core network model in each building.

this design combines the distribution and core layers together, reducing the complexity and cost of the network.

the heart of the network is the switching infrastructure. Juniper Networks eX8200 ethernet switches are used for the

campus core. the two eX8200 switches are configured as a single Virtual Chassis, which provides high availability (Ha)

and resiliency features not found in standalone chassis-based solutions. this configuration provides hardware-level

redundancy with a simplified configuration process because only one logical device needs to be configured, instead of

manually configuring and synchronizing multiple core devices.

the Juniper Networks Virtual Chassis technology reduces the number of actively managed devices and removes the

need for relying on legacy redundancy protocols, such as spanning tree protocol (stp) and Virtual router redundancy

protocol (Vrrp). Virtual Chassis also provides the flexibility to incrementally grow the network on an as-needed basis

without compromising performance or availability.



WLA

WLA

WLA

WLA

WLA

WLA

WLA

BUILDING A BUILDING B

EX4200VC-2a

EX3300VC-1a

EX4200VC-3a

LAGLAG

LAGEX8200VC-1b

SRX SeriesCluster

WLCCluster

INTERNET

EX6200-1b

App Servers

Centralized DHCPand other services

EX4500VC-1a LAG

LAG

Figure 1: Overview of the Tested Network

Building Athe Building a core provides high-density 10-Gigabit ethernet (10Gbe) and 1-Gigabit ethernet connectivity by

combining the Juniper Networks eX4500 ethernet switch and Juniper Networks eX4200 ethernet switch in a single

Virtual Chassis. this provides the core connectivity and routing for the network and acts as the layer 2 and layer 3

boundary for the access switches. the Building a core is connected to the Building B core (eX8200 Virtual Chassis)

using four 10Gbe ports configured as a routed link aggregation group (laG) and distributed across multiple line cards

on each side for redundancy.

the access layer uses eX4200 and/or eX3300 series switches providing power over ethernet (poe) and layer 2

connectivity back to the core, using two 10Gbe ports configured for laG. each access switch is connected back to the

core on different line cards, providing protection in case a single device fails on either end.

Building BBuilding B serves as the campus core; this is where all services are centrally located. the WaN connection, servers,

WlaN controllers all reside in Building B.

the Building B core is made up of two Juniper Networks eX8208 ethernet switches and two Juniper Networks Xre200

external routing engines, which are configured as a single Virtual Chassis. servers and services are directly connected

to the core switches. the eX8200 Virtual Chassis has many separate points of redundancy. each eX8208 has

redundant route engines that are connected to the Xre200. the Xre200s act as primary and backup route-engines

for the eX8200 Virtual Chassis. the eX8208 switches are connected together using six 10Gbe interfaces configured

as Virtual Chassis ports. this system is highly resilient and will be fully functional even if multiple components fail. see

the Best Practice Guidelines for Deploying EX8200 Virtual Chassis Configurations for more information.

the access layer in Building B uses eX6210 switches. the eX6210 is a modular chassis that meets the high-density

1Gbe and poe connectivity that is required in heavily populated environments. the eX6210 is equipped with redundant

route-engines and is connected to the building core via four 10Gbe interfaces. the interfaces are configured as a laG

and distributed between the eX8208 switches so that there is no single point of failure.

http://www.juniper.net/us/en/local/pdf/implementation-guides/8010081-en.pdf



WLAN Infrastructurethe wireless network is configured for centralized switching of guest user traffic, as shown in Figure 2. Wireless user

traffic is received by access points (aps) and then sent to the wireless laN controller (WlC). the WlC then identifies

the traffic by user profile, authenticates against raDIus, and places the traffic in the proper VlaN. the gateway

for guest access traffic is the Juniper Networks srX series services Gateway, which provides isolation between the

enterprise users and guest users.

enterprise users and voice users use the local switching feature of the wireless system, as shown in Figure 3. enterprise

users are authenticated using 802.1x and raDIus when they connect to the wireless network. When an enterprise user

is authenticated, the Wla (Wireless laN access point) places user traffic directly onto the local VlaN to which the

user is assigned. this approach provides the lowest latency, highest performance, and best scalability. an individual

Wla can handle local and centralized switching of traffic simultaneously.

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

WLA

SRX SeriesCluster

WLCCluster

WLC places user tra�c into

guest_wirelessVLAN (60)

xyzcompany_guestWLAN

SRX Series is theonly gateway for

guest_wireless VLAN (60)

INTERNET

SwitchTra�c Tunneled

to/from WLCEX Series

Figure 2: Guest Wireless Overview (Centralized WLAN Switching)

Guest users are placed on the guest VlaN and can access the Internet only. Corporate users have full access to the

intranet and the Internet.

WLAs use local switching for xyzcompany_internal and xyzcompany_voice WLAN SSIDs.

WLAs are configured with trunk ports so they can place user tra�c directly onto the correct VLAN without tunneling tra�c to the WLC.

WLA

VoIP PhoneFile Server

WLC places user tra�c into

guest_wirelessVLAN (60)

xyzcompany_internal orxyzcompany_voice WLANs

Trunk Port

SwitchEX Series

Figure 3: Local Switching Overview



You can configure the WlCs in clusters of up to 32 units. the design example uses a two-WlC cluster, as shown in

Figure 4. the primary WlC (also known as the primary seed controller) is in charge of configuration management for all

WlCs and aps and acts as a central configuration point for all wireless laN changes.

Each WLA forms two WLC connections — a primary WLC connection and a backupWLC connection. This provides non-stop wireless performance in case of failure.

The primary WLC is the configuration point for the network andautomatically load balances WLAs between the WLCs in the cluster.

Wireless LANController

Cluster

WLA

WLA

PrimaryWLC

SecondaryWLC

SwitchEX Series

Figure 4: WLC Clustering

the primary WlC also configures and load-balances the aps across the WlCs to distribute the wireless traffic load.

access points form connections with two separate WlCs—one connection is active, and the other acts as a backup. If

the connection to the active WlC is interrupted, the backup connection takes over immediately, preserving all existing

wireless sessions so that users are not affected.

SRX Series Service Gateway Infrastructurethe Juniper Networks srX series services Gateway is a zone-based firewall in which different traffic networks are

classified as logical zones for easier management. Figure 5 illustrates the logical zones that are defined in the tested

design and the VlaNs contained in each zone.

this illustration sets the Guest zone apart from the eX series to present a clear logical view. the eX series switches

provide only layer 2 connectivity for these zones. the Guest VlaNs use the srX series services Gateway as their

default gateway to obtain Ip addresses using DHCp.

INTERNET EDGE ZONE

MANAGEMENT ZONE

EX SeriesSwitch SRX650-2b

data_wireless_1a data_wireless_1bdata_wired_1b data_wired_1a

management_1bmanagement_1a

UNTRUST ZONEvoip_wired_1a voip_wired_1bservers_1b servers_2b

access_points_1a access_points_1bvoip_wireless_1a voip_wireless_1b

internet_edge

SRX650-1b

GUEST ZONEguest_wireless

INTERNET

SERVICEPROVIDER 1

SERVICEPROVIDER 2

Figure 5: SRX Zone Overview

the Internet edge zone is where most of the tested network VlaNs reside. each VlaN uses the eX series core switch

as its gateway. the internet_edge VlaN is where the eX series forwards traffic requests intended for the Internet to

the srX series. the management VlaNs are in the management zone and kept separate by security policies on the

srX series. this security configuration protects the network management system from intrusion. the untrust zone

connects the srX series to the Internet and is where Network address translation (Nat) is performed. this zone highly

restricts inbound traffic from the Internet.



Clustering SRX Service GatewaysYou can configure the srX series services Gateways as a cluster that operates as a single device with a single point

of configuration. traffic state is maintained between each pair of devices. When the srX series devices are clustered,

you can configure special interfaces called redundant ethernet (reth) interfaces. a reth interface has a primary and

secondary owner. traffic is directed to the primary owner, and the secondary owner takes over in case of a failure.

When clustered, the srX series devices have a control link to maintain state, configuration, and all other control

features. they also have a fabric link that is used to forward traffic within the cluster.

In this network, the srX series services Gateways are configured to use the fabric link to forward traffic in case of WaN

connection failures. this is a useful configuration for any similar network design that has two service providers and uses

Nat, resulting in two possible source addresses for Internet-bound traffic.

Figure 6 illustrates normal and failure traffic flow.

SRX Tra�c Flow—Normal

SRX650-1b

SRX650-2b

Worldwide Web,FTP, email, etc.

ge-4/0/1

ge-20/0/1

ge-2/0/0

ge-11/0/0

ge-2/0/1 10.94.44.2

10.94.44.6ge-11/0/2

INTERNET

SERVICEPROVIDER 2

EX8200Virtual Chassis

SERVICEPROVIDER 1

SRX Tra�c Flow—SRX650-1b Reth Failure

SRX650-1b

SRX650-2b


ge-4/0/1

ge-20/0/1

ge-2/0/0

ge-11/0/0

ge-2/0/1 10.94.44.2

10.94.44.6ge-11/0/2

INTERNET

SERVICEPROVIDER 2


SERVICEPROVIDER 1

SRX Tra�c Flow—SRX650-1b Failure

SRX650-1b

SRX650-2b


ge-4/0/1

ge-20/0/1

ge-2/0/0

ge-11/0/0

ge-2/0/1 10.94.44.2

10.94.44.6ge-11/0/2

INTERNET

SERVICEPROVIDER 2EX8200

Virtual Chassis

SERVICEPROVIDER 1

SRX Tra�c Flow—Service Provider 1 Failure

SRX650-1b

SRX650-2b


ge-4/0/1

ge-20/0/1

ge-2/0/0

ge-11/0/0

ge-2/0/1 10.94.44.2

10.94.44.6ge-11/0/2

INTERNET

SERVICEPROVIDER 2EX8200

Virtual Chassis

SERVICEPROVIDER 1

Figure 6: SRX Traffic Flow

the srX devices tested are configured in an active or passive mode when service provider 1 has a better route

preference and is used for all Internet traffic, unless there is an outage. traffic is allowed to be routed across the fabric

link to retain the use of service provider 1 in case of a local interface outage. this removes the need to reset the session

because the source Nat addresses do not change.



In the examples illustrated in Figure 6, no session is reset in the case of local link failure because there is no change in

the source Nat address for the sessions—they continue to use the same service provider. Where the source address for

srX650-1b or service provider 1 is lost completely, traffic switches to service provider 2. the source Ip address for the

traffic changes when this occurs and results in existing sessions being reset due to the change.

Virtual Chassis for Collapsed Backbone Designtraditional networks achieve high availability and performance by configuring redundant devices and complex

protocols in multiple tiers that each require independent configuration, thereby increasing network complexity. this

design uses a collapsed core, a two-tier model that combines the distribution and core layers, reducing the complexity

and cost of the network. although the tiers are reduced, the network provides the redundancy benefits typically

associated with multiple-tiered designs.

a Virtual Chassis allows multiple eX series switches to act as a single device, achieving device-level redundancy

without creating loops in the network, requiring additional protocols, or tedious configuration management between

devices. all links can be fully utilized, reducing the cost associated with bandwidth upgrades and providing improved

resiliency and performance.

the core and distribution layer is commonly configured as the layer 2 and layer 3 boundary. using a Virtual Chassis in

both the core and access layer allows further simplification of the network by reducing the number of actively managed

devices.

NOTE: Juniper Virtual Chassis technology is unique in its ability to span distances of up to 40 km between devices.

multiple wiring closets—in the same or different buildings—can be easily combined to reduce the total number of

managed devices.

Subnets and VLANsIt is highly recommended that you consistently implement a VlaN and subnetting convention throughout a deployed

network to decrease network management and troubleshooting complexity. You can easily adapt the configuration

presented in this section to any network environment. the configuration matches the VlaN ID with the third octet of

the subnet used (where applicable) to simplify the network and maintain consistency. It is also recommended to leave

room between VlaN numbering to allow for future expansion and to maintain a consistent range of VlaNs for specific

functions. the network example uses the following VlaNs and addressing.

• VlaNs 8–31 are dedicated to wired data and voice. the tested design uses only four of these VlaNs, leaving plenty of

room for future expansion.

• VlaNs 32–42 are dedicated for corporate wireless data and voice access. the tested design uses only four of these

VlaNs

• VlaNs 44–59 are dedicated for network infrastructure.

- the management VlaN manages all the network devices, such as switches and routers.

- the ap VlaNs provide connectivity to the Wlas.

- the server VlaNs service network servers and applications. they are connected to the network.

- the internet_edge VlaN is where the eX8200 Virtual Chassis ethernet switch connects to the srX series services

Gateway and further out to the Internet. this is where the majority of security policies on the srX series are enforced.

• VlaN 60 is used for guest wireless access. the guest VlaN connects directly to the srX series services Gateway. the eX

series switches do not have any interfaces on the guest VlaN—it acts only as a layer 2 switch.

the network example uses private addressing, which enables flexible Ip address allocation. In this design, many of

the networks use a 24-bit subnet mask, but larger subnet masks are used for some services to reduce the number of

subnets and VlaNs to be managed and simplify configuration. larger subnets reduce the number of subnets required,

allowing more hosts to participate in each subnet.

the VlaNs are named in this order: purpose, number, and building. For example, the VlaN name “data_wired_1a”

indicates the purpose (data wired) , the number of the VlaN (1), and the building (a).

You should also reserve some addresses on each subnet for networking devices, typically the first or last few addresses

in a subnet. this design reserves the first 10 Ip addresses of the subnet for network devices and the last Ip address

(.254) for the srX series interface if it resides on a subnet.

tables 2 and 3 map the VlaNs IDs and subnets that are configured on each device. the core switches are configured to

support all VlaNs pertinent to their building. each access switch is configured with its management VlaN address.



Table 2: Campus VLANs

VLAN ID VLAN Name Subnet

8 data_wired_1b 10.10.8.0/22

12 data_wired_1a 10.10.12.0/22

20 voip_wired_1a 10.10.20.0/22

24 voip_wired_1b 10.10.24.0/22

32 data_wireless_1a 10.10.32.0/22

36 data_wireless_1b 10.10.36.0/22

40 voip_wireless_1a 10.10.40.0/23

42 voip_wireless_1b 10.10.42.0/23

44 internet_edge 10.10.44.0/24

46 servers_1b 10.10.46.0/24

48 servers_2b 10.10.48.0/24

50 management_1b 10.10.50.0/24

51 management_1a 10.10.51.0/24

52 access_points_1b 10.10.52.0/24

54 access_points_1a 10.10.54.0/24

60 guest_wireless 10.10.60.0/24

Table 3: VLANs by Building

Building A VLANs Building B VLANs

VLAN ID VLAN Name Subnet VLAN ID VLAN Name Subnet

12 data_wired_1a 10.10.12.0/22 8 data_wired_1b 10.10.8.0/22

24 voip_wired_1a 10.10.24.0/22 20 voip_wired_1b 10.10.20.0/22

36 data_wireless_1a 10.10.36.0/22 32 data_wireless_1b 10.10.32.0/22

42 voip_wireless_1a 10.10.42.0/23 40 voip_wireless_1b 10.10.40.0/23

51 management_1a 10.10.51.0/24 44 internet_edge 10.10.44.0/24

54 access_points_1a 10.10.54.0/24 46 servers_1b 10.10.46.0/24

48 servers_2b 10.10.48.0/24

50 management_1b 10.10.50.0/24

52 access_points_1b 10.10.52.0/24

60 guest_wireless 10.10.60.0/24

the wireless aps are on the access_points VlaNs for each building and communicate with the WlCs that reside on the

management_1b VlaN.

NOTE: Having Wlas and WlCs on different subnets requires configuring the WlC Ip addresses using option 43 on

the DHCp servers so that the Wlas boot and find the WlCs automatically. see Deploying a Secure Wireless LAN or

Juniper’s Mobility System Software Configuration Guide for more details on Wla boot options.

Wireless traffic from guest users on the aps is placed in the proper VlaN when received by the WlC. each WlC has a

configured trunk port on the management_1b and guest_wireless VlaNs.

http://www.juniper.net/us/en/community/junos/training-certification/day-one/wireless/deploying-a-secure-wireless-lan/

http://www.juniper.net/techpubs/en_US/release-independent/wireless/information-products/topic-collections/wireless-lan/software/7.6/mss-76-qsg.pdf



Table 4: Building A VLAN and Device Map

Building A Device and VLAN Map

VLAN ID VLAN Name Subnet EX4200-

VC-1aEX3300-

VC-1aEX4200-

VC-2aEX4200-

VC-3a WLA

12 data_wired_1a 10.10.12.0/22 Ip VlaN VlaN VlaN

20 voip_wired_1a 10.10.20.0/22 Ip VlaN VlaN VlaN

32 data_wireless_1a 10.10.32.0/22 Ip VlaN VlaN VlaN VlaN

40 voip_wireless_1a 10.10.40.0/23 Ip VlaN VlaN VlaN VlaN

51 management_1a 10.10.51.0/24 Ip Ip Ip Ip

54 access_points_1a 10.10.54.0/24 Ip VlaN VlaN VlaN Ip

Table 5: Building B VLAN and Device Map

Building B Device and VLAN Map

VLAN ID VLAN Name Subnet EX8200-

VC-1bEX6200

-1b WLC SRX WLA

8 data_wired_1b 10.10.8.0/22 Ip VlaN

24 voip_wired_1b 10.10.24.0/22 Ip VlaN

36 data_wireless_1b 10.10.36.0/22 Ip VlaN VlaN

42 voip_wireless_1b 10.10.42.0/23 Ip VlaN VlaN

44 internet_edge 10.10.44.0/24 Ip Ip

46 servers_1b 10.10.46.0/24 Ip

48 servers_2b 10.10.48.0/24 Ip

50 management_1b 10.10.50.0/24 Ip Ip Ip Ip

52 access_points_1b 10.10.52.0/24 Ip VlaN Ip

60 guest_wireless 10.10.60.0/24 VlaN Ip Ip

Class of Service and Quality of Servicethis section provides a high-level description of the most commonly used Juniper quality of service (Qos) and class of

service (Cos) items. Not all of these are used in the network example. they are listed here to provide a comprehensive

picture of the options available.

For the purposes of this guide, Qos is the manipulation of aggregates of traffic so that each is forwarded in a fashion

that is consistent with the required behaviors of the applications generating that traffic. From a user’s point of view,

Qos is experienced on the end-to-end (usually round trip) flow of traffic. It is implemented as a set of behaviors at

each hop. this is an important distinction. Basically, a single hop with no configured Qos can destroy the end-to-end

experience, and subsequent nodes can do nothing to recover the end-to-end quality of experience for the user. that

does not mean that Qos must be configured at every hop. However, it is critical to understand that a single, congested

hop can be the undoing of the most intricate Qos design.

On the other hand, Cos within the Junos Os is a configuration construct used to configure an individual node to

implement certain behaviors at that node so that the end-to-end Qos is consistent with the desired end-to-end user

experience or application behavior.

each class is associated with an aggregate of traffic that requires the same behaviors as it flows through the network

device. Classes do not relate implicitly to traffic belonging to a single application. Instead, any application requiring the

same behaviors generates traffic belonging to the same class.

each Cos implementation has certain functions that are required to be able to influence the behavior of outbound

packets on a particular interface. In the network example, only some of the Qos and Cos methods are used. For more

information on these methods, see Deploying Basic QoS or Juniper technical documentation.

NOTE: each vendor’s networking equipment implements the control of these functions in different ways and might use

slightly different terminology. the terminology in this guide is used in Junos Os configurations. the explanations are

vendor-agnostic to be broadly applicable to different vendors’ equipment.

http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/deploying-basic-qos/



Forwarding Classa forwarding class is a label used entirely within a network node. It identifies all traffic that requires a single behavior

when leaving that node. a forwarding class does not explicitly appear outside a node. although if the Qos configuration

of all nodes in a network is consistent, it can easily be derived from information in packet headers.

ClassificationClassification identifies the class to which a packet belongs. Classification is usually initially performed on ingress

to each node, although a packet can be reclassified at various points on its path through a network node. Junos Os

has three main approaches to classifying packets, which vary in their degree of flexibility and in the complexity of

the required configuration: interface-based, behavior aggregate (Ba), and multifield (mF). these approaches are not

mutually exclusive and can be applied in a series to get a less granular first-pass behavior, followed by a more granular

reclassification of a subset of the traffic.

Interface-based ClassificationIf all traffic arriving on a single interface is known to be associated with a single class, the easiest way to classify this

traffic is to associate all traffic arriving on the interface with the relevant forwarding class. While trivial to implement,

this method assumes that all traffic arriving on the interface is of the same class. there is no inherent mechanism

to indicate any exceptions, so it is very inflexible. You can use interface-based classification in conjunction with mF

classifiers to provide more granular exceptions to the default interface classification, if required.

TIP: this mechanism is useful if the upstream node is untrusted and you want to bleach all traffic coming in by

applying a single class (usually Best effort).

Behavior Aggregate ClassificationBa classification provides a good balance between flexibility and complexity. this approach is particularly attractive

when the traffic being classified is transported in large aggregates, for example, in the core of a network where

traffic associated with many unique applications passes over a single link, making mF classification unattractive. Ba

classification relies on markings placed in the headers of incoming packets: ethernet frames, Ipv4 or Ipv6 packets,

or mpls frames. each of these packet or frame types includes a field in the header specifically designated for the

indication of a class to which this packet has been previously assigned.

ethernet 802.1Q VlaN frames include three 802.1p bits to indicate previous assignment. Ipv4 packets have the type

of service byte from which you can use either the three precedence bits or 6 bits to indicate the Diffserve Code point

(DsCp). Ipv6 has 6 bits of the Ipv6 DsCp, and mpls has the three experimental bits. the network example uses the

DsCp marking and Ba classification method.

the main constraint with this model is that the upstream node must be trusted to correctly (and fairly) mark packets.

If the upstream node cannot be trusted, the node could mismark traffic into a class that receives a higher Qos than it

requires.

Multifield Classificationthe most flexible but most complex classification to configure and maintain is mF classification. It uses firewall filters,

also known as access lists, to identify arbitrary attributes of an Ip packet—it is less commonly applicable to non-Ip

traffic types—and places traffic into a particular traffic class based on the contents of the Ip packet.

this approach is constrained only by the characteristics that can be matched in a firewall filter. It is possible to be very

granular in the choice of traffic class to which the packet belongs. However, granular choices require comparatively

complex filters, which might have to be customer-specific. this degree of complexity and administrative overhead

makes using mF classifiers attractive when the upstream node is not trusted (or not able) to mark the packets, and the

requirement to apply Qos based on arbitrary parameters is strong.

mF classifiers can also be used to modify the forwarding class selected by a Ba or interface classifier. You make a

rough classification based on a Ba or interface marking and then reclassify a subset of the traffic based on arbitrary

attributes in the Ip headers. the network example does not use mF classification, but it can be easily added to the

network.

Policingpolicing applies a hard limit to the rate at which traffic can access a resource (for example, upon ingress to a node or

to a queue on egress). a policer constrains access to the node or queue. If a packet is determined to be nonconforming

and should not gain access to the protected resource, it is dropped or reclassified. the hard-drop behavior can have a

negative impact, particularly on tCp traffic and when the policer is run consistently at its limit. While it is possible to

reclassify packets based on a policer, it is important to avoid reordering packets in applications that are sensitive to the

order in which packets are received, such as voice, video, and other real-time traffic. the example does not use policing.



Random Early Detection and Congestion Avoidancerandom early detection (reD), also known as random early discard, is a congestion avoidance mechanism. It helps

mitigate the impact of congestion, specifically with tCp-based traffic. For a thorough review of the behavior of tCp in

the presence of congestion and why reD can help avoid some of the worst aspects of that behavior, see QoS Enabled Networks: Tools and Foundations, by peter lundqvist and miguel Barreiros, (2011, John Wiley & sons).

By selecting random tCp packets from a queue and discarding them, the endpoint that was awaiting delivery of that

packet fails to send an acknowledgement for the packet (or, if that packet was an acknowledgement, the far end does

not receive the acknowledgement). this triggers retransmission of the packet and reduces the transmission window

size. as a consequence, it also reduces the speed with which the source transmits tCp packets, thereby reducing the

degree of congestion. the random nature of selecting packets to be dropped ensures that no single flow of traffic,

application, or source is unfairly penalized, and every source continues to get its “fair share” of the available capacity on

a link that is close to congestion.

although the mechanism is “fair” to all, Qos is not necessarily about being fair to all. rather, Qos is about ensuring that

high-priority traffic—high value or sensitive to loss, latency, or jitter—is given priority. to manipulate the rate at which

packets belonging to particular forwarding classes are dropped, it is necessary to apply a weight to each forwarding

class. this process is known as weighted reD (WreD). It is particularly important to apply a weight to avoid dropping

packets in forwarding classes that are intolerant of loss, such as expedited forwarding and assured forwarding.

Often, the traffic associated with applications that are intolerant of loss, latency, and jitter is transported in uDp. In this

case, using reD is counterproductive because it damages the perceived Qos of the application. In addition, because

uDp has no built-in mechanism to identify the loss of a packet and modify its rate of transmission, the packet is either

lost (reducing the perceived Qos) without having significant impact on the throughput, or worse, the application

identifies the loss and demands retransmission of the packet, so the packet is then seen twice, potentially increasing

the congestion. the network example does not use WreD.

Shapingshaping limits the rate at which traffic can be transmitted. unlike policing, it acts on traffic that has already been

granted access to a queue but is awaiting access to transmission resources. traffic that does not conform to the

shaper’s criteria is held in the queue until it does conform. No explicit constraint is placed on more traffic entering

the queue, as long as the queue is not full. shaping can be less aggressive than policing and have fewer negative side

effects.

Schedulingscheduling decides the order in which to place packets onto the wire based on the class to which they belong or the

queue in which they are waiting. there are multiple queues, all of which may contain packets waiting to be transmitted,

but only a single serial transmission medium is available. the configuration must designate which queue to service first,

for how long, and with what frequency.

Remarkingethernet, mpls, Ipv4, and Ipv6 packets all have a field in the header that can be used to inform another node about a

classification decision made earlier in the path. remarking places a value in the header of an outgoing packet, which

identifies the class to which the packet was assigned by the transmitting router. subsequent nodes can use this

marking to easily and consistently classify the packet using a Ba classifier. It is possible to remark each packet header

type using each marking type (Ieee 802.1p, mpls eXp, Ipv4 precedence, Ipv4 DsCp, or Ipv6 DsCp) that can be used by

Ba classifiers.

Class of Service Used in Design Examplethe network example addresses a primarily unicast environment with little to no multicast. If multicast is present, it is

treated as best effort. If more multicast handling is required, additional queues can be configured to properly manage

that traffic, but it is outside the scope of this document. For more information, see Enabling Class of Service on EX Series Switches in a Campus LAN or Juniper technical documentation.

table 6 shows the Cos settings used in the network example. Depending on the role the device plays in the network,

different features are enabled. For example, on the access devices, traffic is classified and remarked if needed. It is

assumed that remarking has already occurred at the access layer devices, so it is not required on the core devices.

the example uses the Ba classification method, which assumes that traffic is being properly classified by the hosts

or application before entering the switch. this type of deployment is considered a trusted environment. If the network

hosts do not mark traffic, you can configure the access layer to use mF classification instead, which allows for flexible

identification and classification of almost any traffic type.





Table 6: CoS by Device Role

Device Role Classification Congestion Management Scheduling Rate Shaping Remarking

Core Ba - X X X

access Ba - X X X

table 7 lists the queues and forwarding classes used in the network example. traffic is classified by DsCp marking

on the received packets. We have identified several DsCp classifiers and assigned them to queues. additional DsCp

classifiers can be assigned to these queues and is described in the configuration section.

Table 7: CoS Forwarding Classes Used

Forwarding Class Queue # DSCP Buffer Transmit Rate Rate Shaping

control 7NC1/Cs6NC2/Cs7

5% n/a 5%

voice 5 eF 5% n/a 5%

business-app 3 aF21 40% 40% n/a

server-bulk 1 aF11 30% 30% n/a

best-effort 0 n/a remainder remainder n/a

NOTE: eX series switches require a scheduler for every queue used. Queues without a scheduler are not serviced.

eX series switches support eight queues. the tested network example uses five queues. the remaining three queues

can be configured at a later time if additional granularity is needed. It is typically easier to use fewer queues than trying

to define a queue for each application type.

Implementationeach deployment section provides step-by-step processes to set up the network components. each section is

independent. although they can be configured in any order, they are presented in a logical chronology in which each

section builds on the previous one. When deploying a new network, we recommend that you follow the order outlined

here. as you progress through the deployment sections, the diagrams indicate the components being configured. the

“You are here” labels point to where you are in the configuration process.

Wired LAN DeploymentBuilding B: Configuring the Campus Corethe core switch, as shown in Figure 7, connects all networking components together. In this network, it is responsible

for routing all traffic on the intranet, and it is the default gateway for all user networks in Building B, except the Guest

network wireless traffic. Guest access is routed directly to the srX series to maintain clear separation between the

guest and user network traffic. the WlCs, srX series, and network servers and services are also connected directly to

the core.



WLA

WLA

WLA

WLA

WLA

WLA

WLA


EX4200VC-2a

EX3300VC-1a

EX4200VC-3a

LAGLAG

LAGEX8200VC-1b

SRX SeriesCluster

WLCCluster

INTERNET

EX6200-1b

App Servers


EX4500VC-1a LAG

LAG

You are Here

Figure 7: Configuring the EX8200VC

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

xe-16/0/0

ge-0/0/2

ge-0/0/0

ge-0/0/2

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

SRE1-me0SRE0-me0SRE1-me0 SRE0-me0

ge-0/0/0

Member 1

Member 9Member 8

Master RE

To Building A

Backup RE

Line Card 1(slots 16-31)

Control Link Fabric Link

Member 0Line Card 0(slots 0-15)

xe-18/0/0

EX8200-1b EX8200-2b

SRX650-1b

SRX650-2b

INTERNET

EX6200-1b

WLC2800-1b

XRE200-1b XRE200-2b

WLC2800-2b

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

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

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

ge-11/0/0 ge-11/0/2

ge-9/0/1

ge-0/0/1

ge-9/0/2

ge-0/0/2

ge-2/0/0 ge-2/0/1

ge-4/0/0

port 8

port 8

xe-1/0/4

xe-1/0/5

xe-17/0/5ge-20/0/0

xe-17/0/4

xe-5/0/0

xe-4/0/0 xe-5/0/1

xe-4/0/1

Figure 8: Building B Connection Details



EX8200 Virtual Chassis Configurationthe eX8200 Virtual Chassis consists of two eX8200 chassis and two Xres. Because the eX8200 Virtual Chassis has

several components and can be configured in multiple ways, we suggest reading the Best Practice Guidelines for Deploying EX8200 Virtual Chassis Configurations or Appendix B: EX8200 Virtual Chassis Overview for the available

options and features. this guide steps through the required items for configuring the eX8200 in a Full mesh Fabric

mode configuration, as shown in Figure 9.

ge-0/0/2

ge-0/0/0

ge-0/0/2ge-0/0/1ge-0/0/1


ge-0/0/0

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

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

EX8200-1b EX8200-2b

XRE200-1b XRE200-2b

Figure 9: EX8200 Virtual Chassis Layout

the network example assumes that all eX8200s and Xres are running the default configuration as a starting point.

Procedure overview 1. upgrade all Xre200s and eX8200s to the same version of the Juniper Networks Junos® operating system.

2. Configure global configuration items.

3. Configure the Virtual Chassis.

4. Configure layer 2 settings.

5. Configure layer 3 settings.

6. Configure Cos.

Verifying and Upgrading the Software Version for XRE200the Os version used for the tested network is Junos Os 12.1r1.9, available at www.Juniper.net/support. all Xre200

routing engines must be running the same version.

1. unpack the Xres.

2. Connect to the Xre Console port (setting: s9600, 8, 1, none).

3. press enter. the following prompt appears.

Amnesiac (ttyu0)login

4. log in as root and press enter.

Because no password is configured, you are not prompted for one.

login: rootLogging to master.– – – JUNOS 11.4R1.6 built 2011-11-15 11:14:01 UTCroot@:RE:0%

5. Verify that the Xre is running the correct Os version (12.1r1.9 for this validation). If the version is correct, verify the next

Xre by repeating steps 1–4.



http://www.juniper.net/support



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.


Log in as root and press Enter.Because no password is configured, you are not prompted for one.


Type cli at the % prompt.

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

Enter configuration mode by typing configure or edit.

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

At the # prompt, configure the password.

root# set system root-authentication plain-text-passwordNew password:*******Retype new password:*******{master:0}[edit]root#

Configure the management (me0) interface.

root# set interfaces me0 unit 0 family inet address <IP address/mask>commit and-quit

Connect the me0 interface to the network and upgrade the XREthe following line uploads the code and reboots the system.

root> request system software add ftp://anonymous@<IP_address>/<code_version> reboot

Verify the version after rebooting.

Repeat the process for the remaining devices.

http://kb.juniper.net/InfoCenter/index%3Fpage%3Dcontent%26id%3DKB20552%26actp%3DRSS



Verifying and Upgrading the Software Version for EX8200the tested network example assumes that each eX8200 has dual routing engines. You must verify, and possibly

upgrade, the software for each routing engine. the Os version used for the tested network is Junos Os 12.1r1.9, available

at www.juniper.net/support. all eX8200 routing engines must be running the same version. perform the following for

routing engine 0 and routing engine 1.

Connect to the Console port of EX8200 routing engine 0 (Setting: s9600, 8, 1, none).press enter. the following prompt appears.



login: rootLogging to master.– – – JUNOS 12.1r1.9 built 2011-11-15 11:14:01 UTCroot@:RE:0%root@:RE:0%

Verify that routing engine 0 is running the correct Os version. If the version is correct, verify the routing engine 1 by

repeating steps 1–3.





At the # prompt, configure the password.




Connect the me0 interface to the network and upgrade the XRE the following line uploads the code and reboots the system.


Verify the version after rebooting.

Repeat the process for the other routing engines.




Configuring the EX8200 for Virtual ChassisOn the master routing engine of the first EX8200, connect to the console port (Setting: s9600, 8, 1, none).

Log in as root and enable edit mode.

root@ex8200> edit

Enable graceful switchover, nonstop routing, and nonstop bridging.

root# set chassis redundancy graceful-switchoverset system commit synchronizeset routing-options nonstop-routingset ethernet-switching-options nonstop-bridging commit and-quit

Configure resilient dual-boot partitions.this step is highly recommended because it improves the resiliency of the system in case of a primary boot partition

failure. It creates a backup copy of the Os. the process takes approximately 5 minutes for each routing engine or

member.

request system snapshot slice alternate all-members

Configure the EX8200 for Virtual Chassis.

root@ex8200> set chassis virtual-chassis This will reboot the RE(s)Do you want to continue ? [yes, no] yes

Verify that the EX8200 has booted back up in Virtual Chassis mode.after you log in to the eX8200 and type cli, you should see this:

root@:RE:0% cliwarning: This chassis is operating in a non-master role as part of a virtual-chassis (VC) system.warning: Use of interactive commands should be limited to debugging and VC Port operations.warning: Full CLI access is provided by the Virtual Chassis Master (VC-M) chassis.warning: The VC-M can be identified through the show virtual-chassis status command executed at this console.warning: Please logout and log into the VC-M to use CLI.{master:0}

You can also verify the mode using the show virtual-chassis status command.

the following example shows that Virtual Chassis mode is enabled.

{master:0}root> show virtual-chassis status

Virtual Chassis ID: 5ddf.6b28.132fVirtual Chassis Mode: Enabled Mastership Neighbor ListMember ID Status Serial No Model priority Role ID Interface0 (FPC 0-15) Prsnt BT0910434033 ex8208 0 Linecard*

Repeat these steps for the second EX8200 Virtual Chassis.



Preprovisioning the XRE200 for Virtual ChassisIt is important to understand the numbering of Virtual Chassis members before continuing with the configuration. the

member details are shown in Figure 10. the following eX8200 Virtual Chassis numbering is used:

• primary Xre200 is member 8

• Backup Xre200 is member 9

• eX8200 Virtual Chassis are member 0 and member 1.

1. Identify the serial number for each component of the Virtual Chassis (Xre200 and eX8200 chassis serial numbers) and

determine the member ID for each device.

2. log in to the Xre that is used as the master Xre and enable edit mode.

root@ex8200> edit

3. preprovision the chassis. Only preprovisioned eX8200 Virtual Chassis are supported.

4. the Xres are configured as routing engines, and the eX8200s are configured as line cards. Note which member ID each

device is assigned, because you need that information when configuring the chassis later.

root#set virtual-chassis preprovisionedset virtual-chassis member 8 role routing-engineset virtual-chassis member 8 serial-number 042011000023set virtual-chassis member 9 role routing-engineset virtual-chassis member 9 serial-number 042011000036set virtual-chassis member 0 role line-cardset virtual-chassis member 0 serial-number BT0910433933set virtual-chassis member 1 role line-cardset virtual-chassis member 1 serial-number BT0910434033

NOTE: split-detection is enabled by default. However, all devices in the test network are located in the same room and

have many redundant connections, so an accidental chassis split is highly unlikely. But because this is the network core,

we recommend leaving split-detection enabled. If you want to disable split-detection, use the set virtual-chassis no-

split-detection command. If you are not familiar with how split-detection works, review the split-detection section in

appendix a.

ge-0/0/2

ge-0/0/0

ge-0/0/2ge-0/0/1ge-0/0/1


ge-0/0/0

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

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

Member 1

Member 9Member 8

Master RE Backup RE

Line Card 1(slots 16-31)

Member 0Line Card 0(slots 0-15)

EX8200-1b EX8200-2b

XRE200-1b XRE200-2b12

2

3

3

4

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

Connect XRE200-1b ge-0/0/1 to EX8200-1b SRE0 me0, and ge-0/0/2 to EX8200-2b SRE0 me0

Connect XRE200-2b ge-0/0/1 to EX8200-1b SRE1 me0, and ge-0/0/2 to EX8200-2b SRE1 me0

Configure VCP ports on EX8200s and connect together

1

2

3

4

Figure 10: EX8200 Interface Connections



Assembling the EX8200 Virtual Chassis Now that all the components are ready to be connected, we can start assembling the Virtual Chassis.

1. Connect the two Xre200s using ge-0/0/0 on each Xre200.

2. Verify that the Xres have identified each other properly:

root> show virtual-chassis

Preprovisioned Virtual ChassisVirtual Chassis ID: 1716.387c.f292Virtual Chassis Mode: Enabled Mastership Neighbor ListMember ID Status Serial No Model priority Role ID Interface0 (FPC 0-15) NotPrsnt BT0910433933 ex82081 (FPC 16-31) NotPrsnt BT0910434033 ex82088 (FPC 128-143) Prsnt 042011000023 ex-xre 129 Master* 9 vcp-0/09 (FPC 144-159) Prsnt 042011000036 ex-xre 129 Backup 8 vcp-0/0

3. Connect Xre200-1b ge-0/0/1 to the management port of eX8200VC-1b master routing engine 0. Connect Xre200-1b

ge-0/0/2 to the management port of eX8200VC-2b master routing engine 0.

4. Connect Xre200-2b ge-0/0/1 to the management port of eX8200VC-2b backup routing engine 1. Connect Xre200-2b

ge-0/0/2 to the management port of eX8200VC-2b backup routing engine 1.

5. Verify that the eX8200s have been identified properly and joined the Virtual Chassis:

{master:8}root> show virtual-chassis

Preprovisioned Virtual ChassisVirtual Chassis ID: 1716.387c.f292Virtual Chassis Mode: Enabled Mastership Neighbor ListMember ID Status Serial No Model priority Role ID Interface0 (FPC 0-15) Prsnt BT0910433933 ex8208 0 Linecard 8 vcp-0/0 9 vcp-0/11 (FPC 16-31) Prsnt BT0910434033 ex8208 0 Linecard 8 vcp-0/0 9 vcp-0/18 (FPC 128-143) Prsnt 042011000023 ex-xre 129 Master* 9 vcp-0/0 0 vcp-1/0 1 vcp-1/19 (FPC 144-159) Prsnt 042011000036 ex-xre 129 Backup 8 vcp-0/0 0 vcp-1/0 1 vcp-1/1



Configuring Virtual Chassis Ports on the EX8200Only line-rate 10Gbe ports on the eX8200-8Xs line card support VCps. the 10Gbe network ports are converted to

VCps in pairs. For example, interfaces xe-0/0/0 and xe-0/0/1 are both converted to VCps, even though the ClI request

is to convert only one of them. VCps for both eX8200 Virtual Chassis members are configured from the master

Xre200 operational mode.

these are operational commands and are not entered in edit mode. these commands do not appear in the

configuration of the device. the port configurations are specific to each eX8200 chassis and do not reflect the Virtual

Chassis port numbering. For example, eX8200-2b, as part of a Virtual Chassis, uses slots 16–31 when configuring

ports in normal operation. However, because VCps are special, they are configured as their native port designations. to

configure port xe-0/0/6 as a VCp on eX8200-2b, type the following command:

request virtual-chassis vc-port set fpc-slot 0 pic-slot 0 port 6 member 1

We use six ports: xe-0/0/6, xe- 0/0/7, xe-1/0/6, xe-1/0/7, xe-2/0/6, and xe-2/0/7. You only need to configure the first

port in each pair.

Configure the VCPs for EX8200-1b.

root>request virtual-chassis vc-port set fpc-slot 0 pic-slot 0 port 6 member 0member0:--------------------------------------------------------------------------This will also convert FPC slot 0 PIC slot 0 Port 7 to virtual chassis port.

root> request virtual-chassis vc-port set fpc-slot 1 pic-slot 0 port 6 member 0member0:--------------------------------------------------------------------------This will also convert FPC slot 1 PIC slot 0 Port 7 to virtual chassis port.root> request virtual-chassis vc-port set fpc-slot 2 pic-slot 0 port 6 member 0member0:--------------------------------------------------------------------------This will also convert FPC slot 2 PIC slot 0 Port 7 to virtual chassis port.

Configure the VCPs for EX8200-2b.

root> request virtual-chassis vc-port set fpc-slot 2 pic-slot 0 port 6 member 1member1:--------------------------------------------------------------------------This will also convert FPC slot 2 PIC slot 0 Port 7 to virtual chassis port.root>

request virtual-chassis vc-port set fpc-slot 0 pic-slot 0 port 6 member 1member0:--------------------------------------------------------------------------This will also convert FPC slot 0 PIC slot 0 Port 7 to virtual chassis port.

root> request virtual-chassis vc-port set fpc-slot 1 pic-slot 0 port 6 member 1member0:--------------------------------------------------------------------------This will also convert FPC slot 1 PIC slot 0 Port 7 to virtual chassis port.



Connect all six ports together to create a highly resilient LAG connection between the EX8200 chassis, which will be spread across three separate cards in each chassis .

Connect the EX8200s together using the six ports.Verify that the VCps on the eX8200s came up correctly.

{master:8}root> show virtual-chassis vc-portmember0:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfaceSlot/PIC/Portvcp-0/0 Dedicated -1 Up 1000 8 vcp-1/0vcp-0/1 Dedicated -1 Up 1000 9 vcp-1/00/0/6 Configured 3 Up 10000 1 vcp-0/0/60/0/7 Configured 3 Up 10000 1 vcp-0/0/71/0/6 Configured 3 Up 10000 1 vcp-1/0/61/0/7 Configured 3 Up 10000 1 vcp-1/0/72/0/6 Configured 3 Up 10000 1 vcp-2/0/62/0/7 Configured 3 Up 10000 1 vcp-2/0/7

member1:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfaceSlot/PIC/Portvcp-0/0 Dedicated -1 Up 1000 8 vcp-1/1vcp-0/1 Dedicated -1 Up 1000 9 vcp-1/10/0/6 Configured 3 Up 10000 0 vcp-0/0/60/0/7 Configured 3 Up 10000 0 vcp-0/0/71/0/6 Configured 3 Up 10000 0 vcp-1/0/61/0/7 Configured 3 Up 10000 0 vcp-1/0/72/0/6 Configured 3 Up 10000 0 vcp-2/0/62/0/7 Configured 3 Up 10000 0 vcp-2/0/7

NOTE: Only the eX8200 is shown for brevity.

Configure graceful switchover and nonstop routing.

root# set chassis redundancy graceful-switchoverset system commit synchronizeset routing-options nonstop-routingset ethernet-switching-options nonstop-bridgingcommit and-quit

use the following commands to view the status of the Virtual Chassis:

show virtual-chassis

show virtual-chassis vc-port

this completes the setup of the basic eX8200 Virtual Chassis. Now it’s time to configure it.



Configuring Global Settings for the Core EX8200 Virtual Chassis SwitchConnect to the Console port of the Master XRE200 and login (Setting: s9600, 8, 1, none). Note the version of Junos at the prompt and update as needed.

login: rootLogging to master.– – – JUNOS 12.1r1.9 built 2011-11-15 11:14:01 UTCroot@:RE:0%



You should now be at the >prompt.

Configure the date and time in the format: YYYYMMDDhhmm.ss.

set date 201210220830.00



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

Configure the time zone.

root# set system time-zone America/Los_Angeles

Configure the hostname.

root# set system host-name EX8200VC-1b

Configure the management interfaces on the XREs.

EX8200VC-1b#set groups member8 interfaces me0 unit 0 family inet address <IP address/mask>set groups member9 interfaces me0 unit 0 family inet address <IP address/mask>set apply-groups member8set apply-groups member9

Configure management access.

root@EX8200VC-1b# set system services web-management https system-generated-certificateset system services sshdelete system services web-management httpdelete system services telnet

Configure DNS.

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

YYYYMMDDhhmm.ss

xyzcompany.com



Configure NTP.

set system ntp server 10.10.46.100

Configuring Layer 2 Settings on EX8200 Virtual Chassis Core Switchto configure layer 2 parameters and settings on the core switch:

Set the bridge priority on the core switch.NOTE: spanning tree protocol is enabled to prevent loops from forming in the network, even though we do not use it as

a topology protocol. as an extra precaution, we set the bridge priority on the core switch to 8192, which ensures that it

is the default root bridge in the event another bridging device is connected to the network. Juniper Networks eX series

switches run rstp by default.

root@EX8200VC-1b# set protocols rstp bridge-priority 8k

commit

Configure VLANs and IP interfaces.NOTE: We configure all of the inter-VlaN routing on the core switch, except for our guest VlaN. this makes it easier to

simultaneously configure the VlaNs and Ip interfaces for those VlaNs. When creating VlaN names, it is important to

note that these names are case sensitive.

In our examples you may notice that the VlaN ID is the same as the interface VlaN unit number. this is not mandatory,

but we recommend that you match the VlaN ID and interface VlaN unit number. this helps to make things easier to

understand later when you have many VlaNs and interfaces to track.

NOTE: When you issue a large number of commands at once, it is recommended that you issue a commit command to

verify that the commands take effect with no configuration errors. alternatively, a commit check can be issued instead,

which verifies the configuration without making it active.

the complete set of VlaN and layer 3 interface statements for the core switch in the tested network example follows.

We also add the guest VlaN here, but we do not assign any layer 3 interfaces to this VlaN, because routing for the

VlaN are done using the srX series firewall.

VLAN Configurations

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

VLAN Interface Configuration

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



IP interface configuration.

root@EX8200VC-1b# set interfaces vlan unit 8 family inet address 10.10.8.1/22set interfaces vlan unit 20 family inet address 10.10.20.1/22set interfaces vlan unit 32 family inet address 10.10.32.1/22set interfaces vlan unit 40 family inet address 10.10.40.1/23set interfaces vlan unit 44 family inet address 10.10.44.1/24set interfaces vlan unit 46 family inet address 10.10.46.1/24set interfaces vlan unit 48 family inet address 10.10.48.1/24set interfaces vlan unit 50 family inet address 10.10.50.1/24set interfaces vlan unit 52 family inet address 10.10.52.1/24

the interface configuration for laG ae1 which connects to eX4500VC-1a is layer 3 interface and communicates routing

information using the OspF protocol. We will configure the laG for this in the next section.

root@EX8200VC-1b# set interfaces ae1 unit 0 family inet address 10.10.200.1/24commit

Configure LAG (aggregated Ethernet) portsIn the tested network configuration, the laG ports configured will be used to connect to the eX6200 series access

switches and for the inter-building connection to the eX4500VC-1a core chassis for building a.

Junos Os requires that you configure the number of laG interfaces you want to use before you begin configuring

the interfaces. We suggest picking a number slightly larger than you might need, in case you need to add more laG

interfaces later. You can change this value in the future. We need two aggregated ethernet ports for the tested network

example, but most deployments would have more than a single eX6200 so we will configure the core chassis with

eight, allowing us to add additional devices later without having to adjust this.

root@EX8200VC-1b#set chassis aggregated-devices ethernet device-count 8

to provide the highest level of resilience, you want to configure the laG to span multiple eX8200 slots and chassis.

NOTE: If the interfaces we want to use are currently configured, that configuration will need to be removed before they

can be enabled as laG the eX8200 chassis has no port configuration by default, so we can skip this step and move

directly to configuring the ports.

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

root@EX8200VC-1b# set interfaces xe-0/0/0 ether-options 802.3ad ae1set interfaces xe-2/0/0 ether-options 802.3ad ae1set interfaces xe-16/0/0 ether-options 802.3ad ae1set interfaces xe-18/0/0 ether-options 802.3ad ae1set interfaces xe-1/0/4 ether-options 802.3ad ae0set interfaces xe-1/0/5 ether-options 802.3ad ae0set interfaces xe-17/0/4 ether-options 802.3ad ae0set interfaces xe-17/0/5 ether-options 802.3ad ae0

Next we want to add LACP to each LAG interface to provide some health checking.

NOTE: You need to configure laCp on the interfaces at both ends for the laG port to become active.

root@EX8200VC-1b# set interfaces ae0 aggregated-ether-options lacp activeset interfaces ae0 aggregated-ether-options lacp periodic slowset interfaces ae1 aggregated-ether-options lacp activeset interfaces ae1 aggregated-ether-options lacp periodic slow



Disable RSTP on LAG connections to access switches.

Because we are not using stp, we can disable it on the laG ports going to our access switches. this also reduces

potential convergence times in case a laG member fails, because fewer protocols need to converge.

NOTE: all access switches have rstp enabled locally to prevent looping.

root@EX8200VC-1b# set protocols rstp interface ae0.0 disable

commit

Configure trunk, access and VLAN settings for LAGs.We need to configure the laG ports as trunks and add the VlaNs that will be supported on the individual access

switches. after setting the trunks, commit the configuration.

root@EX8200VC-1b# set interfaces ae0 unit 0 family ethernet-switching port-mode trunk

commit

Configure VLANs on the trunk ports.You can configure port-to-VlaN mapping in two different ways:

• You can configure the VlaNs directly as part of the port configuration.

• You can configure the ports included in the VlaN under the VlaN configuration.

each of these has different advantages and disadvantages. Generally, it makes sense to configure access ports (client-

facing) under the VlaN configuration and configure VlaNs directly on the port for trunk port configuration. You cannot

configure the VlaN mapping in both places, because that might result in errors when doing a configuration commit

operation.

as discussed, it is recommended to configure the VlaNs that the trunk port will carry directly on the interface

configuration section. this simplifies identifying what VlaNs a specific trunk is part of when viewing the configuration.

When adding VlaNs directly to a trunk port you have the option of adding them by their VlaN ID or by the VlaN name.

In this example, we will add them by VlaN name; this makes the overall configuration more readable.

to add several VlaNs to a trunk, you can either specify them one at a time or you can specify several VlaNs at the

same time by enclosing them in [] brackets and separating them with spaces.

The VLAN configuration for ae0 connecting to EX6200-1b

root@EX8200VC-1b# set interfaces ae0 unit 0 family ethernet-switching vlan members [ data_wired_1b voip_wired_1b data_wireless_1b voip_wireless_1b access_points_1b management ]

or you can enter it one line at a time

set interfaces ae0 unit 0 family ethernet-switching vlan members data_wired_1bset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wired_1bset interfaces ae0 unit 0 family ethernet-switching vlan members data_wireless_1bset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wireless_1bset interfaces ae0 unit 0 family ethernet-switching vlan members access_points_1bset interfaces ae0 unit 0 family ethernet-switching vlan members management_1b

Configure dual-homed or other network device connections.Configuring connections for other devices that are dual homed (but do not use laG connections or other network

equipment) typically involves connections to the core and trunk ports. In the tested network, the srX series and

wireless laN controllers both use clustering technologies to provide High availability, In this case they are not

configured with laG connections to the core. each of these devices requires two identical port configurations on

separate eX series switches to provide link-level and box-level redundancy.



Configure Wireless LAN controllers.Connect wireless laN controllers (WlCs) to ports ge-4/0/0 and ge-20/0/0 and add them to the following VlaNs:

management, and guest_wireless.

root@EX8200VC-1b# set interfaces ge-4/0/0 unit 0 family ethernet-switching port-mode trunkset interfaces ge-4/0/0 unit 0 family ethernet-switching vlan members management_1bset interfaces ge-4/0/0 unit 0 family ethernet-switching vlan members guest_wirelessset interfaces ge-20/0/0 unit 0 family ethernet-switching port-mode trunkset interfaces ge-20/0/0 unit 0 family ethernet-switching vlan members management_1bset interfaces ge-20/0/0 unit 0 family ethernet-switching vlan members guest_wireless

Configure SRX Firewalls.Connect the srX firewalls to ports ge-2/0/47 and ge-3/0/47 and make them part of the following VlaNs: Internet_

edge, management, Guest_Wired and Guest_Wireless.

root@EX8200VC-1b# set interfaces ge-4/0/1 unit 0 family ethernet-switching port-mode trunkset interfaces ge-4/0/1 unit 0 family ethernet-switching vlan members internet_edgeset interfaces ge-4/0/1 unit 0 family ethernet-switching vlan members management_1bset interfaces ge-4/0/1 unit 0 family ethernet-switching vlan members guest_wireless

set interfaces ge-20/0/1 unit 0 family ethernet-switching port-mode trunkset interfaces ge-20/0/1 unit 0 family ethernet-switching vlan members internet_edgeset interfaces ge-20/0/1 unit 0 family ethernet-switching vlan members management_1bset interfaces ge-20/0/1 unit 0 family ethernet-switching vlan members guest_wireless

Commit the configuration.

commit

Configure the server port.

server ports are typically configured as access ports that have a single VlaN. In the tested network example, we have a

few VlaNs where servers would typically reside. to configure a server port that is part of a single VlaN, it must first be

configured as an access port.

Set port into access mode:

root@EX8200VC-1b# set interfaces ge-4/0/44 unit 0 family ethernet-switching port-mode access

assign the port to a VlaN. as a general rule, we assign access ports under the VlaN configuration instead of the port

configuration, but either can be used. In this case we need to assign the server port to the VlaN servers.

root@EX8200VC-1b# set vlans server_1b interface ge-4/0/44

In some cases it may make more sense to assign the VlaN directly in the port configuration because servers are

different from a standard network host.

Configure server port in trunk mode.some servers reside on more than one VlaN and require a trunk port. In this case, configure the port for trunking and

assign the VlaNs it should belong to directly in the port configuration as we did for the laG ports. Below is an example

of an interface configured as a trunk that belongs to the VlaNs server_1b and management_1b. You can also review the

earlier trunk configuration sections discussing configuration of ports for WlC and srX devices.

root@ EX8200VC-1b# set interfaces <interface> unit 0 family ethernet-switching port-mode trunkset interfaces <interface> unit 0 family ethernet-switching vlan members [servers_1b management_1b]



Enable BPDU-block for server interfaces.Because we do not expect to connect any bridges to the network, the bpdu-block command protects the network

should anyone connect a bridge to the core switch that may shut down any ports sending BpDus. this command

maintains network stability if someone connects an unauthorized bridge to the network.

root@EX8200VC-1b# set ethernet-switching-options bpdu-block interface <interface name>

If interfaces become blocked, you need to clear them manually. the following commands can be used to clear a

blocked port condition:

root@EX8200VC-1b> clear ethernet-switching bpdu-errorroot@EX8200VC-1b> clear ethernet-switching port-error

to view the current state of interfaces run the following command:

root@ EX8200VC-1b> show ethernet-switching interfaces



Configuring Layer 3 Settings for the EX8200 Virtual Chassis Core Switchto configure layer 3 parameters on the core switch:

Configure DHCPthe tested network example uses DHCp forwarding and a central DHCp server for all Ip address allocation , with the

exception of the guest wireless VlaN. Guest wireless addressing is allocated directly from the srX series Gateways to

maintain isolation from the rest of the network.

DHCp services can be set up directly on eX series switches if desired (see appendix C). DHCp forwarding is essentially

a broadcast forwarding system for DHCp requests that allows users to consolidate their DHCp services in a centralized

location instead of having a DHCp server for every subnet. the following configuration enables DHCp forwarding on the

VlaN interfaces listed, and forwards DHCp requests to the DHCp server 10.10.46.100.

root@EX8200-1b# set forwarding-options helpers bootp description DHCP-SERVER-Aset forwarding-options helpers bootp server 10.10.46.100set forwarding-options helpers bootp interface vlan.8set forwarding-options helpers bootp interface vlan.20set forwarding-options helpers bootp interface vlan.32set forwarding-options helpers bootp interface vlan.40set forwarding-options helpers bootp interface vlan.52

Configure default gateway and static routes.

root@EX8200-1b# set routing-options static route 0.0.0.0/0 next-hop 10.10.44.254

Configure OSPF.We need to configure a single OspF area that will be the backbone area 0.0.0.0 and add the interfaces and subnets we

wish to advertise to the srX series Gateways and eX4500VC-1a core in building a.

NOTE: the subnet is all that is required to add the interface to the area. mask information will be automatically

imported into OspF and redistributed. We have configured several interfaces as passive OspF interfaces. this means

their subnets will be advertised to other OspF routers, but we will not send OspF advertisements on these interfaces.

root@EX8200VC-1b# set protocols ospf area 0.0.0.0 interface vlan.48 passiveset protocols ospf area 0.0.0.0 interface vlan.8 passiveset protocols ospf area 0.0.0.0 interface vlan.20 passiveset protocols ospf area 0.0.0.0 interface vlan.32 passiveset protocols ospf area 0.0.0.0 interface vlan.40 passiveset protocols ospf area 0.0.0.0 interface vlan.50 passiveset protocols ospf area 0.0.0.0 interface vlan.64 passiveset protocols ospf area 0.0.0.0 interface ae1.0set protocols ospf area 0.0.0.0 interface vlan.44set protocols ospf area 0.0.0.0 interface vlan.52 passiveset protocols ospf area 0.0.0.0 interface vlan.46 passive


commit



Configure Class of Servicethe basic Cos configuration is almost identical across core and access platforms in the network example. We will

configure Cos on the core eX8200 Virtual Chassis. the configuration defines the Cos service and then applies it to

specific interfaces.

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

root@EX8200VC-1b# set class-of-service forwarding-classes class control queue-num 7set class-of-service forwarding-classes class voice queue-num 5set class-of-service forwarding-classes class business-app queue-num 3set class-of-service forwarding-classes class server-bulk queue-num 1set class-of-service forwarding-classes class best-effort queue-num 0

Configuring classifiersNext we will create the classifiers. In the tested network example we are only using DsCp marking for our classification

of traffic. the classifiers map the different DsCp marked packets to the correct queue – if the traffic is not marked or

marked with a DsCp value it will be considered best-effort traffic and treated accordingly.

root@EX8200VC-1b# set class-of-service classifiers dscp dscp_trusted forwarding-class control loss-priority low code-points nc1set class-of-service classifiers dscp dscp_trusted forwarding-class control loss-priority low code-points nc2set class-of-service classifiers dscp dscp_trusted forwarding-class voice loss-priority low code-points efset class-of-service classifiers dscp dscp_trusted forwarding-class business-app loss-priority low code-points af21set class-of-service classifiers dscp dscp_trusted forwarding-class server-bulk loss-priority low code-points af11set class-of-service classifiers dscp dscp_trusted forwarding-class best-effort loss-priority low code-points be

Configuring schedulersWe will create schedulers for each type of traffic we want to manage. When we define the schedulers we also configure

characteristics like shaping/limiting/forwarding rate, how much buffer is allocated, and what priority the traffic has.

In the tested network we have configured some similar sounding schedulers, for example: voice-user-sched and

voice-network-sched. the difference between these schedulers is they are intended to be applied to different types of

interfaces when we create our scheduler maps later. While these currently have the same values, you may later need

to change the characteristics of your network or access ports to be different from each other. Configuring schedulers in

this manner for the initial configuration makes for less work if changes are needed later.

root@EX8200VC-1b# set class-of-service schedulers control-network-sched shaping-rate percent 5set class-of-service schedulers control-network-sched buffer-size percent 5set class-of-service schedulers control-network-sched priority strict-highset class-of-service schedulers control-user-sched shaping-rate percent 5 set class-of-service schedulers control-user-sched buffer-size percent 5set class-of-service schedulers control-user-sched priority strict-highset class-of-service schedulers voice-network-sched shaping-rate percent 5 set class-of-service schedulers voice-network-sched buffer-size percent 5 set class-of-service schedulers voice-network-sched priority strict-highset class-of-service schedulers voice-user-sched shaping-rate percent 5 set class-of-service schedulers voice-user-sched buffer-size percent 5 set class-of-service schedulers voice-user-sched priority strict-high set class-of-service schedulers business-sched transmit-rate percent 60 set class-of-service schedulers business-sched buffer-size percent 60set class-of-service schedulers business-sched priority low set class-of-service schedulers server-sched transmit-rate percent 30 set class-of-service schedulers server-sched buffer-size percent 30set class-of-service schedulers server-sched priority lowset class-of-service schedulers be-sched transmit-rate remainder set class-of-service schedulers be-sched buffer-size remainderset class-of-service schedulers be-sched priority low



Configuring scheduler map.scheduler maps tie the individual schedulers to forwarding classes and queues. Here we have created two scheduler

maps one for network (switch to switch) ports and one for access or host ports. the difference between the two is the

different names for the individual control and voice schedulers used in each scheduler-map.

root@EX8200VC-1b# set class-of-service scheduler-maps network-port-sched forwarding-class control scheduler control-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class voice scheduler voice-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps network-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps network-port-sched forwarding-class best-effort scheduler be-schedset class-of-service scheduler-maps access-port-sched forwarding-class control scheduler control-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class voice scheduler voice-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps access-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps access-port-sched forwarding-class best-effort scheduler be-sched

Configuring rewrite rules.rewrite rules are used to mark packets appropriately before packets exit an interface to preserve markings

throughout the network.

set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority low code-point nc1set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority high code-point nc2set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class voice loss-priority low code-point efset class-of-service rewrite-rules dscp rewrite-dscp forwarding-class business-app loss-priority low code-point af21set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class best-effort loss-priority low code-point be

Configuring interfaces.In order for Class of service to actually do anything it must be applied to interfaces. We have two main interface types:

Network ports (that connect switches together), and user ports (that users/hosts connect to.) When applying Class of

service to an interface in the tested network example you will configure a scheduler and classifier on network ports, or

a scheduler, classifier and rewrite policy on access ports. users do not connect directly to core switches, but servers do.

We can use the same access port scheduler for the servers on the core switch. this could be re-named or modified to

make it more appropriate for the individual environment.

Wildcards can be used to apply Class of service to multiple interfaces with a single command. For example: here we

use wildcards to configure all the Gbe ports on slot 4 to use the same Class of service settings. this can be done the

same way with our laG connections, but we have relatively few of these to configure so we will do so individually.

NOTE: the most specific commands win, so if you have a wildcard policy that is applied to all gigabit ethernet ports

and then you configure one of those ports specifically with different class of service settings they should not conflict;

instead the more specific port configuration will take precedence.



root@EX8200VC-1b# set class-of-service interfaces ge-4/0/* scheduler-map access-port-schedset class-of-service interfaces ge-4/0/* unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ge-4/0/* unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae0 scheduler-map network-port-schedset class-of-service interfaces ae0 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae0 unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae1 scheduler-map network-port-schedset class-of-service interfaces ae1 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae1 unit 0 rewrite-rules dscp rewrite-dscp


commit

Verifying Class of Service Settingsthere are various commands that can be used to verify portions of the Class of service configuration.

Show class-of-service <sub-category>

examples:

show class-of-service scheduler-map

show class-of-service interface <interface name>

show class-of-service rewrite-rule

the most useful Class of service command might be looking at the interface statistics using the command.

show interfaces <interface name> detail

this command will provide details on what queues are configured on the port and how many packets were seen and if

any were dropped.

NOTE: When looking for Class of service statistics using the show interface command you can only see the statistics

on physical interfaces so when looking at a laG interface you need to run this command for each of the physical

interfaces that make up the link in order to view the Class of service details.



root@EX8200VC-1b> show interfaces xe-1/0/4Physical interface: xe-1/0/4, Enabled, Physical link is Up Interface index: 162, SNMP ifIndex: 530 Link-level type: Ethernet, MTU: 1514, Speed: 10Gbps, Duplex: Full-Duplex, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x4000 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Current address: 2a:c0:da:ba:90:03, Hardware address: 28:c0:da:ba:90:37 Last flapped : 2012-10-22 10:52:25 PDT (2w3d 22:10 ago) Input rate : 0 bps (0 pps) Output rate : 2880 bps (0 pps) Active alarms : None Active defects : None Interface transmit statistics: Disabled

Logical interface xe-1/0/4.0 (Index 79) (SNMP ifIndex 533) Flags: 0x4000 Encapsulation: ENET2 Protocol aenet, AE bundle: ae0.0

{master:8}root@EX8200VC-1b> show interfaces xe-1/0/4 detailPhysical interface: xe-1/0/4, Enabled, Physical link is Up Interface index: 162, SNMP ifIndex: 530, Generation: 165 Link-level type: Ethernet, MTU: 1514, Speed: 10Gbps, Duplex: Full-Duplex, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x4000 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Hold-times : Up 0 ms, Down 0 ms Current address: 2a:c0:da:ba:90:03, Hardware address: 28:c0:da:ba:90:37 Last flapped : 2012-10-22 10:52:25 PDT (2w3d 22:10 ago) Statistics last cleared: 2012-11-08 08:54:00 PST (23:08:50 ago) Traffic statistics: Input bytes : 1321996 0 bps Output bytes : 3688005 0 bps Input packets: 6065 0 pps Output packets: 29479 0 pps IPv6 transit statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0



Egress queues: 8 supported, 8 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 22862 0 1 server-bulk 0 0 0 2 mcast-be 0 0 0 3 business-app 0 0 0 4 mcast-ef 0 0 0 5 voice 0 0 0 6 mcast-af 0 0 0 7 control 0 5783 0 Queue number: Mapped forwarding classes 0 best-effort 1 server-bulk 2 mcast-be 3 business-app 4 mcast-ef 5 voice 6 mcast-af 7 control Active alarms : None Active defects : None Interface transmit statistics: Disabled

Logical interface xe-1/0/4.0 (Index 79) (SNMP ifIndex 533) (HW Token 2147483649) (Generation 144) Flags: 0x4000 Encapsulation: ENET2 Local statistics: Input bytes : 936000 Output bytes : 1139271 Input packets: 3000 Output packets: 3808 Transit statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps Protocol aenet, AE bundle: ae0.0, Generation: 164, Route table: 0



Building B: Configuring the Access Layer

WLA

WLA

WLA

WLA

WLA

WLA

WLA


EX4200VC-2a

EX3300VC-1a

EX4200VC-3a

LAGLAG

LAGEX8200VC-1b

SRX SeriesCluster

WLCCluster

INTERNET

EX6200-1b

App Servers


EX4500VC-1a LAG

LAG

You are Here

Figure 11: EX6200 Configuration

In Building B the access layer uses eX6210 series modular switches. the eX6210 provides high density ethernet

switching with redundant routing-engines and power supplies for high availability. In the tested network we only show

a single eX6210, but in an actual deployment this will likely be a larger number.

NOTE: this process assumes that the eX6200 has redundant routing-engines and both are running the same version.



Software Version /Upgrading the EX6200NOTE: In the tested network example it is assumed that each eX6200 has dual routing-engines, each of the two

routing engines in each eX6200 need have their software version checked and upgraded to the tested version (Junos

12.1r1.9.) the process outlined here steps through the upgrade process for both routing-engines.

NOTE: if the eX6200 code version is already upgraded to Junos 12.1r1.9 you can skip steps 1-8 and start at the “eX6200

Configuration Overview” section.

Routing-engine 0 Connect to the Console port of the EX6200 routing-engine 0 (Setting: s9600, 8, 1, none).press enter. the following prompt appears.




Note version of code, if the routing-engine 0 is running the correct version then check routing-engine 1






Configure the password.




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.


Verify the correct version boots up.



Routing-engine 1Connect to the Console port of the EX6200 routing-engine 1 (Setting: s9600, 8, 1, none).press enter. the following prompt appears.




Note version of code, if the routing-engine is running the correct version then check the next routing-engine






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.



EX6200 Configuration Overview 1. Configure global configuration items

2. Configure the Chassis

• perform Chassis type-specific configuration

3. Configure layer 2 settings


5. Configure Class of service

Configuring Global Settings for the EX6210 Switchto configure global settings on the switch:

Connect to the Console port of the EX6210 route-engine 0 (Setting: s9600, 8, 1, none).press enter. the following prompt appears.








set date 201210220830.00






YYYYMMDDhhmm.ss






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>


root@EX6200-1b# set system services web-management https system-generated-certificateset system services sshdelete system services web-management httpdelete system services telnet

Configure DNS.

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

Configure NTP.

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

Configuring the EX6200 ChassisConfigure global Virtual Chassis commands.

root@EX6200-1b# set system commit synchronizeset ethernet-switching-options nonstop-bridgingset chassis redundancy graceful-switchover


root@EX6200-1b# commit

Configure resilient dual-boot partitions.NOTE: It is important to run this step as it improves the resiliency of the system in the case of primary boot partition

failure. this step creates a backup copy of the operating system and is highly recommended. this process takes

approximately 5 minutes for each re or member.

request system snapshot slice alternate re0request system snapshot slice alternate re1

Configure default settings.the following commands show items that should be enabled by default in the configuration. You may wish to review

and verify that these setting are desired for your specific network.

xyzcompany.com



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

Configuring Layer 2 Settings for EX6200 Chassisto configure layer 2 parameters and settings on the access switch in dedicated mode:

Table 8: VLANs Configured on EX6200

VLAN-ID VLAN Name Subnet Port Range Name

8 data_wired_1b 10.10.8.0/22 wired_access_ports

20 voip_wired_1b 10.10.20.0/22 wired_voice_ports

32 data_wireless_1b 10.10.32.0/23

40 voip_wireless_1b 10.10.40.0/23

50 management_1b 10.10.50.0/24

52 access_points_1b 10.10.52.0/24 wireless_access_points

Configure VLANs.

root@EX6200-1b#set vlans access_points_1b vlan-id 52set vlans data_wired_1b vlan-id 8set vlans data_wireless_1b vlan-id 32set vlans voip_wired_1b vlan-id 20set vlans voip_wireless_1b vlan-id 40set vlans management_1b vlan-id 50

Configure interfaces.We need to configure one Ip interface on the management VlaN.

root@EX6200-1b# set interfaces vlan unit 50 family inet address 10.10.50.10/24

Configure LAG (aggregated Ethernet) ports.the eX6200-1 chassis has only one laG port configured to connect to the eX8200VC core switch. Junos Os requires

that you configure the number of laG interfaces you want to use before you begin configuring the laG interfaces. We

suggest picking a number slightly larger than what you need in case you add more laG interfaces later. You can change

this value in the future.

Because we need one laG interface for this configuration, we will configure the eX6200-1b chassis with two in case we

add another laG connection later.

root@EX6200-1b# set chassis aggregated-devices ethernet device-count 2

the 10-Gigabit ethernet ports on the eX6200 are only available on the route-engines themselves at this time. each

routing-engine has four 10Gbe ports. the port designations for routing-engine 0 are xe-4/0/0 through 4/0/3 and

for routing-engine 1 xe-5/0/0 through 5/0/3. the routing-engines can only be inserted in slots 4 or 5 so the starting

interface slot numbers will always be 4 or 5.

In the tested network example we will use four ports to create the laG xe-4/0/0, xe-4/0/1, xe-5/0/0 and xe-5/0/1

NOTE: If there are pre-existing configurations on the interfaces required for laG ports they must be removed prior to

laG configuration. a new eX6200 chassis has no port configuration by default, so we can move directly to configuring

the ports.



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

root@EX6200-1b# set interfaces xe-4/0/0 ether-options 802.3ad ae0set interfaces xe-4/0/1 ether-options 802.3ad ae0set interfaces xe-5/0/0 ether-options 802.3ad ae0set interfaces xe-5/0/1 ether-options 802.3ad ae0

Next, we need to add laCp to each laG interface to provide some health checking.

NOTE: laCp must be configured on both sides for the laG port to become active.

root@EX6200-1b# set interfaces ae0 aggregated-ether-options lacp activeset interfaces ae0 aggregated-ether-options lacp periodic slow

Disable RSTP on LAG connections to access switches.Because we do not use rstp as a topology protocol, we can disable it on the laG ports going to our access switches.

Disabling rstp also reduces potential convergence times in case a laG member fails, because fewer protocols need to

converge.

NOTE: Note all access switches have rstp enabled locally for loop protection.

root@EX6200-1b# set protocols rstp interface ae0.0 disable

Configure the trunk port and VLAN.Next, we need to configure the laG port as a trunk and add the VlaNs that will be supported going to the core switch.

to enable the laG port as a trunk port, use the set interfaces command.

root@EX6200-1b# set interfaces ae0 unit 0 family ethernet-switching port-mode trunk

Configure VLANs on trunk ports.

Table 9: EX6200 Trunked VLANs

LAG Ports to device to port Trunk/Access VLANs Native VLAN

ae0.0 xe-4/0/0 EX8200VC-1b xe-1/0/4 Trunk data_wired_1b

default

ae0.0 xe-4/0/1 EX8200VC-1b xe-17/0/4 Trunk voip_wired_1b

ae0.0 xe-5/0/0 EX8200VC-1b xe-1/0/5 Trunk data_wireless_1b

ae0.0 xe-5/0/1 EX8200VC-1b xe-17/0/5 Trunk voip_wireless_1b

management_1b

access_points_1b

root@EX6200-1b#set interfaces ae0 unit 0 family ethernet-switching vlan members access_points_1bset interfaces ae0 unit 0 family ethernet-switching vlan members data_wired_1bset interfaces ae0 unit 0 family ethernet-switching vlan members data_wireless_1bset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wired_1bset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wireless_1bset interfaces ae0 unit 0 family ethernet-switching vlan members management_1b


root@EX6200-1b# 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@EX6200-1> show lldp neighborsLocal Interface Parent Interface Chassis Id Port info System Namexe-5/0/0.0 ae0.0 28:c0:da:ba:90:00 xe-1/0/5.0 EX8200VC-1bxe-5/0/1.0 ae0.0 28:c0:da:ba:90:00 xe-17/0/5.0 EX8200VC-1bxe-4/0/0.0 ae0.0 28:c0:da:ba:90:00 xe-1/0/4.0 EX8200VC-1bxe-4/0/1.0 ae0.0 28:c0:da:ba:90:00 xe-17/0/4.0 EX8200VC-1bge-0/0/0.0 - 10.10.52.10 port 1 WLA532-US

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

root@EX6200-1> show lacp interfacesAggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-4/0/0 Actor No No Yes Yes Yes Yes Slow Active xe-4/0/0 Partner No No Yes Yes Yes Yes Slow Active xe-4/0/1 Actor No No Yes Yes Yes Yes Slow Active xe-4/0/1 Partner No No Yes Yes Yes Yes Slow Active xe-5/0/0 Actor No No Yes Yes Yes Yes Slow Active xe-5/0/0 Partner No No Yes Yes Yes Yes Slow Active xe-5/0/1 Actor No No Yes Yes Yes Yes Slow Active xe-5/0/1 Partner No No Yes Yes Yes Yes Slow Active LACP protocol: Receive State Transmit State Mux State xe-4/0/0 Current Slow periodic Collecting distributing xe-4/0/1 Current Slow periodic Collecting distributing xe-5/0/0 Current Slow periodic Collecting distributing xe-5/0/1 Current Slow periodic Collecting distributing

Configure secure access port features.NOTE: in the version of code tested in the tested network (12.1r1.9), there is an issue where DHCp requests do not

complete when configuring ports for arp-inspection and dhcp-examine. so we are omitting this step for the eX6200

in this guide. the bug id for this problem is pr# 787161 this pr# has been fixed in newer versions of code. If you need

this feature verify the fix is in the version of code you are loading by looking at the release notes in the issues resolved

section.

We recommend configuring basic security features on user facing VlaNs on access switches. enable these features on

the data_wired_1b and voip_wired_1b, VlaNs.

NOTE: Do not enable these features on networks that frequently have static Ip address assignments. each device with

a static Ip address attached to a port on a VlaN – with these features enabled – requires a static port configuration

with an Ip address and a maC address in order to communicate with the rest of the network. If required, this additional

level of security can be configured, but it will add some overhead when network changes are made.

root@EX6200-1b# set ethernet-switching-options secure-access-port vlan data_wired_1b ip-source-guardset ethernet-switching-options secure-access-port vlan voip_wired_1b ip-source-guard

For more information on the secure access port features see Day One book, Configuring EX Series Ethernet Switches.

Junos Os supports a feature called interface-range, which allows you to group several interfaces together so that you

can configure the entire group using one statement. this can be helpful when you have many similar ports that share

much of the same configuration. this statement can be used to simplify configurations.

With access switches in the tested network, each member in the Virtual Chassis is divided up by port type.

• ports 0–4 are reserved for wireless access points

• ports 5–26 are reserved for data.

• ports 27–47 reserved for voice.

Because these ports are typically configured identically, they use the interface-range statement to simplify operations

and create three different port groups wireless_access_points, wired_data_ports and wired_voice_ports as listed in

table 8.

http://www.juniper.net/us/en/community/junos/training-certification/day-one/fabric-switching-tech-series/config-ex-series/



Table 10: VLAN to Port Range


8 data_wired_1b 10.10.8.0/22 wired_access_ports

32 voip_wired_1b 10.10.32.0/22 wired_voice_ports

52 access_points_1b 10.10.52.0/24 wireless_access_points

root@EX6200-1b# set interfaces interface-range wireless_access_points member-range ge-0/0/0 to ge-0/0/4set interfaces interface-range wired_access_ports member-range ge-0/0/5 to ge-0/0/26set interfaces interface-range wired_voice_ports member-range ge-0/0/27 to ge-0/0/47

Set the port mode.For the user facing ports we need to set the port mode to access. Because we have used the interface-ranges

statement, we only need to set the port mode at the interface-range level, instead of editing every port. For the ports

supporting Wlas we will configure these as trunk ports, but they all have the same VlaN configuration.

root@EX6200-1b# set interfaces interface-range wired_access_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wired_voice_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wireless_access_points unit 0 family ethernet-switching port-mode trunk

Configure port to VLAN.

root@EX6200-1b# set vlans voip_wired_1b interface wired_voice_portsset vlans data_wired_1b interface wired_access_ports

the ports for the Wlas require a trunking configuration and require a native VlaN (access_points_1b) be configured in

order for the access point to boot up. When configuring a native VlaN you cannot configure the port VlaN members

with this same VlaN or it will ignore the native VlaN configuration and will not work.

set interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members data_wireless_1bset interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members voip_wireless_1bset interfaces interface-range wireless_access_points unit 0 family ethernet-switching native-vlan-id access_points_1b

Configure Layer 3 settings.layer 3 configuration for the access switch involves setting a default route in the case of the tested network. In this

case, it points to 10.10.50.1 which is the core switch Ip interface on the management_1a VlaN.

set routing-options static route 0.0.0.0/0 next-hop 10.10.50.1


commit



Verify IP reachability.Next, you need to verify Ip reachability by “pinging” the core switch management Ip address from the access switch.

this also indicates that trunking is configured properly on the interface and working properly.

root@EX6200-1b> ping 10.10.50.1PING 10.10.50.1 (10.10.50.1): 56 data bytes64 bytes from 10.10.50.1: icmp_seq=0 ttl=64 time=3.458 ms64 bytes from 10.10.50.1: icmp_seq=1 ttl=64 time=3.070 ms

Verify VLANs and trunking.to verify that the proper VlaNs are configured for trunking on the ae0 interface, you can use the show ethernet-

switching interfaces ae0 command.

root@EX6200-1b> show ethernet-switching interfaces ae0Interface State VLAN members Tag Tagging Blockingae0.0 up access_points_1b 52 tagged unblocked data_wired_1b 8 tagged unblocked data_wireless_1b 32 tagged unblocked management_1b 50 tagged unblocked voip_wired_1b 20 tagged unblocked voip_wireless_1b 40 tagged unblocked

to see what ports are configured for specific VlaNs use the show vlans command.

NOTE: Because of the large number of ports in eX6200-1b, the show command output below show the first VlaN’s output.

root@EX6200-1b> show vlansName Tag Interfacesaccess_points_1b 52 ae0.0*, ge-0/0/0.0*, ge-0/0/1.0, ge-0/0/2.0, ge-0/0/3.0, ge-0/0/4.0, ge-1/0/0.0

Configure Class of Servicethe basic Class of service configuration used is almost identical across core and access platforms in the tested

network example.

We will configure Class of service on the core eX6210. the configuration of Cos is done in five steps the first four define

what the Cos service will look like and the last step applies Cos to specific interfaces.

• Forwarding Classes

• Classifiers

• schedulers

• scheduler-maps

• rewrite rules

• Configuring Interfaces

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

root@EX6200-1b# set class-of-service forwarding-classes class control queue-num 7set class-of-service forwarding-classes class voice queue-num 5set class-of-service forwarding-classes class business-app queue-num 3set class-of-service forwarding-classes class server-bulk queue-num 1set class-of-service forwarding-classes class best-effort queue-num 0



Configuring classifiers.Next we will create the classifiers. In the tested network example we are only using DsCp marking for our classification

of traffic. the classifiers map the different DsCp marked packets to the correct queue, if the traffic is not marked or

marked with a DsCp value not listed it will be considered best-effort traffic and treated accordingly.

root@EX6200-1b# set class-of-service classifiers dscp dscp_trusted forwarding-class control loss-priority low code-points nc1set class-of-service classifiers dscp dscp_trusted forwarding-class control loss-priority low code-points nc2set class-of-service classifiers dscp dscp_trusted forwarding-class voice loss-priority low code-points efset class-of-service classifiers dscp dscp_trusted forwarding-class business-app loss-priority low code-points af21set class-of-service classifiers dscp dscp_trusted forwarding-class server-bulk loss-priority low code-points af11set class-of-service classifiers dscp dscp_trusted forwarding-class best-effort loss-priority low code-points be

Configuring schedulers.We will create schedulers for each type of traffic we want to manage. When we define the schedulers we also configure

characteristics like shaping/limiting/forwarding rate, how much buffer is allocated and what priority the traffic has.

In the tested network we have configured a couple of similar sounding schedulers for example voice-user-sched and

voice-network-sched the difference between these schedulers is they are intended to be applied to different types

of interfaces when we create our scheduler maps later. While these currently have the same values, it may be in the

future you need to change the characteristics of your network ports or access ports to be different from each other. By

configuring schedulers this way from the beginning it makes for less work if changes are needed later.

root@EX6200-1b# set class-of-service schedulers control-network-sched shaping-rate percent 5set class-of-service schedulers control-network-sched buffer-size percent 5set class-of-service schedulers control-network-sched priority strict-highset class-of-service schedulers control-user-sched shaping-rate percent 5 set class-of-service schedulers control-user-sched buffer-size percent 5set class-of-service schedulers control-user-sched priority strict-highset class-of-service schedulers voice-network-sched shaping-rate percent 5 set class-of-service schedulers voice-network-sched buffer-size percent 5 set class-of-service schedulers voice-network-sched priority strict-highset class-of-service schedulers voice-user-sched shaping-rate percent 5 set class-of-service schedulers voice-user-sched buffer-size percent 5 set class-of-service schedulers voice-user-sched priority strict-high set class-of-service schedulers business-sched transmit-rate percent 60 set class-of-service schedulers business-sched buffer-size percent 60set class-of-service schedulers business-sched priority low set class-of-service schedulers server-sched transmit-rate percent 30 set class-of-service schedulers server-sched buffer-size percent 30set class-of-service schedulers server-sched priority lowset class-of-service schedulers be-sched transmit-rate remainder set class-of-service schedulers be-sched buffer-size remainderset class-of-service schedulers be-sched priority low

Configuring scheduler maps.scheduler maps tie the individual schedulers to forwarding classes and queues. Here we have created two scheduler





root@EX6200-1b# set class-of-service scheduler-maps network-port-sched forwarding-class control scheduler control-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class voice scheduler voice-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps network-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps network-port-sched forwarding-class best-effort scheduler be-schedset class-of-service scheduler-maps access-port-sched forwarding-class control scheduler control-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class voice scheduler voice-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps access-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps access-port-sched forwarding-class best-effort scheduler be-sched

Configuring rewrite rules.rewrite rules are used to mark packets appropriately before packets exit an interface so that markings are preserved


root@EX6200-1b#set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority low code-point nc1set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority high code-point nc2set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class voice loss-priority low code-point efset class-of-service rewrite-rules dscp rewrite-dscp forwarding-class business-app loss-priority low code-point af21set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class best-effort loss-priority low code-point be


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.


and then you configure one of those ports specifically with different class of service settings they will not conflict;


root@EX6200-1b#set class-of-service interfaces ge-0/0/* scheduler-map access-port-schedset class-of-service interfaces ge-0/0/* unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ge-0/0/* unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae0 scheduler-map network-port-schedset class-of-service interfaces ae0 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae0 unit 0 rewrite-rules dscp rewrite-dscp


commit





examples:




the most useful Class of service command might be looking at the interface statistics using the command,



any were dropped.




root@EX6200-1b# run show interfaces ge-0/0/0 detailPhysical interface: ge-0/0/0, Enabled, Physical link is Up Interface index: 137, SNMP ifIndex: 560, Generation: 140 Link-level type: Ethernet, MTU: 1514, Speed: Auto, Duplex: Auto, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x0 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Hold-times : Up 0 ms, Down 0 ms Current address: 88:e0:f3:c 8:42:03, Hardware address: 88:e0:f3:c8:42:03 Last flapped : 2012-11-05 02:52:26 PST (4d 05:35 ago) Statistics last cleared: 2012-11-08 08:45:06 PST (23:42:31 ago) Traffic statistics: Input bytes : 20807332 5504 bps Output bytes : 10707158 2776 bps Input packets: 83597 2 pps Output packets: 117169 3 pps IPv6 transit statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0



Egress queues: 8 supported, 5 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 69222 0 1 server-bulk 0 0 0 3 business-app 0 0 0 5 voice 0 0 0 7 control 0 47947 0 Queue number: Mapped forwarding classes 0 best-effort 1 server-bulk 3 business-app 5 voice 7 control Active alarms : None Active defects : None Interface transmit statistics: Disabled Logical interface ge-0/0/0.0 (Index 74) (SNMP ifIndex 896) (Generation 139) Flags: SNMP-Traps 0x0 Encapsulation: ENET2 Traffic statistics: Input bytes : 382375 Output bytes : 6507401 Input packets: 2875 Output packets: 47947 Local statistics: Input bytes : 382375 Output bytes : 6507401 Input packets: 2875 Output packets: 47947 Transit statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps Protocol eth-switch, Generation: 159, Route table: 0 Flags: Trunk-Mode



WLA

WLA

WLA

WLA

WLA

WLA

WLA


EX4200VC-2a

EX3300VC-1a

EX4200VC-3a

LAGLAG

LAGEX8200VC-1b

SRX SeriesCluster

WLCCluster

INTERNET

EX6200-1b

App Servers


EX4500VC-1a LAG

LAG

You are Here

Figure 12: EX4500VC Configuration



Building A: Configuring the coreFor reference throughout this portion of the document we have provided the Building a connection level details in

Figure 13.

WLA

WLA

WLA

WLA

WLA

WLA

BUILDING A

EX4200VC-2a

EX3300VC-1a

EX4200VC-3a

LAGLAG

LAG

EX4500VC-1a

LAG

xe-0/0/6

xe-1/0/39xe-1/0/38xe-0/0/39xe-0/0/38

xe-0/0/6xe-1/0/8

xe-7/1/0 xe-0/1/0

xe-0/0/8

xe-3/1/1 xe-1/1/1

xe-0/1/0xe-5/1/0

xe-1/0/6

xe-0/0/6To Building B

Figure 13: Building A Connection Details



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




Configuring Global Settings for the Core Switchto configure global settings on the core switch:

Connect to the Console port of the EX4500 switch (Setting: s9600, 8, 1, none).press enter. the following prompt appears.


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.






set date 201201220830.00




YYYYMMDDhhmm.ss








root# set system host-name EX4500VC-1a


set interfaces vme unit 0 family inet address 10.94.188.101/24


root@EX4500VC-1a# set system services web-management https system-generated-certificateset system services sshdelete system services web-management httpdelete system services telnet

Configure DNS.

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

Configuring a Virtual Chassis for the Mixed Mode Core Chassisto configure a Virtual Chassis for the core switch:

Identify the Virtual Chassis type.In the case of the tested network, the core switch is a mixed mode Virtual Chassis (both eX4500 and eX4200 switches

in the same Virtual Chassis). For more information about Virtual Chassis, see “Virtual Chassis” on page 93, or the Day

One book, Configuring EX Series Ethernet Switches.

Configure a pre-provisioned Virtual Chassis.the recommended setup process for a Virtual Chassis is called pre-provisioned, which is the process we will use here.

to pre-provision a Virtual Chassis, you need to identify the serial numbers of each device that will be part of the Virtual

Chassis, the device function, and the order in which you want each switch to be placed. Here we have configured the

eX4500 switches to be in slot 0 and slot 1, and act as routing engines. the eX4200 switches are in slot 2 and slot 3,

and configured as line cards. later, when all the switches are connected and powered up, they will automatically be

assigned the proper function and slot. make sure you pay attention to the serial numbers and ordering of each switch

when you connect them together.

the eX series switches by default automatically form a Virtual Chassis, but because the ordering is nondeterministic,

and so the switches may not be numbered sequentially, making things confusing. For more information about Virtual

Chassis, see appendix a and B, or the Day One book, Configuring EX Series Ethernet Switches.

xyzcompany.com




root@EX4500VC-1a# set virtual-chassis preprovisionedset virtual-chassis member 0 role routing-engineset virtual-chassis member 0 serial-number GX0212140825set virtual-chassis member 1 role routing-engineset virtual-chassis member 1 serial-number GX0212140845set virtual-chassis member 2 role line-cardset virtual-chassis member 2 serial-number FP0211490796set virtual-chassis member 3 role line-cardset virtual-chassis member 3 serial-number FP0211490618


root@EX4500VC-1a# commitconfiguration check succeedscommit complete

Configure specific Virtual Chassis commands.

NOTE: Because this is a mixed mode chassis, we need to configure it to accept a mix of eX4500 and eX4200

devices in the same Virtual Chassis. exit configuration mode by typing exit at the # prompt. the next command is an

operational command.

root@EX4500VC-1a> request virtual-chassis mode mixed

Verify that the mode is correct, by typing show virtual-chassis.

root@EX4500VC-1a> show virtual-chassisPreprovisioned Virtual ChassisVirtual Chassis ID: 8c7a.9353.df56Virtual Chassis Mode: MixedMstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt GX0212140825 ex4500-40f 129 Master* Y

using the VCp ports at the back of the units, cable the remaining members together in a daisy-chained configuration.

When all of the units are cabled properly, power them up. remember to pay attention to the serial number of each

switch when connecting them together to ensure they are in the right position.

after the switches finish booting up, verify that all of the members of the Virtual Chassis are active by running the show

virtual-chassis command.

Preprovisioned Virtual ChassisVirtual Chassis ID: 804d.1d7f.fd6aVirtual Chassis Mode: Mixed Mstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt GX0212140825 ex4500-40f 129 Backup Y 1 vcp-1 2 vcp-01 (FPC 1) Prsnt GX0212140845 ex4500-40f 129 Master* Y 3 vcp-1 0 vcp-02 (FPC 2) Prsnt FP0211490796 ex4200-48px 0 Linecard Y 3 vcp-0 0 vcp-13 (FPC 3) Prsnt FP0211490618 ex4200-48px 0 Linecard Y 1 vcp-0 2 vcp-1

Enter configuration mode again.

8c7a.9353.df

804d.1d7f.fd



Configure global Virtual Chassis commands.

root@EX4500VC-1a# set system commit synchronizeset routing-options nonstop-routingset ethernet-switching-options nonstop-bridgingset chassis redundancy graceful-switchovercommit and-quit

Configure resilient dual-boot partitions.NOTE: It is important to run this step as it improves the resiliency of the system in case of primary boot partition failure.

this step creates a backup copy of the operating system and is highly recommended. the process takes approximately

5 minutes for each re or member.


Configure default settings.the following items should be enabled by default in the configuration. You may wish to review and verify that these

setting are desired for your specific network.

root@EX4500VC-1a# set protocols igmp-snooping vlan allset protocols rstpset protocols lldp interface allset protocols lldp-med interface allset poe interface allset ethernet-switching-options storm-control interface all

Configuring Layer 2 Settings For Mixed Mode Core Switchto configure layer 2 parameters and settings on the core switch:

Set the bridge priority on the core switch.

NOTE: We enable spanning tree protocol to prevent loops from forming in the network, even though we do not use it

as a topology protocol. as an extra precaution, we set the bridge priority on the core switch to 8192, which will ensure

that it will be the default root bridge in the event another bridging device is connected to the network.

Juniper Networks eX series switches run rstp by default.

root@EX4500VC-1a# set protocols rstp bridge-priority 8k

Configure VLANs and IP interfaces.NOTE: We configure all of the inter-VlaN routing on the core switch. this makes it easier to simultaneously configure

the VlaNs and Ip interfaces for those VlaNs. When creating VlaN names, it is important to note that these names

are case sensitive. the first command creates the VlaN data_wired_1a with a VlaN ID of 12 and then assigns a layer 3

interface called vlan.10 to that VlaN. the second line creates the vlan.12 interface and assigns an Ip address.

root@EX4500VC-1a# set vlans data_wired_1a vlan-id 12set vlans data_wired_1a l3-interface vlan.12

You may notice that the VlaN ID is the same as the interface VlaN unit number (both are number 12). this is not

mandatory, but we recommend that you match the VlaN ID and interface VlaN unit number. It helps to make things

easier to understand later when you have many VlaNs and interfaces to track. We also used a compound command for

the first line. We created the VlaN, assigned the VlaN ID, and assigned a layer 3 interface all at the same time. this

can save you some time but does not have to be done in a single statement. When you look at the configuration, you

will notice that this is separated into two disparate statements.



NOTE: When you issue a large number of commands at once, we recommend that you issue a commit command to

verify that the commands take effect with no configuration errors. alternatively, you can do a commit check instead,

which verifies the configuration without making it active.

the complete set of VlaN and layer 3 interface statements for the core switch in the tested network example follows.

VLAN configurations

root@EX4500VC-1a# set vlans access_points_1a vlan-id 54set vlans access_points_1a l3-interface vlan.54set vlans data_wired_1a vlan-id 12set vlans data_wired_1a l3-interface vlan.12set vlans data_wireless_1a vlan-id 36set vlans data_wireless_1a l3-interface vlan.36set vlans voip_wired_1a vlan-id 24set vlans voip_wired_1a l3-interface vlan.24set vlans voip_wireless_1a vlan-id 42set vlans voip_wireless_1a l3-interface vlan.42set vlans management_1a vlan-id 51set vlans management_1a l3-interface vlan.51

Interface configurations

root@EX4500VC-1a# set interfaces vlan unit 12 family inet address 10.10.12.1/22set interfaces vlan unit 24 family inet address 10.10.24.1/22set interfaces vlan unit 36 family inet address 10.10.36.1/22set interfaces vlan unit 42 family inet address 10.10.42.1/23set interfaces vlan unit 51 family inet address 10.10.51.1/24set interfaces vlan unit 54 family inet address 10.10.54.1/24


commit

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:



root@EX4500VC-1a# delete interfaces xe-1/0/38 unit 0delete interfaces xe-1/0/39 unit 0delete interfaces xe-0/0/38 unit 0delete interfaces xe-0/0/39 unit 0delete interfaces xe-0/0/8 unit 0delete interfaces xe-1/0/8 unit 0delete interfaces xe-0/0/4 unit 0delete interfaces xe-1/0/4 unit 0delete interfaces xe-0/0/6 unit 0 delete interfaces xe-1/0/6 unit 0

then we configure the interfaces to be part of the respective aggregated interfaces:

root@EX4500VC-1a# set interfaces xe-1/0/38 ether-options 802.3ad ae0set interfaces xe-1/0/39 ether-options 802.3ad ae0set interfaces xe-0/0/38 ether-options 802.3ad ae0set interfaces xe-0/0/39 ether-options 802.3ad ae0set interfaces xe-0/0/8 ether-options 802.3ad ae1set interfaces xe-1/0/8 ether-options 802.3ad ae1set interfaces xe-0/0/4 ether-options 802.3ad ae2set interfaces xe-1/0/4 ether-options 802.3ad ae2set interfaces xe-0/0/6 ether-options 802.3ad ae3set interfaces xe-1/0/6 ether-options 802.3ad ae3

Next we want to add laCp to each laG interface to provide some health checking.

NOTE: You need to configure laCp on the interfaces at both ends for the laG port to become active.

root@EX4500VC-1a# set interfaces ae0 aggregated-ether-options lacp activeset interfaces ae0 aggregated-ether-options lacp periodic slowset interfaces ae1 aggregated-ether-options lacp activeset interfaces ae1 aggregated-ether-options lacp periodic slowset interfaces ae2 aggregated-ether-options lacp activeset interfaces ae2 aggregated-ether-options lacp periodic slowset interfaces ae3 aggregated-ether-options lacp activeset interfaces ae3 aggregated-ether-options lacp periodic slow

Disable RSTP on LAG connections to access switches.Because we are not using stp, we will disable it on the laG ports going to our access switches. this reduces potential

convergence times in case a laG member fails because fewer protocols need to converge.

NOTE: all access switches have rstp enabled locally to prevent looping. Interface ae0.0 is not enabled for switching

so we do not need to disable rstp for that interface.

root@EX4500VC-1a# set protocols rstp interface ae1.0 disableset protocols rstp interface ae2.0 disableset protocols rstp interface ae3.0 disable

Configure trunk and VLAN settings.

We need to configure the laG ports as trunks and add the VlaNs that will be supported on the individual access

switches.

root@EX4500VC-1a# set interfaces ae0 unit 0 family ethernet-switching port-mode trunkset interfaces ae1 unit 0 family ethernet-switching port-mode trunkset interfaces ae2 unit 0 family ethernet-switching port-mode trunk

Now commit the configuration.



Configure VLANs on the trunk ports.You can configure port-to-VlaN mapping in two different ways:

• You can configure the VlaNs directly as part of the port configuration.

• You can configure the ports included in the VlaN under the VlaN configuration.

each of these has different advantages and disadvantages. Generally, it makes sense to configure access ports (client-

facing) under the VlaN configuration and configure VlaNs directly on the port for trunk port configuration. You cannot

configure the VlaN mapping in both places— that might produce errors when doing a configuration commit operation.

as discussed previously, we need to configure the VlaNs that the trunk port will carry directly on the interface

configuration section. this makes it easier to tell what VlaNs a specific trunk is part of when viewing the configuration.

When you add VlaNs directly to a trunk port you have the option of adding them by their VlaN ID or by the VlaN

name. In this example, we will add them by VlaN name, because this makes the overall configuration more readable.

the addition of several VlaNs to a trunk can be achieved in two ways: specified one at a time, or several VlaNs can

be configured simultaneously by enclosing them in [] brackets and separating them with spaces. this example shows

each set command. the interfaces are being configured as a trunk and then vlans being added for each of the laG

interfaces we have configured as trunk ports ae1, ae2, and ae3.

root@EX4500VC-1a#set interfaces ae1 unit 0 family ethernet-switching port-mode trunkset interfaces ae1 unit 0 family ethernet-switching vlan members data_wired_1aset interfaces ae1 unit 0 family ethernet-switching vlan members voip_wired_1aset interfaces ae1 unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces ae1 unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces ae1 unit 0 family ethernet-switching vlan members access_points_1aset interfaces ae1 unit 0 family ethernet-switching vlan members management_1aset interfaces ae2 unit 0 family ethernet-switching port-mode trunkset interfaces ae2 unit 0 family ethernet-switching vlan members data_wired_1aset interfaces ae2 unit 0 family ethernet-switching vlan members voip_wired_1aset interfaces ae2 unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces ae2 unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces ae2 unit 0 family ethernet-switching vlan members access_points_1aset interfaces ae2 unit 0 family ethernet-switching vlan members management_1aset interfaces ae3 unit 0 family ethernet-switching port-mode trunkset interfaces ae3 unit 0 family ethernet-switching vlan members data_wired_1aset interfaces ae3 unit 0 family ethernet-switching vlan members voip_wired_1aset interfaces ae3 unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces ae3 unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces ae3 unit 0 family ethernet-switching vlan members access_points_1aset interfaces ae3 unit 0 family ethernet-switching vlan members management_1a

Configure Secure Access Port Features.

most ports on core switches do not need any secure access port features enabled it unnecessarily complicates the

configuration. the reason is that statically assigned Ip addresses are typically used for servers and other networking

devices, and each of these would require exceptions to be manually entered in order to work if these features are

enabled. there are some VlaNs on the core switch, however, on which we recommend enabling these features: the

data_wired_1a, voip_wired_1a ; client-facing VlaNs that are configured on this switch.

root@EX4500VC-1a# set ethernet-switching-options secure-access-port vlan data_wired_1a arp-inspectionset ethernet-switching-options secure-access-port vlan data_wired_1a examine-dhcpset ethernet-switching-options secure-access-port vlan data_wired_1a ip-source-guardset ethernet-switching-options secure-access-port vlan voip_wired_1a arp-inspectionset ethernet-switching-options secure-access-port vlan voip_wired_1a examine-dhcpset ethernet-switching-options secure-access-port vlan voip_wired_1a ip-source-guard

Configuring Power Over Ethernet (Optional).

If you have poe-capable eX4200 switches, you can enable poe on the system. By default this is disabled, because the

default configuration is derived from the eX4500 switch, which does not have poe support. to enable poe on the core

switch run the command:

set poe interface all

root@EX4500VC-1a# set poe interface all



Configuring Layer 3 Settings For Mixed Mode Core Switchto configure layer 3 parameters on the core switch:

Configure DHCP.the tested network example uses DHCp forwarding and a central DHCp server for all Ip address allocation except for

the guest_wireless VlaN. addresses for guest users are allocated directly from the srX series Gateways to keep these

clients isolated from the rest of the network. DHCp services can be set up directly on eX series switches if desired

(see appendix C). DHCp forwarding is essentially a broadcast forwarding system for DHCp requests that allows users

to consolidate their DHCp services in a centralized location instead of having a DHCp server for every subnet. the

following configuration enables DHCp forwarding on the VlaN interfaces listed, and forwards DHCp requests to the

DHCp server 10.10.46.100.

root@EX4500VC-1a# set forwarding-options helpers bootp description DHCP-SERVER-Aset forwarding-options helpers bootp server 10.10.46.100set forwarding-options helpers bootp interface vlan.12set forwarding-options helpers bootp interface vlan.24set forwarding-options helpers bootp interface vlan.36set forwarding-options helpers bootp interface vlan.42set forwarding-options helpers bootp interface vlan.54

Configure default gateway and static routes.

root@EX4500VC-1a# set routing-options static route 0.0.0.0/0 next-hop 10.10.200.1

Configure OSPF.We need to configure a single OspF area that will be the backbone area 0.0.0.0 and add the interfaces and subnets we

wish to advertise to the building B core.

NOTE: the subnet is all that is required to add the interface to the area. mask information will be automatically

imported into OspF and redistributed. We have configured several interfaces as passive OspF interfaces. this means

their subnets will be advertised to other OspF routers, but we will not send OspF advertisements on these interfaces;

just ae0 connecting to the eX8200 Virtual Chassis in building B.

root@EX4500VC-1a# set protocols ospf area 0.0.0.0 interface vlan.46 passiveset protocols ospf area 0.0.0.0 interface vlan.12 passiveset protocols ospf area 0.0.0.0 interface vlan.24 passiveset protocols ospf area 0.0.0.0 interface vlan.36 passiveset protocols ospf area 0.0.0.0 interface vlan.42 passiveset protocols ospf area 0.0.0.0 interface vlan.54 passiveset protocols ospf area 0.0.0.0 interface vlan.58 passiveset protocols ospf area 0.0.0.0 interface ae0.0

Configure non-stop routingConfigure non-stop routing to keep the routing engines in sync with routing protocol state.

root@EX4500VC-1a# set routing-options nonstop-routing


commit



Configure Class of Servicethe basic Cos configuration used is almost identical across core and access platforms in the network example. We

will configure Cos on the core eX4500VC-1a. the configuration first defines the Cos and then applies it to specific

interfaces.

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

root@EX4500VC-1a# set class-of-service forwarding-classes class control queue-num 7set class-of-service forwarding-classes class voice queue-num 5set class-of-service forwarding-classes class business-app queue-num 3set class-of-service forwarding-classes class server-bulk queue-num 1set class-of-service forwarding-classes class best-effort queue-num 0

Configuring classifiersNext we will create the classifiers. In the tested network example we are only using DsCp marking for our classification



root@EX4500VC-1a# set class-of-service classifiers dscp dscp_trusted forwarding-class control loss-priority low code-points nc1set class-of-service classifiers dscp dscp_trusted forwarding-class control loss-priority low code-points nc2set class-of-service classifiers dscp dscp_trusted forwarding-class voice loss-priority low code-points efset class-of-service classifiers dscp dscp_trusted forwarding-class business-app loss-priority low code-points af21set class-of-service classifiers dscp dscp_trusted forwarding-class server-bulk loss-priority low code-points af11set class-of-service classifiers dscp dscp_trusted forwarding-class best-effort loss-priority low code-points be



Configuring schedulersWe will create schedulers for each type of traffic we want to manage. When the schedulers are defined we also

configure characteristics like shaping/limiting/forwarding rate, how much buffer is allocated, and what priority the

traffic has. In the tested network there are similar sounding schedulers, for example: voice-user-sched and voice-

network-sched. the difference between these schedulers is they are intended to be applied to different types of

interfaces when we create our scheduler maps later. While these currently have the same values, they may be changed

if you need to change the characteristics of your network ports or access ports. By configuring schedulers this way from

the beginning it is less work to implement changes later.

root@EX4500VC-1a#set class-of-service schedulers control-network-sched shaping-rate percent 5set class-of-service schedulers control-network-sched buffer-size percent 5set class-of-service schedulers control-network-sched priority strict-highset class-of-service schedulers control-user-sched shaping-rate percent 5 set class-of-service schedulers control-user-sched buffer-size percent 5set class-of-service schedulers control-user-sched priority strict-highset class-of-service schedulers voice-network-sched shaping-rate percent 5 set class-of-service schedulers voice-network-sched buffer-size percent 5 set class-of-service schedulers voice-network-sched priority strict-highset class-of-service schedulers voice-user-sched shaping-rate percent 5 set class-of-service schedulers voice-user-sched buffer-size percent 5 set class-of-service schedulers voice-user-sched priority strict-high set class-of-service schedulers business-sched transmit-rate percent 60 set class-of-service schedulers business-sched buffer-size percent 60set class-of-service schedulers business-sched priority low set class-of-service schedulers server-sched transmit-rate percent 30 set class-of-service schedulers server-sched buffer-size percent 30set class-of-service schedulers server-sched priority lowset class-of-service schedulers be-sched transmit-rate remainder set class-of-service schedulers be-sched buffer-size remainderset class-of-service schedulers be-sched priority low

Configuring scheduler mapsscheduler maps tie the individual schedulers to forwarding classes and queues. Here we have created two scheduler

maps: one for network (switch to switch) ports and one for access or host ports. the difference between the two is the


root@EX4500VC-1a#set class-of-service scheduler-maps network-port-sched forwarding-class control scheduler control-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class voice scheduler voice-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps network-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps network-port-sched forwarding-class best-effort scheduler be-schedset class-of-service scheduler-maps access-port-sched forwarding-class control scheduler control-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class voice scheduler voice-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps access-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps access-port-sched forwarding-class best-effort scheduler be-sched



Configuring rewrite rulesrewrite rules are used to mark packets appropriately before packets exit an interface, so that markings are preserved


root@EX4500VC-1a#set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority low code-point nc1set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority high code-point nc2set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class voice loss-priority low code-point efset class-of-service rewrite-rules dscp rewrite-dscp forwarding-class business-app loss-priority low code-point af21set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class best-effort loss-priority low code-point be


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


You can also use wildcards to apply Class of service to multiple interfaces with a single command. For example, here






root@EX4500VC-1a#set class-of-service interfaces ge-* scheduler-map access-port-schedset class-of-service interfaces ge-* unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ge-* unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae0 scheduler-map network-port-schedset class-of-service interfaces ae0 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae0 unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae1 scheduler-map network-port-schedset class-of-service interfaces ae1 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae1 unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae2 scheduler-map network-port-schedset class-of-service interfaces ae2 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae2 unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae3 scheduler-map network-port-schedset class-of-service interfaces ae3 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae3 unit 0 rewrite-rules dscp rewrite-dscp


commit





examples:




the most useful Class of service command might be looking at the interface statistics using the command.



any were dropped.




root@EX4500VC-1a> show interfaces ge-3/0/47 detailPhysical interface: ge-3/0/47, Enabled, Physical link is Up Interface index: 232, SNMP ifIndex: 727, Generation: 235 Link-level type: Ethernet, MTU: 1514, Speed: Auto, Duplex: Auto, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x0 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Hold-times : Up 0 ms, Down 0 ms Current address: 78:fe:3d:4e:b2:32, Hardware address: 78:fe:3d:4e:b2:32 Last flapped : 2012-05-10 02:16:17 GMT-8 (26w1d 22:23 ago) Statistics last cleared: 2012-11-07 19:03:38 GMT-8 (2d 05:36 ago) Traffic statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps IPv6 transit statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0Egress queues: 8 supported, 5 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 0 0 1 server-bulk 0 0 0 3 business-app 0 0 0 5 voice 0 0 0 7 control 0 0 0 Queue number: Mapped forwarding classes 0 best-effort 1 server-bulk 3 business-app 5 voice 7 control Active alarms : None Active defects : None Interface transmit statistics: Disabled



Building A: Configuring the Access Layer

WLA

WLA

WLA

WLA

WLA

WLA

WLA


EX4200VC-2a

EX3300VC-1a

EX4200VC-3a

LAGLAG

LAGEX8200VC-1b

SRX SeriesCluster

WLCCluster

INTERNET

EX6200-1b

App Servers


EX4500VC-1a LAG

LAG

You are Here

Figure 14: EX4200VC-3a Configuration

Configuring EX4200 as Extended Mode Virtual ChassisConfiguring access switches is simpler than configuring the core switch. We only configure layer 2 services on the

access switches and an Ip address on the management VlaN to provide remote management. this section covers the

configuration for eX4200VC-3b, which is an extended mode Virtual Chassis in the tested network (see Figure 14). this

section includes the following topics:

Procedure overview 1. Configure global configuration items









Configuring Global Settings for the Core Switchto configure global settings on the core switch:

Connect to the Console port of the EX4200 switch (Setting: s9600, 8, 1, none).press enter. the following prompt appears.




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.






set date 201201220830.00









root# set system host-name EX4200VC-3b

Configure the management and VME interface.



root@ EX4200VC-3b# set system services web-management https system-generated-certificateset system services sshdelete system services web-management httpdelete system services telnet

YYYYMMDDhhmm.ss



Configure DNS

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

Configuring an Extended Mode Virtual Chassis for the EX4200to configure a Virtual Chassis for the core switch:

Identify the Virtual Chassis Type.In the case of the tested network, this access switch is an extended mode Virtual Chassis (it uses 10-Gigabit ethernet

links to extend the Virtual Chassis between wiring closets and is managed as a single logical switch). For more

information about Virtual Chassis, see appendix a and B, or the Day One book, Configuring EX Series Ethernet Switches.

Configure a Pre-provisioned Virtual Chassis.the recommended setup process for a Virtual Chassis is called pre-provisioned, which is the process we will use here.

to pre-provision a Virtual Chassis, you need to identify the serial numbers of each device that will be part of the Virtual

Chassis, the device function, and the order in which you want each switch to be placed.

the eX series switches will by default form a Virtual Chassis group automatically when connected together be Virtual

Chassis ports. However, the ordering is nondeterministic, so the switches may not be numbered sequentially, making

things confusing. For more information about Virtual Chassis, see appendix a and B, or the Day One book, Configuring EX Series Ethernet Switches.

root@EX4200VC-3a# set virtual-chassis preprovisionedset virtual-chassis member 0 role routing-engineset virtual-chassis member 0 serial-number FP0211490670set virtual-chassis member 1 role line-cardset virtual-chassis member 1 serial-number FP0211490804set virtual-chassis member 2 role routing-engineset virtual-chassis member 2 serial-number FP0211490739set virtual-chassis member 3 role line-cardset virtual-chassis member 3 serial-number FP0211490735

Set the Virtual Chassis to support fast failover on 10-Gigabit Ethernet Virtual Chassis interfaces.

root@EX4200VC-3a# set virtual-chassis fast-failover xe

NOTE: by default split-detection is enabled, and because all devices are not located in the same location we

recommend leaving split-detection enabled. If you want to disable split detection it can be done by issuing the

command “set virtual-chassis no-split-detection”. It is recommended that split-detection be disabled for Virtual

Chassis with only two devices. If you are not familiar with how split-detection works please review the section on

Virtual Chassis split-detection located appendix a for more details.

Configure global virtual chassis commands.

root@EX4200VC-3a# set system commit synchronizeset ethernet-switching-options nonstop-bridgingset chassis redundancy graceful-switchover


root@EX4200VC-3a# commit

If you see an error message like the following, you can ignore it. the configuration commit operation has been

completed.

xyzcompany.com







root@EX4200VC-3a# commiterror: Could not connect to fpc-1 : Can’t assign requested addresswarning: Cannot connect to other RE, ignoring itconfiguration check succeedscommit complete

using the VCp ports at the back of the units, cable each pair of eX series switches together. remember to pay careful

attention to the serial numbers of each switch before cabling them together.

WARNING: Do not connect the 10-Gigabit Ethernet ports at this time.

When all of the switches are cabled properly, power them up. You should now have two Virtual Chassis each, with two

members. One of the two-member chassis will be pre-provisioned. Verify that this is working properly by running the

show virtual-chassis command. Output similar to the example below indicates that the chassis members are present,

the Virtual Chassis is pre-provisioned, and that the members are correctly identified. Here, member 0 supposed to be a

routing engine and member 1 is supposed to be in line card mode. this is verified by the output.

root@EX4200VC-3a> show virtual-chassisPreprovisioned Virtual ChassisVirtual Chassis ID: 3f68.0cec.a7e1Virtual Chassis Mode: EnabledMstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt FP0211490670 ex4200-48px 129 Master* N 1 vcp-0 1 vcp-11 (FPC 1) Prsnt FP0211490804 ex4200-48px 0 Linecard N 0 vcp-0 0 vcp-1

Configure Virtual Chassis extended ports.since this is an extended mode chassis, we need to configure it to use some of the 10-Gigabit ethernet ports as Virtual

Chassis extended ports so the switches can form a single Virtual Chassis. In our example, we use the eX-um-2x4sFp

uplink module on our chassis that supports either two 10-Gbps or four 1-Gbps ports. the first and third positions

coincide with the 10-Gigabit ethernet ports and are filled on the uplink module, so we will configure ports xe-x/1/0 and

xe-x/1/2. We will use port 0 in our case for each switch.

NOTE: the port definition in your example could be different if you use a different model of eX series device as your

uplink module, but as it should still have port 0, this part of the configuration does not change.

root@EX4200VC-3a> request virtual-chassis vc-port set pic-slot 1 port 0 member 0request virtual-chassis vc-port set pic-slot 1 port 0 member 1

use the show virtual-chassis vc-port command to verify that the ports are configured correctly. Here we can see that

interface 1/0 on each switch is configured and up but has no neighbors.

root@EX4200VC-3a> show virtual-chassis vc-portfpc0:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 1 vcp-1vcp-1 Dedicated 2 Up 32000 1 vcp-01/0 Configured -1 Up 10000fpc1:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 0 vcp-1vcp-1 Dedicated 2 Up 32000 0 vcp-01/0 Configured -1 Up 10000



Connect your console to the second pair of switches. Press Enter and you should see the following prompt:

Amnesiac (ttyu0)login:

Log in as root and press Enter. there should be no password configured, so you should not be prompted for one. Note the version of Junos and

upgrade the unit if necessary.

login: rootLogging to master.- - - JUNOS 12.1r1.9 built 2011-11-15 11:14:01 UTCroot@:RE:0%

You should now be at the % prompt of the switch.

Type cli at the % Prompt.


You should now be at the > prompt.

use the show virtual-chassis command to verify that the switches are up and running. When both of the switches show

up, we can configure the Virtual Chassis ports on these switches.

root> show virtual-chassisVirtual Chassis ID: b155.0784.e162Virtual Chassis Mode: EnabledMstr Mixed NeighborListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt FP0211490739 ex4200-48px 128 Master* N 1 vcp-0 1 vcp-11 (FPC 1) Prsnt FP0211490735 ex4200-48px 128 Backup N 0 vcp-0 0 vcp-1

Configure the Second Set of Virtual Chassis Extended Ports

root>request virtual-chassis vc-port set pic-slot 1 port 0 member 0request virtual-chassis vc-port set pic-slot 1 port 0 member 1



use the show virtual-chassis vc-port command to verify the ports are configured correctly. Here we can see that

interface 1/0 on each switch is configured and up but has no neighbors.

root> show virtual-chassis vc-portfpc0:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 1 vcp-1vcp-1 Dedicated 2 Up 32000 1 vcp-01/0 Configured -1 Down 10000fpc1:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 0 vcp-1vcp-1 Dedicated 2 Up 32000 0 vcp-01/0 Configured -1 Down 10000

Connect the Virtual Chassis extended ports• Connect switches 1 and 3 together using the 10-Gigabit ethernet port xe-x/1/0 on each switch

• Connect switches 2 and 4 together using the 10-Gigabit ethernet port xe-x/1/0 on each switch.

Verify Virtual Chassis extended ports• Connect the console back to the first pair of switches.

• use the show virtual-chassis vc-port command to verify the port configuration is correct. all of the four switches are

visible, with one configured 1/0 port that has a neighbor listed.

root@EX4200VC-3a> show virtual-chassis vc-portfpc0:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 1 vcp-1vcp-1 Dedicated 2 Up 32000 1 vcp-01/0 Configured -1 Up 10000 2 vcp-255/1/0

fpc1:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 0 vcp-1vcp-1 Dedicated 2 Up 32000 0 vcp-01/0 Configured -1 Up 10000 3 vcp-255/1/0





use the show virtual-chassis command to verify that the Virtual Chassis is built as expected, based on the pre-

provisioning configuration we did earlier.

root@EX4200VC-3a> show virtual-chassis

Preprovisioned Virtual ChassisVirtual Chassis ID: 3f68.0cec.a7e1Virtual Chassis Mode: Enabled Mstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt FP0211490670 ex4200-48px 129 Backup N 1 vcp-0 1 vcp-1 2 vcp-255/1/01 (FPC 1) Prsnt FP0211490804 ex4200-48px 0 Linecard N 0 vcp-0 0 vcp-1 3 vcp-255/1/02 (FPC 2) Prsnt FP0211490739 ex4200-48px 129 Master* N 3 vcp-0 3 vcp-1 0 vcp-255/1/03 (FPC 3) Prsnt FP0211490735 ex4200-48px 0 Linecard N 2 vcp-0 2 vcp-1 1 vcp-255/1/0

Configure resilient dual-boot partitionsNOTE: It is important to run this step as it improves the resiliency of the system in the case of primary boot partition




Configure default settingsthe following commands show items that should be enabled by default in the configuration. You may wish to review



Configuring Layer 2 Settingsto configure layer 2 parameters and settings on the access switch in extended mode:

Configure VLANs

the eX4200VC-3b chassis has the following VlaNs assigned: data_wired_1a, data_wireless_1a, voip_wired_1a, voip_

wireless_1a, management_1a. It has only one Ip interface defined, which is on the management_1a VlaN.

root@EX3300VC-1a# set vlans access_points_1a vlan-id 54set vlans data_wired_1a vlan-id 12set vlans data_wireless_1a vlan-id 36set vlans voip_wired_1a vlan-id 24set vlans voip_wireless_1a vlan-id 42set vlans management_1a vlan-id 51

Configure InterfacesWe need to configure one Ip interface on the management VlaN.

set interfaces vlan unit 51 family inet address 10.10.51.9/24



Configure LAG (aggregated Ethernet) Portsthe eX4200VC-3b chassis has only one laG port configured to connect to the core switch. Junos Os requires that you

configure the number of laG interfaces you want to use before you begin configuring the laG interfaces. We suggest

picking a number slightly larger than what you need in case you add more laG interfaces later. You can change this

value in the future.

Because we need one laG interface for this configuration, we will configure the chassis with two in case we add

another laG connection later.

root@EX4200VC-3a# set chassis aggregated-devices ethernet device-count 2

the 10-Gigabit ethernet ports on the eX4200 series are only available using the uplink module ports. We have uplink

modules on each of the four switches. However, the first port xe-x/1/0 is already in use on each switch to form the

extended Virtual Chassis. We need to configure the laG connection on switch members 1 and 3, using ports xe-1/1/1

and xe-3/1/1.

First, we need to remove any port-specific configuration on the physical ports we want to aggregate. By default,

interfaces have unit 0 defined, but this is not allowed on an interface that is part of an aggregate interface because it

would conflict with unit 0 on the logical aggregate interface.

root@EX4200VC-3a# delete interfaces xe-1/1/1 unit 0delete interfaces xe-3/1/1 unit 0

root@EX4200VC-3a# set interfaces xe-1/1/1 ether-options 802.3ad ae0set interfaces xe-3/1/1 ether-options 802.3ad ae0

Next, we need to add LACP to each LAG interface to provide some health checking.NOTE: laCp must be configured on both sides for the laG port to become active.

root@EX4200VC-3a# set interfaces ae0 aggregated-ether-options lacp activeset interfaces ae0 aggregated-ether-options lacp periodic slow

Disable RSTP on LAG connections to access switches.Because we are not using rstp as a topology protocol, we can disable it on the laG ports going to our access

switches. Disabling rstp also reduces potential convergence times in case of a laG member failure, because fewer

protocols need to converge.

NOTE: all access switches will have rstp enabled for loop protection locally.

root@EX4200VC-3a# set protocols rstp interface ae0.0 disable

Configure the trunk port and VLAN

Next, we need to configure the laG port as a trunk and add the VlaNs that will be going to the core switch. to enable

the laG port as a trunk port, use the set interfaces command.

root@EX4200VC-3a# set interfaces ae0 unit 0 family ethernet-switching port-mode trunk

Configure VLANs on trunk ports.VlaN configuration for ae0, which connects to the eX4500VC-1a has data_wired_1a, voip_wired_1a, data_wireless_1a,

voip_wireless_1a, the management_1a VlaN for switch management and access_points_1a for the Wlas to reside.

VlaNs can be added in a single statement surrounded by [] or can be added one line at a time. this example shows

each command:



root@EX4200VC-3a# set interfaces ae0 unit 0 family ethernet-switching vlan members data_wired_1aset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wired_1aset interfaces ae0 unit 0 family ethernet-switching vlan members access_points_1aset interfaces ae0 unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces ae0 unit 0 family ethernet-switching vlan members management_1a


commit

You should see the commit operation finish on each of the eX series switches in the Virtual Chassis.

root@EX4200VC-3a# commitfpc0:configuration check succeedsfpc1:commit completefpc2:commit completefpc3:commit completefpc0:commit complete

Now Connect the LAG connections to the core switch.run the show lldp neighbors command to verify that the connection is up and you can see the other side of the

connection.

root@EX4200VC-3a> show lldp neighborsLocal Interface Parent Interface Chassis Id Port info System Namexe-1/1/1.0 ae0.0 a8:d0:e5:b5:0f:80 xe-0/0/4.0 EX4500VC-1axe-3/1/1.0 ae0.0 a8:d0:e5:b5:0f:80 xe-1/0/4.0 EX4500VC-1a

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

root@EX4200VC-3a# run show lacp interfacesAggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-3/1/1 Actor No No Yes Yes Yes Yes Slow Active xe-3/1/1 Partner No No No No Yes Yes Slow Active xe-1/1/1 Actor No No Yes Yes Yes Yes Slow Active xe-1/1/1 Partner No No Yes Yes Yes Yes Slow Active LACP protocol: Receive State Transmit State Mux State xe-3/1/1 Current Slow periodic Collecting distributing xe-1/1/1 Current Slow periodic Collecting distributing

Configure secure access port features.We recommend configuring these basic security features on the majority of the VlaNs on access switches. We need to

enable these features on the data_wired_1a and voip_wired_1a VlaNs.

You may notice that we do not enable these features on all the VlaNs. some VlaNs have a greater tendency to have

statically configured devices or may not require this feature. each device with a static Ip address attached to a port on

a VlaN, with these features enabled, requires a static port configuration with an Ip address and a maC address in order

to communicate with the rest of the network. this additional level of security can be configured If required, but it will

add some configuration overhead when network changes are made.




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.


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:




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


12 data_wired_1a 10.10.8.0/22 wired_access_ports

24 voip_wired_1a 10.10.24.0/22 wired_voice_ports

54 access_points_1a 10.10.54.0/24 wireless_access_points

root@EX4200VC-3a# set interfaces interface-range wired_access_ports member-range ge-0/0/5 to ge-0/0/26set interfaces interface-range wired_voice_ports member-range ge-0/0/27 to ge-0/0/47set interfaces interface-range wireless_access_points member-range ge-0/0/0 to ge-0/0/4

Set the port mode.set the port mode to access. Because we have used the interface-ranges statement, we only need to set the port mode

at the interface-range instead of editing every port.

root@EX4200VC-3a# set interfaces interface-range wired_access_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wired_voice_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wireless_access_points unit 0 family ethernet-switching port-mode trunk


root@EX4200VC-3a# set vlans data_wired_1a interface wired_access_portsset vlans voip_wired_1a interface wired_voice_ports

the ports for the Wlas require a trunking configuration and require a native VlaN (access_points_1a) be configured in


with this same VlaN or it will ignore the native VlaN configuration and will not work as expected.


https://www.juniper.net/techpubs/en_US/junos9.5/information-products/pathway-pages/ex-series/port-security.html

www.Juniper.net/techpubs



root@EX4200VC-3a# set interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces interface-range wireless_access_points unit 0 family ethernet-switching native-vlan-id access_points_1a

Configure layer 3 settings.layer 3 configuration for the access switch involves setting a default route in the case of the tested network. In this

case, it points to 10.10.28.1 which is the core switch

Ip interface on the management VlaN.

root@EX4200VC-3a# set routing-options static route 0.0.0.0/0 next-hop 10.10.51.1





root@EX4200VC-3a# run ping 10.10.51.1PING 10.10.51.1 (10.10.51.1): 56 data bytes64 bytes from 10.10.51.1: icmp_seq=0 ttl=64 time=2.254 ms64 bytes from 10.10.51.1: icmp_seq=1 ttl=64 time=1.759 ms64 bytes from 10.10.51.1: icmp_seq=2 ttl=64 time=1.720 ms



root@EX4200VC-3a> show ethernet-switching interfaces ae0Interface State VLAN members Tag Tagging Blockingae0.0 up access_points_1a 54 tagged unblocked data_wired_1a 12 tagged unblocked data_wireless_1a 36 tagged unblocked management_1a 51 tagged unblocked voip_wired_1a 24 tagged unblocked voip_wireless_1a 42 tagged unblocked


NOTE: Because of the large number of ports in eX4200VC-3a, the show command output below show the first

VlaN’s output.

root@EX4200VC-3a> show vlansName Tag Interfacesaccess_points_1a 54 ae0.0*, ge-0/0/0.0*, ge-0/0/1.0, ge-0/0/2.0, ge-0/0/3.0, ge-0/0/4.0




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.


• Classifiers

• schedulers

• scheduler-maps

• rewrite rules





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.


Configuring schedulers.We will create schedulers for each type of traffic we want to manage. When the schedulers are defined we also

configure characteristics like shaping/limiting/forwarding rate, how much buffer is allocated and what priority the

traffic has. In the tested network we have configured a couple of similar sounding schedulers; for example: voice-user-

sched and voice-network-sched. the difference between these schedulers is that they are intended to be applied to

different types of interfaces when we create our scheduler maps later. While these currently have the same values, in

the future you may need to change the characteristics of your network ports or access ports to be different from each

other. By configuring schedulers this way from the beginning it makes for less work if changes are needed later.



root@EX4200VC-3a#set class-of-service schedulers control-network-sched shaping-rate percent 5set class-of-service schedulers control-network-sched buffer-size percent 5set class-of-service schedulers control-network-sched priority strict-highset class-of-service schedulers control-user-sched shaping-rate percent 5 set class-of-service schedulers control-user-sched buffer-size percent 5set class-of-service schedulers control-user-sched priority strict-highset class-of-service schedulers voice-network-sched shaping-rate percent 5 set class-of-service schedulers voice-network-sched buffer-size percent 5 set class-of-service schedulers voice-network-sched priority strict-highset class-of-service schedulers voice-user-sched shaping-rate percent 5 set class-of-service schedulers voice-user-sched buffer-size percent 5 set class-of-service schedulers voice-user-sched priority strict-high set class-of-service schedulers business-sched transmit-rate percent 60 set class-of-service schedulers business-sched buffer-size percent 60set class-of-service schedulers business-sched priority low set class-of-service schedulers server-sched transmit-rate percent 30 set class-of-service schedulers server-sched buffer-size percent 30set class-of-service schedulers server-sched priority lowset class-of-service schedulers be-sched transmit-rate remainder set class-of-service schedulers be-sched buffer-size remainderset class-of-service schedulers be-sched priority low




root@EX4200VC-3a#set class-of-service scheduler-maps network-port-sched forwarding-class control scheduler control-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class voice scheduler voice-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps network-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps network-port-sched forwarding-class best-effort scheduler be-schedset class-of-service scheduler-maps access-port-sched forwarding-class control scheduler control-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class voice scheduler voice-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps access-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps access-port-sched forwarding-class best-effort scheduler be-sched



Configuring rewrite rules.these rules are used to mark packets appropriately before they exit an interface so that markings are preserved


root@EX4200VC-3a#set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority low code-point nc1set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority high code-point nc2set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class voice loss-priority low code-point efset class-of-service rewrite-rules dscp rewrite-dscp forwarding-class business-app loss-priority low code-point af21set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class best-effort loss-priority low code-point be


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


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





root@EX4200VC-3a#set class-of-service interfaces ge-* scheduler-map access-port-schedset class-of-service interfaces ge-* unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ge-* unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae0 scheduler-map network-port-schedset class-of-service interfaces ae0 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae0 unit 0 rewrite-rules dscp rewrite-dscp


commit

Verifying Class of Service Settingsthere are various commands that can be used to verify portions of the Class of service configuration


examples:




the most useful Class of service command might be looking at the interface statistics using the command



Show interface <interface name> detail

this command will provide details on what queues are configured on the port ,how many packets were seen, and if any

were dropped.

NOTE: when looking for Class of service statistics using the show interface command you will only see the statistics

on physical interfaces. therefore, when looking at a laG interface you need to run this command for each of the

physical interfaces that make up the link in order to view the Class of service details.

root@EX4200VC-3a> show interfaces ge-0/0/0 detailPhysical interface: ge-0/0/0, Enabled, Physical link is Up Interface index: 377, SNMP ifIndex: 502, Generation: 823 Link-level type: Ethernet, MTU: 1514, Speed: Auto, Duplex: Auto, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x0 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Hold-times : Up 0 ms, Down 0 ms Current address: 78:fe:3d:4e:6c:83, Hardware address: 78:fe:3d:4e:6c:83 Last flapped : 2012-11-09 16:56:38 UTC (00:00:05 ago) Statistics last cleared: 2012-11-07 12:16:51 UTC (2d 04:39 ago) Traffic statistics: Input bytes : 31437476 0 bps Output bytes : 13483181 504 bps Input packets: 127219 0 pps Output packets: 138641 0 pps IPv6 transit statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Egress queues: 8 supported, 5 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 19677 0 1 server-bulk 0 0 0 3 business-app 0 0 0 5 voice 0 0 0 7 control 0 118967 0 Queue number: Mapped forwarding classes 0 best-effort 1 server-bulk 3 business-app 5 voice 7 control Active alarms : None Active defects : None Interface transmit statistics: Disabled

Logical interface ge-0/0/0.0 (Index 68) (SNMP ifIndex 503) (Generation 349) Flags: SNMP-Traps 0x0 Encapsulation: ENET2 Traffic statistics: Input bytes : 2302688 Output bytes : 13055885 Input packets: 9641 Output packets: 119040 Local statistics: Input bytes : 2302688 Output bytes : 13055885 Input packets: 9641 Output packets: 119040 Transit statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps Protocol eth-switch, Generation: 395, Route table: 0 Flags: Trunk-Mode



Building A: Configuring EX3300 Access Switch

WLA

WLA

WLA

WLA

WLA

WLA

WLA


EX4200VC-2a

EX3300VC-1a

EX4200VC-3a

LAGLAG

LAGEX8200VC-1b

SRX SeriesCluster

WLCCluster

INTERNET

EX6200-1b

App Servers


EX4500VC-1a LAG

LAG

You are Here

Figure 15: Configuration of EX3300VC-1a

the setup and configuration for the eX3300 access switches share some common elements with both the dedicated

and extended mode of the eX4200. the difference is that unlike the eX4200 series switches, the eX3300 does not

have dedicated Virtual Chassis ports. Instead, the eX3300 has four fixed 10Gbe ports and two of those are configured

by default to act as VCpe ports. You can build a Virtual Chassis much like you would with the eX4200 – by connecting

the pre-configured VCpe ports together using 10Gbe ports (typically DaC cables).

If an eX3300 extended mode Virtual Chassis is desired (spanning greater distance, consolidating wiring closets, and

such) you simply use different optics to support the distance required and connect the switches as you would in a

normal extended Virtual Chassis setup.

For additional information on the eX3300, please follow this link.










http://www.juniper.net/us/en/products-services/switching/ex-series/ex3300/%23overview



Configuring Global Settings for the Access Switchto configure global settings on the access switch:

Connect to the Console Port of the EX3300 Switch (Setting: s9600, 8, 1, none).press enter. the following prompt appears.


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.


Type cli at the % Prompt



Configure the date and time in the format: YYYYMMDDhhmm.ss.set date 201201220830.00












YYYYMMDDhhmm.ss



Configure management access

root@EX3300VC-1a# set system services web-management https system-generated-certificate set system services sshdelete system services web-management httpdelete system services telnet

Configure DNS


Configuring an EX3300 Virtual Chassisto configure a Virtual Chassis for the access switch in dedicated mode:

Identify the Virtual Chassis type

In the case of the tested network, access switch eX3300 is a dedicated mode Virtual Chassis using only the VCp ports

to form the switching fabric interconnect. all switches are the same model.

Configure a pre-provisioned Virtual Chassisto pre-provision a Virtual Chassis you need to identify the serial numbers of each device that will be part of the Virtual

Chassis, the device function, and the order in which you want each switch to be placed. later, when all of the switches

are connected and powered up, they will automatically be assigned the proper function and slot. make sure you pay

attention to the serial numbers and positioning of each switch when you connect them together.

By default, the eX series devices automatically form a Virtual Chassis, but because the ordering is nondeterministic,

the switches may not be numbered sequentially. For more information about Virtual Chassis, see appendix a and B, or

the Day One book, Configuring EX Series Ethernet Switches.

root@EX3300VC-1a# set virtual-chassis preprovisionedset virtual-chassis member 0 role line-cardset virtual-chassis member 0 serial-number GE0211392919set virtual-chassis member 1 role line-cardset virtual-chassis member 1 serial-number GE0211371778set virtual-chassis member 2 role routing-engineset virtual-chassis member 2 serial-number GB0211501128set virtual-chassis member 4 role line-cardset virtual-chassis member 4 serial-number GB0211501285set virtual-chassis member 5 role line-cardset virtual-chassis member 5 serial-number GB0211494458set virtual-chassis member 3 role routing-engineset virtual-chassis member 3 serial-number GA0212039606

Configure Specific Virtual Chassis CommandsNOTE: split-detection is enabled by default, but because all devices are located in the same room and have dual

redundant connections, an accidental chassis split is unlikely. the eX3300 series switches use an extended Virtual

Chassis type we recommend keeping split-detection enabled. If you want to disable split detection it can be done by

issuing the command “set virtual-chassis no-split-detection”. For Virtual Chassis composed of only two devices we

recommend disabling split-detection. If you are not familiar with how split-detection works please review the section

on Virtual Chassis split-detection located in appendix a for more details.

using the VCpe ports on the front of the units, cable each the eX series switches together. When all of the switches are

cabled properly, power up the remaining switches. Once all the switches are powered up, verify that all of the members

are active by running the show virtual-chassis command.

xyzcompany.com





Preprovisioned Virtual ChassisVirtual Chassis ID: 897e.c906.f943Virtual Chassis Mode: Enabled Mstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt GE0211392919 ex3300-24p 0 Linecard NA 5 vcp-255/1/2 1 vcp-255/1/31 (FPC 1) Prsnt GE0211371778 ex3300-24p 0 Linecard NA 0 vcp-255/1/2 2 vcp-255/1/32 (FPC 2) Prsnt GB0211501128 ex3300-48p 129 Master* NA 1 vcp-255/1/2 3 vcp-255/1/33 (FPC 3) Prsnt GA0212039606 ex3300-48t 129 Backup NA 2 vcp-255/1/2 4 vcp-255/1/34 (FPC 4) Prsnt GB0211501285 ex3300-48p 0 Linecard NA 3 vcp-255/1/2 5 vcp-255/1/35 (FPC 5) Prsnt GB0211494458 ex3300-48p 0 Linecard NA 4 vcp-255/1/2 0 vcp-255/1/3





Configure 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




Configure default settings.

the following commands show items that should be enabled by default in the configuration. You may wish to review





Configuring Layer 2 Settings for EX3300 Virtual Chassisto configure layer 2 parameters and settings on the access switch in dedicated mode:

Configure VLANs.the eX3300VC-1a chassis has the following VlaNs assigned: data_wired_1a, data_wireless_1a, voip_wired_1a, voip_




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.


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.


interfaces have unit 0 defined, but this is not allowed on an interface that is part of an aggregate interface, because it



set interfaces xe-0/1/0 ether-options 802.3ad ae0set interfaces xe-5/1/0 ether-options 802.3ad ae0




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.


converge.






Configure VLANs on trunk ports.VlaN configuration for ae0, which connects to: eX4500VC-1a switch, data_wired_1a, voip_wired_1a, data_wireless_1a,

voip_wireless_1a, the management_1a VlaN for switch management and access_points_1a for the Wlas to reside.

VlaNs can be added in a single statement surrounded by [] or can be added one line at a time. In this example we will

show each command.

set interfaces ae0 unit 0 family ethernet-switching port-mode trunkset interfaces ae0 unit 0 family ethernet-switching vlan members data_wired_1aset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wired_1aset interfaces ae0 unit 0 family ethernet-switching vlan members access_points_1aset interfaces ae0 unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces ae0 unit 0 family ethernet-switching vlan members management_1a



Connect the LAG connections to the core switch using the show lldp neighbors command to verify that the connection is up and you can see the other side of the connection.

root@EX3300VC-1a# run show lldp neighborsLocal Interface Parent Interface Chassis Id Port info System Namexe-0/1/0.0 ae0.0 a8:d0:e5:b5:0f:80 xe-0/0/6.0 EX4500VC-1axe-5/1/0.0 ae0.0 a8:d0:e5:b5:0f:80 xe-1/0/6.0 EX4500VC-1a


root@EX3300VC-1a# run show lacp interfacesAggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-5/1/0 Actor No No Yes Yes Yes Yes Slow Active xe-5/1/0 Partner No No Yes Yes Yes Yes Slow Active xe-0/1/0 Actor No No Yes Yes Yes Yes Slow Active xe-0/1/0 Partner No No Yes Yes Yes Yes Slow Active LACP protocol: Receive State Transmit State Mux State xe-5/1/0 Current Slow periodic Collecting distributing xe-0/1/0 Current Slow periodic Collecting distributing




enable these features on the data_wired_1a and voip_wired_1a VlaNs.

You may notice that we do not enable these features on all the VlaNs. some VlaNs have a greater tendency to have

statically configured devices or may not require this feature. each device with a static Ip address attached to a port on

a VlaN – with these features enabled – requires a static port configuration with an Ip address and a maC address in

order to communicate with the rest of the network. If required, this additional level of security can be configured, but it

will add some overhead when network changes are made.

root@EX3300-vc2# set ethernet-switching-options secure-access-port vlan data_wired_1a arp-inspectionset ethernet-switching-options secure-access-port vlan data_wired_1a examine-dhcpset ethernet-switching-options secure-access-port vlan data_wired_1a ip-source-guardset ethernet-switching-options secure-access-port vlan voip_wired_1a arp-inspectionset ethernet-switching-options secure-access-port vlan voip_wired_1a examine-dhcpset ethernet-switching-options secure-access-port vlan voip_wired_1a ip-source-guard











Table 12: EX3300 VLAN IP Address Mapping






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@EX3300-vc2# set vlans data_wired_1a interface wired_access_portsset vlans voip_wired_1a interface wired_voice_ports






case, it points to 10.10.28.1 which is the core switch Ip interface on the management_1a VlaN



commit



root@EX3300VC-1a> ping 10.10.51.1PING 10.10.51.1 (10.10.51.1): 56 data bytes64 bytes from 10.10.51.1: icmp_seq=0 ttl=64 time=4.240 ms64 bytes from 10.10.51.1: icmp_seq=1 ttl=64 time=3.078 ms



root@EX3300VC-1a# run show ethernet-switching interfaces ae0Interface State VLAN members Tag Tagging Blockingae0.0 up access_points_1a 54 tagged unblocked data_wired_1a 12 tagged unblocked data_wireless_1a 36 tagged unblocked management_1a 51 tagged unblocked voip_wired_1a 24 tagged unblocked voip_wireless_1a 42 tagged unblocked


NOTE: Because of the large number of ports in eX4200VC-3a, the show command output below show the first VlaN’s

output.

root@EX3300VC-1a> show vlansName Tag Interfacesaccess_points_1a 54 ae0.0*, ge-0/0/0.0*, ge-0/0/1.0, ge-0/0/2.0, ge-0/0/3.0, ge-0/0/4.0, ge-5/0/0.0*




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.


• Classifiers

• schedulers

• scheduler-maps

• rewrite rules











characteristics like shaping/limiting/forwarding rate, how much buffer is allocated and what priority the traffic has.

In the tested network we have configured a few similar sounding schedulers. For example: voice-user-sched and

voice-network-sched. the difference between these schedulers is they are intended to be applied to different types

of interfaces when we create our scheduler maps later. While these currently have the same values, this configuration

allows granular changes to the characteristics of your network or access ports to diverge. Configuring schedulers this

way from the beginning makes less work if changes are needed later.

root@EX3300VC-1a# set class-of-service schedulers control-network-sched shaping-rate percent 5set class-of-service schedulers control-network-sched buffer-size percent 5set class-of-service schedulers control-network-sched priority strict-highset class-of-service schedulers control-user-sched shaping-rate percent 5 set class-of-service schedulers control-user-sched buffer-size percent 5set class-of-service schedulers control-user-sched priority strict-highset class-of-service schedulers voice-network-sched shaping-rate percent 5 set class-of-service schedulers voice-network-sched buffer-size percent 5 set class-of-service schedulers voice-network-sched priority strict-highset class-of-service schedulers voice-user-sched shaping-rate percent 5 set class-of-service schedulers voice-user-sched buffer-size percent 5 set class-of-service schedulers voice-user-sched priority strict-high set class-of-service schedulers business-sched transmit-rate percent 60 set class-of-service schedulers business-sched buffer-size percent 60set class-of-service schedulers business-sched priority low set class-of-service schedulers server-sched transmit-rate percent 30 set class-of-service schedulers server-sched buffer-size percent 30set class-of-service schedulers server-sched priority lowset class-of-service schedulers be-sched transmit-rate remainder set class-of-service schedulers be-sched buffer-size remainderset class-of-service schedulers be-sched priority low




root@EX3300VC-1a# set class-of-service scheduler-maps network-port-sched forwarding-class control scheduler control-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class voice scheduler voice-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps network-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps network-port-sched forwarding-class best-effort scheduler be-schedset class-of-service scheduler-maps access-port-sched forwarding-class control scheduler control-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class voice scheduler voice-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps access-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps access-port-sched forwarding-class best-effort scheduler be-sched



Configuring rewrite rules.rewrite rules are used to mark packets appropriately before egress into an interface so that markings are preserved


root@EX3300VC-1a# set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority low code-point nc1set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority high code-point nc2set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class voice loss-priority low code-point efset class-of-service rewrite-rules dscp rewrite-dscp forwarding-class business-app loss-priority low code-point af21set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class best-effort loss-priority low code-point be


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


You can also use wildcards to apply Class of service to multiple interfaces with a single command. For example here






root@EX3300VC-1a# set class-of-service interfaces ge-* scheduler-map access-port-schedset class-of-service interfaces ge-* unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ge-* unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae0 scheduler-map network-port-schedset class-of-service interfaces ae0 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae0 unit 0 rewrite-rules dscp rewrite-dscp


commit

Verifying class of service settings.there are various commands that can be used to verify portions of the Class of service configuration,


examples:









any were dropped.

NOTE: when looking for Class of service statistics using the show interface command you can only see the statistics on

physical interfaces so when looking at a laG interface you need to run this command for each of the physical interfaces

that make up the link in order to view the Class of service details.

root@EX3300VC-1a> show interfaces ge-0/0/0 detailPhysical interface: ge-0/0/0, Enabled, Physical link is Up Interface index: 450, SNMP ifIndex: 504, Generation: 501 Link-level type: Ethernet, MTU: 1514, Speed: Auto, Duplex: Auto, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x4000 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Hold-times : Up 0 ms, Down 0 ms Current address: 88:e0:f3:6e:c1:03, Hardware address: 88:e0:f3:6e:c1:03 Last flapped : 2012-11-05 10:54:05 GMT-8 (4d 06:02 ago) Statistics last cleared: 2012-11-07 12:01:39 GMT-8 (2d 04:55 ago) Traffic statistics: Input bytes : 46419257 3280 bps Output bytes : 28092328 3792 bps Input packets: 186168 4 pps Output packets: 276847 5 pps IPv6 transit statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Egress queues: 8 supported, 5 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 169799 0 1 server-bulk 0 0 0 3 business-app 0 0 0 5 voice 0 0 0 7 control 0 107047 2 Queue number: Mapped forwarding classes 0 best-effort 1 server-bulk 3 business-app 5 voice 7 control Active alarms : None Active defects : None Interface transmit statistics: Disabled

Logical interface ge-0/0/0.0 (Index 90) (SNMP ifIndex 505) (Generation 202) Flags: SNMP-Traps 0xc0004000 Encapsulation: ENET2 Traffic statistics: Input bytes : 866374 Output bytes : 12880915 Input packets: 6631 Output packets: 107049 Local statistics: Input bytes : 866374 Output bytes : 12880915 Input packets: 6631 Output packets: 107049 Transit statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps Protocol eth-switch, Generation: 232, Route table: 0 Flags: Trunk-Mode



Building A: Configuring EX4200 Dedicated Mode Access switch

WLA

WLA

WLA

WLA

WLA

WLA

WLA


EX4200VC-2a

EX3300VC-1a

EX4200VC-3a

LAGLAG

LAGEX8200VC-1b

SRX SeriesCluster

WLCCluster

INTERNET

EX6200-1b

App Servers


EX4500VC-1a LAG

LAG

You are Here

Figure 16: EX4200VC-2a Configuration









Configuring Global Settings for the Switchto configure global settings on the switch:

Connect to the Console Port of the EX4200 Switch (Setting: s9600, 8, 1, none).press enter. the following prompt appears.


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.




Type cli at the % Prompt




set date 201201220830.00










Configure the management and VME interface (optional)



root@EX4200VC-2a# set system services web-management https system-generated-certificateset system services sshdelete system services web-management httpdelete system services telnet

Configure DNS.


YYYYMMDDhhmm.ss

xyzcompany.com



Configuring a Dedicated Mode Virtual Chassisto configure a Virtual Chassis for the access switch in dedicated mode:

Identify the Virtual Chassis type.In the case of the tested network, access switch eX4200VC-2a is a dedicated mode Virtual Chassis using only the VCp

ports to form the switching fabric interconnect. Configure a pre-provisioned Virtual Chassis.

to pre-provision a Virtual Chassis you need to identify the serial numbers of each device that will be part of the Virtual

Chassis, the device function, and the order in which you want each switch to be placed. later, when all of the switches

are connected and powered up, they will automatically be assigned the proper function and slot. make sure you pay

attention to the serial numbers and ordering of each switch when you connect them together later.

By default, the eX series devices automatically form a Virtual Chassis, but because the ordering is nondeterministic,

the switches may not be numbered sequentially. For more information about Virtual Chassis, see “Virtual Chassis” on

page 93, or the Day One book, Configuring EX Series Ethernet Switches.

root@EX4200VC-2a# set virtual-chassis preprovisionedset virtual-chassis member 0 role line-cardset virtual-chassis member 0 serial-number BP0211386965set virtual-chassis member 1 role line-cardset virtual-chassis member 1 serial-number BP0211386975set virtual-chassis member 2 role line-cardset virtual-chassis member 2 serial-number BP0211386950set virtual-chassis member 3 role routing-engineset virtual-chassis member 3 serial-number BP0211386957set virtual-chassis member 4 role routing-engineset virtual-chassis member 4 serial-number BP0211386944set virtual-chassis member 5 role line-cardset virtual-chassis member 5 serial-number FP0211490429set virtual-chassis member 6 role line-cardset virtual-chassis member 6 serial-number FP0211490761set virtual-chassis member 7 role line-cardset virtual-chassis member 7 serial-number FP0211490744

Configure specific Virtual Chassis commands.NOTE: by default split-detection is enabled, but because all devices are located in the same room, and there are dual

redundant connections between devices, an accidental chassis split is unlikely. split detection can be disabled by

issuing the command “set virtual-chassis no-split-detection”. If you are making a Virtual Chassis with only two devices

we recommend disabling split-detection. If you are not familiar with how split-detection works please review the

section on Virtual Chassis split-detection located in appendix a for more details.

using the VCp ports at the back of the units, cable each pair of eX series switches together. When all of the switches

are cabled properly, power up the remaining switch. Once all the switches are powered up, verify that all of the

members are active by running the Commit the configuration show virtual-chassis command.





Preprovisioned Virtual ChassisVirtual Chassis ID: a2e4.9152.3afeVirtual Chassis Mode: Enabled Mstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt BP0211386965 ex4200-48t 0 Linecard N 7 vcp-0 1 vcp-11 (FPC 1) Prsnt BP0211386975 ex4200-48t 0 Linecard N 0 vcp-0 2 vcp-12 (FPC 2) Prsnt BP0211386950 ex4200-48t 0 Linecard N 1 vcp-0 3 vcp-13 (FPC 3) Prsnt BP0211386957 ex4200-48t 129 Backup N 2 vcp-0 4 vcp-14 (FPC 4) Prsnt BP0211386944 ex4200-48t 129 Master* N 3 vcp-0 5 vcp-15 (FPC 5) Prsnt FP0211490429 ex4200-48px 0 Linecard N 4 vcp-0 6 vcp-16 (FPC 6) Prsnt FP0211490761 ex4200-48px 0 Linecard N 5 vcp-0 7 vcp-17 (FPC 7) Prsnt FP0211490744 ex4200-48px 0 Linecard N 6 vcp-0 0 vcp-1 1





Configure resilient dual-boot partitionsNOte: It is important to run this step as it improves the resiliency of the system in the case of primary boot partition




Configure default settings.the following commands show items that should be enabled by default in the configuration. You may wish to review





Configuring Layer 2 Settings for EX4200 Dedicated Virtual Chassisto configure layer 2 parameters and settings on the access switch in dedicated mode:

Configure VLANs.the eX4200VC-2a chassis has the following VlaNs assigned: data_wired_1a, data_wireless_1a, voip_wired_1a, voip_




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.


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.


interfaces have unit 0 defined, but this is not allowed on an interface that is part of an aggregate interface, because it



root@EX4200VC-2a# set interfaces xe-0/1/0 ether-options 802.3ad ae0set interfaces xe-7/1/0 ether-options 802.3ad ae0




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.


converge.








Configure VLANs on trunk ports.VlaN configuration for ae0, which connects to the eX4500VC-1a switch, data_wired_1a, voip_wired_1a, data_

wireless_1a, voip_wireless_1a, the management_1a VlaN for switch management and access_points_1a for the Wlas to

reside. VlaNs can be added in a single statement surrounded by [] or can be added one line at a time. In this example

we will show each command.

set interfaces ae0 unit 0 family ethernet-switching vlan members data_wired_1aset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wired_1aset interfaces ae0 unit 0 family ethernet-switching vlan members access_points_1aset interfaces ae0 unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces ae0 unit 0 family ethernet-switching vlan members management_1a



Connect the LAG connections to the core switch. the show lldp neighbors command will verify that the connection is up and that you can see the other side of the

connection.

root@EX4200VC-2a> show lldp neighborsLocal Interface Parent Interface Chassis Id Port info System Namexe-0/1/0.0 ae0.0 a8:d0:e5:b5:0f:80 xe-0/0/8.0 EX4500VC-1axe-7/1/0.0 ae0.0 a8:d0:e5:b5:0f:80 xe-1/0/8.0 EX4500VC-1a


root@EX4200VC-2a> show lacp interfacesAggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-0/1/0 Actor No No Yes Yes Yes Yes Slow Active xe-0/1/0 Partner No No Yes Yes Yes Yes Slow Active xe-7/1/0 Actor No No Yes Yes Yes Yes Slow Active xe-7/1/0 Partner No No Yes Yes Yes Yes Slow Active LACP protocol: Receive State Transmit State Mux State xe-0/1/0 Current Slow periodic Collecting distributing xe-7/1/0 Current Slow periodic Collecting distributing


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.














Table 13: EX4200 Virtual Chassis 2 VLAN IP Address Mapping






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 vlans data_wired_1a interface wired_access_portsset vlans voip_wired_1a interface wired_voice_ports









case, it points to 10.10.28.1 which is the core switch Ip interface on the management VlaN.



commit

Verify IP reachabilityNext, you need to verify Ip reachability by “pinging” the core switch management Ip address from the access switch.


root@EX4200VC-2a> ping 10.10.51.1PING 10.10.51.1 (10.10.51.1): 56 data bytes64 bytes from 10.10.51.1: icmp_seq=0 ttl=64 time=2.717 ms64 bytes from 10.10.51.1: icmp_seq=1 ttl=64 time=1.887 ms64 bytes from 10.10.51.1: icmp_seq=2 ttl=64 time=2.198 ms



root@EX4200VC-2a> show ethernet-switching interfaces ae0Interface State VLAN members Tag Tagging Blockingae0.0 up access_points_1a 54 tagged unblocked data_wired_1a 12 tagged unblocked data_wireless_1a 36 tagged unblocked management_1a 51 tagged unblocked voip_wired_1a 24 tagged unblocked voip_wireless_1a 42 tagged unblocked


NOTE: Because of the large number of ports in eX4200VC-2a, the show command output below show the first VlaN’s

output.

root@EX4200VC-2a> show vlansName Tag Interfacesaccess_points_1a 54 ae0.0*, ge-0/0/0.0, ge-0/0/1.0, ge-0/0/2.0, ge-0/0/3.0, ge-0/0/4.0




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.


• Classifiers

• schedulers

• scheduler-maps

• rewrite rules





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.





characteristics like shaping/limiting/forwarding rate, how much buffer is allocated, and what priority the traffic has. In

the tested network there are schedulers that have very similar names and configuration. For example: voice-user-sched

and voice-network-sched, the difference between these schedulers is they are intended to be applied to different

types of interfaces when we create our scheduler maps later. While these currently have the same values, it may be

necessary to change the characteristics of your network or access ports to be different from each other. Configuring

schedulers this way from the beginning it makes less work if changes are needed later.

root@EX4200VC-2a# set class-of-service schedulers control-network-sched shaping-rate percent 5set class-of-service schedulers control-network-sched buffer-size percent 5set class-of-service schedulers control-network-sched priority strict-highset class-of-service schedulers control-user-sched shaping-rate percent 5 set class-of-service schedulers control-user-sched buffer-size percent 5set class-of-service schedulers control-user-sched priority strict-highset class-of-service schedulers voice-network-sched shaping-rate percent 5 set class-of-service schedulers voice-network-sched buffer-size percent 5 set class-of-service schedulers voice-network-sched priority strict-highset class-of-service schedulers voice-user-sched shaping-rate percent 5 set class-of-service schedulers voice-user-sched buffer-size percent 5 set class-of-service schedulers voice-user-sched priority strict-high set class-of-service schedulers business-sched transmit-rate percent 60 set class-of-service schedulers business-sched buffer-size percent 60set class-of-service schedulers business-sched priority low set class-of-service schedulers server-sched transmit-rate percent 30 set class-of-service schedulers server-sched buffer-size percent 30set class-of-service schedulers server-sched priority lowset class-of-service schedulers be-sched transmit-rate remainder set class-of-service schedulers be-sched buffer-size remainderset class-of-service schedulers be-sched priority low




root@EX4200VC-2a# set class-of-service scheduler-maps network-port-sched forwarding-class control scheduler control-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class voice scheduler voice-network-schedset class-of-service scheduler-maps network-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps network-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps network-port-sched forwarding-class best-effort scheduler be-schedset class-of-service scheduler-maps access-port-sched forwarding-class control scheduler control-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class voice scheduler voice-user-schedset class-of-service scheduler-maps access-port-sched forwarding-class business-app scheduler business-schedset class-of-service scheduler-maps access-port-sched forwarding-class server-bulk scheduler server-schedset class-of-service scheduler-maps access-port-sched forwarding-class best-effort scheduler be-sched



Configure rewrite rules.rewrite rules are used to mark packets appropriately before packets exit an interface so that markings are preserved


root@EX4200VC-2a# set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority low code-point nc1set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class control loss-priority high code-point nc2set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class voice loss-priority low code-point efset class-of-service rewrite-rules dscp rewrite-dscp forwarding-class business-app loss-priority low code-point af21set class-of-service rewrite-rules dscp rewrite-dscp forwarding-class best-effort loss-priority low code-point be


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


You can also use wildcards to apply Class of service to multiple interfaces with a single command. For example: here






root@EX4200VC-2a# set class-of-service interfaces ge-* scheduler-map access-port-schedset class-of-service interfaces ge-* unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ge-* unit 0 rewrite-rules dscp rewrite-dscpset class-of-service interfaces ae0 scheduler-map network-port-schedset class-of-service interfaces ae0 unit 0 classifiers dscp dscp_trustedset class-of-service interfaces ae0 unit 0 rewrite-rules dscp rewrite-dscp


commit

Verifying class of service settings.there are various commands that can be used to verify portions of the Class of service configuration


examples:









any were dropped.

NOTE: when looking for Class of service statistics using the show interface command you can only see the statistics on

physical interfaces so when looking at a laG interface you need to run this command for each of the physical interfaces

that make up the link in order to view the Class of service details.

root@EX4200VC-2a> show interfaces ge-0/0/0 detailPhysical interface: ge-0/0/0, Administratively down, Physical link is Down Interface index: 469, SNMP ifIndex: 504, Generation: 472 Link-level type: Ethernet, MTU: 1514, Speed: Auto, Duplex: Auto, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online Device flags : Present Running Down Interface flags: Hardware-Down Down SNMP-Traps Internal: 0x0 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Hold-times : Up 0 ms, Down 0 ms Current address: f8:c0:01:c6:72:83, Hardware address: f8:c0:01:c6:72:83 Last flapped : 2012-05-25 16:10:46 GMT-8 (2w2d 06:25 ago) Statistics last cleared: 2012-06-08 17:40:37 GMT-8 (2d 04:56 ago) Traffic statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps IPv6 transit statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Egress queues: 8 supported, 5 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 0 0 1 server-bulk 0 0 0 3 business-app 0 0 0 5 voice 0 0 0 7 control 0 0 0 Queue number: Mapped forwarding classes 0 best-effort 1 server-bulk 3 business-app 5 voice 7 control Active alarms : LINK Active defects : LINK Interface transmit statistics: Disabled

Logical interface ge-0/0/0.0 (Index 86) (SNMP ifIndex 505) (Generation 151) Flags: Device-Down SNMP-Traps 0x0 Encapsulation: ENET2 Traffic statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Local statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Transit statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps Protocol eth-switch, Generation: 179, Route table: 0 Flags: Trunk-Mode



Wireless LAN Overview

WLA

WLA

WLA

WLA

WLA

WLA

WLA


EX4200VC-2a

EX3300VC-1a

EX4200VC-3a

LAGLAG

LAGEX8200VC-1b

SRX SeriesCluster

WLCCluster

INTERNET

EX6200-1b

App Servers


EX4500VC-1a LAG

LAG

You are Here

Figure 17: Wireless LAN

Wireless Setup OverviewWe will use the following wireless ssIDs and VlaNs for the wireless laN table x shows the ssID to VlaN mapping for

each of the two buildings.

Table 14: SSID VLAN Mapping

SSID Bldg A VLAN name Bldg A VLAN ID Bldg B VLAN name Bldg B VLAN ID

xyzcompany_internal data_wireless_1a 36 data_wireless_1b 32

xyzcompany_voice voip_wireless_1a 42 voip_wireless_1b 40

xyzcompany_guest n/a n/a wireless_guest 60

as you can see there are consistent ssIDs throughout the campus, but they will map to different VlaNs in the different

buildings. this will be accomplished using the local switching option on the Wlas that was discussed in the Wireless

laN Overview section

authentication is configured depending on the ssID used (see table x). For example, internal users will be required

to authenticate via 802.1x to a corporate raDIus server. Guest users will have an open ssID no encryption, but will

authenticate using captive portal and be checked against a raDIus server used for guest access. Wireless Ip phones

will authenticate using a Wep key and allowed maC address range for security – many wireless phones have limited

authentication options.

Table 15: Authentication Methods by SSID

SSID Authentication Method Local or Centralized Switching

xyzcompany_internal raDIus, 802.1x local

wireless_voip ssID password, mac local

guest_wireless raDIus, captive portal Centralized



Wireless LAN ConfigurationIn this example we will step through all the essential steps in setting up wireless for corporate users and wireless Guest access.

WlCs will be clustered to provide Ha and load balancing of aps dynamically.

the guest access is for external access only it will provide guest users the ability to connect to the internet and is

isolated from the corporate network.

the setup process assumes your WlC is running the factory default configuration.

We will configure the Wireless laN Controllers in two steps.

1. Configure WlC2800-1b and WlC2800-2b with a base configuration providing Ip reachability using the quick start

configuration script.

2. Complete the configuration (clustering, ap specifics, VlaNs) of the WlCs using ringmaster.

Pre-requisites for WLAN ConfigurationIn order to complete the WlaN configuration section you will need to have the following software components

installed a network reachable server.

• ringmaster

• raDIus server

• DHCp server that supports option 43

Running Quick start on WLC2800-1bWe will use the quick start configuration script; it will guide you through the initial setup of WlC2800-1. It’s possible to

configure more items in quick start than we will be doing here, but this example steps through the process manually —

it allows more control and it will be easier to make changes later if needed.

NOTE: as we go through the Quick start pay close attention to vlan names, VlaN-IDs and password you select. these

items are all device independent and if they are out of sync with the other WlCs it can result in some seemingly

inconsistent behavior. also we will need the enable password for ringmaster to talk with the WlC.

• Connect to the console port of the WlC using settings 9600-8-N-1-None

• Hit the enter key a few times until you get a prompt.

• login with no username/password.

• enter “enable” at the prompt. No password is configured by default so just hit enter when prompted for a password.

• enter “quickstart” at the prompt.

WLC2800-0801B0# quickstart This will erase any existing config. Continue? [n]: yAnswer the following questions. Enter ‘?’ for help. ^C to break outSystem Name [WLC2800]: WLC2800-1bCountry Code [US]:System IP address []: 10.10.50.100System IP address netmask []: 255.255.255.0Default route []: 10.10.50.1Do you need to use 802.1Q tagged ports for connectivity on the default VLAN? [n]:Enable Webview [y]:Admin username [admin]:Admin password [mandatory]:Enable password [optional]:Do you wish to set the time? [y]:Enter the date (dd/mm/yy) []: 24/10/12Enter the time (hh:mm:ss) []: 13:21:00Enter the timezone []: PSTEnter the offset (without DST) from GMT for ‘PST’ in hh:mm [0:0]: -08:00Do you wish to configure wireless? [y]: nsuccess: created keypair for sshsuccess: Type “save config” to save the configurationsuccess: change accepted.

Now save your configuration.

WLC2800-1b# save configsuccess: configuration saved

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



Configuring VLANs and 802.1q trunking for WLC2800-1bIt is assumed that the associated switch port configuration on the eX8200VC-1B has already been done. If this is not

the case, please review the eX8200VC-1B configuration section and configure the associated ports for the WlCs.

the next configuration item is the system Ip address and VlaN that will be used and enable them on the trunk port.

the WlCs will be configured as part of the following VlaNs.

NOTE: the WlCs can be configured with a different vlan-id from the actual 802.1q tag this is specific to the WlC and

should not be confused with the 802.1q tag. For example you could have a vlan-id of 5 on the WlC, but it’s sent out as

802.1q tag 13 so to the network it is vlan-id 13. there can be advantages to this in more complex deployments, but that

is outside the scope of this document. to make things easier to understand we will configure the internal vlan-id the

same as the 802.1q tag that the rest of the network uses.

We will configure the following VlaN on WlC2800-1b

management vlan-id 50

Creating VLANs

set vlan 50 name management

Assigning VLANs to ports

set vlan 50 port 8 tag 50

Assigning IP interfaces to VLANsBy default the WlC will allocate the first Ip address (“system Ip address”) to VlaN 1. In our case we want this to be

VlaN 50 the management VlaN so we will first delete the Ip address association with VlaN 1 and then we will add it

to VlaN 50. NOte: this will still be the system address which has a special meaning to the WlC. the system Ip address

is the source Ip address the WlC uses to communicate with the access points to.

clear interface 1 IP

set interface management IP 10.10.50.100/24

Save your configuration.

save config

You should now be able to ping the Ip address of the eX8200VC-1B on the management VlaN.

WLC2800-1b# ping 10.10.50.1PING 10.10.50.1 (10.10.50.1) from 10.10.50.100 : 56(84) bytes of data.64 bytes from 10.10.50.1: icmp_seq=1 ttl=64 time=5.666 ms64 bytes from 10.10.50.1: icmp_seq=2 ttl=64 time=1.925 ms64 bytes from 10.10.50.1: icmp_seq=3 ttl=64 time=2.302 ms64 bytes from 10.10.50.1: icmp_seq=4 ttl=64 time=2.508 ms64 bytes from 10.10.50.1: icmp_seq=5 ttl=64 time=2.386 ms--- 10.10.50.1 ping statistics ---5 packets transmitted, 5 packets received, 0 errors, 0% packet loss

NOTE: you may notice we have configured the Ip address 10.10.50.100 twice. actually we configured this as the system

Ip address earlier now we are just assigning it to a VlaN. the system Ip address needs to reside on the management

network since that is the address that will be used to communicate to the aps and with other WlCs.



Running Quickstart on WLC2800-2bWe will use the quick start configuration script will guide you through the initial setup of WlC2800-1b. It’s possible to

configure more items in quick start than is done in this example, but we will step through the process manually – we

will have more control and it will be easier to make changes later if needed.

• Connect to the console port of the WlC using settings 9600-8-N-1-None.

• Hit the enter key a few times until you get a prompt.

• login with no username/password.

• enter enable at the prompt. By default, no password is configured. Just press enter when prompted for a password.

• enter “quickstart” at the prompt.

WLC2800-08033C# quickstartThis will erase any existing config. Continue? [n]: yAnswer the following questions. Enter ‘?’ for help. ^C to break outSystem Name [WLC2800]: WLC2800-2bCountry Code [US]:System IP address []: 10.10.50.101System IP address netmask []: 255.255.255.0Default route []: 10.10.50.1Do you need to use 802.1Q tagged ports for connectivity on the default VLAN? [n]: nEnable Webview [y]:Admin username [admin]:Admin password [mandatory]:Enable password [optional]:Do you wish to set the time? [y]:Enter the date (dd/mm/yy) []: 24/10/12Enter the time (hh:mm:ss) []: 13:30:00Enter the timezone []: PSTEnter the offset (without DST) from GMT for ‘PST’ in hh:mm [0:0]: -08:00Do you wish to configure wireless? [y]: nsuccess: created keypair for sshsuccess: Type “save config” to save the configurationsuccess: change accepted..


WLC2800-2b# save configsuccess: configuration saved

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

Configuring VLANs and 802.1q trunking for WLC2800-2bthis section assumes that the associated switch port configuration on the eX8200VC-1b has already been done. If this

is not the case please review the eX8200VC-1B configuration section and configure the associated ports for the WlCs.

Next we will configure the system Ip address and VlaN that will be used and enable them on our trunk port. the WlCs

will be configured as part of the following VlaNs.

the WlCs can be configured with a different vlan-id from the actual 802.1q tag. this is specific to the WlC and should

not be confused with the 802.1q tag. For example, you could have a vlan-id of 5 on the WlC, but it’s sent out as 802.1q

tag 13, so to the network it is vlan-id 13. there can be advantages to this in more complex deployments, but that is

outside the scope of this document. to make things easier to understand we will configure the internal vlan-id the

same as the 802.1q tag that the rest of the network uses.

We will configure the following VlaN on WlC2800-1b.

management vlan-id 50



Creating VLANs

set vlan 50 name management

Assigning VLANs to ports.

set vlan 50 port 8 tag 50

Assigning IP interfaces to VLANsBy default the WlC will allocate the first Ip address (“system Ip address”) to VlaN 1. In our case we want this to be

VlaN 50 the management VlaN so we will first delete the Ip address association with VlaN 1 and then we will add it

to VlaN 50. NOte: this will still be the system address which has a special meaning to the WlC. the system Ip address

is the source Ip address the WlC uses to communicate with the access points.

clear interface 1 ip

set interface Management ip 10.10.50.101/24


save config

It should now possible to ping the Ip address of the eX8200VC-1B on the management VlaN:

WLC2800-2b# ping 10.10.50.1PING 10.10.50.1 (10.10.50.1) from 10.10.50.101 : 56(84) bytes of data.64 bytes from 10.10.50.1: icmp_seq=1 ttl=64 time=5.283 ms64 bytes from 10.10.50.1: icmp_seq=2 ttl=64 time=2.529 ms64 bytes from 10.10.50.1: icmp_seq=3 ttl=64 time=2.349 ms64 bytes from 10.10.50.1: icmp_seq=4 ttl=64 time=2.397 ms64 bytes from 10.10.50.1: icmp_seq=5 ttl=64 time=4.906 ms--- 10.10.50.1 ping statistics ---5 packets transmitted, 5 packets received, 0 errors, 0% packet loss

You are now ready to complete the configuration using ringmaster.

Installing RingmasterInstallation of ringmaster is outside the scope of this document. to install and license ringmaster please see the

ringmaster Quick start Guide and/or the ringmaster documentation located at www.juniper.net/support.

Configuring WLCs and WLAs using RingmasterHigh level list of tasks to be done in order to setup the wireless laN in ringmaster

• upload WlCs into ringmaster

• Create mobility Domain and add WlCs to mobility Domain using the wizard

• Create a cluster

• Configure local WlC VlaNs, Ip addresses, etc…

• Configure authentication services

• Configure VlaN and radio profiles

• Configure wireless services (ssID setup)

• Configure local switching on Wlas

• adding Wlas to the system

Add devices to a NetworkDevices can be added two ways they can be pre-configured in ringmaster and deployed, they can be imported from

the existing network. We have previously configured the two WlCs (WlC2800-1b and WlC2800-2b) for basic network

connectivity. We will import these WlCs into ringmaster. Once this is done we can start managing both the WlCs.

www.juniper.net/support



Uploading WLC2800-1b into RingMaster1. select the Configuration Navigation Bar button.

2. In the tasks panel, select upload WlC.

3. In the Ip address field, type the Ip address for WlC2800-1b.

4. In the enable password field, type the enable password for WlC2800-1b. this password must match the enable

password defined using the ClI command set enablepass. For more information, see the Juniper mobility system

software Configuration Guide.

5. Click Next. the uploading progress is shown.

6. after the successfully uploaded device message is displayed, click Finish.

7. If ringmaster displayed error or warning messages, select the Verification Navigation Bar button and go to Verifying

Configuration Changes.

Uploading WLC2800-2b into RingMaster1. select the Configuration Navigation Bar button.

2. In the tasks panel, select upload WlC.

3. In the Ip address field, type the Ip address for WlC2800-2b.

4. In the enable password field, type the enable password for WlC2800-2b. this password must match the enable

password defined using the ClI command set enablepass. For more information, see the Juniper mobility system

software Configuration Guide.

5. Click Next. the uploading progress is shown.

6. after the successfully uploaded device message is displayed, click Finish.

7. If ringmaster displayed error or warning messages, select the Verification Navigation Bar button and go to Verifying

Configuration Changes.

ringmaster starts with a default Network plan called “default” when we will first import the WlCs they will be

part of this Network.

Creating a Mobility Domain 1. First we will create a mobility domain.

2. select the Configuration Navigation Bar button.

3. select the Create mobility Domain task in the tasks panel. the setup mobility Domain wizard is displayed.

4. In the Name field, type the name for the mobility Domain (1 to 16 characters, with no spaces or tabs).

In our example we will call it “xyzcompany-HQ” Click Next.

5. From the available Devices list, select WlC2800-1b and WlC2800-2b to add to the mobility Domain.

6. Click Next.

7. select WlC2800-1b to act as the primary seed WlC for the mobility Domain.

8. to provide mobility domain redundancy, select WlC2800-2b to act as secondary seed. Click Finish.

Activating Changes from the cluster wizardthe wizard makes the appropriate changes in the individual WlCs, but does not activate these changes. this must

be done manually on both WlCs. ringmaster also provides the ability to review the changes on the device before

deploying them. If you would like to view the changes first you can select “review” from the tasks panel.

1. select the Configuration Navigation Bar button

2. select WlC2800-1b

3. In the tasks panel select “Deploy”, once deploy is completed press “close”


5. In the tasks panel select “Deploy” once deploy is completed press “close”



Creating a Cluster in the Mobility DomainWe will now create a cluster inside the mobility domain. When device are in a cluster the majority of configuration is

shared between the devices in the cluster – but some things are not; for example, items that are locally significant like

Ip addresses and local VlaNs. an easy way to understand what is shared and what is not between WlCs is to select

configuration from the toolbar in ringmaster and click on cluster configuration. all the items there are shared between

devices in the cluster. If you select one of the individual WlCs you will see the items that are specific to that WlC.

1. In the Organizer pane select “xyzcompany-HQ”

2. From the tasks pane select “setup Cluster”

3. Next

4. You should see both the WlCs displayed

5. Check the merge checkbox

6. press “Deploy Changes”

7. Next

8. everything should now complete, when overall progress is 100% press “Finish”

9. You should now see a cluster under “xyzcompany-HQ” called “xyzcompany-HQ Cluster” that contains both

WlC2800-1b and WlC2800-2b when expanded

Configuring VLANs We configured the system Ip address and VlaN id using the ClI already, but we need to add an additional VlaN for

Guest access to the WlCs. each of the WlCs will be configured to sit on the management and guest_wireless VlaNs.

later we will configure the individual Wlas for local switching and configure their VlaN mapping separately.

We have already configured the management VlaN and Ip so we will now configure the remaining VlaN that the WlC

will use.

NOTE: in the tested network example both WlCs are located in the same subnet and have the same VlaNs. You

should be careful when making device specific changes that have local significance like VlaN membership, etc… as

these are NOt sYNCrONIZeD between the WlCs in the cluster. make sure you pay attention as you configure the VlaN

information. For example: if you have one WlC configured with a VlaN called guest_wireless and the other configured

with one called wireless_guest by mistake, you will have some users that will not connect properly to the wireless

network – and some that will – because we load balance Wlas between controllers. On the surface it may seem like

random behavior when one user can connect and another in the same building cannot.

WLC2800-1b VLAN Configuration1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain


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.



WLC2800-2b VLAN Configuration1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain

2. select WlC2800-2

3. select the system-> VlaNs item

4. From the tasks pane select “Create VlaN”

5. set VlaN name and VlaN ID

• VlaN name: wireless_guest

• VlaN id: 60

6. Next

7. add WlC port(s) to the VlaN

• add port 8 to the VlaN wireless_guest

8. Next

Configure WLC IP address for VLAN 1. Ip address: 10.10.60.101/24

2. select “Interface enabled”

3. Finish

4. From the tasks pane select “Deploy”


to verify the configuration you can select the VlaN you just configured and click properties. this will include the

information you just entered and some additional configuration panes that we will ignore for now.

Configuring Authenticationauthentication uses a standard raDIus server for enterprise users and a smartpass server for our guest users.

a single raDIus server could be used for both user types, but in this case we are using smartpass for guest

access because it has specific features that make it easier to manage guest users in an ad-hoc manner. setup and

configuration of smartpass is outside the scope of this document please see the smartpass Quick start Guide or

smartpass documentation located at www.juniper.net/support

We could also configure local authentication if needed for interim testing – if no raDIus servers have been setup yet.

However, this requires users be replicated between WlCs and this manual synchronization process is typically error

prone; it is not recommended as a primary method for authenticating users.

Cluster RADIUS configuration1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain

2. select “xyzcompany-HQ Cluster”

3. select “Cluster Configuration”

4. select aaa -> raDIus

5. In the tasks pane select “Create raDIus server”

6. Name: enterprise_raDIus_server

7. enter the Ip address of the raDIus server

• 10.10.48.100

8. enter the raDIus Key

• <radius key>

9. Next

10. either select next or edit the raDIus server Group name and then select next

11. Finish




Cluster Guest Wireless Authentication ConfigurationNow we will configure the smartpass server for the guest wireless users

1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain



4. In the tasks pane select “Create raDIus server”

5. Name: smartpass_Guest_access_server

6. enter the Ip address of the raDIus server

• 10.10.64.100

7. enter the raDIus Key

• <radius key>

8. Next

9. Do not add this raDIus server to the existing raDIus group we will create a new one for it later

10. Finish

Configuring the RADIUS Authentication OptionsDepending on the setup of your raDIus server you may need to change the authentication protocol option of your

server or the authentication port.




4. select the server “enterprise_raDIus_server”

5. press the “properties” button

6. select the authentication protocol pull-down menu and select the appropriate option for your raDIus server.

In the tested network we used msCHap-V2, but this could be different for your raDIus server configuration.

Creating a RADIUS Server Group for guest users1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain



4. In the tasks pane select “Create raDIus server Group”

5. Name: “smartpass_Guest_access-GrOup”

6. Next

7. select the smartpass_Guest_access_server and add it to the group

8. Finish

Configuring the SmartPass authentication optionsDepending on the setup of your raDIus server you may need to change the authentication protocol option of your

server or the authentication port.




4. select the server “smartpass_Guest_access_server”

5. press the “properties” button

6. select the authentication protocol pull-down menu and select the appropriate option for your smartpass server.

In the tested network we used NONe, but this could be different for your smartpass server configuration.

Activating changes1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain



4. select “Deploy”



Testing RADIUS authenticationIf the raDIus servers are up and active you can test out the raDIus server connection by using the raDIus ping utility

in ringmaster.




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


Setting up VLAN ProfilesVlaN profiles are created under the local switching section of ringmaster. this allows selection of what VlaNs will

be mapped to ssIDs. we will create VlaN profiles for building a and building B of the tested network. this is required

because we want to use a consistent ssID for both buildings, but each building will have slightly different VlaN

mapping. VlaN profiles allow us to provide this single global ssID and authentication method globally, but maps

locally to the specific environment.

VLAN Profile for Building A1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain



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


• 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



VLAN Profile Building B1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain


3. select local switching

4. In the tasks pane select “Create VlaN profile”

5. Name: “Building_B”

6. Next

7. select the “add VlaN” button

8. We will configure the data_wireless_1b network first

• Name: data_wireless_1b


• tag value 32

9. Click OK

10. Now click “add VlaN” again and add the voice wireless

• Name: voip_wireless_1b


• 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





Radio ProfilesCreating Radio Profiles for building A and Building Bradio profiles allow you to manage groups of Wlas easily in one spot. this is very handy when you need to configure

your channel plan and other features after the infrastructure has been deployed. In this tested network example

we have two simple plans – one for each building – but this could be more complex depending on the specific

requirements.


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



Setting up Wireless Servicesthe first step is to set up wireless services for the enterprise users. since we are using local switching a wireless

services profile is required for each building. this will allow a single wireless ssID “xyzcompany_internal” for all

enterprise users in both buildings, but will modify the behavior based on the building. this ensures that user traffic is

handled locally by the wireless access points.

Setting up Building A1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain



4. select Wireless -> Wireless services

5. In the tasks pane select “802.1X service profile”

6. Next

7. enter the name for this profile “secure-802.1X-Building-a”

8. enter the ssID for enterprise users “xyzcompany_internal”

9. Next

10. select eap type “external server authentication”

11. select the server group associated with the enterprise users “enterprise_raDIus_server-GrOup” and

add it to “Current aaa server Groups”

12. Next

13. ImpOrtaNt type in the VlaN name for the VlaN that will be used in building a for internal users “data_wireless_1a”

14. Next

15. Now select the radio profile “Building_a”.

16. Next

17. We will not make any changes to the 802.11n attributes

18. Finish

19. Check “apply changes to Cluster members”

20. Next

21. Finish

22. In the tasks pane select “Deploy”

Setting up Building B1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain




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”




Setting up Wireless Voice Wireless phones typically have some unique requirements. there are in-depth wireless deployment guides available

for different phone models available at www.Juniper.net. these settings are specific to the tested network example

and will need some modification if you are deploying wireless voice. as with the enterprise users, two Wireless service

profiles will be configured – one for each building. Both profiles will share the same ssID “xyzcompany_voice”.

Building A Configuration1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain



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”


http://www.juniper.net



Building B Configuration1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain



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


35. Finish

36. select “apply changes to Cluster members”

37. select “Next”

38. select “Finish”


Guest Wireless setupFor building A1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain



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”



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


18. Finish

19. select apply changes to cluster members

20. Next

21. Finish





For Building B1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain



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


18. Finish

19. select apply changes to cluster members

20. Next

21. Finish







Adding WLAsthere are multiple ways to deploy the Wlas:

• the Wlas can be deployed in the network and configured later if desired.

• the Wlas can be deployed and automatically configured by the system.

• Wlas can pre-configure in ringmaster and then deployed later.

each method has its own advantages and disadvantages. the example presented in the tested network presents pre-

configuration of the Wlas for later deployment. this requires having the serial numbers for the Wlas that are going to

deploy beforehand, and also have an idea where the Wlas will be placed.

NOTE: in the tested network example we have the WlCs and the Wlas on different networks. Because of this it was

necessary to configure option 43 on our DHCp servers. the information contained in that field tells the Wla the Ip

address of the WlCs. Option 43 is a list of Ip addresses that correspond to the WlC(s) configured in the network. For

our case the list has two entries 10.10.50.100 and 10.10.50.101. If deploying your Wlas on a different network from the

WlCs you will need to configure option 43 for the Wlas to boot up and get their configuration from the WlCs.

there are other ways to have Wlas boot and find their WlC without using option 43 that are documented in the day

one book Deploying a Secure Wireless LAN or you can find this in the operator’s manual.

Building B WLA configuration1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain


3. select Wireless -> WlaN access points

4. In the tasks pane select “Wla” under the “Create section

5. enter the following information for each Wla

a. assign a Wla number or let the system pick one for you

b. enter a name for the Wla, you can leave the default or give the Wla a name

c. leave connection as Distributed

d. enter a description if you would like, this could include additional details to help in locating the Wla if needed

later.

6. Next

7. enter the serial number of the unit

8. Next

9. select the Wla model for the Wla in the tested network it is Wla532-us

10. Next

11. select the correct radio profile for the first radio on the Wla in our case we select “Building_B”

12. Next

13. select the correct radio profile for the second radio on the Wla in our case we select “Building_B” again.

14. Finish

Enable local switching on the WLA1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain


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”

http://www.juniper.net/us/en/community/junos/training-certification/day-one/wireless/deploying-a-secure-wireless-lan/



Preparing Clients for Wireless Connectivitymss uses 802.1X for access to secure (encrypted) ssIDs, like xyzcompany_internal, using dynamic keys. to allow a

wireless client access on an encrypted ssD with dynamic keys, 802.1X must be configured on the client.

time to set up that laptop.

Configuring a Client for Guest Accesslet’s configure a Windows laptop for guest access to the public network and see if things are working from this

perspective. the exact procedure, of course, depends on your operating system and hardware:

1. On your Windows 7 pC, right-click the Wireless icon on the toolbar at the bottom right of the screen.

2. select xyzcompany_guest from the list of available wireless networks.

3. Double-click and wait for a successful connection.

4. Once you’re connected, the Web portal page is displayed.

5. log in using the configured username and the password

Configuring a Client for Corporate AccessNow let’s configure a Windows 7 client for access to an encrypted ssID. the exact procedure, of course, depends on

your operating system and hardware:

1. In Windows 7, go to Control panel > Network and Internet >Network and sharing Center.

2. under Change Your Network settings, click Manually to connect to a wireless network.

3. enter acme-corp as the Network name.

4. From the security type list, select Wpa2-enterprise.

5. leave the encryption type as aes.

6. the default authentication method is microsoft:protected eap (peap).

7. Click settings.

8. Clear the Validate server certificate check box.

9. under select authentication method, the default method is secured password (eap-msCHapv2).

10. Click Configure.

11. Clear the automatically use my Windows logon name and password (and domain if any) check box. Click OK.

12. Click OK, and then click Close.

13. Click the Wireless icon in the toolbar, and select xyzcompany_internal from the list of available wireless networks. and

let’s connect to the xyzcompany_internal ssID; this is really easy!

If your laptop doesn’t automatically find the ssID, open Network Connections, and then right-click the Wireless

Connection icon. select View available Wireless Networks to display the list of networks in the area.

In Figure 18, three ssIDs are displayed. Double-click xyzcompany_internal to get connected.

Figure 18: Wireless Network Connection



How to verify connectivitylet’s also verify your Ip address information, by opening a command prompt window, and typing in ipconfig. all of your

wireless client settings are displayed as shown in Figure 19.

Figure 19: ipconfig Information

as you can see from the Ip address assigned, we have connected through an ap located in Building B. so this tells us

we have connected to the wireless network and been assigned a proper Ip address. Now test some basic connectivity.

ping an internal or external device in this case we will ping a device on the internet to verify connectivity, see Figure 20.

Figure 20: Verifying Connectivity



Adding More Clients to the WLANNow it’s time to grab your colleagues and walk them through the steps of configuring the wireless client on various

mobile devices. If you’ve followed the configuration correctly, wireless clients should have no problem finding

and connecting to your wireless network. Bring in all your mobile devices and laptops to document and test their

connectivity. update the drivers on laptops or tablets to be sure that you have the latest versions.

For additional information on Juniper WlaN products and troubleshooting, see appendix C.

SRX Deployment

WLA

WLA

WLA

WLA

WLA

WLA

WLA


EX4200VC-2a

EX3300VC-1a

EX4200VC-3a

LAGLAG

LAGEX8200VC-1b

SRX SeriesCluster

WLCCluster

INTERNET

EX6200-1b

App Servers


EX4500VC-1a LAG

LAG

You are Here

Figure 21: SRX Network Location

Before you begin configuring the srX series services Gateway for the tested network design, ensure the following:

• that all the srX series devices to be configured in the cluster are of the same model and comprise the same modules.

• that all the srX series devices have the same version of Junos Os installed.

Figure 22 shows the srX series cluster configured for the tested network. to keep it simple, each device identifies the

fabric and control links as local physical ports, because these are connected before configuring the srX series cluster

(after the srX series cluster is configured, srX650-2b will see these ports as ge-9/0/2 and 9/0/1). the remaining port

identifiers are listed in the clustering context.



SRX650-1b

Trunk Links with reth Interfaces

VLAN Interface

SRX650-2b

Active(Route Weighted)

ge-2/0/0

ge-11/0/0

ge-2/0/1 10.94.44.2

10.94.44.6ge-11/0/2

INTERNET

SERVICEPROVIDER 2


SERVICEPROVIDER 1

Control Link Fabric Link

internet_edge reth 0.44 10.10.44.252/24

management_1b reth 0.50 10.10.50.254/24

guest_wireless reth 0.60 10.10.60.254/24

SRX Cluster Ports

Fabric LinksSRX650-1b ge-0/0/2

SRX650-2b ge-0/0/2

Control LinksSRX650-1b ge-0/0/1

SRX650-2b ge-0/0/1

Figure 22: SRX Link Diagram

Configuring the SRX Clusterto configure the srX series Gateway devices for the tested network, you must first perform the following setup

procedure for both srX series devices that will make up the cluster.

to perform the initial setup for the srX650 devices:

Unpack the SRX650 and connect a console cable to the serial port with the following settings: 9600, 8, 1 and none.

To access the SRX650 using the Junos OS CLI:1. Connect one end of the console cable to the serial port adapter, plug the adapter into a serial port on the pC or laptop,

and plug the other end of the cable into the console port on the srX series device.

2. start the terminal emulation program on the pC or laptop, select the COm port, and configure the following port

settings: 9600 (bits per second), 8 (data bits), none (parity), 1 (stop bits), and none (flow control).

3. press the pOWer button on the router, and verify that the pOWer leD turns green.

4. log in as root, and press enter at the password prompt. (When booting the factory default configuration, you do not

need to enter a password.)

5. enter the uNIX shell after you are authenticated through the ClI:

Amnesiac (ttyu0)login: rootPassword:- - - JUNOS 12.1r1.9 built 2011-11-16 09:23:09 UTC

6. at the % prompt, type “cli” to start the ClI and press enter. the prompt changes to an angle bracket (>) when you enter

ClI operational mode.

root@%cli root>

7. at the (>) prompt, type “configure” and press enter. the prompt changes from > to # when you enter configuration mode.

root> configureEntering configuration mode[edit]root#



8. Create a password for the root user to manage the srX series device.

root# set system root authentication plain-text-password

(will prompt for password)

9. remove some default configuration items from the srX devices. this is done to make later configuration simpler.

NOTE: Not all of these settings may actually be configured on your device, but we include all these items for

completeness.

root# delete interfacesdelete protocolsdelete vlansdelete system services dhcpdelete system services web-management http interfacedelete system services web-management https interfacedelete security zonesdelete security policiesdelete security nat

10. use the commit command at the ClI prompt to activate the configuration.

Commit

Now repeat this process with the other srX650.

Connect the two SRX devices.NOte: the following process is for the srX650. If you use another srX model, the ports used to connect the two srXs

will be different than the process described below. please see the Juniper Networks support site for clustering details

on your specific model of srX.

On the srX650, connect ge-0/0/1 on device a to ge-0/0/1 on device B. the ge-0/0/1 interface on device B will change

to ge-9/0/1 after clustering happens.

TIP: to connect the devices, it is helpful to know that after we create the cluster the following interface assignments

will occur:

• ge-0/0/0 will be used as fxp0 for individual management of each of the devices

• ge-0/0/1 will become fxp1 and used as the control link between the two devices (this is also documented inKB15356.).

this interface assignment is not configurable.

the other interfaces are also renamed on the secondary device. For example, on a srX 650 device, the ge-0/0/0

interface is renamed to ge-9/0/0 on the secondary node 1. refer to the complete mapping for each srX series device:

Node Interfaces on Active SRX Series Chassis Clusters.

NOTE: the interfaces used for the control link, in this example ge-0/0/1, must be connected with a cable. a switch

cannot be used for the control link connection. also, you will need to decide on a third link to connect the devices,

which will be used for the fabric link between the devices.

In this case we will use ge-0/0/2, but you could use any other open port either onboard or on a gpIm.

Now connect ge-0/0/2 on srX650-1 to ge-0/0/2 on srX650-2.

Enable clustering on the SRX devices.set the devices in cluster mode with the following command and reboot the devices.

NOTE: this is an operational mode command.

root> set chassis cluster cluster-id 0-15 node 0-1 reboot

For example:

root> set chassis cluster cluster-id 1 node 0 rebootroot> set chassis cluster cluster-id 1 node 1 reboot

http://www.juniper.net/techpubs/software/junos-security/junos-security10.1/junos-security-swconfig-security/index.html?topic-43706.html



the cluster ID is the same on both devices, but the node ID should be different, with the node ID as node0 on one

device, at node1 on the other device.

this command should be issued on both devices at the same time so that they boot up together.

the range for the Cluster ID is 0–15. setting it to 0 effectively disables cluster mode.

after rebooting, the ge-0/0/0 and ge-0/0/1 interfaces become as fxp0 and fxp1, respectively.

Check both srX series devices to ensure that the cluster is active and that the primary and secondary devices are both

active.

NOTE: It may take a minute or two for the status to complete after booting, so you may need to enter this command

more than once. the prompt on each srX series device displays the status and node information for the respective

device.

{primary:node0}root> show chassis cluster statusCluster ID: 1Node Priority Status Preempt Manual failoverRedundancy group: 0 , Failover count: 1node0 1 primary no nonode1 1 secondary no no

{secondary:node1}root> show chassis cluster statusCluster ID: 1Node Priority Status Preempt Manual failoverRedundancy group: 0 , Failover count: 0node0 1 primary no nonode1 1 secondary no no

When the primary and secondary status is confirmed, move to the next step. If you encounter any problems during this

step, the following KB articles may be of use in diagnosing clustering problems: KB–15503, KB–20672 and KB–20641.

Configure the SRX Series cluster.

NOTE:

• the following steps are all performed on the primary srX series device. the configuration is automatically copied over to

the secondary srX series device when a configuration is committed.

• We use the Junos Os group configuration feature for this operation. For more information on the group configuration

feature, see the Day One book, Configuring Junos Basics.

• Configuring device-specific properties using the group command: set up device-specific settings such as hostnames

and management Ip addresses. this is specific to each device and is the only part of the configuration that is unique to

specific nodes. this is done by entering the following commands (all on the primary node):

On device srx650-1b: Enter configuration mode

root# configroot# set group node0 system host-name srx650-1bset group node0 interfaces fxp0 unit 0 family inet address 10.94.188.103/24set group node1 system host-name srx650-2bset group node1 interfaces fxp0 unit 0 family inet address 10.94.188.104/24

NOTE: the apply groups command is set so that the individual configurations for each node set by the above

commands applies only to that node.

root# set apply-groups [ node0 node1 ]

http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/basics/




root# commitYou should see the configuration applied to node0 and node1 when you issue a commit{primary:node0}[edit]root# commitnode0:configuration check succeedsnode1:commit completenode0:commit complete

Configure the Fabric Link Create FAB links (data plane links for RTO sync, etc).You need to first delete any specific configuration related to the interfaces. In this case ge-0/0/2 has an address

assigned by default so we will delete it.

root@srx650-1# set interfaces fab0 fabric-options member-interfaces ge-0/0/2 set interfaces fab1 fabric-options member-interfaces ge-9/0/2

Configuring Redundancy Groupsset up the redundancy Group 0 for the routing engine failover properties. also setup redundancy Group 1 (all the

interfaces will be in one redundancy Group in this example) to define the failover properties for the reth interfaces.

NOTE: If you want to use multiple redundancy Groups for the interfaces, refer to the Junos documentationSecurity Configuration Guide.

root@srx650-1b# set chassis cluster redundancy-group 0 node 0 priority 100set chassis cluster redundancy-group 0 node 1 priority 1set chassis cluster redundancy-group 1 node 0 priority 100set chassis cluster redundancy-group 1 node 1 priority 1

Configuring Interface Monitoring set up the Interface monitoring. monitoring the health of the interfaces is one way to trigger redundancy group failover.

NOte: Interface monitoring is not recommended for redundancy-group 0.

root@srx650-1b# set chassis cluster redundancy-group 1 interface-monitor ge-2/0/0 weight 255set chassis cluster redundancy-group 1 interface-monitor ge-11/0/0 weight 255

Set up the reth interface.setup the redundant ethernet interfaces (reth interface) and assign the redundant interface to a zone. make sure that

you setup your redundant interfaces as follows:

root@srx650-1b# set chassis cluster reth-count 1set interfaces ge-2/0/0 gigether-options redundant-parent reth0set interfaces ge-11/0/0 gigether-options redundant-parent reth0set interfaces reth0 redundant-ether-options redundancy-group 1

http://search.yahoo.com/r/_ylt=A0oGdXukQPZQGGEAkvhXNyoA;_ylu=X3oDMTE1MG0zYzQ3BHNlYwNzcgRwb3MDMwRjb2xvA3NrMQR2dGlkA01TWTAwOV8xMTY-/SIG=14s9prmge/EXP=1358344484/**http%3a/www.trapezenetworks.com/techpubs/en_US/junos12.1/information-products/topic-collection

http://search.yahoo.com/r/_ylt=A0oGdXukQPZQGGEAkvhXNyoA;_ylu=X3oDMTE1MG0zYzQ3BHNlYwNzcgRwb3MDMwRjb2xvA3NrMQR2dGlkA01TWTAwOV8xMTY-/SIG=14s9prmge/EXP=1358344484/**http%3a/www.trapezenetworks.com/techpubs/en_US/junos12.1/information-products/topic-collection



Configure VLANs and IP interfaces on the reth interface

root@srx650-1b# set interfaces reth0 vlan-taggingset interfaces reth0 redundant-ether-options redundancy-group 1set interfaces reth0 unit 0 description “Unit 0 must be given a VLAN tag so using a dummy tag to align units to tags”set interfaces reth0 unit 0 vlan-id 1set interfaces reth0 unit 44 description internet_edgeset interfaces reth0 unit 44 vlan-id 44set interfaces reth0 unit 44 family inet address 10.10.44.254/24set interfaces reth0 unit 50 description managementset interfaces reth0 unit 50 vlan-id 50set interfaces reth0 unit 50 family inet address 10.10.50.254/24set interfaces reth0 unit 60 description guest_wirelessset interfaces reth0 unit 60 vlan-id 60set interfaces reth0 unit 60 family inet address 10.10.60.254/24

Commit the configuration to activate it.

commit

Configure the Internet connections

root@srx650-1b# set interfaces ge-2/0/1 description “Primary Internet Connection”set interfaces ge-2/0/1 unit 0 family inet address 10.94.44.2/30set interfaces ge-11/0/2 description “Backup Internet Connection”set interfaces ge-11/0/2 unit 0 family inet address 10.94.44.6/30


root@srx650-1b# commit

NOTE: even though we have configured interfaces, we will not have reachability because no security policies are in

place yet.

Configuring Security Zonesthe srX series services Gateways use a zone-based model for security. the most basic configurations typically have

just two zones: trust (the inside) and untrust (the outside). In our case we have four: untrust, guest, management, and

internet_edge.

NOTE: the security policies shown here are meant to be a starting point and may need to be adjusted to your specific

network. For example, the voice networks can talk to all devices in the intranet and internet currently, but you may want

to restrict the type of traffic allowed to only voice and signaling.

Configure the untrust security zone.the untrust zone is where the srX series devices connect to the Internet. this is considered the least trusted zone. We

have configured our internet-facing ports in this zone.

root@srx650-1b# set security zones security-zone untrust screen untrust-screenset security zones security-zone untrust interfaces ge-11/0/2.0set security zones security-zone untrust interfaces ge-2/0/1.0



Configure the guest security zone.

root@srx650-1b# set security zones security-zone guest address-book address guest_wireless 10.10.60.0/24set security zones security-zone guest host-inbound-traffic system-services pingset security zones security-zone guest host-inbound-traffic system-services tracerouteset security zones security-zone guest interfaces reth0.60 host-inbound-traffic system-services dhcpset security zones security-zone guest interfaces reth0.60 host-inbound-traffic system-services bootp

Configure the Management security zone.

root@srx650-1b# set security zones security-zone management address-book address management_1a 10.10.51.0/24set security zones security-zone management address-book address management_1b 10.10.50.0/24set security zones security-zone management host-inbound-traffic system-services sshset security zones security-zone management host-inbound-traffic system-services httpset security zones security-zone management host-inbound-traffic system-services httpsset security zones security-zone management host-inbound-traffic system-services pingset security zones security-zone management host-inbound-traffic system-services snmpset security zones security-zone management host-inbound-traffic system-services tracerouteset security zones security-zone management interfaces reth0.50

Configure the Internet Edge security zone.the majority of the networks are contained in the internet_edge zone. We use a feature called address-book to map

our networks in this zone to user-friendly names for easier management. that should be easier to understand when

we configure our policies that just use subnet designations. We also need to allow OspF in this zone, because we will

communicate routing information with the eX series switch in this zone.

root@srx650-1b# set security zones security-zone internet_edge address-book address data_wired_1b 10.10.8.0/22set security zones security-zone internet_edge address-book address data_wired_1a 10.10.12.0/22set security zones security-zone internet_edge address-book address voip_wired_1b 10.10.20.0/22set security zones security-zone internet_edge address-book address voip_wired_1a 10.10.24.0/22set security zones security-zone internet_edge address-book address data_wireless_1b 10.10.32.0/22set security zones security-zone internet_edge address-book address data_wireless_1a 10.10.36.0/22set security zones security-zone internet_edge address-book address voip_wireless_1b 10.10.40.0/23set security zones security-zone internet_edge address-book address voip_wireless_1a 10.10.42.0/23set security zones security-zone internet_edge address-book address server_1b 10.10.46.0/24set security zones security-zone internet_edge address-book address server_2b 10.10.48.0/24set security zones security-zone internet_edge host-inbound-traffic system-services pingset security zones security-zone internet_edge host-inbound-traffic system-services tracerouteset security zones security-zone internet_edge host-inbound-traffic protocols ospfset security zones security-zone internet_edge interfaces reth0.44



Configuring Security Policies.Configure guest user policy.

root@srx650-1# set security policies from-zone guest to-zone untrust policy allow-guest-to-internet match source-address guest_wirelessset security policies from-zone guest to-zone untrust policy allow-guest-to-internet match destination-address anyset security policies from-zone guest to-zone untrust policy allow-guest-to-internet match application anyset security policies from-zone guest to-zone untrust policy allow-guest-to-internet then permit

Configure Internet Edge Security Policy.

root@srx650-1b# set security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address data_wired_1aset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address data_wired_1bset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address voip_wired_1aset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address voip_wired_1bset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address data_wireless_1aset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address data_wireless_1bset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address voip_wireless_1aset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address voip_wireless_1bset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address server_1bset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match source-address server_2bset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match destination-address anyset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet match application anyset security policies from-zone internet_edge to-zone untrust policy allow-internet_edge-to-internet then permit

Configuring Routing and OSPF.Configure Routes.

root@srx650-1b# set routing-options static route 0.0.0.0/0 qualified-next-hop 10.94.44.5 preference 20set routing-options static route 0.0.0.0/0 qualified-next-hop 10.94.44.1 preference 10

Configure OSPF.

root@srx650-1b# set protocols ospf area 0.0.0.0 interface reth0.44


root@srx650-1b# commit

You can see the internal networks advertised by OspF by using the show route command.



{primary:node0}root@srx650-1> show routeinet.0: 32 destinations, 35 routes (32 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[Static/10] 6w1d 23:50:07 > to 10.94.44.1 via ge-2/0/1.0 [Static/20] 00:03:53 > to 10.94.44.5 via ge-11/0/2.010.10.8.0/22 *[OSPF/10] 1w2d 20:45:10, metric 2 > to 10.10.44.1 via reth0.4410.10.12.0/22 *[OSPF/10] 1d 04:12:46, metric 3 > to 10.10.44.1 via reth0.4410.10.20.0/22 *[OSPF/10] 1w2d 20:45:10, metric 2 > to 10.10.44.1 via reth0.4410.10.24.0/22 *[OSPF/10] 1d 04:12:46, metric 3 > to 10.10.44.1 via reth0.44…

For readability the remainder of the show route output not shown.

Verifying internal reachability.use the ping command to verify basic reachability to the internal gateway and external interface.

Configuring NATConfigure the Guest NAT policy.

root@srx650-1b# set security nat source rule-set Guest-to-untrust from zone guestset security nat source rule-set Guest-to-untrust to zone untrustset security nat source rule-set Guest-to-untrust rule Guest-source-nat match source-address 0.0.0.0/0set security nat source rule-set Guest-to-untrust rule Guest-source-nat then source-nat interface

Configure the Internet Edge NAT policy.

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

Configuring DHCP services for guest VLANsTo configure DHCP services for guest VLANS:

root@srx650-1b# set system services dhcp pool 10.10.60.0/24 address-range low 10.10.60.11set system services dhcp pool 10.10.60.0/24 address-range high 10.10.60.250set system services dhcp pool 10.10.60.0/24 domain-name xyzcompany.comset system services dhcp pool 10.10.60.0/24 name-server 208.67.222.222set system services dhcp pool 10.10.60.0/24 name-server 208.67.220.220set system services dhcp pool 10.10.60.0/24 router 10.10.60.254


Commit

xyzcompany.com



Verifying NATYou are now configured to be able to access the Internet from your internal user networks. When connecting to the

Internet from inside, the network traffic will be Nat’ed. to view the network sessions and verify that Nat is taking place

properly issue the command show security flow session nat (to see all flows, remove the keyword nat).

the following example shows Nat performed for a session. source address 10.10.10.52 is translated to an external

address of 10.94.191.233 and the destination address is 173.194.79.104.

root@srx> show security flow session natnode0:--------------------------------------------------------------------------Session ID: 15945, Policy name: allow-Internet_Edge-to-internet/5, State:Active, Timeout: 1798, ValidIn: 10.10.10.52/3296 --> 173.194.79.104/80;tcp, If: reth0.22, Pkts: 0, Bytes:0Out: 173.194.79.104/80 --> 10.94.191.233/60064;tcp, If: ge-2/0/1.0, Pkts:36, Bytes: 37380Total sessions: 1

Configuring general settings.set the date and time in the format: YYYYmmDDhhmm.ss

root@srx650-1> set date 201201220830.00Enter configuration modeConfigure the time zone.root@srx650-1# set system time-zone America/Los_Angeles

Configure DNS.

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


root@srx650-1# set system services web-management https system-generated-certificateset system services sshdelete system services telnetdelete system services web-management http

Configure LLDP.

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


root@srx650-1# commit

this completes the srX configuration.

YYYYMMDDhhmm.ss

xyzcompany.com



WLA

WLA

WLA

WLA

WLA

WLA

WLA


EX4200VC-2a

EX3300VC-1a

EX4200VC-3a

LAGLAG

LAGEX8200VC-1b

SRX SeriesCluster

WLCCluster

INTERNET

EX6200-1b

App Servers


EX4500VC-1a LAG

LAG

You are Done!

Figure 23: Configuration Complete

SummaryYou now have a base Vertical Campus network infrastructure providing most commonly used enterprise network

technologies: redundant ethernet, WlaN, and firewall services. the deployment incorporates a simple and scalable

network architecture that provides a reliable foundation on which to base a customized network for your business. the

Juniper Virtual Chassis technology makes it easy to manage because there are few logical devices and protocols to

configure. the modular approach allows you to expand and adapt the network without requiring extensive changes or

forklift upgrades. the infrastructure also supports additional technologies, such as video, collaboration, and other real-

time traffic demands.



Appendix A: Virtual Chassis Virtual Chassis for fixed configuration EX series switchesthe Virtual Chassis flexible scaling solution allows users to connect two or more individual switches together to form

one unit that is managed as a single chassis. Virtual Chassis is supported on the Juniper Networks eX3300, eX4200,

eX4500, and eX8200 series ethernet switches. In this section, however, we discuss only the eX3300, eX4500 and

eX4200 switches.

eX4200 and eX4500 series switches can be interconnected into a Virtual Chassis using the dedicated Virtual Chassis

ports (VCps) on the rear panel of the eX4200 switches, and the dedicated VCps on the Virtual Chassis modules in

the eX4500 switches. You can easily expand the Virtual Chassis configuration to include more member switches.

additional switches are added to an eX4200 or eX4500 Virtual Chassis by cabling together the dedicated VCps.

You can also expand a Virtual Chassis configuration beyond a single wiring closet. Interconnect switches located in

multiple wiring closets or in multiple data center racks by installing sFp, sFp+, or XFp uplink modules, the connect the

uplink module ports on eX4200 member switches or connect the 10-Gigabit ethernet sFp+ network interfaces on the

eX4500 member switches.

Types of Virtual ChassisWe assume that you are configuring at least two or more eX series switches as a single Virtual Chassis. If you are

configuring a standalone eX series switch, then you can perform the basic setup as listed in the Quick start guide that

comes with the switch. after setup, go to the section “Global setup for eX series switches.”

• Dedicated mode

• extended mode

• mixed mode

Dedicated Modethe dedicated mode is the most common method of connecting adjacent eX4500 or eX4200 series switches into a

single Virtual Chassis. Dedicated mode involves interconnecting the switches using the special Virtual Chassis ports

(VCps) at the back of the switch. the two commonly-used methods of cabling when connecting eX series switches

together are: daisy chained and braided ring.

NOTE: although Juniper Networks recommends using one of these two switch topologies; other topologies are

supported (but that is beyond the scope of this document.)

Extended Modethe extended Virtual Chassis method enables switches to be part of a single Virtual Chassis even when the switches

are far apart. You can use the optional uplink modules on the eX4200 switch to connect multiple switches, using

1-Gigabit ethernet and 10-Gigabit ethernet links to provide great flexibility in how a network is configured.

For example, you could have multiple wiring closets on a single floor managed as a single device. this simplifies many

operational tasks, because this reduces the number of individual devices that must be managed.

the eX3300 only uses 10Gbe ports to create a Virtual Chassis, so it is an extended type of Virtual Chassis by default

when compared to the eX4200/eX4500 series products. However, the eX3300 does not require purchase of uplink

modules, instead it has four fixed 10Gbe ports and two of these are already configured to support Virtual Chassis.

eX3300s are typically connected together using DaC cables because of their low cost as a short distance network

medium.

Mixed Modethe mixed -mode Virtual Chassis enables you to interconnect more than one type of switch to act as a single Virtual

Chassis. this is currently only supported between the eX4500 and eX4200 series switches, and provides the ability

to have high-density 10-Gigabit ethernet and 1-Gigabit ethernet in the same Virtual Chassis. this topic provides

configuration examples for each of these Virtual Chassis types.

Virtual Chassis tips for Fixed Configuration eX series switches:

• When you have a two-member Virtual Chassis, we recommend that you disable split detection.

• When you have three or more members in a Virtual Chassis, we recommend that you do not place uplinks on the master

routing engine.

Pre-provisioning of the Virtual ChassisIt is often desirable to deterministically control the role and member ID assigned to each member switch in a Virtual

Chassis. this is accomplished by creating a pre-provisioned configuration. switches can be pre-provisioned by using

the auto provisioning feature to automatically configure the uplink ports as VCps on the switches to be added.



although it is not mandatory to pre-provision each Virtual Chassis, we recommend it, and this is the process we use in

this guide.

NOTE: If you do not pre-provision the Virtual Chassis, the devices are numbered in the order in which they come up. For

example, if you have five switches in a Virtual Chassis and you turn on the middle switch, say #3, this will be member/

card 0, then you turn on the top switch next, and that will be member/slot 1 and you turn on the other switches at

about the same time the rest of the cards will be randomly filled so you may end up with chassis numbering something

like this.

member 1

member 4

member 0

member 3

member 2

although this is confusing, it is completely operational. You can re-assign slots later to make a more logical chassis, but

it is easier to avoid this in the first place.

prerequisites: the switches need to be set at factory defaults to follow this process.

To pre-provision the Virtual Chassis:1. understand what type of Virtual Chassis you will be setting up: Dedicated, extended or mixed. If you are unsure, see

“types Of Virtual Chassis”.

2. unpack and power up the switch you intend to be member 0. Go through the initial setup process for the switch.

3. Identify the serial numbers of the other switches that will be part of this Virtual Chassis. then decide what their function

will be—either routing engine or line card. You can only have two switches configured as routing engines and one will

be member 0 (the first device we booted up). You can change the roles for devices later if required.

the following is a sample set of configuration statements for a four-member Virtual Chassis, specifying each

member role and slot by serial number.

root@EX4500VC-1a# set virtual-chassis preprovisionedset virtual-chassis member 0 role routing-engineset virtual-chassis member 0 serial-number GX0211411253set virtual-chassis member 1 role routing-engineset virtual-chassis member 1 serial-number GX0211411250set virtual-chassis member 2 role line-cardset virtual-chassis member 2 serial-number FP0211333181set virtual-chassis member 3 role line-cardset virtual-chassis member 3 serial-number FP0211333260

4. Determine if you need to disable split detection.

• If your Virtual Chassis has only two members go to step 5: Disable split detection.

• If your Virtual Chassis has more than two members, go to step 6, step 7, or step 8, as appropriate for the type of

Virtual Chassis you want to set up (dedicated mode, extended mode, or mixed mode).

5. Disable split detection if desired or needed.

NOTE: Virtual Chassis split Detection

split detection is designed to avoid possible dual active-or split-brain conditions. this happens when the chassis

loses multiple Virtual Chassis connections and becomes partitioned into two separate Virtual Chassis. the default

behavior is for the primary routing engine to disable itself and the backup routing engine (re) to promote itself to

master.

In a two-switch Virtual Chassis this is not desirable. For example, if the backup re is powered off, the master re

will stop forwarding traffic. therefore we recommend disabling this feature in a two-switch configuration. For more

information, read about Virtual Chassis in the Junos Os documentation for Juniper Networks eX series ethernet

switches.

the below command disables split detection:

root@EX4500VC-1a# set virtual-chassis no-split-detection



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.


Preprovisioned Virtual ChassisVirtual Chassis ID: 804d.1d7f.fd6aVirtual Chassis Mode: Mixed Mstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt GX0212140825 ex4500-40f 129 Backup Y 1 vcp-1 2 vcp-01 (FPC 1) Prsnt GX0212140845 ex4500-40f 129 Master* Y 3 vcp-1 0 vcp-02 (FPC 2) Prsnt FP0211490796 ex4200-48px 0 Linecard Y 3 vcp-0 0 vcp-13 (FPC 3) Prsnt FP0211490618 ex4200-48px 0 Linecard Y 1 vcp-0 2 vcp-1

• proceed to “Virtual Chassis Base Configuration”

7. set up an extended mode Virtual Chassis.

some Virtual Chassis members are connected together using 1-Gigabit ethernet or 10-Gigabit ethernet ports

configured as Virtual Chassis extended (VCe) ports.

NOTE: 10-Gigabit ethernet uplink ports must be configured as VCe ports. the following is an operational mode

command that will not appear in the configuration. Once this is set, the option to configure these ports when in

configuration mode will not appear.

root@EX4500VC-1a> request virtual-chassis vc-port set pic-slot pic-slot port port member-id memberid.

8. set up a mixed mode Virtual Chassis. (eX4500 and eX4200 combined chassis)

• When setting up a combined eX4500 and eX4200 chassis, the chassis must be specifically configured to support

mixed mode operation. If not, the entire chassis will be active. the command to change modes is an operational

command and therefore does not show up in the configuration. request virtual-chassis mode mixed

• to verify that the chassis is indeed in mixed mode, you can view the status by issuing the operational command

show virtual-chassis and look for line Virtual Chassis mode:

root@EX4500VC-1a> show virtual-chassisPreprovisioned Virtual ChassisVirtual Chassis ID: 762b.b071.4181Virtual Chassis Mode: Mixed

• You can now cable up the remaining members using the VCp ports on the back of the units and power them up.

Verify that all of the members are active by running the show virtual-chassis command.

804d.1d7f.fd




Preprovisioned Virtual ChassisVirtual Chassis ID: 804d.1d7f.fd6aVirtual Chassis Mode: Mixed Mstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt GX0212140825 ex4500-40f 129 Backup Y 1 vcp-1 2 vcp-01 (FPC 1) Prsnt GX0212140845 ex4500-40f 129 Master* Y 3 vcp-1 0 vcp-02 (FPC 2) Prsnt FP0211490796 ex4200-48px 0 Linecard Y 3 vcp-0 0 vcp-13 (FPC 3) Prsnt FP0211490618 ex4200-48px 0 Linecard Y 1 vcp-0 2 vcp-1 3

To change a Virtual Chassis back to non-mixed mode issue the following command.

request virtual-chassis mode mixed disable

Proceed to “Virtual Chassis Base Configuration”

Virtual Chassis Base Configurationenter the following commands for all Virtual Chassis:

Commit Synchronizethis ensures that whenever you issue a commit command, it is synchronized with all of the other members of the

Virtual Chassis. Without this command in the configuration, you should issue a commit synchronize command after

every change instead of just the commit command.

set system commit synchronize

Non-stop Bridgingthis command replicates bridging protocol information between master and backup routing engines.

set ethernet-switching-options nonstop-bridging

Graceful SwitchoverGraceful switchover should be configured on any multichassis Virtual Chassis to ensure that the master and backup

routing engines are in sync.

set chassis redundancy graceful-switchover

Layer 3 base configuration itemsConfigure the Default Static Route

root@host# set routing-options static route 0.0.0.0/0 next-hop <IP address>

Configure nonstop active routing

root@host# set routing-options nonstop-routing

804d.1d7f.fd



Appendix B: Configuring DHCP on EX Series Ethernet SwitchesIf you do not have a central DHCp server or need a temporary DHCp solution, you can configure the eX series ethernet

switches to act as a DHCp server.

NOTE: the srX series firewalls are configured to provide DHCp information to guest wireless users in the tested

Network.

In the tested network design presented in this document, the core switches would be used as DHCp servers because it

has Ip addresses on each of the subnets in the network.

to enable the eX series to act as a DHCp server you need the following:

• Ip interface configured on each VlaN to receive DHCp

• Ip address pool and pool range to be allocated to users on each VlaN to receive DHCp

• Default gateway for users on each VlaN

• Domain name for users

• Name server for users

the sample that follows shows DHCp configured for the management VlaN presented in this guide. We already have

the Ip address configured as 10.10.28.1 for this VlaN.

set system services dhcp pool 10.10.28.0/24set system services dhcp pool 10.10.28.0/24 address-range low 10.10.28.11 high 10.10.28.250set system services dhcp pool 10.10.28.0/24 router 10.10.28.1set system services dhcp pool 10.10.28.0/24 domain-name xyzcompany.comset system services dhcp pool 10.10.28.0/24 name-server 10.10.24.100

To view DHCP statistics

show system services dhcp statistics

To view DHCP bindings

show system services dhcp binding

xyzcompany.com



Appendix C: EX8200 Virtual Chassis Overviewthe eX8200 Virtual Chassis is similar to the extended Virtual Chassis. this section details the connections and

processes required to set up the eX8200 Virtual Chassis for Building B. For more information, see Best Practice Guidelines for Deploying EX8200 Virtual Chassis Configurations.

Virtual Chassis technology was first introduced on the Juniper Networks eX4200 line of ethernet switches. Virtual

Chassis technology allows up to 10 interconnected eX4200 switches to operate as a single, unified, high bandwidth

device. these interconnections can be made using any combination of dedicated high-speed Virtual Chassis ports

(VCps) on the switch’s rear panel or front panel gigabit ethernet (Gbe) or 10Gbe fiber links.

eX8200 Virtual Chassis technology was first introduced with the Juniper Networks Junos® operating system 10.4

release, enabling up to two eX8200 chassis to be interconnected as a single logical device – with the ability to expand

to four.

the eX8200 Virtual Chassis architecture consists of redundant external routing engines – the Xre200 external

routing engine – capable of managing up to four eX8200 line Card Chassis (lCCs) connected using 1Gbe or 10Gbe

VCps and operating as a single chassis. unlike other virtual system technologies, eX8200 Virtual Chassis technology

separates the controller of the virtual system from the chassis routing engine. the Xre200s connect to the eX8200

chassis via the 1Gbe out-of-band

management ports on the routing engine modules are installed in the modular switch, forming a single Virtual Chassis

configuration as shown in Figure 24. these interconnections, known as dedicated VCp links, constitute the control

plane connection and do not carry data traffic.

Intra-XRE Connection for HA (1GbE)

XRE-LCC — Active XRE to Internal Routing Engine Connection (1GbE)

XRE-LCC — Standby XRE to Internal Routing Engine Connection (1GbE)

Intra-VC — 10GbE LAG Connection

ActiveXRE200

StandbyXRE200


LAG

Figure 24: EX8200 Virtual Chassis with XRE200 Connected to Each Member

Figure 24 shows a fully meshed two-member Virtual Chassis configuration with two Xre200s and a single 10Gbe link

aggregation Group (laG) between lCCs. In an eX8200 Virtual Chassis configuration, each eX8200 chassis becomes

an lCC and are interconnected through eX8200-8Xs line cards using either a 10Gbe link or a laG bundle with up

to twelve 10Gbe line-rate links. this connectivity serves two functions: to allow data traffic between lCCs for single

homed access devices, and to pass control traffic between the eX8200 chassis in case of the failure of all dedicated

VCp links. the eX8200-8Xs line cards use small form-factor pluggable transceivers (sFp+) that can support

connections up to 40 km in distance. eX8200-based Virtual Chassis configurations can span a large metropolitan area.

If the Virtual Chassis members are located in the same or adjacent racks, low-cost direct attach cables (DaCs) can be

used as the interconnect mechanism. members of an eX8200 Virtual Chassis configuration can include a mix of the

Juniper Networks eX8208 ethernet switch (eight-slot) and eX8216 ethernet switch (16-slot).

EX8200 Virtual Chassis Portsa Virtual Chassis port (VCp) is any port that is capable of sending and receiving Virtual Chassis Control protocol traffic

to create, monitor, and maintain the Virtual Chassis configuration. there are three types of VCps on the eX8200—Inter-

Xre200, Xre-lCC, and intra-Virtual Chassis. the Inter-Xre200 and Xre-lCC are called “dedicated” VCps as they carry

control traffic, while intra-Virtual Chassis ports carry data traffic between lCCs. In some cases, intra-Virtual Chassis

ports may carry data as well as control traffic.





Virtual Chassis Ports on the XRE200 External Routing Engineall Gbe ports on the Xre200 Virtual Chassis Control Interface (VCCI) modules are VCps. any of the VCps can be used

to connect eX8200 switches to the Xre200 to form a Virtual Chassis configuration and also to connect Xre200s

together to provide redundancy within the Virtual Chassis configuration. any link connecting an Xre200 to an eX8200

switch or to another Xre200 is a VCp link. No user configuration is required to configure these VCp links. all VCp links

on the Xre200 only carry Virtual Chassis Control protocol traffic.

Virtual Chassis Ports on EX8200 Member Chassisan eX8200 switch in standalone mode has no VCps. When a standalone eX8200 switch is enabled to function as a

Virtual Chassis switch, the management ports on the switch’s routing engines are converted into dedicated Xre-lCC

Virtual Chassis ports that carry the Virtual Chassis Control protocol traffic over the Xre-lCC VCp links. No further

configuration is required to configure these VCp links.

lastly, the intra-Virtual Chassis ports, which can only reside on the eX8200 switches, can only be configured on the

10Gbe eX8200-8Xs line cards. VCps on the 10Gbe eX8200-8Xs line card are enabled in pairs, i.e., ports that reside

on the same packet Forwarding engine (pFe). the eX8200-8Xs line card offers eight ports—0 through 7—with two

contiguous ports residing on the same pFe. If port 0 is enabled as a VCp, Junos Os will automatically enable port 1 as a

VCp. Intra-Virtual Chassis links between member switches in Virtual Chassis configuration are automatically configured

to form a single laG; no further user configuration is required. It is possible to configure up to 12 ethernet ports as VCps

to form a laG between member switches in a Virtual Chassis configuration.

For highest availability it is recommended to have a two-member laG at a minimum. However, a four-member laG

with two pairs of port members residing on different line cards is preferred.

table 16 provides a summary of differences between the eX8200VC and the eX4500/eX4200 Virtual Chassis

implementation.

Table 16: EX4200/4500 and EX8200 Side by Side Comparison

Category EX4200 Virtual Chassis EX8200 Virtual Chassis

Native Virtual Chassis support Inherent support for Virtual Chassis by the Forwarding engine.

Virtual Chassis emulated using Xre200.

Virtual Chassis ports Fixed Virtual Chassis ports. any 10Gbe port on 8Xs line card can be aVirtual Chassis port.

Virtual Chassis mastership any member is eligible to be a master or backup. routing engine has an election mechanism to choose master and backup.

Body Column

Virtual Chassis management all members are managed from the master member

all members are managed from master Xre200.

link aggregation Group laG load balancing is hash based. laG load balancing is chassis-local.

Virtual Chassis path calculation every pFe is a node in the Virtual Chassis topology.

every chassis is a node in the Virtual Chassis topology.

table 17 shows the chassis member numbering by device role.

Table 17: EX8200 Virtual Chassis Member IDs and Roles

Device Role Member IDS

eX8208 or eX8216 switch line card 0-7

Xre200 master or backup routing engine 8-9

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



Table 18: EX8200VC FPC and Interface Numbering

Member ID FPC Numbering Network Port Interface Range

0 0 through 15 for eX8216 0 through 7 for eX8208

xe-0/0/0 to xe-15/0/7 xe-0/0/0 to xe-7/0/7


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

http://search.yahoo.com/r/_ylt=A0oGdVVqQfZQ4AEASJhXNyoA;_ylu=X3oDMTE1MHZpaWVmBHNlYwNzcgRwb3MDMQRjb2xvA3NrMQR2dGlkA01TWTAwOV8xMTY-/SIG=12v80t3ho/EXP=1358344682/**http%3a/www.juniper.net/us/en/local/pdf/implementation-guides/8010081-en.pdf

http://search.yahoo.com/r/_ylt=A0oGdVVqQfZQ4AEASJhXNyoA;_ylu=X3oDMTE1MHZpaWVmBHNlYwNzcgRwb3MDMQRjb2xvA3NrMQR2dGlkA01TWTAwOV8xMTY-/SIG=12v80t3ho/EXP=1358344682/**http%3a/www.juniper.net/us/en/local/pdf/implementation-guides/8010081-en.pdf




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

http://www.juniper.net/customers/support/

http://www.juniper.net/us/en/community/junos/training-certification/day-one/

http://www.juniper.net/us/en/training/jnbooks/



About Juniper NetworksJuniper Networks is in the business of network innovation. From devices to data centers, from consumers to cloud

providers, Juniper Networks delivers the software, silicon and systems that transform the experience and economics

of networking. the company serves customers and partners worldwide. additional information can be found at

www.juniper.net.




8010091-003-eN may 2013

Copyright 2013 Juniper Networks, Inc. all rights reserved. Juniper Networks, the Juniper Networks logo, Junos, Netscreen, and screenOs are registered trademarks of Juniper Networks, Inc. in the united states and other countries. all other trademarks, service marks, registered marks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

APAC and EMEA Headquarters

Juniper Networks International B.V.

Boeing avenue 240

1119 pZ schiphol-rijk

amsterdam, the Netherlands

phone: 31.0.207.125.700

Fax: 31.0.207.125.701

Corporate and Sales Headquarters

Juniper Networks, Inc.

1194 North mathilda avenue

sunnyvale, Ca 94089 usa

phone: 888.JUNIPER (888.586.4737)

or 408.745.2000

Fax: 408.745.2100

www.juniper.net

to purchase Juniper Networks solutions,

please contact your Juniper Networks

representative at 1-866-298-6428 or

authorized reseller.

printed on recycled paper

888.JUNIPER


Date post:	27-Aug-2019
Category:	Documents
Upload:	hatu
View:	217 times
Download:	0 times

Vertical Campus - Juniper Networks · the Juniper Networks Vertical Campus tested design is based...

Documents