Allied Telesis Software Reference for SwitchBlade x3100 Series

Transcription

Software Reference for SwitchBlade x3100 Series
Switches
Release 17.0 Issue 2
This product includes software developed by Bill Paul.
This product includes software developed by Yen Yen Lim and North Dakota State University.
This product includes software developed by the Internet Initiative Japan, Inc.
This product includes cryptographic software written by Eric Young ([email protected]).
This product includes software developed by the University of California, Berkeley and its contributors.
MD5 functions derived from the RSA Data Security, Inc. MD5 Message-Digest Algorithm.
Copyright 1988, 1989, 1990 by Carnegie Mellon University.
Copyright 1989 by TGV, Incorporated.
Copyright © 2013 Allied Telesis, Inc.
All rights reserved. No part of this publication may be reproduced without prior written permission from Allied Telesis,
Inc.
Allied Telesis and the Allied Telesis logo are trademarks of Allied Telesis, Incorporated. All other product names, company
names, logos or other designations mentioned herein are trademarks or registered trademarks of their respective owners.
Allied Telesis, Inc. reserves the right to make changes in specifications and other information contained in this document
without prior written notice. The information provided herein is subject to change without notice. In no event shall Allied
Telesis, Inc. be liable for any incidental, special, indirect, or consequential damages whatsoever, including but not limited to
lost profits, arising out of or related to this manual or the information contained herein, even if Allied Telesis, Inc. has been
advised of, known, or should have known, the possibility of such damages.
Software Reference for SwitchBlade x3100 Series Switches
2
Introduction
Congratulations on your purchase of a Allied Telesis™ SwitchBlade® x3100 series product. This product is part of a family
of products that leverages Ethernet switching technology to offer service providers a range of services, such as video over
xDSL and voice over IP.
Who Should Read This Guide?
This document provides a reference for the components that comprise the SBx3100 products.
Service and Support
For information about support services for Allied Telesis, contact your Allied Telesis sales representative or visit the
website at http://www.alliedtelesis.com.
3
Table of Contents
Preface - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -14
I Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 14
II Intended audience - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 14
III Reason for Update (Issue 1) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 14
IV Conventions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 15
1 Setting Up the Switch - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -17
1.1 Allied Telesis SBx3100 Products in the Network - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 18
1.1.1 Overview - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 18
1.2 Chassis Configuration - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 20
1.2.1 Card Configurations - SBx3112- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 20
1.2.2 Card Configurations - SBx3106- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 22
1.2.3 Card Representation in Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 22
1.3 Getting Started - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 23
1.3.1 How to Log In - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 23
1.3.2 Initial System Status - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 23
1.3.3 Check Software Load - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 25
1.3.4 How to Get Command Help - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 25
1.4 CLI Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 27
1.4.1 Command Syntax Conventions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 27
1.4.2 Entering Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 27
1.4.3 Control of CLI command confirmation - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 27
1.4.4 Multiple Command Stringing- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 28
1.4.5 Command Alias - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 28
1.4.6 Configuring an Alias - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 29
1.4.7 Alias Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 32
1.5 User Administration - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 38
1.5.1 Users and Privileges - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 38
1.5.2 Customizing the CLI Prompt - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 38
1.5.3 Provisioning the Login Banner- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 40
1.5.4 Password Recovery - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 41
1.5.5 User Administration Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 45
1.6 Configuring Physical Interfaces and Protocols - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 76
1.6.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 76
1.6.2 Initial Interfaces - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 76
1.6.3 Physical Interface Configuration - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 76
1.6.4 Configuring the Management Interfaces - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 77
1.6.5 IP Interface Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 79
1.6.6 System Time - SNTP- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 92
1.6.7 Configuring SNTP - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 93
1.6.8 SNTP Commands- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 97
1.7 File Management - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 109
1.7.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 109
4
1.7.2
1.7.3
1.7.4
1.7.5
Load File Names - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - File Storage - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - CFC Media (SD Card)- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - File Management Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
109
109
110
116
1.8 Software Load Management - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.8.1 Card Load Preferences - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.8.2 Load File Verification - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.8.3 Boot Server (Control Module Only) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.8.4 Commands for Software Load Management - - - - - - - - - - - - - - - - - - - - - - - - - -
139
139
139
139
141
1.9 Database and Text File Management - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.9.1 Database Management - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.9.2 Text File Configuration - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.9.3 Creating a Text Configuration file - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.9.4 Database Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.9.5 Commands for Text File Configuration - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
144
144
147
147
151
156
1.10 Control Module Management - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.10.1 Card Load Preferences - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.10.2 CFC for the SBx3112 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.10.3 Overview (Simplex versus Duplex) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.10.4 CFC200 Card Attributes and States (SHOW CARD ACTCFC) - - - - - - - - - - - 1.10.5 Changing the Administrative State of the Inactive CFC - - - - - - - - - - - - - - - - - 1.10.6 Redundant CFC Operation in the SBx3112 - - - - - - - - - - - - - - - - - - - - - - - - - 1.10.7 Provisioning Scenarios for Control Modules - - - - - - - - - - - - - - - - - - - - - - - - 1.10.8 Software Compatibility - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.10.9 Software Upgrade- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
161
161
161
161
162
164
164
165
166
167
1.11 Log Management - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.11.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.11.2 Viewing Logs - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.11.3 Controlling Output of Logs - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.11.4 Example Log Configuration Setup - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.11.5 Capturing and Sending Logs to a Storage Device - - - - - - - - - - - - - - - - - - - - - 1.11.6 Logging Procedures- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.11.7 Logging Commands- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
174
174
176
176
176
177
178
179
1.12 LED Management - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.12.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.12.2 CFC200 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.12.3 PSU - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.12.4 XE4 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.12.5 GE24POE - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.12.6 GE24SFP - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.12.7 LED Behavior- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
199
199
199
199
199
199
200
200
1.13 ECOMODE and Lamp Test - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.13.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.13.2 ECO Functions and Lamp Test - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.13.3 ECOMODE Commands- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
204
204
204
205
1.14 Alarm Management Overview - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.14.1 Overview - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.14.2 Displaying alarms - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.14.3 Alarms Associated with the SBx3112 Architecture - - - - - - - - - - - - - - - - - - - - 1.14.4 Fan Module Alarms - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
208
208
208
209
211
5
1.14.5 ALARM Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 212
1.15 Power Management and System Cooling - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.15.1 Power Management - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.15.2 Power Supply Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.15.3 System Cooling - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.15.4 System Cooling Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
219
219
223
226
229
1.16 Basic Provisioning of Cards and Ports - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.16.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.16.2 Feature List - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.16.3 Feature / Component Interaction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.16.4 Provisioning Modes - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.16.5 Custom Profiles - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
234
234
234
234
235
236
1.17 Configuring a User Profile - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.17.1 Default Configuration - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.17.2 Configuration Guidelines - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.17.3 Configuration Procedure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.17.4 AlliedView NMS Profile Support - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.17.5 Administrative and Operational States - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.17.6 Common Line Card Attributes - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.17.7 XE4 Card Attributes - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1.17.8 Card Management Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
237
237
237
237
240
241
242
244
245
2 Interface Management - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -266
2.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 266
2.2 Interface Types - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 266
2.2.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 266
2.3 GE Interfaces - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 267
2.3.1 Overview - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 267
2.3.2 Example GE Interface (GE24POE) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 270
2.4 XE Interfaces - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2.4.1 Overview - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2.4.2 Example Output- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2.4.3 Interface (Common) Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
273
273
273
275
3 Power over Ethernet (PoE) - - - - - - - - - - - - - - - - - - - - - - - - - - -292
3.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 292
3.1.1 Definitions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 292
3.2 GE24POE Card Operation - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 3.2.1 Performance and Capacity - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 3.2.2 Hardware Limitations - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 3.2.3 Hardware Detection- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 3.2.4 Power Allocation - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 3.2.5 CFC Power Management - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 3.2.6 Card Power Management - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 3.2.7 LEDs - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
293
293
293
293
293
294
295
295
3.3 Configuring the GE24POE Card - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 295
3.3.1 Default Configuration - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 295
6
3.3.2 Configuration Guidelines - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 295
3.3.3 PoE Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 298
4 Layer Two Switching - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -307
4.1 Switching - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.1.1 Overview - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.1.2 Ingress Rules - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.1.3 Learning Process - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.1.4 Forwarding Process - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.1.5 Egress Rules - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.1.6 MAC Thrash Limiting (SBx3112) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.1.7 Clearing the Forwarding Database (FDB) - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.1.8 Viewing Switch Settings - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.1.9 Configuring the Forwarding Database - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.1.10 Switching Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
308
308
308
308
309
309
309
310
310
311
315
4.2 Link Aggregation (LAG) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.2.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.2.2 Feature Overview - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.2.3 Static versus Dynamic Link Aggregation - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.2.4 Overview of LAG Commands/States - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.2.5 Alarms for LAG States - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.2.6 Setting the Switch Hash Select - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.2.7 Configuring LAG - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.2.8 Configuration Procedure - Destroying a LAG - - - - - - - - - - - - - - - - - - - - - - - - 4.2.9 LAG Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
329
329
329
330
331
333
334
335
341
342
4.3 VLAN (802.3) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.3.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.3.2 Virtual LANs (VLANs) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.3.3 Configuring Standard VLANs - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.3.4 VLAN Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
361
361
361
363
367
4.4 Spanning Tree Introduction: STP, RSTP, MSTP and BPDU Cop - - - - - - - - - - - - - - - - - 4.4.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.4.2 Overview of Spanning Trees- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.4.3 Spanning Tree Protocol (STP and RSTP)- - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.4.4 Example (R)STP Configuration - Standard VLAN - - - - - - - - - - - - - - - - - - - - - - 4.4.5 Configuring (R)STP - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.4.6 Default STP Configuration (Customer and Network Ports) - - - - - - - - - - - - - - - 4.4.7 Configuration Procedure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.4.8 Multiple Spanning Tree Protocol (MSTP) - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.4.9 Configuring MSTP - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.4.10 BPDU COP - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.4.11 Configuring BPDU Cop - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.4.12 Spanning Tree Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
377
377
377
377
385
385
385
386
388
394
397
398
402
4.5 Ethernet Protection Switched Ring (EPSR) and SuperLoop Prevention - - - - - - - - - - - - 4.5.1 EPSR Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.5.2 Overview of EPSR Configuration- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.5.3 EPSR Terms and Definitions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.5.4 EPSR Protocol - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.5.5 Dual Ring Configuration - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
419
419
419
420
421
424
7
4.5.6 Enhanced Recovery (Multiple Link Failure) - - - - - - - - - - - - - - - - - - - - - - - - - - 4.5.7 Log Output for EPSR - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.5.8 Configuring EPSR - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.5.9 EPSR Interoperability - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.5.10 Configuration Procedure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.5.11 SuperLoop Prevention - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.5.12 SuperLoop Configuration Requirements - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.5.13 Configuring SuperLoop - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.5.14 Configuration Procedure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.5.15 EPSR and (R)STP Interaction- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.5.16 EPSR and SuperLoop Commands- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
426
427
429
429
430
434
437
438
439
445
448
4.6 Upstream Forwarding Only (UFO) Mode - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.6.1 Overview - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.6.2 Forwarding Mode and Determining Upstream Nodes and Interfaces - - - - - - - - - 4.6.3 UFO Example Configuration (Static) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.6.4 STP Configuration with UFO VLAN - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.6.5 MSTP Configuration with UFO VLAN - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.6.6 EPSR Configuration with UFO VLAN- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.6.7 Configuring UFO VLANs - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.6.8 Default Configuration - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.6.9 Configuration Guidelines - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
464
464
465
465
466
468
469
470
470
470
4.7 Upstream Control Protocol (UCP) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.7.1 Overview of UCP- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.7.2 UCP Protocol Configuration Overview - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.7.3 UCP with STP - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.7.4 UCP with EPSR/RSTP - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.7.5 Configuring UCP with ESPR - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.7.6 Summary of Topology Configurations for UCP - - - - - - - - - - - - - - - - - - - - - - - 4.7.7 UCP Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
471
471
471
474
474
476
478
478
4.8 HVLAN (Port Based and VLAN Based) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.8.1 Port Based HVLAN - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.8.2 Port Based HVLAN Configuration- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.8.3 Configuring Port Based HVLAN - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.8.4 VLAN Based HVLAN - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.8.5 Configuring VLAN Based HVLAN - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.8.6 Configuration Procedure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.8.7 HVLAN Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
480
480
480
481
485
487
488
490
4.9 VLAN Translation - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.9.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.9.2 Example Configuration - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.9.3 TPID Translations (Extreme VLAN Support)- - - - - - - - - - - - - - - - - - - - - - - - - 4.9.4 HVLAN and Translation Feature Interactions - - - - - - - - - - - - - - - - - - - - - - - - 4.9.5 Configuring VLAN Translation - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.9.6 VLAN Translation Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
500
500
500
502
502
503
505
5 IGMP and MLD Snooping - - - - - - - - - - - - - - - - - - - - - - - - - - - -506
5.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 506
5.1.1 Mulitcast Overview - Bandwidth Efficiency - - - - - - - - - - - - - - - - - - - - - - - - - - - 506
5.1.2 IP Mulitcast Addressing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 506
8
5.1.3 IP Multicast Routing and Switching- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 507
5.1.4 IP Multicast Group Joining and Leaving - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 507
5.1.5 IGMP and MLD Protocols - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 507
5.2 IGMP and MLD Snooping - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.2.1 Known versus Unknown Multicast - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.2.2 Multicast Router Ports (Dynamic versus Static) - - - - - - - - - - - - - - - - - - - - - - - 5.2.3 Interface Snooping Modes - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.2.4 Snooping Optimizations- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
509
509
509
510
511
5.3 IGMP and MLD Support on the SBx3100 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.3.1 Protocol Versions Supported - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.3.2 Hardware Support - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.3.3 Configuration Support- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
513
513
513
513
5.4 IGMP and MLD Snooping Configuration Guidelines - - - - - - - - - - - - - - - - - - - - - - - - - - 515
5.4.1 Enabling IGMP and MLD Snooping (per-VLAN/Interface)- - - - - - - - - - - - - - - - - - 515
5.4.2 Unknown Multicast Flooding - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 515
5.5 Feature Interactions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.5.1 Upstream Forwarding Only VLANs - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.5.2 IPv6 Neighbor Discovery - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.5.3 Link Aggregation - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.5.4 Hierarchical VLANs - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.5.5 IGMP Snooping Disabled - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.5.6 IGMP Snooping Enabled- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.5.7 IGMP Snooping at the System and Interface Level - - - - - - - - - - - - - - - - - - - - - 5.5.8 Summary of Feature Interaction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
518
518
518
519
519
519
519
520
520
5.6 Channel Usage for IGMP - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 522
5.6.1 Reserved - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 522
5.6.2 User provisioned MCAST addresses - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 522
5.7 Configuring IGMP - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.7.1 Default Configuration - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.7.2 Configuration Example - IGMP - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.7.3 Configuration Guidelines - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.7.4 Restrictions and Limitations - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.7.5 Configuration Procedure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.7.6 Configuration Example - MLD - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.7.7 IGMP Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
522
522
523
523
524
524
527
528
6 Access and Security - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -563
6.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 563
6.2 Quality of Service Model - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.2.1 Ingress Traffic Concepts - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.2.2 Egress Traffic Concepts - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.2.3 Traffic Management Throughout the Network- - - - - - - - - - - - - - - - - - - - - - - - -
564
565
566
567
6.3 Classifiers - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.3.1 Classifier Support on the SBx3100- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.3.2 Classifier Management- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.3.3 Configuring Classifiers- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.3.4 Classifier Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
568
568
570
581
583
6.4 Access Control List - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 600
9
6.4.1
6.4.2
6.4.3
6.4.4
Provisioning Overview - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ACL for the SBx3100 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Configuring ACL - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Access Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
600
600
601
604
6.5 Ingress Metering (Policing) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 618
6.5.1 Configuring the Ingress Metering- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 618
6.5.2 Ingress Metering Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 620
6.6 Egress Port Rate Limiting - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 627
6.6.1 Configuring the Egress Port Rate Limiting - - - - - - - - - - - - - - - - - - - - - - - - - - - - 627
6.6.2 Egress Port Rate Limiting Commands- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 628
6.7 Priority Queuing (Layer 2) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.7.1 Overview - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.7.2 Changing Queue Mapping and Disabling/Enabling Interfaces - - - - - - - - - - - - - - - 6.7.3 Configuring Queue Mapping - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
635
635
636
636
6.8 Queue-Based Egress Rate Limiting (QOSPOLICY) - - - - - - - - - - - - - - - - - - - - - - - - - - 6.8.1 Commands and Parameters - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.8.2 QoS Model with QOSPOLICY Parameters - - - - - - - - - - - - - - - - - - - - - - - - - - 6.8.3 QOSPOLICY Command Sequence - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.8.4 Rounding of Values - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.8.5 Configuring QOSPOLICY Attributes - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.8.6 QOSPOLICY Command List - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
638
638
639
639
640
641
642
6.9 Layer 3 QoS Support (DSCP) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.9.1 Built-in DSCP Mapping - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.9.2 Feature Interaction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.9.3 Restrictions for Layer 3 QoS for DSCP - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.9.4 Configuring L3 QoS Support - DSCP - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.9.5 QoS Command List - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
652
652
654
654
654
657
6.10 RADIUS / TACACS Authentication - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.10.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.10.2 Configuring a RADIUS Server - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.10.3 Configuring a TACACS+ Server - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.10.4 RADIUS and TACACS+ Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
670
670
670
672
675
6.11 Port Authentication - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.11.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.11.2 802.1X Authentication- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.11.3 MAC Authentication - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.11.4 RADIUS Configuration - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.11.5 VLAN Configuration (Dynamic and Guest VLAN) - - - - - - - - - - - - - - - - - - - - 6.11.6 Configuring Port Authentication - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.11.7 Port Authentication Commands - 802.1X - - - - - - - - - - - - - - - - - - - - - - - - - - 6.11.8 MAC Authentication Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.11.9 Common Authentication Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
694
694
694
695
695
695
696
705
722
742
6.12 SSH - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.12.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.12.2 Configuring SSH - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.12.3 SSH Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
760
760
761
765
6.13 Address Resolution Protocol (ARP) Filtering - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 777
6.13.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 777
6.13.2 Associated Logs - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 778
10
6.13.3 Configuring ARP- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 778
6.13.4 ARP Filter Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 780
6.14 Local ARP Discard - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.14.1 Local ARP Overview - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.14.2 Local ARP Configuration Requirements - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.14.3 Local ARP Configuration Procedures (Static versus Dynamic)- - - - - - - - - - - - - 6.14.4 Configuring Local ARP Discard - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6.14.5 Local ARP Discard Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
786
786
786
787
788
791
7 Network Management - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -801
7.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 801
7.2 Dynamic Host Configuration Protocol (DHCP) - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.2.1 DHCP Architecture - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.2.2 DHCP Relay Agent - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.2.3 DHCP Relay Mode - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.2.4 DHCP Relay Snooping Mode - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.2.5 Auto-Ageing and IP Filter Removal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.2.6 DHCP Relay TR-101 Support - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.2.7 Configuring DHCP Relay - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.2.8 Default Configuration - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.2.9 Restrictions and Limitations - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.2.10 Feature Interactions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.2.11 Configuration Procedure - Relay - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.2.12 Configuration Procedure - Snooping - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.2.13 DHCP Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
802
802
803
806
807
809
810
810
810
811
811
811
816
820
7.3 Simple Network Management Protocol (SNMP) - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.3.1 Introduction to SNMP Support - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.3.2 SNMP Community - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.3.3 Configuring an SNMP Community - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.3.4 Default Configuration - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.3.5 Restrictions and Limitations - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.3.6 Configuration Procedure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.3.7 SNMP Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
845
845
845
847
848
848
848
850
7.4 Link Layer Discovery Protocol (LLDP) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.4.1 Introduction (LLDP) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.4.2 Configuring LLDP - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.4.3 LLDP-MED - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.4.4 Configuring LLDP-MED - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.4.5 LLDP Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
866
866
871
873
875
880
7.5 Remote Network Monitoring (RMON) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.5.1 RMON Configuration - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.5.2 RMON Statistics Collection - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.5.3 Management Logs for RMON (Ethernet-Based) Thresholds - - - - - - - - - - - - - - - 7.5.4 RMON History Collection - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.5.5 Configuring RMON - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.5.6 Configuring RMON Ethernet Statistics - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.5.7 RMON Ethernet Statistics Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.5.8 Configuring RMON History - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.5.9 RMON History Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
926
926
927
928
928
929
930
931
942
944
11
7.6 IP Statistics - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.6.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.6.2 Access of MIB Statistics Using an SNMP Browser- - - - - - - - - - - - - - - - - - - - - - 7.6.3 IP Statistics Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
949
949
949
950
7.7 Bi-Directional Forward Detection (BFD) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.7.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.7.2 BFD Protocol - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.7.3 BFD Alarms - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.7.4 Possible Fault Scenarios - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.7.5 Configuring BFD - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7.7.6 BFD Commands- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
954
954
954
954
955
957
959
8 Alarms and Troubleshooting - - - - - - - - - - - - - - - - - - - - - - - - - -967
8.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 967
8.2 Alarm System Features - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 8.2.1 Overview of Alarm System - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 8.2.2 Alarm Types - Interface, Card, and System - - - - - - - - - - - - - - - - - - - - - - - - - - 8.2.3 Interface/Port Outage Threshold Feature - - - - - - - - - - - - - - - - - - - - - - - - - - - 8.2.4 Configurable Alarm Severity (Interface Alarm)- - - - - - - - - - - - - - - - - - - - - - - - 8.2.5 Interface Uptime (SHOW INTERFACE) - - - - - - - - - - - - - - - - - - - - - - - - - - - - 8.2.6 Alarm Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
968
968
969
970
970
971
973
8.3 Troubleshooting the SBx3112 (Diagnostics) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 8.3.1 Troubleshooting Overview - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 8.3.2 Card Diagnostics - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 8.3.3 Interface Diagnostics- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 8.3.4 Diagnostics Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
981
981
981
981
982
8.4 Maintenance Audits - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 987
8.5 TRACEROUTE - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 988
8.5.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 988
8.5.2 TRACEROUTE Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 989
8.6 IGMP Trace - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 991
8.6.1 IGMP Counters - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 991
8.7 EPSR Trace - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 992
8.7.1 ESPR TRACE Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 994
8.8 User Event Logging - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 8.8.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 8.8.2 Overview of Setup - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 8.8.3 Event Logging TRACE Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
998
998
998
999
8.9 Technical Support Scripts - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1007
8.9.1 Tech Support Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1008
8.10 Optical Device Data Access- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1010
8.10.1 Optics Data Commands and Output - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1010
8.10.2 SFP/XFP Alarms and Warnings - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1011
8.10.3 Optics Data Output Examples - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1011
8.10.4 Debug Interface - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1012
8.11 Viewing the CPUSTATS (High Water Mark) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1012
8.11.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1012
12
8.11.2 CPUSTATS Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1013
8.12 Port Mirroring - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1017
8.12.1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1017
8.12.3 Port Mirroring Commands - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1018
8.13 Routine Procedures - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1023
8.13.1 Database Management - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1023
8.13.2 Delete Obsolete Users - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1024
8.13.3 Delete Obsolete Files - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1024
8.13.4 Scripting - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1024
Appendix A: Command List - - - - - - - - - - - - - - - - - - - - - - - - - - -1026
13
Preface
I Introduction
The Allied Telesis SwitchBlade x3100 leverages widely accepted Ethernet switching technology to allow the network operator to provide Ethernet-based services. It is a feature-rich platform that enables network operators to offer advanced, simultaneous services, such as high quality voice, tiered IP/Ethernet data services, and broadcast quality IP video.
I.I Purpose of this manual
This document is for those who have purchased and successfully installed this product. Refer to the SBx3100 Installation
Guides for instructions on installing the products and turning them on for the first time.
The outline of this document is first to allow the system administrator to configure the SBx3100 so that it is integrated into
the management interfaces of the network. It then goes through the layer 2 and other features of the product.
Each section generally includes the following:
• Introduction for main concepts
• Configuring the Feature, which can include:
• Default Configuration
• Configuration Guidelines
• Restrictions and Limitations
• Feature Interactions
• Configuration Procedure
• Command Reference
II Intended audience
This manual is intended for the system administrator, network manager or communications technician who will configure
and maintain SBx3100 devices, or who manages a network that includes SBx3100 devices.
It is assumed that the user is familiar with:
• The topology of the network in which the SBx3112 is to be used
• Basic principles of computer networking, protocols and routing, and interfaces
• Administration and operation of a computer network.
III Reason for Update (Issue 1)
The following table lists changes for this release.
14
TABLE i-1
Reason for Update for Release 17.0 - SBx3112
Feature
16.x Functionality
17.0 Functionality
Notes
SBx3106 system
Not Supported
The SBx3106 is a smaller version of
SBx3112 system, This system has the
same features/card support as the
SBx3112 but has a smaller footprint
(4RU). The system supports 4 line card
slots and has two CFC slots, so it can
operate in simplex or duplex. In simplex
mode slot 5 can be used for a line card.
Refer to
Card Configurations SBx3106.
GE40RJ
Not Supported
The GE40RJ (AT-SBx31GT40) provides
40 RJ (copper) ports at 10/100/1000
speed.
Refer to
SBx3100
Cards.
32K FDB MAC
support
The system could support an FDB of
32K MAC entries, but only if all of
the line cards supported 32K (the
GE24POE and GE24RJ cards support
16K).
The user can configure the desired FDB
size (16 or 32K). When confiured for
32K, a card that does not support 32K is
not allowed to become operational.
Refer to
SET
SWITCH
FDBSIZE
UFO VLAN support for LAG Interfaces
Not Supported
The SBX3100 supports Upstream Forwading Only (UFO) VLANs.
Refer to
4.2.7.3.
IGMP and MLD
Snooping
IGMP was supported
There are no CLI changes, only that the
user can set the VLAN to UFO.
Both IGMP and Multicast Listener Discovery (MLD) protocols are supported
(MLD is the IPv6 equivalent of IGMP.)
To enable MLD snooping, use the
"ENABLE MLDSNOOPING VLAN"
command. MLD snooping may be
enabled per-VLAN (but not per-interface as with IGMP). By default, MLD
snooping is disabled for all VLANs.
Filter IPv6 packets
Not Supported
Classifier matches any ICMPv6 protocol
packet or with the specified type (MLD
query, version 1 MLD done, version 1
and version 2 MLD reports, redirect
messages, and user defined ICMPv6
types.)
Refer to
IGMP and
MLD Support on the
SBx3100.
Refer to
Table 6-1
and
Table 6-2
Classifier matches on IPv6 source and
destination addresses (ipv6address/
length)
Provide predefined types for IPv6 destinations: IPv6 multicast, IPv6 permanent
multicast, and IPv6 transient multicast.
IV Conventions
15
IV.I Commands
Commands are usually presented in the following ways:
• Tables for specific functions or features that include important parameters
• Specific commands that are part of examples
The Allied Telesis Series product supports line editing, line recall, and abbreviations, so that command line input and editing
can be done very quickly once command syntax and the line editing commands are learned. Throughout this document all
syntax will use complete words, with verbs and parameters in upper case and the pairing of parameters and values with equal
(=)
There are three levels that can be entered:
• User
• Manager
• Security Officer
Note:
All of the commands used when explaining features in this document assume the Security Officer privilege.
The Allied Telesis Series product supports line editing, line recall, and abbreviations, so that command line input and editing
can be done very quickly once command syntax and the line editing commands are learned. These are described.
Note:
Throughout this document all syntax will use complete words, with verbs and parameters in upper case and the
pairing of parameters and values with equal (=) signs.
IV.II Graphical User Interface (GUI)
Since all operations on the SBx3100 products use the CLI, there are no GUIs presented in this document.
IV.III Syntax
The syntax rules for a command and its parameters use the following conventions throughout this document:
•
•
•
•
All upper case = Key Word
| = Option (OR)
[ ] = Optional
{ = Choice of one value }
16
1. Setting Up the Switch
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Allied Telesis SBx3100 Products in the Network
Chassis Configuration
Getting Started
CLI Introduction
Alias Commands
User Administration
User Administration Commands
Configuring Physical Interfaces and Protocols
IP Interface Commands
File Management
File Management Commands
Software Load Management
Database and Text File Management
Database Commands
Commands for Text File Configuration
Control Module Management
Provisioning Scenarios for Control Modules
Log Management
Logging Commands
LED Management
ECOMODE and Lamp Test
ECOMODE Commands
Alarm Management Overview
ALARM Commands
Power Management and System Cooling
Power Supply Commands
System Cooling Commands
Basic Provisioning of Cards and Ports
Card Management Commands
17
Setting Up the Switch
1.1 Allied Telesis SBx3100 Products in the Network
1.1.1 Overview
The SwitchBlade x3100 product is designed to deliver high availability, maximum performance with wirespeed non-blocking
backplane performance, and high port count. It is a a versatile carrier class FTTx platform for delivering Gigabit services to
residential, Multi-Dwelling Unit (MDU) and business customers in the last mile. The product features redundant power supplies, controllers and WAN ports to ensure reliability standards in carrier networks are met, along with powerful sub-50 millisecond failover protection using EPSR ring for link level protection.
The SBx3112 is a 12-slot access edge chassis switch primarily targeted for service provider fiber access networks. The
SBx3106 is a smaller, 4RU version of the SBx3112 chassis with front loadable cards, power supplies and a fan tray. In addition
to duplicating the feature capabilities of the larger chassis, the SBx3106 enables the use of a CFC200 with a line card in the
mate CFC slot.
The SwitchBlade x3100 series products provide:
• Up to 240 non-blocking PoE Plus Ports
• Up to 240 non-blocking 1Gbps Fiber Ports
• Up to 40 10 Gigabit Ethernet Ports
The following figure shows how Allied Telesis SBx3100 products can be configured within a network to provide a complete
service provider solution.
18
PSTN
Management
Internet
Application
Services
Interworking
IPTV head-end
IP TV services
Service / Application
Layer
SBx900
SBx900
Central Office
Data Center
SBx908
9810
Network (Layer 3)
10G Ring
EPSR Topology
(Note 1)
9700
Note 1 - In future releases, the 9810
will aggregate subtending access islands
SBx3112
SBx3112
Access Layer (Layer 2)
SBx3100
SBx3100
Subtended
GE Ring #1
1
Subtended
GE Ring #8
Distribution Layer
1
1G
Up to 8 nodes each GE ring
1G
EPON
1G
P2P
ADSL
Apartment
= Copper (telephone)
1G
= Copper (RJ45)
= Fiber (100 Mbps, 1G, and 10G)
FIGURE 1-1
High-density
MDU
Business(es)
Allied Telesis Products in the Network
19
1.2 Chassis Configuration
1.2.1 Card Configurations - SBx3112
The following figure shows the card layout of the SBx3112. Labels are explained in Table 1-1.
P
O
E
P
O
E
AC
DC
4
6
8
10
12
14
DC
FAULT
SBxPWRSYS
SBxPWRSYS
plus
2
S
Y
S
T
E
M
AC
E
FAULT
16
18
plus
SBx31GP24
20
0
22
0
23
1
2
4
6
8
10
12
14
16
18
SBx31FAN12
20
22
1
A
1
3
5
7
9
11
13
15
17
19
21
2
4
6
8
10
12
14
16
18
20
0
1
3
5
SBx31CFC
MASTER
SL AVE
NORMAL
FAULT
NORMAL
FAULT
FAN
M/S
PSU
RESET
B
11
FAN
13
15
1000 LINK
17
19
23
1
7
MASTER
SL AVE
NORMAL
FAULT
10/100/1000Base-T
RS-232
NORMAL
FAULT
FAN
FAULT
12
11
13
RESET
2
3
4
5 CFC
6
7
PSU
8
9
FAN
10
11
M/S
REA DY
14
16
15
10G LINK /
18
17
19
22
21
2
3
XFP
XFP
XFP
XFP
24
23
25
19
21
26
28
30
32
34
36
POWER
27
29
31
33
35
3
37
AC T
AC T
CONSOLE
10/100/1000Base-T
RS-232
5
L/A
B USY
FAULT
PORT ACTIVITY
10G LINK /
1
17
ACT
20
10/100 LINK
AC T
0
15
NET MGMT
SBx31XZ4
PORT ACTIVITY
13
1000 LINK
SD
SBx31XZ4
11
SBx S TATUS
1
0
SYS S TA TUS
PSU
10
9
SBx31CFC
M/S
CONSOLE
9
39
5
L/A
B USY
8
6
3
AC T
NET MGMT
7
38
21
AC T
10/100 LINK
SD
REA DY
9
SBx S TATUS
1
0
1
0
3
2
3
2
5 CFC
4
4
5 CFC
7
6
7
6
9
8
9
8
11
10
11
10
SYS S TA TUS
SYS S TA TUS
M/S
PSU
7
0
5
1000 LINK
SBx31GC40
22
C
23
3
plus
SBx31GP24
A
6
S
Y
S
T
E
M
SBxPWRPOE
SBx31GP24
4
DC
FAULT
SBxPWRPOE
2
AC
DC
D
FAULT
0
AC
A
AC T
0
1
2
3
XFP
XFP
XFP
XFP
7
8
SBx31GS24
1000 LINK
2
4
6
8
ACT
10
10/100 LINK
12
ACT
14
16
18
SBx31GS24
20
0
22
0
23
1
2
4
6
8
10
12
14
16
18
20
22
9
1
10
SBx31GT24
3
5
7
9
11
13
15
17
19
21
2
4
6
8
10
12
14
16
18
20
0
23
3
SBx31GT24
22
0
23
1
2
5
7
4
6
9
8
11
10
13
12
15
14
17
19
16
18
21
20
22
11
1
3
5
7
9
11
13
15
17
19
21
23
3
5
7
9
11
13
15
17
19
21
ESD
F
FIGURE 1-2
2035
SBx3112 Chassis
20
TABLE 1-1
Allied Telesis SBx3100 - Slot/Position and Configuration Notes
No.
Module
Slot/Position
Configuration Notes
A
Line Cards
0, 2, 6, 8, 10 (left)
At least one is always configured. Unused slots must be configured with a Filler Card.
1, 3, 7, 9,11 (right)
The cards available are:
- SBx31GP24 (GE24POE) - Power source for Power over
Ethernet (PoE) ports.
- SBx31XZ4 (XE4) - Provides four 10G SFP ports.
- SBx31GS24 (GE24SFP) - Provides 24 1G SFP ports.
- SBx31GT24 (GE24RJ) - Provides 24 RJ ports.
- SBx31GC40 (GE40CSFP) - Provides 40 1G Compact SFP
ports, and can also support 20 regular 1G SFP ports.
- SBx31XS6 (XE6SFP) - Provides six 10 SFP+ ports.
- SBx31GT40 (GE40RJ) - Provides 40 RJ ports.
B
SBx31CFC -
4 (right)
When both slots are used, dual CFC200s provide redundancy.
Control Fabric
Card
5 (left)
Includes serial console and ethernet management ports, as
well as an SD card slot and USB interface.
(CFC200)
Note:
When only one CFC200 is used, the other slot
must remain unused. This is not true for the
SBx3106, as decribed below.
C
AT-SBxFAN12
Fan Tray Slot
Fan Controller. Varies fan speed depending on temperature
thresholds.
D
AC POE PSU
(PSU)
Upper left of shelf
PSU Slots A and B
Allows up to two Power Supply Units (PSU) for Power over
Ethernet (PoE).
E
AC System PSU
Upper right of shelf
Allows up to two PSUs for 12V system power
E
DC System PSU
PSU slots C and D
Upper right of shelf
Allows up to two PSUs for 12V system power
PSU slots C and D
The DC PSU can be used in place of a SBx3100 system (12V)
PSU only. There is not a DC version of the POE PSU.
It is possible to power a chassis with a DC PSU and an AC
PSU, but this is not a recommended configuration. If both PSUs
are of the same type, load balancing is performed, but this is
not guaranteed when the PSU types are mixed. (One PSU can
supply enough power for the entire chassis.)
F
ESD
Bottom right of shelf
ESD wrist strap connection point.
21
1.2.2 Card Configurations - SBx3106
The SBx3106 is a 4RU chassis with the same features as the SBx3106. It contains the same card configuration as the SBx3112
except for the following:
• The SBx3106 Fan tray model number AT-SBxFAN06.
• An optional fifth line card can be used in the CFC slot 5.
The SBx3106 must be configured with the Release 17.x software, but a CFC200 running an earlier release will sucessfully initialize in the shelf, allowing you to install a SBx3106 using an existing CFC200, or to order a CFC200 without requiring the
card to have a Release 17.0 load. The system should then be upgraded to Release 17.x.
The CFC slot 5 can alternatively be used as a line card slot. Line card slots typically provide 20G of backplane data plane traffic capacity to the simplex CFC200, but when slot 5 is used as a line card slot, it provides up to 40G of backplane data plane
traffic capacity to the simplex CFC200.
P
O
E
P
O
E
AC
DC
AC
AC
DC
DC
FAULT
FAULT
2
4
6
8
10
12
14
16
18
20
S
Y
S
T
E
M
AC
DC
FAULT
plus
SBx31GP24
0
S
Y
S
T
E
M
FAULT
plus
SBx31GP24
2
4
6
8
10
12
14
16
18
20
0
22
0
22
1
23
1
23
SBxFAN06
POWER
3
5
7
9
11
13
15
17
19
21
SBx31GP24
2
4
6
8
10
12
14
16
18
20
0
2
1
3
5
SBx31CFC
4
PSU
FAN
MASTER
SL AVE
NORMAL
FAULT
NORMAL
FAULT
7
9
SBx S TATUS
0
1
SYS S TA TUS
M/S
3
plus
RESET
2
3
4
5 CFC
M/S
6
7
PSU
8
9
FAN
10
11
SD
11
13
15
1000 LINK
AC T
10/100 LINK
AC T
NET MGMT
CONSOLE
10/100/1000Base-T
RS-232
17
19
0
23
1
9
11
13
8
6
10
12
14
16
18
15
17
19
21
ACT
20
22
24
26
28
30
32
34
B USY
SBx31GT24
7
2
9
4
11
13
6
15
17
8
19
10
21
23
12
25
14
27
29
16
31
33
18
35
37
20
0
22
L/A
FAULT
FIGURE 1-3
Note:
3
39
5
1
REA DY
36
38
3
21
7
1000 LINK
SBx31GC40
22
5
1
23
3
5
7
9
11
13
15
17
19
5
ESD
21
SBx3106 Chassis (Line Card in CFC Slot 5)
Throughout this document, when references are made to the SBx3112, the SBx3106 will apply as well, except
where noted.
1.2.3 Card Representation in Commands
For all of the cards except the power and cooling cards (refer to 1.15.1), a card is referenced by its slot number (such as
CARD=4). For CARD there is also ACTCFC and INACTCFC. Refer to SHOW CARD.
Note:
For the SBx3106, slot numbers go up to 5.
22
1.3 Getting Started
1.3.1 How to Log In
The default user id / password for the systems are as follows:
• officer/officer or manager/friend
If the default user “officer” or “manager” has its password set to the default value (officer or friend), the following login message is displayed:
*************************************************************************
* Warning: The password for the user 'officer' is the system default.
*
The password should be changed to avoid a security risk.
* Warning: The password for the user 'manager' is the system default.
*
*************************************************************************
If you set the password to something besides the default password, the message is not displayed. However, if the password is
set back to the default, the message is displayed again.
1.3.2 Initial System Status
If service modules and one control module (dual CFC200 or single CFC200 with a filler plate) are installed, the system is
auto-provisioned and ready to pass customer traffic in the default configuration mode.
To see how the system is initially configured, input the SHOW SYSTEM command from the CLI. The system response below
shows a sample of what is displayed for the SHOW SYSTEM command and its initial state. (Descriptions of the CARD and
PSU parameters are in later sections.)
oE135 - manager SEC>> show system
--- System Information -------------------------------------------------------System Date...................
System Uptime.................
Software
Version.....................
Options.....................
Created.....................
Booted From.................
Resource Information
SDRAM (free/total)..........
Flash (free/total)..........
Identifying Information
Shelf Serial Number.........
Shelf CLEI Code.............
Shelf MAC...................
Hostname....................
Contact.....................
Location....................
Name........................
Services....................
Description.................
2010-07-31 17:37:38
1 days, 14 hours, 27 minutes, 48 seconds
14.2.0.GAMMA.20100721
Customer-Release Build
Wed 07/21/2010 at 10:30 AM
preferred
377546 KB / 524288 KB
41896 KB / 129024 KB
8
<unknown>
00:0C:25:04:00:0E
<none>
<none>
<none>
<none>
Layer 2 - Datalink/Subnetwork
Allied Telesis Switchblade x3112 - 12 Slot
High Availability Chassis
Number of MACs on card........ 2
Feature Keying
Customer ID................. <none>
Lock ID..................... icgb-cddf-alnk-kgdf-chkp-eocb-mebg-ighk
MGMT
IP Address.................. <none>
Subnet Mask................. <none>
Gateway..................... <none>
MAC Address................. 00:0C:25:04:00:0E
Domain Name................. <none>
DNS......................... <none>
Shelf Power Input............. AC
Provisioning Mode............. Auto Provisioning
ECO Mode...................... OFF
--- Card Information ---
23
Slot
----0
1
2
3
Prov
Type
------GE24POE
Physical Type
-------------GE24POE
4
5
6
7
CFC200
XE4
CFC200
XE4
8
9
10
XE4
XE4
11
GE24SFP GE24SFP
Model
--------ATSBx24POE
AT-SBxMFC
ATSBx31XZ4
ATSBx04XP
ATSBx31GS24
Serial Number
------------------6
CLEI Code
----------
HW
Rev
--X2
FPGA
Rev
----
51
A042834101200007
-
X2
B
-
28
-
X3
-
A31GS24H100300027
-
X4
-
--- Power Supply Units --Slot
---A
B
C
Type
-----POE
POE
System
State
----UP-UP
UP-UP
UP-UP
Temp(C)
------31
31
43
Layer 2 Base System
------------------Ageing time...........................
Ageing time status....................
Learning status.......................
Age Only FDB clear....................
TABLE 1-2
300
Enabled
Enabled
Disabled
System Parameters for SHOW SYSTEM - SBx3112
Output
Description
System Date
The current time
System Uptime
Length of time since the last system reboot
Software Version
The version of the currently executing software
Software Options
Comments on load
Software Created
The date/time since the software was built.
Booted from
The designation (preferred, temporary, backup) of the image from which the system
booted.
SDRAM (free)
The amount of memory available for dynamic program execution
Flash (free/total).
The amount of Flash memory available for persistent storage of software loads, database images, and command scripts
Shelf Serial Number
Unique Number given to shelf
Shelf CLEI Code
CLEI Code (none)
Shelf MAC
MAC address for the shelf
Hostname
A name that is translated to an IP address using a DNS server.
Contact
Typed in contact name
Location
Typed in location.
Name
Typed in name for Allied Telesis SwitchBlade SBx3100 product.
Services
Service provided by the Allied Telesis SwitchBlade SBx3100 product
Description
Generic description of the product
Number of MACs
on card
Number of MAC addresses available for product identification
Customer ID
String to identify a customer for feature keying
24
TABLE 1-2
System Parameters for SHOW SYSTEM - SBx3112
Output
Description
Lock ID
Key used for feature keying.
MGMT IP Address
IP Address of Allied Telesis SwitchBlade SBx3100 product.
MGMT Subnet Mask
Subnet Address. By default this is 255.255.255.0
MGMT Gateway
The IP address of a gateway device, needed when connecting to an external network.
This will have a default.
MGMT Domainname
This is always set to a default.
MGMT DNS
This is always set to a default.
Shelf Power Input
Type of power supply (AC)
Provisioning Mode
The system provisioning mode
ECO Mode
If the Green mode for LEDs is on or off
1.3.3 Check Software Load
Although the service modules are shipped with release files already present in FLASH memory, the release file should be
compared with the latest software release files that are available
Once a software release file is downloaded onto a network server, the user can copy the file to the CFC flash file system,
load it into FLASH memory, make it the active load, and ensure that when the CFC200 reboots this latest load is always used.
The user can also ensure the service module loads are obtained from the control module.
Caution: Always check with the Allied Telesis web site to see which loads should be used so that a later load can be
downloaded if necessary. Failure to do this may result in the product not being able to provide all the functionality
listed for a release. If you have questions, contact your Allied Telesis representative.
Caution: If the user tries to load a software version for a card that is incompatible with the system, the card will not go into
service and an alarm/log will result.
Note:
Refer to Configuring Physical Interfaces and Protocols for information on setting up the MGMT Ethernet interface
or the inband Ethernet interface to transports management data packets.
1.3.4 How to Get Command Help
Online help is available for all SBx3100 commands. There are two types of online help:
1.
For command string help, type in the start of a command and enter a space and a “?” at the end of the line. The SBx3100
will display a list of possible parameters. After entering a parameter and a “?”, online help provides an explanation of the
parameter. Entering a “?” alone will display all of the verbs available.
2.
For complete online help, type HELP and the command. If the command is incomplete, there is an error message. Entering a space and a “?” will show the next valid parameter. When the command is complete, a complete description of the
command is displayed.
Following is an example of using HELP for a command.
>HELP SHOW SNMP
ATI 200G Central Fabric Controller Help version 14.2.0 - English Version
SYNTAX:
SHOW SNMP
DESCRIPTION:
The SHOW SNMP command displays information about the device's SNMP
agent.
The following is example output from the SHOW SNMP command:
SNMP configuration:
25
--------------------------------Status .......................... Enabled
Authentication failure traps .... Enabled
Community ....................... public
Access ........................ read-only
Status ........................ Enabled
Traps ......................... Enabled
Open access ................... Yes
Community ....................... Administration
Access ........................ read-write
Status ........................ Disabled
Traps ......................... Disabled
Open access ................... No
SNMP counters:
------------------------------inPkts ........................
inBadVersions .................
inBadCommunityNames ...........
inBadCommunityUses ............
inASNParseErrs ................
inTooBigs .....................
inNoSuchNames .................
inBadValues ...................
inReadOnlys ...................
inGenErrs .....................
inTotalReqVars ................
inTotalSetVars ................
inGetRequests .................
inGetNexts ....................
inSetRequests .................
inGetResponses ................
inTraps .......................
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
outPkts ........................
outTooBigs .....................
outNoSuchNames .................
outBadValues ...................
outGenErrs .....................
outGetRequests .................
outGetNexts ....................
outSetRequests .................
outGetResponses ................
outTraps .......................
Parameter
Meaning
Status
The status of the SNMP agent or the specified
community (ENABLED or DISABLED)
Authentication
Failure Traps
Whether or not the SNMP agent generates a trap
on an authentication failure for an incoming
SNMP packet (ENABLED or DISABLED)
Community
The name of an SNMP community on the device.
Access
The access rights for the SNMP community
(READ-ONLY or READ-WRITE)
Status
The status of the community (ENABLED or
DISABLED)
PARAMETERS:
SNMP The SNMP parameter indicates the kind of SHOW operation performed.
SEE ALSO:
ADD SNMP COMMUNITY
CREATE SNMP COMMUNITY
DELETE SNMP COMMUNITY
(etc.)
26
1.4 CLI Introduction
1.4.1 Command Syntax Conventions
The syntax rules for a Command and its parameters use the following conventions throughout this document:
All upper case = Key Word
| = Option (OR)
[ ] = Optional
{ = Choice of one value }
1.4.2 Entering Commands
The SBx3100 supports line editing, line recall, and abbreviations, so that command line input and editing can be done very
quickly once command syntax and the line editing commands are learned.
Table 1-3 lists the terminal editing and keystroke functions most commonly used.
TABLE 1-3
Terminal Editing Functions and Keystrokes
Action
Key Sequence
Move cursor within command line
left and right arrow
Delete character to left of cursor
[Delete] or [Backspace]
Clear command line
[Ctrl/U]
Recall previous command in command history
CTRL/P or up arrow
Recall next command in command history
CTRL/N or down arrow
Automatically complete a partially entered command keyword
[Tab] or [Ctrl/I]
Commands can be entered in the following ways:
• Commands and parameters can be in lower case.
• Commands and parameters can be abbreviated (such as en for ENABLE, sh for SHOW, etc.)
• The equal sign (=) is not needed as long as a parameter is paired with a space and then a value.
Syntax in this document uses complete words with verbs and parameters in upper case and parameters paired with values
using an equal sign.
1.4.3 Control of CLI command confirmation
CLI commands that may result in destructive actions warn the user by responding to the input of such commands with a
prompt asking the user to confirm the requested action with a “YES or Y” or “NO or N”. The user must respond with either
a “YES or Y” or “NO or N”. The system will continue to prompt for this response until the user inputs a correct response.
This provides the system a certain level of protection from unwanted destructive events.
1.4.3.1 Disable/Enable Confirmation
CLI Confirmation can be disabled if required. Disabling is especially useful when executing command scripts on the system.
27
Use the DISABLE CONFIRMATION command to suppress user confirmation prompts for potentially dangerous commands.
This command is intended for expert users who understand the impact of the various operations on the device.
For example, to reboot an active CFC, the following would appear with confirmation prompts enabled:
officer SEC> restart card actcfc cold
Do you really want to restart card actcfc (Y/N)?
With confirmation disabled, the operation is performed without prompt or delay. When this command is used, the settings
only affect the current user session. No other user sessions are altered or changed by. When you log out, the confirmation
settings are automatically restored to enable confirmation prompts.
1.4.4 Multiple Command Stringing
Multiple commands can be strung together on the command line using the “;”. For example, the following commands can be
entered as illustrated and the responses will be returned in the order of command entry.
SHOW SESSION;SHOW USER;SHOW TRANSFER ALL
Example:
officer SEC>> SHOW SESSION;SHOW USER;SHOW TRANSFER ALL
--- Active (logged in) Users -------------------------------------------------ID User
Port
Location
Status Login Time
Deact
(secs)
-- -------------------- ------- ---------------- ------ --------------- -----0 officer
Console local
CONN
2004-06-17
11:18:54
--------------------------------------------------------------------------------- User Authentication Database ---------------------------------------------Username:
officer
Privilege..... SECURITY
OFFICER
Telnet User... Yes
Description:
Security Officer User
Status....... Enabled
Logins..... 2
Last Login... 2004-06-17
11:18:54
Fails...... 0
Lockouts... 0
------------------------------------------------------------------------------------------------------------------------------------------------------------No Transfer in progress
-------------------------------------------------------------------------------
1.4.5 Command Alias
Command alias functionality allows Allied Telesis Network Access product users to define shortcuts to command strings to
simplify the use of the CLI. It allows users to create shortcut strings which can be typed in place of commonly used (longer)
commands. With alias command strings, the user is able to quickly perform operations without having to type the full command line.
1.4.5.1 Creating a Simple Command Alias
CREATE ALIAS=ge1prof STRING=”SHOW PROFILE NAMES GE1”
When the user inputs this alias, the user will type at the prompt:
officer SEC>>ge1prof
However, the alias may NOT be part of a command. For instance:
CREATE ALIAS=ge1prof STRING=“PROFILE NAMES GE24POE”
is not acceptable. If the user attempts to input it as:
28
officer SEC>>SHOW ge1prof
the CLI responds with an error indicating that the command did not function correctly.
With this in mind, alias names must not exactly match any of the CLI command root keywords, such as ADD, DELETE, CREetc. The CREATE ALIAS command validates this and rejects any attempts to do so. This prevents the user
from creating an alias string that overrides an existing command.
ATE, SET, SHOW,
1.4.5.2 Creating a Command Alias that Takes Input Values
officer SEC>>CREATE ALIAS=makecard STRING=”CREATE CARD=$1 $2”
takes two input values. These values are typed in the order indicated by the $n part of the string, and separated by a
space. If the user types:
officer SEC>>makecard 1 GE24POE
a GE24POE card is created in slot 1, as if the user typed:
officer SEC>>CREATE CARD=1 GE24POE
• Alias command strings are made available to all users in the system. Since the alias command is mapped to actual CLI
commands, the substituted CLI command is verified to be valid for the privilege level of the user using the alias. For
instance, if there is an alias string “reboot” to substitute the command “RESTART CARD=ACTCFC CODE FORCE” (CREATE
ALIAS=reboot STRING=”restart card=actcfc force”) and a user with USER privileges attempts to use it, the response is an
error indicating that the command is not available for the current user privilege.
• Alias command strings persist over system reboots. Because of this, there are limits on the number of aliases stored and
the maximum size of the alias name and the substitution string. As mentioned earlier, a maximum of 200 alias commands
may be created and stored with the maximum name length being 40 characters and the maximum substitution string
being 256 characters.
• If there are existing alias commands that conflict with a new verb/action, by overriding it, that was introduced as a result
of system software upgrade, the alias will be automatically removed during the upgrade. For instance if there was an existing alias:
CREATE ALIAS=”clear” STRING=”PURGE USERS”
and the upgrade introduces a new command with the verb/action CLEAR, for example:
CLEAR DATABASE
then the “clear” alias would override the CLEAR verb/action, causing the command to be interpreted as “PURGE USERS
DATABASE”, which is invalid. Therefore, during the upgrade, checks are made for conflicts and any alias commands that
would result in a conflict are destroyed.
If an existing command that is referenced in an alias has changed syntax, thereby causing an invalid syntax, no correction
is taken. Once a user attempts to use the alias, an “Unable to Parse” error is displayed.
1.4.6 Configuring an Alias
This section describes configuration information, procedures, and commands for a Command Alias.
1.4.6.1 Default Configuration
Certain aliases will be created by the Allied Telesis Network Access product upon system start-up. These default aliases are
illustrated below (they are displayed using the SHOW ALIAS command):
>SHOW ALIAS
--- Alias Commands -----------------------------------------------------------Alias Name
----------------------showcfg................
showdebug..............
Substitution String
-----------------------------------------------------show config
showoamp
29
showdhcp...............
showepsr...............
showigmp...............
showint................
showlag................
showoamp...............
showrtp................
showstp................
showswitch.............
showsys................
showtraf...............
showuser...............
showvc.................
showvlan...............
$1;showint;showtraf;showigmp;showvlan;showlag;showswit
ch;showstp;showdhcp;showepsr;showrtp;showvc;showuser;s
howsys;showcfg
show dhcprelay
show epsr all;
show igmp;show igmpsnooping count
messageresponse;show igmpsnooping card all full;show
igmpsnooping interface all full
show interface all queuecount;show interface all
counter;show ip arp all;show ip connections;show ip
interface all;show ip interface all full;show ip
route all;
show lag all
show card $1 software;show card $1 ports;show card
actcfc cpu;show card inactcfc cpu;show card actcfc
memory heap;show card memory quickheap;show card
actcfc memory messagebuffers;show card inactcfc
memory messagebuffers;
show rtp interface all full;
show stp;show stp counter;
show switch;show switch fdb;show switch counter
show system;show system cooling;show fanmodule;show
sntp;show bootserver;show alarms all;show
contactalarm all severity all state all;
show classifier all full;show trafficdescriptor
all;show arpfilter;show qos;show accesslist all
show user;show telnet server;show sessions;show
system userconfig;show log filter;show log
output;show radius;show tacplus;show snmp;show snmp
community all;
show vc interface all full;
show vlan all full
-------------------------------------------------------------------------------
The default aliases are created dynamically when the system reboots and no other aliases have been created by the user. If,
for some reason, a default alias or aliases have been deleted, the user can recreate them all using the SETDEFAULTS ALIAS command.
1.4.6.2 Configuration Guidelines
• Command alias allows the user to create a shortcut to a command string, allowing input of the alias instead of the
extended command string. For example, suppose the user types the following, CREATE ALIAS=reboot
STRING=”RESTART CARD ACTCFC COLD”. From this point forward, the user would only be required to type
“reboot” at the CLI to reboot the active CFC.
• When the user inputs an alias that happens to fail for some reason, the failure will be displayed exactly as if the user
entered the full command string.
• The alias must encompass an entire command line. Alias strings cannot be used to substitute a portion of a command.
• The alias is not case-sensitive; similar to normal CLI commands.
• The system has an upper limit of 200, 255-character long alias entries.
• Alias commands persist between the ACTCFC and INACTCFC. Alias commands are available to all users and are pro•
•
•
•
tected by the user level settings.
Question mark (?), the CLI help symbol, is not available for aliases. For example, if a user created an alias called “mkcard”
that takes a parameter for card slot and card type, the following would not provide any useful information: Manager>>
mkcard ?.
If an alias was created using a command whose definition changed as the result of an upgrade or the alias is associated
with a command that no longer exists after the upgrade, the alias will remain after the upgrade, but will no longer work.
Auditing of the aliases over upgrades to ensure that they match any commands in the current command set is not supported.
An existing alias cannot be overwritten. To reuse an existing alias name, the user must first destroy and then create the
new definition of the alias using the DESTROY and CREATE commands.
An alias command name that is all or part of a command verb is not allowed. For example, the alias command could not
be “CREATE”, “CREAT”, “CRE”, “CR” or “C”, because it could potentially overwrite the command verb “CREATE”.
30
• All aliases are visible to all user privilege levels. Validation of the user privilege level (to execute a certain command), is
done when attempting to use the alias. If the user does not have the privilege level required for the command, command
execution will fail. This will be discussed in more detail later in this subsection.
• Alias names must be alphanumeric.
• Nesting of alias commands is not supported within commands with aliases.
• Alias command strings must substitute a CLI command string from the root of the command. For instance, the user may
set a command string “ge1prof” to be equivalent to “SHOW PROFILE NAMES GE1” (the entire command string) by creating the alias:
1.4.6.3 Configuration Procedure
The following procedure shows the commands used to create an Alias
TABLE 1-4
Step
Action or State
1
Create an alias
Configure a Command Alias
Details
CREATE ALIAS=dm STRING=”disable more”
CREATE ALIAS=shsys STRING=”show system”
2
Use an alias
dm
shsys
3
The output of the actual
string appears.
Show the alias string
SHOW ALIAS=dm
dm=”disable more”
4
Create an alias command with input variables
CREATE ALIAS=shcard STRING=”SHOW CARD=$1”
5
Use this alias to view the information about card 4
shcard 4
31
1.4.7 Alias Commands
This section describes the commands available for using the CLI (Alias)
TABLE 1-5
Alias Commands
Commands
CREATE ALIAS STRING
DESTROY ALIAS
RENAME ALIAS TO
SETDEFAULTS ALIAS
SHOW ALIAS
32
CREATE ALIAS STRING
Syntax
CREATE ALIAS=aliasname STRING=substitution
Description
Creates a command alias. The list of alias commands is available for all users in the system. Validation is
done on the alias name and its definition to ensure that the alias name has not already been created
and that the definition does not reference itself.
Mode
Manager
Options
Option
Description
Range
Default
Value
ALIAS
The name of the alias for the command string.
NA
NA
NA
NA
An alias name may not match all or part of existing CLI
command root keywords.
STRING
The alias name string specifies the case-insensitive literal
string which will be used in place of the CLI string provided in the STRING=substitution string parameter.
An alias string may consist of one or more valid CLI
commands or other previously defined alias commands,
separated by semicolons. The string may contain arguments, identified with a '$' and number, such as "$1 $2"
etc. These arguments indicate placeholders where
tokens will be substituted once the alias command is
executed.
The substitution string value may not be the same as
an existing CLI command ROOT keyword, such as
ADD, DELETE, SHOW, SET, etc. This command may be
executed by users with a MANAGER privilege
level or higher.
Release Note
NA
Example
CREATE ALIAS=su STRING="show user $1;show sys userconfig"
33
DESTROY ALIAS
Syntax
DESTROY ALIAS={ aliasname-list | ALL }
Description
Allows the user to remove an existing alias from the persisted list of alias commands.
Mode
Manager
Options
Option
Description
Range
Default
Value
ALIAS
NA
NA
Specifies the case-insensitive literal string which is to be
destroyed. This command may be executed by users
with a MANAGER privilege level or higher.
The value can be one alias, more then one alias separated by a comma, or ALL.
Release Note
NA
Note
NA
Example
DESTROY ALIAS=su,manage
34
RENAME ALIAS TO
Syntax
RENAME ALIAS=aliasname TO=aliasname
Description
Renames an existing alias. As with the original name, it must follow the same naming rules (An alias
name may not match all or part of existing CLI command root keywords, such as s, sh, sho, or show.).
Mode
Manager
Options
Release Note
Option
Description
Range
Default
Value
ALIAS
The name of the alias to be renamed
NA
NA
TO
The renamed alias. It must match the same naming rules
as the original one.
NA
NA
NA
Example
RENAME ALIAS=su TO=super
35
SETDEFAULTS ALIAS
Syntax
SETDEFAULTS ALIAS
Description
Resets alias defaults. Any aliases created by the user no longer exist and must be re-created, if needed.
The default alias commands consist of "showdebug" which references a set of other alias commands,
used to display all system information.
Mode
Manager
Options
NA
Release Note
NA
Example
SETDEFAULTS ALIAS
36
SHOW ALIAS
Syntax
SHOW ALIAS [ ={ aliasname-list | ALL } ]
Description
The SHOW ALIAS command allows the user to view a list of all alias commands and their corresponding substitution strings. If the user enters a name value, that alias information is displayed. The list of
alias commands is displayed in alphabetical order. This command may be executed by users with a
USER privilege level or higher.
Mode
Manager
Options
Option
Description
Range
Default
Value
ALIAS
NA
ALL
The value can be one alias, more then one alias separated by a comma, or ALL
Release Note
NA
Example
>SHOW ALIAS=showvc
--- Alias Commands --------------------------------Alias Name
Substitution String
----------------------- --------------------------showvc................. show vc interface all full;
37
1.5 User Administration
1.5.1 Users and Privileges
The SBx3100 supports three levels of security: User, Manager, and Security Officer. Each level provides a specific degree of
system access in a progressive fashion as shown in Figure 1-4.
User + Manager + Security Officer
Security Officer
User + Manager
Manager
User
Telesis_Product_Security_Levels
FIGURE 1-4
SBx3100 Security Levels
Each security level controls the commands that can be entered as follows:
• User - Users have the lowest level of access, which is equivalent to read-only privileges. They can change their password
and use any of the SHOW commands to display information. When logged in, the User receives the command-line prompt:
username USR >
• Manager - Managers have a higher priority than Users and can perform all actions that a User can perform. In addition to
User privileges, Managers can control various aspects of a User’s account (such as showing all active sessions or showing
statistics) and can configure most areas of the SBx3112. When logged in, the Manager receives the command-line prompt:
username MGR >
• Security Officer - Security Officers have the highest priority and can access the full set of commands. In addtion to
Manager privileges, Security Officers can add, remove, or modify other user accounts, as well as create, modify, and
destroy management features. When logged in, the Security Officer receives the command-line prompt:
username SEC >
Note:
Commands that are at the Security Officer level have the text “_SEC” added to the command in the command
reference.
For all security levels, a login name and password (case-sensitive) are required to access the system. There is a timer (default
of 300 seconds or 5 minutes) that will log off the session if no commands are entered within the timeout period.
Note:
The SBx3100 can support up to 10 concurrent TELNET sessions.
1.5.2 Customizing the CLI Prompt
When you log into the Allied Telesis system, a default CLI prompt is provided as displayed here:
38
Username: officer
Password:
officer SEC>>
<----------- CLI prompt
You can provision or customize the system CLI prompt. The changes to the CLI prompt affect all user sessions immediately
after the prompt settings are modified.
Usage notes:
• The CLI prompt is a text message presented to a user after successful login authentication.
• The CLI prompt is the same for all users.
The user can change the format of the CLI prompt. Aside from plain text, the CLI prompt can contain any of the following
formats:
•
•
•
•
•
•
Device IP (%i)
System name (%n)
User name (%u)
Date (%d)
Time (%t)
Security level (%s)
Note that changes to the CLI prompt persist over software upgrades, over both active and inactive CFCs in a duplex system,
and over restarts.
Note:
When the Network Access product device is managed by the Allied Telesis NMS system, the user account (Security
Officer level) that is used by the Allied Telesis NMS to query and control the device must use the default >> prompt.
Refer to the Allied Telesis NMS Administration Guide for details.
Following are examples of provisioning the CLI prompt.
1.
Change the CLI prompt:
officer SEC>> SET PROMPT "Testing the CLI User Prompt"
Info (010017): Operation Successful
Testing the CLI User Prompt>>
2.
Reset the CLI prompt:
Testing the CLI User Prompt>> SETDEFAULTS PROMPT
officer SEC>>
3.
Set the CLI prompt to the system IP:
officer SEC>> SET PROMPT="%i"
172.16.66.71>>
172.16.66.71>>
4.
172.16.66.71>> SETDEFAULTS PROMPT
5.
Set the CLI prompt to the system name:
officer SEC>> SET PROMPT="%n"
Lab System 42>>
6.
Lab System 42>> SETDEFAULTS PROMPT
7.
Set the CLI prompt to the system user:
officer SEC>> SET PROMPT="%u"
39
LabUser>>
8.
LabUser>> SETDEFAULTS PROMPT
officer SEC>>
9.
Set the CLI prompt to the system date:
officer SEC>> SET PROMPT="%d"
2004-05-12>>
2004-05-12>>
10.
2004-05-12>> SETDEFAULTS PROMPT
11.
Set the CLI prompt to the system date:
officer SEC>> SET PROMPT="%t"
15:40:24>>
15:40:25>>
12.
15:40:26>> SETDEFAULTS PROMPT
13.
Set the CLI prompt to the Security Officer:
officer SEC>> SET PROMPT="%s"
SEC>>
14.
SEC>> SETDEFAULTS PROMPT
officer SEC>>
1.5.3 Provisioning the Login Banner
The login banner appears as the first system output presented to a user when they log into the Allied Telesis system. The
user has the ability to provision or customize the system login banner. The banner could be changed to present a message to
all users or a message of the day.
Usage notes follow:
• The login banner is a text message presented to a user after successful login authentication.
• The login banner may be the same for all users or be different based upon privilege level (USER, MANAGER, or
SECURITY OFFICER).
• This functionality supports up to three (3) different text entries for login banner.
• Login banner text may either be specified by directly entering the text using CLI commands or added using a script file
that contains the desired text.
• The login banner entry may be up to 255 characters long.
Note that changes to the banner persist over software upgrades, over both active and inactive CFCs in a duplex system, and
over restarts.
Note:
Only the Security Officer can change the login banner.
Following is an example of provisioning the login banner.
Set the login banner default:
officer SEC>> SETDEFAULTS LOGINBANNER ALL
Set the login banner:
40
officer SEC>> SET LOGINBANNER STRING="Allied Telesis SBx3112"
Display the login banner:
officer SEC>> SHOW LOGINBANNER
--- Login Banner Settings ----------------------------------------------------Privilege Level: USER,MANAGER,SECURITY OFFICER
Allied Telesis SBx3112
------------------------------------------------------------------------------------------------------------------------------------------------------------
Logout and log back into the system to see the changed banner:
Username: officer
Password:********
Allied Telesis SBx3112
officer SEC>>
1.5.4 Password Recovery
If all system user IDs and passwords have been deleted, destroyed, or corrupted, you can recover the default user ID and
password using the password recovery procedure.
Password recovery should only be performed on a simplex system; on a duplex system, the inactive may restart and gain
activity while the boot parameters are being changed on what was the active unit.
1.5.4.1 Password Recovery Interactions
• A system power cycle must be performed in order to recover the default user ID and password.
• The system must be rebooted in order to recover the default user ID and password.
• Boot flags must be set in order to perform the password recovery procedure.
Since all system user IDs and passwords have been destroyed, there is no user access to the CLI command line prompt to initiate a reboot from software using the RESTART command. Therefore, the system must be power-cycled. Refer to 1.5.4.2.
1.5.4.2 Password Recovery Procedure
1.
Ensure that the management device (PC, laptop, etc.) is connected to the CONSOLE (serial) port of the active CFC card.
2.
Cut the power to the PSUs.
3.
Restore power to the PSUs.
4.
As the CFC recovers, watch the boot banner as it appears.
5.
When the message to enter ^b (Ctrl b) appears, enter Ctrl b. This stops the boot process and gives control of the session
to the user, starting with the password, as shown below.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ATI 200G Central Fabric Controller Boot Loader
Version 14.1.g.02.20100414
Created on Wed 04/21/2010 at 09:50 AM
Copyright Allied Telesis Inc., 2009
VxWorks Version 5.5.1 for MV78100 CFC200 LE MMU ARCH 5
BSP version 1.2/1.3.5_000
Copyright Wind River Systems, Inc., 1984-2002
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
*****************************************************************************
* Warning: The password for the bootrom is the system default.
*
*****************************************************************************
Press ^b to stop automatic loading of software image...
41
6
// Countdown timer
Enter Password:
[Allied Telesis Boot Loader]:
6.
It is a good idea to change the default bootrom password (“friend”). Type “w” and press ENTER. You will be prompted
for the old password and new password, as shown below.
[Allied Telesis Boot Loader]:w
Enter Old Password:
Enter New Password:
Re-enter New Password:
Password successfully changed
7.
Type “c” (for change parameter) and press ENTER. As each parameter appears, press ENTER to accept the current value,
until the parameter “BOOTFLAGS” is reached. At this point, add the hexadecimal value “0x100000” to the existing value
and press ENTER. This enables the password recovery mode. For example, if the existing value is “0x1000”, enter
“0x101000” (0x1000 + 0x100000).
[[Allied Telesis Boot Loader]: c
'.' = clear field;
'-' = go to previous field;
BOOTSERVER NAME
BOOTSERVER IPADDR
NETWORKLOAD
HOSTNAME
MGMT IPADDR
GATEWAY IPADDR
SUBNETMASK
FTP USERNAME
FTP PASSWORD
BOOTFLAGS
:
:
:
:
:
:
:
:
:
:
^D = quit
10.52.18.3
/tffs/load/cfc200_14.1.0.GAMMA.20100303.tar
10.52.71.36
10.52.71.1
255.255.255.0
target
telesyn
0x1008 0x101008
8.
Type “@” and press ENTER to reboot the system again.
[Allied Telesis Boot Loader]: @
9.
The boot sequence starts again. This time, let the countdown timer expire and the system reboots automatically. Note
the message that appears indicating that password reset has been performed. All existing users and passwords have been
removed from the system and the default user ID and password combination (officer/officer and manager/friend) has
been restored.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ATI 200G Central Fabric Controller Boot Loader
Version 14.1.g.02.20100414
VxWorks Version 5.5.1 for MV78100 CFC200 LE MMU ARCH 5
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
*****************************************************************************
* Warning: The password for the bootrom is the system default.
*
*****************************************************************************
Press ^b to stop automatic loading of software image...
0
Automatically loading software image...
FPGA Version 15.0
Starting Application Software Loading.
Attaching to Flash File System ... done.
/tffs/ - Volume is OK
Boot album is (current, attempt 1): 'cfc200_14.1.0.GAMMA.20100303.tar'
Checking Album's integrity...done
Loading vxWorks.bin.gz...(12854375 bytes)
Starting at 0x10000...
Attaching interface lo0...done
42
Adding 45812 symbols for standalone.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
;@ @@@@@@@@@@@@@@@@@ ====
,;@@@@ @@@@@@@@@@@@@@" ========
;@@@@@@@@
@@@@@@@@" ,@ ========
,;@@@@@@@@@@@ @@@@@@@" ,@@@ ========
;@@@@@@@@@@@@@@@ @@@@;" ,@@@@@@ ====,
,;@@@@@@@@@@" ;@@@@@ @@" @@@@@@@@@@@@"
@@@@@@@@@@@"
"@@@@@ " @@@@@@@@@@@@@"
Allied Telesis, Inc.
ATI 200G Central Fabric Controller
Version 14.1.0.GAMMA.20100303 (Lab-Only Build)
---------------------------------------------Software Version Information
---------------------------------------------Build name : ATI 200G Central Fabric Controller
Build type : Lab-Only Build
Revision
: 14.1.0.GAMMA.20100303
Built on
: Wed 03/03/2010 at 04:10 AM
Built by
: Loadbuild Prime
Environment: ccb_R14.1_int
Baseline
: R14.0.1_2010_03_01_RC4
Target
: cfc200
Options
: OFFICIALBUILD=TRUE
Brand
: ATI
---------------------------------------------Boot ROM Version Information
---------------------------------------------Boot ROM
: ATI 200G Central Fabric Controller Boot Loader
Revision
: 14.1.g.02.20100414
Built on
: Wed 04/21/2010 at 09:50 AM
Built by
: dlayne
Environment: dlayne_R14.1_2
Baseline
: R14.0_4_16_2010_preRC9
BuildTarget: bootcfc200
---------------------------------------------VxWorks Version 5.5.1 for MV78100 CFC200 LE MMU ARCH 5
Memory Size: 511 MB
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
********************
* WARNING: Password reset mode has been activated for this reboot.
********************
System Time is 2010-04-21 07:11:29.428
Last reset occurred due to a power interruption.
System initializing...
/tffs/
- Volume is OK
Initialization completed successfully (14.1.0.GAMMA.20100303)
User Access Verification
Username: officer
Password:
10.
Enter the user ID officer (or manager).
Username: manager
11.
Enter the user password officer (or friend).
Password: (typed password is hidden from view)
12.
The user is logged into the system. System user data can be re-configured and stored in the database. Other configuration
data remains intact.
13.
Note that there is a security risk if the default user ID and password are enabled. It should be modified as soon as possible or the default “officer” and “manager” accounts should be replaced by a different SECURITY OFFICER account.
43
>show user
--- User Authentication Database ---------------------------------------------Username
--------------------officer
manager
Privilege
---------------SECURITY OFFICER
SECURITY OFFICER
Status
-------Enabled
Enabled
Telnet
-----Yes
Yes
SSH
--Yes
Yes
Last Login
------------------2010-04-21 07:11:50
2010-04-21 07:11:58
-------------------------------------------------------------------------------
44
1.5.5 User Administration Commands
This section describes the commands available for User Administration.
TABLE 1-6
User Administration Commands
Commands
ADD USER PASSWORD (SEC)
DEACTIVATE SESSION (SEC)
DELETE USER (SEC)
DISABLE CONFIRMATION
DISABLE MORE
DISABLE USER (SEC)
ENABLE CONFIRMATION
ENABLE MORE
ENABLE USER (SEC)
PURGE USER (SEC)
RESET USER (SEC)
SEND MESSAGE SESSION
SET LOGINBANNER (SEC)
SET PASSWORD
SET PROMPT
SET SYSTEM
SET SYSTEM LANGUAGE
SET SYSTEM USERCONFIG (SEC)
SET SYSTEM USERCONFIG - (password) - (SEC)
SET USER (SEC)
SETDEFAULTS LOGINBANNER (SEC)
SETDEFAULTS PROMPT
SHOW LOGINBANNER
SHOW SESSIONS
SHOW SYSTEM
SHOW SYSTEM USERCONFIG (SEC)
SHOW USER
45
ADD USER PASSWORD (SEC)
Syntax
ADD USER=login-name PASSWORD=password [
DESCRIPTION=description ] [ PRIVILEGE={
[ LOGIN={ TRUE | FALSE | ON | OFF | YES
SSH={ YES | NO } [ PUBLICKEY=key-name ]
[ DEACTIVATE={ OFF | yyyy-mm-dd } ]
Description
Used to add new user accounts to the system. At a minimum, a user login name and password must be
specified. The password can be clear text (non-encrypted) or in the form of a 32-character MD5
encrypted string. Unless the FORMAT option is specified, the password value is assumed to be clear
text.
Mode
Sec_Off
FORMAT={ CLEARTEXT | MD5 } ] [
USER | MANAGER | SECURITYOFFICER } ]
| NO } ] [ TELNET={ YES | NO } ] [
] [ PWDAGEING={ OFF | 0 | 1..365 } ]
Options
Option
Description
Range
Default
Value
USER
Identifies the name of the account to change. It is a character string, 1 to 32 characters in length. Valid characters are uppercase letters (A-Z), lowercase letters (a-z),
and decimal digits (0-9). The string may not contain
spaces. The login name is case insensitive.
NA
NA
PASSWORD
The password can be clear text (non-encrypted) or in
the form of a 32-character MD5 encrypted string.
NA
NA
FORMAT
Format of the password
NA
CLEARTEXT
CLEARTEXT - Non-encrypted text
MD5 - Pre-encrypted as a 32 character MD5 digest.
DESCRIPTION
Descriptive text for the user
NA
NA
PRIVILEGE
One of the three levels. Refer to 1.5.1.
NA
USER
LOGIN
Specifies whether or not the account is accessed via
direct login or not.
NA
YES
NA
NO
YES - The account can be used immediately after it is
created.
NO, FALSE, or OFF - the account cannot be used to
access the system.
TELNET
Allows telnet access to be enabled or disabled for the
user being added.
YES - the user has access via telnet.
NO - The user will only be able to connect via serial
port.
SSH
Allows Secure Shell access to be enabled or disabled for
the user being added.
NA
NO
PUBLICKEY
The SSH Public key associated with the user account
and used for SSH authentication.
NA
NA
46
Option
Description
Range
Default
Value
PWDAGEING
Indicates the number of days before a password expires
and requires the user to change its password. If the
value is OFF or 0, then the password does not expire.
NA
OFF
DEACTIVATE
Indicates the date that the user account is to be deactivated. The default value is OFF, which indicates that
there is no deactivation date.
NA
OFF
Release Note
NA
Example
ADD USER coleman PASSWORD cac1cacX TELNET=YES
47
DEACTIVATE SESSION (SEC)
Syntax
DEACTIVATE SESSION={session-list|ALL} [{CANCEL|[MESSAGE=messagetext][DELAY=1..600]}]
Description
Provides a means to force a user off the system. There are two primary modes of operation for the
command, to force users off immediately or to have a delay.
Mode
Sec_Off
Options
Option
Description
Range
Default
Value
SESSION
By running the command with just a session id, the associated user is forced off immediately.
NA
NA
Session Id values can be found by running the SHOW
SESSIONS command. The session Id corresponds to
either the console number (0) or one of the 10 telnet
sessions. The SHOW SESSION command will indicate
which sessions have been initiated for a delayed deactivation. A number in the 'Deact' column indicates the
number of seconds left before that session is forced off.
MESSAGE
Text message to send to other users before ending the
session.
NA
NA
DELAY
If there is a need to offer users an opportunity to complete their work before logging off, the DELAY and MESSAGE options can be used.
NA
1 second
If delayed deactivation is used, the deactivation can be
aborted through the use of the CANCEL option.
Release Note
NA
Example
DEACTIVATE SESSION=ALL MESSAGE=Reboot in 60 seconds DELAY=60
48
DELETE USER (SEC)
Syntax
DELETE USER=login-name
Description
Used to remove user accounts from the system. Once removed, the associated user cannot log into
the system again until his/her account is recreated via the ADD USER command. The DELETE USER
command does not, however, log the associated user off the system. If the affected user is currently
logged in, he/she is informed that his/her account was removed, but no other action is taken. If there is
a desire to force the user off the system as part of deleting the account, the DEACTIVATE SESSION
command must also be used.
Mode
Sec_Off
Options
Release Note
Option
Description
Range
Default
Value
USER
The login id that was configured
NA
NA
NA
Example
>DELETE USER=coleman
Delete User (Y/N)? Y
Info (020100): User "coleman" has been deleted
49
Syntax
Description
Used to suppress user confirmation prompts for potentially dangerous commands. This command is
intended for expert users who understand the impact of the various operations on the device.
Mode
Manager
Release
Options
NA
Release Note
NA
Example
50
DISABLE MORE
Syntax
DISABLE MORE
Description
Disables the --More-- output and lets the SBx3112 output continue to run past the end of the window.
The disabling of the MORE prompt via this command will only affect the current CLI session. The
MORE prompt can be re-enabled via the ENABLE MORE command.
Mode
Manager
Options
NA
Release Note
NA
Example
DISABLE MORE
51
DISABLE USER (SEC)
Syntax
DISABLE USER=login-name
Description
Locks out a user. The account is still present, but the user that owns the account is unable to login.
Once disabled, the associated user cannot log into the system again until his/her access is re-enabled
via the ENABLE USER command. The DISABLE USER command does not, however, log the associated
user off the system. If the affected user is currently logged in, he/she is informed that his/her account
was removed, but no other action is taken. If there is a desire to force the user off the system as part
of deleting the account, the DEACTIVATE SESSION command must also be used.
Mode
Sec_Off
Options
Option
Description
Range
Default
Value
USER
The login name of the user
NA
NA
Release Note
NA
Example
DISABLE USER=coleman
52
ENABLE CONFIRMATION
Syntax
ENABLE CONFIRMATION
Description
Used to re-enable confirmation prompts after they were disabled by the DISABLE CONFIRMATION
command. By default, confirmations are enabled. When this command is used, the settings only affect
the current user session. No other user sessions are altered or changed. When a user logs out, the
confirmation settings are automatically restored to enable confirmation prompts.
Mode
Manager
Options
NA
Release Note
NA
Example
ENABLE CONFIRMATION
53
ENABLE MORE
Syntax
ENABLE MORE
Description
Stops the terminal output at the end of a window and displays --MORE --. Press return to continue the
output. This paging can be disabled via the DISABLE MORE command. BY doing so, the data will be
displayed to the screen in its entirety. The MORE prompt can be re-enabled via the ENABLE MORE
command.
Mode
Manager
Options
NA
Release Note
NA
Example
ENABLE MORE
54
ENABLE USER (SEC)
Syntax
ENABLE USER=login-name
Description
Re-enables an account that was previously disabled. Once enabled, the associated user can log into the
system again until his/her access is disabled via the DISABLE USER command.
Mode
Sec_Off
Options
Option
Description
Range
Default
Value
USER
The login name of the user
NA
NA
Release Note
NA
Example
ENABLE USER=coleman
55
PURGE USER (SEC)
Syntax
PURGE USER
Description
Deletes all users from the database and recreates the default Security Officer user. Global configuration parameters and counters are not affected. To clear these counters use the RESET USER command.
Mode
Sec_Off
Options
NA
Release Note
NA
Example
PURGE USER
56
RESET USER (SEC)
Syntax
RESET USER[=login-name] [COUNTER[={ALL|GLOBAL|USER}]]
Description
Resets the User Authentication Database counters for one or all users, or resets global counters for
the User Authentication Facility. Statistics about users are shown with the SHOW USER and SHOW
SYSTEM USERCONFIG commands. The login name is not case sensitive.
Mode
Sec_Off
Options
Option
Description
Range
Default
Value
USER
If a login name is specified with the USER parameter, the
COUNTER parameter is optional (only USER may be
specified) and the activity counters for the specified user
are reset.
NA
NA
COUNTER
If a login name is not specified with the USER parameter
then the COUNTER parameter is used to specify which
counters should be reset. If USER is specified, the activity counters for all users are reset.
NA
USER
If GLOBAL is specified, the global counters for the User
Authentication Facility are reset.
If ALL is specified, all counters are reset.
Release Note
NA
Example
RESET USER COUNTER=ALL
57
SEND MESSAGE SESSION
Syntax
SEND MESSAGE=message-text SESSION={session-list|ALL}
Description
Will allow the user to send a simple text message to any other active CLI session. The message will be
displayed asynchronously on the command window of each session listed in the SESSION parameter.
Mode
Manager
Options
Option
Description
Range
Default
Value
MESSAGE
text to send to other users (sessions)
NA
NA
SESSION
The Session ID(s) that will receive a message. The session ID. Session ID values can be found by running the
SHOW SESSIONS command. The session ID corresponds to either the console number (0) or one of the
10 telnet sessions
NA
ALL
ALL sends the message to all sessions
Release Note
NA
Example
SEND MESSAGE=”reboot in 5 minutes” SESSION=ALL
58
SET LOGINBANNER (SEC)
Syntax
SET LOGINBANNER { FILE=filename | STRING=string }
[ { USER | MANAGER | SECURITYOFFICER | ALL } ]
Description
Allows the Security Officer user to change the login banner.
Mode
Sec_Off
Options
Option
Description
Range
Default
Value
FILE
If the FILE parameter is provided, the contents of the file
is retrieved and stored locally. The contents of the file is
also retrieved upon system reboot. If the file is deleted
or replaced, the local storage of the loginbanner is not
updated unless the command is re-run or the system is
rebooted.
NA
NA
STRING
If the STRING parameter is provided, the contents of
the string is stored locally and persisted for use after
system reboots. The maximum length of the STRING
value is 255 characters.
NA
NA
Security Level
The USER, MANAGER, SECURITYOFFICER and ALL
parameters define which user level(s) the loginbanner is
applied to.
NA
ALL
Release Note
NA
Example
SET LOGINBANNER STRING="Allied Telesis SBx3112"
59
SET PASSWORD
Syntax
SET PASSWORD
Description
Allows Users to change their password at anytime. The command prompts for the old password and
asks to reconfirm the new password.
Mode
Manager
Options
NA
Release Note
NA
Example
SET PASSWORD
Enter Old Password:
Enter New Password:
60
SET PROMPT
Syntax
SET PROMPT=string
Description
Allows the user to change the CLI prompt. Note that the parameter string must be enclosed in double
quotes “ string “. The SET PROMPT command is used to define a new, default CLI command prompt
for user login sessions.
Mode
Manager
Options
Release Note
Option
Description
Range
Default
Value
string
The prompt string can contain alphanumeric text and
special tokens. The special tokens identify dynamic
information in the prompt. Refer to 1.5.2.
NA
NA
NA
Example
SET PASSWORD
Enter Old Password:
Enter New Password:
61
SET SYSTEM
Syntax
SET SYSTEM { CONTACT=contact | LOCATION=location | NAME=name | HOSTNAME=name
| GATEWAY=ipaddress | DOMAINNAME=name | DNS=ipaddress-list }
Description
Sets various administrative global attributes. These attributes affect the overall system. All attributes
can be displayed using the SHOW SYSTEM command. Refer to the SET IP INTERFACE for information on datafilling the DNS, DOMAINNAME, and, GATEWAY attributes.
Mode
Manager
Options
Release Note
Option
Description
Range
Default
Value
CONTACT
Specifies the contact information for the system. The
information is a string of descriptive text for whom to
contact. The maximum length is 80 characters. Valid
characters are any printable character. If the string
includes spaces is must be enclosed in double quotes.
NA
NA
LOCATION
Specifies the location information for the system. The
information is a string of descriptive text for where the
system is located. The maximum length is 80 characters.
Valid characters are any printable character. If the string
includes spaces it must be enclosed in double quotes.
NA
NA
NAME
Specifies a string defining the name ofthe system. The
name can be a maximum of 80 characters. If the string
includes spaces it must be enclosed in double quotes. By
convention, this is the full domain name of the IP entity
("hostname.domainname").
NA
NA
NA
Example
SET SYSTEM CONTACT=
Enter Old Password:
Enter New Password:
62
SET SYSTEM LANGUAGE
Syntax
SET SYSTEM LANGUAGE={EN}
Description
Allows the user to specify the language settings for the device. The security officer user has the ability
to change the system language preference at runtime. Once changed, the language setting affects all
CLI sessions (is a system-wide setting), and also affects the management logs.
Mode
Manager
Options
Option
Description
Range
Default
Value
LANGUAGE
English (EN) is the only language supported currently.
NA
EN
Release Note
NA
Example
NA
63
SET SYSTEM USERCONFIG (SEC)
Syntax
SET SYSTEM USERCONFIG [ LOGINFAIL=1..10 ] [ LOCKOUTPD=0..30000 ] [ MANPWDFAIL=1..5 ] [ SECUREDELAY={ OFF | 0 | 1..90 } ]
[ MINPWDLEN=1..23 ] [ PERSISTTIMER=1..1440 ]
[ PWDAGEING={ OFF | 0 | 1..365 } ] [ FORCEPWDCHANGE={ YES | NO } ]
Description
Used to modify the global (system-wide) security parameters for user authentication. Changes to the
minimum password length will affect only new users or future updates to existing user passwords.
Mode
Sec_Off
Options
Option
Description
Range
Default
Value
LOGINFAIL
Determines the maximum number of consecutive login
failures allowed before locking out a user or session.
NA
5
LOCKOUTPD
Sets the number of seconds to lockout a user or session
after the maximum number of consecutive failed login
attempts were made. The maximum number of consecutive failed logins is defined by the LOGINFAIL parameter.
NA
60
SECUREDELAY
Specifies the number of minutes that a user session can
remain idle before it is automatically timed out.
NA
5
MANPWDFAIL
Not currently supported
NA
NA
SECUREDELAY
Specifies the number of minutes that a user session can
remain idle before it is automatically timed out.
NA
5
MINPWDLEN
Specifies the minimum number of characters a user
password is allowed to contain. This parameter affects
setting of password in CLEARTEXT format or via the
SET PASSWORD command.
NA
6
PERSISTTIMER
Sets the persistence interval for system counters. The
value is specified in minute increments.
NA
10
PWDAGEING
NA
30
FORCEPWDCHANG
E
Indicates if a new user account requires a change in the
password upon the initial login of that user. If the value is
set to YES, then the user will be prompted for a new
password when they first log in.
NA
NO
Release Note
NA
Example
SET SYSTEM USERCONFIG LOGINFAIL=10 LOCKOUTPD=120 MANPWDFAIL=3 SECUREDELAY=0 MINPWDLEN=3 PERSISTTIMER=1440 PWDAGEING=OFF FORCEPWDCHANGE=No
64
SET SYSTEM USERCONFIG - (PASSWORD) - (SEC)
Syntax
SET SYSTEM USERCONFIG { MANAGERPASSWORD={ password | NONE } | SECURITYOFFICERPASSWORD={ password | NONE } }
[ FORMAT={ CLEARTEXT | MD5 }]
Description
Allows the user to set global passwords that can be used to obtain privileges at the SECURITY OFFICER level and/or MANAGER level when authenticating against the local database. This command can
also specify optional password encryption.
A password string can consist of any character and have a maximum length of 32 characters. The minimum password length is determined by the SET SYSTEM USERCONFIG MINPWDLEN command.
Mode
Sec_Off
Options
Option
Description
Range
Default
Value
MANAGERPASSWORD
Controls the password for all users at the Manager level
or whether all users at the Manager level will need a
password.
NA
NA
NA
NA
NA
CLEARTEXT
The MANAGERPASSWORD parameter is used to set a
global password that can be used to obtain MANAGER
level privileges when authenticating against the local
database. If there are RADIUS or TACACS+ servers
configured and enabled, privilege escalation requests are
sent to those servers first.
SECURITYOFFICERPASSWORD
Controls the password for all users at the Security Officer level or whether all users at the Security Officer
level will need a password.
The SECURITYOFFICERPASSWORD parameter is used
to set a global password that can be used to obtain
SECURITYOFFICER level privileges when authenticating
against the local database. If there are RADIUS or
TACACS+ servers configured and enabled, privilege
escalation requests are sent to those servers first.
FORMAT
Detrmines whether or not the password is encrypted:
Release Note
NA
Example
SET SYSTEM USERCONFIG MANAGERPASSWORD=classified SECURITYOFFICERPASSWORD=NONE FORMAT=CLEARTEXT
65
SET USER (SEC)
Syntax
SET USER=login-name [ PASSWORD=password
[ FORMAT={ CLEARTEXT | MD5 } ] ]
[ DESCRIPTION=description ]
[ PRIVILEGE={ USER | MANAGER | SECURITYOFFICER } ] [ LOGIN={ TRUE | FALSE | ON
| OFF | YES | NO } ] [ TELNET={ YES | NO } ] [ PWDAGEING={ OFF | 0 | 1..365 } ]
[ DEACTIVATE={ OFF | yyyy-mm-dd } ]
Description
Used to modify an existing user account in the system. At a minimum, a user login name must be specified. The password can be clear text (non-encrypted) or in the form of a 32-character MD5 encrypted
string. Unless the FORMAT option is specified, the password value is assumed to be clear text.
Mode
Sec_Off
Options
Option
Description
Range
Default
Value
PASSWORD
The password can be clear text (non-encrypted) or in
the form of a 32-character MD5 encrypted string.
NA
NA
FORMAT
Format of the password
NA
CLEARTEXT
DESCRIPTION
Text to provide a hint about the user
NA
NA
PRIVILEGE
One of the three levels. Refer to 1.5.1.
NA
USER
LOGIN
Specifies whether or not the account is accessed via
direct login or not. By default, the login setting is set to
YES which means the account can be used immediately
after it is created. A value of NO, FALSE, or OFF means
that the account cannot be used to access the system.
NA
YES
TELNET
Allows telnet access to be enabled or disabled for the
user being added. If the value is YES, then the user has
access via telnet. If the value is NO, then the user will
only be able to connect via serial port.
NA
YES
PWDAGEING
NA
0
DEACTIVATE
Indicates the date that the user account is to be deactivated. The default value is OFF, which indicates that
there is no deactivation date.
NA
OFF
Release Note
NA
Example
SET USER coleman PASSWORD cac2cacY TELNET=NO
66
SETDEFAULTS LOGINBANNER (SEC)
Syntax
SETDEFAULTS LOGINBANNER
[ { USER | MANAGER | SECURITYOFFICER | ALL } ]
Description
Used to restore the login banner back to its default settings for the requested user privilege level. The
default loginbanner for each of the user privilege levels is an empty string.
Mode
Sec_Off
Options
Option
Description
Range
Default
Value
Security Level
The level in which the default banner is set. If ALL
parameter is provided, all user levels are reset to the
default loginbanner.
NA
ALL
Release Note
NA
Example
SETDEFAULTS LOGINBANNER
67
SETDEFAULTS PROMPT
Syntax
SETDEFAULTS PROMPT
Description
Sets the CLI prompt to the default. When this command is run, the prompt reverts back to the
prompt string of "%u %s" which displays the user name and security level of the user of the current
session.
Mode
Manager
Options
NA
Release Note
NA
Example
SETDEFAULTS PROMPT
68
SHOW LOGINBANNER
Syntax
SHOW LOGINBANNER
Description
The SHOW LOGINBANNER command allows the user to view the login banner settings for each
user. This command shows the text that will be displayed to the user upon login.
Mode
User
Options
NA
Release Note
NA
Example
SHOW LOGINBANNER
--- Login Banner Settings ---------------------Privilege Level:
USER,MANAGER,SECURITY OFFICER
(Login banner is empty)
69
SHOW SESSIONS
Syntax
SHOW SESSIONS
Description
Displasy a list of all active (logged in) users, including the login-name, the port or device that the user
is logged into, the IP address that the user is logged in from and the login time for the user session.
There is also a column that identifies if the user has been scheduled for deactivation and the number of
seconds before the session is logged off. This column has a value only if the DEACTIVATE SESSION
command was invoked.
Mode
User
Options
NA
Release Note
NA
show sessions
--- Active (logged in) Users -------------------------------------------------ID User
Port
Location
Deact
(secs)
-- -------------------- ------- ---------------- ------ --------------- -----0 Console local
AUTH
2 officer
Telnet 10.52.18.149
CONN
2010-11-05
17:33:36
3 manager
Telnet 10.52.18.230
CONN
2010-11-08
12:03:13
Status Login Time
70
SHOW SYSTEM
Syntax
SHOW SYSTEM
Description
Displays a terse summary of current configuration information for the shelf.
Mode
User
Options
NA
Release Note
NA
Note
The slot numbering will only go up to 5 for the SBx3106.
Example
SHOW SYSTEM
-- System Information -------------------------------------------------------System Date...................
System Uptime.................
Software
Version.....................
Options.....................
Created.....................
Booted From.................
Resource Information
SDRAM (free/total)..........
Flash (free/total)..........
Identifying Information
Shelf Serial Number.........
Shelf CLEI Code.............
Shelf MAC...................
Hostname....................
Contact.....................
Location....................
Name........................
Services....................
Description.................
2010-11-05 10:52:59
8 days, 22 hours, 27 minutes, 56 seconds
15.0.0.ALPHA.20101025
Lab-Only Build
Tue 10/26/2010 at 05:19 PM
preferred
379266 KB / 524288 KB
82292 KB / 129024 KB
7
<unknown>
00:0C:25:04:00:0C
<none>
<none>
<none>
<none>
Layer 2 - Datalink/Subnetwork
Allied Telesis Switchblade x3112 - 12 Slot
High Availability Chassis
Number of MACs on card........ 2
Feature Keying
Customer ID................. <none>
Lock ID..................... phik-lbjj-loch-ceic-ojie-mjmk-bakm-oneb
MGMT
IP Address.................. 10.52.71.108
Subnet Mask................. 255.255.255.0
Gateway..................... 10.52.71.1
MAC Address................. 00:0C:25:04:00:0C
DNS......................... <none>
vlan:10.0
IP Address.................. 10.52.71.108
Subnet Mask................. 255.255.255.0
Gateway..................... 10.52.71.1
DNS......................... <none>
Shelf Power Input............. AC
Provisioning Mode............. Auto Provisioning
ECO Mode...................... OFF
71
Slot
----0
1
Prov
Type
------GE24POE
GE24POE
Physical Type
-------------GE24POE
2
3
4
5
6
7
8
GE24POE
GE24SFP
CFC200
CFC200
GE24POE
GE24POE
GE24POE
CFC200
CFC200
GE24POE
9
GE24SFP GE24SFP
10
XE4
XE4
11
XE4
XE4
Model
--------ATSBx24POE
AT-SBxMFC
AT-SBxMFC
ATSBx24POE
ATSBx31GS24
ATSBx04XP
ATSBx04XP
Serial Number
------------------18
CLEI Code
----------
HW
Rev
--X6
FPGA
Rev
----
31
45
11
-
X2
X2
X6
-
A042824103900008
-
B
-
17
-
X3
-
6
-
X3
-
---A
B
C
D
Type
-----POE
POE
System
System
State
----UP-DN
UP-DN
UP-DN
UP-UP
Temp(C)
------0
0
0
44
Layer 2 Base System
------------------Ageing time...........................
Ageing time status....................
Learning status.......................
Age Only FDB clear....................
300
Enabled
Enabled
Disabled
72
SHOW SYSTEM USERCONFIG (SEC)
Syntax
SHOW SYSTEM USERCONFIG
Description
The SHOW SYSTEM USERCONFIG command will display the value of all of the global security parameters and security counters. The security parameters indicate the values set by the SET SYSTEM
USERCONFIG command. The security counters are counters maintained to monitor user authentication activity in the system. The counters are persisted at intervals as defined by the PERSISTTIMER
parameter of the SET SYSTEM USERCONFIG command or whenever a modification to the system
parameters is done. The counters can be reset using the RESET USER command.
The following security counters are displayed:
•
Logins - number of successful logins into the system
•
Manager Pwd changes - number of times a manager or security officer password has been
changed.
•
Unknown login names - number of attempts to login with an invalid login-name
•
Idle session timeouts - number of idle sessions that have closed due to timeout.
•
Database clears - number of calls to RESET USER command for global counters.
•
Authentications - number of successful logins into the system.
•
Manager Pwd fails - number of unsuccessful logins to manager or security officer accounts.
•
Total Pwd fails - total number of unsuccessful logins to existing accounts.
•
Login lockouts - number of times a user or session was locked out due to consecutive failed login
attempts.
•
Default account resets - number of times PURGE USER command was called.
Additional information is displayed for the security parameters, including:
•
number of login fails allowed before lockout
•
length of lockout period (in seconds)
•
number of manager password fails before logoff
•
minimum password length
•
amount of idle time (in minutes) before a telnet session times out
•
value of Persist Timer (in minutes)
•
the RADIUS authentication mode
•
the TACACS+ authentication mode
Mode
Sec_Off
Example
SHOW SYSTEM USERCONFIG
--- User Authentication Facility Configuration and Counters ------------------Security Parameters:
login fails before lockout.................
lockout period (seconds)...................
manager passwd fails before logoff.........
minimum password length....................
idle telnet session timeout (minutes)......
persist Timer (minutes)....................
3
60
3
6
OFF
1440
(LOGINFAIL)
(LOCKOUTPD)
(MANPWDFAIL)
(MINPWDLEN)
(SECUREDELAY)
(PERSISTTIMER)
73
RADIUS authentication mode................. Login
TACACS+ authentication mode................ Login
New User Account Defaults:
password ageing (days)..................... OFF
force password change on first login....... No
(PWDAGEING)
(FORCEPWDCHANGE)
Security Counters: (Last persisted 2010-08-09 11:06:47)
logins....................... 42
authentications..............
manager Pwd changes.......... 0
manager Pwd fails............
unknown login names.......... 0
total Pwd fails..............
idle session timeouts........ 0
login lockouts...............
database clears.............. 0
default account resets.......
42
0
0
0
0
74
SHOW USER
Syntax
SHOW USER[=login-name] [FULL]
Description
Displays the list of all configured users and their configuration parameters and counters. The configuration parameters indicate the values set by the ADD USER or SET USER command. The counters are
counters maintained to monitor user authentication activity in the system for each user configured.
Mode
User
Options
Release Note
Option
Description
Range
Default
Value
login-name
The id of the user
NA
NA
FULL
Includes the attributes for all login names
NA
NA
NA
Example
manager SEC>> show user
--- User Authentication Database ---------------------------------------------Username
--------------------officer
manager
Privilege
---------------SECURITY OFFICER
SECURITY OFFICER
Status
-------Enabled
Enabled
Telnet
-----Yes
Yes
SSH
--Yes
Yes
Last Login
------------------2010-11-05 17:33:36
2010-11-08 12:03:13
SHOW USER manager
--- User Authentication Database --------------Username...................
Description................
Privilege..................
Status.....................
Telnet User................
SSH User...................
Public Key.................
Password Ageing............
Deactivation...............
Accounting Statistics:
Last Login...............
Logins...................
Failed Attempts..........
Lockouts.................
manager
Default User
SECURITY OFFICER
Enabled
Yes
Yes
None
Off
OFF
2010-11-08 12:03:13
2
0
0
75
1.6 Configuring Physical Interfaces and Protocols
1.6.1 Introduction
1.6.2 Initial Interfaces
FIGURE 1-5 shows the physical and protocol interfaces that allow the SBx3112 to communicate with management systems.
One of two IP interfaces can be used:
• The MGMT Ethernet interface that transports only management data packets.
• An inband Ethernet interface that interleaves user data packets with management data packets on the uplink, using an
already created VLAN interface. In using a VLAN interface the management data packets are always VLAN-tagged.
Over these two interfaces, the TELNET or SNMP agent can be configured.
Caution: Only one interface can be enabled at a time; enabling an interface will disable an interface already enabled. If
necessary, the ENABLE IP INTERFACE command will automatically disable the other IP Interface.
1.6.3 Physical Interface Configuration
SBx31CFC
SBx S TATUS
0
1
SYS S TA TUS
M/S
PSU
FAN
MASTER
SL AVE
NORMAL
FAULT
NORMAL
FAULT
RESET
2
3
4
5 CFC
M/S
6
7
PSU
8
9
FAN
10
11
SD
REA DY
B USY
1000 LINK
AC T
10/100 LINK
AC T
NET MGMT
CONSOLE
10/100/1000Base-T
RS-232
L/A
FAULT
Management software,
PC with *TELNET/CLI,
Network Management System
Management software,
PC with *TELNET/CLI,
Network Management System
Ethernet
Ethernet (Dedicated for Management)
SBx31XZ4
PORT ACTIVITY
10G LINK /
AC T
0
1
2
3
XFP
XFP
XFP
XFP
FIGURE 1-5
Connections for Management Interfaces for the SBx3112
To enable TELNET access for the management ethernet interfaces, TELNET must be enabled. The user can then choose
which interface to use and supply the IPADDRESS and SUBNETMASK for the SBx3112 that will be used by the management
device when a user logs in
76
1.6.4 Configuring the Management Interfaces
The following tables show how to configure the MGMT and Inband interface.
Caution: Enabling the Inband Interface would disable the MGMT interface.
TABLE 1-7
Configure the MGMT Interface
Step
Action or State
Details
1
Enable the telnet server
Required before telnet interfaces can be used
ENABLE TELNET SERVER
2
ADD IP INTERFACE=MGMT
IPADDRESS=10.52.66.220
SUBNETMASK=255.255.255.0
Sets the IP address and subnet mask for the management interface.
3
SET SYSTEM GATEWAY 10.51.66.1
Sets the system gateway.
4
Set system DNS (if not already set)
This step is optional.
SET SYSTEM DNS 10.4.5.7,10.52.7.50
Set system domain name (if not already set)
SET SYSTEM DOMAINNAME ALLIED-SYSTEM-1
The domain name is a string of 1 to 63 characters in
length.
6
ENABLE IP INTERFACE=MGMT
Enables the interface so management-related data
can be transmitted and received.
7
SHOW IP INTERFACE=MGMT
This shows a dedicated MGMT interface has been
configured.
5
Interface.......................... ETH:0 (MGMT)
IP State........................... Enabled
Note:
Provisioning
IP Address...................... 10.52.66.220
Subnet Mask..................... 255.255.255.0
Gateway......................... 10.52.66.1
DNS............................. <none>
Domain Name..................... <none>
Card............................ ACTCFC
MGMT............................ Yes
The SBx3112 only supports a single
default gateway, DNS server, and
Domain Name, and so these
parameters do not appear on the SET
IP INTERFACE and ADD IP
INTERFACE commands.
Caution: The inband interface can be accessed from any port. Therefore, avoid provisioning subscriber ports on the inband
VLAN
TABLE 1-8
Configure the Inband Interface
Step
Action or State
1
Create the VLAN to be used for the inband interface
Details
CREATE VLAN INBAND VID 420
2
Add the VLAN to the Network interface
ADD VLAN INBAND INTERFACE 1.0 FRAME TAGGED
3
Add the IP interface to the VLAN
ADD IP INTERFACE VLAN:420.0 IPADDRESS 10.51.66.101 SUBNETMASK 255.255.255.0 IFNAME INBAND
77
TABLE 1-8
Configure the Inband Interface
Step
Action or State
Details
4
Set system gateway (if not already set)
SET SYSTEM GATEWAY 10.51.66.1
5
Set system DNS (if not already set)
SET SYSTEM DNS 10.4.5.7,10.52.7.50
6
7
Set system domain name (if not already set)
SET SYSTEM DOMAINNAME ALLIED-SYSTEM-1
The domain name is a
string of 1 to 63 characters in length.
Enable the interface for the created VLAN (3)
ENABLE IP INTERFACE=VLAN:420.0
8
Show the physical interfaces again.
>SHOW IP INTERFACE=ALL
--- IP Interfaces --Interface
-------------ETH:0
VLAN:420.0
Name
---------MGMT
inband
IP State
-------Disabled
Enabled
IP Address
--------------10.52.66.108
10.52.66.101
Subnet Mask
--------------255.255.255.0
255.255.255.0
Card
-----ACTCFC
ACTCFC
1.6.4.2 Using the PING Command
Following is an example output for the PING command
officer SEC>> ping 10.52.66.67
officer SEC>>
PING 10.52.66.67 (10.52.66.67)
64 bytes from 10.52.66.67 (10.52.66.67): icmp_seq=1
--- 10.52.66.67 ping statistics --1 packets transmitted, 1 packets received, 0% packet loss
officer SEC>> PING 172.16.66.1
PING 172.16.66.1
officer SEC>>
PING 172.16.66.1 (172.16.66.1)
officer SEC>> PING 172.16.66.1 FROM INTERFACE=vlan:402.0
PING 172.16.66.1 FROM INTERFACE=vlan:402.0
officer SEC>>
PING 172.16.66.1 (172.16.66.1)
officer SEC>> PING 172.16.66.1 FROM IPADDRESS=172.16.66.240
PING 172.16.66.1 FROM IPADDRESS=172.16.66.240
officer SEC>>
PING 172.16.66.1 (172.16.66.1)
78
1.6.5 IP Interface Commands
This section describes the commands available to enable, configure and manage the IP Interface.
TABLE 1-9
IP Interface Commands
Commands
ADD IP INTERFACE
DELETE IP INTERFACE
DISABLE IP INTERFACE
DISABLE TELNET SERVER (SEC)
ENABLE IP INTERFACE
ENABLE TELNET SERVER (SEC)
PING
SET IP INTERFACE
SET TELNET
SHOW IP INTERFACE
SHOW TELNET
STOP PING
79
ADD IP INTERFACE
Syntax
Note:
ADD IP INTERFACE={ MGMT | type:id }
IPADDRESS=ipaddress SUBNETMASK=mask | IPANDLENGTH=ipaddress/length
[ CARD={ slot | ACTCFC } ] [ IFNAME=ifname ] [ MANAGEMENT={ YES | NO } ]
The SBx3112 only supports a single default gateway, DNS server, and Domain Name, and so these parameters do
not appear on the SET IP INTERFACE and ADD IP INTERFACE commands
Description
Configures the IP address, gateway address, and subnetmask of a VLAN interface. The VLAN interface
is specified by the vlan number (vid). When the IP interface is added, its state is by default disabled and
must be enabled using the ENABLE IP INTERFACE command. If the interface and telnet server are
enabled (See ENABLE TELNET SERVER), users can log in to the system via the specified IP address.
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
The data packet interface for the system.
NA
NA
MGMT - for the dedicated interface)
type:id - for the inband, the VLAN to be used
IPADDRESS
The IP address used to login to the system.
NA
NA
SUBNETMASK
The subnet mask to associate with the given interface.
NA
NA
IPANDLENGTH
As an alternative to specifying IPADDRESS and SUBNETMASK, the IPANDLENGTH may be used to specify
the IPv4 address and the subnet mask in a single parameter, with the IP address in standard dotted-decimal
notation and the length indicating the number of bits in
the subnet mask. For example, the address
“140.215.30.62” with subnet mask “255.255.255.0” can
be specified as “IPANDLENGTH=140.215.30.62/24”..
NA
NA
CARD
Note: The user should only specify the ACTCFC
option (for the active CFC). The “slot” option is currently not supported.
NA
ACTCFC
IFNAME
A name that can be given for the interface.
NA
NA
MANAGEMENT
Allows MANAGEMENT access to this interface
NA
YES
YES - The interface can be used for MANAGEMENT. A
user can Telnet directly into a MANAGEMENT interface
and use it for remote access.
NO - The interface cannot be used for MANAGEMENT.
Release Note
NA
Example
ADD IP INTERFACE VLAN:420.0 IPADDRESS=10.51.66.101 SUBNETMASK=
255.255.255.0 IFNAME=INBAND
80
DELETE IP INTERFACE
Syntax
DELETE IP INTERFACE={ MGMT | type:id-range | ifname-list | ALL } [ FORCE ]
Description
Deletes the MGMT or VLAN interface
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
The interfaces that have been defined.
NA
NA
FORCE
Overrides the confirmation message.
NA
NA
Release Note
NA
Example
DELETE IP INTERFACE=MGMT
81
DISABLE IP INTERFACE
Syntax
DISABLE IP INTERFACE={ MGMT | type:id | ifname }
Description
Deactivates the VLAN or MGMT interface, so that users can no longer log into the SBx3112 product
using the IP address.
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
The interfaces that have been defined.
NA
NA
Release Note
NA
Example
DISABLE IP INTERFACE=MGMT
82
DISABLE TELNET SERVER (SEC)
Syntax
DISABLE TELNET SERVER
Description
The DISABLE TELNET SERVER command blocks access to the device via telnet. For security reasons,
there may be a need to disable the telnet server. Once deactivated, the only other means of access are
through SNMP (if enabled) and the Console. After deactivation and all users log off, the Console provides the only interface through which the telnet server can be re-enabled. Users are not automatically
forced out of the system when telnet server is disabled. If there is a desire to force users off the system as part of disabling telnet, the DEACTIVATE SESSIONS command must also be used.
Mode
Sec_Off
Options
NA
Release Note
NA
Example
DISABLE TELNET
83
ENABLE IP INTERFACE
Syntax
ENABLE IP INTERFACE={ MGMT | type:id | ifname }
Description
The ENABLE IP INTERFACE command enables an existing interface. Only one IP Interface can be
enabled at a given time. If necessary, the ENABLE IP INTERFACE command will automatically disable
the other IP Interface. If the telnet service is enabled (See ENABLE TELNET SERVER), users can log in
to the system the IP address associated with the enabled interface.
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
The provisioned IP interface
NA
NA
Release Note
NA
Example
ENABLE IP INTERFACE=VLAN:420.0
84
ENABLE TELNET SERVER (SEC)
Syntax
Description
The ENABLE TELNET SERVER command will allow remote users to telnet to the system. Since the
default is for TELNET to be disabled for security, the user must input this command before the TELNET interfaces can be used.
Mode
Sec_Off
Options
NA
Release Note
NA
Example
85
PING
Syntax
PING={ ipaddress | hostname }
[ FROM { INTERFACE={ type:id | id | ifname } | IPADDRESS=ipaddress } ]
[ DELAY=1..900 ] [ LENGTH=1..8192 ]
[ NUMBER={ 1..65535 | CONTINUOUS } ]
[ TIMEOUT=1..900 ]
Description
Pings an interface or IP address from the Allied Telesis product. The PING command is used to find
other hosts in the same network. The PING command sends ICMP echo packets to the specified host
and waits for a response. If a response is received, an indication of success is shown to the user. Once
the command operation completes, the user is presented with a summary of the number of packets
sent and received along with an indication of the percentage of packets lost. In the event that a user
wishes to end a repetitive PING request, the STOP PING command terminates ping operation and
presents information regarding the number of packets sent and received.
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
Identifies the source VLAN interface from which the
PING request originates.
NA
NA
IPADDRESS
Used to indicate the source of a PING request. The
originating IP address is used when the PING request
needs to originate from a network source other than
the SBx3112 management network connection.
NA
NA
DELAY
Sets the number of seconds to wait between a PING
response and the next PING request.
NA
1 second
LENGTH
Sets the size of the ICMP packet, in bytes, sent as part
of the ping request
NA
64 bytes
NUMBER
Indicates the number of ping requests to send to the
specified host. To stop the ping operation before all
attempts are given or to stop continuous pinging, use
the STOP PING command.
NA
1 request
TIMEOUT
Specifies the amount of time, in seconds, to wait for a
response from the remote host. If the timeout delay
expires, the ICMP response packet is considered lost
and the remote host unreachable.
NA
5 seconds
Release Note
NA
Example
PING 10.52.201.234
86
SET IP INTERFACE
Syntax
Note:
SET IP INTERFACE={ MGMT | type:id-range | ifname-list | ALL }
{ [ IPADDRESS=ipaddress ] [ SUBNETMASK=mask ] |
[ IPANDLENGTH=ipaddress/length ] }
[ IFNAME=ifname ]
[ MANAGEMENT={ YES | NO } ]
The SBx3112 only supports a single default gateway, DNS server, and Domain Name, and so these parameters do
not appear on the SET IP INTERFACE and ADD IP INTERFACE commands.
Description
Changes the existing setting for the MGMT or VLAN interface. If this command is executed while the
interface is in use, users of the interface must reconnect after the settings are applied by the system.
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
The data packet interface for the system.
NA
NA
MGMT - for the dedicated interface
type:id - for the inband, the VLAN to be used
ifname-list - The names for the interfaces if they exist
ALL - All of the IP interfaces
IPADDRESS
The IP address of the system
NA
NA
SUBNETMASK
The subnet mask to associate with the given interface.
NA
NA
IPANDLENGTH
As an alternative to specifying IPADDRESS and SUBNETMASK, the IPANDLENGTH may be used to specify
the IPv4 address and the subnet mask in a single parameter, with the IP address in standard dotted-decimal
notation and the length indicating the number of bits in
the subnet mask. For example, the address
“140.215.30.62” with subnet mask “255.255.255.0” can
be specified as “IPANDLENGTH=140.215.30.62/24”.
NA
NA
IFNAME
A name that can be given for the interface.
NA
NA
MANAGEMENT
Allows MANAGEMENT access to this interface.
NA
YES
YES - The interface can be used for MANAGEMENT. A
user can Telnet directly into a MANAGEMENT interface
and use it for remote access.
NO - The interface cannot be used for MANAGEMENT.
Release Note
NA
Example
The following sequence shows the result of changing IPANDLENGTH:
>set ip int mgmt ipandlength 10.52.71.142/24
The mgmt interface will be reset. Do you want to continue (Y/N)? y
Info (010017): Operation Successful officer SEC>> show ip int mgmt
--- IP Interfaces ---
87
Interface.......................ETH:0 (MGMT)
abled
IP State........................... Dis-
Provisioning
IP Address...................... 10.52.71.142
Subnet Mask..................... 255.255.255.0
Gateway......................... 10.52.71.1
DNS............................. <none>
Domain Name..................... <none>
Card............................ ACTCFC
MGMT............................ Yes
> set ip int mgmt ipandlength 10.52.71.142/16
The mgmt interface will be reset. Do you want to continue (Y/N)? y
Info (010017): Operation Successful officer SEC>>
> show ip int mgmt
--- IP Interfaces --Interface.......................... ETH:0 (MGMT)
Disabled
Provisioning
IP Address......................
Subnet Mask.....................
Gateway.........................
DNS.............................
Domain Name.....................
Card............................
MGMT............................
IP State...........................
10.52.71.142
255.255.0.0
10.52.71.1
<none>
<none>
ACTCFC
Yes
88
SET TELNET
Syntax
SET TELNET [ TERMTYPE=termstring ] [ INSERTNULL={ ON | OFF } ]
Description
Allows the user to set the system-wide settings of the telnet client configuration, including the TERMTYPE and INSERTNULL data.
Mode
Manager
Options
Option
Description
Range
Default
Value
TERMTYPE
The string that will be sent to a remote telnet server
during the negotiation of the telnet connection. The terminal identification is usually used by the remote system
to set the terminal attributes for the Telnet session.
NA
XTERM
INSERTNULL
When set to ON, specifies that a NULL character
should be inserted after each CR sent to the remote
system.
NA
OFF
Release Note
NA
Example
SET TELNET INSERTNULL=ON
89
SHOW IP INTERFACE
Syntax
SHOW IP [ INTERFACE [ ={ MGMT | type:id-range | ifname-list | ALL }] [ FULL ]
]
Description
Displays the IP configuration information for the named interface. The information displayed includes
the interface name, the IP address and the subnet mask, and status. It shows whether the MGMT or
inband ethernet interface has been enabled.
Mode
User
Options
Release Note
Option
Description
Range
Default
Value
INTERFACE
The provisioned IP interfaces
NA
NA
NA
Example
E135 - >SHOW IP INTERFACE=FULL
--- IP Interfaces --Interface.......................... ETH:0 (MGMT)
IP State........................... Disabled
Provisioning
IP Address......................
Subnet Mask.....................
Gateway.........................
DNS.............................
Domain Name.....................
Card............................
MGMT............................
10.52.71.108
255.255.255.0
10.52.71.1
<none>
<none>
ACTCFC
Yes
--- IP Interfaces --Interface.......................... VLAN:10.0 (inband)
IP State........................... Enabled
Provisioning
IP Address......................
Subnet Mask.....................
Gateway.........................
DNS.............................
Domain Name.....................
Card............................
VLAN ID.........................
MGMT............................
10.52.71.108
255.255.255.0
10.52.71.1
<none>
<none>
ACTCFC
10
Yes
90
SHOW TELNET
Syntax
SHOW TELNET [ { SERVER | SESSIONS } ]
Description
Displays the Telnet Client configuration information, indicating the settings for InsertNull and Terminal
Type.
Mode
User
Options
Release Note
Option
Description
Range
Default
Value
SERVER
Displays the state of the telnet server, indicating if it is
ENABLED or DISABLED.
NA
NA
SESSIONS
Displays the current telnet client sessions, indicating if
there are any connections to remote systems, the CLI
Session Id that requested the connection, the source
and destination IP addresses of the telnet connection,
and the time at which the connection was made.
NA
NA
NA
Example
SHOW TELNET SERVER
Info (020108): Telnet Server is Enabled.
91
STOP PING
Syntax
STOP PING
Description
Terminates a ping session that is in progress and presents information regarding the number of packets
sent and received.
Mode
Manager
Options
NA
Release Note
NA
Example
STOP PING
1.6.6 System Time - SNTP
When the SBx3112 is first installed, local time can be set up using the command SET SYSTEM TIME.
The SBx3112 can also synchronize with a network time server using the SNTP protocol, which requires an SNTP server with
a host name or IP address to be configured.
1.6.6.1 Time Zones and Daylight Savings Time
There is support for Time-zones and Daylight Saving Time (DST) on the SBx3112. With this feature the SBx3112-based times
correctly reflect current local time and whether DST is in effect if desired. Standard North American Time-zones and their
DST settings (start and end date/time and UTC offset) are supported. In addition the user may specify a custom time-zone
with a start and end date/time and UTC offset for DST.
Note that this feature includes standard DST rules for the following US time-zones:
•
•
•
•
•
•
Eastern Time - Standard Time: -5:00, DST UTC: -4:00
Central Time - Standard Time: -6:00, DST UTC: -5:00
Mountain Time - Standard Time: -7:00, DST UTC: -6:00
Pacific Time: - Standard Time: -8:00, DST UTC: -7:00
Alaska Time - Standard Time: -9:00, DST UTC: -8:00
Hawaii Time - Standard Time: -10:00 (Hawaii does not observe DST)
The all standard US time-zones DST start and end date/time is defined as the second Sunday in March at 02:00 and the first
Sunday in November at 02:00 respectively.
The user defined time-zone is named CUSTOM and has a start date and time, end date and time, and a UTC offset. Date is
either specified as a month and day combination or as the “third Thursday of March” (as an example).
As an example, with the EASTERN time-zone specified by the command:
SET SYSTEM TIMEZONE=EASTERN DST=ON
The SHOW SYSTEM TIME would display one of the following:
• Info (033608): System time is 2007-08-16 13:26:20 (DST)
• Info (033608): System time is 2007-02-16 13:26:20 (STANDARD)
The SHOW SYSTEM TIME FULL would display:
--- System Time --Date.................................2007-01-01
UTC Offset........................... -06:00:00
Time................................. 11:00:01 (STANDARD)
Day Light Saving
Status............................. ON
92
Time-zone..........................
Start..............................
End................................
DST UTC Offset.....................
Standard UTC Offset................
CENTRAL
2ND.SUN.MAR/02:00:00 (2007-03-11)
1ST.SUN.NOV/02:00:00 (2007-11-04)
-05:00:00
-06:00:00
SNTP Settings
Status............................. OFF
1.6.7 Configuring SNTP
This section describes configuration information, procedures, and commands for SNTP.
When an SBx3112 switch is initially booted up, the system time will be configured as follows:
• Standard Eastern Time, DST is OFF, and UTC offset is -5:00.
• All command interactions are supported by both CLI and SNMP.
• DST support can be enabled or disabled, with the default setting disabled.
• Only a single time-zone can in effect at a time whether that is the user time-zone rule or one of the pre-defined North•
•
•
•
American time-zones.
A Management Log entry is generated whenever DST starts or stops.
Modifying the current system time will cause a reevaluation of whether or not DST is in effect.
Disabling DST while DST settings are in effect will cause a reversion to the standard time UTC offset.
If a pre-defined time-zone is being used, modifying the current UTC offset will generate a warning and clear all of the DST
settings.
• All logs (error, crash, trace, management) will indicate whether in DST or standard time. And all logs that were generated
prior to the onset of DST will retain their original time.
• The SHOW SYSTEM TIME command will indicate whether in DST or standard time.
A typical SNTP configuration procedure involves the following steps:
•
•
•
•
ADD SNTP SERVER
ENABLE SNTP
- Inputs the hostname or IP address of the SNTP server that the Allied Telesis product will use.
- Activates the SNTP so that the SBx3112 will be able to synchronize its clock with the SNTP clock.
SET SYSTEM TIMEZONE
- Sets the timezone offset.
RESET SNTP - Once the SNTP server is configured, this has the SBx3112 send an SNTP query to re-synchronize the
SBx3112 with the SNTP server. Note that the SNTP server must be enabled to do this.
To delete the SNTP server, the following sequence would be used:
•
•
DISABLE SNTP
- Deactivates the SNTP so that the SBx3112 will no longer synchronize its clock with the SNTP clock.
DELETE SNTP SERVER
- Deletes the hostname or IP address of the SNTP server that the SBx3112 is using.
93
The following procedure shows the commands used for adding an SNTP server, enabling SNTP, and modifying the system
timezone.
TABLE 1-10
Step
Configuration Procedure for SNTP
Command
Description (Optional)
Review the default SNTP settings before configuring
1
SHOW SNTP
SNTP Configuration
-----------------------------------------------------------------------------Status
Off
Local IP
10.52.70.14
Last Update
Last Delta
Last Status
SNTP Server
-----------------------------------------------------------------------------No SNTP Server Configured
SNTP Statistics
-----------------------------------------------------------------------------Requests Sent
0
Responses Received
0
Set up the configuration for SNTP. These commands are normally issued during system setup
2
>ENABLE TELNET SERVER
>ADD IP INTERFACE=MGMT IPADDRESS=10.52.70.14 SUBNETMASK=255.255.255.0
CARD=ACTCFC GATEWAY=10.52.70.1 IFNAME=MGMT MANAGEMENT=Yes
>ENABLE IP INTERFACE=MGMT
Add the SNTP server (by specifying an IP address or hostname)
3
ADD SNTP SERVER=192.43.244.18
Specifies the hostname or IP address of the SNTP
server that the SBx3112 system will use.
Enable the SNTP server
4
ENABLE SNTP
Activates the SNTP so that the SBx3112 will be
able to synchronize its clock with the SNTP clock.
Note the results
5
SHOW SNTP
-------------------------------------------------------------------SNTP Configuration
-------------------------------------------------------------------Status
On
Local IP
10.52.70.14
Last Update
2009-12-07 09:18:46
Last Delta
+00.12s
Last Status
Operation Successful
SNTP Server
-------------------------------------------------------------------192.43.244.18
SNTP Statistics
-------------------------------------------------------------------Requests Sent
1
Responses Received
1
Review the system time setting before changing the time-zone
94
TABLE 1-10
Configuration Procedure for SNTP
Step
Command
6
SHOW SYSTEM TIME FULL
--- System Time --Date.................................... 2009-12-07
Time.................................... 09:18:55 (STANDARD)
Current UTC Offset................. -05:00:00
Day Light Saving
Status................................
ON
Timezone..............................
EASTERN
Start.................................
2ND.SUN.MAR/02:00:00 (2010-03-14)
End...................................
1ST.SUN.NOV/02:00:00 (2010-11-07)
DST UTC Offset........................
-04:00:00
Standard UTC Offset..............
-05:00:00
SNTP Settings
Status................................
ON
Change the system time-zone (using a custom UTC offset)
7
Modifies the UTC offset by -01:00.
SET SYSTEM TIMEZONE CUSTOM
UTCOFFSET -01:00
Verify that the UTC offset changed
8
--- System Time --Date.................................... 2009-12-07
Time.................................... 13:21:55 (STANDARD)
Current UTC Offset................. -01:00:00
Day Light Saving
Status................................
OFF
Timezone..............................
CUSTOM
Start.................................
End...................................
DST UTC Offset........................
+00:00:00
Standard UTC Offset................ -01:00:00 <- HERE
SNTP Settings
Status................................
ON
95
The following procedure shows the commands used for deleting an SNTP server.
TABLE 1-11
Step
Configuration Procedure for SNTP - Deleting SNTP Server
Command
Review the SNTP settings
1
SHOW SNTP
-------------------------------------------------------------------SNTP Configuration
-------------------------------------------------------------------Status
On
Local IP
10.52.70.14
Last Update
2009-12-07 09:18:46
Last Delta
+00.12s
Last Status
SNTP Server
-------------------------------------------------------------------192.43.244.18
SNTP Statistics
-------------------------------------------------------------------Requests Sent
1
Responses Received
1
Disable the SNTP
2
DISABLE SNTP
Deactivates the SNTP so that the SBx3112 will no
longer synchronize its clock with the SNTP clock.
Delete the SNTP server
3
DELETE SNTP SERVER
Deletes the hostname or IP address of the SNTP
server that the SBx3112 is using.
Verify that SNTP has been disabled and that SNTP server has been deleted
4
SHOW SNTP
SNTP Configuration
-----------------------------------------------------------------------------Status
Off
Local IP
10.52.70.14
Last Update
Last Delta
Last Status
SNTP Server
-----------------------------------------------------------------------------No SNTP Server Configured
SNTP Statistics
-----------------------------------------------------------------------------Requests Sent
0
Responses Received
0
96
1.6.8 SNTP Commands
This section describes the commands available to enable, configure and manage the IP Interface.
TABLE 1-12
SNTP Commands
Commands
ADD SNTP SERVER
DELETE SNTP SERVER
DISABLE SNTP
ENABLE SNTP
RESET SNTP
SET SYSTEM
SET SYSTEM TIMEZONE
SHOW SNTP
SHOW SYSTEM TIME
97
ADD SNTP SERVER
Syntax
ADD SNTP SERVER={ipaddress|hostname}
Description
Inputs the hostname or IP address of the SNTP server that the SBx3112 will use. If an SNTP server is
already specified, the command is rejected. To change the server, the existing server must be deleted
using the DELETE SNTP SERVER command.
Mode
Manager
Options
Release Note
Option
Description
Range
Default
Value
SERVER
The hostname or IP address of the SNTP server
NA
NA
NA
Example
officer SEC>> add sntp server 192.43.244.18.
officer SEC>> sh sntp
------------------------------------------------------------------------------SNTP Configuration
-----------------------------------------------------------------------------Status
On
Local IP
10.52.70.13
Last Update
2009-11-07 11:02:22 DST
Last Delta
+00.00s
Last Status
Unknown error
SNTP Server
-----------------------------------------------------------------------------192.43.244.18
SNTP Statistics
-----------------------------------------------------------------------------Requests Sent
2
Responses Received
2
----------------------------------------------------------------------
98
DELETE SNTP SERVER
Syntax
DELETE SNTP SERVER
Description
Deletes the hostname or IP address of the SNTP server that the SBx3112 is using. The SNTP server
may be removed regardless of the state of the SNTP client on the device (see ENABLE SNTP or DISABLE SNTP).
Mode
Manager
Options
NA
Release Note
NA
Example
SHOW SNTP
-------------------------------------------------------------SNTP Configuration
-------------------------------------------------------------Status On
Local IP 10.52.70.13
Last Update 2009-12-07 09:47:51
Last Delta +00.13s
Last Status
SNTP Server
----------------------------------------------------------------------192.43.244.18
SNTP Statistics
--------------------------------------------------------------Requests Sent 1
Responses Received 1
--------------------------------------------------------------DELETE SNTP SERVER
officer SEC>> sh sntp
-------------------------------------------------------SNTP Configuration
---------------------------------------------------Status On
Local IP 10.52.70.13
Last Update 2009-12-07 09:47:51
Last Delta +00.13s
Last Status
SNTP Server
---------------------------------------------(DELETED)
99
DISABLE SNTP
Syntax
DISABLE SNTP
Description
Deactivates the SNTP so that theSBx3112 will no longer synchronize its clock with the SNTP clock.
The SNTP server can now be deleted. If the SNTP client is unable to communicate with the SNTP
server, the disable operation places the client in a state where it can attempt to communicate with the
server when ENABLE SNTP is executed.
Mode
Manager
Options
NA
Release Note
NA
Example
DISABLE SNTP
100
ENABLE SNTP
Syntax
ENABLE SNTP
Description
Activates the SNTP so that theSBx3112 will be able to synchronize its clock with the SNTP clock once
the SNTP server has been added.
Mode
Manager
Options
NA
Release Note
NA
Example
ENABLE SNTP
101
RESET SNTP
Syntax
RESET SNTP
Description
Resets the timing counters and sends a query to the SNTP server to re-establish the time. Note that
the SNTP server must be in use.
Mode
Manager
Options
NA
Release Note
NA
Example
RESET SNTP
102
SET SYSTEM
Syntax
SET SYSTEM [TIME=hh:mm:ss] [DATE=yyyy-mm-dd]
Description
Sets various administrative global attributes. These attributes affect the overall system. All attributes
can be displayed using the SHOW SYSTEM command. The SET SYSTEM command sets the local time
or date on the product.
Note that the behavior of changing the system time is affected by the choice of parameters:
TIME only - the TIME is converted to UTC time based on the current offset.
TIME and DATE - The TIME is converted to UTC time based on the current TIMEZONE settings and
the DATE provided.
DATE only - If the new date moves the system into or out of DST, then the UTC time is adjusted such
that the local time is unaffected.
Mode
Manager
Options
Option
Description
Range
Default
Value
TIME
Specifies the current local time of day. The format for
the time is hh:mm:ss, for example 08:30:00 for 8:30 AM
and 20:30:00 for 8:30 PM.
NA
TBS
NA
TBS
Note that the time set using this command is potentially
changed by enabling an SNTP server.
DATE
Specifies the current date of the year. The format is
yyyy-mm-dd, for example 2010-01-01 for January 1,
2010.
Setting the system date is immediately reflected in all
system output that contains date, such as logs, SNMP
traps, etc.
Release Note
NA
Example
(TIME only)
TIMEZONE is set to EASTERN
Current local date/time is 11:00:00 on 2011-01-01 (out of DST so offset is -5 hours)
SET SYSTEM TIME 13:00:00
Current local date/time is 13:00:00 on 2011-01-01 (still out of DST)
UTC time would therefore be 18:00:00
Example
(TIME and DATE)
Current local date/time is 11:00:00 on 2011-01-01 (out of DST so offset is -5 hours)
SET SYSTEM TIME 13:00:00 DATE 2011-06-01
Current local date/time is 13:00:00 on 2011-06-01 (in DST so offset is -4 hours)
Example
(DATE)
SET SYSTEM DATE 2011-11-30 (out of DST)
Current local date/time is now 13:00:00 on 2011-11-30 (out of DST so offset is -5 hours)
103
104
SET SYSTEM TIMEZONE
Syntax
SET SYSTEM TIMEZONE [ { EASTERN | CENTRAL | MOUNTAIN | PACIFIC | ALASKAN |
HAWAIIAN | CUSTOM UTCOFFSET={ + | -hh:mm }
[ DSTSTART=nth.weekday.month [ /hh:mm:ss ]
DSTEND=nth.weekday.month [ /hh:mm:ss ]
DSTUTCOFFSET={ + | -hh:mm } ] } ] [ DST={ ON | OFF } ]
Description
Sets the timezone. There is support for Time-zones and Daylight Saving Time (DST) on the SBx3112.
With this feature the SBx3112-based times correctly reflect current local time and whether DST is in
effect if desired. Standard North American Time-zones and their DST settings (start and end date/time
and UTC offset) are supported. The user may specify a custom time-zone with a start and end date/
time and UTC offset for DST.
Note that changing the TIMEZONE has no effect on the UTC time in the shelf, only how it is displayed.
(The local time being displayed is always calculated on the fly from the UTC date/time and the TIMEZONE parameter.) Refer to the example below.
Mode
Manager
Options
Default
Value
Option
Description
Range
TIMEZONE
Allows the user to specify one of the pre-defined North
American DST time-zone settings:
NA
EASTERN
NA
NA
(DST UTC: -4:00, Standard Time: -5:00) Eastern Time
(EDT)
(DST UTC: -5:00, Standard Time: -6:00) Central Time
(CDT)
(DST UTC: -6:00, Standard Time: -7:00) Mountain Time
(MDT)
(DST UTC: -7:00, Standard Time: -8:00) Pacific Time
(PDT)
(DST UTC: -8:00, Standard Time: -9:00) Alaska Time
(AKDT)
The standard US time-zone DST start and end date/
time is defined as M03.02.00/02:00:00 and M11.01.00/
02:00:00 respectively.
CUSTOMUTCOFFSET
Specifies a value (hour and minutes) to be used as the
UTC offset. The offset can be any value between -23:59
and +23:59 (e.g., +5:45).
105
Option
Description
Range
Default
Value
DSTSTART
Used to specify a date for the start of Daylights Savings
Time (DST). Depending on the region, this may either
be a fixed calendar date or an offset relative to a day of a
given month. For example, if DST starts on the second
Sunday in March at 02:00, the DSTSTART parameter is
set to 01.00.03/02:00:00.
NA
02:00:00
NA
NA
The date is represented as either a month and day combination in the format mmm-dd where:
mmm can either be a number between 1-12 (1=January
and 12=December) or one of the following three letter
month abbreviations:
JAN,FEB,MAR,APR,MAY,JUN,JUL,AUG,SEP,OCT,NOV,D
EC.
dd is the day of the month starting with 1.
The other format is used to specify something like “the
first Sunday in March.” This format is in the format
wwww.ddd.mmm, as follows:
www - 1ST,2ND,3RD,4TH,LAST
ddd - SUN,MON,TUE,WED,THU,FRI,SAT
mmm JAN,FEB,MAR,APR,MAY,JUN,JUL,AUG,SEP,OCT,NOV,D
EC
If hh:mm:ss is not supplied by the user for DSTSTART or
DSTEND a value of 02:00:00 will be used as the default.
DSTEND
Used to specify a date for the end of Daylights Savings
Time (DST). Depending on the region, this may either
be a fixed calendar date or an offset relative to a day of a
given month. For example, if DST ends on the first Sunday in November at 02:00, the DSTEND parameter is
set to 00:00:11/02:00:00.
Refer to DSTEND for more information.
DSTUTCOFFSET
Specifies a value (hour and minutes) to be used as the
UTC offset when DST is in effect. The offset can be any
value between -23:59 and +23:59 (e.g., +5:45).
NA
NA
DST
Turn the Daylight Saving Time feature on or off.
NA
OFF
Release Note
NA
Example
SET SYSTEM TIMEZONE EASTERN DSTSTART=2ND.SUN.MAR DSTEND=1ST.SUN.NOV
DSTUTCOFFSET=-04:00 DST=ON
Example
(Changing TIMEZONE only)
SET SYSTEM TIMEZONE PACIFIC
Current local date/time is 10:00:00 on 2011-06-01 (offset is now -7 hours)
UTC time is still 17:00:00
106
SHOW SNTP
Syntax
SHOW SNTP
Description
Shows the attributes of the Simple Network Time Protocol (SNTP) configuration, which includes the
SNTP server hostname/address, and UTC offset).
Mode
User
Options
NA
Release Note
NA
Example
SHOW SNTP
-------------------------------------------------------------SNTP Configuration
-------------------------------------------------------------Status On
Local IP 10.52.70.13
Last Update 2009-12-07 09:47:51
Last Delta +00.13s
Last Status
SNTP Server
----------------------------------------------------------------------192.43.244.18
SNTP Statistics
--------------------------------------------------------------Requests Sent 1
Responses Received 1
---------------------------------------------------------------
107
SHOW SYSTEM TIME
Syntax
SHOW SYSTEM TIME [FULL]
Description
Displays the current date and time that the system is using.
Mode
User
Options
Release Note
Option
Description
Range
Default
Value
FULL
Includes all of the time attributes (UTC Offset, Daylight
Savings Time settings, SNTP setting as ON or OFF
NA
NA
NA
Example
--- System Time --Date................................. 2010-03-25
Time................................. 11:12:29 (STANDARD)
Current UTC Offset................... +00:00:00
Day Light Saving
Status.............................
Timezone...........................
Start..............................
End................................
DST UTC Offset.....................
Standard UTC Offset................
OFF
CUSTOM
+00:00:00
+00:00:00
SNTP Settings
Status............................. OFF
108
1.7 File Management
1.7.1 Introduction
A software release is the set of executable binary code that runs on system cards. Software releases are delivered in the form
of executable files, or load files. Depending on the card, some will require a load, others may not. Card load files and the system configuration database are normally stored on the control module card. New functionality and feature content for the
system is delivered in the form of new software releases. Users perform software upgrades to load new releases. Management of system files is important to maintaining optimum operational performance from the system. System file management,
load management, database management, and the software upgrade process will be described.
The SBx3112 offers two system configurations, duplex or simplex. Software upgrades for both configurations are described
below. Some differences between a simplex and duplex system are:
• Simplex systems are equipped with a single control module, the active CFC (ACTCFC)
• Duplex systems are configured with two control modules, the active CFC (ACTCFC) and the inactive CFC (INACTCFC),
providing a hot standby control module.
1.7.2 Load File Names
Load file names describe both the hardware type that uses the software and the version identification for the release. There
is internal meta data imbedded within the file that contains the same information. This external and internal data is used during the loading and installation processes to verify and assure correct software installation for appropriate hardware. For
example, the meta data insures that a control module load file will only load into and execute on a control module card.
These are examples of software release file:
• CFC200 card load file name: CFC200_14.2.1.tar
• GE24POE card load file name: GE24_14.2.1.tar
• GE24SFP card load file name: GE24SFP_14.2.1.tar
Consider the load file names listed above. The load release is subdivided into three levels. The release level will be important
and will be referred to during a software upgrade. They are as follows:
{
CFC200_14.2.1.tar
14 = Major Release
2 = Minor Release
1 = Patch Release
FIGURE 1-6
Note:
Release levels
Software load files are delivered as tar files, and the”.tar” extension must be retained.
1.7.3 File Storage
Load files can be stored in numerous locations. For example, loads will be stored in FLASH on the control module, service
module, and could be stored in the users network on a TFTP server, ZMODEM, FTP server, or SD card.
FLASH memory is a nonvolatile, reusable memory device that allows storage of large volumes of data. RAM is volatile,
dynamic memory that contains the executable software. Software loads are stored in FLASH and RAM memory on the control module and service module. The primary function of FLASH memory on the system is to store software releases, simpli-
109
fying the servicing and maintenance requirements of the system and reducing recovery time during system restorations.
Control modules and service modules are shipped with release files already present in FLASH memory.
Note:
The files on these control and service modules may or may not have the latest release.
For a duplex system, both control modules have the same files on their respective FLASH file systems. When both control
modules are UP and are in sync, all file operations are automatically applied to both the active and inactive control module. If
the inactive control module is DOWN, it is out-of-sync and file operations are not performed on it. When the inactive control module is enabled, it performs a bulk sync, and once complete, the two control modules have file operations applied to
both.
Control modules have enough FLASH memory to store two release files for each card type, allowing older and new releases
to coexist in FLASH memory during upgrade procedures. The configuration database is also stored in FLASH on the control
modules. Service modules have enough memory to store a single copy of its software release file.
When performing an upgrade, management commands retrieve the new release files from a network host and load them into
FLASH memory on the control module and service module.
1.7.4 CFC Media (SD Card)
The media card is an SD card.
Note:
A USB slot is physically present on the faceplate, but there is no software support in16.0. (USB support will be
available in a future release.)
The following SD flash memory cards are officially supported in this release.
• SanDisk SD 2G Flash card
• SanDisk 4GB SDHC Flash card
• SanDisk SDHC 32G Flash card
Note:
Others brands can be used but are not guaranteed to work.
The SD cards are labeled as “SD4” (on the slot 4 CFC) and “SD5” (on the slot 5 CFC) and are managed via the MEDIA commands. The SD cards (on both the active and inactive CFC) can be used in all commands that allow media devices for either
source or destination files, including:
BACKUP DATABASE
RESTORE DATABASE
BACKUP CONFIG
PUT LOG
COPY FILE
DELETE FILE
PUT FILE
RENAME FILE
SHOW FILE
Note:
The RESTORE CONFIG is not supported from the SD card in 16.0 for either CFC.
Following are some sample input commands with the 2GB SD card.
show media
--- Media Devices -----------------------------------------------------Unit
State
-------------------------------------- --------------------------------SD4
UP Online
SD5
UP Online
-------------------------------------------------------------------------
110
show media sd5
------------------------------------------------------------------------Device Name
SD5
Fault
No Faults
Parent Card
5
Card Type
SD MEDIA
State
UP
Status
Online
Serial Number
1894278981
Firmware Version
8.0
Number of Sectors
3862528
Bytes per Sector
512
Model
SD02G
------------------------------------------------------------------------show files sd5:*
------------------------------------------------------------------------File.................................. Size KiB
-------------------------------------- --------------------------------AllMsg.log............................ 2
MostMsgs.log.......................... 12
back09Dec2009.cfg..................... 65
backup08Dec2009.db.................... 635
cfc200_14.1.0.GAMMA.20091207.tar...... 13282
ge24poe_14.1.0.GAMMA.20091207.tar..... 2082
renamingRob........................... 75
Capacity KiB.......................... 1931264
Total Displayed KiB................... 16157
Available KiB......................... 1912672
------------------------------------------------------------------------copy file john.scr to sd5:john.scr
Command has been submitted
Copy OK: 1683 bytes copied
Info (033019): Successfully copied file john.scr to john.scr media sd5
show file sd5:*
------------------------------------------------------------------------File.................................. Size KiB
-------------------------------------- --------------------------------AllMsg.log............................ 2
MostMsgs.log.......................... 12
back09Dec2009.cfg..................... 65
backup08Dec2009.db.................... 635
cfc200_14.1.0.GAMMA.20091207.tar...... 13282
ge24poe_14.1.0.GAMMA.20091207.tar..... 2082
john.scr.............................. 1
renamingRob........................... 75
Capacity KiB.......................... 1931264
Available KiB......................... 1912671
------------------------------------------------------------------------show files media sd4
------------------------------------------------------------------------------File.................................. Size KiB
-------------------------------------- --------------------------------------AllMsg.log............................ 207
DBBackupTR15.db....................... 670
RobSD.txt............................. <1
cfc200_14.1.0.GAMMA.20100203.tar...... 13359
rob.tar............................... 2097
Capacity KiB.......................... 3567616
Available KiB......................... 4194303
111
delete file sd5:john.scr
Do you really want to delete file(s) (Y/N)? y
Info (033822): Submitted request to delete file john.scr
Info (033816): Successfully deleted file: john.scr media sd5
deactivate media sd5
Command has been submitted for card 5
Info (039512): Operation Successful (SD5 )
show media
--- Media Devices -----------------------------------------------------Unit
State
-------------------------------------- --------------------------------SD4
UP Online
SD5
DOWN Offline
------------------------------------------------------------------------
1.7.4.1 Transferring Files between Flash and an SD Card
The COPY FILE command can be used to transfer (and rename) files between flash and an SD card. If either the source file or
destination is a media card, the file name should be directly preceded by the unit name (e.g., SD5).
When copying to flash, if the system is running with redundant CFCs, the operation is performed on both CFCs (when both
CFCs are online). The command fails if there is insufficient space on the CFC flash file system or SD card for the new file.
The following procedure shows the commands used to copy a file from flash to an SD card as well as from an SD card to
flash.
TABLE 1-13
Step
Procedure - Transferring File between Flash and SD Card
Command
Description/Notes
Copy a file from flash to an SD card
1
copy file D104_14.1.0.cfg to sd5:
Copies file “D104_14.1.0.cfg” from the local
flash to the SD5 media card.
Info (033019): Successfully copied file
D104_14.1.0.cfg to D104_14.1.0.cfg media sd5
Verify that file was copied
2
show file sd5:
------------------------------------------------------------------------------File..................................
-------------------------------------D104_14.1.0.cfg.................. 62
DBBackupTR15.db.......................
cfc200_14.1.0.GAMMA.20100208.tar......
rob.tar...............................
rob1.tar..............................
rob12.tar.............................
xe4_14.1.0.GAMMA.20100111.tar.........
xe4_14.1.0.GAMMA.20100118.tar.........
Size KiB
--------------------------------------670
13366
2097
2097
2053
2053
2054
Capacity KiB.......................... 1985024
Available KiB......................... 1960160
Copy a file from flash to an SD card and renaming it
3
copy file D104_14.1.0.cfg to
sd5:D104_old.cfg
Info (033019): Successfully copied file
D104_14.1.0.cfg to D104_old.cfg media sd5
Copies file “D104_14.1.0.cfg” from the local
flash to the SD5 media card and changes the
filename to “D104_old.cfg“.
112
TABLE 1-13
Step
Procedure - Transferring File between Flash and SD Card
Command
Description/Notes
Verify that file was copied and renamed
4
show file sd5:
------------------------------------------------------------------------------File..................................
-------------------------------------D104_14.1.0.cfg.......................
D104_old.cfg..................... 62
DBBackupTR15.db.......................
cfc200_14.1.0.GAMMA.20100208.tar......
rob.tar...............................
rob1.tar..............................
rob12.tar.............................
xe4_14.1.0.GAMMA.20100111.tar.........
xe4_14.1.0.GAMMA.20100118.tar.........
Size KiB
--------------------------------------62
670
13366
2097
2097
2053
2053
2054
Capacity KiB.......................... 1985024
Available KiB......................... 1960096
Copy a file from an SD card to flash and renaming it
5
copy file sd4:D104.cfg to D104_today.cfg
Info (033006): Successfully copied file D104.cfg to
D104_today.cfg card 4
Info
(033011):
Successfully
D104_today.cfg to card 5
transferred
Copies file “D104.cfg” from the SD4 media card
to the flash on both CFCs (card 4 and card 5)
and changes the filename to “D104_today.cfg“.
file:
Verify that file was copied to flash and renamed
6
show file
------------------------------------------------------------------------------File..................................
-------------------------------------AllMsg-2.log..........................
AllMsg.log............................
D10-14_14.0.0.ALPHA.20091012.cfg......
D10-14_14.0.0.ALPHA.20091021.cfg......
D10-14_14.0.0.ALPHA.20091026.cfg......
D10-14_14.0.0.ALPHA.20091102.cfg......
D10-14_14.0.0.ALPHA.20091109.cfg......
D10-14_14.0.0.ALPHA.20091118.cfg......
D10-14_14.0.0.GAMMA.20091117.cfg......
Size KiB
--------------------------------------2
3
6
6
6
6
75
68
65
(output Omitted)
D104_14.2.0.GAMMA.20100609.cfg........
D104_14.2.0.GAMMA.20100611.cfg........
D104_14.2.0.GAMMA.20100615.cfg........
D104_14.2.0.GAMMA.20100617.cfg........
D104_14.2.0.GAMMA.20100622.cfg........
D104_14.2.0.GAMMA.20100629.cfg........
D104_14.2.0.GAMMA.20100629_john.cfg...
D104_14.2.0.GAMMA.20100629a.db........
D104_14.2.0.GAMMA.20100709.cfg........
D104_14.2.0.GAMMA.20100709b.cfg.......
D104_14.2.0.GAMMA.20100716.cfg........
D104_today.cfg..................59
EcoMode.cfg...........................
EcoTest2.cfg..........................
HvlanEpsrTc_Jan25.cfg.................
58
58
59
59
61
60
60
276
61
61
61
5
63
63
(output Omitted)
113
1.7.4.2 Transferring Files between a TFTP Server and an SD Card
The PUT FILE and GET FILE commands can be used to transfer (and rename) files between a TFTP server and an SD card.
The commands fails if there is insufficient space on the CFC flash file system or SD card for the new file.
The following procedure shows the commands used to copy a file from a TFTP server to an SD card as well as from an SD
card to a TFTP server.
TABLE 1-14
Step
Procedure - Transferring File between TFTP Server and SD Card
Command
Description/Notes
Copy a file from SD card to a TFTP server
1
put file sd5:D104_14.1.0.cfg tftp server
10.52.65.42
Transfers file “D104_14.1.0.cfg“ from SD card
(SD5) to the TFTP server.
Copy a file from SD card to a TFTP server and change the filename
2
put file sd5:D104_14.1.0.cfg tftp server
10.52.65.42 to logfiles/D104_14.1.0.cfg
Transfers file “D104_14.1.0.cfg“ from SD card
(SD5) to the TFTP server and changes its name
to “logfiles/D104_14.1.0.cfg“.
Copy a file from the TFTP server to the SD card
3
get file D104_14.1.0_19July.cfg tftp
server 10.52.65.42 to sd5:
Transfers file “D104_14.1.0_19July.cfg“ from
the TFTP server to SD card (SD5).
Verify that file was copied to the SD card
4
show file sd5:
------------------------------------------------------------------------------File..................................
-------------------------------------D104_14.1.0.cfg.......................
D104_14.1.0_19July.cfg................
D104_old.cfg..........................
DBBackupTR15.db.......................
cfc200_14.1.0.GAMMA.20100208.tar......
rob.tar...............................
rob1.tar..............................
rob12.tar.............................
xe4_14.1.0.GAMMA.20100111.tar.........
xe4_14.1.0.GAMMA.20100118.tar.........
Size KiB
--------------------------------------62
62
62
670
13366
2097
2097
2053
2053
2054
Capacity KiB.......................... 1985024
Available KiB......................... 1960032
Copy a file from the TFTP server to the SD card and change the filename
5
get file D104_14.1.0_19July.cfg tftp
server 10.52.65.42 to sd4:backup.cfg
Transfers file “D104_14.1.0_19July.cfg“ from
the TFTP server to SD card (SD4) and changes
its name to “backup.cfg“.
114
TABLE 1-14
Step
Procedure - Transferring File between TFTP Server and SD Card
Command
Description/Notes
Verify that file was copied to the SD card and renamed
6
show file sd4:
------------------------------------------------------------------------------File..................................
-------------------------------------AllMsg.log............................
D104.cfg..............................
backup.cfg............................
DBBackupTR15.db.......................
RobSD.txt.............................
cfc200_14.1.0.GAMMA.20100203.tar......
rob.tar...............................
Size KiB
--------------------------------------207
59
62
670
<1
13359
2097
Capacity KiB.......................... 3567616
Available KiB......................... 4194303
115
1.7.5 File Management Commands
TABLE 1-15
File Management Commands
Commands
ACTIVATE MEDIA
AUDIT FILES
COPY FILE TO
DEACTIVATE MEDIA
DELETE FILES
DELETE NONPREFLOADS
DIAGNOSE MEDIA
EXECUTE SCRIPT
FORMAT MEDIA
GET FILE
PURGE MEDIA
PUT FILE
PUT FILE CARD
RENAME FILE TO
SHOW FILES OPERATIONS
SHOW FILES
SHOW FLASH
SHOW MEDIA
SHOW SCRIPT
SHOW TRANSFER
STOP TRANSFER
116
ACTIVATE MEDIA
Syntax
ACTIVATE MEDIA=unit
Description
The ACTIVATE MEDIA command brings the media card to an operational state of UP, with the status
of Online indicating that it is available for service. During the activation sequence, the following steps
are performed: - The device information is read - Out of service diagnostics are run - The file system
on the media card is activated.
Mode
Manager
Options
Option
Description
Range
Default
Value
MEDIA
The name of the file that is being copied from. The unit
is the SD card and the number of the CFC slot (e.g.,
SD4).
NA
NA
117
AUDIT FILES
Syntax
AUDIT FILES
Description
Audits all load files (files with extension .tar) and raises or clears file corruption alarms accordingly
Refer to Software Load Management for its use in verifying loads.
Mode
Manager
Options
NA
Example
AUDIT FILES
officer SEC>>>>
--------------------------------------------------------------------------File
CRC Local
LocalCRC
Mate
MateCRC
------------------------------ ------------------------------------------E134cfgOn032310.log........... No
Pass
0xdeadbeef Pass
0xdeadbeef
E134cfgOn032310.txt........... No
Pass
0xdeadbeef Pass
0xdeadbeef
Jan25Config................... No
Pass
0xdeadbeef Pass
0xdeadbeef
Jan25Config.txt............... No
Pass
0xdeadbeef Pass
0xdeadbeef
W5_ge24poe_14.1.0.mdavidson.20 No
Pass
0xdeadbeef Pass
0xdeadbeef
100306.tar....................
W5_xe4_14.1.0.mdavidson.201003 No
Pass
0xdeadbeef Pass
0xdeadbeef
06.tar........................
attachment.txt................ No
Pass
0xdeadbeef Pass
0xdeadbeef
cfc200_14.2.0.dhays2.20100326. No
Pass
0xdeadbeef Pass
0xdeadbeef
tar...........................
cfc200_14.2.0.dhays3.20100326. No
Pass
0xdeadbeef Pass
0xdeadbeef
tar...........................
cfc200_14.2.0.dhays4.20100326. No
Pass
0xdeadbeef Pass
0xdeadbeef
tar...........................
cfc200_14.2.0.dhays5.20100326. No
Pass
0xdeadbeef Pass
0xdeadbeef
tar...........................
cfc200_14.2.0.dhays6.20100326. No
Pass
0xdeadbeef Pass
0xdeadbeef
tar...........................
ge24poe_14.1.0.dhays4.20100319 No
Pass
0xdeadbeef Pass
0xdeadbeef
.tar..........................
ge24poe_14.2.0.dhays1.20100325 No
Pass
0xdeadbeef Pass
0xdeadbeef
.tar..........................
ge24poe_14.2.0.dhays1.20100326 No
Pass
0xdeadbeef Pass
0xdeadbeef
.tar..........................
vxWorks_cfc200................ No
Pass
0xdeadbeef Pass
0xdeadbeef
xe4_14.1.0.GAMMA.20100202.tar. No
Pass
0xdeadbeef Pass
0xdeadbeef
xe4_14.1.0.dhays4.20100319.tar No
Pass
0xdeadbeef Pass
0xdeadbeef
xe4_14.2.0.dhays1.20100325.tar No
Pass
0xdeadbeef Pass
0xdeadbeef
xe4_14.2.0.dhays1.20100326.tar No
Pass
0xdeadbeef Pass
0xdeadbeef
---------------------------------------------------------------------------
118
COPY FILE TO
Syntax
COPY FILE={ sourcefile | unit:sourcefile } TO={ destinationfile | unit:destinationfile }
Description
Copies the specified source file to the specified destination file. The command is rejected if there is
insufficient space on the CFC flash file system for the new file. If either the source file or destination is
a media card, the file name should be directly preceded by the unit name. For example, COPY FILE
SD5:myFile to myFile would copy the file “myFile” from the SD card associated with CFC 5 to
local flash.
Mode
Manager
Options
Option
Description
Range
Default
Value
FILE
SD4).
NA
NA
TO
The name of the file that the file is being copied to. The
unit is the SD card and the number of the CFC slot (e.g.,
SD4).
NA
NA
If only the filename is specified, the file is copied to
FLASH memory.
Example
COPY FILE SD5:D104.CFG TO D104.CFG
119
DEACTIVATE MEDIA
Syntax
DEACTIVATE MEDIA=unit [FORCE]
Description
The DEACTIVATE MEDIA command brings the media card to an operational state of DOWN, with
the status of Offline indicating that is not available for service. During the deactivation sequence, the
following steps are performed:
Applications that could be using the media card are polled for approval. If there is an operation in progress, the request to deactivate the device may be denied.
The file system on the media card is deactivated.
Mode
Manager
Options
Option
Description
Range
Default
Value
MEDIA
SD4).
NA
NA
FORCE
The media card will be deactivatedeven if there is an
operation in progress that is using the media card.
NA
NA
120
DELETE FILES
Syntax
DELETE FILES={ filename-pattern | unit:filename-pattern } [ FORCE ]
Description
Deletes the specified file from the CFC flash file system. The file must already exist on the CFC flash
file system. The command is disallowed if the specified file is already designated as a preferred load file
for a provisioned card. The command is allowed for files that are designated as alternate or temporary
load files for a provisioned card. The DELETE FILE command can also be used to delete the specified
file from an SD card. In this case, filename must be preceded by the unit name, for example SD5:myFile.
Mode
Manager
Options
Example
Option
Description
Range
Default
Value
FILES
One or more filenames to be deleted. Wildcards can be
used for multiple files. The unit is the SD unit on the
active CFC.
NA
NA
FORCE
Suppresses the confirmation message.
NA
NA
DELETE FILES SD5:D104.CFG FORCE
121
DELETE NONPREFLOADS
Syntax
DELETE NONPREFLOADS
Description
Deletes all files on the CFC flash file system that are not designated as a preferred load for a provisioned card. This command is useful during load upgrade, to remove all non-essential files so that space
for new load files is available. For an SBx3112 with redundant CFCs, the operation is performed on
both CFCs when they are both ONLINE.
Mode
Manager
Options
NA
Example
DELETE NONPREFLOADS
122
DIAGNOSE MEDIA
Syntax
DIAGNOSE MEDIA=unit
Description
The DIAGNOSE command runs Out Of Service diagnostics on the media card. These diagnostics
require the media card to be deactivated before being permitted to run. The diagnostics get run automatically when the media card is activated.
Mode
Manager
Options
Option
Description
Range
Default
Value
MEDIA
SD4).
NA
NA
Release Note
NA
Example
DIAGNOSE MEDIA=SD4
123
EXECUTE SCRIPT
Syntax
EXECUTE SCRIPT=filename
Description
Processes all of the commands specified in the specified filename. The script file contains one or more
CLI commands. The first line in the file must contain a comment that identifies the file as a script.
Other words can also exist on the line, but the word 'script' must appear some place in the line. Comments are identified as a hash(#) character on a line in the file. A CLI command in the script file must
occupy a single line. A command cannot span more than one line. If a command requires user interaction like a confirmation, the user response text is included on the line after the command. The contents of a script file are played back as written. A syntax error in the file is detected as the script is run.
If an error is encountered, the device is left in an unknown condition.
Mode
Manager
Options
Option
Description
Range
Default
Value
filename
The filename that contains the scripting commands.
NA
NA
Release Note
NA
Example
EXECUTE SCRIPT CLIENT_EPSR_SETUP
124
FORMAT MEDIA
Syntax
DIAGNOSE MEDIA=unit
Description
The FORMAT MEDIA command allows the user to format a new media card so that is able to be used.
Care should be taken, as any files or data already on the media card will be lost.
Mode
Manager
Options
Option
Description
Range
Default
Value
MEDIA
SD4).
NA
NA
Release Note
NA
Example
FORMAT MEDIA=SD4
125
GET FILE
Syntax
GET FILE={ sourcefilename | serverpath/sourcefilename } { TFTP SERVER={ ipaddress | hostname } | ZMODEM | FTP SERVER={ ipaddress | hostname } USER=userid
PASSWORD=password } [ TO=unit: ]
Description
Used to transfer files onto either the CFC flash file system or, (if the optional TO parameter is used) a
specified media card, from the specified SERVER, using the specified file transfer METHOD. The command fails if there is insufficient space on the CFC flash file system or SD card, or if the filename is the
same as a pre-existing preferred load file for a provisioned card. For an SBx3112 with redundant CFCs,
the operation is performed on both CFCs when they are both ONLINE.
Mode
Manager
Options
Option
Description
Range
Default
Value
FILE
The file that is either on the CFC FLASH (sourcefilename) or on the server that is designated by the path.
NA
NA
TFTPSERVER
The ip address or name of the tftp server.
NA
NA
ZMODEM
Specifies the file should be transferred using the ZMODEM protocol.
NA
NA
FTPSERVER
NA
NA
USER
The user id to gain access to the specified server.
NA
NA
PASSWORD
The password needed after entering the user id to gain
access to the specified server
NA
NA
TO
The SD card that will receive the file from the specified
server.
NA
NA
Release Note
NA
Example
GET FILE D104_14.1.0_19JULY.CFG TFTP SERVER 10.52.65.42 TO SD5:
126
PURGE MEDIA
Syntax
PURGE MEDIA=unit
Description
The PURGE MEDIA command deletes all files from the specificed media card.
Mode
Manager
Options
Option
Description
Range
Default
Value
MEDIA
SD4).
NA
NA
Release Note
NA
Example
PURGE MEDIA=SD4
127
PUT FILE
Syntax
PUT FILE={sourcefile|unit:sourcefile} {TFTP SERVER={ipaddress|hostname} | FTP
SERVER={ipaddress|hostname} USER=userid PASSWORD=password | ZMODEM}
[TO=serverpath]
Description
Transfers the specified file from the CFC flash file system or specified SD card to the given destination.
The destination is either an external server, or a card or set of cards in the shelf. The source file must
already exist on the flash file system.
Mode
Manager
Options
Option
Description
Range
Default
Value
FILE
The file that is either on the CFC FLASH (sourcefilename) or on the server that is designated by the path.
NA
NA
TFTP_Server
NA
NA
ZMODEM
NA
NA
FTP_Server
NA
NA
USER
NA
NA
PASSWORD
NA
NA
TO
The SD card that will receive the file from the specified
server.
NA
NA
Release Note
NA
Example
PUT FILE SD5:D104_14.1.0.CFG TFTP SERVER 10.52.65.42 TO LOGFILES/
D104_14.1.0.CFG
128
PUT FILE CARD
Syntax
PUT FILE={ sourcefile | unit:sourcefile } CARD={ slot | slot-list }
Description
Transfers the specified file from the CFC flash file system or specified SD card to the given destination.
The destination is a card or set of cards in the shelf. The source file must already exist on the flash file
system.
Mode
Manager
Options
Option
Description
Range
Default
Value
FILE
The file name on the CFC FLASH memory. The unit can
also be included.
NA
NA
CARD
The slot(s) of the cards that will receive the file.
NA
NA
Release Note
NA
Example
PUT FILE SD5:D104_14.1.0.CFG CARD 10-11
129
RENAME FILE TO
Syntax
RENAME FILE={ sourcefile | unit:sourcefile } TO={ destinationfile | unit:destinationfile }
Description
Renames the specified file on the CFC flash file system. The file must already exist on the CFC flash file
system. The command is disallowed if the specified file is already designated as a preferred, alternate or
temporary load file for a provisioned card. For a duplex system, the operation is performed on both
CFCs when they are both ONLINE. The RENAME FILE command can also be used to rename the
specified file on a specified media card by prepending the name of the media card to the respective filenames. Example: RENAME cflash9:myOldFilName TO cflash9:myNewFileName.
Mode
Manager
Options
Option
Description
Range
Default
Value
FILE
is the SD card and the number of the CFC slot.
NA
NA
TO
The name of the file that the file is being copied to. If
only the filename is specified, the file is copied to FLASH
memory. Note - In release 14.1 only one SD unit is
allowed on the active CFC, and so you cannot copy a file
from one SD unit to another.
NA
NA
Release Note
NA
Example
RENAME FILE SD4:D104_14.1.0_19JULY.CFG TO SD4:D104_14.1.0_OLD.CFG
130
Syntax
Description
Show in-progress/pending transactions for the COPY, DELETE, and RENAME commands. This command when used with the SHOW TRANSFER command can tell the user the reason a file is busy.
Mode
User
Options
NA
Release Note
NA
Example
----------------------------------------------------------------------------Command Device
Filename
------- --------- ----------------------------------------------------------DELETE
LOCAL
xe4_14.2.0.GAMMA.20100810.tar
------------------------------------------------------------------------------
131
SHOW FILES
Syntax
SHOW FILES [ ={ filename-pattern | unit: | unit:filename-pattern } ] [ FULL ]
Description
Displays all user manageable files that exist on the CFC flash file system. Examples of manageable files
include software load files and script files. There are other types of files that are not directly manageable by the user that exist on the CFC flash file system, but are hidden and not displayed by this command. Database and log files are examples of files that are not directly user manageable. The
information is displayed in a columnar format, and for each file the following is shown:
•
the name of the file
•
the size of the file in kilobytes
Additional general information is shown about the CFC flash file system, including:
Mode
•
the total amount of space (in kilobytes) allocated for user manageable files
•
the total amount of space (in kilobytes) currently in use for user manageable files
•
the total amount of free space (in kilobytes) available for additional user manageable files.
User
Options
Default
Value
Option
Description
Range
FILES
Used to select the
NA
All files
on the
CFC flash
file system.
NA
NA
filename-pattern - A set of files using wildcards.
unit - The CD unit (SD4 or SD5)
unit:filename-pattern - the specific SD unit
and the pattern (in 14.1, only the SD unit on the active
CFC unit can be specified)
FULL
When the FULL option is specified, extra information
about each file is shown:
- the version of the file if it is a software load file; for
other types of files this field is left blank
- the hardware model number supported by this file if it
is a software load file; for other types of files this field is
left blank
- the date and time that the file was last modified
Release Note
NA
Example
SHOW FILES
File............................................................
---------------------------------------------------------------D104_14.2.0_PR22173.cfg.........................................
D104_16.0.0.ALPHA.20120213a.cfg.................................
D104_16.0.0.ALPHA.20120305.cfg..................................
D104_16.0.0.ALPHA.20120312.cfg..................................
D104_16.0.0.ALPHA.20120319.cfg..................................
D104_16.0.0.ALPHA.20120319_26Mar2012.cfg........................
D104_16.0.0.ALPHA.20120326.cfg..................................
D104_16.0.0.ALPHA.20120326.out..................................
D104_16.0.0.ALPHA.20120326_superloop.cfg........................
Size KiB
----------834
859
113
95
96
95
95
285
113
132
D104_16.0.0.ALPHA.20120409_PR24981_ringEveryPort.cfg............
D104_16.0.0.ALPHA.20120409_superloop_0.0_0.5_1.0.cfg............
D104_16.0.0.ALPHA.20120416.cfg..................................
D104_16.0.0.ALPHA.20120416_fullR15Config.cfg....................
cfc200_14.2.0.tar...............................................
cfc200_15.1.0.tar...............................................
cfc200_16.0.0.RC1.20120418.tar..................................
ge24_14.2.0.tar.................................................
ge24_15.1.0.tar.................................................
ge24sfp_14.2.0.tar..............................................
ge24sfp_15.1.0.tar..............................................
x31sma_16.0.0.RC1.20120418.tar..................................
xe4_14.2.0.tar..................................................
xe4_15.1.0.tar..................................................
xe6sfp_15.1.0.tar...............................................
75
113
113
859
13866
11002
13680
2154
2095
2101
2034
2629
2085
2049
2049
Allowed KiB..................................................... 87040
Total Displayed KiB............................................. 59489
Available KiB................................................... 27539
------------------------------------------------------------------------------
133
SHOW FLASH
Syntax
SHOW FLASH [INACTCFC]
Description
Displays information about the flash memory on the CFC card. Flash memory is used for storage of
user manageable files and other data not manageable by the user. The information displayed by the
SHOW FLASH command includes:
•
the total size of flash memory (in kilobytes)
•
the total size of free flash memory (in kilobytes)
•
the total size of contiguous free flash memory (in kilobytes)
This command should not be confused with the SHOW FILES command which shows files and memory usage associated only with user manageable file space on the flash memory.
Mode
Manager
Options
Option
Description
Range
Default
Value
INACTCFC
This option is not supported in 14.2.
NA
NA
To display the flash memory of the "inactive" CFC, the
user must first swap the active card with the inactive
one (thereby making the inactive CFC the active CFC)
and then issue the SHOW FLASH command.
Release Note
NA
Example
>SH FLASH
--- Flash Information ------------------------------------------Total size............... 129024
Free size................ 41604
Contiguous free size..... 17056
kb
kb
kb
---------------------------------------------------------------->SH FLASH
<cr>
INACTCFC
- This parameter is currently not supported.
>SH FLASH INACTCFC
Error: (010014): Particular command argument set not yet supported : inactive
134
SHOW MEDIA
Syntax
SHOW MEDIA [ ={ unit-list | ALL } ] [ FULL ]
Description
Displays information for the specified media card(s). The information that can be displayed includes:
the Parent Card slot number, the media card’s type, state, status, model/serial number, firmware version, number of sectors, and number of bytes per sector.
Mode
Manager
Options
Option
Description
Range
Default
Value
MEDIA
Used to select the:
NA
NA
NA
NA
unit-list - A specific SD unit or a list of SD units.
ALL - all available media cards
FULL
When the FULL option is specified, extra information
about each media card is shown:
- Serial Number
- Firmware Version
- Number of Sectors
- Number of Bytes per Sector
Release Note
NA
Example
show media full
------------------------------------------------------------Device Name
Fault
Parent Card
Card Type
State
Status
Serial Number
Firmware Version
Number of Sectors
Bytes per Sector
Model
SD4
No Faults
4
SD MEDIA
UP
Online
2156096975
8.0
15523840
512
SD08G
--------------------------------------------------------------------------------------------------------------------------Device Name
Fault
Parent Card
Card Type
State
Status
Serial Number
Firmware Version
Number of Sectors
Bytes per Sector
Model
SD5
No Faults
5
SD MEDIA
UP
Online
1613776034
8.0
3970048
512
SD02G
135
SHOW SCRIPT
Syntax
SHOW SCRIPT=filename
Description
Displays the contents of a Command Line Interface (CLI) script. A script contains CLI commands that
are executed through the EXECUTE SCRIPT command.
Mode
Manager
Options
Option
Description
Range
Default
Value
SCRIPT
The filename of a valid script file
NA
NA
Release Note
NA
Example
SHOW SCRIPT CLIENT_EPSR_SETUP
136
SHOW TRANSFER
Syntax
SHOW TRANSFER [ ={ transferid-list | ALL } ]
Description
Displays current file transfer operations, including those in progress and those that are pending. The
information is displayed in a columnar format. For files that are being transferred to or from a network
server (as result of a PUT FILE or GET FILE command, the following is displayed:
- an ID, which is simply a number associated with a particular file transfer to serve as an identifying tag
- the CMD, which is the command that was used to initiate the file transfer. The command is either
PUT or GET.
- Remote file, which is the name of the file being transferred to or from the network server
- Local file, which is the name of the file on the CFC flash file system being transferred to or from the
network server
- the Server, which is the IP address of the network server
- the Mode, which is the protocol being used for the file transfer. Currently, only TFTP is supported.
- the Status, which describes the current state of the file transfer operation. The status is either Progress, which means that the transfer is in progress, or Pending, which means that the transfer is delayed
and will begin when other transfers are completed.
- the MB, which is the number of megabytes that have been transferred, if the associated transfer status
is in progress For files that are being transferred from the CFC flash file system to another card in the
shelf (as result of a PUT FILE operation), the following is displayed: - the Card, which is the card the file
is being transferred to
- the CMD, which is the command that was used to initiate the file transfer. Currently, only the PUT
command is supported.
Mode
Manager
Options
Option
Description
Range
Default
Value
TRANSFER
The transfer ID(s), separated by a comma
NA
ALL
Release Note
NA
Example
SHOW TRANSFER ALL
137
STOP TRANSFER
Syntax
STOP TRANSFER={ transferid-list | ALL }
Description
Aborts an in-progress or pending file transfer. Only transfers to/from a network server can be
stopped. File transfers from the CFC flash file system to a card in the shelf cannot be stopped. Stopping
a transfer that is in progress deletes the destination file, but does not affect the source file.
Mode
Manager
Options
Option
Description
Range
Default
Value
TRANSFER
The transfer ID(s), separated by a comma.
NA
ALL
Release Note
NA
Example
STOP TRANSFER ALL
138
1.8 Software Load Management
1.8.1 Card Load Preferences
Once a software load is present in the control module FLASH file system, it can be designated as the target software load for
one or more cards using the parameters on the SET CARD command. The setting can be PREFLOAD, ALTLOAD, or TEMPLOAD.
1.8.2 Load File Verification
When software load files are created, a CRC value is calculated and written into the internal file data. Once a file has been
transferred to the control module FLASH file system (and to Service Module FLASH), the file contents can be verified by
recalculating the CRC value and comparing it to the internal CRC value. In the unlikely event that there is a mismatch
between the value, the file is designated corrupt.
File CRC validation is performed on all load files (those with the “.tar” extension on the file name) in the control module
FLASH file system a follows:
•
•
•
•
immediately after a restart or swap of activity
periodic audit (every 24 hours)
whenever a user enters the AUDIT FILES command
File CRC validation is performed on individual files when:
• the file is being designated as a parameter on the SET CARD command
• the file is being used during the card restart sequence, as a result of system action or manual command (RESTART
CARD or ENABLE CARD)
As mentioned above, the user can audit system files using the AUDIT FILES command. Following is an example of the use of
the command.
officer SEC>> audit files
officer SEC>>
File
Local Audit Result
Mate Audit Result
-----------------------------------------------------------------------------------------------D104_14.2.0_PR22173.cfg...................................Pass
Pass
D104_16.0.0.ALPHA.20120213a.cfg...........................Pass
Pass
D104_16.0.0.ALPHA.20120305.cfg............................Pass
Pass
D104_16.0.0.ALPHA.20120312.cfg............................Pass
Pass
D104_16.0.0.ALPHA.20120319.cfg............................Pass
Pass
D104_16.0.0.ALPHA.20120319_26Mar2012.cfg..................Pass
Pass
D104_16.0.0.ALPHA.20120326.cfg............................Pass
Pass
D104_16.0.0.ALPHA.20120326.out............................Pass
Pass
D104_16.0.0.ALPHA.20120326_superloop.cfg..................Pass
Pass
D104_16.0.0.ALPHA.20120409_PR24981_ringEveryPort.cfg......Pass
Pass
D104_16.0.0.ALPHA.20120409_superloop_0.0_0.5_1.0.cfg......Pass
Pass
D104_16.0.0.ALPHA.20120416.cfg............................Pass
Pass
D104_16.0.0.ALPHA.20120416_fullR15Config.cfg..............Pass
Pass
cfc200_14.2.0.tar.........................................Pass
Pass
cfc200_15.1.0.tar.........................................Pass
Pass
cfc200_16.0.0.RC1.20120418.tar............................Pass
Pass
ge24_14.2.0.tar...........................................Pass
Pass
ge24_15.1.0.tar...........................................Pass
Pass
ge24sfp_14.2.0.tar........................................Pass
Pass
ge24sfp_15.1.0.tar........................................Pass
Pass
x31sma_16.0.0.RC1.20120418.tar............................Pass
Pass
xe4_14.2.0.tar............................................Pass
Pass
xe4_15.1.0.tar............................................Pass
Pass
xe6sfp_15.1.0.tar.........................................Pass
Pass
1.8.3 Boot Server (Control Module Only)
Users of the system have the option of storing secure copies of software release load files on their network servers. This
assists the user in providing optimum network reliability. The boot server should be configured and the most current control
module load file should be stored there. This insures that secure load files are always available.
139
Note that boot server functionality is only available for the active control module.
Users can also configure the system to boot from the network servers where the load files are stored using the SET BOOTSERVER. It permits users to designate a server to be the system boot server. As discussed in 1.7.3, load files are stored in
FLASH memory on the control module. If the FLASH should become corrupted or the files become unusable for any reason,
the system will boot from the secure load files stored on the boot server. To ensure system recovery back to its normal
operating state, the card load files that are stored on the boot server must be a copy of the card load file designated as PREFLOAD for the control module.
Loading the system from the boot server is not intended to be the primary method for software release delivery. Rather, it is
a backup or secondary method that the system will utilize if the primary method is unusable for any reason.
To configure the boot server, the flow of commands would be.
1.
Get the preferred load using the GET FILE command.
2.
Set the preferred load using the SET CARD PREFLOAD command.
3.
Make a backup of preferred load using the COPY FILE command.
4.
Make the backup the alternate load using the SET CARD ALTLOAD command.
5.
Set the Bootserver using the SET BOOTSERVER command.
6.
Copy the current control module preferred load files, that are designated as PREFLOAD, onto the boot server using the
PUT FILE command.
The following procedure shows the commands used to configure a boot server’s IP address and the path to where the preferred CFC software load resides on server. In this example, the filename of the preferred CFC software load is
“cfc200_14.2.0.GAMMA.20100716.tar” (as previously set by the user using the SET CARD=ACTCFC PREFLOAD command). The IP address of the designated network boot server is 10.52.65.38.
TABLE 1-16
Step
Procedure - Configuring the Boot Server
Command
Description/Notes
Configure the IP address of the boot server (where preferred CFC software load resides)
1
set bootserver ipaddress 10.52.65.38
Sets the IP address of the network boot server
to 10.52.65.38
Configure the path on boot server (where preferred CFC software load is located)
2
set bootserver path x3112Files/
Sets the path (on the network boot server) to
“x3112/”
Verify the new boot server settings
3
show bootserver
------------------------------------------------------------------------------Network Boot Host IP..... 10.52.65.38
Network Boot Load........ cfc200_14.2.0.GAMMA.20100716.tar
Network Boot Path........ x3112Files/
140
1.8.4 Commands for Software Load Management
TABLE 1-17
Software Load Management Commands
Commands
SET BOOTSERVER
SHOW BOOTSERVER
141
SET BOOTSERVER
Syntax
SET BOOTSERVER=ipaddress [PATH=pathname|NONE]
Description
Sets static IP address of the network boot server. The network boot server is the source for the preferred CFC software load file. The device downloads the preferred load from the boot server via TFTP
when all boot attempts for the CFC fail from the CFC flash file system. The preferred software load is
set using the command SET CARD=ACTCFC PREFLOAD=filename. In the event the CFC cannot use
the preferred load from its own flash file system, the preferred load file is transferred from the boot
server and written to the flash, replacing any existing preferred load file for the CFC.
Mode
Manager
Options
Option
Description
Range
Default
Value
BOOTSERVER
Specifies the IP address of the network server that is the
source for the preferred CFC software load. Files are
transferred from the network server via TFTP.
NA
NA
PATH
Identifies the directory path on the network server
from which the preferred software load is retrieved.
The path on the network server includes spaces then
the entire PATH must be enclosed in double quotes (").
NA
NONE
NONE - The load is located at the root level on the
boot server.
Release Note
NA
Example
SET BOOTSERVER IPADDRESS 10.52.70.30 PATH X3112 FILES/
142
SHOW BOOTSERVER
Syntax
SHOW BOOTSERVER
Description
Displays the static IP address of the network boot server, and the preferred software load file which is
downloaded from the server when all boot attempts for the CFC fail from the CFC flash file system.
Mode
Manager
Options
NA
Release Note
NA
Example
SHOW BOOTSERVER
------------------------------------------------------------------------------Network Boot Host IP..... 10.52.65.38
Network Boot Load........ cfc200_14.2.0.GAMMA.20100716.tar
Network Boot Path........ x3112Files/
-------------------------------------------------------------------------------
143
1.9 Database and Text File Management
1.9.1 Database Management
1.9.1.1 Introduction
All configuration and provisioning changes made by the system user are stored internally in the system configuration database. The database is updated dynamically any time a configuration change is made to the system, through the normal use of
CLI commands. When the control module is restarted, it restores the system configuration from the database.
The database is stored in the control module FLASH memory, but is not a user manageable file in the FLASH system, so no
file-related CLI commands apply to it. A separate set of CLI commands is provided to manipulate the database.
For a system configured for duplex operation, a copy of the current database is located on both the active and inactive control module. Configuration changes made on the active control module are automatically written to the database and propagated to the copy of the database located on the inactive control module. As long as the control modules are operating in
synchronization, any action that results in configuration data being written to the database is reflected on both control modules. When the inactive control module is being brought online from an offline condition, its database is bulk synchronized
with the active control module.
During a normal software release upgrade, commands that manage the configuration database are executed. Summaries of
the commands follow.
1.9.1.2 Database Backup
If required, the database containing the most recent provisioning and configuration data from the active CFC would be used
to restore the system back to normal.
Note:
Keep a copy of the most recent database on a secure network server by preforming a backup after any configuration
change.
During a normal software release upgrade, the database is manually backed up if a downgrade is required after the new load
files have been committed. If a downgrade is required, a database restoration is performed.
The steps in performing a database backup include:
1.
Designate a network server for secure storage of the current configuration database
2.
Using the BACKUP DATABASE command, back up the current configuration database to the secure server.
Note:
3.
The user can specify the source of the database backup as either the RAM database contents or the database kept in
the CFC FLASH.
The user may execute the SHOW TRANSFER command to display the progress of the backup.
The following procedure shows the commands used to back up the contents of the system configuration database (located
on flash) to a secure TFTP server.
TABLE 1-18
Step
Procedure for Backing Up the Database
Command
Description/Notes
Note the IP address of the destination TFTP server on which to save backup file: 10.52.65.42.
Initiate the backup.
1
backup database file D104_17July2010.db
tftp server 10.52.65.42 source flash
Takes the system configuration database residing on local flash and saves it to the designated
TFTP server with a filename of
“D104_17July2010.db“.
144
TABLE 1-18
Step
Procedure for Backing Up the Database
Command
Description/Notes
View status of database backup.
2
Info (033752): Database backup created, transfer started
Info (033753): Database backup succeeded
1.9.1.3 Specifying Source for a Database Backup
In normal system operation, all persistent data attributes are stored in RAM memory on the CFC and dynamically written to
the system database in the onboard FLASH. However, in abnormal failure cases the data integrity of the database in the
onboard flash can become suspect, due to alarm conditions including flash memory failure or software audit failure. In these
failure cases, any attempt to backup the database would fail since the onboard flash is not reliable as a backup source.
When the onboard FLASH database integrity is suspect due to flash memory failure, the user has the option to create a
binary database file based on the RAM memory contents, since in this case the RAM data is usually still reliable as a backup
source.
If the SOURCE parameter is not specified, the default behavior is the same as in previous releases, with the source for the
database backup being the onboard flash database.
The backup operation will still fail if a database audit alarm is present, since in this case the reliability of both the RAM and
flash memory is questionable. However, in the case where flash failure is detected and an alarm is raised, the database audit is
suspended to prevent it from raising an additional alarm.
1.9.1.4 Database Purge
The PURGE DATABASE command erases the current configuration database. This command would be used if the user
wanted to reconfigure the system back to factory defaults. When the command is entered, the system reboots and recovers
with the factory defaults.
Note:
When the PURGE DATABASE command is used on a duplex configuration that is in normal (synchronized)
mode, the database on the active control module and the copy on the inactive control module will be purged.
TELNET is disabled by default, and If the user is connected through TELNET, when the database purge completes, TELNET
will be back in the default disabled mode, and the user will no longer be connected to the system. The user should therefore
connect and login to the CONSOLE interface of the control module prior to executing the PURGE DATABASE command.
Once the database is purged, and the system reboots, the system configuration database can be built by either:
• Restoring a previously backed up database (RESTORE DATABASE)
• Rebuilding the database manually using CLI commands and scripts
• Restoring a Config File
The following shows an example of the PURGE DATABASE command and the reply that the purge is completed. Note that
this example was completed at the TELNET interface and is last message before the connection was lost.
officer SEC> PURGE DATABASE FORCE
PURGE DATABASE - success
Caution: Use of the PURGE DATABASE command can cause network outages.
145
1.9.1.5 Restore Database
With the SBx3112, the user can use the RESTORE DATABASE command to replace the current database with a database
that had been previously backed up and sent to a network server. (The user should be aware of backward compatibility criteria, as explained in 1.7.2.)
During a database restore, the binary database file contents are read to the onboard flash database, and then the system will
boot up with the creation of the RAM database using the contents of the onboard flash database.
Because the database contents are read from the onboard flash database, RESTORE DATABASE FILE (SEC) is not the best
recovery procedure for a simplex system with an onboard flash failure. In this case the RESTORE CONFIG FILE (SEC) command is preferred.
RESTORE DATABASE would be the preferred recovery method if the user is replacing the CFC that has flash failure with a
known good CFC, and they had backed up from RAM to create the database file.
Note:
While the database transfer is occurring, the old database is still intact in FLASH memory, and the new database is
written to RAM. The user can abort the database restore operation while the database transfer is still in progress.
Once the database transfer is complete, the old database is erased from FLASH and the new database is written to
FLASH. The control module is then automatically restarted, and the new database is used to configure the system.
The following procedure shows the commands used to overwrite the configuration database with contents from a backup file
(transferred from an external network server).
TABLE 1-19
Step
Procedure for Restoring the Database
Command
Description/Notes
Note the IP address of the TFTP server containing the desired backup file: 10.52.65.42.
Note the filename of the desired backup file (from which to restore the system).
Initiate the restore.
1
restore database file D104_17July2010.db
tftp server 10.52.65.42
Takes the contents of the backup file named
“D104_17July2010.db“ located on the designated TFTP server and overwrites the system
configuration database in flash.
Note the warning, and type “y” to continue with database restore.
2
WARNING: Restoring the database will also reboot the CFC and may cause the system to become inaccessible. Continue (Y/N)? y
View status of database restore.
3
Info (033754): Database restore submitted with transfer ID: 7
Info (033755): Database restore succeeded; automatically rebooting...
After system reboots, log back into system.
4
Username:
Password:
1.9.1.6 Database in Upgrade Mode
During a software upgrade, a schema migration is performed, where the configuration data read from the original database in
flash memory is written to a new database. The data in the new database is converted (schema migrated) to a new format
that is compatible with the load being upgraded to. During this process, the original database is left intact in flash memory,
146
and the new database is held in RAM memory on the control module. When in this condition, the database is considered to
be in “upgrade mode”, and an alarm is raised against the control module being upgraded.
To get out of upgrade mode, the user must commit to the new load using the SET CARD command on the CM, which erases
the original database in flash memory and then copies the new database from RAM to flash memory. Alternatively, during
duplex upgrades only, upgrade mode can be cleared by doing an abort of the upgrade process, which erases the new database
in RAM memory and causes the system to revert back to the original database still in flash memory.
1.9.2 Text File Configuration
A text configuration file is a “snapshot” of the configuration database including all of the non-default configuration commands
in a text-based (rather than binary) file. The source of the data to build the configuration file was the binary database in RAM
memory, not the binary database in the onboard flash.
The advantage to having a text file is that it can be read (unlike a binary file), modified if necessary, saved, and then used to
configure (or reconfigure) this or other systems.
Note:
Since the file is in text rather than binary format, applying a configuration file will take longer (by minutes) than a
binary file.
Following are the major tasks and commands used for this feature.
1.9.3 Creating a Text Configuration file
The parameter FILE is used to write either to the local FLASH (destinationfile) or the SD (using the format SD<no.>:destinationfile).
In the case where the onboard flash file system is not reliable due to a flash write failure condition, the user also has to
option to specify another destination for the configuration file output.
The BACKUP CONFIG command therefore allows the user to specify alternative file output destinations, similar to the file
output options supported by the BACKUP DATABASE command. The file destination can be specified using an optional
parameter on the BACKUP CONFIG command. If the optional parameter is not specified, the default behavior will be to
write the output file to the onboard flash file system.
The following procedure shows the commands used to create a backup file that reflects current configuration of the system
and save it to an SD card as well as to TFTP server.
TABLE 1-20
Step
Procedure for Backing Up the Config
Command
Description/Notes
Note the IP address of the destination TFTP server on which to save configuration file: 10.52.65.42.
Note the SD card on which to save configuration file: SD4
Initiate the backup to an SD card.
1
backup config file sd4:D104.cfg
Saves the current configuration of the system to
the designated SD card (SD4) with a filename of
“D104.cfg“.
View status of database backup.
2
Info (020139): Configuration Backup Processing...
Info (020147): Configuration file "sd4:D104.cfg" successfully created.
147
TABLE 1-20
Step
Procedure for Backing Up the Config
Command
Description/Notes
Verify that configuration file was created.
3
show files sd4:
------------------------------------------------------------------------------File..................................
-------------------------------------AllMsg.log............................
D104.cfg......................... 59
DBBackupTR15.db.......................
RobSD.txt.............................
cfc200_14.1.0.GAMMA.20100203.tar......
rob.tar...............................
Size KiB
--------------------------------------207
670
<1
13359
2097
Capacity KiB.......................... 3567616
Available KiB......................... 4194303
Alternatively, the following steps show how to back up the config to a TFTP server:
4
backup config file D104.cfg tftp server
10.52.65.42
Saves the current configuration of the system to
the designated TFTP server with a filename of
“D104.cfg“.
View status of configuration backup.
5
officer SEC>>
Command has been submitted Transfer ID: 1
Info (033012): Successfully transferred file: D104.cfg
Note:
While the BACKUP CONFIG command is executing, commands that further affect the system configuration are
disallowed, with the user receiving a command rejected message. Moreover, the execution of this command may
take several minutes to complete.
1.9.3.2 Restoring a Configuration Database Using a Text Configuration File
A text configuration file can be used to populate the configuration database of a device, and can be useful during system
upgrades and downgrades. The command used to execute the file and restore a configuration database is RESTORE CONFIG
FILE (SEC).
The keyword FILE requires that a sourcefile (from FLASH) or unit:sourcefile (from CFLASH) be supplied. The optional keyword OUTPUT is recommended since this can be used to capture logs that are produced by the script.
Since the configuration file has usually been written to a remote server, the RESTORE CONFIG command will automatically
transfer the file from the remote server to the onboard flash file system, and then reboot the system using the transferred
file.
Note:
Once the text configuration file has finished running, the system will purge its current database and reboot using the
configuration reflected in the text configuration file. The user can stop this from occurring using the STOP CONFIG
file, as explained below.
Note:
RESTORE DATABASE would be the preferred recovery method if the user is replacing the CFC that has a flash
failure with a known good CFC, and they had backed up from RAM to create the database file. RESTORE CONFIG
can be used if no trusted database file is available on the remote server but a trusted config file is available. However,
RESTORE CONFIG recovers a system slower than RESTORE DATABASE.
148
The following procedure shows the commands used to restore a previously generated configuration, which was created via
the BACKUP CONFIG located on flash.
TABLE 1-21
Step
Procedure for Restoring the Config
Command
Description/Notes
Initiate the restore.
1
restore config file D104_17July2010.cfg
Overwrites the current configuration of the
system based on the contents of the configuration file named “D104_17July2010.cfg“ (located
on the local flash).
Note the warning, and type “y” to continue with database restore.
2
Database will be cleared and system will reboot.
configuration (Y/N)? y
The system may become inaccessible. Restore
View status of database restore.
3
Info (020148): Restore configuration successfully requested.
Info (033756): Database purge succeeded; automatically rebooting...
After system reboots, log back into system.
4
Username:
Password:
1.9.3.3 Stopping a Backup/Restore in Progress
Both the BACKUP and RESTORE commands take several minutes to execute, and the user may wish to stop the command
before it is complete. The command to do this is STOP CONFIG and it has the following effect:
• If entered during a BACKUP CONFIG command, STOP CONFIG throws away the configuration text file being created,
and configuration commands can be input.
• If entered during a RESTORE CONFIG command, STOP CONFIG cancels the execution of the file, closes out the log file
(if one is being output) and configuration commands can be input.
Note:
Stopping a RESTORE CONFIG should be done before the database is purged and the system reboots; otherwise, an
incorrect configuration could be installed.
1.9.3.4 Viewing the Progress of a BACKUP or RESTORE
While a BACKUP or RESTORE is in progress, the user can view the status of the file execution using the command SHOW
CONFIG STATUS. The command displays the processes that are run, and as each one is completed, it will have a 100% displayed next to it.
If a STOP CONFIG is input during a BACKUP or RESTORE, the SHOW CONFIG STATUS will show which process was
being run when the STOP CONFIG command was input, and what percentage of that process was completed. When the
text file configuration is present on the system, the system will use the text file to create the DB which it runs from. The text
file configuration will also be kept up to date as additional commands are entered into the system.
Following is an example of the SHOW CONFIG command when a STOP CONFIG command has been input during a
BACKUP CONFIG. Notice that Dsl2vnTextConfig is in the Processing state with (6.10%) complete.
officer SEC> SHOW CONFIG STATUS
--- Configuration File Progress ----------------------------------------------State.................. Backup
149
Backup Initiated....... 2010-03-25 12:52:59
Backup Completed....... In progress...
Progress Summary....... 9 of 10 complete
Backup Configuration Progress Details
User Data.............................
OA&M Configuration....................
DslagTextConfig.......................
Traffic Management....................
DsbaseTextConfig......................
DsstpTextConfig.......................
DsdhcpTextConfig......................
Dsl2vnTextConfig......................
OampNmTextConfig......................
DsigmpTextConfig......................
Complete (100.00%)
Complete (100.00%)
Complete (100.00%)
Complete (100.00%)
Complete (100.00%)
Complete (100.00%)
Complete (100.00%)
Processing (6.10%)
Complete (100.00%)
Complete (100.00%)
1.9.3.5 Editing a Text Configuration File
Once the BACKUP command has been used to create a text file of the system configuration, the file can be edited by using
the PUT FILE command to send the file to a destination (such as a server) where it can be edited. The file can then be placed
back onto the FLASH or FLASH media using the GET FILE command.
Following is an example of this sequence:
// Put file onto server
officer SEC> PUT FILE bkupcfgfl TFTP SERVER 172.16.18.50
officer SEC> Info (033012): Successfully transferred file: bkupcfgfl
// File arrives on TFTP server
TFTP Daemon started
New session created
Requested to write file bkupcfgfl in format octet
Fully expanded file specification : C:\tftp_files\bkupcfgfl
Received 4486 bytes in < 1 second
// File arrives on server
script_file_1.txt
test_script1.txt
bkupcfgfl
1 KB
1 KB
5 KB
Text Document
Text Document
File
5/1/2010 6:22 AM
6/24/2010 6:11 AM
3/26/2010 8:05 AM
// Editing the backup file on the server
// Get file from server after editing
officer SEC> GET FILE bkupcfgfl TFTP SERVER 172.16.18.50
officer SEC> Info (033012): Successfully transferred file: bkupcfgfl
1.9.3.6 Using Configuration Text Files During Upgrades/Downgrades
The text config file can be useful when performing software release upgrades, especially when upgrading hardware at the
same time. Refer to the software release upgrade sections for more information.
150
1.9.4 Database Commands
TABLE 1-22
Database Commands
Commands
BACKUP DATABASE FILE (SEC)
PURGE DATABASE (SEC)
RESTORE DATABASE FILE (SEC)
SHOW DATABASE
BACKUP CONFIG FILE (SEC)
RESTORE CONFIG FILE (SEC)
SHOW CONFIG (SEC)
STOP CONFIG (SEC)
151
BACKUP DATABASE FILE (SEC)
Syntax
BACKUP DATABASE FILE={ destinationfile | unit:destinationfile | serverpath/
destinationfile } [ { TFTP SERVER={ ipaddress | hostname } | ZMODEM | FTP
SERVER={ ipaddress | hostname } USER=userid PASSWORD=password } ] [ SOURCE={
FLASH | RAM } ]
Description
Backs up the contents of the system configuration database to a file on an external network server.
The newly created file is not user readable or writable. While transfer of data is in progress, any configuration change caused by any CLI command aborts the transfer and the backup operation is cancelled.
Mode
Sec_Off
Options
Option
Description
Range
Default
Value
FILE
The destination filename to use for creating the backup.
The system does not require the filename to have an
extension, nor does it place restrictions on an extension
(if specified).
NA
NA
Note: If the filename already exists on the destination
media (e.g., SD card, server), the system will overwrite
the contents of that file.
TFTP_Server
NA
NA
ZMODEM
NA
NA
FTP_Server
NA
NA
USER
NA
NA
PASSWORD
NA
NA
SOURCE
The source of the database file. It can be directly from
RAM or from the flash memory.
NA
FLASH
Release Note
NA
Example
BACKUP DATABASE FILE D104_17JULY2010.DB TFTP SERVER 10.52.65.42
152
PURGE DATABASE (SEC)
Syntax
PURGE DATABASE [ALL][FORCE]
Description
Purges all contents in the system configuration database and then automatically restarts the CFC. After
the restart, the database is repopulated only with factory default configuration.
The configuration must be restored through individual CLI commands, or read from a script file using
the EXECUTE SCRIPT command, or by restoring the database contents from a network server using
the RESTORE DATABASE command.
Mode
Sec_Off
Options
Option
Description
Range
Default
Value
ALL
In addition to the system configuration database, the following NVRAM parameters are reset to their defaults:
NA
NA
NA
NA
SET IP INTERFACE MGMT IPADDRESS=x SUBNETMASK=y
x=192.168.1.1
y=255.255.255.0
SET SYSTEM GATEWAY=x
- x=<none> ("0.0.0.0")
SET SYSTEM TIMEZONE CUSTOM UTCOFFSET=x
- x=+00:00
SET BOOTSERVER IPADDRESS=x PATH=y
- x=<none> ("0.0.0.0")
- y=""
Boot ROM password
- "friend"
FORCE
Overrides the user confirmation.
Release Note
NA
Example
PURGE DATABASE FORCE
153
RESTORE DATABASE FILE (SEC)
Syntax
RESTORE DATABASE FILE={sourcefile|unit:sourcefile|serverpath/sourcefile}
[{TFTP SERVER={ipaddress|hostname}|ZMODEM| FTP SERVER={ipaddress|hostname}
USER=userid PASSWORD=password}] [FORCE]
Description
Rewrites the configuration database with contents from a file transferred from an external network
server. While the data is transferred from the server, it is buffered in RAM memory in the CFC and not
written to the flash. If the transfer fails or is aborted, the existing database is retained. If the file transfer is successful, then the database in flash memory is automatically purged and rewritten with the new
contents. Once the flash memory write completes, the CFC automatically restarts to apply the
updates from the database. * This command impacts service if completed successfully * User warning
confirmation is required unless overridden with the FORCE option.
Mode
Sec_Off
Options
Option
Description
Range
Default
Value
FILE
The filename identifying the database file that is located
either on the CFC SD card or on the server that is designated by the path.
NA
NA
TFTP_Server
NA
NA
ZMODEM
NA
NA
FTP_Server
NA
NA
USER
NA
NA
PASSWORD
NA
NA
FORCE
Overrides the user confirmation.
NA
NA
Release Note
NA
Example
RESTORE DATABASE FILE D104_17July2010.db TFTP SERVER 10.52.65.42
WARNING: Restoring the database will also reboot the CFC and may cause the system to become
inaccessible. Continue (Y/N)? y
Info (033754): Database restore submitted with transfer ID: 7
Info (033755): Database restore succeeded; automatically rebooting...
Username: officer
Example
Password:
154
SHOW DATABASE
Syntax
SHOW DATABASE
Description
Shows the system configuration database utilization information to the user.
Mode
User
Options
NA
Release Note
NA
Example
E134 - officer SEC>>>> SHOW DATABASE
--- Database Information -----------------------MAX Record Storage in Bytes
Percent Record Storage Utilized
Largest Free Record Available
Maximum Number of Entries
Percent Entries Utilized
Cache or Flash
:
:
:
:
:
:
6291456
10%
4299251
100000
00%
Flash
-------------------------------------------------
155
1.9.5 Commands for Text File Configuration
TABLE 1-23
Text File Configuration Commands
Commands
SHOW CONFIG (SEC)
STOP CONFIG (SEC)
156
Syntax
BACKUP CONFIG FILE={ destinationfile | unit:destinationfile | serverpath/destinationfile } [ { TFTP SERVER={ ipaddress | hostname } | ZMODEM | FTP
SERVER={ ipaddress | hostname } USER=userid PASSWORD=password } ]]
Description
Allows the user to create a configuration file which reflects current configuration of the system. This
configuration file can be used to recreate the configuration on the same or similar system, using the
RESTORE CONFIG command.
Mode
Sec_Off
Note
While the BACKUP CONFIG command is executing, commands that further affect the system configuration are disallowed, with the user receiving a command rejected message. Moreover, the execution
of this command may take several minutes to complete.
Options
Option
Description
Range
Default
Value
FILE
The destination filename to use for creating the backup
on the CFC flash, an SD card, or a server designated by
the path. The system does not require the filename to
have an extension, nor does it place restrictions on an
extension (if specified).
NA
NA
Note: If the filename already exists on the destination
media (e.g., SD card, server), the system will overwrite
the contents of that file.
TFTP_Server
NA
NA
ZMODEM
NA
NA
FTP_Server
NA
NA
USER
NA
NA
PASSWORD
NA
NA
Release Note
NA
Example
BACKUP CONFIG FILE D104_17JULY2010.CFG
157
Syntax
RESTORE CONFIG FILE={ sourcefile | unit:sourcefile } [ { TFTP SERVER={ ipaddress | hostname } | ZMODEM | FTP SERVER={ ipaddress | hostname } USER=userid
PASSWORD=password } ] [ OUTPUT={ CONSOLE | logfile | unit:logfile } ]
Description
Allows the user to restore a previously generated configuration, which was created via the BACKUP
CONFIG command. During the processing of RESTORE CONFIG, the current data is purged, the system is rebooted, and the configuration is then restored by executing the commands in the configuration file that is provided with the FILE parameter. The OUTPUT parameter indicates the destination of
the responses to the commands executed. If the OUTPUT parameter is not provided, the responses
to the commands are not recorded or displayed. To monitor the progress of the RESTORE CONFIG
command, the user may run the SHOW CONFIG STATUS command.
Mode
Sec_Off
Note
While the BACKUP CONFIG command is executing, commands that further affect the system configuration are disallowed, with the user receiving a command rejected message. Moreover, the execution
of this command may take several minutes to complete.
Options
Option
Description
Range
Default
Value
FILE
The filename identifying the configuration file that is
located either on the CFC SD card or on the server
that is designated by the path.
NA
NA
TFTP_Server
NA
NA
ZMODEM
NA
NA
FTP_Server
NA
NA
USER
NA
NA
PASSWORD
NA
NA
OUTPUT
Indicates the destination for the responses to the executed commands:
NA
CONSOLE
CONSOLE - the output of the command execution is
displayed on the CLI console.
logfile (unit:logfile) - the filename of the log file to which
command execution output is saved during the restore
process. The maximum length of the filename is 100
characters.
Note: If the OUTPUT parameter is not provided, the
output from the commands are not recorded or displayed.
Release Note
NA
Example
RESTORE CONFIG FILE D104_17JULY2010.CFG OUTPUT CONSOLE
158
SHOW CONFIG (SEC)
Syntax
SHOW CONFIG <STATUS>
Description
Allows the user to view the current configuration information or to monitor the progress of a currently running BACKUP CONFIG or RESTORE CONFIG command. If the STATUS parameter is provided, the current or previous status of a BACKUP CONFIG or RESTORE CONFIG is displayed.
Without the STATUS parameter, the current configuration information is generated and displayed to
the user.The status information is not saved over reboots of the system.
Mode
Sec_Off
Options
Release Note
Option
Description
Range
Default
Value
STATUS
If the STATUS parameter is provided, the current or
previous status of a BACKUP CONFIG or RESTORE
CONFIG is displayed.
NA
NA
NA
Example
voip2-iMAP4-x3112>> SHOW CONFIG
-----------------------------------------------------------------------------# script
#
# Version: 14.2.0.GAMMA.20100803
# File created: 2010-08-12 15:38:29
DISABLE MORE
#
#
SET SYSTEM USERCONFIG LOGINFAIL=3 LOCKOUTPD=60 MANPWDFAIL=3 SECUREDELAY=0
MINPWDLEN=6 PERSISTTIMER=1440 PWDAGEING=OFF FORCEPWDCHANGE=No
ENABLE USER=officer
ENABLE USER=manager
SET USER=officer PASSWORD=D31D86D0DE8DD34FC535C67E480DEAA2 FORMAT=MD5
DESCRIPTION="Security Officer User" PRIVILEGE=SECURITYOFFICER TELNET=Yes
PWDAGEING=OFF DEACTIVATE=OFF
SET USER=manager PASSWORD=3AF00C6CAD11F7AB5DB4467B66CE503E FORMAT=MD5
DESCRIPTION="Default User" PRIVILEGE=SECURITYOFFICER TELNET=Yes PWDAGEING=OFF
DEACTIVATE=OFF
(ouput continues)
159
STOP CONFIG (SEC)
Syntax
STOP CONFIG
Description
Allows the user to cancel a BACKUP CONFIG or RESTORE CONFIG command that is currently in
progress. If neither is currently in progress, no action is taken.
Mode
Sec_Off
Options
NA
Release Note
NA
Example
STOP CONFIG
160
1.10 Control Module Management
When creating or changing the attributes of a card, the type of load must be considered, especially when doing a software
upgrade.
1.10.1 Card Load Preferences
Once a software load is present in the control module FLASH file system, it can be designated as the target software load for
one or more cards using the parameters of the SET CARD command. One or more of the following types of designations
can be set for a card:
• Preferred - selected using the PREFLOAD parameter. A load designated as PREFLOAD indicates that this is the primary load that the specified card will load from. For system integrity reasons, load files designated as PREFLOAD cannot
be renamed or deleted. Any changes made in load designations, for a system configured for duplex operation, while the
system is operating in sync, will be reflected on both the ACTCFC and INACTCFC.
• Alternate - (Control Module Only) selected using the ALTLOAD parameter. A load designated as ALTLOAD indicates that this is the alternate load that the specified CM will load from. The ALTLOAD is used when a redundant copy
of the preferred load file is made on the CM FLASH file system; it specifies an alternate load preference for the redundant
file. Establishing an alternate load provides a backup in the unlikely event that the preferred load file cannot boot. For a
duplex system configuration, any changes made in the ALTLOAD designation apply to both the active (ACTCFC) and
inactive (INACTCFC) control modules.
Note:
This parameter is not supported for the service modules because the copy of the service module load stored on the
control module FLASH file system is the alternate by default (the preferred is the copy located in the service module
flash memory).
• Temporary - selected using the TEMPLOAD parameter. A load designated as TEMPLOAD indicates that this is the
load that the specified card will load from, one time, during the next loading process. The TEMPLOAD designation is
used during the software upgrade procedure.
TEMPLOAD designation results in two things. First, if for any reason the new load file is unusable, the system will erase
the designation of TEMPLOAD for the new file and revert back to using its original load, allowing the system to automatically recover from an initialization failure of the TEMPLOAD. Second, setting a load as TEMPLOAD puts the configuration into the upgrade mode. For upgrade purposes, changes made to the designation of temporary are independent of
system synchronization status.
Note that load preferences for the CFC(s) are stored in the non-volatile RAM (NVRAM) of each module, while load preferences for the Line Cards are stored in the configuration database, explained in 1.8.1.
Note:
An Inconsistent Load Minor alarm will be posted against any service module whose running major and minor
software load version does not match the preferred major and minor software load version of the active control
module. The alarm is raised whenever the CM is taken out of upgrade mode. This is intended to maintain
consistency of load versions throughout the system.
1.10.2 CFC for the SBx3112
The following modes and CFCs are available:
For the SBx3112 (200G) the CFC200 supports simplex and duplex mode. Note that in duplex mode, each CFC200 switches
traffic in a load sharing mode thereby doubling the system throughput to 400G. Note that for this capacity both CFCs must
be in service.
1.10.3 Overview (Simplex versus Duplex)
For the SBx3112 in simplex mode there is one Control Module, and it is called the active CFC: it has the only copy of the
configuration database, and if the CFC restarts, service is temporarily lost.
161
When a SBx3112 is in duplex mode, one of the CFCs is redundant. Because the default for the shelf is AutoProv, the newly
inserted CFC is discovered and provisioned and comes up as the inactive CFC. The system is now equipped with an active
and inactive CFC; referred to on the system as ACTCFC and INACTCFC, respectively, and the inactive keeps a copy of
the persistent data and dynamic data, as well as the software load on the active CFC. Moreover, the inactive receives incremental updates from the active CFC, called data synchronization, or data sync. This ensures there is matching data (called
data mirroring) in both CFCs.
Because of this mirroring, the inactive CFC can take over the shelf if there is a fault in the active CFC. This is called a swap
activity or a swap; all persistent and transient data is retained, so the Allied Telesis duplex system can continue to process
subscriber services as well as receive requests and produce outputs to the management interfaces, including the alarms associated with the swap.
The above explanation of the SBx3112 in duplex mode assumes that both CFCs are functioning normally prior to the degradation of the active CFC, that all data and software loads have synched, and that the inactive CFC has been successfully mirroring data up to the swap and has no alarms. There are situations where these conditions do not exist, and these can be
created by the user (such as disabling the inactive CFC), or autonomously. These will be explained below.
The following shows the output for the SHOW CARD ACTCFC and SHOW CARD INACTCFC commands.
manager SEC>> show card actcfc
--- Card Information --Slot...............................
Type...............................
State..............................
Provisioning Profile...............
5
CFC200
UP-UP-Online (Active)
AutoProv
Hardware
Model Number (Revision)......... AT-SBxMFC (Rev X2)
Serial Number................... 43
CLEI Code....................... <none>
Software
Running Load....................
Preferred Load..................
Temporary Load..................
Alternate Load..................
cfc200_14.2.0.GAMMA.20100722.tar
cfc200_14.2.0.GAMMA.20100722.tar
None
None
Software Build Information
Load File.......................
Build Name......................
Build Type......................
Revision........................
Built On........................
Boot ROM Build Name.............
cfc200_14.2.0.GAMMA.20100722.tar
Customer-Release Build
14.2.0.GAMMA.20100722
Thu 07/22/2010 at 03:05 PM
ATI 200G Central Fabric Controller Boot
Loader
Boot ROM Version................ 14.1.g.01
Card Type Specific Information
Timing Reference................ N/A
1.10.4 CFC200 Card Attributes and States (SHOW
CARD ACTCFC)
Table 1-24 describes the common attributes and states for the CFC card.
.
TABLE 1-24
CFC200 Card Attributes - Defaults are in Bold
CFC Card Attribute
Values / Range
Description
Slot
Slot Number of the CFC card
The identifying slots of the CFC card (slots 4 and 5).
Type
Card Type
The type of card, here the CFC200
162
TABLE 1-24
CFC200 Card Attributes - Defaults are in Bold (Continued)
CFC Card Attribute
Values / Range
Description
State
Three attributes:
These three attributes determine the state of the card;
whether it is capable of carrying traffic and the status
(Implied Operational Status)
- Admin State
- Operational State
- Status
Also, the CFC200 can be Active
or Inactive. When the Inactive
has an Operational status of UP,
it provides traffic switching
capacity (200G) and can take
over if the active CFC has a fault.
(The system is then in Simplex
mode.)
ONLINE - Card is configured and can provide service.
(UP)
DEGRADED - There is a fault but the card can still provide service (UP). If this is the status of the active CFC
and the inactive is in an ONLINE status, a switch of activity may occur.
OFFLINE - The normal status when a card is in a
DOWN state. The card requires a routine operation to
place it ONLINE and available for service. (DOWN)
CARD NOT PRESENT - For the Inactive CFC only, The
card is provisioned and enabled, but the card is not present.
FAILED - The card has detected a hardware or software
fault that makes it unable to provide service. (DOWN)
The system is now in simplex mode.
NOT INSTALLED - Card is provisioned in software
(CREATE) but not physically present (DOWN)
NOT PROVISIONED - For the inactive CFC200 card,
the card may be physically installed but has not been provisioned in software (CREATE).
RESET - Transient state as card resets (DOWN)
LOADING - The software load is being transferred from
the CFC to the flash memory in the card. (DOWN)
BOOTING - The software load is being copied from the
flash memory into its RAM memory. (DOWN)
INITIALIZING - Card is being initialized as part of
attempt to restore it to service (DOWN)
CONFIGURING - Provisioning data for he card is being
copied from the CFC to the RAM memory on the card.
(DOWN)
TERMINATING - The card is performing an operation in
preparing to go out of service. (UP or DOWN)
Provisioning Profile
Profile that has been applied to
the card and if there is a Profile
mismatch.
If there is a Profile mismatch, a (*) appears next to the
Profile Name. Refer to 1.16.5.
Hardware
Model Number
The AT number for card type
Serial Number
The unique serial number for the card
CLEI Code
The CLEI code, if the card has one.
163
TABLE 1-24
CFC200 Card Attributes - Defaults are in Bold (Continued)
CFC Card Attribute
Values / Range
Description
Software
Running
Refer to 1.10.1.
Preferred SW Load
Temporary SW Load
Alternate Load
1.10.5 Changing the Administrative State of the Inactive CFC
When both CFC cards are functioning properly, the inactive CFC has an Admin and Operational Status of UP and data is
synched so it can take activity if necessary. However, it is possible to change the state of the inactive CFC so that normal
duplex operation does not take place and the inactive CFC cannot assume activity.
Caution: Data traffic capacity is reduced from 400g to 200G.
You can do this ny disabling the inactive CFC (i.e. DISABLE CARD=5)
The inactive CFC now cannot take over activity, and the card goes through the following changes:
• Admin State - DOWN, since the CFC is now disabled.
• Operational State - DOWN, since the Operational State follows the Admin State.
• STATUS - OFFLINE, since the card is disabled and is no longer synching with the active CFC.
Note:
The Admin State and Op State of the active CFC will always be UP.
When the inactive CFC is disabled, data sync is no longer occurring between the two CFCs. To bring the inactive (and disabled) CFC back into service and have it receive the data stored on the active CFC so it can take over the shelf, enable the
card. (This can be done by entering ENABLE CARD INACTCFC or pressing the reset button on the inactive CFC.)
The inactive CFC now reboots, and goes through the following steps before it can return to normal operation for traffic load
sharing and redundancy protection (Admin and Operational States are UP).
1.
Status sequence - This is the most important attribute, and it is a sequence that shows the progress of data sync with the
active CFC. During data sync, the status is Initializing, and the Admin State and Operational State continue to be
DOWN, since the card cannot provide service yet. Once data sync is complete, the inactive card states change to normal:
2.
Admin State - UP, since the card now is synched to the active CFC and is enabled.
3.
Status - IN TEST, since the inactive CFC is running diagnostics on itself to ensure it has no faults and is ready to go
into service
4.
Operational State - UP, since the CFC will now be able to take over the shelf if it can sync with the active CFC and has
no faults.
Note:
Whenever the inactive CFC reboots, it assumes that the active CFC is functioning normally during the reboot
process; this ensures the inactive will not come up as the newly active CFC if the currently active CFC were to fail
during the reboot. Moreover, in assuming the active CFC is functioning normally during the reboot, the inactive CFC
will wait for the active CFC to establish communications and begin the data sync. However, if the inactive card
detects that the active card is no longer providing service (rebooting, failed, removed), the inactive card will start a
5 minute timer. If the timer expires, the inactive CFC will try to come into service as the active using its own
(possibly not current) data.
1.10.6 Redundant CFC Operation in the SBx3112
The SBx3112 duplex configuration each CFC200 switches traffic in a load sharing mode thereby doubling the system
throughput to 400G.
164
Audits are performed after a switchover, to ensure that the CFC and Line Cards are in sync. There is the potential for the
cards to be out of sync if, for example, a change to the mirroring was in progress during the switchover.
For full packet throughput both CFCs must be installed and operational. The CFCs will provide a level of redundancy allowing
the system to survive one of the CFCs being removed, although with a reduction to half the backplane bandwidth.
The system will still switch at full duplex capacity (400Gbps) whenever both CFCs are in sync during software upgrade,
where one of the CFCs is in upgrade mode. However, during the restart of the CFC for loading the new software, there will
be a reduction in backplane bandwidth since that CFC is temporarily not providing service.
1.10.7 Provisioning Scenarios for Control Modules
1.10.7.1 Overview
The following procedures are used when changing the SBx3112 mode from simplex to duplex (one always active CFC to an
active and inactive CFC) or duplex to simplex (an active and inactive CFC to only one always active CFC). Both types of procedures can be done in AutoProv or Manual mode.
Note:
To minimize the possibility of loss of service, all procedures to change the CFC configuration involve inserting or
removing the inactive CFC. Ensure that all of the commands used in this section apply to the currently inactive CFC.
If the slots the user wishes to provision involve the CFC that is currently active, perform a Swap Activity to make it
the inactive CFC.
1.10.7.2 Simplex to Duplex (AutoProv Mode)
When the Allied Telesis system is in simplex mode, one of the slots (4,5) will contain a filler plate. Changing the mode from
simplex to duplex is done as follows:
1.
Remove the filler plate from either Slot 4 or 5.
2.
Remove the new CFC card from its antistatic container.
3.
Following antistatic procedures, insert the CFC card into the available slot. Refer to the Installation Guide for details.
4.
Because the CFC cards are in AutoProv mode, the active CFC will detect the newly inserted CFC and try to provision it,
synch all of its data with the inactive CFC (bulk sync), and then bring the CFC into service (an Admin and Operational
State of UP, a status of ONLINE, and a status of INACTIVE).
1.10.7.3 Duplex to Simplex (AutoProv Mode)
In AutoProv mode, whenever a CFC card is physically present, the system will try to bring the CFC card into service (perform data sync). Therefore, the card must be disabled and then physically removed. Follow these steps:
1.
Disable the inactive CFC (DISABLE CARD INACTCFC)
2.
Follow antistatic procedures and remove the inactive CFC from its slot and place in an antistatic container.
3.
With the inactive CFC card now removed, delete the card from the configuration database (DESTROY CARD INACTCFC).
4.
Insert a filler plate into the empty slot for optimum system cooling. (Line Cards are not allowed in the unused slot in
14.2.)
1.10.7.4 Simplex to Duplex (Manual Mode)
When the Allied Telesis system is in simplex mode, one of the slots (4 or 5) contains a filler card. Moreover, because the CFC
is in manual mode, the CFC must be explicitly created and enabled, as shown in the following steps:
1.
Follow antistatic procedures and remove any Filler Plate Full card(s) in slots 4 or 5.
2.
Remove the CFC card from its antistatic container.
3.
Follow antistatic procedures and insert the CFC card into the available slot. Refer to the Installation Guide for details.
165
4.
Because the CFC cards are in Manual mode, the slot will have a status of NOT PROVISIOINED. The card must therefore
be provisioned using the command:
CREATE CARD=4 <CFC200>
or CREATE CARD=5 <CFC200>
5.
The card is now provisioned in the configuration database, but must change its Admin State to UP to sync with the active
CFC, and to try to go into service. The default for the manual mode is when cards are created, ENABLED=UP, so no
additional actions are needed. If this has been changed, enter the ENABLE CARD=INACTCFC command.
6.
The newly enabled CFC will boot, sync all of its data with the active CFC (bulk sync), and then bring the CFC into service
(an Operational State of UP, a status of ONLINE, and a state of INACTIVE).
1.10.7.5 Duplex to Simplex (Manual Mode)
In Manual mode, the CFC card can be physically present and the shelf will not try to create and enable the card. Therefore,
the card does not need to be removed before deleting it from the database. Follow these steps:
1.
Disable the inactive CFC (DISABLE CARD=INACTCFC).
2.
Delete the card from the configuration database (DESTROY CARD=4 or DESTROY CARD=5).
3.
Follow antistatic procedures and remove the inactive CFC from its slot and place in an antistatic container.
4.
Insert a filler plate into the empty slot for optimum system cooling. (Line Cards are not allowed in the unused slot in
14.2.)
1.10.8 Software Compatibility
A software release will retain backward compatibility with certain releases that preceded it (i.e., up to one major release
back). Backward compatible means that database data -- that was saved in flash memory using an older software release -- will
be restorable when the newer software release is loaded. This allows for a software upgrade to occur without requiring the
entire system database to be recreated.
Backward compatible also means that a card using a given software release can communicate with another card using an older
software release.
Caution: The SBx3112 supports restoring the system configuration using the configuration (text) file from an earlier
software release. However, it is only recommended for users that are very knowledgeable about CLI commands
and syntax. Due to differences that may exist between the commands in the current software release and those of
the older release, the configuration file may require editing before initiating the restore. Otherwise, the restore
may result in unpredictable configuration results.
An understanding of software upgrades and interim upgrades is important to the concept of backward compatibility. An
upgrade where system load files are changed in order to add new, significant feature functionality is called a software
upgrades. For example, an upgrade from release 14.0.0 to 15.0.0. An upgrade where system load files are changed in order
to possibly add minor feature functionality and software fixes is referred to as an interim upgrade. For example, an upgrade
from release 14.1.1 to 14.1.2. During an interim upgrade, no schema migration is to be performed on the configuration database. Also, during the interim upgrade, no Database in Upgrade alarm is raised.
Software upgrades and interim upgrades will be reemphasized in each of the system upgrade procedure sections.
Backward compatibility is unidirectional; a newer load may be able to understand data that originates from an older load, but
the reverse (i.e., forward compatibility) is not necessarily true.
The rules for backward compatibility are:
• Interim-release changes have no effect on backward compatibility. For example, release “14.1.1” is fully backward
compatible with release “14.1.0”. Any release that is backward compatible with release “14.1.1” is also, by extension,
compatible with release “14.1.0”.
• Backward compatibility is supported between any two releases that share the same major release number. For example, release “14.1.1” is backward compatible with release “14.0.1”.
166
• If a software release has a minor release number of “0” (zero), it is backward compatible with any releases in the previous major release. For example, release “15.0.1” is backward compatible with release “14.1.0”.
In cases where a direct upgrade is not supported, a multi-step upgrade process may be used. The user must first upgrade to
the interim release, and then upgrade to the desired release.
Note:
Only the control module card (not the service modules) has this backward compatibility logic. Therefore, a control
module running a newer software load is compatible with a service module running an equivalent or older load, but
a control module running an older release load is not compatible with an service module running a newer release
load.
Note:
The third digit, for patches, is automatically compatible for upgrade. For any anomalies, refer to the specific Release
Notes.
Any CM load supports its major release load and the same release for Line Cards. Also, any CM load supports one major
release back on Line Cards for the purpose of upgrading. The following figure shows the compatibility hierarchy.
15.2
15.1
15.0
Current Release
{
FIGURE 1-7
14.2
14.1
14.0
{
New Release
Compatibility Hierarchy
1.10.9 Software Upgrade
To upgrade the system to a new software release, load files can be remotely loaded into FLASH memory and then individually
selected for use at runtime. Along with the user commands described earlier in this manual, there are comprehensive commands provided to examine the state of the FLASH memory and to load, view, and remove release files. There are also commands provided to install, query, and activate the software on each card, at which time the software is booted into RAM
memory and executed.
The latest software release files are available from Allied Telesis. For the latest software loads go to
http://www.alliedtelesis.com/support/software/restricted/login.aspx
You should have an account with an email address and password.
The general steps are:
1.
If not already done, set up the MGMT/Inband interface and network servers. Refer to Section 1.6.4
2.
Do SHOW SYSTEM or SHOW CARD ACTCFC SOFTWARE to see what CFC load is used.
3.
Compare current system loads with the latest load’s information.
4.
If the loads are the same, no action is required.
5.
If the loads are not the latest, contact ATI to obtain them.
167
1.10.9.2 Software Upgrade Procedure - Overview
A software upgrade involves obtaining new load files. Next, the loads are stored in FLASH on the CM. The boot status of the
new loads is set to TEMPLOAD. The user then executes a restart on the control module. The user verifies that the new
loads are working correctly. The user must commit, then downgrade if necessary.
Commit means that the user chooses to accept the new loads as the new system load files. After setting the loads as PREFLOAD, the system will boot from these loads until new loads are set as PREFLOAD.
The user can choose to perform a downgrade after a software upgrade has been completed. The user may revert back to the
original load files and database, but any changes made to the new database are lost.
1.10.9.3 Simplex Upgrade Procedure
This is a walkthrough of a software upgrade for a simplex CFC200. It is assumed that the system is running in a stable state.
TABLE 1-25
CFC200 Simplex Software Upgrade Steps
Step
State or Action
Details
1.
Pre-Upgrade Configuration
Checking the Allied Telesis website, find the latest loads for the hardware
and software release this upgrade will support and download these to the
network server so that they may be copied if necessary.
Note:
2.
Back up the current database:
BACKUP DATABASE
3.
Retrieve the new load files for
the CFC and Line Cards from
the network server and store
them in FLASH on the CFC
card.
For both the CFC and Line Cards, ensure that all
PREFLOADs are set to the current load. This
ensures that the database that is backed up (in the
step below) can correctly allow the user to perform a
downgrade or abort the upgrade if necessary.
For network reliability purposes, backup the existing configuration database to the external network server using the BACKUP DATABASE
command. Refer to Section 1.9.
Follow these steps to get the latest CFC and Line Card load files and set
them as the TEMP load.
1 Ensure the latest loads are on the network server.
2. Transfer the new loads from the server to the control module FLASH
(Refer to 1.7.4.)
- GET FILE <load> tftp server 10.52.65.42
3. Set the new CFC load as the TEMP load for the CFC200.
- SET CARD=ACTCFC TEMPLOAD=<latest CFC200 load>
4. Set a new Line Card load as a Temp load for verification testing
- SET CARD=<slot-list> TEMPLOAD=<latest Line Card
load>
4.
Execute a restart on the CFC
card
Restart the card with the command:
RESTART CARD=ACTCFC COLD
The CFC200 and Line cards reboot to the new loads and recover.
The database contains all the original configuration, schema-migrated to
the new load, and held in CFC200 RAM during this step only. The original
database is still intact in FLASH memory.
168
TABLE 1-25
CFC200 Simplex Software Upgrade Steps (Continued)
Step
State or Action
Details
5.
Run any verification tests.
After step 4 is completed, the system will be in a “Database in
upgrade mode” alarm condition unless this is an Interim Upgrade (See
Section 1.10.8).
Note:
6.
Commit to the new load:
Set the CFC200 card with the
new load file as the preferred
load.
Whenever the active CFC is in upgrade mode, all
commands are allowed, but a warning is displayed
to remind the user that the system is in upgrade
mode and changes are not being saved to FLASH
memory until the upgrade is committed to (see Step
6.)
The new load is set as PREFERRED so that on the next reboot the new
load will be loaded.
SET CARD=ACTCFC PREFLOAD=<latest CFC load>
The new schema-migrated database is now written into FLASH memory.
The old database is erased. The upgrade mode alarm is cleared.
If the user is sure they are not going to perform a downgrade, the original
CFC loads can be deleted with the DELETE FILE command.
7.
Back up the current database:
BACKUP DATABASE
For network reliability purposes, backup the existing configuration database to an external network server using the command:
BACKUP DATABASE (Refer to 1.9.1.2)
169
1.10.9.4 Simplex Downgrade Procedure
To revert back to the original load files after they have been committed to, a downgrade must be performed. The user must
fully commit to the upgrade before performing a downgrade. Load preferences must be set to the new loads.
Note:
Any configuration changes completed while the upgrade was in progress will not be saved to the database
if a downgrade is performed.
TABLE 1-26
Simplex Software Downgrade Steps
Step
State or Action
Details
1.
Obtain the original load files.
If the original load files are not in FLASH on the CFC200, obtain copies
and put them in FLASH on the CFC200. (Refer to 1.7.4).
2.
Set the original load files as PREFLOAD.
Set the original CFC load files to PREFERRED.
SET CARD=ACTCFC PREFLOAD=<original CFC200 load>
Line Card load preferences are saved on the database and will be taken
from it after it has been restored.
Restore the original database.
3.
Restore the original database. (Refer to 1.9.1.5.)
The user inputs the command:
RESTORE DATABASE
During this process, the database reverts back to its original configuration data, the CFC200 restarts, and the CFC200 and Line
Cards revert back to their original loads.
1.10.9.5 Duplex Upgrade Procedure
By taking advantage of redundant control modules provided by the duplex configuration, software upgrades on a duplex system are not service affecting for the control modules.
Note:
Service is affected when performing upgrades on Line Cards. Video, data, and voice traffic will be affected.
Also, for brief periods swtiching capacity is reduced from 400G to 200G
Following is a detailed walkthrough of a duplex software upgrade for the CFC200 duplex system. It is assumed that the system is running in a stable state
.
TABLE 1-27
Duplex Software Upgrade Steps
Step
State or Action
Notes
1.
Pre-Upgrade Configuration
Obtain the latest loads from Allied Telesis. Contact Allied Telesis for load
information. Download the loads to the network server so that they may
be copied if necessary.
2.
The user backs up the current
database using the BACKUP
DATABASE command.
For network reliability purposes, backup the existing configuration database to the external network server using the BACKUP DATABASE command. (Refer to Section 1.9.)
3.
The user retrieves the new load
files from the network server
using the GET FILE command.
Transfer the new load(s) from the server to the control module FLASH
They are stored in FLASH on
both control modules
Ensure the latest load is on the network server as explained in Step 1.
- get file <load> tftp server 10.52.65.42
The loads are automatically transferred to the INACTCFC.
170
TABLE 1-27
Duplex Software Upgrade Steps (Continued)
Step
State or Action
Notes
4.
The user sets the new control
module load as TEMPLOAD on
the inactive CFC (INACTCFC)
using the SET CARD command.
Set the new CFC load as TEMPLOAD for the INACTCFC.
Execute a restart on the inactive
control module.
Restart the inactive CFC by using either:
Note the resulting state as a
result of restarting the inactive
CFC.
The inactive control module recovers on the new load.
5.
6.
- SET CARD=INACTCFC TEMPLOAD=<latest load>
- RESTART CARD INACTCFC
Certain CLI commands are not available at this point in the upgrade
(unless this is an Interim Upgrade).
An Out of Sync alarm may be raised on the INACTCFC informing the
user that synchronization with the ACTCFC is in progress. Wait until this
alarm has cleared before proceeding with the upgrade.
Note: A Database in Upgrade alarm is raised on the INACTCFC
informing the user that an upgrade is in progress. The system will be in
an alarm condition unless there is no schema migration to be performed (Interim upgrade).
7.
Switch activity and activate the
new control module load.
Input the command:
- SWAP ACTIVITY
The active control module releases activity, The previously inactive control module takes activity and becomes the active CFC with the new load.
The newly inactive does not reboot, however, so no database changes are
synchronized to it.
Note:
8.
Upgrade at least 1 Line Card and
perform any verification tests.
Whenever the active CFC is in upgrade mode, all
commands are allowed, but a warning is displayed to
remind the user that the system is in upgrade mode
and changes are not being saved to FLASH memory
until the upgrade is committed.
The user upgrades one or more Line Cards for verification test purposes.
The user does this by setting the new load as temporary, so the module
will boot using the new load.
SET CARD=<slot(s) with Line Card> TEMPLOAD=<latest
load>
The user then loads the temp load into the Line Card(s) by restarting the
line Card(s)
RESTART CARD=<slot-list>
9.
New Load Verification
The user executes new load verification testing.
Once testing is complete, the user may accept the new loads and commit
to them or not ac
cept them and abort back to the original loads.
To abort - go to Step 10, Abort the Upgrade.
To commit - go to Step 11, Commit to new loads.
171
TABLE 1-27
Duplex Software Upgrade Steps (Continued)
Step
State or Action
Notes
10.
Abort the Upgrade
To abort the upgrade at this point, input the command:
SWAP ACTIVITY FORCE
Reload the Line Card (s) that was upgraded in Step 8 with the original load
and restart the Line Cards.
SET CARD=<slot(s) with Line Card> TEMPLOAD=<old
load>
RESTART CARD=<slot-list>
The active control module releases activity.
The previously inactive control module takes activity and becomes active
with the original load. The previously active control module restarts and
syncs up with the newly active one.
The system is now running on the original CFC loads and database.
11.
Commit to new loads
To commit to the new loads, set them as Preferred for the control module
and service modules using the SET CARD <card> PREFLOAD <loadname> command. The Database in Upgrade alarm is cleared and the
inactive reboots with the new load and re synchronizes to the active CM.
Immediately upgrade the remaining service modules.
Note:
The user should not attempt to perform any
maintenance activity on the INACTCFC until it
has re-synchronized with the ACTCFC. The
possibility of load corruption could occur on the
INACTCFC rendering it out of service.
Note:
An Inconsistent Load Minor alarm will be posted
against any Line Card whose running major and
minor software load version does not match the
preferred major and minor software load version
of the active CFC. The alarm is raised whenever
the CFC is taken out of upgrade mode. This is
intended to maintain consistency of load
versions throughout the system.
Also the user should make a copy of the control module load and set it as
ALTLOAD.
The user should perform a database backup to a new database file name
using the BACKUP DATABASE commands. Refer to Section 1.9.
The old loads can now be deleted from control module FLASH, if desired,
using the DELETE FILE command.
1.10.9.6 Duplex Downgrade Procedure
There is no support for backward schema migration of the database; therefore, in order to revert back to the original loads,
once they have been committed to, a software downgrade must be performed. The system will revert back to the old database and will lose any configuration changes made to the new database. During this process, the database reverts back to its
original configuration data, the CFC200 restarts, and the CFC200 and Line Cards revert back to their original loads.
172
Note:
Downgrading causes a loss of configuration changes made to the new database.
TABLE 1-28
Duplex Software Downgrade Steps
Step
State or Action
Details
1.
Evaluate the CFC200 and Line
Card loads on the CFC200. If
the original files are still in
FLASH, this step can be skipped.
Transfer the CFC200 and Line Card loads from the server to the control
module FLASH:
Set the original CFC load as
PREFLOADs
Set the original CFC load as the PREF load for the active and inactive
CFC200. The PREFLOAD setting is synchronized to the inactive.
2.
- get file <load> tftp server 10.52.65.42
SET CARD=ACTCFC PREFLOAD=<original load>
For the Line cards, the preferred loads will come from the restored database and will reload automatically.
3.
Restore the database that was
backed up in Step 2.of Table 127.
The user inputs the command:
RESTORE DATABASE (Refer to Section 1.9.1.5.)
Once the boot sequence continues, the original database is loaded into
RAM memory and is schema migrated to the old load. The original database is still intact in FLASH memory.
173
1.11 Log Management
1.11.1 Introduction
The SBx3112 produces management logs that provide information about all changes that occur. Figure 1-8 shows an example
log, and Table 1-29 describes the fields included with a management log.
A
B
C
D
** PORT003 2010-07-30 07:06:54
Location: Slot: 8 Port: 11
Description: Port Fault Set F
Reason Code: Loss of Link
3106 FAULT
A
= Severity
C
= Date and time
E
= Log Type
B
= Category
D
= Sequence
F
= Message
FIGURE 1-8
E
Sample Log Produced by the SBx3112
174
TABLE 1-29
Field Definitions of Management Logs
Field
Value
Description
Category - You can clear
the CATEGORY field of a
LOG FILTER by setting
the CATEGORY to
‘NONE’ or ““. Refer to
SET LOG FILTER.
BDB
Configuration database has been backed up
CARD
Change to a card
CFCP
A change in CFC protection, such as duplex to simplex.
CHAS
Chassis
CLI
Command-line interface
CUC
Cooling Unit Controller
EPSR
EPSR Change of State
FAN
Fan Unit
FILE
File Changes
IGMP
Changes to IGMP configuration
LOG
Log management
PORT
Port change
RDB
Configuration database has been restored
RMON
Performance Monitoring of Ethernet-based statistics
RSDB
Configuration Database has been reset (purged)
SHLF
Changes in shelf
SNTP
Changes in SNTP (time setting)
STP
Spanning tree protocol
SYS
Changes in overall system
TRAP
A trap has been produced
USER
Changes in user configuration
AUTH
Port Authentication
RAD
RADIUS Server
INFO
Information only
FAULT
Fault condition
OTHER
All other logs
*C
CRITICAL: data service is affected and requires immediate attention.
**
MAJOR: data service may be affected and must be investigated.
*
MINOR: data service is not affected but could lead to a larger problem.
<blank>
NONE: Information only
Log Type
Severity
175
TABLE 1-29
Field Definitions of Management Logs (Continued)
Field
Value
Description
Date and Time
yyyy-mm-dd
hh:mm:ss
Date and time the log was produced
1.11.2 Viewing Logs
Use the SHOW LOG command to filter logs immediately in the output, for example to show only logs that have a severity of
CRITICAL.
1.11.3 Controlling Output of Logs
To control the output of logs the following are used:
• Log Filter - This is a filterid (usually a text string) that is associated with a Category and Severity.
• Log Output - This is an outputid (also usually a text string) that is associated with the destination for the logs. The destination can be a terminal or SYSLOG server. The outputid can also define the log format.
By combining the two, a filterid can be created and then associated with an outputid. Figure 1-9 shows an example configuration.
outputids for:
SYSLOG server
SBx3112
TELNET/CLI
SBx3100
All logs (all Categories and Severities)
Physical Link
Critical Severity only
Categories CARD, SHLF only
SBx31CFC
local
terminal
CFC control module (console port)
FIGURE 1-9
Example Log Configuration
1.11.4 Example Log Configuration Setup
An example sequence of setting up a log management system would be as follows:
• Create a log filter - Use the CREATE
LOG FILTER=<filter name> command to create a name for a set of logs, called
the filterid, and set up a criteria so logs that meet that criteria are collected together and associated with that filterid.
176
• Create a log output - Use the CREATE
LOG OUTPUT=<output name> command to create a name for the destination for
the logs (called an outputid), set up the attributes for that destination (such as an IP address), and specify the log format.
• Associate the filterid with the outputid - Use the ADD FILTER OUTPUT=<output name> command to associate the
filterid with the outputid so that logs filtered in a certain way are sent to a certain destination.
The log format can be set to FULL, SUMMARY, or MSGONLY by using the FORMAT keyword with the CREATE LOG OUTPUT
or the SET LOG OUTPUT command. The FULL format displays the entire log message. The SUMMARY format displays only the
category, timestamp, and log type. The MSGONLY format displays only the log message. A comparison of the formats is
shown in Figure 1-10.
Full
USER002 2010-07-15 10:57:23 9123 INFO
User: user01 at IP: 192.16.18.103 has logged in
Summary
USER002 2010-07-15 10:57:23 9123 INFO
Message
Only
User: user01 at IP: 192.16.18.103 has logged in
FIGURE 1-10
Comparison of Log Formats
1.11.5 Capturing and Sending Logs to a Storage Device
Users can query the system for logs and send them to a storage device using the PUT FILE command. Note that the PUT
FILE command can be used for not only log files, but any supported file type. Usually logs will be captured and sent to a network server for analysis.
For logs from both the ACTCFC and the INACTCFC, an example of using the PUT FILE command to capture logs and send
them to a TFTP server follows. In this example, the user captured logs from the INACTCFC of a duplex system.
officer SEC> PUT LOG FILE=LOG_FILE TFTP SERVER=172.16.18.50 CARD=INACTCFC
officer SEC>
Info (010020): Successfully transferred file: LOG_FILE
The log file now exists on the TFTP server:
FIGURE 1-11
TFTP session with reception of log file
Any text editor can now be used to analyze the file.
Logs can be captured from any card with an independently running software load (as described above, the ACTCFC and the
INACTCFC). In the PUT LOG command syntax, the CARD parameter can have the value slot. The procedure is the same,
except that the CARD parameter will use a slot number rather than ACTCFC or INACTCFC.
177
1.11.6 Logging Procedures
The following procedure shows the commands used in the configuration.
TABLE 1-30
Step
Configuration Procedure for LOG Filtering
Command
Description
Show logs that match a criteria. For example, to view logs that have a severity level of CRITICAL, input the following:
1.
officer SEC> SHOW LOG SEVERITY=CRITICAL
*C SYS010 2010-04-16 14:39:42 3538 FAULT
System: Cleared Port Outage Threshold
Create a log filter for critical severity only
2.
CREATE LOG FILTER=CRITICAL_log SEVERITY=CRITICAL
Create a log output to associate with the log filterid CRITICAL
3
CREATE LOG OUTPUT=terminal DESTINATION=CLI FORMAT=SUMMARY
Add the log filter created in step 2. to the log output created in step 3
4.
ADD LOG FILTER=CRITICAL_log OUTPUT=TERMINAL
Enable the output.
5.
ENABLE LOG OUTPUT=TERMINAL
178
1.11.7 Logging Commands
This section describes the commands available to enable, configure and manage Logging.
TABLE 1-31
Logging CLI Commands
Commands
ADD LOG FILTER OUTPUT
CREATE LOG OUTPUT
CREATE LOG FILTER
DELETE LOG FILTER
DESTROY LOG FILTER
DESTROY LOG OUTPUT
DISABLE LOG OUTPUT
ENABLE LOG OUTPUT
PURGE LOG
PUT LOG FILE
SET LOG FILTER
SET LOG OUTPUT
SHOW LOG
SHOW LOG FILTER
SHOW LOG OUTPUT
179
ADD LOG FILTER OUTPUT
Syntax
ADD LOG FILTER={filterid-list|ALL} OUTPUT=outputid
Description
Used to associate existing management log filters with an existing management log output destination.
After successful execution of this command, the specified management log output destination, if
enabled, receives management logs that match the filter criteria contained in the management log filters.
Mode
Manager
Options
Option
Description
Range
Default
Value
FILTER
The log filter that was created.
NA
NA
OUTPUT
The outputid that was created.
NA
NA
Release Note
NA
Example
ADD LOG FILTER=CRITICAL_log OUTPUT=TERMINAL
180
CREATE LOG OUTPUT
Syntax
CREATE LOG OUTPUT=outputid
[ { CLI [ FORMAT={ FULL | MSGONLY | SUMMARY } ] |
CONSOLE [ FORMAT={ FULL | MSGONLY | SUMMARY } ] |
SYSLOG SERVER={ ipaddress | hostname }
{ [ FACILITY={ 0..7 | DEFAULT } ] |
[ CRITICALFACILITY={ 0..7 | DEFAULT } ]
[ MAJORFACILITY={ 0..7 | DEFAULT } ]
[ MINORFACILITY={ 0..7 | DEFAULT } ]
[ INFOFACILITY={ 0..7 | DEFAULT } ] }
| FILE=unit:filename
[ FORMAT={ FULL | MSGONLY | SUMMARY } ] } ]
Description
Creates management log output destinations. Management log output destinations are used to direct a
filtered management log stream to a specific destination. Currently, supported destinations include a
CLI session, the system console and a Syslog server. Note that CLI session output destinations are not
persisted. If a user sets up a management log output destination and then subsequently logs out, that
management log output destination is removed from the system. In addition, created log output destinations are disabled upon creation. Execute the ENABLE LOG OUTPUT command to enable the management log output destination for output.
Mode
Manager
Options
Default
Value
Option
Description
Range
OUTPUT
The outputid is a name associated with the destination for the logs. The destination can be a terminal
or SYSLOG server. The outputid can also define
the log format.
NA
NA, but
usually a
text string
upto 23
characters
long
CLI
The output will go to the CLI session.
NA
NA
CONSOLE
The output will go to the System Console.
NA
NA
SYSLOG_Ser
ver
The IP address or hostname of the Syslog server.
NA
NA
FACILITY
The log facility that all levels of syslogs are sent to.
NA
2
Refer to RFC3164 for details on the SYSLOG protocol.
CRITICALFACILITY
The log facility that critical syslogs are sent to. The possible values are 0-7, indicating LOCAL0-LOCAL7 or
DEFAULT.
NA
LOCAL2
MAJORFACILITY
The log facility that major syslogs are sent to. The possible values are 0-7, indicating LOCAL0-LOCAL7 or
DEFAULT.
NA
LOCAL2
MINORFACILITY
The log facility that minor syslogs are sent to. The possible values are 0-7, indicating LOCAL0-LOCAL7 or
DEFAULT.
NA
LOCAL2
181
Option
Description
Range
Default
Value
INFOFACILITY
The log facility that informational syslogs are sent to.
The possible values are 0-7, indicating LOCAL0LOCAL7 or DEFAULT.
NA
LOCAL2
FILE
and the pattern (in 14.2, the SD unit on the active or
inactive CFC unit can be specified.
NA
NA
FORMAT
Allows users to specify the format of the management
logs. Valid formats include the following:
NA
FULL
FULL - Displays the entire contents of the management
log including log type, date and time, severity, sequence
number and message body.
MSGONLY - Displays only the management log bodies.
SUMMARY - Displays a one-line summary of the management log. The summary includes the log type, date
and time and log sequence number.
Release Note
NA
Example
CREATE LOG OUTPUT=terminal DESTINATION=CLI FORMAT=SUMMARY
182
CREATE LOG FILTER
Syntax
CREATE LOG FILTER=filterid [CATEGORY=category]
[SEVERITY=[op]{CRITICAL|MAJOR|MINOR|NONE}]
Description
Creates a management log filter. Management log filters are used to set filter criteria for management
logs. If a management log passes the criteria in a given log filter, the management log is routed to all of
the management log output destinations that are associated with that filter via the ADD LOG FILTER
command. By default, without a category or severity value specified, a management log filter matches
all logs.
Mode
Manager
Options
Option
Description
Range
Default
Value
FILTER
The name of a filter to create. The name should match
criteria that the filter is going to define.
NA
NA
CATEGORY
A comma-separated list of log categories, Valid values
for the SBx3112 are listed in Table 1-29.
NA
NA
SEVERITY
SEVERITY of the log to filter on
NA
NONE
- CRITICAL
- MAJOR
- MINOR
- NONE
Release Note
NA
Example
CREATE LOG FILTER=rmon_filter CATEGORY=RMON SEVERITY=MINOR
183
DELETE LOG FILTER
Syntax
DELETE LOG FILTER={filterid-list|ALL} OUTPUT=outputid
Description
Used to remove the association between management log filters and a management log output destination. Upon successful execution of this command, the specified management log filters are removed
from the management log output destination. The management log output destination will no longer
receive logs that match the filter criteria in the log filters that were removed.
Mode
Manager
Options
Option
Description
Range
Default
Value
FILTER
The name of a previously created filter to delete.
NA
NA
OUTPUT
The name of the output destination. This was created
with the CREATE LOG FILTER command.
NA
NA
Release Note
NA
Example
DELETE LOG FILTER=rmon_filter OUTPUT=terminal
184
DESTROY LOG FILTER
Syntax
DESTROY LOG FILTER={filterid-list|ALL}
Description
Removes management log filters from the system. Upon successful completion of this command, the
specified management log filter is completely removed from the system. The log filter is also removed
from all log output destinations that have had the filter added with the ADD LOG FILTER command.
Mode
Manager
Options
Option
Description
Range
Default
Value
FILTER
Name given for the log filter.
NA
NA
Release Note
NA
Example
DESTROY LOG FILTER=rmon_filter
185
DESTROY LOG OUTPUT
Syntax
DESTROY LOG OUTPUT={outputid-list|ALL}
Description
Removes existing management log output destinations from the system. CLI output destinations are
automatically destroyed when the user logs out of his/her session. Upon successful completion of this
command, the specified management log destination is completely removed from the system.
Mode
Manager
Options
Option
Description
Range
Default
Value
OUTPUT
The log destination ids that have been created.
NA
NA
Release Note
NA
Example
DESTROY LOG OUTPUT=terminal
186
DISABLE LOG OUTPUT
Syntax
DISABLE LOG OUTPUT={outputid-list|ALL}
Description
Disables management log streaming for existing management log output destinations.
Mode
Manager
Options
Option
Description
Range
Default
Value
OUTPUT
NA
NA
Release Note
NA
Example
DSIABLE LOG OUTOUT=systest
187
ENABLE LOG OUTPUT
Syntax
ENABLE LOG OUTPUT={outputid-list|ALL}
Description
Enables management log streaming for existing management log output destinations.
Mode
Manager
Options
Option
Description
Range
Default
Value
OUTPUT
NA
NA
Release Note
NA
Example
ENABLE LOG OUTPUT=terminal
188
PURGE LOG
Syntax
PURGE LOG
Description
Used to remove all stored management logs from the system.
Mode
Manager
Options
None
Release Note
NA
Example
PURGE LOG
189
PUT LOG FILE
Syntax
PUT LOG FILE={ destinationfile | unit:destinationfile | serverpath/destinationfile }
[ { TFTP SERVER={ ipaddress | hostname }
| ZMODEM | FTP SERVER={ ipaddress | hostname }
USER=userid PASSWORD=password } ]
[ TYPE={ MGMT | ERROR | TRACE | CRASH } ]
[ CARD={ slot | ACTCFC | INACTCFC } ]
Description
Used to transfer management, error, trace or crash logs off the device. Currently, TFTP is the only
supported transfer method. Logs can be captured from any card with an independently running software load. In the PUT LOG command syntax, the CARD parameter can have the value slot. The procedure is the same, except that the CARD parameter will use a slot number rather than ACTCFC or
INACTCFC.
Mode
Manager
Options
Option
Description
Range
Default
Value
FILE
The FILENAME parameter is used to specify the filename for the logs to be transferred into on the remote
server. If a unit:filename, the logs will be written to a file
on the specified flash unit.
NA
NA
TFTP_Server
ip address or host name of tftp server
NA
NA
ZMODEM
Transfer logs usng the ZMODEM protocol.
NA
NA
FTP_Server
ip address or host name of ftp server
NA
NA
NA
MGMT
NA
ACTCFC
USER - user for the ftp server
PASSWORD - password for th ftp server
TYPE
MGMT - management logs - logs generated during the
normal course of system operation that may indicate
system status, state or error conditions.
ERROR - error logs - logs used for field support and
debugging that may assist in troubleshooting.
TRACE - trace logs - logs used for field support and
debugging that may assist in troubleshooting.
CRASH - crash logs - logs used for field support and
debugging in cases where the system has experienced an
unhandled exception condition.
CARD
Used to select which cfc the logs are offloaded from.
slot - slot number of card
ACTCFC - Active CFc
INACTCFC - Inactive CFC
Release Note
NA
Example
PUT LOG FILE SD4:NEWLOGS TFTP SERVER 10.52.36.2 TYPE MGMT CARD ACTCFC
190
SET LOG FILTER
Syntax
SET LOG FILTER=filterid
[CATEGORY=category]
[SEVERITY=[op]
{CRITICAL|MAJOR|MINOR|NONE}]
Description
Used to change the filter criteria on an existing management log filter. By default, if no category, severity or format options are specified, the management log filter is set to match all logs.
Mode
Manager
Release
Options
Option
Description
Range
Default
Value
FILTER
The filterid that has been created
NA
NA
CATEGORY
Allows the user to specify one or more management log
categories to filter. A comma-separated list of categories is accepted. The management log category is taken
from the leading 3 or 4 alphabetic characters from the
management log name. Refer to Table 1-29.
NA
NA
NA
NA
To clear the categories and set back to the default, use
eithe NONE or ““.
SEVERITY
The SEVERITY parameter allows for the display of management logs that have only a certain sequence number
values. A single severity value may be specified or an
operation-specified range of severities. Valid severities
are CRITICAL, MAJOR, MINOR or NONE. These
severity values can be combined with an optional operator to include a range of severities. The valid operators
are the following:
< - less-than - match all logs with a severity less than
or equal to the specified severity threshold
> - greater-than - match all logs with a severity greater
than or equal to the specified severity threshold
! - not-equal - match all logs with a severity less than
or equal to the specified severity threshold
Release Note
NA
Example
SET LOG FILTER=rmon_filter SEVERITY=MAJOR
191
SET LOG OUTPUT
Syntax
SET LOG OUTPUT=outputid
[ { CLI [ FORMAT={ FULL | MSGONLY | SUMMARY } ] |
CONSOLE [ FORMAT={ FULL | MSGONLY | SUMMARY } ] |
SYSLOG { [ SERVER={ ipaddress | hostname } ] }
{ [ FACILITY={ 0..7 | DEFAULT } ] |
[ CRITICALFACILITY={ 0..7 | DEFAULT } ]
[ MAJORFACILITY={ 0..7 | DEFAULT } ]
[ MINORFACILITY={ 0..7 | DEFAULT } ]
[ INFOFACILITY={ 0..7 | DEFAULT } ] } |
FILE=unit:filename [ FORMAT={ FULL | MSGONLY | SUMMARY } ] } ]
Description
Used to change the management log output destination settings. By default, if no category, severity or
format options are specified, the management log filter is set to match all logs.
Mode
Manager
Options
Option
Description
Range
Default
Value
OUTPUT
The outputid that was created.
NA
NA
The output will go to the Command Console.
NA
NA
CLI
FORMAT can be:
- FULL displays the entire log message.
- SUMMARY displays only the category, timestamp, and
log type.
- MSGONLY displays only the log message.
CONSOLE
The FORMAT meanings are the same as for the CLI.
NA
NA
SYSLOG_Ser
ver
The SERVER that will receive the management log
stream
NA
NA
The log facility that all levels of syslogs are sent to.
NA
2
FACILITY
Refer to RFC3164 for details on the SYSLOG protocol.
CRITICALFACILITY
The log facility that critical syslogs are sent to. The possible values are 0-7, indicating LOCAL0-LOCAL7 or
DEFAULT.
NA
LOCAL2
MAJORFACILITY
The log facility that major syslogs are sent to. The possible values are 0-7, indicating LOCAL0-LOCAL7 or
DEFAULT.
NA
LOCAL2
MINORFACILITY
The log facility that minor syslogs are sent to. The possible values are 0-7, indicating LOCAL0-LOCAL7 or
DEFAULT.
NA
LOCAL2
INFOFACILITY
The log facility that informational syslogs are sent to.
The possible values are 0-7, indicating LOCAL0LOCAL7 or DEFAULT.
NA
LOCAL2
192
Option
Description
Range
Default
Value
FILE
and the pattern (in 14.1, only the SD unit on the active
CFC unit can be specified
NA
NA
NA
NA
The FORMAT meanings are the same as for the CLI
OUTPUT
The outputid is a name associated with the destination for the logs. The destination can be a terminal
or SYSLOG server. The outputid can also define
the log format.
Release Note
NA
Example
SET LOG OUTPUT=terminal CLI FORMAT=MSGONLY
193
SHOW LOG
Syntax
SHOW LOG [ CATEGORY=category ] [ DATE=[ op ] yyyy-mm-dd [ -yyyy-mm-dd ] ] [
FORMAT={ FULL | MSGONLY | SUMMARY } ] [ REVERSE ]
[ SEQUENCE=0..9999 [ -0..9999 ] ]
[ SEVERITY=[ op ] { CRITICAL | MAJOR | MINOR | NONE } ]
[ TAIL [ =count ] ] [ TIME=[ op ] hh:mm:ss [ -hh:mm:ss ] ]
Description
Used to display all the stored management logs. Optional parameters are available to display only the
management logs matching certain criteria. With no optional parameters specified, all management
logs are displayed in order from newest to oldest.
Mode
User
Options
Option
Description
Range
Default
Value
CATEGORY
A comma-separated list of log categories, Valid values
for the SBx3112 are listed in Table 1-29.
NA
ALL
DATE
Causes SHOW LOG to display only the logs that
occurred on a certain date or within a range of
dates.There are three possible ways to use the DATE
parameter.
NA
ALL
NA
FULL
NA
NA
1) As a single date, yyyy-mm-dd (e.g., 2010-03-14 to display all logs that occurred on March 14, 2010)
2) As an explicit range of dates, yyyy-mm-dd-yyyy-mmdd (e.g., 2010-03-14-2010-03-17 to display all logs that
occurred between March 14, 2010, and March 17, 2010,
inclusive)
3) As an operation-specified range of dates. The following operations are valid:
< - less-than - displays all logs earlier than or equal to a
certain date
> - greater-than - displays all logs with a date later than
or equal to a certain date
FORMAT
Controls how the logs are displayed to the user. The
following formats are valid:
FULL - Displays the entire contents of the management log including log type, date and time, severity,
sequence number and message body.
MSGONLY - Displays only the management log bodies.
SUMMARY - Displays a one-line summary of the management log. The summary includes the log type, date
and time and log sequence number.
REVERSE
Reverses the normal order of management log display,
displaying the management logs in oldest to newest
order.
194
Option
Description
Range
Default
Value
SEQUENCE
Allows for the display of management logs that match
the specified range of sequence numbers. Sequence
number ranges can be either a single sequence number,
an explicit range of sequence numbers (e.g., 100-200) or
an operation-specified range of sequence numbers (e.g.,
<200)
NA
NA
NA
NA
The following are the valid operations:
< - less-than - displays all logs with a sequence number
less than or equal to the given sequence number.
> - greater-than - displays all logs with a sequence number greater than or equal to the given sequence number.
SEVERITY
Indicates the severity level to filter the display with.
Severity indicates the degree of service impact associated with an alarm condition. The following severities
are defined:
- CRITICAL: A critical alarm is used to indicate that a
severe, service-affecting condition has occurred and
that immediate corrective action is imperative.
- MAJOR: A major alarm is used to indicate a serious
disruption of service or the malfunctioning or failure of
important circuits. These troubles require immediate
attention and response to restore or maintain system
capability. The urgency is less than critical situations
because of lesser immediate or impending effect on service or system performance.
- MINOR: Minor alarms are used for troubles that do
not have serious effect on service to customers or for
troubles that do not effect essential system operation.
- NONE: Represents an informational message. No
explicit action is required.
TAIL
The TAIL parameter allows for the display of a certain
number of the newest logs. If a numeric argument is not
supplied, the newest 20 logs are displayed, otherwise
the optional numeric argument is taken as the number
of logs to display, if that number of logs exists.
NA
NA
TIME
Filters logs based on the time at which the log occurred.
The time may be specified as an exact value (hh:mm:ss),
an explicit range (hh:mm:ss-hh:mm:ss) or as an operation-specified range of values.
NA
NA
The following operations are valid:
< - less-than - displays all logs with a time less than or
equal to the specified value.
> - greater-than - displays all logs with a time greater
than or equal to the specified value.
Release Note
NA
Example
195
SHOW LOG CATEGORY=PORT SEVERIT
** PORT004 2010-11-04 15:47:13
3314 FAULT
Description: Port Fault Cleared
Reason Code: Remote BFD Session Failed
** PORT004 2010-11-04 15:47:13
3311 FAULT
** PORT004 2010-11-04 15:47:12
Reason Code: BFD Session Failed
3310 FAULT
** PORT004 2010-11-04 15:47:12
3307 FAULT
** PORT004 2010-11-04 15:47:11
3306 FAULT
** PORT004 2010-11-04 15:47:02
3305 FAULT
** PORT003 2010-11-04 15:47:02
3304 FAULT
Description: Port Fault Set
** PORT003 2010-11-04 15:47:02
3303 FAULT
** PORT003 2010-11-04 15:47:02
3302 FAULT
** PORT004 2010-11-04 15:47:02
Reason Code: Loss of Link
3301 FAULT
196
SHOW LOG FILTER
Syntax
SHOW LOG FILTER
Description
displays all the existing management log filters in the system. The log filter name, the log categories filtered, if any, and the severity values filtered are displayed by this command.
Mode
User
Options
NA
Release Note
NA
Example
SHOW LOG FILTER
--- Management Log Filters --------------------------------------------------Filter ID
------------------------1
2
Categories
------------------------CLI
PORT
Severities
------------------------Critical Major Minor None
Critical Major Minor None
197
SHOW LOG OUTPUT
Syntax
SHOW LOG OUTPUT
Description
Displays all the existing management log output destinations currently defined in the system. The information displayed contains the management log output name, the destination type, the log format type,
the associated management log filters, and the status (enabled or disabled). Additional destination-specific information is also displayed. For CLI log output destinations, the user name, IP address and session number information is displayed. For Syslog log output destinations, the Syslog server IP address is
shown.
Mode
User
Options
NA
Release Note
NA
Example
SHOW LOG OUTPUT
--- Management Log Output Destinations ----------------
Output ID.............................
Destination...........................
Message Type..........................
Filters...............................
Status................................
Syslog server hostname/IP address.....
Critical facility.....................
Major facility........................
Minor facility........................
Info facility.........................
19
Syslog
SYSLOG - NORMAL
1 2
Enabled
10.52.18.202
2
2
2
2
198
1.12 LED Management
1.12.1 Introduction
On the SBx3100, the LEDs have the following attributes:
• Color - Green or amber
• State - Solid, flashing, or off
1.12.2 CFC200
The CFC 200 has:
•
•
•
•
•
•
2 slot status LEDs, labeled per slot number (0-11) on the faceplate
one power LED, labeled “PSU” on the faceplate
one activity LED, labeled “M/S” (for Master/Slave) on the faceplate
one Fan Status LED, labeled “FAN” on the faceplate
one management Ethernet port LED, labeled “L/A” (for Link/Activity) on the faceplate
one SD card LED, labeled “SD” on the faceplate, to show status of the removable SD memory card
Note:
The slot status LEDs on the CFC are physically controlled by the cards in the slots, not by the CFC.
1.12.3 PSU
The AC PSU card has 3 LEDs:
• One input AC power LED, labeled “AC” on the faceplate
• One output DC power LED, labeled “DC” on the faceplate
• One fault LED, labeled “FAULT” on the faceplate
The DC PSU card has 3 LEDs:
• One input DC power LED, labeled “DC In” on the faceplate
• One output DC power LED, labeled “DC out” on the faceplate
• One fault LED, labeled “FAULT” on the faceplate
Note:
If any provisioned PSU is in failed state, then the single PSU LED on the CFC is flashing amber.
1.12.4 XE4
The XE4 card has four green LEDs, one for each port, labeled L/A (for Link/Activity) on the faceplate. The LED is on when
the link is up, and blinking when the link has activity. Disabling the XE interface turns the LED off, regardless of whether a
fiber is present.
1.12.5 GE24POE
The GE24POE card has two LEDs per port. One port LED is used to indicate activity (green for a 1Gbps link, yellow for a
10/100 Mbps link, and flashing for activity). The second port LED is used to indicate PoE status (green for PoE active, solid
yellow for power fault conditions and flashing yellow for insufficient power conditions). Disabling the GE interface turns the
activity LED off, regardless of whether a cable is present. Disabling the GE interface has no effect on the POE LED.
199
1.12.6 GE24SFP
The GE24SFP card had 24 LEDs, one for each port, labeled L/A (for Link/Activity) on the faceplate. Each port LED is used to
indicate activity (green for a 1Gbps link, yellow for a 10/100 Mbps link, and flashing for activity). The LED is OFF if the cable
or SFP is missing. Disabling the XE interfaces turns the LED off, regardless of whether a fiber is present.
1.12.7 LED Behavior
Color and pattern are used to distinguish the card states on the single LED per card. Green color indicates in service or
potentially in service (bootup) states, and amber color indicates out of service states. Thus, an amber color indicates “Ok To
Pull”. Solid light patterns are used to indicate stable states, while flashing patterns indicate transient states. Table 1-32 illustrates the display of the slot status LEDs over various card states.
TABLE 1-32
Single LED State for Card State on CFC200
Card State
Slot LED State on CFC200
DN-DN-Offline
Solid Amber
UP-DN-Reset
Solid Amber
UP-DN-Offline (query)
Solid Amber
UP-DN-Loading
Flashing Green
UP-DN-Booting
Flashing Green
UP-DN-Intest
Flashing Green
UP-DN-Configuring
Flashing Green
UP-UP-Online
Solid Green
UP-UP-Degraded
Flashing Amber
UP-DN-Failed
Flashing Amber
UP-DN-NotInstalled (card mismatch)
Solid Amber
UP-DN-NotInstalled (card not present)
Off
No card physically present, no card provisioned
Off
Inserted, not in database (manual provisioning mode)
Solid Amber
Note that when a card is reset, its LED is solid amber which is the same as the disabled state. The bootROM on the card
assumes that the card is disabled until told by the CFC to proceed with coming in service (which involves transition to UPDN-Loading or UP-DN-Booting). This policy ensures that a manually disabled card continues to show solid amber even if a
card is put into reset state by card insertion. It's also useful in visual determination of reboot loops; in that case the card
would continue to cycle between solid amber and flashing green. Once the application level software on the card is running
and the bootROM is no longer in control, the CFC will drive the LED states as per the table above.
The CFC activity LEDs are slightly different from iMAP devices, in that on iMAP systems the inactive CFC does not light the
activity LED at all, while on the x3112 the inactive CFC shows the amber color on its activity LED. The inactive CFC activity
LED is a solid amber pattern in all cases unless the card is online with the "Out of Sync" alarm; in that case it has a flashing
amber pattern. The active CFC booting up in simplex will set the M/S LED to solid amber until the software determines
activity status during initialization, then it turns to solid green to indicate that the CFC is active.
When the CFC is in a stable state (either UP-UP-Online with no "Out of Sync" alarm, or DN-DN-Offline), neither the card
status LED for that CFC nor the M/S LED is in a flashing state.
200
The following table illustrates the display of the Master/Slave LED over various states:
TABLE 1-33
CFC Card State and M/S LED on CFC200
CFC Card State
M/S LED State (on corresponding CFC200)
Solid Green
UP-UP-Online (Inactive) - in sync
Solid Amber
UP-UP-Online (Inactive) - out of sync
Flashing Amber
UP-DN- (Inactive)
Solid Amber
DN-DN-Offline
Solid Amber
a
a. Any transitional state
The following table illustrates the display of the PSU related LEDs over various states. Note that if any provisioned PSU is in
a failed state, then the single PSU LED on the CFC is flashing amber.
TABLE 1-34
PSU Card
State
AC PSU States and Associated LEDs
PSU LED State
(on CFC200)
AC (or DC In) LED
(on PSU)
DC (or DC Out)
LED (on PSU)
Fault LED (on
PSU)
UP-UP-Online
Solid Green
Solid Green
Solid Green
Off
UP-UPDegraded
Flashing Amber
Solid Green
Off
Ona
UP-DN-Failed
(output fault)
Flashing Amber
Solid Green
Off
Solid Red
UP-DN-Failed
(no AC input)
Flashing Amber
Off
Off
Off
UP-DN-NotInstalled
Flashing Amber
NA
NA
NA
Not inserted,
not in databaseb
Solid Green
NA
NA
NA
a. The Fault LED on the PSU is driven by the PSU firmware, so that LED is on if the fault is detected by the firmware
on the PSU. However, faults detected by software running on the CFC do not set the fault LED on the PSU
b. In this case the system only has a single PSU physically present and configured in the database. In this case the PSU
LED on the CFC is solid green because this is considered a normal operating mode
TABLE 1-35
DC PSU States and Associated LEDs
PSU Card
State
PSU LED State
(on CFC200)
AC (or DC In) LED
(on PSU)
DC (or DC Out)
LED (on PSU)
Fault LED (on
PSU)
UP-UP-Online
Solid Green
Solid Green
Solid Green
Off
UP-UPDegraded
Flashing Amber
Solid Green
Off
Ona
UP-DN-Failed
(output fault)
Flashing Amber
Solid Green
Off
Solid Red
UP-DN-Failed
(no AC input)
Flashing Amber
Off
Off
Off
201
TABLE 1-35
DC PSU States and Associated LEDs (Continued)
PSU Card
State
PSU LED State
(on CFC200)
AC (or DC In) LED
(on PSU)
DC (or DC Out)
LED (on PSU)
Fault LED (on
PSU)
UP-DN-NotInstalled
Flashing Amber
NA
NA
NA
Not inserted,
not in databaseb
Solid Green
NA
NA
NA
NA - PSU powered outside of
chassis
NA
Solid Green
Flashingc
Off
a. The Fault LED on the PSU is driven by the PSU firmware, so that LED is on if the fault is detected by the firmware
on the PSU. However, faults detected by software running on the CFC do not set the fault LED on the PSU
b. In this case the system only has a single PSU physically present and configured in the database. In this case the PSU
LED on the CFC is solid green because this is considered a normal operating mode
c. If the DC PSU is powered but not inserted in the chassis, it is in "STANDBY" mode. In this state, the DC OUT LED
will be flashing. This is an unexpected state while inserted in the chassis. Note that the AC PSU cannot be powered
outside of the chassis.
The following table illustrates the display of the fan related LEDs over various states:
TABLE 1-36
Fan Card State and LED State CFC200 and FC4
Fan Card State
FAN LED State (CFC200
FAN LED State (FC4)
UP-UP-Offline
Solid Green
Solid Green
UP-UP-Degraded
Flashing Amber
Solid Green
UP-DN-Failed
Flashing Amber
Solid Greena
UP-DN-NotInstalled
Flashing Amber
NA
a. The Fan power LED only turns OFF if there is an overload condition and the hot-swap circuitry isolates the
fan tray from the system power
The following table illustrates the display of the SD related LEDs over various states:
TABLE 1-37
SD Card State and LED State CFC200
SD Card State
SD LED State (on Corresponding CFC200
Activated (Ready)
Solid Green
Activated (Busy)
Flashing Green
Activated (Fault)
Flashing Amber
Deactivated
Off
Not inserted
Off
The following table illustrates the display of the MGMT interface LEDs over various states.
TABLE 1-38
MGMT Interface State and LED State
MGMT Interface State
L/A LED State (on Corresponding CFC200
UP-UP-Online (1000 LINK)
Solid Green
UP-UP-Online (1000 ACT)
Flashing Green
UP-UP-Online (10/100 LINK)
Solid Amber
202
TABLE 1-38
MGMT Interface State and LED State
MGMT Interface State
L/A LED State (on Corresponding CFC200
UP-UP-Online (10/100 ACT)
Flashing Amber
UP-DN-Failed
Off
Disabling of the physical Ethernet layer for the MGMT interface is not supported; however, disable/enable of the IP service on
the interface will affect whether or not the interface is actively passing data (flashing LED). This is the same behavior as other
iMAP products.
The following table illustrates the display of the port activity LEDs on the GE24POE/GE24SFP over various states:
TABLE 1-39
GE Interface State and Port Activity LED State on GE Cards
GE Interface State
Port Activity LED State (on Corresponding GE24POE/GE24SFP
Solid Green
Flashing Green
UP-UP-Online (10/100 LINK)
Solid Amber
UP-UP-Online (10/100 ACT)
Flashing Amber
UP-DN-Offline
Off
UP-DN-Failed
Off (Note that since the LED shows link-state, there could be a BFD failure,
where the port may be operationally down but the LED could still be On.
The following table illustrates the display of the port LEDs on the XE4 over various states:
TABLE 1-40
XE Interface State and Port Activity LED State on XE4
XE Interface State
Port Activity LED State (on Corresponding XE4
Solid Green
Flashing Green
DN-DN-Offline
Off
UP-DN-Failed
Off
203
1.13 ECOMODE and Lamp Test
1.13.1 Introduction
The SBx3112-00 has a “green” energy savings mode called ECOMODE that is activated by the user either via a front-panel
ECO mode switch or by CLI command. While ECO mode is on, the system removes power to all LEDs on the CFCs (except
for the master/slave LED) and all port LEDs on the service modules. ECO mode has no effect on the LEDs on the fan tray,
the PSUs and the optocouplers on the back of the chassis.
Following is an example output for the SHOW SYSTEM ECOMODE. It simply toggles between the modes.
SHOW SYSTEM ECOMODE
Info (038019): System ECOMODE is set to OFF
SET SYSTEM ECOMODE=ON
SHOW SYSTEM ECOMODE
Info (038019): System ECOMODE is set to ON
1.13.2 ECO Functions and Lamp Test
The system retains its ECO mode status in the configuration database, so the mode survives power cycles and software
restarts. The default ECO mode is off; i.e., all LEDs are enabled. The user can set the ECO mode via SET SYSTEM ECOMODE ON/OFF command, and query it via the SHOW SYSTEM ECOMODE or SHOW SYSTEM commands. The text configuration files generated by BACKUP/SHOW CONFIG contain the set command for the ECO mode.
The ECO mode switch toggles the current ECO mode. So if the system is not in ECO mode, pushing the ECO mode switch
is the same as typing SET SYSTEM ECOMODE ON. Once in ECO mode, pushing the ECO mode switch is the same as typing
SET SYSTEM ECOMODE OFF. Although both CFCs have the ECO mode switch on the faceplate, only the ECO switch on
the active CFC controls ECO mode, the inactive CFC ECO switch has no effect on the system.
The ECO mode switch/command is also used for LED lamp test. Lamp test is the opposite of ECO mode, in that all LEDs are
illuminated for a brief period. Unlike ECO mode, lamp test is not a persisted state for the LEDs. Lamp test is performed
automatically by entering or exiting ECO mode.
Specifically, LED behavior for ECOMODE and lamp test is as follows, and is initiated by either:
• Pressing an holding the ECO mode switch
• Entering the SET SYSTEM ECOMODE=ON or SET SYSTEM ECOMODE=OFF
When entering ECO mode (mode transition from OFF to ON), all applicable LEDs will illuminate in alternating colors for 3
seconds (effectively a lamp test), then turn OFF
When exiting ECO mode (mode transition from ON to OFF), all applicable LEDs will illuminate in alternating colors for 3
seconds (also effectively a lamp test), then return to their appropriate normal states (as per tables above)
Alternating colors means that the LEDs alternate green/amber, with each color showing for 200 milliseconds, during the 3
second lamp test period. Note that the XE4 port LEDs do not have an amber color, so during lamp test they appear as solid
green for the 3 second lamp test period.
204
1.13.3 ECOMODE Commands
TABLE 1-41
ECOMODE Commands
Commands
SET SYSTEM ECOMODE
SHOW SYSTEM ECOMODE
205
SET SYSTEM ECOMODE
Syntax
SET SYSTEM ECOMODE={ ON | OFF }
Description
The SBx3112-00 has a “green” energy savings mode called ECOMODE that is activated by the user
either via a front-panel ECO mode switch or by this CLI command. While ECO mode is on, the system removes power to all LEDs on the CFCs (except for the master/slave LED) and all port LEDs on
the service modules.
Mode
Manager
Options
Option
Description
Range
Default
Value
ECOMODE
Toggles ECOMODE as either ON or OFF
NA
OFF
Release Note
NA
Example
SET SYSTEM ECOMODE=ON
206
SHOW SYSTEM ECOMODE
Syntax
SHOW SYSTEM ECOMODE
Description
Shows the status of ECOMODE on the SBx3112 (on or off).
Mode
User
Options
NA
Release Note
NA
Example
SHOW SYSTEM ECOMODE
Info (038019): System ECOMODE is set to OFF
207
1.14 Alarm Management Overview
1.14.1 Overview
There are three levels of alarm severity on the system, Critical, Major, and Minor. In general, they are described as:
• Critical - A critical alarm is used to indicate that a severe, service-affecting condition has occurred and that immediate
corrective action is imperative.
• Major - A major alarm is used to indicate a serious disruption of service or the malfunctioning or failure of important circuits. These troubles require immediate attention and response by the crafts person to restore or maintain system capability. The urgency is less than critical situations because of lesser immediate or impending effect on service or system
performance.
• Minor - Minor alarms are used for troubles that do not have serious effect on service to customers or for troubles that
do not affect essential system operation.
• Info - Represents an informational message. No explicit action is required of the user.
When an anomaly occurs, the system generates management logs. In reality, every time an event occurs on the system, a log
is created. Logs are also generated when performance measurement thresholds have been exceeded. For an efficient management configuration, users can configure logs to be filtered, output, and shown on specified devices and formats.
1.14.2 Displaying alarms
Alarms can be displayed using the SHOW ALARMS command. Depending on the parameters used when the user inputs the
SHOW ALARMS command, different information will be provided in the response. For example the column Time Stamp is
added with the time and date of the alarm. This can help the user correlate the alarm to other problems in the network. The
SHOW ALARMS command will be discussed below.
• SHOW ALARMS ALL - To display all system alarms, the user inputs this command. The alarm statuses for all system
cards will be displayed.
• SHOW ALARMS CARD - To display alarms for a specified card
• SHOW ALARMS PORT - To display alarms for a specified port
• SHOW ALARMS SEVERITY - To display alarms according to their severity
Here are some examples of the use of the SHOW ALARMS command:
>show alarms
--- Shelf Alarms --Shelf
Fault
Severity
------------ -------------------------------- -------Shelf
Port Outage Threshold
Critical
Time Stamp
-------------13:31:11 03/19
--- Fan Alarms --Fan
Fault
Severity
------------ -------------------------------- -------Fan Module
Hardware Not Recognized
Major
Time Stamp
-------------13:31:22 03/19
--- Interface(Port) Alarms --Interface
-----------0.1
0.2
0.3
0.4
Fault
-------------------------------Loss of Link
Loss of Link
Loss of Link
Loss of Link
Severity
-------Major
Major
Major
Major
Time Stamp
-------------13:40:49 03/19
13:40:49 03/19
13:40:49 03/19
13:40:49 03/19
208
0.6
0.7
0.8
0.9
0.10
0.12
0.13
0.14
0.15
0.16
0.17
0.18
0.19
0.20
0.21
0.22
0.23
1.0
1.1
1.2
1.3
11.1
11.2
11.3
11.6
11.7
11.8
11.9
11.10
11.12
11.13
11.14
11.15
11.16
11.17
11.18
11.19
11.20
11.21
11.22
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
Loss
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
of
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Link
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
13:40:49
13:40:49
13:40:49
13:40:49
13:40:49
13:40:49
13:40:49
13:40:49
13:40:49
13:40:49
13:40:49
13:40:49
13:40:49
13:40:49
13:40:49
13:40:49
13:40:49
13:32:14
13:32:14
13:32:14
13:32:14
13:32:06
13:32:06
13:32:06
13:32:06
13:32:06
13:32:06
13:32:06
13:32:06
13:32:06
13:32:06
13:32:06
13:32:06
13:32:06
13:32:06
13:32:06
13:32:06
13:32:06
13:32:06
13:32:06
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
03/19
Severity
-------Major
Major
Major
Major
Time Stamp
-------------13:32:14 03/19
13:32:14 03/19
13:32:14 03/19
13:32:14 03/19
>show alarms CARD=1
-----------1.0
1.1
1.2
1.3
Fault
-------------------------------Loss of Link
Loss of Link
Loss of Link
Loss of Link
1.14.3 Alarms Associated with the SBx3112 Architecture
All of the logs and alarms are listed in Log Reference for SwitchBlade x3100 Series Switches. Following are the alarms that are
related to the SBx3112 architecture.
1.14.3.1 Alarms for the (Dual) CFC
The SBx3112 has a dual CFC that operates in load sharing mode.
• The internal control links between all data switching cards are Ethernet based. Therefore, all the data switching cards on
the SBx3112 support an alarm that indicates loss of the control plane link.
• There are two internal data plane links between each CFC and each service module, and so each service module has four
active data plane links in a duplex configuration. In the iMAP series products, each service module has a single data plane
209
link to each CFC, so the “Datalink Lost” alarms are enhanced on SBx3112 to provide more detailed information about
which internal data link is having a fault.
• On data link failures detected by the CFC (CM side), the alarm differentiates between the two links to the service module
by designating the alarm as “A” or “B”, and the failure can be detected by either CFC. On data link failures detected by
Line Cards, the alarm differentiates between the four links by using both the A/B designation and the CFC slot.
1.14.3.2 Alarms for the CFC200
The CFC200 supports all of the pre-release 14.0 CFC card alarms, in addition to the following new alarms. (Refer to the
Allied Telesis Log Manual for complete information on these alarms.)
• Control link lost - as explained above, when control link is lost between CFCs
• USB Failure - because of thermal shutdown or over-current
• High Temperature - as detected by the temperature sensor on the CFC.
Alarms for the inactive CFC have a high severity due to the fact that losing the inactive CFC causes a loss in total system
bandwidth.
1.14.3.3 Alarms for the Service Modules
The XE and GE24 type line cards all support a standard set of alarms, and in addition the following new control and data link
alarms.
•
•
•
•
•
•
•
Control link lost
Datalink lost (CM side: link A)
Datalink lost (CM side: link B)
Datalink lost (Line Card side: link A to slot 4)
Datalink lost (Line Card side: link B to slot 4)
Datalink lost (Line Card side: link A to slot 5)
Datalink lost (Line Card side: link B to slot 5)
1.14.3.4 PSU Card Alarms
The PSU cards support the following alarms.
•
•
•
•
•
•
•
Card Not Present
Input Voltage Fault
No Communication
Output Voltage Fault
High Temperature - as detected by the temperature sensor on the PSU
General Fault - PSU failures for which there is no more specific alarm (e.g. fan failure)
There are some notable behaviors of PSU alarms during a PSU mismatch (System PSU installed in a PoE PSU slot or vice
versa) scenario.
If a PoE PSU is installed in a System PSU slot (slot C or D), the following alarms are generated for the mismatched slot:
• Input Voltage Fault
1.
• Output Voltage Fault
• PSU General Fault - (This alarm will be masked.)
210
If a System PSU is mistakenly installed in a PoE PSU slot (slot A or B), the behavior depends on whether a PoE PSU is
installed in the other PoE PSU slot. If a PoE PSU is installed in one PoE PSU slot and a System PSU is installed in the other
PoE PSU slot, the following alarms are generated for the mismatched slot:
• Hardware Not Recognized
2.
• No Communication
If a System PSU is installed in one PoE PSU slot and there is no other PoE PSU installed, there will be no alarms.
1.14.4 Fan Module Alarms
Alarms for the fan module include the following.; (Refer to the Allied Telesis Log Manual for complete information on these
alarms.)
•
•
•
•
•
Fan Module Not Present
Fans Not Rotating Properly
No Communication
High Temperature - as detected by one or more of the temperature sensors on the fan tray.
211
1.14.5 ALARM Commands
TABLE 1-42
Alarm Commands
Commands
SET ALARMS THRESHOLD
SETDEFAULTS ALARMS THRESHOLD
SHOW ALARMS
SHOW ALARMS PORT
SHOW ALARMS THRESHOLD
212
SET ALARMS THRESHOLD
Syntax
SET ALARMS THRESHOLD [ MINOR=value ] [ MAJOR=value ] [ CRITICAL=value ]
Description
The alarm thresholds control when the MINOR, MAJOR, and CRITICAL Port Outage Threshold
alarms are raised. The entered values must be non-zero and satisfy the condition: MINOR < MAJOR <
CRITICAL These signify the lowest number of ports for that alarm to be raised. When all UPLINK
ports are out of service a CRITICAL alarm will be raised regardless of the threshold values.
Mode
Manager
Options
Option
Description
Range
Default
Value
THRESHOLD
The threshold for MINOR, MAJOR, CRITICAL port
outage alarms.
NA
NA
MINOR -Minimum number of ports before a MINOR
alarm is raised.Setting minor to anything greater than
one is allowed but not recommended. That means that
(MINOR - 1) ports can be out of service before the
threshold alarm is raised.
MAJOR -Minimum number of ports before a MAJOR
alarm is raised.
CRITICAL -Minimum number of ports before a CRITICAL alarm is raised.
Release Note
NA
Example
SET ALARMS THRESHOLD MINOR=10
Warning(033613): 9 ports can go out of service before
an alarm is raised if the MINOR threshold is 10.
Threshold Mark
-------------------------------------MINOR
10
MAJOR
24
CRITICAL
128
213
Syntax
Description
Sets all alarm threshold values back to the factory defaults.
Mode
Manager
Options
NA
Release Note
NA
Example
214
SHOW ALARMS
Syntax
SHOW ALARMS [ { ALL | CARD={ slot-list | ACTCFC | INACTCFC | ALL } | INTERFACE={ type:id-range | id-range | ifname-list | ALL } } ] [ SEVERITY={ CRITICAL | MAJOR | MINOR | INFO | ALL } ] [ FULL ]
Description
Displays alarm conditions on system components. The display is filtered according to the given parameters and shown in a tabular output, with one alarm per row. There are 4 columns of output for each
alarm consisting of:
Mode
•
The component the alarm is against
•
A description of the fault or condition
•
The severity of the alarm
•
The time and date the alarm occurred.
User
Options
Option
ALARMS
Description
Range
Default
Value
The component that will have its alarms displayed.
NA
ALL
NA
NA
ALL - all system components
CARD - The slot number for the card
ACTCFC- The acive CFC
INACTCFC- The inactinve CFC
ALL - All alarms on all system components are displayed.
INTERFACE
Specifies the list of interfaces that may have an alarm
against them. Interfaces can be of varioust ypes like,
ETH or LAG. LAG type of interface can have more than
one physical port associated with it.
Interfaces can be queried by using 'type:id-range', 'namelist' or 'ALL' options.
For example, 'ETH:2.0', 'ETH:2.1-2.4', where 2.0,2.1 etc
are the actual physical ports and are used as the interface Id's in this representation.
215
Option
Description
Range
Default
Value
SEVERITY
Indicates the severity level to filter the display with.
Severity indicates the degree of service impact associated with an alarm condition. The following severities
are defined:
NA
NA
NA
NA
- CRITICAL: A critical alarm is used to indicate that a
severe, service-affecting condition has occurred and
that immediate corrective action is imperative.
- MAJOR: A major alarm is used to indicate a serious
disruption of service or the malfunctioning or failure of
important circuits. These troubles require immediate
attention and response to restore or maintain system
capability. The urgency is less than critical situations
because of lesser immediate or impending effect on service or system performance.
- MINOR: Minor alarms are used for troubles that do
not have serious effect on service to customers or for
troubles that do not effect essential system operation.
- INFO: Represents an informational message. No
explicit action is required.
FULL
Release Note
Show all alarms regardless of whether or not they are
masked
NA
Example
SHOW ALARMS=ALL
-----------3.0
3.1
3.2
3.3
3.6
3.7
3.8
3.9
3.10
Fault
-------------------------------Loss of Link
Loss of Link
Loss of Link
Loss of Link
Loss of Link
Loss of Link
Loss of Link
Loss of Link
Loss of Link
Severity
-------Major
Major
Major
Major
Major
Major
Major
Major
Major
Time Stamp
-------------03:07:26 07/30
03:07:26 07/30
03:07:26 07/30
03:07:26 07/30
03:07:26 07/30
03:07:26 07/30
03:07:26 07/30
03:07:26 07/30
03:07:26 07/30
216
SHOW ALARMS PORT
Syntax
SHOW ALARMS [ PORT [ ={ port-list | ALL } ] ] [ FULL ]
Description
Shows alarms for a specified set of ports or all ports.
Mode
User
Options
Release Note
Option
Description
Range
Default
Value
PORT
The comma-separated list of port(s) that will have its
alarms displayed.
NA
ALL
FULL
Includes more descriptive information.
NA
NA
NA
Example
SHOW ALARMS PORT=3.0,3.1
-----------3.0
3.1
Fault
-------------------------------Loss of Link
Loss of Link
Severity
-------Major
Major
Time Stamp
-------------03:07:26 07/30
03:07:26 07/30
217
Syntax
Description
Displays alarm threshold settings for MINOR, MAJOR, CRITICAL port outage alarms.
Mode
User
Options
NA
Release Note
NA
Example
>SHOW ALARMS THRESHOLD
Threshold Mark
-------------------------------------MINOR
1
MAJOR
24
CRITICAL
128
218
1.15 Power Management and System Cooling
1.15.1 Power Management
The power and system cooling for the SBx3112 involves the following components:
• SBxFAN
• POE Power Supply Units (PSU)
• System Power Supply Units (PSU) - There are two types, AC and DC.
The next two sections describe their functions and how the interact.
1.15.1.2 Power Supply Unit (PSU)
There are four removable system Power Supply Units (PSU) labeled on the front of each shelf. They are in groups of two,
with each group providing the following
• System - These are labeled as “SBxPWR-SYS/AC”. Each system PSU has AC power input, with output voltage of 12VDC
and output power of 1200 W.
• Power over Ethernet (PoE) - These are labeled as “SBxPWR-POE/AC”. Each POE PSU has AC power input, with output
voltage of 56VDC and output power of 1200 W.
Model numbers for the PSUs follow the numbering scheme AT-SBxPWRSYS1-xx (System) and AT-SBxPWRPOE1-xx (POE),
with the nn designating a country or region. Refer to the SwitchBlade x3112 Installation Guide for specific model numbers.
The POE PSUs reside in power slots A and B, and the system PSUs reside in power slots C and D. The slots are electronically
keyed to prevent a PSU from being damaged if accidentally inserted in the wrong slot; the PSU will only draw power and light
LEDs in the correct slot. If an incompatible PSU is inserted into a PSU slot, the system will raise an alarm, CARD MISMATCH. (Refer to the Log Manual.)
1.15.1.3 Power Supply Functions
All 4 power supplies are monitored and controlled for voltage, current, and temperature levels, and controlling the on/off
state. All are hot swappable.
The system power supplies operate in a load sharing mode, but the system can run with a single system power supply. If both
system PSUs have been configured in the system but one of them is physically not present, then the system will report a
power feed failure alarm. However, if only one PSU is configured in the database the system does not report a power feed
failure alarm. Thus the customer can run normally on one system PSU if they desire, but dual PSUs are recommended for
increased fault tolerance.
There are two, replaceable opto-coupler modules on the back of the chassis, labeled as SBxOCPLR. There is one for PSU
slots A and C, and the other is for PSU slots B and D, as indicated on the back of the chassis. These opto-coupler modules
are not hot- swappable and affect the control plane between the CFCs and the PSUs. Each opto-coupler has a green power
LED that is illuminated under normal circumstances. In the event that an opto-coupler module is faulty, the CFCs will not be
able to communicate with the associated PSUs. Therefore, as part of troubleshooting an alarm on the PSUs, the user should
visually inspect the associated opto-coupler on the back of the chassis to ensure that it is functioning.
PSUs can be queried from the CLI using SHOW PSU. PSUs cannot be disabled or enabled but can be created and destroyed.
The CREATE PSU command assumes that slot A and B are for POE type PSUs, and slots C and D are for system PSUs, so the
user doesn't have to specify the PSU type on the command. PSUs can be destroyed from the system database using
DESTROY PSU, but only if they are not physically present. The system will only allow one system PSU to be destroyed under
219
any circumstance, but will allow both POE PSUs to be destroyed if not physically present. PSUs are always auto provisioned
upon insertion regardless of system provisioning mode.
1.15.1.4 Sample Command Output
The following are examples of power supply unit commands.
show psu
---A
B
C
D
Type
-----POE
POE
System
System
State
----UP-UP
UP-UP
UP-UP
UP-UP
Temp(C)
------43
47
32
30
show psu full
--- Power Supply Units --Slot............................................................
Type............................................................
State...........................................................
Hardware
Model Number..................................................
Serial Number.................................................
Actual
Temperature...................................................
A
POE
UP-UP-Online
AT-SBxPWRPOE1-10
A043334101100005
43 degrees Celsius
Type............................................................
State...........................................................
Hardware
Model Number..................................................
Serial Number.................................................
Actual
Temperature...................................................
B
POE
UP-UP-Online
AT-SBxPWRPOE1-10
A043334101100003
47 degrees Celsius
Type............................................................
State...........................................................
Hardware
Model Number..................................................
Serial Number.................................................
C
System
UP-UP-Online
AT-SBxPWRSYS1-80
A043334101100022
220
Actual
Temperature................................................... 32 degrees Celsius
Type............................................................
State...........................................................
Hardware
Model Number..................................................
Serial Number.................................................
Actual
Temperature...................................................
D
System
UP-UP-Online
AT-SBxPWRSYS1-80
A043334101100010
30 degrees Celsius
Following is an example of manually destroying and recreating a PSU that is not physically present
show psu a
--- Power Supply Units --Slot..................................
Type..................................
State.................................
Hardware
Model Number........................
Serial Number.......................
Actual
Temperature.........................
A
POE
UP-DN-NotInstalled
<none>
<none>
0 degrees Celsius
PSU Faults
PSU Card Not Present............ Major
officer SEC>> destroy psu a force
officer SEC>> show psu a
----------------------------------------------------------------------------No information to display from settings provided
----------------------------------------------------------------------------officer SEC>> create psu a
officer SEC>> show psu a
Type..................................
State.................................
Hardware
Model Number........................
Serial Number.......................
Actual
A
POE
UP-DN-NotInstalled
<none>
<none>
221
Temperature......................... 0 degrees Celsius
PSU Faults
PSU Card Not Present............ Major
222
1.15.2 Power Supply Commands
TABLE 1-43
Power Supply Commands
Commands
CREATE PSU
DESTROY PSU
SHOW PSU
223
CREATE PSU
Syntax
CREATE PSU={ A | B | C | D }
Description
Creates the one to four PSUs for the SBx3112
Mode
Manager
Options
Option
Description
Range
Default
Value
PSU
The CREATE PSU command allows the user to create
POE Power Supply Units (PSUs) for preprovisioning.
The CREATE PSU command assumes that slot A and B
are for POE type PSUs, and slots C and D are for system PSUs.
NA
NA
PSUs are always auto provisioned upon insertion
regardless of system provisioning mode. A single POE
PSU that is not receiving power on the back of the unit
is *not* detected as present in the shelf, because POE
power is used to detect POE presence. If a second POE
PSU is added and powered, then the first will appear as
present.
Release Note
NA
Example
CREATE PSU=A
224
DESTROY PSU
Syntax
DESTROY PSU={ A | B | C | D }
Description
Destroys the one to four PSUs for the SBx3112.
Mode
Manager
Options
Option
Description
Range
Default
Value
PSU
The DESTROY PSU command allows the user to
destroy POE Power Supply Units (PSUs). The
DESTROY PSU command assumes that slot A and B are
for POE type PSUs, and slots C and D are for system
PSUs. PSUs can be destroyed from the system database
using DESTROY PSU, but only if they are not physically
present. The system will only allow one system
PSU1200 to be destroyed under any circumstance, but
will allow both POE PSUs to be destroyed if not physically present.
NA
NA
Release Note
NA
Example
DESTROY PSU=B
225
SHOW PSU
Syntax
SHOW PSU [ ={ A | B | C | D | ALL } ] [ FULL ]
Description
Shows the status of the PSUs on the SBx3112.
Mode
User
Options
Release Note
Option
Description
Range
Default
Value
PSU
Allow the user to view the configuration an status information of the given PSU. If ALL or no value is provided
with the PSU parameter, a summary view of all PSUs is
displayed.
NA
ALL
FULL
A more detailed output of PSU information is displayed.
NA
NA
NA
Example
manager SEC>> SHOW PSU C FULL
Type..................................
State.................................
Hardware
Model Number........................
Serial Number.......................
Actual
Voltage (measured/nominal)..........
Current.............................
Power...............................
Temperature.........................
C
System
UP-UP-Online
AT-SBxPWRSYS1-80
00
12.3/12.0 Volts
278.0 Amps
3419.4 Watts
33 degrees Celsius
1.15.3 System Cooling
The system fan tray is identified in software as FM4 and is a removable module that consists of:
• Four fans
• Three temperature sensors
• Controller Board
1.15.3.2 Temperature Sensors
There is an additional temperature sensor on the CFC200, monitored for high temperature alarms, and can be queried for
current readings via CLI and SNMP, but is not used to control the fan speeds. There are also temperature sensors on the
PSUs.
Note:
The specific alarm on the CFC200 is “High Temperature” and is described in the Log Manual.
226
1.15.3.3 Temperature and Fan Control
The system controls the fan tray to include reading the IDPROM, monitoring temperature and fan speed, and adjusting the
fan speed. The user cannot change the fan speed settings (There is no support for SET FANMODULE SPEED like on 9100.)
The user can query the fan speeds and temperature readings using CLI and SNMP, the same as with the iMAP products.
Unlike the iMAP products, the fan module cannot be administratively disabled.
The SBx3112 is designed to operate at commercial temperatures over a temperature range from 0-40 degrees Celsius. However, the fan tray on SBx3112 does have a cold temperature shutdown mode which is enabled once the fan sensor drops to
~11C. When enabled, the cold temperature shutdown mode protects the fans by turning them off. The system exits cold
temperature shutdown when the fan sensor rises to ~15C, and the fans resume operation.
1.15.3.4 Example Command Output
The following are examples of SYSTEM COOLING and FANMODULE commands and output. Note that in the case that
temperature sensors can not be read, for example because the card containing the sensor is not physically present, then the
temperature for that sensor would be shown as “Not Available”.
officer SEC>> show system cooling
--- Temperature Sensors --Fan
Fan
Fan
CFC
CFC
PSU
PSU
PSU
PSU
Tray
Tray
Tray
Slot
Slot
Slot
Slot
Slot
Slot
Sensor #1....................
Sensor #2....................
Sensor #3....................
4 ...........................
5 ...........................
A ...........................
B ...........................
C ...........................
D ...........................
31
32
30
40
42
42
42
47
47
Celsius
Celsius
Celsius
Celsius
Celsius
Celsius
Celsius
Celsius
Celsius
--- Fan Module --Fan Module............................
Model Number..........................
Serial Number.........................
State.................................
FM4
AT-SBx31FAN
102
UP-UP-Online
Actual
Fan Speed
Fan 1.............................
Fan 2.............................
Fan 3.............................
Fan 2.............................
Cold Temperature Shutdown...........
2685
2724
2702
2690
Off
rpm
rpm
rpm
rpm
officer SEC>> show fanmodule
227
Model Number..........................
Serial Number.........................
State.................................
FM4
AT-SBx31FAN
102
UP-UP-Online
Actual
Fan Speed
Fan 1.............................
Fan 2.............................
Fan 3.............................
Fan 2.............................
2685
2724
2702
2690
Off
rpm
rpm
rpm
rpm
1.15.3.5 High Temperature Alarms
The SBx3112 system raises high temperature alarms against individual components that cross a high temperature threshold.
The thresholds are as follows:
TABLE 1-44
High Temperature Alarm Thresholds
Component
Alarm is Raised (Celsius)
Alarm is Cleared (Celsius)
CFC
70
65
FAN
55
50
PSU
50
45
Note:
The FAN alarm is based on the highest reading of the three temperature sensors on the fan module.
228
1.15.4 System Cooling Commands
TABLE 1-45
System Cooling Commands
Commands
DISABLE FANMODULE
ENABLE FANMODULE
SHOW FANMODULE
SHOW SYSTEM COOLING
229
DISABLE FANMODULE
Syntax
DISABLE FANMODULE
Description
Changes the ADMINSTATE of the system fan module to DOWN. The operational state remains UP
and the fan module continues to operate. Use of this command is recommended before physically
removing the module.
Mode
Manager
Options
NA
Release Note
NA
Example
DISABLE FANMODULE
230
ENABLE FANMODULE
Syntax
ENABLE FANMODULE
Description
Changes the ADMINSTATE of the system fan module to UP. The operational state remains UP and the
fan module continues to operate.
Mode
Manager
Options
NA
Release Note
NA
Example
ENABLE FANMODULE
231
SHOW FANMODULE
Syntax
SHOW FANMODULE
Description
Displays various information about the system fan module, including: - dynamic state attributes alarms and defect conditions - current fan speeds.
Mode
User
Options
NA
Release Note
NA
Example
>SHOW FANMODULE
Model Number..........................
Serial Number.........................
State.................................
FM4
AT-SBxFAN
8
UP-UP-Online
Actual
Fan Speed
Fan 1.............................
Fan 2.............................
Fan 3.............................
Fan 4.............................
2428
2450
2435
2413
Off
rpm
rpm
rpm
rpm
232
SHOW SYSTEM COOLING
Syntax
SHOW SYSTEM COOLING
Description
Displays various information about shelf temperature and fan conditions. Information includes: - current readings of the shelf temperature sensors - any current faults related to the temperature sensors
- fan module information including dynamic state attributes, alarms and defect conditions, and current
fan speeds (the same information as the SHOW FANMODULE output).
Mode
User
Example
>SHOW SYSTEM COOLING
--- Temperature Sensors --Fan
Fan
Fan
CFC
CFC
PSU
PSU
PSU
PSU
Tray
Tray
Tray
Slot
Slot
Slot
Slot
Slot
Slot
Sensor #1....................
Sensor #2....................
Sensor #3....................
4............................
5............................
A............................
B............................
C............................
D............................
27 Celsius
29 Celsius
28 Celsius
not available
42 Celsius
not available
38 Celsius
42 Celsius
not available
Model Number..........................
Serial Number.........................
State.................................
FM4
AT-SBxFAN
8
UP-UP-Online
Actual
Fan Speed
Fan 1.............................
Fan 2.............................
Fan 3.............................
Fan 4.............................
2428
2448
2433
2412
Off
rpm
rpm
rpm
rpm
233
1.16 Basic Provisioning of Cards and Ports
1.16.1 Introduction
Provisioning for any SBx3112 means to query and control the configuration database, and involves the following:
• Provisioning Data - The provisioning data itself, which consists of:
• States - These determine whether the card or port can be placed in service and if so whether it can process data.
• Attributes - These are the characteristics of the card or port, usually to optimize the processing of data.
• Management Configuration - These are all the settings that allow the SBx3112 to communicate to management interfaces, and have been described in Section 3.
The provisioning data is stored in the CFC and can be retrieved and backed up when necessary, usually during a software
upgrade, described in Section 5.
• Persistence - This is the ability of the provisioning data to survive changes such as a reboot of the shelf or the removal
of a card.
• Pre-provisioning - The user has the option of creating a card and having it in the database prior to inserting the card.
1.16.2 Feature List
TABLE 1-46
Feature for the Provisioning of Modules
Feature
Description
Refer to
Module Configuration
Which modules are compatible with the ATI products
1.16.3
Provisioning Modes
Manual (PROVMODE = MANUAL) versus Automatic (PROVMODE = AUTO)
Provisioning Modes
1.16.4
User-Created Profiles
The user can modify the AutoProv profile provided for each card type or
port type (called a managed entity). User-created profiles are also possible,
1.16.5
AlliedView NMS Profile
Support
The NMS profile is displayed as an external profile with the SHOW INTERFACE command. If a port is de-provisioned at the NMS, the output for the
External Profile is set to None.
1.17.4
Administrative and operational States
The combination of the two determines whether the card or port is available
for service and, if available for service, whether it is being provided
1.17.5
Software Loads
The attributes of the load and how they determine module behavior, especially
during an upgrade.
1.10
Line Card Attributes
Attributes common to all Line Cards
1.17.6
XE4 Attributes
Attributes common to XE4 cards
1.17.7
1.16.3 Feature / Component Interaction
The components for the SBx3112 interfaces are divided into Service Modules and Control Modules.
Note:
This table includes the ATN code where applicable to specify the card. For more information on these cards,
especially model numbers and compatible releases, refer to the Allied Telesis Component Specification.
Controlling these components is done through the use of profiles, operational states, and provisioning modes, as explained
below.
234
TABLE 1-47
Detail
Minimum
Software
Release
SBx3112-00
SBx3112-00 Chassis Group
NA
SBx3106-00
SBx3112-00 Chassis Group
17.0
Component
Type
Component
Chassis
Cooling and
Power
Line Cards
Control
SBx3100 Cards
Model Number
FM4 (SBx3112)
SBxFAN12
Fan Controller
NA
FM2 (SBx3106)
SBxFAN06
Fan Controller
17.0
PoE Power Supply
AT-SBxPWRPOE1-xx
Up to two PSUs for Power over Ethernet
(PoE).
NA
System Power Supply AC
AT-SBxPWRSYS1-xx
Up to two PSUs for 12V system power
NA
System Power Supply DC
AT-SBxPWRSYS1-80
Up to two PSUs for 12V system power
15.1
GE24POE
SBx31GP24
10/100/1000M with PoE
14.1
XE4
SBx31XZ4
XFP-based 10G interface
14.1
GE24SFP
SBx31GS24
SFP-based 1G interface
14.2
GE24RJ
SBx31GT24
10/100/1000M without PoE
15.0
XE6SFP
SBx31XS6
SFP+-based 10G interface
15.1
GE40CSFP
SBx31GC40
SFP-based 1G interface (Compact)
16.0
GE40RJ
SBx31GT40
10/100/1000M without PoE
17.0
CFC200
SBx31CFC
Provides 200G in load sharing mode, so
in duplex provides 400G throughput.a
14.1
Full-height
NA
Modules
Filler Plate
FPF
a. In the SBx3106, the CFC200 must be configured with Release 17.x.
1.16.4 Provisioning Modes
1.16.4.1 Manual Provisioning Mode (PROVMODE = MANUAL)
In this mode, commands are used to create, modify, or delete the provisioning data. The data is persistent over reboots and
restarts of the Allied Telesis system and the removal of the card. (To delete a card, the user must explicitly do so with the
DESTROY CARD command.)
Important to note is that insertion of a card when in the Manual Provisioning Mode does not create/provision the card in the
database; this must be done using the CREATE command.
1.16.4.2 Automatic Provisioning Mode (PROVMODE = AUTO)
In the AUTO mode, hardware is discovered in a slot where there is no prior provisioning and the cards and ports are automatically provisioned. This discovery occurs when:
235
• The card is inserted into a slot (this would not apply to a CM in a simplex system since it is in simplex mode).
• The Network or Service Module is already inserted and the following occurs:
• The Control Module powers up
• The Control Module reboots
• The system mode is changed from manual to automatic.
Similar to the Manual Provisioning Mode, commands are used to create, modify, or delete provisioning data, and data is persistent over reboots/restarts of the system and the removal of the card.
Note:
The default mode for the Allied Telesis series products is Automatic Provisioning Mode (PROVMODE=AUTO), and
the mode can be changed through commands
Note:
Once the user has set the PROVMODE to MANUAL, the user must explicitly provision Allied Telesis Series
modules and ports using CLI commands. It is recommended that the default AUTO mode be used.
1.16.4.3 The AUTOPROV Profile
When the system is first initialized, the system’s PROVMODE is set to AUTO, and all modules come up with the profile name
AUTOPROV.
Note:
Modification of a profile does not change the attributes of a card/port that has already been provisioned.
1.16.4.4 Provisioning Data at Startup
When the system is first brought up, it is configured as follows:
•
•
•
•
The Provisioning Mode is set to AUTO (PROVMODE=AUTO)
All modules and ports use the AUTOPROV profile
The AUTOPROV profile is set to the factory defaults.
The Administrative State of all modules and ports is UP, and the Operational State is set to UP if the module/port can
process data.
1.16.4.5 Provisioning Mode (SHOW SYSTEM PROVMODE)
Use this command to view whether the Provisioning Mode is MANUAL or AUTO.
officer SEC> SHOW SYSTEM PROVMODE
System is in AUTO provisioning mode
1.16.5 Custom Profiles
The user can modify the AutoProv profile provided for each card type or port type (called a managed entity). User-created
profiles are also possible, and these profiles have the following attributes:
• Profile Creation
Profiles are created with the CREATE PROFILE command.
Profile names must be unique within a type; they are case insensitive.
• Applying Profiles to Managed Entities
Configuration settings of a Profile are applied to managed entities when requested at the CLI as long as the Profile and
entities define the same type.
236
Configuring a User Profile
If a profile is applied to a managed entity and the user manually changes an attribute of the managed entity, the managed
entity keeps it reference to the Profile but indicates that it no longer matches the Profile.
If a Profile is modified, all managed entities using the Profile indicate their provisioning no longer matches the profile.
An entity must be disabled before a different Profile can be applied.
A profile controls the attributes of the entity, but not the state.
• Destroying User Profiles
Any user-created Profile can be destroyed (unlike AutoProv, which can never be destroyed).
If a Profile that has been applied to managed entities is destroyed, the managed entity has no Profile (this shows up as
<none>).
• Command Changes for Profile Names
One of the main change to existing commands is that the SHOW PROFILE NAMES command has changed to SHOW PROFILE=name for card and port types.
The set of commands used to create, change, and destroy profiles is not that large; however, for each type there are different parameters since each type has different attributes.
1.17 Configuring a User Profile
1.17.1 Default Configuration
When an SBx3112 switch is initially booted up, Profiles will be configured as follows:
• All card profiles are set to AUTOPROV
• ALL port profiles are set to AUTOPROV
1.17.2 Configuration Guidelines
Any profiles that are created, changed, or destroyed, are persistent; this means the following:
• Reboot - Any changes made to profiles survive a system reboot
• Redundancy - The profile settings are mirrored in both CFCs, and so survive an activity switch.
• Upgrade - The profile settings survive over an upgrade (not relevant for release 6.0).
Note:
Although the user can SET a Profile, this does not mean that profile can be applied successfully. General checks are
done on the profile, but some checks cannot be done until the user tries to apply the profile to an entity.
To associate an interface with a profile, the interface must be disabled.
1.17.3 Configuration Procedure
The following procedure walks through all of the steps needed to create a user profile
Note:
In the outputs below, the response may be abbreviated if it does not add to the concepts being explained. Removed
output is shown with an extended dotted line (...............................)
237
TABLE 1-48
Step
Configuration Procedure for User profile
Command
Description
Show the cards in the SBx3112
1
SHOW CARD
--- Card Information --Slot
----0
1
2
3
4
5
6
7
8
9
10
11
Prov
Card Type
--------GE24POE
GE24POE
GE24POE
CFC200
CFC200
GE24POE
GE24POE
GE24POE
GE24SFP
XE4
XE4
State
---------------------------------------DN-DN-NotInstalled
DN-DN-NotInstalled
DN-DN-NotInstalled
UP-UP-Online (Inactive)
DN-DN-NotInstalled
DN-DN-NotInstalled
UP-UP-Online
DN-DN-NotInstalled
UP-UP-Online
UP-UP-Online
Faults
-----Info
Info
Info
Info
Info
Info
-
Show the Profiles that exist. If no profiles have been created, the are all AUTOPROV.
2
SHOW PROFILE NAMES
--- Card Profiles --Name
-------------------------------AutoProv
AutoProv
AutoProv
AutoProv
Type
---------CFC200
GE24POE
GE24SFP
XE4
--- Port Profiles --Name
-------------------------------AutoProv
AutoProv
Type
------GEPORT
XEPORT
Show the AUTOPROVattributes for a specific port.
3
>SHOW PROFILE AUTOPROV=GE
--- Gigabit Ethernet Port Profiles --Name...............................
Type...............................
Initial Admin State................
Auto Negotiation...................
Speed..............................
Duplex.............................
Flow Control.......................
AutoProv
GEPORT
Up
On
Auto
Auto
Auto
Create a Profile, gold, where all of the attributes are the same except for FLOWCONTROL. This is added to the Port
Profiles.
238
TABLE 1-48
Configuration Procedure for User profile
Step
Command
Description
4
>CREATE PROFILE=GOLD GEPORT FLOWCONTROL=ON
Info (033561): Successfully created profile(s) GOLD
>SHOW PROFILE NAMES
--- Card Profiles --............................................
-------------------------------AutoProv
GOLD
AutoProv
Type
-------GEPORT
GEPORT
XEPORT
Associate an interface with the profile. (If necessary, disable the interface first.)The interface now has the profile attributes.
5
>SET INTERFACE=8.0 PROFILE=gold
>SHOW INTERFACE=8.0
--- GE Interfaces --Interface..........................
Type...............................
State..............................
Description........................
Remote ID..........................
External Profile...................
Card Type..........................
8.0
GE
UP-DN-Dependency
<none>
<none>
<none>
GE24POE
Provisioning
Provisioning Profile............ gold
Direction....................... Customer
..........................
1.17.3.1 Creating an Entity
When creating a card, the user has the option to CREATE the card and associate it with a Profile. If the user does not include
a Profile (that exists), the card and its associated entities (interfaces) will have <none> as the associated Profile.
>CREATE CARD=3 GE24POE
>SHOW INTERFACE 3.0
Type...............................
State..............................
Description........................
Remote ID..........................
Card Type..........................
3.0
GE
UP-DN-Dependency
<none>
<none>
<none>
GE24POE
Provisioning
Provisioning Profile............ <none>
------------------------------------
The user could now create a new Profile (silver) with changed attributes, and SET the interface (3.0) to this Profile. As a
result, the interface will be associated with the silver profile and have its attributes.
>CREATE PROFILE SILVER GEPORT FLOWCONTROL=ON
Info (033561): Successfully created profile(s) SILVER
>SHOW PROFILE NAMES
239
--- Card Profiles ---------------------------------------- Port Profiles --Name
-------------------------------AutoProv
SILVER
AutoProv
Type
---------GEPORT
GEPORT
XEPORT
>SET INTERFACE 3.0 PROFILE=SILVER
>SHOW INTERFACE=3.0
Type...............................
State..............................
Description........................
Remote ID..........................
Card Type..........................
3.0
GE
UP-DN-Dependency
<none>
<none>
<none>
GE24POE
Provisioning
Provisioning Profile............ SILVER
1.17.3.2 Setting an Interface to No Profile
If the user wishes to disassociate an entity with any Profile, two double quotes are used. Whatever profile the entity was
associated with is dropped and the entity has <none> for a Profile association.
>SET INTERFACE 3.0 PROFILE=""
Info (020186): Successfully modified interface(s) 3.0
>SHOW INTERFACE=3.0
Type...............................
State..............................
Description........................
Remote ID..........................
Card Type..........................
3.0
GE
UP-DN-Dependency
<none>
<none>
<none>
GE24POE
Provisioning
Provisioning Profile............ <none>
----------------------------------
1.17.4 AlliedView NMS Profile Support
1.17.4.1 Overview
The AlliedView NMS product also has a profile feature, but at a network service level; a profile is created for a card type or
port type, and can then be applied to multiple interfaces over multiple devices. Moreover, profiles can include a more global
set of attributes, such as traffic and performance management attributes. Finally, the profiles are filled out using pull-down
menus and GUIs, ensuring there is less chance of error.
Note:
Refer to the AlliedView NMS Administration Guide for a complete description of profiles.
240
When the NMS sets the port attributes by deploying an NMS profile, the SHOW INTERFACE command on the SBx3112 displays the NMS profile name that has been applied as an External Profile name. Moreover, if at the NMS a port is deprovisioned, the product output for External Profile is set to None.
1.17.4.2 Feature Operation
• NMS profile names can be set against any root interface of a card or any interface that can be dynamically created after a
card is provisioned. Interfaces include ETH (for XE4, GE24POE, and GE24SFP) and any future interfaces.
• LAG interfaces are explicitly excluded from support by this feature as they have no corresponding profile in the NMS.
These interfaces reject NMS profile name setting.
• If the profile name associated with an interface is changed at the NMS, the NMS updates the product to ensure that
NMS and product are in sync with regard to the profile name.
• If, at the NMS, a new profile is applied to a given collection of interface, the NMS automatically updates the product.
• The profile settings exist at the CLI to ensure that the profile name survives in a text configuration-based restore. As a
result, users have the ability to override the NMS profile name at the product. This results in mismatch notifications at the
NMS when the NMS rediscovers the device. The user at the NMS can then redeploy the NMS profile and reset the External Profile name to the NMS Profile name.
• The NMS profile name has a maximum of 50 characters, and rejects a profile name of ‘None’. (Refer to the AlliedView
NMS Administration Guide for a complete description of Profile naming conventions.)
The SET INTERFACE EXTERNALPROFILE supports the specification of an external profile name on an interface.
Note:
In most circumstances, the user should not manually change the External Profile name.
>SHOW INTERFACE=10.0
--- XE Interfaces --Interface..........................
Type...............................
State..............................
Description........................
Remote ID..........................
Card Type..........................
10.0
XE
UP-UP-Online
<none>
<none>
gold
XE4
Provisioning
Provisioning Profile............ AutoProv
Flow Control.................... Off
Remote Monitoring............... Off
Actual
Direction....................... Network
............
1.17.5 Administrative and Operational States
1.17.5.1 Overview
Administrative and Operational States determine whether the card or port is available for service and, if available for service,
whether it is being provided:
• The Administrative State is controlled by the user and can be set to either UP (available for service) or DOWN (Not
available for service). Control of this state is through the ENABLE/DISABLE command.
• The Operational State is either UP (providing service) or DOWN (not providing service). This state is not user controllable but does depend on the Administrative State:
• If the Administrative State of a card is UP, the Operational State will be UP if the card/port can provide service.
• If the Administrative State is DOWN, the Operational State will always be DOWN.
241
1.17.6 Common Line Card Attributes
The attributes for a Line Card are shown in the display for the SHOW CARD <slot number> command.
Following is the output for the command. Table 1-49 describes the attributes and states that are common for Ethernet cards.
E134 - officer SEC>>>> show card 3
Type...............................
State..............................
3
GE24POE
UP-UP-Online
AutoProv (*)
Hardware
Model Number (Revision)......... AT-SBx24POE (Rev X6)
Serial Number................... 17
CLEI Code....................... <none>
Software
Running Load.................... 14.2.0.dhays.20100325
Preferred Load.................. ge24poe_14.2.0.dhays1.20100325.tar
Temporary Load.................. <none>
.
TABLE 1-49
Common Line Card Attributes - Defaults are in Bold)
Card Attribute
Values / Range
Description
Slot
Slot Number
The slot number occupied by the card
Type
Depends on the card type
The type of card
242
TABLE 1-49
Common Line Card Attributes - Defaults are in Bold) (Continued)
Card Attribute
Values / Range
Description
State
Three attributes:
These three attributes determine the state of the
card; whether it is capable of carrying traffic and the
status (Implied Operational Status)
- Admin State
- Operational State
- Status
ONLINE - Card is configured and can provide service. (UP)
DEGRADED - There is a fault but the card can still
provide service (UP)
OFFLINE - The normal status when a card is in a
DOWN state. The card requires a routine operation
to place it ONLINE and available for service.
(DOWN)
FAILED - The card has detected a hardware or software fault that makes it unable to provide service.
(DOWN)
NOT INSTALLED - Card is provisioned in software
(CREATE) but not physically present (DOWN)
RESET - transient state as card resets (DOWN)
LOADING - The software load is being transferred
from the CFC to the flash memory in the card.
(DOWN)
Note:
A percentage number for loading is
included. Once at 100%, there may
still be a delay so that the transfer of
software to the card is complete.
BOOTING - The software load is being copied from
the flash memory into its RAM memory. (DOWN)
IN TEST - Card is running diagnostics (DOWN)
CONFIGURING - Provisioning data for he card is
being copied from the CFC to the RAM memory on
the card. (DOWN)
TERMINATING - The card is performing an operation in preparing to go out of service. (UP or
DOWN)
Provisioning Profile
Profile that has been applied to
the card and if there is a Profile
mismatch.
If there is a status mismatch, a (*) appears next to
the Profile Name. Refer to 1.16.5.
Hardware
Model Number
The TN number for card type
Serial Number
The unique serial number for the card
CLEI Code
The CLEI code, if the card has one.
Running
Refer to 1.10.
Preferred SW Load
Preferred SW Load
Temporary SW Load
243
1.17.7 XE4 Card Attributes
The only common attribute for XE4 cards is the ADMIN STATE (UP or DOWN).
Note:
If the user sets the Administrative State of the NM card to DOWN (using the DISABLE command with the FORCE
option) and there is only one NM provisioned, upstream data service is lost for the SBx3112.
Following are the outputs for the Network Interfaces. (For details on the DIRECTION attribute, refer to 2.2.)
E134 - officer SEC>>>> SHOW INTERFACE DIRECTION=NETWORK
--- GE Interfaces --Interface
----------3.22
3.23
10.16
10.17
State
----UP-UP
UP-UP
UP-UP
UP-UP
Autonegotiate
------------On
On
On
On
Flow Control
-----------Off
Off
On
On
Duplex
-----Full
Full
Full
Full
Speed
-------1 Gbps
1 Gbps
1 Gbps
1 Gbps
Direction
--------Network
Network
Network
Network
--- XE Interfaces --Interface
----------0.0
0.1
0.2
0.3
2.0
2.1
2.2
2.3
State
----UP-UP
UP-DN
UP-DN
UP-DN
UP-DN
UP-DN
UP-DN
UP-DN
Flow Control
-----------Off
Off
Off
Off
Off
Off
Off
Off
Direction
--------Network
Network
Network
Network
Network
Network
Network
Network
--- General Interfaces --Interface
--------------ETH:0
LAG:0
LAG:1
State
----UP-UP
UP-UP
UP-UP
Name
---------MGMT
l1
l2
244
1.17.8 Card Management Commands
TABLE 1-50
Card Management Commands
Commands
CREATE CARD card_type
CREATE PROFILE cardtype
DESTROY CARD
DESTROY PROFILE
DISABLE CARD
ENABLE CARD
RESTART CARD
RESTART SYSTEM
RESTART SYSTEM
SET CARD PROFILE
SET PROFILE CARD_TYPE
SET SYSTEM
SHOW CARD
SHOW CARD MEMORY
SHOW PROFILE
SHOW SYSTEM PROVMODE
SWAP ACTIVITY
245
CREATE CARD CARD_TYPE
Syntax
CREATE CARD=slot card_type [{[PREFLOAD=filename] [ADMINSTATE={UP|DOWN}]| PROFILE=name}]
Description
Creates software provisioning for a card in a specific slot. A CARD is a field replaceable module that
occupies a slot. The ports on the specified card are automatically provisioned when the card is provisioned.
Mode
Manager
Note
Control and Fan Modules are automatically provisioned during system startup and are not affected by
the CREATE CARD command.
At minimum, when creating a card, the user must specify the slot number and the card type. If no
other parameters are entered, the card and its ports are provisioned using default values. If the card
auto provisioning profile is specified, then all card attributes are set to the values in the card auto provisioning profile and all port attributes are set to the values in the port auto provisioning profile. PROFILE specifies the name of the profile used to provision the card. The contents of a profile can be
displayed (SHOW PROFILE) and changed (SET PROFILE).
Options
Option
Description
Range
Default
Value
Card
The slot for the card. Refer to 1.16.1 for which cards
can be provisioned in which slots.
NA
NA
card_type
The type of card. For the SBx3112, the allowed card
types are GE24POE, GE24RJ, GE24SFP, and XE4.
NA
NA
PREFLOAD
Specifies the name of the preferred software load file for
the card. This file must reside on the CFC flash file system, and is loaded to the flash memory on the card (if
it's not already there) when the card is enabled or reset.
The command is rejected if the preferred software load
specified is not compatible with the specified card.
NA
NA
ADMINSTATE
The initial administrative state for the card. The administrative state reflects the user's intent on having the card
available for service (ready to process data).
NA
NA
PROFILE
A profile contains a set of pre-defined provisioning attributes. The contents of a profile can be displayed
(SHOW PROFILE) and changed (SET PROFILE).
NA
NA
Release Note
NA
Example
CREATE Card=2 GE24POE
246
CREATE PROFILE CARDTYPE
Syntax
CREATE PROFILE=name cardtype [ PREFLOAD=filename ]
[ ADMINSTATE={ UP | DOWN } ]
Description
Creates a profile for the specified card type. Attributes required are usually the PREFLOAD and
ADMINSTATE.
Mode
Manager
Options
Option
Description
Range
Default
Value
PROFILE
A profile contains a set of pre-defined provisioning attributes. The contents of a profile can be displayed
(SHOW PROFILE) and changed (SET PROFILE).
NA
NA
card_type
The type of card. For the SBx3112 the cards supported
are GE24POE, GE24RJ, GE24SFP, and XE4.
NA
NA
PREFLOAD
The command is rejected if the preferred software load
specified is not compatible with the specified card.
NA
NA
ADMINSTATE
The initial administrative state for the card. The administrative state reflects the user's intent on having the card
available for service (ready to process data).
NA
NA
Release Note
NA
Example
CREATE PROFILE=GOLD GE24POE ADMINSTATE=UP
247
DESTROY CARD
Syntax
DESTROY CARD=slot-list [FORCE]
Description
Removes software provisioning for the specified card or list of cards. The command fails if the administrative state for each card has not already been set to DOWN (See DISABLE CARD). A warning is
provided for this command and confirmation is required.
Mode
Manager
Options
Option
Description
Range
Default
Value
FORCE
Suppress.es the warning and bypasses the confirmation
NA
NA
Release Note
NA
Example
DESTROY CARD=2 GE24POE
248
DESTROY PROFILE
Syntax
DESTROY PROFILE=name cardtype
Description
Destroys a profile for the specified card type. No other attributes are required. Any managed entity
that had a Profile applied is set to (no profile association).
Mode
Manager
Options
Option
Description
Range
Default
Value
card_type
The type of card. For the SBx3112 the cards supported
are GE24POE, GE24RJ, GE24SFP, and XE4.
NA
NA
Release Note
NA
Example
DESTROY PROFILE=GOLD GE24POE
249
DISABLE CARD
Syntax
DISABLE CARD={slot-list|INACTCFC} [FORCE]
Description
Takes a card out-of-service and sets the card's administrative state to DOWN. A list or range of slots
is accepted. It is recommended that the user disable the card before physically removing it from the
slot. The DISABLE CARD command is disallowed for the slot containing the active CFC card. A confirmation is provided before the card is taken out-of-service.
Mode
Manager
Note
For the GE24POE, disabling the card will cause power to be disabled for all affected ports. However, it
will not change the admin state of the PoE feature for those ports, only the operational state. Refer to
DISABLE POE INTERFACE.
Options
Option
Description
Range
Default
Value
CARD
The slot number or list of slot numbers separated by a
comma.
NA
NA
INACTCFC
For a dual CFC, the inactive one.
NA
NA
NA
NA
Caution; the CFCs operate in load-sharing mode, disabling one of the CFCs will mean a reduction in traffic
capacity.
FORCE
The confirmation message is suppressed.
Release Note
NA
Example
DISABLE CARD=2
250
ENABLE CARD
Syntax
ENABLE CARD={slot-list|INACTCFC} [NODIAGS] [VERBOSE]
Description
Changes the administrative state of the specified card to UP, making it available for service. A list or
range of slots is accepted. During the enable sequence, several steps are performed to initialize the
card and return it to service, such as card reset, hardware/software version compatibility checking,
reloading of the card if applicable and necessary, booting the software load if applicable, running out of
service diagnostics if applicable, sending card configuration data, and initiating defect monitoring on the
card.
If any of the ports on the card are in the enabled state (administrative state set to UP), they are also
initialized. Initialization steps for ports include configuration of enabled ports on the card, initiation of
defect monitoring on the port.
Mode
Manager
Options
Option
Description
Range
Default
Value
CARD
The slot number or list of slot numbers separated by a
comma.
NA
NA
INACTCFC
For a dual CFC, the inactive one. This will bring the card
into service so it may begin traffic load sharing.
NA
NA
NODIAGS
Signifies that out of service diagnostics will not run during the enable sequence. Out of service diagnostics are
run by default unless this parameter is provided.
NA
NA
VERBOSE
Lists the change in card status as the card is enabled.
(Logs, however, are always produced even if this option
is not used.)
NA
NA
Release Note
NA
Example
ENABLE CARD=2
251
RESTART CARD
Syntax
RESTART CARD={ slot-list | INACTCFC | ACTCFC } [ COLD ] [ FORCE ]
Description
Performs a restart of the software running on the specified card. For the active CFC card, the entire
system is affected and all cards are restarted.
Mode
Manager
Options
Option
Description
Range
Default
Value
CARD
The slot number of the card(s) to be reset. The list must
not include the slots for the ACTCFC or INACTCFC
NA
NA
INACTCFC
The inactive CFC as determined by the system.
NA
NA
ACTCFC
For a dual CFC, the inactive CFC as determined by
NA
NA
NA
NA
NA
NA
the system. Otherwise the single active CFC
COLD
For the active CFC card, a COLD restart - resets the
CFC and all other cards in the shelf - reboots and re initializes the software on the CFC - runs out of service
diagnostics on the CFC if previously scheduled through
use of the DIAGNOSE CARD command - reloads configuration data from the system database - manages
recovery of the remaining cards in the shelf
For the inactive CFC card, a COLD restart - changes
the operational state to DOWN, if not already DOWN
- performs a hardware reset on the card - reboots and
re initializes the software - runs out of service diagnostics - reloads configuration data - restores the operational state to UP if the administrative state is UP,
including data initialization and initiation of defect monitoring
FORCE
Performs the reset without the confirmation message.
Release Note
NA
Example
RESTART Card=INACTCFC COLD FORCE
252
RESTART SYSTEM
Syntax
RESTART SYSTEM [ FORCE ]
Description
Restarts the system. If the command is executed on a duplex system, avoiding the requirement to
restart both the ACTCFC and INACTCFC.
Mode
Manager
Options
Option
Description
Range
Default
Value
FORCE
Performs the reset without the confirmation message.
NA
NA
Release Note
NA
Example
RESTART SYSTEM
253
SET CARD
Syntax
SET CARD={slot-list|ACTCFC|INACTCFC}
{PREFLOAD={filename|NONE}|
ALTLOAD={filename|NONE}|
TEMPLOAD={filename|NONE}}
Description
The SET CARD command modifies the provisioning attributes for the specified card or list of cards.
The administrative state is modified through the ENABLE CARD or DISABLE CARD commands, so
the only provisioning attributes that are modifiable with the SET CARD command relate to software
load file preferences. Therefore, this command is only used during software load changes to set software load preferences for cards.
Mode
Manager
Options
Option
Description
Range
Default
Value
CARD
The slot number of the card(s) to be modified.
NA
NA
PREFLOAD
Refer to 1.8.1 on software loads.
NA
NA
Setting of PREFLOAD is not allowed for the inactive
CFC; it obtains its prefload settings from the active
CFC.
ALTLOAD
The ALTLOAD is used when a redundant copy of the
preferred load file is made on the CM FLASH file system; it specifies an alternate load preference for the
redundant file. Establishing an alternate load provides a
backup in the unlikely event that the preferred load file
cannot boot.
NA
NA
TEMPLOAD
A load designated as TEMPLOAD indicates that this
is the load that the specified card will load from, one
time, during the next loading process. The TEMPLOAD designation is used during the software upgrade
procedure.
NA
NA
Release Note
NA
Example
SET CARD=ACTCFC PREFLOAD=cfc200_14.1.0.GAMMA.20100303.tar
254
SET CARD PROFILE
Syntax
SET CARD=slot-list PROFILE=name
Description
Modifies the provisioning attributes for the specified card or list of cards. The administrative state is
modified through the ENABLE CARD or DISABLE CARD commands, so the only provisioning attributes that are modifiable with the SET CARD command relate to software load file preferences.
Therefore, this command is only used during software load changes to set software load preferences
for cards.
Mode
Manager
Options
Option
Description
Range
Default
Value
CARD
not include the slots for the ACTCFC or INACTCFC.
NA
NA
PROFILE
The name of an already created Profile
NA
NA
Release Note
NA
Example
SET CARD=2,3 PROFILE=SILVER
255
SET INTERFACE EXTERNALPROFILE
Syntax
SET INTERFACE={ type: | type:id-range | id-range | ifname-list | ALL }
EXTERNALPROFILE={ profile | NONE }
Description
Supports the specification of an external profile name on an interface. When the AlliedView NMS sets
the port attributes by deploying an NMS profile, the SHOW INTERFACE command on the product displays the NMS profile name that has been applied as an External Profile name. Moreover, if at the
NMS a port is deprovisioned, the product output for External Profile is set to None.
When the SBx3112 is managed by the NMS, this command should not be used.
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
The interface that will have the external profile.
NA
NA
EXTERNALPROFILE
Used to identify the name of a profile associated with
the interface that is external to the SBx3112, such as the
NMS. This parameter is used by external management
systems to identify the profile specified by the management system. The profile name can then be used by CLI
users to correlate external configuration settings with
interfaces.
NA
NA
Release Note
NA
Example
SET INTERFACE=8.* EXTERNALPROFILE=GE24POE_ClassA
256
SET PROFILE CARD_TYPE
Syntax
SET PROFILE=name card_type [PREFLOAD=filename] [ADMINSTATE={UP|DOWN}]
Description
Modifies provisioning attributes for the profile specified by name and component type. A profile for a
component is similar to a template, since it contains a set of pre-defined provisioning attributes. Usercreated Profiles and the name AutoProv are supported, which signifies the auto provisioning profile.
The auto provisioning profile is used by the system when cards and ports are discovered during card
insertion or system startup. The auto provisioning profile can also be manually applied to an already
provisioned card or port using the SET CARD or SET INTERFACE commands. Upon initial system
startup (before any user modification is done) the profiles are populated with factory default attributes. Any subsequent user modification of the profile attributes using this command is stored in the
system database and is retained over subsequent restarts.
Mode
Manager
Options
X
Option
Description
Range
Default
Value
PROFILE
The profile name that has been created.
NA
NA
card_type
A card type such as the GE24POE, GE24RJ, GE24SFP,
GE40RJ, GE40CSFP, XE6SFP, and XE4.
NA
NA
PREFLOAD
Refer to 1.8.1 on software loads.
NA
NA
ADMINSTATE
The admin state of the card when the card is initially
seated or restarted.
NA
UP
Release Note
NA
Example
SET PROFILE=AUTOPROV XEPORT FLOWCONTROL=off ADMINSTATE=up
257
SET SYSTEM
Syntax
SET SYSTEM [PROVMODE={MANUAL|AUTO}]
Description
Controls the system provisioning mode.
Mode
Manager
Options
Option
Description
Range
Default
Value
PROVMODE
The PROVMODE parameter specifies the system provisioning mode. The provisioning mode determines how
hardware devices are introduced to the system software.
NA
AUTO
- AUTO: In auto provisioning mode, removable hardware devices are automatically discovered and provisioned either upon insertion or upon system startup.
The provisioning is persisted in the CFC database until
manually destroyed using CLI commands (DESTROY
CARD for example). Auto provisioning is the default
mode for the system
- MANUAL: In manual provisioning mode, all provisioning is performed through the use of CLI commands
(CREATE CARD for example). Hardware devices are
not automatically provisioned upon card insertion or
upon system startup. The manually entered provisioning
data is persisted in the CFC database until manually
destroyed using CLI commands (DESTROY CARD for
example).
Some cards (active CFC and FC) are automatically provisioned even in manual mode, and cannot be destroyed
using CLI commands.
Release Note
NA
Example
SET SYSTEM PROVMODE=MANUAL
258
SHOW CARD
Syntax
SHOW CARD [ ={ slot-list | ACTCFC | INACTCFC | ALL } ] [ { INVENTORY | SOFTWARE | FULL } ]
Description
Displays various information about the provisioned card in the specified slot. Entering the command
with no optional parameters displays basic information about the card. Optional parameters are provided to display additional information.
Mode
User
Options
Option
Description
Range
Default
Value
CARD
NA
NA
ACTCFC
The active CFC
NA
NA
INACTCFC
For a dual configuration, the inactive CFC (although it is
still load-sharing if in service).
NA
NA
ALL
The SHOW CARD ALL command displays a summary
of cards present in the shelf. Entering SHOW CARD
ALL command without the optional INVENTORY
parameter displays the following information for each
slot in tabular format:
NA
NA
NA
NA
- slot number
- provisioned card type
- current state of the card, in the format of hyphen separated administrative state, operational state, and status
attribute (for example, UP-UP-ONLINE)
- current faults against the card
INVENTORY
Entering the SHOW CARD ALL command with the
optional INVENTORY parameter displays the following
information for each slot in tabular format:
- slot number
- provisioned card type
- model number (read from the IDPROM on the card)
- serial number (read from the IDPROM on the card
Release Note
SOFTWARE
Show the software loads of the cards
NA
NA
FULL
Show a full display without summaries
NA
NA
NA
Example
SHOW CARD ACTCFC
Type...............................
State..............................
5
CFC200
AutoProv
259
Hardware
Serial Number................... 51
CLEI Code....................... <none>
Software
Running Load....................
Preferred Load..................
Temporary Load..................
Alternate Load..................
cfc200_14.2.0.kmartin.20100401_KWM.tar
None
None
Software Build Information
Load File.......................
Build Name......................
Build Type......................
Revision........................
Built On........................
Built By........................
Environment.....................
Baseline........................
Boot ROM Build Name.............
Lab-Only Build
14.2.0.GAMMA.20100401
Fri 04/30/2010 at 03:20 PM
kmartin
kmartin_R14.2_Dev1
R14.2.0_2010_04_01_Nightly
ATI 200G Central Fabric Controller Boot
Loader
Boot ROM Version................ 14.1.g.01
Card Type Specific Information
Timing Reference................ N/A
SHOW CARD=5 // The same output as with SHOW CARD=ACTCFC
Type...............................
State..............................
5
CFC200
AutoProv
Hardware
Example
SHOW CARD (for the SBx3106)
Slot
----0
1
2
3
4
5
Prov
Card Type
--------GE24RJ
GE40CSFP
GE40RJ
XE6SFP
CFC200
CFC200
State
---------------------------------------UP-UP-Online
UP-UP-Online
UP-UP-Online
UP-UP-Online
UP-UP-Online (Inactive)
Faults
--------
SHOW CARD INVENTORY
260
Slot
----0
1
2
3
4
5
Prov
Type
-------GE24RJ
GE40CSFP
GE40RJ
XE6SFP
CFC200
CFC200
Physical
Type
--------GE24RJ
GE40CSFP
GE40RJ
XE6SFP
CFC200
CFC200
Model
-----------AT-SBx31GT24
AT-SBx31GC40
AT-SBx31GT40
AT-SBx31XS6
AT-SBx31CFC
AT-SBx31CFC
Serial Number
------------------A044024103200003
A31GC40H100000001
A31GT40H100000001
3020081840407063
A31CFCH100300022
A31CFCH100300022
CLEI Code
----------
HW
Rev
--A1
A1
A1
A1
FPGA
Rev
----
261
SHOW CARD MEMORY
Syntax
SHOW CARD [ ={ slot-list | ACTCFC | INACTCFC | ALL } ] MEMORY { HEAP | MESSAGEBUFFERS | QUICKHEAP }
Description
Displays information about card memory usage.
Mode
User
Options
Option
Description
Range
Default
Value
CARD
NA
ALL
ACTCFC
The active CFC
NA
NA
INACTCFC
For a dual configuration, the inactive CFC (although it is
still load-sharing if in service).
NA
NA
MEMORY
- HEAP - Displays memory heap usage statistics. This
parameter is only supported for the CFC card.
NA
NA
- MESSAGEBUFFERS - Displays memory message bufferstatistics. This parameter is only supported for the CFC
card.
- QUICKHEAP - Displays memory quick heap usage statistics. This parameter is only supported for the CFC
card.
Release Note
NA
Example
SHOW CARD=actcfc MEMORY HEAP
-- Heap Memory Usage --------------------------------------------------Current Time: 2010-11-05 11:27:47
Number of Free Bytes.........................................
Number of Free Blocks........................................
Maximum Free Block Size......................................
Number of Allocated Bytes....................................
Number of Allocated Blocks...................................
388410720
1478
387338984
84416288
56112
262
SHOW PROFILE
Syntax
SHOW PROFILE [ ={ name-list | NAMES | ALL } ] [ FULL ]
Description
Displays a summary of profiles including their card/interface types. If only a single profile is given or the
FULL option is supplied, the details of the profile are displayed.
Mode
User
Options
Option
Description
Range
Default
Value
PROFILE
The profiles for the components. In 16.0 these are:
NA
ALL
NA
NA
- CFC200 card
- GE24POE card
- GE24RJ card
- GE24SFP card
- GE40CSFP card
- XE4 card
- XE6SFP card
- GEPORT
- XEPORT
FULL
Release Note
Provides more detailed information
NA
Example
E135 - >SHOW PROFILE
--- Card Profiles --Name
-------------------------------AutoProv
AutoProv
AutoProv
AutoProv
Type
---------CFC200
GE24POE
GE24SFP
XE4
-------------------------------AutoProv
AutoProv
Type
---------GEPORT
XEPORT
263
Syntax
Description
Displays the current provisioning mode for the system.
Mode
User
Options
NA
Release Note
NA
Example
System is in AUTO provisioning mode
264
SWAP ACTIVITY
Syntax
SWAP ACTIVITY [FORCE]
Description
Switches activity between the 2 redundant CFCs. Both CFCs must be in the ONLINE status. Sanity
checking is performed automatically to ensure a non-service affecting switchover, unless the optional
FORCE option is used.
Mode
Manager
Options
Release Note
Option
Description
Range
Default
Value
FORCE
Bypasses sanity checking and requires no confirmation.
NA
NA
NA
Example
SWAP ACTIVITY
265
2. Interface Management
2.1 Introduction
This chapter describes the interfaces that the SBx3112 supports.
• Interface Types
• GE Interfaces
• XE Interfaces
2.2 Interface Types
2.2.1 Introduction
An interface is a capability associated with a physical port. The interface, therefore, provides a logical representation of one
or many physical ports. A specific instance of an interface has an identifier which can be used when configuring these capabilities.
The relationship between interfaces and physical ports can vary from one-to-one to many-to-many. This means that one port
can have more than one interface type and an interface type can use more than one port.
For the SBx3112, there are the following interface types:
• Ethernet - Each instance having a Type of ETH, an ID of the port number, and no name. The management interface has an
interface of ETH:0 and has a category of General.
• LAG - This occurs when a LAG is created, and has a Type of LAG, an ID of 0.0 (first), and associated ports that depend
on the ports that have been chosen to be part of the LAG group.
• VLAN - This supports the INBAND and ethernet module interfaces.
• GE - This is used when changing attributes for the interface and for profiles.
• XE - This is used when changing attributes for the interface and for profiles.
266
Interface Management
GE Interfaces
2.3 GE Interfaces
2.3.1 Overview
The cards that provide the GE Interfaces (such as the GE24POE and GE24SFP) have common attributes, as listed in the following table. Also, note the following for each card type.
2.3.1.1 GE24POE and GE24RJ Interfaces
• The 1000BASE-T standard does not support running at 1 Gbps without auto negotiation, (SPEED=1000 and
AUTO=OFF). The GE24POE allows this, but operation in this mode is not guaranteed.
• The copper interfaces on the GE24POE card support automatic MDIX crossover detection. This keeps the user from
having to use crossover cables for physical interface connections. Crossover detection works whether AUTO is ON or
OFF (does not depend on auto negotiation).
2.3.1.2 GE24RJ Interfaces
The only difference between the GE24RJ and GE24POE is that the GE24RJ does not support PoE. Otherwise, interface support is the same.
2.3.1.3 GE24SFP Interfaces
Three different Ethernet types are supported by the GE24SFP when the corresponding SFP module is inserted:
• 1000BASE-X
• 100BASE-FX
• 10/100/1000BASE-T (tri-speed copper).
Some provisioned parameters and SFP module combinations are incompatible, such as SPEED=10 or SPEED=1000 when a
100BASE-FX SFP is inserted, or SPEED=10 or SPEED=100 when a 1000BASE-X SFP is inserted. SPEED will only be used for
SFP modules recognized as models that support tri-speed operation with an internal PHY. The actual operating value will be
correctly displayed by SHOW INTERFACE which may result in a mismatch between provisioning and actual SPEED.
The combination of SPEED=1000 and AUTO=OFF will not be blocked when an SFP module that supports tri-speed operation is inserted. This is not technically a valid configuration per the 1000B-T standard and is different than the operation of
the GE24POE, but the combination is valid for 1000BASE-X SFP modules. This configuration cannot be blocked during provisioning because it is not known in advance which SFP module will be used. Instead, SPEED=1000 and AUTO=OFF is allowed,
and is applied to the interface.
AUTONEGOTIATE does not apply to 100BASE-FX, and it is ignored when a 100FX SFP module is detected. Port settings
provisioned as AUTO are set to defaults as shown in table below. The actual operating value is correctly displayed by SHOW
INTERFACE.
2.3.1.4 GE40CSFP Interfaces
The interfaces on the GE40CSFP card support up to 40 Compact SFP (CSFP) modules or up to 20 SFP modules.
Port numbering is as follows:
Each CSFP port has two ports numbered n and n+2. Even numbers are across the top of the card and odd numbered ports
are across the bottom of the card.
Refer to the following figure for how the ports are configured with SFPs. This is explained in detail after the figure.
267
GE Interfaces
SBx31GC40
2
1000 LINK
4
8
6
10
12
14
16
18
ACT
20
22
24
26
28
30
32
34
36
0
38
0
39
1
3
5
7
9
11
13
15
17
19
21
23
25
27
29
31
33
35
37
If Compact SFP is used (one for each port), both ports are 1G Bi-Directional
If SFP is used, one port of two is 1G Bi-Directional, for top row left port is active ,
for bottom row right port is active.
FIGURE 2-1
Port Layout and SFP Configuration for GE40CSFP
The GE40CSFP only supports 1000Mbps. The standard 10/100/1000B-T SFP module AT-SPTX is only supported at
1000Mbps. Standard 100BASE-FX SFP modules are not supported.
When a standard SFP module is used in place of a CSFP module, only one of the two ports can used. The secondary interface
is masked, or eclipsed, and it will have a state of UP-DN-Failed. A corresponding alarm is raised against this interface. For
even numbered ports, 0, 2, 4, 6 …, the secondary interface port is the higher numbered (on the right) interface: 2, 6, etc. For
odd numbered ports, 1, 3, 5, 7, the secondary interface is the lower numbered (on the left) interface: 1, 5, etc.
Note:
Refer to the SwitchBlade x3112 Installation Guide for information on SFP models.
There are two alarms for the GE40CSFP:
• "Pluggable Module Not Supported" - This alarm is raised when an unsupported C/SFP module is inserted. Modules are
considered unsupported based if the bit rate is not 1000M. For example, this alarm is raised on the GE40CSFP when a
100BASE-FX SFP module or a 10G SFP+ module is inserted. The alarm is cleared when the module is removed.
• "Eclipsed" - alarm is raised when a standard SFP is inserted into a GE40CSFP interface. The secondary port is then
masked, or eclipsed, and the interface state is UP-DN-Failed. The alarm is cleared when the module is removed or the
port is disabled.
Only the flow control port setting is auto-negotiated on the GE40CSFP. The actual operating value is displayed by SHOW
INTERFACE
2.3.1.5 GE Interface Attributes
The following table lists the common attributes for the GE interfaces.
TABLE 2-1
Interface Attributes for the GE Cards
Attribute
Values/Range
Description
Interface
Number of the interface
The identifying number of the interface.
Type
Interface Type
The type of interface, in this case GE
268
GE Interfaces
TABLE 2-1
Attribute
Values/Range
Description
State
Three attributes:
- Admin State
These three attributes determine the state of the card; whether it is
capable of carrying traffic and the status (Implied Operational Status)
- Operational State
ONLINE - Port is configured and can provide service. (UP)
- Status
DEGRADED - There is a fault but the port can still provide service
(UP)
OFFLINE - The normal status when a port is in a DOWN state. The
card requires a routine operation to place it ONLINE and available for
service. (DOWN)
FAILED - The port has detected a hardware or software fault that
makes it unable to provide service. (DOWN)
DEPENDENCY - The port cannot provide service because the card on
which it depends is unavailable. (DOWN)
CONFIGURING - Provisioning data for the port is being copied from
the CFC to the RAM memory on the card. (DOWN)
TERMINATING - The port is performing an operation in preparing to
go out of service. (UP or DOWN)
Description
Text
This is an attribute that should help in administration of the system. In
most cases, the user should create names that are alpha-numeric and
avoid using special characters such as ‘-’, ‘:’, or ‘.’ , since these may be
rejected by the CLI if they could represent a type or interface set.
Remote ID
1 to 31 ASCII characters
Used by DHCP Servers to identify the Relay Agent.
External Profile
Profile Name provided by the NMS.
Card Type
In this case, GE24POE, GE24RJ, GE24SFP, or GE40CSFP
Interface Faults
Any faults on the interface and the level of alarm. (This only appears if
there is a fault.)
Provisioning
Provisioning Profile Profile that has been
applied to the card and if
there is a Profile mismatch.
If there is a status mismatch, a (*) appears next to the Profile Name.
Direction
Customer or Network. (Default is Customer.)
Auto Negotiation
Specifies whether automatic negotiation of transmission parameters
for the ports is allowed.
If ON, the port has increased flexibility to communicate with the
remote peer. The port has the ability to advertise flow control and to
provide single direction fault coverage. The port will drive the link state
up and down based on the ability to communicate with the remote
peer, triggering on both transmit and receive failures Loss of Signal
(LOS).
If OFF, the port state is driven by receive failure (LOS). Flow control is
still provided as long as the FLOWCONTROL parameter is ON.
The default value is ON.
Speed
10, 100, 1000, AUTO (Default is AUTO.)
Duplex
HALF, FULL, AUTO (Default is AUTO.)
269
GE Interfaces
TABLE 2-1
Attribute
Values/Range
Description
Provisioning
Flow Control
Specifies whether flow control is enabled. Note that flow control
works between the card and the external interface only; it does not
work across the backplane from card to card
If ON, the port behavior is the same as AUTO.
If OFF, pause is ignored and not generated, and potential for packet loss
is increased.
FLOWCONTROL is independent of AUTONEGOTIATION, but the
combination of the settings determines the port’s behavior. Following
is the result of Flow Control / Auto states - behavior:
AUTO or ON / ON - Advertise Symmetric pause (send and receive
pause frames). Flow control setting is the result of negotiation. Note
that when Auto=ON, FLOWCONTROL cannot be set to ON.
ON / OFF - Flow control is ON, and pause frames are sent and
received.
OFF / ON or OFF - Flow control is OFF (regardless of link partner).
The default value is OFF.
Remote monitoring
On of Off
Actual
Attributes measured
when the interface is
operationally UP.
Other attributes are determined by the Interface.
VLAN Information
VLAN attributes
The attributes for the VLAN over the interface.
2.3.2 Example GE Interface (GE24POE)
show interface eth:10.0
Type...............................
State..............................
Description........................
Remote ID..........................
Card Type..........................
10.0
GE
UP-UP-Online
<none>
<none>
<none>
GE24POE
Provisioning
Provisioning Profile............
Direction.......................
Auto Negotiation................
Speed...........................
Duplex..........................
Flow Control....................
Remote Monitoring...............
AutoProv (*)
Customer
On
10 Mbps
Auto
Auto
Off
Actual
270
Direction.......................
Physical Address................
Speed...........................
Duplex..........................
Flow Control....................
logo
VLAN Information
Acceptable Frame Types..........
Ingress Filtering...............
TPID............................
TAGALL..........................
Dynamic MAC Learning Limit......
Untagged VLAN...................
GE Interfaces
Customer
00:0C:25:04:00:80
10 Mbps
Full
Off
All
On
0x8100
Off
0
1
manager SEC>> show interface 11.0
Type...............................
State..............................
Description........................
Remote ID..........................
Card Type..........................
11.0
GE
UP-DN-Failed
<none>
<none>
<none>
GE24SFP
Interface Faults
Loss of Link.................... Major
Provisioning
Provisioning Profile............
Direction.......................
Auto Negotiation................
Speed...........................
Duplex..........................
Flow Control....................
Remote Monitoring...............
AutoProv
Customer
On
Auto
Auto
Auto
Off
Actual
Physical Address................ EC:CD:6D:03:6E:B7
VLAN Information
Acceptable Frame Types.......... All
Ingress Filtering............... On
TPID............................ 0x8100
271
GE Interfaces
TAGALL.......................... Off
Dynamic MAC Learning Limit...... 0
Untagged VLAN................... 1
272
GE Interfaces
2.4 XE Interfaces
2.4.1 Overview
Interface management includes state management, configuration, alarms, audits and optics query.
The only provisionable attribute for an XE interface is FLOW, which can be either ON or OFF, and defaults to OFF.
The XE interfaces can also be configured for either CUSTOMER or NETWORK direction.
There are two attributes that can be set:
• FLOW - (ON, OFF)
• DIRECTION - (CUSTOMER, NETWORK)
Note:
Refer to the SwitchBlade x3112 Installation Guide for information on XFP and SFP+ models.
The XE6SFP only supports 10G SFP+ modules. Standard 1G SFP modules can be inserted and queried using the SHOW
INTERFACE OPTICS command, but they will not link up. A "Pluggable Module Not Supported" alarm will be raised when an
unsupported module is inserted.
2.4.2 Example Output
Following is an example output.
show interface eth:0.0
--- XE Interfaces --Interface..........................
Type...............................
State..............................
Description........................
Remote ID..........................
Card Type..........................
0.0
XE
UP-UP-Online
voip2 ring primary Uplink
<none>
<none>
XE4
Provisioning
Provisioning Profile............ AutoProv
Flow Control.................... Off
Remote Monitoring............... On
Actual
Direction....................... Network
Port Speed...................... 10 Gbps
Physical Address................ EC:CD:6D:03:26:55
VLAN Information
TPID............................
TAGALL..........................
VLAN-tagged only
On
0x8100
Off
273
GE Interfaces
Dynamic MAC Learning Limit...... 0
Tagged VLAN(s).................. 100,102,200,300,400,402,500-501,600,10011003
Packet Statistics
Octets..........................
Unicast Packets.................
Discarded Packets...............
Errored Packets.................
Input
Output
------------- ------------1389760201948 1470700206344
2
4
1042177
11700122
0
0
0
0
274
GE Interfaces
2.4.3 Interface (Common) Commands
The following tables list the commands available to configure and manage interfaces on the SBx3112 switch.
TABLE 2-2
Interface Commands
Commands
CREATE PROFILE GEPORT
CREATE PROFILE XEPORT
DESTROY PROFILE PORT_TYPE
DISABLE INTERFACE
ENABLE INTERFACE
SET INTERFACE
SET INTERFACE DESCRIPTION
SET INTERFACE GE
SET INTERFACE XE
SET INTERFACE PROFILE
SET INTERFACE REMOTEID
SET PROFILE GEPORT
SHOW INTERFACE
SHOW INTERFACE OPTICS
275
GE Interfaces
CREATE PROFILE GEPORT
Syntax
CREATE PROFILE=name GEPORT
[ AUTONEGOTIATION={ ON | OFF } ]
[ SPEED={ AUTONEGOTIATE | 10 | 100 | 1000 } ]
[ DUPLEX={ AUTONEGOTIATE | FULL | HALF } ]
[ FLOWCONTROL={ AUTONEGOTIATE | ON | OFF } ]
Description
The GEPORT parameter identifies the profile as a Gigabit Ethernet (GE) interface profile. As a GE
interface profile, only GE interface options are available to the user.
Mode
Manager
Options
Refer to SET INTERFACE GE.
Release Note
NA
Example
CREATE PROFILE=ge_example SPEED=1000 DUPLEX=FULL
276
GE Interfaces
CREATE PROFILE XEPORT
Syntax
CREATE PROFILE=name XEPORT [ FLOWCONTROL={ ON | OFF } ] [ ADMINSTATE={ UP |
DOWN } ]
Description
The GEPORT parameter identifies the profile as a Gigabit Ethernet (GE) interface profile. As an GE
Mode
Manager
Options
Refer to SET INTERFACE XE.
Release Note
NA
Example
CREATE PROFILE=xe_example ADMINSTATE=DOWN
277
GE Interfaces
DESTROY PROFILE PORT_TYPE
Syntax
DESTROY PROFILE=name port_type
Description
Destroys a profile for the specified port type (GEPORT or XEPORT). No other attributes are
required. Any managed entity that had a Profile applied is set to None (no profile association).
Mode
Manager
Options
NA
Release Note
NA
Example
create profile=fred XEPORT adminstate=down Info
(033561): Successfully created profile(s) fred officer
destroy profile=fred XEPORT
Info (033571): Successfully destroyed profile(s) fred
278
GE Interfaces
DISABLE INTERFACE
Syntax
DISABLE INTERFACE={ type:id-range | id-range | ifname-list } [ FORCE ]
Description
This command should be used with caution. Places the interface(s) in the DOWN administrative state.
FORCE will do this even is the interface is operationally UP.
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
The INTERFACE parameter allows the filtering of interfaces. Interfaces to be displayed may be selected by type
or a type:id/name list (e.g., ETH:4.4-4.8/name1,name2)
NA
ALL
FORCE
Will disable the interface even if it is operationally UP.
NA
NA
Release Note
NA
Note
Disabling the GE24POE interface has no effect on the port’s ability to provide power.
Example
DISABLE INTERFACE=1.2 FORCE
Info (039512): Operation Successful (XE4 Slot 1 Port 2)
279
GE Interfaces
ENABLE INTERFACE
Syntax
ENABLE INTERFACE={ type:id-range | id-range | ifname-list }
Description
Places the interface in the UP administrative state and attempts to make the port in-service.
Mode
Manager
Options
Release Note
Option
Description
Range
Default
Value
INTERFACE
The INTERFACE parameter allows the filtering of interfaces. Interfaces to be displayed may be selected by type
or a type:id/name list (e.g., ETH:4.4-4.8/name1,name2)
NA
NA
NA
Example
enable interface 0.23
Info (039512): Operation Successful (GE24POE Slot 0 Port 23)
280
GE Interfaces
SET INTERFACE
Syntax
SET INTERFACE={ type:id-range | id-range | ifname-list | ALL } [ ACCEPTABLE={
ALL | VLAN | HVLAN } ]
[ INFILTERING={ OFF | ON } ]
[ TAGALL={ ON | OFF } ]
[ TPID=tpidvalue ]
[ LEARNLIMIT={ 1..64 | OFF } ]
Description
Modifies the value of parameters for system interfaces.
Mode
Manager
Options
Option
Description
Range
Default
Value
ACCEPTABLE
Sets the acceptable frame types
NA
NA
NA
ON
all - tagged and untagged)
VLAN-VLAN tagged only
HVLAN-HVLAN - tagged only.
INFILTERING
Sets the ingress filtering settings ON or OFF. Infiltering
is the validation of VLANs on an interface.
ON - if a received frame’s VLAN does not match the
interface’s VLAN membership, it is dropped.
TAGALL
Controls whether all the frames are to be tagged or not
NA
OFF
TPID
Used to identify the frame as a tagged frame.The value
of the TPID for an 802.1q ethernet tagged frame is
0x8100
NA
NA
NA
TBS
Note:
LEARNLIMIT
There is a limited number of TPIDs for a
given card that can be applied to all of the
ports on the card. For the XE4 the limit
is 2, and for the GE24 cards the limit is 8.
Specifies the maximum number of MAC addresses that
can be learned for an interface. A MAC address/VID pair
counts as one, so for example one MAC associated with
three VIDs would count as three against the LEARNLIMIT.
Release Note
NA
Example
SET INTERFACE 0.22INFILTERING ON TAGALL OFF LEARNLIMIT 32
281
GE Interfaces
SET INTERFACE DESCRIPTION
Syntax
DESCRIPTION={ description | NONE }
Description
Used to modify attributes common to all interfaces.
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
The interface(s) that will have their description(s) set.
NA
NA
DESCRIPTION
Provides a label that is used to identify the purpose or
function of an interface.
NA
NA
NONE - sets the Description back to none if it previously had a name.
Release Note
NA
Example
SET INTERFACE 0.23 DESCRIPTION Customer_POE
282
GE Interfaces
SET INTERFACE GE
Syntax
GE
[ DIRECTION={ NETWORK | CUSTOMER } ]
[ FORCE ]
Description
Modifies the provisioning attributes for the specified interface or list of interfaces. One or more individual attributes or a profile name are specified. Some individual attributes can be modified while the
interface is in-service. These in-service modified attributes are downloaded to the hardware dynamically. For other attributes, the interface must be disabled (See DISABLE INTERFACE) If a profile is used
to modify all attributes, the interface must be disabled first, and all attributes are downloaded again
when the interface is enabled.
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
The GE interfaces that are being modified.
NA
NA
AUTONEGOTIATION
Specifies whether automatic negotiation of transmission
parameters for GE ports is allowed. The user may set
this parameter only when the interface is disabled.
NA
ON
If ON, the port has increased flexibility to communicate
with the remote peer. The port has the ability to advertise flow control and to provide single direction fault
coverage. The port will drive the link state up and down
based on the ability to communicate with the remote
peer, triggering on both transmit and receive failures
(LOS).
If OFF, the port state is driven by receive failure (LOS).
Flow control is still provided as long as the FLOWCONTROL parameter is ON.
SPEED
The speed of the interface (10, 100, 1000, AUTO). Note
that some combinations are with other parameters are
incompatible. (Refer to Section 2.3.)
NA
AUTO
DUPLEX
The duplex mode to be used (AUTONEGOTIATE|FULL|HALF).
NA
AUTONEGOTIATE
283
GE Interfaces
Option
Description
Range
Default
Value
FLOWCONTROL
Specifies whether flow control is enabled for GE ports.
For GE ports, the parameter can either be ON or OFF.
NA
OFF
NA
CUSTOMER
NA
NA
If ON, the port can generate and respond to pause signals with the remote peer.
If OFF, pause is ignored and not generated, and potential
for packet loss is increased.
FLOWCONTROL is independent of AUTONEGOTIATION.
The user can set this parameter only when the interface
is disabled.
DIRECTION
NETWORK - The interface is toward another system,
and so data packets from multiple customers are carried
over the link.
CUSTOMER - The interface is toward a customer site
and all data streams are associated with the customer.
FORCE
Release Note
Suppress any confirmation message.
NA
Example
SET INTERFACE 0.23 GE DIRECTION=NETWORK
Info (020186): Successfully modified interface(s) 0.23
284
GE Interfaces
SET INTERFACE XE
Syntax
XE
[ FLOWCONTROL={ ON | OFF } ]
[ DIRECTION={ NETWORK | CUSTOMER } ]
[ FORCE ]
Description
Changes attributes for the specified XE interface.
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
The XE interfaces that are being modified.
NA
NA
FLOWCONTROL
Specifies whether flow control is enabled for GE ports.
For XE4 ports, the parameter can either be ON or OFF.
NA
OFF
NA
NETWORK
NA
NA
If ON, the port can generate and respond to pause signals with the remote peer.
If OFF, pause is ignored and not generated, and potential
for packet loss is increased.
The user can set this parameter only when the interface
is disabled.
DIRECTION
over the link.
FORCE
Suppress any confirmation message.
Release Note
NA
Example
SET INTERFACE ALL FLOWCONTROL ON DIRECTION NETWORK
285
GE Interfaces
SET INTERFACE PROFILE
Syntax
PROFILE=name
Description
Applies the Profile to the interface. If double quotes are used after PROFILE, the interface has no Profile.
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
The interfaces that are having their profile set.
NA
NA
PROFILE
The name of the profile being applied.
NA
NA
Release Note
NA
Example
SET INTERFACE 1.23 PROFILE=poe_on
286
GE Interfaces
SET INTERFACE REMOTEID
Syntax
REMOTEID={ remote-id | NONE }
Description
Sets the remote id for the interface.
Mode
Manager
Options
Option
Description
Range
Default
Value
REMOTEID
Used by DHCP servers to identify a RELAY AGENT.
Setting this parameter is optional. The default is the
MAC address of the switch the RELAY AGENT is running on. The user can specify the REMOTEID by entering a string of 1 to 31 ASCII characters.
NA
NONE
Release Note
NA
Example
SET INTERFACE=ETH:0.23 REMOTEID=DVLK-x3112-A01
287
GE Interfaces
SET PROFILE GEPORT
Syntax
SET PROFILE=name GEPORT
Description
The GEPORT parameter identifies the profile as a Gigabit Ethernet (GE) interface profile. As an GE
Mode
Manager
Options
Refer to SET INTERFACE GE.
Release Note
NA
Example
SET PROFILE=ge_example SPEED=100 DUPLEX=FULL
288
GE Interfaces
SHOW INTERFACE
Syntax
SHOW INTERFACE [ ={ type: | type:id-range | id-range | ifname-list | ALL } ]
[ CARD=slot-list ] [ STATE={ UP | DOWN | ALL } ]
[ DIRECTION={ NETWORK | CUSTOMER | INTERNAL } ]
[ DESCRIPTION ] [ FULL ]
Description
Displays information about interfaces in the system. Information provided includes interface type,
interface ID, interface name, physical ports associated with the interface, interface direction, interface
mode (UP or DOWN) and the last change time (based on the system uptime).
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
The interfaces that will have information displayed.
NA
ALL
CARD
The slot number for the card interfaces to display.
NA
NA
STATE
The state of the interfaces:
NA
ALL
NA
ALL
- UP - Operationally UP
- DOWN- Operationally DOWN (The Admin state can
be UP or DOWN).
- ALL - Both UP and DOWN
DIRECTION
over the link.
Release Note
DESCRIPTION
Includes the DESCRIPTION value for the displayed
interfaces.
NA
NA
FULL
Gives complete information for each interface type
NA
NA
NA
Example
E135 - manager SEC>> SHOW INTERFACE CARD=1
--- GE Interfaces --Interface
----------1.0
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
State
----UP-DN
UP-DN
UP-DN
UP-DN
UP-DN
UP-DN
UP-DN
UP-DN
UP-DN
UP-DN
UP-UP
Autonegotiate Flow Control Duplex Speed
Direction
------------- ------------ ------ -------- --------On
Customer
On
Customer
On
Customer
On
Customer
On
Customer
On
Customer
On
Customer
On
Customer
On
Customer
On
Customer
On
Off
Full
1 Gbps
Customer
289
1.11
1.12
1.13
1.14
1.15
1.16
1.17
1.18
1.19
1.20
1.21
1.22
1.23
UP-DN
UP-DN
UP-DN
UP-DN
UP-DN
UP-DN
UP-DN
UP-DN
UP-DN
UP-DN
UP-DN
UP-DN
UP-DN
GE Interfaces
On
On
On
On
On
On
On
On
On
On
On
On
On
-
-
-
Customer
Customer
Customer
Customer
Customer
Customer
Customer
Customer
Customer
Customer
Customer
Customer
Customer
--- General Interfaces --Interface
State Name
--------------- ----- ---------LAG:1
UP-UP mylag2
290
GE Interfaces
SHOW INTERFACE OPTICS
Syntax
SHOW INTERFACE [ ={ type: | type:id-range | id-range | ifname-list | ALL } ]
[ OPTICS ] [ FULL ]
Description
Shows the optics data, as a subset of the data contained the SFP/XFP memory. For the user to query
the optics on an interface, the card must be operationally UP but the state of the interface does not
matter, as long as the SFP/XFP module is physically present.
Mode
User
Options
Release Note
Option
Description
Range
Default
Value
INTERFACE
The interfaces that will have information displayed.
NA
ALL
OPTICS
Shows the optics specifications
NA
NA
FULL
Gives complete information for the interfaces specified.
NA
NA
NA
Example
E135 - manager SEC>> SHOW INTERFACE OPTICS
--- Interface Optics ---
Interface
----------10.0
10.1
10.2
10.3
Port
Type
----XE
XE
XE
Transceiver
Type
-----------XFP
XFP
XFP
Nominal
Bit Rate
Tx/Rx Power
Temperature
---------- ---------------- -----------/10000
0.5739/0.6255
30.9 C
10000
0.5698/0.5744
32.1 C
10000
0.5627/0.5619
33.2 C
19:19:23 manager SEC>> show interface 1.0 optics
--- Interface Optics --Interface..........................
Type...............................
State..............................
Port Uptime........................
Description........................
Optics Specification
Transceiver Type................
Nominal Bit Rate................
Vendor Name.....................
Vendor Part Number..............
Vendor Revision.................
Vendor Serial Number............
Date Code.......................
Wavelength......................
Internal Temperature............
Transmit Power..................
Receive Power...................
1.0
GE
UP-DN
000:00:00:00
<none>
SFP
1300 Mbits/sec
AGILENT
QBCU-5730R
AK0549GHFA
051211
Not Available
Not Available
Not Available
Not Available
291
3. Power over Ethernet (PoE)
3.1 Introduction
The SBx3112 switch provides Power over Ethernet (PoE) capability with the GE24POE card. The GE24POE card allows up
to 24 devices (one per port) to receive power from the Ethernet faceplate connection. With PoE technology, a supported
Ethernet-based terminal (known as a Powered Device or PD) can receive up to 30 watts of power over the same Ethernet
cable as data. Examples of PDs include IP phones, wireless access points, and IP cameras.
Power can be carried over Ethernet cables in one of two ways:
• Mode A uses the data pairs 1-2 and 3-6.
• Mode B uses the spare pairs 4-5 and 7-8, which are unused in 10/100BASE-T. The power applied allows data flow to be
maintained regardless of power status.
Note:
The IEEE PoE Power Standard 802.3af only allows one set of wires to be used per device. Mode B is not supported
on the GE24POE card.
The IEEE 802.3af standard defines support for devices up to 15.4 watts. (A newer standard IEEE 802.3at extends the power
range to 25.5 watts.)
3.1.1 Definitions
The following terms are used throughout this chapter:
• PoE (Power over Ethernet) - the 802.3af PoE feature that allows power to be carried over the same Ethernet infrastructure as data
• PSE (Power Sourcing Equipment) - the source, such as an Ethernet switch, that is responsible for supplying power to one
or more devices by Ethernet cable
• PD (Powered Device) - the device receiving power by Ethernet cable from a PSE
• PoE PSU (Power Supply Unit) - one of the devices providing power to the shelf for use in powering PDs
• Allocated power - the amount of power the PoE manager on the Central Fabric Control (CFC) card has given to a PoE
line card to use; it may be greater or less than the amount of power the card has requested.
• Requested power - the amount of power a port has requested for PoE. It is equal to the port's user power limit (if set)
or based on the determined classification of the discovered PD. Ports with no discovered PD are not requesting power.
The card's requested power is the sum of all ports.
• Actual power - the actual, instantaneous, power draw of a port or card as measured by the PSE.
292
Power over Ethernet (PoE)
Introduction
3.2 GE24POE Card Operation
3.2.1 Performance and Capacity
The maximum number of supported devices is determined by the number of installed PoE power supplies as well as the class
of PD installed at each PoE port. Refer to the following table.
TABLE 3-1
Performance and Capacity for the PSUs (for PoE)
Configuration
Class 2 PDs (7W)
Class 3 PDs (15.4W)
Class 4 PDs (30W)
2 PoE PSUs (2400W)
240/240 ports (100%)
155/240 ports (64.6%)
80/240 (33.3%)
1 PoE PSU (1200W)
171/240 ports (71.3%)
77/240 ports (32.1%)
40/240 ports (16.7%)
For example, with a single PSU supplying 1200 watts and Class 2 PDs drawing 7 watts each over 171 ports, 71% of the total
available ports can use power.
3.2.2 Hardware Limitations
Of the two solutions for providing power over Ethernet cable, only Mode A (using data pairs 1-2 and 3-6) is supported on
the GE24POE.
Only two ports per card at a time are able to detect PDs. The maximum detection period for a PD is 500ms. This is followed
by a 75ms classification period. Given 24 ports per card, this leads to an estimated recovery time (for PoE) of 6.9 seconds,
which is illustrated in the following calculation:
[24 (total ports) / 2 (ports at a time)] * [500ms (detection period) + 75ms (classification period)] = 6.9 seconds
Each GE24POE card has a minimum power allocation of 37W that it can draw from the shared pool. (By disabling all POE
ports on the card, you can reduce the allocation to 0W.)
3.2.3 Hardware Detection
Whenever any device is plugged into a port supporting PoE, the system must determine if it is a powered device and, if so,
how much power it needs. The PSE is responsible for managing this process.
The first step is to detect the presence of a PD on the port. When any device is attached to the port (whether or not it supports PoE) the PSE applies a small amount of voltage to the line. It then looks for a 25 K-Ohm “signature” resistor on the
device. This resistor is located on the front-end of the PD and is isolated from the rest of the circuitry until detection is complete. If this resistor is detected, the device is accepted as a valid PD.
The next step is for the PSE to attempt to classify the device. To do this it applies a voltage of between 15.5 and 20.5 Vdc to
the line for a short period of time (10-75 ms). The amount of current it draws indicates the power class of the device. If the
PD does not support classification, it is assigned the default class of 0 and a maximum unclassified power consumption of
15.4W is assumed (Classes using greater than 15.4W MUST support classification). Otherwise the device is assigned a class
indicating the maximum amount of power it will draw.
When detection and classification are complete, the full voltage is applied gradually (to minimize noise on the line). This voltage is maintained until the PD is disconnected or an error condition is detected.
3.2.4 Power Allocation
In Release 14.2 the SBx3112 will support two 1200W PoE PSUs for a total of 2400W of available PoE power. This is enough
to power a subset of the ports in some cases, but not all. When there is no longer sufficient PoE power remaining to service
new PDs, then the shelf is at capacity and some ports will not receive power. The power allocation system is responsible for
determining which ports will receive power.
293
Introduction
Not all PDs draw the same amount of power. The amount of power that is actually needed determines the device's class.
There are currently 4 supported classes: Class 1 (4W), Class 2 (7W), Class 3 (15.4W), and Class 4 (30W). The number of
supported devices per shelf depends on the classes of the devices in use.
The user also has the additional ability to set a power limit for a port manually. If the device tries to draw more power than
the user limit, the port will be shut down (just as if it had exceeded the port's classified power limit). The port power limit, if
set, is used in the power allocation algorithm instead of the PD class detected. For instance, if the power limit is less than the
PD class limit, then the power delta is still available for use by other ports.
In addition to the shelf power limit (determined by the installed PoE PSUs) each card has an additional limit of 720W. The
total amount of power consumed by the ports on a card cannot exceed this amount even if the shelf has power available.
It is sometimes important to ensure that selected ports always receive power even when the system is at capacity. To support this, each port is given a priority level: critical, high, or low (with low as the default). Critical priority ports are serviced
first, then high and low (if enough power is available).
To ensure deterministic behavior, the slot and port number of each interface is also taken into account when determining
power allocation. Within each level, priority will be given to the lower number slots (and then lower number ports). For
example, if ports 1.1, 2.1, and 1.3 were all low priority and higher priority ports needed power, then 2.1 would be disabled
first followed by 1.3 then 1.1. This is mainly for deterministic behavior and should not be relied upon by the customer as a
means of controlling which ports receive power.
In order to ensure that power distribution is handled correctly and to prevent ports from bouncing as devices come up, only
two PDs per card will be allowed to come up at a time.
If a PD is removed from a port (or the PoE feature on that port is disabled) when the system is at capacity, then the next
highest priority port that is not already getting power will now receive power.
If a PD is connected to a port when the system is at capacity and the new port is a higher priority than other ports already
getting power, then the lowest priority port(s) will lose power and the newly connected port will receive power.
The determination of whether or not a port is capable of being powered is determined entirely by the PoE state and the
presence on the port of a supported PD. The port's administrative state, as well as the state of the PD’s Ethernet, has no
effect. Provided that the connection to the PD is maintained, a port that is providing power will continue to even if the port
is administratively disabled or if the PD disables its Ethernet. This allows the port or the device to disable traffic without shutting down power.
3.2.5 CFC Power Management
The CFC is responsible for setting the maximum power allowed by each PoE card.
It does this by going through the ports on each slot (starting with the ports on slot 0) and summing the requested usage for
all enabled ports that have detected a PD. The requested usage for a port is the user defined power limit (if set) or the class's
power limit (if user power limit is not set). The first pass allocates power for critical priority ports, followed by high priority
ports, and then low priority ports (if any power remains). Any power left over after this allocation is divided evenly amongst
the slots (so that they can more quickly respond to detected PDs before the CFC has time to respond). The CFC’s power
allocation algorithm is performed each time a PD is detected or removed (or a port is enabled/disabled).
Each card also has a minimum power limit of 37W. The CFC ensures that any card with enabled PoE ports must get at least
37W regardless of requested power. If all ports have PoE disabled, then the card will not be allocated power.
The CFC will alarm the card or the system if the requested power need was not able to be met. At this point there may or
may not be alarms on the interfaces (the actual power draw may not have exceeded the allocation), but the user is warned
that there is not enough allocated power to meet the requested need.
The CFC also calculates the power allocation for the cases where any currently installed PoE PSU is removed and sends
down those card power limits as well so that the GE24POE card can quickly reallocate power in the case of PSU removal.
294
Configuring the GE24POE Card
3.2.6 Card Power Management
The GE24POE card is responsible for limiting each port to its port power limit (which is the class limit if no user limit is set)
as well as taking the total card power (determined by the CFC) and allocating it to each of the ports based on priority. The
difference here is that (due to hardware limitations) instead of comparing the sum of each port's class power to the card
limit, it uses instead the actual current power usage of the ports. The impact of this is that some ports may be receiving
power when the CFC’s algorithm would have assumed they would not be. These ports would be the first to lose power if
higher priority ports on the card began to need more power.
3.2.7 LEDs
The faceplate for the GE24POE card has two light-emitting diodes (LEDs) per port. The top left LED indicates traffic status
while the top right LED is reserved for PoE status. The following table shows the meanings for this LED.
Note:
Disabling PoE on all ports on a card will turn off the LED, even if there is a card fault that would result on all ports
being solid amber.
TABLE 3-2
GE24PoE LEDs and Meanings
LED
Meaning
Off
PoE disabled or no PD detected
Solid Green
PD detected/providing power
Flashing Green
Unused
Solid Amber
PD fault or PSE failed
Flashing Amber
PD insufficient power
3.3 Configuring the GE24POE Card
The default PoE state for each port is ENABLED.
3.3.2.1 Restrictions and Limitations
• Only data pairs 1-2 and 3-6 can supply power on the GE24POE.
• The total amount of power consumed by the ports on a card cannot exceed 720W even if the shelf has power available.
• Only two ports per card at a time are able to detect PDs. The maximum detection period for a PD is 500ms.
3.3.2.2 Feature Interactions
This section describes the interactions between provisioning PoE and other features on the SBx3112.
• System recovery
The configuration settings identified in this document are persisted in the iMAP database. During system recovery, these settings are applied to the associated port/interface like any other configuration setting.
• Redundant operation
295
The configuration settings identified by this document are mirrored between the CFCs in a duplex configuration. Switchovers
(both controlled and uncontrolled) will have no impact on any ports providing power to a PD.
• System upgrades
The configuration settings identified in this document are expected to survive over upgrades from one release to the next.
• Logging
The PoE system will generate management (MGMT) logs whenever the operational state of the port changes. This includes
the discovery or removal of a PD as well as disabling power to a port due to PoE power capacity issues. Refer to the Allied
Telesis Log Manual.
A typical PoE configuration procedure involves the following steps:
•
•
•
•
Display the ports on the PoE card to check their status
Set the priorities for power allocation on the ports to prevent outages on critical devices.
Set the power limit for the ports if CLASS is not used.
Set the threshold for monitoring power usage (optional).
For example, if five cards are provisioned in the switch, there will be 120 ports available. If 50 Class 2 devices, 10 Class 3
devices, and 30 Class 4 devices are connected, they would require 1400 watts of power, while the shelf only supplies 1200W.
This configuration requires that some ports will be dropped to maintain critical power support for Class 4 devices.
Ports provisioned on PoE cards by class type:
• Class 4 - provisioned on 0.0-0.14, 1.0-1.14 (30 devices, 900 watts)
• Class 2 - 0.5, 1.5, 2.0-2.23, 3.0-3.23 (50 devices, 350 watts)
• Class 3 - 0.6-0.10, 6.0-6.4 (10 devices, 154 watts)
Levels of priority set on the PDs:
• All 30 Class 4 devices as Critical priority.
• Of the 50 Class 2 devices, 12 are set to High priority, 38 are Low priority
• Class 3 - All 10 are set to Low priority (5 are on slot 0 and 5 are on slot 6).
The following procedure shows the commands used to configure the GE24POE card on the SBx3112 switch.
TABLE 3-3
Step
Configuration procedure for PoE
Command
Description
Show the current status of the ports on the card(s).
1
SHOW POE INTERFACE=ALL
Displays the ports on the interface. All ports are
enabled by default.
Set the priorities on the ports with Class 4 devices.
2
SET POE INTERFACE=0.0-0.14, 1.0-1.14
PRIORITY=CRITICAL
Changes the priority of the ports from LOW to
CRITICAL for ports on slot 0 and slot 1.
Set the power limit on the Class 4 devices in slot 1.
3
SET POE INTERFACE=1.0-1.14 POWERLIMIT=2200MW
Modifies the power limit on ports 1.0-1.14 to a
maximum of 22W.
Set the PoE threshold for the shelf.
296
TABLE 3-3
Configuration procedure for PoE
Step
Command
Description
4
SET POE THRESHOLD=80
Monitors the power usage on the shelf by sending
an alarm when the threshold is exceeded.
Show the current status of the ports on the selected interface.
5
SHOW POE INTERFACE=0.*, 1.*
Displays the current configuration of the ports.
297
3.3.3 PoE Commands
The following tables list the commands available to configure and manage the PoE feature on the SBx3112 switch.
TABLE 3-4
PoE Commands
Commands
DISABLE POE INTERFACE
ENABLE POE INTERFACE
RESET POE COUNTER INTERFACE
SET POE INTERFACE
SET POE THRESHOLD
SHOW POE COUNTER INTERFACE
SHOW POE INTERFACE
SHOW POE
298
DISABLE POE INTERFACE
Syntax
DISABLE POE INTERFACE={ type:id-range | id-range | ifname-list | ALL }
Description
Disables the POE interface. This is independent of the interface’s administrative state, meaning that a
port with PoE disabled could still be UP-UP and passing traffic.
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
A logical representation of one or more physical ports
NA
NA
type:id-range - the type of available ports, such as
ETH:7.0 or a range (ETH:8.0-8.9)
id-range - used with type (type:id) to query the physical
ports; the numerical identifier of the interface
ifname-list - list of interface names, if not numerical
ALL - all applicable interfaces in the system
Release Note
NA
Example
DISABLE POE INTERFACE 1.23
Service may be affected, are you sure (Y/N)? y
Info (020185): Successfully disabled interface(s) ETH:[1.23]
299
ENABLE POE INTERFACE
Syntax
ENABLE POE INTERFACE={ type:id-range | id-range | ifname-list | ALL } [ PRIORITY={ CRITICAL | HIGH | LOW } ] [ POWERLIMIT={ CLASS | 1..30000 } ]
Description
Enables the POE interface so it may pass traffic. The priority controls which interfaces are granted
power when the power demand exceeds the available PoE power capacity. Low priority ports are the
first to be powered down, followed by high priority ports. By default all ports are low priority. The
power limit allows the user to set the maximum power that the port can draw before shutting down.
The default PoE state for each port is enabled. .
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
NA
NA
NA
LOW
NA
CLASS
PRIORITY
Specifies which interfaces are given power when the
power demand exceeds the available PoE power capacity.
CRITICAL - Critical priority ports are given power first
in a capacity shortage.
HIGH - Next priority to receive power in a capacity
shortage, if power is available.
LOW - First ports to be powered down in a capacity
shortage.
POWERLIMIT
Specifies the maximum power that the port can draw
before shutting down, in milliwatts.
CLASS - the power class of the device. The PSU
identifies the class of the PD and uses the power
limit that applies to that class: Class 1 (4W), Class
2 (7W), Class 3 (15.4W), and Class 4 (30W).
1...30000 - range of power in milliwatts
Release Note
NA
Example
ENABLE POE INTERFACE=1.23
300
RESET POE COUNTER INTERFACE
Syntax
RESET POE COUNTER INTERFACE [ ={ type:id-range | id-range | ifname-list | ALL
} ]
Description
Resets the counters for the POE interface(s).
Mode
Manager
Options
Option
Description
Default Value
Default
Value
INTERFACE
NA
NA
Release Note
NA
Example
RESET POE COUNTER INTERFACE=1.23
301
SET POE INTERFACE
Syntax
SET POE INTERFACE={ type:id-range | id-range | ifname-list | ALL } [ PRIORITY={ CRITICAL | HIGH | LOW } ] [ POWERLIMIT={ CLASS | 1..30000 } ]
Description
Sets the PoE options for one or more interfaces. The PRIORITY parameter controls which interfaces
are granted power when the power demand exceeds the available PoE power capacity. Low priority
ports are the first to be powered down, followed by high priority ports. By default all ports are low
priority. The power limit allows the user to set the maximum power that the port can draw before
shutting down.
Mode
Manager
Options
Option
Description
Default Value
Default
Value
INTERFACE
NA
NA
LOW
LOW
CLASS
CLASS
PRIORITY
Specifies which interfaces are given power when the
power demand exceeds the available PoE power capacity.
CRITICAL - Critical priority ports are given power first
in a capacity shortage.
HIGH - Next priority to receive power in a capacity
shortage, if power is available.
LOW - First ports to be powered down in a capacity
shortage.
POWERLIMIT
Specifies the maximum power that the port can draw
before shutting down, in milliwatts.
CLASS - the power class of the device. The default
class is 0, which is allocated 15.4W by default.
The supported classes are: Class 1 (4W), Class 2 (7W),
Class 3 (15.4W), and Class 4 (30W). The number of
devices capable of being supported per shelf depends on
the class of the devices in use.
1...30000 - range of power in milliwatts; use to manually
set the power limit instead of using CLASS.
Release Note
NA
Example
SET POE INTERFACE=1.23 POWERLIMIT=CLASS PRIORITY=HIGH
302
SET POE THRESHOLD
Syntax
SET POE THRESHOLD=1..99
Description
Sets the PoE options for the system for the power usage threshold. This is the percentage of the total
power available that is currently being used (instantaneous usage, not requested usage). The default
threshold is 99 percent. When the threshold is exceeded, an alarm notification is recorded.
Mode
Manager
Options
Option
Description
Range
Default
Value
THRESHOLD
Percentage of total power available that is currently in
use. The range is 1-99 percent.
99
99
Release Note
NA
Example
SET POE THRESHOLD=75
303
SHOW POE COUNTER INTERFACE
Syntax
SHOW POE COUNTER INTERFACE [ ={ type:id-range | id-range | ifname-list | ALL
} ]
Description
Shows the counters for the POE interface(s).
PoE counters are fault and status events. These are defined as follows:
Mode
•
MPS Absent - Maintenance power signature is the signal a PD sends to the switch to indicate that
the PD is connected and requires power; indicates the number of times a detected PD has no longer
requested power from the port
•
Invalid - indicates a fault with the connected PD
•
Denied - the number of times PDs requesting power on the port have been denied due to insufficient power available
•
Overload - the number of times a connected PD attempted to draw more than 15.4 watts
•
Short - the number of times the switch provided insufficient current to a connected PD.
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
NA
NA
Release Note
NA
Example
officer SEC>> SHOW POE COUNTER INTERFACE=1.0-1.4
--- PoE Interface Counters --------------------------------------Interface
----------1.0
1.1
1.2
1.3
1.4
MPS Absent
-----------12
6
0
0
Invalid
--------0
3
0
0
Denied
--------0
3
0
0
Overload
---------0
0
0
0
Short
-------0
0
1
0
304
SHOW POE INTERFACE
Syntax
SHOW POE INTERFACE [ ={ type:id-range | id-range | ifname-list | ALL } ] [
FULL ]
Description
Displays the PoE attributes and settings for one or more interfaces.
Mode
User
Options
Option
Description
Range
Default
Value
INTERFACE
NA
NA
NA
NA
FULL
Shows full information for the specified command.
Release Note
NA
Example
When a specific interface is included, the SHOW POE INTERFACE command
shows the main attributes for the specified interface. With the FULL
option, this command shows the configuration options and the actual
status.
officer SEC>> SHOW POE INTERFACE=1.*,2.0
--- POE Power Status --PoE
POE
Interface State
Priority Limit Power Status
Class
Actual
--------- -------- -------- ----- -------------- ---------- ---------1.0
Disabled Low
7.0W Disabled
2 (7W)
0W
1.1
Enabled High
CLASS Powered
3 (15.4W) 8.7W
1.2
Enabled Low
15.0W No PD Detected 0W
1.3
Enabled Critical 10.0W Fault Present 0 (15.4W)
0W
1.4
Enabled Critical 5.5W Powered
2 (7W)
6.4W
1.5
Enabled High
5.0W Disabled
4 (30W)
0W ...
2.0
Enabled High
CLASS Disabled
0W
officer SEC>> SHOW POE INTERFACE=1.1 FULL
--- POE Power Status --Interface.............................
POE State.............................
Priority..............................
Power Limit...........................
Actual
Power Status........................
Class...............................
Power...............................
Voltage.............................
Current.............................
1.0
Enabled
Low
CLASS
Powered
3 (15.4W)
4.3W
50.1V
86mA
305
SHOW POE
Syntax
SHOW POE [ CARD={ slot-list | ALL } ]
Description
Displays the power usage for the shelf and/or supported cards. If no card is selected then all cards are
shown.
Mode
User
Options
Option
Description
Range
Default
Value
CARD
The slot number for the PoE card (module) in the shelf.
NA
NA
slot-list - a comma-separated or a dash range of slots
ALL - shows all applicable cards on the shelf.
Release Note
NA
Example
officer SEC>> SHOW POE CARD=ALL
--- POE Power Status --Shelf Power Total.....................
Shelf Power Requested.................
Shelf Power Available.................
Shelf Power Actual....................
Shelf Power Threshold.................
Card
---0
1
2
3
7
8
10
11
Allocated
-----------53W
51W
500W
182W
51W
51W
51W
261W
Requested
---------30W
16W
510W
168W
0W
30W
16W
247W
Actual
------24W
9W
439W
168W
0W
26W
15W
207W
1200W
1017W
183W
888W
99%
Min Voltage
-----------50.0V
50.0V
50.0V
50.0V
50.0V
50.0V
50.0V
50.0V
Max Voltage
-----------57.0V
57.0V
57.0V
57.0V
57.0V
57.0V
57.0V
57.0V
306
4. Layer Two Switching
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Switching
Switching Commands
Link Aggregation (LAG)
LAG Commands
VLAN (802.3)
VLAN Commands
Spanning Tree Introduction: STP, RSTP, MSTP and BPDU Cop
Spanning Tree Commands
Ethernet Protection Switched Ring (EPSR) and SuperLoop Prevention
EPSR and SuperLoop Commands
Upstream Forwarding Only (UFO) Mode
Upstream Control Protocol (UCP)
HVLAN (Port Based and VLAN Based)
HVLAN Commands
VLAN Translation
VLAN Translation Commands
307
Layer Two Switching
4.1 Switching
4.1.1 Overview
As a layer 2 switching device, the Allied Telesis SBx3112 ensures data packets arrive at their proper destination by using:
• VLAN - This is a software-defined subnetwork that allows devices to be grouped into one logical broadcast domain.
• MAC address - The MAC address uniquely identifies each hardware device attached to the network.
The layer 2 switching process includes four separate but related processes:
1.
Ingress Rules admit or discard frames based on their VLAN tagging.
2.
Learning Process learns the MAC addresses for each VLAN as frames are admitted to each interface.
3.
Forwarding Process determines which interfaces the frames are forwarded to.
4.
Egress Rules determine for each frame whether VLAN tags are included in the Ethernet frames that are Transmitted.
Since this is layer 2, the learning process assumes that each host on the extended LAN has a unique data link layer address,
and all data link layer frames have a header which includes the source (sender) MAC address and destination (receiver) MAC
address.
4.1.2 Ingress Rules
When a frame first arrives at a port, the Ingress Rules for the port will check the VLAN tagging in the frame to determine
whether it will be discarded or forwarded to the Learning Process.
Every frame received by the switch must be associated with a VLAN. If a received frame is untagged, then the port's untagged
VLAN Identifier (VID) will be associated with the received frame. Since every port belongs to one or more VLANs, every
incoming frame will have a VID to indicate which VLAN it belongs to.
The Ingress Rule will check whether the port, in which the frame was received on, belongs to the VLAN indicated by the
received frame's VID. If the port is not a member of the VLAN, then the frame will be discarded; otherwise, the frame will be
passed on to the Learning Process.
4.1.3 Learning Process
When a layer 2 ethernet switch first receives frames, the switch floods the data packets. The Learning Process uses an adaptive learning algorithm -- sometimes called backward learning -- to discover the location (port) of each host on the extended
LAN and ensure frames are sent to their destination as efficiently as possible.
All frames admitted by the Ingress Rules on any port are passed on to the Learning Process, where the frame's source MAC
address and numerical (VID) are compared with entries in the Forwarding Database for the VLAN (also known as a MAC
address table, or a forwarding table) maintained by the switch. The Forwarding Database contains one entry for every unique
host MAC address the switch knows in each VLAN.
If the frame's source address is not already in the Forwarding Database for the VLAN, the address is added (MAC address
and VLAN ID) and an ageing timer for that entry is started. If the frame's source address is already in the Forwarding Database, the ageing timer for that entry is restarted.
By default, switch learning is enabled, and it can be disabled or enabled using the commands:
DISABLE SWITCH LEARNING
ENABLE SWITCH LEARNING
Caution: If the Learning Process is disabled, MAC addresses are no longer added to the forwarding database, and as the
ageingtimer (discussed next) expires and frames with their source addresses and VLAN IDs are no longer learned,
the system will slowly depopulate its forwarding database
308
Layer Two Switching
If the ageing timer for an entry in the Forwarding Database expires before another frame with the same source address and
VID is received, the entry is removed from the Forwarding Database. This prevents the Forwarding Database from being
filled up with information about hosts that are inactive or have been disconnected from the network, while ensuring that
entries for active hosts are kept alive. By default, the ageing timer is enabled, and it can be disabled or enabled using the commands
ENABLE SWITCH AGEINGTIMER
DISABLE SWITCH AGEINGTIMER
The ageing timer can be modified and has a range of 10 - 630 seconds. By default, the ageing time is set to a value of 300 second (5 minutes).
The Forwarding Database relates a host's (source) address to a port on the switch, and is used by the switch to determine
from which port (if any) to transmit frames with a destination MAC address matching the entry in the host map.
To display the contents of the Forwarding Database, use the SHOW SWITCH FDB command. The output includes:
•
•
•
•
VLAN or HVLAN - The VID Identifier for the VLAN or HVLAN.
Interface - The interface from which the MAC address was learned.
MAC Address - The MAC address as learned from the source address field of a frame. Example: 00:0C:25:00:13:8C.
Status - Whether the MAC address was learned from the source address field of a frame.
manager SEC>> show switch fdb interface 0.1
--- Switch Forwarding Database --Slot
VLAN
Interface ID
MAC Address
Status
----------0
0
0
0
0
0
0
0
0
0
----------1
1
1
1
1
1
1
1
1
1
--------------0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
---------------------00:58:F8:3F:8F:9F
04:6D:D6:B6:16:BA
06:46:69:F9:38:9D
0A:37:F5:3A:50:B5
0C:1E:A0:ED:3E:23
0E:68:72:C3:CC:8E
10:2A:7E:46:55:B7
12:61:E5:FE:D3:00
16:31:91:FB:7B:5A
1A:3D:A3:21:66:53
-------Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
4.1.4 Forwarding Process
The Forwarding Process forwards received frames that are to be relayed to other ports in the same VLAN. If a frame is
received on the port for a destination in a different VLAN, it will need to be serviced by a Layer 3 switch/router external to
the SBx3112 product.
4.1.5 Egress Rules
Once the Forwarding Process has determined which ports the frame is to be forward to, the Egress Rules for each port
determine if the outgoing frame is to be VLAN-tagged with its numerical VLAN Identifier (VID).
When an interface is added to a VLAN, the VLAN is configured to transmit either untagged or tagged VLAN packets. This is
done using the commands to add or set the VLAN interface. Refer to 4.3.2.1 on VLAN tagging.
4.1.6 MAC Thrash Limiting (SBx3112)
As explained in the previous sections, the four related processes listed in 4.1.1 result in traffic being sent directly to its
proper destination with a system that maps VLANs to unique MAC addresses on specific interfaces. However, it is possible
that duplicate MAC addresses can occur legitimately (called a MAC move), and these can occur on different interfaces or on
309
Layer Two Switching
the same interface. The MAC Thrash Limiting feature detects and handles this scenario where MAC moves occur at a high
rate.
4.1.6.1 Duplicate Addresses on Inter-card Interfaces (System Wide)
If the same address is seen on more than one interface a number of times, there is a possible loop condition. Any time a MAC
move occurs, it is considered a potential duplicate address. When the first MAC move is detected a system-wide one second
timer starts. During this second, the MAC move count increments. If the count exceeds 128 before the second expires, a
duplicate address condition is declared and the following actions occur:
•
•
•
•
•
The interface on which the next MAC move occurs is learning disabled. Packets received will continue to forward.
The interface will stay in a learning disabled state for 60 seconds.
The interface that currently has the MAC address is not affected, and its learning is not disabled.
Up until the second expires, these actions continue for every succeeding MAC move.
An alarm is generated, and a trap is sent.
When the second expires, the process for detecting MAC moves starts again.
4.1.6.2 Duplicate Addresses on Intra-card Interface
If a duplicate MAC address is detected on an intra-card interface in a very short period of time, the following actions occur:
• The interface is learning disabled immediately (there is no one-second timer or 128 limit). Packets received will continue to forward.
• The Line Card sends a message to the CFC to inform the FDB Management system that the interface has been disabled
because of MAC Thrash Limiting.
• The interface will stay in a learning disabled state for 60 seconds.
4.1.7 Clearing the Forwarding Database (FDB)
There are two ways in which an address can be cleared from the switch FDB.
The contents of the FDB can be manually cleared by using the CLEAR SWITCH FDB command:
• VLAN or HVLAN - The VID Identifier for the VLAN or HVLAN.
• MAC Address - The MAC address as learned from the source address field of a frame. Example: 00:0C:25:00:13:8C
• Interface - The interface from which the MAC address was learned.
Alternatively, there is an option to have the MAC addresses remain in the FDB after the interface fails. MAC addresses can be
dynamically removed from the FDB by using the following command:
SET SWITCH MACREMOVALMODE={AGEONLY|AGEANDSTATE}
The default setting, AGEANDSTATE, removes dynamic FDB entries upon regular ageing time-outs and on interface out-ofservice state changes.
The optional setting, AGEONLY, removes dynamic FDB entries upon regular ageing time-outs but does not remove them on
interface out-of-service state changes.
4.1.8 Viewing Switch Settings
The SHOW SWITCH command displays configuration information for the switch functions.
officer SEC>> show switch
--- Switch Configuration ------------------Learning.............................. On
310
Layer Two Switching
Ageing Timer..........................
Ageingtimer...........................
Age-Only FDB Clear....................
Number of SM Ports....................
Number of NM Ports....................
Number of HVLAN.......................
Number of Standard VLAN...............
Number of
VLAN.................... 0
Hash Select ..........................
On
300
Off
96
4
0
1
ALL
--------------------------------------------
The displayed switch settings are:
• Learning - Whether or not the switch's dynamic learning and updating of the Forwarding Database is enabled; one of
“ON” or “OFF”.
• Ageing Timer - Whether or not the ageing timer is enabled; one of “ON” or "OFF".
• Ageingtimer - The value in seconds of the ageing timer, after which a dynamic entry is removed from the Forwarding
Database.
• Age-Only FDB Clear:
• As displayed above, the attribute Age-Only FDB Clear is Off, which indicates that the default AGEANDSTATE setting is currently ON.
• If the attribute Age-Only FDB Clear is On, the optional AGEONLY setting is currently ON.
• Number of SM Ports - The number of fixed switch downlink Line Card interfaces.
• Number of NM Ports - The number of switch uplink interfaces.
Note:
The concept of NM and SM Ports does not apply to the SBx3112; it will be replaced with the term Line Card in a
future release.
• Number of HVLAN - The number of HVLANs in the switch.
• Number of Standard VLAN - The number of standard 802.1q VLANs in the switch.
• Number of UFO VLAN - The number of upstream forwarding-only VLANs in the switch. In a UFO VLAN, the traffic
from downstream interfaces is forwarded only to upstream interface(s). Also includes the type of MACREMOVAL set for
the system.
• Hash Select - The current hash selection setting.
4.1.9 Configuring the Forwarding Database
By default, the Switch Learning and Ageingtimer are set to ENABLED, so the FDB is dynamically learned and updated, and
AGEINGTIMER determines when a dynamic entry is removed.
When a learn limit is set on an interface and that limit is exceeded there is no log or trap sent. (This is different than the feature for the iMAPs where an “FDB management overflow” log, a CARD046, and associated SNMP trap would be generated.)
The SBx3112 supports a maximum 16K MAC address table size. If this learn limit is exceeded, those MAC addresses (in
excess of the 16K limit) are flooded.
4.1.9.3 Feature Interactions for Interface Learn Limit and TPID
The SET INTERFACE TPID and SET INTERFACE LEARNLIMIT commands affect this feature.
311
Layer Two Switching
• The SBx3112 supports a maximum 16K MAC address table size. On a per-port basis, if LEARNLIMIT=OFF then the port
can learn up to the system maximum. If LEARNLIMIT=1..64, then the port can fully support that limit. This applies both
XE4 and GE24 interfaces.
• Unlike legacy iMAP, there is a limited number of TPIDs for a given card -- that can be applied to all card ports. For the
XE4, the limit is 2 different TPIDs. For GE24 cards, the limit is 8 different TPIDs.
4.1.9.4 Configuration Procedure - Dynamically Clearing the FDB
The following procedure demonstrates the behavior of the FDB when MAC addresses are configured to be dynamically
cleared -- using the SET SWITCH MACREMOVALMODE command.
TABLE 4-1
Step
Configuration Procedure for Clear FDB (Dynamically)
Command
Description/Notes
View current switch settings. The “Age-Only FDB Clear” parameter is “Off” -- indicating the default MAC removal mode
as AGEANDSTATE.
1
show switch
--- Switch Configuration -----------------------------------------------------Learning..............................
Ageing Timer..........................
Ageingtimer...........................
Age-Only FDB Clear............... Off
Number of HVLAN.......................
Number of UFO VLAN....................
Hash Select ..........................
On
On
300
196
24
2
261
14
ALL
View contents of the FDB.
2
show switch fdb
VLAN
Interface ID
MAC Address
----------- ----------- --------------- ---------------------0
420
0.0
00:00:CD:0E:B1:F0
0
420
0.0
00:0C:25:00:FC:59
0
2100
0.0
00:0C:25:00:FC:59
0
3511
0.23
00:00:02:00:0B:99
Dynamic
11
512
11.23
00:02:02:00:AB:15
11
512
11.23
00:02:02:00:AB:AF
11
512
11.23
00:02:02:00:AC:05
11
512
11.23
00:02:02:00:BC:A7
Status
--------------Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Disable interface 0.23 in order to observe behavior of FDB.
3
disable interface 0.23
First, disable interface.
Verify that the entry for interface 0.23 has been removed from FDB.
312
Layer Two Switching
TABLE 4-1
Step
Command
4
show switch fdb
Description/Notes
----------0
0
0
0
0
0
11
11
11
11
VLAN
----------420
420
420
420
420
2100
512
512
512
512
Interface ID
--------------0.0
0.0
0.0
0.0
0.0
0.0
11.23
11.23
11.23
11.23
MAC Address
---------------------00:00:CD:0E:B1:F0
00:0C:25:00:FC:59
94:0C:6D:B6:49:65
94:0C:6D:BC:47:B5
94:0C:6D:BC:49:54
00:0C:25:00:FC:59
00:02:02:00:AB:15
00:02:02:00:AB:AF
00:02:02:00:AC:05
00:02:02:00:BC:A7
Status
--------------Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Slot
VLAN
Interface ID
MAC Address
----------- ----------- --------------- ---------------------0
420
0.0
00:00:CD:0E:B1:F0
0
420
0.0
00:0C:25:00:FC:59
0
2100
0.0
00:0C:25:00:FC:59
0
3511
0.23
00:00:02:00:0B:99
Dynamic
11
512
11.23
00:02:02:00:AB:15
11
512
11.23
00:02:02:00:AB:AF
11
512
11.23
00:02:02:00:AC:05
11
512
11.23
00:02:02:00:BC:A7
Status
--------------Dynamic
Dynamic
Dynamic
Re-enable the interface 0.23.
5
enable interface 0.23
Verify that interface 0.23 reappears in FDB.
6
show switch fdb
--- Switch Forwarding Database ---
Dynamic
Dynamic
Dynamic
Dynamic
Change the MAC Removal mode so that a MAC address is removed only when it is aged out.
7
set switch macremovalmode ageonly
Verify that the MAC Removal mode has changed to AGEONLY (i.e., the “Age-Only FDB Clear” parameter is “On”).
8
show switch
--- Switch Configuration ------------------------------------------------------
.
Learning..............................
Ageing Timer..........................
Ageingtimer...........................
Age-Only FDB Clear............... On
Number of HVLAN.......................
Hash Select ..........................
On
On
300
<<Notice this is now "On"
196
24
2
261
14
ALL
Disable interface 0.23 again
9
disable interface 0.23 force
313
Layer Two Switching
TABLE 4-1
Step
Command
Description/Notes
Verify that the MAC address now remains -- where as, it was immediately removed before
10
show switch fdb
VLAN
Interface ID
MAC Address
Status
----------- ----------- --------------- ---------------------- --------------0
420
0.0
00:00:CD:0E:B1:F0
Dynamic
0
420
0.0
00:0C:25:00:FC:59
Dynamic
0
2100
0.0
00:0C:25:00:FC:59
Dynamic
0
3511
0.23
00:00:02:00:0B:99 Dynamic <<still present!
11
512
11.23
00:02:02:00:AB:15
Dynamic
11
512
11.23
00:02:02:00:AB:AF
Dynamic
11
512
11.23
00:02:02:00:AC:05
Dynamic
11
512
11.23
00:02:02:00:BC:A7
Dynamic
314
Layer Two Switching
4.1.10 Switching Commands
This subsection provides an alphabetical reference for commands used to configure the Forwarding Database (FDB). For
information about spanning trees, including configuration procedures, refer to 4.4.
TABLE 4-2
Switching Commands
Commands
CLEAR SWITCH FDB (HVLAN)
CLEAR SWITCH FDB (VLAN)
SET SWITCH AGEINGTIMER
SET SWITCH FDBSIZE
SET SWITCH MACREMOVALMODE
SHOW SWITCH
SHOW SWITCH FDB
SHOW SWITCH INTERNALMAC
315
Layer Two Switching
CLEAR SWITCH FDB (HVLAN)
Syntax
CLEAR SWITCH FDB [INTERFACE={type:id-range|id-range|ifname-list| ALL}]
[ADDRESS=macaddress] [HVLAN={hvlanname|vid}]
Description
Clears the contents of the Forwarding Database for the specified HVLAN.
Mode
Manager
Options
Option
Description
Range
Default Value
INTERFACE
The interface from which the MAC address was learned
NA
NA
MAC_Address
A specific MAC address as learned from the source
address field of a frame. Example: 00:0C:25:00:13:8C
NA
ALL - All
learned MAC
addresses
HVLAN
The VID Identifier for the HVLAN.
NA
NA
Release Note
NA
Example
CLEAR SWITCH FDB INTERFACE=8.0 HVLAN=236
316
Layer Two Switching
CLEAR SWITCH FDB (VLAN)
Syntax
CLEAR SWITCH FDB [INTERFACE={type:id-range|id-range|ifname-list| ALL}]
[ADDRESS=macaddress] [VLAN={vlanname|vid}]
Description
Clears the contents of the Forwarding Database for the specified VLAN.
Mode
Manager
Options
Option
Description
Range
Default Value
INTERFACE
The interface from which the MAC address was learned
NA
NA
MAC Address
A specific MAC address as learned from the source
address field of a frame. Example: 00:0C:25:00:13:8C
NA
ALL - All learned
MAC addresses
VLAN
The VID Identifier for the VLAN.
NA
NA
Release Note
NA
Example
CLEAR SWITCH FDB INTERFACE=8.0 VLAN=123
317
Layer Two Switching
Syntax
Description
Disables the ageing timer from ageing out dynamically learned entries in the Forwarding Database. The
default setting for the ageing timer is enabled.
If the switch finds no matching entries in the Forwarding Database during the Forwarding Process, then
all switch interfaces in the VLAN/HVLAN will be flooded with the packet (except the interface on
which the packet was received).
Mode
Manager
Note
Disabling the switch ageing timer is not recommended.
Options
None
Release Note
NA
Example
318
Layer Two Switching
Syntax
Description
Disables the dynamic learning and updating of the Forwarding Database. The default setting for the
learning function is enabled.
Mode
Manager
Options
None
Release Note
NA
Example
319
Layer Two Switching
Syntax
Description
Enables the ageing timer to age out dynamically learned entries in the Forwarding Database. The
default setting for the ageing timer is enabled. If the switch finds no matching entries in the Forwarding
Database during the Forwarding Process, then all switch interfaces in the VLAN/HVLAN will be
flooded with the packet, except the interface on which the packet was received.
Mode
Manager
Options
NA
Release Note
NA
Example
320
Layer Two Switching
Syntax
Description
Enables the dynamic learning and updating of the Forwarding Database. The default setting for the
learning function is enabled. If the switch finds no matching entries in the Forwarding Database during
the Forwarding Process, then all switch interfaces in the VLAN/HVLAN will be flooded with the
packet, except the interface on which the packet was received.
Mode
Manager
Options
NA
Release Note
NA
Example
321
Layer Two Switching
SET SWITCH AGEINGTIMER
Syntax
SET SWITCH AGEINGTIMER=10..630
Description
The SET SWITCH AGEINGTIMER sets the threshold value (in seconds) of the ageing timer. Afterwards, a dynamic entry in the Forwarding Database is automatically removed.
Mode
Manager
Options
Option
Description
Range
Default
Value
AGEINGTIMER
Time (in seconds) after which a dynamic entry in the
Forwarding Database is automatically removed.
10-630
300 seconds
The maximum setting of 630 seconds is approximately
10.5 minutes.
The valid ageing timer range for the SBx3112 is 10 to
630. This range may be different for other products in
the SBx3100 family.
Release Note
NA
Note
Changing the ageing time will only affect entries added to the Forwarding Database after the timer has
been changed.
Example
SET SWITCH AGEINGTIMER=300
322
Layer Two Switching
SET SWITCH FDBSIZE
Syntax
SET SWITCH FDBSIZE={ 16K | 32K } RESTARTSYSTEM [ FORCE ]
Description
This command sets the value of the FDBSIZE attribute. Setting this attribute will require a system
restart. Any cards that are incompatible with this FDB size will not be allowed to come online. If there
is no change in FDBSIZE the user is notified with an informative message and no action is taken.
The SHOW SWITCH command will show that the FDB size has been changed.
Mode
Manager
Options
Option
Description
Range
Default
Value
FDBSIZE
Specify the desired maximum nominal size of the
FDB in terms of MAC address capacity
16K, 32K
NA
RESTARTSYSTEM
There will be a prompt that a system restart will
take place.
NA
NA
FORCE
There will be no prompt that a system restart will
take place.
NA
NA
Note
When the user tries to place into service a card that cannot support the configured FDBSIZE parameter, there is a failure raised against the card with the message “Incomptaible DB size.” The user must
change the FDBSIZE so that card can be placed into service, or use a card that matches the configured
FDBSIZE. This alarm will not appear if a higher priority message (card not persent or incompatible
load) is also present.
Note
This command is rejected if any currently inservice cards are incomptible with the new setting.
Example
officer SEC>> SET SWITCH FDBSIZE=32K RESTARTSYSTEM
(Error xxxxx) Cards 0,1 cannot support the new FDB size and must be disabled.
officer SEC>>
officer SEC>> DISABLE CARD 0,1
Service may be affected, are you sure (Y/N)? y
Info (039512): Operation Successful (GE24POE Slot 0)
Info (039512): Operation Successful (GE24POE Slot 1)
officer SEC>>
officer SEC>> SET SWITCH FDBSIZE=32K
Error (000001): The command entered is incomplete.
Please refer to the following list of expected parameters:
RESTARTSYSTEM - User acknowledgement of the required system restart
officer SEC>>
officer SEC>> SET SWITCH FDBSIZE=32K RESTARTSYSTEM
Setting the switch FDB size automatically restarts the system.
Cards that cannot support the new FDB size will not boot.
Do you want to proceed (Y/N)? Y
323
Layer Two Switching
SET SWITCH MACREMOVALMODE
Syntax
SET SWITCH MACREMOVALMODE={AGEONLY|AGEANDSTATE}
Description
Provides the option to have the MAC addresses remain in the FDB after the interface fails.
Note:
If the AGEONLY parameter is set and a device is physically moved from one port to another, the device’s MAC
address will naturally appear on the new port. This is regarded as a legitimate MAC move. The resulting duplicate
MAC address will be detected/handled by the MAC Thrash Limiting feature as decribed in MAC Thrash Limiting
(SBx3112).
Mode
Manager
Options
Option
Description
Range
MACREMOVALMODE
AGEANDSTATE - removes dynamic FDB entries upon
regular ageing time-outs and on interface out-of-service
state changes.
NA
Default
Value
AGEANDSTATE
AGEONLY - removes dynamic FDB entries upon regular
ageing time-outs but does not remove them on interface
out-of-service state changes.
Release Note
NA
Example
SET SWITCH MACREMOVALMODE=AGEANDSTATE
324
Layer Two Switching
SHOW SWITCH
Syntax
SHOW SWITCH
Description
Displays configuration information for the switch functions.
Mode
Manager
Options
NA
Release Note
NA
Example
E135 - manager SEC>> SHOW SWITCH
--- Switch Configuration -----------------Learning..............................
Ageing Timer..........................
Ageingtimer...........................
Number of HVLAN.......................
Hash Select ..........................
On
On
300
Off
182
18
0
22
1
ALL
-------------------------------------------
325
Layer Two Switching
SHOW SWITCH FDB
Syntax
SHOW SWITCH FDB [ INTERFACE={ type:id-range | id-range | ifname-list | ALL} ]
[ ADDRESS=macaddress ] [ HVLAN={ hvlanname | vid } ]
Description
Displays the contents of the Forwarding Database.
Mode
Manager
Options
Release Note
Option
Description
Range
Default
Value
INTERFACE
An interface name or ID
NA
NA
ADDRESS
A MAC address. You can use the wildcard (*) character
to filter for a range of MAC addresses
NA
ALL
HVLAN
The name of id of an HVLAN
NA
ALL
NA
Example
SHOW SWITCH FDB INTERFACE=3.*,11.22
----------3
3
3
3
3
3
3
3
3
3
3
3
3
11
11
11
11
VLAN
----------420
420
512
512
10
402
402
402
420
420
420
512
512
1415
1415
1415
1415
Interface ID
--------------3.1
3.1
3.1
3.1
3.2
3.2
3.2
3.2
3.2
3.2
3.2
3.2
3.2
11.22
11.22
11.22
11.22
MAC Address
---------------------00:00:CD:0E:B1:F0
00:09:6B:09:1C:32
00:0C:31:D4:60:00
00:15:77:F5:68:61
00:18:8B:A7:F0:00
00:00:CD:1D:C1:C2
00:00:CD:23:28:6F
00:0A:5E:61:B2:37
00:0C:25:00:05:AD
00:0C:25:00:06:AE
00:0C:25:00:FC:59
00:02:02:00:AC:0A
00:02:02:00:BC:5B
00:00:CD:0E:B1:F0
00:09:6B:09:1C:32
00:0D:DA:0C:01:3C
EC:CD:6D:03:10:CC
Status
-------Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
Dynamic
326
Layer Two Switching
Syntax
SHOW SWITCH INTERNALMAC [ { INTERFACE={ type:id-range | id-range | ifnamelist | ALL } | CARD={ slot-list | ALL } } ] [ ADDRESS=macaddress ]
Description
Displays the all the internal MAC addresses assigned to all the external and internal ports of all the
card types.
Mode
Manager
Options
Release Note
Option
Description
Range
Default
Value
INTERFACE
The id type, name, or ALL
NA
ALL
CARD
The slot number or ALL
NA
ALL
ADDRESS
A specific MAC address
NA
ALL
NA
Example
--- Internal MAC Address --Slot
----------5
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
8
8
8
8
Interface ID
--------------0
1.0
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
1.13
1.14
1.15
1.16
1.17
1.18
1.19
1.20
1.21
1.22
1.23
8.0
8.1
8.2
8.3
Card Type
----------CFC200
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
MAC Address
---------------------00:0C:25:04:00:0C
00:0C:25:04:02:F7
00:0C:25:04:02:F8
00:0C:25:04:02:F9
00:0C:25:04:02:FA
00:0C:25:04:02:FB
00:0C:25:04:02:FC
00:0C:25:04:02:FD
00:0C:25:04:02:FE
00:0C:25:04:02:FF
00:0C:25:04:03:00
00:0C:25:04:03:01
00:0C:25:04:03:02
00:0C:25:04:03:03
00:0C:25:04:03:04
00:0C:25:04:03:05
00:0C:25:04:03:06
00:0C:25:04:03:07
00:0C:25:04:03:08
00:0C:25:04:03:09
00:0C:25:04:03:0A
00:0C:25:04:03:0B
00:0C:25:04:03:0C
00:0C:25:04:03:0D
00:0C:25:04:03:0E
00:0C:25:04:02:48
00:0C:25:04:02:49
00:0C:25:04:02:4A
00:0C:25:04:02:4B
327
Layer Two Switching
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
10
10
10
10
11
11
11
11
8.4
8.5
8.6
8.7
8.8
8.9
8.10
8.11
8.12
8.13
8.14
8.15
8.16
8.17
8.18
8.19
8.20
8.21
8.22
8.23
10.0
10.1
10.2
10.3
11.0
11.1
11.2
11.3
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
GE24POE
XE4
XE4
XE4
XE4
XE4
XE4
XE4
XE4
00:0C:25:04:02:4C
00:0C:25:04:02:4D
00:0C:25:04:02:4E
00:0C:25:04:02:4F
00:0C:25:04:02:50
00:0C:25:04:02:51
00:0C:25:04:02:52
00:0C:25:04:02:53
00:0C:25:04:02:54
00:0C:25:04:02:55
00:0C:25:04:02:56
00:0C:25:04:02:57
00:0C:25:04:02:58
00:0C:25:04:02:59
00:0C:25:04:02:5A
00:0C:25:04:02:5B
00:0C:25:04:02:5C
00:0C:25:04:02:5D
00:0C:25:04:02:5E
00:0C:25:04:02:5F
00:0C:25:04:00:BC
00:0C:25:04:00:BD
00:0C:25:04:00:BE
00:0C:25:04:00:BF
00:0C:25:04:00:40
00:0C:25:04:00:41
00:0C:25:04:00:42
00:0C:25:04:00:43
328
Layer Two Switching
4.2 Link Aggregation (LAG)
4.2.1 Introduction
The Link Aggregation Group (LAG) feature, defined in 802.3ad, allows multiple physical links to be joined into a LAG, which
creates one virtual link. If one link fails, traffic is distributed to the remaining inservice links. Links can be added or deleted
from the LAG, depending on traffic requirements.
The following figure shows a basic LAG configuration for the SBx3112.
= Line
Card
lagid 1
lagid 2
= Interface
SBx3112
SBx3100
CFC
FIGURE 4-1
Upstream Protection Using LAG - SBx3112
The LAG feature works on all the Allied Telesis products, but there are key differences in how they can be deployed for the
SBx3100.
• The SBx3100 supports cross-card LAG, across like interfaces (GE or XE), on all line cards. The SB x3100 supports one
hash select algorithm for the entire switch, which can be set using the set switch hash select CLI command. Setting the
switch hash select affects the behavior of all existing LAGs.
• The SBx3100 also supports the Link Aggregation Control Protocol (LACP) feature. When enabled, this feature allows
the SBx3100 to exchange LACP messages (LACPDUs) with neighboring systems, for the purpose of aggregating links connected between the systems. The SBx3100 continues to support static-mode link aggregation (LAG), which requires
manual configuration of the LAG on the near and far-end systems. Therefore, the SBx3100 can statically or dynamically
configure LAGs via LACP.
• The SBX3100 supports Upstream Forwading Only (UFO) VLANs, allowing users with certain configurations (such as subtending rings) to increase the bandwidth capacity of the uplinks. Refer to 4.2.7.3 for how this is configured.
4.2.2 Feature Overview
IEEE Standard 802.3ad specifies a means of aggregating one or more physical links into a logical link of increased bandwidth
and reliability, between two nodes in a local or metropolitan area network. The resulting logical link is referred to as a LAG,
329
Layer Two Switching
which is comprised of N parallel, full duplex, point-to-point links operating at the same speed. MAC clients then utilize the
LAG as if it were a single link.
Link Aggregation enables setting up grouped links between two nodes, of greater bandwidth than the individual physical links.
This is accomplished by creating a LAG and assigning one or more physical links (ports) to the group. The newly formed
aggregation will have a single MAC address for use by the associated MAC Client. The fact that there are multiple physical
links carrying frames is transparent to the Client.
Ports have their own unique, globally administered MAC address, which are used as the source address for frame exchanges
initiated by Link Aggregation sublayer entities. LACP and Marker protocols use a multicast destination address (01-80-C200-00-02) for exchanges and do not impose any requirement for a port to recognize more than one unicast address on
received frames. Similarly, Aggregators have their own unique, globally administered MAC address, which, per IEEE, can be
the MAC of one of the LAG member ports.
Depending on the direct physical links available between two nodes in the network, it is possible to add or delete links from
the aggregation group. This enables tuning of the LAG size/speed and helps to optimize bandwidth allocation between the
nodes. Prior to link aggregation or logical trunking, bandwidth allocation was solely dependent on the number and data rate
of individual physical links (limited by equipment speeds available at the time) . In order to increase bandwidth, hardware
upgrades were required to utilize faster physical layer technology as it became available (which was typically by orders-ofmagnitude and with a price-tag to match). Without some form of link aggregation or trunking of individual links, there was
no mechanism for increasing bandwidth incrementally.
4.2.3 Static versus Dynamic Link Aggregation
Static link aggregation involves manually provisioning and activating LAGs on the two end-systems, connected via multiple
physical links. This is accomplished with CLI commands on the running system. Steps required include creation of the LAG,
assigning links/ports to the LAG, setting parameters to specify LAG and port behavior, and finally activating the LAG. These
steps must be performed on both systems, with a priori knowledge of the physical links and their characteristics. In staticmode, Link Aggregation Control Protocol Data Units (LACPDUs) are not exchanged between two systems to configure
LAGs.
With dynamic link aggregation, the two systems will automatically enable configured links that can be aggregated within the
LAGs (i.e. admin keys match, run-time attributes match, operational state is up, etc.) without user intervention. This is
accomplished by the exchange LACPDUs between systems, which provide state information for each port.
Note:
Most equipment vendors with deployed systems supporting LACP require users to specify which links are actually
aggregatable, by assigning them to a LAG or trunk group, after which time LACP will manage and optimize the
aggregation. The SBx3112 also requires configuring LAG member ports via applicable CLI commands (see LAG
Commands section).
Protocol partners are referred to as "Actor" and "Partner". The term "Actor" always refers to the local system and "Partner"
always refers to the remote system, from the perspective of the local system. LACPDUs contain Actor and Partner state
information. LACPDUs are transmitted periodically or when either partner has a need to transmit (NTT). Primary reasons
for NTT are Actor state changes, and when the Actor believes that its Partner does not have correct/current knowledge of
the Actor's state. This is determined by examining the Partner's LACPDUs, which contains Actor and Partner state information, from the perspective of the Partner.
Partners can operate in one of two administratively controlled LACP modes: "active" or "passive". Active mode indicates
that the Actor will attempt to initiate LACP regardless of its Partner's mode (speak always). Passive mode indicates that the
Actor will only send LACPDUs if its Partner is in the active mode (speak when spoken to).
When static-mode LAG is configured on both systems connected by one or more links, it is up to the local link/port fault
detection and handling mechanism on each system to remove failed ports from the LAG. This typically requires a loss-of-signal/loss-of-link event or hardware failure being detected and processed. If a media converter is employed between the systems, it is possible that a fault could occur that does not result in a loss-of signal/loss-of-link event. In this case, the link
would be down, but the failure undetected. Traffic would continue to be sent over the failed link, resulting in lost traffic.
330
Layer Two Switching
Running LACP over all links in the LAG avoids this problem, since periodic LACPDUs would not be received by one or both
systems, and the failure would be detected at the individual link level.
Another advantage of running LACP is that Actor and Partner information is exchanged to determine and confirm eligibility
of specific links to be aggregated. This additional level of automatic configuration validation can detect and prevent aggregation of links that are possibly mis-wired between the systems or not truly capable of being aggregated. Note that a limitation
inherent in LACP is that remote system IDs are not evaluated (but there is some level of validation).
Note:
Refer to Bi-Directional Forward Detection (BFD) for a similar feature that can detect hardware or link problems
that have not been reported,
4.2.4 Overview of LAG Commands/States
4.2.4.1 Creating and Activating a LAG
Creating a LAG is done using the CREATE LAG INTERFACE command, and this where the user defines the type of LAG.
Setting the MODE=STATIC indicates that the LAG must be configured on both systems, and will not participate in LACP.
LACP requires setting the MODE=DYNAMIC. The mode is further refined by setting the ROLE attribute to either ACTIVE
or PASSIVE. Setting the ROLE=ACTIVE indicates that the local system will seek to initiate exchange of LACP messages to
negotiate and configure available links in an aggregation with the far-end. Setting the ROLE=PASSIVE indicates that the local
system will only respond to LACP messages when received from another system with ROLE=ACTIVE (essentially, a "speak
only when spoken to" mode of operation).
Note:
In previous releases, the MODE parameter was set via the SET LAG command, and was set to ON or OFF to
control activating the LAG. The MODE parameter now controls the static or dynamic mode of the LAG, and is
specified when the LAG is created using the CREATE LAG INTERFACE command. Refer to the Release Notes for
how saved text configuration files can be modified.
When creating the LAG, the user must specify at least one LAG member port.
Note:
Previously an empty LAG could be created and member port(s) added afterwards. There is no longer support for
"empty” LAGs. Refer to the Release Notes for any upgrade issues.
When a LAG is created, is has a state of disabled. To activate the LAG, the user uses the ENABLE INTERFACE (for LAG
Type) command with an interface of type LAG. This interacts with the Admin and Operational state, as described below.
Note:
In previous releases, the MODE=ON/OFF parameter as part of SET LAG was used.
4.2.4.2 LAG Admin State
The LAG has an Admin state similar to other interfaces; LAG will support an admin state of "enabled" (UP) and "disabled"
(DN), as specified by ENABLE INTERFACE (for LAG Type) or DISABLE INTERFACE (for LAG Type)
Enabling a LAG allows the LAG's administratively enabled ports to attempt to achieve the UP operational state. All LAG
member ports that are able to achieve a state of UP-UP-Online will be aggregated together in hardware and are capable of
carrying traffic. If all of the ports go UP, then the LAG will go UP-UP-Online. But if there is a mix of UP and DN enabled
links, the LAG will be UP-UP-Degraded, since the bandwidth is less than what the user configured.
Disabling a LAG administratively results in all member ports being disabled operationally. The member links' states will
become UP-DN-AutoDisabled. (This is similar to how ports are operationally disabled for the BPDU COP feature.) When all
provisioned LAG member ports transition to UP-DN-AutoDisabled, the resulting LAG state will be DN-DN-Offline. Note
that disabling the LAG does not change the administrative state of the member interfaces, since it could result in losing the
user-configured administrative state if the LAG were to be administratively re-enabled.
Provisioned LAG member ports can still be enabled/disabled individually via the CLI. In the event that all provisioned member ports of a given LAG are disabled administratively, and their operational state follows (to DN), the LAG containing these
331
Layer Two Switching
ports will also have a DN operational state. The difference in this case is that the LAG state would show UP-DN-Dependency, since the admin state for the LAG itself was never disabled.
The default administrative state for a LAG is disabled (DN).
4.2.4.3 Adding/Deleting Ports and Ethernet (Q-Bridge Port) Attributes to LAG
The following Q-Bridge Port parameters provide LAGs with the same characteristics as Ethernet interfaces in the system:
•
•
•
•
•
Acceptable Frame Types - accept ALL, VLAN, or HVLAN frame types
Ingress Filtering Enabled - filtering ON or OFF
TPID - value of Tag Protocol ID (0x0000..0xFFFF) - 0x8100
TAGALL - double-tagging ON or OFF
Learn Limit - Dynamic MAC Learn Limit OFF or 1..64
When the LAG is initially created (CREATE LAG INTERFACE), it inherits the Q-Bridge Port settings of the first member port
specified. All candidate LAG member ports must have the same Q-Bridge Port settings to be successfully added to the LAG.
This will provide LAGs with the same characteristics as Ethernet interfaces in the system.
Therefore, when an interface is provisioned to be a LAG member port, all Q-Bridge Port attributes must match that of the
LAG. If they do not match, the user must use the appropriate SET INTERFACE (For lag type) parameters to change the
interface's settings and then attempt to add the interface to the LAG again. (Attributes can be queried via SHOW INTERFACE (for LAG Type) and SHOW LAG commands.)
Note:
The user cannot set these attributes directly on the LAG using the SET LAG command. The SET INTERFACE (For
lag type) command must be used.
When a LAG member port is deleted from a LAG via DELETE LAG INTERFACE command (see the next section), it will
retain the Q-Bridge Port settings that it shared with the LAG. Once deleted from the LAG, the user may change the settings
using the SET INTERFACE (For lag type) command. If the user attempts to change Q-Bridge Port settings on an interface
that is currently a LAG member port, the command will fail with an error.
4.2.4.4 Deleting LAG Member Ports
Prior to Release 16.0, it was possible to remove a member port from a LAG, regardless of its administrative or operational
state. This could result in a loop condition, since all LAG member ports must terminate at the same two endpoints (by definition). The LAG member ports must now be administratively disabled (and thus driving its operational state to disabled)
prior to being deleted from a LAG. This can be accomplished one of two ways.
• Disable the port using the DISABLE INTERFACE command, prior to issuing the DELETE LAG INTERFACEcommand.
• Issue the DELETE LAG INTERFACE command, and if the interface being deleted is UP-UP-Online, the user is informed
the interface will automatically be disabled (admin=DN, oper=DN). The user can accept this auto-disable, after which
the interface will be deleted from the LAG. If the user rejects the auto-disable, the interface will remain UP-UP-Online
and the DELETE LAG command will not complete and there will be an error message..
Either of these methods will prevent potential loop conditions.
4.2.4.5 Destroying a LAG
All link members must be disabled before or during the destruction of a LAG to prevent loops in the network. The user may
first disable the link members and then destroy the LAG, or the user can just destroy the LAG and the system will ask permission to disable the link members as part of the destroy operation. The user can use the FORCE option to skip the
request for permission.
332
Layer Two Switching
4.2.4.6 Summary of Administrative and Operational Status
The following table summarizes the releationship of the Admin and Operational Status over member ports.
TABLE 4-3
Relation of Administrative and Operational States for LAG
State
Interface
Admin State
Operational
State
Admin State of
LAG is DN
LAG:1
DN
DN
1.0
Don’t care
DN
1.1
Don’t care
DN
3.0
Don’t care
DN
Operational
state of all member ports is DN
LAG to attain
Operational status of UP
LAG:1
Don’t care
DN
1.0
Don’t care
DN
1.1
Don’t care
DN
3.0
Don’t care
DN
LAG:1
UP
UP
1.0
UP
UP
1.1
Don’t care
Don’t care
3.0
Don’t care
Don’t care
Notes
Regardless of the state of member ports, if the Admin
state of the LAG is Down, the Member Port Operational states are driven to Down and the LAG Operational state is also Down.
Regardless of Admin state of LAG and Member Ports,
if the Oper state of ALL Member Ports is Down, the
LAG Oper state is driven to Down.
Note that if the Admin state of all Member Ports is
DOWN, this effectively drives LAG Oper state to
DOWN.
For a LAG to attain UP Operational state, the LAG
Admin state must be UP, and ONE OR MORE Member Ports must also have UP Admin state AND Operational state.
4.2.4.7 Setting of ADMINKEY as Unique Identifier
In previous releases, the LAG’s unique ID was created by the system in the order of creation, starting with LAG:0. In release
16.0, the ADMINKEY (part of CREATE LAG INTERFACE) can be used as the unique identifier, so the LAG ID does not need
to follow the order of creation. Since the identifier is now LAG:x , where x is the Admin Key rather than that previous 1-up
number, some numeric identifiers may change over an upgrade.
4.2.5 Alarms for LAG States
Previously, there were no alarms raised against LAGs. In release 16.0, there are alarms for failed or degraded LAG operational states. In release 16.0 the following interface alarms will now be supported for LAG interfaces in a similar manner to
other interfaces.
Note:
Refer to the Log Reference Manual for a listing of all log messages and maintenance actions.
4.2.5.1 LAG Alarms
• "All Parents Non-Administratively Down" - (INTF001) - This indicates that all the administratively enabled member ports
in a LAG are currently failed (indicating that loss-of-link, or some other failure has occurred on all enabled member ports)
and the LAG itself has an UP administrative state (indicating that the LAG should be enabled and carrying traffic if possible). Under these conditions the LAG will have a state of UP-DN-Failed.
This alarm is cleared by the following:
• One or more member ports achieve the UP-UP-Online state.
• Administratively disabling the LAG, resulting in a DN-DN-Offline state for the LAG.
333
Layer Two Switching
• Administratively disabling all the member ports, resulting in a UP-DN-Dependency state for the LAG.
• "Bandwidth Degraded" - (INTF003) - indicates that one or more enabled LAG member ports are currently DOWN operationally, with one or more LAG member ports still currently UP operationally. This alarm is used to inform the user that
the LAG is currently not capable of carrying the maximum bandwidth that would be available if all enabled member ports
were UP-UP-Online. Under these conditions the LAG will have a state of UP-UP-Degraded.
This alarm is cleared by the following:
• All member ports achieve the UP-UP-Online state.
• Administratively disabling the LAG, resulting in a DN-DN-Offline state for the LAG
• Administratively disabling all the member ports, resulting in a UP-DN-Dependency state for the LAG.
4.2.5.2 Port Alarms (PORT003)
Two port alarms help the user understand the LAG state:
• "No LACP Sync" alarm - will be raised against a dynamic LAG member port that is up enough to pass LACPDU packets
but has not yet achieved sync with the partner.
• "Link Attribute Mismatch" alarm - will be raised against a static or dynamic LAG member port that does not match the
operational physical attributes (speed or duplex settings) of the links already in the LAG.
These alarms can be cleared by disabling the port or ensuring the link negotiates to the same value as the LAG.
4.2.6 Setting the Switch Hash Select
The hash select can be set at any time and persists across system or card reboots. When new LAGs are created, their hash
select will be determined by the switch-wide hash select setting. The SHOW SWITCH command can be used to view the
configured hash select.
Using this SBx3112-specific command SET SWITCH HASH SELECT the user controls the global hash selection setting. The
SHOW SWITCH command includes a field to display the current hash selection setting, and the SHOW LAG command uses
the existing “Select Criteria” field to show the current hash selection setting.
show switch
--- Switch Configuration ------------------Learning..............................
Ageing Timer..........................
Ageingtimer...........................
Number of HVLAN.......................
Hash Select ..........................
On
On
300
Off
165
35
2
125
2
ALL
--------------------------------------------
334
Layer Two Switching
4.2.7 Configuring LAG
When an SBx3100 switch is initially booted up, LAG is configured as follows:
• There are no LAGs configured. (‘No LAGs currently exist’)
4.2.7.2 Basic Configuration Steps
Following is the hierarchy of steps for configuring a LAG:
1.
Create the LAG (CREATE LAG iNTERFACE)
• This creates the LAG and must include at least one interface
• The first interface in the command has the Q-settings that apply to all interfaces on the LAG
• If the default settings are OK, all interfaces are included, and all interfaces are enabled, the user can go to Step 5.
2.
Ensure all interfaces share same settings (SET INTERFACE)
• These are the attributes for the ethernet interface (VLAN configuration, speed, duplex, autonegotation, direction)
• To change a setting, the interface must be disabled, the attributes changed, and then enabled.
3.
Ensure all interfaces have same Q-BRIDGE settings (SET INTERFACE for LAG)
• These are the attributes for the LAG that enable it to have an Ethernet interface.
• To change a setting, the interface must be disabled, the attributes changed, and then enabled.
4.
Add interfaces to the LAG
• All interfaces must have the same settings.
• If any attribute does not match, there is an errored response.
5.
Enable the LAG (ENABLE INTERFACE for LAG) to give the LAG an Admin state of UP.
• All ports must be enabled.
• The first port to go up (selected with the CREATE LAG command), determines the interface and LAG ethernet settings
• When more than one port is UP, the LAG goes to state UP-UP with as status of Online (all links up) or Degraded.
Following is the hierarchy of steps for taking down a LAG:
1.
Disable the LAG to set the LAG to an ADMIN state of DOWN
• Each port goes to state UP-DOWN-AutoDisabled
• When all ports are set to UP-DOWN-AutoDisabled, LAG goes to state DN-DN-OFFLINE.
2.
Disable all of the member ports to set their Admin State to DOWN.
3.
Delete the LAG member ports from the LAG
4.
Destroy the LAG.
Note:
In practice, the user can input DESTROY LAG <lag_name> FORCE and the LAG is deleted.
4.2.7.3 Setting the VLANs in the LAG in UFO Mode
The steps to include a VLAN in UFO mode are similar to the steps in 4.2.7.2, as in this example for a static LAG.
1.
Make sure all interfaces to be used in the LAG share the same setting (as mentioned in step 2 in 4.2.7.2).
SET INTERFACE=(interface list), GE DIRECTION=NETWORK
335
Layer Two Switching
2.
Create the LAG(s), for example creating a PRIMARYUPSTREAM and SECONDARYUPSTREAM LAG for UFO setup.
CREATE LAG=primarylag1 INTERFACE=ETH:1.0-1.3,3.10-3.13 MODE=static ADMINKEY=10
CREATE LAG=secondarylag1
KEY=11
3.
INTERFACE=ETH:1.14-1.17,3.4-3.7 MODE=static ADMIN-
Create the UFO VLAN, setting it to UFO.
CREATE VLAN=v445 VID=445 FORWARDINGMODE=UPSTREAMONLY
4.
Add the UFO VLAN to the LAGs
ADD VLAN=445 INTERFACE= LAG:[10-11] FRAME=TAGGED
5.
Set the PRIMARYUPSTREAM and SECONDARYUPSTREAM on the appropriate LAG
SET VLAN=445 INTERFACE=LAG:[10] FORWARDING=PRIMARYUPSTREAM
SET VLAN=445 INTERFACE=LAG:[11] FORWARDING=SECONDARYUPSTREAM
336
Layer Two Switching
4.2.7.4 Configuration Guidelines (both Static and Dynamic)
Following is a summary of the provisioning rules to follow when creating LAG groups:
• The SBx3100 supports a maximum of 127 LAGs configured on the system at one time. A maximum of eight member
•
•
•
ports per LAG is supported.
When a LAG is first created, one or more member interfaces must be specified. The LAG will be initialized with the set
of physical and Ethernet Q-Bridge Port attributes associated with the first member port successfully added. Refer to
CREATE LAG INTERFACE.
Provisioning of individual Ethernet Q-Bridge Port attributes is not allowed if the interface belongs to a LAG. However,
these settings can be configured on the LAG itself, and all member ports will automatically be configured to share these
same settings.
A LAG member port must be disabled (using DISABLE INTERFACE command) before it can be removed from a LAG
(using DELETE LAG INTERFACE command). This is to prevent loops in the network.
All ports in the LAG group must share the same untagged and tagged VLAN configuration.
•
• All physical attributes (speed, duplex, autonegotiate settings) of a LAG member port must be consistent with the LAG
when the links are configured into the LAG. This means that the link must have the potential to operate at the LAG's settings. A setting of "auto-negotiation" along with any speed is therefore allowed, but (for example) links configured for
fixed speeds of 100M and 1G in the same LAG is not allowed. Also, duplex setting to half-duplex on any link in the LAG
is not allowed.
The “LAG speed” is determined by the speed of the first port added to the LAG. If the user tries to add a second interface with a different speed, there will be a “port speed does not match LAG speed” error message.
• A LAG can be administratively disabled. Disabling a LAG adds an "AutoDisabled" secondary state to member ports. Any
ports that were UP-UP-Online become UP-DN-AutoDisabled. Any ports that are operationally down (due to failure or
admin action) remain in that state since the port's own reason for being down takes precedence over the influence of the
aggregate.
• A LAG can be administratively enabled. Enabling a LAG removes member ports' "AutoDisabled" secondary states. If one
or more member ports are able to attain the UP-UP-Online state, the LAG will be considered operationally UP.
• The LAG group has an Operational State. An Operational State of UP means the LAG group has been provisioned and
one or more ports are in an Operational State of UP.
• A maximum of 8 ports can be provisioned in a single LAG.
Following are restrictions for LAG in general:
•
•
•
•
•
•
•
Ports cannot have egress rate limiting configured.
Ports cannot have a traffic descriptor configured.
Once an interface belongs to a LAG group, changing individual interface attributes is not allowed using the LAG interface.
All ports must have the same Classifier configuration.
The port direction must match that of the lag, as determined by the first port added to the LAG.
Aggregations between more than two systems in a single LAG are not allowed.
Link Aggregation is supported only on point-to-point links with MACs operating in full duplex mode
4.2.7.6 Feature Interactions
• UFO mode is supported on a LAG interface. The product supports 16 UFO VLANs.
• Other features, such as VLAN and STP, can be configured against the lag-id or LAG interface ID.
337
Layer Two Switching
• LAG and (R)STP are compatible; a LAG can be created (or interfaces added to a LAG) regardless of the STP state. Also,
STP can be disabled/enabled on an interface regardless of whether the interface is in a LAG or not.
4.2.7.7 Configuration Procedure - Creating a Dynamic LAG
The following table shows the configuration hierachy to follow to ensure that a LAG is configured correctly, as well as deconfigured.
The following procedure shows the commands used to create the LAG
TABLE 4-4
Step
Configuration Procedure for Creating a Cross-Card LAG - Static
Command
Description/Notes
Ensure that physical interfaces that you wish to combine into a LAG have matching provisioning attributes (e.g., VLAN
configuration, speed, duplex, auto-negotiation, direction, Q-settings, etc.)
Create the LAG, including the interfaces and ensuring the mode is dynamic
1
create lag main int 1.3,2.2-2.3,9.1-9.5 mode=dynamic
Enable the interfaces, including the lag ID
2
enable interface=1.3,2.2-2.3,9.1-9.5,main
Info (039512): Operation Successful (XE4 Slot
1 Port
3)
2 Port
2)
2 Port
3)
Info (039512): Operation Successful (XE6SFP Slot
9 Port
1)
9 Port
2)
9 Port
3)
9 Port
4)
9 Port
5)
Info (020184): Successfully enabled interface(s) main
Review the LAG for general attributes.
338
Layer Two Switching
TABLE 4-4
Step
Command
Description/Notes
3
15:36:06 officer SEC>> sh lag main
--- LAG Info Data --MAC Address......................................... EC:CD:6D:4F:8F:F3
System Priority..................................... 65535
LAG Name............................................
Interface...........................................
State...............................................
Configured Interfaces ..............................
H/W Aggregated Interfaces...........................
Mode................................................
Select Criteria.....................................
Speed...............................................
Direction...........................................
Acceptable Frame Type...............................
Ingress Filtering ..................................
TPID................................................
TAGALL..............................................
Dynamic MAC Learning Limit..........................
Admin Key...........................................
main
LAG:2
UP-UP-Online
1.3,2.2-2.3,9.1-9.5
1.3,2.2-2.3,9.1-9.5
Dynamic
port both & ip both & mac both
80 Gbps
Network
VLAN
On
0x8100
Off
0
2
LACP Information
---------------Oper Key............................................
Individual..........................................
LACP Control Ready..................................
Partner LAG ........................................
Role ...............................................
2
No
Yes
0x19,00:0C:25:04:01:AC,0x1
Active
Member Interfaces
----------------LACP Port
Port
------ LACP
Machine
Interface Number
Priority
Rx
Periodic Tx
---------- ----------- -------------------------------ETH:1.3
260
32768
Current
Slow
ETH:2.2
515
32768
Current
Slow
ETH:2.3
516
32768
Current
Slow
ETH:9.1
2306
32768
Current
Slow
ETH:9.2
2307
32768
Current
Slow
ETH:9.3
2308
32768
Current
Slow
ETH:9.4
2309
32768
Current
Slow
ETH:9.5
2310
32768
Current
Slow
States ---Mux
----------Collecting/
Distributing
Collecting/
Distributing
Collecting/
Distributing
Collecting/
Distributing
Collecting/
Distributing
Collecting/
Distributing
Collecting/
Distributing
Collecting/
Distributing
Review the LAG for interface attributes
339
Layer Two Switching
TABLE 4-4
Step
Command
4
15:36:09 officer SEC>> sh int main
Description/Notes
--- LAG Interfaces --Name...............................
State..............................
Description........................
Provisioned Ports..................
Enabled Ports......................
Mode...............................
Select Criteria....................
Speed..............................
Direction..........................
LAG:2
main
UP-UP-Online
<none>
1.3,2.2-2.3,9.1-9.5
1.3,2.2-2.3,9.1-9.5
Dynamic
80 Gbps
Network
VLAN Information
TPID............................
TAGALL..........................
Tagged VLAN(s)..................
VLAN-tagged only
On
0x8100
Off
0
10,415,420,512,2400-2407,3000,3002
The FDB should now display LAG as the interface.
5
show switch fdb
Slot
VLAN
Interface ID
MAC Address
Status
----------- ----------- --------------- ---------------------- -------2
402
2.0
00:00:CD:1D:C1:C2
Dynamic
2
402
2.0
00:00:CD:23:28:6F
Dynamic
2
402
2.0
00:04:13:36:66:4D
Dynamic
(output omitted)
1-2, 9
420
main (LAG:2)
00:0C:25:04:01:AC
Dynamic
(output omitted)
340
Layer Two Switching
4.2.8 Configuration Procedure - Destroying a LAG
To destroy a LAG, the user can perform these steps (the order of the first two steps is not important).
1.
Disable the LAG to set the LAG to an ADMIN state of DOWN
• Each port goes to state UP-DOWN-AutoDisabled
• When all ports are set to UP-DOWN-AutoDisabled, LAG goes to state DN-DN-OFFLINE.
2.
Disable all of the member ports to set their Admin State to DOWN.
3.
Destroy the LAG.
The following procedure shows the commands used to destroy the LAG.
Note:
Using the DESTROY command with with FORCE option destroys the LAG in one step.
TABLE 4-5
Step
Configuration Procedure for Destroying a LAG
Command
Description/Notes
Disable the LAG and its interfaces
1
disable interface 1.3,2.2-2.3,9.19.5,main
Disables the LAG and puts each port to UPDOWN-AutoDisabled.
Destroy the LAG
2
destroy lag main
Member port(s) will be automatically disabled, and service may be affected.
Do you still want to destroy the LAG (Y/N)? y
Verify that the LAG has been destroyed
3
show lag
--- LAG Info Data ----------------------------------------------------------------------LAG Name
Provisioned Ports
Mode
Select Criteria
Admin Key Index
------------------------------- --------------------------------------------------------LAG Name
Enabled Ports
Speed
Oper State
Dir
Interface ID
------------------------------- ----------------------------------------------------------
341
Layer Two Switching
4.2.9 LAG Commands
The following tables list the commands available to configure and manage LAG on the SBx3112 switch.
TABLE 4-6
LAG Commands
Commands
ADD LAG INTERFACE
CREATE LAG INTERFACE
DELETE LAG INTERFACE
DISABLE INTERFACE (for LAG Type)
ENABLE INTERFACE (for LAG Type)
DESTROY LAG
RESET LAG COUNTER
SET INTERFACE (For lag type)
SET LAG
SET SWITCH HASH SELECT
SHOW INTERFACE (for LAG Type)
SHOW LAG
The following table describes the global hash selection settings that are available with the SET SWITCH HASH SELECT command, and the corresponding display in the SHOW LAG command:
TABLE 4-7
SBx3112 - SET SWITCH HASH SELECT Parameters
Parameter
Value
LAG Hashing Behavior
MAC
macsrc & macdest
Hash based only on layer 2 source and destination MAC in packet
IP
ipsrc & ipdest
Hash based on layer 3 source and destination IP in packet. If layer 3 data
is not present in the packet, hash based on layer 2 source and destination
MAC
MACANDIP
ipboth & macboth
Hash based on both source and destination MAC and IP. If layer 3 data is
not present in the packet, hash based on layer 2 source and destination
MAC
IPANDPORT
portboth & ipboth
Hash based on both layer 4 source and destination port (UDP/TCP) and
layer 3 source and destination IP. If packet is not UDP/TCP, then hash
based on the IP addresses. If layer 3 data is not present in the packet,
hashed based on layer 2 source and destination MAC
ALL
portboth & ipboth &
macboth
Hash based on layer 4 source and destination port (UDP/TCP), layer 3
source and destination IP, and layer 2 source and destination MAC. If
packet is not UDP/TCP, then hash based on the IP addresses and MAC
addresses. If layer 3 data is not present in the packet, hashed based on
layer 2 source and destination MAC.
This is the default setting, to get the best randomization
342
Layer Two Switching
343
Layer Two Switching
ADD LAG INTERFACE
Syntax
ADD LAG={ lagname | type:id }
INTERFACE={ type:id-range | id-range | ifname-list }
Description
This command adds interfaces to a Link Aggregation Group (LAG). The LAG must already exist before
interfaces are assigned to it (see CREATE LAG INTERFACE).
All interfaces in a LAG must operate at the same speed, autonegotiate setting, and must be in full
duplex mode, but these settings do not have to match for configuring the member interface. All interfaces in the LAG must have the same VLAN configuration and Q-Bridge Port settings.
Once an interface is added to the LAG, Q-Bridge attributes are managed on the aggregate (i.e. the
LAG interface) rather than the individual link.
Mode
Manager
Options
Option
Description
Range
Default
Value
LAG
The lagname already created.
NA
NA
NA
NA
lagname – name of the LAG instance, as specified by
user via CREATE LAG INTERFACE command.
type:id - the type of interface (in this case LAG) and a
single interface identifier (id). This value is the one generated with the CREATE LAG INTERFACE command.
INTERFACE
A logical representation of one or more physical interfaces.
type:id-range - the type of interface (such as ETH) and
one or more interface identifiers (id-range).
id-range – one or more interface identifiers.
Refer to Configuration Guidelines (both Static and
Dynamic) for how all of the LAG commands work
together.
Release Note
NA
Note
Interfaces of type "LAG" cannot be added to a LAG (no support for combining LAGs).
Example
ADD LAG=test_lag
INTERFACE=ETH:0.1-0.3,1.0-1.3
344
Layer Two Switching
CREATE LAG INTERFACE
Syntax
CREATE LAG=lagname
[ MODE={ STATIC | DYNAMIC}] [ ROLE={ ACTIVE | PASSIVE }
[ ADMINKEY=1..1024 ]
]
Description
Creates a Link Aggregation Group (LAG). When a LAG is created, a unique name must be specified.
When the CREATE LAG INTERFACE command is processed and completes successfully, the user will
be informed of the auto-generated interface identifier. The lagname or the interface identifier can be
used for subsequent ADD, DELETE, DESTROY, DISABLE, ENABLE, SET, and SHOW LAG commands.
One or more interfaces that will comprise the LAG must be specified at LAG creation time. Additional interfaces can be added to the LAG at a later time via ADD LAG INTERFACE command.
Mode
Manager
Options
Option
LAG
Description
Range
Default
Value
A single LAG instance.
NA
NA
NA
NA
NA
STATIC
NA
ACTIVE
lagname – name given to the LAG.
INTERFACE
one or more interface identifiers (id-range)
id-range – one or more interface identifiers
MODE
The MODE parameter controls behavior of the LAG.
The modes are described as follows:
STATIC - specifies that the interfaces belonging to the
LAG do not have Link Aggregation Control Protocol
(LACP) running. For aggregation to work, the interfaces
in the LAG must be connected to interfaces in a LAG on
the far-end that is also in the STATIC mode. This is
"statically configured link ” configuration
DYNAMIC - specifies that the interfaces belonging to
the LAG will run Link Aggregation Control Protocol
(LACP). This is "dynamically configured link aggregation".
ROLE
The ROLE parameter controls the LACP behavior of the
LAG. This parameter is applicable only when LAG
MODE=DYNAMIC.
ACTIVE - causes ports in the LAG to initiate LACP
negotiation with the ports in the LAG it is connected to,
by sending LACP packets. This is "dynamically configured link aggregation".
PASSIVE - causes the ports in the LAG to respond to
LACP packets, but does not initiate LACP negotiation.
The ports will speak LACP only when spoken to. This is
"passive dynamically configured link aggregation".
345
Layer Two Switching
Option
Description
Range
Default
Value
ADMINKEY
The 802.3ad admin key value for the LAG. It is used to
identify specific groups of ports capable of aggregation.
A default value is set by the system if one is not specified. (If the user inputs ADMINKEY=3, for example, this
will give the LAG group the label LAG:3.)
1-1024
NA
Release Note
NA
Note
To run LACP between two systems, at least one of the systems must have ROLE set to ACTIVE.
Example
CREATE LAG=test_lag INTERFACE=0.0,0.1 MODE=DYNAMIC ROLE=PASSIVE
346
Layer Two Switching
DELETE LAG INTERFACE
Syntax
DELETE LAG={ lagname | type:id }
INTERFACE={ type:id-range | id-range | ifname-list | ALL }
[ FORCE ]
Description
Deletes one or more interfaces from a Link Aggregation Group (LAG).
Mode
Manager
Options
Option
Description
Range
Default
Value
LAG
NA
NA
NA
NA
NA
NA
INTERFACE
single interface identifier (id). Note that the interface
type and .
FORCE
Used to delete the member interface regardless of current state. If the interface is currently enabled, it will
automatically be set to a disabled administrative state
and deleted from the LAG.
Release Note
NA
Note
Any member interface being deleted from the LAG must be administratively disabled via DISABLE
INTERFACE command. Disabling the interface prevents loops in the network when the interface is
deleted from the LAG.
Example
DELETE LAG=test_lag
INTERFACE=1.0
347
Layer Two Switching
DESTROY LAG
Syntax
DESTROY LAG={ lagname | type:id } [ FORCE ]
Description
The DESTROY LAG command destroys a Link Aggregation Group (LAG). The LAG being destroyed
must be administratively disabled via DISABLE INTERFACE {type:id-range|id-range|ifname-list|ALL}
command, where type=LAG. Moreover, the link members are always disabled before being removed
from the LAG. It is not necessary to delete all interfaces from the LAG prior to destroying it, however,
the interface list and all associated LAG parameter settings are destroyed along with the LAG.
Mode
Manager
Options
Option
Description
Range
Default
Value
LAG
NA
NA
FORCE
The FORCE option may be used to destroy the LAG
regardless of current state. If the LAG is currently
enabled and the FORCE option is used, the LAG will
automatically be set to a disabled administrative state,
which results in all member interfaces being operationally disabled and deleted from the LAG.
NA
NA
Release Note
NA
Example
DESTROY LAG=test_lag
348
Layer Two Switching
DISABLE INTERFACE (FOR LAG TYPE)
Syntax
DISABLE INTERFACE {type:id-range|id-range|ifname-list|ALL}
Description
The DISABLE INTERFACE command results in operational state of all LAG member ports being set to
DOWN. This command can be invoked for an INTERFACE where TYPE=LAG and identified by IDRANGE. If ALL member ports attain a DN operational state, the LAG will attain DN-DN-Offline
operational state. If the DISABLE INTERFACE operation is successful, the "State" of the LAG will be
displayed as DN-DN-Offline in the SHOW LAG and SHOW INTERFACE command output.
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
NA
NA
type:id-range - the type of interface (LAG in this case)
and one or more interface identifiers (id-range).
ifname-list - list of interface names, if not numerical.
ALL – keyword for disabling all interfaces currently configured in the system.
Release Note
NA
Note
NA
Example
Refer to the following commands:
DISABLE INTERFACE=LAG:1
349
Layer Two Switching
ENABLE INTERFACE (FOR LAG TYPE)
Syntax
ENABLE INTERFACE {type:id-range|id-range|ifname-list|ALL}
Description
The ENABLE INTERFACE command results result in operational state of all LAG member ports being
set to UP (enabled). This command can be invoked for an INTERFACE where TYPE=LAG and identified by ID-RANGE. If one or more member Ports has Admin state set to UP, and is able to attain UPUP-Online operational state, the LAG will attain UP-UP-Online (if all links are up) or UP-UP-Degraded
(not all links up) operational state. Provisioned Ports with UP-UP-Online state will also appear in
Enabled Port list, indicating that the port is participating in LAG. If the ENABLE INTERFACE operation
is successful, the "State" of the LAG will be displayed as UP-UP-Online in the SHOW LAG and SHOW
INTERFACE command output.
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
NA
NA
ALL – keyword for disabling all interfaces currently configured in the system.
Release Note
NA
Note
NA
Example
ENABLE INTERFACE=LAG:1
350
Layer Two Switching
RESET LAG COUNTER
Syntax
RESET LAG={ lagname | type:id-range | ifname-list | ALL } COUNTER
Description
The RESET LAG COUNTER command clears all LACPDU count information pertaining to Link
Aggregation Groups (LAGs) configured on the system. LACP statistics for individual LAGs are cleared
by specifying a valid lagname, type:id-range, or comma-separated list of interface names. If a valid lagname is not known, or if statistic for all LAGs is to be reset, use the ALL keyword to reset LACP statistics for all configured LAGs. If a lagname, type:id-range, comma-separated list of interface names, or
ALL keyword is not specified, the statistic cleared will be that of RESET LAG ALL COUNTER.
Mode
Manager
Options
Option
Description
Range
Default
Value
LAG
One or more LAG instances.
NA
NA
user via CREATE LAG command.
type:id-range - the type of interface (in this case LAG)
and one or more interface identifier (id-range).
ALL – keyword for showing data for all LAGs currently
configured in the system.
Release Note
NA
Example
RESET LAG=test_lag
COUNTER
351
Layer Two Switching
SET INTERFACE (FOR LAG TYPE)
Syntax
SET INTERFACE {type:id-range|id-range|ifname-list|ALL}
[ACCEPTABLE=(VLAN|HVLAN|ALL)]
[INFILTERING=(OFF|ON)]
[TPID=0x000..0xFFFF]
[TAGALL=(OFF|ON)]
[LEARNLIMIT=(OFF|1..64)]
Description
The SET INTERFACE command modifies the provisioning attributes for the specified interface or list
of interfaces. (In command responses these are the Q-bridge attributes.)
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
NA
NA
ALL – keyword for enableing all interfaces currently
configured in the system.
ACCEPTABLE
Parameter specifies the Acceptable Frame Types –
accept ALL, VLAN, or HVLAN frame types.
NA
ALL
INFILTERING
Parameter specifies if Ingress Filtering is Enabled – filtering ON or OFF
NA
ON
TPID
Parameter contains the value of Tag Protocol ID, which
is specified as a 4-digit hex value.
(0x0000..0x
FFFF)
0x8100
TAGALL
Parameter controls whether double-tagging is enabled
or not.
ON,OFF
OFF
LEARNLIMIT
Parameter specifies the number of dynamic MAC
addresses that can be learned.
OFF, 1-64
OFF
Release Note
NA
Note
DIRECTION is for a future release.
Example
SET INTERFACE=LAG:1 TPID=0x5000 LEARNLIMIT=ON
352
Layer Two Switching
SET LAG
Syntax
SET LAG {
= { lagname | type:id }
{ROLE= PASSIVE | ACTIVE}
and
SET LAG
{INTERFACE= { type:id-range | id-range | ifname-list | ALL }
[LACPINTERFACEPRIORITY={ 1..65535 }
]
[LACPTIMEOUT={ SHORT | LONG }
]
| [LACPSYSTEMPRIORITY=={ 1..65535 }]
}
Description
The SET LAG command modifies an existing Link Aggregation Group (LAG). This command can be
used to change the ROLE setting on the LAG or the LACP System Priority and LACP Timeout values
for LAG member interfaces. If a user desires to change the set of interfaces comprising the LAG, the
ADD LAG INTERFACE and DELETE LAG INTERFACE commands must be used. Once the LAG is
created, it is not possible to change the LAG name, ADMINKEY or MODE setting.
Mode
Manager
Options
Option
Description
Range
Default
Value
LAG
NA
NA
1-65535
NA
single interface identifier (id).
ROLE
The ROLE parameter controls the LACP behavior of the
LAG. This parameter is applicable only when LAG
MODE=DYNAMIC.
ACTIVE - causes ports in the LAG to initiate LACP
negotiation with the ports in the LAG it is connected to,
by sending LACP packets. This is "dynamically configured link aggregation".
PASSIVE - causes the ports in the LAG to respond to
LACP packets, but does not initiate LACP negotiation.
The ports will speak LACP only when spoken to. This is
"passive dynamically configured link.”
INTERFACE
one or more interface identifiers (id-range).
ALL – keyword for deleting all interfaces currently configured in the LAG.
LACPINTERFACEPRIORITY
The LACP Interface Priority setting.
Interface Priority is used by LACP to determine which
interfaces to aggregate. . Interfaces with lower numerical value of INTERFACEPRIORITY have higher priority
and are selected first.
353
Layer Two Switching
Option
Description
Range
Default
Value
LACPTIMEOUT
The LACP Timeout setting for an interface.
NA
NA
1-65535
NA
Timeout is used by LACP to inform LACP partner on
far-end the rate at which it would like to receive LACP
updates.
SHORT - corresponds to preference to receive updates
once every 1 second.
LONG - corresponds to preference to receive updates
once every 30 seconds.
LACPSYSTEMPRIORITY
The LACP System Priority setting.
System Priority is used to help resolve conflicts in
choice of aggregation groups. The system with the
lower numerical value of SYSTEMPRIORITY has higher
priority.
Release Note
NA
Note
NA
Example
SET
SET
SET
SET
LAG=test_lag ROLE=ACTIVE
LAG INTERFACE 1.0 LACPINTERFACEPRIORITY=5000
LAG INTERFACE 2.0 LACPTIMEOUT=LONG
LAG LACPSYSTEMPRIORITY=10000
LACPTIMEOUT=SHORT
354
Layer Two Switching
Syntax
SET SWITCH HASH
SELECT={ MAC | IP | MACANDIP | IPANDPORT | ALL }
Description
This command applies to the SBx3112, and controls the global hash selection setting. The SHOW
SWITCH command includes a new field to display the current hash selection setting, and the SHOW
LAG command uses the existing “Select Criteria” field to show the current hash selection setting.
Mode
Manager
Options
Release Note
Example
Option
Description
Range
Default
Value
SELECT
Refer to Table 4-7.
NA
NA
NA
SET SWITCH HASH SELECT=MAC
355
Layer Two Switching
SHOW INTERFACE (FOR LAG TYPE)
Syntax
SHOW INTERFACE [{type:id-range|id-range|ifname-list|ALL}] [FULL]
Description
The SHOW INTERFACE command displays information pertaining to LAG type interfaces.
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
NA
ALL
NA
NA
ALL – keyword for showing all interfaces currently configured in the system.
FULL
Release Note
Example
Keyword to display all available information for one or
more interfaces.
NA
show interface
(other output omitted)
--- LAG Interfaces --Interface
State Name
--------------- ----- ---------LAG:1
UP-DN testLag
Show intrface lag:1 full
--- LAG Interfaces --Interface..........................
Name...............................
State..............................
Description........................
Provisioned Ports..................
Enabled Ports......................
Mode...............................
Select Criteria....................
Speed..............................
Direction..........................
LAG:1
main
UP-DN-Dependency
<none>
3.1-3.2,7.0-7.5
None
Dynamic
No ports in this Gb LAG
Network
VLAN Information
TPID............................
TAGALL..........................
VLAN-tagged only
On
0x8100
Off
0
356
Layer Two Switching
Tagged VLAN(s).................. 10,415,420,512,2400-2407,3000,3002
357
Layer Two Switching
SHOW LAG
Syntax
SHOW LAG [ = { lagname | type:id-range | ifname-list | ALL }
[ INTERFACE= { type:id-range | id-range | ifname-list | ALL }
[ COUNTER ] ]
[ FULL ]
Description
The SHOW LAG command displays information pertaining to Link Aggregation Groups (LAGs) configured on the system.
]
Individual LAGs can be displayed by specifying a valid lagname, type:id-range, or comma-separated list
of interface names. If a valid lagname is not known, or if information for all LAGs is desired, use the
ALL keyword to display all configured LAGs.
If a lagname, type:id-range, comma-separated list of interface names, or ALL keyword is not specified,
the output displayed will be that of SHOW LAG ALL. If the INTERFACE keyword is specified, the
SHOW command displays LACP information pertaining to Link Aggregation (LAG) member interfaces.
LACP information for individual LAG member interfaces can be displayed by specifying one or more
interfaces. If a valid interface is not known, or if information for all interfaces is desired, use the ALL
keyword to display all configured LAG member interfaces.
If one or more LAG member interfaces are not specified, or ALL keyword is not specified, the output
displayed will be that of SHOW LAG INTERFACE ALL.
The system settings include the system MAC address and the LACPSYSTEMPRIORITY. The system
with the lower numerical value of LACPSYSTEMPRIORITY has higher priority. Supported values are [
1..65535].
Mode
User
Options
Option
Description
Range
Default
Value
LAG
One or more LAG instances.
ALL
ALL
ALL
ALL
NA
NA
lagname – name of the LAG instance, as specified by user via
CREATE LAG command.
type:id-range - the type of interface (in this case LAG) and one
or more interface identifier (id-range).
ALL – keyword for showing data for all LAGs currently configured in the system.
INTERFACE
type:id-range - the type of interface (such as ETH) and one or
more interface identifiers (id-range).
ALL – keyword to configure all interfaces with the specified
interface priority.
COUNTER
LACPDU count information pertaining to Link Aggregation
Groups (LAGs) configured on the system.
358
Layer Two Switching
Option
Description
Range
Default
Value
FULL
Keyword to display all available information for one or more
LAGs
NA
NA
Release Note
NA
Example
show lag
--- LAG Info Data ---
Name
--------test_lag
maple
jefferson
syrup
State
-------------------DN-DN-Offline
DN-DN-Offline
DN-DN-Offline
DN-DN-Offline
Interface
--------LAG:1
LAG:3
LAG:5
LAG:6
Mode
--------Dynamic
Dynamic
Dynamic
Dynamic
Config Ports
--------------3.1-3.2,7.0-7.5
11.4
10.0
11.5
officer SEC> show lag sfp
--- LAG Info Data --------------------------------------------------------------
--- LAG Info Data --MAC Address........................... 00:00:00:00:00:00
System Priority....................... 25
LAG Name..............................
Interface.............................
State.................................
Configured Interfaces ................
H/W Aggregated Interfaces.............
Mode..................................
Select Criteria.......................
Speed.................................
Direction.............................
Acceptable Frame Type.................
Ingress Filtering ....................
TPID..................................
TAGALL................................
Dynamic MAC Learning Limit............
Admin Key.............................
sfp
LAG:1
DN-DN-Offline
3.1-3.2,7.0-7.5
None
Dynamic
No ports in this Gb LAG
Network
VLAN
On
0x8100
Off
0
1
LACP Information
---------------Oper Key..............................
Individual............................
LACP Control Ready....................
Partner LAG ..........................
Role .................................
0
Yes
No
0x0,00:00:00:00:00:00,0x0
Active
359
Layer Two Switching
Member Interfaces
-----------------
Interface
----------ETH:3.1
ETH:3.2
ETH:7.0
ETH:7.1
ETH:7.2
ETH:7.3
ETH:7.4
ETH:7.5
LACP Port
Number
----------0
0
0
0
0
0
0
0
Port
Priority
----------32768
32768
32768
32768
32768
32768
32768
32768
------- LACP
Rx
----------Undefined
Undefined
Undefined
Undefined
Undefined
Undefined
Undefined
Undefined
Machine
Periodic Tx
----------Unknown
Unknown
Unknown
Unknown
Unknown
Unknown
Unknown
Unknown
States -Mux
--------Undefined
Undefined
Undefined
Undefined
Undefined
Undefined
Undefined
Undefined
officer SEC>> show lag test_lag counter
--- LACP Counter Data ------- LACPDUs ----- ----- Marker ------ - PDU/Mrk Errors -Interface
Sent
Received
Sent
Received
Sent
Received
--------- --------- --------- --------- --------- --------- --------ETH:3.1
0
0
0
0
0
0
ETH:3.2
0
0
0
0
0
0
ETH:7.0
0
0
0
0
0
0
ETH:7.1
0
0
0
0
0
0
ETH:7.2
0
0
0
0
0
0
ETH:7.3
0
0
0
0
0
0
ETH:7.4
0
0
0
0
0
0
ETH:7.5
0
0
0
0
0
0
360
Layer Two Switching
4.3 VLAN (802.3)
4.3.1 Introduction
A VLAN is a virtual subnetwork that allows devices to be grouped into one logical broadcast domain. This allows broadcasts
from one VLAN to be sent only to members on the same VLAN.
4.3.2 Virtual LANs (VLANs)
4.3.2.1 VLAN Tagging
An Ethernet packet can contain a VLAN tag, with fields that specify VLAN membership (the VLAN ID or VID) and user priority. The VLAN tag is described in IEEE Standard 802.3ac, and is four octets that can be inserted between the Source Address
and the Type/Length fields in the Ethernet packet. To accommodate the tag, Standard 802.3ac also increased the maximum
allowable length for an Ethernet frame to 1522 octets (the minimum size is 64 octets). IEEE Standard 802.1q specifies how
the data in the VLAN tag is used to switch frames. VLAN-aware devices are able to add the VLAN tag to the packet header.
VLAN-unaware devices cannot add or read the VLAN tag.
•
•
•
•
Ethernet packets which contain a VLAN tag are referred to as tagged frames.
Switch ports that transmit tagged frames are referred to as tagged ports.
Ethernet packets which do not contain the VLAN tag are referred to as untagged frames.
Switch ports that transmit untagged frames are referred to as untagged ports.
A VLAN can therefore consist of:
• A set of untagged ports, in which the ports receive and transmit untagged packets.
• A set of tagged ports, in which all ports for the VLAN transmit tagged frames
• A mixture of tagged and untagged ports, where on some ports the VLAN receives and transmits tagged frames and on
other ports the VLAN receives and transmits untagged frames.
The SBx3112 accepts VLAN tagged frames, and support the VLAN switching required by these tags. A network can contain
a mixture of VLAN aware devices and VLAN unaware devices (e.g., workstations and legacy switches that do not support
VLAN tagging). The SBx3112 can be configured to send VLAN-tagged or untagged frames on each port, depending on
whether or not the devices connected to the port are VLAN aware. By assigning a port to two different VLANs (one as an
untagged port and another as a tagged port), it is possible for the port to transmit both VLAN-tagged and untagged frames.
When VLAN membership is determined using VLAN tagging, switch ports and network resources can be used more efficiently, since a port can belong to several VLANs. Moreover, one port can be used to uplink (trunk) all VLAN traffic between
the SBx3112 and another VLAN-aware switch, since this port can be configured to include all VLANs on the SBx3112.
When devices cannot include VLAN tagging, the VLAN membership is determined by which port its packets arrive on; all
untagged traffic arriving on a certain port belongs to that VLAN.
4.3.2.2 Standard VLAN Configuration
Figure 4-2 shows a sample configuration for setting up a VLAN in STD mode. The following explanation is based on this figure.
When a standard VLAN is configured, the Forwarding Database and VLAN/port mappings are set as follows:
TABLE 4-8
FDB
Port Mapping
361
Layer Two Switching
TABLE 4-8
VID=5
MAC=00:50:94:31:33:00
8.4
VID=5
MAC=00:50:94:31:60:3D
9.8
When the Control Module receives the Source Address and VID, it performs two steps:
1.
Learning - The Source Address-VLAN ID pair are checked against the FDB, and if it is not there the values are added.
2.
Forwarding - The Destination Address is checked against the port mapping, and if the port mapping exists, it forwards the
data onto that port. Otherwise, it floods all ports for that VLAN.
SBx3112
Port 0.0
SBx3100
CM
Port to Port Forwarding
Slot 8
Slot 9
Port 4
MAC=00:50:94:31:33:00
VID=5
Port 8
VLAN=Marketing
MAC=00:50:94:31:60:3D
VID=5
Std_VLAN_Cnfg_3112
FIGURE 4-2
Standard VLAN Configuration in the SBx3112
4.3.2.3 MAC Address Limiting for an Interface
In setting the VLAN attributes for an interface or an interface list, the user can specify the maximum number of MAC addresses that can
be learned for an interface, or set the limit to OFF. This is useful in controlling how many MAC addresses can be learned against the customer interface.
Note:
A single MAC address learned against a specific VID counts as one against the learn limit.
4.3.2.4 Syntax for Adding a VLAN to an Ethernet Interface
Provisioning a VLAN with the various configurations is done by ADDing the VLAN (or set of VLANs) with the Ethernet
physical and virtual interfaces that are associated with the configuration interface. In most cases, the user will add a VLAN to
a single ethernet interface, and this is done in provisioning examples in this Guide. In some cases, however, the user may wish
to associate a VLAN with a set of virtual interfaces that reside on a set of physical interfaces. The syntax to support this is
as follows:
ADD VLAN <interface type>:slot.<interface range | list>
• The range is <number> - <higher number>
• A list is <number>,<higher number>,<higher number>,etc.
For example, with the command:
ADD VLAN=100 INTERFACE=ETH:[9.0-15],[11.0-23] FRAME=UNTAGGED
362
Layer Two Switching
This can be read from right to left to see how the syntax is used.
• VLAN 100 is being added to interfaces 0 through 23 on slot 11.
• VLAN 100 is also being added to interfaces 0 through 15 on slot 9.
This syntax is shown in the output of the SHOW VLAN command.
show vlan 100
--- VLAN Information ------------------------------------------------------------ VLAN Information ---------------------------------------Type..................................
Name..................................
Identifier............................
Status................................
Forwarding Mode.......................
IP module attached....................
Configured Untagged Interfaces
Downstream..........................
Downstream (restricted).............
Current Untagged Interfaces
Downstream..........................
Tagged Interfaces
Downstream..........................
VLAN Translation interfaces...........
MVR Receiver interfaces...............
Note:
VLAN
vlan10
10
Static
Standard
<none>
ETH:[10.1-23]/LAG:[5]
<none>
ETH:[10.1-23]/LAG:[5]
<none>
LAG:[1,7,1024]
<none>
<none>
<none>
This format is also used as part of the file created by the BACKUP CONFIG command and is displayed when using the
SHOW CONFIG command.
4.3.2.5 Syntax for Simultaneously Creating Multiple VLANs
It is possible to create multiple VLANs (at once) by specifying a range of VIDs rather than specifying a VLAN name in the
CREATE VLAN command:
CREATE VLAN VID {vid-range}
For n VIDs, the system will assign n VLAN names in the following format:
vlan<VID-1>
vlan<VID-2>
...
vlan<VID-n>
4.3.3 Configuring Standard VLANs
• As a default, there is one VLAN (VID 1), which cannot be created or destroyed.
• The default VLAN is associated with all Line Card interfaces and is in standard (non-UFO) mode.
• When creating a VLAN, its default forwarding mode is standard (non-UFO) and it is assigned to the default STP.
• When an interface is added to a VLAN, it has untagged framing as its default with no VLAN translation.
• The SBx3112 system supports up to 4094 VLANs and supports VLAN translation on all 4094 VLANs.
• Once an interface is added to a VLAN, it can only be associated with a single spanning tree.
• If adding interface that is part of a link aggregation group (LAG), all of the interfaces in the LAG must in the same VLAN.
363
Layer Two Switching
The following procedure shows the commands used to create a standard VLAN, add an interface, and destroy the VLAN.
TABLE 4-9
Step
Configuration Procedure for Creating a Standard VLAN
Command
Description/Notes
Create the VLAN
1
create vlan videoHD vid 4004 forwardingmode STD
Creates a new VLAN named “videoHD” with a
VID of 4004 that’s configured for standard
(STD) forwarding.
View information related to new VLAN
2
show vlan videoHD
--- VLAN Information ---------------------------------------------------------Forwarding Tagged Interfaces
Untagged Interfaces
Mode
--------------- ---- ---------- ---------------------- -----------------------
3
Name
VID
videoHD
4004 Standard
<none>
<none>
show vlan videoHD full
--- VLAN Information ---------------------------------------------------------Type..................................
Name..................................
Identifier............................
Status................................
Forwarding Mode.......................
Untagged Interfaces
Downstream..........................
Tagged Interfaces
Downstream..........................
VLAN
videoHD
4004
Static
Standard
<none>
<none>
<none>
<none>
<none>
<none>
Add an interface to the new VLAN
4
add vlan videoHD interface 0.23 frame
tagged
Adds interface 0.23 (configured for tagged framing) to the new VLAN.
Verify that interface has been added to VLAN
5
show vlan videoHD
--- VLAN Information ---------------------------------------------------------Name
VID
Forwarding Tagged Interfaces
Untagged Interfaces
Mode
--------------- ---- ---------- ---------------------- ----------------------videoHD
4004 Standard
ETH:[0.23]
<none>
364
Layer Two Switching
TABLE 4-9
Configuration Procedure for Creating a Standard VLAN
Step
Command
Description/Notes
6
show vlan videoHD full
--- VLAN Information ---------------------------------------------------------Type..................................
Name..................................
Identifier............................
Status................................
Forwarding Mode.......................
Untagged Interfaces
Downstream..........................
Tagged Interfaces
Downstream..........................
VLAN
videoHD
4004
Static
Standard
<none>
<none>
<none>
ETH:[0.23]
<none>
<none>
Destroy the VLAN. (Before a VLAN can be destroyed, all its associated interfaces must be deleted.)
7
delete vlan 4004 interface 0.23
Deletes interface 0.23 from VLAN 4004.
DESTROY VLAN=4004
Destroys VLAN 4004.
Verify that VLAN has been destroyed
8
SHOW VLAN=4004
--- VLAN Information ---------------------------------------------------------No information to display
The following procedure shows how to create several standard VLANs using a single command.
TABLE 4-10
Step
Configuration Procedure - Creating Multiple VLANs at Once
Command
Description/Notes
Create a series of VLANs. Rather than specifying the VLAN names. Specify a range of desired VIDs.
1
Creates a series of 10 VLAN with VIDs that
range from 3201 to 3210. The system sequentially assign names to the VLANs -- based on
the range of VIDs.
CREATE VLAN VID=3201-3210
View information related to the new VLANs
2
show vlan 3201-3210
--- VLAN Information ---------------------------------------------------------Name
VID Forwarding Tagged Interfaces
Untagged Interfaces
Mode
--------------- ---- ---------- ---------------------- ----------------------vlan3201
vlan3202
vlan3203
vlan3204
vlan3205
vlan3206
vlan3207
vlan3208
vlan3209
vlan3210
3201
3201
3203
3204
3205
3206
3207
3208
3209
3210
Standard
Standard
Standard
Standard
Standard
Standard
Standard
Standard
Standard
Standard
<none>
<none>
<none>
<none>
<none>
<none>
<none>
<none>
<none>
<none>
<none>
<none>
<none>
<none>
<none>
<none>
<none>
<none>
<none>
<none>
365
Layer Two Switching
366
Layer Two Switching
4.3.4 VLAN Commands
This subsection provides an alphabetical reference for commands used to configure VLANs.
TABLE 4-11
VLAN Commands
Commands
ADD VLAN INTERFACE
CREATE VLAN VID
DELETE VLAN INTERFACE
DESTROY VLAN
SET VLAN FORWARDINGMODE
SET VLAN INTERFACE
SHOW VLAN
367
Layer Two Switching
ADD VLAN INTERFACE
Syntax
ADD VLAN={ vlanname-list | vid-range }
[ FRAME={ UNTAGGED | TAGGED } ]
[ TRANSLATE={ 1..4094 | NONE } ]
[ FORWARDING={ PRIMARYUPSTREAM | SECONDARYUPSTREAM | DOWNSTREAM | RESTRICTED
| STP | UCP | EPSR } ]
[ MCASTSTATICROUTERPORT={ NO | IGMP | MLD | BOTH | YES } ]
Description
Associates a VLAN with a physical interface. When doing this, some restrictions must be considered.
Refer to 4.3.2.
For IGMP and MLD snooping, the command allows the interface to be configured as a static multicast
router port for the VLAN. If the "MCASTSTATICROUTERPORT" parameter is set to "NO", the interface will not be considered a static multicast router port on the VLAN for either IGMP or MLD (but
may still become a dynamic multicast router port). If it is set to "IGMP" or "MLD", the interface will be
considered a static multicast router port for the specified protocol. If it is set to "BOTH" or "YES" , the
interface will be considered a static multicast router port for both IGMP and MLD. By default, the
static multicast router port designation is set to "NO". Refer to IGMP and MLD Snooping.
Mode
Manager
Options
Option
Description
Range
Default Value
INTERFACE
Specifies the type of physical port. For a VLAN,
interfaces can have a type of ETH or LAG. The
LAG interface type can have more than one physical ports associated with it.
NA
NA
NA
UNTAGGED
NA
None
Interfaces can be queried by using 'type:id-range',
'name-list' or 'ALL' options. For example, 'ETH:2.0',
'ETH:2.1-2.4', where 2.0,2.1 etc. are the actual
physical ports and are used as the interface Id's in
this representation.
FRAME
Specifies whether a VLAN tag header is included in
each frame transmitted on the specified interfaces.
TAGGED - a VLAN tag is added to frames prior to
transmission. The interface is then called a tagged
interface for this VLAN.
UNTAGGED - the frame is transmitted without a
VLAN tag. The interface is then called an untagged
TRANSLATE
The VLAN identifier from which the VLAN is
translated.
368
Layer Two Switching
Option
Description
Range
Default Value
FORWARDING
The FORWARDING parameter is only applicable
when the VLAN is in UPSTREAMONLY forwarding
(UFO) mode. The interface’s role for VLAN can
be:
NA
Downstream
NA
NO
PRIMARYUPSTREAM - all frames that are received
on the other interfaces will be sent out this interface.
SECONDARYUPSTREAM - all frames that are
received on the other interfaces will be sent out
this interface if there is a fault with the PRIMARYUPSTREAM.
DOWNSTREAM - Only frames that are received
over the UPSTREAM interface may be switched to
the DOWNSTREAM interface.
STP - The Spanning Tree Protocol will dynamically
determine the upstream interface.
UCP - For the specified VLANs the UCP protocol
will determine the UPSTREAM interface dynamically.
EPSR - The VLAN(s) are part of an EPSR configuration and the EPSR protocol determines the
UPSTREAM interface.
MCASTSTATICROUTERPORT
For IGMP and MLD snooping, the command allows
the interface to be configured as a static multicast
router port for the VLAN.
If the “MCASTSTATICROUTERPORT” parameter
is set to “NO”, the interface will not be considered
a static multicast router port on the VLAN for
either IGMP or MLD (but may still become a
dynamic multicast router port).
If it is set to “IGMP” or “MLD”, the interface will
be considered a static multicast router port for the
specified protocol.
If it is set to “BOTH” or “YES” , the interface will
be considered a static multicast router port for
both IGMP and MLD. By default, the static multicast router port designation is set to “NO”. This
parameter is only valid on the SBx3100.
Release Note
Modified - This command has the option MCASTSTATICROUTERPORT added.
Example
ADD VLAN=6 INTERFACE=8.1 FRAME=TAGGED
369
Layer Two Switching
CREATE VLAN VID
Syntax
CREATE VLAN=vlanname VID=2..4094 [FORWARDINGMODE={STD|UPSTREAMONLY}]
Description
The CREATE VLAN command creates a Virtual LAN (VLAN) entry with a unique name and identifier
(VID). When a VLAN entry is created, it is assigned to the default STP. To change the VID of an existing VLAN, the VLAN must be removed with the DESTROY VLAN command and created again.
For the SBx3100, the user can configure up to 16 VLANs that are UFO, and these can be anywhere in
the 2-4094 range.
Mode
Manager
Options
Option
Description
Range
Default
Value
VLAN
The name for the VLAN.
NA
NA
VID
The ID number of the VLAN.
NA
NA
FORWARDINGMODE
STD - Traffic can be forwarded to either upstream
or downstream interfaces.
NA
STD
UPSTREAMONLY - Traffic can only be forwarded
to upstream interfaces.
Release Note
NA
Example
CREATE VLAN=videoHD vid=4004 FORWARDINGMODE=STD
370
Layer Two Switching
DELETE VLAN INTERFACE
Syntax
DELETE VLAN={ vlanname-list | vid-range } INTERFACE={ type:id-range | idrange | ifname-list | ALL }
Description
Removes the interface association from the specified Virtual LAN (VLAN). Once an untagged port is
disassociated with all user-defined VLANs, it is automatically added to the default VLAN (VID=1). A
user cannot remove the association between the default VLAN and an untagged port if the port has no
other HVLAN/VLAN associations.
Mode
Manager
Product
Options
Option
Description
Range
Default
Value
VLAN
A comma-delimited list of VLAN names or VLAN
number range (e.g., 4-6).
NA
NA
INTERFACE
The interface that is being disassociated with the
VLAN.
NA
NA
Release Note
NA
Example
DELETE VLAN=4004 INTERFACE=0.23
371
Layer Two Switching
DESTROY VLAN
Syntax
DESTROY VLAN={ vlanname-list | vid-range
Description
Destroys the specified Virtual LAN (VLAN) or all VLANs in the switch. The default VLAN (VID=1)
cannot be destroyed. If ALL is specified then all VLANs except the default VLAN are destroyed. A
VLAN cannot be destroyed if interfaces still belong to it.
Mode
Manager
| ALL }
Product
Options
Option
Description
Range
Default
Value
VLAN
NA
NA
Release Note
NA
Example
DESTROY VLAN=4004
372
Layer Two Switching
SET VLAN FORWARDINGMODE
Syntax
SET VLAN={ vlanname-list | vid-range } FORWARDINGMODE={ STD | UPSTREAMONLY }
Description
Changes the type of VLANs specified to either Standard or Upstream Forwarding Only (UFO). For
information on UFO VLANs refer to Upstream Forwarding Only (UFO) Mode.
Mode
Manager
Product
Options
Option
Description
Range
Default
Value
VLAN
NA
NA
FORWARDINGMODE
STANDARD - Traffic can be forwarded to either
upstream or downstream interfaces.
NA
NA
UPSTREAMONLY - Traffic can only be forwarded
to upstream interfaces.
Release Note
NA
Example
SET VLAN=4004 FORWARDINGMODE=UPSTREAMONLY
373
Layer Two Switching
SET VLAN INTERFACE
Syntax
SET VLAN={ vlanname-list | vid-range } INTERFACE={ type:id-range | id-range |
ifname-list | ALL } [ FRAME={ UNTAGGED | TAGGED } ] [ TRANSLATE={ 1..4094 |
NONE } ] [ FORWARDING={ PRIMARYUPSTREAM | SECONDARYUPSTREAM | DOWNSTREAM |
RESTRICTED | STP | UCP | EPSR } ]
[ MCASTSTATICROUTERPORT={ NO | IGMP | MLD | BOTH | YES } ]
Description
The SET VLAN INTERFACE command specifies:
- the framing type (tagged or untagged) on the interfaces in a Virtual LAN (VLAN)
- an interface's forwarding role for VLANs that are in UPSTREAMONLY forwarding mode
- the VLAN identifier from which the VLAN is to be translated.
For IGMP and MLD snooping, the command allows the interface to be configured as a static multicast
router port for the VLAN. The "MCASTSTATICROUTERPORT" parameter (for the SBx3100) behaves
in the same manner as in the ADD VLAN INTERFACE command.
Mode
Manager
Product
Options
Option
Description
Range
Default
Value
INTERFACE
Specifies the type of physical port. For a VLAN,
interfaces can have a type of ETH or LAG. The
LAG interface type can have more than one physical ports associated with it.
NA
NA
NA
NA
NA
NA
Interfaces can be queried by using 'type:id-range',
'name-list' or 'ALL' options. For example, 'ETH:2.0',
'ETH:2.1-2.4', where 2.0,2.1 etc. are the actual
physical ports and are used as the interface Id's in
this representation.
FRAME
Specifies whether a VLAN tag header is included in
each frame transmitted on the specified interfaces.
TAGGED - a VLAN tag is added to frames prior to
transmission. The interface is then called a tagged
UNTAGGED - the frame is transmitted without a
VLAN tag. The interface is then called an untagged
TRANSLATE
Specifies the VLAN identifier from which the
VLAN is translated.
374
Layer Two Switching
Option
Description
Range
Default
Value
FORWARDING
The FORWARDING parameter is only applicable
when the VLAN is in UPSTREAMONLY forwarding
(UFO) mode. The interface’s role for VLAN can
be:
NA
NA
NA
NO
PRIMARYUPSTREAM - all frames that are received
on the other interfaces will be sent out this interface.
SECONDARYUPSTREAM - all frames that are
received on the other interfaces will be sent out
this interface if there is a fault with the PRIMARYUPSTREAM.
DOWNSTREAM - Only frames that are received
over the UPSTREAM interface may be switched to
RESTRICTED - The VLAN cannot be used by all
interfaces at the same time.
STP - The Spanning Tree Protocol will dynamically
UCP - For the specified VLANs the UCP protocol
will determine the UPSTREAM interface dynamically regardless of the type of configuration.
EPSR - The VLAN(s) are part of an EPSR configuration.
MCASTSTATICROUTERPORT
For IGMP and MLD snooping, the command allows
the interface to be configured as a static multicast
router port for the VLAN. Refer to ADD VLAN
INTERFACE
Release Note
Modified - This command has the option MCASTSTATICROUTERPORT added.
Example
SET VLAN=600 INTERFACE=10.0
FORWARDING=PRIMARYUPSTREAM
375
Layer Two Switching
SHOW VLAN
Syntax
SHOW VLAN [ ={ vlanname-list | vid-range | ALL } ] [ FORWARDINGMODE={ STD |
UPSTREAMONLY | ALL } ] [ FULL ]
Description
Displays information about the specified Virtual LAN (VLAN). If no VLAN name or identifier is specified, then ALL is assumed. If ALL is used, a summary of all VLANs is presented.
Mode
Manager
Options
Option
Description
Range
Default
Value
VLAN
A comma-delimited list of VLAN names, the VLAN
number range (such as 4-6) or ALL
NA
ALL
FORWARDINGMODE
STD - displays VLANs that are forwarding traffic to
both upstream and downstream interfaces.
NA
ALL
NA
Summary output
UPSTREAMONLY - displays VLANs that are forwarding traffic to upstream interfaces only.
ALL - displays both STD and UPSTREAMONLY
VLANs.
FULL
Displays detailed information for each VLAN.
Release Note
Modified - The output is changed for Release 17.0
Note
For IGMP and MLD snooping, this command will also display any multicast router ports that have been
statically configured using the "MCASTSTATICROUTERPORT" parameter in the "ADD/SET VLAN
INTERFACE" commands. Refer to the example.
Example
SHOW VLAN=300
--- VLAN Information ------------------------------------------------Type..................................
Name..................................
Identifier............................
Status................................
Forwarding Mode.......................
Configured Untagged Interfaces
Downstream..........................
Current Untagged Interfaces
Downstream..........................
Tagged Interfaces
Downstream..........................
MVR Receiver interfaces...............
IGMP Static Router Port Interfaces....
MLD Static Router Port Interfaces.....
VLAN
vlan300
300
Static
Standard
<none>
ETH:[1.0-3],ETH:[7.0-23]
<none>
ETH:[1.0-3],ETH:[7.0-23]
<none>
<none>
<none>
<none>
<none>
ETH:[7.1-2]
ETH:[7.1-2]
376
Layer Two Switching
4.4 Spanning Tree Introduction: STP, RSTP, MSTP and BPDU Cop
This chapter describes and provides configuration procedures for:
• Spanning Tree Protocol (STP and RSTP)
• Multiple Spanning Tree Protocol (MSTP)
• BPDU COP
For detailed information about the commands used to configure spanning trees, see Spanning Tree Commands
4.4.1 Introduction
4.4.1.1 Spanning Tree Modes
STP can run in one of three modes: STP, RSTP or MSTP. A device running RSTP is compatible with other devices running STP;
a device running MSTP is compatible with other devices running RSTP or STP. By default, on a device in MSTP mode each
port automatically detects the mode of the device connected to it (MSTP, RSTP or STP), and responds in the appropriate
mode by sending messages (BPDUs) in the corresponding format. Ports on a device in RSTP mode can automatically detect
and respond to connected devices in RSTP and STP mode. Particular ports can also be forced to only operate in a particular
mode.
• STP
The Spanning Tree Protocol (STP) is the original protocol defined by IEEE standard 802.1D-1988. It creates a single spanning
tree over a network.
By default, STP is disabled on all interfaces.
• RSTP
Rapid Spanning Tree Protocol (RSTP) also creates a single spanning tree over a network. Compared with STP, RSTP provides
for more rapid convergence to an active spanning tree topology. RSTP is defined in IEEE standard 802.1D-2004.
By default, when STP is enabled, the system operates in RSTP mode.
• MSTP
The Multiple Spanning Tree Protocol (MSTP) addresses the limitations in the previous spanning tree protocols, STP and RSTP,
within networks that use multiple VLANs with topologies that employ alternative physical links. It supports multiple spanning
tree instances on any given link within a network, and supports large networks by grouping bridges into regions that appear
as a single bridge to other devices.
MSTP is defined in IEEE standard 802.1Q-2005. The protocol builds on, and remains compatible with, the previous IEEE standards defining STP and RSTP. (MSTP is provided in release 14.2.)
4.4.2 Overview of Spanning Trees
A Spanning Tree instance is a (named) logical representation of the underlying data structures and control mechanisms
that provide a simple, fully-connected active network topology for a set of bridges and the LANs that connect them in a network.
4.4.3 Spanning Tree Protocol (STP and RSTP)
The Spanning Tree Protocol (STP) makes it possible to automatically disable redundant paths in a network to avoid network
loops, and to re-enable them when it is necessary to maintain connectivity in the event of a fault in the network (such as the
failure of a link or a switch).
377
Layer Two Switching
The spanning tree algorithm prunes redundant paths from the topology (i.e. marking paths as unavailable so frames are not
transmitted over those paths). The resulting loop-free topology set of switches and active paths is called the logical spanning
tree.
A logical spanning tree has the following elements:
• Each switch in the extended LAN has a unique bridge ID. This is a combination of the a switch's priority component (a
value assigned by default or via manual configuration) and its the switch's MAC address.
• The switch with the numerically lowest bridge ID is considered the root bridge of the logical spanning tree.
• Each port on a switch has a unique port ID. This is a combination of the port's priority component (a value assigned by
default or via manual configuration) and an internally assigned, unique numeric location identifier local to the bridge.
• Each port connecting a switch to a LAN has an associated path cost. This is a value assigned by switch software as a
•
•
•
•
default based on port speed, or via manual user configuration, that provides an indication of the latency or resource consumption that would be encountered if a frame were to be transmitted on that port.
The root path cost for a particular path from a port, a LAN, or switch to the root bridge is the sum of the port path
costs incurred if a frame were to be transmitted on that path to the root bridge.
The root port of a switch is the port on the switch with the lowest root path cost. If two or more ports on a switch have
the same root path cost, the root port is the port with the numerically lowest port ID.
The designated bridge of a LAN is the switch on the LAN with the lowest root path cost. If two or more switches on
the LAN have the root path cost, the designated bridge is the switch with the lowest bridge ID.
A designated port of a switch is a port that connects a LAN to its designated bridge.
Note:
For the SBx3112, RSTP is the default STP setting.
4.4.3.1 Protocol Concepts
4.4.3.2 Protocol Communication
To ensure that the switches in the extended LAN agree about root bridge, root port, and designated bridge elections, they
must communicate information about bridge IDs and root path costs to other switches. This communication is accomplished
via the exchange of messages known as Configuration Bridge Protocol Data Units (BPDUs), also known as hello
messages.
There is also the need to communicate when changes occur in the network topology (e.g. link failure or a new bridge). This
type of communication is accomplished via the exchange of Topology Change Notification (TCN) BPDUs.
4.4.3.3 Spanning Tree Port States
An SBx3112 switch port that is participating in spanning tree operations can be in one of six states. A summary of the states
is provided in Table 4-12.
TABLE 4-12
Spanning Tree Port States
State
Meaning
Transition
Blocking
The port is disabled for receiving and transmitting normal traffic frames. It may receive
BPDU frames, but does not transmit them. It
does not add information about any MAC
address from either Received BPDUs to its
forwarding database
This is the initial state for each port.
The switch also places the ports into
his state to eliminate network loops,
or if its perception if the network
topology changes (new root port or
root bridge).
378
Layer Two Switching
TABLE 4-12
Spanning Tree Port States
State
Meaning
Transition
Listening
The port does not receive or transmit traffic
data frames.It may receive and transmit
BPDUs. It does not add information about
source MAC addresses from received BPDUs
to the forwarding database.
The switch places ports into this sate
if it is a candidate for participating in
the spanning tree topology.
Learning
The port does not receive or transmit traffic
data frames. It may receive and transmit
BPDUs. It adds source MAC address information from the BPDU to the forwarding database.
The switch places ports into this
state upon expiration of a forwarding
delay timer while in the listening
state, unless something has caused
the port to be placed in the blocking
state.
Forwarding
The normal state for a port. The port is
enabled and receiving and transmitting traffic
data frames as well as BPDUs, and is adding
source MAC address information for all
frames to the forwarding database.
state upon expiration of a forwarding
delay timer while in the learning
state, unless something has caused
the port to be placed in the blocking
state.
Disable
No BPDUs are received or transmitted on the
port
state based on manual actions.
Excluded
Port has been removed from STP operations.
When a port is originally designated
as taking part in STP, and is then
removed from STP, the port can have
a role of DESIGNATED and a state
of EXCLUDED.
Note:
For Rapid STP (explained in 4.4.3.5), the “blocking” and “listening” states shown above are combined into a single
“discarding” state
4.4.3.4 Convergence
The process by which the switches in the extended LAN come to agreement about the logical spanning tree topology is
known as convergence. This process includes several key steps:
• The switches set their ports to the listening state. They elect a root bridge by exchanging hello messages to determine
which switch has the lowest bridge ID.
• The root bridge initiates calculation of root path costs. Each switch uses information received from other switches, along
with its own port cost information, to compute its own root path cost. It forwards this cost information along to other
switches; eventually, the correct root path cost for every path in the extended LAN will be computed.
• Each switch elects a root port for that switch.
• The switches elect a designated bridge for each physical LAN, based on the root path cost for the switches
• Any port that is determined not to be a root port or a designated port is set to the blocking state.
• After the expiration of forwarding delay timers, every root port and designated port is set to the forwarding state. Once
this is done, traffic may flow over the extended LAN, without any network loops being present.
If a link or switch fails, or the network topology otherwise changes, the network starts the convergence process again to
reach a new spanning tree topology.
379
Layer Two Switching
4.4.3.5 Rapid Spanning Tree (RSTP)
In the 802.1d Spanning Tree Algorithm and Protocol, timer driven processing controls how each port goes through the STP
state transitions before be placed into a “forwarding” mode where normal traffic flow is supported. In the Rapid Spanning
Tree Algorithm and Protocol (RSTP), significant time savings are accomplished using rapid STP port state transitions in many
of the expected network topology change scenarios. The time savings is accomplished through additional information
exchange and new “hand shake” processing between the ports of LAN connected bridges. The concept of a point-to-point
connection is introduced to identify when a port is connected to exactly one other bridge. This condition must exist for
some of the above mentioned rapid state transitions to take place. The concept of edge ports is also introduced to completely
bypass the state transition process when a port is known to be connected to a single host.
The parameters that are associated with RSTP are included below.
4.4.3.6 Spanning Tree Parameters
The following subsection provides an overview of parameters that are of particular importance in setting up a configuration.
4.4.3.7 Bridge Priority
Bridge IDs are used in root bridge elections. The root bridge is the switch in the extended LAN with the numerically lowest
bridge ID value. This is guaranteed to identify a single bridge due to the unique MAC address component. The user is allowed
to change the bridge priority component to override the arbitrary root selection that will result from only comparing MAC
addresses when the default bridge priorities are in use.
Bridge IDs are also used in designated bridge elections. Normally the switch with the lowest root path cost is the designated
bridge for a physical LAN. If more than one switch ties has the same lowest root path cost, then the designated bridge is the
switch with the numerically lowest numbered bridge priority ID value.
The value of the PRIORITY parameter is used to set the writable portion of the bridge ID. The default bridge priority is
32768. To change the STP priority value, use the SET STP PRIORITY command
Note:
The range is from 0 to 65535 (a limitation of RSTP) in increments of 4096.
4.4.3.8 Port Priority
Port IDs are used in root port elections. Normally, the port with the lowest root path cost is the root port for the switch. If
more than one port ties for the lowest root path cost, then the root port is the port with the lowest numerical port ID (as
assigned by the system).
The default port priority value is 128. The port priority values can be configured on a per-port basis, as a value from zero to
240, in accordance with IEEE Std 802.1d, 1998 Edition. However, the storage space (number of bits) allocated to the priority
component of the port ID is reduced to support bridges with larger numbers of ports, since this only left room for port
numbers from 1-255.
Note:
To maintain compatibility for comparison with previous versions of STP, the port priority is now considered to be a
value between 0-240 that can only be provisioned in increments of 16.
4.4.3.9 Interface Path Costs
Interlace path costs are used in root path cost calculations, which are a factor in root interface and designated bridge elections. By default, interface path costs are related to the bandwidth capacity of the interfaces; however, the default values may
be changed by the user to reflect other factors (e.g. propagation delay, link quality, desired traffic level, etc.)
The default values and recommended ranges for path cost are as follows:
• Interface Speed: 10 Mbps
• Default Path Cost: 100
380
Layer Two Switching
• Recommended Range: 50-600
• Interface Speed: 1 Gbps
The path cost values identified above reflect what is implemented in the initial SBx3112 product release as identified in IEEE
Std.802.1d, 1998 Edition. The corresponding default values and recommended ranges for path cost as specified in IEEE Std.
802.1w-2001 to support RSTP and MSTP are shown in the table below.
• Default Path Cost: 2,000,000
• Recommended Range: 200,000-20,000,000
• Default Path Cost: 200,000
• Recommended Range: 20,000-2,000,000
• Interface Speed: 1 Gbps
• Default Path Cost: 20,000
• Recommended Range: 2,000-200,000
A calculation is shown below that can be used to determine the recommended path cost value to use for intermediate link
speeds:
20,000,000,000 / (link speed in kb/s)
In LAN environments where bridges are in use that are operating different revision levels of STP, all the bridges must be configured to use compatible path cost value ranges. This will either require the older STP revision level bridges to be reconfigured to use the ranges specified in the newer standard, or the bridges with newer STP revisions will need to be configured to
utilize the ranges from the older standard. The range of path cost values available from the older STP standard may be insufficient to support the data rates available in newer bridges.
The default PATHCOST values and the range of recommended PATHCOST values depend on the interface speed (as indicated above). If the path cost for an interface is not explicitly set, it will vary as the speed of the interface varies. Setting the
path cost to a larger value on a particular interface is likely to reduce the traffic over the LAN connected to it. This may be
appropriate if the LAN has lower bandwidth, or if there are reasons for limiting the traffic across it. To modify the STP interface path cost, use the command:
SET STP INTERFACE
If the path cost of an interface has been explicitly set to a particular value, it can be returned to its self-adjusting default path
cost and priority, using the following command:
SET STP INTERFACE={type:id-range|id-range|ifname-list|ALL} DEFAULT
Each interface also has a path cost, which is used if the interface is the root interface for the STP on the switch. The path cost
is added to the root path cost field in configuration messages received on the interface to determine the total cost of the
path to the root bridge. To modify the STP interface path cost, use the command:
SET STP INTERFACE={type:id-range|id-range|ifname-list|ALL} PATHCOST=path-cost
Note:
The range of the path-cost value for STP mode is 1..65535. For RSTP mode, it is 1..200000000.
To display STP interface information, use the command:
381
Layer Two Switching
SHOW STP INTERFACE[={type:id-range|id-range|ifname-list|ALL}]
4.4.3.10 STP Timer Control Parameters
The Spanning Tree Protocol uses three configurable parameters for the time intervals that control the flow of STP information on which the dynamic STP topology depends:
• HELLOTIME (default 2 seconds) - This value determines how often the switch sends hello messages if it is the root
bridge, or if it is trying to determine the root bridge identity in the network. Setting a shorter value makes the network
more robust, in that network changes can be detected more rapidly. Setting a longer value reduces network traffic and
processing overhead.
• MAXAGE (default 20 seconds) - This value determines the maximum “age” of dynamic spanning tree configuration
information (e.g. the root bridge ID, designated ports, and root ports). If this information has not been refreshed by hello
messages before the timer expires, the information is discarded and the spanning tree must reconverge. If this timer is
too short, the spanning tree will undergo reconvergence unnecessarily, resulting in network outages. If the timer is too
long, the spanning tree may be slow to react to changes in network topology.
• FORWARDDELAY (default 15 seconds) - This value is used in the convergence process to allow for propagation of
hello messages through the network. The timer represents how long ports are in the listening and learning states. By using
this delay, the network has time for all the switches to agree on the spanning tree configuration. If the timer is too short,
ports may reach the forwarding state before a stable topology has been reached. This may result in network loops that
serious degrade overall network performance. If the timer is too long, it will cause unnecessary delays in enabling the
ports for passing bearer traffic. (At the default timer, the network will require at least 30 seconds for ports to transition
from “blocking” to “forwarding”, since each port will spend 15 seconds in the “listening” state and 15 seconds in the
“learning” state. All switches in the same spanning tree topology must use the same values for these parameters. The
parameter values actually used by each switch are those sent by the root bridge, and forwarded to all other switches by
the designated bridges.
Each switch that participates in the spanning tree (i.e. each switch in the extended LAN) must use the same values for these
timers; otherwise, the convergence process would be unpredictable and unstable. To ensure that the timer values are consistent throughout the network, the timers for all the switches are set to values configured for the root bridge, once the identity of the root bridge has been determined.
The recommended relationship between the timer values can be expressed using the following formulae:
MAXAGE >= HELLOTIME x (number of network “hops” in longest path through network)
MAXAGE >= 2 x (HELLOTIME + 1 second)
MAXAGE <= 2 x (FORWARDDELAY - 1 second)
To modify the parameters controlling these time intervals, use the command SET STP and the appropriate parameter.
4.4.3.11 The Priority Parameter
The value of the PRIORITY parameter is used to set the writable portion of the bridge ID, for example, the first two octets
of the (8-octet long) Bridge Identifier. The remaining 6 octets of the bridge IDs are given by the MAC address of the switch.
The Bridge Identifier parameter is used in all Spanning Tree Protocol packets transmitted by the switch. The first two octets,
specified by the PRIORITY parameter, determine the switch’s priority for becoming the root bridge or a designated bridge in
the network, with a lower number indicating a higher priority. In fairly simple networks, for instance those with a small number of switches in a meshed topology, it may make little difference which switch is selected to be the root bridge, and no
modifications may be needed to the default PRIORITY parameter, which has a default value of 32768. In more complex networks, one or more switches are likely to be more suitable candidates for the root bridge role, by virtue of being more centrally located in the physical topology of the network. In these cases, the STP PRIORITY parameters for at least one of the
switches should be modified. To change the STP priority value, use the command SET STP PRIORITY=bridge-priority, where bridge-priority is 0..65535 for STP mode and 0..65535 in steps of 4096 in RSTP mode. To restore STP timer
and priority defaults, use the command SET STP DEFAULT.
382
Layer Two Switching
Changing the STP PRIORITY, using either of the previous commands, restarts the STP algorithm, so that elections for the
root bridge and designated bridges begin anew, without resetting STP counters. To display general information about STPs on
the switch, use the command SHOW STP.
4.4.3.12 Force Version
This parameter is used for RSTP. This parameter allows the user to specify that the bridge should operate in the
STP_ORIGINAL mode, RSTP, or STP_COMPATIBLE_RSTP mode. If the STP_COMPATIBLE_RSTP mode is chosen,
the RSTP will be compatible with other switches in the network that may not use RSTP and therefore use older parameter
values and ranges.
4.4.3.13 Edge Port
This parameter allows the user to specify a port as an “Edge Port” when it is expected that a port will be directly connected
to a host (i.e. a port at the “edge” of the Bridged LAN). Additional processing is associated with the use of this parameter to
verify that a port identified as an “Edge Port” by the user is not actually connected to another bridge. This parameter and its
associated processing can facilitate a port state transition directly to the forwarding state as part of the RSTP processing.
In the SET STP INTERFACE command, set EDGEPORT=TRUE to enable this for RSTP.
4.4.3.14 Point-to-Point Port
This parameter allows the user to specify a port as a Point-to-Point Port when it is expected that it will be connected to exactly
one other bridge. Additional processing is associated with this parameter to automatically determine whether or not the
port should be considered a point-to-point connection, when so indicated by the user via (auto).parameter setting
The Point-to-Point Port parameter, and its associated processing, is utilized by the RSTP to facilitate the rapid transition of a
port into the forwarding state under certain conditions specific to Point-to-Point ports only.
In the SET STP INTERFACE command, set POINT2POINT=TRUE or AUTO to enable this for RSTP.
Note:
In most cases, select AUTO so that the system can determine the port connection.
4.4.3.15 Transmit Hold Count
This parameter allows the user to specify the maximum BPDU transmission rate for any port on the bridge, which therefore
determines how much STP control traffic is going into the network. The default value for this parameter is 6, indicating that
at most 3 BPDUs can be transmitted from any port in a given Hello Time period (2 seconds by default).
In the SET STP command, the parameter is TXMAX; the range is 1 to 10 (with the default of 6).
4.4.3.16 Enable/Disable STP
The default Spanning Tree instance is disabled (by default) at switch start up, and Spanning Tree instances created by a user
are disabled by default when they are created. To enable or disable Spanning Tree instances, use the commands ENABLE/
DISABLE STP.
4.4.3.17 Enable/Disable Interface
When an STP is enabled in a looped or meshed network, it dynamically enables and disables particular ports belonging to it,
to eliminate redundant links. All ports in a VLAN belong to the same STP, and their participation in STP configuration is
enabled by default when STP is enabled, and hence the possibility of them being elected to the STP's active topology. To
enable or disable particular ports for participation or exclusion from STP operations, use the commands ENABLE and DISABLE STP INTERFACE.
383
Layer Two Switching
This command also supports the TOPOLOGYCHANGE parameter to control the detection of topology changes on the
associated port. This allows the disabling of topology change detection on ports that are known to be connected to single
end stations that could cause the Topology Change Notification mechanism to be triggered for the entire network when the
end station is power cycled.
4.4.3.18 Display Counters
To display STP counters, use the following command, with the results shown below.
SHOW STP COUNTER
officer SEC> SHOW STP COUNTER
--- STP Counter Information --------------------------------------------------STP Instance Name.....................
STP Packets Transmitted...............
STP Packets Received..................
Configuration BPDU Transmitted........
Configuration BPDU Received...........
TCN BPDU Transmitted..................
TCN BPDU Received.....................
Invalid BPDU..........................
Port Disabled.........................
Invalid Protocol......................
Invalid Type..........................
Invalid Message Age...................
Configuration BPDU length.............
TCN BPDU length.......................
MAIN
0
0
0
0
0
0
0
0
0
0
0
0
0
-------------------------------------------------------------------------------
4.4.3.19 Reset STP
The spanning tree algorithm can be recalculated at any time, and all timers and counters be initialized, using the command
RESET STP.
4.4.3.20 (R)STP and VLAN Interaction
Since STP is a port-based topology and VLAN is a logic-based topology (over a physical port), the user needs to understand
how these two work together so that the blocked links that are part of (R)STP convergence do not have unintended consequences for the VLANs that are carried over these ports.
Note:
With the MSTP feature, there can be an additional (R)STP instance based on a (set of) VLANs. However, the
configuration rules listed here should be understood first, since they apply to understanding the MSTP instances.
Refer to the following figure, which shows an (R)STP topology in which two physical links are blocked and two VLANs are
configured.
384
Layer Two Switching
A
VLAN 100
(TDMdata)
1
0.2
0.0
4
VLAN 50
(TDMdata)
0.0
VLAN 100 on Device A is
disconnected
from the network
0.1
0.1
B
VLAN 50
(TDMdata)
5
0.1
0.1
D
VLAN 100
(TDMdata)
C
0.0
VLAN 50
(TDMdata)
2
A
D
= Devices
1
5
= Links
0.0
0.2
VLAN 100
(TDMdata)
= VLAN 50
= VLAN 100
= Links blocked
(ports blocked)
= Physical Link
VLAN_STP
FIGURE 4-3
3
STP Network with Multiple VLANs - STP Blocks Two Ports and VLAN is Isolated
To prevent loops, STP convergence has blocked links 4 and 5. For VLAN 50, this is not a problem; VLAN 50 follows a physical
loop and so actually mimics the loop and needs to be blocked. VLAN 100, however, is a non-looped VLAN, and so with physical link 4 being blocked, the VLAN on Device A is disconnected from the network and cannot send or receive data.
From this figure two rules follow:
• There should be no non-looped VLANs in the STP network.
• Looped VLANs should follow physical loops of the STP network
4.4.4 Example (R)STP Configuration - Standard VLAN
Once the topology stabilizes, in each system one of the ports will become the root port (the one closest to the root bridge
as determined by STP) and the other port(s) become the designated port. The port which is the root port is considered to be
the upstream port and the port which is not the root port (designated port) is considered to be the downstream port.
To prevent one of the systems from becoming the Spanning Tree root bridge, the network design must ensure that the
appropriate STP parameters are set such that the root bridge is always located above the ring configuration.
4.4.5 Configuring (R)STP
4.4.6 Default STP Configuration (Customer and Network Ports)
By default the SBx3112 series product has the following STP set-up:
• There is one STP instance that cannot be destroyed. Its name is “MAIN” and its initial state is disabled.
• By default all ports will belong to the default STP.
385
Layer Two Switching
Interfaces have the DIRECTION attribute that can be NETWORK or CUSTOMER. Usually, the user does not want interfaces with a direction of CUSTOMER to participate in STP.
The CUSTOMER-direction interfaces default is not to be included (i.e. STP is disabled for those interfaces).
The SBx3112 is a designated bridge in the network shown in Figure 4-4. Interface 0.22 serves as the root port. Interfaces
0.20, 0.21, 1.2, 1.3, and 11.0 serve as designated ports. Interface 0.0 serves as an alternate port.
32768 / 00:0C:25:00:06:AD
32768 / 00:0C:25:00:06:AD
ROOT
BRIDGE
SBx3112
0.22
0.22
Designated
Forwarding
11.0
SBx3100
32768 / EC:CD:6D:03:10:CB
1.3
Designated
Forwarding
1.2
Forwarding
32768 / 00:0C:25:00:06:AD
0.21
Designated
0.20
Designated
1.3
Forwarding
Designated
Forwarding
Changing
the Root Port
1.2
0.21
Designated
Forwarding
Designated
0.20
0.0
Designated
Forwarding
Designated
Forwarding
Designated
Forwarding
ROOT
BRIDGE
Forwarding
0.0
32768 / EC:CD:6D:03:10:CB
Designated
11.0
SBx3100
Alternate
Discarding
Forwarding
Designated
SBx3112
Forwarding
Root
Forwarding
DESIGNATED
BRIDGE
ROOT
BRIDGE
Alternate
Starting RSTP
Configuration
Discarding
SBx3112
0.22
11.0
SBx3100
Root
32768 / EC:CD:6D:03:10:CB
0.0
Forwarding
Designated
Forwarding
Changing
the Root Bridge
1.3
Designated
FIGURE 4-4
Forwarding
Forwarding
1.2
Designated
Forwarding
0.21
Designated
Forwarding
Designated
0.20
RSTP Network - Changing Root Port and Changing a Designated Bridge to Root
The following procedure shows the commands used to configure RSTP parameters in order to change the SBx3112’s root
port as well as to change it from being a designated bridge to being the root bridge in the network.
TABLE 4-13
Step
Configuration Procedure for RSTP
Command
Description/Notes
Enable STP
1
enable stp
A single STP instance (MAIN) is created. The
default mode is RSTP.
View the current RSTP configuration
The root bridge has a priority of 32768 and a MAC address of 00:0C:25:00:06:AD. The SBx3112 has a priority of 32768
and a MAC address of EC:CD:6D:03:10:CB. The SBx3112 is forwarding on its root port (0.22) and designated ports
(0.20, 0.21, 1.2, 1.3, 11.0), while discarding on its alternate port (0.0).
386
Layer Two Switching
TABLE 4-13
Step
Command
2
show stp
Description/Notes
--- STP Information ---------------------------------------------------------Spanning Tree Type...................... RSTP
Instance Name......................... MAIN (0)
Instance State........................ ENABLED
Root Bridge ID Priority............ 32768
Root Bridge ID MAC Address....... 00:0C:25:00:06:AD
Max Age (seconds)..................... 20
Hello Time (seconds).................. 2
Forward Delay (seconds)............... 15
Bridge ID Priority................. 32768 (priority 32768 mstid 0)
Bridge ID MAC Address............ EC:CD:6D:03:10:CB
Bridge Max Age (seconds).............. 20
Bridge Hello Time (seconds)........... 2
Bridge Forward Delay (seconds)........ 15
Int
Role
State
Cost Prio.Number
Type
----- ---------- ---------- ---------- ----------- ------------------------0.0
ALTERNATE
DISCARDING
20000 128.321
RSTP
0.20 DESIGNATED
FORWARDING
200000 128.341
RSTP
0.21 DESIGNATED
FORWARDING
200000 128.342
RSTP
0.22 ROOT
FORWARDING 20000 128.343
RSTP
1.2
DESIGNATED
FORWARDING
2000 128.387
RSTP
1.3
DESIGNATED
FORWARDING
2000 128.388
RSTP
11.0 DESIGNATED
FORWARDING
20000 128.1025
RSTP
Change the SBx3112’s root port
The root port switches from interface 0.22 to 0.0, while interface 0.22 becomes a discarding alternate port.
3
set stp interface 0.0 pathcost 2000
Reduces the path cost from 20000 to 2000 on
interface 0.0.
Verify the root port change
4
show stp
--- STP Information ---------------------------------------------------------Spanning Tree Type......................
Instance Name.........................
Instance State........................
Root Bridge ID Priority.................
Root Bridge ID MAC Address............
Max Age (seconds).....................
Hello Time (seconds)..................
Forward Delay (seconds)...............
Bridge ID Priority......................
Bridge ID MAC Address.................
Bridge Max Age (seconds)..............
Bridge Hello Time (seconds)...........
Bridge Forward Delay (seconds)........
RSTP
MAIN (0)
ENABLED
32768
00:0C:25:00:06:AD
20
2
15
32768 (priority 32768 mstid 0)
EC:CD:6D:03:10:CB
20
2
15
Int
Role
State
Cost
Prio.Numbe
Type
----- ---------- ---------- ---------- ----------- ------------------------0.0
ROOT
FORWARDING
2000 128.321
RSTP
0.20 DESIGNATED
FORWARDING
200000 128.341
RSTP
0.21 DESIGNATED
FORWARDING
200000 128.342
RSTP
0.22 ALTERNATE DISCARDING 20000 128.343
RSTP
1.2
DESIGNATED
FORWARDING
2000 128.387
RSTP
1.3
DESIGNATED
FORWARDING
2000 128.388
RSTP
11.0 DESIGNATED
FORWARDING
20000 128.1025
RSTP
Reset RSTP to default configuration.
5
set stp default
The root port is changed from interface 0.0
back to interface 0.22.
View RSTP configuration
387
Layer Two Switching
TABLE 4-13
Step
Command
6
show stp
Description/Notes
--- STP Information ------------------------------------------------------------Spanning Tree Type......................
Instance Name.........................
Instance State........................
Root Bridge ID Priority.................
Root Bridge ID MAC Address............
Max Age (seconds).....................
RSTP
MAIN (0)
ENABLED
32768
00:0C:25:00:06:AD
20
2
15
EC:CD:6D:03:10:CB
20
2
15
Int
Role
State
Cost
Prio.Number
Type
----- ---------- ---------- ---------- ----------- ------------------------0.0
ALTERNATE
DISCARDING
20000 128.321
RSTP
0.20 DESIGNATED
FORWARDING
200000 128.341
RSTP
0.21 DESIGNATED
FORWARDING
200000 128.342
RSTP
0.22 ROOT
FORWARDING 20000 128.343
RSTP
1.2
DESIGNATED
FORWARDING
2000 128.387
RSTP
1.3
DESIGNATED
FORWARDING
2000 128.388
RSTP
11.0 DESIGNATED
FORWARDING
20000 128.1025
RSTP
Switch the SBx3112 from a designated bridge to the root bridge
7
set stp priority 1000
Reduces the priority from 32768 to 1000
(rounded down to 0). This results in the
SBx3112 switching from a designated bridge to
the root bridge.
Verify the root bridge change
8
show stp
--- STP Information ----------------------------------------------------------Spanning Tree Type...................... RSTP
Root Bridge ID Priority............ 0
Root Bridge ID MAC Address....... EC:CD:6D:03:10:CB
Max Age (seconds)..................... 20
Bridge ID Priority................. 0 (priority 0 mstid 0)
Bridge ID MAC Address............ EC:CD:6D:03:10:CB
Int
----0.0
0.20
0.21
0.22
1.2
1.3
11.0
Role
---------DESIGNATED
DESIGNATED
DESIGNATED
DESIGNATED
DESIGNATED
DESIGNATED
DESIGNATED
State
Cost Prio.Number
---------- ---------- ----------FORWARDING
20000 128.321
FORWARDING
200000 128.341
FORWARDING
200000 128.342
FORWARDING
20000 128.343
FORWARDING
2000 128.387
FORWARDING
2000 128.388
FORWARDING
20000 128.1025
Type
------------------------RSTP
RSTP
RSTP
RSTP
RSTP
RSTP
RSTP
4.4.8 Multiple Spanning Tree Protocol (MSTP)
The previous subsections have described the STP and RSTP features and how they are configured. It is also possible to configure multiple (R)STP instances on a VLAN basis, so this is called the Multiple Spanning Tree Protocol (MSTP).
388
Layer Two Switching
With MSTP, separate spanning tree instances are created for VLANs (or groups of VLANs). Each of the separate instances
elect root bridges, root ports, and designated bridges independently.
When an (R)STP network is configured and no VLANs are configured (only the default VLAN), each device and each port are
considered part of the same extended LAN, and so all participate in the same convergence process. Therefore all devices and
ports are part of a single (R)STP instance. As VLANs are added, they are still part of the single spanning tree instance.
Note:
As VLANs are configured, the user must be careful to ensure that the physical (link) and virtual (VLAN) connections
work together and do not lead to any disconnected VLANs.
This association of multiple VLANs with the one spanning tree is called a Common and Internal Spanning Tree, or CIST.
Bridges configured within a CIST behave as a single spanning tree system automatically.
With MSTP, additional spanning tree instances can be created and associated with the VLANs defined on the device. These
additional spanning tree instances are called Multiple Spanning Tree Instances (MSTI).
Note:
Each VLAN can be associated with only one instance.
Bridges that share a common set of MSTIs (each with their associated set of VLANS) make up an MST region, with each
MSTI forming a logical network topology; this is explained below.
Figure 4-5 shows an example of a network using MSTP. Note that the CIST has been omitted for simplicity.
Note:
Since MSTP is a set of RSTP instances, the user should be familiar with the concepts of the single (R)STP instance,
explained in previous subsections.
= Physical Link
= MST Instance 1 (V_60)
V_60
V_80
= MSTRegion1
= CIST Spanning
Tree Instance
= VLAN on MST
Instance 2 block
= VLAN on MST
Instance 1 block
0.3
0.2
0.1
V_80
A
V_60
1
4
MSTRegion1
0.2
V_80
B
Regional
V_60 Root
Bridge
MSTI2
A
D = Devices
1
4
0.1
Regional
Root
V_60
Bridge
MSTI1
= Links
0.1
V_80
D
0.2
2
0.1
0.2
3
V_60
C
V_80
MSTP_config_no_secondary
FIGURE 4-5
Concept of an MSTP Network
389
Layer Two Switching
In Figure 4-5, there are two MST instances, Instance 1 with VLAN 60 and Instance 2 which includes VLAN 80. Only one
VLAN is associated with each instance; more than one VLAN can be associated with an MST instance, but this simple example helps to demonstrate key concepts.
For MST Instance 1, the VLAN is blocked on physical link 3, so that no traffic over VLAN 60 can traverse between bridges C
and D. For MST Instance 2, the VLAN is blocked on physical link 4, so that no traffic over VLAN 80 can traverse between
bridges A and D. With this topology, no loops are formed for each MSTP instance.
With this topology, if link 2 is now physically blocked, there will also be a block over MST Instances 1 and 2 over Physical Link
2. As a result, Bridge C is blocked from the network for MST Instance 2 (VLAN 80) and Bridges C and D are blocked from
the network for MST Instance 1 (VLAN 60).
To correct this, MST Instance 1 will unblock its VLAN (V_60) over physical link 3, and Instance 2 will unblock its VLAN
(V_80) over Physical Link 4. The resulting topology will now allow for no loops and no bridge is isolated. Refer to Figure 4-6.
= Physical Link
V_60
V_80
= CIST Spanning
Tree Instance
= MST Region 1
0.3
0.2
0.1
V_80
A
V_60
1
4
MST Region 1
0.2
V_80
V_60
B
Regional
Root
Bridge
MSTI 2
A
D
= Devices
1
4
= Links
0.1
Regional
Root
Bridge
MSTI 1
= Physical Link 2 is blocked, VLANs
for MSTI on Physical Links 3 and 4 are
unblocked
0.1
V_80
V_60
D
0.2
2
3
0.1
0.2
V_60
C
V_80
MSTP_config_no_secondary_rec
FIGURE 4-6
MSTP Recovery when Physical Link Blocked
4.4.8.1 MTSP Region
When a set of switches have the same MSTI configuration (meaning the set of switches have the same MSTIs and their VLAN
associations), these switches can make an MSTP region. This allows the group of switches to be placed under a common
administration; the region appears as one large bridge to the rest of the network spanning tree (i.e. the CIST). Since there is
one overall network instance, which connects all the regions, blocking on boundary ports would occur so that there would
be no loops into and out of the MST Region. Refer to the following figure.
Note:
One feature, Cisco Compatible STP Mode, allows the Allied Telesis SBx3112 to participate in the same MSTP region
with one or more adjacent Cisco bridges that do not meet the 802.1s MST standard.
To form an MSTP Region, all bridges that make up the region must share these attributes:
390
Layer Two Switching
•
•
•
•
MSTP Instances
VLANs associated with these instances
MSTP Region Name
MSTP Region Revision Level
Refer to Figure 4-7, which shows the MST Region as part of the larger CIST. The CIST represents a spanning tree outside
the MST region, but also has a spanning tree inside the region (the IST), and can carry all VLAN traffic outside the MST
region.
Note that it is not required that VLANs are configured on all the ports (interfaces), although it is necessary if the user wishes
traffic for a specific VLAN (which is part of an Instance) to be carried over that port. Not configuring VLANs on the port can
be useful in the following scenarios:
• The user wishes to block VLAN traffic without changing the existing spanning tree
• As the MST Region is created, no loops are created.
= Physical Link
= Network Spanning
Tree Instance
Root
Bridge
CIST
= MST Region 1
V_60
V_80
= VLAN on MST
Instance 2 blocked
= VLAN on MST
Instance 1 blocked
0.3
V_60
V_80
0.2
0.1
V_80
A
V_60
4
1
MST Region 1
V_80
B
Regional
V_60 Root
Bridge
MSTI 2
A
D = Devices
1
4
0.1
Regional
V_60
Root
Bridge
MSTI 1
= Links
0.1
0.2
0.2
D
V_80
0.2
2
3
0.1
0.2
V_60
C
V_80
MSTP_Region_concept
FIGURE 4-7
Concept of an MSTP Region
391
Layer Two Switching
4.4.8.2 Provisioning Parameters
Many of the commands and parameters for MSTP are similar to (R)STP, since the user is still creating an (R)STP instance that
must go through a convergence process. However, some parameters are unique for MSTP, or some value for a common
parameter is different, and these are highlighted.
Following are the key parameters that are data filled for (R)STP; for each there is a summary for the parameter (or a reference to an earlier subsection, especially 4.4.3.6), and how MSTP uses the parameter.
4.4.8.3 Bridge ID
Bridge IDs are used in root bridge elections. The root bridge is the switch in the extended LAN with the numerically lowest
bridge ID value. This is guaranteed to identify a single bridge due to the unique MAC address component. The user is allowed
to change the bridge priority component to override the arbitrary root selection that will result from only comparing MAC
addresses when the default bridge priorities are in use.
Bridge IDs are also used in designated bridge elections. Normally the switch with the lowest root path cost is the designated
bridge for a physical LAN. If more than one switch has the same lowest root path cost, then the designated bridge is the
switch with the numerically lowest bridge ID value.
The default bridge priority value is 32768. A bridge priority can be configured as a value from zero to 65535, in accordance
with IEEE Std 802.1D, 1998 Edition. For MSTP, however, the priority component of the bridge ID is reduced to support MSTP
operations, to allow for the unique identification of each MSTI in a bridge as part of a “system ID” that represents a (12-bit)
numerical extension to the MAC address. This avoids the potential need to allocate up to 4094 additional MAC addresses
per bridge to uniquely identify each MSTI. The reallocation of (bits in) the bridge ID contents was done in a manner that supports backwards compatibility with IEEE Std. 802.1D, 1998 Edition.
As a result, the bridge priority component has been modified to be a (4-bit) value between 0-65535 that can only be provisioned in increments of 4096. This was done to allow for direct comparison with values from earlier versions of STP.
For Bridges that are running MSTP, there will be MSTI definitions to support the different VLANS defined for the bridge. Each
of the MSTIs will have its own Bridge Identifier with the composition described above, except that each will include the
Bridge MAC address as a component of the Bridge ID. Each will have a priority component, as described above, which can be
independently provisioned from the other spanning tree instances defined for the same bridge.
The final component is an identifier called the “system ID extension” that is used to uniquely identify each of the MSTIs for a
bridge. The CIST for each bridge will use the system ID extension value of zero. Any other MSTI defined for the bridge will
utilize a value called the MSTID that identifies the MSTI. The MSTID parameter is described in a later section.
4.4.8.4 Port ID
Port IDs are used in root port elections. Normally, the port with the lowest root path cost is the root port for the switch. If
more than one port ties for the lowest root path cost, then the root port is the port with the lowest numerical port ID.
The default port priority value is 128. The IEEE Std 802.1D, 1998 Edition includes priority values on a per-port basis from
zero to 255. For the Allied Telesis SBx3112, the storage space (number of bits) allocated to the priority component of the
port ID is reduced to support bridges with larger numbers of ports, since this only left room for port numbers from 1-255.
To maintain compatibility for comparison with previous versions of STP, the port priority is a value between 0-240 that can
only be provisioned in increments of 16.
For Bridges that are running MSTP, the priority component of the Port ID is repeated for the CIST, and each MSTI defined for
the bridge. This allows the user complete independent control over the port configurations for each Spanning
Tree instance.
392
Layer Two Switching
4.4.8.5 Port Path Costs
Port path costs are used in root path cost calculations, which are a factor in selecting root ports and designated bridges. By
default, port path costs are related to the bandwidth capacity of the ports; however, the default values may be changed by the
user to reflect other factors (e.g. propagation delay, link quality, desired traffic level, etc.)
The values for port path costs are listed in 4.4.3.9. For MSTP, the internal port path cost and the external port path cost are
represented by one port path cost parameter described there.
4.4.8.6 Port participation
If ports on a switch are members of an extended LAN or VLAN that does not require use of the spanning tree protocol (i.e.,
if the VLAN is administered such that no network loops could exist), then spanning tree protocol operations can be disabled
for those ports. However, if a port is a member of multiple VLANs, then the spanning tree protocol must be enabled on that
port for all those VLANs or none of them; a mixed configuration is not supported.
If spanning tree protocol operations are disabled for a port, it may still pass bearer traffic to and from other ports, regardless
of whether or not the spanning tree protocol is used for those other ports.
For bridges that run MSTP, port participation in the spanning tree may be disabled on a per MSTI basis. This means that
VLAN traffic associated with the disabled MSTI may flow freely through those ports
Note:
Spanning tree instances (MSTIs) themselves may not be disabled individually.
4.4.8.7 Force Version
Refer to 4.4.3.12. The value specifies whether STP or RSTP is to be used on a bridge. For MSTP the value 2 (RSTP) is used.
4.4.8.8 Edge Port
Refer to 4.4.3.13, and is part of RSTP processing in that it identifies a port is directly connected to the host. For MSTP, this
value is also used.
4.4.8.9 Point-to-Point Port
Refer to 4.4.3.14, and is used by MSTP.
Note:
In most cases, select AUTO so that the system can determine the port connection.
4.4.8.10 Transmit Hold Count
Refer to 4.4.3.15, and is used by MSTP processing.
4.4.8.11 Max Hops (Unique for MSTP)
For MSTP, an additional mechanism is added to control the circulation of old information within a spanning tree instance
(CIST and MSTIs). Each BPDU sent for MSTP will contain a “remaining hop count” field. The value is initially set by the root
bridge for the spanning tree instance (i.e., the Regional Root) where the BPDU originates. The field is then decremented at
each bridge that the information passes through. Once the field reaches zero, the information stops circulating.
The Max Hops parameter allows the user to specify the value that this field will be initialized to should the bridge for which
it is provisioned become the root of a spanning tree instance. By default, the max hops parameter is set to the same value as
max age.
393
Layer Two Switching
4.4.8.12 Multiple Spanning Tree Instance ID (Unique for MSTP)
When the user creates a new Spanning Tree instance for a bridge, a number between 1 and 4096 must be specified to
uniquely identify this Multiple Spanning Tree Instance (MSTI) to other bridges connected to this bridge using LAN segments.
The user also provides a name when the spanning tree instance is created which may be used for all commands on the local
bridge which require a spanning tree instance to be identified. When the name “MAIN” is provided, the Common and Internal Spanning Tree instance (CIST) is utilized by the command processing. The MSTID for the CIST is zero.
4.4.8.13 MST Configuration Table (Unique for MSTP)
To associate one or more VLANs with a spanning tree instance, the ADD STP command is used with the name or MST ID of
a spanning tree instance and one or more VLANs (by name or VID). The MST Configuration Table contains the VLAN to
Spanning Tree mapping for a particular Bridge that is running MSTP. By default, all VLANs defined for a Bridge running MSTP
will be mapped to CIST. As additional MSTIs are defined for the Bridge, this table will be filled in as the user provisions the
desired mapping of defined VLANs for the bridge to the new MSTI.
4.4.9 Configuring MSTP
The default is the same as with (R)STP; only an RSTP instance exists, labeled MAIN with id 0, and it is disabled.
• To meet the redundancy and load balance needs of the network, the minimum number of MSTIs necessary should be created. This implies putting as many bridges as possible into an MST Region. With this minimum number of MSTIs, multiple
VLANs can be assigned to each one.
• When multiple VLANs are mapped to the MSTI, port blocking will occur for all the VLANs on the ports that are blocked
by the MSTI.
• An interface must be enabled against MAIN before it can be enabled to any other MSTP instance. (Before enabling an
MSTP instance against an interface, the MAIN instance must be enabled against that interface as well.) Otherwise you will
receive an error message, as shown here.
show stp interface=1.2 // 1.2 is excluded from MAIN instance
--- STP Interfaces Information -----------------------------------------------STP Instance
Forwarding
Learning
Discarding
Excluded
Interfaces
Interfaces
Interfaces
Interfaces
---------------- --------------- --------------- --------------- -----------MAIN
1.2
mst9
mst10
1.2
enable stp inst mst9 int 1.2 // attempting to include 1.2 in mst9
Error (040482): Could not enable MSTP instance for interface since MAIN
instance is excluded
enable stp int 1.2 // enabling all instances against interface 1.2
Info (040409): Spanning Tree Protocol operation is now enabled for the
specified interface/interface-list (1.2)// Repeated for each instance
394
Layer Two Switching
show stp interface=1.2 // mst9 now has 1.2 included
--- STP Interfaces Information -----------------------------------------------STP Instance
Forwarding
Learning
Discarding
Excluded
Interfaces
Interfaces
Interfaces
Interfaces
---------------- --------------- --------------- --------------- -----------MAIN
1.2
mst9
1.2
mst10
1.2
-
• You cannot disable the MAIN instance against an interface if other instances are enabled against that interface. Otherwise
you will receive an error message, as shown here.
disable stp inst main interface=1.0
Error (040483): Could not exclude interface for MAIN instance while active
for other MSTP instance(s)
The following table shows the basic steps to configure the MSTP instances shown in Figure 4-5 with:
•
•
•
•
•
•
The MST region named MSTRegion1.
The MSTP instances named MSTID1 and MSTID2.
VLANs 60 and 80 are already created and added to the device interfaces.
RSTP is enabled on all of the devices.
RSTP is enabled on all the connecting interfaces of the devices.
Device B defaults to the Regional Root Bridge.
TABLE 4-14
Step
Configuration Procedure for MSTP
Command
Set the stp version to MSTP on Devices A-D
1
SET STP PROTOCOL=MSTP
A single MSTP instance (MAIN) is created containing all created VLANs.
Create a region on Devices A-D
2
SET STP MSTREGION=MSTRegion1
Region appears as one large bridge to the rest of
the network.
Create the MSTP instances MSTI1 and MSTI2 on Devices A-D.
3
CREATE STP INSTANCE=MSTI1 MSTID=1
CREATE STP INSTANCE=MSTI2 MSTID=2
Set Device D to be Regional Root Bridge (optional). Command for Device D only..
4
SET STP INSTANCE=MSTI1 PRIORITY=1
Changing the Regional Root Bridge for MSTI1 to
be Device D. This would also have to be done for
MSTI2 if the default Regional Root Bridge is not
for Device B.
Associate VLANs with MSTP instances on Devices A-D
395
Layer Two Switching
TABLE 4-14
Step
Command
5
ADD STP INSTANCE=1 VLAN=60
ADD STP INSTANCE=2 VLAN=80
Show the configuration on Device A
6
officer SEC>> show stp inst all full
--- STP Information -------------------Spanning Tree Type...................... MSTP (CIST)
VLAN Associations....................... 1 (2-59,61-79,81-4094)
Root Bridge ID Priority................. 32768
.....................................
Int
Role
State
Cost Prio.Number Type
----- ---------- ---------- ---------- ----------- -----0.1 DESIGNATED FORWARDING
200000 128.834
MSTP
0.2 DESIGNATED FORWARDING
20000 128.848
MSTP
0.3 ROOT
FORWARDING
20000 128.848
RSTP (boundary)
------------------------------------------------------------------- STP Information --------------------------------------------Spanning Tree Type...................... MSTP (MSTI)
Instance Name......................... MSTI1 (1)
VLAN Associations....................... 60
Regional Root Bridge ID Priority........ 32769
..................................................
Int
Role
State
----- ---------- ---------- ---------- ----------- ---------0.1 DESIGNATED FORWARDING
200000 128.834
MSTP
0.2 ROOT
FORWARDING
20000 128.848
MSTP
0.3 MASTER
FORWARDING
20000 128.848
RSTP (boundary)
--- STP Information ---------------------------------------------Spanning Tree Type...................... MSTP (MSTI)
..................................................
Int
Role
State
----- ---------- ---------- ---------- ----------- ---------0.1 ROOT
FORWARDING
200000 128.834
MSTP
20000 128.848
MSTP
0.3 MASTER
FORWARDING
20000 128.848
RSTP (boundary)
--------------------------------------------------------------officer SEC>> show stp
--- MSTP Configuration Identifier Information ---------------------Format Selector................................ 0
Region Name.................................... region1
Revision Level................................. 0
---------------------------------------------------------------------- Spanning Tree Instance Summary --------------------------------STP Instance
MSTID
STP State
Root Port Vlan(s) Associated
-------------- -------- ------------ ---------- ------------------MAIN
0
ENABLED
0.2
1 (2-59,61-79,81-4094)
MSTI1
1
ENABLED
0.2
60
MSTI2
2
ENABLED
0.1
80
396
Layer Two Switching
TABLE 4-14
Step
Command
Destroy the instance, this will automatically put the VLAN(s) back in to the MAIN instance .
7
officer SEC>> show stp instance msti2
--- STP Information -----------------------------------------------Spanning Tree Type...................... MSTP (MSTI)
..................................................
Int
Role
State
----- ---------- ---------- ---------- ----------- ---------0.1 ROOT
FORWARDING
200000 128.834
MSTP
20000 128.848
MSTP
0.3 MASTER
FORWARDING
20000 128.848
RSTP (boundary)
--------------------------------------------------------------officer SEC>> destroy stp instance msti2
officer SEC>> show stp
--- MSTP Configuration Identifier Information ---------------------Format Selector................................ 0
Revision Level................................. 0
---------------------------------------------------------------------- Spanning Tree Instance Summary --------------------------------STP Instance
MSTID
STP State
-------------- -------- ------------- ---------- ------------------MAIN
0
ENABLED
0.2
80 (1-59,61-79,81-4094)
MSTI1
1
ENABLED
0.2
60
(MSTI2 is not included and VLAN 80 is back in MAIN)
--------------------------------------------------------------------
4.4.10 BPDU COP
4.4.10.1 Overview
An SBx3112 interface could be connected to some other device (i.e.a switch or media converter), Some part of the hardware could go out of service, but the hardware fault would not be detected. and a netwrok loop could result. To prevent the
network loop from affecting the entire network, when the SBx3112 feature BPDU Cop enabled, when the interface does not
recieve a BPDU that interface will be temporarily or permanently disabled depending on how the interface is configured
The parameter BPDUCOP={ ON | OFF } is part of the SET STP INTERFACE command and is set against the specific interface(s).
There is a second parameter (TIMEOUT=0..2048), that when set to a non-zero value determines how many minutes the
system will wait before it tries to re-enable the interface.
4.4.10.2 Feature without AutoRecovery (TIMEOUT=0)
When a BPDU is received and the feature is activated, the operational state goes to DOWN and the state changes to AUTO-DISABLED,
as shown in 4.4.11.
Note that once the interface is set to AutoDisabled by the system, the user must disable and enable the interface to clear the
alarm and bring the interface back into service. In other words, once an interface is placed out of service by the
BPDU Cop feature, it will stay disabled unless it is explicitly brought back up by the user.
397
Layer Two Switching
4.4.10.3 Feature with Auto Recovery (TIMEOUT=1 to 2048, Default = 10)
With the TIMEOUT parameter, the Auto-Recovery is activated, and this allows the option to have the system wait 1 to 2048
minutes before automatically re-enabling the interface.
When BPDU Cop is enabled, the auto recovery is also enabled by default, with TIMEOUT set at 10 minutes.
4.4.10.4 Summary of Feature Operation
Table 4-15 shows the state of the interface, how the parameters can be set, and how the feature will work. Included in the
table are possible (although uncommon) situations where the user may change a parameter while the interface is in a failed
state.
TABLE 4-15
Interface
State
BPDUCOP
(Y/N)
Normal
Y
(no faults)
Normal
Feature Operation for BPDU Cop
TIMEOUT = n
(0..2048)
Manual Change
made by User
n=0
None
If there is an unexpected BPDU, feature is
activated. The interface is disabled and must
be re-enabled by the user
None
If there is an unexpected BPDU, feature is
activated. After n minutes, the system will
re-enable the interface.
(Auto-recovery
disabled)
Y
(no faults)
n = 1..2048
(Auto-recovery
enabled)
Result
Fault State
Y
n = 1..2048
User changes BPDUCOP to N
The fault is cleared immediately (interface is
re-enabled) by the system, but the feature is
now disabled.
Fault State
Y
n=0
User changes BPDUCOP to N
The fault is not cleared (user must re-enable
interface), and the feature is now disabled.
Fault State
Y
n = 1..2048
User changes n to 0
Fault is not cleared (user must re-enable
interface), and the fault will not clear automatically the next the feature is invoked.
Fault State
Y
n=0
User changers to a nonzero value
Auto-recovery is being invoked, and once
the command is accepted the system will
wait n minutes and re-enable the interface.
Fault State
Y
n = 1..2048
User changes n to
another value
The previous value is used for system
recovery, and the new value is used the next
time
4.4.11 Configuring BPDU Cop
In the following procedure, STP and BPDU Cop are set up on an interface (0.23 on a GE24POE line card), with at first the
default TIMEOUT value (10) used.
398
Layer Two Switching
TABLE 4-16
Step
Configuration Procedure for BPDU Cop
Command
Ensure that (R)STP is enabled. Note that 0.23 is not included in the interface set.
1
SHOW STP
--- STP Information ----------------------------------------------------Spanning Tree Type...................... RSTP
............................................................
Int
Role
State
Cost Prio.Number
Type
----- ---------- ---------- ---------- ----------- ---------------0.0
ROOT
FORWARDING
20000 128.321
RSTP
0.22 ALTERNATE DISCARDING
20000 128.343
RSTP
1.2
DESIGNATED FORWARDING
2000 128.387
RSTP
1.3
2000 128.388
RSTP
200000 128.1048
RSTP
Enable BPSU Cop for the 0.23 interface
2
SET STP INTERFACE=0.23 BPDUCOP=ON
Enable STP for the 0.23 interface
3
ENABLE STP INTERFACE=0.23
Info (040409): Spanning Tree Protocol operation is now enabled for the
specified interface/interface-list (0.23)
Review the status of the interface
399
Layer Two Switching
TABLE 4-16
Step
Command
4
SHOW STP
--- STP Information -----------------------------------------------------Spanning Tree Type...................... RSTP
(output omitted)
Int
Role
State
Cost Prio.Number
----- ---------- ---------- ---------- ----------0.0
ROOT
FORWARDING
20000 128.321
0.22 ALTERNATE DISCARDING
20000 128.343
200000 128.344
1.2
2000 128.387
1.3
2000 128.388
Type
--------------------RSTP
RSTP
RSTP
RSTP
RSTP
SHOW STP INTERFACE=0.23 FULL
------------- STP Information for Port 0.23 ----------------------------Spanning Tree Instance Name...........
Port ID...............................
Role................................
State...............................
Priority............................
Pathcost............................
(output omitted)
BPDU Cop..............................
timeout.............................
MAIN (0)
33112
DESIGNATED
FORWARDING
128
200000
ON
10
If a loop occurs, BPDU Cop disables the interface, sends a SYSLOG, and raises an alarm.
5
SHOW INTERFACE=0.23
Type...............................
State..............................
Description........................
Remote ID..........................
Card Type..........................
0.23
GE
UP-DN-AutoDisabled
<none>
<none>
<none>
GE24SFP
Interface Faults
Unexpected BPDU Received........ Major
(output omitted)
6
SHOW ALARM
(output omitted)
Fault
Severity
------------ ------------------------------- -------0.1
Loss of Link
Major
0.21
Loss of Link
Major
0.23
Unexpected BPDU Received
Major
Time Stamp
-----------17:55:07 05/21
17:55:07 05/21
10:11:19 05/25
Once the loop is removed, the interface is re-enabled, the fault clears, and traffic resumes after the 10-minute time-out.
Change the TIMEOUT values to 0. With the interface and BPDU Cop enabled, this change is immediate.
7
SET STP INTERFACE=0.23 TIMEOUT=0
If a loop occurs, BPDU Cop disables the interface and it remains disabled.
400
Layer Two Switching
TABLE 4-16
Step
Command
8
SHOW INTERFACE=0.23
Type...............................
State..............................
Description........................
Remote ID..........................
Card Type..........................
0.23
GE
UP-DN-AutoDisabled
<none>
<none>
<none>
GE24SFP
Interface Faults
Unexpected BPDU Received........ Major
Manually re-enable the interface
9
DISABLE INTERFACE=0.23 FORCE
Info (039512): Operation Successful (GE24SFP Slot
ENABLE INTERFACE=0.23
Info (039512): Operation Successful (GE24SFP Slot
0 Port 23)
0 Port 23)
SHOW INTERFACE=0.23
--- GE Interfaces --Interface.......................... 0.23
Type............................... GE
State.............................. UP-UP-Online
(output omitted)
401
Layer Two Switching
4.4.12 Spanning Tree Commands
This subsection provides an alphabetical reference for commands used to configure RSTP, STP or MSTP. For information
about spanning trees, including configuration procedures, see 4.4.
TABLE 4-17
Spanning Tree Commands
Commands
ADD STP INSTANCE VLAN
ADD TRACE STP
CREATE STP INSTANCE MSTID
DELETE STP INSTANCE VLAN
DELETE TRACE STP
DESTROY STP INSTANCE
DISABLE STP
ENABLE STP
RENAME STP INSTANCE
RESET STP
SET STP
SHOW STP
SHOW TRACE STP
402
Layer Two Switching
ADD STP INSTANCE VLAN
Syntax
ADD STP INSTANCE={ stpname | mstid } VLAN={ vlanname | vid-range }
Description
For MSTP. By default, all VLANs (and therefore all ports), belong to the Common STP instance, the
CIST. Once created, VLANs can be associated with the MSTI using this command: (VLANs can also be
dis-associated with the MSTI as well.) The user can continue to associate VLANs with MSTIs until
there are no VLANs associated with the CIST.
Mode
Manager
Options
Option
Description
Range
Default
Value
INSTANCE
The name of the Multiple Spanning Tree instance
(MSTI) to create
NA
NA
VLAN
The name or numerical VLAN identifier.
1-4094
NA
Release Note
NA
Example
ADD STP INSTANCE=mst9 VLAN=420
403
Layer Two Switching
ADD TRACE STP
Syntax
ADD TRACE STP [ INSTANCE={ stpname | mstid | MAIN | ALL } ]
[ EVENT={ BPDU | ALL } ]
[ INTERFACE={ type:id-range | id-range | ifname-list | ALL } ]
Description
Adds filter criteria for which Spanning Tree Protocol traces to generate. BPDU traces can be filtered
by instance, and/or by interface. You then can use the ENABLE TRACE OUTPUT=CLI to view the
output.
Mode
Manager
Options
Option
Description
Range
Default
Value
INSTANCE
The Spanning Tree Instance of the trace
NA
NA
EVENT
The event trace to add. Currently this is only
BPDUs.
NA
ALL
INTERFACE
The interface against which the trace will be
applied.
NA
NA
See Note below when applying this utility to a
LAG.
Release Note
NA
Note
It is possible to reference a LAG, either by name or symbol (e.g. LAG:1) to identify all the member
ports from that LAG as currently defined in the system. However, if the LAG port membership is modified subsequent to that reference, the TRACE STP utility will not include the changes. The user should
make the corresponding updates to the TRACE STP utility (use the ADD TRACE command against the
LAG again) to reflect the updated LAG port membership. Then the SHOW TRACE STP command will
include the updated LAG membership.
Example
ADD TRACE STP LAG:3, LAG:4 << LAG:3 has 6.10, LAG:4 has 6.13
E136 09:33:31>> show trace stp
--- STP Traces ---------------------------------------------------------------Trace
----------------1
Event
----------------BPDU
MSTID
----------------0
Interfaces
----------------6.10, 6.13
-------------------------------------------------------------------------------
404
Layer Two Switching
CREATE STP INSTANCE MSTID
Syntax
CREATE STP INSTANCE=stpname MSTID=1..4094 [ PRIORITY=0..65535 ]
Description
For MSTP, create an STP instance and give it a name as well as ID. VLANs can then be associated with
this instance.
Mode
Manager
Options
Option
Description
Range
Default
Value
INSTANCE
The name of the existing interface that this route will
use. To display interface names, use the IP LIST INTERFACES command.
NA
NA
MSTID
The number to assign (0 is reserved for the CIST).
NA
NA
PRIORITY
Determines the switch's priority for becoming the root
bridge or a designated bridge in the network, with a
lower number indicating a higher priority.
0..65535 for
STP mode
32768
0..65535 in
steps of 4096 in
RSTP or MSTP
modes
Release Note
NA
Example
(Create mstp instance mstd9, mstp and region already set)
officer SEC>> create stp instance mst9 mstid 9
show stp
--- MSTP Configuration Identifier Information ---------------------------------Format Selector................................ 0
Revision Level................................. 10
-------------------------------------------------------------------------------
--- Spanning Tree Instance Summary ------------------------------------------STP Instance
MSTID
STP State
Root Port
Vlan(s) Associated
----------------- -------- --------------- ---------- --------------MAIN
0
DISABLED
NA
1 (2-4094)
mst9
9
DISABLED
NA
None
405
Layer Two Switching
DELETE STP INSTANCE VLAN
Syntax
DELETE STP INSTANCE={ stpname | mstid | ALL } VLAN={ vlanname | vid-range |
ALL }
Description
Disassociates a VLAN (range) with an STP instance. Once all VLANs are disassociated, the instance
can be destroyed.
Mode
Manager
Options
Option
Description
Range
Default
Value
INSTANCE
The spanning tree instance(s) that will have VLANs
removed.
NA
NA
VLAN
The VLAN(s) that will be removed from the instance.
NA
NA
Release Note
NA
Example
DELETE STP INSTANCE=mstd9 VLAN=420
406
Layer Two Switching
DELETE TRACE STP
Syntax
DELETE TRACE STP [ INSTANCE={ stpname | mstid | MAIN | ALL } ] [ EVENT={ BPDU
| ALL } ] [ INTERFACE={ type:id-range | id-range | ifname-list | ALL } ]
Description
Removes specified trace criteria for STP traces.
Mode
Manager
Options
Option
Description
Range
Default
Value
INSTANCE
The instance form which the trace will be deleted.
NA
NA
EVENT
All events or BPDUs
0.0.0.0
0.0.0.0
INTERFACE
The interface(s) where the trace will be removed.
If no IP address is
supplied, the natural mask of the IP
address is used.
If no IP
address is
supplied,
the natural
mask of the
IP address
is used.
Release Note
NA
Example
DELETE TRACE STP INSTANCE 2
407
Layer Two Switching
DESTROY STP INSTANCE
Syntax
DESTROY STP INSTANCE={ stpname | mstid | ALL }
Description
Once all relevant VLANs are disassociated with the STP instance, the Instance itself can be destroyed.
(You cannot destroy to default STP instance, or CIST.)
Mode
Manager
Options
Option
Description
Range
Default
Value
INSTANCE
The instance to be destroyed.
NA
NA
Release Note
NA
Example
DESTROY STP INSTANCE=mstd9
408
Layer Two Switching
DISABLE STP
Syntax
DISABLE STP
[ { [ INSTANCE={ stpname | mstid | MAIN | ALL }
[ TOPOLOGYCHANGE ] ] |
[ INTERFACE={ type:id-range | id-range | ifname-list | ALL } [ TOPOLOGYCHANGE
] ] } ]
Description
Disables Spanning Tree Protocol operations for the system. When this command is issued, all ports in
the system are set to the STP FORWARDING state so that they are traffic capable. The STP port state
displayed for all ports is STP DISABLED to indicate that STP operations are disabled.
Mode
Manager
Options
Option
Description
Range
Default
Value
INSTANCE
The instance to be disabled.
NA
NA
INTERFACE
The interface(s) on which STP will be disabled.
NA
NA
TOPOLOGYCHANGE
Controls the detection of topology changes on the
associated port. This allows the disabling of topology
change detection on ports that are known to be connected to single end stations that could cause the Topology Change Notification mechanism to be triggered for
the entire network when the end station is power
cycled.
NA
NA
Release Note
NA
Example
(Disable instance on all interfaces)
officer SEC>> disable stp int all
Spanning Tree Protocol operation is now disabled for the specified interface/
interface-list (0-3,6-7,9-11.0-3,8.0-23)
409
Layer Two Switching
ENABLE STP
Syntax
ENABLE STP [ {
[ INSTANCE={ stpname | mstid | MAIN | ALL }
INTERFACE={ type:id-range | id-range | ifname-list | ALL } [ { TOPOLOGYCHANGE
| RSTPCHECK } ] ] |
[ INTERFACE={ type:id-range | id-range | ifname-list | ALL } [ { TOPOLOGYCHANGE | RSTPCHECK } ] ] }
Description
Used to enable Spanning Tree Protocol operations for the system. When this command is issued, all
interfaces in the system that have not been identified by the user to be excluded from STP operations
are processed by the Spanning Tree Protocol algorithm (see DISABLE STP for information on interface
exclusion from STP operations).
Mode
Manager
Options
Option
Description
Range
Default
Value
INSTANCE
The instance to be enabled.
NA
NA
INTERFACE
The interface(s) on which STP will be enabled.
NA
NA
RSTPCHECK
The interface can be forced to go for migration
check. This parameter is functional only in the
RSTP and STP_COMPATIBLE_RSTP operational
mode.
NA
NA
TOPOLOGYCHANGE
Controls the detection of topology changes on the
associated port. This allows the disabling of topology
change detection on ports that are known to be connected to single end stations that could cause the Topology Change Notification mechanism to be triggered for
the entire network when the end station is power
cycled.
NA
NA
Release Note
NA
Example
(Enable stp and show the all of the interfaces included)
enable stp
show stp inst all
--- STP Information -----------------------------------------------------------Spanning Tree Type...................... MSTP (CIST)
............................................................
Int
Role
State
Cost Prio.Number
Type
----- ---------- ---------- ---------- ----------- ------------------------0.0
DESIGNATED DISCARDING
2000 128.321
MSTP (boundary)
0.2
2000 128.323
MSTP
1.0
2000 128.385
MSTP
1.1
2000 128.386
MSTP
410
Layer Two Switching
1.2
1.3
2.0
2.1
8.1
9.1
9.3
10.1
10.3
11.1
ALTERNATE
ROOT
BACKUP
BACKUP
DESIGNATED
DESIGNATED
DESIGNATED
BACKUP
BACKUP
BACKUP
DISCARDING
FORWARDING
DISCARDING
DISCARDING
FORWARDING
DISCARDING
DISCARDING
DISCARDING
DISCARDING
DISCARDING
2000
2000
2000
2000
200000
2000
2000
2000
2000
2000
128.387
128.388
128.449
128.450
128.834
128.898
128.900
128.962
128.964
128.1026
MSTP
MSTP
MSTP
MSTP
MSTP
MSTP
MSTP
MSTP
MSTP
MSTP
--------------------------------------------------------------------------------- STP Information ----------------------------------------------------------Spanning Tree Type...................... MSTP (MSTI)
Instance Name......................... mst9 (9)
.....................................................
Int
Role
State
Cost Prio.Number
Type
----- ---------- ---------- ---------- ----------- ------------------------0.0
2000 128.321
MSTP (boundary)
0.2
2000 128.323
MSTP
1.0
2000 128.385
MSTP
1.1
2000 128.386
MSTP
1.2
ALTERNATE DISCARDING
2000 128.387
MSTP
1.3
ROOT
FORWARDING
2000 128.388
MSTP
2.0
BACKUP
DISCARDING
2000 128.449
MSTP
2.1
BACKUP
DISCARDING
2000 128.450
MSTP
8.1
200000 128.834
MSTP
9.1
2000 128.898
MSTP
9.3
2000 128.900
MSTP
10.1 BACKUP
DISCARDING
2000 128.962
MSTP
10.3 BACKUP
DISCARDING
2000 128.964
MSTP
11.1 BACKUP
DISCARDING
2000 128.1026
MSTP
----------------------------------------------------------------
411
Layer Two Switching
RENAME STP INSTANCE
Syntax
RENAME STP INSTANCE={ stpname | mstid } TO=stpname
Description
Rename the STP instance (using the name or id to specify) to another name. When the name is
changed, all the associated interface information is changed as well.
Mode
Manager
Options
Option
Description
Range
Default
Value
INSTANCE
The original instance name.
NA
NA
TO
The new name for the instance.
NA
NA
Release Note
NA
Example
(Renaming mst9 to msttst)
rename stp instance mst9 to msttst
show stp inst all
--- STP Information ---------------------------------------Spanning Tree Type...................... MSTP (CIST)
(information omitted)
--- STP Information --------------------------------------Spanning Tree Type......................
Instance Name.........................
Instance State........................
Regional Root Bridge ID Priority........
Regional Root Bridge ID MAC Address...
Max Age (seconds).....................
MSTP (MSTI)
msttst (9)
ENABLED
9
00:0C:25:04:01:AB
20
2
15
00:0C:25:04:01:AB
20
2
15
Int
Role
State
----- ---------- ---------- ---------- ----------- -----------8.1
200000 128.834
MSTP
412
Layer Two Switching
RESET STP
Syntax
RESET STP [ { INSTANCE={ stpname | mstid | MAIN | ALL } | LEARNCISCODIGEST } ]
Description
Resets the counters for the default STP instance and forces the spanning tree algorithm to restart. This
causes this bridge to temporarily assume the role of “root bridge” and declare all its ports as “designated ports”, as would happen when the bridge is powered cycled or rebooted.
Mode
Manager
Options
Option
Description
Range
Default
Value
INSTANCE
The instance to be reset.
NA
NA
LEARNCISCODIGEST
Specifies the Cisco MST configuration digest for the
bridge that should be copied/stored.
NA
NA
Release Note
NA
Example
RESET STP INSTANCE=msttst
413
Layer Two Switching
SET STP
Syntax
SET STP { INSTANCE={ stpname | mstid | MAIN | ALL } { DEFAULT | PRIORITY=0..65535 |
INTERFACE={ type:id-range | id-range | ifname-list | ALL } { DEFAULT | [ PATHCOST=path-cost ] [ PORTPRIORITY=port-priority ]
[ EDGEPORT={ TRUE | FALSE } ]
[ POINT2POINT={ TRUE | FALSE | AUTO } ]
[ BPDUCOP={ ON | OFF } ] [ TIMEOUT=0..2048 ] } } |
DEFAULT | [ PRIORITY=0..65535 ] [ FORWARDDELAY=4..30 ] [ HELLOTIME=1..10 ]
[ MAXAGE=6..40 ] [ TXMAX=1..10 ] [ MAXHOPS=6..40 ] [ MSTREGION=regionname ] [
REVISIONLEVEL=0..65535 ] [ CISCOCONFIGURATIONDIGEST=hexstring ]
[ CISCOLEARNEDINTERFACE={ type:id | id | ANY } ] |
PROTOCOL={ STP_ORIGINAL | RSTP | STP_COMPATIBLE_RSTP | MSTP |
CISCO_COMPATIBLE_MSTP } [ FORCE ] |
INTERFACE={ type:id-range | id-range | ifname-list | ALL } { DEFAULT |
[ PATHCOST=path-cost ] [ PORTPRIORITY=port-priority ] [ EDGEPORT={ TRUE |
FALSE } ] [ POINT2POINT={ TRUE | FALSE | AUTO } ]
[ BPDUCOP={ ON | OFF } ] [ TIMEOUT=0..2048 ] } }
Description
Allows a user to modify select STP parameters.
Mode
Manager
Options
Option
Description
Range
Default
Value
INSTANCE
The Spanning Tree instance
NA
NA
INTERFACE
The interface(s) selected that will have their settings
modified.
NA
NA
DEFAULT
Resets the STP settings to their defaults.
NA
NA
The default settings are as follows:
- FORWARDDELAY - 15 seconds.
- HELLOTIME
- 2 seconds.
- MAXAGE
- 20 seconds.
- PRIORITY
- FORCE
- 32768.
- RSTP.
PRIORITY
Determines the switch's priority for becoming the root
bridge or a designated bridge in the network, with a
lower number indicating a higher priority.
0..65535
32768
INTERFACE
The interface(s) which are to have their spanning tree
information modified.
NA
NA
PATHCOST
Used if the interface is the root port for the STP on the
switch. The path cost is added to the root path cost field
in configuration messages received on the interface to
determine the total cost of the path to the root bridge.
NA
NA
STP Mode - 1..1000000
RSTP Mode - 1 - 200000000
414
Layer Two Switching
Option
Description
Range
Default
Value
PORTPRIORITY
Used to determine which interface should be the root
port for the STP if two interfaces are connected in a
loop. A lower number indicates the higher priority.
128
128
EDGEPORT
Whether the interface is an edge port. Spanning Tree
protocol will be turned off for the specified interface
TRUE
TRUE
POINT2POI
NT
Interface connection type. whether to treat interface as: a point-to-p connection
auto detection
auto detection
- shared medium connection
- apply automatic detection criteria
BPDUCOP
Enable or disable an interface specific feature that will
detect the receipt of a Spanning Tree Protocol specific
information message (i.e., BPDU) and bring down the
associated interface operationally.
OFF
OFF
TIMEOUT
Controls the automatic recovery of an interface which
has been operationally disabled via the BPDU COP failure detection mechanism. The units for this parameter
are in minutes. If a zero (0) value is entered for this
parameter it indicates that automatic recover has been
disabled.
10 minutes
10 minutes
Note: BPDUCOP must be set to ON. Refer to BPDU
COP.
FORWARDDELAY
Determines how long the interfaces remain in each of the
Listening and Learning states before moving on to the
Forwarding state in the active topology, that is, half the
time between when it is decided that the interface will
become part of the spanning tree, and when it is allowed
to forward traffic.
15 seconds
15 seconds
HELLOTIME
Determines how often the switch sends Hello messages
containing spanning tree configuration information if it is
the root bridge, or is trying to become the root bridge in
the network.
2
2
MAXAGE
Determines the maximum time that dynamic STP configuration information is stored in the switch, before it is
considered too old, and discarded.
20 seconds
20 seconds
TXMAX
The maximum number of BPDUs that can be transmitted
on an interface per second.
TBS
TBS
MAXHOPS
The maximum number of bridges a BPDU can travel
through before aging out.
TBS
TBS
MSTREGION
The MST region name for the bridge, which is used in
conjunction with REVISIONLEVEL and VLAN to MSTI
associations to define the MST region for the bridge.
NA
NA
REVISIONLEVEL
MST revision level for the bridge, which is used to define
the MST region for the bridge.
TBS
TBS
415
Layer Two Switching
Option
Description
Range
Default
Value
CISCOCONFIGURATIONDIGES
T
Specifies the Cisco MST configuration digest to be
backed up or restored from a text config file.
NA
NA
CISCOLEARNEDINTERFACE
The interface that the Cisco MST configuration digest
will be learned on.
NA
NA
PROTOCOL
Identifies which version of the Spanning Tree Protocol to
run, and should be made based upon what version of
Spanning Tree is being run on all the other bridges in the
network.
RSTP
RSTP
- original STP
- Rapid Spanning Tree (RSTP)
- STP compatible version of RSTP.
- MSTP
- CISCO_COMPATIBLE_MSTP
Release Note
NA
Example
(set protocol as mstp)
officer SEC>> set stp protocol mstp
show stp
--- MSTP Configuration Identifier Information ---------------------------------Format Selector................................ 0
Region Name.................................... 00:0C:25:04:01:AB
Revision Level................................. 0
-----------------------------------------------------------------------------
--- Spanning Tree Instance Summary -----------------------------------------STP Instance
MSTID
STP State
----------------- -------- --------------- ---------- ---------------------MAIN
0
DISABLED
NA
1 (2-4094)
416
Layer Two Switching
SHOW STP
Syntax
SHOW STP [ { [ INSTANCE={ stpname | mstid | MAIN | ALL } ] [ INTERFACE={
type:id-range | id-range | ifname-list | ALL } ] [ FULL ] | COUNTER } ]
Description
The SHOW STP command displays the system wide STP information for the bridge.
Mode
User
Options
Option
Description
Range
Default
Value
INSTANCE
The instance that will be displayed.
NA
NA
INTERFACE
The interface(s) that will be displayed.
NA
NA
FULL
Includes all attributes, including the number of topology
changes that have occurred.
NA
NA
COUNTER
Counter information includes transmitted and received
BPDU counts, as well as other count information.
NA
NA
When an interface parameter is specified the counter
values represent the count values for the given interface(s) which contribute to the total system level
counts. When no interface parameter is specified, the
counter values show represent the total system level
counts. (All the counter values are reset to zero when
the RESET STP command is entered.)
Release Note
NA
Example
(shows default at startup)
show stp
--- STP Information ------------------------------------------Spanning Tree Type...................... RSTP
Instance State........................ DISABLED
Max Age (seconds)..................... 20
Bridge ID Priority...................... 32768 (priority 32768 mstid 0)
Bridge ID MAC Address................. 00:0C:25:04:01:AB
Int
Role
State
Cost Prio.Number
Type
----- ---------- ---------- ---------- ----------- -------------------------
417
Layer Two Switching
SHOW TRACE STP
Syntax
SHOW TRACE STP [ INSTANCE={ stpname | mstid | MAIN | ALL } ] [ EVENT={ BPDU |
ALL } ] [ INTERFACE={ type:id-range | id-range | ifname-list | ALL } ]
Description
Displays the current set of trace criteria for STP.
Mode
User
Options
Option
Description
Range
Default
Value
INSTANCE
The instance where the trace will be displayed.
NA
NA
EVENT
Specify whether BPDU or ALL will be shown
NA
NA
INTERFACE
The interface(s) where the trace will be displayed.
NA
NA
Release Note
NA
Example
SHOW TRACE STP
--- STP Traces ---------------------------------------------------------------Trace
-----------1
Event
----------------BPDU
MSTID
--------------0
Interfaces
--------------0.22
------------------------------------------------------------------------------
418
Layer Two Switching
4.5 Ethernet Protection Switched Ring (EPSR) and SuperLoop
Prevention
4.5.1 EPSR Introduction
Ethernet Protection Switched Ring (EPSR) is a protection scheme for Ethernet networks, specifically for ring-based network
topologies. EPSR provides a 50 milliseconds switching time for an Ethernet-based ring network, similar to that provided by
the Synchronous Optical Network (SONET) protocol, to maintain layer 2 redundancy in the network.
EPSR assists the multicast streams in being redirected around a faulty link in a ring network fast enough to result in an uninterrupted multicast service. The EPSR protocol provides fast protection switching to layer 2 switches which are interconnected in an Ethernet ring topology.
Note:
EPSR is only supported on ring topology networks.
EPSR is available only on ring topology networks comprised of nodes that are physically connected to form a ring. Each node
on the ring will have two Ethernet ports connected to the ring. EPSR operates over these Ethernet ports.
4.5.2 Overview of EPSR Configuration
The protection scheme for an Ethernet ring network basically operates by configuring an EPSR domain on the ring. The vlans
that require fault protection are configured on all the ring ports and are assigned to the EPSR domain. All such vlans are
referred to as the protected vlans. Additionally, a control vlan is assigned to the EPSR domain and is used to send and receive
the EPSR protocol control messages over the ring network that are then used accordingly by all the nodes to prevent loops
in the network and ensure that none of the nodes are isolated from the network.
Note:
There can only be one control vlan per EPSR domain and is configured to use tagged frames. This control vlan is
unique to this domain and cannot be re-used for another domain. Also, the control vlan is provisioned to have the
highest priority p-bit setting (as per IEEE 802.1p) and is mapped to the highest priority queue in the system.
One of the nodes in the ring is designated as the MASTER node while all the other nodes are designated as TRANSIT nodes.
For example, in the figures accompanying this text, Allied Telesis System C is designated the master node while all the other
systems are designated transit nodes. One ring port on the master node is designated to be the Primary Port (PP) and the
other ring port is designated to be the Secondary Port (SP).
When the ring is operating normally, the master node blocks its SP port for all data traffic belonging to the EPSR domain, preventing a loop on the ring. The layer 2 Ethernet switching and learning mechanisms operate normally on each of the nodes in
the ring. However, the control vlan traffic is not blocked at the SP port and is allowed to flow through. This does not pose a
problem, because the control messages originate either at a master node or transit node but always terminate at the master
node.
An EPSR ring network is shown in Figure 4-8 below:
419
Layer Two Switching
To / From Network
= Physical Link
2.1
= Control VLAN (V_60)
= Data VLAN (V_80)
0.1
1.1
V_80
= data VLAN is blocked
over Physical Link 3
A
V_60
1
4
0.2
V_80
0.1
V_60
B
A
D
= Devices
1
4
= Links
V_80
V_60
D
1.1
1.2
Master
Node
2
3
1.1
0.2
V_60
C
PP
V_80
SP
EPSR_Topology__non_UFO
FIGURE 4-8
An EPSR Ring Topology (Standard VLAN)
When the master node detects a physical link break in the ring, it unblocks its SP port and allows the flow of data traffic
through the EPSR domain. This mode continues until the master node determines that the break in the ring has been
restored; at which point, it goes back to its normal operating procedure.
4.5.3 EPSR Terms and Definitions
To implement EPSR, the user is required to configure the PP and SP ports and EPSR protocol to support the fault detection
and recovery in the network. Configuration data is as follows:
• Hello Time
The rate at which the EPSR protocol Health control message is sent by the master node for this EPSR domain.
• FailoverTime
Time for which the master node waits before declaring that it has detected a break in the ring for this EPSR domain.
• Flap
The minimum number of seconds that a master node must remain in the failed state (before moving to the complete
state), even if the ring has recovered from its fault condition. This delay is to limit unnecessary blocking and unblocking of
the secondary port when a link in the ring is flapping (intermittently recovering from its fault). The default is 0.
• Ringports
The two ports that are members of the EPSR domain.
• Protected Vlan(s)
The Data vlans which require protection on the EPSR domain.
420
Layer Two Switching
• Control Vlan
The unique vlan which will be used for EPSR messaging for the EPSR domain.
Configuration requirements and commands will be covered in detail later in this section.
Note:
With the Allied Telesis SBx3112, if both fibers are cut on a single node, and one of the fibers is restored, the Allied
Telesis SBx3112 will recover and begin processing traffic. This applies whether the node is a Master Node or
another node on the ring. However, this scenario applies only when both ring ports on the same node have failed.
More complicated failure scenarios are handled by a specific feature, Enhanced Recovery, described in 4.5.6.
4.5.4 EPSR Protocol
The EPSR protocol is used to provide the EPSR functionality in Allied Telesis layer 2 systems. EPSR protocol control messages
are transported around the ring network for an EPSR domain via its control vlan. The messages can originate at the master
node or at the transit node; however, they will always terminate at the master node. These messages are used to provide fast
protection switching, for a given EPSR domain, in the layer 2 systems interconnected to form the Ethernet ring.
An Allied Telesis system with EPSR implemented can be part of more than one ring network. As a result, there can be more
than one EPSR domain on such a system, one for each of the EPSR protected rings of which it is a member. Note that there
can also be more than one EPSR domain running in a system when it is part of only one ring network, with each domain
assigned its own set of protected vlans. This helps manage the bandwidth available in the ring, with some data traffic going
one way around the ring and other data traffic going the other way around the ring, depending on which domain the data vlan
is on.
4.5.4.1 EPSR Protocol Procedures
The master node and the transit nodes that make up the Ethernet ring use the Fault Detection and Fault Restoration procedures provided by the EPSR protocol to maintain the continuous flow of the non-control traffic in the ring.
1.
Fault Detection Procedure - Two kinds of fault detection procedures are defined to detect a fault. The polling procedure
is the fail-safe mechanism executing in the master node in case the unsolicited fault message procedure in a transit node
fails
• Master Node Polling Fault Detection Procedure (4.5.4.2)
• Transit Node Unsolicited Fault Message Fault Detection Procedure (4.5.4.3)
2.
Master Node and Transit Node Fault Detected Correction Procedure (4.5.4.4)
3.
Fault Restoration Procedure (4.5.4.5)
• Master Node Restoration Procedure
• Transit Node Restoration Procedure
Each of the above procedure are discussed in the following subsections.
4.5.4.2 Master Node Polling Fault Detection Procedure
The master node uses the polling procedure as a fail-safe mechanism to detect a fault in the ring. It does this by sending an
EPSR health control message via its PP port (only) every HELLOTIME seconds (which is a configured value as seen earlier).
Under normal conditions, when there is no fault in the ring, this health message will make it across the network and will be
received by the master node over its SP port. However, if there is a fault anywhere in the network, the health message will
not be received by the master node over its SP port. To detect this condition, the master node starts a failover timer (using
the configured FAILOVERTIME) every time it sends the health message. If the health message is not received by the master
node over its SP port before the failover timer expires, then it declares a fault in the ring and takes appropriate measure.
Note:
Because of the fact that messages could get lost in the network, the FAILOVERTIME configured value must be at
least twice the value of the HELLOTIME configured value.
421
Layer Two Switching
4.5.4.3 Transit Node Unsolicited Fault Message Fault Detection Procedure
Unlike the polling procedure described above, where the burden is upon the master node to eventually detect a fault in the
ring in a fail-safe manner, this procedure is used by the transit node to detect a fault on its attached ring port and immediately
notify the master node of the fault. This is accomplished by sending an EPSR Links-Down control message over a functioning
link. A fault link spans two nodes; therefore, both of the transit nodes that detect the fault send the EPSR Links-Down control message to the master node. When this occurs, the transit node(s) in question alter the state of the EPSR domain from
Links-Up state to Links-Down and maintains this state until the transit node Fault Restoration procedures are executed.
Also, the state of the faulty port is set to Blocked. However, the state of the functioning ring port is maintained at Forwarding.
4.5.4.4 Master Node and Transit Node Fault Detected Correction Procedure
When the master node detects a fault in the ring using either of the above described procedures, it takes the following
actions:
• Declares the EPSR domain to be in a failed state (from the complete state the EPSR domain was in before the fault was
detected).
• Unblocks its SP port for the Data traffic for this EPSR domain
• Flushes its own forwarding database (FDB) for just the two ring ports
• Sends an EPSR Ring-Down-Flush-FDB control message to all the transit nodes via both its PP port and SP port.
As the EPSR domain non-control traffic starts flowing, each of the nodes (both master and transit) then re-learn the layer 2
addresses on the flushed ring ports again to reflect the newly collapsed network topology. The master node continues to follow the Master Node Polling Fault Detection Procedure and as long as the fault is still present in the ring, the EPSR domain
will continue to remain in the failed state. This newly constructed network topology exists until the fault in the ring is corrected; then the fault restoration procedures take over and restore the ring to its original normally operating state.
The EPSR stabilized topology under normal operating conditions is shown in Figure 4-8. For a link fault detected between
Allied Telesis System A and Allied Telesis System B, Figure 4-9 shows the new EPSR stabilized topology after the fault detection and corrections procedures have been executed.
422
Layer Two Switching
To / From Network
= Physical Link
= Data VLAN (V_80)
2.1
= Physical Link 1
is blocked, so Device
A and B report break
to Master Node C
1.1
0.1
V_80
A
V_60
1
4
0.2
0.1
B
V_80
V_60
B
A
D
= Devices
1
4
= Links
V_80
V_60
D
1.1
1.2
Master
Node
2
3
Data VLAN is
unblocked
PP
1.1
0.2
V_60
C
V_80
SP
EPSR_Topology_50_Post_Fault
FIGURE 4-9
An EPSR stabilized Network after Ring Fault (Standard VLAN)
4.5.4.5 Master Node Fault Restoration Procedure
When the fault in the ring between Allied Telesis System A and Allied Telesis System B is fixed, the polling EPSR Health control message that was being sent by the master node over its PP port (sent even when the fault is present) is now received
over its SP port. The master node then takes the following actions to restore the ring back from that shown in Figure 4-9 to
its original normally operating state.
1.
Declares the EPSR domain to be in a complete state from the failed state it was in before the fault was corrected.
2.
Blocks its SP port for data VLAN traffic for this EPSR domain.
3.
Flushes its own forwarding database (FDB) for the two ring ports.
4.
Sends an EPSR Ring-Up-Flush-FDB control message to all the transit nodes via both its PP port and SP port.
As the EPSR domain non-control traffic starts flowing again, all nodes (both master and transit) then re-learn the layer 2
addresses again to reflect the newly complete network topology. The master node continues to follow the Polling Fault
Detection procedure and, since the fault is no longer present, the EPSR domain continues to remain in the complete state
The network topology, restored to its normally operating state, continues to operate until a fault is detected, when, again,
the above mentioned procedures are re-executed. EPSR maintains a continuous, uninterrupted operation of the user’s network.
4.5.4.6 Transit Node Fault Restoration Procedure
The transit node(s) that span the faulty link will delay the starting of the flow of data traffic over the link once the fault has
been fixed and the link restored. The reason for this delay is to prevent the master node from viewing the fixed link as a loop
in the network. The loop is caused because the transit node has corrected the fault for the domain before the master node
detects that the fault is restored and blocks its SP port for the domain’s data traffic. In order to avoid this situation, the transit node(s), after detecting that the broken link has been restored, follow these fault restoration procedures:
423
Layer Two Switching
1.
Ensure that the protected vlans are still in a blocked state for the repaired port. The state of the restored port was set as
blocked earlier when the state of the domain went from Links-Up to Links-Down
2.
Change the state of the EPSR domain from Links-Down to Pre-forwarding
3.
Wait for the EPSR Ring-Up-Flush-FDB control message from the master node. This is the trigger that ensures that the
master node has detected the restoration of the fault in the ring, flushed its FDB, and blocked its SP port for the domain
non-control traffic.
4.
Flush its FDB, for both the ring ports, upon receiving the above trigger message from the master node
5.
Change the state of the EPSR domain from Pre-Forwarding to Links-Up when the flow of the domain non-control
traffic can start to flow again ensuring that there is no loop present in the ring. At this point, the state of the port is set to
Forwarding.
4.5.5 Dual Ring Configuration
The discussion above had an underlying assumption that there is an Ethernet ring access network consisting of Allied Telesis
systems that are physically connected to form a ring using EPSR functionality to provide redundancy at the layer 2 level. The
master node in this EPSR-enabled ring network is the one which is considered to be the layer 2 aggregating switch with an
uplink to the core. However, there could be a case where the access network consists of multiple rings, interconnected to
form a more complex access network with uplinks to the core network. An example of such a network is shown in Figure 410.
424
Layer Two Switching
To / From Network
0.3
PP
SP
Master
Node
A
0.2
0.1
V_80
V_60
4
1
0.2
0.1
B
V_80
D
V_60
A
D = Devices
1
4
0.1
0.2
2
3
Data VLAN is
unblocked
V_60
0.1
C
0.2
= Physical Link
= Data VLAN (V_80)
= Data VLAN (V_80)
V_80
= Data VLAN on Physical SP
Link 1 is blocked
= Data VLAN on Physical
Link 5 is blocked
0.4
0.3
PP
V_90
5
8
0.2
0.1
E
V_80
V_80
V_60
= Links
V_90
C
D = Devices
1
4
G
V_80
V_90
= Links
0.1
0.2
6
7
0.2
0.2
V_90
F
V_80
EPSR_Topology_Dual_UFO
FIGURE 4-10
Configuration of Ring Ports in Interconnected EPSR Ring Networks
One of the systems, Allied Telesis System C, is common to Ethernet access ring Networks 1 and 2. As indicated, this system
is a master node for ring network 1 and a transit node for the ring network 2. System A in ring network 2 is the master
node for that ring. The remainder of the systems in both networks are considered to be transit nodes.
The initial configuration of the FORWARDING parameter is set using the SET VLAN INTERFACE command for the ports
in all the systems in both networks. Note that the master node ports are manually configured as upstream or downstream and remain so, whereas the transit node ports could be configured as UCP - eventually stabilizing as upstream or
downstream as the topology dictates.
425
Layer Two Switching
4.5.6 Enhanced Recovery (Multiple Link Failure)
The fault detection and recovery procedure described in 4.5.4 hold true when there is a single link failure in the network. In
case of multiple link failure, one or more of the transit nodes can become isolated and remain in isolation even after the
recovery of one or more failed links; these recovered links could have provided some level of connectivity to the node, if not
for concern over network loops. Refer to the following figure, which shows a multiple link failure scenario.
To / From Network
= Physical Link
= Data VLAN (V_80)
2.1
1.1
V_80
0.1
SP
A
PP
V_60
1
6
Master
Node
0.2
2.1
B
V_80
V_60
B
A
F
= Devices
1
6
= Links
D
V_80
V_60
F
1.1
0.2
2
X
X
515
0.2
1.2
B
V_80
B
V_60
V_80
V_60
E
1.0
0.1
X
C
4
V_60
1.1
0.2
3
D
V_80
FIGURE 4-11
EPSR Network with Multiple Link Faults
In this network, systems C, D and E are isolated from the core network. Moreover if link 5 between system E and F is
restored, there is no Ring-Up-Flush FDB message, the ports on link 5 cannot be changed to Forwarding, and systems D and
E will still be cut off from traffic, even though link 5 is restored.
The Enhanced Recovery feature changes the processing of this condition in both the Master and Transit nodes so that some
additional network connectivity can be restored when one or more links in a multiple-link failure are restored, but there is
still at least one link that has not been restored.
426
Layer Two Switching
When the Master and Transit nodes are operating in Enhanced Recovery EPSR mode, a Transit node that has recovered its
failed ring port and has its other port in a non-failed state will send a message (called a Link-Forward-Request message
or LFR message) to the Master node that it has recovered its failed port. When the Master node receives this message, it
starts a Link-Forward-Request-Process timer, or LFRP timer (fixed at 4 seconds). If the timer expires and the Master node
has not been able to recover the ring from the multiple-link failure, the Master mode sends a message back to this Transit
node that it can safely restore traffic on its recovered link.
Note:
If the Transit node has both ring ports in a failed state and one port recovers, the Transit can safely enable traffic on
the one recovered port since it knows the ring is not yet a loop because of the other port’s failed state.
If the multiple link failure condition is resolved and the Master Node is able to restore the normal ring before the 4-second
LFRP timer expires, it sends out its normal “Ring-Up-Flush-FDB” message, and the recovery procedure described in 4.5.4.6 is
followed.
When the Transit node sends the LFR message asking if it can recover traffic on its restored link, it also starts an LFR timing interval (fixed at 6 seconds). If this timer expires and the Transit node has received from the Master Node neither a
message that it can recover its failed link nor a Ring-Up-Flush-FDB message, it will resend the message asking that it restore
message to its recovered link.
Note:
The scenario described above is labeled EPSR+, and it assumes that there is communication between the Transit
node with the recovered port and the Master node.
It is also possible that the Master node may be in a failed state or is unreachable. In this scenario, when the Transit node
resends the LFR message asking that it restore its recovered link and does not receive a response, the Transit node will go
ahead and begin traffic on its recovered port.
Note:
This scenario, in which the Transit Node cannot communicate with the Master node and still begins traffic on its
recovered port, is labeled EPSR++.
The Transit node will continue to pass traffic over its recovered ports until communication with the Master node is restored.
At this point, the Master node will send out its normal “Ring-Up-Flush-FDB” message, and the recovery procedure described
in 4.5.4.6 is followed.
This feature is activated with the parameter ENHANCEDRECOVERY, that is added to the existing EPSR command CREATE
EPSR MASTER | TRANSIT.
The ENHANCEDRECOVERY parameter is also added to the SET EPSR and SETDEFAULTS EPSR.
4.5.7 Log Output for EPSR
The user can configure log output to capture logs that monitor the EPSR and can track any change of state. (Refer to the Log
Management section.) As well as the CFCP category, there is the EPSR category that includes a reason for the failed domain.
The following output includes the EPSR category:
===
Start of logs
===
CLI001 2012-03-21 07:45:19
1571 INFO
User: "officer" at IP: "10.52.19.13" entered CLI command:
SHOW EPSR=e8
CFCP014 2012-03-21 07:45:05
1570 INFO
Domain
: e8
Description: Master Node EPSR State Change
Old State : Failed
New State : Complete
CLI001 2012-03-21 07:44:41
1569 INFO
427
Layer Two Switching
SHOW LOG CATEGORY=epsr
CLI001 2012-03-21 07:44:38
1568 INFO
SHOW EPSR=e8
CFCP014 2012-03-21 07:44:35
1567 INFO
Domain
: e8
Old State : Complete
New State : Failed
** EPSR000 2012-03-21 07:44:35
1566 INFO
Failed Domain : e8
Failure Reason: Ring failed due to loss of health messages
<<< removed ring port from control vlan on Transit node >>>
CLI001 2012-03-21 07:44:02
1565 INFO
SHOW EPSR=e8
CFCP014 2012-03-21 07:43:59
1564 INFO
Domain
: e8
Old State : Failed
New State : Complete
CLI001 2012-03-21 07:42:23
1563 INFO
SHOW LOG CATEGORY=epsr
CFCP014 2012-03-21 07:42:19
1562 INFO
Domain
: e8
Old State : Complete
New State : Failed
** EPSR000 2012-03-21 07:42:19
1561 INFO
Failed Domain : e8
Failure Reason: Ring failed due to receipt of Link Down message
<<< disabled port between Master and Transit node >>>
428
Layer Two Switching
4.5.8 Configuring EPSR
When an SBx3112 switch is initially booted up, EPSR will be configured as follows:
• There are no EPSR domains configured.
• Enhanced Recovery is not active (ENHANCEDRECOVERY=OFF).
• Enhanced Recovery survives restarts and upgrades.
• When used with BFD, a maximum of 64 domains, with up to 50 protected VLANs per domain, can be provisioned for
EPSR. (Refer to 7.7 for a description of BFD.)
• When provisioning EPSR on a ring, the user should avoid creating any network loops. There are many ways to configure a
network in a ring topology without producing a loop within the network. Some of these approaches can involve disabling
one of the ring's links while configuring the EPSR domains and the protected VLANs; however, disabling one of the ring's
links may not be an acceptable approach because doing so removes the ring's redundancy while provisioning. Another
approach is to add the vlans to the EPSR domain first, and then add the vlans to the interfaces.
• When provisioning a system, the user can fill in the attributes “name” and “location” to identify the system. These are for
administrative purposes and do not affect the working of EPSR.
• To prevent system isolation, the SP and PP ports should be configured on different cards.
• As mentioned in 4.5.3, the ringFlapTimer is needed to prevent unnecessary opening and closing of the Secondary port
when a link in the ring is flapping, and is started when the Master node moves into the failed state. The master cannot
come out of the failed state until the ringFlapTimer expires even if it detects that the ring is complete. The ringFlapTimer
defaults to zero. It is recommended that you set this to a non-zero value if there are many EPSR domains, many protection vlans, and/or BFD enabled on EPSR interfaces. The actual value will depend on your specific network.
• Because of MAC Thrash Limiting, there is a further restriction to using different cards for the PP and SP ports on the
Master Node:
• If the Enhanced Recovery feature is configured (refer to 4.5.6), you must use different cards for the SP and PP ports.
• If the SP and PP ports are configured on the same card, you cannot use the Enhanced Recovery feature.
Note:
With the MAC Thrash Limiting Feature, just one duplicate MAC address on an intracard interface will disable
learning and cause VLAN flooding of traffic on EPSR ring ports. Also, with EPSR+/++, the Transit Node sends the
(same) LFR message to both the PP and SP of the Master Node. If the PP and SP are on the same card of the Master
Node, MAC Thrash Limiting will see this as a learning violation.
4.5.8.3 Feature Interactions for Enhanced Recovery
• To work with other vender EPSR products based on the RFC3619 which do not recover from multiple link failure, the
CREATE EPSR or SET EPSR commands enable the feature on per EPSR domain. Moreover, this feature must be enabled
on the Master node and all the Transit nodes (e.g., SET EPSR=ALL ENHANCEDRECOVERY=ON command).
• With ENHANCEDRECOVERY=ON for all nodes in the ring, ensure that on the Master Node RINGFLAPTIME is set to
0 (the default) to avoid the possibility of creating a loop. (Refer to 4.5.3 and SET EPSR.)
• There are restrictions on using Enhanced Recovery and SuperLoop. Refer to 4.5.12
• The LFRP timer and LFR timing interval are fixed at 4 and 6 seconds respectively, and cannot be changed.
4.5.9 EPSR Interoperability
Allied Telesis EPSR is based on RFC3619 - Extreme Networks'™ Ethernet Automatic Protection Switching (EAPS)1 Version 1
whether as the Master or Transit node and can interoperate with Extreme Networks’ switches that also supports EAPS.
429
Layer Two Switching
When Extreme is the master, ensure that the following configuration is completed on the Extreme EAPS master switch:
config eaps name failtime expiry-action actionvalue
name is the domain name the Extreme is the master for and the actionvalue specifies the action taken by the master when
the failover timer expires. actionvalue can be either open-secondary-port or send-alert.
In order to ensure that the Extreme Networks’ switch interoperates with the SBx3112, use the following command for configuring domains where Extreme is the master:
config eaps name failtime expiry-action open-secondary-port
Caution: DO NOT set the expiry-action in the above command to send-alert. If expiry-action is set to send-alert, the
Extreme master will not be fully interoperable, which can cause a segment of the ring to be isolated under certain
failure conditions.
The following tables shows the basic steps to configure a Master Node (Device C Figure 4-9) Table 4-17 and a Transit Node
(Device B Figure 4-9) Table 4-18 with:
•
•
•
•
The EPSR domain name is allied.
The CONTROL VLAN is 60, the DATA VLAN is 80.
The interfaces on all devices are on separate cards.
The interfaces are all configured as network interfaces.
TABLE 4-18
Step
Configuration Procedure for EPSR - Configure a Master Node
Command
Description/Notes
Create the EPSR domain
1
CREATE EPSR=allied MASTER ENHANCEDRECOVERY=ON
ENHANCEDRECOVERY is optional; it can also
be set later using the “SET EPSR” command.
Set the GE interfaces to have a direction of NETWORK facing.
2
SET INTERFACE=0.2,1.1 GE DIRECTION=NETWORK
GE interfaces are CUSTOMER facing by default
and XE interfaces are NETWORK facing by
default. EPSR interfaces must be NETWORK
facing.
Create the Control VLAN and associate it with the EPSR interfaces as FRAME=TAGGED
3
CREATE VLAN=V_60 VID=60
ADD VLAN 60 INTERFACE 0.2,1.1
FRAME=TAGGED
To prevent system isolation in the event of a
card failure EPSR interfaces should be on separate cards.
Define the interface for the EPSR domain that will be PRIMARY and SECONDARY
4
ADD EPSR ALLIED INTERFACE=0.2 TYPE=PRIMARY
ADD EPSR ALLIED INTERFACE=0.3 TYPE=SECONDARY
Add the CONTROL VLAN to the EPSR domain
5
ADD EPSR=allied VLAN=60 TYPE=CONTROL
Enable the EPSR domain
6
ENABLE EPSR=allied
1. Extreme Networks is a registered trademark of Extreme Networks, Inc. All Rights Reserved
430
Layer Two Switching
TABLE 4-18
Step
Configuration Procedure for EPSR - Configure a Master Node
Command
Description/Notes
Create the DATA VLAN and add the VLAN to the EPSR domain.
7
You will receive a warning that the VLAN does
not have any ports associated with it. Adding
the VLAN to the EPSR Domain first then to the
interface will prevent network loops on this
VLAN.
ADD EPSR=allied VLAN=80 TYPE=DATA
Add the Data VLAN to the interfaces.
8
ADD VLAN=80 INTERFACE=0.2,1.1 FRAME=TAGGED
SHOW the status of the EPSR domain.
9
officer SEC>> show ep allied
--- EPSR Domain Information --EPSR Domain Name......................
EPSR Domain Node Type.................
EPSR Domain State.....................
MAC Address of Master Node............
EPSR Domain Status....................
Control Vlan..........................
Enhanced Recovery.....................
Primary Interface.....................
Physical State of Primary Interface...
Primary Interface Type................
Primary Interface State...............
Primary Interface Priority............
Primary Interface Priority Rank.......
Secondary Interface...................
Physical State of Secondary Interface.
Secondary Interface Type..............
Secondary Interface State.............
Secondary Interface Priority..........
Secondary Interface Priority Rank.....
Hello Timer (seconds..................
Failover Timer (seconds)..............
RingFlap Timer (seconds)..............
Hello Time Remaining (seconds)........
Failover Time Remaining (seconds).....
RingFlap Time Remaining (seconds).....
Hello Sequence........................
Data Vlans............................
allied
Master
COMPLETE
00:0C:25:00:05:AD
Enabled
60
ON
ETH:[0.2]
UP
DOWNSTREAM
PHYSICALLY FORWARDING
0
0
ETH:[1.1]
UP
DOWNSTREAM
PHYSICALLY BLOCKED
0
0
1
2
0
1
0
0
809
80
431
Layer Two Switching
TABLE 4-19
Step
Configuration Procedure for EPSR - Configure a Transit Node
Command
Description/Notes
Create the EPSR domain
1
CREATE EPSR=allied TRANSIT ENHANCEDRECOVERY=ON
ENHANCEDRECOVERY is optional; it can also
be set later using the “SET EPSR” command.
Set the GE interfaces to have a direction of NETWORK facing
2
SET INTERFACE=0.2,1.1 GE DIRECTION=NETWORK
GE interfaces are CUSTOMER facing by default
and XE interfaces are NETWORK facing by
default. EPSR interfaces must be NETWORK
facing.
Create the Control VLAN and associate it with the interfaces as FRAME=TAGGED
3
FRAME=TAGGED
The interfaces should be on separate cards.
Add the interfaces to the EPSR domain
4
ADD EPSR=allied INTERFACE=0.2,1.1
Add the CONTROL VLAN to the EPSR domain
5
ADD EPSR=allied VLAN=60 TYPE=CONTROL
Enable the EPSR domain
6
ENABLE EPSR=allied
Create the DATA VLAN and add the VLAN to the EPSR domain.
7
ADD EPSR=allied VLAN=80 TYPE=DATA
You will receive a warning that the VLAN does
not have any ports associated with it. Adding
the VLAN to the EPSR Domain first then to the
interface will prevent network loops on this
VLAN.
Add the DATA VLAN to the interfaces
8
ADD VLAN=80 INTERFACE=0.2,1.1
FRAME=TAGGED
432
Layer Two Switching
TABLE 4-19
Step
Configuration Procedure for EPSR - Configure a Transit Node
Command
Description/Notes
SHOW the status of the EPSR domain
9
officer SEC>> show ep allied
Control Vlan..........................
Ring Interface # 1....................
Physical State of Ring Interface # 1..
Ring Interface # 1 Type...............
Ring Interface # 1 State..............
Ring Interface # 1 Priority...........
Ring Interface # 1 Priority Rank......
Ring Interface # 2....................
Data Vlans............................
allied
Transit
LINKS-UP
00:0C:25:00:AA:80
Enabled
60
ON
ETH:[0.2]
UP
DOWNSTREAM
LOGICALLY FORWARDING
0
0
ETH:[1.1]
UP
UPSTREAM
0
0
80
433
Layer Two Switching
4.5.11 SuperLoop Prevention
With interconnected topologies, it is possible to have a condition called a SuperLoop, if all of the following conditions exist.
• The network has two or more EPSR domains.
• The protected (data) VLAN overlaps two or more EPSR domains.
• The EPSR domains and the overlapping protected VLANs share a common link.
4.5.11.1 Overview of EPSR SuperLoop Ring Port Priority Configuration
To prevent a SuperLoop condition from occurring, the concept of certain ring interfaces having a specified priority is used.
This priority is assigned to the interfaces that make up the common link shared by EPSR domains. The value range is 0 to 127.
By default, the priority of each of the ring interfaces for an EPSR domain is 0 (the lowest priority). The higher values, however, are used when there are interconnected EPSR rings in which the SuperLoop condition needs to be avoided.
To use the priorities, the user should take the following steps:
1.
Review the network topologies and see which ring segments have conditions in which the SuperLoop condition could
occur.
2.
Assign these ring segments a unique priority number. The user should start with 127 for the ring segment that is closest
to the upstream network and go down in intervals of 1 (127, 126, 125..) for the ring segments as they go farther away
form the upstream network.
3.
Assign the interfaces for the common link with the priority of the ring segment.
4.
Assign the interfaces for the master node with the priority of the ring segment.
The following figures show the result of taking these steps.
Figure 4-12 shows a sample interconnected topology where priorities have been configured. Also, a nested ring has been
included. Ring 1 is closest to the upstream network and is therefore assigned priority 127. For the control VLAN (V_60), this
priority has been assigned to the master node interfaces and the common link interfaces. Ring 2 has priority 126 and its control VLAN (V_90) has this priority assigned to its master node and common link interfaces. Ring 3 (the nested loop within
ring segment 2) has priority 125 and its control VLAN (V_40) has this priority assigned to its master node and common link
interfaces.
Figure 4-13 shows what happens when there is a fault with the common link. Since ring segment 1 has the higher priority on
the interface, it will unblock its SP interface, but the lower priority ring segments 2 and 3 will not. As a result, the SuperLoop
condition is prevented.
Caution: As long as a fault exists in the common link, the lower priority masters will continue to block their SP interfaces,
even if another fault occurs in the high priority ring. This could result in loss of service for some nodes in the
lower priority rings.
434
Layer Two Switching
Note 1
= Interface priorities of Master Node
and common link interface match
Note 2
= Interface priorities of Transit Nodes
not including common link are 0
(default value)
To / From Network
= Physical Link
0.3
= EPSR Blocking
0.2
0.1
V_80
V_60
Note 2
Note 1
SP
= Ring 1 Control VLAN (V_60)
= Data VLAN (V_80)
127
0.2
V_80
0.1
Master
Node
(M1)
V_60
0.1
PP
V_80
V_60
0.2
127
0.1
127
126
126
V_90
V_90
125
1.1
125
1.0
V_80
0.3
0.1
0.3
V_80
Note 2
0.2
V_60
127
0.1
0.2
V_60
V_40
V_40
Note 1
Note 1
Master Node
(M3)
125
125
0.2
0.2
0.1
V_40
0.1
V_80
V_80
V_90
V_90
Note 1
0.1
Note 1
Master
Node
(M2)
126
V_80
0.2
126
SP
FIGURE 4-12
0.2
0.2
V_90
V_80
PP
EPSR_Topology_SuperLoop_nested
Ring Interface Priorities - Ring Segments
435
Layer Two Switching
To / From Network
= Physical Link
Note 1= Only SP interface of highest
priority is unblocked, so no
superloop created
0.3
= EPSR Blocking
Note 1
0.2
0.1
V_80
V_60
Note 2
Note 1
SP
= Data VLAN (V_80)
127
0.2
V_80
0.1
Master
Node
(M1)
V_60
0.1
126
V_90
1.0
125
V_40
126
V_90
125
V_40
Master Node
(M3)
125
0.2
V_80
0.3
0.1
Note 2
0.3
V_80
V_60
127
1.1
127
0.1
V_60
0.2
0.1
X
127
0.2
PP
V_80
V_60
125
0.2
0.2
0.1
V_40
0.1
V_80
V_80
V_90
V_90
Master
Node
(M2)
0.1
126
V_80
0.2
126
SP
FIGURE 4-13
0.2
0.2
V_90
V_80
PP
EPSR_Topology_SuperLoop_nested_Break
Ring Interface Priorities - only Highest Priority Unblocks and Prevents SuperLoop
436
Layer Two Switching
4.5.11.2 Feature Interaction
The following features support SuperLoop prevention
• In the output, the Data Vlan Countcolumn shows how many protected VLANs are included in the EPSR domain.
• For the SHOW EPSR command, the user can easily determine Non-peer SuperLoop and Peer SuperLoop configurations.
• The parameter PRIORITY is available in the ADD EPSR INTERFACEand SET EPSR commands.
4.5.12 SuperLoop Configuration Requirements
4.5.12.1 Configuration Rules
Since a control VLAN can have many associated data VLANs, and common links can span multiple ring segments, understanding and then configuring a system with common links with shared data VLANs can become complex. The following rules
should be kept in mind when designing the domains with common links and shared data VLANs.
1.
It is possible that two or more domain instances could share a common link and the same data VLAN(s), and yet each
domain could still have its own unique set of data VLANs. To prevent this configuration, note the following:
Note:
2.
The network should be configured such that domain instances sharing a common link should have their data VLANs
segregated; domains should either have a unique set of data VLANs (so no data VLANs are shared with other
domains) or have domains that share data VLANs should have only those shared data VLANs in them. This is
enforced through the CLI, and is explained in more detail in the subsection on the example configuration.
No two domain instances with a common ring port with shared data VLANs can have the same priority value on the
common interface.
Note:
If the user tries to do this, the CLI will fail the command, and the domain(s) cannot be enabled.
3.
The user should avoid defining any of the overlapping domains with a Master node on the common link between the two
domains. (This rule is followed in the configuration in Figure 4-12.) If it is necessary that a Master node be defined on a
common link (e.g., where an "inner core" ring is surrounded on all sides by other EPSR rings), the common link where the
secondary port is defined for the Master node must not be shared with a domain of higher relative priority (i.e. the Master node can only be defined with its secondary port on a common link which is shared with a lower priority domain).
The configuration in Figure 4-13 would break this rule; if a Master node on either side of the common link were defined,
the domain with the higher priority (127) would have to be configured with its Secondary Port on the ring port which is
not the common link.
4.
In a Superloop configuration, EPSR Enhanced Recovery Mode (4.5.6) should not be used; when the lower priority ring of
a Superloop configuration has more than one link failure, and one of those failed links is a common segment and the
other is not on a common segment, the Master node on that lower priority ring will open up its secondary port to traffic
flow (since it will receive a Link Down message for the non-common segment Transit node). If the non-common link is
then recovered from the failed state, it will transition its recovered ring port to a forwarding state, either due to response
from the Master node with a PLF message when it receives a Link-Forward-Request (LFR) from the transit node, or due
to timeout if no response is received from the Master node. In this case, with a common segment still failed, a Superloop
would be formed.
5.
To configure xSTP and a SuperLoop configuration in a network, refer to 4.5.15 and its rules on EPSR/xSTP coordination,
since SuperLoop is an interconnected EPSR configuration
4.5.12.2 Interoperability (General)
1.
The SuperLoop feature will interoperate with any third party switches that have implemented RFC 3619 as part of the
network, provided that those third-party switches are not:
• Configured as a Master node for a domain with a common link
• Located on either end of a common link within the SuperLoop topology.
437
Layer Two Switching
2.
Any Network Access product which is running software that includes the SuperLoop feature can be placed anywhere in
the SuperLoop ring topology (i.e., regardless of whether it is adjacent to a common link or not).
3.
Any Network Access product which does not have the SuperLoop feature included in the software it is running cannot
act as a Master node for a domain with a common link or as a transit node on either end of a common link when placed
within a SuperLoop ring topology.
4.
A traditional (non-SuperLoop) EPSR ring network (made up of Network Access products and/or third party switches)
can subtend from any node that is part of an EPSR SuperLoop network topology and is not required to have the SuperLoop feature running in any of the nodes in that subtended ring.
4.5.12.3 Interoperability (Extreme Products)
The SBx3112 contains processing to allow for increased interoperability with Extreme Networks products that are running
Extreme Networks proprietary “EAPS Shared-Ports protocol” in a network topology similar to the SuperLoop topologies
discussed in this Section.
In this scenario, an Extreme Networks product is located on each end of the common link, with one configured as “Controller” and the other as “Partner”. Processing is provided by the Network Access products to be compatible with the Extreme
Networks products in this configuration provided the following restrictions are applied:
• The SBx3112 can only operate as a Transit node anywhere within any of the rings sharing a common link that are running
Extreme Networks proprietary “EAPS Shared-Ports protocol”.
• The SBx3112 cannot be configured as either the “Controller” or the “Partner” nodes which are located on either end of
the common link, anywhere within any of the rings sharing a common link that are running Extreme Networks proprietary “EAPS Shared-Ports protocol”.
4.5.12.4 SuperLoop with Complex Topologies (EPSR Logical Domain Types)
As a result of the SuperLoop feature, there arethree types of EPSR logical domains:
• Non-SuperLoop Domain -The configuration rules are
• A protected VLAN canbe shared by two or more domains, but a Common Link is not allowed.
• A Common Link cannot be configured between two systems.
• Non-peer SuperLoop Domains - In this configuration, a SuperLoop domain is one which is part of a physical ring segment that shares a Common Link with another ring segment. However, these domains are considered as non-peer
because each domain does not share the same protected VLANs with the other(s). From the protocol viewpoint, this
behavior is the same as the Non-SuperLoop.The priority of the shared ring port of the domains is set to 0.
• Peer SuperLoop Domains - This is one which is part of a physical ring segment that not only shares a common link
with another segment but also has the same set of protected data vlans as all the other “peer SuperLoop” domains in
the SuperLoop topology part (the SuperLoop nodes is part of) of the interconnected EPSR access network. Moreover,
the priority value of the shared ring port must be set greater than 0 and a rank of 0 or 1. (A description of rank is
included in the next subsection on the CLI overview.)
4.5.13 Configuring SuperLoop
This section describes complex topologies. The control and data VLANs are, to reduce possible confusion, not shown.
Refer to Figure 4-14 for an example of Peer SuperLoop Domains with disjointed ring segments. Because there are two separate Common Links, they can have their own set of priorities. Overlap of priority numbers is not an issue. Since they are still
Peer SuperLoop domains, all five rings segments share the same set of data VLANs.
438
Layer Two Switching
127
M1
127
= Blocked SP interface
Note 2
= Common Link
127 127
T1
T1
127 127
T1
T2
126 126
T2
T2
126 126
T2
Note 2
126
Note 1
T3
T1
T1
126
M2
= All interfaces not
numbered are 0 (default)
= With non-shared common link,
can use same priority number
Note 1
Ring Segment Priority 127
T1
T1
T1
Note 1
Note 1
T2
T2
126 126
T2
T3
125 125
T3
125
M3
Note 2
126
M2
126
T3
125
T3
Note 1
T2
T2
126 126
T2
T3
125 125
T3
125
M3
Note 1
T3
125
EPSR_Topology_SuperLoop_complex1
FIGURE 4-14
SuperLoop Example - Disjointed Ring Segments
When an SBx3112 switch is initially booted up, the SuperLoop will be configured as follows:
• No EPSR domains have been created, and so the SuperLoop feature is not configured.
Figure 4-15 shows a network consisting of two protected ring segments that share a common link. The two ring segments
(ring segments 1 and 2) make up two EPSR domains that share the same set of data VLANs. There are two SBx3112 systems
(System A and System F). System A is a Transit Node shared by both ring segments 1 and 2. System F is a Master Node on
ring segment 1. This network represents a Peer SuperLoop EPSR logical domain (as described in section 4.5.12.4) because
both ring segments share a common link as well as the same set of protected VLANs.
Note:
Each interface on the common link must have the same VLAN configuration. So, the VLAN configuration on
interface 3.2 (on System A) must match the configuration on interface 11.4 (on System E).
439
Layer Two Switching
To / From Network
= Physical Link
B
= EPSR Blocking
Transit
Node
iMAP 9100
1
4
4.0
5.2
V_6
V_20
RING 1
(EPSR Domain = “allied-1”)
V_300
5
9.2
A
C
SBx3112
10.1
11
0.0
V_20
11
V_300
3.2
iMAP 9810
10.2
D
Transit
Node
V_200
V_6
SBx3112
3
Master
Node 1
10
V_20
V_300
V_6
iMAP 9700
11.2
6
F
10
V_20
11.4
E
Transit
Node
PP
0.2
V_20
0.1
RING 2
(EPSR Domain = “allied-2”)
10
V_200
V_300
Transit
Node
V_6
To / From Network
V_6
“Common Link”
iMAP 9700
8.2
0.0
1.1
V_200
10
SP
0.0
V_20
11.2
10.2
V_300
SP
PP
11
11
7
V_6
2
Master
Node 2
= Data VLAN (V_6)
= Data VLAN (V_20)
FIGURE 4-15
A
F
= Devices
1
7
= Links
SuperLoop Example - Peer SuperLoop Domain
The following procedure shows the steps to configure SBx3112 System A as a common Transit Node on both ring segments
and to set the port priority for the common link so as to prevent a SuperLoop condition from occurring.
TABLE 4-20
Step
Configuration Procedure for SuperLoop - Peer SuperLoop Domain
Command
Description
Create EPSR domain for ring segment 1
1
CREATE EPSR=allied-1 TRANSIT
Creates an EPSR domain named “allied-1” (for
ring segment 1) with the Enhanced Recovery
feature enabled. The SBx3112 System A is configured as a Transit node on this domain.
Default status of domain is Disabled.
440
Layer Two Switching
TABLE 4-20
Step
Command
2
show epsr allied-1
Description
--- EPSR Domain Information --EPSR Domain Name...................... allied-1
EPSR Domain Node Type................. Transit
EPSR Domain State..................... IDLE
MAC Address of Master Node............ 00:00:00:00:00:00
EPSR Domain Status.................... Disabled
Control Vlan.......................... Enhanced Recovery..................... ON
Ring Interface # 1.................... <unknown>
Physical State of Ring Interface # 1.. <unknown>
Ring Interface # 1 Type............... <unknown>
Ring Interface # 1 State.............. <unknown>
Ring Interface # 1 Priority........... <unknown>
Ring Interface # 1 Priority Rank...... <unknown>
Ring Interface # 2.................... <unknown> Physical State of Ring Interface # 2.. <unknown>
Ring Interface # 2 Type............... <unknown>
Ring Interface # 2 State.............. <unknown>
Ring Interface # 2 Priority........... <unknown>
Ring Interface # 2 Priority Rank...... <unknown>
Data Vlans............................ -
Create EPSR domain for ring segment 2
3
CREATE EPSR=allied-2 TRANSIT
4
show epsr allied-2
Creates an EPSR domain named “allied-2” (for
ring segment 2) with the Enhanced Recovery
featured enabled. The SBx3112 System A is
configured as a Transit node on this domain.
Default status of domain is Disabled.
Control Vlan..........................
Ring Interface # 1....................
Ring Interface # 2....................
Data Vlans............................
allied-2
Transit
IDLE
00:00:00:00:00:00
Disabled
ON
<unknown>
<unknown>
<unknown>
<unknown>
<unknown>
<unknown>
<unknown>
<unknown>
<unknown>
<unknown>
<unknown>
<unknown>
-
Create the control and data VLANs
5
create vlan vid 6,20,200,300
Creates 4 VLANs with the following IDs: 6, 20,
200 and 300.
Add control/data VLANs to the interfaces (with TAGGED framing)
441
Layer Two Switching
TABLE 4-20
Step
Command
Description
6
ADD VLAN=6 INTERFACE=ETH:[0.0],[3,8-9.2]
FRAME=TAGGED
Adds interfaces 0.0, 3.2, 8.2 and 9.2 to VLAN 6
and sets framing to tagged.
ADD VLAN=20 INTERFACE=ETH:[3,8-9.2]
FRAME=TAGGED
Adds interfaces 3.2, 8.2 and 9.2 to VLAN 20
and sets framing to tagged.
ADD VLAN=200 INTERFACE=ETH:[3,8.2]
FRAME=TAGGED
Adds interfaces 3.2 and 8.2 to VLAN 200 and
sets framing to tagged.
ADD VLAN=300 INTERFACE=ETH:[3,9.2]
FRAME=TAGGED
Adds interfaces 3.2 and 9.2 to VLAN 300 and
sets framing to tagged.
Delete the interfaces from the default VLAN
7
DELETE VLAN=1 INTERFACE=ETH:[0.0],[3.2],
[8.2],[9.2]
8
show vlan
Deletes interfaces 0.0, 3.2, 8.2 and 9.2 from the
default VLAN (VID=1).
--- VLAN Information ------------------------------------------------------------------------Name
VID
Forwarding Tagged Interfaces
Untagged Interfaces
Mode
--------------- ---- ---------- ------------------------------- ----------------------------default
1
vlan6
vlan20
vlan200
vlan300
6
10
200
300
Standard
Standard
Standard
Standard
Standard
<none>
ETH:[0.0],[3,8-9.2]
ETH:[3,8-9.2]
ETH:[3,8.2]
ETH:[3,9.2]
ETH:[0.1-3],[1-2,6-7,10-11.0-3],
[3,8-9.0-1,3-23]
<none>
<none>
<none>
<none>
Set GE interfaces to the NETWORK direction
9
set interface 8.2 ge direction network
Configures the GE interfaces for the Network
direction.
Add interfaces to the “allied-1” domain
10
ADD EPSR=allied-1 INTERFACE=ETH:[8.2]
Adds interfaces 8.2 and 3.2 to the “allied1” EPSR domain.
Add interfaces to the “allied-2” domain
11
Adds interfaces 9.2 and 3.2 to the “allied2” EPSR domain.
Add control VLAN to the “allied-1” domain
12
ADD EPSR=allied-1 VLAN=200 TYPE=CONTROL
Adds VLAN 200 to the “allied-1” EPSR
domain as the control VLAN.
Add the data VLANs to the “allied-1” domain
442
Layer Two Switching
TABLE 4-20
Step
Command
Description
13
ADD EPSR=allied-1 VLAN=6 TYPE=DATA
domain as a data VLAN.
ADD EPSR=allied-1 VLAN=20 TYPE=DATA
Review configuration information for the “allied-1” domain
14
show epsr allied-1
Control Vlan..........................
Ring Interface # 1....................
Ring Interface # 2....................
Data Vlans............................
allied-1
Transit
IDLE
00:00:00:00:00:00
Disabled
200
ON
ETH:[8.2]
UP
RING
0
0
ETH:[3.2]
UP
RING
0
0
6, 20
Add the control VLAN to the “allied-2” domain
15
ADD EPSR=allied-2 VLAN=300 TYPE=CONTROL
domain as the control VLAN.
Add the data VLANs to the “allied-2” domain
16
add epsr allied-2 vlan 6 type data
add epsr allied-2 vlan 20 type data
Review configuration information for the “allied-2” domain
443
Layer Two Switching
TABLE 4-20
Step
Command
17
show epsr allied-2
Description
Control Vlan..........................
Ring Interface # 1....................
Ring Interface # 2....................
Data Vlans............................
allied-2
Transit
IDLE
00:00:00:00:00:00
Disabled
300
ON
ETH:[9.2]
UP
RING
0
0
ETH:[3.2]
UP
RING
0
0
6, 20
Set the priority for the “common” link (shared by both domains)
18
SET EPSR=allied-1 INTERFACE=ETH:[3.2]
PRIORITY=10
Makes the “allied-1” EPSR domain the lowpriority ring (by assigning it a priority of 10).
19
SET EPSR=allied-2 INTERFACE=ETH:[3.2]
PRIORITY=11
Makes the “allied-2” EPSR domain the highpriority ring (by assigning it a higher priority of
11).
Enable both EPSR domains
20
Enables the “allied-1” and “allied-2”
EPSR domains on System A.
ENABLE EPSR=allied-1,allied-2
Note: This enable command must be issued
with both domains specified at the same time.
Review data VLANs per EPSR domain
21
show epsr datavlans
--- EPSR Domain Information ---
EPSR Domain Overlapping Domain(s)/Shrd Ring Port Data Vlans
----------- ------------------------------------ -----------allied-1
allied-2/3.2
6,20
allied-2
allied-1/3.2
6,20
444
Layer Two Switching
TABLE 4-20
Step
Command
Description
Review full configuration information for each EPSR domain
22
show epsr full
Control Vlan..........................
Ring Interface # 1....................
Ring Interface # 2....................
Data Vlans............................
allied-1
Transit
LINKS-UP
00:15:77:F5:68:61
Enabled
200
ON
ETH:[8.2]
UP
DOWNSTREAM
0
0
ETH:[3.2]
UP
UPSTREAM
10
0
6, 20
Control Vlan..........................
Ring Interface # 1....................
Ring Interface # 2....................
Data Vlans............................
allied-2
Transit
LINKS-UP
00:0C:25:00:05:33
Enabled
300
ON
ETH:[9.2]
UP
DOWNSTREAM
0
0
ETH:[3.2]
UP
UPSTREAM
11
1
6, 20
4.5.15 EPSR and (R)STP Interaction
You can coordinate EPSR and (R)STP so that devices can take part in both EPSR and (R)STP. By data filling certain parameters
correctly, the blocking of links to remove loops is coordinated.
4.5.15.1 EPSR and STP Interaction
The EPSR and (R)STP topologies conceptually do the same thing: provide a protection scheme for the network while blocking certain links to prevent loops. The key difference between the two features, however, is that:
• EPSR requires the user to explicitly create the ring configuration and to decide where blocking will occur for the data
VLAN(s).
• (R)STP configures where links are to be broken based on user provisioned values which are calculated to determine the
lowest cost paths for data traffic. This is used to determine which paths allow data traffic and where links should be
blocked to prevent loops.
It is possible to coordinate these features (through the provisioning of key parameters) so that certain devices can take part
in both EPSR and (R)STP. By data filling these parameters correctly, the blocking of links to remove loops is coordinated.
445
Layer Two Switching
Note:
One key aspect of providing this coordination is that provisioning must ensure that with ports that are part of both
EPSR and (R)STP, their spanning tree states must be controlled by EPSR. This is explained in more detail later.
The following configurations are supported:
• Connection of an (R)STP subnetwork to a single node in the EPSR ring.
• Connection of an (R)TP subnetwork to two adjacent nodes of the EPSR ring.
Figure 4-16 shows these two configurations.
Note:
UCP is used with EPSR and STP to determine the upstream direction of the UFO VLAN interface configured on the
port. In setting these interfaces as UCP, any node in the EPSR ring can be the Master Node.
= Physical Link
= Data VLAN (V_80)
To / From NetworkRoot
Bridge
U
0.3
D
D
0.2
0.1
V_80
over Physical Link 3 (SP)
A
V_60
1
4
0.2
B
V_80
V_60
D = Devices in EPSR topology
C
G = Devices in RSTP topology
1
8 = Links
B
U
0.1
D
D = Downstream (by UCP)
D
V_80
V_60
U = Upstream (by UCP)
0.1
D
0.2
A
U
0.2
8
Master Node
2
U
V_60
PP
SP
C
0.1
0.1
0.2
3
V_80
U
V_80
G
0.3
0.2
D
5
= physical link is blocked
by STP over Physical Link 8
3
= path costs set so will
never be blocked by STP
unless no other choice
D
7
U
0.1
E
U
V_80
0.1
D
D
0.2
0.2
6
F
V_80
EPSR_STP_Interop_60
FIGURE 4-16
Note:
Possible EPSR/RSTP Configurations
The Multiple Spanning Tree Protocol (MSTP) is also available (refer to Section 4.4). However, implementing MSTP
and EPSR features on the same system is not recommended, and so is explained separately.
446
Layer Two Switching
4.5.15.2 Configuration Overview - EPSR and (R)STP
The communication of STP/RSTP information to other bridges via the exchange of messages known as Configuration Bridge
Protocol Data Units (BPDUs), Topology Change Notification (TCN) BPDUs, and RST BPDUs.
For the feature interaction, these take place as part of the STP/RSTP processing on the NSP product nodes which are configured to run EPSR and STP/RSTP together, as well as the nodes which are only running STP/RSTP.
4.5.15.3 Configuration Requirements - EPSR and (R)STP
Following are the key concepts/parameters that must be understood for the feature interaction to function correctly:
• Protocol Communication (BPDUs)
For ports that are participating in both EPSR & STP/RSTP, when the STP/RSTP processing that is “attempting” to control
the spanning tree states of alternate or backup ports indicates that those ports are in a “blocked” or “discarding” state,
BPDUs will not be transmitted on those ports, even though in fact they are actually “forwarding” due to EPSR control.
There is also communication added between the EPSR protocol and STP/RSTP within the NSP product node to signal
when a port has been unblocked as a result of the EPSR ring being restored to full service following recovery of a failed
link. This event will be processed rather than port enable event by the STP/RSTP feature.
• Convergence (selection of root bridge)
The root bridge for the overall Spanning Tree for the network in this type of configuration must either be one of the EPSR
ring nodes, or a bridge which is at a “higher level” in the network and connects directly via one of the nodes on the EPSR
ring. In other words the root bridge can NOT be a node from one of the STP/RSTP sub-networks, nor can it be a “higher
level” network node that only connects via a link to one of the STP/RSTP sub-networks.
4.5.15.4 Port Costs
When a network is being setup to utilize an EPSR ring in conjunction with STP or RSTP sub-networks, the port paths costs
of all the links involved will need to be reviewed and potentially modified by the user. At a minimum, the port path costs for
all the “shared” links from the EPSR ring will need to be set artificially low (e.g., to a value of 1,2, or 3) to keep the STP/RSTP
algorithm processing from attempting to block those links.
In addition, whenever STP sub-networks are in use, it may be necessary to raise the path costs of the links in each STP subnetwork such that the combined cost for a traffic path through any one of those sub-networks can not be lower than the
cost to traverse the EPSR ring.
Note:
This will only be an issue in a scenario where a link (or bridge) on the EPSR ring has failed.
This restriction is a side effect of the low magnitude and limited range of path cost values used for STP. When RSTP is in use,
the same general principal applies (i.e., RSTP sub-network path costs must be greater than path cost for EPSR ring), but due
to the greater magnitude of path cost value utilized for RSTP by default, this becomes much easier to accomplish through
provisioning.
When provisioning an EPSR and RSTP network with shared links, there can be a warning at the CLI about path costs, this can
occur if the user is going from separate EPSR / RSTP networks to one with the shared link, and when the user enables RSTP
on a port that has EPSR configured, the message will appear.
447
Layer Two Switching
4.5.16 EPSR and SuperLoop Commands
This subsection provides an alphabetical reference for commands used to configure EPSR.
TABLE 4-21
EPSR Commands
Commands
ADD EPSR INTERFACE
ADD EPSR VLAN
ADD TRACE EPSR MESSAGETYPE
CREATE EPSR MASTER | TRANSIT
DELETE EPSR INTERFACE
DELETE EPSR VLAN
DELETE TRACE EPSR MESSAGETYPE
DESTROY EPSR
DISABLE EPSR
ENABLE EPSR
SET EPSR
SET EPSR INTERFACE
SETDEFAULTS EPSR
SHOW EPSR
448
Layer Two Switching
ADD EPSR INTERFACE
Syntax
ADD EPSR=epsrdomain
[ TYPE={ PRIMARY | SECONDARY } ]
[ PRIORITY=0..127 ]
Description
Adds an Interface to the already existing EPSR domain. Only one interface can be specified at a time
when the EPSR domain is of 'Master' node type. If it's a 'Transit' node type then the user can specify
two interfaces at a time. (More than two interfaces are not allowed in any case.)
Mode
Manager
Options
Option
Description
Range
Default
Value
EPSR
The domain name of the EPSR.
NA
NA
INTERFACE
The Ethernet interface that is being configured as
part of the EPSR.
NA
NA
TYPE
For a system that is being designated as the Master
Node, whether the interface will be a PRIMARY
PORT (PP) or Secondary port (SP)
NA
SECONDARY
PRIORITY
Sets the ring port priority for a domain when the
ring port is part of a common link spanning one or
more superloop segments. Refer to 4.5.11.
0
0
Release Note
NA
Example
449
Layer Two Switching
ADD EPSR VLAN
Syntax
ADD EPSR={ epsrdomain-list } VLAN={ vlanname-list | vid-range } [ TYPE={ CONTROL | DATA } ]
Description
Adds a VLAN to the already existing EPSR domain. The user can add a VLAN as a CONTROL or
DATA type. The interfaces associated with the EPSR domains should be tagged members of the CONTROL or DATA vlan being added to that domain.
Mode
Manager
Options
Option
Description
Range
Default Value
EPSR
The name(s) that has been given to the EPSR
domain(s)
NA
NA
VLAN
The VLAN(s) that are being added to the EPSR
configuration.
NA
NA
TYPE
CONTROL - A VLAN that carries the EPSR configuration messages. A CONTROL vlan must be
NA
DATA
of UFO type. A CONTROL vlan, once added
to any EPSR domain, cannot be added to any
other domain either as CONTROL or DATA
type
DATA - A VLAN that carries traffic. One or more
VLANs can be configured as DATA VLANs in one
EPSR domain. A DATA vlan cannot be associ-
ated with two EPSR domains that are part of
the same physical RING network (EPSR
domains having the same interfaces provisioned).
Release Note
NA
Example
ADD EPSR ALLIED VLAN=1200 TYPE=CONTROL
450
Layer Two Switching
ADD TRACE EPSR MESSAGETYPE
Syntax
ADD TRACE EPSR [ ={ epsrdomain-list | ALL } ]
MESSAGETYPE={ HEALTH | RINGUPFLUSH | RINGDOWNFLUSH | LINKDOWN | LINKFORWARDREQUEST | PERMISSIONLINKFORWARD | QUERYLINKSTATUS | ALL }
Description
Add an EPSR trace to an interface. Detailed call events pertaining to a port or set of ports can be
obtained by defining and enabling trace log criteria.
Mode
Manager
Options
Release Note
Option
Description
Range
Default
Value
EPSR
domain(s)
NA
NA
MESSAGETYPE
The EPSR message types
NA
ALL
INTERFACE
The interfaces where the TRACE will occur
NA
NA
NA
Example
ADD TRACE EPSR NC MESSAGETYPE HEALTH
451
Layer Two Switching
CREATE EPSR MASTER | TRANSIT
Syntax
CREATE EPSR=epsrdomain { TRANSIT | MASTER [ HELLOTIME=0..65535 ] [ FAILOVERTIME=0..65535 ] [ RINGFLAPTIME=0..65535 ] } [ ENHANCEDRECOVERY={ ON | OFF } ]
Description
Used to create an EPSR domain. The domain being created is either a 'Transit' or 'Master' type.
Mode
Manager
Options
Option
Description
Range
Default
Value
EPSR
domain(s)
NA
NA
MASTER_or_TRAN
SIT
The type of domain,
NA
One from
the list is
required
If MASTER, then the system is a MASTER node and
the TIME parameters must be specified; otherwise
default values are used.
If TRANSIT, only ENHANCEDRECOVERY can be
specified.
HELLOTIME
The rate at which the EPSR protocol Health control message is sent by the master node for this
EPSR domain.
NA
1
FAILOVERTIME
Time for which the master node waits before
declaring that it has detected a break in the ring for
this EPSR domain.
NA
2
RINGFLAPTIME
The minimum number of seconds that a master
node must remain in the failed state (before moving to the complete state), even if the ring has
recovered from its fault condition.
NA
0
ENHANCEDRECOVERY
Allows a partial recovery of the ring even if there
are links that are down.
NA
OFF
Release Note
NA
Example
CREATE EPSR=allied MASTER
452
Layer Two Switching
DELETE EPSR INTERFACE
Syntax
DELETE EPSR={ epsrdomain-list | ALL } INTERFACE={ type:id-range | id-range |
ifname-list | ALL }
Description
Deletes an Interface from the already existing EPSR domain. This operation is only allowed when the
EPSR domain is disabled.
Mode
Manager
Options
Option
Description
Range
Default
Value
EPSR
domain(s)
NA
NA
INTERFACE
The interfaces that will be deleted from the EPSR
domain.
NA
NA
Release Note
NA
Example
DELETE EPSR=allied-1 INTERFACE=ETH:[8.3]
453
Layer Two Switching
DELETE EPSR VLAN
Syntax
DELETE EPSR={ epsrdomain-list | ALL } VLAN={ vlanname | vid | ALL }
Description
Deletes a VLAN from the already existing EPSR domain. This operation is only allowed when the EPSR
domain is disabled.
Mode
Manager
Options
Option
Description
Range
Default
Value
EPSR
domain(s)
NA
NA
VLAN
The VLAN(s) that are going to be deleted from the
EPSR domain
NA
NA
Release Note
NA
Example
DELETE EPSR=allied VLAN=403
454
Layer Two Switching
DELETE TRACE EPSR MESSAGETYPE
Syntax
DELETE TRACE EPSR [ ={ epsrdomain-list | ALL } ] [ MESSAGETYPE={ HEALTH |
RINGUPFLUSH | RINGDOWNFLUSH | LINKDOWN | LINKFORWARDREQUEST | PERMISSIONLINKFORWARD | QUERYLINKSTATUS | ALL } ] [ INTERFACE={ type:id-range | id-range |
ifname-list | ALL }
Description
Delete the events which match the given filters.
Mode
Manager
Options
Option
Description
Range
Default
Value
EPSR
domain(s)
NA
NA
MESSAGETYPE
The EPSR message types
NA
If not input,
will default to
wildcard (ALL)
INTERFACE
The interfaces where the TRACE will occur
NA
If not input,
will default to
wildcard (ALL)
Release Note
NA
Example
DELETE TRACE EPSR GA MESSAGETYPE HEALTH
455
Layer Two Switching
DESTROY EPSR
Syntax
DESTROY EPSR={ epsrdomain-list | ALL }
Description
Used to destroy the already existing EPSR domains. The EPSR domain must be disabled before it can
be destroyed. See DISABLE EPSR.
Mode
Manager
Options
Option
Description
Range
Default
Value
EPSR
domain(s)
NA
NA
Release Note
NA
Example
DESTROY EPSR=allied-1
456
Layer Two Switching
DISABLE EPSR
Syntax
DISABLE EPSR={ epsrdomain-list | ALL }
Description
Used to disable the EPSR domain.
Mode
Manager
Options
Option
Description
Range
Default
Value
EPSR
domain(s)
NA
NA
Release Note
NA
Example
DISABLE EPSR=allied
457
Layer Two Switching
ENABLE EPSR
Syntax
ENABLE EPSR={ epsrdomain-list | ALL }
Description
Used to enable the EPSR domain. Before any EPSR domain can be enabled, the Control Vlan, Primary
and Secondary interfaces should have been provisioned on that EPSR domain.
Mode
Manager
Options
Option
Description
Range
Default Value
EPSR
domain(s)
NA
NA
Release Note
NA
Example
ENABLE EPSR=allied-1,allied-2
458
Layer Two Switching
SET EPSR
Syntax
SET EPSR={ epsrdomain-list | ALL } [ HELLOTIME=1..32767 ] [ FAILOVERTIME=2..65535 ] [ RINGFLAPTIME=0..65534 ] [ ENHANCEDRECOVERY={ ON | OFF } ]
Description
Used to set the values of hello time, failover time and ringflap time for the EPSR domains. This command is valid only for Master type of EPSR domains. This operation is only allowed when the EPSR
domain is disabled.
Mode
Manager
Options
Option
Description
Range
Default
Value
EPSR
domain(s)
NA
NA
HELLOTIME
EPSR domain.
NA
1
FAILOVERTIME
this EPSR domain.
NA
2
RINGFLAPTIME
NA
0
ENHANCEDRECOVERY
NA
OFF
Release Note
NA
Example
SET EPSR=allied-2 HELLOTIME=5
459
Layer Two Switching
SET EPSR INTERFACE
Syntax
SET EPSR=epsrdomain INTERFACE={ type:id | id | ifname } [ TYPE={ PRIMARY |
SECONDARY } ] [ PRIORITY=0..127 ]
Description
Used to change the interface designation in the EPSR domain. This operation is valid only for Master
type of EPSR domains. This operation is only allowed when the EPSR domain is disabled.
Mode
Manager
Options
Option
Description
Range
Default
Value
EPSR
domain(s)
NA
NA
INTERFACE
The Ethernet interface that is being configured as
part of the EPSR. For the SBx3112 these are on the
XE4.
NA
NA
TYPE
For a system that is being designated as the Master
Node, whether the interface will be a PRIMARY
PORT (PP) or Secondary port (PP)
NA
NA
PRIORITY
Sets the ring port priority for a domain when the
ring port is part of a common link spanning one or
more superloop segments. Refer to
NA
NA
Release Note
NA
Example
SET EPSR=allied-1 INTERFACE=ETH:[3.2] PRIORITY=10
460
Layer Two Switching
SETDEFAULTS EPSR
Syntax
SETDEFAULTS EPSR={ epsrdomain-list | ALL } [ HELLOTIME ] [ FAILOVERTIME ] [
RINGFLAPTIME ][ENHANCEDRECOVERY]
Description
Used to reset the values of hello time, failover time, or ringflap time back to defaults. This operation is
only allowed when the EPSR domain is disabled.
Mode
Manager
Options
Option
Description
Range
Default
Value
EPSR
domain(s)
NA
NA
HELLOTIME
EPSR domain.
NA
1
FAILOVERTIME
this EPSR domain.
NA
2
RINGFLAPTIME
NA
0
ENHANCEDRECOVERY
NA
OFF
Release Note
NA
Example
SETDEFAULTS EPSR=allied-2 HELLOTIME
461
Layer Two Switching
SHOW EPSR
Syntax
SHOW EPSR [ ={ epsrdomain-list | ALL } ] [ { FULL | DATAVLANS } ]
Description
Used to display the information about the EPSR domains. SHOW EPSR and SHOW EPSR ALL command displays the summary information about all the provisioned EPSR domains in the system. The
SHOW EPSR epsrdomain command displays the detailed information about that specific EPSR domain.
Mode
User
Options
Release Note
Option
Description
Range
Default
Value
EPSR
The name(s) that have been given to the EPSR
domain(s).
NA
ALL
FULL
Provides information on both CONTROL and
DATA VLANS
NA
NA
DATAVLANS
Lists the DATA VLAN(s) for the domain(s)
NA
NA
NA
Example
SHOW EPSR
--- EPSR Domain Information ---
Data
Node
EPSR Domain Type
Domain State
----------- ------- -----------e163
Master EN/COMPLETE
Ctrl
Interface(s) (Phy. State, Type, Vlan
Vlan
State, Prio)Count
------ ------------------------------- -----4
8.18 (UP,DNSTRM,PHYFWD,0(0)),
19
8.19 (UP,DNSTRM,PHYBLK,0(0))
test
Master
DIS/IDLE
-
-
0
videoring
Master
EN/COMPLETE
6
1
8.22 (UP,DNSTRM,PHYBLK,0(0))
e164
Transit EN/LINKS-UP
5
1
8.19 (UP,UPSTRM,PHYFWD,0(0))
E135 - manager SEC>> sh epsr=videoring
--- EPSR Domain Information --EPSR Domain
EPSR Domain
EPSR Domain
MAC Address
EPSR Domain
Name......................
Node Type.................
State.....................
of Master Node............
Status....................
videoring
Master
COMPLETE
00:0C:25:04:00:0D
Enabled
462
Layer Two Switching
Control Vlan..........................
Primary Interface.....................
Physical State of Primary Interface...
Primary Interface Type................
Primary Interface State...............
Primary Interface Priority............
Primary Interface Priority Rank.......
Secondary Interface...................
Physical State of Secondary Interface.
Secondary Interface Type..............
Secondary Interface State.............
Secondary Interface Priority..........
Secondary Interface Priority Rank.....
Hello Timer (seconds..................
Failover Timer (seconds)..............
RingFlap Timer (seconds)..............
Hello Time Remaining (seconds)........
Failover Time Remaining (seconds).....
RingFlap Time Remaining (seconds).....
Hello Sequence........................
Data Vlans............................
6
OFF
ETH:[11.0]
UP
DOWNSTREAM
0
0
ETH:[8.22]
UP
DOWNSTREAM
PHYSICALLY BLOCKED
0
0
1
2
0
1
0
0
57937
512
463
Layer Two Switching
4.6 Upstream Forwarding Only (UFO) Mode
4.6.1 Overview
For the SBx3100, a VLAN can be created where all data from ports associated with that VLAN must be forwarded only to
the upstream port. This segregation of traffic is done when:
• Certain types of services require only connections between the port and an upstream device.
• Security must be maintained (a malicious subscriber on one port cannot access a MAC or IP address on another port).
Understanding UFO mode is important to understand when UFO FLANs are used in a Spanning Tree configuration. Refer to
section 4.4.
SBx3100
Line Card Slot 8
Line Card Slot 8
Port 0
Port 4
MAC=34567*
VID=4
VLAN=Train
MAC=45678*
VID=4
* MAC addresses are not actual values
CREATE VLAN=Train VID=4 TYPE=VLAN FORWARDINGMODE=UPSTREAMONLY
ADD VLAN=4 INTERFACE=ETH:8.0, 9.4
UFO_Mode_VLAN_Cnfg
ADD VLAN=4 INTERFACE=ETH:0.0 FRAME=TAGGED
FIGURE 4-17
UFO Mode VLAN Configuration
4.6.1.1 Isolated UFO VLAN Notification
When a UFO VLAN is no longer associated with a functional network facing interface, a management log is produced. This
log contains a list of all isolated UFO VLANs. When a UFO VLAN is no longer isolated, the log is produced again with the list
of the remaining isolated UFO VLANs. This process continues until there are no more isolated UFO VLANs. Once all UFO
VLANs have at least one operational interface, the shelf alarm is cleared.
Following is an example of the log:
SHLF010 2008-02-11 14:20:40 3541 INFO
Description: No active/standby or dynamic interface in UFO VLAN
VLANs: 5,10-12
464
Layer Two Switching
4.6.2 Forwarding Mode and Determining Upstream Nodes and Interfaces
In setting up the UFO VLANs on interfaces, there is the FORWARDING parameter that controls how the interface for the
UFO VLAN determines whether it is the upstream interface. This is used in the various protection schemes where a configuration will reconverge and the UFO interface may need to change its status as upstream or downstream.
The values for FORWARDING can be divided into two groups:
• Static - The interface for this UFO is always either upstream or downstream.
• Dynamic - The interface uses one of the spanning tree protocols to dynamically determine whether it is upstream or
downstream.
The following table describes these modes.
TABLE 4-22
Forwarding Modes for UFO VLANs
Forwarding Mode
Description
Notes
PRIMARYUPSTREAM
All frames that are received on the other
interfaces will be sent out this interface.
Static (can also be used with UCP)
SECONDARYUPSTREAM
All frames that are received on the other
interfaces will be sent out this interface if
there is a fault with the PRIMARYUPSTREAM.
Refer to Upstream Control Protocol
(UCP).
DOWNSTREAM
Only frames that are received over the
UPSTREAM interface may be switched to
Static
RESTRICTED
The VLAN cannot be used by all interfaces
at the same time.
This is not used on the SBx3112.
STP
The Spanning Tree Protocol will dynamically
Upstream is towards Root Bridge (refer
to Overview of Spanning Trees).
EPSR
The VLAN(s) are part of an EPSR configuration and the EPSR protocol determines the
UPSTREAM interface.
Upstream is towards EPSR Master (refer
to Ethernet Protection Switched Ring
(EPSR) and SuperLoop Prevention)
UCP
The UCP protocol will determine the
UPSTREAM interface dynamically regardless
of the type of configuration.
Upstream is determined by UCP protocol
(refer to Upstream Control Protocol
(UCP)).
4.6.3 UFO Example Configuration (Static)
In a simple configuration, a UFO can be used to provide a permanent (static) Forwarding Mode, since these will never have to
change. Refer to the following figure.
465
Layer Two Switching
SBx900
FORWARDING =
PRIMARYUPSTREAM
Port 0
SBx3100
V_60
Line Card Slot 8
Line Card Slot 8
Port 0
Port 4
FORWARDING =
DOWNSTREAM
V_60
FORWARDING =
DOWNSTREAM
= VLAN in UFO Mode
UFO_Mode_VLAN_Cnfg
UFO Model - Static Configuration
FIGURE 4-18
4.6.4 STP Configuration with UFO VLAN
Figure 4-19. and Figure 4-20 show an example ring configuration that uses (R)STP with UFO VLANs
To / From Network
= Physical Link
= VLAN 60 (V_60)
0.3
0.2
(Root Bridge)
0.1
If Device A is the root, UFO VLAN is set at interfaces:
0.1 = DOWNSTREAM
0.2 = DOWNSTREAM
0.3 = PRIMARYUPSTREAM
A
For other devices, UFO VLAN on the interface
set to STP for dynamic state change
(Upstream to Downstream,
1
Downstream to Upstream)
= STP Blocking of Physical Link
V_60
4
Upstream
Upstream
0.2
0.1
V_60
B
A
D = Devices
1
4
0.1
V_60
= Links
D
Downstream
0.2
Downstream
Downstream
Upstream
3
V_60
C
0.1
0.2
2
Ring_Topology_STP_60
FIGURE 4-19
Ring Topology Using STP and UFO VLAN
466
Layer Two Switching
(Root Bridge)
E
= Physical Link
= VLAN 60 (V_60)
0.2
0.3
0.1
If Device A is not the root, UFO VLAN is set at interfaces:
0.1 = STP
0.2 = STP
A
For other devices, UFO VLAN on the interface
set to STP for dynamic state change
1
= STP Blocking of Physical Link
V_60
4
Upstream
Upstream
0.2
0.1
V_60
B
A
D = Devices
1
4
0.1
V_60
= Links
D
Downstream
0.2
Downstream
Upstream
3
V_60
C
0.1
0.2
2
Downstream
Ring_Topology_STP_up
FIGURE 4-20
Ring Topology Using STP and UFO VLAN - Root Bridge is above Ring
Once the topology stabilizes, in each system one of the ports will become the root port (the one closest to the root bridge
as determined by STP) and the other port(s) become the designated port. The port which is the root port is considered to be
the upstream port and the port which is not the root port (designated port) is considered to be the downstream port.
The user can provision the ports in each shelf with FORWARDING=STP indicating that the topology is a ring and allowing the
STP protocol to determine the exact upstream.
To prevent one of the systems from becoming the Spanning Tree root bridge, the network design must ensure that the
appropriate STP parameters are set such that the root bridge is always located above the ring configuration made up of the
systems.
When a ring topology is implemented in the user’s network, the user may not be aware of which ring ports are designated
primaryupstream and which are designated downstream. Therefore, if the user wants to configure classifiers on these ring
ports, they should apply them to both ring ports. This ensures that the traffic classification required by the user is actually
applied.
This restriction strictly applies only to the switches which actually make up the ring. The aggregating layer 2 switch or any
switch above it could be the root bridge for a ring network. These are configured as follows:
• If the aggregating layer 2 switch is an iMAP (Device A in Figure 4-19 ) and does become the root bridge then the FORWARDING parameter for the ports cannot be set to STP. The upstream port from the aggregating layer 2 switch, which
is the real network uplink for such a configuration, should be set to PRIMARYUPSTREAM and the other two links
which make up the ring must be set to DOWNSTREAM.
• If the aggregating layer 2 switch is an iMAP but is not the root bridge but one of the switches above it is (Device E in
Figure 4-21), then the FORWARDING parameter can be set to STP and the status of the ports will be determined with
STP’s assistance similar to the other switches in the ring.
467
Layer Two Switching
4.6.5 MSTP Configuration with UFO VLAN
Figure 4-21 shows an example configuration that uses MSTP with UFO VLANs.
Parameters can be set so that each MSTI has a Regional Root Bridge on separate systems. On each of these systems, the
VLANs on the upstream port are set to PRIMARYUPSTREAM and the other ports are set to DOWNSTREAM. All other
ports are other systems are set to STP.
Note:
In this example, each MST Instance has only one VLAN and its upstream interface is configured as
PRIMARYUPSTREAM. If there are multiple VLANs for an MST Instance, each VLAN should be set as
PRIMARYUPSTREAM over the same upstream port.
To / From Network
For Root Bridge A,
UFO VLANS set as
0.1 = DOWNSTREAM
0.2 = DOWNSTREAM
= Physical Link
0.3
For other devices, UFO VLAN
on the interface set to STP
for dynamic state change
= Blocking of VLAN traffic
0.2
0.1
V_80
A
V_60
1
4
Regional Root Bridge MST2
MST1 Instance
MST2 Instance
0.2
Regional
Root Bridge
MST1
V_60 = UFO VLAN 60
V_60
V_80
V_60
V_80 = UFO VLAN 80
B
0.1
A
D = Devices
1
4
D
= Links
3
V_60
0.1
0.2
To / From
Network
0.2
2
C
V_80
FIGURE 4-21
0.3
V_80
0.1
For Root Bridge D,
UFO VLANS set as
0.1 = DOWNSTREAM
0.2 = DOWNSTREAM
For other devices, UFO VLAN
on the interface set to STP
for dynamic state change
Ring Topology Using MSTP and UFO VLAN
468
Layer Two Switching
4.6.6 EPSR Configuration with UFO VLAN
To / From Network
For other devices, data VLAN has
FORWARDING set to EPSR for
dynamic state change
SP
PP
= Data VLAN on Physical
Link 1 is blocked
A
Master
Node
1.1
V_80
0.1
With Device A as the root, data VLAN
FORWARDING could be set at interfaces:
0.1 = DOWNSTREAM
1.1 = DOWNSTREAM
= Physical Link
= Data VLAN (V_80)
2.1
V_60
4
1
0.2
V_80
0.1
V_60
B
A
D = Devices
1
4
V_80
V_60
= Links
D
1.1
1.2
2
1.1
0.2
3
V_60
C
Data VLAN is
unblocked
V_80
EPSR_Topology_UFO
FIGURE 4-22
Initial forwarding configuration of ring ports in an EPSR network
Figure 4-22 shows a configuration where the master node, Allied Telesis System A, has its port pointing towards the network configured as upstream with the two ring ports configured as downstream. This is provisioned using the SET VLAN
command with the FORWARDING parameter. This is similar to the current implementation of configuring the layer 2 aggregating switch the same way when it is the root bridge according to the STP protocol. In the EPSR ring using the EPSR protocol, the master node configuration is conceptually the equivalent of it being a root bridge for this network
In each of the transit nodes, both the ring ports are configured using the SET VLAN INTERFACE command with the FORWARDING parameter set to EPSR. For EPSR, unlike an STP implementation where a port change event is used to configure
ports the receipt of the EPSR protocol message is used. The ring port uses a Health message with the a state of Complete
received by the transit switch to configured the upstream port with the other ring port configured to be the downstream
port
Note:
To use EPSR functionality for the determination of the upstream and downstream port in the nodes that make up
the ring, the node which has the link to the network must be the master node.
469
Layer Two Switching
4.6.7 Configuring UFO VLANs
• As a default, there is one VLAN (vid 1), which cannot be created or destroyed.
• The default VLAN is associated with all Line Card interfaces.
• The default VLAN is in standard (non-UFO) mode.
• The UFO mode is controlled on a VLAN basis.
• For the SBx3112, up to 16 VLANs can be configured in UFO mode, and they can use any VID in the 2-4094 range. Moreover, the features VLAN Translations (4.9) and VLAN-based HVLANs (4.8) do no affect this number.
• When all VLANs on a port are deleted, the port would revert to the default VLAN (vid 1), which would be in either UFO
or Standard mode.
• An interface may be set as the upstream interface (either statically or dynamically) for a UFO VLAN regardless of its
DIRECTION setting.
• UFO VLANs are supported for the LAG uplinks in release 17.0. Refer to 4.2.7.3.
Once the ADD VLAN command for UFO has been invoked, the system may generate a warning message at the user’s CLI
session stating that classifier capacity or capabilities have been exceeded on the slot(s) impacted by the provisioning change.
The user should investigate classifier-related provisioning, such as IGMP, DHCPRELAY, VLAN (for per-VLAN UFO and
HVLAN), EPSR, INTERFACE (TAGALL option for HVLAN), ACCESSLIST, and CLASSIFIER to determine the reason for the
message.
470
Layer Two Switching
4.7 Upstream Control Protocol (UCP)
4.7.1 Overview of UCP
UCP is a proprietary protocol used by Allied Telesis Network Access product devices so that it can inform other devices in
the network that it is the “upstream node” for a UFO VLAN. A UCP node creates Port Notification messages that
announces it is the “upstream node.” The non-upstream nodes receive these UCP protocol messages for the UFO VLAN so
that they can dynamically determine their upstream interfaces. This occurs independently of the topology feature being used.
4.7.2 UCP Protocol Configuration Overview
To understand UCP operation, the user should first consider UCP enabled on a set of connected devices that does not use a
Spanning Tree or EPSR feature; a set of interfaces are configured with a UFO VLAN, and one of the interfaces is on the
upstream device and faces into the larger network.
When the user sets the FORWARDING parameter to PRIMARYUPSTREAM, then for this UFO VLAN on this interface, this
device is the upstream device and this interface is the upstream interface.
Moreover, the user can have a second device that also is an upstream device with an upstream interface. The user can therefore set this second interface as SECONDARYUPSTREAM, which will act as a backup if there is a failure of the primary interface device. This will be explained in detail later.
As the other interfaces are associated with the UFO VLAN, they are by default set to UCP, meaning they dynamically determine their direction during topology changes.
Once all of the interfaces are configured, they can exchange the two UCP messages:
• The Upstream Port Notification Message sent by the upstream node
• The Upstream Port Topology Change Message sent by the devices spanning a failed link (or adjacent to a failed device)
when the failure occurs and when it subsequently recovers.
4.7.2.1 Upstream Port Notification Message
The upstream node periodically formats this message for each of the UFO VLANs that qualifies and sends them over the
UCP-enabled interfaces. This message is received by the other devices that make up this UFO VLAN configuration
Table 4-23 shows the logic of how this message is processed:.
TABLE 4-23
Processing of Upstream Port Notification Message Sent by Upstream Device
Process
If Check Condition, Outcome
A classifier rule intercepts this message based upon the
layer 2 destination address value and sends it to the cpu
only.
The UCP protocol task upon receiving this message will
check to see if the tagged vlan in the message is configured
to be a ufo vlan.
If not, the message is discarded.
Check is made to see if the port on which it was received
is a tagged member of the ufo vlan
If not, the message is discarded
Check if message is received on UCP enabled interface
If interface not configured to be UCP enabled, message
discarded.
If the received tagged vlan in the message is configured
to be a ufo vlan, continue
If tagged member, continue.
If interface UCP enabled, continue.
471
Layer Two Switching
TABLE 4-23
Processing of Upstream Port Notification Message Sent by Upstream Device
Process
The layer 2 source address value of the active upstream
node which originally sent the message is stored against
the received ufo vlan vid value.
This is done so that this non-upstream node knows which
node is the upstream node for this ufo vlan in the network
topology in case it has to send the upstream port topology
change message during a network link fail or link recovery
condition.
Check if other UCP enabled ports for this ufo vlan are
configured
If no other UCP-enabled interfaces for this UFO VLAN
configure, message is discarded.
If other UCP-enabled ports for this UFO VLAN are configured, continue.
Received message sent over all other UCP-enabled network module interfaces that have been configured for this
UFO VLAN.
If no other UCP enabled ports for this ufo vlan are configured or if any are configured to be UCP enabled but
are not tagged members of the ufo vlan then the message is just discarded.
4.7.2.2 Topology Change Message
This message is used for fault and recovery scenarios:
• Link Fault - When a link fault occurs, each of the nodes spanning the faulty link send the upstream port topology change
message for each of the ufo vlans towards its upstream node. This topology change message will indicate to the upstream
node that this message is being sent as a result of a link failure in the network.
• Link Recovery - When a link fault gets corrected and the recovery is detected then each of the nodes spanning this recovered link send the upstream port topology change message for each of the ufo vlans towards its upstream node. This
topology change message will indicate to the upstream node that this message is being sent as a result of a link recovery
in the network.
The non-upstream nodes that originate this topology change message for each of the ufo vlans send the message over all the
applicable UFO-enabled network ports and the ufo vlan may or may not have an upstream port (based upon where the fault
is) until the node hears from the upstream node again when it receives this topology change message.
Each of the other nodes between the originating node and the upstream node receive the Topology Change Message and
take the actions listed in the following table.
TABLE 4-24
Processing of Topology Change Message by Nodes Between Originating and
Upstream Node
Process
layer 2 destination address value and sends it to the cpu.
to be a ufo vlan.
If tagged member, continue.
472
Layer Two Switching
TABLE 4-24 Processing of Topology Change Message by Nodes Between Originating and
Upstream Node (Continued)
Process
Check if message is received on UCP enabled interface
If interface not configured to be UCP enabled, message
discarded.
If interface UCP enabled, continue.
The message is sent as is over all the other applicable UCP
enabled network ports. The ufo vlan may or may not have
an upstream port (based upon where the fault is) until the
node hears from the upstream node again when it receives
this topology change message
Topology Change Message received by upstream node
layer 2 destination address value and sends it to the cpu.
to be a ufo vlan
Check if port on which message received is configured as
UFO-enabled port
If not UFO-enabled, message is discarded.
Check if this node is an upstream node for the UFO
VLAN.
If this is not an upstream node, message is discarded
If tagged member, continue
If UFO-enabled, continue.
If this is an upstream node, continue
The upstream node does not wait for its periodic timer
expiry to send the upstream port notification messages
over its allowed ring ports. It sends the upstream port
notification message over all the allowed ring ports in rapid
succession a few times after which it settles down to sending the notification message using its periodic timer
The non-upstream nodes receive the upstream port notification message and process them as described in Table 423.
4.7.2.3 UCP Redundancy (Different Nodes)
With UCP redundancy, a standby upstream interface can be configured. In most cases these interfaces for the UFO VLAN
will be on separate nodes, so redundancy is provided at the node level.
1.
The active node does not actively source hello type messages. It is responsible for responding to messages received from
standby nodes. This is done to reduce chatter and would be redundant for networks which do not have a standby node.
2.
The active node response contains the state of the upstream port - Up or Down.
3.
The active node response is to flood out all UCP enabled network ports. This is to provide information to all nodes in the
network so that each can maintain an active and secondary “topology”.
4.
The active node must source an unsolicited response if its configured upstream port changes state. This allows the active
node to “monitor” its upstream port and to provide rapid failover and recovery characteristics.
5.
The standby node is responsible for sourcing hello messages on a rapid periodic basis. These hello messages must be sent
for each VLAN for which it is a standby for. These hello messages are flooded out each UCP enabled network port.
6.
The standby node must assume that the active node is no longer in service if it fails to receive 2 or more hello responses.
473
Layer Two Switching
4.7.2.4 UCP Redundancy (Same Node)
If the active and standby interfaces are on the same node, all messages are still flooded over the UCP-enabled network ports.
However, since both active and standby are on the same node, the failover and message can be solely determined by port
state.
4.7.3 UCP with STP
Many of the concepts about the interaction of UCP with EPSR also apply to UCP with STP; the STP protocol ensures there
are no loops in the converged (reconverged) topology, while UCP ensures that the UFO VLAN interfaces are set correctly
for that topology. Since STP is a port based topology (as opposed to EPSR which is a VLAN based topology), the STP will
perform blocking on the port and therefore block all the VLANs on that port. The user should therefore ensure that no
VLANs are isolated when STP changes the topology for the relevant nodes. (Refer to 4.4.3.20 for details and an example.)
4.7.4 UCP with EPSR/RSTP
Although UCP can act as a standalone protocol when the topology control is further up in the network, it can interact with
the STP and EPSR features; for example, in a ring network, the EPSR feature ensures there is no loop created over the protected domain, while the UPC is used in the non-upstream nodes to determine the upstream interface for the (protected)
UFO VLANs.
Figure 4-23 shows the resulting topology. Switch A is the upstream node for the UFO VLAN (V_80) in the domain, and so
sends out the Upstream Port Notification message (see 4.7.2.1) for each of the UFO VLANs over its two ring ports. This
message is received by nodes B and C on one side of the ring and node D on the other. Note that switch C does not receive
this message from Node D because the messaging is over the protected VLAN and this is blocked by EPSR.
The message when received at each node is intercepted by the classifier and sent to the CPU. If all ingress checks pass (see
4.7.2.1), each node stores the VLAN ID (80) along with the MAC address of the upstream node (Node A). The message is
then forwarded over the other ring port towards the next node in the ring network. Finally, the message is discarded at node
C because the UFO VLAN is logically blocked.
474
Layer Two Switching
Upstream Network
Primary
Upstream
Interface
= Physical Link
= Control VLAN (1200)
= Data VLAN (600)
10.0
A
DOWN
11.2
600
10.1
DOWN
SBx900
Secondary
Upstream
Interface
1200
1
4
UP
UP
10.1
1200
B
A
D = Devices
1
4 = Links
10.2
DOWN
Master
Node
PP
D
10.1
DOWN
SP
2
UP
10.1
10.2
3
1200
C
600
EPSR_UCP_Interop
FIGURE 4-23
600
1200
10.0
600
11.2
DOWN
over Physical Link 3
UPC is part of VLAN
messaging and so it
is blocked
EPSR Topology with UCP
4.7.4.1 Fault Message and Recovery - Physical Link
Assume a fault occurs on link 2. The EPSR protocol reacts and takes steps to change the topology so that no node is isolated
and no new loops are formed. The UPC protocol makes sure that the direction of the ports (upstream, downstream) are set
correctly.
On node C, the UCP protocol sends the Upstream Port Topology Change (4.7.2.2) message for the UFO VLAN. This message is received and forwarded to the next node until the node that receives the message is the upstream node (A). Therefore, nodes D and A would receive the message.
On Node B, the UCP protocol would also send the Upstream Port Topology Change message for the UFO VLAN. This message is also received and forwarded to the next node until the node that receives the message is the upstream node (A).
Therefore, nodes B and A would receive the message.
Node A will then send an unsolicited (non-timer) “Upstream Port Notify” message for the UFO VLAN(s) over both its ring
ports a few times before settling back to its normal (timer) sending procedure.The other nodes receive this message, process
it as described earlier, and the result is a reconverged topology in which the upstream/downstream direction of the interfaces
are configured correctly.
475
Layer Two Switching
Upstream Network
Primary
Upstream
Interface
= Physical Link
= Control VLAN (1200)
= Data VLAN (600)
10.0
A
DOWN
11.2
600
10.1
DOWN
SBx900
Secondary
Upstream
Interface
1200
1
4
UP
UP
10.1
1200
B
A
D = Devices
1
4
10.2
DOWN
Master
Node
PP
D
10.1
DOWN
SP
2
3
1200
C
600
DOWN
FIGURE 4-24
UCP Protocol changes
direction of interfaces
to match new topology
10.1
10.2
EPSR_UCP_Interop
600
1200
= Links
10.0
600
11.2
UP
UCP and EPSR - Fault Recovery
4.7.5 Configuring UCP with ESPR
Table 4-25 shows the steps involved in configuring the PRIMARYUPSTREAM node for Figure 4-23.
TABLE 4-25
Step
Configuration Procedure for UCP/EPSR/RSTP
Command
Description/Notes
Create the Control VLAN and add it to the appropriate interfaces
1
CREATE VLAN vid=1200 FORWARDINGMODE=STANDARD
FRAME=TAGGED
The default for FORWARDINGMODE is
STANDARD, but this is shown here to contrast
this with the Data VLAN
476
Layer Two Switching
TABLE 4-25
Step
Configuration Procedure for UCP/EPSR/RSTP
Command
Description/Notes
Create the Data VLAN as a UFO VLAN and give it the attributes to use UCP and PRIMARYUPSTREAM
2
CREATE VLAN vid=600 FORWARDINGMODE=UPSTREAMONLY
ADD VLAN 600 INTERFACE 10.0,10.1,11.2 FRAME=TAGGED
SET VLAN 600 INTERFACE 10.1,11.2 FORWARDING=UCP
SET VLAN 600 INTERFACE 10.0 FORWARDING=PRIMARYUPSTREAM
Set the GE interfaces as having a direction of NETWORK
3
SET INTERFACE=10.0,10.1,11.2 GE DIRECTION=NETWORK
Configure the node for EPSR.
4
CREATE EPSR=ALLIED TRANSIT
ADD EPSR ALLIED VLAN=1200 TYPE=CONTROL
ADD EPSR ALLIED VLAN=600 TYPE=DATA
Configure the node for RSTP. The path cost for the primary node should be lower than the secondary node.
5
SET STP PROTOCOL=RSTP FORCE
SET STP INSTANCE=MAIN INTERFACE=10.0 PATHCOST=40000
SET STP INSTANCE=MAIN INTERFACE=10.1,11.2 PATHCOST=10
Enable STP
6
ENABLE STP
Using the SET command, you can turn on the Enhanced Recovery feature.
7
SET EPSR allied ENHANCEDRECOVERY=ON
477
Layer Two Switching
4.7.6 Summary of Topology Configurations for UCP
The following table lists the various network configurations where Upstream forwarding can be applied with or without UCP
and the configuration rules that apply.
TABLE 4-26
Configurations with and without UCP and Associated Rules
Configuration
Rules
STP, without UCP
STP Root is the Upstream Node, with VLAN-port FORWARDING as
- PRIMARYUPSTREAM - Example when forwarding to a Router
- DOWNSTREAM - For vlan-ports attached to other STP bridges
Non-root STP nodes configure each VLAN-port
- FORWARDING value as STP: For ports running STP and not Edge Ports
- DOWNSTREAM: For remaining ports this VLAN
STP, with UCP
Root Bridge can be located anywhere in the topology
Primary Upstream port can be on any node in the topology, independent of the
Root Bridge.
Secondary Upstream port can be on any node in the topology, independent of
the Root Bridge.
EPSR, without UCP
EPSR Master Node is the Upstream Node
Configure the EPSR Master node with VLAN/port FORWARDING as
- Control VLAN is set to STANDARD VLAN
- Protected VLANs are UFO, and FORWARDING value is:
- PRIMARYUPSTREAM for non PP/SP ports
- DOWNSTREAM for PP/SP ports
EPSR Transit Node
Configure the EPSR Transit node with VLAN/port FORWARDING as
- Control VLAN is set to STANDARD VLAN
- Protected VLANs are UFO, and FORWARDING value is:
- EPSR for EPSR ring ports
- DOWNSTREAM for other ports
EPSR, with UCP
EPSR Master Node is any node in the ring
Primary Upstream port can be on any node in the ring, independent of the Master Node
Secondary Upstream port can be on any node in the ring, independent of the
Master Node
EPSR and RSTP, with UCP
Topology must be loop-free as described in EPSR and RSTP sections
Primary Upstream port can be located anywhere.
Secondary Upstream port can be located anywhere.
4.7.7 UCP Commands
To configure a UFO VLAN on an interface, the previously described ADD VLAN INTERFACE and SET VLAN INTERFACE commands are used, which include UCP as a FOWARDING parameter value.
478
Layer Two Switching
479
Layer Two Switching
4.8 HVLAN (Port Based and VLAN Based)
4.8.1 Port Based HVLAN
A VLAN allows broadcast traffic to flood only ports that are members of that VLAN. Moreover, ports can be tagged or
untagged, with a tagged Ethernet frame including the VID field that uniquely identifies the VLAN of the frame. The number of
VLANs that can be configured across the network operator network is restricted to the 12-bit VID field (1 to 4094).
To help overcome the VLAN addressing limitation, an additional or outer tag can be added on top of the 802.1q tagged. The
use of the additional tag creates a hierarchical VLAN (HVLAN).
At the port, incoming customer frames are wrapped with an outer tag that is used to switch the traffic across the network.
At the port for the outgoing traffic, the outer tag is removed and the frame is delivered to the customer’s VLAN.
By using this outer tag, Allied Telesis system users can expand service to customers in the following ways:
• Two VLAN tags are used to identify the customer VLAN, in theory expanding the number range of customer VLAN tags
to 4094 * 4094.
• Since the inner tag is used by each customer, the VLAN ID for different customers may be the same (overlap). Thus, the
customer VLAN ID is preserved and unchanged as it crosses the network.
By using this outer tag, network operators can tunnel the VLANs of each customer into a single VLAN (the VLAN ID of the
outer tag) and send them across the network, allowing businesses to interconnect devices from multiple locations in a network operator area.
To understand the HVLAN feature, the 802.1q tagged ethernet frame and the fields it contains must be fully understood.
These are listed in Table 4-27.
TABLE 4-27
VLAN Tag Fields
Field Name
Length
Description
Tag Protocol Identifier
(TPID)
2 octets
The TPID is used to identify the frame as a tagged frame.The value
of the TPID for an 802.1q ethernet tagged frame is 0x8100
User Priority
3 bits
The User Priority field can represent up to eight priority levels. (This
field is explained in greater detail when discussing traffic management, in Priority Queuing (Layer 2).
Canonical Format Indicator
(CFI)
1 bit
The CFI is a flag to indicate whether all MAC address information
that may be present in the MAC data carried by the frame is in
canonical format.
VLAN ID (VID)
12 bits
The VID identifies which VLAN the frame belongs to, with a range
of 1 to 4094.It consists of the Tag Protocol Identifier (TPID) and
the Tag Control Information (TCI).
The TPID, which is used to identify the frame as a tagged frame in 802.1q, has a value of 0x8100. The TPID value for the
HVLAN (the outer tag), is configurable, and should be set depending on the interconnecting vendor’s recommendation.
Note:
To obtain the TPID value that each vendor supports, consult the interconnecting vendor’s documentation.
4.8.2 Port Based HVLAN Configuration
Figure 4-25 shows a configuration where both 802.1q and HVLANs are created. The 802.1q VLAN (10), is used for multicasting for video. The HVLAN is provisioned for a business customer who has their own private network and wishes to connect this network to devices on SBx3112 systems. The port-based HVLANs are configured on System A (interfaces 2.0 and
2.1) and on System E (interface 3.0).
480
Layer Two Switching
Video
Head
Upstream Network
6
= Physical Link
= 802.1q VLAN (10)
= HVLAN (H_100)
0.0
5
H_100
0.0
H_100
0.2
0.1
H_100
D
E
3.0
60
1
10
30
20
40
4
to Business
Network
10
0.2
0.1
= Business VLANs
40
60
H_100
A
E
= Devices
1
6
= Links
60
B
H_100
(Note 2)
C
0.1
0.2
2
3
= STP blocks
physical link
0.1
0.2
60
A
H_100
H_100
H_100
2.0
2.1
Note 2 - Business VLANs can be configured on
Devices B/C/D
2.2
10
FIGURE 4-25
20
40
30
30
HVLAN Configuration (Port Based)
4.8.3 Configuring Port Based HVLAN
The default configuration for HVLANs is that there are no HVLANs configured, with TAGALL set to OFF and all TPID values
set to 0x8100.
481
Layer Two Switching
The following rules are for setting the TAGALL and TPID values for a port-based HVLAN configuration:
• When adding a Network Interface to an HVLAN, the user should include FRAME=TAGGED
• When adding a Customer Interface to an HVLAN, the user should include FRAME=UNTAGGED
Note:
Untagged is the default.
• On Customer interfaces, the port-based HVLAN tunnel is not operational until the interface is set to tagall=on
• DHCP Relay/Snooping and IGMP Snooping must be disabled for the Customer Interface prior to setting the interface to
tagall=on. Examples of the IGMP and DHCP commands are:
• Disable igmp interface=5.2
• Disable dhcp all interface=5.2
• An interface with a TPID value set can be a member of more than one HVLAN.
• An HVLAN can consist of one or more interfaces with TPIDs set at different values.
• When an interface is removed from an HVLAN, it will become a member of the an 802.1q default VLAN, and the TPID
value should be set back to the default 0x8100 value.
482
Layer Two Switching
TABLE 4-28
Step
Configuration Procedure for Port Based HVLAN
Command
Description
Create the port-based HVLAN
1
CREATE HVLAN=H_100 VID=100 TYPE=PORTTUNNEL
Creates a port-based VLAN tunnel.
Set the Network interfaces to a TPID value
2
SET INTERFACE=0.1,0.2 TPID=0x9100
Set this only when sure that the Network interface is expecting this value.
Note: This step is only needed when connecting
to a non-Allied Telesis device.
Associate HVLAN with Network interfaces.
3
ADD HVLAN=H_100 INTERFACE=0.1,0.2
FRAME=TAGGED
Adds a tagged HVLAN to Network interfaces.
Associate HVLAN with line card ports.
4
ADD HVLAN=H_100 INTERFACE=2.0,2.1
FRAME=UNTAGGED
Adds an untagged HVLAN to Customer interfaces.
Disable IGMP and DHCP on the customer interfaces
5
DISABLE IGMP INTERFACE=2.0,2.1
DISABLE DHCP ALL INTERFACE=2.0,2.1
On Customer interfaces, ensure IGMP and DHCP
are correctly configured.
Set line card interface to TAGALL=ON
6
SET INTERFACE=2.0,2.1 TAGALL=ON
Observe the configuration
7
SHOW HVLAN FULL
--- HVLAN Information --------------------------Type..................................
Name..................................
Identifier............................
Status................................
Forwarding Mode.......................
Untagged interfaces...................
Tagged interfaces.....................
Tunneled VLANs........................
TABLE 4-29
Step
HVLAN - port tunnel
H_100
100
static
Standard
ETH:[2.0,2.1]
ETH:[0.1,0.2]
n/a
Configuration to Deprovision a Port Based HVLAN
Command
Description
Set the TAGALL parameter to OFF.
1
SET INTERFACE=2.0,2.1 TAGALL=OFF
You must set TAGALL=OFF for the customer
interfaces before you can delete the interface
from the HVLAN.
483
Layer Two Switching
TABLE 4-29
Step
Configuration to Deprovision a Port Based HVLAN
Command
Description
Delete ALL the interfaces from the HVLANs
2
DELETE HVLAN=H_100
INTERFACE=0.1,0.2,2.0,2.1
Destroy the HVLANs
3
DESTROY HVLAN=H_100
Set the TPID values back to 0x8100
4
Enable IGMP and DHCP on the Customer interfaces (optional)
5
ENABLE IGMP INTERFACE=2.0,2.1
ENABLE DHCP ALL INTERFACE=2.0,2.1
484
Layer Two Switching
4.8.4 VLAN Based HVLAN
This feature allows a customer VLAN that is configured on several interfaces to have an outer tag applied. The outer VLAN
can be configured so that it goes to a specific ISP, such as one that provides data or voice.
Note:
VLANs that are configured for multicast traffic, such as those for video service, are not part of this feature.
With the port-based HVLAN, once a customer interface is assigned to an HVLAN all ingress frames are internally tagged
with the HVLAN. In contrast, the VLAN-based HVLAN feature assigns an outer tag to a single-tagged egress frame (exiting the shelf).
4.8.4.1 VLAN-based HVLAN Configuration
Refer to Figure 4-26, which shows an example configuration with the following VLANs:
Note:
The outer tags that are applied to VLAN-based HVLANs are referred to as Service VLANs, or SVLANS.
• VLAN 10 is a multicast VLAN that is routed to a Video Head end.
• VLAN 20 is a VLAN for data service and connects to an ISP that handles data service.
• VLAN 30 is a VLAN for voice service and connects to an ISP that handles voice service.
VLAN 20 traffic is given an outer tag of SVLAN 200 and then passed through the systems to the ISP. Note that other customers on different customer interfaces (and different systems) can also be a member of VLAN 20 with an outer tag of
SVLAN200, and routed to the ISP. The same is true for VLAN 30.
485
Layer Two Switching
Video
Head
Upstream Network
= Physical Link
= 802.1q VLAN (10)
= SVLAN (S_200)
5
Voice ISP
= SVLAN (S_300)
Data ISP
0.0
= 802.1q VLAN (20)
20
DATA
30
VOICE = 802.1q VLAN (30)
S_300
0.2
0.1
S_200
D
10
(Note 1)
1
(Note 2)
0.2
10
S_200
A
E
= Devices
1
5
= Links
0.1
(Note 1)
S_300
4
(Note 1)
(Note 2)
10
(Note 2)
B
Note 1 = Can provision Customer
VLAN 20 to S_200 and
VLAN 30 to S_300
0.1
S-200
S_300
C
0.2
Note 2 = Cannot provision Customer
VLAN 200 or 300 (overlap)
2
3
= Blocked by Topology
0.0
S_300
0.1
S_200
S_300
S_200
(Note 2)
30
10
20
2.2
20
FIGURE 4-26
10
A
2.3
30
20
10
30
VLAN-Based HVLAN Configuration
4.8.4.2 HVLAN Support for the SBx3112 Interfaces
The SBx3112 can support HVLAN on cards that can support network interfaces.
The SBx3112 does not allow Tagged-only frame acceptance on an interface that is a member of a customer VLAN (CVLAN)/
tunneled VLAN. This means that if an interface is an untagged member of a VLAN from which the interface is being deleted
and the interface is a member (tagged and untagged) of customer VLAN (CVLAN), the interface delete is not allowed and an
error message is generated.
For example, this shows the rejection of an attempt to delete the default untagged vlan on an interface that has been associated with a CVLAN:
officer SEC>> CREATE HVLAN VID 300 TYPE VLANTUNNEL
486
Layer Two Switching
Info (040590): Successfully created HVLAN(s) 300
officer SEC>> CREATE VLAN VID 20
Info (040590): Successfully created VLAN(s) 20
officer SEC>> ADD HVLAN 300 INT 0.0 FR TAGGED
Processing.....
Info (040604): Successfully added HVLAN(s) 300 on interface(s) ETH:[0.0]
officer SEC>> ADD VLAN 20 INT 1.0 FRAME TAGGED
Processing.....
Info (040604): Successfully added VLAN(s) 20 on interface(s) ETH:[1.0]
officer SEC>> ADD VLANTUNNELMAP VLAN 20 HVLAN 300
Info (040556): 1 VLANs were added to the tunnel for HVLAN 300
officer SEC>> DEL VLAN 1 INT 1.0
Processing.....
Error (040617): Interface(s) ETH:[1.0] can not deleted from VLAN(s) 1
Because interface(s) acceptable frame type would become
VLAN-tagged only.
officer SEC>>
4.8.5 Configuring VLAN Based HVLAN
When the SBx3112 is initially booted up (or from a “Purge database”), all interfaces will be configured to be the default
VLAN (VID 1), and no HVLAN is created by default.
• When adding a Network Interface to an HVLAN, it should be provisioned with FRAME=TAGGED (example “add hvlan
•
•
•
•
•
•
Btunnel interface=10.0 frame=tagged”)
The Customer Interfaces that are participating in the VLAN-based HVLAN tunnel should not be a member of the
HVLAN; only the Network direction interfaces are a member of the HVLAN.
You cannot have a CVLAN that is a member of its associated HVLAN on the same card. If you try to do so you will
receive the message ‘HVLAN and VLAN member interfaces can not coexist on card <card_number>’.
The Network Interfaces that are tunneling Customer VLANs via the VLAN-based HVLAN tunnel should not be a member of the Customer VLANs (the system will configure the Customer VLANs on the Network Interfaces).
Customer Interfaces that are participating in the VLAN-based HVLAN tunnel can be a member of many VLANs, tagged
or untagged (only one untagged VLAN).
Any single VLAN can map to only one VLAN-based HVLAN tunnel. The HVLAN tunnel is defined by the creation of the
HVLAN and the interfaces that are a member of the HVLAN. When a VLAN is associated with a tunnel, it will be associated with the tunnel on all of the interfaces that are a member of the tunnel (HVLAN).
To change the VID of an existing HVLAN, the HVLAN must be removed with the DESTROY HVLAN command and created again.
Do not use the “tagall=on” setting; this is only used for port-based HVLAN tunneling.
•
• IGMP packets are not tunneled; and therefore, if multicast is to be supported, then the Customer Interface should be
enabled for IGMP Snooping.
• DHCP packets can either be tunneled or Relayed/Snooped by the local Network Access product. If tunneling of DHCP
packets is desired, then DHCP Relay/Snooping can be disabled on the Customer Interface for the VLANs that are to be
tunneled, or DHCP Snooping could be used. If the desire is to have the Network Access product handle the DHCP pack-
487
Layer Two Switching
ets outside of the tunnel, then DHCP Relay (not DHCP Snooping) can be configured on the Customer Interface for the
VLANs.
4.8.5.3 Feature Interactions (Port-based and VLAN-based HVLANs)
• An HVLAN can be either Port-based or VLAN-based, but not both.
• An HVLAN cannot be changed to/from Port-based from/to VLAN-based; the HVLAN must be destroyed and recreated
to be changed.
The following procedure creates the VLAN-based HVLANs shown in Figure 4-26.
TABLE 4-30
Step
Configuration Procedure for VLAN Based HVLAN
Command
Description
Create HVLAN
1
CREATE HVLAN=S_200 VID=200 TYPE=VLANTUNNEL
Creates a VLAN-based HVLAN.
Create the standard 802.1q standard VLANs
2
CREATE VLAN=VIDEO VID=10
CREATE VLAN=DATA VID=20
CREATE VLAN=VOICE VID=30
Creates standard VLANs.
Associate the S_200 and S_300 to ports 0.0/0.1
3
ADD HVLAN=S_200 INTERFACE=0.0,0.1
FRAME=TAGGED
ADD HVLAN=S_300 INTERFACE=0.0,0.1
FRAME=TAGGED
Adds HVLANs to Network interfaces.
Associate the standard VLAN with the ports 2.2./2.3
4
ADD VLAN=VIDEO INTERFACE=2.2,2.3
Adds standard VLAN (VIDEO) to Customer
interfaces.
Set the NM ports 0.0 and 0.1 to a TPID value (optional)
5
Note: This step is needed only when connecting
to a non-Allied Telesis device.
Associate the DATA and VOICE VLANs to the VLAN-based HVLAN tunnels.
6
ADD VLANTUNNELMAP VLAN=DATA
HVLAN=S_200
ADD VLANTUNNELMAP VLAN=VOICE
HVLAN=S_300
Adds standard VLANs (DATA, VOICE) to HVLAN
tunnels.
Destroy the HVLANs
7
DELETE VLANTUNNELMAP DATA S_200
DELETE VLANTUNNELMAP VOICE S_300
Disassociates the DATA and VOICE VLANs from
the VLAN-based HVLAN tunnels.
DELETE HVLAN=S_200 INTERFACE=0.0,0.1
Removes the Network interfaces 0.0 and 0.1 from
HVLANs S_200 and S_300.
DESTROY HVLAN=S_200,S_300
Destroys HVLANs S_200 and S_300.
488
Layer Two Switching
489
Layer Two Switching
4.8.7 HVLAN Commands
Table 4-31 lists the CLI commands for the HVLAN feature.
TABLE 4-31
HVLAN Commands
Commands
ADD HVLAN INTERFACE
ADD VLANTUNNELMAP VLAN HVLAN
CREATE HVLAN VID
DELETE HVLAN INTERFACE
DELETE VLANTUNNELMAP VLAN HVLAN
DESTROY HVLAN
SET HVLAN INTERFACE
SHOW HVLAN
SHOW VLANTUNNELMAP
490
Layer Two Switching
ADD HVLAN INTERFACE
Syntax
ADD HVLAN={ hvlanname-list | vid-range } INTERFACE={ type:id-range | id-range
| ifname-list | ALL } [ FRAME={ UNTAGGED | TAGGED } ]
Description
Adds interfaces to the specified layer-2 virtual network. When adding interfaces to an HVLAN, some
restrictions must be considered. Refer to 4.8.3.2 and 4.8.5.2.
Mode
Manager
Options
Option
Description
Range
Default
Value
HVLAN
The list of provisioned HVLAN names, separated by a
comma, or the range of VLAN IDs.
NA
NA
INTERFACE
The interfaces that are to be added to the HVLAN.
NA
NA
FRAME
TAGGED - the frames are transmitted with a VLAN tag.
UNTAGGED - the frame is transmitted without a VLAN
tag.
NA
UNTAGGED
Release Note
NA
Example
ADD HVLAN=S_300 INTERFACE=0.0,0.1 FRAME=TAGGED
491
Layer Two Switching
ADD VLANTUNNELMAP VLAN HVLAN
Syntax
ADD VLANTUNNELMAP VLAN={ vlanname-list | vid-range }
HVLAN={ hvlanname | vid }
Description
Makes the association of the VLAN to a VLAN-based HVLAN tunnel. The tunnel is defined by the
HVLAN and its interface membership.
Mode
Manager
Options
Option
Description
Range
Default
Value
VLAN
The list of provisioned VLAN names, separated by a
comma, or the range of provisioned VLAN IDs that are
to be mapped to the HVLAN tunnel
NA
NA
HVLAN
The HVLAN name or id that represents the tunnel.
NA
NA
Release Note
NA
Example
ADD VLANTUNNELMAP VLAN=VOICE HVLAN=S_300
492
Layer Two Switching
CREATE HVLAN VID
Syntax
CREATE HVLAN=[ hvlanname ] VID={ 2..4094 | vid-range } [ TYPE={ PORTTUNNEL |
VLANTUNNEL } ]
Description
Creates a Hierarchical Virtual LAN (HVLAN) entry with a unique name and identifier (VID). Once created, the HVLAN’s VID cannot be changed. The HVLAN must first be removed with the DESTROY
HVLAN command and then created again. When an HVLAN entry is created, it is assigned to the
default STP. A maximum of 4093 HVLANS/VLANS can be created with any VID in the range 2 to 4094.
Mode
Manager
Options
Option
Description
Range
Default
Value
HVLAN
The name for this HVLAN.
NA
vlan{VID},
e.g., vlan3000
VID
The VLAN id or range of vids. A maximum of 4093
NA
NA
NA
PORTTUNNEL
HVLANs can be created with any VID in the range
2 to 4094.
TYPE
PORTTUNNEL - Port-based HVLAN
VLANTUNNEL - VLAN-based HVLAN
Release Note
NA
Example
493
Layer Two Switching
DELETE HVLAN INTERFACE
Syntax
DELETE HVLAN={ hvlanname-list | vid-range } INTERFACE={ type:id-range | idrange | ifname-list | ALL }
Description
Removes the interface association from the specified Hierarchical VLAN (HVLAN).
Mode
Manager
Options
Option
Description
Range
Default
Value
HVLAN
comma, or the range of HVLAN IDs.
NA
NA
INTERFACE
The interface where the HVLAN association is being
deleted.
NA
NA
Release Note
NA
Example
494
Layer Two Switching
DELETE VLANTUNNELMAP VLAN HVLAN
Syntax
DELETE VLANTUNNELMAP VLAN={ vlanname-list | vid-range | ALL } HVLAN={ hvlanname | vid }]
Description
Disassociates a VLAN from a VLAN-based HVLAN tunnel.
Mode
Manager
Options
Option
Description
Range
Default
Value
VLAN
NA
NA
NA
NA
ALL - All VLANs associated with this HVLAN
HVLAN
The name or ID of the VLAN-based HVLAN tunnel
Release Note
NA
Example
DELETE VLANTUNNELMAP VLAN=VOICE HVLAN=S_300
495
Layer Two Switching
DESTROY HVLAN
Syntax
DESTROY HVLAN={ hvlanname-list | vid-range | ALL }
Description
Destroys the specified Hierarchical VLAN (HVLAN) or all HVLANs. An HVLAN cannot be destroyed
if interfaces are associated with it.
Mode
Manager
Options
Option
Description
Range
Default
Value
HVLAN
NA
NA
ALL - all HVLANs are destroyed.
Release Note
NA
Example
DESTROY HVLAN=S_200,S_300
496
Layer Two Switching
SET HVLAN INTERFACE
Syntax
SET HVLAN={ hvlanname | vid } INTERFACE={ type:id-range | id-range | ifnamelist | ALL } [ FRAME={ UNTAGGED | TAGGED } ]
Description
Toggles the status of interfaces in a Hierarchical VLAN (HVLAN) between tagged and untagged.
Mode
Manager
Options
Option
Description
Range
Default
Value
HVLAN
The provisioned HVLAN name, or the HVLAN ID.
NA
NA
INTERFACE
The interface where the HVLAN FRAME setting is being
changed.
NA
NA
FRAME
TAGGED - the frames are transmitted with a VLAN tag.
UNTAGGED - the frame is transmitted without a VLAN
tag.
NA
UNTAGGED
Release Note
NA
Example
SET HVLAN=S_200 INTERFACE=0.23 FRAME=TAGGED
497
Layer Two Switching
SHOW HVLAN
Syntax
SHOW HVLAN [ ={ hvlanname-list | vid-range | ALL } ] [ FULL ]
Description
Displays information about the specified Hierarchical VLAN (HVLAN).
Mode
Manager
Options
Option
Description
Range
Default Value
HVLAN
NA
ALL
NA
Summary information for all
HVLANs is displayed
If no HVLAN name or identifier is specified, then ALL is
assumed.
ALL - A summary of all HVLANs is presented.
FULL
Release Note
NA
Example
SHOW HVLAN
Displays detailed information for each HVLAN.
--- HVLAN Information --------------------------------------------------------Name
Tunnel Forwarding Tagged Interfaces
Type
Mode
--------------- ---- ------ ---------- -----------------vlan4000
VID
4000 PORT
Standard
ETH:[3,8-9.2]
Untagged Interfaces
----------------<none>
-------------------------------------------------------------------------------
498
Layer Two Switching
SHOW VLANTUNNELMAP
Syntax
SHOW VLANTUNNELMAP [ VLAN={ vlanname-list | vid-range | ALL } ] [ HVLAN={
hvlanname-list | vid-range | ALL } ]
Description
Shows the VLAN to HVLAN associations for VLAN based HVLANs.
Mode
Manager
Options
Option
Description
Range
Default
Value
VLAN
NA
ALL
NA
ALL
ALL - All VLANs that are associated with HVLANs
HVLAN
ALL - All HVLANs that have association with VLANs.
Release Note
NA
Example
SHOW VLANTUNNELMAP
--- Vlan Tunnel Map Configuration --HVLAN
Tunneled VLANs
---------- -------------------------------------------------------------300
21-30
499
Layer Two Switching
4.9 VLAN Translation
4.9.1 Introduction
When customer networks are connected through network operator networks, customers may want to keep their existing
VLAN assignments. It is not uncommon for the VLAN IDs to be same for different customers (overlap). To allow this overlap, a network operator needs to be able to change (translate) a customer VID into a unique VLAN ID for transport across
the network.
To do this, an 802.1q tagged VLAN can be configured with this translations option. The general flow of commands to perform this translation are:
• Create a VLAN (CREATE VLAN=VLAN100 VID=100)
• Add an interface to the VLAN as a tagged port (ADD VLAN=VLAN100 INTERFACE=1.0 FRAME=TAGGED)
• Turn the translation option on for the port for a customer VLAN ID (SET VLAN=VLAN100 INTERFACE=1.0 TRANSLATE=10)
This will result in the following:
• When a tagged frame with a VLAN ID of 10 enters the interface 1.0, the VLAN ID will be translated to VLAN ID 100.
• When the tagged frame with VLAN ID 100 leaves the interface 1.0, the VLAN ID will be translated (back) to VLAN ID
10.
This is shown in more detail in the configuration example in 4.9.5.
4.9.2 Example Configuration
Figure 4-27 shows a set of SBx3112s that are configured for two customers, A and B, where each in their network has a
VLAN 10 configured. Moreover, there is also a VLAN 10 configured against other interfaces.
500
Layer Two Switching
Upstream Network
6
= Physical Link
= translate 10 - 100
Customer A)
0.0
5
E
= translate 10 - 200
(Custormer B)
100
200
10
100
200
10
3.0
3.1
3.2
0.0
= VLAN (10)
0.2
0.1
100
D
10
10
(Note 1)
1
200
0.2
Customer
B
0.1
(Note 1)
10
100
10
Customer
A
4
A
E
= Devices
1
6
= Links
10
200
B
100
200
C
0.1
(Note 1)
0.2
0.2
200
2
3
0.1
0.2
10
A
100
Note 1 - Can provision similar translations
for systems B, C, and D if providing same services
for Customer A and B
100
200
10
2.0
2.1
2.2
10
10
Customer
A
FIGURE 4-27
= STP blocks
physical link
Note 2 - Can provision VLAN 10 against other interfaces,
but not against interfaces that are set up to translate
packet with VLAN 10
(Note 2)
Customer
B
Translations Example Configuration
501
Layer Two Switching
4.9.3 TPID Translations (Extreme VLAN Support)
This feature is required in order to support Extreme HVLANs.
The XE4 supports TPID configuration for each port. Thus XE4 ports configured for TPID=x9100 for example will send out
single or double tagged packets with x9100 in the outermost tag. On ingress, packets whose single or double tag is x9100 are
considered to indeed be a tag and the TPID will be translated to x8100.
The TPID translation feature is available on the GE8 SM and the XE1 NM.
On the GE and XE cards, tagged packets are identified by the FPGA based on the TPID that the interface has been configured
with. Tagged packets that arrive with a TPID other than the configured TPID will be considered to be untagged packets by the
FPGA.
The interactions of TPID translation and other features are as follows:
• VLAN translation and TPID translation can be configured on the same interface, so that a VLAN translation AND a TPID
translation can occur on the same packet.
• VLANTUNNEL HVLAN(s) and TPID translation can be configured on the same interface. When a tunnel tag is being
added on egress, the TPID translation will occur on the outer tag only. The TPID of the inner tag will remain unchanged.
4.9.4 HVLAN and Translation Feature Interactions
With the HVLAN and translation options, VLAN configurations interact with each other and other features as follows:
• The HVLAN (both port- and VLAN-based) and translation feature are not compatible on the same port. Once a port is
•
•
•
•
configured with the HVLAN option, it cannot use the translation feature, and vice-versa. This is enforced by the CLI.
For traffic management, classifiers are used to filter traffic according to certain criteria, and this may be affected with the
double tagging of frames.
Link Aggregation (LAG) can still be enabled for a port that has an HVLAN as long as all member ports of the LAG group
belong to the same VLANs, both tagged and untagged.
IGMP Snooping and Port-based HVLAN are mutually exclusive features. If IGMP snooping is enabled system
wide and a port has IGMP snooping enabled, that port cannot participate in the HVLAN; if a port is part of an HVLAN,
IGMP snooping cannot be enabled on that port.
Spanning Tree Protocol can be enabled on an HVLAN port, as long as the following applies:
When customer traffic at multiple sites is tunneled over the network operator network, every customer VLAN will need
to build a spanning tree that includes the multiple sites across the VLAN. To enable this, the Bridge Protocol Data Unit
(BPDU) will need to be tunnelled across the network. (Note that the Network Access product does not support tunneling BPDUs.)
Note:
The VLAN-based HVLAN and Translation features can be supported on one system, but in most network
engineering solutions, either one or the other is used.
Note:
As shown below, translated and non-translated VLANs on the same port are not supported in order to avoid the
mixing of a non-translated VLAN traffic onto translated VLAN traffic (which is undesirable); non-translated VLANs
are therefore dropped. Users should be careful in their network design to ensure this.
The following table shows the support for HVLAN and VLAN Translations for each SBx3112 card:
502
Layer Two Switching
TABLE 4-32
HVLAN and VLAN Translation Support for the SBx3112
Feature
GE24POEa
GE24SFP
GE40CSFP
XE4
XE6SFP
Extreme HVLANsb
Y
Y
Y
Y
Y
Can act as an HVLAN network port (Can be tagged
HVLAN member)
Y
Y
Y
Y
Y
Can act as an HVLAN customer port (Can be untagged
HVLAN member)
Y
Y
Y
Y
Y
Can support both tagged and untagged HVLANs (Can
co-exist)
Y
Y
Y
Y
Y
VLANTUNNEL HVLANS
Y
Y
Y
Y
Y
VLAN Translation supportc
Y
Y
Y
Y
Y
VLAN Translation Limit per Port
8
8
8
128
128
a. Also includes the GE24RJ
b. Requires hardware support for replacing packet TPID on egress
c. Null translations are done automatically.
4.9.5 Configuring VLAN Translation
This section describes configuration information, procedures, and commands for the VLAN Translation.
When an SBx3112 switch is initially booted up, VLAN Translation will be configured as follows:
• There is no VLAN translation on any interface.
To configure the VLAN translation option, the following rules apply:
• Refer to Table 4-32 for cards support which translation functions
• There is a one-to-one mapping between the customer VLAN ID and the VLAN ID used for crossing the network operator network. (Each customer VLAN ID can be translated into only one VLAN ID, and vice versa.)
• The customer VLANs to be translated must be tagged.
503
Layer Two Switching
The following procedure shows the commands used to provision and deprovision VLAN translations based on Figure 4-27.
TABLE 4-33
Step
Configuration procedure for VLAN Translation
Command
Description
Configure System A
1
CREATE VLAN=VLAN100 VID=100
Add interfaces to the VLANs
2
ADD VLAN=100 INTERFACE=0.1,0.2,2.0
FRAME=TAGGED
3
ADD VLAN=200 INTERFACE=0.1,0.2,2.1
FRAME=TAGGED
Set the translation option on interface 2.0
4
SET VLAN=100 INTERFACE=2.0 TRANSLATE=10
Translate the Customer A VLAN ID 10 to
100
5
Translate the Customer B VLAN ID 10 to 200.
Configure System E
Create the VLANs
6
Add interfaces to the VLANs
7
FRAME=TAGGED
8
FRAME=TAGGED
9
Translate the Customer A VLAN ID 10 to 100
10
Note:
Systems B, C, and D could also be provisioned for the translation configuration as long as the translated VLANs
(100 and 200) applied to customer A and B. Also, VLAN 10 could not be associated with the SM interfaces that use
translation.
TABLE 4-34
Step
Procedure to Deprovision VLAN Translation
Command
Description
On System A, set the translation option on SM port 2.0 to NONE
1
TRANSLATE=NONE
504
Layer Two Switching
TABLE 4-34
Step
Procedure to Deprovision VLAN Translation
Command
Description
Set the translation option on SM port 2.1 to NONE
2
TRANSLATE=NONE
Destroy the associations between the translated VLANs and their interfaces
3
4
Destroy the two VLANs
5
4.9.6 VLAN Translation Commands
The command that includes the VLAN translation feature is described in ADD VLAN INTERFACE and SET VLAN INTERFACE.
505
5. IGMP and MLD Snooping
5.1 Introduction
The Internet Group Management Protocol (IGMP) and Mulitcast Listener Delivery protocol (MLD) features allow the
SBx3100, positioned as a Layer 2 switch between a multicast router and host devices to snoop the two protocols, i.e. to
monitor the protocol packets sent between the routers and hosts. The SBx3100 can then direct mulitcast traffic from the
router only to hosts that have registered for the mulitcast groups. This allows the product to conserve network bandwidth
by limiting the layer 2 forwarding of IP multicast packets only to the LAN segments that have expressed interest in receiving
packets addressed to a multicast group.
The concept of IGMP and MLD snooping is similar, except that:
• IGMP uses IPv4 Mulitcast addresses.
• MLD uses IPv6 multicast addresses.
5.1.1 Mulitcast Overview - Bandwidth Efficiency
In applications such as video streaming, where the same packet stream is to be delivered to a (varying in number) set of
hosts, mulitcast is used because of its advantages over other messaging types:
• Unicast - This is where a host device sends data to a single other specific host device on the network using IPv4 or IPv6
network addresses specific to individual host devices. Those addresses are mapped to host-specific Ethernet MAC
addresses on a layer-2 network for delivery on an Ethernet-based LAN or VLAN. In this scenario, a stream source (such
as a video server) would need to replicate the stream for each host.
• Broadcast - This is where the stream source sends only one stream and broadcasts the stream to all downstream host
devices. In this scenario, there would be one source video stream, but it would be sent to hosts that may have no interest
in receiving this stream.
• Multicast - Only one stream is sent, but the stream is replicated only to devices that have indicated an interest in the
stream. The stream is therefore common (not sent redundantly) on common network segments, and is replicated only at
the points where the path to the recipients diverge.
5.1.2 IP Mulitcast Addressing
As opposed to unicast addressing, where each device on the network has its own unique IP address and Ethernet MAC
address, a multicast stream's destination address is shared by all the devices interested in that stream. This address is called
the multicast group. (That term may also refer to all the hosts who have subscribed to the stream, or to the data stream
itself.)
In IPv4, a multicast group address is of the form 224.0.0.0/4; i.e. all addresses between 224.0.0.0 and 239.255.255.255, inclusive.
In IPv6, a multicast group address is of the form FF00::/8; i.e. all addresses between FF00:: and FFFF:FFFF:FFFF:FFFF:FFFF:FFFF.
When a source device sends a stream to an IPv4 or IPv6 multicast address, multicast-aware network devices recognize the
addresses as multicast destinations, and send the stream to network segments corresponding to hosts that have subscribed
to the stream, using processes described in the sections below.
506
IGMP and MLD Snooping
Introduction
In a layer-2 network, IP destination addresses must be translated to MAC addresses. Unlike unicast addressing where ARP
(IPv4) or Neighbor Discovery (IPv6) is used to determine a unique host MAC address (programmed into the host hardware)
for each IP address, a multicast address may correspond to multiple hosts, a single host may be subscribed to multiple groups,
and the correspondence between host and group may change dynamically. In other words, multicast MAC addresses may not
be "owned" by any one particular host device, but must be shared across all host devices.
Therefore, IP multicast addresses are mapped to MAC addresses in a well-known fixed scheme. In IPv4, the 23 low-order bits
of the IPv4 address are mapped to the 23 low-order bits of a MAC address that starts with 01:00:5E. For example, the IPv4
address 224.10.20.30 would map to the MAC address 01:00:5E:0A:14:1E. In IPv6, the four low-order bytes of the IPv6
address are mapped to the four low-order bytes of a MAC address that starts with 33:33. For example, the IPv6 address
FF0E::A030:216C would map to the MAC address 33:33:A0:30:21:6C.
Note that for both IPv4 and IPv6, the multicast MAC address range is not large enough to cover the entire IP multicast
address range; for example, the IPv4 address 224.1.1.1 and 225.1.1.1 would map to the same MAC address, and thus a host
that has registered for one of these groups may receive both. Network engineers must keep this in mind when assigning multicast IP addresses in a network.
Outside the 01:00:5E and 33:33 address ranges, certain other Ethernet addresses (used for specific Ethernet protocols) are
considered multicast addresses as well. These include some addresses in the range 01:80:C2:00:00:xx. Addresses within this
range are not treated in the same manner as IP multicast addresses; they may be blocked or flooded by a switch, depending
on the particular address and the switch's configuration.
5.1.3 IP Multicast Routing and Switching
Multicast streams may be routed at layer-3 or switched at layer-2. A multicast router can forward a multicast stream from
one IP subnet to another, based on the IP multicast address. A multicast-capable switch can forward a multicast stream within
an IP subnet to particular interfaces, based on either the IP multicast address or the Ethernet multicast MAC address. The
multicast routing and switching functions may be performed in the same device, or in different devices. Typically, a multicast
router also contains a multicast switching function, but the reverse is not always true.
5.1.4 IP Multicast Group Joining and Leaving
A host that wants to subscribe to a particular multicast stream uses the Internet Group Management Protocol (IGMP) in
IPv4, or the Multicast Listener Discovery (MLD) protocol in IPv6.
In both IGMP and MLD, a subscriber sends a "join" report message on its subnet, with the multicast group address of the
stream it wants to receive. When a multicast router on the subnet sees the "join", it notes the presence of the subscriber on
the subnet. If the multicast stream arrives at the router, the router knows to forward the stream to that subscriber's subnet.
Meanwhile, at layer-2, the multicast switch is snooping (monitoring) the IGMP and MLD protocols to determine on which
particular layer-2 interface the subscriber wants to receive the multicast stream. The multicast switch limits the transmission
to only the interfaces on which active subscribers have joined the group.
A host device that has subscribed to a multicast group is said to be a member of that group.
When a subscribing host is no longer interested in a multicast stream, it may simply allow the stream to expire (the router
"ages out" subscribers after a period of time), or it may send "leave" message to the multicast router. When a multicast
router detects that there are no more subscribers for a particular group on a subnet, it can cease sending the group to the
subnet. Similarly, when a multicast snooping switch detects that there are no more subscribers for a group on a particular
layer-2 interface, it can cease sending the group to that particular interface. This is covered in the overview of the protocol
versions in the next sub-section.
5.1.5 IGMP and MLD Protocols
Following are the versions of the protocols and SBx3100 support:
507
Introduction
5.1.5.1 IGMP Version 1
Defined in RFC 1112, this defines IGMP for IPv4 multicast, and defines Host Membership Report and Query.
• Host Membership Report: this is a message sent from a subscriber host to the multicast router, indicating that it
wants to subscribe to a multicast group. This message is multicast to the group address, so that any current subscribers to
the group also receive the message. This message may be sent spontaneously from a host, or in response to a query message, the next item.
• Host Membership Query: this is a message sent by the multicast querier process on a multicast router. It is sent to the
"all-hosts" multicast address (224.0.0.1) so that all hosts on the VLAN receive the message. The message prompts host
devices to respond back with an indication of which multicast groups they have joined, using report messages.
Note that when a host no longer wishes to subscribe to a group, it simply stops sending reports for that group. If a period of
time elapses and the querier no longer sees any reports for a multicast group on a VLAN, the multicast router ceases transmitting the group to the VLAN.
IGMP version 2 is defined in IETF RFC 2236. IGMPv2 extends IGMPv1 with several changed and added protocol messages:
• Leave-Group: this is a message sent from the subscriber host to the multicast router indicating that it is no longer interested in receiving a multicast group. This is an improvement over IGMPv1, which simply allowed subscriptions to expire
after a period of time. An explicit leave-group ("leave") message prompts the multicast router to query the remaining
hosts on the VLAN to see if any other subscribers for the group are still present (see "Group-Specific Query", below),
and if not, to cease transmitting the group on the VLAN. This allows unsubscribed groups to be terminated much more
quickly as compared to IGMPv1.
• General Query: this is the same as the IGMPv1 host membership query, except that there is an additional maximum
response time field. This field defines the maximum amount of time hosts may delay before sending a membership report
in response to the query. A host (or another router) on the network may identify an IGMPv1 querier by the fact that it
will send a zero value in the maximum response time field of the message; that is an indication to the host to respond to
the query with an IGMPv1 host membership report.
• Group-Specific Query: unlike a general query, which is sent to the all-hosts multicast address, this query message is
sent to a particular multicast group address, to determine which hosts are subscribed to that particular multicast group.
One important use for this message is after a leave-group message arrives from a host; the querier uses a group-specific
query message as a last member query to determine whether any other hosts on the VLAN are still subscribed to the
group.
• Version 2 Membership Report: this is essentially the same as an IGMPv1 host membership report. However, using a
different message type allows the router (and other hosts) on the network to identify the subscriber host as an IGMPv2
host as opposed to an IGMPv1 host. If an IGMPv2 router sees an IGMPv1 report, this is an indication to the router to
ignore leave-group messages, and thus avoid sending last member query messages (which an IGMPv1 host would not recognize).
IGMP version 3 is defined in IETF RFCs 3376 and 4604. IGMPv3 extends IGMPv2 by adding source-specific multicast, the ability to join a multicast group from a specific stream source. With IGMPv3, the Version 3 Membership Report message may
contain directives to include or exclude one or more groups from one or more sources. Note that an "exclude group from
no sources" report is effectively the same as an IGMPv1 or IGMPv2 "join group" message; and, an "include group from no
sources" report is effectively the same as an IGMPv2 "leave group" message. Therefore IGMPv3 does not define separate
"join" reports and "leave" messages. However, IGMPv3 routers and hosts must support IGMPv2 reports and leaves (and
IGMPv1 reports) for backwards compatibility.
IGMPv3 also adds a Group-And-Source-Specific Query message, which is sent by the router to determine which hosts are
subscribed to a particular multicast group from a particular stream source
508
5.1.5.4 MLD Version 1
The Multicast Listener Discovery (MLD) protocol is the IPv6 equivalent of IGMP.
MLD version 1 is documented in IETF RFC 2710. It is essentially identical in operation to IGMPv2, except that it does not
carry the IGMPv1 backwards-compatibility requirements that IGMPv2 does.
The protocol specification has some terminology changes as compared to IGMP: a leave-group message is called a done message, and a group-specific query message is called a multicast-address-specific query (MASQ) message.
5.1.5.5 MLD Version 2
MLD version 2 is the IPv6 equivalent of IGMPv3, and is documented in IETF RFCs 3810 and 4604. It is essentially identical in
operation to IGMPv3, and it adds source-specific multicast functionality to MLDv1.
The protocol specification has some terminology changes as compared to IGMPv3: a group-and-source-specific query message is called a multicast-address-and-source-specific query (MASSQ) message.
5.2 IGMP and MLD Snooping
IGMP and MLD protocol messages are exchanged between the querier function in the multicast router and a subscriber host.
In many cases, there is a layer-2 (Ethernet) switch between the router and the host. Such a switch cannot, through the normal
unicast process of learning MAC addresses, determine to which specific layer-2 interfaces multicast groups are to be sent.
Thus, in order for multicast groups to traverse the switch from the router to the host, the switch would either have to
broadcast the groups to all the interfaces in the layer-2 subnetwork (VLAN), or it would have to dynamically learn which subscriber hosts were attached to which interfaces.
A switch can, in fact, learn the host-to-interface association by monitoring the IGMP or MLD protocol exchange between the
router and the host. If the switch sees a report message from a host indicating that it wants to subscribe to a multicast group,
the switch can remember the interface on which the report message was seen. This process is known as snooping. If the
switch is monitoring IGMP protocol messages, it is performing IGMP Snooping function; if it is monitoring MLD protocol
messages, it is performing an MLD Snooping function.
Snooping allows the switch to optimize network usage by avoiding broadcasting a multicast group to interfaces on which
there are no subscriber hosts. In some cases it can also help optimize the protocol exchange between the hosts and the
router by eliminating redundant messages; for example, a switch may track when there is more than one host subscribed to
a group, and only send a report or leave message to the router when the first host joins or the last host leaves. Refer to TBS.
5.2.1 Known versus Unknown Multicast
A known multicast group is a group to which a host has subscribed, as determined by the IGMP or MLD snooping process.
When the multicast group arrives at the switch from the multicast router, the switch knows to forward the group to interfaces on which subscriber hosts are connected.
An unknown multicast group is a group where the destination address is recognized as a multicast address, but for which
there are no matching subscriber hosts. The switch may be configured to flood unknown multicast groups to all interfaces in
the VLAN, to drop (block) the groups, or to forward them only to specific interfaces. (See "Known versus Unknown Multicast for information on how to configure unknown multicast group handling.
5.2.2 Multicast Router Ports (Dynamic versus Static)
A multicast router port is an interface on which a multicast router is reachable from the snooping switch. Multicast router
ports can be automatically detected when the snooping process detects an IGMP query or MLD query from a querier connected to the interface. When the snooping process receives a report (or done, or leave) message from a listener host, it will
forward the report to all multicast router ports.
509
When the layer-2 network topology is controlled by a dynamic protocol such as RSTP or EPSR, and the network is configured as an Upstream Forwarding Only (UFO) VLAN, then a multicast router port that had previously been dynamically
detected will automatically be moved to the designated upstream router port for the VLAN in the event of an RSTP or EPSR
network topology change. This helps avoid a temporary loss of service that can occur until a new protocol packet is received
from the multicast router.
Multicast router ports may also be statically configured. This can be useful if the automatic protocol packet detection mechanism cannot properly detect the multicast router (e.g., if no such protocols are configured on the router). It can also help
avoid loss of service during a network topology change, regardless of whether or not the VLAN is a UFO VLAN. For example, in an EPSR ring, both ring interfaces may be manually configured as static multicast router ports.
5.2.3 Interface Snooping Modes
For each interface on which IGMP or MLD snooping is used, the treatment of multicast traffic on the interface may be set to
one of four modes: internal snooping, external snooping, multicast pass-through, or multicast send-all.
Note:
This pass-through mode is not supported on the SBx3100; it is included here because it shares many attributes with
send-all (which is supported on the SBx3100), and because pass-through mode was supported prior to Release 17.0
and must be changed on upgrade. Refer to SET SWITCH MULTICAST INTERFACE SNOOPINGMODE.
5.2.3.1 Internal Snooping
The internal snooping mode is the normal setting for interfaces that are connected to downstream listener hosts.
When an interface is set for internal snooping, the IGMP and MLD snooping processes track each listener host on each
VLAN and interface by monitoring for report messages, indicating that the host is joining a multicast group. A multicast
stream is only forwarded to the interface on a VLAN if one or more listener hosts on the VLAN/interface has joined the
group.
When a "leave" or "done" message for a group is seen on the interface, the snooping processes check to see if the client host
that sent the message had previously joined the group on the VLAN. If so, it removes that host from its known list of listeners for that group, VLAN, and interface. When the list of known hosts is empty for a given group, VLAN, and interface, the
switch ceases forwarding that multicast stream to the VLAN/interface.
5.2.3.2 External Snooping
The external snooping mode is used on interfaces where there is a downstream switch that is also performing IGMP or
MLDv1 snooping. In this case, it is assumed that the downstream switch may be performing duplicate report suppression and
last leave behavior (see Duplicate Report Suppression and Last Leave), or is functioning as an IGMP or MLD proxy device
(performing snooping, and then presenting the appearance of a single host device). This allows the system to optimize processing of "leave" and "done" messages by assuming the downstream switch will only forward that message if there are no
more listener hosts for the group on the downstream switch. By making this assumption, it is not necessary to track listener
hosts and validate the leave messages against a list; the system may simply stop forwarding a multicast group to a VLAN/interface upon receipt of any leave/done message for that group on that VLAN/interface, regardless of which host originated the
message.
For MLDv2, report and leave suppression are disallowed on downstream snooping switches. Therefore, external snooping
should generally not be used with MLDv2 unless there is only a single listener host on the interface, or if the downstream
switch is performing a proxy function and presenting the appearance of a single host on the interface. However, in this case,
the performance advantage of setting the interface to external snooping mode (as compared to internal snooping mode) is
minimal.
5.2.3.3 Mulitcast Passthrough
For an interface in multicast pass-through mode, incoming report and leave messages from the interface are passed to multicast router ports with minimal processing, and no attempt is made to detect or track listener hosts on the interface. Multi-
510
cast groups arriving from any other pass-through interface are always forwarded to all other pass-through interfaces,
regardless of whether there are listener hosts on the interfaces or not. This can be used to help avoid a service impact that
could result from a topology change in the network, and can help improve performance when multiple snooping switches are
daisy chained.
Consider the case when multiple switches are configured in an EPSR ring. Without the ability to designate interfaces as multicast pass-through, two problems could arise. First, if the network topology changes, an interface that was previously considered "upstream" may now be "downstream", requiring the switch to snoop reports on that interface before multicast traffic is
sent to it. In this case, there could be a significant period of time before the newly-downstream switch receives any multicast
traffic, thus resulting in a service interruption to listener hosts on that switch. Second, an upstream switch may need to track
a large number of listener hosts on the downstream interface, resulting in performance degradation on the switch.
By configuring the EPSR ring interfaces as multicast pass-through, both of these issues can be avoided. Multicast traffic is
always forwarded in both directions around the EPSR ring, so topology changes do not cause a significant service interruption
to any nodes in the ring. Also, the switches do not have to track listener hosts on the ring interfaces; they only have to track
listener hosts on downstream customer-facing interfaces, potentially improving the overall performance of each switch.
Similarly, it may be beneficial to configure all network-facing interfaces in a spanning tree as multicast pass-through, as well as
any interface used to interconnect daisy-chained devices.
5.2.3.4 Multicast Send-All
A multicast send-all interface is a special type of multicast pass-through interface. It behaves in much the same manner as a
multicast pass-through interface, but multicast groups are sent to send-all interfaces even if the group did not arrive on a multicast pass-through interface. This can be used in the case where multicast sources may be present on non pass-through
interfaces that should be forwarded to upstream interfaces, but where it is undesirable to send multicast traffic back to those
ports.
Note:
This value is supported on the SBx3100 in Release 17.0.
5.2.4 Snooping Optimizations
5.2.4.1 Fast Leave
Ordinarily when an IGMP or MLD querier receives a "leave", "done", or "report" message indicating that a host machine is no
longer interested in a multicast group, it sends a group-specific query to see whether there are any other hosts still listening
to the group. On the device performing snooping, if no responses to the query are seen on an interface after a period of
time, the interface may be removed from the multicast group. During that period of time, the multicast group may continue
to be forwarded on that interface, even when there are no listeners for that group, causing unnecessary network utilization.
Fast leave is an optimization where the system immediately discontinues forwarding a multicast group to an interface as soon
as a host on the interface leaves a group, without waiting for responses to the group-specific query. This is possible when
there is only one host on an interface, or if the system tracks all the destination hosts for the multicast groups on each interface, so it can be determined when all hosts have left a group.
5.2.4.2 Duplicate Report Suppression and Last Leave
For IGMPv1, IGMPv2, and MLDv1, the protocol permits suppressing multiple reports for the same multicast group on a
VLAN. Hosts may suppress reports if they detect other hosts on the network already listening to the group, or (more commonly) snooping switches can determine whether there are multiple hosts listening to the same group, and collate multiple
reports into a single report to be sent upstream. This can help reduce the processing load on the multicast router and
upstream snooping devices, when many hosts are listening to the same multicast group.
Similarly, IGMPv2 "leave" or MLDv1 "done" messages may be suppressed by a snooping switch if the switch knows that there
are other hosts on the VLAN still listening to the group. This feature is also known as last leave, since the snooping switch
only sends a leave message to the multicast router when the last host leaves the multicast group.
511
These features do not apply to a network that only uses MLDv2 or IGMPv3, as these protocols require that all reports be
sent to the multicast router.
512
IGMP and MLD Support on the SBx3100
5.3 IGMP and MLD Support on the SBx3100
5.3.1 Protocol Versions Supported
The SBx3100 system supports IGMPv1, IGMPv2, MLDv1, and MLDv2 snooping; they do not support IGMPv3. Support for
MLDv2 is limited: MLDv2 protocol packets are recognized but source-specific multicast is not supported
5.3.2 Hardware Support
IGMP Snooping is supported on all cards on all SBx3100 systems
MLD Snooping is supported on a SBx3100-series chassis with a CFC200 central fabric controller and any SBx3100-series
compatible service module (including the GE24RJ, GE24POE, GE24SFP, GE40RJ, GE40CSFP, XE4, and XE6SFP).
5.3.3 Configuration Support
5.3.3.1 VLAN Limits
On the SBx3100, IGMP and MLD snooping may only be enabled on up to 128 VLANs. When the system is upgraded from a
release prior to Release 17.0, the system may temporarily be in a state where more than 128 VLANs are enabled for IGMP
snooping. Certain operations will be disabled while the system in this state See Enabling IGMP and MLD Snooping (perVLAN/Interface).
5.3.3.2 Multicast Group Limits
On SBx3100 systems, IGMP and MLD snooping support up to 2048 multicast groups combined. (There is no per-card limit.)
If the total number of learned multicast groups exceeds this limit, then a management log will be generated; IGMP and
MLDv1 reports will be discarded, while MLDv2 reports will be forwarded to the multicast router but the multicast group will
not be learned by the snooping process.
On the SBx3100, IGMP snooping supports up to eight multicast groups per subscriber host. If a host attempts to join more
than eight multicast groups, the host's report message will be discarded, and the multicast group will not be learned by the
snooping process.
5.3.3.3 Host Tracking Limits
IGMP snooping tracks up to six active IPv4 hosts (listeners) per interface (unless there is a querier on the interface, in which
case the limit is five), and up to eight multicast groups per host. If there are too many hosts on an interface, or if a host
attempts to join too many groups, the Fast Leave feature will not function properly; this may cause some hosts to be disconnected from a multicast group unexpectedly.
MLD snooping supports up to 2400 active IPv6 hosts (listeners) system-wide. If the number of learned IPv6 multicast hosts
exceeds this limit, system performance may be adversely affected due to excessive CPU usage. Symptoms of an overload
condition may include: hosts' attempts to join and leave multicast groups being delayed or not processed at all; responses to
MLD queries from a multicast router being delayed or lost; poor command-line interface responsiveness on the management
interface; and, potential network-wide issues due to tasks for network topology protocols (such as RSTP and EPSR) being
starved.
For networks with more than 2400 hosts, MLD proxies should be used between the SBx3100 and the end hosts. An external
proxy device can reduce the processing load on the SBx3100 by presenting the appearance of a single proxy host in place of
multiple actual hosts. This reduces amount of MLD messaging that must be handled by SBx3100.
513
5.3.3.4 Multicast Router Port Limits
The SBx3100 supports up to a total of 512 static and dynamic multicast router ports, spread across up to 128 VLANs. MLD
and IGMP snooping may only be enabled on up to 128 VLANs (see VLAN Limits), and static multicast router ports should
only be configured on VLANs where IGMP or MLD snooping is enabled.
514
5.4 IGMP and MLD Snooping Configuration Guidelines
5.4.1 Enabling IGMP and MLD Snooping (per-VLAN/Interface)
To enable IGMP snooping, use the "ENABLE IGMPSNOOPING" command. IGMP snooping may be enabled per-VLAN and/
or per-interface. However, for IGMP to function on a particular VLAN and interface, it must be enabled on both the VLAN
and the interface. By default, IGMP snooping is disabled for all VLANs but enabled for each interface (meaning that the overall state is disabled by default).
To enable MLD snooping, use the "ENABLE MLDSNOOPING VLAN" command. MLD snooping may be enabled per-VLAN
(but not per-interface as with IGMP). By default, MLD snooping is disabled for all VLANs.
When IGMP/MLD snooping is disabled on a VLAN, IPv4/IPv6 multicast traffic may be blocked or flooded on the VLAN,
according to the unknown multicast flooding settings on the system and VLAN (see Unknown Multicast Flooding). When
snooping is enabled on a VLAN, known multicast groups will be sent to interfaces that have registered for those groups;
unknown multicast groups will be handled according to unknown multicast flooding settings.
On the SBx3100, only up to 128 VLANs may be administratively enabled for MLD or IGMP snooping (combined). When the
system is upgraded from a release prior to Release 17.0, the system may temporarily be in a state where more than 128
VLANs are administratively enabled for IGMP snooping. Certain operations will be disabled while the system in this state
(see IGMP Snooping Disabled). Additionally, IGMP snooping will only be operational on up to 128 VLANs, since that is the
SBx3100 limit for the number of VLANs on which multicast router ports may be configured or dynamically detected.
When IGMP snooping is disabled on an interface, the interface may still receive flooded multicast traffic, but IGMP protocol
messages (such as "join" reports) on the interface will be ignored (dropped).
5.4.2 Unknown Multicast Flooding
The handling of unknown multicast groups can be controlled globally using the "SET SWITCH MULTICAST FLOODUNKNOWNS" command. When the global "FLOODUNKNOWNS" parameter is set to "ALL", all unknown multicast traffic on
a VLAN is flooded to all interfaces in the VLAN. When it is set to "NONE", unknown multicast traffic is dropped by default
(however, note the exception in the next paragraph). When it is set to "CONTROLONLY", only certain well-known multicast address ranges are flooded on the VLAN; other unknown multicast traffic is dropped by default. The well-known multicast address ranges are:
• all IPv6 addresses in the range FF0n::m:0:0/98 or FF0n::m:FF00:0/104, where n is a value from 0-F and m is a value from 02; or,
• all IPv4 addresses in the range 224.0.0.0/24.
Note that certain interfaces may always receive both known and unknown multicast traffic regardless of the "FLOODUNKNOWNS" setting: these are any interfaces that have been designated as multicast pass-through or multicast send-all interfaces (see Interface Snooping Modes).
The "ADD IGMPSNOOPING FLOODING" command allows packets for particular IPv4 protocols (well-known IPv4 multicast addresses) to be flooded on particular VLANs, when the global "FLOODUNKNOWNS" parameter is set to "NONE". If
"FLOODUNKNOWNS" is set to "ALL" or "CONTROLONLY", all IPv4 protocol packets are flooded anyway, so this command would have no effect. Up to 64 IPv4 protocol addresses may be configured for flooding, on up to 10 VLANs; the total
number of address-VLAN combinations may not exceed 128.
The default setting for "FLOODUNKNOWNS" is "NONE"; and, by default, no addresses are configured for "IGMPSNOOPING FLOODING" on any VLAN.
On the SBx3100, the "SET SWITCH MULTICAST FLOODUNKNOWNS FLOODUNKNOWNS=CONTROLONLY" setting is supported on all central fabric controllers and service modules.
515
5.4.2.1 IPv6 Neighbor Discovery Interaction
When "FLOODUNKNOWNS" is set to "NONE" (the default), the IPv6 solicited node multicast address range
(FF02::1:FF00:0/104) will never be forwarded to any downstream ports, even though an IPv6 host will generally send a report
to join such an address as part of the IPv6 Neighbor Discovery Protocol. Despite the use of the MLD "join" report, solicited
node multicast groups are always treated as "unknown" multicast. Therefore, with "FLOODUNKNOWNS" set to "NONE",
IPv6 neighbor discovery will not function for hosts on downstream interfaces. It is recommended that "FLOODUNKNOWNS" be set to "CONTROLONLY" or "ALL" when IPv6 is in use.
5.4.2.2 Group Ageing Timers
A multicast group detected by the snooping process expires ("ages out") a period of time after a general query message has
been sent by the querier, unless a report is received from the host in response to the query. This time period may be configured for IGMP and MLD snooping using the "SET IGMPSNOOPING with the GENQUERYTIMER option or SET MLDSNOOPING with the GENQUERYTIMER option" command. The value should generally be related to parameters set on the
IGMP or MLD Querier according to this formula:
QUERYINTERVAL > GENQUERYTIMER >= QUERYRESPONSEINTERVAL
The default value for the "GENQUERYTIMER" is 20 seconds.
Under normal circumstances (excluding IGMPv1 hosts), group "done" messages (or "include none" reports) are expected on
an interface when hosts are no longer interested to a multicast group, before the group ageing timer expires. However, in the
event that a host disconnects unexpectedly, this ageing mechanism is used to clean up any groups to which the host was listening.
5.4.2.3 Fast Leave Behavior
Fast leave (see Fast Leave) is always enabled (for IGMP snooping on the iMAP, and for both IGMP and MLD snooping on the
SBx3100).
If the snooping mode of an interface is set to "internal" (see Interface Snooping Modes), the system determines that there are
no subscribers on the interface when "leave" or "done" messages have been received for all hosts that were known to be
members of the group. For IGMP snooping, the number of hosts that can be tracked on each interface is limited to six. (If any
of those hosts are using IGMPv1, however, the system reverts to timing-out the groups after a general query, since IGMPv1
hosts do not send "leave" messages.) For MLD snooping, the number of hosts that are tracked is subject to a system-wide
limit of 2400; there is no per-interface limit. Note that host devices must not perform duplicate report suppression in this
configuration, as that would prevent the switch from tracking the hosts properly. Duplicate report suppression may only be
performed by the SBx3100 switch.
If the snooping mode of an interface is set to "external", then it is assumed that there is only one listener host (or proxy
device) on the interface, so the switch will cease sending a multicast group to an interface upon receipt of any "leave" or
"done" message on the interface, without checking the identity of the host device.
If the snooping mode of an interface is set to "send-all", then multicast streams are always sent to the interface, so the fastleave behavior does not apply.
5.4.2.4 Duplicate Report Suppression and Last Leave
Duplicate report suppression may be configured separately for IGMP and MLD snooping, using the "SET IGMPSNOOPING
with the DUPREPORTTIMER" and "SET MLDSNOOPING with the DUPREPORTTIMER" commands. The value may be set
to "OFF" (indicating that the snooping process will not attempt to suppress duplicate reports) or a value in seconds (indicating that any duplicate reports within the given timeframe will not be sent to the multicast router). The setting does not apply
to MLDv2 reports. The default value is 10 seconds.
The last leave feature is always active for IGMPv1, IGMPv2, and MLDv1 snooping; it does not require configuration.
516
5.4.2.5 Interface Snooping Mode
For each interface on which IGMP or MLD snooping is used, the treatment of multicast traffic on the interface may be set to
one of four modes: internal snooping, external snooping, multicast pass-through, or multicast send-all. See Interface Snooping
Modes for a description of the different snooping modes.
To configure an interface's snooping mode, set the "SNOOPINGMODE" attribute in the "SET SWITCH MULTICAST
INTERFACE SNOOPINGMODE" command to "INTERNAL", "EXTERNAL", "PASSTHROUGH", or "SENDALL". The setting
applies to all VLANs for the interface, and for both IGMP and MLD.
The multicast pass-through mode and the multicast send-all mode are similar. The SBx3100 does not support multicast passthrough interfaces; interfaces should be configured as multicast send-all instead.
5.4.2.6 Multicast Router Ports (Static Router Ports Supported)
On the SBx3100, multicast router ports may also be statically configured using the ADD VLAN INTERFACE or SET VLAN
INTERFACE command with the MCASTSTATICROUTERPORT option. Up to 512 VLAN-interface pairs may be designated as
static multicast router ports, on up to 128 VLANs; for each VLAN-interface pair, the multicast router port designation may
apply to IGMP, MLD, or both. Note that the total number of static and dynamically-detected multicast router ports is limited
to 512, so any statically-configured multicast router ports will reduce the number of multicast router ports that can be
dynamically detected.
For multicast router ports that have been dynamically determined by examining protocol packets (as opposed to being statically configured), the multicast router port designation will expire after a period of time if protocol packets are no longer
observed on an interface for a VLAN. The amount of time before the multicast router port designation expires may be configured for IGMP and MLD separately, using the "SET IGMPSNOOPING or SET MLDSNOOPING with the ROUTERAGEINGTIMER option.
The timer value may be set from 10 to 1200 seconds. The value should be greater than the maximum interval between protocol packets, for whatever protocol is being used to detect the multicast router. For IGMP and MLD protocol packets, this
would be the router's query interval multiplied by the "robustness value". If OSPF is being used for dynamic multicast router
port detection, the router ageing timer should also be greater than the "router dead" interval (typically four times the "hello
interval").
The default value for the router ageing timer is 300 seconds (5 minutes).
On the SBx3100, any multicast groups that with subscribers on a VLAN are forwarded to any multicast router ports on the
VLAN (in addition to being forwarded to the interfaces with the subscribers and to multicast send-all interfaces). If the SET
SWITCH MULTICAST FLOODUNKNOWNS setting is set to "CONTROLONLY", unknown multicast groups are also forwarded to multicast router ports on the VLAN (and multicast send-all interfaces), as long as IGMP or MLD snooping is
enabled on the VLAN.
This behavior is primarily to allow the SBx3100 to operate on networks that use other multicast protocols that are currently
not snooped (e.g., Protocol Independent Multicast [PIM]). Therefore, if the SBx3100 is deployed as a layer-2 switch between
PIM routers, it is recommended to do one of the following:
• SET SWITCH MULTICAST FLOODUNKNOWNS be set with FLOODUNKNOWNS = "ALL";
• SET SWITCH MULTICAST FLOODUNKNOWNS be set with FLOODUNKNOWNS = "CONTROLONLY", and IGMP
or MLD snooping be enabled on the VLAN(s) on which PIM is operating, even if there are no IGMP or MLD clients on
the VLAN;
• Have all interfaces connecting the iMAP to the PIM routers be designated as multicast send-all interfaces (SET SWITCH
MULTICAST INTERFACE SNOOPINGMODE).
This behavior is not supported on the iMAP. If the iMAP is deployed as a layer-2 switch between PIM routers, it is recommended to either:
• SET SWITCH MULTICAST FLOODUNKNOWNS be set with FLOODUNKNOWNS = "ALL";
517
Feature Interactions
• All interfaces connecting the iMAP to the PIM routers be designated as multicast pass-through interfaces.
5.4.2.7 Set-Top Box Mobility Prevention
For IGMP snooping, MAC addresses may be statically configured against particular interfaces. When this is done, the IGMP
snooping process will only accept IGMP reports from hosts matching the statically configured addresses. This can "lock
down" the interface so that only approved devices may receive multicast streams on the interface. For example, when IGMP
is used for video service, this feature helps prevent set-top-box mobility (i.e., taking an existing set-top-box and using it to
receive service at an unauthorized location) and theft of service (i.e., connecting an unauthorized device to the network to
receive video streams).
Up to six full MAC addresses (e.g. "11:22:33:AA:BB:CC") or partial MAC addresses (e.g. "11:22:33") may be configured
against each interface. If a partial MAC address is configured, the subscriber host must have a MAC address starting with the
specified octets.
If static MAC addresses are configured against an interface while existing hosts on the interface are actively subscribed to
multicast groups, those hosts will not be removed from the groups immediately; however, if their MAC addresses do not
match one of the statically configured entries, new IGMP reports from them will not be processed, and they will eventually
expire from the group.
5.4.2.8 IGMP Snooping Per-Card Multicast Group Limits
On the SBx3100, the concept of a Multicast Group Limit per Card does not apply, and so there is no MCASTGROUPLIMIT
option. Refer to the iMAP Software Reference Manual for how this works on iMAP systems.
5.4.2.9 IGMP Snooping IMG Compatibility Mode
On SBx3100 systems, the global "IMGCOMPATIBILITYMODE" setting for IGMP snooping specifies whether IGMP protocol
packets should be exempt from filtering by user-defined access-lists and classifiers; this is required for operation with certain
Allied Telesis iMG devices that have an IGMP proxy function enabled. (There is no corresponding setting for MLD snooping;
MLD protocol packets are exempt from filtering on a VLAN as long as MLD snooping is enabled for the VLAN.) Refer to the
SET IGMPSNOOPING command.
5.5 Feature Interactions
5.5.1 Upstream Forwarding Only VLANs
On SBx3100 systems, if a VLAN is configured as UFO, and if a topology management protocol is in use on the VLAN, then a
topology change in the network will cause the newly designated upstream interface for the VLAN to be added as an additional dynamic multicast router port, so long as system-wide limits on the number of multicast router ports have not been
exceeded (see Multicast Router Port Limits).
5.5.2 IPv6 Neighbor Discovery
The IPv6 Neighbor Discovery Protocol uses MLD in its operation. Upon joining a network, an IPv6 host sends an MLD
report to join its solicited node multicast address so that it can receive neighbor discovery packets from other hosts on the
network. (The address is in the IPv6 link-local multicast address range FF02:0:0:0:0:1:FF00::/104). MLD snooping will not
intercept or process these specific MLD reports, but instead will simply forward them to multicast router ports.
If a data packet is received with a destination in the solicited node multicast address range, the system will flood them to all
interfaces if the "SWITCH MULTICAST FLOODUNKNOWNS" parameter is set to "CONTROLONLY" or "ALL". If the
parameter is set to "NONE", the packet will only be sent to multicast pass-through or send-all interfaces and therefore, IPv6
neighbor discovery will not operate correctly for downstream hosts.
518
5.5.3 Link Aggregation
IGMP and MLD snooping may be used with link aggregation groups (LAGs), without restrictions.
5.5.4 Hierarchical VLANs
Hierarchical VLANs (also called HVLANs, double-tagged VLANs, VLAN tunnels, or Q-in-Q VLANs) may not be used in conjunction with IGMP or MLD snooping. For a tunneled VLAN, customer VLAN (C-VLAN) traffic is designed to be passed
transparently through the tunnel in the HVLAN. This conflicts with the need to intercept and re-inject protocol packets by
the IGMP and MLD snooping processes.
IGMP snooping allows the SBx3112 to conserve the local area network bandwidth by not flooding (broadcasting) the multicast frames but rather forwarding the multicast frames only to those ports that have expressed an interest in receiving such
frames. The product must examine (or snoop) some layer 3 information (join and leave) in the IGMP host membership
report message and the IGMP host leave group messages sent by the host to a multicast router. The snooping of these messages is used to learn (or forget) which ports are interested (or not interested) in receiving multicast packets.
In simple terms, upon the receipt of an IGMP host membership report message for a particular multicast group, the IGMP
learning process adds the port to the MAC address table against the multicast MAC address if it is not already present. Upon
the receipt of an IGMP host leave group message for a multicast group, the IGMP learning process deletes the port from the
MAC address table if it is present.
The forwarding process then utilizes the MAC address table populated by the learning process above to do efficient forwarding of the received multicast frame.
5.5.5 IGMP Snooping Disabled
When IGMP snooping is disabled, the treatment of multicast frames by the SBx3112 is the same as any other layer 2 switch.
• Each time a frame is received, the learning process reads the source MAC address and updates the address tables if
required. The forward process then uses these address tables to do an address lookup on the destination MAC address
to determine where to forward the frame.
• Initially, the SBx3112 starts out by broadcasting/flooding (default forwarding) the received unicast frames on all its ports
other than the port it was received on. This continues until the learning process learns and populates the MAC address
table (consisting of MAC address - port entries) after which the received unicast frames are forwarded only to the
intended destination. The exact port of the intended destination is obtained by using the destination MAC address in the
received frame as a key to locate the address - port entry (inserted by the learning process earlier on) in the MAC
address table. This is called the address lookup phase as part of the forwarding process to exactly forward the unicast
frames. Note that there is one entry per unicast MAC address in the MAC address table since the unicast addresses are
unique.
• For any broadcast frames (with a destination MAC address of all 1's), the frame is forwarded on all the LAN switch ports
(flooding) by the forwarding process obviously not including the port the broadcast frame was received on.
• For any multicast frames the lookup fails to determine the ports to send this frame on, and so floods them to all ports in
the VLAN. There is no Source Address with the Multicast Address since it has not been learned.
Note:
Creating a VLAN of type VLAN is actually the same, except the frame may be flooded on only member ports of the
VLAN.
5.5.6 IGMP Snooping Enabled
As mentioned above, IGMP snooping allows the SBx3112 to conserve local area network bandwidth by not broadcasting a
received multicast frame but rather forwarding the multicast frame only to those ports that have expressed an interest in
receiving such frames. (The default forwarding behavior of a LAN switch for unicast and broadcast frames is not affected.)
The snooping will configure the hardware to allow multicast streams for that group to be forwarded only to ports that have
requested that stream.
519
The SBx3112 keeps track of Multicast Group membership by MAC address, so Leaves are processed immediately and the
interface is removed from the Multicast Group (no timers). This is called IGMP Fast Leave.
The parameter DUPREPORTTIMER (of the SET IGMPSNOOPING command) helps control the number of duplicate reports
sent to the multicast router(s). Also, the SBx3112 only sends up the last Leave to the router.
Once IGMP has been enabled, the system may generate a warning message at the user’s CLI session stating that classifier
capacity or capabilities have been exceeded on the slot(s) impacted by the provisioning change. The user should investigate
classifier-related provisioning, such as IGMP, DHCPRELAY, VLAN (for per-VLAN UFO and HVLAN), EPSR, INTERFACE
(TAGALL option for HVLAN), ACCESSLIST, and CLASSIFIER to determine the reason for the message.
5.5.7 IGMP Snooping at the System and Interface Level
Since the IGMP Snooping feature can be enabled and disabled at both the system and port level, the following interactions
apply:
• If IGMP Snooping is disabled system wide, all multicast packets will be flooded (within the VLAN) including IGMP control
packets (Reports, General Queries, Groups Specific Queries). In this case, no IGMP control messages are forwarded to
the CPU for processing; they are just switched (flooded).
• If IGMP Snooping is enabled system wide and the port level control is enabled, then the port is snooped; IGMP Snooping
software in the CFC will receive Reports and Leaves and process them as follows:
• Unrequested (no Report processed by IGMP Snooping) multicast packets are dropped at the CFC switch.
• Requested multicast packets are only sent to the ports where an IGMP Report is received.
• If IGMP Snooping is enabled system wide and the port level control is disabled, then any IGMP Control Packet (Reports
and Leaves) that are received from that port will be discarded (not processed and not flooded). This port will not be able
to participate in IGMP.
5.5.8 Summary of Feature Interaction
The following figure shows the flow of the IGMP and MLD features and how multicast groups are processed for the
SBX3100.
520
Note 1 = Controlled by SET SWITCH MULTICAST INTERFACE SNOOPINGMODE
Note 2 = Controlled by SET VLAN=X INTERFACE=Y MCASTSTATICROUTERPORT=YES
or Dynamically Learned
Note 3 = Packet matches item controlledby ADD IGMPSNOOPING FLOODING
Note 4 = Controlled by SET SWITCH MULTICAST FLOODUNKNOWNS
Note 5 = Controlled by ENABLE IGMPSNOOPING or ENABLE MLDSNOOPING
MULTICAST DATA
IS DESTINATION
MULTICAST
SENDALL
?
FORWARD TO
INTERFACE
YES
Note 1
NO
YES
IS GROUP
LEARNED BY
SNOOPING
YES
IS LISTENER
LEARNED ON
DESTINATION
YES
?
NO
?
NO
IS DESTINATION
MC ROUTER
PORT
Note 2
?
NO
YES
NO
IS SNOOPING
ENABLED ON VLAN?
IS IGMPSNOOPING
FLOODING PACKET
?
?
Note 3
Note 5
NO
NO
IS DESTINATION
YES
MC ROUTER
PORT
Note 2
?
NO
YES
FLOOD TO ALL
INTERFACES IN VLAN
YES
IPv4 / IPv6
CONTROL PACKET
ALL
CONTROL
ONLY
MULTICAST
FLOODUNKNOWNS
?
DROP
?
Note 4
OFF
FIGURE 5-1
Processing of Multicast Data for iMAP
521
Configuring IGMP
5.6 Channel Usage for IGMP
5.6.1 Reserved
For the SBx3100, there is a subset of the reserved multicast address range of 224.0.0.x (x = 0..255):
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
01:00:5e:00:00:01 (All-Hosts Group).)
01:00:5e:00:00:02 (All Routers Group)
01:00:5e:00:00:04 (DVMRP)
01:00:5e:00:00:05 (OSPFALL)
01:00:5e:00:00:06 (OSPFDESIGNATED)
01:00:5e:00:00:09 (RIP2)
01:00:5e:00:00:0a (IGRP)
01:00:5e:00:00:0c (DHCPRELAY)
01:00:5e:00:00:0d (PIM)
01:00:5e:00:00:0e (RSVP)
01:00:5e:00:00:0f (CBT)
01:00:5e:00:00:12 (VRRP)
01:00:5e:00:00:23 (DXCLUSTER)
01:00:5e:00:00:65 (CISCONHAP)
01:00:5e:00:00:66 (HSRP)
01:00:5e:00:00:fb (MDNS)
Note:
These reserved multicast entries do not take away from the 512 multicast groups supported by the system.
5.6.2 User provisioned MCAST addresses
The SBx3112 system user can provision specific MCAST addresses that are considered important and are not auto-populated. This allows the user to pass other application-specific protocols that are outside the reserved multicast addresses that
the SBx3112 system IGMP policy would otherwise block. With IGMP snooping enabled and the port set to INTERNAL,
reserved MCAST addresses (224.0.0.1->224.0.0.255) will be dropped unless joined. For this reason, the system provides the
user the ability to use CLI commands to statically configure MCAST addresses that are considered important but are not
auto-populated. Furthermore, this provides the ability to pass other application specific protocols that are outside the
reserved multicast addresses which the SBx3112 system IGMP policy would otherwise block.
The default behavior is that with IGMPSNOOPING disabled, the system will flood all MCAST. However, with IGMPSNOOPING enabled, the system will automatically enter 224.0.0.1 and 224.0.0.2 as entries. The user then has the option, using CLI
commands, to add and delete these protocol forwarding addresses.
Protocol forwarding addresses can be displayed using the SHOW IGMPSNOOPING FLOODING command.
5.7 Configuring IGMP
As described in, when an SBx3112 switch is initially booted up, IGMP and MLD are configured as follows:
• IGMP snooping is disabled for all VLANs but enabled for each interface (meaning that the overall state is disabled by
default).
522
Configuring IGMP
• MLD snooping is disabled for all VLANs.
• Flooding of unknowns default setting for IGMP and MLD snooping is disabled (set to NONE)
5.7.2 Configuration Example - IGMP
The following figure shows a simple configuration in which multiple SBx3112s are used. Systems B and C have a switch that is
configured with host with a number of Set Top Boxes (STB).
SBx908
SBx3112 A
1
2.2
2.1
301
2
2.3
SBx3100
3
SBx3112 B
SBx3112 C
1.0
= Devices
1
6
= Links
2.2
301
0.3
6.0
5
SBx3100
2.3
C
4
0.2
301
A
2.1
0.2
SBx3100
3.3
6
Host
Host
STB STB
STB STB
FIGURE 5-2
Example Configuration for IGMP
In Figure 5-2, there are interfaces that are configured to support MC traffic. The options used depend on the place of the
interface in the network and how MC traffic is to be handled. The two options that work together are:
• DIRECTION • NETWORK - The SBx3112 interface is to another system and so traffic must be further processed before going to a
customer/subscriber.
• CUSTOMER - The interface is to a device that handles the incoming subscriber traffic.
• SNOOPINGMODE - How IMGP packets will be handled:
• MCPASSTHROUGH - IGMP Snooping will filter IGMP packets and will flood all mulitcast traffic that is received from the
mulitcast router to network interfaces that are set to MCPASSTHROUGH and are a member of the VLAN.
• INTERNAL (snooping) - The interface will reconfigure the hardware to limit forwarding of mulitcast packets only to the
ports that have expressed interest in the multicast group.
523
Configuring IGMP
• EXTERNAL (limited snooping) - Behind the interface towards the customer is a device that has a snooping function. The
SBx3112 interface will only snoop for the first IGMP Report and the last IGMP Leave message, when it knows that there
is no more interest for the specific multicast stream on the downstream device.
For Figure 5-2, the interfaces could be configured as follows:
• SBX3112-B and SBx3112 - C - The link (4) is part of a ring and connects the two SBx3112s. Interfaces 0.2 and 2.1 are
configured as:
• DIRECTION = NETWORK
• SNOOPINGMODE = MCPASSTHROUGH
• SBX3112-B - The link (5) is to a device that provides IGMP, and so interface 0.3 is configured as:
• DIRECTION = CUSTOMER
• SNOOPINGMODE = EXTERNAL
• SBX3112-C - The link (6) is to a device that does not provide IGMP, and so interface 6.0 is configured as:
• DIRECTION = CUSTOMER
• SNOOPINGMODE = INTERNAL
Refer to the SET IGMPSNOOPING command.
5.7.4 Restrictions and Limitations
The number of IGMP groups can be set from 1 up to 512, depending on bandwidth requirements (usually for the number of
video channels). Note that on the SBX3112, there is no feature (MCASTGRUPLIMIT) that when the number of IGMP groups
reaches 80% of the configured number, a management log is produced, and at 100% an alarm is produced.
MAC limiting restricts the ability to learn MAC addresses on a port. When the MAC learning limit is reached, all frames from
MAC sources that are not already in the FDB are dropped. This could be part of a subscriber’s Service Level Agreement.
Figure 5-3 demonstrates an IGMP multicast group that is formed -- using a video VLAN -- and set up with two customer
hosts. The network includes an SBx3112 connected to a customer STB (on link 2), to another customer STB (on link 3) via
an iMG616 gateway (serving as an IGMP proxy modem), and to the network via a multicast router (on link 1).
524
Configuring IGMP
1
SBx3112 A
0.22
SBx3100
11.10
11.11
512
3
2
B
C
iMG616
A
C
= Devices
1
4
= Links
Set top box
512
= vlan_video
4
Set top box
FIGURE 5-3
Video Multicasting Using IGMP Snooping
The following procedure shows the commands used to create the IGMP video multicasting configuration shown in Figure 53.
TABLE 5-1
Step
Configuration Procedure for IGMP Snooping
Command
Description/Notes
Create the video VLAN
1
create vlan video vid 512
Creates a VLAN named “video” with an ID of
512.
Create the network interface for IGMP
2
Sets GE interface 0.22 to the Network direction.
Configure the network interface for MC Passthrough snooping
3
set igmpsnooping interface 0.22 snoopingmode mcpassthrough
Sets the network interface to
MCPASSTHROUGH snooping mode.
Add video VLAN to the network interface
4
add vlan 512 interface 0.22 frame tagged
Associates the network interface with VLAN
512
View IGMP snooping status/data for the network interface. If all is working correctly, the multicast router should be visible.
525
TABLE 5-1
Step
Command
5
show igmpsnooping
Configuring IGMP
Description/Notes
--- System-wide IGMP Snooping Status --Snooping Status.................................................
Duplicate Report Delay..........................................
General Query Timeout...........................................
Router Ageing Timeout...........................................
Reserved Subscribed Groups......................................
ENABLED
10 sec
20 sec
300 sec
0
Provisioning
Flood Unknown Multicast...................................... OFF
Actual
Flood Unknown Multicast...................................... DROPPED
--- System-wide IGMP VID Counts --Number of Groups Receiving
VID
Local
Pass Through
MC Stream
MC Stream
----- ------------------ ---------------512
2
2
--- System-wide IGMP Learned Router --Query
Aging
Source
VID Timeout
Timeout
Interface
MacAddress
---- -------- --------- -------------- ----------------512 11 sec
291 sec
ETH:0.22
00:0C:31:D4:60:00
Add the video VLAN to the customer interface on link 2
6
add vlan 512 interface 11.10 frame
untagged
Associates customer interface 11.10 with
VLAN 512 and configures it for untagged framing
Configure the customer interface (on link 2) for Internal snooping
7
set igmpsnooping interface 11.10 snoopingmode internal
Sets customer interface 11.10 to INTERNAL
snooping mode.
Add the video VLAN to the customer interface (link 3) to the IGMP proxy modem
8
add vlan 512 interface 11.11 frame
tagged
Associates customer interface 11.11 with
VLAN 512
Configure the customer interface (on link 3) for External snooping
9
set igmpsnooping interface 11.11 snoopingmode external
Sets the customer interface 11.11to EXTERNAL snooping mode.
View IGMP snooping status/data for the system and for the customer interfaces
526
TABLE 5-1
Step
Command
10
show igmpsnooping
Configuring IGMP
Description/Notes
--- System-wide IGMP Snooping Status --Snooping Status.................................................
Duplicate Report Delay..........................................
General Query Timeout...........................................
Router Ageing Timeout...........................................
Reserved Subscribed Groups......................................
ENABLED
10 sec
20 sec
300 sec
0
Provisioning
Flood Unknown Multicast...................................... OFF
Actual
Flood Unknown Multicast...................................... DROPPED
--- System-wide IGMP VID Counts --Number of Groups Receiving
Local
Pass Through
MC Stream
MC Stream
----- ------------------ ---------------512
4
4
VID
--- System-wide IGMP Learned Router --Query
Aging
Source
VID Timeout
Timeout
Interface
MacAddress
---- -------- --------- -------------- ----------------512 7 sec
287 sec ETH:0.22
00:0C:31:D4:60:00
11
show igmpsnooping card 11
Processing....
--- Card IGMP Snooping Status/Multicast (MC) Groups --Card: 11
MC Group Limit: 512
Local
Pass Through
VID
MC MAC Address
MC IP Address
MC Stream
MC Stream
---- ----------------- --------------- --------------------------------512 01:00:5E:01:01:07 225.1.1.7
ETH:11.10
ETH:11.0
01:00:5E:01:01:0B 225.1.1.11
ETH:[11.10-11]
ETH:11.0
01:00:5E:0A:0A:0A 225.10.10.10
ETH:[11.10-11]
ETH:11.0
01:00:5E:61:05:02 225.225.5.2
ETH:11.11
ETH:11.0
01:00:5E:61:05:03 225.225.5.3
ETH:[11.10-11]
ETH:11.0
5.7.6 Configuration Example - MLD
TBS
527
Configuring IGMP
5.7.7 IGMP Commands
The following tables list the commands available to configure and manage IGMP on the SBx3112 switch.
TABLE 5-2
IGMP Commands
Commands
ADD IGMPSNOOPING FLOODING
ADD IGMPSNOOPING INTERFACE MACADDRESS
ADD TRACE IGMPSNOOPING MESSAGETYPE
ADD TRACE MLDSNOOPING MESSAGETYPE
DELETE IGMPSNOOPING INTERFACE MACADDRESS
DELETE IGMPSNOOPING FLOODING
DELETE TRACE IGMPSNOOPING
DELETE TRACE MLDSNOOPING
DISABLE IGMPSNOOPING
DISABLE MLDSNOOPING VLAN
ENABLE IGMPSNOOPING
ENABLE MLDSNOOPING VLAN
RESET IGMPSNOOPING COUNTER
SET IGMPSNOOPING
SET MLDSNOOPING
SET SWITCH MULTICAST FLOODUNKNOWNS
SET SWITCH MULTICAST INTERFACE SNOOPINGMODE
SETDEFAULTS MLDSNOOPING
SETDEFAULTS SWITCH MULTICAST
SETDEFAULTS SWITCH MULTICAST INTERFACE
SHOW IGMPSNOOPING
SHOW IGMPSNOOPING COUNTER
SHOW IGMPSNOOPING FLOODING
SHOW MLDSNOOPING
SHOW SWITCH MULTICAST
SHOW TRACE IGMPSNOOPING
SHOW TRACE MLDSNOOPING
528
Configuring IGMP
Syntax
{ ALLSTANDARD | DVMRP | OSPFALL | OSPFDESIGNATED | RIP2 | IGRP | DHCPRELAY |
PIM | RSVP | CBT | VRRP | DXCLUSTER | CISCONHAP | HSRP | MDNS | CUSTOM=groupname GROUPADDRESS=ipaddress }
{ VLAN={ vlanname-list | vid-range
}
| VID=vid-list }
Description
This command enables flooding of particular types of IPv4 multicast traffic on particular VLANs that
already exist. By default, if the global "SWITCH MULTICAST FLOODING" setting is "NONE", IPv4
multicast control traffic is only sent to multicast pass-through or send-all interfaces. This command
overrides the global setting on the specified VLANs. (If the global "SWITCH MULTICAST FLOODING" setting is "CONTROLONLY" or "ALL", this command has no effect on system behavior, as all
IPv4 multicast control traffic will be flooded to all VLANs.)
The IPv4 multicast addresses to be flooded may be selected using one of the predefined names, or by
creating a custom name and specifying the multicast group address. Custom addresses must be within
the range 224.0.0.0/24.
Up to 64 addresses may be configured for flooding on up to 10 VLANs; the total number of addressVLAN combinations may not exceed 128. Note that "ALLSTANDARD" counts as 14 addresses.
Mode
Manager
Options
Option
Description
Range
Default
Value
FLOODING
Specify the IPv4 multicast address to flood. Select from
one of the 14 predefined addresses; or, select ALLSTANDARD to flood all of the 14 predefined addresses;
or, select CUSTOM to select a different address. If CUSTOM is specified, assign the address a name and specify
the GROUPADDRESS in standard IPv4 dotted notation
(e.g., “224.0.0.20”).
ALL
NA
VLAN
Specify the VLANs for which the IPv4 multicast
addresses are to be flooded. The VLANs may be specified as a comma-separated list of names, a list or range
of VIDs, or a combination of the two.
NA
NA
Release Note
Modified - In releases prior to Release 17.0, the VLAN parameter was named "VID”.
Note
For the SBx3100, IGMP and MLD snooping may only be enabled on up to 128 VLANs (combined).
Example
ADD IGMPSNOOPING FLOODING=ALLSTANDARD VID=401,402
529
Configuring IGMP
ADD IGMPSNOOPING INTERFACE MACADDRESS
Syntax
ADD IGMPSNOOPING INTERFACE={ type:id-range | id-range | ifname-list | ALL }
MACADDRESS={ macaddress-list | partial-macaddress-list }
Description
This command adds one or more static MAC addresses to a list of permitted host devices on a particular interface, for IGMP snooping. When one or more MAC addresses are statically configured on an
interface, IGMP snooping will only process membership reports originating from the devices matching
those addresses. This is primarily to prevent theft of service by disallowing unauthorized devices from
subscribing to multicast streams.
The MAC address may be specified as a full six-octet address (e.g., "11:22:33:AA:BB:CC"), or as a partial address of five or fewer octets (e.g., "11:22:33"). If a partial address is entered, then IGMP reports
will be accepted from hosts with MAC addresses starting with the given octets.
If this command is entered while existing hosts on the interface are actively subscribed to multicast
groups, those hosts will not be removed from the groups immediately; however, if their MAC
addresses do not match one of the statically configured entries, new IGMP reports from them will not
be processed, and they will eventually expire from the group.
Up to six MAC addresses or partial MAC addresses may be configured for each interface
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
Specify the interfaces for which the given MAC
addresses are to be statically assigned for IGMP snooping. Typically a specific MAC address will be assigned to a
single interface, but it is possible to configure addresses
on multiple interfaces by specifying a list, a range, or a
combination of the two. Specify “ALL” to add the MAC
address to all interfaces (this is not common).
NA
NA
MAC Address
Enter one or more MAC addresses or partial MAC
addresses, in a comma-separated list. Each MAC address
or partial MAC address should be entered as a series of
hexadecimal octets separated by colons
NA
NA
Release Note
NA
Note
The specified interfaces must already exist. No more than six full or partial MAC addresses may be
configured for each interface.
Example
ADD IGMPSNOOPING INTERFACE=ETH:3.1 MACADDRESS=11:22:33:AA:BB:CC
530
Configuring IGMP
ADD TRACE IGMPSNOOPING MESSAGETYPE
Syntax
ADD TRACE IGMPSNOOPING
MESSAGETYPE={ V1REPORT | V2REPORT | LEAVE | GENERALQUERY | LASTMEMBERQUERY |
ALL }
[ VLAN={ vlanname | vid | ALL } ]
[ MACADDRESS={ macaddress | ALL } ]
[ GROUPADDRESS={ ipaddress | ALL } ]
Description
This command adds IGMP message types to the event tracing subsystem. When IGMP message types
are added and event tracing is globally enabled (using the "ENABLE TRACE" command), the system
will capture IGMP protocol packets that are processed by the IGMP snooping software. This can be
used to help debug network or protocol problems relating to IGMP snooping.
•
When the "REPORTV1" message type is added, the system will capture IGMPv1 report messages
from a listener host.
•
When the "REPORTV2" message type is added, the system will capture IGMPv2 report messages
•
When the "LEAVE" message type is added, the system will capture IGMPv2 "leave" messages
•
When the "GENERALQUERY" message type is added, the system will capture IGMP general
query messages from an IGMP querier.
•
When the "LASTMEMBERQUERY" message type is added, the system will capture last-member
query (i.e., IGMPv2 group-specific query) messages from an IGMP querier.
If the "INTERFACE", MACADDRESS", and/or "GROUPADDRESS" parameters are used, tracing will be
limited to specific physical or aggregate interfaces, source MAC addresses, and/or IPv4 multicast group
addresses, respectively. Multiple invocations of the command may be used to generate multiple inclusive filters.
It is recommended that the trace buffer size be increased (using the "SET TRACE BUFFERSIZE" command) when capturing IGMP snooping events.
The parameters, when specified together in a single command, are taken to be AND'ed together. Multiple invocations of this command are OR'ed. If parameters are not specified, ALL is assumed.
Mode
Manager
Options
Option
Description
Range
Default
Value
MESSAGETYPE
Specify the type of IGMP messages to capture in the
event trace system. Specify ALL to capture all types of
messages
NA
ALL
VLAN
SpeSpecify the VLAN for which the IGMP messages are
to be traced. The VLAN may be specified by name or
VID. Specify ALL if tracing is not to be filtered by VLAN
NA
ALL
INTERFACE
Specify a filter list of physical or aggregate interfaces for
which the IGMP messages are to be traced. Specify ALL
if tracing is not to be filtered by interface.
NA
ALL
531
Configuring IGMP
Option
Description
Range
Default
Value
MACADDRESS
Specify one or more MAC addresses for which IGMP
messages are to be traced. (This is the MAC address of
the source of the multicast packet.) Specify ALL if tracing is not to be filtered by MAC address.
NA
ALL
GROUPADDRESS
Specify an IPv4 multicast group address for which IGMP
messages are to be traced. Specify ALL if tracing is not
to be filtered by group address.
NA
ALL
Release Note
Modified - In Release 17.0 the VLAN parameter is added.
Note
Traces will only be captured if event tracing is globally enabled using the "ENABLE TRACE" command.
No traces will be captured for a VLAN if IGMP snooping is not enabled for the VLAN.
Example
ADD TRACE IGMPSNOOPING MESSAGETYPE=REPORTV2
ADD TRACE IGMPSNOOPING MESSAGETYPE=GENERALQUERY
INTERFACE=ETH:1.* MACADDRESS=A4:BA:DB:E7:B3:34
ADD TRACE IGMPSNOOPING MESSAGETYPE=REPORTV1 GROUPADDRESS=224.1.10.10
532
Configuring IGMP
ADD TRACE MLDSNOOPING MESSAGETYPE
Syntax
ADD TRACE MLDSNOOPING MESSAGETYPE={ GENERALQUERY | LASTLISTENERQUERY |
V2REPORT | V1REPORT | V1DONE | ALL }
[ IPSOURCE={ ipv6address | ALL } ]
[ GROUPADDRESS={ ipv6address
| ALL } ]
Description
This command adds MLD message types to the event tracing subsystem. When MLD message types
are added and event tracing is globally enabled (using the "ENABLE TRACE" command), the system
will capture MLD protocol packets that are processed by the MLD snooping software. This can be
used to help debug network or protocol problems relating to MLD snooping.
•
When the "GENERALQUERY" message type is added, the system will capture MLD general
query messages from an MLD querier.
•
When the "LASTLISTENERQUERY" message type is added, the system will capture last-listener
query messages from an MLD querier. This includes group-specific queries (Multicast Address
Specific Queries [MASQ]) and source-specific queries (Multicast Address Source Specific Queries
[MASSQ]).
•
When the "V2REPORT" message type is added, the system will capture MLDv2 report messages
•
When the "V1REPORT" message type is added, the system will capture MLDv1 report messages
•
When the "V1DONE" message type is added, the system will capture MLDv1 "done" messages
If the "VLAN", "INTERFACE", IPSOURCE", and/or "GROUPADDRESS" parameters are used, tracing
will be limited to specific VLANs, physical or aggregate interfaces, source IPv6 addresses, and/or IPv6
multicast group addresses, respectively. Multiple invocations of the command may be used to generate
multiple inclusive filters.
This command is only available on the SBx3100. It is recommended that the trace buffer size be
increased (using the "SET TRACE BUFFERSIZE" command) when capturing MLD snooping events.
The parameters, when specified together in a single command, are taken to be AND'ed together. Multiple invocations of this command are OR'ed. If parameters are not specified, ALL is assumed.
Mode
Manager
Options
Option
Description
Range
Default
Value
MESSAGETYPE
Specify the type of MLD messages to capture in the
event trace system. Specify ALL to capture all types of
messages
NA
ALL
VLAN
Specify the VLAN for which the MLD messages are to
be traced. The VLAN may be specified by name or VID.
Specify ALL if tracing is not to be filtered by VLAN
NA
ALL
INTERFACE
Specify a filter list of physical or aggregate interfaces for
which the MLD messages are to be traced. Specify ALL
if tracing is not to be filtered by interface.
NA
ALL
533
Note
Configuring IGMP
Option
Description
Range
Default
Value
GROUPADDRESS
Specify an IPv6 multicast group address for which MLD
messages are to be traced. Specify ALL if tracing is not
to be filtered by group address.
NA
ALL
Traces will only be captured if event tracing is globally enabled using the "ENABLE TRACE" command.
No traces will be captured for a VLAN if MLD snooping is not enabled for the VLAN.
Example
ADD TRACE MLDSNOOPING MESSAGETYPE=V2REPORT
ADD TRACE MLDSNOOPING MESSAGETYPE=GENERALQUERY
VLAN=100-199 INTERFACE=ETH:1.* IPSOURCE=fe80::202:ffff:f100:0102
ADD TRACE MLDSNOOPING MESSAGETYPE=V1REPORT GROUPADDRESS=FF1E::101:101
534
Configuring IGMP
DELETE IGMPSNOOPING INTERFACE MACADDRESS
Syntax
DELETE IGMPSNOOPING INTERFACE={ type:id-range | id-range | ifname-list | ALL}
MACADDRESS={ macaddress-list | partial-macaddress-list | ALL }
[ FORCE ]
Description
This command deletes one or more static MAC addresses from the list of "known" host devices on a
particular interface, for IGMP snooping. If no more static MAC addresses are configured for an interface, the system will no longer limit IGMP reports to particular host MAC addresses.
The MAC address may be specified as a full six-octet address (e.g., "11:22:33:AA:BB:CC"), or as a partial address of five or fewer octets (e.g., "11:22:33"). The specification must match the one used in the
"ADD IGMPSNOOPING INTERFACE MACADDRESS" command
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
Specify the interfaces for which the given MAC
addresses are to be no longer statically assigned for
IGMP snooping. Multiple interfaces may be selected by
specifying a list, a range, or a combination thereof.
Specify “ALL” to remove the specified MAC address
from all interfaces on which they have been configured
NA
NA
MAC Address
Enter one or more MAC addresses or partial MAC
addresses, in a comma-separated list. Each MAC address
or partial MAC address should be entered as a series of
hexadecimal octets separated by colons.
NA
NA
Release Note
NA
Example
DELETE IGMPSNOOPING INTERFACE=1.23 MACADDRESS= 00:0C:25:00:13:8C
535
Configuring IGMP
Syntax
{ ALL | ALLSTANDARD | DVMRP | OSPFALL | OSPFDESIGNATED | RIP2 | IGRP |
DHCPRELAY | PIM | RSVP | CBT | VRRP | DXCLUSTER | CISCONHAP | HSRP | MDNS |
CUSTOM=groupname }
[ { VLAN={ vlanname-list | vid-range | ALL } | VID={ vid-list | ALL } } ]
[ FORCE ]
Description
This command disables flooding of particular types of IPv4 multicast traffic on particular VLANs. If the
specified type of traffic had previously been enabled for flooding, and the global "SWITCH MULTICAST FLOODING" setting is "NONE", then this command will cause flooding to cease for that particular type of traffic. (If the global "SWITCH MULTICAST FLOODING" setting is "CONTROLONLY"
or "ALL", this command has no effect on system behavior, as all IPv4 multicast control traffic will be
flooded to all VLANs.)
Mode
Manager
Options
Option
Description
Range
Default
Value
FLOODING
Specify the IPv4 multicast address for which flooding is
to cease. Select from one of the 14 predefined
addresses; or, select “ALLSTANDARD” to cease flooding for the 14 predefined addresses; or, select “CUSTOM” to cease flooding for a custom-defined group; or,
select “ALL” to cease flooding for all groups
NA
ALL
VLAN
Specify the VLANs for which the IPv4 multicast
addresses are to be flooded. The VLANs may be specified as a comma-separated list of names, a list or range
of VIDs, or a combination thereof. Specify “ALL” to
cease flooding for all VLANs.
NA
NA
FORCE
Bypasses the confirmation message
NA
NA
Release Note
Modified - In release 17.0 the parameter VLAN has been added.
Note
The specified groups must have been previously enabled for flooding on the specified VLANs.
Example
DELETE IGMPSNOOPING FLOODING ALLSTANDARD VID=401
Delete IGMPSNOOPING FLOODING ALLSTANDARD settings (Y/N)?Y
536
Configuring IGMP
Syntax
[ MESSAGETYPE={ V1REPORT | V2REPORT | LEAVE | GENERALQUERY | LASTMEMBERQUERY
| ALL } ]
[ MACADDRESS={ macaddress | ALL } ]
[ GROUPADDRESS={ ipaddress | ALL } ]
Description
This command deletes IGMP message types from the event trace subsystem that were previously
added using "ADD TRACE IGMPSNOOPING". When message types are deleted, message of that type
will no longer be captured in the event trace buffer.
The "INTERFACE", "MACADDRESS", and "GROUPADDRESS" filter specification must match the
specification provided in the "ADD TRACE IGMPSNOOPING" command
Mode
Manager
Options
Option
Description
Range
Default
Value
MESSAGETYPE
Specify the type of IGMP messages for which capture in
the event trace system is to be stopped. Specify ALL to
stop capturing all types of messages
NA
ALL
VLAN
Specify the VLAN that was used in the “ADD TRACE
IGMPSNOOPING” command, if any
NA
ALL
INTERFACE
Specify the interface filter list that was used in the
“ADD TRACE IGMPSNOOPING” command.
NA
ALL
MACADDRESS
Specify the MAC address filter list that was used in the
“ADD TRACE IGMPSNOOPING” command
NA
ALL
GROUPADDRESS
Specify the IPv4 multicast group filter that was used in
the “ADD TRACE IGMPSNOOPING” command.
NA
ALL
Release Note
Modified - In Release 17.0 the parameter VLAN is added.
Note
The specified trace types must have previously been added using "ADD TRACE IGMPSNOOPING".
Example
DELETE TRACE IGMPSNOOPING MESSAGETYPE=REPORTV2
DELETE TRACE IGMPSNOOPING MESSAGETYPE=GENERALQUERY
DELETE TRACE IGMPSNOOPING MESSAGETYPE=REPORTV1 GROUPADDRESS=224.1.10.10
537
Configuring IGMP
Syntax
Syntax
[ MESSAGETYPE={ GENERALQUERY | LASTLISTENERQUERY | V2REPORT | V1REPORT |
V1DONE | ALL } ]
[ IPSOURCE={ ipv6address | ALL } ]
[ GROUPADDRESS={ ipv6address | ALL } ]
Description
This command deletes MLD message types from the event trace subsystem that were previously added
using "ADD TRACE MLDSNOOPING". When message types are deleted, message of that type will no
longer be captured in the event trace buffer.
The "VLAN", "INTERFACE", "MACADDRESS", and "GROUPADDRESS" filter specification must match
the specification provided in the "ADD TRACE MLDSNOOPING" command
Mode
Manager
Options
Option
Description
Range
Default
Value
MESSAGETYPE
Specify the type of MLD messages for which capture in
the event trace system is to be stopped. Specify ALL to
stop capturing all types of messages
NA
ALL
VLAN
Specify the VLAN that was used in the “ADD TRACE
MLDSNOOPING” command, if any
NA
ALL
INTERFACE
Specify the interface filter list that was used in the
“ADD TRACE MLDSNOOPING” command.
NA
ALL
IPSOURCE
Specify the IPv6 source address filter list that was used
in the “ADD TRACE MLDSNOOPING” command.
NA
ALL
GROUPADDRESS
Specify the IPv6 multicast group filter that was used in
the “ADD TRACE MLDSNOOPING” command.
NA
ALL
Note
The specified trace types must have previously been added using "ADD TRACE MLDSNOOPING".
Example
INTERFACE=ETH:1.*
MESSAGETYPE=V2REPORT
MESSAGETYPE=GENERALQUERY VLAN=100-199
IPSOURCE=fe80::202:ffff:f100:0102
MESSAGETYPE=V1REPORT GROUPADDRESS=FF1E::101:101
538
Configuring IGMP
Syntax
{ INTERFACE={ type:id-range | id-range | ifname-list | ALL } ]
| VLAN={ vlanname-list | vid-range | ALL } }
[ FORCE ]
Description
This command disables IGMP snooping on the specified interfaces or VLANs. By default, IGMP snooping is disabled on all VLANs but enabled on all interfaces. For IGMP snooping to be operational on a
VLAN-interface pair, it must be enabled for both the VLAN and the interface.
When IGMP snooping is disabled on a VLAN, the system will cease intercepting or examining IGMP
protocol packets on that VLAN. All learned groups will be cleared from the IGMP snooping system for
the VLAN; therefore, all subsequent IPv4 multicast groups received on the VLAN will be treated as
unknown multicast, subject to the flooding rules specified by the "SWITCH MULTICAST FLOODUNKNOWNS" system setting (see "SET SWITCH MULTICAST". If an active querier has been detected
on any of the specified VLANs, a warning message will appear.
When IGMP snooping is disabled on an interface, the system will not intercept or examine IGMP protocol packets from that interface. All learned groups will be cleared from the IGMP snooping for that
interface
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
When this option is selected, IGMP snooping will be disabled for one or more interfaces. Specify the interfaces
for which IGMP snooping is to be disabled. Interfaces
may be specified as a list, a range, or a combination
thereof. Specify “ALL” to disable IGMP snooping for all
interfaces.
NA
NA
VLAN
When this option is selected, IGMP snooping will be disabled for one or more VLANs. Specify the VLANs for
which IGMP snooping is to be disabled. The VLANs may
be specified as a comma-separated list of names, a list or
range of VIDs, or a combination thereof. Specify ALL to
disable IGMP snooping on all existing VLANs.
NA
NA
FORCE
This command will display a warning and prompt for
confirmation if an active querier has been detected on
any specified VLANs. Use the “FORCE” option to
bypass the confirmation prompt.
NA
NA
Release Note
Modified - In Release 17.0 the options VLAN and FORCE are added.
Note
Any explicitly specified VLANs or interfaces must already exist.
Example
DISABLE IGMPSNOOPING INTERFACE=ETH:3.4
DISABLE IGMPSNOOPING VLAN=301-305,310-390
539
Configuring IGMP
DISABLE MLDSNOOPING VLAN
Syntax
DISABLE MLDSNOOPING VLAN={ vlanname-list | vid-range | ALL }
[ FORCE ]
Description
This command disables MLD snooping on the specified VLANs.
When MLD snooping is disabled on a VLAN, the system will cease intercepting or examing MLD protocol packets on that VLAN. All learned groups will be cleared from the MLD snooping system for the
VLAN; therefore, all subsequent IPv6 multicast groups received on the VLAN will be treated as
unknown multicast, subject to the flooding rules specified by the SWITCH MULTICAST FLOODUNKNOWNS system setting (see SET SWITCH MULTICAST FLOODUNKNOWNS). If an active querier has been detected on any of the specified VLANs, a warning message will appear.
Mode
Manager
Options
Option
Description
Range
Default
Value
VLAN
Specify the VLANs for which MLD snooping is to be disabled. The VLANs may be specified as a comma-separated list of names, a list or range of VIDs, or a
combination thereof. Specify ALL to disable MLD
snooping on all existing VLANs.
NA
NA
FORCE
This command will display a warning and prompt for
confirmation if an active querier has been detected on
any specified VLANs. Use the “FORCE” option to
bypass the confirmation prompt.
NA
NA
Example
officer SEC>> DISABLE MLDSNOOPING VLAN=301-305,310-390
540
Configuring IGMP
ENABLE IGMPSNOOPING
Syntax
ENABLE IGMPSNOOPING
{ INTERFACE={ type:id-range | id-range | ifname-list | ALL }
| VLAN={ vlanname-list | vid-range | ALL } }
Description
This command enables IGMP snooping on the specified interfaces or VLANs.
When IGMP snooping is enabled on a VLAN and interface, the system will look for IGMP reports to
determine if a host on the VLAN and interface has subscribed to a multicast group, so that the group
can be forwarded to the VLAN and interface appropriately. The system will also look for IGMP queries
and other protocol packets to dynamically determine the interface on which the multicast router is
connected, so that it can determine to which interfaces the reports are to be sent.
By default, IGMP snooping is enabled on all interfaces but disabled on all VLANs. IGMP is not functional on a VLAN-interface pair unless it is enabled on both the VLAN and interface. Therefore, by
default, all IPv4 multicast groups are treated as unknown. If "ENABLE IGMPSNOOPING VLAN=ALL"
is entered, all existing VLANs will be enabled for IGMP snooping; however, new VLANs that are created later will have IGMP snooping disabled by default.
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
When this option is selected, IGMP snooping will be
enabled for one or more interfaces. Specify the interfaces for which IGMP snooping is to be enabled. Interfaces may be specified as a list, a range, or a combination
thereof. Specify “ALL” to enable IGMP snooping for all
interfaces
NA
NA
VLAN
When this option is selected, IGMP snooping will be
enabled for one or more VLANs. Specify the VLANs for
which IGMP snooping is to be enabled. The VLANs may
range of VIDs, or a combination thereof. Specify ALL to
enable IGMP snooping on all existing VLANs
NA
NA
Release Note
In release 17.0 the option VLAN is added.
Note
On the SBx3100, only up to 128 VLANs may be enabled for MLD or IGMP snooping (combined).
When the system is upgraded from a release prior to Release 17.0, the system may temporarily be in a
state where more than 128 VLANs are enabled for IGMP snooping. Certain operations will be disabled
while the system in this state. See Enabling IGMP and MLD Snooping (per-VLAN/Interface).
Example
ENABLE IGMPSNOOPING VLAN=301-400
ENABLE IGMPSNOOPING INTERFACE=ETH:3.4
541
Configuring IGMP
ENABLE MLDSNOOPING VLAN
Syntax
ENABLE MLDSNOOPING VLAN={ vlanname-list | vid-range | ALL }
Description
This command enables MLD snooping on the specified VLANs, which must already exist. When MLD
snooping is enabled, the system will look for MLD reports to determine which interfaces are listening
to which multicast groups, so that those groups can be forwarded to those interfaces appropriately.
The system will also look for MLD queries and other protocol packets to dynamically determine the
interface on which the multicast router is connected, so that it can determine to which interfaces the
reports are to be sent.
By default, MLD snooping is disabled on all VLANs, so all IPv6 multicast groups are treated as
unknown. If "ENABLE MLDSNOOPING VLAN=ALL" is entered, all existing VLANs will be enabled for
MLD snooping; however, new VLANs that are created later will have MLD snooping disabled by
default.
This command is only available on the SBx3100. Only up to 128 VLANs may be enabled for MLD or
IGMP snooping (combined). When the system is upgraded from a release prior to Release 17.0, the
system may temporarily be in a state where more than 128 VLANs are enabled for IGMP snooping.
Certain operations will be disabled while the system in this. See Enabling IGMP and MLD Snooping
(per-VLAN/Interface).
Mode
Manager
Options
Option
Description
Range
Default
Value
VLAN
Specify the VLANs for which MLD snooping is to be
enabled. The VLANs may be specified as a comma-separated list of names, a list or range of VIDs, or a combination thereof. Specify ALL to enable MLD snooping on
all existing VLANs.
NA
NA
Example
officer SEC>> ENABLE MLDSNOOPING VLAN=301-400
542
Configuring IGMP
Syntax
[ { STANDARD | MESSAGERESPONSE
| INTERFACE={ type:id-range | id-range | ifname-list | ALL }
| CARD={ slot-list | ALL } } ]
Description
This command resets statistical counters related to IGMP snooping back to zero. Message counts are
maintained for each interface. They may be reset on specific interfaces, for all interfaces on a card, or
system-wide. Message response time counters are global.
Mode
Manager
Options
Option
Description
Range
Default
Value
COUNTER
STANDARD - This parameter is optional. When specified, the command will reset message counts for all
interfaces system-wide.
NA
ALL
MESSAGERESPONSE - This parameter is optional.
When specified, the command will only reset the message response time counters
INTERFACE
This parameter is optional. When specified, the command will reset message counters for the specified
interfaces. Interfaces may be specified as a list, a range,
or a combination thereof. Specify “INTERFACE=ALL” to
reset IGMP message counts for all interfaces; this is
equivalent to specifying “STANDARD”, since the system-wide count is a sum of all the per-interface counts
NA
ALL
CARD
This parameter is optional. When specified, the command will reset message counters for interfaces on the
specified cards. Card slot numbers may be specified as a
list, a range, or a combination thereof. Specify
“CARD=ALL” to reset IGMP message counts for interfaces on all cards; this is equivalent to specifying “STANDARD”, since the system-wide count is a sum of all the
per-interface counts
NA
ALL
Release Note
NA
Example
RESET igmpsnooping COUNTER INTERFACE=ETH:3.*
543
Configuring IGMP
SET IGMPSNOOPING
Syntax
SET IGMPSNOOPING
{ INTERFACE={ type:id-range | id-range | ifname-list | ALL }
SNOOPINGMODE={ INTERNAL | EXTERNAL | MCPASSTHROUGH } |
[ FLOODUNKNOWNS={ ON | OFF } ]
[ ROUTERAGEINGTIMER=10..1200 ]
[ GENQUERYTIMER=5..120 ]
[ DUPREPORTTIMER={ OFF | 1..120 } ]
[ IMGCOMPATIBILITYMODE={ ON | OFF } ] }
Description
The SET IGMPSNOOPING command is used to set various configurable IGMP settings in the switch.
These being setting the multicast stream count per slot, the flooding of unknown multicast packets,
and various timers are options you can set.
Mode
Manager
Options
Option
Description
Range
Default
Value
INTERFACE
The interface(s) for setting the MCASTGROUPLIMIT
NA
NA
SNOOPINGMODE
This option is used when defining IGMPSNOOPING
for an interface or set of interfaces.
NA
NA
NA
No
INTERNAL - The system will reconfigure HW to
limit the forwarding of multicast packets only to the
interface(s) that have expressed interest in the multicast group. IGMP Snooping will perform it's normal processing actions, such as source MAC
validation of IGMP Leaves AND set-top-box mobility.
EXTERNAL - The system will reconfigure HW to
limit the forwarding of multicast packets only to the
interface(s) that have expressed interest in the multicast group. IGMP Snooping will perform modified
processing actions, such as skipping source MAC
validation of IGMP Leaves AND set-top-box mobility. This mode will allow an IGMP Snooper behind
these interface(s).
MCPASSTHROUGH - The system will NOT reconfigure HW to limit the forwarding of multicast packets only to the interface(s) that have expressed
interest in the multicast group. Instead, the system
will FLOOD all multicast traffic, that is received
from a MC router, to all interface(s) in the same
VLAN AND that are in MCPASSTHROUGH mode.
*NOTE: This mode is ONLY supported on NETWORK direction interface(s).
FLOODUNKNOWNS
Indicates whether the unknown multicast packets
will be flooded or dropped.
544
Configuring IGMP
Default
Value
Option
Description
Range
ROUTERAGEINGTIMER
Specifies how long to wait before cleaning up ALL
IGMP related information associated with a learned
multicast router. If no multicast related packets have
been received, on the port we learned the router
on, (IGMP general query packets, OSPF multicast
hello, PIMv1/PIMv2, or DVMRP), all associated
IGMP information will be cleaned up.
NA
300 seconds (5
minutes)
GENQUERYTIMER
Allows you to specify how long after an IGMP general query is received, before the switch cleans up
any non-IGMP reporting subscriber devices.
NA
20 seconds
DUPREPORTTIMER
Time delay before sending duplicate IGMP reports
to multicast router(s)
NA
10 seconds
NA
OFF
Multiple subscriber devices may send up duplicate
multicast group information in an IGMP report (i.e.,
EPG) after a general query is received. Usually, ALL
of these reports would be sent to the multicast
router(s). This option controls the time delay, which
is used to determine when another duplicate report
would be sent to the multicast router(s).
IMGCOMPATIBILITYMODE
Used to support IGMP and iMGs in proxy mode
when IP ACLs and/or IP Classifiers are also used.
The two available modes are:
- ON - IGMP packets are NOT applied against filters.
- OFF - IGMP packets are applied against filters.
Note that If iMGs (in proxy mode) are used with
the mode set to OFF, received IGMP packets are
applied against filters and MAY get dropped unexpectedly.
Release Note
Modified - In release 17.0, the CARD and MCASTGROUPLIMIT options are removed.
Example
SET IGMPSNOOPING ROUTERAGEINGTIMER=250 GENQUERYTIMER=30
SET IGMPSNOOPING DUPREPORTTIMER=OFF
545
Configuring IGMP
SET MLDSNOOPING
Syntax
SET MLDSNOOPING
[ ROUTERAGEINGTIMER=10..1200 ]
[ GENQUERYTIMER=5..120 ]
[ DUPREPORTTIMER={ OFF | 1..120 } ]
Description
This command sets global parameters for MLD snooping. The "ROUTERAGEINGTIMER" parameter
sets the number of seconds after which a dynamically detected multicast router will be removed from
the system (i.e., the interface on which the router was detected will no longer be designated as a
dynamic multicast router port). The "GENQUERYTIMER" parameter sets the expiration time for a
host in a multicast group; after this amount of time passes since a query message was seen from the
querier, the host will be removed from the group. The "DUPREPORTTIMER" specifies the amount of
time during which duplicate MLDv1 report messages for the same group will be suppressed (prevented
from being forwarded to MLD queriers).
Mode
Manager
Options
Default
Value
Option
Description
Range
ROUTERAGEINGTIMER
This parameter is optional. Specifies the number of seconds after which a dynamically detected multicast
router will be removed from the system due to inactivity.
10-1200
300 seconds (5
minutes)
GENQUERYTIMER
This parameter is optional. Specifies the number of seconds after a general query message that a host will be
removed from a multicast group, if the host has not
responded to the query with a report for the group.
5-120
20 seconds
DUPREPORTTIMER
This parameter is optional. For MLDv1 reports only,
specifies the number of seconds during which duplicate
report messages for the same group will be suppressed
(prevented from being forwarded to MLD queriers).
This setting does not affect MLDv2 reports.
1-120
10 seconds
Example
SET MLDSNOOPING ROUTERAGEINGTIMER=250 GENQUERYTIMER=30
SET MLDSNOOPING DUPREPORTTIMER=OFF
546
Configuring IGMP
SET SWITCH MULTICAST FLOODUNKNOWNS
Syntax
SET SWITCH MULTICAST FLOODUNKNOWNS={ ALL | NONE | CONTROLONLY }
Description
This command controls the handling of layer-2 multicast traffic in the switch.The "FLOODUNKNOWNS" parameter specifies how the system should globally handle multicast data that is not associated with a group learned by IGMP or MLD snooping.
Mode
•
If the parameter is set to "ALL", all unknown multicast data traffic is flooded to all interfaces on the
originating VLAN (i.e., the VLAN on which the packet arrived).
•
If it is set to "NONE", unknown multicast traffic data traffic is only sent to multicast pass-through
or send-all interfaces , or to multicast router port interfaces on an SBx3100, by default. However,
flooding can be enabled for particular addresses or protocols on particular VLANs using the “ADD
IGMPSNOOPING FLOODING" command.
•
If it is set to "CONTROLONLY", IPv4 and IPv6 protocol control packets are flooded to interfaces
on the originating VLAN; other unknown multicast data traffic is only sent to multicast send-all
interfaces by default. Protocol control packets are defined as packets where the destination is recognized as well-known multicast address (IPv6 addresses in the range FF0n::m:0:0/98 or
FF0n::m:FF00:0/104, where n is a value from 0-F and m is a value from 0-2; or, IPv4 addresses in
the range 224.0.0.0/24).
Manager
Options
Option
Description
Range
Default
Value
FLOODUNKNOWNS
Specify how unknown multicast packets are to be handled globally by the system. Refer to the Description.
NA
NONE
Release Note
New - In release 17.0, this is a new command. The "FLOODUNKNOWNS" parameter was an IGMPspecific parameter on the "SET IGMPSNOOPING" command in releases prior to Release 17.0. For
more information on the change to the SET IGMPSNOOPING command.)
Note
On the SBx3100, this command may not be used if IGMP or MLD snooping is enabled for more than
128 VLANs. This should only occur if the system has been upgraded from a release prior to Release
17.0 (see Enabling IGMP and MLD Snooping (per-VLAN/Interface).
Example
SET SWITCH MULTICAST FLOODUNKNOWNS=CONTROLONLY
547
Configuring IGMP
SET SWITCH MULTICAST INTERFACE SNOOPINGMODE
Syntax
SET SWITCH MULTICAST
SNOOPINGMODE={ INTERNAL | EXTERNAL | PASSTHROUGH | SENDALL }
Description
This command controls the handling of layer-2 multicast traffic in the switch for an interface.
The "SNOOPINGMODE" parameter controls how the system should handle multicast data traffic on
a per-interface basis.
If the mode is set to "INTERNAL", the IGMP and MLD snooping processes look for report messages
on the interface, and the system only forwards a known multicast group to the interface if a report has
been seen for the group. "Leave" or "done" messages for a multicast group are only processed if the listener host originating the message is known to be subscribed to the group. When the list of known listener hosts for a group-VLAN-interface triplet is empty, the group is no longer forwarded to the
VLAN-interface pair. Since "INTERNAL" snooping causes the system to track each listener host on a
VLAN-interface, this also enables duplicate report suppression and last leave processing to occur on
the interface.
If the mode is set "EXTERNAL", the behavior is the same as "INTERNAL" except that system does not
track individual listener hosts on an interface, and thus no attempt is made to validate the "leave" message against a list of known hosts. Instead, the system stops forwarding the multicast group to the
VLAN-interface pair upon receipt of any "leave" or "done" message for that group, regardless of which
listener host sent the message. Duplicate report suppression and last leave processing will not be performed on an interface set to "EXTERNAL" snooping. This setting is typically used when there is a
downstream IGMP or MLDv1 snooping device that is already performing last-leave processing or is
behaving as a snooping proxy device, or if there is only one listener host connected to the interface.
(This setting should not be used with a downstream MLDv2 snooping device, unless the device is acting as a layer-2 MLD proxy.)
If the mode is set to "PASSTHROUGH", the interface is designated as a multicast pass-through interface; all multicast traffic on any VLANs associated with the interface will always be forwarded to it as
long as the traffic arrived on another pass-through interface . IGMP snooping and MLD snooping processes do not attempt to detect listeners on the interface. There is no hard limit to the number of
interfaces designated as multicast pass-through interfaces. However, note that excessive numbers of
multicast pass-through interfaces may cause increased network usage, since more multicast traffic may
be flooded.
If the mode is set to "SENDALL", the interface is designated as a multicast send-all interface. It behaves
like a multicast pass-through interface, except that multicast traffic is always sent to the interface
regardless of whether or not it arrived on a pass-through or send-all interface.
The multicast pass-through and send-all designations are generally used for interfaces involved in
redundant network topologies such as EPSR or STP, when the direction of multicast traffic flow
between switching nodes may need to change as a result of a topology change; or, for interfaces that
interconnect daisy-chained switches.
The default snooping mode for an interface depends on the type of card on which the interface
resides. For interfaces on the SBx3100 XE4 and XE6SFP cards, the default mode is "SENDALL". For all
other interface types, the default mode is "INTERNAL".
Mode
Manager
548
Configuring IGMP
Options
Note
Option
Description
Range
Default
Value
INTERFACE
Specify one or more physical or aggregate interfaces for
which to change the multicast settings. Interfaces may be
specified as a list, a range, or a combination thereof.
Specify “ALL” to change the multicast settings for all
interfaces.
NA
NA
SNOOPINGMODE
Controls how the system should handle multicast
data traffic on a per-interface basis. Refer to the
description.
NA
determined by
cardtype
In Release 17.0 the SBx3100 does not support "PASSTHROUGH" and the iMAP does not support
"SENDALL". (In releases prior to Release 17.0, the SBx3100 incorrectly designated send-all interfaces
as "PASSTHROUGH". Interfaces marked "PASSTHROUGH" in earlier releases are corrected to "SENDALL" during the software upgrade process. See "Multicast Pass-Through changed to Multicast SendAll" TBS.) Since they are similar in function, interfaces on the SBx3100 should be configured for "SENDALL" in situations that would otherwise call for "PASSTHROUGH"; conversely, interfaces on the
iMAP should be configured for "PASSTHROUGH" in situations that would otherwise call for "SENDALL".
Example
SET SWITCH MULTICAST INTERFACE=ETH:[1.1-2] SNOOPINGMODE=SENDALL
549
Configuring IGMP
SETDEFAULTS MLDSNOOPING
Syntax
SETDEFAULTS MLDSNOOPING [ ROUTERAGEINGTIMER ] [ GENQUERYTIMER ]
[ DUPREPORTTIMER ]
Description
This command sets global parameters for MLD snooping to their default values. If one or more parameters are specified, those parameters will be set back to their default values. If no parameters are specified, then all parameters are set to their default values.
Mode
Manager
Options
Default
Value
Option
Description
Range
ROUTERAGEINGTIMER
Specifies how long to wait before cleaning up ALL IGMP
related information associated with a learned multicast
router. If no multicast related packets have been
received, on the port we learned the router on, (IGMP
general query packets, OSPF multicast hello, PIMv1/
PIMv2, or DVMRP), all associated IGMP information will
be cleaned up.
NA
300 seconds (5
minutes)
GENQUERYTIMER
Allows you to specify how long after an IGMP general
query is received, before the switch cleans up any nonIGMP reporting subscriber devices.
NA
20 seconds
DUPREPORTTIMER
Time delay before sending duplicate IGMP reports to
multicast router(s)
NA
10 seconds
Multiple subscriber devices may send up duplicate multicast group information in an IGMP report (i.e., EPG)
after a general query is received. Usually, ALL of these
reports would be sent to the multicast router(s). This
option controls the time delay, which is used to determine when another duplicate report would be sent to
the multicast router(s).
Note
The specified interfaces must already exist.
Example
SETDEFAULTS MLDSNOOPING ROUTERAGEINGTIMER
550
Configuring IGMP
Syntax
SETDEFAULTS SWITCH MULTICAST [ FLOODUNKNOWNS ]
Description
This command sets the unknown multicast data traffic handling behavior to the system default,
"NONE". Multicast groups that have not been learned by IGMP snooping or MLD snooping will not be
flooded unless the destination address category has been designated for flooding on a VLAN using the
"ADD SWITCH MULTICAST FLOODING" command or ADD IGMPSNOOPING FLOODING command.
Mode
Manager
Options
Option
Description
Range
Default
Value
FLOODUNKNOWNS
This parameter is optional. It indicates that the FLOODUNKNOWNS parameter is to be set to its default
value, “NONE”. (Since there are no other global
SWITCH MULTICAST attributes, the command
behaves the same way whether this parameter is specified or not.)
NA
NONE
Example
officer SEC>> SETDEFAULTS SWITCH MULTICAST
551
Configuring IGMP
SETDEFAULTS SWITCH MULTICAST INTERFACE
Syntax
[ SNOOPINGMODE ]
Description
This command changes the multicast snooping mode for the specified interfaces to the default value
for each interface. The default setting for an interface depends on the type of card on which the interface resides.
Mode
Manager
Options
Note
Option
Description
Range
Default
Value
INTERFACE
which to change the multicast snooping mode, for both
IGMP and MLD snooping. Interfaces may be specified as
a list, a range, or a combination thereof. This designation applies across all VLANs on the interfaces.
NA
NA
SNOOPINGMODE
This parameter is optional. It indicates that the
“SNOOPINGMODE” parameter is to be set to its
default value. (Since there are no other SWITCH MULTICAST attributes for interfaces, the command behaves
the same way whether this parameter is specified or
not.)
NA
Set by
interface
card type
For interfaces on the SBx3100 XE4 and XE6SFP cards, the default mode is "SENDALL". For all other
interface types, the default mode is "INTERNAL.
Example
officer SEC>> SETDEFAULTS SWITCH MULTICAST INTERFACE=ETH:[1.1-2]
552
Configuring IGMP
SHOW IGMPSNOOPING
Syntax
Description
SHOW IGMPSNOOPING
[ { VLAN={ vlanname-list | vid-range |
| INTERFACE={ type:id-range | id-range
| MCASTGROUPS
[ { VLAN={ vlanname-list | vid-range |
| CARD={ slot-list | ALL }
| INTERFACE={ type:id-range | id-range
} ]
[ FULL ] } ]
ALL }
| ifname-list | ALL }[ FULL ]
ALL }
| ifname-list | ALL }
This command displays information about IGMP snooping. If the "MCASTGROUPS" option is specified,
the command displays information about multicast groups currently known by the IGMP snooping processes; otherwise, it displays IGMP snooping configuration data.
The command may show information by VLAN, interface, or card. More detail is available with some
parameter combinations if the FULL option is specified. If the command is issued with no parameters,
system-wide configuration data will be shown
Mode
Manager
Options
Option
Description
Range
Default Value
VLAN
This parameter is optional. When specified, the command will display the IGMP snooping state for each
specified VLAN and a list of static or dynamic multicast
router ports. VLANs may be specified as a comma-separated list, a range of VIDs, or a combination thereof.
Specify “VLAN=ALL” to display the IGMP snooping
state for all VLANs
NA
system-wide settings (not perVLAN information)
INTERFACE
which to display IGMP snooping configuration data.
Interfaces may be specified as a list, a range, or a combination thereof. When this parameter is used, the command will display the IGMP snooping state for each
specified interface, along with the interface’s multicast
snooping mode and the number of static multicast MAC
addresses associated with the interface. When used in
conjunction with the FULL option, a list of full or partial
static MAC addresses associated with the interface will
be shown
NA
system-wide settings (not perinterface information)
MACASTGROUP
Specify the command will display multicast groups that
have been learned by IGMP snooping rather than IGMP
snooping configuration data. The groups shown may be
filtered using the optional parameters below.
NA
NA
- VLAN
This parameter is optional when the “MCASTGROUPS”
parameter is used. Show a count of learned multicast
groups for each VLAN. When used in conjunction with
the “FULL” option, the command will display the multicast MAC and IP address of each group, and the slot
numbers of the cards that are receiving the groups.
Specify “VLAN=ALL” to show multicast group information about all VLANs
NA
ALL
553
Release Note
Configuring IGMP
Option
Description
Range
Default Value
- CARD
parameter is used. Specify one or more card slot numbers for which to display IGMP multicast groups. Cards
may be specfied as a comma-separated list, a range, or a
combination thereof. When this parameter is used, the
command will display the number of multicast groups
being received by each card and VLAN. When used in
conjunction with the “FULL” option, the command will
display the multicast MAC and IP address of each group.
Specify “CARD=ALL” to show multicast group information about all cards
NA
Display by
VLAN not filtered by card
- INTERFACE
parameter is used. Specify the physical or aggregate
interfaces for which to display IGMP multicast group
information. Interfaces may be specified as a list, a range,
or a combination thereof. When this parameter is used,
the command will display the number of active subscriber host MAC addresses detected by IGMP snooping on the interface, and the number of multicast groups
currently being sent to the interface. When used in conjunction with the “FULL” option, the command will display each host’s MAC address and the multicast IP
address of each group. Specify “INTERFACE=ALL” to
show multicast group information about all interfaces
NA
Display by
VLAN not filtered by interface
FULL
This parameter is optional. When specified with certain
parameters (see parameter descriptions above), information will be shown in detail rather than in tabular
summary format. This will allow for more information
to be shown, but will greatly increase the length of the
output
NA
Display summary
information only
Modified - The command is updated in Release 17.0 to include the VLAN options.
Example
officer SEC>> SHOW IGMPSNOOPING INTERFACE=ETH:8.11,ETH:8.13
--- Interface IGMP Snooping Configuration --Static MAC
Interface
State
Snooping Mode
Addresses
-------------- -------- -------------- ----------ETH:[8.11]
Enabled Internal
0
ETH:[8.13]
Enabled Internal
0
officer SEC>> SHOW IGMPSNOOPING INTERFACE=ETH:8.11 FULL
--- Interface IGMP Snooping Configuration --Interface....................... ETH:[8.11]
Interface IGMP State............ Enabled
IGMP Snooping Mode.............. Internal
554
Configuring IGMP
Syntax
[ { STANDARD
| MESSAGERESPONSE
| CARD={ slot-list | ALL }
} ]
Description
This command displays a count of IGMP messages that have been observed by the IGMP snooping process. If the "MESSAGERESPONSE" parameter is selected, it displays the number of responses to an
IGMP query within specific time ranges. This command may be useful in diagnosing the operation of
the IGMP protocol.
Packet counts are divided into "good" packets and "error" packets. An "error" packet is one that could
not be parsed by the IGMP snooping process; this may be due to an incompatibility with third-party
host devices or routers.
Mode
Manager
Options
Release Note
Option
Description
Range
Default Value
STANDARD
This parameter is optional. When specified, the command will only display the “standard” counters, which is
a system-wide count of IGMP messages by message
type.
NA
Display both
STANDARD
(global) and
MESSAGERESPONSE counters
MESSAGERESPONSE
This parameter is optional. When specified, the command will only display message response counters,
which indicates the number of responses to an IGMP
query within specific time ranges
NA
Display both
STANDARD
(global) and
INTERFACE
This parameter is optional. When specified, the command will display a count of IGMP messages per interface, by message type. Interfaces may be specified as a
list, a range, or a combination thereof. Specify “INTERFACE=ALL” to show IGMP message counts for all interfaces.
NA
Display both
STANDARD
(global) and
CARD
This parameter is optional. When specified, the command will display a count of IGMP messages per card, by
message type. Interfaces may be specified as a list, a
range, or a combination thereof. Specify “INTERFACE=ALL” to show IGMP message counts for all interfaces
NA
Display both
STANDARD
(global) and
New - In Release 17.0 this command is added.
Example
SHOW IGMPSNOOPING COUNTER STANDARD
--- IGMP Message Counters ---
555
Configuring IGMP
Message Type
Good Count
Error Count
-------------- -------------- -------------Report ver 1
0
0
Report ver 2
415
0
Leave
390
0
General Query
205
0
Grp Spec Query
315
0
officer SEC>> SHOW IGMPSNOOPING COUNTER MESSAGERESPONSE
--- IGMP System-level Message Response Counters --Response Range
--------------0-249
(msec)
250-499 (msec)
500-749 (msec)
750-1000 (msec)
1-2 (sec)
2-3 (sec)
3-4 (sec)
4+ (sec)
Last Updated
Message Count
---------------------- -------------2012-04-01 13:00:17
250
2012-04-01 13:00:00
10
2012-04-01 13:00:00
0
2012-04-01 13:00:00
0
2012-04-01 13:00:00
125
2012-04-01 13:00:00
30
2012-04-01 13:00:00
0
2012-04-01 13:00:00
0
556
Configuring IGMP
Syntax
Description
This command displays the IPv4 protocols that have been enabled for flooding on one or more VLANs,
using the "ADD IGMPSNOOPING FLOODING" command.
Mode
Manager
Options
NA
Release Note
NA
Example
--- IGMP Snooping Static Flooding Groups --Multicast Group Name
-------------------MDNS
OSPFDESIGNATED
PIM
RIP2
RSVP
VRRP
Multicast MAC
----------------01:00:5E:00:00:FB
01:00:5E:00:00:06
01:00:5E:00:00:0D
01:00:5E:00:00:09
01:00:5E:00:00:0E
01:00:5E:00:00:12
Multicast IP
--------------224.0.0.251
224.0.0.6
224.0.0.13
224.0.0.9
224.0.0.14
224.0.0.18
VLAN(s)
----------520-529
520-529
520-529
520-529
512
512
557
Configuring IGMP
SHOW MLDSNOOPING
Syntax
SHOW MLDSNOOPING
[ { VLAN={ vlanname-list | vid-range | ALL }
[ FULL ]
| MCASTGROUPS
[ { GROUP={ groupaddress-list | ALL }
| VLAN={ vlanname-list | vid-range | ALL }
} ]
[ FULL ]
} ]
Description
This command displays information about the MLD snooping process. The "SHOW MLDSNOOPING"
command with no parameters shows global settings related to MLD snooping.
If the "VLAN" parameter is used, the command will display the MLD snooping state for the specified
VLANs (enabled or disabled), as well as any multicast router ports that have been configured or
dynamically detected for the VLAN.
If the "MCASTGROUPS" parameter is used, the command shows known IPv6 multicast groups that
have been discovered by MLD snooping. The list of groups shown may be filtered by multicast group
address, by VLAN, or by interface.
Mode
Manager
Options
Option
Description
Range
Default Value
VLAN
This parameter is optional. When specified, the command will display the MLD snooping state for each specified VLAN and a list of static or dynamic multicast
router ports. VLANs may be specified as a comma-separated list, a range of VIDs, or a combination thereof.
Specify “VLAN=ALL” to display the MLD snooping state
for all VLANs
NA
Display only system-wide settings, not perVLAN information
- FULL
This parameter is optional. When specified, MLD information will be shown in detail rather than in tabular
summary format. This will allow for more information
to be shown, but will greatly increase the length of the
output.
NA
Summary display is shown
MCASTGROUPS
This parameter is optional. When specified, the command will display multicast groups that have been
learned by MLD snooping rather than system-wide MLD
snooping settings. The groups shown may be filtered
using the optional parameters below.
NA
Display only system-wide settings, not a list of
multicast groups
- GROUP
This parameter is optional. Filter the list of multicast
groups shown by the specified list of multicast groups,
entered in standard IPv6 notation. Multiple groups may
be specified as a comma-separated list. If “ALL” is specified, the output will not be filtered by group address
NA
ALL
558
Configuring IGMP
Option
Description
Range
Default Value
- VLAN
groups shown by the specified VLANs. The VLANs may
range of VIDs, or a combination thereof. If “ALL” is
specified, the output will not be filtered by VLAN.
NA
ALL
- INTERFACE
groups shown by the specified physical or aggregate
interfaces. Interfaces may be specified as a list, a range,
or a combination thereof. If “ALL” is specified, the output will not be filtered by interface.
NA
ALL
- FULL
This parameter is optional. When specified, multicast
groups information will be shown in detail rather than in
tabular summary format. This will allow for more information to be shown, but will greatly increase the length
of the output.
NA
Summary display shown
Example
officer SEC>> SHOW MLDSNOOPING
--- MLD Snooping Configuration --Duplicate Report Delay (MLDv1).......
General Query Timeout................
Router Ageing Timeout................
Multicast Send-All Interfaces .......
MLD Snooping VLANS...................
10 seconds
20 seconds
300 seconds
ETH:[7.1-2]
306-310,391-400
officer SEC>> SHOW MLDSNOOPING VLAN=300,309-310
VLAN
---300
309
State
-------Disabled
Enabled
310 Enabled
-- Multicast Router Ports -- GenQuery
Type
Interface
Expires ExpTimer
-------- ----------- ------- -------Dynamic ETH:7.1
215s
22s
Dynamic ETH:7.2
213s
22s
Dynamic ETH:7.1
141s
17s
Dynamic ETH:7.2
144s
17s
559
Configuring IGMP
Syntax
[ { INTERFACE [ ={ type:id-range | id-range | ifname-list | ALL } ]
} ]
Description
This command displays data on multicast switching settings. If no optional parameters are specified, the
command will show the global setting for the "FLOODUNKNOWNS" parameter and a list of multicast pass-through and/or send-all interfaces. For convenience, the command also displays a list of
VLANs for which IGMP or MLD snooping is enabled. (This information is also available under "SHOW
IGMPSNOOPING" or "SHOW MLDSNOOPING".)
If the "INTERFACE" parameter is used, the command will display the snooping mode for each of the
specified interfaces, as well as the IGMP snooping state of the interfaces. (Note that there is no MLD
snooping state for an individual interface.)
Mode
User
Options
Option
Description
Range
Default
Value
INTERFACE
This parameter is optional. If included, the command
will display the snooping mode for a set of interfaces,
rather than just a global summary multicast settings
NA
ALL
- If a range of interfaces is specified, the command will
display the snooping mode for each specified physical or
aggregate interface. Interfaces may be specified as a list,
a range, or a combination thereof. Specify ALL to show
multicast data for all interfaces.
Note
The SBx3100 series displays multicast send-all interfaces since multicast pass-through interfaces are
not supported on the SBx3100.
Example
--- Multicast Switching Settings --Flood Unknown Multicast..............
Multicast Send-All Interfaces........
IGMP Snooping VLANs..................
MLD Snooping VLANS...................
Control Packets Only
ETH[1.1-2]
306-310,391-400
306-310,391-400
officer SEC>> SHOW SWITCH MULTICAST INTERFACE=ETH:[1.1-3]
--- Multicast Switching Interface Settings --Interface
--------ETH:1.1
ETH:1.2
ETH:1.3
Snooping Mode
------------SendAll
SendAll
Internal
IGMP Snooping
------------Enabled
Enabled
Enabled
560
Configuring IGMP
Syntax
Description
This command displays the IGMP message types that have been enabled for event tracing using the
"ADD TRACE IGMPSNOOPING" command. Note that this command does not display captured trace
data; use the "SHOW TRACE BUFFER" command for that purpose.
Mode
User
Options
NA
Release Note
Modified - In Release 17.0 all options have been removed and can be found in the SHOW TRACE BUFFER command.
Example
ADD TRACE IGMPSNOOPING MESSAGETYPE=GENERALQUERY
GROUPADDRESS=224.1.10.10
--- IGMP Packet Traces -------------------------------------------------------Message Type
MC Group
Address
----------------- --------------ReportV2
ALL
General Query
ALL
ReportV1
224.1.1.10
Source MAC
Address
----------------ALL
A4:BA:DB:E7:B3:34
ALL
Interface(s)
-------------------------ALL
ETH:[1.0-3]
ALL
-------------------------------------------------------------------------------
561
Configuring IGMP
Syntax
Description
This command displays the MLD message types that have been enabled for event tracing using the
ADD TRACE MLDSNOOPING MESSAGETYPE command. Note that this command does not display
captured trace data; use the SHOW TRACE command for that purpose.
Mode
User
Options
NA
Example
officer SEC>> ADD TRACE MLDSNOOPING MESSAGETYPE=V2REPORT
officer SEC>> ADD TRACE MLDSNOOPING MESSAGETYPE=GENERALQUERY
VLAN=100-199 INTERFACE=ETH:1.* IPSOURCE=fe80::202:ffff:f100:0102
officer SEC>> ADD TRACE MLDSNOOPING MESSAGETYPE=V1REPORT
GROUPADDRESS=ff1e::101:101
officer SEC>> SHOW TRACE MLDSNOOPING
--- MLD Packet Traces ------------------------------------------------------Message Type............
VLANs...................
Interfaces..............
Source MAC Addresses....
Group IP Addresses......
V2Report
ALL
ALL
ALL
ALL
Message Type............
VLANs...................
Source IP Address.......
GeneralQuery
100-199
[ETH:1.0-3]
fe80::202:ffff:f100:0102
ALL
Message Type............
VLANs...................
Source MAC Addresses....
V1Report
ALL
ALL
ALL
ff1e::101:101
562
6. Access and Security
6.1 Introduction
This chapter introduces those features that control the types of packets and packet flow through the switch:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Quality of Service Model
Classifiers
Classifier Commands
Access Control List
Access Commands
Ingress Metering (Policing)
Ingress Metering Commands
Egress Port Rate Limiting
Egress Port Rate Limiting Commands
Priority Queuing (Layer 2)
Queue-Based Egress Rate Limiting (QOSPOLICY)
Layer 3 QoS Support (DSCP)
Ingress Metering Commands
RADIUS / TACACS Authentication
RADIUS and TACACS+ Commands
Port Authentication
Port Authentication Commands - 802.1X
MAC Authentication Commands
Common Authentication Commands
SSH
SSH Commands
Address Resolution Protocol (ARP) Filtering
ARP Filter Commands
Local ARP Discard
Local ARP Discard Commands
563
Access and Security
Introduction
6.2 Quality of Service Model
Packet-based networks provide primarily three types of services:
• Data
• Voice
• Video
Providers must deliver these services at a level of quality acceptable to the customer. Service quality or service level can be
defined by controlling:
•
•
•
•
Availability
Delay
Delay variation (jitter)
Lost packet ratio (bandwidth)
Additionally, various applications (e-mail, file transfer, teleconferencing, video conferences) can be considered as real-time
verses non real-time applications.
• Real-time applications (such as voice) have a lower tolerance to delay or delay variation, but can handle some packet loss.
• Non-real-time applications are not as adversely affected by delay or delay variation, but are highly affected by packet loss.
A Service Level Agreement (SLA) details the level of service the service provider and customer negotiate. Providers use Quality of Service (QoS) functions to segregate traffic and then manage the service quality through the network to meet the customer’s needs.
Figure 6-1 shows the general flow for QoS; refer to this figure while reading the rest of this subsection.
Note:
The rest of this subsection describes in general what traffic management provides. For the capabilities of the
SBx3100 refer to the rest of this section. Refer to the next two sections for details (capabilities, restrictions) on a
specific product.
564
Access and Security
Introduction
drop
Rule A
Rule B
mark
Rule C
mark
drop
drop
Rule D
Rule E
mark
Egress
Traffic
Shaper
count
Scheduler
Ingress
Traffic
PriorityToCOSMapper
meter
Rule F
meter
drop
Classification Filtering/Remarking/Policing Mapping
FIGURE 6-1
Queuing
Scheduling Shaping
Model of Traffic Flow for a QoS-capable Device
6.2.1 Ingress Traffic Concepts
The main strategy in providing QoS is to first classify and segregate traffic into separate flows. These flows can then be
managed separately through the provider’s network with each flow getting a specified level of service. Traffic classification and
segregation are performed when traffic from a customer enters the network through the network edge device. Traffic is classified and segregated according to set of criteria or rules. Once the traffic is classified, the packets will have certain actions
performed upon them as configured by the provider. These actions are mark, meter, count, and drop.
To mark a packet in the traffic flow means that once a packet has been allowed to ingress the port, it will be associated with
a certain flow. Marking the packet means to identify the packet with a Class of Service (COS) that will be applied to the
packet as it moves through the device and into the network.
• For ethernet frames, these are defined as the 802.1p user priority bits or class of service bits.
• For IP packets there are the DSCP field and the TOS field. The COS identifier can specify both a service level priority
and the precedence for dropping packets, but this is not done at the ethernet level.
Once a packet is marked, it may go immediately to a COS queue, but in many cases the traffic is metered. To meter the
packet flow is to monitor or police the rate of traffic flow and to see if incoming traffic exceeds the bandwidth specified in
the SLA. When packet flow exceeds the bandwidth allocated, they are labeled as Out Of Profile (OOP). This policing function is done using the leaky bucket algorithm. The bucket has a capacity and an output rate as packets enter and leave the
bucket.
If packets arrive at a rate faster than contracted for in the SLA for a continuous period of time, the bucket will overflow.
These overflow packets are classified as out of profile and another action can be applied to them, such as drop (throw away),
or remark them in such a way that these OOP packets have a higher probability of being thrown away when congestion
565
Access and Security
Introduction
points are encountered through the device or further on in the network. Packets that exceed this bandwidth are labeled as
out of profile with the SLA.
By metering the rate at which packets arrive, the provider can control bandwidth, since the SLA may include a minimum
bandwidth availability and as well as a maximum (for short periods). These are defined as follows:
• Committed Information Rate (CIR) is the minimum guaranteed rate the provider network will provide under normal
conditions, and is measured in bits per second.
Note:
Any service that provides a non-zero bandwidth guarantee must have a CIR. A CIR of zero indicates the service will
provide no minimum guarantee for frame delivery.
• Committed Burst Size (CBS) is the maximum number of bytes that can be sent at the CIR and is measured in kilobytes
(KB) or megabytes (MB)
• Peak Information Rate (PIR) is the maximum rate at which frames/packets are allowed to burst above the CIR and is
measured in bytes per second.
• Peak Burst Size (PBS) is the maximum number of bytes that can be sent at the PIR and is measured in kilobytes (KB) or
megabytes (MB).
For a service that requires only a CIR and CBS, a single meter is used; the capacity of a single bucket is equal to the CBS and
the leak rate is the CIR. For services that require all four parameters, two meters are required.
6.2.2 Egress Traffic Concepts
Once the traffic flows have passed through the policing function and are allowed to continue, the COS identifier (obtained
when the traffic was marked) is used to map the traffic with a set of queues and to assign a priority. Each queue is associated
with a level of service of low versus high. If a QoS network provides four levels of service, there will typically be four queues.
Traffic flows will be associated with a priority (using the COS identifier bit) and therefore a queue.
As the packets are placed in the queues, there may still be conditions where packets may need to be dropped. One method
of handling overflow is tail-drop; when a queue is in an overflow state, all newly arriving packets are dropped. If the potential
for queue overflow was too high, the queue size(s) were increased. However, dynamic managing of queue depth can result in
better network performance, and one method is Random Early Discard (RED), which improves network throughput and
lowers the probability of packet discard.
Note:
Random Early Discard (RED) is not supported.
As the traffic passes through the queues, they are then scheduled for output. The common type of scheduler is the Strict
Priority (SP) scheduler, which selects a packet at the head of the highest priority queue (usually allows no delay) and continues to select packets in that queue until it is empty; only then are packets chosen from other queues. When a network has
little or no congestion, all queues are scheduled equally. However, in a heavily congested network, the highest priority queue
may always have packets, and so the lower priority queues are never scheduled and are therefore blocked.
The Weighted Round Robin (WRR) scheduler associates an additional weight to each queue, so that the scheduler
spends at least some time (although limited because of its lower weighting) with the other queues.
All of these functions together help ensure that traffic is classified/filtered and then metered to ensure that its bandwidth
does not exceed the SLA. However, this does not guarantee that all network resources are available so that the bandwidth
agreed to can be propagated through the network. Call Admission Control (CAC) is an accounting algorithm that qualifies the available network resources against the SLA. Within a network device, the CFC function balances downstream congestion and full utilization of available bandwidth. CAC takes into account all factors and calculates an equivalent maximum
bandwidth.
Finally, the provider should use the performance monitoring tools provided by the system to verify the levels of service that
have been negotiated. These tools measure packet loss, delay, jitter, availability, and failure recovery time.
Note:
Weighted round robin (WRR) scheduling is not supported.
566
Access and Security
Introduction
6.2.3 Traffic Management Throughout the Network
Since the traffic flows occur throughout the network, each device must give these flows the same treatment as they pass
through the device. For Rapier devices, there are QoS features that can be configured so that traffic prioritization is similar to
what is configured for the SBx3100. For relevant documentation, go to http://www.alliedTelesis.co.nz/documentation.
567
Access and Security
Introduction
6.3 Classifiers
6.3.1 Classifier Support on the SBx3100
The following table summarizes components and their traffic management feature availability. (“X” means supports, with
qualifiers having footnotes, blank means not supported.)
TABLE 6-1
Traffic Management Summary Table - Cards on the SBx3100
GE24P
OE
GE24
RJ
GE24S
FP
GE40C
SFP
GE40RJ
XE4
XE6
X
X
X
X
X
X
X
IPDESTa
X
X
X
X
X
X
X
IPDSCP
X
X
X
X
X
X
X
IPPROTOCOL
X
X
X
X
X
X
X
IPSOURCEa
X
X
X
X
X
X
X
LSAP
X
X
X
X
X
X
X
MACDEST
X
X
X
X
X
X
X
MACSOURCE
X
X
X
X
X
X
X
PROTOCOL
X
X
X
X
X
X
X
TCPPORTDEST
X
X
X
X
X
X
X
TCPPORTSOURCE
X
X
X
X
X
X
X
UDPPORTDEST
X
X
X
X
X
X
X
UDPPORTSOURCE
X
X
X
X
X
X
X
VID
X
X
X
X
X
X
X
VPRIORITY
X
X
X
X
X
X
X
DROP
X
X
X
X
X
X
X
FORWARD
X
X
X
X
X
X
X
COUNT
X
X
X
X
X
X
X
Classifier Match Fields
ETHFORMAT
ICMPV6TYPE
INNERVID
INNERVPRIORITY
IPTOS
TCPFLAGS
Classifier Actions
568
Access and Security
Introduction
TABLE 6-1
Traffic Management Summary Table - Cards on the SBx3100 (Continued)
Classifier Match Fields
GE24P
OE
GE24
RJ
GE24S
FP
GE40C
SFP
GE40RJ
XE4
XE6
SETVPRIORITY
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Number of Egress Queues
8
8
8
8
8
8
8
Number of Classifiersb
128
128
128
120
120
128
128
Number of Ingress Traffic Meters
192
192
192
59
59
32
32
Number of Ingress Traffic Counters
1200c
(1176)
1200d
(1176)
512(b)
(508)
118e
118f
1920(b)
(1896)
1920(b)
(1896)
Number of Out-of-profile Packet Meter Counters
192
192
192
118
118
32
32
SETIPTOS
SETIPDSCP
MOVEPRIOTOTOS
MOVETOSTOPRIO
a. Includes IPv6 values. Refer to Table 6-2.
b. Classifier capacity is an approximation. The features enabled on a port or interface, such as such as IGMP, DHCPRELAY, VLAN
(for per-VLAN UFO and HVLAN), EPSR, INTERFACE (TAGALL option for HVLAN), ACCESSLIST, and CLASSIFIER,
classifiers on surrounding ports, content of the user classifiers, and many other factors influence the number of classifiers available on a given port or interface.
c. The number of ingress traffic counters is limited by the current total number of available classifiers. The maximum possible classifiers is shown in the above table. BFD always consumes 1 classifier per external port (24 for the GE24POE and GE24SFP, and
4 for the XE4), so the maximum attainable by customer is contained in parentheses.
d. The number of ingress traffic counters is limited by the current total number of available classifiers. The maximum possible classifiers is shown in the above table. BFD always consumes 1 classifier per external port (24 for the GE24POE and GE24SFP, and
4 for the XE4), so the maximum attainable by customer is contained in parentheses.
e. The counters are twice the number of traffic meters (minus two reserved for BFD).
f. The counters are twice the number of traffic meters (minus two reserved for BFD).
Following are notes related to this table:
• Classifiers on LAGs only support filtering and remarking; not metering.
• LAGs do not support egress port rate limiting.
• Ingress Meters (TRAFFIC DESCRIPTORs) are limited to 1 per classifier. Their actions on out-of-profile packets are
NCFORWARD (the default), NCDROP, and NCCOUNT.
• All interfaces support p-bit mapping to queues.
• All interfaces support only Strict Priority, Tail-drop queuing discipline.
The following classifier match fields are not supported on the SBx3100, which affects the CREATE/SET CLASSIFIER commands:
•
•
•
•
INNERVPRIORITY
INNERVID
TCPFLAGS
IPTOS
569
Access and Security
Introduction
• ETHFORMAT
The following classifier actions are not supported on the SBx3100, which affects the ADD ACTION command:
• MOVEPRIOTOTOS
• MOVETOSTOPRIO
• SETIPTOS
The following rules apply to IPv6 packet classifiers:
• A classifier with a match rule for IPv6 source and/or destination addresses cannot also have match rules for:
• MACDEST
• MACSOURCE
• LSAP
• IPv6 match rules will not operate correctly when a packet contains IPv6 extension headers, except when a single hop-byhop extension header is used.
• A classifier with MACDEST and/or MACSOURCE match rules will not operate correctly with IPv6 packets.
6.3.2 Classifier Management
Classifiers provide the remarking, metering, counting, etc., actions for interfaces. Classifiers define packet matching rules that
classify packets into data flows so that they may be processed in a similar manner. For example, all packets with the same destination TCP/IP port may be defined to form a flow (such as Telnet or HTTP traffic).
Once packets are defined by the use of classifiers, the QoS functions associate the classifier rule and subsequent actions on
the packets.
Classifiers perform the following key functions:
• Traffic filtering - Filters traffic so that only required traffic goes on to the VLAN. Sample filters would be by protocol, IP
address and applications such as HTTP or SMTP.
• Traffic quality of service - Prioritizes frames based on their classification. For instance, voice over IP traffic could be given
a higher priority than web traffic.
6.3.2.1 Classifier Match Rules
A set of packet matching rules can be created by the user. The classifiers can identify any single packet based upon the following criteria:
• Layer 2 protocols - Ethernet encapsulation type - Packets are classified depending on the specific protocol type of each
frame. Different values indicate how the packet is formatted. For more details on values see the ETHFORMAT parameter
in the CREATE CLASSIFIER command in Table 6-2.
• Layer 3 protocols - Frames are classified based on any value for Layer 3 protocols. The system can match based on any
Layer 3 field regardless of the Layer 2 frame type (as long as it is supported).
• Source/destination IP address - Frames are classified based on an IP mask so that frames can be allowed on a partial
match.
• Layer 4 protocol (TCP/UDP, etc.) - Frames are classified based on specific Layer 4 TCP or UDP destination and source
port numbers contained within the header of an IP frame.
570
Access and Security
Introduction
Table 6-2 lists the available classifiers match rules.
TABLE 6-2
Classifiers Match Rules
Parameter
Description
ICMPV6TYPE
The ICMPV6TYPE match rule field matches any ICMPv6 protocol packet
with the specified type. Certain common types values may be specified by
name (e.g., REDIRECT).
- ROUTERADVERTISEMENT - Matches ICMPv6 type for Router Advertisement, 134 (0x86).
- MLDQUERY - Matches ICMPv6 type for Multicast Listener Query, 130
(0x82).
- MLDV1DONE - Matches ICMPv6 type for Version 1 Multicast Listener
Done, 132 (0x84).
- MLDV1REPORT - Matches ICMPv6 type for Version 1 Multicast Listener
Report, 131 (0x83).
- MLDV2REPORT - Matches ICMPv6 type for Version 2 Multicast Listener
Report, 143 (0x8f).
- REDIRECT - Matches ICMPv6 type for Redirect Message, 137 (0x89).
- icmpv6type - Matches the specified ICMPv6 type value, a decimal or hexadecimal value that is less than 256.
IPDEST={ ipaddress/length | ipv6address/
length | MULTICAST | IPV6MULTICAST |
IPV6PERMANENTMULTICAST |
IPV6TRANSIENTMULTICAST | ANY }
The destination IP address (either host or subnet) of the IP packet.
IP address ranges are specified using a valid IP address or valid subnet and
mask. A range is specified using a ‘/’ character (such as 1.0.0.0/8).
ipaddress/length - The value is specified as a subnet prefix with a mask. For
example, 192.168.1.0/24 matches 192.168.1.0 to 192.168.1.255). If no mask
is provided then /32 is assumed, which is equivalent to specifying a host
address (e.g. 192.168.1.1).
ipv6address/length - The value is specified as a prefix with a mask. For
example, 1234:5678:9012:3456::/64 matches
1234:5678:9012:3456:0000:0000:0000:0000 (1234:5678:9012:3456::) to
1234:5678:9012:3456:ffff:ffff:ffff:ffff. If no mask is provided then /128 is
assumed, which is equivalent to specifying a host address (e.g.
1234:5678:9012:3456:0000:0000:0000:0001).
MULTICAST - Matches any IPv4 multicast address, 224.0.0.0 to
239.255.255.255 inclusive.
IPV6MULTICAST - Matches any IPv6 multicast address, i.e., any IPv6
address with the prefix FF00::/8.
IPV6PERMANENTMULTICAST - Matches any IPv6 multicast address, i.e.,
any IPv6 address with the prefix ff00::/8, that has the transient flag set to 0.
This matches permanently-assigned, or “well-known,” multicast addresses.
IPV6TRANSIENTMULTICAST - Matches any IPv6 multicast address, i.e.,
any IPv6 address with the prefix ff00::/8, that has the transient flag set to 1.
This matches dynamically-assigned, or transient, multicast addresses.
ANY - The value ANY matches any IP packet.
A classifier may only have one IPDEST match rule, for an IPv4 or an IPv6
address or a multicast address variant
571
Access and Security
Introduction
TABLE 6-2
Classifiers (Continued)Match Rules
Parameter
Description
IPDSCP={0..63|ANY}
The code point field with the DiffServ byte of an IP packet. This parameter
cannot be specified with the IPTOS parameter.
ANY - match all IP packets with any IPDSCP value.
IPPROTOCOL={TCP|UDP|ICMP|IGMP|
ipprotocol-number|ANY}
The IPPROTOCOL match rule field matches on any IPv4 packet with the
specified value in the protocol field of an IPv4 packet, and any IPv6 packet
with the specified value in the next header field of an IPv6 packet. PROTOCOL=IPV4 | IPV6 can be used to limit the classifier to only IPv4 or to only
IPv6 packets, respectively. Otherwise, both IPv4 and IPv6 packets will be
matched.
ANY value may be specified by number. Certain common protocol values
may be specified by name (e.g., TCP).
TCP - Matches TCP, 0x06.
UDP - Matches UDP, 0x11.
ICMP - Matches ICMP, 0x01.
ICMPV6 - Matches ICMPv6, 0x3A.
IGMP - Matches IGMP, 0x02.
ipprotocol-number | ipv6nextheader-number - Matches the specified IP
Protocol value, a decimal or hexadecimal value that is less than 256. In an
IPv6 header, the IP Protocol value is found in the IPv6 next header field. A
single value can be specified which will be checked against the IP protocol
value of IPv4 packets and the IPv6 Next Header value of IPv6 packets.
IPSOURCE={ipaddress-mask|ANY}
The source IP address (either host or subnet) of the IP packet.
ipaddress/length - The value is specified as a subnet prefix with a mask. For
example, 192.168.1.0/24 matches 192.168.1.0 to 192.168.1.255). If no mask
is provided then /32 is assumed, which is equivalent to specifying a host
address (e.g. 192.168.1.1).
ipv6address/length - The value is specified as a prefix with a mask. For
example, 1234:5678:9012:3456::/64 matches
1234:5678:9012:3456:0000:0000:0000:0000 (1234:5678:9012:3456::) to
1234:5678:9012:3456:ffff:ffff:ffff:ffff. If no mask is provided then /128 is
assumed, which is equivalent to specifying a host address (e.g.
1234:5678:9012:3456:0000:0000:0000:0001). Refer to RF4291 [15] for IPv6
addressing syntax.
ANY - The value ANY matches any IP packet.
A classifier may only have one IPSOURCE match rule, for either an IPv4 or
an IPv6 address
LSAP={NETBIOS|lsap-value|ANY}
The LSAP match rule field matches on any packet with the specified LSAP
value.
LSAP refers to the combination of the DSAP (Destination Service Access
Point) and SSAP (Source Service Access Point) octets in an 802.3 Ethernet
frame. The value may be entered in decimal or in hex but must be less than
or equal to 4095.
The value "NETBIOS" can be used to specify the LSAP value for that protocol (0xF0F0). The value "ANY" matches any LSAP value.
572
Access and Security
Introduction
TABLE 6-2
Parameter
Description
MACDEST={macaddress|MULTICAST|ANY}
The destination MAC address for the packet. MULTICAST is for multicast
packets.
macaddress - The MAC address to match. The value must be entered as a
sequence of 6 bytes (2 hex digits each) separated by colons (e.g.,
00:0C:25:00:13:8C).
MULTICAST - Match only multicast MAC addresses.
ANY - The value ANY matches any MAC destination address.
MACSOURCE={macaddress|ANY}
The source MAC address.
macaddress - The MAC address to match. The value must be entered as a
sequence of 6 bytes (2 hex digits each) separated by colons (e.g.,
00:0C:25:00:13:8C).
ANY - The value ANY matches any MAC source address.
PROTOCOL={IPV4|IPV6|protocoltype|ANY}
The PROTOCOL match rule field matches on any packet with the specified
layer 2 "protocol" field value. The value of this field indicates which layer 3
protocol is being carried. Any value may be specified as a number (e.g.,
PROTOCOL=0x806). However, certain common protocols (e.g., IPV4,
IPV6) may be entered by name.
IPV4 - Matches IPv4 protocol, 0x0800.
IPV6 - Matches IPv6 protocol, 0x86DD.
protocol-type - Matches protocol specified by EtherType value. The value
can be in decimal or hexadecimal and must be less than 65536.
ANY - The value ANY matches any valid Ethernet frame.
TCPFLAGS =
{{URG|ACK|RST|SYN|FIN|PSH }
[ ,... ]|ANY }
This parameter is optional. The TCPFLAGS match rule field matches on
any TCP packet where the specified TCP flags are set, and any TCP flags
not specified are not set. Values are entered as a comma-separated list of
flag names.
The value ANY matches any TCP packet regardless of flag values.
URG - Urgent pointer field is significant.
ACK - Acknowledgement field is significant.
RST - Reset the connection.
SYN - Synchronize sequence numbers.
FIN - No more data from sender.
PSH - Push function.
TCPPORTDEST={tcp-port|ANY}
The TCPPORTDEST match rule field matches on any TCP packet with the
specified value in the destination port field. The value may be entered in
decimal (10) or hexadecimal (0xa) format. Multiple values (separated by
commas) can be entered. The value ANY matches any TCP packet.
TCPPORTSOURCE={tcp-port|ANY}
The TCPPORTSOURCE match rule field matches on any TCP packet with
the specified value in the source port field. The value may be entered in
decimal (10) or hexadecimal (0xa) format. The value ANY matches any
TCP packet.
573
Access and Security
Introduction
TABLE 6-2
Parameter
Description
UDPPORTDEST={udp-port-list|ANY}
The UDPPORTDEST match rule field matches on any UDP packet with the
specified value in the destination port field. The value may be entered in
decimal (10) or hexadecimal (0xa) format. Multiple values (separated by
commas) can be entered.
ANY - match all IP packets with any UDPPORTDEST value.
Note: In order to filter (block) a subscriber’s port and prevent it from acting as a DHCP client, add a filter of UDPPORTDEST=67, dropping any
packets destined for a DHCP server. To filter packets from an upstream
DHCP server to the subscriber port, add a filter of UDPPORTDEST=68.
UDPPORTSOURCE={udp-port|ANY}
The UDPPORTSOURCE match rule field matches on any UDP packet with
the specified value in the source port field. The value may be entered in
decimal (10) or hexadecimal (0xa) format.
ANY - match all IP packets with any UDPPORTSOURCE value.
VID={1..4095|ANY}
The source VLAN the packet is associated with when received by the
switch.
- ANY - match all packets with any VLANID value.
The VID match rule field matches on any packet with the specified value in
the outer VLAN identifier field. If the port's service configuration adds tags
to the packet, or translates VLAN IDs, then this comparison is to the newly
added VLAN tag, after translation.
VPRIORITY={0..7|ANY}
This matches the VLAN ID specified with the User Priority frame
- ANY - match all packets with any VPRIORITY value.
The VPRIORITY match rule field matches on any packet with the specified
value in the outer VLAN priority field. If the port's service configuration
adds tags to the packet, this comparison is to the priority field of the newly
added VLAN tag, which is always 0.
This match rule is used to set up the class of service queues. Refer to 6.7.
6.3.2.2 Classifier Actions and COUNTs
A classifier or set of classifiers then can have actions associated with them:
• DROP - discard the packet at the card. This action excludes the packet.
• FORWARD - allow traffic to be forwarded. This action includes the packet.
• COUNT - count the number of packets that have been forwarded or dropped. These are displayed with the SHOW
CLASSFIER COUNTER command.
Note:
The outputs associated with the COUNT setting are as follows: If the COUNT is combined with a DROP action,
then the Filter Count is incremented in the output. If combined with a TRAFFICDESCRIPTOR (for policing), then
the Policed Count is incremented in the output. If neither is associated, then the Match Count is incremented in
the output. To view these outputs, use the command SHOW CLASSFIER COUNTER <interface>.
• Remark the 802.1q priority field - The priority bits can be set (remarked) on ingress, and that priority is used
throughout the network devices at each egress queue. This is set using the SETVPRIORITY action.
Note:
To correlate the p-bit value with a queue, the SET QOS command is used.
574
Access and Security
Introduction
6.3.2.3 Classifier Association with an Interface (Precedence)
When a classifier is associated with an interface, it is given a precedence, with the lowest number receiving the highest precedence. Classifiers on the same port cannot share the same precedence number.
If the user wishes to further qualify a traffic flow, metering can be applied to the ingress interface before the classifier is associated with that interface.
Note:
The precedence setting for classifiers should be 51 to 68 for classifiers that perform a filtering action, with 69 used
for dropping packets that do not match any of the filtering criteria.
Note:
The precedence setting for classifiers that remark packets for the QoS function should be 146 to 199.
6.3.2.4 Example of configuring a Video Classifier
When there is no remarking of p-bits (default settings), the network is being configured so that the p-bits settings are set by
the upstream device. The user can, however, set the p-bit to a different value and place it in a different queue. For example,
multicast video traffic could be placed in a high priority by remarking the p-bit to 6 which places it in queue 7 on interfaces
supporting 8 queues and on queue 3 on interfaces supporting 4 queues. The example will show it being placed in queue 4.
The user can create the classifier as follows:
• The ports 11.0-11.3 are all upstream
• The precedence setting is 146 (within the remarking range)
• The name of the classifier is remark_mulitcast
officer SEC>> create class remark_multicast IPDEST=MULTICAST
officer SEC>> add action class remark_multicast SETVPRIORITY=4
officer SEC>> add class remark_multicast interface 11.0-11.3 precedence 146
officer SEC>> show class all
--- Classifier Configuration Data --------------------------------------------Name
Field Match(es)
Action(s)
------------------- -------------------------------------- ------------------remark_multicast
IPDEST= MULTICAST
SETVPRIORITY=4
------------------------------------------------------------------------------officer SEC>> show class all int all full
--- Classifier Configuration Data --------------------------------------------Interface Rank Name
Field Match(es)
Action(s)
--------- ---- --------------- ------------------------------ ---------------ETH:11.0 146 remark_multicast
PROTOCOL= IPV4
(D) SETVPRIORITY=4
IPVERSION= 4
(D)
IPDEST= MULTICAST
ETH:11.1 146 remark_multicast
PROTOCOL= IPV4
(D) SETVPRIORITY=4
IPVERSION= 4
(D)
IPDEST= MULTICAST
ETH:11.2 146 remark_multicast
PROTOCOL= IPV4
(D) SETVPRIORITY=4
IPVERSION= 4
(D)
IPDEST= MULTICAST
-------------------------------------------------------------------------------
Note that when configuring classifiers, the FULL display for the classifiers for an interface will also include information that
has been derived from the classifiers. This will be shown with a (D) next to the classifier attribute. Refer to the next subsection.
6.3.2.5 Derived Classifiers (D)
Note that when configuring classifiers, the FULL display for the classifiers for an interface will also include information that
has been derived from the classifiers. For example, a user has configured a classifier set as shown below.
officer SEC> SHOW CLASSIFIER=ALL INTERFACE=2.0
--- Classifier Configuration Data ------------------------------------Interface Rank Name
Field Match(es)
Action(s)
--------- ---- ---------------- --------------------------------- ----------ETH:2.0
51
ip1
IPSOURCE=1.1.1.1/32
52
ip2
IPSOURCE=1.1.1.2/32
53
ip3
IPSOURCE=1.1.1.3/32
54
ip4
IPSOURCE=1.1.1.4/32
55
ip5
IPSOURCE=1.1.1.5/32
56
ip6
IPSOURCE=1.1.1.6/32
57
ip7
IPSOURCE=1.1.1.7/32
575
Access and Security
69
ipde
Introduction
IPSOURCE=ANY
DROP
The following shows that classifiers are added by the system when they can be derived. For the IPSOURCE classifiers, the
PROTOCOL (IPV4) and IPVERSION (4) are derived from the IPSOURCE and are added with the (D) added, telling the user
these were added by the system.
officer SEC>> show class all interface=2.0 full
Field Match(es)
Action(s)
--------- ---- ------------ ---------------------------------------- --------ETH:2.0
51
ip1
PROTOCOL=IPV4
(D)
IPVERSION=4
(D)
IPSOURCE=1.1.1.1/32
52
ip2
PROTOCOL=IPV4
(D)
IPVERSION=4
(D)
IPSOURCE=1.1.1.2/32
53
ip3
PROTOCOL=IPV4
(D)
IPVERSION=4
(D)
IPSOURCE=1.1.1.3/32
54
ip4
PROTOCOL=IPV4
(D)
IPVERSION=4
(D)
IPSOURCE=1.1.1.4/32
55
ip5
PROTOCOL=IPV4
(D)
IPVERSION=4
(D)
IPSOURCE=1.1.1.5/32
56
ip6
PROTOCOL=IPV4
(D)
IPVERSION=4
(D)
IPSOURCE=1.1.1.6/32
57
ip7
PROTOCOL=IPV4
(D)
IPVERSION=4
(D)
IPSOURCE=1.1.1.7/32
69
ipde
PROTOCOL=IPV4
(D)
DROP
IPVERSION=4
(D)
IPSOURCE=ANY
-------------------------------------------------------------------------------
6.3.2.6 Set Match Rule Defaults (SETDEFAULTS)
Classifier match rule defaults can be reset using the SETDEFAULTS command. This command is useful if the user wishes to
change a match rule setting without having to delete the classifier. An example follows.
1.
Create a classifier ipfilt1, with an IPSOURCE filter.
officer SEC>> CREATE CLASSIFIER=ipfilt1 IPSOURCE=172.16.5.0/28
officer SEC>> SHOW CLASSIFIER=IPFILT1
Field Match(es)
Action(s)
------------------- -------------------------------------- ------------------ipfilt1
IPSOURCE= 172.16.5.0/28
------------------------------------------------------------------------------2.
Add an action to the classifier to drop the IPSOURCE ipaddress.
officer SEC>> ADD ACTION CLASSIFIER=ipfilt1 DROP
Field Match(es)
Action(s)
------------------- -------------------------------------- ------------------ipfilt1
IPSOURCE= 172.16.5.0/
DROP
28
------------------------------------------------------------------------------3.
Add a PROTOCOL filter on the classifier.
officer SEC>> SET CLASSIFIER=ipfilt1 PROTOCOL=IPV4
576
Access and Security
Introduction
Field Match(es)
Action(s)
------------------- -------------------------------------- ------------------ipfilt1
PROTOCOL= IPV4
DROP
IPSOURCE= 172.16.5.0/
28
------------------------------------------------------------------------------4.
Set a IPDEST filter.
officer SEC>> SET CLASSIFIER=ipfilt1 IPDEST=10.0.0.0/8
Field Match(es)
Action(s)
------------------- -------------------------------------- ------------------ipfilt1
PROTOCOL= IPV4
DROP
IPSOURCE= 172.16.5.0/
28
IPDEST= 10.0.0.0/8
------------------------------------------------------------------------------
Using the SETDEFAULTS command, set the IPDEST back to it’s default value.
officer SEC>> SETDEFAULTS CLASSIFIER=IPFILT1 IPDEST
Field Match(es)
Action(s)
------------------- -------------------------------------- ------------------ipfilt1
PROTOCOL= IPV4
DROP
IPSOURCE= 172.16.5.0/2
5.
577
Access and Security
Introduction
6.3.2.7 System Monitoring for Errors (NORES, ERR, NOSPT)
When creating classifiers, the user should consider all configuration guidelines, restrictions and limitations, some of which are
described in previous sections. The CLI provides outputs that help the user understand a classifier configuration and why a
certain command was accepted or rejected. These are explained below.
6.3.2.8 Classifier Resources Exceeded (NORES)
The system will generate a warning message informing the user if or when classifier resource capacity or capabilities have
been exceeded on the interface(s) impacted by the provisioning change. The user should investigate classifier-related provisioning, such as IGMP, DHCPRELAY, VLAN (for per-VLAN UFO and HVLAN), EPSR, INTERFACE (TAGALL option for
HVLAN), ACCESSLIST, and CLASSIFIER to determine the reason for the message.
Note:
When resources are exceeded on the interface(s), all user-created classifiers are set on the interface(s) to NORES.
(Internal-created classifiers persist.)
Exceeding classifier resources raises a NORES alarm (Classifier Resource Failed). An example of setting the NORES
alarm is illustrated below.
officer SEC>> CREATE CLASSIFIER IPDROP protocol=ipv4
officer SEC>> ADD ACTION CLASSIFIER IPDROP DROP
officer SEC>> ADD ACTION CLASSIFIER IPDROP COUNT
officer SEC>> CREATE CLASSIFIER IPS1 IPSOURCE=10.10.10.1
// Classifiers IPS2 through IPS13 are also created with IPSOURCE as 10.10.10.2, 10.10.10.3,
etc.
// User now adds classifiers to an interface
officer SEC>> ADD CLASS IPS1 INTERFACE 3.4 PRECEDENCE 51
// etc.
// After adding classifiers IPS1 through IPS12 to interface 3.4, user now adds Classifier
IPS13, and receives // the message that classifier resources are exceeded
578
Access and Security
Introduction
officer SEC>>
Classifier resources exceeded on the following interfaces:
ETH:[3.4]
officer SEC>> show class all int 3.4 full
Field Match(es)
--------- ---- ------------ ---------------------------------------ETH:3.4
51
ips1 (NORES)
IPSOURCE=10.10.10.1/32
52
ips2 (NORES)
IPSOURCE=10.10.10.2/32
53
ips3 (NORES)
IPSOURCE=10.10.10.3/32
54
ips4 (NORES)
IPSOURCE=10.10.10.4/32
55
ips5 (NORES)
IPSOURCE=10.10.10.5/32
56
ips6 (NORES)
IPSOURCE=10.10.10.6/32
57
ips7 (NORES)
IPSOURCE=10.10.10.7/32
58
ips8 (NORES)
IPSOURCE=10.10.10.8/32
59
ips9 (NORES)
IPSOURCE=10.10.10.9/32
60
ips10
IPSOURCE=10.10.10.10/32
(NORES)
61
ips11
IPSOURCE=10.10.10.11/32
(NORES)
62
ips12
IPSOURCE=10.10.10.12/32
(NORES)
63
ips13
IPSOURCE=10.10.10.13/32
(NORES)
68
ipdrop
PROTOCOL=IPV4
(NORES)
Action(s)
---------
DROP
COUNT
------------------------------------------------------------------------------officer SEC>> show alarm card 3
Fault
Severity
------------ -------------------------------- -------3.4
Classifier Resource Failed
Minor
Time Stamp
-------------03:17:56 08/04
6.3.2.9 Error (ERR)
This error would occur in the instance of a software error. This would be different from a NOSPT or NORES.
In the example below, the user has added three classifiers to a port and attempts to add a fourth. An error appears saying the
card cannot accept the fourth classifier because the number of masks supported by the card has been exceeded. As a result,
when the user displays the classifiers for the port a No Resources error appears next to the classifier. The user can delete
the fourth classifier and the (ERR) is removed from the display.
579
Access and Security
Introduction
officer SEC> ADD CLASSIFIER=ip1 PORT=11.0 PRECEDENCE=51
P
officer SEC> ADD CLASSIFIER=ip2 PORT=11.0 PRECEDENCE= 52
officer SEC> SHOW CLASSIFIER=ALL PORT=11.0
--- Classifier Configuration Data --------------------------------------------Port Rank Name
Field Match(es)
Action(s)
---- ---- ---------------- --------------------------------- ----------------11.0 51
ip1 (ERR)
IPSOURCE=1.1.1.1/1
52
ip2 (ERR)
IPSOURCE=1.1.1.1/2
53
ip3 (ERR)
IPSOURCE=1.1.1.1/3
54
ip4 (ERR)
IPSOURCE=1.1.1.1/4
145 telesyn_default_ IPDEST=MULTICAST
SETVPRIORITY=1
video (ERR)
------------------------------------------------------------------------------officer SEC> DELETE CLASSIFIER=ip4 PORT=11.0
Delete classifier(s) from port(s) (Y/N)? y
Field Match(es)
Action(s)
---- ---- ---------------- --------------------------------- ----------------11.0 51
ip1
IPSOURCE=1.1.1.1/1
52
ip2
IPSOURCE=1.1.1.1/2
53
ip3
IPSOURCE=1.1.1.1/3
SETVPRIORITY=1
video
6.3.2.10 No Support (NOSPT)
An example of when this error will be raised is when classifiers are configured on a port and the software for the card where
the port resides is downgraded to a release that doesn’t support classifiers. The system will generate a NOSPT error.
In the example below, the user has created a classifier with an IP source and has associated this with a VPRIORITY. The system allows this, but when the user tries to associate the classifier with a port, a message is output stating that p-bit marking
is only supported for IP multicast in a certain range. The command is accepted, but when the user lists the classifiers for that
port, No Support (NOSPT) is displayed next to the classifier, meaning the classifier will not be used.
Field Match(es)
Action(s)
---- ---- ---------------- --------------------------------- ----------------11.0 51
ip1
IPSOURCE=1.1.1.1/1
52
ip2
IPSOURCE=1.1.1.1/2
580
Access and Security
53
145
ip3
IPSOURCE=1.1.1.1/3
telesyn_default_ IPDEST=MULTICAST
video
Introduction
SETVPRIORITY=1
officer SEC> CREATE CLASS=badclass ips=3.3.3.3
officer SEC> ADD ACTION CLASSIFIER=badclass SETVPRIORITY=2
officer SEC> ADD CLASSIFIER=badclass PORT=11.0 PRECEDENCE=146
Field Match(es)
Action(s)
---- ---- ---------------- --------------------------------- ----------------11.0 51
ip1
IPSOURCE=1.1.1.1/1
52
ip2
IPSOURCE=1.1.1.1/2
53
ip3
IPSOURCE=1.1.1.1/3
SETVPRIORITY=1
video
146 badclass (NOSPT) IPSOURCE=3.3.3.3/32
SETVPRIORITY=2
Another scenario is when a combination of classifiers and specific values for match fields is not allowed. For example, if the
user installs a classifier that tries to match the LSAP field to a value other than NETBIOS and SNAP (refer to Table 6-2), then
the NOSPT error code appears.
6.3.3 Configuring Classifiers
When the SBx3100 is first installed and in service, there are no user-defined classifiers configured.
For the XE4, filtering on the DHCP packets can occur if the filter has only layer 2 fields in the match rules. So, for example,
if the user creates a classifier to block all traffic on VID=1, then DHCP requests on VID 1 are blocked. However, if rules are
created to allow certain IP addresses through, and all other IP addresses are blocked, the DHCP packets can still get through
because those layer 3 filters are not applied. This is done so that the customer can get a valid IP address via DHCP.
The general sequence to configure classifiers is to:
• Create the classifiers with a descriptive name and match rule.
• Associate actions to the classifiers, using COUNT as well when appropriate.
• Associate the classifiers to interfaces, including a PRECEDENCE, with the lower number receiving the higher precedence.
The general sequence to deprovision a classifier is to:
581
Access and Security
Introduction
• DELETE the classifier from the associated interfaces.
• DESTROY the classifier
In the following procedure, the user wishes to only allow traffic originated from a range of IP addresses, and to drop any
other packets.
TABLE 6-3
Step
Configuration procedure for Classifiers
Command
Create the classifiers and the allowed IP source (/ is for the mask)
1
CREATE CLASSIFIER=ipfilt1 IPSOURCE=192.168.1.0/24
CREATE CLASSIFIER=ipdrop IPSOURCE=ANY
Associate the classifiers with actions, with a COUNT for dropped packets
2
ADD ACTION CLASSIFIER=ipfilt1 FORWARD
ADD ACTION CLASSIFIER=ipfilt2 FORWARD
ADD ACTION CLASSIFIER=ipdrop DROP
ADD ACTION CLASSIFIER=ipdrop COUNT
SHOW CLASSIFIER=ALL
--- Classifier Configuration Data ------------------------------Name
Field Match(es)
Action(s)
------------ ---------------------------------------- ---------ipdrop
IPSOURCE=ANY
DROP
COUNT
ipfilt1
IPSOURCE=192.168.1.0/24
FORWARD
ipfilt2
IPSOURCE=10.0.0.0/24
FORWARD
Associate the classifiers to interfaces
3
ADD CLASSIFIER=ipfilt1 INTERFACE=3.0 PRECEDENCE=51
ADD CLASSIFIER=ipfilt2 INTERFACE=3.0 PRECEDENCE=52
ADD CLASSIFIER=ipdrop INTERFACE=3.0 PRECEDENCE=69
SHOW CLASSIFIER INTERFACE=3.0
--- Classifier Configuration Data ---------------------------------Interface
Rank
Name
Field Match(es)
----------- ------ ------------ -----------------------ETH:3.0.0
51
ipfilt1
IPSOURCE=192.168.1.0/24
52
ipfilt2
IPSOURCE=10.0.0.0/24
69
ipdrop
IPSOURCE=ANY
Action(s)
---------FORWARD
FORWARD
DROP
COUNT
Deprovision the CLASSIFIER
DELETE the INTERFACE(s) from the classifier from interface or set of interfaces, then DESTROY the classifier.
4
DELETE CLASSIFIER=ipfilt1,ipfilt2,ipdrop INTERFACE=3.0
Delete classifier(s) from interface(s) (Y/N)? y
Info (010017): Operation Successful$
5
Destroy CLASSIFIER=ipfilt1,ipfilt2,ipdrop
Destroy classifier(s) (Y/N)? y
582
Access and Security
Introduction
6.3.4 Classifier Commands
Table 6-4 lists the commands that are used for Classifiers.
TABLE 6-4
Classifier Commands
Commands
ADD ACTION CLASSIFIER
ADD CLASSIFIER INTERFACE PRECEDENCE
CREATE CLASSIFIER
DELETE ACTION CLASSIFIER
DELETE CLASSIFIER INTERFACE
DESTROY CLASSIFIER
RESET CLASSIFIER
RESET CLASSIFIER COUNTER INTERFACE
SET CLASSFIER
SETDEFAULTS CLASSIFIER
SHOW CLASSFIER COUNTER
SHOW CLASSIFIER
583
Access and Security
Introduction
ADD ACTION CLASSIFIER
Syntax
ADD ACTION CLASSIFIER=classifiername-list
{ DROP | FORWARD | COUNT | SETVPRIORITY=0..7 | SETIPTOS=0..7 |
SETIPDSCP=0..63 |
SETQUEUE=0..7 |
SETBANDWIDTHCLASS={ GREEN | YELLOW | RED } |
MOVEPRIOTOTOS | MOVETOSTOPRIO }
Description
Adds an ACTION to one or more CLASSIFIERs. As a result, when the CLASSIFIER is added to a port,
the specified ACTION is performed on an incoming packet if the packet conforms to the CLASSIFIER's match rules, unless the ACTION conflicts with an ACTION on a matching CLASSIFIER with
higher precedence. This command cannot add an ACTION that conflicts with an ACTION already on
the CLASSIFIER.
To use SETIPDSCP, either SETVPRIORITY or SETQUEUE must be specified. In either case SETBANDWIDTHCLASS will also be used, using either the configured value or the default setting (GREEN). If
both are used, SETVPRIORITY remarks the 802.1p class of services bits in the outgoing packet and
SETQUEUE determines the egress queue to be used. If only SETVPRIORITY is specified, then the
802.1p remarking is determined by SETVPRIORITY and the egress queue is determined by SETVPRIORITY in conjunction with the VLANQUEUEMAP (system-wide).
Note that these actions for settting DSCP over-ride that settings in the IPDSCP table.
Note that if any classifier already has metering (TRAFFICDESCRIPTOR), the command is blocked.
Refer to 6.5.
Mode
Manager
Options
Option
Description
Range
Default
Value
CLASSIFIER
Associate an action with a classifier or set of classifiers.
Each classifier is separated with a comma.
NA
NA
DROP
DROP - Discard the packet. The DROP ACTION conflicts with all ACTIONs except COUNT
NA
NA
COUNT
On a CLASSIFIER match, increment a per-port counter.
The rules for which counter to increment vary slightly
depending on hardware platform.
NA
NA
If combined with a DROP action, this action increments
the "Filter Count". If combined with actions that do not
include DROP, this action increments the "Match
Count" counter.
Note that on the 9x00 series platform both the "Match
Count" and the "Filter Count" can be incremented by a
single packet that matches both the FORWARD and
DROP classifier. On other platforms only the count
with the higher precedence is incremented.
Current COUNTs are displayed via SHOW CLASSIFIER PORT port-list COUNTER
584
Access and Security
Introduction
Option
Description
Range
Default
Value
SETVPRIORITY
Sets the 802.1p bits to the specified value. This value will
impact selection of the egress CoS queue. This action
conflicts with the MOVETOSTOPRIO ACTION,
because it modifies the same location in the packet.
Refer to the Description for how this works for DSCP
processing.
NA
NA
SETIPTOS
Sets the IP TOS field. On a CLASSIFIER match, set the
IP TOS field to a specified value. This action conflicts
with the SETIPDSCP and MOVEPRIOTOTOS
ACTIONs, because they both modify the same location
in the IP packet. This action requires that one or more
of the match rules on the classifier qualifies the packet
as an IP packet.
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
Also implies a FORWARD ACTION, and so it conflicts
with the DROP ACTION.
SETIPDSCP=0..63
On a CLASSIFIER match, set the IP DSCP field to a
specified value. This action conflicts with the SETIPTOS
and MOVEPRIOTOTOS ACTIONs, because they both
modify the same location in the IP packet. This action
requires that one or more of the match rules on the
classifier qualifies the packet as an IP packet.
SETQUEUE=0..7
This parameter is optional. On a CLASSIFIER match,
determine the egress queue from the specified value.
This action overrides the egress queue that would be
used otherwise based on the 802.1p priority bits.
Also implies a FORWARD ACTION and so it conflicts
SETBANDWIDTHCLASS={
GREEN | YELLOW | RED }
This parameter is optional. On a CLASSIFIER match, set
the bandwidth class (drop precedence) to specified
value.
MOVEPRIOTOTOS
On a CLASSIFIER match, copy the IP TOS field to the
outer VLAN priority field. This action conflicts with the
SETVLANPRIORITY ACTION, because they both modify the same field in the packet. Also implies a FORWARD ACTION, and so it conflicts with the DROP
ACTION. - TBS - Supported?
This action requires that one or more of the match
rules on the classifier qualifies the packet as an IP
packet.
585
Access and Security
Introduction
Option
Description
Range
Default
Value
MOVETOSTOPRIO
This parameter is optional. On a CLASSIFIER match,
copy the outer VLAN priority field to the IP TOS field.
NA
NA
This action conflicts with the SETIPTOS and SETIPDSCP
ACTIONs, because they both modify the same location
in the IP packet. This action also implies a FORWARD
ACTION, and so it conflicts with the DROP ACTION.
This action requires that one or more of the match
rules on the classifier qualifies the packet as an IP
packet.
Example
ADD ACTION CLASSIFIER=ipfilt1 DROP
586
Access and Security
Introduction
ADD CLASSIFIER INTERFACE PRECEDENCE
Syntax
ADD CLASSIFIER=classifiername INTERFACE={ type:id-range | id-range | ifnamelist | ALL } PRECEDENCE=1..255
Description
Adds a CLASSIFIER to one or more Interfaces. As a result, the CLASSIFIER is applied to every packet
received on the Interface. This command attempts to add every specified combination of CLASSIFIER
and INTERFACE, and returns an error message for any combinations that cannot be added (e.g. due to
conflicting PRECEDENCE, duplicate CLASSIFIERs, INTERFACEs that do not exist).
Because classifiers are a limited resource, there are constraints on the number of classifiers, and combinations of classifiers, that can be supported on a given interface. If these limits are exceeded, then an
alarm is raised on the interface and operational classifier behavior may differ from the classifier configuration. The SHOW CLASSIFIER command shows details about errors loading the classifier configuration to a given port.
Mode
Manager
Options
Option
Description
Range
Default
Value
CLASSIFIER
The name of the classifier.
NA
NA
INTERFACE
The interface where the classifier is being added.
NA
NA
PRECEDENCE=1..2
55
The value of the PRECEDENCE parameter indicates
whether actions from this CLASSIFIER are performed
when other matching CLASSIFIERS have actions that
conflict with the actions on this CLASSIFIER. In this
case, actions from the CLASSIFIER with the higher PRECEDENCE (smaller numeric value) are performed,
along with any actions from other matching CLASSIFIERs that do not conflict with those actions.
1.255
CLASSIFIERS for filtering should use PRECEDENCE values between 51 and 69. CLASSIFIERS for setting fields in
the packets should use PRECEDENCE values between
146 and 199.
Some PRECEDENCE values are reserved for internal
use (e.g., for IGMP snooping): 1, 2, 3, 4, 11, 12, 13, 14,
20, 25, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131,
132, 133, 134, 135, 140, 230, 231, 232, 233, 234, 235
Example
ADD CLASSIFIER=ipdrop INTERFACE=3.0 PRECEDENCE=69
587
Access and Security
Introduction
CREATE CLASSIFIER
Syntax
CREATE CLASSIFIER=classifiername
[ VID={ 1..4095 | ANY } ]
[ VPRIORITY={ 0..7 | ANY } ]
[ INNERVID={ 1..4095 | ANY } ]
[ INNERVPRIORITY={ 0..7 | ANY } ]
[ ETHFORMAT={ 802.3 | 802.3TAGGED | 802.3UNTAGGED | ETHII | ETHIITAGGED |
ETHIIUNTAGGED | ANY } ]
[ LSAP={ NETBIOS | lsap-value | ANY } ]
[ ICMPV6TYPE={ ROUTERADVERTISEMENT | MLDQUERY | MLDV1DONE | MLDV1REPORT |
MLDV2REPORT | REDIRECT | icmpv6type } ]
[ IPDEST={ ipaddress/length | ipv6address/length | MULTICAST | IPV6MULTICAST
| IPV6PERMANENTMULTICAST | IPV6TRANSIENTMULTICAST | ANY } ]
[ IPSOURCE={ ipaddress/length | ipv6address/length | ANY } ]
[ IPDSCP={ 0..63 | ANY } ]
[ IPPROTOCOL={ TCP | UDP | ICMP | ICMPV6 | IGMP | ipprotocol-number |
ipv6nextheader-number | ANY } ]
[ IPTOS={ 0..7 | ANY } ]
[ MACDEST={ macaddress | MULTICAST | ANY }] MACSOURCE={ macaddress | ANY } ]
[ PROTOCOL={ IPV4 | IPV6 | protocol-type | ANY } ]
[ TCPPORTDEST={ tcp-port-list | ANY } ] [ TCPPORTSOURCE={ tcp-port | ANY } ]
[ TCPFLAGS={ { URG | ACK | RST | SYN | FIN | PSH } [ ,... ] | ANY } ]
[ UDPPORTDEST={ udp-port-list | ANY } ] [ UDPPORTSOURCE={ udp-port | ANY } ]
Syntax
Creates a CLASSIFIER. A CLASSIFIER supports performing certain actions to
certain received packets. A CLASSIFIER has a match rule, which is A CLASSIFIER
may be associated with many ports. CLASSIFIERs are associated to ports using
the ADD CLASSIFIER command.
A default CLASSIFIER (i.e., one created by CREATE CLASSIFIER with no match fields) always matches
all packets. If a CLASSIFIER has no match actions, then the default action is to FORWARD.
Mode
Manager
Options
Option
Description
Range
Default
Value
CLASSIFIER
The unique name for the classifier.
NA
NA
Match_rules
A set of fieldname/fieldvalue pairs that discriminate
among packets. A packet matches this rule only if all of
the specified fields have the values specified. The match
rule is specified by CREATE CLASSIFIER and SET CLASSIFIER commands. Refer to Table 6-2
NA
Classifier
matches all
packets,
default
action is to
FORWARD
Classifiers are associated with:
- Zero or more match actions, which are performed if
the incoming packet matches the CLASSIFIER's match
rule. A CLASSIFIER's actions are managed via ADD
ACTION and DELETE ACTION commands.
- Zero or one traffic descriptors, which specify a profile
(traffic rate and burst size) for packets that match the
CLASSIFIER's match rule. A CLASSIFIER's association to
a traffic descriptor is managed via the ADD TRAFFICDESCRIPTOR and DELETE TRAFFICDESCRIPTOR
commands.
588
Access and Security
Example
Introduction
589
Access and Security
Introduction
DELETE ACTION CLASSIFIER
Syntax
Description
DELETE ACTION CLASSIFIER=classifiername-list
{ DROP | FORWARD | COUNT | SETVPRIORITY | SETIPTOS | SETIPDSCP |
SETBANDWIDTHCLASS | MOVEPRIOTOTOS | MOVETOSTOPRIO }
SETQUEUE |
Deletes one ACTION or ALL ACTIONs from one or more CLASSIFIERs. This is the opposite of
ADD ACTION CLASSIFIER. If choosing an action over multiple classifiers, all classifiers must have that
same action.
To delete SETIPDSCP, either SETVPRIORITY or SETQUEUE (or both) must have been specified when
the action was added, and so these must be deleted as well.
Mode
Manager
Product
Options
Option
Description
Range
Default
Value
CLASSIFIER
Associate an action with a classifier or set of classifiers.
Each classifier is separated with a comma.
NA
NA
ACTION
Refer to ADD ACTION CLASSIFIER.
NA
NA
Note
For the SBx3100, The DELETE ACTION CLASSIFIER command may fail with the error, “Reason:
Hardware marking resources exceeded.” This occurs when the removal of the remarking action leaves
a unique combination of remarking actions that requires the allocation of a hardware marking resource
when none are available. Refer to Hardware Resources.
Example
DELETE ACTION CLASSIFIER=ipfilt1 DROP
590
Access and Security
Introduction
DELETE CLASSIFIER INTERFACE
Syntax
DELETE CLASSIFIER=classifiername-list INTERFACE={ type:id-range | id-range |
ifname-list | ALL } [ FORCE ]
Description
Deletes one or more CLASSIFIERs from one or more INTERFACE(s). This command causes the specified CLASSIFIER(s), and their actions, to no longer affect traffic on the specified INTERFACE(s). This
command deletes every combination of specified CLASSIFIER(s) and INTERFACE(s) that actually
exists. Note that the classifier is not deleted, only the interface associations.
Mode
Manager
Options
Option
Description
Range
Default
Value
CLASSIFIER
The name of the classifier(s), separated by a comma
NA
NA
INTERFACE
ALL - Deletes all the specified interface(s) and classifier(s) association.
NA
NA
FORCE
Executes the command without a confirmation.
NA
NA
Release Note
NA
Example
DELETE CLASSIFIER=ipfilt1,ipfilt2,ipdrop INTERFACE=3.0
591
Access and Security
Introduction
DESTROY CLASSIFIER
Syntax
DESTROY CLASSIFIER={classifiername-list|ALL} [ FORCE ]
Description
Attempts to remove every specified CLASSIFIER from the system, and returns an error message for
any that cannot be destroyed. This command is allowed only if no interfaces are currently associated
with the CLASSIFIER(s). Use "DELETE CLASSIFIER=classifiername-list INTERFACE=ALL" to delete all
interface associations for the classifiers in one command.
Mode
Manager
Options
Option
Description
Range
Default
Value
CLASSIFIER
The name of the classifier(s), separated by a comma
NA
NA
NA
NA
ALL - delete all interface associations for the classi-
fiers in one command.
FORCE
Release Note
Executes the command without a confirmation.
NA
Example
DESTROY CLASSIFIER class1
Destroy classifier(s) (Y/N)? Y
DESTROY CLASSIFIER class2 FORCE
592
Access and Security
Introduction
RESET CLASSIFIER
Syntax
RESET CLASSIFIER=classifiername [FORCE]
Description
The RESET CLASSIFIER command clears all of the match rules from the CLASSIFIER, resulting in a
classifier that always matches all packets. This command does not remove association of the CLASSIFIER to ACTION(s) or PORT(s). Use DELETE ACTION CLASSIFIER or DELETE CLASSIFIER PORT
for those types of changes.
Mode
Manager
Options
Release Note
Option
Description
CLASSIFIER
The classifier where all match rules are being cleared.
FORCE
Resets the classifier without confirmation
Default Value
NA
RESET CLASSIFIER=ip_32
593
Access and Security
Introduction
RESET CLASSIFIER COUNTER INTERFACE
Syntax
RESET CLASSIFIER COUNTER
INTERFACE={type:id-range|id-range|ifname-list|ALL} [FORCE]
Description
Resets (sets to 0) all CLASSIFIER counters associated with the specified INTERFACE(s). There are
three pre-defined CLASSIFIER counters for each INTERFACE, as described in SHOW CLASSFIER
COUNTER.
You may not specify a CLASSIFIER name. There is no means to clear counters associated with a subset
of CLASSIFIERS on an interface.
Mode
Manager
Options
Example
Option
Description
Range
Default
Value
INTERFACE
The interface where the counters are reset. Specify
“ALL” to add the classifier to all interfaces
NA
NA
FORCE
Resets the classifier without confirmation
NA
NA
RESET CLASSIFIER COUNTER INTERFACE=1.23 FORCE
594
Access and Security
Introduction
SET CLASSFIER
Syntax
SET CLASSIFIER=classifiername-list
[ VID={ 1..4095 | ANY } ]
[ VPRIORITY={ 0..7 | ANY } ]
[ INNERVID={ 1..4095 | ANY } ]
[ INNERVPRIORITY={ 0..7 | ANY } ]
[ ETHFORMAT={ 802.3 | 802.3TAGGED | 802.3UNTAGGED | ETHII | ETHIITAGGED |
ETHIIUNTAGGED | ANY } ]
[ LSAP={ NETBIOS | lsap-value | ANY } ]
[ ICMPV6TYPE={ ROUTERADVERTISEMENT | MLDQUERY | MLDV1DONE | MLDV1REPORT |
MLDV2REPORT | REDIRECT | icmpv6type } ]
[ IPDEST={ ipaddress/length | ipv6address/length | MULTICAST | IPV6MULTICAST
| IPV6PERMANENTMULTICAST | IPV6TRANSIENTMULTICAST | ANY } ]
[ IPSOURCE={ ipaddress/length | ipv6address/length | ANY } ]
[ IPDSCP={ 0..63 | ANY } ]
[ IPPROTOCOL={ TCP | UDP | ICMP | ICMPV6 | IGMP | ipprotocol-number |
ipv6nextheader-number | ANY } ]
[ IPTOS={ 0..7 | ANY } ]
[ MACDEST={ macaddress | MULTICAST | ANY }] MACSOURCE={ macaddress | ANY } ]
[ PROTOCOL={ IPV4 | IPV6 | protocol-type | ANY } ]
[ TCPPORTDEST={ tcp-port-list | ANY } ] [ TCPPORTSOURCE={ tcp-port | ANY } ]
[ TCPFLAGS={ { URG | ACK | RST | SYN | FIN | PSH } [ ,... ] | ANY } ]
[ UDPPORTDEST={ udp-port-list | ANY } ] [ UDPPORTSOURCE={ udp-port | ANY } ]
Syntax
Sets the match rule for the specified CLASSIFIER(s). The match rule specified
in this command replaces any existing match rule on the CLASSIFIER(s). Refer
to the options table (Table 6-2).
Mode
Manager
Options
Example
Option
Description
Range
Default
Value
CLASSFIER
The already created CLASSFIER(s), separated by a
comma.
NA
NA
SET CLASSIFIER=ipfilt2 IPSOURCE=ANY
595
Access and Security
Introduction
SETDEFAULTS CLASSIFIER
Syntax
SETDEFAULTS CLASSIFIER=classifiername [ VID ] [ VPRIORITY ] [ INNERVID ]
[ INNERVPRIORITY ] [ ETHFORMAT ] [ LSAP ] [ ICMPV6TYPE ]
[ IPDEST ] [ IPSOURCE ] [ IPDSCP ] [ IPPROTOCOL ] [ IPTOS ] [ MACDEST ]
[ MACSOURCE ] [ PROTOCOL ] [ TCPPORTDEST ] [ TCPPORTSOURCE ] [ TCPFLAGS ]
[ UDPPORTDEST ] [ UDPPORTSOURCE ]
Description
Clears the specified user defined match rule (or rules) from the CLASSIFIER. The previous user
defined match rule match rule may still exist on the CLASSIFIER as a derived rule if it is required by
any of the remaining match rules. For example, if the match rules TCPPORTDEST=45 and IPPROTOCOL= TCP exist on a classifier then clearing IPPROTOCOL will result in that rule being removed as a
user defined rule and added back as a derived rule. This command does not remove association of the
CLASSIFIER to ACTION(s) or INTERFACE(s).
Mode
Manager
Options
Option
Description
Range
Default
Value
TRAFFICDESCRIPTOR
The name(s) of the already created TRAFFICDESCRIPTOR(s), separated by a comma.
NA
NA
Release Note
Changed - In Release 17.0, the option ICMPV6TYPE is added.
Note
This command does not remove association of the CLASSIFIER to ACTION(s) or INTERFACE(s). Use
DELETE ACTION CLASSIFIER or DELETE CLASSIFIER INTERFACE for those types of changes.
Example
SETDEFAULTS CLASSIFIER=ipfilter3
596
Access and Security
Introduction
SHOW CLASSFIER COUNTER
Syntax
SHOW CLASSIFIER COUNTER [ { INTERFACE={ type:id-range | id-range | ifnamelist | ALL } } ]
Description
Shows the classification counters for the specified interface(s). Each interface has three classification
counters:
Mode
•
Filter Count" - counts packets dropped because of classifiers with both the DROP and COUNT
actions.
•
Match Count" - counts packets that match a classifier with the COUNT action but no DROP
action.
•
Policed Count" - counts packets dropped because they exceed a TRAFFICDESCRIPTOR when
the NCCOUNT action is ON.
Manager
Options
Example
Option
Description
Range
Default
Value
INTERFACE
Interfaces included for showing the classification counters.
NA
NA
SHOW CLASSIFIER count_ip
Field Match(es)
Action(s)
------------ ---------------------------------------- -----------------------count_ip
IPPROTOCOL=ANY
COUNT
------------------------------------------------------------------------------officer SEC>> SHOW CLASSIFIER count_ip INTERFACE ALL
Field Match(es)
Action(s)
--------- ---- ------------ ---------------------------------------- --------ETH:0.1
100 count_ip
IPPROTOCOL=ANY
COUNT
------------------------------------------------------------------------------officer SEC>> SHOW CLASSIFIER COUNTER
--- Classifier Port
Port/Interface
-----------------ETH:0.1
Counters -------------------------------------------------Match Count
Filter Count
Policed Count
------------------- -------------------- -----------------17
0
0
597
Access and Security
Introduction
SHOW CLASSIFIER
Syntax
SHOW CLASSIFIER={ classifiername-list | ALL }
[ { INTERFACE={ type:id-range | id-range | ifname-list | ALL } } ]
[ { SUMMARY | FULL } ]
Description
There are two minor variations of this command: one that shows only CLASSIFIER data (independent
of associations to INTERFACEs), and one that shows CLASSIFIERs in the context of their associations
to INTERFACEs. The command displays the CLASSIFIER name, match rules, and actions. The second
case shows only CLASSIFIERs associated with the specified INTERFACE(s). It shows the relative precedence of each CLASSSIFIER on that INTERFACE. It also identifies any classifiers that were not able
to be applied to the INTERFACE's hardware, resulting in classifier configuration alarms.
The SUMMARY option shows only CLASSIFIERs that can be managed by the user. The SUMMARY display option is the default.
The FULL option shows two additional types of information not shown by the SUMMARY option:
Mode
•
"internal" classifiers, which are added by the system to enable other features (e.g. IGMP snooping),
and
•
"derived" match rules, which match fields implied but not explicitly specified by higher protocol
match rules (e.g., rules added to match only IPv4 packets if IPDSCP match rule is specified).
User
Options
Option
Description
Range
Default
Value
CLASSFIERCLASSFIER
The already created CLASSFIER(s), separated by a
comma
NA
NA
INTERFACE
The interface
NA
NA
SUMMARY
Shows only CLASSIFIERs that can be managed by the
user.
NA
SUMMARY
FULL
Shows two additional types of information not shown
by the SUMMARY option:
NA
NA
- "internal" classifiers, which are added by the system to
enable other features (e.g. IGMP snooping)
- "derived" match rules, which match fields implied but
not explicitly specified by higher protocol match rules
(e.g. rules added to match only IPv4 packets if IPDSCP
match rule is specified).
Example
SHOW CLASSIFIER
Field Match(es)
Action(s)
------------ ---------------------------------------- -----------------------drop_vid10
VID=10
DROP
-------------------------------------------------------------------------------
598
Access and Security
Introduction
officer SEC>> SHOW CLASSIFIER FULL
Field Match(es)
Action(s)
------------ ---------------------------------------- -----------------------_dhcpRelay_a
UDPPORTDEST=67
LIMIT_FWD_CPU
gent
UDPPORTSOURCE=67
IPPROTOCOL=UDP
(D)
_dhcpRelay_s
UDPPORTDEST=67
LIMIT_FWD_CPU
ub
UDPPORTSOURCE=68
IPPROTOCOL=UDP
(D)
drop_vid10
VID=10
DROP
------------------------------------------------------------------------------officer SEC>> SHOW CLASSIFIER INTERFACE 0.0
Field Match(es)
Action(s)
--------- ---- ------------ ---------------------------------------- --------ETH:0.0
150 drop_vid10
VID=10
DROP
-------------------------------------------------------------------------------
599
Access and Security
Introduction
6.4 Access Control List
Access Control Lists (ACLs) provide traffic filtering functionality. They are shortcuts for creating classifiers. Unlike classifiers,
ACLs are a more easily understood syntax and a more common method for applying filters.
Note:
The CLASSIFIER commands support additional match fields and actions. Refer to Section 6.3.
ACLs give the user the ability to define traffic types by protocol (in English words) without the need to know the exact IP/
TCP/UDP characteristics of the protocol specified.
An ACL is composed of a set of rules, each rule specifies a traffic stream to be permitted (PERMIT) or denied (DENY) to
transit the switch port. By default, the system adds a DENY rule as the last one in the set of rules. (This default can be
changed to PERMIT.)
6.4.1 Provisioning Overview
Provisioning allows one access list per port or interface. It can be applied to the ingress traffic on the specified interface.
In addition to the line card physical interfaces, the user can apply an access list to control traffic associated with the management interface (MGMT and inband) destined to the CFC’s CPU. The management interface refers to either the physical
Ethernet port on the control module faceplate (MGMT) or the virtual management port accessed through in-band traffic
paths.
Following are the general provisioning rules:
• An access list can be created and provisioned by the user as a standalone configuration.
• The access list is managed by name.
• Rules may be added, modified or deleted at any time. The order of rules in an access list convey an evaluation priority.
Earlier rules (those that have lower Rule numbers) that may overlap with rules that occur later in the list (that have higher
numbers) will be given priority if the actions on the two rules conflict.
• The user can apply the access list to an interface or a set of interfaces. The system will reject a user’s request if an attribute of the access list is not compatible with interface’s capabilities.
The following lists the packet attributes and protocols that can be provisioned in an ACL. These attributes may be combined
to form an expression to compare against the attributes of a packet as it enters an interface.
•
•
•
•
•
•
•
Note:
Ethernet MAC source and/or destination address.
Layer 2 protocol type field.
IP source and/or destination address with a subnet mask.
IP protocol type field.
UDP source and/or destination port numbers.
TCP source and/or destination port numbers.
APPLICATION abstract rule types that provide a predefined set of rules such as a rule to permit or deny NETBIOS,
DHCP and subscriber multicast traffic (FUM). These rule attributes are expanded by the internal traffic management
system into one or more classifiers.
Application ACLs (for example NETBIOS ACL) do not cover protocols running over IPX.
6.4.2 ACL for the SBx3100
ACLs will also be qualified by the SBx3100 as follows:
• Conflicting match fields on a single rule will be rejected.
600
Access and Security
Introduction
• Internally, there are some automatic match qualifications that are derived. For example, if the user configures an
access list with a TCP source port rule, the system will automatically add match qualifiers for the layer 2 protocol field
to be IPv4, and the IP protocol field to be TCP.
The SB x3112 supports up to 96 rules per ACL (+ 1 default deny rule), while the iMAP supports up to 35 rules per ACL.
On a card basis:
• XE4 - can hold a full access list of 96 rules on all 4 ports
• GE24POE - up to 44 rules of the same type per port
• GE24SFP - up to 44 rules of the same type per port.
6.4.3 Configuring ACL
When the SBx3100 is first installed and in service, there are no ACCESSLIST names.
• If enabled for filtering of dynamically learned DHCP IP addresses, dynamic DHCP IP filters are preserved.
• The user can set the default DENY or PERMIT rule for accesslists using the CREATE or SET ACCESSLIST command. See
•
•
•
•
•
•
•
the example that follows for details.
Filtering can be applied to the MGMT and inband interfaces. This allows the user to block certain packets at thc CFC
CPU preventing them from being processed.
Hardware classification resources on ingress ports are limited. In the event the system experiences contention for
resources, an alarm will be raised on the port.
The user is not allowed to add an access list to a port that currently has classifiers in the precedence range reserved for
access lists. The user must remove those classifiers on the port before being allowed to add the access list.
Mapping of a classifier configuration port alarm will not be direct. If an accesslist configuration error occurs, a system
alarm or error indication will be generated. The user can observe, using the SHOW ALARMS command, an error against
an ACL. From there, the user can use the SHOW ALARMS command on the port in combination with SHOW ACCESSLIST
<acl-name> INTERFACE <interface-name> and SHOW CLASSIFIER ALL on the interface command to understand the
root cause of the alarm. The cause of the error will be revealed in the SHOW ACCESSLIST <acl-name> INTERFACE
<interface-name> output. Users can normally diagnose the error from that output. To see exactly which classifier caused
the problem use SHOW CLASSIFIER ALL INTERFACE <interface-name> FULL (note that this is usually not required).
The user must be careful when applying the FUM (From User Multicast) application rule. If applied to the wrong upstream
port, for example an XE port, multicast video could be disabled for the whole system. Refer to 6.3.2 on using classifiers.
Because accesslists use classifiers, the user may observe classifier configuration failure logs/alarms when configuring ACLs.
Refer to the Allied Telesis Log Manual for information about classifier configuration failure.
The user also cannot apply a classifier or access list to an empty LAG (i.e. one with no port members).
Note:
The system will generate a warning message informing the user if or when resources have been exceeded. The user
should investigate classifier-related provisioning, such as IGMP, DHCPRELAY, VLAN (for per-VLAN UFO and
HVLAN), EPSR, INTERFACE (TAGALL option for HVLAN), ACCESSLIST, and CLASSIFIER to determine the reason
for the message.
• For the access list name of Application a match rule of DHCPCLIENT or DHCPSERVER (in Table 6-7) filters on the destination DHCP traffic. In other words a match rule of DHCPCLIENT will filter on the interface's ingress traffic that has a
destination to the dhcp client and the match rule of DHCPSERVER will filter on the interface's ingress traffic that has a
destination to the dhcp server.
601
Access and Security
Introduction
6.4.3.3 Configuration Procedure for ACL
The general sequence to configure an ACL is to:
• Create the ACCESSLIST; if this is for one rule, and interfaces are associated, the ACL is provisioned.
• Add rules to the ACCESSLIST; a rule can also be placed BEFORE an existing rule so that it takes higher precedence over
the existing rule, or AFTER an existing rule so that it takes a lower precedence over the existing rule.
• Add the ACCESSLIST to an interface or set of interfaces.
The general sequence to deprovision an ACCESSLIST is to:
• DELETE the ACCESSLIST from the associated interfaces.
• DESTROY the ACCESSLIST
In the following procedure, the user wishes to only allow traffic originated from a range of IP addresses assigned to customers using the user’s set-top boxes (172.16.5.0 – 172.16.5.15).
TABLE 6-5
Step
Configuration Procedure for ACL
Command
Create the ACCESSLIST stb_range to PERMIT the IP address range.
1
CREATE ACCESSLIST stb_range RULE=PERMIT IPSOURCE=172.16.5.0
SOURCEMASK=255.255.255.240
SHOW ACCESSLIST stb_range
--- Access Lists -------------------------------------------------------------Name
Interfaces
Rule Action Fields
---------------- ---------------- ---- ------- ------------------------------stb_range
1
PERMIT IPSOURCE=172.16.5.0
SOURCEMASK=255.255.255.240
-DENY // all other packets dropped
Since all other packets are dropped, add rule to the stb_range to allow ARP packets through.a
2
ADD ACCESSLIST stb_range RULE=PERMIT PROTOCOL=0x806
// 0x806 is the protocol-type for ARP
--- Access Lists ---------------------------------------------------------Name
Interfaces
Rule Action Fields
--------- -------------- ---- ------- ------------------------------- ---stb_range
1
SOURCEMASK=255.255.255.240
2
PERMIT PROTOCOL=2054
-DENY
If needed, deny a type of packet from the approved range by placing a new rule at a higher precedence. than the Ip
address rule.
3
ADD ACCESSLIST stb_range RULE=DENY APPLICATION=NETBIOS BEFORE=1//ipaddress
rule
--- Access Lists ---------------------------------------------------------Name
Interfaces
Rule Action Fields
--------- -------------- ---- ------- ------------------------------- ---stb_range
1
DENY
APPLICATION=NETBIOS
2
SOURCEMASK=255.255.255.240
3
-DENY
Add the ACCESSLIST stb_range to an interface or set of interfaces.
602
Access and Security
Introduction
TABLE 6-5
Configuration Procedure for ACL (Continued)
Step
Command
4
ADD ACCESSLIST stb_range INTERFACE=eth:10.0
--- Access Lists --------------------------------------------------------Name
Interfaces
Rule Action Fields
--------- -------------- ---- ------- ------------------------------- --stb_range ETH:[10.0]
1
DENY
APPLICATION=NETBIOS
2
SOURCEMASK=255.255.255.240
3
-DENY
Deprovision the ACCESSLIST
DELETE the ACCESSLIST from interface or set of interfaces
5
DELETE ACCESSLIST stb_range
INTERFACE=eth:10.$
DESTROY the ACCESSLIST
6
DESTROY ACCESSLIST=stb_range
Destroy Access List(s) (Y/N)? Y
SHOW ACCESSLIST=stb_range
Error (041154): Access List(s) "stb_range" do not exist.
a. To ensure that only ARP packets from the permitted IP addresses were allowed to pass, the ARP Filtering feature
would be used, as described in 6.13.1.
603
Access and Security
Introduction
6.4.4 Access Commands
Table 6-6 lists the commands that are used for ACL.
TABLE 6-6
Access List Commands
Commands
ADD ACCESSLIST INTERFACE
ADD ACCESSLIST RULE
CREATE ACCESSLIST
DELETE ACCESSLIST RULE
DELETE ACCESSLIST INTERFACE
DESTROY ACCESSLIST
RESET ACCESSLIST RULE
SET ACCESSLIST
SHOW ACCESSLIST
Table 6-7 lists the parameters that are available for ACCESSLIST commands.
TABLE 6-7
Access List Command Parameters
Parameter
Description
ACCESSLIST
The name of the access list. The name may contain a maximum of 22 characters.
604
Access and Security
Introduction
TABLE 6-7
Access List Command Parameters (Continued)
Parameter
Description
APPLICATION
The name of the APPLICATION to match on. APPLICATION is one of
several predefined match rules. Allowed values are:
DHCPSERVER - matches packets with UDPPORTDEST=67
DHCPV6SERVER - matches packets with UDPPORTDEST=547
DHCPCLIENT - matches packets with UDPPORTDEST=68
DHCPV6CLIENT - matches packets with UDPPORTDEST=546
NETBIOS - matches packets with LSAP=NETBIOS; TCPPORTDEST=137,
138, 139, or 445; or UDPPORTDEST=137, 138, 139, or 445
FUM - matches IPv4 multicast packets, i.e., in the IPv4 ad

Allied Telesis Software Reference for SwitchBlade x3100 Series

Transcription

Similar documents

TRACe-NET xM8P2G-1

Westermo Group

Napoleon Container Terminal

Subcutaneous Port Catheter (Port, porta

January 17, 2011 - Village of Port Clements

PDF 1mb - Marina Adelaide

Nov - Ft Myers Knife Club (FMKC)

the perfect condo in port aransas!

SWM-24GTX-4GSF Switch 28 Gigabit Ethernet port

Managed Ethernet Switches - D-Link